BCatVM

A Fair & Programmable Runes Protocol based on OP_CAT and EVM

Introduction

BCatVM is a Fair & Programmable Runes Protocol based on OP_CAT and EVM. The purpose of BCatVM is to introduce fairness and programmability to Runes, build the infrastructure for the upcoming Bitcoin ecosystem explosion, and enable Runes to issue tokens fairly and build decentralized finance (DeFi) and other applications. As a fair Runes Protocol, BCatVM has no premine, no name length restrictions, no hard-coded runes, and nothing that we think is unfair, so that the Runes Protocol returns to fairness and nature like Bitcoin, and becomes the Runes belonging to the community, not the Runes belonging to the developers. BCatVM will be the optimized VM (Virtual Machine) based on the mature EVM (Ethereum Virtual Machine), to achieve the programmable Runes, and will use the emerging OP_CAT Covenants, to make sure the complete decentralization and trustlessness of the interaction between Runes protocol and EVM. At the same time, the BCatVM indexer will be open source, and everyone can run BCatVM Indexer, just like running a Bitcoin node, to protect the fairness and security of BCatVM in a completely decentralized way. In the future, developers can use Runes to issue assets on BCatVM and use Solidity to write smart contracts like on Ethereum. Users can mint Runes assets fairly, stake assets to get stablecoin, and quickly trade assets in AMM Swap to receive liquidity, as well as more possibilities created by developers.

Background

The Runes Protocol is a new fungible token standard on the Bitcoin network that utilizes the UTXO model and OP_RETURN data fields to create and manage digital tokens efficiently. Runes represents a groundbreaking step forward in the evolution of Bitcoin by introducing a new fungible token protocol that leverages the unique aspects of Bitcoin's architecture. Unlike previous token standards, which often relied on complex and resource intensive methods, Runes simplifies the process, making it more accessible and efficient. Runes Protocol was founded by Casey Rodarmor, who is also known for creating the Ordinals protocol. Runes are more than just another digital asset; they are a transformative protocol that enhances the utility of the Bitcoin network. But the Runes protocol is not as fair as Bitcoin. Runes Tokens can be pre-mined, the name length is limited, and there are hard-coded tokens. Also, the current Runes protocol does not have the programmability and cannot build the complex decentralized applications like the decentralized finance (DeFi).

The Ethereum Virtual Machine (EVM) is a decentralized virtual environment that executes code consistently and securely across all Ethereum nodes. The EVM is a piece of software that executes smart contracts and computes the state of the Ethereum network after each new block is added to the chain. The EVM sits on top of Ethereum's hardware and node network layer. Its main purpose is to compute the network's state and to run and compile various types of smart contract code into a readable format called 'Bytecode'. The underlying technical architecture of EVM and Bitcoin is very different. Most Bitcoin Layer 2 adopts EVM, which simply forks a side chain without solving the compatibility problem, like the address is still Ethereum Style, etc. Also the assets operations are not decentralized enough. Most of the multi signatures used are essentially trusting the multi signature person and the multi signature mechanism, not the trust on the Blockchain consensus. The asset security of the Bitcoin layer 2 solution of multi signature + EVM completely replies the multi signature people or private key holder designated by the project.

OP_CAT is an operation code (opcode) in the Bitcoin scripting language used in Bitcoin transactions. An opcode is a basic instruction that tells the Bitcoin network how to process a transaction. OP_CAT specifically stands for "concatenate" and is used to combine two data elements into a single one. With OP_CAT, developers can create more sophisticated and detailed smart contracts that require data manipulation. OP_CAT makes it easier to create and execute smart contracts on the Bitcoin blockchain. OP_CAT allows for secure cross-chain bridges, facilitating interactions between Bitcoin and other blockchains.

Finally, the Bitcoin network does not verify the new meta-protocols on blockchain, but only stores them. Although the Runes protocol saves the data on the Bitcoin network, its correctness has not been verified by the Bitcoin network. So it still requires a centralized server outside of Bitcoin to compute and index. But centralized indexers can be manipulated.

Fair Runes Protocol

The lmproved Runes Protocol in BCatVM introduces several key concepts to enhance the asset management to be Fair.

The improvements for Runes in BCatVM

No Name Limitation: Names consist of the letters A through Z and name length is open with no length limit. Spacers can only be placed between two letters. Spacers do not count towards the letter count.
No Premine: No tokens can be pre-minted. All tokens can only be public mint, no one can allocate tokens to themselves except public mint.
No Hard-Coded Tokens: All tokens are created through the etching operation, no token was hard-coded like UNCOMMON·GOODS in Runes Protocol.

Runestones

Runes protocol messages are termed "runestones".

Abstractly, runestones contain the following fields:

struct Runestone {
  edicts: Vec<Edict>,
  etching: Option<Etching>,
  mint: Option<RuneId>,
  pointer: Option<u32>,
  deposits: Vec<Edict>,
  withdraws: Vec<Edict>,
  callContracts: Vec<CallContract>,
}

Operations

Etching

