Joint ledger

Gummiworm’s joint ledger keeps a prospective L1 ledger and a black-box L2 ledger in sync with each other as it processes user requests.

Prospective L1 ledger

The L1 blockchain anchors Gummiworm’s L2 ledger: the L2 ledger’s rules require L2 state to correspond to funds held by Gummiworm on L1. The L1 blockchain also provides a safety net for Gummiworm’s consensus protocol—if consensus fails, L1 smart contracts take over to evacuate L1 funds in the rules-based regime.

Gummiworm maintains a prospective L1 ledger state that corresponds to the cumulative effects of all requests for which the head peers have determined outcomes and a total order. Gummiworm uses this prospective state to continue deriving effects for new requests without waiting for previous effects to be executed on L1.

This is possible because Gummiworm’s L1 smart contracts only allow Gummiworm’s state on the L1 blockchain to be modified by Gummiworm’s consensus (until it fails), and Gummiworm’s consensus never contradicts the effects that it derives.

The prospective L1 ledger state is partitioned into one main, one equity, and zero or more deposit compartments. It does not have an exit compartment because it presumes that all derived effects have been executed, including those transferring funds out of the exit compartment.

Black-box L2 ledger

Gummiworm views the L2 ledger as a black box. This allows the L2 ledger state, transitions, and rules to be fully customizable without significantly changing Gummiworm’s consensus protocol. However, Gummiworm is aware of its custody compartments and expects the L2 ledger state to align with it on the main and deposit compartments. The equity, exit, and fallback contingency compartments are managed exclusively by the prospective L1 ledger.

In case of consensus failure, Gummiworm needs to know how to evacuate the L1 funds out of the main compartment, as those funds would otherwise remain indefinitely stranded in that compartment. On the other hand, funds in the deposit compartments do not need evacuation because Gummiworm’s custody over those funds is only temporary. Accordingly, Gummiworm maintains an evacuation map specifying how the main compartment’s funds should be paid out to their respective owners if consensus fails.

Gummiworm processes user requests, in the total order decided by the peers, by issuing corresponding commands to the black-box L2 ledger. The L2 ledger validates the commands, reports outcomes of the user requests to Gummiworm, and applies L2 ledger state transitions if the commands are valid. Each request may contain domain-specific information, which Gummiworm’s consensus protocol passes to the black box without inspection.

A request outcome answers these questions:

• Is the request valid?
• If valid, how does the evacuation map need to change, and which immediate payouts (if any) does Gummiworm need to remit on L1?
• If not valid, what was the error?
• (Optional) How can an outsider verify that the black box properly applied the domain-specific L2 ledger rules to determine this outcome?

Depending on the request type, the outcomes are determined in one or two stages:

• Deposit request outcomes are determined in two stages.
• Transaction request outcomes are determined in a single stage.

Gummiworm requires that the L2 ledger rules have all these properties:

• No-op on failure. Invalid requests do not modify the ledger state or evacuation map, and they do not cause Gummiworm to remit payments.
• No replay. Each request can only be valid once. Afterward, the same request will always be invalid if resubmitted.