From c4cf49308e5fbeddfffc15c12422f7cdcecb863d Mon Sep 17 00:00:00 2001 From: gconnect Date: Tue, 2 Jul 2024 14:18:20 +0100 Subject: [PATCH] reordered the numbering and removed unsed content --- docs/wiki/research/roadmap.md | 105 +++++++++++++++++----------------- 1 file changed, 52 insertions(+), 53 deletions(-) diff --git a/docs/wiki/research/roadmap.md b/docs/wiki/research/roadmap.md index 70286655..07250ca9 100644 --- a/docs/wiki/research/roadmap.md +++ b/docs/wiki/research/roadmap.md @@ -35,24 +35,24 @@ Upgrades relating to the switch from proof-of-work to proof-of-stake. The Merge **TODO** | Upgrade | Description | Expected effect | State of the art | | :----------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------- | -| Single slot finality (SSF) | Blocks could be proposed and finalized in the same slot | (i) More convenient for apps (transactions finalization time improved by an order of magnitude, i.e. 12 seconds instead of 12 minutes means better UX for all. Under [full rollup scaling](#the-surge), with real-time SNARK proofs implemented, single slot finality would also mean faster bridging for L2s ), (ii) Much more difficult to attack (multi block MEV re-orgs can be eliminated and the complexity in consensus mechanism, reduced) | in research
(i) VB's SSF notes[^4]
(ii) 8192 signatures post-SSF[^5]
(iii) simple SSF protocol[^6] | -| Single Secret Leader Election (SSLE) | Allow elected block proposers to remain private until block publishing, to prevent DoS attacks | Only the selected validator knows it has been selected to propose a block. | in research
EIP-7441[^7] | -| Enable more Validators | The technical challenge of efficiently coordinating an ever increasing number of validators to achieve SSF with the best trade-offs possible | Greater redundancy, a broader range of proposers, a wider array of attesters, and overall increased resilience | in research
(i) EIP-7514[^8]
(ii) EIP-7251[^9]
(iii) 8192 signatures[^5] | -| Quantum-safe signatures | Proactive research and integration of quantum-resistant cryptographic algorithms | Quantum-safe, aggregation-friendly signatures will enhance protocol security against quantum attacks | in research
(i) lattice-based[^10]
(ii) STARK-based [^11] systems | +| Single slot finality (SSF) | Blocks could be proposed and finalized in the same slot | (i) More convenient for apps (transactions finalization time improved by an order of magnitude, i.e. 12 seconds instead of 12 minutes means better UX for all. Under [full rollup scaling](#the-surge), with real-time SNARK proofs implemented, single slot finality would also mean faster bridging for L2s ), (ii) Much more difficult to attack (multi block MEV re-orgs can be eliminated and the complexity in consensus mechanism, reduced) | in research
(i) VB's SSF notes[^3]
(ii) 8192 signatures post-SSF[^4]
(iii) simple SSF protocol[^5] | +| Single Secret Leader Election (SSLE) | Allow elected block proposers to remain private until block publishing, to prevent DoS attacks | Only the selected validator knows it has been selected to propose a block. | in research
EIP-7441[^6] | +| Enable more Validators | The technical challenge of efficiently coordinating an ever increasing number of validators to achieve SSF with the best trade-offs possible | Greater redundancy, a broader range of proposers, a wider array of attesters, and overall increased resilience | in research
(i) EIP-7514[^7]
(ii) EIP-7251[^8]
(iii) 8192 signatures[^5] | +| Quantum-safe signatures | Proactive research and integration of quantum-resistant cryptographic algorithms | Quantum-safe, aggregation-friendly signatures will enhance protocol security against quantum attacks | in research
(i) lattice-based[^9]
(ii) STARK-based [^10] systems | ### The Surge Upgrades related to scalability by Roll-ups and Data Sharding. **IMPLEMENTED** | Upgrade | Track | Topic | Description | Effect | State of the art | | :----------------- | :---: | :------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------: | :-----------------------: | :------------------------- | -| Proto-danksharding | - | Basic rollup scaling | We can stop storing Rollup data permanently on Ethereum and move the data into a temporary 'blob' storage that gets deleted from Ethereum once is no longer needed | Reduced transaction costs | shipped
EIP-4844[^12] | +| Proto-danksharding | - | Basic rollup scaling | We can stop storing Rollup data permanently on Ethereum and move the data into a temporary 'blob' storage that gets deleted from Ethereum once is no longer needed | Reduced transaction costs | shipped
EIP-4844[^11] | **TODO** | Upgrade | Track | Topic | Description | Expected effect | State of the art | | :---------------------------------------------- | :---: | :-------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Danksharding | - | Full rollup scaling | Danksharding is the full realization of the rollup scaling that began with Proto-Danksharding | Massive amounts of space on Ethereum for rollups to dump their compressed transaction data | in research
| -| Data Availability Sampling (DAS) | - | Full rollup scaling | Data Availability Sampling is a way for the network to check that data is available without putting too much strain on any individual node | (i) ensure rollup operators make their transaction data available after EIP-4844 (ii) ensure block producers are making all their data available to secure light clients (iii) under proposer-builder separation, only the block builder would be required to process an entire block, other validators would verify using data availability sampling | in research
EIP-7594[^13] | -| Removing Rollup Training Wheels | - | Basic & Full rollup scaling | (i) Optimistic Rollup Fault Provers
(ii) ZK-EVMs
(iii) Rollup interoperability | (i) Optimistic rollups having live proof systems will address the L2's censorship risk
(ii) Massive improvements to Ethereum's scalability and privacy without sacrificing the security and decentralization aspects of the chain via zkEVMs (EVM-compatible virtual machines that supports zero-knowledge proof computation)
(iii) L1 Sequencers, or Ethereum L1 proposers with given rollup sequencing rights will bring better credible-neutrality and security, and offer roll-ups L1 compatibility | in research
(i)Arbitrum BoLD[^14]
Optimism Cannon[^15]
(ii) ZK-EVMs [^16] [^17] [^18]
(iii) [ET](/wiki/research/PBS/ET.md),
[Based Sequencing with Preconfirmations](/wiki/research/Preconfirmations/BasedSequencingPreconfs.md) | +| Data Availability Sampling (DAS) | - | Full rollup scaling | Data Availability Sampling is a way for the network to check that data is available without putting too much strain on any individual node | (i) ensure rollup operators make their transaction data available after EIP-4844 (ii) ensure block producers are making all their data available to secure light clients (iii) under proposer-builder separation, only the block builder would be required to process an entire block, other validators would verify using data availability sampling | in research
EIP-7594[^12] | +| Removing Rollup Training Wheels | - | Basic & Full rollup scaling | (i) Optimistic Rollup Fault Provers
(ii) ZK-EVMs
(iii) Rollup interoperability | (i) Optimistic rollups having live proof systems will address the L2's censorship risk
(ii) Massive improvements to Ethereum's scalability and privacy without sacrificing the security and decentralization aspects of the chain via zkEVMs (EVM-compatible virtual machines that supports zero-knowledge proof computation)
(iii) L1 Sequencers, or Ethereum L1 proposers with given rollup sequencing rights will bring better credible-neutrality and security, and offer roll-ups L1 compatibility | in research
(i)Arbitrum BoLD[^13]
Optimism Cannon[^14]
(ii) ZK-EVMs [^15] [^16] [^17]
(iii) [ET](/wiki/research/PBS/ET.md),
[Based Sequencing with Preconfirmations](/wiki/research/Preconfirmations/BasedSequencingPreconfs.md) | | Quantum-safe and Trusted-Setup-Free Commitments | - | - | replace KZG commitments with commitments that don't require a trusted setup and are quantum safe | Quantum-safe Commitments | in research
| ### The Scourge @@ -67,22 +67,21 @@ Upgrades related to censorship resistance, decentralization and mitigating proto | Upgrade | Track | Topic | Description | Expected effect | State of the art | | :--------------------------------- | :-------: | :-------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :--------------------------------------------------------------------------------------------------------- | -| ePBS | MEV-Track | Endgame Block Production Pipeline | Enshrinement of block Proposer and block Builder separation at protocol level, because of anti-censorship and MEV risk mitigation reasons | (i) creates opportunities to prevent transaction censorship at the protocol level
(ii) prevents hobbyist validators from being out-competed by institutional players that can better optimize the profitability of their block building
(iii) helps with scaling Ethereum by enabling the Danksharding upgrades | [in research](/wiki/research/PBS/ePBS.md)[^19]
| -| MEV - Burn | MEV-Track | Endgame Block Production Pipeline | A simple enshrined PBS add-on to smooth and redistribute MEV spikes | The extracted ETH would be burned, therefore benefiting all ETH holders, rather than only those running validators. | [in research](/wiki/research/PBS/ePBS.md#mev-burn)[^20] | -| ET | MEV-Track | Endgame Block Production Pipeline | A permissionless market allowing buyers to purchase the right to propose execution payloads. | Attester - Proposer separation: the beacon proposer is unconcerned with execution proposer. Execution proposer is selected from the permissionless execution tickets market and has the option to transfer the execution building right to a third party.
Since ET market will be a protocol gadget, the protocol will have introspection over who comes to market and how much they are willing to pay | [ET](/wiki/research/PBS/ET.md),
APS-Burn[^21] | -| IL | MEV-Track | Endgame Block Production Pipeline | Inclusion lists - a way for the most decentralized set of Ethereum to fight censorship by inputting their preferences onto the construction of the chain | Prevents block builders from censoring blocks. Allow Proposers to retain some authority by providing a mechanism by which transactions can be forcibly included, avoiding the current situation, when without any forced transaction inclusion mechanism, the proposer is faced with the choice of either having to say no, on the transactions that get included, or they build the block locally (having the final say on transactions) and sacrifice some MEV rewards | [in research](/wiki/research/inclusion-lists.md)[^22]
Multiplicity gadgets [^23]
COMIS [^24] | -| Distributed Block Building | MEV-Track | Endgame Block Production Pipeline | Decentralize the block building process, by distributing it | Decentralize different parts of the Builder:
(i) the algorithms for choosing transactions (the block building transaction ordering)
(ii) resources for block construction, especially under full Danksharding (split-up big blocks)
(iii) add extra builder services (e.g.Preconfirmations) | in research
[Preconfirmations](/wiki/research/Preconfirmations/Preconfirmations.md),
SUAVE[^25] | -| Application Layer MEV Minimization | MEV-Track | - | App layer effort to minimize harmful MEV | The minimization techniques target:
(i) frontrunning, and
(ii) sandwich attacks | Examples[^26] | -| Preconfirmations | MEV-Track | - | Users preconfirmations on transaction execution, for a competitive user experience in Ethereum interactions | Block builders could publicly agree to include transactions with a priority fee over a certain amount, and send users a receipt indicating their intent to include the transaction in a specific block | [in research](/wiki/research/Preconfirmations/Preconfirmations.md)[^27] | +| ePBS | MEV-Track | Endgame Block Production Pipeline | Enshrinement of block Proposer and block Builder separation at protocol level, because of anti-censorship and MEV risk mitigation reasons | (i) creates opportunities to prevent transaction censorship at the protocol level
(ii) prevents hobbyist validators from being out-competed by institutional players that can better optimize the profitability of their block building
(iii) helps with scaling Ethereum by enabling the Danksharding upgrades | [in research](/wiki/research/PBS/ePBS.md)[^18]
| +| MEV - Burn | MEV-Track | Endgame Block Production Pipeline | A simple enshrined PBS add-on to smooth and redistribute MEV spikes | The extracted ETH would be burned, therefore benefiting all ETH holders, rather than only those running validators. | [in research](/wiki/research/PBS/ePBS.md#mev-burn)[^19] | +| ET | MEV-Track | Endgame Block Production Pipeline | A permissionless market allowing buyers to purchase the right to propose execution payloads. | Attester - Proposer separation: the beacon proposer is unconcerned with execution proposer. Execution proposer is selected from the permissionless execution tickets market and has the option to transfer the execution building right to a third party.
Since ET market will be a protocol gadget, the protocol will have introspection over who comes to market and how much they are willing to pay | [ET](/wiki/research/PBS/ET.md),
APS-Burn[^20] | +| IL | MEV-Track | Endgame Block Production Pipeline | Inclusion lists - a way for the most decentralized set of Ethereum to fight censorship by inputting their preferences onto the construction of the chain | Prevents block builders from censoring blocks. Allow Proposers to retain some authority by providing a mechanism by which transactions can be forcibly included, avoiding the current situation, when without any forced transaction inclusion mechanism, the proposer is faced with the choice of either having to say no, on the transactions that get included, or they build the block locally (having the final say on transactions) and sacrifice some MEV rewards | [in research](/wiki/research/inclusion-lists.md)[^21]
Multiplicity gadgets [^22]
COMIS [^23] | +| Distributed Block Building | MEV-Track | Endgame Block Production Pipeline | Decentralize the block building process, by distributing it | Decentralize different parts of the Builder:
(i) the algorithms for choosing transactions (the block building transaction ordering)
(ii) resources for block construction, especially under full Danksharding (split-up big blocks)
(iii) add extra builder services (e.g.Preconfirmations) | in research
[Preconfirmations](/wiki/research/Preconfirmations/Preconfirmations.md),
SUAVE[^24] | +| Application Layer MEV Minimization | MEV-Track | - | App layer effort to minimize harmful MEV | The minimization techniques target:
(i) frontrunning, and
(ii) sandwich attacks | Examples[^25] | +| Preconfirmations | MEV-Track | - | Users preconfirmations on transaction execution, for a competitive user experience in Ethereum interactions | Block builders could publicly agree to include transactions with a priority fee over a certain amount, and send users a receipt indicating their intent to include the transaction in a specific block | [in research](/wiki/research/Preconfirmations/Preconfirmations.md)[^26] | -Here is a summarized table of the provided content for the Staking Economics/Experiences Track: | Upgrade | Track | Topic | Description | Expected Effect | State of the Art | |------------------|-------------|----------------------------|----------------------------------------------|----------------------------------------------------|---------------------------------------------------------------------------------| -| Increase MAX_EFFECTIVE_BALANCE | Staking Economics | Raising Validator Cap | Increase the max balance for Ethereum validators from 32 ETH to reduce overhead for large stakers | Consolidates validators, reduces network load, simplifies operations for large stakers | [in research](/wiki/research/eODS.md)[^28], confirmed for Pectra upgrade | -| Improve Node Operator Usability | Staking Economics | Making Nodes Cheaper | Make nodes cheaper and easier to operate using verkle trees and SNARKs | Lower SSD requirements, faster sync times, easier node operation | Research/Proposal: [in eps node workshop](/docs/eps/nodes_workshop.md)[^29] | -| Explore Total Stake Capping | Staking Economics | Capping Validator Set | Cap the total amount of stake to manage communication overhead between validators | Prevents excessive validator participation, maintains network efficiency | Research/Proposals: [in research](/wiki/research/eODS.md)[^30] | -| Explore Solutions to Liquid Staking Centralization | Staking Economics | Combat LST Centralization | Solutions to reduce centralization in the Liquid Staking Token (LST) market | Prevents large LST providers from gaining too much control over the network | Research/Proposals: [^31], [^32], [^33], [^34],[^35] | +| Increase MAX_EFFECTIVE_BALANCE | Staking Economics | Raising Validator Cap | Increase the max balance for Ethereum validators from 32 ETH to reduce overhead for large stakers | Consolidates validators, reduces network load, simplifies operations for large stakers | [in research](/wiki/research/eODS.md)[^27], confirmed for Pectra upgrade | +| Improve Node Operator Usability | Staking Economics | Making Nodes Cheaper | Make nodes cheaper and easier to operate using verkle trees and SNARKs | Lower SSD requirements, faster sync times, easier node operation | Research/Proposal: [in eps node workshop](/docs/eps/nodes_workshop.md)[^28] | +| Explore Total Stake Capping | Staking Economics | Capping Validator Set | Cap the total amount of stake to manage communication overhead between validators | Prevents excessive validator participation, maintains network efficiency | Research/Proposals: [in research](/wiki/research/eODS.md)[^29] | +| Explore Solutions to Liquid Staking Centralization | Staking Economics | Combat LST Centralization | Solutions to reduce centralization in the Liquid Staking Token (LST) market | Prevents large LST providers from gaining too much control over the network | Research/Proposals: [^30], [^31], [^32], [^33],[^34] | @@ -101,73 +100,73 @@ Other upgrades that don't fit well into the previous categories. ## Resources -[^1]: [EIP-2982: Serenity Phase 0](https://eips.ethereum.org/EIPS/eip-2982), [[archived]](https://web.archive.org/web/20230928204358/https://eips.ethereum.org/EIPS/eip-2982) +[^1] : [EIP-2982: Serenity Phase 0](https://eips.ethereum.org/EIPS/eip-2982), [[archived]](https://web.archive.org/web/20230928204358/https://eips.ethereum.org/EIPS/eip-2982) -[^2]: [EIP-4895: Beacon chain push withdrawals](https://eips.ethereum.org/EIPS/eip-4895), [[archived]](https://web.archive.org/web/20240415201815/https://eips.ethereum.org/EIPS/eip-4895) +[^2] : [EIP-4895: Beacon chain push withdrawals](https://eips.ethereum.org/EIPS/eip-4895), [[archived]](https://web.archive.org/web/20240415201815/https://eips.ethereum.org/EIPS/eip-4895) -[^4]: [VB's SSF notes](https://notes.ethereum.org/@vbuterin/single_slot_finality), [[archived]](https://web.archive.org/web/20240330010706/https://notes.ethereum.org/@vbuterin/single_slot_finality) +[^3] : [VB's SSF notes](https://notes.ethereum.org/@vbuterin/single_slot_finality), [[archived]](https://web.archive.org/web/20240330010706/https://notes.ethereum.org/@vbuterin/single_slot_finality) -[^5]: [Sticking to 8192 signatures per slot post-SSF](https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989). [[archived]](https://web.archive.org/web/20240105131126/https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989) +[^4] : [Sticking to 8192 signatures per slot post-SSF](https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989). [[archived]](https://web.archive.org/web/20240105131126/https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989) -[^6]: [A simple Single Slot Finality protocol](https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920), [[archived]](https://web.archive.org/web/20231214080806/https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920) +[^5] : [A simple Single Slot Finality protocol](https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920), [[archived]](https://web.archive.org/web/20231214080806/https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920) -[^7]: [EIP-7441: Upgrade BPE to Whisk](https://eips.ethereum.org/EIPS/eip-7441), [[archived]](https://web.archive.org/web/20231001031437/https://eips.ethereum.org/EIPS/eip-7441) +[^6] : [EIP-7441: Upgrade BPE to Whisk](https://eips.ethereum.org/EIPS/eip-7441), [[archived]](https://web.archive.org/web/20231001031437/https://eips.ethereum.org/EIPS/eip-7441) -[^8]: [EIP-7514: Add Max Epoch Churn Limit](https://eips.ethereum.org/EIPS/eip-7514), [[archived]](https://web.archive.org/web/20240309191714/https://eips.ethereum.org/EIPS/eip-7514) +[^7] : [EIP-7514: Add Max Epoch Churn Limit](https://eips.ethereum.org/EIPS/eip-7514), [[archived]](https://web.archive.org/web/20240309191714/https://eips.ethereum.org/EIPS/eip-7514) -[^9]: [EIP-7251:Increase the MAX_EFFECTIVE_BALANCE](https://eips.ethereum.org/EIPS/eip-7251), [[archived]](https://web.archive.org/web/20240324072459/https://eips.ethereum.org/EIPS/eip-7251) +[^8] : [EIP-7251:Increase the MAX_EFFECTIVE_BALANCE](https://eips.ethereum.org/EIPS/eip-7251), [[archived]](https://web.archive.org/web/20240324072459/https://eips.ethereum.org/EIPS/eip-7251) -[^10]: [Medium post on lattice encryption](https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175), [[archived]](https://web.archive.org/web/20230623222155/https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175) +[^9] : [Medium post on lattice encryption](https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175), [[archived]](https://web.archive.org/web/20230623222155/https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175) -[^11]: [VB's hackmd post on STARK signature aggregation](https://hackmd.io/@vbuterin/stark_aggregation), [[archived]](https://web.archive.org/web/20240313124147/https://hackmd.io/@vbuterin/stark_aggregation) +[^10] : [VB's hackmd post on STARK signature aggregation](https://hackmd.io/@vbuterin/stark_aggregation), [[archived]](https://web.archive.org/web/20240313124147/https://hackmd.io/@vbuterin/stark_aggregation) -[^12]: [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844), [[archived]](https://web.archive.org/web/20240326205709/https://eips.ethereum.org/EIPS/eip-4844) +[^11] : [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844), [[archived]](https://web.archive.org/web/20240326205709/https://eips.ethereum.org/EIPS/eip-4844) -[^13]: [EIP-7594: PeerDAS](https://github.com/ethereum/EIPs/pull/8105) +[^12] : [EIP-7594: PeerDAS](https://github.com/ethereum/EIPs/pull/8105) -[^14]: [BoLd: dispute resolution protocol](https://github.com/OffchainLabs/bold/blob/e00b1c86124c3ca8c70a2cc50d9296e7a8e818ce/docs/research-specs/BOLDChallengeProtocol.pdf) +[^13] : [BoLd: dispute resolution protocol](https://github.com/OffchainLabs/bold/blob/e00b1c86124c3ca8c70a2cc50d9296e7a8e818ce/docs/research-specs/BOLDChallengeProtocol.pdf) -[^15]: [Fault proofs bring permissionless validation to the OP Sepolia testnet](https://blog.oplabs.co/open-source-and-feature-complete-fault-proofs-bring-permissionless-validation-to-the-op-sepolia-testnet/) +[^14] : [Fault proofs bring permissionless validation to the OP Sepolia testnet](https://blog.oplabs.co/open-source-and-feature-complete-fault-proofs-bring-permissionless-validation-to-the-op-sepolia-testnet/) -[^16]: [Parallel Zero-knowledge Virtual Machine](https://eprint.iacr.org/2024/387), [[archived]](https://web.archive.org/web/20240415180222/https://eprint.iacr.org/2024/387) +[^15] : [Parallel Zero-knowledge Virtual Machine](https://eprint.iacr.org/2024/387), [[archived]](https://web.archive.org/web/20240415180222/https://eprint.iacr.org/2024/387) -[^17]: [What is zkEVM](https://www.alchemy.com/overviews/zkevm), [[archived]](https://web.archive.org/web/20240129204732/https://www.alchemy.com/overviews/zkevm) +[^16] : [What is zkEVM](https://www.alchemy.com/overviews/zkevm), [[archived]](https://web.archive.org/web/20240129204732/https://www.alchemy.com/overviews/zkevm) -[^18]: [Types of ZK-EVMs](https://vitalik.eth.limo/general/2022/08/04/zkevm.html), [[archived]](https://web.archive.org/web/20240329112600/https://vitalik.eth.limo/general/2022/08/04/zkevm.html) +[^17] : [Types of ZK-EVMs](https://vitalik.eth.limo/general/2022/08/04/zkevm.html), [[archived]](https://web.archive.org/web/20240329112600/https://vitalik.eth.limo/general/2022/08/04/zkevm.html) -[^19]: [Barnabe - More pictures about proposers and builders](https://mirror.xyz/barnabe.eth/QJ6W0mmyOwjec-2zuH6lZb0iEI2aYFB9gE-LHWIMzjQ), [[archived]](https://web.archive.org/web/20240424010902/https://mirror.xyz/barnabe.eth/QJ6W0mmyOwjec-2zuH6lZb0iEI2aYFB9gE-LHWIMzjQ) +[^18] : [Barnabe - More pictures about proposers and builders](https://mirror.xyz/barnabe.eth/QJ6W0mmyOwjec-2zuH6lZb0iEI2aYFB9gE-LHWIMzjQ), [[archived]](https://web.archive.org/web/20240424010902/https://mirror.xyz/barnabe.eth/QJ6W0mmyOwjec-2zuH6lZb0iEI2aYFB9gE-LHWIMzjQ) -[^20]: [MEV burn—a simple design](https://ethresear.ch/t/mev-burn-a-simple-design/15590), [[archived]](https://ethresear.ch/t/mev-burn-a-simple-design/15590) +[^19] : [MEV burn—a simple design](https://ethresear.ch/t/mev-burn-a-simple-design/15590), [[archived]](https://ethresear.ch/t/mev-burn-a-simple-design/15590) -[^21]: [APS-Burn](https://mirror.xyz/barnabe.eth/QJ6W0mmyOwjec-2zuH6lZb0iEI2aYFB9gE-LHWIMzjQ#heading-aps-burn) +[^20] : [APS-Burn](https://mirror.xyz/barnabe.eth/QJ6W0mmyOwjec-2zuH6lZb0iEI2aYFB9gE-LHWIMzjQ#heading-aps-burn) -[^22]: [Inclusion lists](https://eips.ethereum.org/EIPS/eip-7547), [[archived]](https://web.archive.org/web/20240309191147/https://eips.ethereum.org/EIPS/eip-7547) +[^21] : [Inclusion lists](https://eips.ethereum.org/EIPS/eip-7547), [[archived]](https://web.archive.org/web/20240309191147/https://eips.ethereum.org/EIPS/eip-7547) -[^23]: [ROP-9: Multiplicity gadgets](https://efdn.notion.site/ROP-9-Multiplicity-gadgets-for-censorship-resistance-7def9d354f8a4ed5a0722f4eb04ca73b) +[^22] : [ROP-9: Multiplicity gadgets](https://efdn.notion.site/ROP-9-Multiplicity-gadgets-for-censorship-resistance-7def9d354f8a4ed5a0722f4eb04ca73b) -[^24]: [Committee-enforced inclusion sets (COMIS)](https://ethresear.ch/t/the-more-the-less-censored-introducing-committee-enforced-inclusion-sets-comis-on-ethereum/18835), [[archived]](https://web.archive.org/web/20240310000045/https://ethresear.ch/t/the-more-the-less-censored-introducing-committee-enforced-inclusion-sets-comis-on-ethereum/18835) +[^23] : [Committee-enforced inclusion sets (COMIS)](https://ethresear.ch/t/the-more-the-less-censored-introducing-committee-enforced-inclusion-sets-comis-on-ethereum/18835), [[archived]](https://web.archive.org/web/20240310000045/https://ethresear.ch/t/the-more-the-less-censored-introducing-committee-enforced-inclusion-sets-comis-on-ethereum/18835) -[^25]: [SUAVE](https://writings.flashbots.net/the-future-of-mev-is-suave), [[archived]](https://writings.flashbots.net/the-future-of-mev-is-suave) +[^24] : [SUAVE](https://writings.flashbots.net/the-future-of-mev-is-suave), [[archived]](https://writings.flashbots.net/the-future-of-mev-is-suave) -[^26]: [Examples of app layer MEV minimization](https://herccc.substack.com/i/142947825/examples-of-the-defensive-side-of-mev) +[^25] : [Examples of app layer MEV minimization](https://herccc.substack.com/i/142947825/examples-of-the-defensive-side-of-mev) -[^27]: [Based preconfirmations](https://ethresear.ch/t/based-preconfirmations/17353), [[archived]](https://ethresear.ch/t/based-preconfirmations/17353) +[^26] : [Based preconfirmations](https://ethresear.ch/t/based-preconfirmations/17353), [[archived]](https://ethresear.ch/t/based-preconfirmations/17353) -[^28]: [EIP-7251: Increase the MAX_EFFECTIVE_BALANCE](https://eips.ethereum.org/EIPS/eip-7251) +[^27] : [EIP-7251: Increase the MAX_EFFECTIVE_BALANCE](https://eips.ethereum.org/EIPS/eip-7251) -[^29]: [Spin Up Your Own Ethereum Node - Ethereum.org](https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/) +[^28] : [Spin Up Your Own Ethereum Node - Ethereum.org](https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/) -[^30]: [Paths to SSF](https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928) +[^29] : [Paths to SSF](https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928) -[^31]: [Enshrining Liquid Staking/Decentralized Liquid Staking](https://notes.ethereum.org/@vbuterin/H1_5auGQd) +[^30] : [Enshrining Liquid Staking/Decentralized Liquid Staking](https://notes.ethereum.org/@vbuterin/H1_5auGQd) -[^32]: [Enshrined LST from Arixon](https://ethresear.ch/t/enshrined-lst-allocating-stake-to-node-operators/11053) +[^31] : [Enshrined LST from Arixon](https://ethresear.ch/t/enshrined-lst-allocating-stake-to-node-operators/11053) -[^33]: [Unbundling staking: towards rainbow staking](https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/11054) +[^32] : [Unbundling staking: towards rainbow staking](https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/11054) -[^34]: [Liquid Staking Maximalism design by Dankrad](https://ethresear.ch/t/liquid-staking-maximalism/11050) +[^33] : [Liquid Staking Maximalism design by Dankrad](https://ethresear.ch/t/liquid-staking-maximalism/11050) -[^35]: [Two-tiered staking from Mike Neuder](https://ethresear.ch/t/two-tiered-staking/11049) +[^34] : [Two-tiered staking from Mike Neuder](https://ethresear.ch/t/two-tiered-staking/11049) [ethereum/EIPs github repository](https://github.com/ethereum/EIPs/tree/master#ethereum-improvement-proposals-eips)