lighthouse VS randao

Lighthouse — an Ethereum consensus client (written in Rust);

Daily Goerli: A whole lot more detail on the lighthouse db corruption issue I posted about previously. There's a warning that's been quite frequent on my erigon nodes for a while that doesn't seem to have any impact on its performance. I asked if it should be downgraded to INFO here.

According to lighthouse team, the root cause was beacon node waited too long before requesting the payload header. All details here : https://github.com/sigp/lighthouse/issues/4312

Update LH to 4.0.2-rc.0 More info here https://github.com/sigp/lighthouse/releases/tag/v4.0.2-rc.0

Which is not true... full nodes are consuming a lot of CPU now... hot-fix was released, but didn't solve the problem completely: https://github.com/sigp/lighthouse/releases/tag/v4.0.2-rc.0 ... more hot-fixes will be needed

https://github.com/sigp/lighthouse 142 contributors

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.

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.

https://github.com/randao/randao Is this what you’re referring to? It says it’s a DAO.

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

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