Check Sequencer for specific event data emitted by an OVM contract

[platocrat]

Question from @barrasso

1. How do you properly check the sequencer for specific event data emitted by a contract on the OVM?
2. How do you verify that event data is legit?
3. What are the potential attack vectors of this approach?

Here's an summary of the intent of these questions:

To summarize, what we're trying to do is skip the withdrawal period by verifying for ourselves that a given L2 transaction is valid and then reporting it to L1 using oracles. So to do this we'd run an OVM node and watch the state of the chain using an event listener. It'd listen for a specific event reported by the Sequencer and push the event data to the Oracle network.

In this scheme, we are trusting that the Sequencer is reporting the correct state, right? What prevents the Sequencer from misbehaving and including bad state? I know it's run by Optimism now with plans to decentralize, but I am still trying to wrap my head around the trust/incentives model here.

We have some ideas for risk mitigation for this anyways like withdrawal limits, time locks, collateralized insurance, dispute resolutions, etc. but I wanted to get an idea of how feasible this sounds from the Optimism side of things.

Additional Context These questions were surfaced through my Discord DMs

[smartcontracts]

This is a great question. Here's the "reasonably detailed" answer:

You have three main options when running an OE node:

1. Run a verifier and only pull transaction data from L1
2. Run a replica and only pull transaction data from the Sequencer
3. Run a verifier but pull transaction data from the Sequencer before those transactions have been published to L1

Options (2) and (3) give you information faster because you're getting data directly from the Sequencer. However, this can be considered insecure because there's a chance that the Sequencer claims that a given transaction will be included in the system but never actually publishes that transaction to L1.

It seems like you really want (1). When you're running a verifier, you don't have to trust the Sequencer at all (if you don't want to). Your verifier node would compute the correct state for itself. I would highly recommend running your own verifier node for this sort of application -- otherwise you are trusting the Sequencer.

Hope this answers the question. Going to close this unless there are additional open questions!

[barrasso]

Thanks @smartcontracts for the "reasonably detailed" answer :)

Just had a few follow up questions:

(1) So in order to pull this off, we'd have to run an OVM node AND a verifier node, correct? And then our event listener would be watching the verifier node for the validated transaction data? Also, is there documentation on how to run a verifier?

(2) How often is transaction data published to L1?

---

If we do get data directly from the Sequencer, we accept that this might be an inherent trade-off in UX vs. Risk for the users of our system, but we are trying to understand the potential pitfalls here in order to mitigate as much as possible.

there's a chance that the Sequencer claims that a given transaction will be included in the system but never actually publishes that transaction to L1.

(3) Can that chance be quantified in some sort of rough percentage?

(4) Let's say we cap the fast withdrawal limit, isn't there an (optimistic) assumption that the Sequencer will behave properly for most of the time (depending on how much is at stake)? Trying to find that balance.

[smartcontracts]

So in order to pull this off, we'd have to run an OVM node AND a verifier node, correct? And then our event listener would be watching the verifier node for the validated transaction data? Also, is there documentation on how to run a verifier?

You would only have to run the verifier node ("verifier nodes" are just a fancy name for OE nodes that aren't the sequencer). And then yes, your even listener would point at your own verifier node. Alternatively of course you could use a service provider like infura or alchemy if you didn't want to run your own node (but as always, this is shifting the trust over to those providers). I'm not 100% sure if the process of running a verifier node is well documented. I've asked if this is documented anywhere. If it isn't then I have a weekend project...

How often is transaction data published to L1?

Very regularly, with some caveats. We have minimum number of transactions before we'll submit a batch of transactions. I'm not sure of the exact number, but because mainnet is restricted and transaction volumes are low, this can sometimes be on the order of several hours. Of course this will basically become irrelevant once more volume is introduced. I think right now we submit batches once per minute on Kovan and something like once every 15 minutes on mainnet. As volume increases, this time interval will decrease.

Can that chance be quantified in some sort of rough percentage?

Probably "pretty darn low" -- but of course it depends on circumstance. We're working very hard to make sure this will never happen as long as we're running the Sequencer. However, we obviously can't make that same guarantee in the future when other parties will operate the Sequencer. We're working on mechanisms that will make "Sequencer confirmations" stronger by asking the Sequencer to sign off on transaction receipts and putting some funds at risk in the case that they do not include transactions in the order that they've promised. That would further reduce the risk of transactions not being published after being accepted by the Sequencer.

Let's say we cap the fast withdrawal limit, isn't there an (optimistic) assumption that the Sequencer will behave properly for most of the time (depending on how much is at stake)?

I think it's relatively reasonable to assume the Sequencer will behave properly. However, I think that it's still worth running your own verifier node and accepting a slightly longer withdrawal period for at least the next few months while the system becomes more and more stable. Although it's unlikely, there's always the possibility of an unknown geth bug that breaks the node and causes us to lose some transaction data before those transactions have been published. We do maintain backups to (hopefully) avoid this sort of scenario but you never know.