<![CDATA[EIP Fun]]>https://eipfun.substack.comhttps://substackcdn.com/image/fetch/$s_!MyLx!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F827514b1-7d94-42e0-81fe-e364607d52f5_1024x1024.pngEIP Funhttps://eipfun.substack.comSubstackMon, 28 Sep 2026 09:58:22 GMT<![CDATA[EIP Fun Weekly #93: History Expiry Meta, Block-Level Access Lists]]>https://eipfun.substack.com/p/eip-fun-weekly-93-history-expiryhttps://eipfun.substack.com/p/eip-fun-weekly-93-history-expiryMon, 14 Apr 2025 09:30:17 GMT

Welcome to read the 93th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Execution Layer Meeting 209

  • Pectra Upgrade

    • Mainnet Activation: The Pectra upgrade is scheduled for activation on May 7, 2025. All client teams are expected to have their final releases ready by April 21, 2025.

    • No Further Changes: No more refinements to the 11 EIPs in Pectra; the focus is on ensuring smooth deployment.

  • Other Information

    • Fusaka EIPs: The list of EIPs being considered for Fusaka has grown significantly. Currently, 12 EIPs are under consideration, with potential for more additions in future discussions.

    • Scoping Spiral: Developers are avoiding new EIPs in Fusaka until PeerDAS and EOF are stable.

    • ACDT Calls: A new ACDT call series will focus on testing future upgrades, helping clear up space in existing calls for long-term planning.

Weekly EIP & ERC Highlights

EIP-7927: History Expiry Meta

Provide a method the activation process for history expiry in Ethereum, including testnet and mainnet activation, client requirements, and pre-merge history storage.

  • Purpose: Defines the steps for activating history expiry on Ethereum, reducing data storage by allowing clients to drop pre-merge history, and ensuring compatibility with JSON-RPC use cases.

  • Key Benefits:

    • Mainnet & Testnet Activation: History expiry will be activated shortly after the Pectra hard fork, with testing on Sepolia starting May 1, 2025.

    • Improved Data Efficiency: Clients can drop pre-merge history to save on storage, improving scalability.

    • Pre-Merge History Storage: Pre-merge history can be accessed through decentralized solutions like the Portal network.

  • Key Components:

    • Client Requirements: Execution layer clients must implement EIP-7642, and consensus clients must rely on EIP-6110 to remove dependence on pre-merge data.

    • Testing: History expiry will be tested on Sepolia and devnets before mainnet activation.

EIP-7928: Block-Level Access Lists

Introduce block-level access lists to improve transaction validation parallelization by including a list of all addresses and storage keys accessed in the block header.

  • Purpose: Enhances execution efficiency by enabling parallel transaction execution through block-level enforced access lists, allowing the execution engine to know in advance which storage slots are accessed in each transaction.

  • Key Benefits:

    • Parallel Transaction Execution: By enforcing block-level access lists, transactions can be scheduled and executed in parallel, improving performance.

    • Improved Execution Pipelines: Explicitly defining storage interactions for each transaction allows for better optimization of execution pipelines.

  • Key Components:

    • Block Header Modification: A new field block_level_accesses is introduced to the block header, mapping accessed addresses and storage keys to transaction indices and their corresponding values.

    • State Transition Function: The state transition function validates the block-level access list asynchronously to ensure correctness without delaying execution.

Upcoming EIP Events

Stateless Implementers Call #34

All Core Devs - Execution (ACDE) #210

Ethproofs call 01

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #92: Dynamic Exit Queue Rate Limit, Memory Efficiency, Stack Manipulation]]>https://eipfun.substack.com/p/eip-fun-weekly-92-dynamic-exit-queuehttps://eipfun.substack.com/p/eip-fun-weekly-92-dynamic-exit-queueMon, 07 Apr 2025 03:01:24 GMT

Welcome to read the 92th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Consensus Layer Meeting #154

  • Pectra Upgrade

    • Pectra Upgrade Testing: Testing of Pectra features on the Hoodi testnet is complete, with validator "top-up" deposits showing limitations.

    • Mainnet Activation Date: Pectra's mainnet activation is now scheduled for May 7, with the final client release deadline set to April 21.

    • Client Readiness: Client teams are urged to release final updates as soon as ready for the Pectra mainnet upgrade.

    • Blob Scaling (PeerDAS Updates): PeerDAS specifications are being implemented, with plans for automated blob capacity increases post-Fusaka.

  • Other Information

    • Fusaka Upgrade Scoping: Key EIPs, including EIP 7917 and EIP 7898, are being discussed for inclusion in Fusaka.

    • EIP 7922: EIP 7922 introduces a dynamic validator exit queue rate limit to improve validator operations.

Weekly EIP & ERC Highlights

EIP-7922: Dynamic Exit Queue Rate Limit

Dynamically adjusts the validator exit churn limit to optimize the exit process, improving network flexibility while ensuring security.

  • Purpose: proposes dynamically adjusting the validator exit churn limit based on historical data, allowing Ethereum to handle spikes in validator exits while maintaining network security and stability.

  • Key Benefits:

    • Flexibility in Exit Demand: It reduces wait times for validators during periods of high demand, such as market events, while keeping the security of the network intact.

    • Improved Validator Experience: By dynamically adjusting the churn limit, Ethereum can process more exits when capacity allows, making validator exits more efficient.

    • Network Security Preservation: The dynamic adjustment ensures that the same security constraints are preserved over each rolling two-week period.

  • Key Components:

    • Dynamic Churn Limit: The maximum churn limit is adjusted based on the unused churn capacity from previous generations.

    • Historical Churn Vector: A vector tracks the churn capacity used in the previous 16 generations, which is used to determine the allowed churn for the current period.

    • Generation-Based Exit Queuing: The exit queue is now based on 256-epoch generations, making the process more flexible and aligned with actual demand patterns.

EIP-7923: Linear, Page-Based Memory Costing

Replaces the EVM’s quadratic memory pricing with a linear, page-based model to reduce costs, improve efficiency, and support modern memory usage patterns.

  • Purpose: Introduce a more efficient and predictable memory pricing model in the EVM by replacing the outdated quadratic cost formula with a linear, page-based system, enabling better performance, reduced gas costs, and improved compatibility with high-level programming paradigms.

  • Key Benefits:

    • Lower and Predictable Costs: Makes memory usage more affordable and easier to reason about, especially for large allocations.

    • Improved Language Support: Enables support for modern memory management (e.g., separate heap and stack) in smart contract languages like Solidity and Vyper.

    • Efficiency Gains: Reduces gas usage and enables optimizations based on memory locality and usage patterns.

    • Support for Virtual Memory: Emulates virtual memory behavior, allowing more advanced memory handling in contracts.

  • Key Components:

    • Page-Based Model: Memory is divided into 4KB pages. Accessing a page for the first time in a message call costs 100 gas; accessing a page not recently used (LRU) costs 6 gas.

    • Virtual Addressing: Memory is virtually addressable, with a maximum address space of 4GB (2^32 bytes).

    • Global Memory Limit: Hard limit of 64MB per transaction (16,384 pages) to mitigate DoS risks.

    • Instruction Costs: Base gas cost for memory instructions (MLOAD, MSTORE, etc.) remains 3 gas.

    • MSIZE Semantics: No change to maintain backwards compatibility—returns the highest byte touched, rounded up to 32.

EIP-7912: Pragmatic expansion of stack manipulation tools

Introduces new stack manipulation instructions for deeper stack access in the EVM.

  • Purpose: Enhances EVM stack manipulation capabilities by adding new instructions for arbitrary stack depth, allowing for more efficient and flexible stack operations in smart contracts.

  • Key Benefits:

    • Improved Stack Access: Enables stack operations beyond the current depth, supporting more complex contract logic and deeper stack manipulations.

    • Efficient Stack Operations: New instructions like SWAPN and DUPN provide dynamic stack access, reducing the need for code versioning and improving compiler behavior.

    • Enhanced Flexibility: The EXCHANGE instruction allows swapping two elements of the stack based on dynamic indices, enabling more complex contract patterns.

  • Key Components:

    • New Instructions:

      • SWAP17-SWAP24: Swap the top element with the 17th to 24th most recent stack elements.

      • DUP17-DUP24: Duplicate the 17th to 24th most recent stack elements and push them to the top.

      • SWAPN and DUPN: Swap or duplicate stack elements based on an integer N (specified via a preceding PUSH1 instruction).

      • EXCHANGE: Swap two stack elements at indices N-1 and M-1, where N and M are derived from a PUSH2 operation.

Other EIPs and ERCs:

  • EIP-7925: Optional RPC Methods `eth_sendBlobs` and `eth_getBlobsStatus`

Upcoming EIP Events

All Core Devs - Execution (ACDE) #209

EIPIP Meeting 115

AllWalletDevs | call #32

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #91: Enhancing On-Chain Asset Management, Margin Token, Signature Verification]]>https://eipfun.substack.com/p/eip-fun-weekly-91-enhancing-on-chainhttps://eipfun.substack.com/p/eip-fun-weekly-91-enhancing-on-chainMon, 31 Mar 2025 07:43:04 GMT

Welcome to read the 91th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Ethereum All Core Developers Execution Call #208

  • Pectra Upgrade

    • Pectra Mainnet Activation Date: Tentatively set for April 30, 2025, with final releases due between April 10-14.

    • Pectra Testing on Hoodi: Testing continues but delayed due to validator deposit backlogs; no critical issues found so far.

    • Client Configurations Before Upgrades: Proposed EIP 7910 to ensure smooth upgrade deployments by detailing client configurations, still under review.

    • EOF in Fusaka: Complete EOF proposal moves forward despite opposition, with updates to documentation to reflect it.

  • Other Information

    • PeerDAS Updates: Sunnyside Labs working to accelerate PeerDAS implementation, with discussions on how to integrate it into client layers.

    • Fusaka Scope: Broad support for including EIP 7883 in Fusaka; no new EIPs to be added until PeerDAS and EOF are ready.

    • History Expiry: Pushed back May 1 deadline for activating history expiry on mainnet until after Pectra upgrade, with focus on Sepolia testnet first.

    • Protocol Research Calls: New call series starting April 2, 2025, to discuss Ethereum’s long-term future.

