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

L2 full nodes that provide the Espresso finality to bridges #235

Closed
ImJeremyHe opened this issue Sep 19, 2024 · 2 comments · Fixed by #237
Closed

L2 full nodes that provide the Espresso finality to bridges #235

ImJeremyHe opened this issue Sep 19, 2024 · 2 comments · Fixed by #237
Assignees

Comments

@ImJeremyHe
Copy link
Member

ImJeremyHe commented Sep 19, 2024

Rationale: Instead of connecting to a Nitro validator Ethereum RPC a bridge can connect to this node to reach faster finality.

Requirements

  • Receive finalized messages via Espresso block namespace from Espresso query service
  • Build L2 block from finalized Espresso finalized messages
  • Expose Ethereum RPC (like existing nitro sequencer or validator node)

Stretch goal

  • Correct handling of re-orgs. For the first prototype we can defer this unless it's straightforward.

Not requirements

  • Forward transactions to the Nitro sequencer. If we can get this for free that's fine but we don't need it.

Bridges are supposed to use their own trusted L2 nodes that always provide the correct information to them.
In Nitro, every L2 node is fed from the sequencer and in terms of our integration, these L2 nodes should have the ability to discern if an L2 block has been finalized in the Espresso consensus.

We have already known how to run a normal L2 node (that doesn't have the functionality to check the finality) here. The rest for us is to help the L2 node gain the ability to get the confirmation from HotShot and to build the block only the related confirmation is found in HotShot. By this way, we don't need to change the RPC so that the bridges can reuse their code directly.

Currently an easy way I can think of is to add a flag and then to create a new kind of sequencer. This sequencer fetches the hotshot blocks, gets the transactions with the same namespace and creates blocks. This is largely similar with what we did before except that we don't need to fetch the justifications and put them into the messages.

The whole process is like:

  • Add a flag indicating we are running a fast finality node
  • Add a specific sequencer(maybe this is not an appropriate name) for creating L2 blocks from HotShot blocks. Reference:

I think we can use this #226 to continue

@Sneh1999
Copy link

Sneh1999 commented Sep 19, 2024

For my own understanding, Why will we not need to fetch justifications and put them in messages?

@sveitser
Copy link
Collaborator

Previously we needed justifications to post the data to L1, but this fast finality node does not send batches to L1. It's only a node for reading data from as soon as it's finalized by Espresso.

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

Successfully merging a pull request may close this issue.

3 participants