Resonance

​

Architecture

Resonance is a general, two-sided fee market, matching sets of user transactions, $T$, to sets of capable, executing nodes, $N$. This is in contrast to fee mechanisms like EIP-1559 (Ethereum’s current default fee mechanism) that operate on the basis of assigning single transactions to execution by every node in a network.

​

User valuation

Transactions in Ethereum pay gas for inclusion into a block.

After EIP-1559, gas fees are split into two parameters: a baseFee and a priorityFee. The baseFee is a minimum inclusion fee that modulates based on blockspace demand and is burnt. The priorityFee is a user-specified tip to block proposers to prioritize inclusion of their transaction relative to others.

Resonance operates in a surplus-maximizing setting. Rather than transactions specifying baseFee or priorityFee, users instead assign a valuation to their transactions, which represents the maximum amount of money a user submitting a transaction is willing to pay for its execution.

​

Node cost function

In Ethereum today, all nodes execute each and every transaction in a block. In return for their service, validators actively benefit from sum(priorityFee) of included transactions and an inflationary block reward (currently, 2 ETH) when they are the elected block proposer, and passively from ETH supply reduction via the baseFee burn.

Irrespective of whether a node is specialized to execute certain types of compute, it is rewarded congruently to any other, and forced to execute all transactions.

In Ritual, via Resonance and Symphony, we enable selective execution and node specialization, reducing redundant re-execution and enabling nodes to make explicit their unique execution costs.

Akin to users specifying a true valuation for their transactions, each node also specifies a cost function which dictates their true cost to executing a set of transactions.

Formally, this can be defined as each node, $n \in N$ ($n$ is an element in the set of nodes, $N$), specifies a cost function, $c_n(X):2^T\rightarrow\mathbb{R}_{\ge0}$, denoting the amount of money the node, $n$, must be paid to execute a bundle of transactions, $X$, where $X \subseteq T$ ($X$ is a subset of all valid transactions, $T$).

​

Brokers

Resonance introduces a new set of entities known as brokers. Brokers are sophisticated and profit-seeking agents that compute efficient allocations assigning transactions to set of nodes.

Think of brokers as a parallel to searchers or block builders in the MEV ecosystem: advanced participants that use their informed priors to efficiently match transactions, pocketing the spread between transaction valuation and node execution cost in the process.

Brokers primarily interface with the Auctioneer (described below). For each Auctioneer batch:

1. Brokers collect the set of transactions, $T$, that need to be matched via Auctioneer API
2. Execute their internal logic to produce a valid allocation, $\alpha:T\rightarrow 2^N$
3. Submit their best routing, $R_b$, to the Auctioneer via API

You can learn more about brokers via our canonical, open-source implementation, Echo (coming soon…).

​

Auctioneer

At the center of Resonance lies the Auctioneer, a new entity responsible for orchestrating brokers and executing the Resonance mechanism.

The Auctioneer has two components: an on-chain smart contract and an off-chain service:

​

On-chain smart contract

The Auctioneer smart contract, Auctioneer.sol, has four core functions:

1. Exposing the auctioneer publicKey to which users and nodes encrypt data
2. Managing node registration and periodic cost function updates
3. Enshrining match transactions from the off-chain service into chain state
4. Handling post-execution payments and disputes between users, nodes, and brokers

​

Off-chain service

The off-chain Auctioneer service has six core functions:

1. Receiving an inbound stream of pending transactions, $t$, from various nodes
2. Reading the on-chain node registration and cost function updates
3. Periodically initiating a new Auctioneer batch, exposing a set of to-match transactions, $T$
4. Receiving and validating broker routing, $R_b$, submissions, per batch
5. Executing the Resonance mechanism to select the surplus-maximizing routing, $R^*$
6. Enshrining the best routing, $R^*$, via match transaction to the on-chain smart contract

​

Desired properties

An Auctioneer must adhere to certain desired properties:

1. Auctioneers must execute the Resonance mechanism correctly
2. Auctioneers must not censor any broker routing, $R_b$, submissions
3. Auctioneers must not censor any query valuation or node cost function submissions
4. Auctioneers must not leak decrypted transaction valuation, decrypted node cost function, or broker routing submissions publicly

​

Account Abstraction

EIP-1559 is enforced as the default Ethereum fee mechanism and enshrined directly into the execution client codebase.

In contrast, Resonance is an opt-in upgrade for users that demand heterogeneous compute or those willing to trade increased transaction inclusion latency for potentially cheaper execution.