Weekly EIP & ERC Highlights

ERC-7908: HD Wallet in Treasury Management

Proposes a standardized method for managing institutional assets on-chain using HD wallets with hierarchical key paths for secure key generation and departmental isolation.

  • Purpose: Enhance on-chain treasury management by enabling secure, hierarchical key management and departmental isolation, supporting asset security and transaction efficiency in multi-chain environments.

  • Key Benefits:

    • Provides secure hierarchical key management for institutional assets.

    • Ensures departmental isolation and permission control.

    • Supports multi-chain environments for efficient asset management.

    • Aligns with BIP-44 standards for deterministic key generation.

  • Key Components:

    • Hierarchical deterministic (HD) key paths for asset management.

    • Entity and department-specific key isolation.

    • Secure private key generation using a standardized derivation path.

ERC-7909: Margin Token Wrapper

Defines a wrapper contract that converts any ERC-20, ERC-721, or ERC-1155 token into a lockable "margin token" for use as collateral across DEXs.

  • Purpose: Enhance interoperability and enable the use of any token as collateral by wrapping it into a lockable margin token, allowing for secure and flexible margin management across different DEX protocols.

  • Key Benefits:

    • Converts any ERC-20, ERC-721, or ERC-1155 token into a lockable margin token.

    • Enables cross-protocol interoperability for decentralized margin trading.

    • Provides a unified wrapper contract for multiple token standards.

    • Supports token locking with expiration to avoid infinite locking.

  • Key Components:

    • MarginTokenWrapper contract: Implements core functionalities such as minting, approving, locking, unlocking, and liquidating tokens.

    • ApproveLock and PermitLock: Allows for the approval of locking tokens with specific limits and expiration times.

    • Lock and Unlock operations: Manage locked assets as collateral for margin trading.

    • Burn function: Enables the conversion of unlocked tokens back into their original form.

ERC-7913: Signature Verifiers

Proposes a standard for verifying signatures from keys without Ethereum addresses, such as those from other cryptographic curves, hardware devices, or email-based systems.

  • Purpose: Enable the verification of signatures from keys without Ethereum addresses by using verifier contracts, facilitating account abstraction and the integration of diverse cryptographic methods for signing.

  • Key Benefits:

    • Extends signature verification to keys without Ethereum addresses, such as non-Ethereum cryptographic curves (e.g., secp256r1, RSA), hardware devices, or emails.

    • Reduces the need for deploying multiple ERC-1271-compatible contracts by using a small number of verifier contracts.

    • Facilitates account abstraction and social recovery by decoupling signers from traditional Ethereum addresses.

    • Backward compatible with Externally Owned Accounts (EOA) and ERC-1271 contracts.

  • Key Components:

    • Keys: Represented as bytes objects of arbitrary length, such as public keys from P256 or RSA.

    • Verifiers: Smart contracts that handle signature verification for a specific key type, identified by their Ethereum address.

    • Signer Identification: Signers are identified by a (verifier, key) pair rather than a fixed on-chain address.

Other EIPs and ERCs:

  • ERC-7914: An Interface for Transfer From Native

  • ERC-7920: Composite EIP-712 Signatures

  • EIP-7921: Skip `JUMPDEST` immediate argument check

Upcoming EIP Events

PeerDAS Breakout Call #23

L2 Interop Working Group Call #6

All Core Devs - Consensus (ACDC) #154

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #90: Simplifying Smart Contract Deployment, Fork Preparations]]>https://eipfun.substack.com/p/eip-fun-weekly-90-simplifying-smarthttps://eipfun.substack.com/p/eip-fun-weekly-90-simplifying-smartMon, 24 Mar 2025 10:22:50 GMT

Welcome to read the 90th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Ethereum All Core Developers Consensus Call #146

  • Pectra Upgrade

    • Developers confirmed the plan for Pectra testing on the Hoodi testnet, with the upgrade scheduled for March 26, 2025.

    • Mainnet activation of Pectra will be postponed until after further testing on Hoodi.

    • The May 1 deadline for history expiry is likely to be moved due to delays in Pectra activation.

    • Testing continues on Pectra Devnet 6 with an increased block gas limit to 60m, and issues with Geth and Lighthouse are being investigated.

    • EIP 6110 in Pectra changes validator deposit and verification, affecting history expiry plans.

  • Other Information

    • PeerDAS development requires more attention from client teams, with minor specification changes proposed for review.

    • EIP 7688, forward-compatible consensus data structures, is proposed for inclusion in the Fusaka upgrade, but implementation is prioritized after PeerDAS.

    • EIP 7688 could help reduce Beacon Chain state size and minimize overhead for client teams, especially for staking pools and restaking protocols.

Weekly EIP & ERC Highlights

EIP-7903: Remove Initcode Size Limit

Removes the initcode size limit introduced in EIP-3860 to simplify smart contract deployment and enable high-level languages to cleanly abstract large contracts.

  • Purpose: Eliminates the 49152-byte initcode size restriction to allow more flexible contract deployment and support large logical contracts composed of smaller sub-contracts in a single transaction.

  • Key Benefits:

    • Simplified Deployment: Enables large contract deployments in a single transaction, avoiding the need to split contracts.

    • Better Abstraction for HLLs: Supports high-level languages in abstracting away deployment complexities without hitting size limits.

    • Maintains Gas Fairness: Retains the existing gas costs for initcode execution, ensuring fair cost attribution with the removal of the size cap.

  • Key Components:

    • Initcode Size: Removes the 49152-byte size cap on initcode during contract creation.

    • Gas Costs: Retains the existing gas costs (2 gas per byte for JUMPDEST analysis) for initcode.

    • Contract Size Limit: No change to the EIP-170 24576-byte limit for deployed contract size.

EIP-xxxx: eth_config JSON-RPC Method

Introduces a JSON-RPC method to provide configuration details for the current and next fork, helping ensure node readiness for upcoming hard forks.

  • Purpose: Provides an RPC method that allows clients to report their configuration for the current and next Ethereum fork, ensuring they are properly configured ahead of time.

  • Key Benefits:

    • Pre-Fork Validation: Enables node operators and validators to verify client configurations before a hard fork.

    • Error Prevention: Helps prevent forks caused by misconfigured nodes, which have occurred in the past.

    • Improved Debugging: Provides insights into configuration mismatches, aiding client developers and monitoring tools in identifying issues early.

  • Key Components:

    • eth_config RPC Method: Exposes the current and next fork configuration via JSON-RPC.

    • Configuration Object: Includes key data like activation time, blob schedule, chain ID, precompiles, and system contracts.

    • Fork Hashing: Uses CRC-32 hashing for configuration objects to ensure accurate configuration reporting and validation.

Upcoming EIP Events

EOF Implementors Call #70

All Core Devs - Consensus (ACDC) #154

beam chain call #3

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #89: Stateless Mempool, Wallet Capabilities for AA]]>https://eipfun.substack.com/p/eip-fun-weekly-89-stateless-mempoolhttps://eipfun.substack.com/p/eip-fun-weekly-89-stateless-mempoolMon, 17 Mar 2025 06:10:50 GMT

Welcome to read the 89th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Ethereum All Core Developers Execution Call #207

  • Pectra Upgrade

    • Hoodi Testnet Launch: Hoodi testnet will launch on March 17, 2025, and activate the Pectra upgrade 10 days after on Wednesday, March 26.

    • Holesky Exit Queue: The validator exit backlog on Holesky will take 1.5 years to process.

    • Pectra Mainnet : Pectra must first be tested on Hoodi before mainnet activation, expected by late April or May.

    • Hoodi Over Holesky: Developers agreed to focus on launching Hoodi instead of hard forking Holesky to clear the exit queue.

  • Other Information

    • Error Handling: Updates to Pectra specifications are needed for system contract call failures.

    • PeerDAS: Updates to the PeerDAS proposal will be reviewed asynchronously in the coming weeks.

    • Fusaka Fork Deadlines: The deadline to propose EIPs for Fusaka is March 24, with client teams submitting proposals by March 31.

    • EIP-4444 Progress: The Portal Network will provide an alternative service for historical Ethereum data, starting with pruning in May 2025.

    • Stateless Clients: Discussions on stateless clients will continue asynchronously due to time constraints during the call.

Weekly EIP & ERC Highlights

EIP-7901: Stateless Mempool Transaction

Specifies how transactions can be submitted to stateless block builders with pre-state witnesses and optional ZK proofs, enabling decentralized block production.

  • Purpose: facilitate block production by stateless validators using state diffs and ZK proofs, reducing centralization risks in Ethereum.

  • Key Benefits:

    • Enables stateless block production and validation.

    • Reduces centralization risk by allowing validators to operate without full node state.

    • Uses state proofs and optional ZK proofs for secure transaction inclusion.

  • Key Components:

    • Transactions include execution witnesses (e.g., merkle, verkle) and state diff proofs.

    • Block builders verify transactions using pre and post-state proofs.

ERC-7902: Wallet Capabilities for Account Abstraction

Defines a set of wallet capabilities to enable communication between dApps and Account Abstraction wallets, supporting advanced features and seamless integration.

  • Purpose: To provide a structured set of "capabilities" for dApps and AA wallets to communicate, enabling advanced features of Account Abstraction without requiring custom solutions.

  • Key Benefits:

    • Seamless Integration: Enables dApps and AA wallets to communicate supported features and parameters.

    • Standardized Wallet Capabilities: Provides a structured method for dApps to adapt to various AA wallets.

    • Advanced Account Abstraction Support: Expands functionality to support more complex use cases in the Ethereum ecosystem.

  • Key Components:

    • Create EIP-7702 Authorization Capability: Enables wallets to provide an authorization tuple for EIP-7702 compatible transactions.

    • Static Paymaster Configuration Capability: Allows integration with Paymasters that do not require dynamic configuration.

    • Validity Time Range Capability: Specifies a time range during which requested operations remain valid after signing.

Other EIPs and ERCs:

  • EIP-7906: Restricted Behavior Transaction Type

  • ERC-7905: Minimal interface of Sovereign Bridged Token

Upcoming EIP Events

Stateless Implementers Call #32

All Core Devs - Execution (ACDE) #208

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #88: Social SBT, On-Chain Function Encoding, Gas Cost Repricing]]>https://eipfun.substack.com/p/eip-fun-weekly-88-social-sbt-on-chainhttps://eipfun.substack.com/p/eip-fun-weekly-88-social-sbt-on-chainMon, 10 Mar 2025 06:34:16 GMT

Welcome to read the 88th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Ethereum All Core Developers Consensus Call #152

  • Pectra Upgrade

    • Holesky Testnet Recovery: Holesky testnet is still not finalized, and developers decided to use a Shadow Fork for Pectra testing.

    • Pectra Devnet-7: Devnet 7 was launched but lacks application testing, so developers recommended stopping it and focusing on the Shadow Fork.

    • EIP 6110 Proposal: Developers discussed updating EIP 6110 for client consistency and decided to postpone the discussion.

    • Pectra Mainnet Activation: The timing for Pectra mainnet activation will depend on the progress of Holesky testnet recovery.

    • Pectra BLS Precompiles Issue: Issues found through the Pectra bug bounty program have been resolved.

    • Sepolia Testnet: Sepolia testnet upgrade was successful, and the empty block issue was fixed.

    • PeerDAS Devnet Update: PeerDAS Devnet 5 is running smoothly with all nodes as supernodes.

    • Pectra Bug Bounty Update: A potential attack vector related to EIP 7002 was found and is under investigation.

Weekly EIP & ERC Highlights

ERC-7894: Social SBT

Introduces SocialSBT, a non-transferable ERC-721 token that assigns DAO voting power based on social contributions instead of wealth.

  • Purpose: It aims to prevent wealthy individuals from dominating governance by linking voting power to meaningful contributions rather than token holdings.

  • Key Benefits:

    • Prevents Whale Attacks: Shifts governance power from token holdings to social contributions, stopping large holders from dominating votes.

    • Fair Voting: Social points are adjusted through community voting, ensuring influence is based on actual contributions.

    • Non-Transferable: Tokens can't be transferred or bought, ensuring governance power is tied to active participation.

    • Equitable Participation: Limits each address to one token, preventing power concentration.

  • Key Components:

    • Non-Transferability: ERC-721 transfer functions are disabled.

    • Social Points: Points are adjusted through community voting based on contributions.

    • Voting Process: Token holders vote to adjust social points, with only one vote per proposal.

    • Minting & Deleting: One token per address, with a permanent deletion option.

EIP-7899: On-Chain Function Return Type Encoding

Introduces on-chain encoding for Solidity function return types, allowing contracts to dynamically determine return data structure for better interoperability.

  • Purpose: It aims to eliminate reliance on off-chain ABI documentation by providing a standardized, on-chain method for encoding and decoding function return types, improving cross-contract communication.

  • Key Benefits:

    • Cross-Contract Calls: Contracts can interpret return data without predefined knowledge.

    • Future Proofing: Supports adding new return types to existing contracts.

    • Middleware & Proxies: Enables dynamic processing of unknown function outputs.

    • Interoperability: Facilitates contract introspection and integration with different frameworks.

    • On-Chain Oracles: Verifies expected data structure without relying on off-chain ABI metadata.

  • Key Components:

    • Encoding Scheme: Return types are encoded in a bytes array with type tokens (e.g., 0x01 for bool, 0x02 for address).

    • ERC-165 Implementation: Contracts must implement ITypeReturn to expose encoded return types.

    • Support for Complex Types: Handles basic types, tuples, arrays (dynamic and fixed), and complex data.

EIP-7901: General Repricing

Proposes adjusting Ethereum's gas costs to better reflect the computational effort required by smart contracts, rather than network-related costs.

  • Purpose: The adjustment aims to make gas pricing more accurate, improve blockchain throughput, and ensure gas costs match the actual computational complexity of executing contracts.

  • Key Benefits:

    • Improved Gas Cost Accuracy: Gas costs will better reflect the computational complexity of different opcodes and operations.

    • Enhanced Network Efficiency: Reduces the overall gas cost, increasing transaction throughput per block.

    • Fairer Transaction Processing: Ensures that computational costs are proportional across operations, mitigating risks of optimization exploits.

    • Increased Block Throughput: Reduces block validation time by improving gas cost efficiency.

  • Key Components:

    • Gas Cost Adjustments: Rebalancing of gas costs for opcodes, memory expansion, and precompiles based on empirical data and computational complexity.

    • New Gas Parameters: Introduction of new constants and formulas to reflect actual computational effort, including new costs for opcodes and memory.

    • EVM Adjustment: Changes to the Ethereum Virtual Machine (EVM) to implement the new gas cost schedule, affecting transaction execution and block validation.

Other EIPs and ERCs:

  • EIP-7898: Uncouple execution payload from beacon block

  • EIP-7900: Secure Delegatecall Opcode

  • ERC-7895: API for hierarchical accounts

  • ERC-7897: Wallet-Linked Services for Smart Accounts

Upcoming EIP Events

EIPIP Meeting 114

EVMMAX Implementers Call 4

Consensus-layer Call 153

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading EIP Fun! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #87: Clawback Transactions, Blob Scaling, and Crosschain Interoperability]]>https://eipfun.substack.com/p/eip-fun-weekly-87-clawback-transactionshttps://eipfun.substack.com/p/eip-fun-weekly-87-clawback-transactionsMon, 03 Mar 2025 09:44:02 GMT

Welcome to read the 87th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Ethereum All Core Developers Execution Call #206

  • Pectra Upgrade

    • Holesky Recovery: Holesky testnet failure was caused by misconfigured validator deposit addresses in Geth, Nethermind, and Besu clients, causing a chain split.

    • Recovery Plan: Sepolia testnet upgrade on March 5 will include updated client software to address the Holesky issues.

    • Mass Slashing Event: A mass slashing event may be triggered to help finalize the correct version of Holesky, though there are concerns about its effectiveness and long recovery time.

    • Sepolia Upgrade: Sepolia upgrade is still scheduled for March 5 with mandatory updates for Geth, Nethermind, Besu, and Lodestar clients.

    • Time Constraints: Due to time limits, some topics, like Fusaka, were not discussed and will be raised in future meetings.

Weekly EIP & ERC Highlights

EIP-7890: Clawback Transactions for EOAs

Introduces a cap of 30 million gas for transactions to improve network stability and prevent DoS attacks.

  • Purpose: Introduces a new Ethereum transaction type (0x05) that allows senders to reclaim funds within a clawback window before final settlement, offering enhanced security for EOAs and providing a decentralized safety layer for recovering funds lost due to errors or unauthorized transfers.

  • Key Benefits:

    • Fund Recovery: Provides an option for senders to reclaim mistakenly sent funds or funds transferred from compromised wallets before final settlement.

    • Security Enhancement: Reduces the risk of irreversible loss from errors, hacks, or malicious transfers.

    • No Central Authority: Operates entirely within the Ethereum protocol, without the need for centralized arbitration or third-party involvement.

  • Key Components:

    • Clawback Window: A delay period (in blocks) that allows the sender to reclaim funds before final settlement.

    • Transaction Type (0x05): A new transaction type specifically for clawback-enabled transactions.

    • Recovery Address: An optional address (clawbackAuth) that can initiate a clawback on behalf of the sender.

    • Transaction Structure: Includes fields for the clawback period and recovery address.

EIP-7892: Blob Parameter Only Hardforks

Introduces a mechanism for scaling Ethereum’s blob capacity through specialized hard forks that adjust only blob-related parameters, enabling more agile and efficient scaling.

  • Purpose: Introduces a lightweight mechanism for incrementally scaling Ethereum’s blob capacity via hard forks that modify only blob-related parameters.

  • Key Benefits:

    • Continuous Scaling: Allows for frequent and safe scaling of blob capacity in response to growing Layer 2 demand.

    • Reduced Overhead: Simplifies upgrades by only modifying blob-related parameters, avoiding the need for extensive coordination.

    • Stability with Scaling: Enables developers to adjust blob parameters after observing real-world network performance.

    • Predictable Upgrades: Provides a structured framework for developers to confidently scale Ethereum to meet Layer 2 needs.

  • Key Components:

    • Blob Target (blob_target): The expected number of blobs per block.

    • Blob Limit (blob_limit): The maximum number of blobs per block.

    • Blob Base Fee Update Fraction (baseFeeUpdateFraction): Determines how blob gas pricing adjusts per block.

    • BPO Fork Schedule: Defines when blob parameters are updated using a schedule that is shared between execution and consensus clients.

EIP-7888: Crosschain Broadcaster

Defines a standardized protocol for trustless cross-rollup message broadcasting using storage proofs, enabling secure and decentralized message passing across rollups with a common ancestor chain.

  • Purpose: Defines a standardized protocol for trustless cross-rollup message broadcasting and reception via storage proofs, enabling messages to be broadcasted on one chain and read by others with a common ancestor chain.

  • Key Benefits:

    • Cross-Rollup Interoperability: Enables trustless message passing between rollups on different architectures, supporting interoperability across chains.

    • Decentralized Messaging: Broadcasters store messages, while Receivers verify them using storage proofs, ensuring decentralized and secure message distribution.

    • Flexible Contract Updates: Introduces 'Pointer' contracts to dynamically update storage locations for finalized block hashes, allowing flexibility in evolving rollup contracts.

  • Key Components:

    • Broadcaster: A contract responsible for storing messages that can be read by Receivers on other chains. Messages are 32-byte and only non-duplicate messages from a publisher are accepted.

    • Receiver: A contract that verifies the contents of a Broadcaster on another chain using storage proofs, ensuring messages can be securely read across chains.

    • BlockHashProvers: Contracts that establish a unidirectional link between two chains, verifying the existence of finalized block hashes through storage proofs.

Other EIPs and ERCs:

Upcoming EIP Events

RollCall #11

All Core Devs - Execution (ACDE) #207

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading EIP Fun! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #86: NTT Precompiles for Quantum Security, Delayed Block Validation]]>https://eipfun.substack.com/p/eip-fun-weekly-86-ntt-precompileshttps://eipfun.substack.com/p/eip-fun-weekly-86-ntt-precompilesMon, 24 Feb 2025 05:42:26 GMT

