Skip to content

Latest commit

 

History

History
687 lines (641 loc) · 35.2 KB

chloe.md

File metadata and controls

687 lines (641 loc) · 35.2 KB
Raw

Chloe

Hi I'm Chloe, currently PM of EIP Fun. I've followed the EPF study group since Week 0 and super excited to join the intensive study group to level up my learning and study & discuss together.

Notes

2024.4.3

My previous notes on EPF study group: https://twitter.com/EIPFun/status/1775443183884763521, incl.

  • Week 1 Ethereum protocol 101
  • Week 2 Execution layer overview
  • Week 3 Consensus layer overview
  • Week 4 Testing & Security overview
  • Week 5 Ethereum roadmap overview
  • Week 6D CL & EL specs
  • Week 6R Sharindg & DAS

2024.4.5 Verkle tree study

Youtube video:

Brief notes

  • The Verge
    • The goal
      • Make the blocks self-contained execution units → New node operators don’t need any prerequisite eg. sync action
    • Major changes needed
      • Change the state trie format from a Merkle Patricia Tree (MPT) to a Verkle Tree (VKT)
      • Adding state diffs to the block
      • In the current MPT, all the values are accessible through a key and the key is a hash. When changing to VKT, key rehashing process is needed.
  • Converting the state tree to Verkle requires a lot of work
    • In 1 year (from July 2023), there will be c.1bn leaves in the tree, which is a lot of data take days/ months to convert
    • It’s the riskiest change so far, no mistake is allowed
    • There are simply too much data for an instant conversion
  • The overlay method: the favoured conversion method
    • How does it work?
      • Freeze the current MPT at a fork block
      • Lay another tree, i.e. the VKT, on top
      • Every value then goes to the new tree
      • In every block, n values were taken from the MPT and their keys were converted then inserted in the VKT
      • The conversion ends when all leaves from the MPT transferred to the VKT
      • Internal MPT nodes will be deleted when the block is finalized (but can be stored else where)
    • Performance
      • Full sync under the process will probably takes 2 weeks to 1 month
      • The process will not affect the block production
    • Timeline
      • If N = 10k, the conversion will take 15 days; if N = 5k, 1 month; if N = 1k, 6 months
      • Why not N = 100k
        • Consequence: more leaves get translated per block → more nodes dropping from the network
        • Tradeoff: # of machines that can follow <> keep the conversion short enough
    • Current result
      • An AMD64 machine from 2017 with 16GB of RAM can handle 10k leaves
      • Rock 5B & cheap ARM machine may handle c.5k leaves
    • Trade offs
      • Pros
        • Conversion in consensus
          • Easy to reorg, sync, debug, and suspend & resume
        • Code for the transition is reused in sync code
        • No need for extra disk space
      • Cons
        • Lower power machine (eg. rock 5b) can drop from the network
        • Long process that can potentially interfere with emergency releases
        • Gas becomes more expensive during the transition (to find some data may need read both MPT and VKT)
    • Backup methods (To do)
      • Offline conversion
      • Bulk conversion
      • State expiry

2024.4.6 Week 7R Verkle tree summary notes

2024.4.7 Working on Week 7D Reth (EL client) Architecture notes

