(78.94%) Target correct: 1149956/1386000 (82.97%) Target timely: 1149956/1386000 (82.97%) Head correct: 1111231/1386000 (80.18%) Head timely: 918835/1386000 (66.29%) Sync committees: 12927/14336 (90.17%) Overall Network Report: ![overview-resource-use]**(https://storage.googleapis.com/ethereum-hackmd/upload_f0c32807e29183674d9b13b823de6817.pn
11/29/2024Considerations Resource use: CPU, Disk, Cost, I/O Syncing and Sync complexity increase Complexity of Implimentation and Testing Time for conversion to take place Ideological Methods Overview
1/18/2024Thanks to Barnabé, Andrew, Sam and Marius for the review and discussions Introduction As the topic of Gas limit increase has surfaced recently, I thought I'd spend some time compiling thoughts from various places and try to enumerate a path forward to increase the limit safely. In its current form, Ethereum consists of 2 layers, the Execution Layer (EL) that is responsible for handling transactions, state, history, building blocks and the Consensus Layer (CL) that is responsible for consensus. The CL consensus engine is currently a combination of Casper the Friendly Finality Gadget (Casper FFG) and the LMD-GHOST fork choice algorithm. This consensus engine is strictly time dependent and introduces a concept of Slots and Epochs, there are tasks that need to be completed at certain periodic intervals by the validators. Two such tasks that we will consider are called Block proposals and Attestations. A block proposal specifies what the assigned validator thinks the canonical slot needs to be and the attestation specifies the vote of each validator for said proposed slot. Each interval (slot) is 12 seconds long and the specification says that the validator must attest as soon as they see a valid block or at the 4s mark into the slot. This introduces the concept of a deadline for the attestation task, i.e, under ideal conditions we'd want every validator on the network to attest to the canonical slot with a valid block before the 4s mark. On receiving information about the proposed block, the CL triggers a engineAPI call called forkchoiceUpdated(fcu). If the EL has all the data it requires, then it verifies the block and responds with VALID. Until this verification is complete, the CL cannot proceed with its duties, implying that the verification needs to ideally be complete within the 4s mark. There are a couple of variables at play with regards to this verification time: It depends on when the CL sends it the fcu, how big the block being verified is and if the EL already has all the data required for verification. A higher gas limit would be one factor that affects this verification time. The presence of Blobs also adds some complexity to this systems as a slot isn't valid until all the blobs proposed in it are fetched from the network and verified. The CLs do this in parallel, i.e once the block is received the fcu is issued, the block is then imported into forkchoice once the blobs have been deemed valid and available. The trigger for both tasks are handled by the CL, since they are done in parallel we would need to analyze which aspect takes the longest. If the blob fetch and verification takes longer, then the assumption is that on this one metric we can potentially afford to increase the EL gas limit. If the block verification takes longer, then on this one metric alone we can potentially increase the blob count. However, we do need to ensure that in any case the tasks are complete (ideally) in under 4s across the network.
1/18/2024Problematic slots: 7413760 and 7413770 Missing keys(all patched): 10K EF (Running Prysm), 40k Nimbus (non-upgraded nodes), 40k Prysm Root cause: Prysm had an issue where on the upgrade to deneb they zero-ed out the historical root. The devnets all forked at <256 epochs, meaning the network was too new to even hit one cycle of SLOTS_PER_HISTORICAL_ROOT. So we never triggered this issue in devnets. Ideally the spec tests and hivetests get updated to catch the problem 7413760
1/17/2024