Sugar Rush overview
To demonstrate the flexibility of Gummiworm, we have also built Sugar Rush, a central limit orderbook DEX focused on privacy and MEV resistance.
The Sugar Rush Ledger runs in an Intel TDX Trusted Enclave. This provides the ability to sign attestations to the code it is running and generate keys visible only inside of the hardware enclave. On boot, the head peers running the Sugar Rush ledger connect, attest to each other, and then generate a shared decryption key.
Users then receive, on connection, an attestation which they can validate, and then encrypt all future traffic for the shared decryption key.
Because Gummiworm is agnostic to the L2 payload and the L2 ledger rules, consensus can still occur to sequence the encrypted payloads. This means every order is an opaque ciphertext, and a malicious intermediary has very little signal to delay, censor, or reorder transactions, eliminating most vectors of extractable value.
Once the sequence of transactions has been committed to, the Sugar Rush ledger then re-encrypts the order payload for a shared secret used by the coil, which enables them to replicate the state change. All traffic between peers happens over authenticated and encrypted channels.
Inside the ledger, we provide a standard central limit orderbook:
- There are a list of markets, each with a pair of assets, a fee, and a list of open orders
- Users have an account with some amount of funds, and a list of references to open orders
- Users can place new orders, which either execute, if they cross the spread, or rest in the orderbook
- Users can update or cancel orders
- Users can request withdrawals
We also provide many quality of life features:
- Users can submit requests with bulk actions, efficiently and atomically updating many orders at once
- Users can delegate trading authority to another key, removing the need to sign a transaction for every trade
- Accounts can specify a destination, facilitating protocol treasury managed accounts
- Users can opt orders on the orderbook into supporting accelerated deposits, turning a big chunk of the orderbook into bridge liquidity (see accelerated deposits)
- Withdrawals can interact with protocols on the L1; for example, a market maker can replenish their inventory via SundaeSwap via a withdraw which routes to an order, which routes back into a deposit
After each request, the Sugar Rush ledger reports an updated evacuation map that simply assigns each user’s funds (from open orders and account balance) to their designated destination (on Cardano, this is an address and a datum) on the L1.
To surface information to the user, the Sugar Rush ledger writes events into an append-only log, which asynchronously updates various snapshots and aggregate views. A unified Sugar Rush API provides a horizontally scalable public-facing websocket API where users can submit requests (which get routed to the Gummiworm consensus), and stream events (such as status updates about orders or new snapshots) efficiently to connected users.
User requests are encrypted for the enclave key, and outbound events are encrypted for the user’s public key, ensuring their data stays relatively private. It’s worth noting that, because of the need to reproduce the same replicated state machine, the coil also has visibility of these requests and events, not just the head. Due to the added cost of running trusted enclaves, we do not require that the coil nodes run inside of TEEs. This privacy is much narrower than a user would enjoy on most L1s, but doesn’t maintain perfect privacy. Future iterations of Sugar Rush could use fancier cryptography, like multiparty computation, fully homomorphic encryption, or zero knowledge proofs to further secure user data from the coil, but that is outside the scope of the initial version of Sugar Rush.
For the full technical specification of Sugar Rush, including the TDX architecture, ledger state, commands, and encryption protocols, see the Sugar Rush detailed specification.