-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create P2PStateChannels.md #2350
Conversation
CLA Assistant Lite bot: Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. Please submit the following text as a separate comment: I have read and hereby sign the Contributor License Agreement. You can retrigger this bot by commenting recheck in this Pull Request |
Thanks for the application @lukastanisic99 very interesting tech indeed. My only question is, the milestone states, "Everything is done". Does this mean everything has already been implemented, or just that the milestone spreadsheet is finished? |
@keeganquigley Well we did do a lot of the work already, but it's not complete and there's still a lot of work to be done and even later on maintaining and improving the system. The one milestone proposed was intended to be on completion of our V1 alpha and when everything is runnable. We could break it down further into smaller milestone that we can claim before the alpha if that's what you're referring. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lukastanisic99, we recently updated our terms and template to include a flexible DOT amount, can you please update your document to include this? Please keep in mind that this is a rather large amount you are asking for, so the bigger the DOT share, the better.
@semuelle We're fine with taking 100% in DOT with 50% being vested over 2 years, if all the DOT goes through a vesting process then we'll have to do 50% DOT and 50% USDT. Before I update the doc, can you clarify can we chose the % of DOT that has to be vested (minimum 50%) or all DOT received has to be vested, forcing us to take a portion in stablecoin? Normally we wouldn't mind taking 100% in vested DOT, but we have immediate costs.. |
Hi @lukastanisic99. Thanks for the quick reply. Currently, we only offer payment in fiat and stablecoins beside the vested (!) DOT portion. I will check internally if we can make an exception, but for now I would suggest we continue with this information. |
Ok I've modified the doc to make the Milestone more clear (could break it down further if needed), added the USDT address on Asset Hub (same as DOT) and added the DOT % and indicated that we're willing to take 100% in DOT with 50% vested if that's possible. Maybe better to not squash future modifications so it's easier to keep track what has changed? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @lukastanisic99 is there a chance that you'd be willing to come up with a proposal that is under $100k? As anything over this amount requires approval from the W3F council, and it could take a while to put it up for discussion. I will also say that we don't fund deliverables retroactively, so anything that has already been built could be removed from the milestone tables. Perhaps that would help to further reduce the scope/cost.
Hey @keeganquigley sure. I'll come up with a milestone that includes a minimal feature set so It's still runnable, but doesn't have all the features. I'll update the proposal later today or tomorrow. On the retroactive part - we did do some things (in private repos), we can always ctrl+A, delete and start from 0. Regardless that's not the point, there's still a lot of work to be done, so we'll try a figure out today a minimal set that works and update the proposal to reflect that, so we can continue and move on. |
Thanks @lukastanisic99 sounds good; you can always break it up and apply for subsequent grants down the line. |
I've updated the proposal to be within budget and explained what's included in the milestone. Take a look and let me know what are the next steps. |
Sounds good @lukastanisic99 thanks for the changes. I will go ahead and mark the application as ready for review so other committee members can comment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lukastanisic99 feel free to have a look at my comments. Apart from that, I'm currently talking to W3F-internal researchers, will be back soon with additional feedback.
@takahser I've merged your recommendations and clarified the section around FTE |
The system is composed of a client side framework/SDK and on-chain smart contracts. | ||
|
||
Tech stack: | ||
On-chain: smart contracts (solidity) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The performance hit to polkadot here is minimal since they'll run rarely, given the whole system is a state channel. In the longer term, I'll push cyril on the compiler side for this, but maybe he pivoted to targeting primarily polkavm over wasm, not sure.
|
||
Tech stack: | ||
On-chain: smart contracts (solidity) | ||
Off-chain (p2p) - written in typescript, holepunch for p2p and discovery, ethereumjs for running the EVM on client, ethers for manipulating and signing evm data and everything else is built from scratch (typescript). The entire design is state machine and runtime independent (can support substrate) - it works with native tooling. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worth clarifying that the application's solidiy run primarily on the user's side here, in the optimimistic case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it runs on the users side. Only during a dispute, when proving an incorrect state transition, the same bytecode gets invoked on-chain.
2) State machine replication - allowing connected peers to commit to state machines and allowing them to progress and replicate those state machines, | ||
3) Agreement tracking - tracking agreements on the order of transactions and state, managing forks, checking and collecting signatures, finalizing state | ||
4) Virtual (logical) clock - Having a local logical clock that’s synced to the DLT clock (timestamp) - allows peers to have a local perception of time that mimics the one of the DLT, but tolerates skewness to a degree. This is of course subjective and peers will never reach consensus on the clock nor with other peers nor with the DLT itself. This is very important and will be discussed further below, | ||
5) Dispute handling - constructing fraud proofs when a peer deviates from the protocol, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess "fraud proof" is fine here, but mostly it just returns to running on-chain
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes
|
||
p2pTime - the max amount of time a peer can take to decide, execute and broadcast their Tx to other peers, | ||
agreementTime - accounts for reasonable network delay, execution time and skewness of clocks. All agreements on the Tx (state transition) should happen within this time, | ||
chainFallbackTime - if p2p agreements fail within p2pTime + agreementTime, this is the last resort allowing peers to post on chain. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least in the obvious applciations, you could move everything back off-chain after doing the on-chain stuff resumting from a timeout claim. I'm not sure that optimization is worth the development costs though, exspecially if this rarely happens and everything eventually winds up compiled to polkavm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes
|
||
Before explaining optimistic consensus, it’s important to understand the structure of a Transaction in this system: | ||
|
||
A transaction in this system references the exact state (previousStateHash) to which it is an input, and references the expected state post execution (stateHash). This resembles the logic behind UTXOs to a degree. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the required to be linearly ordered? That's slightly more than what UTXOs do. It's also what you expect when doing full state. Assuming yes, anything else should proibably be future work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll punt on this for now, because the simplest thing alraedy makes sense for initial applications.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
@keeganquigley updated the doc + all shareholders completed KYC |
Great thanks @lukastanisic99 I see it is pending now. Will let you know when we get a result, it can take up to three days but is usually faster. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re-approving.
Thanks @lukastanisic99 while waiting for KYB, could you also please add a Legal Entity section with the registered physical address as shown in the template? Thanks! |
20714bc
to
4e54666
Compare
@keeganquigley done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re-approving.
@lukastanisic99 please avoid force-pushing in case of future updates, to make it easier for us to review the changes. Note that the commits will be squashed anyway when merging to master.
@keeganquigley I've received an email that the KYB/KYC process in completed - double check on your end and let me know if there's anything else to do. |
Thanks @lukastanisic99 I can confirm it passed, so now just waiting on the last two approvals. I pinged the committee again w/ the status update. |
@laboon @SBalaguer @aeronbuchanan @rrtti @PieWol can anyone take a look and approve since we have 4/5 and want to finish this? |
@lukastanisic99 I'm looking into it, should be able to provide feedback (if any) by end of day today. |
@lukastanisic99 forgive me if I missed this from the long previous discussion, but where are you planning on deploying the smart contracts for the on-chain part? |
@SBalaguer just to clarify, this is a public good SDK/framework to develop and deploy pure p2p state channels as described above. As such, we don't impose any restrictions on developers where they should deploy (nor could we if we wanted to - permissionless). The contracts can run in any EVM, so we assume most people would deploy their contracts to Moonbeam, Astar or any parachain that implements the EVM pallet (which many if not most already do). We also designed it to be VM agnostic so it can later support the PVM, but too early to cover that now. |
1 similar comment
@SBalaguer just to clarify, this is a public good SDK/framework to develop and deploy pure p2p state channels as described above. As such, we don't impose any restrictions on developers where they should deploy (nor could we if we wanted to - permissionless). The contracts can run in any EVM, so we assume most people would deploy their contracts to Moonbeam, Astar or any parachain that implements the EVM pallet (which many if not most already do). We also designed it to be VM agnostic so it can later support the PVM, but too early to cover that now. |
Sorry for the double comment - seems github mobile glitched out |
No worries at all @lukastanisic99, thanks for your answer. I'm looking forward to see how this develops! I strongly recommend ensuring compatibility with the PVM as stated on the comment. |
Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions. |
Project Abstract
Tech part of -
https://docs.google.com/document/d/1DcDFScgeXijnXSGuaa30uOnYNtRm_9OnAsM97igrSwA/
Grant level
Application Checklist
project_name.md
).@_______:matrix.org
(change the homeserver if you use a different one)