Add Signal Service Design Doc #61
Conversation
There was a problem hiding this comment.
Looks good overall, but I think:
- We should expand a bit more. While keeping docs concise for now is a good idea, they should still be helpful and easy to read.
- Separate the concepts of general message passing(signals) from bridging
- Make the "fast message passing" section more clear
|
|
||
|  | ||
|
|
||
| Currently each application is responsible for their own signalling (i.e. there is no central storage of all signals). This means any potential relaying must be done on an app by app basis. We only provide a standard signalling library to store and verify signals on chain. |
There was a problem hiding this comment.
Should we also describe how the storage slot for signals is calculated and why?
documentation/SignalServiceDesign.md
Outdated
| @@ -0,0 +1,33 @@ | |||
| ## Normal ‘slow’ Message Passing | |||
|
|
|||
| In our current protocol, signalling is performed by storing a message at a specific storage slot, then, once the L1 state root is accessible on the L2, executing a storage proof to verify that value exists. This proof can then trigger then certain logic, such as minting tokens. | |||
There was a problem hiding this comment.
Why don't we separate the general message passing from the bridging? I believe the initial section should focus on how general message passing works and then another section can explain bridges as a specific application of message passing
There was a problem hiding this comment.
okay i re-structured the document!
| 1. The proposer listens to any signals being stored on the L1 SS | ||
| 2. The proposer (during his allocated slot) can selectively inject L1 → L2 signals when proposing a batch in `publish` function. | ||
| 3. Signals will be verified that they exist in the SS’s storage. | ||
| 4. A trusted entity (owned by the rollup) will then call `receiveSignal` on the L2 SS. This will fill a mapping of `_receivedSignals` to true (signal —> true) |
There was a problem hiding this comment.
Why do you need a trusted entity? I don't remember this being necessary, nor is discussed in the post
There was a problem hiding this comment.
From my understanding the rollup operator will need to call 'recieveSignal' on the L2 - see here. This because for 'fast' signals we need to trust that those signals were verified on the L1 since we dont have access to the L1 state root yet. Otherwise anyone could therotically fill the mapping and say the signal was received without providing a proof.
Co-authored-by: Gustavo Gonzalez <[email protected]>
…lup into feat/signal-doc
|
@nikeshnazareth @LeoPatOZ @ernestognw now that I had the time to read again the research post and this doc I believe there might be an under-explored part that we were discussing in person at the hotel lobby.
Now that we will have preconfs, publishing will be done less often. If I make a deposit from L1->L2 for example I will only be able to claim that once the anchor transaction updates the L1 state root. But if the preconfer can "inject" the signals to the L2 then I can claim my deposit directly on the L2 before the next "sync" happens and then when the proposer submits a publication the Inbox contract can check that those signals are actually present in storage on the L1. This is in practice probably very similar to the mechanism used in same slot message passing, but I think it warrants its own section and thinking. |
|
|
||
| Bridges are one of the main use cases of signalling. | ||
|
|
||
| ### ETH Bridge |
There was a problem hiding this comment.
It’s worth noting that the ETH bridge is not just for transferring ETH across chains; it shall be able to interact with arbitrary contracts on the destination chain, passing custom calldata and a specified amount of Ether (msg.value). Essentially, it functions as a remote call bridge, with ETH bridging being the simplest use case
There was a problem hiding this comment.
Ah ok i didnt realise the eth bridge would handle contract calls as well - currently it seems to not be able to support this https://github.com/OpenZeppelin/minimal-rollup/blob/bridge/src/protocol/ETHBridge.sol#L60 as we hardcode 0 for the calldata
No description provided.