AggLayer tampering with CDK submissions

[HarryTmetic]

In the current construction, the certificates from the current epoch, along with the global_balance_tree and global_exit_tree from the previous epoch, serve as inputs to the pessimistic proof. This setup allows the AggLayer to potentially tamper with the withdrawals by simply altering the values. Consequently, SP1 would generate new_global_balance_root and new_global_exit_root based on the modified withdrawals list, resulting in "emulated" states being settled on L1.

A solution could be to require chains to commit their LER (post-application of the withdrawals) to L1 before submitting their certificates to the AggLayer. The bridge contract would then verify the consistency between the posted LERs and the new GET to accept the pessimistic proof from the AggLayer before updating the GET. This approach should be generic (i.e., work for validiums and DACs as well).

[pgebheim]

I think another option here is to assume the chain (or a party designated trusted by the chain) actually generate the proof and submit it to the agglayer, thus allowing them to check that the output LER is correct.

In the current zkevm this is asserted through the final state root of the chain.

It's a bummer to require chains to commit that LER state to the L1 and really sorta breaks the flow...

[pgebheim]

I think this implies that the Proof of Consensus can be used to show the the LER stored in a "final" state root of the chain

[krlosMata]

I think there are two different scenarios:

• straightforward is committing data:
  • zkEVM/Validium --> LER is commited on L1 when called verifiedBatches
  • non zk-chains --> commit to L1 all its bridges
• non-straighforward is validating consensus
  • each chain to have a consensusType
  • PP to verify that consensus (just ecdsa it its first iteration)

The issue here is that if the PP is done by all the chains, you somehow need a consensusTree which has all the consensusTypes for each chain. If it is a single PP per chain, you do not even need that, you can check it on L1 by splitting submission bridges & verification....or just validating a signature on L1 when verifying the PP

[pgebheim]

BTW I think where you're using "Consensus" I am using "Finality" now. Because chains can come to finality without consensus (in a single sequencer, zk chain).

By

non zk-chains --> commit to L1 all its bridges

do you mean writing all the withdrawals and using L1 as DA for that? cause that's not workable.

[krlosMata]

• I use consensus in this scenario referring to who decides the bridges ordering.
  Similar to who decides the transaction ordering in zk-chains. Nowadays, in zk-chains this is the trustedSequencer, but it could be a PoS, multisig, ...

• yep, I meant that xD

  • That would be the ideal case since a forced bridge mechanism could be build in L1, but It would add an additional cost
  • To avoid that cost, non-zk-chains could just post its hash, hashBridges (like Validiums)
  • Some concerns would be:
    • LER tree for non-zk-chains cannot be build from L1 DA
    • DAC in charge of the DA could prevent other chains to import its bridges
    • if hash is posted wrongly to L1 --> it could lead to a non provable proof

[pgebheim]

Can't we just handle this by enforcing the finality data to be signed and checking the output LER in a proof such that if the agglayer-rs tampered with it the proof would be invalid?

[HarryTmetic]

One way to solve the issue is to have the chains' submissions be signed i.e., the certificate and hence the LER in it, and have the pessimistic proof check that the provided certificates are indeed correctly signed by checking the signatures against the chains' public keys.
The L1 verifier would need to have access to the chains' public keys (as aggregated input) to verify the pessimistic proof.

This way the AggLayer cannot manipulate the chains' submissions, it can at worst omit some.

[krlosMata]

yes, that will work indeed.
That approach would mean:

• verify a signature inside the PP
• having in L1 the chain's public key

I think that is the way to go, but more generalized, like instead the input being the chain public key, it will be the chain consensus, which is a data structure that has consensusType and consensusPayload. The PP, depending on the consensusType verifies the consensusPayload (This is for next stages)

---

To simplify you approach @HarryTmetic , maybe we can just make the chain to sign the LER_i+1. Then, to L1 you submit the PP, LER_i+1 & the signature. The L1 verifies the signature (against the chain public key) and includes the LER_i+1 as a public input to the proof. It should match at the very final stage of the PP, otherwise the PP is invalid.
I believe this approach is what @pgebheim mentioned.
Both cases works and I probably think that it is easier to check the signature in L1 at this very first initial stage. Maybe it is easier to check it in the PP xD

[HarryTmetic]

Closing this discussion as we are verifying the signature in the PP.