As a result of this optionality, Resonance transactions are implemented at a smart-contract layer rather than through the introduction of a custom transaction type (akin to Type-2 transactions which were introduced when Ethereum added EIP-1559 support).

This optionality presents a few problems:

1. Without the addition of a new transaction type, we can’t introduce encrypted valuation as a transaction parameter
2. Because valuation must remain private except to the Auctioneer, only the Auctioneer can validate and deduct balances for transaction execution
3. Without using the transaction value parameter (publicly enforced), nodes cannot deduct any ETH balances at all
4. Transactions must remain in-executable until after their match is enshrined
5. But, once a match is enshrined, transactions must reflect a payment to matched nodes
6. We must co-opt existing Ethereum wallet provider APIs for seamless integration with popular wallets
7. We must enable 1-6 without forcing all developers to introduce modifications in their own smart contracts

We found our solution to these problems via account abstraction:

1. Resonance users upgrade their wallets by setting their implementation to AuctioneerWallet.sol
2. AuctioneerWallet.sol permissions the on-chain Auctioneer.sol contract to manage EOA ETH balances through an auctioneer-permissioned withdraw() function
3. AuctioneerWallet.sol::execute() entrypoint conforms to similar parameters as a regular transaction
4. Yet, the new, smart implementation reverts until an Auctioneer sets a match (and thus, executing node) for the transaction

In this way, users can continue to use regular EIP-1559 transactions and Resonance, in parallel, with the same wallets and tooling they are familiar with.

// Minimal example of AuctioneerWallet.sol implementation
struct Transaction {
  bytes32 id;
  address to;
  uint256 value;
  uint256 gasLimit;
  bytes data;
  bytes encryptedValuation;
}

contract AuctioneerWallet {
  function withdraw(uint256 value) onlyAuctioneer {}

  function execute(Transaction calldata trx) external returns (bytes memory) {
    // Execute transaction normally
    (...) = address(trx.to).call{value: trx.value, gas: trx.gasLimit}(trx.data);

    // Auctioneer callback to pay assigned transaction executor
    // (reverts if none assigned)
    AUCTIONEER.txExecuted(trx.id);
  }
}

​

Transaction lifecycle

Resonance is an opt-in upgrade that allows users to choose the fee mechanism they want to use, for each transaction they send. To that extent, Resonance was designed to be a simple drop-in addition to the transaction lifecycle users are already familiar with:

​

Standard EIP-1559 lifecycle

A simplified smart contract transaction lifecycle, without Resonance, looks like:

1. Ethereum users authenticate with decentralized applications (dApps) via wallets
2. dApps prepare transaction payloads that execute on-chain smart contracts
3. dApps prompt wallets to send transaction payloads via the wallet provider API
4. Wallets interface with execution clients via their JSON-RPC API to estimate gas fees
5. Users select appropriate fees, usually deferring to wallet and RPC recommendations
6. Users sign fee-included transaction payloads with their wallet and broadcast via RPC
7. Nodes receive transactions via RPC and append to their local transaction pools
8. Then, nodes gossip transactions to other nodes in the network
9. Block-building nodes collect transactions with sufficient fees and propose blocks
10. Blocks are gossiped and validated amongst validators, progressing the chain
11. As blocks are included, users see executed state as a result of their transaction

​

New Resonance lifecycle

A simplified smart contract transaction lifecycle, with Resonance, looks like:

cast send <eoa_address> \
  --auth "<address of AuctioneerWallet deployment>" \
  --private-key <eoa_private_key>

Put together, using Resonance is simple and fully opt-in with few changes to the patterns users are already familiar with.

​

Looking forward

We expect to extend Resonance in a few ways:

1. Support natively pricing scheduled transactions
2. Decentralize the Auctioneer, enabling anyone to run the mechanism
3. Support a streaming setting rather than fixed duration Auctioneer batches to reduce E2E transaction inclusion latency
4. Explore posted price mechanisms to reduce user difficulty in inferring transaction valuation

​

More information

For more information on Resonance, see our blog posts and academic paper:

Resonance: A Market Mechanism for Heterogeneous Computation

Resonance enables heterogeneous computation on-chain. This post builds towards a formal definition of the heterogeneous setting.

The Resonance Mechanism and its Properties

This post gives a formal description of the Resonance mechanism and the desiderata it satisfies.

arXiv: Resonance: Transaction Fees for Heterogeneous Computation

This paper introduces Resonance: a new kind of transaction fee mechanism for the general two-sided market setting (with users on one side and nodes on the other), where both sides of the market exhibit a high degree of heterogeneity.