Closed ImJeremyHe closed 1 month ago
For my own understanding, Why will we not need to fetch justifications and put them in messages?
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