Welcome to read the 86th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Ethereum All Core Developers Consensus Call #151

  • Pectra Devnet 6: Clients are stable, and MEV testing is going well, with some issues in the Flashbots builder being resolved.

  • Blob Count Increase in Fusaka: Developers aim for a theoretical max blob limit of 50, with discussions on using Blob Parameter-Only (BPO) forks if needed.

  • EIP 7872 and EIP 7870: Both EIPs were finalized, focusing on local builder blob limits and hardware/bandwidth recommendations for validators.

  • PeerDAS Devnet 5: Changes to the execution layer (EL) and a new design for outsourcing blob proof computation were discussed.

  • Testing and Future Meetings: Developers are preparing for further testing on a shadow fork of Ethereum mainnet and scheduling alternating PeerDAS breakout meetings.

Weekly EIP & ERC Highlights

EIP-7885: Precompile for NTT Operations

Introduces a set of precompiled contracts for Number Theoretical Transformations (NTT) and their inverse, optimizing polynomial multiplication for Post-Quantum and STARK applications.

  • Purpose: This aims to mitigate quantum computing threats and improve Ethereum's scalability.

  • Key Benefits:

    • Post-Quantum Security: Supports fast polynomial multiplication critical for quantum-resistant signature algorithms like Falcon and Dilithium.

    • STARK Optimizations: Enhances STARK verification performance, benefiting Ethereum's scaling efforts.

    • Efficient Computation: Reduces the complexity of polynomial multiplication, achieving faster operations compared to classical methods.

  • Key Components:

    • NTT_FW: Precompiled contract for forward NTT transformation, with a gas cost of 600.

    • NTT_INV: Precompiled contract for inverse NTT transformation, with a gas cost of 600.

    • NTT_VECMULMOD: Precompiled contract for vectorized modular multiplication with gas cost proportional to the input size.

    • NTT_VECADDMOD: Precompiled contract for vectorized modular addition with gas cost proportional to the input size.

EIP-7886: Delayed Execution

Introduces a mechanism where blocks can be validated before execution, allowing validators to attest to a block's validity based on its structure and upfront payment for inclusion costs.

Purpose: This reduces bottlenecks in the consensus process, enabling more efficient block validation.

Key Benefits:

  • Asynchronous Block Validation: Allows block validation to occur before the full execution of transactions, reducing the time it takes for validators to confirm a block.

  • Efficiency: By skipping invalid transactions instead of invalidating the whole block, it enables quicker validation and increases overall throughput.

  • Upfront Payment for Inclusion Costs: Ensures that even skipped transactions pay their resource costs by having the COINBASE pay for inclusion upfront.

Key Components:

  • Deferred Fields in Block Header: Fields such as state_root, receipt_root, bloom, gas_used, and requests_hash are deferred to allow for block verification without executing transactions.

  • COINBASE Signature: The COINBASE address signs the block header to authorize the upfront payment for transaction inclusion costs.

  • Static Block Validation: The block is validated without executing transactions by checking structural correctness, verifying transaction signatures, and confirming that COINBASE can pay the total inclusion cost.

  • Transaction Validation: Each transaction undergoes static checks to ensure valid gas prices and that the inclusion costs do not exceed block limits.

Other EIPs and ERCs:

Upcoming EIP Events

eth_simulate Implementers' Meeting

PeerDAS Breakout Room #19

All Core Devs - Execution (ACDE) #206

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading EIP Fun! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #85: DApp Network Configuration, EOF Enhancements, Gas Utilization Adjustments]]>https://eipfun.substack.com/p/eip-fun-weekly-85-dapp-network-configurationhttps://eipfun.substack.com/p/eip-fun-weekly-85-dapp-network-configurationMon, 17 Feb 2025 02:56:38 GMT

Welcome to read the 85th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

All Core Developers Execution (ACDE) Call #205

  • Pectra Upgrade Schedule: Pectra will be released on Holesky and Sepolia testnets on February 24 and March 5, respectively. The upgrade for Ethereum mainnet is expected around April 8.

  • Fusaka Upgrade Scope: Beiko suggested freezing the Fusaka upgrade scope when Pectra goes live. Geth developers disagreed, saying the timeline was too quick and some EIPs, like EOF, should be excluded from Fusaka.

  • Pectra Devnet Status: Pectra Devnet 6 is running well with nearly perfect validator participation.

  • EIP Requirements for Forks: EF engineer Vega proposed that EELS (Ethereum execution layer code specifications) and EEST (execution test cases) should be mandatory for any EIP in a hard fork. Geth developers raised concerns about the EELS team being overwhelmed with work.

  • Fusaka EIP Selection: Developers discussed the EIPs to include in Fusaka. There was disagreement on whether EOF and PeerDAS should be coupled together, with some pushing for earlier implementation of PeerDAS.

  • Development Timelines:

    • March 13: Deadline for proposing EIPs for Fusaka.

    • March 27: Client teams share their thoughts on which EIPs to include.

    • April 10: Finalize Fusaka’s scope.

  • EOF Progress: There’s still debate over coupling EOF with PeerDAS, with some developers questioning the necessity of EOF for Fusaka. If EOF delays PeerDAS by more than a month, the issue will be revisited.

Weekly EIP & ERC Highlights

EIP-7876: Ethereum Network Configuration for DApps

Provides a standardized format for DApps to configure and manage Ethereum network settings across multiple platforms.

  • Purpose: Establishes a unified format for specifying network configurations, enabling DApp developers to integrate seamlessly with multiple Ethereum networks and maintain consistent configuration management across platforms.

  • Key Benefits:

    • Interoperability: Provides a consistent configuration format for easy integration with multiple Ethereum-compatible networks.

    • Extensibility: Supports additional network-specific configurations without resorting to external storage.

    • Simplified Configuration: Eases the configuration process for developers, reducing inconsistency in network setup.

  • Key Components:

    • Network Configuration: JSON format specifying details like network name, RPC URLs, native currencies, contract addresses, and block explorers.

    • Smart Contract Integration: Supports contract-specific configuration, ensuring proper deployment and consistency across networks.

    • Extensibility: Allows the inclusion of custom configuration parameters, ensuring adaptability to new network features.

EIP-7880: EOF - EXTCODEADDRESS Instruction

Introduces a new instruction, EXTCODEADDRESS, in EOF to retrieve code delegation designations from an account without requiring code introspection.

  • Purpose: Adds the EXTCODEADDRESS instruction to EOFv1 to read code delegation designations set by EIP-7702, enabling contracts to react to delegation without inspecting raw code.

  • Key Benefits:

    • Enhanced Delegation Handling: Facilitates proactive contract security by reading delegation designations without relying on raw code inspection.

    • Compatibility with Managed Proxy Contracts: Prevents issues in proxy contracts that may arise from delegating to non-EOF code.

  • Key Components:

    • New EOF Instruction: The EXTCODEADDRESS instruction reads delegation designators, deducting gas for access.

    • Execution Flow: If the target address contains a delegation designator, the delegated address is returned; otherwise, the original address is pushed onto the stack.

    • Gas Consumption: Deducts GAS_WARM_ACCESS for warm access and GAS_COLD_ACCOUNT_ACCESS for cold access when loading code.

EIP-7881: Increase Gas Utilization Target

Proposes increasing the gas utilization target from 50% to 75% to boost network throughput without increasing DoS attack risks.

  • Purpose: Adjusts the gas utilization target to 75% from the current 50% in order to close the gap between average and worst-case computational loads, improving network efficiency and scalability.

  • Key Benefits:

    • Improved Throughput: Increases average network throughput by adjusting the gas utilization target to 75%.

    • DoS Attack Mitigation: The change enhances safety against DoS attacks by maintaining the worst-case load without increasing it.

    • Efficient Resource Use: Reduces the need for overprovisioning resources, aligning the average load more closely with the worst-case load.

  • Key Components:

    • Updated Gas Target: The gas target is changed from 50% to 75% of the block's gas limit.

    • Modified Base Fee Update Rule: The formula is updated to ensure that base fee changes remain within a range of [-12.5%, +12.5%] to maintain stable network dynamics.

    • Piecewise Slope Modification: Adjusts the slope of gas utilization for better alignment with the target, ensuring effective utilization while preventing overloading.

Other EIPs and ERCs:

Upcoming EIP Events

Portal Implementers Call #45

EOF Implementers Call #67

Consensus-layer Call 151

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading EIP Fun! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #84: Max Blob Limits, DeFi Solvency, Wallet Signing API]]>https://eipfun.substack.com/p/eip-fun-weekly-84-max-blob-limitshttps://eipfun.substack.com/p/eip-fun-weekly-84-max-blob-limitsMon, 10 Feb 2025 06:25:15 GMT

Welcome to read the 84th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Ethereum All Core Developers Consensus Call #150

  • Pectra Upgrade

    • Timeline and Buffer Period: A 30-day buffer between the last public testnet upgrade and the mainnet upgrade, with the earliest estimated mainnet activation date is April 8, 2025.

    • Pectra Devnet 6 Progress: Devnet launched smoothly on February 5, 2025, with minor Lighthouse client issues.

    • Fork Scheduling: Preferred timeline: testnet releases by February 13, mainnet upgrade by April 8.

    • Pectra Retrospective: Devs propose freezing Fusaka’s scope to PeerDAS and EOF, deferring other EIPs.

    • Pectra Bug Bounty Attackathon: EF to host a $2m bug bounty hackathon for Pectra security research.

  • Other Information

    • PeerDAS Testing and Discussions: PeerDAS testing is ongoing, with discussions about shifting KZG proof work to transaction senders for scalability.

    • Validator Hardware and Bandwidth: The max blobs flag could affect validator hardware and L2 rollup costs, with solutions discussed for home staker participation.

    • Additional Considerations: EIP reviews for Fusaka continue, with focus on optimizing blob handling and the Engine API for scaling.

Weekly EIP & ERC Highlights

EIP-7872: Max Blob Flag for Local Builders

