Gummiworm overview

The Gummiworm protocol is designed to solve a collection of urgent priorities for end users.

Users want to transact in high throughput arenas with fast finality
Users want minimized trust in central authorities
Businesses don’t want the risk of custodying user funds
Businesses need predictable compute that can scale to meet demand
Businesses want to reach users and transact with funds from many chains
Businesses don’t want to isolate their users from other dApps
Businesses want to bring their own software stack, not rebuild from scratch

The key obstacle to delivering on all of these concurrently is that most scaling solutions conflate “execution” and “custody”. Execution, in this context, is the decision making process that places user requests in a specific sequence and evaluates their results, while custody is the safeguarding of user funds.

State channels, for example, are able to execute extremely quickly because they reach consensus among a very small set of peers (2, in the case of Bitcoin Lightning, and 2-8 in the case of Hydra). As you try to scale this up to more participants, you hit a limit as communication overhead slows down that decision making process. This pushes solutions like Hydra, when used for DeFi, into a “star” topology: a small set of participants are trusted not to collude and steal user funds. Note that this trust model is often asking more than most people suspect: even if you trust the real head participants, their keys or servers may get compromised.

Gummiworm, then, makes the central decision to separate execution and custody. A small set of peers (the “Head”) rapidly sequence and evaluate transactions as fast as they can, while a larger set of peers (the “Coil”) check their work and ratify the L1 effects of those transactions to absorb or disburse user funds.

The ability to separate these two rests on determinism in the consensus algorithm. Because L1 effects are deterministically derived from the agreed sequence of events, peers never contradict a decision once it’s been made, and there are no conflicts or failure states to reconcile. The Gummiworm protocol is free to produce a long sequence of transactions that only must “eventually” settle on the L1, rather than stalling consensus while it waits. The only failure condition is inability to reach quorum, at which point a pre-signed “dead-man’s-switch” transaction matures (reaches its validity start time) and shifts the protocol into a rules-based regime to mediate the latest snapshot and evacuate the head.

This has the following benefits:

Since the Coil can simply ratify the latest state, rather than each intermediate state, the head can produce blocks as fast as it can collect a single round of signatures
On the other hand, the head peers have no ability to touch user funds, as absorbing or disbursing funds requires the coil
This also means the businesses operating the head peers don’t bear any risk; even total key failure or compromise can’t result in lost user funds
With (planned) native cross-head transactions, as demand scales, new heads can be provisioned
Because custody is separated from execution, a single head can custody funds from many L1s simultaneously
Fast and flexible deposits and withdrawals, along with cross-head transactions, mean that protocols can be composed across borders
And finally, separating execution from custody means that the execution layer can be replaced and customized for the specific use case

The remainder of this whitepaper will justify these claims by showing concrete results and detailing the exact implementation.