Question about L1 state root injection and signal verification in fast path Signaling in Signal Service

[NIC619]

In the "Same Slot L1 → L2 ('fast') Signaling" section of Signal Service doc, it mentioned that L2 proposer will inject L1 state root via anchor transaction (in step 3) and the inbox contract will verify the signals' proof against the injected L1 state root (in step 4):

My questions are:

1. Doesn't this introduce a trust assumption on the L2 proposer? since he can inject any L1 state root he claimed to be "the upcoming L1 state root" and can thus fake any signal he desires. And how can the L2 proposer even come up with "the upcoming L1 state root" as "the upcoming L1 block" is not even created yet?
2. There's isSignalStored function in the SignalService contract, shouldn't the inbox contract just call this function to check a signal instead?

[nikeshnazareth]

Hey Nic - great questions! Unfortunately, the answer is that the docs are incorrect and sloppy.

Some context:

• Last week I created this explanation of a generalisation of the idea, as well as a sample implementation on the contract side. The "fast signal" mechanism is Nethermind's "same slot messaging" technique. Hopefully that adds some clarity.
• The current version of this code base does not implement either the Fast Signal mechanism or the generic provable assertions.
• I believe the docs you're quoting were created when we were planning to replicate Taiko's implementation of the fast-signal mechanism (which we still might, depending on how the provable assertions discussions go).

To answer your questions directly:

• it's not a new trust assumption because the injected values are checked in the inbox when the publication makes it to L1. The rollup state-transition function ensures that they are consistent (that the proposer-injected values are the same as the ones retrieved in the L1 inbox). If they don't match then the publication is invalid.
• The slow case injects the old L1 state root. The fast case injects the actual signals (see this line of the Taiko code base) so anyone on L2 can confirm they exist with isSignalSent. These must match the signals checked on L1 (as you noted, by checking the L1 signal service directly).

Sorry for the confusion! We are definitely due for a cleanup and update to all the docs.

[NIC619]

Hi @nikeshnazareth Thank you for the clarification and the references provided! They are really helpful. I will take a deep dive into to the provable assertions next.