Runes come into existence by being etched. Etching creates a rune and sets its properties. Once set, these properties are immutable, even to its etcher. Names may contain spacers, represented as bullets, to aid readability. The uniqueness of a name does not depend on spacers. Thus, a rune may not be etched with the same sequence of letters as an existing rune, even if it has different spacers. Spacers can only be placed between two letters. Finally, spacers do not count towards the letter count.

Runes are created by etchings:

struct Etching {
  divisibility: Option<u8>,
  rune: Option<Rune>,
  spacers: Option<u32>,
  symbol: Option<char>,
  terms: Option<Terms>,
}

Minting

Anyone can etch, mint, and transfer assets in a permissionless manner without censorship.

Tokens are minted in a decentralized manner, promoting fairness and community participation

Runestones may contain mint terms:

struct Terms {
  amount: Option<u128>,
  cap: Option<u128>,
  height: (Option<u64>, Option<u64>),
  offset: (Option<u64>, Option<u64>),
}

Transferring

When transaction inputs contain runes, or new runes are created by mint, those runes are transferred to that transaction's outputs. A transaction's runestone may change how input runes transfer to outputs.

Runes are transferred by edict:

struct Edict {
  id: RuneId,
  amount: u128,
  output: u32,
}

Deposit

Deposit tokens from the Runes Protocol on Bitcoin to EVM.

Runes are deposited by edict too:

struct Edict {
  id: RuneId,
  amount: u128,
  output: u32,
}

Withdraw

Withdraw tokens from the EVM to Runes Protocol on Bitcoin.

Runes are withdrawn by edict too:

struct Edict {
  id: RuneId,
  amount: u128,
  output: u32,
}

Rune IDs are encoded as the block height and transaction index of the transaction in which the rune was etched:

struct RuneId {
  block: u64,
  tx: u32,
}

Rune IDs are represented in text as BLOCK:TX.

Rune names are encoded as modified base-26 integers:

struct Rune(u128);

Improved EVM (Ethereum Virtual Machine)

The BCatVM is a decentralized virtual environment that executes code consistently and securely across all BCatVM Indexers. Indexers run the BCAT Virtual Machine to execute smart contracts, using Runes "gas" to measure the computational effort required for operations, ensuring efficient resource allocation and network security.

The improvements for EVM in BCatVM

Use OP_CAT to ensure the decentralization and security of the interaction between the Runes protocol and EVM.
Change the signature algorithm and add the support for the Schnorr signature algorithm.
Change the address generation algorithm to use BTC Address instead of Ethereum Style Address.
Deep integration with the Runes protocol to support the conversion of UTXO and EVM State.
Support the Auto Mapping Wrapped Runes smart contracts, so that Runes Tokens can be automatically mapped to the Wrapped Tokens in EVM, similar to the ETH coin can be mapped to the Wrapped ETH token.
Support Runes Token as gas to prevent Sybil attack.
The call of the EVM contract is saved in OP_RETURN, and the bytecode of the contract is saved in Inscriptions due to the byte limitation of OP_RETURN.

The analogy of a 'Decentralized ledger' is often used to describe blockchains like Bitcoin, which enable a decentralized currency using fundamental tools of cryptography. The ledger maintains a record of activity which must adhere to a set of rules that govern what someone can and cannot do to modify the ledger. For example, a Bitcoin address cannot spend more Bitcoin than it has previously received. These rules underpin all transactions on Bitcoin and many other blockchains.

BCatVM is a decentralized state machine. Large data structure which holds not only all accounts and balances, but a machine state, which can change from block to block according to a predefined set of rules, and which can execute arbitrary machine code. The specific rules of changing state from block to block are defined by the BCatVM.

State is a mapping between addresses and account states. It is assumed that the implementation will maintain this mapping in a modified Merkle Patricia tree. The trie requires a simple database backend that maintains a mapping of byte arrays to byte arrays; we name this underlying database the state database. This has a number of benefits; firstly, the indexer of this structure is crypto graphically dependent on all internal data and as such its hash can be used as a secure identity for the entire system state. Secondly, being an immutable data structure, it allows any previous state (whose root hash is known) to be recalled by simply altering the root hash accordingly. Since we store all such root hashes in the blockchain, we are able to trivially revert to old states.

The BCatVM is a simple stack-based architecture. The word size of the machine (and thus size of stack items) is 256bit. This was chosen to facilitate the Keccak256 hash scheme and elliptic curve computations. The memory model is a simple word addressed byte array. The stack has a maximum size of 1024. The machine also has an independent storage model; this is similar in concept to the memory but rather than a byte array, it is a word addressable word array. Unlike memory, which is volatile, storage is nonvolatile and is maintained as part of the system state. All locations in both storage and memory are well defined initially as zero. The machine does not follow the standard Von Neumann architecture. Rather than storing program code in generally accessible memory or storage, it is stored separately in a virtual ROM interactable only through a specialised instruction. The machine can have exceptional execution for several reasons, including stack underflows and invalid instructions. Like the out of gas exception, they do not leave state changes intact. Rather, the machine halts immediately and reports the issue to the execution agent (either the transaction processor or, recursively, the spawning execution environment) which will deal with it separately.

