You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
Rationale: Instead of connecting to a Nitro validator Ethereum RPC a bridge can connect to this node to reach faster finality.
Requirements
Stretch goal
Not requirements
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:
I think we can use this #226 to continue
The text was updated successfully, but these errors were encountered: