Inspired to finally write this as a post by a recent tweet by Justin Drake.
Background
Based and Native Rollups
Based rollups use the base layer (aka L1) to order batches of transactions that form the state transitions of the rollup. However, on their own, based rollups only prescribe how sequencing is done; the design space for trust-minimized two-way bridging is left open.
Native rollups take based rollups one step further: the verification logic of the correctness of the bridge is enshrined into the protocol. In other words, both smart contract bugs and upgradability (to fix smart contract bugs) are removed from the equation.
Segregated Witness (SegWit)
Bitcoin’s SegWit is implemented as a soft fork. In other words, it’s a set of constraints on otherwise-valid transactions, making them invalid. Specifically, SegWit is implemented as constraints on anyone-can-spend outputs. While to a non-SegWit Bitcoin full node, such outputs appear to be spent without a signature (which is allowed for anyone-can-spend outputs), SegWit-enabled Bitcoin nodes will verify the signatures for correctness and validity.
Strawman Proposals
Strawman Proposal 1
One method of enshrining a native rollup would be to add hooks in the Celestia state machine to verify the correctness of a specific rollup. In other words, unlike ZK accounts—where the verifier is uploaded by users and may have bugs that must be resolved by upgrading the verifier keys rather than a hard fork—the verifier logic of a native rollup would be embedded directly into the Celestia state machine. And if there are any bugs in the verifier code, the expectation would be to hard fork Celestia to resolve such bugs.
While completely technically feasible, this method leaves some to be desired:
- It requires complex ZK verification logic to be enshrined as a dependency of the native rollup existing, and maintained by the Celestia core engineers.
- The bridge verifier needs to be enshrined into the Celestia state machine, which all nodes are required to verify.
Strawman Proposal 2
Another method of enshrining a native rollup would be to add hooks in the Celestia state machine to fully execute a specific rollup to verify its correctness. In other words, pessimistic verification.
While also completely technically feasible, this method leaves a lot to be desired:
- The bridge verifier needs to be enshrined into the Celestia state machine, requiring all Celestia full nodes to fully execute the rollup.
Proposal
Leveraging ideas from SegWit, we propose a mechanism to enable a native rollup on Celestia without changes to the Celestia state machine.
An anyone-can-spend account is created. Unlike with Bitcoin, where anyone-can-spend outputs are part of the protocol, this doesn’t exist for the Celestia state machine. We can accomplish it alternatively by simply publishing the private key of the account, and including a (valid) signature with transactions from that account.
Sends to the account are treated as deposits into a rollup. Sends from that account must satisfy the following condition: they must be valid withdrawals from the rollup, from the rollup’s point of view (i.e. from the rollup’s state machine).
We can actually enforce this condition through a soft fork, much like with SegWit. Moreover, this can be done without requiring changes to the state machine! A sidecar process can be ran that rejects blocks for the soft fork. This is known as a Core-Untouched Soft Fork (CUSF).
Thus, Celestia full nodes that want to enforce this rule (in particular, Celestia validators) can run a sidecar process that’s essentially an execution state machine with based sequencing and bridge logic, entirely outside of the Celestia state machine.
An obvious downside of this mechanism is that in order to guarantee correctness of the rollup (and thus, the bridge), any Celestia full node that runs the sidecar process would also be fully validating the rollup—which could be quite expensive. We note that in order to verify the validity of the rollup, a sidecar process only needs to know the rollup is valid, not what the full state of the rollup is. So we can have the sidecar process also run in a mode where it only verifies ZK proofs of correct execution of the rollup. Indeed even Celestia validators can run the sidecar process in this mode if they don’t intend to participate in batching rollup transactions!
A number of ways of posting the ZK proofs on-chain can be imagined. For example, the soft fork can require a PFB transaction containing the proof to the posted as the first transaction in some namespace. Complete exploration of this space is left as an exercise for reader. Of note is that this is an optimization that doesn’t strictly need to be done before such a native rollup is deployed. Moreover, the ZK verifier would be in the sidecar process, not in the Celestia state machine.
Conclusion
To wrap up, we propose here a mechanism for adding native rollups to Celestia with no changes to the Celestia state machine through a CUSF. This would allow Celestia as a protocol to verticalize the stack it offers to users.
Appendix
Thanks Eric Wall for bringing up this discussion point.
In PoW, strictly greater than 50% of mining power needs to run the sidecar process for a CUSF—or just soft forks in general—to be successful. Specifically, success here means that the heaviest header (not block!) chain is the one that has the CUSF applied to it.
In Tendermint, this is slightly different, since Tendermint is prioritizes safety over liveness. Only strictly greater than 1/3 of voting power running the sidecar process is required to halt any attempt to progress the chain in a way that violates the soft fork. This would then encourage a remaining 1/3 to also pick up the sidecar process, until strictly greater than 2/3 of the voting power is running the sidecar process and the chain resumes.
This is even more pronounced in protocols like Alpenglow, which have a 1/5 liveness threshold rather than 1/3.