L1 Weekly#2025.01.03

The L1 Weekly Report is published every Friday, focusing on the development of Layer 1 blockchains. If you have any suggestions, feel free to contact [email protected].

Bitcoin

• Analyzing Mining Pool Behavior to Address Bitcoin Core’s Double Coinbase Reservation Issue
  • Bitcoin Core has a double coinbase reservation issue. Current practice differs from theory, with blocks generated at 3,992,000 WU instead of 3,996,000 WU. Fixing it may cause some miners to generate invalid blocks. Analysis of 107,313 blocks from 2022-2024 shows most pools adhere to default, but Ocean.xyz and an unknown pool have larger coinbase weights. F2Pool optimally uses block weight. Fixing the bug will enhance fairness and clarify the codebase.
• Contract-level Relative Timelocks
  • ln-symmetry in Eltoo has an issue where relative timelock resets on update confirmation, locking funds and extending HTLC expiry. The proposed solution is a Contract-level Relative Timelock (CLRT) with a dedicated utxo. It changes the transaction sequence. The CLRT output commits to a relative delay and must be spent concurrently with the state output. Proofs are needed, and there are challenges with and without TXID stability. The Chia version is described, and John Law’s construction with two relative timelocks is mentioned.

Ethereum

• Ahead-of-Time Block Auctions To Enable Execution Preconfirmations
  • The article discusses execution preconfirmations in block auctions, proposing two approaches to address issues like adversarial flow and pricing. It details a pricer system where pricers bid to underwrite futures risk, and a design where the proposer delegates to a gateway (block builder). The gateway must predict MEV, take on futures risk, and avoid being gamed. Execution preconfirmations enable synchronous composability. The gateway can buy block building rights in advance or just in time, with JIT auctions preferred. Concerns include gateway centralization and bidding uncertainties, but preconfirmation tips may outweigh risks.
• ERC: Chain-Specific Payment Requests
  • An EIP proposes a standardized URI scheme for chain-specific payment requests. It aims to clarify multi-chain payment requests. The URI format’s components are detailed with examples. Rationale for design, alternative designs considered, related work, backwards compatibility, security considerations are covered. Copyright waived via CC0.
• ERC-7854: Verification-independent Cross-Chain Messaging
  • This ERC specifies an API for cross-chain messaging in the Ethereum ecosystem. It has three main components: Mailbox, Interchain Security Modules (ISM), and Post-Dispatch Hooks. It aims for modularity and a good developer experience. Rationale, relaying semantics, compatibility, and security are discussed.
• G-star name for Consensus Layer upgrade after Fusaka
  • A G-star name is needed for the Consensus Layer upgrade after Fusaka, likely combined with Amsterdam. Star names are used for consensus layer upgrades. Examples of recent upgrade names are given. A list of G-star names is provided, and a poll may be created in 2025 for additional names. Amsgar is liked by the author.
• ERC-7846: Wallet Connection API
  • This ERC presents a new wallet connection RPC method for extensibility. It aims to simplify connection and authentication. Specification details wallet_connect, signInWithEthereum capability. Rationale covers multiple aspects like multiple accounts, capability results. It has backwards compatibility, and considers security and privacy.
• ERC-7853: Social SBT
  • SocialSBT is an ERC-721-based non-transferable token standard with a social point system for DAO governance. It aims to prevent whale attacks and ensure fairness. It has functions for minting, deleting, voting, and querying. Rationale, backwards compatibility, test cases, and security considerations are discussed.
• EIP-7851: EOA private key deactivation/reactivation
  • This EIP proposes a precompiled contract enabling EOAs with delegated control to deactivate/reactivate private keys. It details parameters, delegated code encoding, and transaction validations. Rationale, gas cost, compatibility, and security considerations are discussed. A reference implementation and test cases are provided.