Fair Exchange Problem
How Taiyi ‘solves’ the fair exchange problem
The fair exchange problem exists between the user and the preconfirmer. There are multiple attack vectors that could be exploited, allowing either party to take advantage over the other. Here are a couple of examples:
- The preconfirmer, upon receiving the user’s preconfirm request, could withhold the information instead of broadcasting it. Worse still, they could steal the user’s transaction to front-run it. To address this problem, the system has to rely either on centralized trusted parties or alternative data availability solutions such as EigenDA. Simply put, the solution is not ideal.
- On the other hand, the user could withhold the transaction to intentionally cause the preconfirmer to be slashed, since the preconfirmer has no transaction details to share.
In fact, this is a classic problem in cryptography - Fair Exchange problem
Definition of the Fair Exchange Problem
The Fair Exchange Problem can be defined as follows:
You have two parties, Alice and Bob. Alice has a piece of data (e.g., raw data identified by a hash, signatures, results of a database query, etc.) that Bob wants, and Bob has a piece of data that Alice wants.
Problem: Can one design a trade mechanism that ensures atomicity, i.e., either both Alice gets and Bob gets , or neither Alice gets nor Bob gets ?
A key result in the field is that, in the general case, fair exchange is impossible without a third party. However, in our context, we don’t want to rely on a third party. A zero-knowledge proof may be applicable to the current problem.
Proposed Solution
According to Justin Drake, he proposed a solution to the fair exchange problem using zero-knowledge proofs.
The scheme would work as follows:
- Both Alice and Bob encrypt and using public keys and to produce and
- They swap (non-atomically) and (this shouldn’t reveal information about or if padding is used)
- They prove to each other in zero knowledge (e.g., using zkSNARKs or zkSTARKs) that and were correctly constructed
- They post a large collateral (much larger than the value of or ) into a fair exchange smart contract initialized with parameters and
- They reveal their private keys to the contract
- The contract verifies that the private keys match and , and if so, releases the collateral back to both parties
- Alice and Bob can now decrypt and respectively
While this sounds promising, the cost of on-chain interaction and latency caused by the state of the art zkp tech stack raises user experience concerns. We need a more performant solution.
Taiyi’s Solution
Here, we propose a solution that leverages the game-theoretical dynamic between the preconfirmer and user. Inspired by the design of LedgerHedger, we can indeed solve the fair exchange problem.
Our approach introduces a strategic game between two key players:
- The user (transaction initiator)
- The preconfirmer (transaction executor)
This game is designed to achieve the system goals of Partial Data Commitment and Fair Exchange without additional Trust Assumptions.
The Game
For a detailed explanation of this mechanism, we recommend reading Simon Brown’s article on Proposer Commitment Infrastructure in Ethereum. Simon Brown provides an excellent breakdown of how this system works and its implications for fair exchange in blockchain transactions.
-
User Request:
- The user sends a request with:
The request does not include transaction data (
preconfTx
). - The user sends a request with:
-
Preconfirmer Response:
- The preconfirmer simulates the transaction to ensure the user has sufficient balance.
- If the tips are sufficient, the preconfirmer accepts the request by co-signing it with the proposer and sending it back to the user.
-
Transaction Data Sharing:
- The user must share the transaction data (
preconfTx
) with the preconfirmer no later than 6 seconds into the specified block.
- The user must share the transaction data (
-
Exhaust Function:
- If the user fails to share the data or submits a transaction exceeding the original
gasLimit
, the preconfirmer can call theexhaust()
function. - The
exhaust()
function: a. Burns an amount of gas equal to the specifiedgasLimit
b. Transfers theprePayment
from the user to the preconfirmer c. Relieves the preconfirmer of the commitment duty
- If the user fails to share the data or submits a transaction exceeding the original
-
Incentive for Inclusion:
- If the user sends the transaction data on time, the preconfirmer is incentivized to include the transaction rather than calling
exhaust()
. - This allows the preconfirmer to receive both the
prePayment
andafterPayment
.
- If the user sends the transaction data on time, the preconfirmer is incentivized to include the transaction rather than calling
Conclusion
The success of Taiyi’s fair exchange system hinges on carefully balancing incentives through thoughtful parameter selection, particularly in the distribution of payments:
-
PrePayment: This initial payment to preconfirmers upon accepting a transaction request must be sufficient to maintain an attractive risk-to-reward ratio, ensuring continued interest in the system.
-
AfterPayment: This contingent payment, released upon successful transaction execution, must be substantial enough to discourage abuse of the
exhaust()
function and promote commitment fulfillment.
In the initial stages, we recommend users set higher afterPayments, relying on social consensus to prevent abuse. However, as we progress towards decentralizing the preconfirmer role, it becomes crucial to:
- Conduct extensive game theory analysis, drawing inspiration from studies by Manifold Finance and 20Square.
- Continuously refine the system based on simulations and real-world data.
By meticulously designing and iterating on the game-theoretical aspects of Taiyi, we aim to establish a robust, fair, and permissionless market that serves preconfirmers, proposers, and end-users alike. This ongoing process of refinement and optimization will be key to Taiyi’s long-term success and adoption in the blockchain ecosystem.