The following should act as a braindump of things we need to investigate before giving an okay to 100MGas. All worst cases are collected in geth via statetests. The fuzzers used for finding these are not sophisticated and this analysis should be replicated in a less time constrained manner. Hard requirements Modexp repricing: the worst cases we see are around 6 seconds per block (addressed in Fusaka) BN256Add repricing: the worst cases are around 4.7 seconds per block BN256Pairing repricing: the worst cases are around 2+ seconds per block BN256Mul repricing: worst case around 2+ seconds per block LOG repricing or changing the devp2p limits for receipts
6/16/2025Holesky has not been finalizing for a couple of days now. We need a healthy chain for staking pools to test their setups and it is pretty clear that it will take Holesky longer to finalize again. A solution to this is to do a shadowfork of holesky in order to allow staking pools to test on Pectra. Note that pools can not test their setups on Sepolia, since Sepolia uses a permissioned validator set. Since we are still collecting a lot of useful information from Holesky, we do not want client teams to stop their nodes over there. It is a good experiment to see what happens to the network when so many validators leak out or get mass-slashed. The Plan We do a shadow fork of the chain before the Pectra fork, and gothrough the transition The network would be run by PandaOps, with ~1.5M keys We use the validator set of Holesky before the Pectra fork as the new genesis set and replace the public keys of all client teams with keys owned by PandaOps.
3/4/2025BLS G1 MSM exploration Input: 0x000000000000000000000000000000000f89ff59d6cdf6a80a4bd2ef847d7328cdda8153f9119dc8252cba7cbc065e7ce635d2eb538044387eea8db2219537a9000000000000000000000000000000000a3468224c7a9d4df13ab6a64fe7fd3eb6ecb716156646f0eced5708f69f994061bba0a3a4b741bc4f9c23ba69ef061ec1828e413dd0b08fdbb04763c308d2a013df3c193dd49d3a9633745f01c88eb70000000000000000000000000000000014c03a472acfd2837196af16b56a9c1519b443792aa8f14b100feab759c0b6b1938e126127f3d173495086dd50cedbd30000000000000000000000000000000002c20dcc4e6297a90b616c15dacae186a7c1cdd6d8fcd966cb73d02bc05ec242ea6d8aa9bef1af14a147c6a2b267b1393c40185d7f2594cb94d67ca0b72133e84869482dd62fd960879056142304d42a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e40e1db8fcbf3dbb91727e166ce0ec04bb2f18767b3448bee52e27ea1bababff00000000000000000000000000000000051d1dab66442184421fcb55a61c20c6923d156554229b4955668c7dffb3a78174e681472f0c162a6567ec5219e60f820000000000000000000000000000000018a1f5c6e281acc223e3f01d3a57831a3385be683887d035902ae6fc7b6e42c995553b7e1c66a43055400b0308c50bf69324ac82a05b52103cc501da438c983630b00b5b214f7329bcb332df877a740d0000000000000000000000000000000013529240d0dd34047826b80c7efe64af519fc3546ea1eaa11ba3cb2d34fcc5599d192d933137562f18852310676b5b3000000000000000000000000000000000056cea5afa7af7fc45a918727e19ed2c09f40352bd975af75cb3e369da2088fa1d596f584399046532401e40b32e01684f9f0ab9972051f489993ff43f551124ee6aca7644b3b159d2957a03b3ab8bab0000000000000000000000000000000006558d2dffd0361e5eb65fbe8b7244d2ecdfb5602a0be94f2dfbd3b5186a2ef105f24289e671d55a88754cdd4acc83b3000000000000000000000000000000001410a4c89d2cd95c2cc3b887bc46d32f779d935b5678234f22212bae81da8e78dfd3b6bc34b1aaaab2e235ee64c76c1f1c61cf76958db68e901b9b53298b684ccd1db78a3e9ff2ada5666b76217c92dd000000000000000000000000000000000cb01d33935474a2b4ea10afb5c657d2d48f418d81604f33531778300bdecc7140b3c2baa8811aff436576938a227066000000000000000000000000000000000ae4fceb8677d4d7fbdb1a07932648edffe82543fba4caf18b98508e1bc079f65dd066a1efa8baea4fd682c82d223cd6aa39b6b9978d9c743c5333dc3771fe5ce6e48f073b90b62d18ac14b7da956d32000000000000000000000000000000000d3306579eb93622e67fef53d8bb839f03651af8c8694bc22b5efbb7529f82dcd25bd30cdea21c489c9ff37490abea8900000000000000000000000000000000095a82b42b7551d947c0c5237d29b268bdc6563fec3adb6b38888c8e29f7e9590fd0e1bfd728c8301be6f47ead55ac5363fe50f3bc82261da2c96158247eb47b2131608386e7b094eac2e172d9a5fa0c000000000000000000000000000000000d3aff0f3b2e6f4878f15a81eabab5d8c9f765bc93ae0a2f0da5ed1941b4924bca4516661600c41a74beeb243695b52d0000000000000000000000000000000016ce48c345cce7cd395692cecbb8704bcb29645135c8ac366c4e5c40dead3c218814904df7d4c92cbb9aa956bbb1deabc03d1856de9cf1e3403fb4278b85c65685c1723eb5d0a2437769ef423476cb11 Output: 0000000000000000000000000000000011ed5c29653e93c0d6f3e39e82cd916958e091eefc94659b3a08fc2df138e8f1b9eb8ba7f7370d72a66195b8e7cf39f80000000000000000000000000000000012c3e6183bb3094f71b7b8e9ec4b73e4b9f71cf244a41739f148cc5f92e4b8bd7a00a0b29113fe5100d332af974e3ebb
3/3/2025Summary: With the recent rise in MEV, private mempools, blob txs, AA, the role of the public mempool changes. In this session we discuss what the issues are and what we might be able to about it. Facilitator: Marius Note Taker: TBD, lemme know if you want to take notes! Pre-Reads: https://eips.ethereum.org/EIPS/eip-7702#backwards-compatibility https://github.com/erigontech/erigon/wiki/Transaction-Pool-Design
11/11/2024