Introduces a flag to allow block builders to set a maximum number of blobs they can include in a block.

  • Purpose: Adds a configurable flag for local block builders to limit the maximum number of blobs they will include in a block, preventing overload due to low bandwidth.

  • Key Benefits:

    • Improved Bandwidth Management: Allows builders with low bandwidth to control the number of blobs they add to a block.

    • Customizable Limits: Enables builders to set a maximum blob count based on their local configuration, preventing inclusion of too many blobs.

  • Key Components:

    • Block Builder Configuration: A parameter USER_CONFIGURED_MAX_BLOBS_PER_BLOCK will be added for configuring the maximum blobs.

    • Blob Count Determination: The actual number of blobs included in a block is determined by the minimum of MAX_BLOB_GAS_PER_BLOCK and USER_CONFIGURED_MAX_BLOBS_PER_BLOCK, with a default of one if the result is zero.

EIP-7874: DeFi Protocol Solvency Proof Mechanism

Provides a standard interface for DeFi protocols to verify and report solvency via smart contracts, ensuring real-time financial transparency.

  • Purpose: Enables DeFi protocols to report their solvency status by tracking assets, liabilities, and solvency ratios, allowing users to verify financial health in real time.

  • Key Benefits:

    • Real-Time Solvency Verification: Users can instantly verify solvency.

    • Standardized Reporting: Solvency data is consistently reported across protocols.

    • Risk Alerts: Stakeholders are notified if solvency thresholds are breached.

    • Historical Data: Access to historical solvency data for audits.

  • Key Components:

    • Asset & Liability Tracking: Protocol assets and liabilities are tracked and updated in real time.

    • Solvency Metrics: Provides solvency ratio and health factor calculations.

    • Risk Alerts: Emitted when solvency is at risk.

    • History Tracking: Stores historical solvency data for transparency.

ERC-7871: Wallet Signing API

Introduces a new JSON-RPC method wallet_sign for requesting wallet signatures, supporting multiple EIP-191 data versions and future compatibility.

  • Purpose: Simplifies wallet and developer tool integration by consolidating signature requests under a single method, while supporting new signed data versions without adding new methods.

  • Key Benefits:

    • Unified Signature Requests: Consolidates multiple signature requests into one JSON-RPC method.

    • Future-Proof: Allows for easy extension to new EIP-191 signed data versions.

    • Capabilities Support: Introduces wallet capabilities, enabling apps to query supported features.

  • Key Components:

    • wallet_sign Method: Requests a signature over EIP-191 signed_data with an optional address parameter for targeting a specific wallet address.

    • Capabilities: Allows apps to communicate with wallets about supported features via the capabilities field.

Other EIPs and ERCs:

  • EIP-7873: EOF - TXCREATE and InitcodeTransaction type

Upcoming EIP Events

RPC Standards Call #1

EOF Implementers Call #67

  • Date & Time: 2025/02/19 , 15:00 UTC

  • For more details about the meeting agenda, you can visit here.

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading EIP Fun! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #83: Flow Control Wallet Call Capability, Decentralised User Profiles]]>https://eipfun.substack.com/p/eip-fun-weekly-83-flow-control-wallethttps://eipfun.substack.com/p/eip-fun-weekly-83-flow-control-walletMon, 03 Feb 2025 08:39:08 GMT

Welcome to read the 83th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Ethereum All Core Developers Execution Call #204

  • Pectra Upgrade

    • Devnet 5: New consensus bug found in Nethermind but won't block Devnet 6 launch.

    • Devnet 6: Hive release ready; system contract addresses to follow EIP patterns.

    • Testnet Fork Slots: Developers to finalize Holesky and Sepolia upgrade slots after Devnet 6 launch.

    • Timeline: Devnet 6 launches Feb 3, Holesky upgrade Feb 19, mainnet upgrade mid-March.

    • Audits: Pectra system contracts audited by four security firms with reports on GitHub.

  • Other Information

    • Geth Bug: Affects peer-to-peer layer; update to Geth 1.14+ immediately.

    • Fusaka Planning: EOF and PeerDAS will be prioritized; other EIPs under review.

    • Upgrade Process: Focus on staging EIPs across devnets to avoid scope creep.

    • ACD Call Bot: New bot in development to organize ACD calls and summaries.

    • RPC Standards: Breakout meeting on Feb 3 to discuss RPC standards.

Weekly EIP & ERC Highlights

EIP-7867: Flow Control Wallet Call Capability

Extends EIP-5792 to allow more control over transaction atomicity and behavior after failures.

  • Purpose: To give dApps and wallets more flexibility in handling failed or reverted transactions, optimizing for use cases like gas savings or partial batch execution.

  • Key Benefits:

    • Atomicity Control: Allows strict, loose, or none atomicity levels.

    • Failure Handling: Offers options to continue or halt after failure, improving flexibility.

    • Improved User Experience: Reduces unnecessary reverts and allows for partial success in transactions.

  • Key Components:

    • Atomicity Levels: Three options (strict, loose, none) for batch atomicity.

    • Flow Control: Per-call failure behavior (rollback, halt, continue).

    • Transaction Flexibility: Enables smoother transaction handling, especially for complex dApp interactions.

ERC-7866: Decentralised User Profiles

Introduces a standard for decentralised, interoperable user profiles using Soul Bound Tokens (SBTs) for secure, non-transferable identities.

  • Purpose: To create a unified system for decentralised user identities that works across blockchains, supports dApp-specific customisations, and ensures secure, non-transferable identity management.

  • Key Benefits:

    • Cross-Chain Use: Profiles work across multiple blockchain networks.

    • User Control: Stored on decentralised platforms like IPFS/Arweave.

    • Customisation: Unique avatars for each dApp.

    • Decentralised Identity: Enables secure verification and authentication.

  • Key Components:

    • Identifiers: Profiles are identified by username@network_slug.soul and a Decentralised Identifier (DID).

    • Metadata: Includes bio, website, social links, and avatars with visibility settings.

    • Access Control: Users can set avatar visibility (public or private) for each dApp.

Other EIPs and ERCs:

  • EIP-7870: Hardware and Bandwidth Recommendations for Validators and Full Nodes

  • ERC-7868: Verifiable Cross Rollup Links

  • ERC-7869: Social SBT

Upcoming EIP Events

Execution Layer Meeting 205

EVM Resource Pricing Breakout #2

  • Date & Time: 2024/02/12 , 16:00 UTC

  • For more details about the meeting agenda, you can visit here.

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading EIP Fun! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #82: Guidelines for Finalizing ERCs, Pectra Upgrade Timeline Confirmed]]>https://eipfun.substack.com/p/eip-fun-weekly-82-guidelines-forhttps://eipfun.substack.com/p/eip-fun-weekly-82-guidelines-forMon, 27 Jan 2025 04:22:12 GMT

Welcome to read the 82th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Ethereum All Core Developers Consensus Call #149

  • Pectra Upgrade

    • Devnet 5 Bugs: Gas estimation bug caused a three-way chain split, with ongoing bug fixes from client teams.

    • Devnet 6 Launch: Developers agreed to launch Devnet 6 after addressing bugs on Devnet 5 and completing hive testing.

    • Public Testnet Timeline: Sepolia testnet upgrade on February 12, Holesky on February 19, and mainnet activation on March 11, 2025.

    • Shadow Fork: A shadow fork will be used to test Pectra by forking a live network to simulate real-world conditions.

  • Other Information

    • PeerDAS Development: PeerDAS aims to increase blob throughput by 8x, with testing ongoing but requiring more research.

    • BPO Fork Proposal: BPO forks are proposed to scale Ethereum’s blob capacity incrementally, though concerns about complexity remain.

    • Fusaka Fork Planning: Developers discussed improving Ethereum’s fork planning process in preparation for the Fusaka upgrade.

    • Pectra Testing Call: A testing call on January 27, 2025, will align teams ahead of upcoming deadlines, with less than 100 days left to remove pre-Merge history.

Weekly EIP & ERC Highlights

EIP-7865: Guidelines for Finalizing ERCs

Provides guidelines to help ERC authors create clearer, more testable standards that are easier to adopt and implement, with steps to gather community feedback.

  • Purpose: Offers practical advice for finalizing ERCs, focusing on user stories, trade-offs, and conformance to ensure smoother adoption in wallets, smart contracts, and decentralized apps.

  • Key Benefits:

    • Better Adoption: Clearer, more practical ERCs are more likely to be implemented.

    • Improved Feedback: Encourages authors to revise with real-world challenges in mind.

    • Clearer Specifications: Defines specific behaviors, failure cases, and conformance, improving clarity for implementers.

    • Conformance: Establishes clear expectations for how different roles interact with the ERC.

  • Key Components:

    • User Stories: Ensure clear, detailed use cases in the "Motivation" section.

    • Trade-offs: Be transparent about the pros and cons of the ERC.

    • Backwards Compatibility: Consider existing solutions and maintain compatibility where possible.

    • Conformance Definitions: Define expected behaviors and how different participants should conform.

Upcoming EIP Events

RPC Standards Call #0

PeerDAS Breakout Room #16

Consensus-layer Call 150

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading EIP Fun! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #81: Block-level Warming, Delayed State Root, ERC-721 Verifiable Credentials]]>https://eipfun.substack.com/p/eip-fun-weekly-81-block-level-warminghttps://eipfun.substack.com/p/eip-fun-weekly-81-block-level-warmingMon, 20 Jan 2025 07:40:09 GMT

Welcome to read the 81th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Ethereum All Core Developers Consensus Call #146

  • Pectra Upgrade

    • Pectra Devnet 5 was launched, with gas estimation issues being observed.

    • Five specifications updates were discussed, some requiring further review and testing.

    • Third-party audits of Pectra system contracts showed no major issues.

    • Testnet upgrade schedule was proposed, with a mainnet launch expected in March 2025.

    • Holesky gas limit will be set to 36 million for testing.

    • Some updates will be tested on a public testnet shadow fork.

  • Additional Information

    • Geth developer expressed frustration over RPC standardization feedback and further discussions are planned.

    • The minimum node hardware and bandwidth requirements for validation and full nodes need clarification.

    • EIP Editors Workshop will provide an overview of the EIP editing process.

Weekly EIP & ERC Highlights

EIP-7863: Block-level Warming

Introduces block-level address and storage key warming to maintain warm status throughout a block, improving gas efficiency by reducing redundant warming costs.

  • Purpose: Extends slot warming from the transaction level to the block level, aligning gas costs with actual computational overhead and improving network throughput.

  • Key Benefits:

    • Reduced Costs: Minimizes redundant slot warming within a block.

    • Improved Efficiency: Aligns gas costs with actual computation.

    • Better Throughput: Increases network throughput by optimizing gas usage.

  • Key Components:

    • Warm Slot Tracking: Accessed addresses and storage keys are tracked throughout the block.

    • Gas Optimization: Warm accesses are charged lower gas costs, reducing redundant warming.

