Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Technical Specification for Bridging EigenDA AVS Data to L3 Rollups #8

Open
5 tasks
0xsuryansh opened this issue Mar 11, 2024 · 0 comments
Open
5 tasks
Assignees

Comments

@0xsuryansh
Copy link
Member

Summary

EigenDA aims to extend support for L3 rollups such as Arbitrum Orbit by ensuring its AVS (Aggregate Verification System) data from Ethereum L1 is available across multiple Layer 2 ecosystems. This will facilitate the development of EigenDA-integrated rollups on those chains. The proposed solution leverages Hyperlane's general messaging layer for transporting AVS data from L1 to L2s efficiently and in a scalable manner. This GitHub issue seeks to outline the technical specification required to implement this bridge and addresses open questions related to the lifecycle of AVS data, its consumption by EigenDA, and failure management.

Background

EigenDA's integration into L3 rollups necessitates the availability of AVS data on Ethereum L1 to be transported to various L2 ecosystems. Hyperlane's messaging layer offers a versatile solution that plugs into the native transport mechanisms of different ecosystems, allowing for seamless data bridging.

Open Questions

  1. AVS Data Posting by Eigenlayer to Ethereum L1

    • How is AVS data generated and structured by Eigenlayer?
    • Through what mechanism is this data currently posted to Ethereum L1?
  2. Data Bridging Lifecycle

    • At which stage in the AVS data lifecycle is it most efficient to bridge this data?
    • Should the data be bridged immediately upon posting to L1, or is there a verification/waiting period involved?
  3. Consumption of AVS Data by EigenDA

    • How does EigenDA interact with AVS data?
    • Is there a requirement for the data to be actively pushed to EigenDA, or does it poll a data store for new entries?
  4. Failure Modes and Handling

    • What are the potential failure points in the data bridging process?
    • How should Hyperlane and Eigenlayer address these failure modes to ensure data integrity and system reliability?

Tasks

  • Define the structure and generation process of AVS data by Eigenlayer.
  • Detail the current mechanism for posting AVS data to Ethereum L1.
  • Identify the optimal point in the AVS data lifecycle for initiating the bridge to L2s.
  • Describe how EigenDA consumes AVS data, including any requirements for data delivery mechanisms.
  • Outline potential failure modes in the data bridging process and propose strategies for handling these failures.

Documentation and Linked Issues

  • Spec: TBD
  • Related GitHub Issues: (List any related issues here)

Discussion

Please share any insights, suggestions, or concerns regarding the technical specifications and the open questions listed. Your input is valuable in ensuring the robustness and efficiency of the bridging process for EigenDA AVS data to L3 rollups.

@0xsuryansh 0xsuryansh self-assigned this Mar 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant