Implement smart contracts on Bitcoin by simulating the Bitcoin virtual machine.
Original link: https://github.com/atomicals/avm-whitepaper/blob/main/avm.md
Summary
To date, all overlay digital asset protocols on Bitcoin have followed fixed rules for creating and transferring digital assets. By allowing programmers to define state machine logic to create and manage these rules, we can make fully flexible (Turing complete) smart contracts for overlay digital assets. We propose a solution that uses Bitcoin as a global database, stores smart contract code in transactions, and executes this code in a sandboxed environment through the overlay digital asset indexer. The original Bitcoin Script opcode instruction set is adopted as the programming language because it has all the necessary properties for efficient execution in a resource-constrained environment. State hashes are used to track overlay transactions and provide participants with a convenient way to verify their synchronization status. Our proposed solution is a natural evolutionary step for Bitcoin overlay digital asset protocols, and also a platform for testing the original Bitcoin opcodes, demonstrating their flexibility and security.
1 Introduction
The Bitcoin peer-to-peer electronic cash system [1] was originally used primarily as a store of value, hence the name “digital gold”, while its function as a medium of exchange was secondary. Before Satoshi Nakamoto left, he disabled many primitive opcodes (Op Codes) used for advanced scripting for security reasons, especially to avoid potential denial of service attacks. These disabled opcodes mainly include arithmetic and binary operations, which are the basic operations that developers rely on in the most basic programming environments. Without the support of these key opcodes, the available functions for Bitcoin application developers and end users are very limited. In particular, the “OP_CAT” (data connection) opcode, which could have been used to create custom spending and transfer constraints, so-called contracts. Therefore, due to these historical decisions, Bitcoin failed to become the powerful smart contract platform originally envisioned by Satoshi Nakamoto, and can only exist as a kind of digital gold. In short, due to the disabling of these key opcodes, Bitcoin had to exist only as digital gold and could not develop into a complete smart contract system to protect this emerging electronic cash system.
“The nature of Bitcoin is that once version 0.1 is released, its core design is fixed for the lifetime of the blockchain. Because of this, I intended to design it to support every transaction type I could think of. The problem is that each transaction type requires special supporting code and data fields, which can only handle one specific case at a time, regardless of whether they are used. This can lead to a lot of special case bloat. Script provides a solution by generalizing the problem so that parties can describe their transaction as a predicate to be evaluated by a network of nodes.” — Satoshi Nakamoto[2]
Since Bitcoin first disabled some opcodes, multiple protections have been introduced. One important limitation is MAX_SIGOPS, which limits the maximum number of signature operations allowed in any particular transaction. Looking back in history, we can observe how these original opcodes behave in forked versions of Bitcoin such as BSC and BSV; these forks reactivated most of the original opcodes a few years ago. So far, these opcodes have not caused any security issues or denial of service attacks, and have caused almost no controversy. On the contrary, they have greatly expanded the development potential of these Bitcoin forks.
Despite the current limitations of Bitcoin smart contracts, a number of overlay protocols have emerged that allow for the creation and transfer of digital assets on Bitcoin itself. The first mainstream non-fungible token standard was a protocol called Ordinals, which was followed by a fungible token standard, BRC20. Soon thereafter, more other digital asset protocols emerged, such as Atomicals digital objects and ARC20, the latter of which utilizes the satoshi unit as the unit of account, as well as Bitcoin Stamp and the more recent Runes fungible token protocol (released in April 2024). This generation of overlay protocols essentially creates and manages digital assets through Bitcoin transactions, and overlay protocol indexers track and manage the lifecycle of digital assets by reading data directly from special Bitcoin transactions. What is missing from these protocols is the ability for developers to customize the behavior of digital assets - until now, there has been no way to create advanced smart contracts for these overlay protocols.
We propose a method to create and execute smart contracts for various overlay digital assets by emulating the Bitcoin virtual machine and its script interpreter. In this method, the Bitcoin blockchain not only provides timestamps and data for smart contract programs stored on the chain, but also the execution of these programs is carried out in a sandbox environment through various overlay protocol indexers. Overlay protocol indexer nodes are jointly managed by application developers, service providers and users, and together form a spontaneous consensus. This concept and its technology are widely applicable to all overlay protocols, and only need to be appropriately adjusted for the respective overlay protocol indexer.
We have demonstrated the power and elegance of the original Bitcoin design. This new paradigm serves as a platform for testing a wide range of opcodes—albeit for digital asset overlay protocols—and we hope that Bitcoin will eventually re-enable all of the original opcodes, thereby unlocking the full potential of Satoshi’s creation.
2. Bitcoin as a global database
The Bitcoin network is essentially a distributed timestamp server designed to solve the double-spending problem. The system is designed not only for the transmission and storage of monetary transactions, but also for storing data such as invoices and large files. Satoshi included various opcodes such as OP_RETURN, which allows arbitrary data to be appended, and OP_PUSHDATA4, which allows data to be pushed up to 4GB. Even the first Bitcoin transaction - the genesis transaction - included arbitrary text data: "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks".
Over the years, attempts have been made to prevent Bitcoin from being used as a data storage medium by limiting the maximum push size to 520 bytes and limiting the use of OP_RETURN to 40 bytes (later extended to 80 bytes). Indeed, this was seen as an attack vector that could lead to runaway "blockchain bloat" and crowd out pure monetary use. This seemed like a reasonable protection at the time.
In recent years, Bitcoin developers have effectively reintroduced the ability to store large amounts of arbitrary data similar to earlier versions of Bitcoin by introducing Segregated Witness (SegWit) and the Taproot upgrade. Application developers have quickly taken advantage of this opportunity to use Bitcoin as an immutable global ledger to store valuable data. The digital asset market on Bitcoin has seen exponential growth, reaching a market capitalization of billions of dollars and generating hundreds of millions of dollars in network fees for miners in a relatively short period of time.
3. Overlay Protocol
Hal Finney proposed and predicted the concept of using Bitcoin as a global, decentralized, consistent database to support "overlaying other protocols". The basic idea involves creating overlay assets through signaling and associating these assets with a specific transaction history. This mechanism adds a new dimension to Bitcoin as a monetary system, namely that transaction outputs themselves can represent any other type of digital asset, such as tokens, points, digital media, or even proxy rights to physical assets.
“In a discussion on the BitDNS thread, I brought up the idea of overlaying other protocols onto Bitcoin. From a certain perspective, Bitcoin is a global, decentralized, yet consistent database.
This database is primarily used to record transfers of coins, but it can be used for many other things. Many applications can benefit from a globally consistent database. According to my description of BitDNS, this mechanism will be implemented by adding additional data to regular Bitcoin transactions using an arcane and complex system of "scripts". This data will appear as NOPs (no operation instructions) to current clients and be ignored, but overlay protocol-aware clients will examine the additional data within these NOP blocks and interpret it according to the overlay protocol.
Specifically, I can imagine using OP_NOP1 to mark the overlay data, then using OP_PUSHDATA to push specific data, then using OP_DROP to remove the data from the stack, and finally executing the regular transaction opcode. This has no effect on regular clients, and looks like a normal transaction (it can be a virtual transaction, such as transferring 0.01 bitcoins to yourself), but the code that can recognize the overlay protocol will recognize that this is a protocol transaction.
For example, Bitcoin can be used as a cheap timestamping service, allowing you to prove that a document existed before a certain date. All you need to do is create a dummy transaction to yourself and modify your client to do an OP_PUSHDATA operation, push the hash of the document in, and then remove it from the stack with an OP_DROP. The hash will live permanently in the blockchain as proof that the document existed on that date." - Hal Finney[3]
The first widely used overlay protocol is the Ordinals theory. According to the Ordinals manual, a single satoshi can burn any content to create a unique Bitcoin-native digital artifact. These artifacts are durable, immutable, secure, and decentralized, and can be stored in a Bitcoin wallet and transferred through Bitcoin transactions.
In 2023, developers realized that a homogeneous token standard was needed on Bitcoin, so they developed BRC20. BRC20 uses the Ordinals theory to establish an overlay account model associated with a wallet address, enabling it to send and receive token units. In fact, it creates a layered overlay protocol based on Ordinals, which is itself an overlay protocol based on Bitcoin.
By early 2024, a new protocol called Atomicals Protocol Digital Objects has emerged in response to the continued growth of the market for token standards and indexing technology. As described in the Atomicals Guide, the Atomicals Protocol is a simple but flexible protocol for minting, transferring, and updating digital objects (commonly known as non-fungible tokens) on blockchains that use unspent transaction outputs (UTXOs), such as Bitcoin. Atomicals (or "atoms") are a way of organizing chains of digital ownership according to a few simple rules. The Atomicals Protocol also includes a fungible token standard called ARC20, where each token unit is backed by at least one satoshi unit and operates using the same UTXO architecture as Bitcoin itself.
In early 2024, another overlay protocol called Runes was released, which was implemented directly into the Ordinals Indexer to complete the functionality of the Ordinals theory, eventually also including a fungible token standard.
4. State Machine
So far, all overlay protocols on Bitcoin run based on fixed or predefined state machines. These overlay protocols have two main components: one is responsible for signaling to create digital assets, and the other is the rules that govern the transfer of these digital assets. These state machine rules are hard-coded in the respective overlay protocol indexers, and developers cannot customize the creation or transfer rules.
We propose a dynamic state machine programming model that allows developers to fully define the creation and transfer rules of their digital assets. This essentially enables developers to define their own meta-overlay protocol rules without creating new protocol indexers, but rather leveraging existing overlay protocol indexers.
The basic idea is to allow developers to store their smart contract code on the blockchain, making it readable and interpretable by all parties involved. By storing the code on the chain, it is ensured that the logic is executed in the same way in distributed and unconnected parties, thus facilitating the synchronization of states. A smart contract programming language should have the following important properties:
Deterministic and predictable runtime.
Allows arbitrary flexibility (Turing completeness) [4].
and can run efficiently on resource-constrained systems.
From these requirements, it can be seen that Bitcoin Script is very suitable for use as an instruction set to define the rules for the creation and transfer of digital assets. The key is that it needs to support any type of state transition while limiting the execution time to prevent service denial attacks and infinite program loops. Bitcoin Script is Turing complete. It is a two-stack push-down automaton (2-Stack PDA). Due to the use of loop unrolling technology, loops are not allowed, so the running time is predictable and linear with the length of the program.
Smart contract program code is stored in Bitcoin transactions, and the Overlay Protocol Indexer loads the code into memory and executes it consistently. All parties involved can execute the same logic and reach the same state transition.
5. Status Consensus
The synchronization of states can be achieved through state hashing, a mechanism that communicates the internal state of the Overlay Protocol Indexer to external observers. By exposing the state hash, distributed parties can easily determine whether they are following the same rules and are in sync with each other.
Since all data is stored on-chain and timestamped in chronological order, there is no need for complex state commitment synchronization mechanisms. This allows anyone to come to a consistent state result while following the same rules.
6. Virtual digital assets
Any overlay protocol can adopt this dynamic state machine programming technique, allowing digital assets to be virtualized and materialized in smart contracts. Essentially, this means that we can think of the concept of deposits and withdrawals as a contract, because everything else is a contract to build the indexer state based on the complete transaction history on the blockchain.
In BRC20, a token balance is an abstract representation of an account and can be described as a virtual digital asset - a digital asset on top of another digital asset (Bitcoin). Atomicals ARC20 tokens are abstractions that maintain affinity with the underlying satoshi unit, but they are also a virtual digital asset. More accurately, they are called "virtual digital assets" because they exist as an abstraction on top of another digital asset (Bitcoin).
Extending this analogy further, we can define a state machine that allows any type of token to be deposited into a contract and later withdrawn, similar to how the Solidity programming language of the Ethereum blockchain allows methods to be marked as payable, indicating that ether can be paid to the method and later withdrawn according to the rules of the smart contract program. Tracking and management of these digital assets can be accomplished through special opcodes such as OP_FT_WITHDRAW and OP_NFT_WITHDRAW, as well as a mechanism that allows payable methods in the smart contract state to accept tokens.
7. System Architecture
To ensure consistent execution of scripts, the script interpreter is set in a sandbox environment with static or dynamic binding and clear boundaries. This setting enables different programming languages and environments to call the sandbox and obtain consistent results, thus ensuring consistent execution.
The sandbox interpreter is a simplified version of the Bitcoin script interpreter, which differs in some key aspects, such as it can directly accept execution lock script (scriptPubKey) and unlock script parameters (scriptSig), as well as some other useful parameters that facilitate virtual digital asset management. The purpose of these designs is to simplify and enhance the processing and management of virtual digital assets, so that they can operate more efficiently and securely on the Bitcoin network.
8. Conclusion
We propose a system to implement smart contracts for overlay digital assets on Bitcoin by emulating the Bitcoin Virtual Machine. To date, overlay digital assets on Bitcoin are completely subject to predefined state transition rules that only allow the creation and transfer of these assets. To address this limitation, we develop a general technique that uses Bitcoin as a global database, stores smart contract code in transactions, and executes this code in a sandbox runtime environment of an overlay digital asset indexer.
The original Bitcoin Script instruction set is very powerful because it implements a two-stack push-down automaton (2-Stack PDA) that has been proven to be Turing complete. Our system uses state hashing so that all participants can easily verify that their indexer states are correctly synchronized. This system is designed to be very flexible and is not only a natural extension of existing overlay protocols, but also demonstrates the great potential of the original Bitcoin Script language. This approach provides more advanced capabilities to overlay protocols within the Bitcoin ecosystem, enabling them to support more complex smart contract applications.
references
[1] Satoshi Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System" https://bitcoin.org/bitcoin.pdf, 2008.
[2] Satoshi Nakamoto, "The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime...", https://satoshi.nakamotoinstitute.org/posts/bitcointalk/126/, 2010.
[3] Hal Finney, "In discussion on the BitDNS thread I came up with an idea for overlaying other protocols onto Bitcoin...", https://bitcointalk.org/index.php?topic=2077.msg26888, 2010.
[4] Wikipedia contributors. "Turing completeness." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/wiki/Turing_completeness, 2024