randao
eth2.0-dafny
randao | eth2.0-dafny | |
---|---|---|
7 | 3 | |
826 | 65 | |
0.0% | - | |
0.0 | 0.0 | |
about 1 year ago | over 2 years ago | |
JavaScript | Dafny | |
GNU General Public License v3.0 only | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
randao
-
Gas is the cheapest it's been in a long time. Imagine that this will be the norm a year or so from now
There's really no "forcing", in sharding validators are randomly assigned to a shard, similarly to how they're currently randomly split up into committees that attest to the validity of blocks. There's no centralizing force: the randomness into the process is provided in a decentralized fashion by the validators themselves, through a mechanism called RANDAO.
-
Explaining Ethereum's consensus mechanism after The Merge
Article author here.
Great questions, should have explored the randomness beacon more. Ethereum uses [RANDAO](https://github.com/randao/randao), which is a distributed commit-reveal scheme where participants in the generation post a hash of their data on the commit portion and then at a later timestamp reveal the data preimage, and get slashed if they do not reveal a correct preimage. Then all participant data is aggregated together. This means if there is at least one honest participant the generation will be random.
A supermajority (2/3rds) of validators is required to finalize a block, in case of a 50-50 network partition blocks would stop being finalized and attestation rewards would stop. Non-participating validators would slowly leak stake through the inactivity leak until online validators once again had a supermajority. This is the "self-healing" mechanism that allows both safety and liveness.
-
How does Eth 2.0 PoS choose block proposer randomly?
https://github.com/randao/randao Is this what you’re referring to? It says it’s a DAO.
-
Proposals on random
So according to this generating randoms for the eth chain is like validating but with shorter cycle and more profitable. Now I have even more questions like: How can I participate Is there software like prysm for using random contracts What is the minimum stake for random contracts Is anyone doing this, is it wort it
-
Suggestion for multiple-user seed
Thank you Eric, I discussed it too in the PoolTogether discord and got this reponse from one of the founders: " What you're describing is a version of "RANDAO". See here: https://github.com/randao/randao Really, the VRF is an unnecessary step if a seed is being selected by all participants If you look through the above project, you'll see they try to handle a few corner cases like if a user refuses to reveal their seed, or preventing a seed from being used twice The trouble with Randao is the amount of coordination and expense that it incurs. " I understand ETH 2.0 will be doing some implementation of RANDAO along VDFs for the Beacon chain. Algorand implements this too. I found this talk from Justin Drake talking about this algorithm: https://www.youtube.com/watch?v=zqL_cMlPjOI
eth2.0-dafny
-
Explaining Ethereum's consensus mechanism after The Merge
> The implementations are also very close to formally verified if not fully formally verified.
So is Eth2, see "Formal Verification of the Ethereum 2.0 Beacon Chain" by Franck Cassez, Joanne Fuller, Aditya Asgaonkar, paper (https://arxiv.org/abs/2110.12909) and source code (https://github.com/ConsenSys/eth2.0-dafny). More efforts to formally verify Eth2 is ongoing as well, by different entities.
> Nothing is perfect but cryptographic code has to be pretty bulletproof or a lot of systems would get owned
Same with Ethereum. The chance of having a major impact with a vulnerability is even higher I'd argue, as you can easily extract currency you can trade for USD, and the entire network is inter-connected, so finding targets to exploit becomes even easier.
Point still stands that cryptography goes over a lot of peoples head, but you don't hear those people complaining that because they don't understand it, no one does.
-
How does the Dafny Programming Language compile-time check its constraints?
Things can get pretty complicated fast, with lots of assert statements:
- Formal Verification of the Ethereum 2.0 Beacon Chain
What are some alternatives?
ethereumbook - Mastering Ethereum, by Andreas M. Antonopoulos, Gavin Wood
openzeppelin-solidity - OpenZeppelin Contracts is a library for secure smart contract development. [Moved to: https://github.com/OpenZeppelin/openzeppelin-contracts]
openzeppelin-contracts - OpenZeppelin Contracts is a library for secure smart contract development.
truffle - :warning: The Truffle Suite is being sunset. For information on ongoing support, migration options and FAQs, visit the Consensys blog. Thank you for all the support over the years.
teku - Open-source Ethereum consensus client written in Java
annotated-spec - Vitalik's annotated eth2 spec. Not intended to be "the" annotated spec; other documents like Ben Edgington's https://benjaminion.xyz/eth2-annotated-spec/ also exist. This one is intended to focus more on design rationale.
prysm - Go implementation of Ethereum proof of stake
lighthouse - Ethereum consensus client in Rust
consensus-specs - Ethereum Proof-of-Stake Consensus Specifications
web3.js - Collection of comprehensive TypeScript libraries for Interaction with the Ethereum JSON RPC API and utility functions.
nimbus-eth2 - Nim implementation of the Ethereum Beacon Chain