[REJECTED] Real-time access to pre-chain data RFP Mission Request

Grants 🏹
,
13

Thank you all for the rich discussion and feedback. Here is our revised Mission Request based on what we have heard from the community. We look forward to continuing the discussion:

Public Goods Infrastructure to Enhance Observability in Service of Transparency, Developer Experience, and Decentralization

S5 Intent : Intent 1: Progress towards technical decentralization
Proposing Delegate: Gonna.eth (Sponsor)
Proposal Tier: Eagle Tier
Baseline grant amount: 650k OP
Should this Foundation Mission be fulfilled by one or multiple applicants: Multiple
Submit by: To be set by Grants Council
Selection by: To be set by Grants Council
Start date: If applicable
Completion date: 12 months upon grant approval

Delegate Mission Request Summary:

This Mission Request aims to enhance the observability of the Optimism ecosystem by incentivizing the development of public goods tooling and infrastructure. This Mission Request demonstrates how improvements in observability can directly translate into real-world solutions to pressing challenges, such as clarifying the end-to-end transaction lifecycle, mitigating stuck transactions, improving gas estimation and gas prediction (including the complexities introduced by EIP4844), or enabling archival access to ephemeral datasets including type 3 blob transactions.

Specification

How will this Delegate Mission Request help accomplish the above Intent?

This Mission Request focuses on improving the observability of the Optimism ecosystem via new public goods tooling and infrastructure. As the Optimism ecosystem makes progress on its decentralization roadmap, it is desirable to ensure that all ecosystem participants have equitable access to the data layers that relate to transaction settlement. These layers are becoming increasingly complex as the base layer evolves (new EIPs) and as the Optimism ecosystem evolves into the Superchain, making it critical to address the observability challenges today and research approaches for the future.

The intent of this Mission Request is to encourage researchers, builders, and infrastructure providers to submit grant proposals which yield positive progress towards implementing sustainable long-term solutions to these observability challenges.

Real-time observability covers, but is not limited to, the following problems:

  • End-to-End Transaction Status & the Stuck Transaction Problem
    • The end-to-end L2 transaction lifecycle has many stages that developers and end-users need to know:
      • Nominal Lifecycle: Pending L2 > Sequencer Confirmed / Unsafe Block L2 > Batch Pending L1 > Published to Ethereum / Safe L1 > Finalized L1
      • Other Possible Statuses: Underpriced L2, Stuck L2, Dropped L2, Batch Underpriced L1, Batch Stuck L2, Batch Dropped L2, Batch Reorged L2
      • With the introduction of EIP4844, there may be additional gaps in the L2 transaction lifecycle, including: pending L1 normal (type 0 or type 2) transaction vs. pending L1 blob (type 3) transaction
      • And potentially additional transaction status types enabled by other upcoming Ethereum roadmap milestones
    • While some transaction status types are available, others are more difficult to ascertain or unavailable.
    • Some examples of relevant tooling and infrastructure:
      • Transaction status APIs for wallets and traders
      • Smart RPCs (for example, ones that take into account gas prices and/or user preferences)
      • Visual interfaces for transaction’s status through L1 finality
  • Gas Estimation & Prediction
    • With the increasing complexity of the transaction lifecycle via the introduction of EIP4844, there is an opportunity to incentivize a more robust and diverse landscape for real-time gas estimation. For example, an L2 transaction will have to account for EIP1559 on the L2, EIP1559 on the L1 for regular transactions, or EIP1559 for blob transactions depending on how batches are settled to the L1 – also referred to as multi-dimensional gas. There will be times when regular type 2 batch transactions are more expensive than type 3 blob transactions and vice versa. So, incentivizing the development and operation of a diverse set of gas estimation tooling will improve developer and user experience while saving end-users and protocol providers money on transaction fees.
    • As recently demonstrated by the inscription craze, network congestion can cause L2 batches to become stuck in the Ethereum public mempool, which in turn can negatively impact the L2 developer and user experience. The introduction of EIP4844 may increase both the occurrence and complexity of these situations. Net new public goods tooling, APIs, and observability will be needed to monitor both the L1 mempool and the blob mempool.
    • Comprehensive gas estimation at each layer of the stack will help reduce stuck transactions, whether at the L2 or L1.
    • Some examples of relevant tooling and infrastructure:
      • Real-time machine learning based Optimism gas prediction via API and/or visual interfaces
      • 4844 blob pricing prediction modeling
  • Archival Access to Ephemeral Datasets
    • EIP4844 introduces type 3 transactions (blobs) mainly geared towards L2 rollups as a cheaper alternative for posting their L2 batch transactions to Ethereum.
    • The actual blob data will only be accessible for 4,096 epochs (~ 18 days) on the beacon nodes (CL).
    • For the Optimism community to have historical data access for research purposes and integration with block explorers, multiple parties should be incentivized to fetch, store, and open source the blob data.
    • Some examples of relevant tooling and infrastructure:
      • The collection and maintenance of these data sets for the community - accessible as a public good via APIs
      • Visual interfaces such as dashboards, explorers, etc.

Grants issued under this Mission Request will be for the design and development of real-world production solutions as well as to fund the necessary operational infrastructure to supply the public good on an ongoing basis.

What is required to execute this Delegate Mission Request?

  • The teams participating in this Mission should have members skilled in implementing the topics referenced above.
  • Developers need extensive experience in the relevant development field. Having a history of contributing to related open-source projects is a plus.
  • Teams should have experience running infrastructure at scale in Web3.
  • The Mission aims at practical applications that enhance the usability of the Superchain. This requires a combination of theoretical understanding and hands-on technical expertise with Web3 infrastructure.
  • Deliverables are open-sourced to the public and provided as a public good.
  • It’s preferable for one entity to submit a single proposal covering multiple topics, rather than multiple proposals unnecessarily.
  • To avoid any doubt, grants issued will explicitly prohibit any form of proprietary and/or exclusive access to any data layer or data set.

How should the Token House measure progress towards this Mission?

  • Publicly accessible real-time transaction explorers for developers and users to observe transaction status.
  • Programmatic access via real-time developer APIs.
  • Improved gas estimation on Optimism.
  • Utilities for detecting, diagnosing, and repairing stuck wallets and other pain points.

How should badgeholders measure impact upon completion of this Mission?

  • Assess the extent to which the tools are being utilized and adopted within the community and target users.
  • Github key metrics such as Issues, Pull Requests, Stars, Watches, and Forks.

Have you engaged a Grant-as-a-service provider for this Mission Request?
No.

Has anyone other than the Proposing Delegate contributed to this Mission Request?
Blocknative team.

3 Likes