Intro on Reth Recap on Reth

  • What is Reth?
  • Why Reth?
    • Client diversity: Need more client implementations for staking
    • Talent resilience: Need more clients to onboard more new core devs, and more eyes on Ethereum protocols
    • Client scalability: Need clients built for a high gas per second L2 world
    • Code extensibility: Need clients that are easy to extend with principle, without cowboy forking/ rebasing
  • 2024 Goals
    • Credible alternative client for L1 Ethereum usage
    • Fastest L2 EVM client
    • State of the art framework for building EVM infra
  • What has Reth done so far?
  • Reth's performance benchmark
    • Sync speed
      • Historical sync: 2-4k mg/second
        • Sync historical blocks
      • Live sync: 100-200 mg/second
        • incl. new blocks and check state root for every block
    • Tools used for benchmarking
  • Beta version: 0.2.0 beta.4
    • Current status
      • L1: Cancun ready, tested on Devnets/ Sepolia etc.
      • L2: Support OP stack for usage in L2/ L3s, aka OP Reth
      • Stress tested on EF's EVM fuzzing/ chaos testing, for staking & RPC
      • State of the art performance on all axes except block notifications
      • Snapshot sync done by the Merkle: https://snapshots.merkle.io/
      • Full JSON-RPC incl. Geth-style & Parity style traces
      • Protocol guild/ RetroPGF recipients for impact, to be redistributed
    • Docs
  • Production ready?
    • Production ready in May
      • Reth audit with Sigma Prime (Lighthouse)
      • REVM fuzzing engagement with Guido Vranken (#1 ETH bug bounty leaderboard) 2024 Roadmap
  • 3 tracks & mission
    • Core development: Ethereum resilience
      • Cancun: already shipped
      • Ship Electra ASAP: EOF, Verkle tries, Account abstraction
      • Contribute to core dev process with precise writing & benchmarking
    • Performance: Maximize gas per second
      • Parallel EVM: Parallelized execution for any historical/ live sync, builder, or sequencer use cases. Each one is different.
      • JIT/AOT EVM: Run native code instead of interpreter overhead
      • Optimized state commitment: Parallelized state root calculation + new algos
      • Optimal database: Replace MDBX with firewood/ MonadDB-style DB or new perfect hash table index-based design
      • Rigorous benchmarking: Regression testing in CL, aggressive systems optimization
    • Reth Kernel: State of the art EVM infra in <1 day
      • Reth Kernel is the SDK for building bleeding-edge EVM infra
      • Node builder API: Puggable componenets, stop forking nodes
      • Library usage: Build p2p crawlers, indexers, simulations APIs, MEV bots etc.
      • Import Rust node infra and run as one:
        • Rethhouse = Reth + Lighthouse = CL + EL in 1 binary
        • Reth + Helios = Light client CL + EL in 1 binary
        • OP Reth + Reth + Helios + Magi = L1 CL/EL + L2 CL/EL in 1 binary
      • Project idea: Testnet rollup w/ customer EIPs?

2024.4.8 Working on Week 8D Teku (CL client) Architecture brief notes

Guest speaker

  • Paul Harris, Lead protocol engineer at Teku
    • Senior staff blockchain protocol engineer at Consensys
    • CL client Teku developer
    • Beacon-api maintainer
    • Keymanager-api maintainer

Summary notes Teku CL client

  • Team of Teku
    • 7 software engineers: 4 in EU, 3 in APAC
  • High level overview
    • Key drivers of each CL client
      • CL spec
      • Execution API: interface to CL
      • Standard REST api's: beacon-api, keymanager-api, builder-api
      • Client team direction: eg. Teku currently doesn't implement lightclient
  • Rules: CL and EL both define open specs
    • PoS is bascially a distributed game
      • Interactions are fairly well defined, and there are rules & grey areas
    • CL uses executable specs
      • Tests are written for the specs, and can be run on all implementations
  • Key features of Teku: Aim to be the client of choice for institutional stakers
    • Written in Java
    • Fairly extensive metrics (prometheus/ grafana)
    • Focuses on testing (incl. unit, integration, system tests)
    • Relatively clear logging
    • Maintain 1 code-stream generally (aka master development), and release frequently
    • Well documented, open source, and strive to offer good support
    • Teku is node operator, and also runs the Teku client

2024.4.10 Notes on SNARK proving ASICs

Guest speaker: Justin Drake @zksummit11

  • Instant proving can incur
    • instant proving (proof latency < slot time) → synchronous composability
    • light validators
    • EVM-in-EVM precompile → native rollups
  • For builder there is also incentives
    • synchronous composability → more txns
    • light validators → faster blocks
    • native rollups → bigger blocks
    • overall more MEV
  • Companies that work on zkASICs
    • dedicated companies: ASSEAL, Cysic, Fabric
    • relevant companies: Bitmain, Semisand, SuperScalar, ZKTo
    • others: Auradine, Ingonyama, SupraNational

2024.4.12 Notes on EIP 3074 <> 4337

Source: https://hackmd.io/@matt/note-on-3074

How 3074 different from 4337

  • 3074’s Main goal is to delegate control of EOA to a smart contract. Stolen key means total loss. There is no consideration for tx sponsoring/ relaying.
  • 3074 allows EOAs to be used within 4337, and set the stage for future EIPs, which could allow EOAs to permanently upgrade to smart contract wallets.

Beef between 3074 and 4337

  • Previously, there are some people from the 4337 camp complained about that 3074 would fragment the community, where devs would build momentum on separate EIPs.
  • 3074 could support the multi EVM chain future more easily than 4337.

Weakness of 3074

  • Inability to spend ETH from the authorized account

2024.4.13 Notes on Evolving Ethereum With Improvement Proposals | Pooja Ranjan

2024.4.14 Week 8R protocol services notes

2024.4.15 Week 9D Testing & Prototyping

  • Slides link: https://docs.google.com/presentation/d/1c95eV_55ZlojL9yE1OOPHUPjLyAU8xdh/edit?rtpof=true&sd=true
  • What was complicated about the testing?
    • Over 20 client comlinations need to be tested & regressions can sneak in easily
    • Debugging can also be difficult
    • Competences for CLs and ELs are separate
  • What are devnets?
    • Devnets are short lived eg. from 30min to a few months, compared to testnets
    • A testing mirror of the Ethereum base layer
    • Contain EL/CL/validators, setup in a config that we want to test
    • Pectra devnet will be setup soon
    • Verkle devnet is already on
  • What does testing look like today?
    • Pectra: current upcoming fork
    • Verkle: upcoming future fork
    • Features that are proposed for future forks, prototyping
      • IL
      • EIP 7441 (whisk)
    • Client optimisations
      • EthereumJS snap sync testnet
      • Bigboi beaconchain tests for blob/validator limits
  • Local testing:
    • Hard to test changes quickly, as it normally needs a lot of coordination
    • Solution: local testing
      • Move to local devnets enables faster iterations: enter Kurtosis
      • Able to work async on features
      • Configurable locally: 3s slot times, quick forks, MEV workflow
      • Scalable: to whatever extent kurbernets/ docker allows
    • Github repo: https://github.com/kurtosis-tech/ethereum-package
    • Install instruction: https://docs.kurtosis.com/install/
    • Example of configured with YAML
    • Example of MEV local testing
  • How do I prototype?
    • Kurtosis works on the concept of "allow everything to be overridden"
    • To test protocol changes, we can override the client images
    • To test new tools, run an existing network and connect your tool to it
    • To test quick forks, we can override the network parameters
  • Example of prototype testing: Verkle transition
  • What comes after local testing?
    • Remote/ public devnets
      • Devnets used to be error prone and time consuming
      • Easy drift btw setup configs of various testnets due to customizations
    • Solution
      • Move barebones logics upstream into role
      • Move generic components into its own tool, eg. Genesis
      • Make tooling independent of repo/ testnet (with GitOps)
      • Generalize setups for all testnets
  • Shadowforks
    • Allow us to check compatibility across all clients through the entire lifecycle
    • Shadow forks allow us to stress test the clients with real state and tx load
    • Act as release test which triggers real world edge cases, before we recommend the releases to the general public
  • Handy tools overview
    • Overview
      • https://ethpandaops.io/
      • notes.ethereum.org/@parithosh/testing-overview-doc
      • Tools are all open-sourced (MIT). Some configs depending on the projects sometimes won't be open-sourced.
    • Template-devnets
      • Contain everything to config for any type of testnet
      • Use Terraform to spin up cloud instances and Ansible to deploy the network
      • Useful if you want to run nodes on a larger scale and local testing tools are inadequate
    • Assertoor
      • Tool to assert network level expectations, eg. Can a network handle deposits, handle every opcode being called, handle a reorg etc.
      • Similar to Hive: Hive <> Single node, Assertoor <> Network side
      • Can be run locally via kurtosis or integrated into a CL
    • Forky
      • Ethereum forkchoice visualizer
      • Can display the forkchoice of a live node
      • Help debug forkchoice related issues
    • Tracoor
      • Ethereum trace explorer
      • Can display a collection of traces & states of EL & CL blocks/ slots
      • Help debug network related issues
      • Recent blog post [][]
    • Dora
    • Xatu
      • Xatu data is fed into an analysis pipeline to get data we care about
      • The visualization is handled by Grafana, but the DB can directly be queried as well

2024.4.16 Week 9R History expiry pre-reading

Statelessness, state expiry and history expiry: https://ethereum.org/en/roadmap/statelessness/

Goal

  • Let modest hardware (eg. Mobile phones, micro-computers, home computers etc.) have the ability to run Ethereum nodes to achieve decentralization

Current problem

  • High disk space requirement is the main barrier, primarily due to the need to store large Ethereum's state data
  • Currently a fast 2TB SSD is recommended for running a full node

Solution: Reduce storage for nodes

  • Data expiry
    • History expiry
      • Enable nodes to discard state data older than X blocks, but does not change how Ethereum client's handle state data
      • Option for clients to request historical data from peers
        • Portal network: p2p network for serving historical data
      • Risk
        • Moving the responsibility for providing data guarantee outside of the Ethereum core protocol could introduce new censorship risks
    • State expiry
      • Allow state data that is not used frequently to become inactive. Inactive data can be ignored by clients until it is resurrected
      • Options for state expiry
        • Expire by rent: charging "rent" to accounts and expiring them when their rent reaches 0
        • Expire by time: making accounts inactive if there is no reading/ writing for some time
  • Statelessness
    • Weak statelessness
      • Only block producers need access to full state data
      • Other nodes can verify blocks without a local state database
      • Prerequest: Verkle tree & PBS
    • Strong statelessness
      • No nodes need access to the full state data

Current progress

  • Prerequest: Verkle tree and PBS
  • Research in progress: weak statelessness, history expiry, and state expire. If state expiry is implemented first, then there may be no need to implement history expiry

2024.4.18 Portal network study

The Portal Network by Piper Merriam - Lightweight protocol for everyone https://www.youtube.com/watch?v=0stc9jnQLXA

  • What's the portal network
    • 5 new decentralized storage networks
      • Beacon light client: beacon chain light protocol data
      • State network: account & contract storage
      • Transaction gossip: lightweight mempool
      • History network: headers, block bodies, receipts
      • Canonical txn index: TxHash > Hash, Index
  • Design goals
    • Users-focused
    • Lightweight
    • Elimination of syncing
    • Scalable in terms of # of participants
  • Project status as of Devcon Bogota
    • In full development stage
    • 3 portal client implementations: Trin, Ultralight, Fluffy
    • Rough timeline: fully operational history network -> beacon light network -> state & transaction gossip networks

2024.4.19 Notes on Vitalik's blog on state expiry & statelessness roadmap

https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal

2024.4.21 Week 9R History expiry notes

2024.4.22 Week 10D Precompiles notes

  • 3 kinds of precompiles
    • Precompiles: tasks you could do with the EVM, but are too expensive/ slow
    • System contracts: tasks & side effects you cannot do with the EVM
    • Predeployed contracts: contracts that are part of the initial state
  • Ethereum mainnet precompiles: https://www.evm.codes/precompiled
    • 0x01 - ecRecover
    • 0x02 - SHA2-256
    • 0x03 - RIPEMD-160
    • 0x04 - identity
    • 0x05 - modexp (Byzantium)
    • 0x06, 0x07, 0x08 - ecAdd, ecMul, and ecPairing on alt_bn128 (Byzantium)
    • 0x09 - Blake2B F Function (Istanbul)
    • 0x0A - KZG point evaluation (Cancun)
  • EVM view
  • Design issues in precompiles
    • All boundary conditions must be specified
    • Gas should scale with effort
      • Execution: algo can hide problems
      • Input: variable input should always be charged
    • Costs should account for worst case
  • Implementation strategies
    • Implement with client software
    • x
  • How it's implemented
    • Besu
    • Geth
    • Nethermind
    • Reth
  • Implementation strategies
    • Implement with client software
    • Implement System contracts
  • System contract use cases
    • Access L1/L2 bridging
      • Arbitrum, Optimism, zk chains
    • Access foreign host chain services
      • Moonbeam, Aurora, Hedera
    • Advanced services (coming soon)
      • Fhenix (FHE), Ritual (AI model execution)
  • Typical L2 system contract uses: https://www.rollup.codes/
    • L1/2 communications
    • treasury/ fee vault mgmt
    • security/ admin tasks
    • Chain info queries
  • Notable design choices in L2 contracts
    • Use of solidity ABI for precompiled access
    • Mixed API designs
    • Mixed permance
    • Mixed implementation strategies
    • Mixed contract address deployments
  • Foreign host chain services
    • altL1 token access
    • altL2 account tools
    • Zk features
  • Security & system contracts
    • Precompiles don't share Ethereum's memory model
    • DELEGATECALLS can impersonate SENDERs via callback
    • Best to ban Delegatecalls into precomiples
    • Ensure all actions are revertable
  • Precompile futures
    • There is resistance to adding new mainnet precompiles
      • BLS-9 separate functions
    • Rollcall is standdardinzing L2 precompiles
      • ECDSA (secp256r1) verification
    • EVMMAX (modular math extensions) may reduce the demand
      • Aspirationally to be w/in 2x gas cost
  • Progressive precompile
    • New quasi-proposal to "cannonize" well known contracts
    • How to handle gas is unresolved
    • Needs better math support (eg. EVMMAX)
    • Mixed execution example: EIP 4788 - canonical EVM code exists
      • Execute the contract - Geth/ Reth
      • Native evaluation - Besu/ Nethermind

2024.4.24 Notes on Fork choice advanced research

Week 10 最后一节课，听得我真是头大，需要重新回顾视频好几遍 Deck link：https://docs.google.com/presentation/d/1Hrk-0x7N18qHwy9d7DeONdOVpA_6GPOqG7xxf6TtaGw/edit#slide=id.g1f7e27a7462_3_890

  • Gasper recap
    • GHOST (Greediest Heaviest Observed SubTree)
    • LMD-GHOST (Latest Message Driven GHOST)
      • Aka Vote driven GHOST
      • LMD-GHOST as a protocol
    • Casper FFG
    • Ethereum today
    • Modelled as an Ebb-and-flow protocol
      • Aim
        • Dynamic availability
        • Finality
        • Prefix
    • Hybrid fork-choie
  • Problems of LMD-GHOST
    • Simple ex-ante reorg
      • Solution: Proposer boost
        • New block proposals have a temporary weight boost during their slot
        • In practice, set to 40%
    • Balancing attacks
      • Solution: Proposer boost still works in this case
  • Designing a theoretically secure available chain
    • Improving on proposer boost: View-merge
    • RLMD-GHOST
  • SSF protocol
  • Fork choice in the Ethereum Roadmap
    • SSF or fast finality
    • ePBS
    • DAS
  • Q&A
    • If possible, can you elaborate on what's the BLS signature count limit / slot in SSF scenario?

2024.4.25-28 Notes on PoS evolution

Source: https://github.com/ethereum/pos-evolution/blob/master/pos-evolution.md

  • System model
    • Validators
      • Validators are assigned a protocol to follow
      • A protocol for V consists of a collection of programs with instructions for all validators
      • Each validator has a deposit/ or stake
    • Failures
      • A validator that follows its protocol during an execution is called honest
      • A faulty validator may crash or deviate arbitrarily from its spec -> Byzantine faults
      • Assume the existence of a probabilistic poly-time adversary A, that can choose up to F validators to corrupt
    • Links
      • Assume a best-effort gossip primitive that will reach all validators is available
    • Time & sleepiness
      • Time is divided into discrete rounds & validators have synchronized clocks
      • In a synchronous network, the message delay is upper-bounded by a constant Δ rounds, with Δ known to the protocol.
      • In a partially synchronous network in the sleepy model, communication is asynchronous until a global stabilization time (GST), after which communication becomes synchronous
        • Honest validators sleep and wake up until a global awake time (GAT), after which all validators are awake.
        • Adversary validators are always awake.
    • View
      • A view is a subset of all the messages that a validator has received.
      • The notion of view is local for validators.
  • Gasper: a PoS consensus protocol by combining FFG Casper, a partially synchronous consensus protocol, and a synchronous consensus protocol named LMD-GHOST.

    • FFG (Friendly finality gadget) Casper

      • Overivew
        • Goal: finalize the proposed blocks, ensuring their safety even during potential network partitions
        • Feature
          • Accountability, i.e. If a validator violates some rule, it's possible to detect the violation and know which one violated -> allow the system to penalize/ slash the Byzantine validator
        • Casper Mechanism
          • 2-phase traditional propose-vote-based BFT mechanism
          • Designed as a gadget that works on top of a provided blockchain protocol
          • There is no leader in charge of assembling proposals -> generated across honest nodes by an underlying proposal mechanism
      • Checkpoint
        • Process of Casper
          • Validators participate in the protocol by casting votes on blocks in the block-tree -> Messages exchange among validators are votes for blocks
          • Vote message incl.: 2 blocks source & target, and their heights
          • Once a vote has been cast by 2/3 of validators and the checkpoint of the source block is justified, and the target block becomes justified
        • Casper has 2 properties
          • Accountable safety: 2 conflicting checkpoints imply that more than 1/3 adversarial stake can be detected
          • Plausible liveness: Possible to produce new finalized checkpoints
      • Voluntary exit
        • Dynasty of a block: the number of finalized checkpoints in the chain from root to the parent of block b
        • Start dynasty: When a would-be validator’s deposit message is included in a block with dynasty 𝑑, then the validator 𝑣𝑖 will join the validator set at first block with dynasty 𝑑+2
        • End dynasty: If validator 𝑣𝑖’s withdraw message is included in a block with dynasty 𝑑, it similarly leaves the validator set at the first block with dynasty 𝑑+2

      == TODO ==

    • LMD-GHOST

      • Latest message

    • FFG Casper + (H)LMD-GHOST = Gasper

      • Beacon state
      • Committee
      • Proposer
      • Beacon block
      • Attestation
      • Justification & finalization
      • Fork choice
      • Slashing
      • More on slashing
  • Properties of Gasper
    • Availability-finality dilemma
  • Extra: Weak subjectivity
  • Problem & solution
    • Problem: balancing attack
      • Part of the solution: Proposer weight boosting
      • Other part of the solution: Equivocation discounting
    • Problem: Avalanche attack (solved with equivocation discounting)
    • Problem: Ex-Ante reorg
      • Solution: View-merge as a replacement for proposer weight boosting

2024.4.29 notes on week 10R fork choice

Link: https://twitter.com/EIPFun/status/1785056437971927380

2024.4.30 MEV basics

  • Blog link: https://ethereum.org/en/developers/docs/mev/
  • MEV definition
    • MEV refers to the max value that can be extracted from block production in excess of the standard block reward and gas fees, by including, excluding, and changing the order of txns in a block
  • MEX extraction
    • Overview
      • In theory, MEV accrues entirely to validators
      • In practice, a large portion of MEV is extracted by independent network participants aka searchers.
    • Gas golfing
      • Definition: Program txns so that they use the least amount of gas, which allows searchers to set a higher gas price while keeping total gas fees constant
    • Generalized frontrunners
      • Definition: Bots that watch the mempool to detect profitable txns
      • How it works
        • The frontrunner will copy the potentially profitable txn's code, replace addresses with the frontrunner's address, and run the tx locally to double check if it's profitable
        • If yes, the frontrunner will submit the modified tx with the replaced address, and a higher gas price
        • Thus, frontrunning the original tx and gets the original searcher's MEV
    • Flashbots
      • Extend execution clients with a service that allows searchers to submit MEV tx to validators without revealing them to the public mempool
      • This prevents tx from being frontrun by generalized frontrunners
      • 所以 flashbot 主要是为 EL 客户端提供服务，防止 generalized frontrunner 这种的 MEV
      • 主要方法是将 MEV 交易秘密的提交给 validators 而不显示在公共的 mempool 中，这样 generalized bot 就没法在 mempool 中看到及抢跑了
  • MEV examples
    • DEX arbitrage
      • Most well known MEV opportunity, thus most competitive one
      • How it works: If 2 DEXes are offering a token at 2 different prices, one can buy the token on the lower-priced DEV and sell it to the higher-priced DEX in a single, atomic tx
    • Liquidations
      • If, due to market fluctuation, there is collateral liquidation, the borrower usually has to pay a hefty liquidation fee, which is where MEV comes in.
      • Searchers compete to deteremine which borrowers can be liquidated, and be the first to submit a liquidation tx and collect the liquidation fee.
    • Sandwich trading
      • A searcher will watch the mempool for large DEX trades, which typically will raise the price of a token
      • The searcher can cal the approximate price effect, execute an optimal buy order before the large trade, then sell it after the large trade for higher price

2024.5.3 notes on devp2p & libp2p

https://twitter.com/Chloe_zhuX/status/1786420940701659246

2024.5.4 notes on MEV basic

blog: https://ethereum.org/en/developers/docs/mev/

  • Effects of MEV
    • The good
      • Many defi projects rely on eco rational actors to ensure the usefulness & stability of their protocols
      • Eg. Price discovery, speedy liquidation
    • The bad
      • At app layer, some MEV (eg. sandwich trading) could result in worse experience for end users, eg. Increased slippage
      • At network layer, generalized frontrunners & gas-price auctions could result in network congestion and high gas prices
      • Within blocks, MEV can have deleterious effects between blocks. If the MEV in a block significantly > standard block reward, validators may be incentivized to reorg blocks and capture MEV for themselves -> block reorg & consensus instability

2024.5.5 & 6 notes on MEV basic

  • MEV in PoS
    • Validator centralization
    • Permissioned mempools
      • Traders may conduct off-chain deals with validators for tx privacy. Traders can send the tx directly to the validator, bypassing the public mempool to avoid MEV.
        • Dark pool: permissioned, access-only mempools, open to users willing to pay certain fees
      • Potential result
        • -> diminish Ethereum's permissionless, trustless mechanism
        • Accelerate the centralization risks -> large pools running multiple validators will benefit from offering tx privacy to traders & users -> more MEV revenue goes to larger player
    • Two solutions to reduce the negative impact of MEV
      • PBS: mitigate the MEV impact, especially at the consensus layer
        • Separation of block producer & block proposer
          • Validators: propose and vote on blocks
          • Block builders (new entities): order tx and build blocks
        • Create an auction market, where builders negotiate with validators selling blockspace
        • Scheme: current PBS designs use a commit-reveal scheme
          • Builders only publish a cryptographic commitment to a block's content, along with their bids
          • After accepting the winning bid, the proposer creates a signed block proposal that incl. The block header
          • The block builder is expected to publish the full block body after seeing the signed block proposal. It needs enough attestations before finalized.
      • Builder API
        • To do
  • To read

2024.5.7 EIP 7702 Set EOA account code for one transaction

https://github.com/ethereum/EIPs/pull/8527/files

  • Why:
    • Lots of interest in adding ST functionality improvements to EOAs
      • Batching
      • Sponsorship
      • Privilege de-escalation
    • EIP 3074 solves all the above use cases, but it has forward-compatibility concerns.
      • It introduces 2 opcodes, that would have no use in an endgame AA world, where all users will use smart contract wallets.
      • That could lead to possible fragmentation of effort.
    • EIP 7702 wants to enable the above use cases, without the 2 weakness
  • What:
    • Add a new tx type "contract_code" field and a signature, and convert the signing account into a smart contract wallet for the duration of that tx
  • How:
    • Conversion of EIP 3074 use cases
      • AUTH and AUTHCALL would be replaced by calls into the EOA
      • AUTH would be replaced by a code to verify
      • AUTHCALL would be replaced by a call to execute
    • Forward compatibility with future AA
      • The contract code that users would need to sign could be existing ERC 4337 wallet code
      • No need to add any opcode
      • Allow EOAs to temporarily convert themselves into contracts to be incl. Into ERC 4337 bundles
      • Once implemented, EIP 5003 is just a flag to not set the code back to empty at the end
    • Backward compatibility
      • Impact on mempool and inclusion list （不太懂为啥）

2024.5.9 ACDE call notes

主要围绕下个升级 Pectra 展开

  • devnet-0 准备：EF devops 团队正在进行 kurtosis 配置文件预计下周将推出
  • AA 相关讨论：本周进行了 AA 的单独会议，讨论主要围绕 Vitalik 新提出的 EIP 7702 展开，其中很多细节还有待商榷，但核心开发者整体比较支持 EIP 7702。相关讨论详见：【】
  • EIP 7685 General purpose execution layer requests：
    • 核心开发者针对该 EIP 的改动及对 optimistic sync 的影响进行了讨论
    • 另外讨论也涉及到是否引入 SSZ 来取代该 EIP 中使用的 MPT 根，目前该想法还未得到多数核心开发者的支持
  • EOF（EVM Object Format）：
  • EIP 7623 Increase calldata cost