OP_CAT

OP_CAT was originally an opcode in Bitcoin. Both the original OP_CAT and the new proposals for it concatenate two elements on the stack into a single element. For example, the following script:

<0xB10C> <0xCAFE> OP_CAT

Would become:

<0xB10CCAFE>

OP_CAT (Concatenate) is an opcode in Bitcoin Script that concatenates two strings together.

OP_CAT can concatenate strings or data to form custom messages or conditions in your contract.

Example:

     OP_PUSHDATA <data1>
     OP_PUSHDATA <data2>
     OP_CAT

Bitcoin Script allows to combine OP_CAT with other opcodes like cryptographic operations (e.g., OP_CHECKSIG) or conditional operations (e.g., OP_IF):

   OP_IF
       OP_PUSHDATA <data1>
       OP_PUSHDATA <data2>
       OP_CAT
       OP_PUSHDATA <expected_message>
       OP_EQUALVERIFY
   OP_ELSE
       <alternative_condition>
   OP_ENDIF

OP_CAT will be used for the deposit and withdraw tokens between EVM and Runes Protocol, to make sure trustless and decentralized.

BCatVM GAS

The cost for computation, state transitions, and storage is called gas. Gas is used to prioritize transactions, as a Sybil resistance mechanism, and to prevent attacks stemming from the halting problem.

In order to avoid issues of network abuse and to sidestep the inevitable questions stemming from Turing completeness, all programmable computation in BCatVM is subject to fees. The fee schedule is specified in units of gas. Thus any given fragment of programmable computation (this includes creating contracts, making message calls, utilising and accessing account storage and executing operations on the virtual machine) has a universally agreed cost in terms of gas. And the gas in BCatVM will be some Runes tokens.

Smart Contracts

A "smart contract" is simply a program that runs on the BCatVM. It's a collection of code (its functions) and data (its state).

BCatVM introduces a novel approach to creating and executing smart contracts on the Bitcoin blockchain. Similar to smart contracts on other EVM chains, BCatVM smart contract operate as decentralized applications that autonomously execute predefined logic based on transactions.

BCatVM smart contracts are applications that run on the Bitcoin protocol. Each contract operates independently with its own logic and internal state. When a transaction triggers execution by BCatVM, the appropriate contract is identified, its current state is loaded, the transaction is executed according to the contract's logic, and the resulting new state is saved back to the blockchain.

BCatVM manages the smart contract's state, ensuring that each transaction updates the contract's internal data structures accordingly. Smart contracts are public on BCatVM and can be thought of as open APIs. This means you can call other smart contracts in your own smart contract to greatly extend what's possible. Contracts can even deploy other contracts.

BCatVM opcode represents a specific operation, such as arithmetic operations, logical operations, data manipulation, control flow, etc. BCatVM compiler will also produce the Application Binary Interface (ABI) which you need in order for your application to understand the contract and call the contract's functions. The ABI is a JSON file that describes the deployed contract and its smart contract functions.

By embracing an open and free development model. Anyone can write a smart contract and deploy it to the network, no censorship required. BCatVM smart contracts foster innovation while ensuring transparency and decentralization in smart contract execution. Developers are encouraged to explore the possibilities of BCatVM smart contracts to build a new generation of decentralized applications on Bitcoin.

Calling Smart Contract

BCatVM works by listening to specific on chain transactions on the Bitcoin network, interpret them based on contract logic provided in the transaction hash, and execute the contract accordingly.

Bitcoin Node: A full node that listens to the Bitcoin network for transactions.

Transaction Listener: Detects specific transactions.

BCat Virtual Machine: A virtual machine that interprets and executes contract logic based on the data stored in inscriptions and OP_RETURN.

Indexer: Indexes and parses relevant transactions. Store contract data and execution results.

Smart Contract on BCatVM

BCatVM contracts are stored on the Bitcoin blockchain as inscriptions. Contract logic and state are verifiable by any participant, ensuring trustless execution without reliance on intermediaries. Once deployed, contract inscriptions are immutable.

Smart contract inscribed on Bitcoin by inscriptions. The smart contract is saved on Bitcoin, executed and verified in BCatVM indexers, which will make Bitcoin have virtual machine to execute smart contract and computing capability like many blockchains such as Ethereum.

Decentralized BCatVM Indexers

Decentralized indexers to index and store data related to the BCatVM Protocol. Unlike centralized systems, a decentralized indexer offers greater security, resilience, and censorship resistance.

Indexers are responsible for parsing the blockchain data and indexing it for easy retrieval. They connect to Bitcoin nodes to receive blockchain data.

Each indexer should be able to share indexed data with others to ensure redundancy and availability.

Data Consistency: Ensure that indexed data remains consistent across all nodes.

Security: Implement measures to protect against malicious attacks and data tampering.

Scalability: Design the system to handle growing blockchain data efficiently.

Latency: Optimize the system to minimize latency in data retrieval.

References

NextBCAT Runes Bridge

Last updated 9 months ago