Order Encryption
Sugar Rush provides resistance against front-running user orders. Front-running is a phenomenon where orders are pre-empted or re-ordered to provide unfair market advantage to one party. For example, on seeing a large order with a higher slippage tolerance, an operator could update their order to widen the spread and extract more from the user.
To provide resistance to this, we leverage the TDX Architecture to generate a shared key and encrypt the users order. It can only be decrypted inside of the trusted enclave, and the user can audit the code in the attestation quote to ensure there is no specialized front-running code.
Since the order is encrypted, it appears as an opaque blob to all of the networking infrastructure leading up to the TDX, and so cannot be reordered for operator advantage.
In theory, there are other metadata leaks like source IP and timing. These are much harder to guard against, but also much harder to leverage for advantage. This is why we say Sugar Rush is resistant to front-running, rather than immune.
Group Key Derivation
Each peer in a gummiworm head has a long-lived ed25519 signing key, which we’ll call the head_{public|private}_key_i, that they use for consensus multisig.
On startup, the peers need to establish forward-secret secure communication channels with each other peer, along with an ephemeral key that can be used externally to communicate with any peer.
To do this, the peers sugar-rush-boot servers first open unencrypted channels with eachother. Each peer opens a bidirectional TCP channel to each other peer, reading an IP or DNS name from a configuration file on disk.
Each peer generates an ephemeral X25519 key for this session, called (transport_public_key_i, transport_private_key_i).
The peer binds this transport key to the TDX (encrypts it so that only the TDX can read it), and saves it to disk in a known location. Alternatively, to avoid the key hitting disk, we can pass the key to the gummiworm process later via stdout->stdin, or via file descriptor inheritance.
[!NOTE] For forward-secrecy (i.e. someone who compromises next months key can’t read messages sent this month), we should do this on every boot, and pass the key over stdin or file-descriptor inheritance; but for the time being we generate it once, save it to disk, and reuse the transport key across sessions.
They each generate a cryptographically random seed_i and a commitment to this value, commitment_i = SHA256(seed_i || head_public_key_i || transport_public_key_i).
They then each exchange TDX attestation quotes, with REPORTDATA set to transport_public_key_i || commitment_i (which should be a total of 64 bytes).
Each peer signs their attestation quote with head_public_key_i, and shares it with each other peer.
Each peer validates the attestation, including the firmware, VM image, that the timestamp in the quote is within 30 seconds (replays would fail in the second round, as the man in the middle wouldn’t have the transport key, but this detects it early), and that the enveloping signature is from the head peer they expected it to be from.
Each peer can then safely communicate in ciphertext with each other peer using the corresponding transport_public_key_i, using ChaCha20-Poly1305 encryption. We save each other peers transport_public_key_i to disk, to be read by the gummiworm consensus node.
Next, each peer reveals the commitment to each other peer. They send, over the encrypted channel, seed_i, and the peer on the other end validates that commitment_i = SHA256(seed_i || expected_public_key_i || transport_public_key_i).
With the seed securely exchanged between valid TDX enclaves, each peer can sort the seeds canonically (for example, by the order that head_public_key appears in the on-chain head open transaction), calculate a group seed for keygen: group_seed = SHA256(seed_1 || seed_2 || ... || seed_n || "SUGAR-RUSH-HEAD-GROUP-KEY"). This is uniformly distributed, as no head had an opportunity to adaptively choose a seed to influence the group seed.
Each head can then independently derive (group_public_key, group_private_key) = X25519_keygen(group_seed).
We bind this private key to the TDX, and save it to disk in a known location. We can save the group public key in cleartext.
Then, we construct the relevant public and private configuration for both the Gummiworm consensus node and the sugar rush ledger process, and spawn these processes pointing to this configuration.
User communication
When a user connects to one of the head nodes, they generate their own fresh (user_session_public_key, user_session_private_key). Their opening message in the handshake to the peer includes their user_session_public_key.
The peer responds with a TDX attestation, with REPORT_DATA set to user_session_public_key || group_public_key, which serves as a challenge nonce.
The peer and the user can now each independently derive a shared secret:
user_shared_secret = X25519(user_session_private_key, group_public_key)
peer_shared_secret = X25519(group_private_key, user_session_public_key)
user_shared_secret == peer_shared_secretEach can also then derive salted keys (to prevent cross-channel key confusion).
The user derives request_key = SHA256(shared_secret || "SUGAR-RUSH-ORDERBOOK-REQUEST"), and encrypts all messages to the peer with ChaCha20-Poly1305(request_key, nonce, plaintext).
The server derives response_key = SHA256(shared_secret || "SUGAR-RUSH-ORDERBOOK-RESPONSE"), and encrypts all return messages to the peer with ChaCha20-Poly1305(response_key, nonce, plaintext).
Some of the above may instead be the responsibility of the gummiworm consensus node, which already has to establish trusted communication channels and runs on the same TDX machine. We’ll need to finalize the startup procedure with them.