Auditing RGB consensus and underlying libraries

[dr-orlovsky]

Structure of the libraries involved in the audit

A possible RGB consensus audit should consist of two blocks:

1. Audit of underlying client-side-validation commitment schemes, which main purpose is the prevention of double-spending using bitcoin blockchain
2. Audit of RGB state history validation rules according to RGB schema (smart contract declarative rules and AluVM scripts)

Client-side validation commitment schemes

Client-side validation uses a hierarchy of commitment schemata, implemented as different rust modules, abstracted from each other and designed to solve specific tasks required for the overall commitment structure to work. These tasks include:

1. General algorithms for Merkle tree and Merkle path proof construction, and verification, which (unlike other algorithms) commit to tree parameters (width) and the specific place in the tree. These algorithms are designed after Peter Todd suggestions.
2. Multi-protocol commitments (MPC, also known as LNPBP-4), which is a novel commitment scheme. It uses Merkle trees in a way where commitments under multiple protocols (in the context of RGB these "protocols" are separate RGB contracts) can be structured into a Merkle tree such that it can be proven that the tree contains only a single commitment under each of the protocols without revealing the protocol or commitment information.
3. Deterministic bitcoin commitments (DBC) allow putting a commitment inside a bitcoin transaction in such a way that it can be proven that the transaction may contain only a single commitment. RGB uses two specific schemata from DBC implementation: tapret and opret. The former is a Taproot-based OP_RETURN commitment, where OP_RETURN instruction with the commitment exists under a specific branch of the Taproot tree (and thus is never present in the explicit form onchain); the latter is just usual OP_RETURN-based commitments, where the allowed place for the commitment is always the first transaction output containing bare OP_RETURN opcode.
4. Bitcoin transaction output-based single-use seals commitment scheme. Single-use seal-based commitments is a cryptographic primitive which unlike usual commitment scheme allows the creation of provably singular commitment, and is the foundation of how double-spending is prevented in the RGB protocol.

There are two main repositories containing all the above four components:

• client_side_validation, with commit_verify crate in it, which most critical parts are
  • merklization and
  • multi-protocol commitments business logic;
• bp-core, with bp-dbc and bp-seals crates in them, where the main parts are
  • Tapret commitments
  • Transaction output-based seals

RGB consensus

The whole of RGB consensus code exists in rgb-core repository and consists of the following components (structured as crate modules/directories under src):

1. schema: a declarative formalism for defining RGB smart contracts. The schema allows defining types of RGB contract state (which can be owned by some party via bitcoin UTXO - or be global) and rules for state transitions. Additionally, for implementing complex parts of business logic schema may contain validation scripts (which further restricts rules of state transition validation) written for AluVM virtual machine using AluVM bytecode (see below).

2. contract: data types and structures of how the contract data are stored by the client (genesis, state transitions etc).

3. validation: the main code performing verification of the contract state run by each user when it receives an RGB transfer. Verification iterates through a DAG of past RGB state transitions for a single given contract (different contracts are abstracted from each other) up to genesis and checks the satisfaction of two conditions for each DAG node (RGB operation):

• proper commitment of the state transition data (though MPCs and DBCs) into a bitcoin transaction (the system relies on the information of valid transactions received from Bitcoin Core or a lightning node through an abstracted "resolver API");
• valid state changes matching the restrictions defined by the schema and validation AluVM scripts

4. vm: RGB-specific components for AluVM virtual machine, which includes calls to the AluVM and RGB-specific additional operation codes related to Pedersen commitments extending basic AluVM instruction set architecture doing arithmetics, string operations, hash functions and Secp256k1 elliptic curves.

Questions the audit should answer:

1. Are the cryptographic commitment schemes used in the RGB and client-side validation secure under the assumption of the SHA-256 hash function and Secp256k1 curve being secure?

2. Is there a possible way for creating double commitments which opens a way to exploit double-spending at both levels of client-side-validation libraries (doing the commitment schemes) or how does RGB validation code call these libraries?

3. Does the code contain any backdoors or a functionality which is not required and may be misused?

4. Which possible attack vectors on the external/underlying dependencies can exist which may lead/introduce double-spending vulnerabilities into the RGB?

5. Does the RGB verification code perform all necessary validation for each of the RGB operations for both single-use seal commitments and RGB schema and script?

6. Does the RGB verification code verify all possible rules which can be defined using RGB schema language and AluVM scripts?

[drNeubauer]

Ты крут, док!