Markets

A New Blueprint for Bitcoin Contracts: Off-Chain Efficiency, On-Chain Guarantees

Abstract and 1. Introduction

  1. On-chain contracts
  2. Off-chain contracts
  3. Conclusions and References

Abstract

We consider the execution of smart contracts on Bitcoin. There, every contract step corresponds to appending to the blockchain a new transaction that spends the output representing the old contract state, creating a new one for the updated state. This standard procedure requires the contract participants to pay transaction fees for every execution step.

In this paper, we introduce a protocol that moves most of the execution of a Bitcoin contract off-chain. When all participants follow this protocol, they are able to save on transaction fees. By contrast, in the presence of adversaries, any honest participant is still able to enforce the correct execution of the contract, according to its original semantics.

1. Introduction

Moving the computation off-chain to save on fees has become a popular means to scale the blockchain smart contracts processing capabilities, making them more practical. To this aim, a variety of methods has been considered, in particular over account-based blockchain such as Ethereum [1, 2, 3]. In this work, we instead focus on Bitcoin smart contracts.

While limited by a non Turing-complete scripting language, Bitcoin still allows the implementation of a broad class of smart contracts [4, 5]. Some simple contracts can be expressed using a single Payto-Script-Hash transaction that encodes a suitable spending condition. However, exploiting multiple transactions it is possible to implement more complex Bitcoin contracts, allowing multiple rounds of interaction among participants [7, 6].

Users who want to deploy a multi-transaction smart contract on Bitcoin can do so with the following standard technique: first, they generate a tree of transactions that describes the possible evolution of the contract, then they sign all the transactions in the tree, and finally they append to the blockchain only the transactions in a single tree path, according to participants’ choices. A downside of this approach is that every contract step corresponds to appending a transaction to the blockchain: this is expensive in terms of fees.

In this paper we propose a protocol to move most of the execution off-chain, while still guaranteeing the same contract behaviour. In this protocol participants simulate the contract by exchanging off-chain signatures. In the optimistic case, in which all participants are honest and follow the protocol correctly, they only need to append three transactions to the blockchain. This does not depend on the number of transactions in the original contract.

Our off-chain protocol has a failsafe mechanism that can be triggered whenever someone detects malicious behaviour. This mechanism moves the contract execution back on-chain, safeguarding the contract behaviour from malicious actors. Even in this negative scenario, the steps that were completed off-chain are preserved, reducing the amount of on-chain steps needed to get the contract to completion. When the failsafe is triggered, participants need to pay the fees associated with the remaining contract steps and wait for a few additional time delays. The fees that are saved by the off-chain execution can be distributed to the participants when the contract terminates: this serves as an incentive for participants to correctly execute the off-chain protocol.

While our technique is designed to be executed on Bitcoin as-is, it only relies on the fundamentals of the UTxO model, as well as timelocks, a widely adopted primitive in UTxO blockchains, making our approach easily adaptable to other UTxO platforms.

Contributions We summarize our contributions as follows:

• We outline a general technique to transform a on-chain Bitcoin contract into an off-chain contract.

• We showcase our technique through a simple example.

• We discuss the security and efficiency of our protocol.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button