Added polkadot for etherans draft #145
Conversation
|
|
||
| Ethereum implements finalization through a system called [Gasper](https://our.status.im/two-point-oh-justification-and-finalization/), a blend of LMD GHOST (Last Message Driven Greediest Heaviest Observed SubTree) and Casper FFG (friendly finality gadget). Finalization is the concept of being so certain a block is correct and cannot be undone that being wrong about this claim would result in the punishment of a large part of the network (a large number of validators). Polkadot uses GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) to do the same thing. | ||
|
|
||
| Both Ethereum and Polkadot separate block production from finalization. In Ethereum, block production doesn't have a special name. In Polkadot, it's called [BABE](https://research.web3.foundation/en/latest/polkadot/BABE/Babe/) - Blind Assignment for Blockchain Extension. This separation makes sure that block production can continue without finalization, theoretically supporting blockchain growth even with a severely reduced number of validators. Once enough are back online, the finalization process can finalize the blocks starting from the last finalized one. |
There was a problem hiding this comment.
Doesnt "theoretically supporting blockchain growth even with a severely reduced number of validators" fall down if finality is not reached for a checkpoint in Ethereum?
Same in next paragraph it may be useful to mention safety issues and lack of finality fallback.
There was a problem hiding this comment.
It's exactly the same in polkadot afaik - chains will keep growing so probabalistic finality kicks in based on number of primary blocks in a fork. In Ethereum, the number of votes (attestations) for a particular block is used for added weight during fork choice when justified/finalized blocks aren't around to guide the validators.
|
Going to continue with this review shortly, only got about 1/3 of the way through. Looking good so far! |
Co-Authored-By: Bill Laboon <[email protected]>
Co-Authored-By: Bill Laboon <[email protected]>
Co-Authored-By: Bill Laboon <[email protected]>
Co-Authored-By: Bill Laboon <[email protected]>
Co-Authored-By: Bill Laboon <[email protected]>
Co-Authored-By: Bill Laboon <[email protected]>
Co-Authored-By: Bill Laboon <[email protected]>
Co-Authored-By: Bill Laboon <[email protected]>
|
|
||
| - Ethereum shards: identical (homogenous) chains with shared security, splitting the network's load by evenly distributing it | ||
| - Parachains: different (heterogenous) chains with shared security, splitting the network's load by making sure each chain deals with its own specific context | ||
|
|
There was a problem hiding this comment.
The parachain section needs some work in structure and also information about the availability and validity scheme. It should be mentioned that we are using much fewer miners than ETH2.0, and we can do it because of the availability and validity scheme. We should also mention that we assign validators randomly to parachains who are then responsible for its validity and availability. There should be a mention of fishermen there too. The auction scheme should e in a separate paragraph. There should be a note on how these design decisions impact security. Nested relay chains should ideally maybe not be mentioned at all since we still have to figure out how to do it, we had meetings about it but the design is not finalized. I would also avoid using "legit".
| One thing that should be noted is that if a parathread is using a local currency to reward collators, the collator must be natively aware of a DOT->local conversion rate if they are to be able to submit appropriate bids for block production in DOTs. That's an economic problem for a parathread to solve on its own. | ||
|
|
||
| Parathreads also require deposits in DOTs, but as mentioned earlier they are _much_ smaller than the deposits needed for parachain slots, and there's no auction for slots - the capacity is estimated to be enough for everyone interested to join. | ||
|
|
There was a problem hiding this comment.
Parathread section:
-A special case are Polkadot's parathreads. A special case of what?
forward reference to ICMP is not necessary
the word slot is used in many places: block slot, parachain slot, this slot (?) , parathread slot and sometimes the word slot is not used. It causes a bit of confusion.
what type of auction is used?
comparison to mining in Bitcoin and Ethereum
-line 40 seems redundant
| Ethereum has **no on-chain governance** of ether holders and will probably never have such a system. The decision-making is ultimately social and political, which [can be dangerous for the health of the network](https://decrypt.co/5219/progpow-kristy-leigh-minehan-ethereum-mining-asic-gpu/) due to effective lobbying. | ||
|
|
||
| Polkadot comes with **governance built-in** from the start. Three layers of vote holders exist in Polkadot - technical committee, council, and stakeholder (any DOT holder). The Technical Committee can - with the agreement of 3/4 of the Council - propose fast-tracked referenda which have shorter voting and enactment times, mainly for emergency upgrades. Members of the TC are different developer teams of the Polkadot Runtime and Runtime Environment. The Council and Stakeholders can make proposals for referenda, and referenda can change almost any aspect of the chain - from number of parachain/validator slots available, to payout fees, treasury expenses, and more. | ||
|
|
There was a problem hiding this comment.
Governance Section:
- I would start by saying that proposals are made that are voted by Stakeholders.
- as far as I know, both council and technical committee are not layers of vote-holders but they can make a difference in the urgency of referenda and priotity of proposals.
- add (TC) in the second sentence after the Technical Committee.
Comments by Alfonso:
It is not the case that stakeholder-suggested proposals have positive turnout bias and council proposals have negative turnout bias. Rather, regardless of who suggested it, the bias depends on the proportion of council members that support the proposal. If it's a minority, there's positive turnout bias (bias towards status quo); if there a majority of council members approving it, then there's no bias (majority carries); and finally, if and only if there is unanimous support from the council, there is negative turnout bias (bias towards approval). And all of these biases tend to majority carries as the turnout tends to 100%.
| _Side note: in Ethereum, members of the Technical Committee would be teams like Nimbus, Chainsafe, the Ethereum Foundation, Pegasys, Prysmatic, Parity, Sigma Prime, and others that are developing Ethereum 2.0 clients._ | ||
|
|
||
| Stakeholder-suggested proposals have a positive turnout bias, which means a super-majority is required for the proposal to pass. As turnout increases to 100% this ratio edges closer to simple majority i.e. majority carries (50% + 1 vote to win). Council proposals are opposite - they are leaning towards passing by default and need a negative super-majority to fail. Again, as turnout approaches 100%, majority carries is in effect again and there is no difference between the negative and positive turnout bias. Proposals to spend Treasury money are voted on by the council, not the public. Votes are tentatively plutocratic in a one-coin-one-vote way, but can get a buff by the voter indicating the desire to lock the tokens in the vote for a period of time. Quoting from the [Kusama Rollout and Governance post by Gavin Wood](https://medium.com/polkadot-network/kusama-rollout-and-governance-31eb18041044): | ||
|
|
There was a problem hiding this comment.
I think this paragraph needs an intro sentence. Also, what does "buff" mean? It should be specified or mentioned that this is only a proposal.
| > All voters are required to hold for the 30 day period up until the enactment date in the case that “their side wins” (if not then they are otherwise free to sell and leave the network). Those willing to hold for twice as long gain an additional vote. This is the case for up to five additional votes (i.e. those willing to hold for approximately two and a half years gain six votes). Those unwilling to hold at all may still vote but with a 90% reduction in power compared to those who hold for the four week minimum. | ||
|
|
||
| Plans exist for adding more governance bodies, but for details on that I recommend reading the post linked above. | ||
|
|
There was a problem hiding this comment.
I would remove the sentence in line 54, it doesn't help the reader to understand more.
| Plans exist for adding more governance bodies, but for details on that I recommend reading the post linked above. | ||
|
|
||
| It should be noted that making proposals for spending the Treasury's funds (see next section) requires a deposit of 5% of the target amount which is burned if the proposal does not pass, and that the Treasury must be spent entirely every period of 24 days, otherwise it has to burn some of its remaining funds. Both of these mechanics make for some deflationary pressure (see next section). | ||
|
|
There was a problem hiding this comment.
I don't think referring to the next section is necessary for this paragraph.
Comment by Alfonso:
"the Treasury must be spent entirely every period of 24 days, otherwise it has to burn some of its remaining funds."
I think that's not the right way of putting it. There's nothing wrong with not using the full budget, or in other words, using the budget to produce deflation, could be a perfectly valid decision
|
|
||
| However, it too will probably be mitigated by using a VDF - verifiable delay function. In layman's terms, a VDF is function which is mathematically proven to take a long time, and cannot be sped up by throwing more computers at it (it is non-parallelizable). This delayed function executes another mathematical operation on top of the RANDAO number in order to make the result come "late" - an hour and a half after the numbers have been revealed. Special devices called ASICs will be running these functions, and they will be open source and distributed freely. There is no incentive for running them. For more info on Ethereum 2 randomness, see [this post](https://our.status.im/two-point-oh-randomness/) and for more info on VDF, please see [the VDF research site](https://vdfresearch.org). | ||
|
|
||
| In Polkadot, VRF is used. VRF stands for verifiable random function. It's much simpler than RANDAO and VDF in that the validators who are participating in the network have a secret "randomness roll key" which is regenerated for every slot. They use this randomness key along with some other inputs (the randomness of the previous epochs and the slot number) to generate a random number for themselves and only themselves. Then, they compare this number to a protocol-defined number (a so-called threshold) and if their number is less than that threshold, they are a viable candidate for producing the next block. If they rolled too high, they should skip this slot. |
There was a problem hiding this comment.
-first sentence way too short.
-what is a slot? You used slot earlier for the parathreads and parachains.
| Randomness is very important in blockchains using proof of stake. You need a way to reliably randomly select a subset of your validators to do some work. If this randomness is even the least bit predictable, then it can be abused and validators can game the system by always making sure it's their turn to be rewarded, or by attacking those they know whose turn it is in order to get them punished for unavailability. | ||
|
|
||
| In Ethereum 2.0, randomness will come from a two-part system: the first is RANDAO, the second is VDF. RANDAO is what's called a commit-reveal scheme in which, to put it plainly, many validators secretly pick a number, and then the result is some mathematical operation performed on all those numbers, revealed one by one. Since it is not possible to predict which number all of the validators will chose, and the final output can vary wildly depending on just a single one of them, it's not possible to predict this random number. However, it is possible to influence it because the last revealer always has the option of not revealing his number, after he calculated that the current number is more in his favor than the one with his reveal. The chances of this happening are miniscule and the advantage to be gained by this bit-level influence would have to be immense - the network is plenty secure even without mitigating this risk. | ||
|
|
There was a problem hiding this comment.
how many times can someone do that attack? If it is many times, it is a serious attack...
| In Polkadot, VRF is used. VRF stands for verifiable random function. It's much simpler than RANDAO and VDF in that the validators who are participating in the network have a secret "randomness roll key" which is regenerated for every slot. They use this randomness key along with some other inputs (the randomness of the previous epochs and the slot number) to generate a random number for themselves and only themselves. Then, they compare this number to a protocol-defined number (a so-called threshold) and if their number is less than that threshold, they are a viable candidate for producing the next block. If they rolled too high, they should skip this slot. | ||
|
|
||
| The VRF function which they use to roll this number is deterministic, so they cannot reroll to try again - for the same input, the same output will be produced. This function also produces a _proof_ - some data that proves the randomly rolled number is legit, without actually showing the roll or the inputs that went into it (thereby keeping the roll key secret). | ||
|
|
There was a problem hiding this comment.
The VRF function which they use to roll this number is deterministic,...
| Crosslinks are how shards in Ethereum will be communicating. By telling the beacon chain that a state change has occured on the shard, the other shards which depend on fresh data from the changed shard need to query it manually. In other words, they need to know what they don't know so that they can request it. This will be a user-land implementation detail and will depend entirely on how wallets, IDEs, protocols and other users of Ethereum implement this communication. | ||
|
|
||
| ICMP or inter-chain message passing is Polkadot's way of establishing communication across parachains and parathreads. Each chain and thread have an ingress and egress queue - a queue for incoming and outgoing messages, respectively. Messages are transactions meant for another chain or thread, which are forwarded to the destination parachain or parathread on every block through common collators - collators that are using both of the communicating chains. Since we assume that people will be running collator nodes for different chains at the same time, there should be a reasonably stable mesh effect going on allowing for messages to successfully gossip across to their destination. As a backup, in case some chains or threads are islands and have no other connections, validators will also make sure that ingress and egress queues of the chains and threads they are processing are empty. If not, then they will assume this role of message relayer. | ||
|
|
There was a problem hiding this comment.
ICMP design has changed a bit. Al can provide input on that.
|
|
||
| |Name |Role |Incentivized|Optional | | ||
| |-----------|------------------------------------------------------------|------------|---------| | ||
| |Collator |Full node of particular shard. Passes on data to validators.|Possibly |No | |
| |Nominator |Nominates a validator through which to proxy-stake. |Yes |In theory| | ||
| |Fishermen |Monitor the network for misdeeds like equivocation or illegal randomness.|Yes|Yes| | ||
|
|
||
| Validators can be fishermen, which makes fishermen optional. Nominators are _theoretically_ unnecessary, i.e. the network would work fine without them if the validators had enough self-stake to keep themselves in the validator pool, but the relay chain will almost certainly have them in practice.. |
| |Name |Role |Incentivized|Optional | | ||
| |-----------|------------------------------------------------------------|------------|---------| | ||
| |Collator |Full node of particular shard. Passes on data to validators.|Possibly |No | | ||
| |Validator |Full client of all parachains and parathreads. Proposes and attests to blocks based on collator data. |Yes |No | |
There was a problem hiding this comment.
Every validator is not necessarily a full node of all parachains but only has to be to the one it is currently assigned to. A validator proposes relay chain blocks and attests to parachain blocks.
|
|
||
| A collator is a full node of a specific parachain. The collator passes data which becomes a block candidate, along with proof of the state transition so that the validator can replay and verify it. The collator most likely depends on the local economy of the parachain - probably a local token. A parachain can also use wrapped DOTs as a native token, and a local token purely for governance or similar, and there's the possibility of token-less collators too (in, for example, a PoA chain). | ||
|
|
||
| Fishermen earn money for each valid report they make on some wrongdoing - the slashing amount is in part burned, in part sent to treasury, and in part given to the fisherman who reported the issue. The amounts depend on the offence and on how many other validators are in the same predicament (e.g. the offline penalties are much bigger if many validators are offline at the same time). |
There was a problem hiding this comment.
Fishermen have to put in stake too I think, to prevent spamming.
|
|
||
| Fishermen earn money for each valid report they make on some wrongdoing - the slashing amount is in part burned, in part sent to treasury, and in part given to the fisherman who reported the issue. The amounts depend on the offence and on how many other validators are in the same predicament (e.g. the offline penalties are much bigger if many validators are offline at the same time). | ||
|
|
||
| There is no limit to the amount of stake a validator can commit, and the active validators are picked from the top most-staked validators (including nominations) once per era (24 hours). This ensures that all the top validators have approximately the same amount of staked DOTs, and that a single whale can't effectively take over because the reward per validator is the same - it's not proportional to the staked amount. Therefore, the reward per dot is less when you stake more, but the penalty per offence is greater because penalties are proportionate to staked amount. This system incentivizes nominators to nominate less popular validators, keeping the distribution balanced. |
|
|
||
| Finally, let's talk about the meat of the protocol - the execution layer. | ||
|
|
||
| In Ethereum, there will be the concept of Execution Enivronments. These will be special runtimes built by special teams and funded by special interests to run and execute custom code. In other words, if someone wants to build the ability to process Bitcoin-like transactions into Ethereum, they need to fund a UTXO-execution-environment and make sure all clients add it to their code as well (likely helping with funding those efforts, or contributing outright). Once done, the execution environment becomes available to everyone - it's considered a network upgrade. |
5 participants
No description provided.