EIP-7862: Delayed Execution Layer State Root

Proposes delaying the Execution Layer (EL) state root by one block to reduce computation overhead, lower latency, and increase throughput.

  • Purpose: Removes state root computation from the block propagation path, speeding up validation, improving throughput, and aiding real-time ZK proving.

  • Key Benefits:

    • Reduced Latency: No need for state root computation during the same slot.

    • Improved Throughput: Frees up time for higher block capacity and fewer reorg risks.

    • Simplified MEV-Boost and Builder Timing: More time for efficient block construction and fewer timing issues.

    • Accelerates Real-time ZK Proving: Delays state root computation, providing more time for proof generation.

  • Key Components:

    • Execution Payload Change:

      • Before: State root references post-state of the current block.

      • After: State root references post-state of block n-1.

    • Block Header Validation: Validation checks that the state root matches the post-state of block n-1.

    • Proactive Computation: Clients compute post-state root of block n-1 during idle time of block n to speed up verification.

ERC-7861: ERC-721 Verifiable Credential Extension

Extends ERC-721 to support verifiable credential properties, enabling NFTs to manage on-chain credentials with features like encryption, revocation, and verification.

  • Purpose: Standardizes the management of verifiable credentials within ERC-721, making it easier to store, encrypt, revoke, and verify credentials on-chain. It aims to provide a flexible solution for linking off-chain data to NFTs.

  • Key Benefits:

    • Simplifies credential management for NFTs.

    • Provides encryption and verification methods for secure data handling.

    • Supports off-chain data integration (e.g., IPFS).

    • Facilitates interoperability across third-party platforms.

  • Key Components:

    • Credential properties at the contract level (issuer, type, encryption method).

    • Credential URI for locating off-chain data.

    • Events for credential issuance and revocation.

    • Methods for encryption, verification, and revocation tracking.

Upcoming EIP Events

Execution Layer Meeting 204

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading EIP Fun! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #80: Expirable NFTs, AgentNFT Extension]]>https://eipfun.substack.com/p/eip-fun-weekly-80-expirable-nftshttps://eipfun.substack.com/p/eip-fun-weekly-80-expirable-nftsMon, 13 Jan 2025 07:47:18 GMT

Welcome to read the 80th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Ethereum All Core Developers Consensus Call #148

  • Pectra Upgrade:

    • Developers discussed the progress of Pectra testing and resolved a few issues, with plans to launch Devnet 5 soon.

    • Devnet 5 could launch within the next 1-2 weeks, with public testnet upgrades scheduled for February and mainnet activation in March.

    • No final decision was made on when to launch Devnet 6 or on the testing client release plan.

  • Additional Information:

    • ENR Fields: A proposal for new ENR fields to support IPv4 and IPv6 connections was made, which is backward compatible.

    • PeerDAS: No updates were provided on PeerDAS.

    • Validator Hardware: Kev introduced a document defining hardware requirements for Ethereum validators, open for developer review and feedback.

    • Gloas Upgrade: The seventh consensus layer upgrade was named “Gloas,” to be launched alongside the EL fork "Amsterdam," with the combined upgrade referred to as "Glamsterdam."

Weekly EIP & ERC Highlights

ERC-7858: Expirable NFTs and SBTs

Adds expiration functionality to NFTs and SBTs, enabling them to become invalid after a set period.

  • Purpose: To allow time-limited use cases for NFTs and SBTs while maintaining compatibility with existing applications.

  • Key Benefits:

    • Time-Limited Use Cases: Ideal for membership, access, loyalty programs, etc.

    • Backward Compatibility: Ensures existing systems remain functional.

    • Flexible Expiry: Expiration can be set by block height or timestamp.

  • Key Components:

    • Expiry Type: BLOCK_BASED or TIME_BASED.

    • Validity Check: isTokenValid checks if a token has expired.

    • Minting: Tokens are minted with expiration windows (startTime and endTime).

ERC-7859: AgentNFT Extension for ERC-721

Extends ERC-721 to enable NFTs to represent AI agents and store related data like prompts and agent addresses.

  • Purpose: To provide a standardized way for NFTs to serve as on-chain identities for AI-powered entities, including AI agents, prompts, and settings.

  • Key Benefits:

    • On-Chain Identity: Provides AI agents with decentralized identities on the blockchain.

    • Transferable: AgentNFTs are liquid assets, allowing ownership transfer while retaining agent and prompt data.

    • Privacy and Verifiability: Prompts and data can be encrypted for privacy but remain verifiable for authenticity.

    • Composable: Facilitates interactions with smart contracts by associating AI agents with NFTs.

  • Key Components:

    • agent(tokenId): Returns the AI agent's address.

    • updateAgent(tokenId, newAgent): Updates the agent's address.

    • prompt(tokenId): Returns the AI agent's associated prompt.

    • updatePrompt(tokenId, newPrompt): Updates the agent's prompt.

Upcoming EIP Events

PeerDAS Breakout Room #15

EOF Implementers Call #65

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading EIP Fun! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #79: Enhancing EVM Performance, Multi-Chain Payments, AI Agent NFTs]]>https://eipfun.substack.com/p/eip-fun-weekly-79-enhancing-evm-performancehttps://eipfun.substack.com/p/eip-fun-weekly-79-enhancing-evm-performanceMon, 06 Jan 2025 08:57:00 GMT

Welcome to read the 79th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Weekly EIP & ERC Highlights

EIP-7852: Opcodes Per Second (OpPS)

Introduces OpPS as an additional metric to assess EVM performance by measuring the number of opcodes executed per second.

  • Purpose: Enhances performance evaluation by providing a more granular view of EVM operations, complementing existing metrics like TPS and GPS.

  • Key Benefits:

    • Improved Efficiency Analysis: Provides a finer view of smart contract performance beyond TPS and GPS.

    • Granular Workload Insights: Highlights computational complexity through opcode execution rather than just gas usage or transaction count.

  • Key Components:

    • TPS: Measures transaction throughput.

    • GPS: Measures gas consumption.

    • OpPS: Measures the number of opcodes executed per second, offering a deeper look into operational complexity.

ERC-7856: Chain-Specific Payment Requests

Introduces a URI scheme for chain-specific payment requests, allowing users to specify transactions across multiple blockchains with clarity.

  • Purpose: To standardize and simplify payment requests in a multi-chain environment.

  • Key Benefits:

    • Multi-Chain Clarity: Eliminates ambiguity in payment requests across different chains, improving user experience.

    • Simple Integration: Allows seamless peer-to-peer and vendor transactions with clear specifications for amount, token, and chain.

  • Key Components:

    • URI Format: cspr://<recipient>/<amount>/<token-address>?on-success=<success-callback-url>&on-error=<error-callback-url>

    • Recipient: Specified using a CAIP-10 account identifier.

    • Amount: The amount of tokens to be sent.

    • Token Address: Contract address of the token or native for native chain currency.

    • Callback URLs: Optional success and error callback URLs for transaction redirection.

ERC-7844: NFT Interface for AI Agents

Proposes an NFT interface for AI agents, enabling secure management and transfer of private metadata with verifiable data ownership.

  • Purpose: To create a standardized NFT interface for securely transferring AI agent metadata with verifiable ownership and privacy.

  • Key Benefits:

    • Secure Metadata Handling: Ensures AI agent metadata, like models and memories, remains private and verifiable during transfers.

    • Decentralized Ownership: Facilitates decentralized management of AI agents by securing agent data and proving ownership.

    • Privacy-Preserving Verification: Implements verification mechanisms (TEE, ZKP) for secure data transfer and privacy protection.

  • Key Components:

    • Main NFT Interface: Defines minting, transferring, and cloning operations for agent NFTs.

    • Metadata Interface: Manages metadata for AI agent NFTs, including updates and storage configuration.

    • Data Verification Interface: Verifies ownership and transfer validity of the encrypted agent data using on-chain and off-chain verification mechanisms.

Upcoming EIP Events

Execution Layer Meeting 203

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading EIP Fun! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #78: On-Chain Upgrade Signaling, Key Deactivation Reactivation, Tokens with Built-in AMM]]>https://eipfun.substack.com/p/eip-fun-weekly-78-on-chain-upgradehttps://eipfun.substack.com/p/eip-fun-weekly-78-on-chain-upgradeMon, 30 Dec 2024 05:39:11 GMT

Welcome to read the 78th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Weekly EIP & ERC Highlights

EIP-7848: On-Chain Upgrade Signaling

Enables network participants to signal readiness for protocol upgrades directly on-chain, transitioning Ethereum upgrades to community-driven decision-making.

  • Purpose: Facilitates decentralized governance by allowing validators to vote for upgrades through mined blocks.

  • Key Benefits:

    • Decentralized Governance: Shifts upgrade decisions from centralized announcements to participant consensus.

    • Regulatory Alignment: Reinforces Ethereum's decentralized nature, addressing potential legal concerns.

    • Community Trust: Empowers the network to decide upgrades collectively, enhancing transparency.

  • Key Components:

    • Voting Mechanism: Validators signal support by embedding an upgrade-specific hash fragment in the extraData field of blocks.

    • Voting Parameters:

      • Window: Defined block range for voting.

      • Threshold: Minimum percentage (e.g., 90%) of approval required for activation.

    • Upgrade Activation: New rules apply starting from the block after the voting window if the threshold is met.

EIP-7851: EOA Private Key Deactivation/Reactivate

Introduces a precompiled contract for EOAs to securely deactivate or reactivate their private keys using delegated code, enabling migration to smart contract wallets while retaining recovery options.

  • Purpose: Facilitates a transition to smart contract wallets with enhanced control and security while supporting native account abstraction and recovery mechanisms.

  • Key Benefits:

    • Flexible Key Management: Allows deactivation and reactivation of EOA private keys without modifying account states or storage fields.

    • Enhanced Security: Supports secure reactivation through mechanisms like social recovery, reducing risks of key compromise.

    • Migration to Account Abstraction: Eases the transition from EOAs to smart contract wallets while maintaining compatibility with existing accounts.

  • Key Components:

    • Precompiled Contract: A contract toggles private key activation by appending or removing a byte in delegated code.

    • Delegated Code States:

      • Active: 0xef0100 || address (private key active).

      • Deactivated: 0xef0100 || address || 0x00 (private key inactive).

    • Transaction Validation: Rejects transactions and authorizations from deactivated private keys.

