├── docs ├── IPFS1.png ├── IPFS10.png ├── IPFS2.png ├── IPFS3.png ├── IPFS4.png ├── IPFS5.png ├── IPFS6.png ├── IPFS7.png ├── IPFS8.png ├── IPFS9.png └── LIBP2P1.png ├── consensus ├── leader_election │ ├── le_overview.pdf │ └── README.md ├── bfts │ └── README.md ├── README.md ├── decentralized_sequencers │ └── README.md └── tendermint │ └── README.md ├── data_availability ├── bitcoin │ └── README.md ├── README.md ├── ethereum │ └── README.md └── celestia │ └── README.md ├── README.md ├── blockchains ├── ethereum │ ├── eips_and_updates │ │ ├── README.md │ │ ├── eip-4844.md │ │ └── pectra.md │ └── README.md ├── bitcoin │ └── README.md └── README.md └── cryptoeconomics └── README.md /docs/IPFS1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cypherpunk-symposium/decentralized-protocols-toolkit/HEAD/docs/IPFS1.png -------------------------------------------------------------------------------- /docs/IPFS10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cypherpunk-symposium/decentralized-protocols-toolkit/HEAD/docs/IPFS10.png -------------------------------------------------------------------------------- /docs/IPFS2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cypherpunk-symposium/decentralized-protocols-toolkit/HEAD/docs/IPFS2.png -------------------------------------------------------------------------------- /docs/IPFS3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cypherpunk-symposium/decentralized-protocols-toolkit/HEAD/docs/IPFS3.png -------------------------------------------------------------------------------- /docs/IPFS4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cypherpunk-symposium/decentralized-protocols-toolkit/HEAD/docs/IPFS4.png -------------------------------------------------------------------------------- /docs/IPFS5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cypherpunk-symposium/decentralized-protocols-toolkit/HEAD/docs/IPFS5.png -------------------------------------------------------------------------------- /docs/IPFS6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cypherpunk-symposium/decentralized-protocols-toolkit/HEAD/docs/IPFS6.png -------------------------------------------------------------------------------- /docs/IPFS7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cypherpunk-symposium/decentralized-protocols-toolkit/HEAD/docs/IPFS7.png -------------------------------------------------------------------------------- /docs/IPFS8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cypherpunk-symposium/decentralized-protocols-toolkit/HEAD/docs/IPFS8.png -------------------------------------------------------------------------------- /docs/IPFS9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cypherpunk-symposium/decentralized-protocols-toolkit/HEAD/docs/IPFS9.png -------------------------------------------------------------------------------- /docs/LIBP2P1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cypherpunk-symposium/decentralized-protocols-toolkit/HEAD/docs/LIBP2P1.png -------------------------------------------------------------------------------- /consensus/leader_election/le_overview.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cypherpunk-symposium/decentralized-protocols-toolkit/HEAD/consensus/leader_election/le_overview.pdf -------------------------------------------------------------------------------- /data_availability/bitcoin/README.md: -------------------------------------------------------------------------------- 1 | ## bitcoin 2 | 3 |
4 | 5 | ### cool resources 6 | 7 |
8 | 9 | * **[bitcoin as a data availability layer, by rolkit (2024)](https://github.com/rollkit/bitcoin-da)** 10 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## ⛓🧱 decentralized protocols toolkit 2 | 3 |
4 | 5 | 6 | * ⬛️ **[blockchains 101](blockchains)** 7 | * ⬛️ **[consensus](consensus)** 8 | * ⬛️ **[cryptoeconomics](cryptoeconomics)** 9 | * ⬛️ **[data availability](data_availability)** 10 | 11 | -------------------------------------------------------------------------------- /blockchains/ethereum/eips_and_updates/README.md: -------------------------------------------------------------------------------- 1 | ## eips and updates 2 | 3 |
4 | 5 | ### cool readings 6 | 7 |
8 | 9 | * **[rough consensus: post-pectra, by nixo (2025)](https://mirror.xyz/nixo.eth/hT5F3Eo4iqQYNtoZCNqobogAr_Kd2QOmzqEtoizG5GA)** 10 | -------------------------------------------------------------------------------- /blockchains/bitcoin/README.md: -------------------------------------------------------------------------------- 1 | ## cool bitcoin research 2 | 3 |
4 | 5 | * **[scaling bitcoin for mass use, by e. ben-sasson](https://starkware.co/blog/scaling-bitcoin-for-mass-use/)** 6 | * **[bitcoin wildlife researching bitcoin scaling with OP_CAT](https://docs.btcwild.life/)** 7 | * **[covenants, by bitcoin optech](https://bitcoinops.org/en/topics/covenants/)** 8 | -------------------------------------------------------------------------------- /consensus/bfts/README.md: -------------------------------------------------------------------------------- 1 | ## byzantine fault tolerant ramblings 2 | 3 |
4 | 5 | * [minimmit: fast finality with even faster blocks, by kobayashi chou et al (2025)](https://arxiv.org/pdf/2508.10862) 6 | - bft state machine with significantly lower latency through an innovative view-change mechanism. 7 | - on a total of `n` processors or replicas, at most `f` of them may be bizantine, where `n >= 5f + 1`. 8 | - key insight: `n` decoupling view progression from tx finalizatin (l-notarizations). protocol allows view progression with only `2f + 1` votes (m-notarizations). 9 | - design leads to ~17% redux in tx latency. 10 | -------------------------------------------------------------------------------- /consensus/README.md: -------------------------------------------------------------------------------- 1 | ## consensus 2 | 3 |
4 | 5 | ### chapters 6 | 7 |
8 | 9 | * **[bfts](bfts)** 10 | * **[tendermint](tendermint)** 11 | * **[leader election](leader_election)** 12 | * **[decentralized sequencers](decentralized_sequencers)** 13 | 14 |
15 | 16 | --- 17 | 18 | ### cool resource 19 | 20 |
21 | 22 | * **[bookmark list for consensus researchers](https://collective.flashbots.net/t/bookmarks-relevant-for-consensus-researchers/1204)** (nice list from flashbots on canonical papers on consensus) 23 | * **[the engineer's guide to blockchain finality, by b. samuels](https://blog.trailofbits.com/2023/08/23/the-engineers-guide-to-blockchain-finality/)** 24 | -------------------------------------------------------------------------------- /data_availability/README.md: -------------------------------------------------------------------------------- 1 | ## data availability 2 | 3 |
4 | 5 | ### tl; dr 6 | 7 | * data availability is the proof that the underlying data behind a particular hash was actually published 8 | * in the case of ethereum, da is one of the primary scaling bottlenecks. 9 | * protocol-level changes such as sharding and eip-4488 (proto-sharding) are intended to increase da and reduce the cost of storing data on ethereum (the current leading design is **danksharding**, which should happen in several steps). 10 | 11 |
12 | 13 | --- 14 | 15 | ### chapters 16 | 17 |
18 | 19 | * **[celestia](celestia)** 20 | * **[ethereum](ethereum)** 21 | * **[bitcoin](bitcoin)** 22 | 23 | -------------------------------------------------------------------------------- /data_availability/ethereum/README.md: -------------------------------------------------------------------------------- 1 | ## ethereum da 2 | 3 |
4 | 5 | ### cool resources 6 | 7 |
8 | 9 | * **[peerdas: a simpler das approach using battle-tested p2p components, by djrtwo (2024)](https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541)** 10 | * **[relay based data availability sampling, by dankrad (2024)](https://notes.ethereum.org/NgKvvYiAQ7WdxPECCVdGUQ)** 11 | * **[fulldas: towards massive scalability with 32MB blocks and beyond, by cskiraly (2024)](https://ethresear.ch/t/fulldas-towards-massive-scalability-with-32mb-blocks-and-beyond/19529)** 12 | * **[private data attestation using merkle trees, by ethereum attestation servicei (2023)](https://mirror.xyz/0xeee68aECeB4A9e9f328a46c39F50d83fA0239cDF/BiFUEFJKo6ZsIvPwsP9WPC2UZX0-x_9BdtrvmQo1FwY)** 13 | * **[new sharding design with tight beacon and shard block integration, by dankrad (2022)](https://notes.ethereum.org/@dankrad/new_sharding)** (the original danksharding paper) 14 | -------------------------------------------------------------------------------- /consensus/decentralized_sequencers/README.md: -------------------------------------------------------------------------------- 1 | ## decentralized sequencers 2 | 3 |
4 | 5 | #### bt3gl's diagram for **[espresso systems](https://docs.espressosys.com/sequencer/espresso-sequencer-architecture/readme)**: 6 | 7 |
8 | 9 |

10 | 11 |

12 | 13 |
14 | 15 | --- 16 | 17 | ### cool resources 18 | 19 |
20 | 21 | * **[shared sequencers, by bridge harris](https://bridgeharris.substack.com/p/a-primer-on-shared-sequencers)** 22 | * **[shared sequencers, by maven11](https://maven11.substack.com/p/the-shared-sequencer)** 23 | * **[shared sequencers, dba](https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg)** 24 | * **[shared sequencers, by celestia](https://forum.celestia.org/t/sharing-a-sequencer-set-by-separating-execution-from-aggregation/702)** 25 | * **[shared sequencing, by expresso](https://hackmd.io/@EspressoSystems/SharedSequencing)** 26 | -------------------------------------------------------------------------------- /consensus/tendermint/README.md: -------------------------------------------------------------------------------- 1 | ## tendermint 2 | 3 |
4 | 5 | ### tl; dr 6 | 7 |
8 | 9 | * consensus protocol for ordering events in a distributed network under adversarial conditions (aka byzantine fault tolerant consenus, or atomic broadcast). 10 | * tendermint consists of two technical components: a blockchain consensus engine and a generic application interface, and works even if up to 1/3 of machines fail in arbitrary ways. 11 | * tendermint core (the consensus engine) performs BFT state machine replication (SMR) for arbitrary deterministic, finite state machines. 12 | * the application interface (abci) enables the transactions to be processed in any programming language. 13 | 14 |
15 | 16 |

17 | 18 |

19 | 20 |
21 | 22 | --- 23 | 24 | ### cool resources 25 | 26 |
27 | 28 | * **[tendermint docs](https://docs.tendermint.com/)** 29 | * **[tenderming abci](https://github.com/tendermint/tendermint/tree/v0.34.x/abci)** 30 | * **[the latest gossip on BFT consensus, e. buchman et al.](https://arxiv.org/abs/1807.04938)** 31 | * **[cometbft (a distributed byzantine fault-tolerant derterministic state machine replication engine)](https://github.com/cometbft/cometbft)** 32 | -------------------------------------------------------------------------------- /consensus/leader_election/README.md: -------------------------------------------------------------------------------- 1 | ## leader election 2 | 3 |
4 | 5 | ### secret leader election 6 | 7 |
8 | 9 | * **[leader election overview](le_overview.pdf)** 10 | * **[wtf is a secret leader election, by 2077](https://etherpedia.2077.xyz/posts/wtf-is-secret-leader-election/)** 11 | * **[secret leader election, by ef](https://ethereum.org/en/roadmap/secret-leader-election/)** 12 | 13 |
14 | 15 | --- 16 | 17 | ### single secret leader election 18 | 19 |
20 | 21 | * **[single secret leader election, by d. boneh et al.](https://eprint.iacr.org/2020/025.pdf)** 22 | * **[post-quantum single secret leader election, by d. boneh](https://www.youtube.com/watch?v=8caTi0JNGYA)** 23 | * **[private attacks in longest chain proof-of-stake protocols with ssle, by a. azouv](https://arxiv.org/pdf/2109.07440)** (hiding the identity of the leader) 24 | * **[a framework for constructing ssle from mpc, backes et al.](https://eprint.iacr.org/2022/1040.pdf)** (computational cost for N parties as low as O(N), garbled circuits, concerns over linear blow-up) 25 | * **[whisk, a practical shuffle-based SSLE protocol](https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763)** (ef's choice) 26 | 27 |
28 | 29 | --- 30 | 31 | ### leaderless consensus protocols 32 | 33 |
34 | 35 | * **[red belly: a secure, fair and scalable open blockchain, crain et al.](https://cognizium.io/uploads/resources/Red%20Belly-A%20secure,%20fair%20and%20scalable%20open%20blockchain%20-%20Tyler%20Crain,%20Christopher%20Natoli,%20Vincent%20Gramoli%20-%202021%20-%20paper.pdf)** 36 | 37 |
38 | 39 | --- 40 | 41 | ### cool resources 42 | 43 |
44 | 45 | * **[vulnerabilities on blockchains' randomness, the autistic symposium](https://github.com/autistic-symposium/blockchains-security-toolkit/blob/main/advanced_expert/vulnerabilities/randomness/README.md)** 46 | -------------------------------------------------------------------------------- /cryptoeconomics/README.md: -------------------------------------------------------------------------------- 1 | ## cryptoeconomics 2 | 3 |
4 | 5 | 6 | ### game theory 7 | * **[columbia cryptoeconomics workshop 2022](https://www.youtube.com/playlist?list=PLpktWkixc1gUqkyc1-iE6TT0RWQTBJELe)** 8 | * **[standford class on game theory](https://www.coursera.org/learn/game-theory-1#syllabus) and [advanced course](https://www.coursera.org/learn/game-theory-2)** 9 | * **[finding pure strategy nash equilibrium in finite simultaneous games](https://www.youtube.com/watch?v=gINERi_wbbg)** 10 | * **[censorship resistance in on-chain auctions, pai et al.](https://github.com/eljhfx/Decentralized-Auctions/blob/main/Censorship_Resistance_in_On-Chain_Auctions.pdf)** 11 | - single proposer blockchains are not ideal for holding time sensitive auctions when the number of potential bidders is large. collusion arrangements are extremely profitable for the colluding bidder but only marginally profitable for the proposer. order agnostics mechanism should solve mev. 12 | * **[algorithmic game theory, by t. roughgarden](https://theory.stanford.edu/~tim/papers/cacm.pdf)** 13 | * **[algorithmic game theory (the book), by nisan et al.](https://www.cs.cmu.edu/~sandholm/cs15-892F13/algorithmic-game-theory.pdf)** 14 | 15 | 16 |
17 | 18 | ### protocol economics and auctions 19 | * **[CADlabs's ethereum economic model](https://github.com/CADLabs/ethereum-economic-model)** 20 | * **[protocol economics: the ethereum protocol’s perspective, by vub](https://hackmd.io/@vbuterin/mev_presentation_3#/)** 21 | * **[a16z menagerie of auction mechanisms implemented in solidity](https://github.com/a16z/auction-zoo)** 22 | * **[on some results and challenges in cryptoeconomics, by t. roughgarden](https://www.youtube.com/watch?v=hMbXH3SdWd4)** 23 | * **[centralization in attester-proposer separation, m. pai and m. resnick](https://arxiv.org/pdf/2408.03116)** 24 | * **[the cases for focil and multi-proposer schemes on ethereum, by p. garimidi](https://a16zcrypto.com/posts/article/ethereum-roadmap-focil-and-multi-proposers/)** 25 | -------------------------------------------------------------------------------- /blockchains/ethereum/eips_and_updates/eip-4844.md: -------------------------------------------------------------------------------- 1 | ## eip-4844 2 | 3 |
4 | 5 | ### tl; dr 6 | 7 | - first interation of sharding design of ethereum: a way to have more data through the network. 8 | - eip-4844 creates a cheap palce for l2 solutions to post data on ethereum and reduce overall tx fees users pay on l2. 9 | - a new tx format for "blob-carrying txs" (large amount of data that cannot be accessed by evm execution, but which commitment can). 10 | - zk rollups would need to provide 2 commitments: the kzg in the blob and some commitment using zkp syste. they would prove that the kzg and the zk rollup commitment refer to the same data. 11 | 12 |
13 |
14 |

15 | 16 |

17 |
18 |
19 | 20 | * **[eip-4844: shard blob transactions](https://www.eip4844.com/)** introduces a new kind of tx type, that accepts "blobs" of data to be persisted in the beacon node for a short period of time. blobs are significantly larger than transaction (~125kb). 21 | * blobs are small enough to keep disk use manageable. they are ephemeral data storage and cheaper than on-chain storage (calldata). 22 | * this eip is designed for rollups to further reduce the cost of data submission and verification. rollups can use this storage to post tx data or proof back to the mainnet. 23 | * proto-danksharding requires a new cryptographic scheme: kzg commitments, also called a **["trusted setup"](https://github.com/go-outside-labs/blockchains-protocol-design/tree/main/zero_knowledge_proofs/proofs#common-reference-strings-trusted-setup-multi-party-computation-ceremony)**. it generates a structured reference string (SRS) which is needed for the commitments to work. 24 | * because nodes will have to download full blob contents with proto-danksharding, the ethereum block capacity is targeted to 1-2MB of space rather than 16MB with full danksharding (where data availability sampling will be possible). 25 | 26 |
27 | 28 |

29 | 30 |

31 | 32 |
33 | 34 | ---- 35 | 36 | ### cool resources 37 | 38 |
39 | 40 | * **[vitalik's proto-danksharding faq](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#Proto-Danksharding-FAQ)** 41 | * **[code for testing EIP-4844 on EL and CL clients](https://github.com/Inphi/eip4844-interop)** 42 | -------------------------------------------------------------------------------- /blockchains/README.md: -------------------------------------------------------------------------------- 1 | ## blockchains 101 2 | 3 |
4 | 5 | ### chapters 6 | 7 |
8 | 9 | * **[ethereum](ethereum)** 10 | * **[bitcoin](bitcoin)** 11 | 12 |
13 | 14 | --- 15 | 16 | ### tl; dr 17 | 18 |
19 | 20 | * **in general, blockchains have four core functions** (although modular blockchains specialize in one or two): 21 | * execution: transaction execution and state update. 22 | * settlement: finality and dispute resolution. 23 | * consensus: agreement on transaction ordering. 24 | * data availability: prove data was published to the network. 25 | 26 | * **in general, each block in a blockchain consists of two pieces**: 27 | * a block header: metadata for the block, which consists of some basic information about the block, including the merkle root of txs. 28 | * the transaction data: making up the majority of the block, and consisting of actual transactions. 29 | 30 | * **in general, a blockchain has two types of nodes**: 31 | * full nodes (fully validating nodes): they download and check that every tx in the blockchain is valid, and require lots of resources. 32 | * light clients: they don't download or validate any tx, but instead thye only download the block header and assume that the block only contains valid txs (less secure). light clients can rely on full nodes sending them a fraud proof if a block contains a invalid tx. 33 | 34 | * **the data availability problem:** 35 | * in order to a full node to generate a fraud proof for a block, they need to know the tx data for that block. if a block producer just publishes the block header, but not the tx data, then full nodes won't be able to check if the txs are valid and generate fraud proofs. 36 | * it's a requirement that block producers must publish all the data for the blocks, but this needs to be enforced. 37 | * to solve this problem, there need to be a way for light clients to check that the tx data for a block was actually published to the network so full nodes can check it. 38 | 39 |
40 | 41 | ---- 42 | 43 | ### cool resources 44 | 45 |
46 | 47 | #### cool learning 48 | 49 | * **[authenticated data structures, generically (2014)](https://www.cs.umd.edu/~mwh/papers/gpads.pdf)** 50 | * **[authenticated data structures as a library (2016)](https://bentnib.org/posts/2016-04-12-authenticated-data-structures-as-a-library.html)** 51 | * **[understanding trie databases, by d. brickwood (2018)](https://medium.com/shyft-network/understanding-trie-databases-in-ethereum-9f03d2c3325d)** 52 | * **[optimizing sparse merkle trees (2018)](https://ethresear.ch/t/optimizing-sparse-merkle-trees/3751)** 53 | * **[leaves of hash, by trail of bits (2019)](https://blog.trailofbits.com/2019/06/17/leaves-of-hash/)** 54 | * **[jellyfish merkle tree, by z. gao et al. (2021)](https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf?ref=127.0.0.1)** 55 | * **[on uploading your soul to the interplanetary sys, by bt3gl (2023)](https://mirror.xyz/go-outside.eth/A3iJGhXTJI5fgQoZVgIu3ovPV1P8zrxigpwngm0n4I0)** 56 | * **[on a rusty sparse merkle tree experiment, by bt3gl (2023)](https://mirror.xyz/go-outside.eth/zX1BaGZLHAcQOKdhFnSSM0VW67_-OFCi5ZegGFPryvg)** 57 | * **[how merkle trees work, by consensys (2024)](https://media.consensys.net/ever-wonder-how-merkle-trees-work-c2f8b7100ed3)** 58 | 59 |
60 | 61 | #### cool tools 62 | 63 | * **[bitcoin memory pool](https://www.blockchain.com/explorer/mempool/btc)** 64 | * **[celestia's namespaced merkle tree](https://github.com/celestiaorg/nmt)** 65 | 66 |
67 | 68 | #### cool discussions 69 | 70 | * **[revisiting the world computer, by l. yang et al. (2024)](https://user.fm/files/v2-261b7914c204931fbf213d7d35307264/worldcomputer.pdf)** 71 | * **[dba's journey towards ethereum's north star (2024)](https://dba.xyz/ethereums-north-star/)** 72 | 73 | 74 | -------------------------------------------------------------------------------- /blockchains/ethereum/README.md: -------------------------------------------------------------------------------- 1 | ## the ethereum blockchain 2 | 3 |
4 | 5 | 6 | * **[ethereum yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)** 7 | * **[eips and updates](eips_and_updates)** 8 | * the ethereum roadmap: 9 | 10 |
11 |

12 | 13 |

14 |
15 | 16 |
17 | 18 | --- 19 | 20 | ### tl; dr 21 | 22 |
23 | 24 | ##### evm execution 25 | 26 | * in native execution, evm will load the bytecode and execute the opcodes in the bytecodes one by one from the beginning. 27 | * each opcode can be thought as doing the following steps: 28 | 1. read elements from stack, memory, or storage 29 | 2. perform some computation on these elements 30 | 3. write back results to stack, memory, or storage 31 | 32 |
33 | 34 | ##### light clients 35 | 36 | * light clients receive the block headers, which contain a merkle root (more on this later) that can be used to query full nodes to verify if a transaction is included in a particular block. 37 | 38 |
39 | 40 | ##### scaling 41 | 42 | * **[scaling ethereum l1 and l2s in 2025 and beyond, by vub (2025)](https://vitalik.eth.limo/general/2025/01/23/l1l2future.html)** 43 | * **[possible futures of the ethereum protocol, part 1: the merge, by vub (2024)](https://vitalik.eth.limo/general/2024/10/14/futures1.html)** 44 | * **[possible futures for the ethereum protocol, part 2: the surge, by vub (2024)](https://vitalik.eth.limo/general/2024/10/17/futures2.html)** 45 | * **[gas limit dashboard, by t. wahrstätter](https://gaslimit.pics/)** 46 | 47 |
48 | 49 | ##### rollups tl; dr 50 | 51 | * rollups move computation (and state storage) off-chain, but keep some data per tx on-chain, using compression tricks to replace data with computation wherever possible (but scalability is still limited by the data bandwidth of the underlying blockchain). 52 | * an onchain smart contract maintains a state root (the merkle root) of the state of the rollup. 53 | * anyone can publish a batch (collection of txs, compressed to form the previous state root and the new state root). 54 | * the contract checks that the previous state root in the batch matches the current state root - if not, it switches the state root to the new state root. 55 | * for depositing and withdrawing, txs can have input or output outside the rollup state (processed within the batches). 56 | * optimistic (fraud proof) or zk (validity proof) rollups are solutions to know that the post-state roots in the batches are correct. 57 | 58 |
59 | 60 |

61 | 62 | 63 | 64 |

65 | 66 |
67 | 68 | * optimistic l2s 69 | * arbitrum one 70 | - started rollups 71 | - largest TVL 72 | * optimism 73 | - rollup from optimism collective, with a rich ecosystem of l2 74 | - tool to create l2 part of the superchain 75 | * mantle 76 | - l2 from bitdao 77 | 78 | * zk-rollups l2s 79 | - zksync era 80 | - the leading zk-rollup and a zkevm (zk-rollups that use ethereum virtual machine to execute transactions are called zkevms) 81 | - the only zkevm that supports native account abstraction in the consensus layer of the chain 82 | * starknet 83 | - zk-rollups from starkware 84 | - not a zkevm 85 | - used the cairo language 86 | - has recently open-souced their STARK prover 87 | * polygon zkevm 88 | - part of polygon 2.0, an ecosystem of zk-rollups 89 | - converting polygon pos into a zk-validum 90 | - has their prover open-sourced 91 | * linea 92 | - another recent zkevm from consensys 93 | 94 |
95 | 96 | 97 | ##### based rollup 98 | 99 | * **[native rollups - superpowers from l1 exec, by j. drake (2025)](http://ethresear.ch/t/native-rollups-superpowers-from-l1-execution/21517)** 100 | * **[based rollup and mev, by kubi mensah (2025)](https://x.com/kubimensah/status/1887876381322715146)** 101 | * **[truly based rollup and mev, by c. noyes (2025)](https://x.com/_charlienoyes/status/1887552361863737486)** 102 | * **[wtf are based rollups and preconfs?, by j. vranek (2024)](https://www.youtube.com/watch?v=j4wLhmXaZn8)** 103 | * interesting projects: **[taiko](https://taiko.xyz/)**, **[keyspace](https://docs.key.space)**, **[unifi](https://docs.puffer.fi/)** (taiko fork), **[spire labs](https://docs.spire.dev/)**, **[nuconstruct](https://nuconstruct.xyz/)** 104 | 105 | 106 |
107 | 108 | ##### proposer-builder separation 109 | 110 | * **[the autistic-symposium's mev-toolkit on ethereum block building (2025)](https://github.com/autistic-symposium/mev-toolkit/blob/main/MEV_by_chains/MEV_on_Ethereum/block_builders.md)** 111 | * **[notes on pbs, by barnabe.eth (2022)](https://barnabe.substack.com/p/pbs)** (thoughts on in-protocol pbs, market structure and allocation mechanism, whole vs. partial block building, block vs. slot auctions, inclusion lists, capturing true pbs value via consensus bid and protocol capture) 112 | * **[decentralizing the builder role, by j. charbonneau (2022)](https://joncharbonneau.substack.com/p/decentralizing-the-builder-role)** 113 | 114 |
115 | 116 | ##### inclusion lists 117 | 118 | * **[eip-7547 inclusion list, by m. neuder (2023)](https://ethereum-magicians.org/t/eip-7547-inclusion-lists/17474)** 119 | * **[inclusion list economics (2022)](https://efdn.notion.site/Inclusion-list-economics-b0d61d0e21a74963a54448e48d9adc8a)** 120 | 121 |
122 | 123 | ###### eips 124 | 125 | * **[eip-4844 tl; dr](eips_and_updates/eip-4844.md)** 126 | 127 |
128 | 129 | --- 130 | 131 | ### cool resources 132 | 133 |
134 | 135 | #### cool readings on the protocol 136 | 137 | * **[attester-proposer separation tracker, by j. ma (2025)](https://efdn.notion.site/Attester-Proposer-Separation-Tracker-15bd9895554180c2ac75cb40878ecd33?p=18bd98955541807da881e245abb008c9&pm=s)** 138 | * **[ethereum foundation r&d teams, by nixo (2025)](https://mirror.xyz/nixo.eth/TS-GwCEAKD_UTOE2_SCA_eFWyHstVAtGGn2Hu8mMezQ)** 139 | * **[how long non-finality could kill ethereum, by dapplion (2024)](https://www.youtube.com/watch?v=z2jafwPFLaQ)** 140 | * **[ef's ethereum protocol wiki (2024)](https://epf.wiki/#/)** 141 | * **[upgrading ethereum book, by b. edgington (2023)](https://eth2book.info/)** 142 | 143 |
144 | 145 | #### cool readings on rollups 146 | 147 | * **[what are rollups, by ef (2024)](https://ethereum.org/en/developers/docs/scaling/zk-rollups/)** 148 | * **[rollups are not real, by j. charbonneau (2023)](https://joncharbonneau.substack.com/p/rollups-arent-real)** 149 | * **[understanding rollups, by barnabe (2022)](https://barnabe.substack.com/p/understanding-rollup-economics-from?s=r)** 150 | * **[an incomplete guide to rollups, by vub (2021)](https://vitalik.ca/general/2021/01/05/rollup.html)** 151 | * **[a rollup-centric ethereum roadmap (2020)](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698)** 152 | 153 |
154 | 155 | #### cool tools 156 | 157 | * **[ethereum transaction visualizer](https://github.com/naddison36/tx2uml)** 158 | 159 | -------------------------------------------------------------------------------- /data_availability/celestia/README.md: -------------------------------------------------------------------------------- 1 | ## celestia's das network 2 | 3 |
4 | 5 | ### tl; dr 6 | 7 |
8 | 9 | * celestia is a modular data availability network that scales with the number of users, by decoupling execution from consensus and introducing a new primitive, **data availability sampling** (das), through **namespaced merkle trees**. 10 | * celestia da layer consists of a pos blockchain (celestia app), an application that provides transactions to faciliate the da layer and is built using cosmos sdk. 11 | * rollups and l2s use celestia as a network for publishing and making transaction da available, where optimistic rollups require data availability to detect fraud and zero-knowledge rollups require data availability to reconstruct the state of the chain (celestia can scale to the data throughput needed for millions of rollups without compromising on security). 12 | 13 |
14 |

15 | 16 |

17 | 18 | * lexicon: 19 | * **blobs**: data is posted to celestia's da layer by using `MsgPayForBlobs` transactions to the core network. 20 | * **namespaces**: celestia partitions the block data into multiple namespaces, one for every application. this allows applications to only download their data, and not the data of other applications. 21 | * **blockchain cluster:** a group of blockchains that can communicate with each other in a trust-minimized way. 22 | * **consensus**: the ordering of txs is agreed upon by a set of validators. 23 | * **data availability commitee (dac)**: permissioned group of nodes responsible for providing da to a blockchain. 24 | * **data availability layer**: a blockchain that provides for other types of chains (e.g., rollups). 25 | * **settlement layer**: a modular blockchain whose primary role is to provide proof verification and dispute resolution for rollups. 26 | * **data throughput**: a measurement of the data capacity of a blockchain, and calculated by the amount of data that a block. 27 | * **the data availability problem**: concerned with whether the data in the proposed block can be verified that is available. 28 | 29 |
30 | 31 | ----- 32 | 33 | ### data availability sampling (das) 34 | 35 |
36 | 37 | * da answers the question "has the data for this blockchain been published?". 38 | - celestia solves the problem of having to download all the blockchain data by making it possible for users to verify very large blocks with data availability sampling. 39 | - this new primitive enables celestia light nodes to, instead of downloading all data, download only **block headers that contain commitments** (i.e. merkle roots) of the block data (i.e. the list of transactions). 40 | - to make das possible, celestia uses as **2D reed-solomon encoding scheme** to encode the block data: every block data is split into `k x k` chunks, arranged in a `k x k` matrix, and extended with parity data into a `2k x 2k` extended matrix by applying multiple times reed-solomon encoding. 41 | 42 |
43 | 44 |

45 | 46 | 47 |

48 | 49 |
50 | 51 | * celestia does not require a majority of the consensus (i.e. block producers) to be honest to guarantee data availability. 52 | - if the extended data is invalid, the original data might not be recoverable, even if the light nodes are sampling sufficient unique chunks. 53 | - as a solution, da fraud proofs of incorrectly generated extended data enable light nodes to reject blocks with invalid extended data (data availability proofs using erasure codes). 54 | - such proofs require reconstructing the encoding and verifying the mismatch. 55 | 56 |
57 | 58 |

59 | 60 |

61 | 62 |
63 | 64 | ---- 65 | 66 | ### namespaced merkle trees 67 | 68 |
69 | 70 | * celestia partitions the block data into **multiple namespaces**, one for every application (e.g. rollup), using the da layer. 71 | - every application needs to download only its own data and can ignore the data of other applications. 72 | - for this to work, the da layer must be able to prove that the provided data is complete, i.e., all the data for a given namespace is returned. 73 | * a nmt is a merkle tree with the leafs ordered by the namespace identifiers and the hash function modified so that every node in the tree includes the range of namespace of all its descendants. 74 | - when an application requests the data for `namespace 2`, the da layer must provide the data chunks `D3`, `D4`, `D4`, `D6`, and the nodes `N2`, `N8`, `N7` as proof. 75 | - the application is able to check that the provided data is part of the block data. furthermore, the application can verify that all the data for `namespace 2` was provided. if the DA layer provides only the data chunks `D4` and `D5`, it must also provide nodes `N12` and `N11` as proofs. however, the application can identify that the data is incomplete by checking the namespace range of the two nodes, i.e., both `N12` and `N11` have descendants part of `namespace 2`. 76 | 77 |
78 | 79 |

80 | 81 |

82 | 83 |
84 | 85 | ---- 86 | 87 | ### building a pos blockchain for da 88 | 89 |
90 | 91 | * celestia-app is built on top of celestia-core, a modified version of the tendermint consensus algorithm. it ensures: 92 | * the erasure coding of block data (using the 2D reed-solomon encoding scheme). 93 | * the replacement of regular merkle tree used by tendermint to store block data wiht a namespaced merkle tree that enables the above layers (execution and settlement) to only download the needed data. 94 | * celestia-core nodes are still using the tendermint p2p network. 95 | * similarly to tendermint, celestia-core is connected to the application layer (i.e., the state machine) by ABCI++. 96 | - like its predecessor, ABCI++ is the interface between tendermint (a state-machine replication engine) and the actual state machine being replicated (i.e., the application). yhe api consists of a set of methods, each with a corresponding request and response message type. 97 | - all ABCI++ messages and methods are defined in protocol buffers. 98 | * the celestia-app state machine is necessary to execute the pod logic and to enable the governance of the fs layer. however, the celestia-app is data-agnostic - the state machine neither validates nor stores the data that is made available by the celestia-app. 99 | 100 |
101 | 102 | ---- 103 | 104 | ### celestia light nodes 105 | 106 |
107 | 108 | * light nodes ensure da, and they are the most common way to interact with celestia. 109 | 110 |
111 | 112 |

113 | 114 |

115 | 116 | 117 |
118 | 119 | --- 120 | 121 | ### celestia full nodes 122 | 123 |
124 | 125 | * full nodes store all the data. 126 | * they send block shares, headers, and fraud proofs to light nodes (while light nodes gossif headers, fraud proofs, and sometimes block shares between one another). 127 | 128 |
129 | 130 |

131 | 132 |

133 | 134 |
135 | 136 | --- 137 | 138 | ### ethereum fallback 139 | 140 |
141 | 142 | * a mechanism that enables l2s to "fallback" to using ethereum calldata for da when celestia mainnet is under downtime. it's triggered whenever the sequencer has an error sending the `PayForBlobs` transacations to celestia. 143 | * fallback can also be triggered due a congested mempool or nonce error, and can be simulated with an error as low as balance or incorrect sequence. 144 | 145 |
146 | 147 |

148 | 149 |

150 | 151 |
152 | 153 | ----- 154 | 155 | ### blockspace 156 | 157 |
158 | 159 | * to publish data on celestia, developers can submit `PayForBlobs` transactions, which consist of the identity of the sender, the data to be made available, the data size, the namespace, and a signature. 160 | * each `PayForBlobs` transaction is split into two parts: the blob or blobs which include the data to be made available along with the namespace, and the executable payment transaction which includes a commitment to the data. 161 | * both the blobs and executable payment transactions are put into the block within the appropriate namespace, the block data is extended using erasure coding and then merkelized into a data root commitment included in the block header. 162 | 163 |
164 | 165 |

166 | 167 |

168 | 169 |
170 | 171 | * celestia uses a standard gas-price prioritised mempool, where transactions with higher fees will be prioritised by validators. fees are comprised of a flat fee per transaction and then a variable fee based on the size of each blob in the transaction. 172 | 173 |
174 | 175 | --- 176 | 177 | ### cool resources 178 | 179 |
180 | 181 | * **[celestia docs](https://docs.celestia.org/learn/how-celestia-works/data-availability-layer#namespaced-merkle-trees-nmts)** 182 | * **[cosmos sdk](https://docs.cosmos.network/)** 183 | * **[tendermint consensus algorithm docs](https://docs.tendermint.com/)** 184 | * **[building a sparse merkle tree from scratch in rust, by bt3gl](https://mirror.xyz/go-outside.eth/zX1BaGZLHAcQOKdhFnSSM0VW67_-OFCi5ZegGFPryvg)** 185 | * **[lazyledger: a distributed da ledger with client-side smart contracts, by m. al-bassam](https://arxiv.org/abs/1905.09274)** 186 | * **[fraud and da proofs: maximising light client security, by m. al-bassam et al.](https://arxiv.org/abs/1809.09044)** 187 | -------------------------------------------------------------------------------- /blockchains/ethereum/eips_and_updates/pectra.md: -------------------------------------------------------------------------------- 1 | ## [DRAFT] security considerations for **[pectra](https://eips.ethereum.org/EIPS/eip-7600)** (early 2025) 2 | 3 |
4 | 5 | ### ✅🔐🏋🏻‍♀️ **[eip-2537: precompile for bls12-381 curve operations, by a. vlasov et al.](https://eips.ethereum.org/EIPS/eip-2537)** 6 | 7 |
8 | 9 | - adds bls signature verification and operations over `bls12-381`, a cryptographic primitive allowing to get `120+` bits of security for operations over pairing friendly curve (compared to the existing `bn254` precompile that only provides `80` bits of security) 10 | 11 |

12 | 13 |

14 | 15 | - ddos protection: 16 | - *a sane implementation of this eip should not contain potential infinite loops (it is possible and not even hard to implement all the functionality without while loops) and the gas schedule accurately reflects the time spent on computations of the corresponding function (precompiles pricing reflects an amount of gas consumed in the worst case where such a case exists)* 17 | 18 |
19 | 20 | --- 21 | 22 | ### ✅🔐🤝🏋🏻‍♀️ **[eip-6110: supply validator deposits on chain, by m. kalinin et al.](https://eips.ethereum.org/EIPS/eip-6110)** 23 | 24 |
25 | 26 | - appends validator deposits to the el block structure, shifting the responsibility of deposit inclusion and validation to the el and removes the need for deposit 27 | - faster for validators to deposit their eth (12 hours -> 30 min) 28 | - removes the need for deposit voting from the cl, reducing the complexity of client software design, and contributing to the security of the deposits flow 29 | 30 |

31 | 32 |

33 | 34 |
35 | 36 | --- 37 | 38 | ### ✅🔐🤝🏋🏻‍♀️ **[eip-7002: execution layer triggerable exits, by djrtwo et al.](https://eips.ethereum.org/EIPS/eip-7002)** 39 | 40 |
41 | 42 | - improves ux for validators, giving them more flexibility 43 | - allows validators to trigger exits and partial withdrawals via their el (`0x01`) withdrawal credentials (e.g., enabling more trustless staking pool designs) 44 | - these new execution layer exit messages are appended to the el block and then processed by the cl 45 | 46 |

47 | 48 |

49 | 50 | - security consideration on fee overpayment: 51 | - *calls to the system contract require a fee payment defined by the current contract state. overpaid fees are not returned to the caller* 52 | - *it is not generally possible to compute the exact required fee amount ahead of time* 53 | - *using an eoa to request withdrawals will always result in overpayment of fees* 54 | - *there is no way for an eoa to use a wrapper contract to request a withdrawal* 55 | - *and even if a way existed, the gas cost of returning the overage would likely be higher than the overage itself* 56 | - *if requesting withdrawals to an eoa through the system contract is desired, we recommend that users perform transaction simulations to estimate a reasonable fee amount to send* 57 | 58 |
59 | 60 | --- 61 | 62 | ### ✅🔐🤝 **[eip-7251: increase the `MAX_EFFECTIVE_BALANCE`, by m. neuder et al.](https://eips.ethereum.org/EIPS/eip-7251)** 63 | 64 |
65 | 66 | - biggest ux improvement for validators 67 | - raises the validator stake limit (maximum effective balance from 32 -> 2048 eth, with reward compounding) 68 | - potentially can reduce the number of inactive nodes and possibly improving the network efficiency 69 | - security: 70 | - *proposer selection is already weighted by the ratio of their effective balance to `MAX_EFFECTIVE_BALANCE`* 71 | - *due to the lower probabilities, this change will slightly increase the time it takes to calculate the next proposer index* 72 | 73 |

74 | 75 |

76 | 77 |
78 | 79 | --- 80 | 81 | ### ✅🔐🤝 **[eip-7549: move committee index outside attestation, by dapplion](https://eips.ethereum.org/EIPS/eip-7549)** 82 | 83 |
84 | 85 | - makes the aggregation of validator votes (attestation) in blocks more efficient, reducing networking load and saving node bandwidth 86 | - this eip introduces backward incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork 87 | - because the on chain `Attestation` container changes, attestations from the prior fork can't be included into post-electra blocks, therefore the first block after the fork may have zero attestations 88 | 89 |

90 | 91 |

92 | 93 |
94 | 95 | --- 96 | 97 | ### ✅🔐🤝🏋🏻‍♀️ **[eip-7702: set eoa account code, by vub et al.](https://eips.ethereum.org/EIPS/eip-7702)** 98 | 99 |
100 | 101 | - add a new transaction type that adds a list of `[chain_id, address, nonce, y_parity, r, s]` authorization tuples, improving the functionality of crypto wallets by giving them smart contract properties (the so called "account abstraction") 102 | 103 |

104 | 105 |

106 | 107 | - more usability in crypto, enhanced security features: 108 | - batching multiple operations from the same user into one atomic transaction (e.g., erc-20's approval + spending) 109 | - sponsorship (an account can pay for a transaction on behalf of another account) 110 | - privilege de-escalation where users can sign sub-keys, giving them specific permissions that are much weaker than global access to the account (e.g., a permission to spend erc-20 but not eth, or spend a percentage of balance per day, or interact only with a specific application) 111 | 112 |

113 | 114 |

115 | 116 | - introduces a new transaction, the setcode tx, very similar to eip-1559 txs, with an additional authorization list elements ("authorizing some code to live into your account" through creating by template) 117 | 118 |

119 | 120 |

121 | 122 | - e.g., gas fees could be outsourced to services to pay on another erc-20 token 123 | 124 |

125 | 126 |

127 | 128 |
129 | 130 | #### main security challenges: full account abstraction introduces ddos vectors 131 | 132 | - the main challenges are efficient block building and DoS-resilient p2p mempool (unused gas as a vector can become a side channel attack) 133 | - example: 134 | 1. suppose an attack implement an attacker and this account depends on a flag stored in a singleton smart contract 135 | 2. every account using this implementation looks at the same flag to determine the transaction validity (and also flips the flag) 136 | 3. the attacker then sends thousands of such transactions, and every time such transaction gets included, it immediately invalidates all the other ones, so they can't be included in the chain and need to be dropped without paying gas (since they are not valid) 137 | 4. this can escalate to a point where the nodes cannot do any useful work 138 | - the mitigation can done by separating validation from execution so that the mempool protocol only propagates compliant transactions 139 | - block builders must be able to validate each transaction independently (parallelizing their validation) 140 | - if validation accessible data overlaps, transactions can invalidate each other causing another DoS attack vector is the mempool is filled with mutually exclusive txs 141 | 142 |

143 | 144 |

145 | 146 |
147 | 148 | --- 149 | 150 | ### ✅🏋🏻‍♀️ **[eip-7685: general purpose execution layer requests, by lightclient](https://eips.ethereum.org/EIPS/eip-7685)** 151 | 152 |
153 | 154 | - boosts the interoperability between the execution and the consensus layer (helping with surge demand on the execution layer) by defining a general purpose framework for storing contract-triggered requests: 155 | - extends the execution header with a single field to store the request information 156 | - requests are later on exposed to the consensus layer, which then processes each one 157 | - more efficient way to code, test, and implement execution triggered requests such as eip-6110 and eip-7002 158 | - note on "exec" concern: 159 | - *a request’s validity can often not be fully verified at the execution layer* 160 | - *this is why they are referred to merely as "requests": they do not carry the authority on their own to unilaterally catalyze an action* 161 | - *we expect the system contracts to perform whatever validation is possible by the el and then pass it on to the cl for further validation* 162 | 163 |
164 | 165 | --- 166 | 167 | ### ✅🏋🏻‍♀️ **[eip-2935: save historical block hashes from state, by vub et al.](https://eips.ethereum.org/EIPS/eip-2935)** 168 | 169 |
170 | 171 | - store last `HISTORY_SERVE_WINDOW` historical block hashes in the storage of a system contract as part of the block processing logic 172 | - increases amount of data from past blocks that can be stored on new blocks 173 | - sets the stage for verkle tree 174 | - improves solo staking ux: enabling stateless validator clients, allowing staking nodes to run with very little hard disk space and quick sync 175 | - security: 176 | - *having contracts (system or otherwise) with hot update paths (branches) poses a risk of "branch" poisioning attacks where attacker could sprinkle trivial amounts of eth around these hot paths (branches)* 177 | - *but it has been deemed that cost of attack would escalate significantly to cause any meaningful slow down of state root updates* 178 | 179 |
180 | 181 | --- 182 | 183 | ### ✅ **[eip-7692: evm object format meta, by a. beregszaszi et al.](https://eips.ethereum.org/EIPS/eip-7692)** 184 | 185 |
186 | 187 | - more zk friendly! 188 | - adds a bunch of evm object format for smart contract deployment and execution efficiency, including optimized code validation, better function handling, more efficient data access instructions: 189 | - **[eip-3540](https://eips.ethereum.org/EIPS/eip-3540)**: 190 | - introduces an extensive container format for the evm with a once-off validation at deploy time 191 | - `magic, version, (section_kind, section_size_or_sizes)+, 0,
` 192 | - **[eip-3670](https://eips.ethereum.org/EIPS/eip-3670)**: 193 | - validates eof bytecode for correctness at the time of deployment 194 | - **[eip-4200](https://eips.ethereum.org/EIPS/eip-4200)**: 195 | - `RJUMP`, `RJUMPI`, and `RJUMPV` instructions with a signed immediate encoding the jump destination 196 | - **[eip-4750](https://eips.ethereum.org/EIPS/eip-4750)**: 197 | - individual sections for functions with `CALLF` and `RETF` instructions 198 | - 🔐 **[eip-5450](https://eips.ethereum.org/EIPS/eip-5450)**: 199 | - deploy-time validation of stack usage for eof functions 200 | - security: introduces extended validation of eof code sections to guarantee that neither stack underflow nor overflow can happen during execution of validated contracts) 201 | - **[eip-6206](https://eips.ethereum.org/EIPS/eip-6206)**: 202 | - introduces instruction for chaining function calls 203 | - **[eip-7480](https://eips.ethereum.org/EIPS/eip-7480)**: 204 | - instructions to read data section of eof container (clear separation between code and data from eof1) 205 | - *accessing immutable values and contract payloads efficiently* 206 | - **[eip-663](https://eips.ethereum.org/EIPS/eip-663)**: 207 | - introduces additional instructions for manipulating the stack which allows accessing the stack at higher depths 208 | - the evm stack is fixed at 1024 items and most implementations keep that in memory at all times - this change increases the number of stack items accessible via single instruction 209 | - *helping compilers avoid "stack too deep" errors* 210 | - 🔐 **[eip-7069](https://eips.ethereum.org/EIPS/eip-7069)**: 211 | - revamped `CALL` intrusctions by introducing `EXTCALL`, `EXTDELEGATECALL`, `EXTSTATICALL`, with simplified semantics 212 | - *addressing gas introspection and preserving space for address space expansion* 213 | - security: when implemented in eof - where the `GAS` opcode and the original `CALL` operations are removed - existing out of gas attacks will be slightly more difficult, but not entirely prevented as transactions can still pass in arbitrary gas values 214 | - **[eip-7620](https://eips.ethereum.org/EIPS/eip-7620)**: 215 | - introduces `EOFCREATE` and `RETURNCONTRACT` instructions 216 | - *most code introspection issues are contract creation issues* 217 | - 🔐 **[eip-7620](https://eips.ethereum.org/EIPS/eip-7698)**: 218 | - deploys eof contracts using creation transactions 219 | - *how eof contracts are introduced into the blockchain* 220 | - security: external unverified code (e.g., check for correct price, dos) 221 | 222 | 223 |

224 | 225 |

226 | 227 |
228 | 229 | --- 230 | 231 | ### ✅🤝🏋🏻‍♀️ **[eip-7742: uncouple blob count between cl and el, by a. stokes](https://eips.ethereum.org/EIPS/eip-7742)** 232 | 233 |
234 | 235 | - extends functionalities from blobs 236 | - execution layer no longer verifies data blobs's maximum value and instead gets this value dynamically from the consensus layer 237 | 238 |
239 | 240 | --- 241 | 242 | ### ✅🤝 **[eip-7594: peerdas - peer data availability sampling, by djrtwo et al.](https://eips.ethereum.org/EIPS/eip-7594)** 243 | 244 |
245 | 246 | - allows beacon nodes to perform data availability sampling, improving how da is handled across the network 247 | - crucial feature for layer 2s (making them more efficient and cost-effective) 248 | - compare to celestia (tba) 249 | 250 |
251 | 252 | --- 253 | 254 | ### 🟡 **[eip-7623: increase calldata cost, by t. wahrstätter et al.](https://eips.ethereum.org/EIPS/eip-7623)** 255 | 256 |
257 | 258 | - increases the calldata cost for transactions (increase the cost of calldata to 10/40 gas for transactions that do not exceed a certain threshold of gas spent on evm operations) 259 | - highligting data availability 260 | 261 |
262 | 263 | --- 264 | 265 | ### 🟡 **[eip-7762: increase `MIN_BASE_FEE_PER_BLOB_GAS`, by m. resnick](https://eips.ethereum.org/EIPS/eip-7762)** 266 | 267 |
268 | 269 | - speeds up discovery on blob space 270 | - security: "rollups that use blobs as da will need to update their posting strategies" 271 | 272 |
273 | 274 | ---- 275 | 276 | ### cool resources 277 | 278 |
279 | 280 | * **[pectra retrospective at eth magickians, by t. beiko et al. (2025)](https://ethereum-magicians.org/t/pectra-retrospective/22637)** 281 | * **[what's going into the pectra upgrade?, by c. kim (2024)](https://www.youtube.com/watch?v=ufIDBCgdGwY)** 282 | * **[eip-7702: a technical deep dive, by lightclient (2024)](https://www.youtube.com/watch?v=_k5fKlKBWV4)** 283 | * **[exploring eip-7702, by y. weiss (2024)](https://www.youtube.com/watch?v=63Wd5mPla-M)** 284 | * **[native aa in pectra - combining eof, eip-7702, by a. forshtat (2024)](https://www.youtube.com/watch?v=FYanFF-yU6w)** 285 | * **[evm object format (eof) - history and motivation, by d. ferrin (2024)](https://www.youtube.com/watch?v=X2mlptWzphc)** 286 | * **[evm object format (eof) - managing the bytecode chaos, by a. murashkin (2024)](https://www.youtube.com/watch?v=WKVgCoNp39g)** 287 | * **[unpacking eof: applications, by n. urisevic et al. (2024)](https://www.youtube.com/watch?v=OsKyVPdpJgI)** 288 | * **[eip-7251, maximum effective balance overview, by p. harris (2024)](https://www.youtube.com/watch?v=EwW6dNi9VCY)** 289 | 290 | 291 | --------------------------------------------------------------------------------