Improve SignalService docs #73
Conversation
documentation/SignalServiceDesign.md
Outdated
| 1. An application on the L1 stores a signal in the SS. | ||
| 2. The L2 proposer listens to any signal being stored on the L1 SS. | ||
| 3. After building a block and obtaining a commitment, the L2 proposer submits a transaction batch to their L1 inbox contract. This batch includes an anchor transaction where the proposer injects the L1 state root and the signals that were stored on the L1 SS. | ||
| 4. The inbox contract verifies that the signals exist in the L1 SS using a storage proof with the L1 state root that was just injected. |
There was a problem hiding this comment.
Im confused by step 3/4.
The inbox contract verifies that the signals exist in the L1 SS using a storage proof with the L1 state root that was just injected.
The inbox contract doesnt rely on an 'injected L1 state root' to verify signals as the inbox is on the L1 / or a storage proof. It simply reads the signal services storage directly.
There was a problem hiding this comment.
Good question. Inbox is not the best name as it's the one that will go in L2.
Step 3 is done in the L1 and step 4 is done in the L2. However, the misunderstanding relies on when it happened. The L2 transaction is built into an L2 block before published on the L1, where the L1 batch includes the L2 transactions (including the anchor).
documentation/fast_signaling.svg
Outdated
There was a problem hiding this comment.
I think similar comment to before I dont think step 4 occurs, its simply a storage read?
There was a problem hiding this comment.
Looks good, left a few small comments.
One thing I would like to see documented is this use case
Co-authored-by: Leo <[email protected]>
Co-authored-by: Leo <[email protected]>
Co-authored-by: Leo <[email protected]>
Co-authored-by: Leo <[email protected]>
Co-authored-by: Leo <[email protected]>
Co-authored-by: Leo <[email protected]>
Co-authored-by: Leo <[email protected]>
Are you saying that we should outline the specific use case of a "fast-deposit"? My feeling is that it's already implicit by fast tracking signals to the L2. |
Yes, I do believe this deserves its own section - but I'm fine with merging this PR and then adding it |
Disagree, if we were following a structured approach to the L1Rollup, that becomes just a feature on top. The reason this is not clear and we need to write it is because we don't have a proper abstraction yet. |
Extends the documentation of the signal service. In particular, it addresses some of the comments in the past PR.
Generalization of signaling
The new version tries to expand on the idea of signaling being general enough. For example, one can build their own app to "fast-track" their own trusted values. This way, the mechanics of doing so are passed to the application developers (i.e. Solidity developers) so that they can incentivize the execution whichever they want.
Preconfirmations
By generalizing the signaling mechanism, it's possible to treat signals differently depending on the context. In the context of preconfirmations, a rollup may decide to condition the inclusion of "fast-tracked" signals in their inbox. I see this as a feature that should be customizable when using the library (e.g.
contract TaikoInbox is BaseInbox, EnforcedFastSignalInbox { ... })