ERC-7850: Token with Built-in AMM

Integrates Automated Market Maker (AMM) functionality into tokens, enabling gas-efficient swaps, reducing MEV risks, and eliminating reliance on external platforms like Uniswap.

  • Purpose: Simplifies Ethereum trading with native liquidity management, reducing costs and improving security.

  • Key Benefits:

    • Lower Costs: Eliminates external interactions, reducing gas fees.

    • MEV Protection: Minimizes frontrunning and sandwich attacks.

    • Simplified UX: Removes token approval steps and reduces complexity.

  • Key Components:

    • Liquidity Management: Functions to add/remove liquidity directly in the token contract.

    • Swapping: Built-in methods for token-to-ETH and ETH-to-token swaps with slippage protection.

    • Fee Control: Configurable trading fees with options to disable for promotions.

    • Reserve Access: Provides real-time token and ETH reserve data for swap calculations.

Upcoming EIP Events

EOF Implementers Call #64

Consensus-layer Call 148

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading EIP Fun! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #77: Slot Precompiles, Minimal Orchestrator RPC, Social Media NFTs]]>https://eipfun.substack.com/p/eip-fun-weekly-77-slot-precompileshttps://eipfun.substack.com/p/eip-fun-weekly-77-slot-precompilesMon, 23 Dec 2024 06:18:55 GMT

Welcome to read the 77th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Ethereum All Core Developers Execution Call #202

  • Pectra Upgrade

    • Pectra Devnet 5 Updates:

      • EIP 7742 has been replaced by EIP 7840, simplifying the implementation of blob capacity adjustments.

      • The chain ID in EIP 7702 has been changed to uint256 type to improve compatibility.

      • Updates to EIP 2537 include reducing the gas costs for BLS operations and removing redundant multiplication operations.

      • EIP 2935 has been adjusted to align with the Pectra system contract structure.

    • Pectra Testing Progress: The Mekong testnet is still running, and developers plan to launch Pectra Devnet 5 by late December or early January.

    • EIP 4444 (History Data Cleanup): The process of gradually removing pre-merge history data has begun, with alternative access options provided through the Portal Network and other means.

  • Additional Information:

    • EIP 7808: A proposal to reserve transaction type address ranges from 0x40 to 0x7f for rollup teams, avoiding conflicts with Ethereum Layer 1.

Weekly EIP & ERC Highlights

EIP-7843: SLOT Precompile

Introduces a precompile to return the current block's slot number.

  • Purpose: Simplifies access to the current slot number without requiring hardcoding of chain slot length, aiding in encrypted mempool support and improving security for transaction validity in the correct slot.

  • Key Benefits:

    • Encrypted Mempools: Supports secure validation of transactions in encrypted mempools, ensuring inclusion in the correct slot.

    • Simplified Slot Access: Provides an easy way to retrieve the current slot number without needing smart contract updates for future slot length changes.

  • Key Components:

    • Precompile Address: A new precompile contract at address TBD returns the current slot number as an 8-byte ulong.

    • Gas Cost: Fixed fee of 2 gas.

ERC-7845: Minimal Orchestrator RPC

Standardizes the request format for wallets or systems to interact with an Orchestrator, promoting easy decentralized app development and system interoperability.

  • Purpose: Provides a consistent data model for requests from Ethereum wallet managers to Orchestrators, supporting AI, XR, and decentralized app development. Prioritizes chain abstraction for flexibility across different chains.

  • Key Benefits:

    • Improved Interoperability: Standardized format for easier wallet and Orchestrator integration.

    • Simplified Wallet Integration: Developers can interact with the Orchestrator without needing deep blockchain knowledge.

    • Future-Proof: Room for future upgrades and features.

  • Key Components:

    • Request Structure: Wallets send a JSON-RPC request with Problem objects, containing Action details.

    • Action & Solution Model: Actions define tasks like transfer, swap, or call. Orchestrator responds with Solutions containing Transactions.

    • Chain Abstraction: Ensures flexibility in asset targeting across different blockchains.

    • Gas & Asset Management: Wallets manage gas estimation and execution.

ERC-7847: Social Media NFTs

Establishes a standard for NFTs representing decentralized social media posts, compatible with Nostr, supporting original posts, replies, reposts, quotes, and media attachments.

  • Purpose: Integrates Nostr’s decentralized social media with NFT standards (ERC-721/1155), enabling long-lasting, censorship-resistant content. Supports cross-chain publishing and editing of posts.

  • Key Benefits:

    • Decentralized: Author signs posts, allowing third-party publishing/editing.

    • Censorship-Resistant: Posts are stored on the blockchain, immune to censorship.

    • Interoperability: Works with Nostr and other decentralized platforms.

    • Ownership: Users fully own their content.

  • Key Features:

    • Post Types: Original posts, replies, reposts, and quotes, identified via metadata.

    • Editability: Supports editing posts through editPost and EditPostEvent.

    • Media & Links: Attach media and external references via tags.

    • Standard Metadata: Uses common NFT standards for easy integration with apps.

Other EIPs and ERCs:

  • ERC7842: State channel data types & interfaces

  • ERC7844: Consolidated dynamic storage

  • ERC7846: Wallet connection API

Upcoming EIP Events

EVMMAX Implementers Call 2

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading EIP Fun! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #76: Unified Network Configuration, Dynamic Blob Schedules, Cross-Chain Messaging]]>https://eipfun.substack.com/p/eip-fun-weekly-76-unified-networkhttps://eipfun.substack.com/p/eip-fun-weekly-76-unified-networkMon, 16 Dec 2024 04:51:23 GMT

Welcome to read the 76th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Ethereum All Core Developers Consensus Call #147

  • Pectra Upgrade

    • Pectra Devnet 5 Key updates:

      • Gossip Limit Adjustment: Proposal to increase the gossip limit from 10 MiB to 15 MiB to support a larger block gas limit. Concerns about potential consensus failures have led to a decision to maintain the current 10 MiB limit for now.

      • EIP 7742 Removal: EIP 7742, which uncouples blob count between CL and EL, was removed due to implementation complexity. Blob count will be adjusted through the genesis configuration instead.

      • Timeline: Devnet 5 may launch between Christmas and New Year's if enough clients pass Hive tests.

      • PeerDAS Renaming: EIP 7549 (PeerDAS) is renamed to "Fulu," intended for the next CL upgrade after Pectra.

  • Additional Information

    • Mekong: Stable with no issues; the block gas limit was recently increased from 30m to 36m gas.

    • EIP 7762: Excluded from Pectra based on feedback from rollup developers.

    • EIP 2537: BLS precompiles repricing is near completion, with final benchmarking expected next week.

Weekly EIP & ERC Highlights

EIP-7839: Unified Network Configuration

Streamlines configuration management by allowing the Execution Layer (EL) to fetch network parameters directly from the Consensus Layer (CL).

  • Purpose: Simplifies configuration management, ensuring consistency between the Execution and Consensus layers by making the CL the authoritative source of network parameters, reducing duplication and human error.

  • Key Benefits:

    • Eliminates Duplication: Removes the need to configure parameters separately for both the EL and CL.

    • Automatic Synchronization: Ensures parameters are always in sync between layers, reducing manual errors and maintenance overhead.

    • Simplifies Network Upgrades: Having a single source of truth for parameters simplifies upgrades and fork transitions.

    • Error Reduction: Reduces operator mistakes caused by misconfiguration.

  • Key Components:

    • New API: CL exposes an API endpoint to return unified configuration parameters, such as chain ID, fork epochs, and gas limits.

    • EL Startup Behavior: EL fetches configuration from CL at startup with retry logic to ensure availability. It does not start processing blocks until valid configuration is received.

    • Parameter Derivation: Some parameters (e.g., gas limits) are derived from values returned by the CL API, ensuring consistency.

EIP-7840: Add Blob Schedule to EL Config Files

Introduces a new configuration object in client files to specify per-fork blob counts, allowing dynamic adjustments to target and max blobs per block.

  • Purpose: Provides a way to configure the target and max blob counts per block for each fork, ensuring that execution clients can adjust these values without requiring complex handshakes over the engine API.

  • Key Benefits:

    • Dynamic Adjustments: Allows flexibility in adjusting blob counts (target and max) per block for each fork.

    • Simplified Configuration: Eliminates the need for complex communication via the engine API, streamlining configuration management.

    • Improved Protocol Interaction: Execution clients can use these values for core protocol activities like RPC methods, ensuring better functionality without overburdening the network.

  • Key Components:

    • Blob Schedule Configuration: A new object, blobSchedule, is added to the client configuration files with per-fork target and max blob counts.

    • Fork Transition Handling: If no explicit configuration is provided for the current fork, the values from the last specified fork are used. If no prior values exist, both target and max are set to zero.

ERC-7841: Cross-chain Message Format and Mailbox

Defines a standardized mailbox API and message format to simplify cross-chain communication between Layer 2 solutions, improving interoperability and developer experience.

  • Purpose: To standardize data exchange between L2 chains, addressing the fragmentation of existing communication protocols, allowing developers to build cross-chain applications without dealing with different formats, settlement mechanisms, or protocols.

  • Key Benefits:

    • Unified Developer Experience: One interface for cross-chain messaging, regardless of chain type or protocol.

    • Modularity: Chains can choose their own coordination and settlement protocols while using the same messaging system.

    • Shared Infrastructure: Reuse of existing tools and contracts for multiple use cases, simplifying development.

  • Key Components:

    • Mailbox API: Two contracts (one for synchronous, one for asynchronous messaging) to send/receive messages.

    • Message Format: A standardized structure for messages with metadata (source, destination, session ID) and payload.

    • Coordination Protocol: Mechanism for relaying messages between chains, either synchronously or asynchronously.

Other EIPs and ERCs:

Upcoming EIP Events

