Summary

So-called trustless commit-reveal protocols that purport to allow the secure exchange of assets across chains, claim to do so even in the presence of malicious or untrusted actors. However, the realities of delayed finality mean that even these "trustless" protocols require some level of trust. In fact, we argue that truly trustless protocols based on commit-reveal schemes are actually impossible when at least one of the participants is hasty, i.e., does not wait for block finality. 

Commit-reveal protocols

Consider a scenario where participants want to play the classic game of rock-paper-scissors but are physically distant, communicating only through a designated channel to exchange information. 

Given the game’s simultaneous nature, the first difficulty is synchronization, that is, ensuring that both players cast their hands at the same time. If the game was turn-based, the player acting in the second turn would gain a decisive advantage over the first. So suppose there is a mechanism, a device, which triggers a signal upon which both players must cast their choice. What happens if player A receives the signal, but B’s reception is delayed due to latency? Player A could transmit their choice over the channel before player B has even received the signal from the device, potentially learning player A's decision before being required to commit to their own.

The second concern is the adversarial nature of the players: Player B can maliciously decide to ignore the synchronization signal and wait for Player A to show their hand. In other words, the players cannot trust that the game will be played honestly.

As is often the case with these kinds of protocols, instead of trusting the players to act synchronously and honestly, which is hard to guarantee in practice, one can make the protocol turn-based: both players first commit to an opaque representation of their choice, in order to prevent the counterpart from adapting their hand. After both players submit their commitments, they reveal their hands, which must correspond to their initial opaque representation, proving that they haven’t changed their choice.

Cryptographic hashes serve as a common mechanism for this purpose: each player first commits to their chosen symbol by sharing its hash. In the final step, both players reveal their secret hands, which must correspond to their initially committed hash. Since the symbol space is very small and hash functions are deterministic (producing the same commitment for the same symbol and thus causing symbol aliasing), additional randomness may be required, but this is merely an implementation detail. An asymmetric variant is also possible: the second player can be exempt from committing to a hash, instead only being required to send their choice after the first player’s commitment, but not before the latter’s reveal.

Finality

If the commit-reveal scheme effectively hinders the visibility of a secret to a malicious party until the very last moment, it does not shield the protocol from a differing ordering of events. Indeed, blockchains are subject to competing, different views of the state, commonly referred to as forks. Forks pose a problem to commit-reveal schemes, as they can reorder the canonical chain of events.

A transaction is said to accumulate confirmations as subsequent blocks are appended on top of the one containing it: each additional block makes it more unlikely for the chain to reorganize deep enough to orphan it. What this means in practice for a turn-based protocol is that the assumed ordering of events is not guaranteed: suppose that player Alice commits to the hash with transaction Tx1, included in blockchain’s block B, and subsequently reveals the secret with Tx2, included in block B+1. From Alice's perspective, the flow of time is linear: Tx1 was processed before Tx2 was even broadcast. However, suppose that a competing view of the blockchain forks at block B-1; in this alternative branch, block B is orphaned, and Tx1 is returned to the mempool. Yet Tx2 has already been broadcast and is equally visible there. Bob, a malicious participant, witnessing Tx2 in the mempool, now knows the secret and could play adaptively with a stronger hand in the alternative branch, effectively defeating the original purpose of the protocol. The natural remedy is therefore to require the committing party to wait for a sufficient number of confirmations before broadcasting the reveal, deep enough that a reorganization of the required depth becomes unlikely.

This confirmation “stack” is called finality, that is, the property of blocks and transactions to be irreversible, and delayed finality refers to chains that require a specific number of blocks before finality is reached. Ethereum Beacon Chain is an example of a chain with delayed finality, as it requires two epochs for a block to be confirmed as final due to the underlying Casper FFG: a first round of votes (attestations) for a target checkpoint (the first slot of an epoch) of epoch N are cast during the course of epoch N to form a majority link that elects the checkpoint as justified; a second round of attestations cast during epoch N+1 for a source checkpoint equal to the target of epoch N make the checkpoint finalized. Given that each slot takes 12 seconds and that an epoch is composed of 32 slots, a full finalization takes roughly 12.8 minutes to complete. In other words, all blocks and transactions therein between two finalized checkpoints are impossible to revert, but this also means that, in theory, a chain reorganization could happen if a fork occurs before finalization of the last checkpoint. There is also a weaker form of guarantee, by which a block becomes safe after it has been attested to by a supermajority in an epoch. This only gives guarantees against re-orgs under honest majority assumptions, but that “safety” does not hold under adversarial conditions.

