eth2.0-dafny VS lighthouse

> 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.

Things can get pretty complicated fast, with lots of assert statements:

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