*Christmas holidays

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading EIP Fun! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #75: Self-Scheduling Contracts, Multi-Chain Addressing, Cross-Chain Intents]]>https://eipfun.substack.com/p/eip-fun-weekly-75-self-schedulinghttps://eipfun.substack.com/p/eip-fun-weekly-75-self-schedulingMon, 09 Dec 2024 08:33:26 GMT


Welcome to read the 75th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Ethereum All Core Developers Execution Call #201

  • Pectra Upgrade

    • EIP 7623 (Increase to calldata cost) has been included in the Pectra upgrade.

    • EIP 7762 (Increase to minimum blob base fee) has been excluded from the Pectra upgrade due to insufficient consensus.

    • Coordination of EIP 7639 (Cease Serving History Before the Paris Upgrade) and EIP 4803 (Limit Transaction Gas to a Reasonable Maximum) discussed for inclusion.

    • Three open pull requests for Devnet 5 specifications (EIP 7742, EIP 7691, and changes for EIP 7742) need urgent review to finalize Devnet 5.

  • Additional Information

    • Mekong Testnet Update: Following major network disruptions on the Mekong testnet, the Grandine team implemented several fixes, restoring validator participation to 97%. However, some issues persist in the Nimbus and EthereumJS clients that need to be addressed.

    • ACD Holiday Schedule:

      • Monday, December 23: Testing call as planned.

      • Thursday, December 26 and Monday, December 30: ACDE call and testing call canceled.

      • Thursday, January 2: ACDC call replaced by a Pectra testing call.

Weekly EIP & ERC Highlights

EIP-7833: Scheduled Function Calls

Introduces the OFFERCALL opcode, allowing smart contracts to self-schedule function calls by offering ETH to block producers.

  • Purpose: Aims to improve smart contract execution by allowing contracts to schedule function calls and offer ETH to block producers, prioritizing execution and reducing MEV manipulation.

  • Key Benefits:

    • Timely Execution: Ensures functions are executed promptly, even in the face of network delays or malicious block producers.

    • MEV Mitigation: Reduces the risk of market manipulation by incentivizing block producers to execute scheduled calls that neutralize such attacks.

    • Self-Scheduling Contracts: Contracts can autonomously schedule their function calls, providing more predictable behavior for critical contract operations.

  • Key Components:

    • OFFERCALL Opcode: A new opcode that allows contracts to offer ETH to block producers in exchange for executing a function in the next block.

    • Offer Ranking: ETH offers are aggregated and ranked by the node, with only the top N offers being executed.

    • Failure & Revival: If an offer fails (due to insufficient ETH or a low ranking), the scheduled call is deactivated and can only be reactivated by the contract owner manually increasing the offer.

ERC-7831: Multi-Chain Addressing

Proposes a unified address format combining account and chain information for improved multi-chain interoperability.

  • Purpose: Aims to make Ethereum's addressing system compatible with multi-chain environments, ensuring addresses are clear and human-readable while leveraging ENS for chain name resolution.

  • Key Benefits:

    • Prevent Misrouting: Reduces errors caused by sending funds to addresses on incorrect chains.

    • Improved Readability: Uses human-readable chain names instead of numerical chain identifiers.

    • Decentralized Resolution: Relies on ENS for mapping chain names to identifiers, avoiding centralized dependency.

  • Key Components:

    • Address Format: Combines account and chain information, with optional root chain identification.

    • ENS Integration: Resolves chain names and mappings through ENS on the root chain.

    • Compatibility: Supports both hexadecimal and ENS-style account representations.

ERC-7835: wallet_transmitCrossChainIntents Method

Proposes a standardized RPC method for wallets to manage cross-chain intents, improving multi-chain interoperability and simplifying user experience.

  • Purpose: Aims to enable seamless cross-chain interactions by providing a unified interface for wallets to parse and transmit cross-chain intentions, reducing complexity for users and enhancing multi-chain interoperability.

  • Key Benefits:

    • Simplified User Experience: Eliminates the need for users to manually switch networks or use third-party tools for cross-chain transactions.

    • Cross-Chain Interoperability: Facilitates communication between EVM-compatible chains (e.g., Ethereum, Polygon, Optimism).

    • Standardization: Aligns with EIP-7683, ensuring consistent cross-chain support across wallets and protocols.

  • Key Components:

    • RPC Method: wallet_transmitCrossChainIntents, which accepts parameters such as origin and destination chain IDs, serialized intent data, and optional settings.

    • Cross-Chain Intent Data: Serialized transaction details complying with EIP-7683, including token info, amounts, and destination chains.

    • Broadcast and Tracking: Allows wallets to broadcast transactions and track their progress on multiple chains.

    • Backward Compatibility: Introduces a new, optional RPC method that does not affect existing wallet functionality.

Other EIPs and ERCs:

  • EIP7830: Contract size limit increase for EOF

  • EIP7834: Separate metadata section for EOF

  • ERC7831: Multi-chain addressing

  • ERC7836: Wallet call preparation API

Upcoming EIP Events

EOF Implementers Call #63

Execution Layer Meeting 202

FOCIL Break-Out Room #1210

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading EIP Fun! Subscribe for free to receive new posts and support my work.

]]><![CDATA[EIP Fun Weekly #74: Gas Limits, Address Formats, Data Asset NFTs]]>https://eipfun.substack.com/p/eip-fun-weekly-74-gas-limits-addresshttps://eipfun.substack.com/p/eip-fun-weekly-74-gas-limits-addressMon, 02 Dec 2024 07:39:16 GMT

Welcome to read the 74th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community last week.

Meeting Updates

Ethereum All Core Developers Consensus Call #146

  • Pectra Upgrade

    • Mekong Testnet: A bug in the Mekong testnet caused delays and inconsistencies in deposit processing. The consensus layer client team is urgently fixing the issue to ensure the testnet mirrors the mainnet. This fix is crucial for the reliability of fund verification and deposit transmission.

    • Blobs: The target number of blobs per block has been increased to 6, with a maximum of 9. The update ratio will be adjusted through EIP-7691. This proposal aims to improve the network’s throughput and capacity.

    • EIP-7623 (Increase calldata cost): A decision on whether to include EIP-7623, which proposes increasing calldata costs to limit inefficient data usage, will be made at next week’s execution layer meeting (ACDE).

    • Pectra-devnet-5 Specifications: agreed to exclude empty requests from the Engine API, following EIP-7685 specifications to optimize request handling. The meeting also confirmed a merge processing fix in EIP-7251, which improves block generation efficiency and synchronization stability.

  • Additional Information

    • Blob Fee Market: This is an ongoing discussion on how to manage and incentivize blob usage to prevent excessive network resource consumption.

    • Fork-choice Enforced Inclusion Lists (FOCIL): This is a long-term discussion about how to enforce inclusion lists for data at the consensus layer, ensuring only valid and efficient transactions are included in blocks.

Weekly EIP & ERC Highlights

EIP-7825: Transaction gas limit cap

New cap to limit the maximum gas used by a transaction to 30 million gas.

  • Purpose: Introduces a protocol-level cap on the maximum gas used by a transaction to 30 million, improving network stability, mitigating DoS attacks, and providing more predictability in transaction processing.

  • Key Benefits:

    • DoS Attack Mitigation: Reduces the risk of a single transaction consuming excessive gas and destabilizing the network.

    • Fairer Gas Allocation: Ensures more equitable distribution of gas across transactions within a block.

    • Improved Network Stability: Limits extreme block validation times, making block verification more predictable and synchronized across nodes.

  • Key Components:

    • Gas Cap: A hard limit of 30 million gas per transaction, irrespective of the block gas limit.

    • Transaction Validation: Transactions with a gas limit higher than 30 million will be rejected during transaction pool validation.

    • Block Validation: Blocks containing any transaction exceeding 30 million gas will be deemed invalid and rejected.

    • EVM Adjustment: The GAS_LIMIT for transactions is capped at 30 million in client implementations.

ERC-7828: Chain-specific addresses using ENS

New unified chain-specific address format for specifying both the account and the chain it operates on.

  • Purpose: Proposes a unified format for chain-specific addresses that include both the account and the chain it operates on, making it easier and safer to interact with multiple chains.

  • Key Benefits:

    • Clearer Addresses: Specifies both the account and the chain, reducing the risk of sending funds to the wrong chain.

    • Human-Readable: Uses human-readable chain names (e.g., eth, sepolia) and ENS for easy resolution.

    • ENS Integration: Resolves both account addresses and chain identifiers using ENS.

  • Key Components:

    • Address Format: <user>@<chain>, where:

      • user: An address or ENS subdomain (e.g., user.app.eth).

      • chain: Chain ID, chain name (e.g., eth), or ENS domain (e.g., rollup.eth).

    • Resolution: Both address and chain are resolved separately, with ENS supporting L2 as well.

    • Checksum: Mandatory for both address and chain portions.

ERC-7829: Data Asset NFT

Enhances Data Asset NFTs by ensuring data validity and availability through storage proofs and extended metadata.

  • Purpose: Introduces Data Asset NFTs to ensure NFT integrity through storage proofs and metadata validation for data assets.

  • Key Benefits:

    • Storage Proofs: Validates metadata correctness, including expiration and storage details.

    • Access Control: Adds a "Reader" role for multiple users to access data without changing ownership.

    • Extended Metadata: Adds commitment, size, expiration, and uploader’s address to NFT metadata for better transparency.

  • Key Components:

    • Storage Metadata: Includes commitment, size, expire time, and uploader’s address, stored on-chain.

    • Permission Metadata: Defines ownership and reader access, stored on-chain.

    • Data Content: Off-chain data stored in trusted storage nodes.

    • Storage Proof: Uses KZG polynomial commitment technology to ensure data availability and metadata accuracy.

Other EIPs and ERCs:

  • ERC7826: Quantum supremacy bounty

  • ERC7827: JSON contract with value version control

Upcoming EIP Events

PeerDAS Breakout Room #13

Stay Up to Date

EIP Fun, co-initiated by LXDAO and PlanckerDAO and operated by ETHPanda, has been launched to act as the 'layer 2' of the EIP ecosystem, simplifying and accelerating EIP adoption.

Follow us: Twitter | Telegram

Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.

Thanks for reading EIP Fun! Subscribe for free to receive new posts and support my work.

]]>