Amazing, and excited to see this! Would love to see the Celo ecosystem come closer to Ethereum.
Some technical questions/feedback:
-
In the diagram, shouldn’t it be the proposers that sends a block to the validator set? Generally in PBFT-style consensus, the proposer moves first.
-
Would the data submitted to Ethereum contain the signatures, or a SNARK of the signatures, or just the DA certificate?
Making it include either the signatures or a SNARK, and making an L1 contract actually verify it, has a lot of benefits because then assets issued outside Celo (whether ethereum or an L2) can be bridged to Celo in a way with the maximum possible guarantees of a validium: even if the DA mechanism is broken, the worst that a malicious Celo validator set could do is freeze everyone’s funds by making a block with missing data; they would not be able to steal funds.
On the other hand, if the SNARK (Plumo proofs?) live outside of Ethereum, then a bridge would not have that security guarantee, unless of course the bridge itself demands a full recursive proof. If bridging happens much less frequently than block submission, then maybe that would be ok.
-
On “never reverting” as an objective. One of the challenges of that is that Ethereum itself can revert, and even post-SSF in extreme cases: during an inactivity leak the finality mechanism would not run and the chain would run on LMD GHOST.
A particular risk in that situation is: what if someone deposits assets issued on Ethereum into Celo, but then Ethereum reverts, reverting the deposit, but those assets still exist on Celo.
I see two solutions:
- Abandon the “never revert” objective, and instead have a design where a Celo block header points to the most recent Ethereum block that it accepts deposits from, so Celo would revert in lockstep with Ethereum (this would happen only in extreme cases of inactivity leak + network instability, so users would know ahead of time that Ethereum is in an extreme mode that it is recovering from)
- Only accept deposits from finalized blocks. In this case, if Ethereum enters an inactivity leak stage, Celo would just not accept deposits until the inactivity leak ends (this has happened once in Ethereum history so far, and lasted less than an hour, but in the worst case it could last several weeks)
Personally, my opinion is that ideally all networks would embrace publishing revertable blocks in situations where finality stops working, because giving users partial information about what is likely to be included is better than giving users no information at all. But I understand that this is technically difficult to implement if the chain is not built for it already, and would not wish extra technical challenges on the Celo community that it’s not able to handle given its ongoing hard work in many other areas. Hence the second option sounds better?