execution-specs VS lighthouse

EIP6780 (SELFDESTRUCT only in same transaction) is planned for the Dencun upgrade. (See Cancun included EIPs https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md)

I followed the link which took me to https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md and then I started getting a little lost on the details.

@ TimBeiko: teams felt comfortable moving forward with Goerli, which we agreed to fork on March 14, 10:25pm UTC. I've opened a PR to update the specs accordingly: https://github.com/ethereum/execution-specs/pull/724

Mar 01 08:37:30 computername geth[402568]: INFO [03-01|08:37:30.496] - Homestead: 1150000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/homestead.md)

EIP-4844 is slated for the Cancun Fork.

If you know Python you can read around the execution layer specs, namely for the EVM. Technically the "source of truth" for execution layer specs is still the yellow paper and EIPs but there's ongoing effort to turn it all into testable and executable specs. Otherwise this paper specifically goes in depth on the data structures used throughout the execution layer

You can see them here https://github.com/ethereum/execution-specs/pull/633/files

EIP-4895 for staking withdrawals is the main proposal members cared about, and it was upgraded from "EIPs Considered for Inclusion" to "Included EIPs" in the latest Shanghai specs. The other 3 are just minor changes.

The following EIPs have now been upgraded from "EIPs Considered for Inclusion" to "Included EIPs" in the latest Shanghai specs.

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