In practice, though, a probabilistic, even shorter finalization time could be inferred by observing the likelihood of chain re-orgs: re-orgs as deep as 7 blocks have occurred naturally, and the more likely reorgs have depth of 1, 2 and 3 blocks; the root cause seems to be a combination of latency conditions and missed slots at the epoch boundary. In short, validators at slot 0 may be delayed by the heavier epoch-transition computation, leading the slot 1 proposer to attempt an "honest reorg" to punish the late block, and then themselves getting reorged by slot 2, creating a cascade. Indeed, a slot is about 4.78 times more likely to be reorged if the previous slot was also reorged. With EIP-4844 going live, and blobs becoming the main contributor to block size, further research shows that blob count, compressed block size, and transaction count all have statistically significant effects on reorg probability.

All this means that, in practice, waiting for a confirmation of at least 7 blocks could suffice to optimistically mark a transaction as "unlikely to revert", and hence confirm it as practically finalized, under the assumptions of the honest majority, that historical network conditions are representative of the future, and that the value at stake does not justify waiting for stronger guarantees. With this tenet in mind, it comes naturally to wonder whether there exist on-chain commit-reveal protocols that behave hastily, i.e., where the participants do not wait for enough confirmations to reach at least this weakest form of confirmation on the actual state of the protocol.

Trustless Atomic Swaps

The dominant bridge architecture nowadays requires trusted participants: when a user initiates a bridge transaction, a message is recorded on the source chain. An oracle (an off-chain entity) waits for the events to be emitted from the source chain, usually at finalized blocks. A set of bridge validators verifies that the block is finalized and puts their signatures on it. The oracle is not strictly necessary, and the validators could listen to the events themselves, but it is useful to separate the roles at least logically. The message and the signatures are then relayed to the destination chain, where a smart contract proceeds to their verification. The trust assumption is that the oracle does not behave hastily, i.e., it waits  for the required block confirmations, and that the validators set for the bridge have no majority controlled by a malicious party. If the message included in a block that was later re-organized were propagated by the oracle, the destination chain would then successfully accept it, allowing the funds to be transferred without any corresponding burning of funds on the source chain.

A radically different architecture named Hashed Timelock Contract (HTLC) proposes to be the solution to cross-chain swaps without any trusted entity, leveraging a commit-reveal scheme at its core instead. It combines two key mechanisms: a hashlock, whereby funds can only be released if the recipient provides a secret value (preimage) that hashes to a predetermined hash, and a timelock preventing funds from being locked forever. In its most basic form, Alice generates a secret S, computes H = hash(S), and keeps S private. Alice locks her funds on the source chain’s HTLC contract, which unlocks the funds only if Bob, the designated recipient, presents a valid preimage that hashes to the hashlock. Bob sees the hashlock H on-chain and locks his funds with the same hashlock in the destination chain’s HTL contract. The latter unlocks the funds only when presented with the valid preimage, which only Alice knows at this stage. Alice claims Bob's funds on the destination chain by submitting secret S to the destination contract; this reveals S publicly on-chain. Bob sees S on the destination chain and uses it to claim Alice's funds on the source chain. If one of the participants refuses to cooperate, the other can always redeem their funds after the expiration time.

While elegant and apparently trustless, this design presents practical challenges: users are responsible for managing the secret, and, most important of all, they must independently keep track of the protocol's current state. 

A revised version, named PreHTLC, proposed by a company that wishes to remain anonymous, is shown below. The difference is that, with the first commit transaction (step 1), the User only manifests their intent to swap, but there is no hashlock yet; it’s the Solver, a trustless, off-chain entity, to generate the secret and lock their funds in the destination chain with a hashlock, designating the User as the recipient (step 2). The User learns the hash H as an on-chain event on Chain B and finalizes their initial commitment by adding a lock with the hash that the Solver produced (step 3). At this stage, the User does not know the secret S, in contrast to the regular HTLC. User’s addLock triggers the Solver to redeem the funds in Chain A (step 4) by submitting the preimage secret S, whose hash matches the hashlock. This action reveals the secret to the User, who can present it in Chain B to redeem the funds (step 5). The latter action could also be performed by the Solver or any other entity, since the only designated recipient is the User.

This variant delegates secret management to an off-chain component, but it does not introduce any additional trust assumption, as the Solver does not need to be a trusted party. Or does it?

