Inscription Standard

Check the Bitcoin Inscription Standard used by VIA Protocol.

We view Bitcoin as a secure and decentralized "wall" for inscribing arbitrary data. At the interpretation level (encompassing the Sequencer and Verifiers) we retrieve and process this data according to predefined rules governing interactions between different parties. These rules are formalized in the VIA Inscription Standard.

Introduction

VIA protocol needs Bitcoin blockchain to serve as the single source of truth. Unlike Ethereum, which has the Ethereum Virtual Machine (EVM) providing significant flexibility for designing various protocols, Bitcoin offers limited scripting capabilities. The available opcodes in Bitcoin’s scripting language are not directly related to our needs.

Given these constraints, we had to solve our problem indirectly using the available opcodes. One of the capabilities VIA Protocol leverages, is the ability to write arbitrary data onto the Bitcoin network. This concept of embedding arbitrary data onto the Bitcoin blockchain is referred to as inscription within the ecosystem and it allowed us to establish a single point of truth for our protocol on the most secure and decentralized blockchain.

How Inscriptions work?

This section explains a different approaches for inscribing data on the Bitcoin blockchain.

Using OP_RETURN

This method involves spending a small amount of BTC and creating another UTXO with the OP_RETURN opcode to write data. The data is revealed in the output section of the transaction.

• Advantage: Requires only one transaction and implementation is simple.

• Disadvantage: It is more expensive because the data is not written in the witness section.

Using TapScript

Enabled by the Taproot fork on the Bitcoin network, this approach stores data in the witness storage instead of the UTXO chain-state database, making it significantly cheaper than using OP_RETURN. The mechanism is straightforward. Inscription content is serialized using data pushes within unexecuted conditionals, called "Envelopes” OP_FALSE OP_IF … OP_ENDIF :

let taproot_script = ScriptBuilder::new()
    .push_slice(encoded_pubkey.as_push_bytes())
    .push_opcode(all::OP_CHECKSIG)
    .push_opcode(OP_FALSE)
    .push_opcode(all::OP_IF)
    .push_slice(encoded_data)
    .push_opcode(all::OP_ENDIF)
    .into_script();

• First, OP_FALSE is pushed onto the Bitcoin Stack-based validation machine. An if-statement with OP_IF is then used. The default behavior of this opcode is to execute the code within the if-statement if the latest value in the stack is interpreted as "true". However, by pushing OP_FALSE onto the stack, we ensure the code within the if-statement does not execute.

• Nevertheless, the code in this section becomes part of the Bitcoin blockchain data. By writing arbitrary data here, we can use this approach for inscription at a lower cost.

• Advantage: 4 times cheaper then OP_RETURN option since the data is written in the witness section of the transaction.

• Disadvantage: Requires 2 transactions (commit & reveal) and it is more complex to implement.

VIA Inscription Standard

Witness data structures for different message types inscribed and used by the various components of the VIA Protocol can be seen here.