Let’s see what happens when the Solver behaves hastily (which is the current behavior at the time of this writing). The solver does not wait for any confirmation and acts as soon as it observes the events, emitted as logs and hence coalesced in the latest block. Suppose that source chain A has delayed finality (e.g., Ethereum) and destination B has near-instant finality (e.g., Solana). A block marked as latest is the most recent block on Ethereum and may be re-orged out of the canonical chain even under normal conditions. It is therefore plausible to assume that the addLock transaction can be re-orged.

In the first run of the protocol, the User and the Solver reach Step 5 in Destination Chain B, which has near-instant finality. Therefore, all transactions on Chain B are finalized, while those in Source Chain A, namely transactions for Step 3 (User's addLock) and Step 4 (Solver's redeem in Source Chain A), are not. A fork occurs in chain A and re-organizes the tip of the chain so that Tx "User's addLock" and Tx "Solver's redeem" are excluded, and the source chain reverts to the state where only the User's initial commit transaction is present. The User could therefore re-send the addLock Tx with an invalid hashlock that won't match the original secret S calculated by the Solver. To ensure this new addLock Tx is favored over the original one (which is now pending due to the re-org), they could select higher fees. When the Solver's redeem Tx re-executes on source chain A at Step 4, the transaction will fail: the Solver doesn't know the new pre-image with which the User set his addLock Tx, hence they will never be able to redeem their funds in the alternative branch of the fork. The User waits for the timelock to expire and, in the end, invokes a refund to claim back their initial deposit. The transactions in Chain B were already finalized, hence the User had already benefited from the last redeem transaction at Step 5 in Chain B. As a result, the User manages to claim both funds in both chains, whereas the Solver loses what he had locked in step 2.

Alternatively, consider a scenario where the finality of the chains is swapped: Chain A achieves near-instant finality, while Chain B has delayed finality. If the User does not wait for confirmation of the Solver’s lock transaction at step 2, then, when the latter is re-orged in Chain B, the Solver could re-send the lock with a different hash, preventing the User from claiming the funds in step 5.

The attentive reader would notice the same attack scenario holds for the “vanilla” HTLC: therein, if the first transaction in Chain A is re-orged, then Alice could re-submit a new one with a different hashlock, impeding Bob from claiming the funds with the original secret S. At the same time she would need to make the original transaction, which is now pending in the mempool, fail, for example, by making sure she doesn’t possess enough assets to complete it.

Based on these observations, we argue that it is impossible for any similar protocol to function securely without some reliance on trust assumptions, despite any claim to the contrary: the participants can be both hasty and malicious. When they behave hastily, not waiting for block confirmations may lead to one of them losing their funds to the malicious counterpart. Since participants cannot force the others to be non-hasty, they must be trusted to be honest, lest the others risk abuse. Equivalently, since participants cannot trust the others to be honest, they must behave non-hastily to escape abuse. However, while a participant's decision to wait for finality is a necessary act of “self-defense”, it does not ensure the protocol's integrity if the other party is hasty. For instance, the Solver waiting for finality only safeguards the Solver; the User must either act non-hastily or, equivalently, must expect the Solver not to behave maliciously, but they could still abuse the Solver if the latter is hasty. And vice versa. Furthermore, "non-hastiness" must apply to all participants, not just a subset. If even one participant is hasty, they inherently trust that the others will not exploit this hastiness maliciously.

While avoiding trust might appear straightforward in practice by simply waiting for finality, enforcing even the weakest form of finality for all parties is non-trivial: for example, in the preHTLC, the contract in chain A could make the Tx at step 4 revert if not enough time has passed since the addLock Tx at Step 3, making Step 3 effectively finalized so that the User could not override addLock in the alternative branch to abuse the Solver. When the situation is reversed, however, no equivalent in-protocol remedy exists. One could argue that the User should simply wait for sufficient confirmations of the Solver's lock transaction at Step 2 before proceeding to Step 3. Yet this relies entirely on off-chain self-discipline: nothing in the contract can force the User to observe this delay. A contract-level enforcement analogous to the one described above would require chain A to verify the finality of a transaction on chain B, that is, it would demand cross-chain finality proofs, likely via a light client or a trusted bridge, exactly the sort of architecture that HTLC-like protocols are intended to be an alternative to. Therefore, there is no practical way to protect the User from performing Step 3 before Step 2 is finalized on chain B, giving the Solver the opportunity to substitute the original hashlock of Step 2 in the event of a re-org. The same considerations apply to the basic HTLC.

When thinking about it, the commit-reveal scheme appears superficially to be a mechanism designed to mitigate the issue of choice visibility within turn-based protocols; however, at its core, it really functions as a primitive to induce a strict temporal ordering of events. As shown, in networks characterized by delayed finality, this ordering cannot be enforced but only assumed.