LNP/BP Standards Association presents the final production-ready release of the consensus layer for the new generation of RGB smart contracts (version 0.12).
All RGB contract issuers can now issue contracts on testnet and bitcoin mainnet using this consensus release. For the sake of security and consistency of software across the ecosystem, it is recommended to re-issue all previously-issued contracts (made with pre-release versions) using this final v0.12 version.
This is a consensus layer release. It will be followed by releases of the standard library and applications. The consensus layer is unique among RGB libraries because it defines contract stability: only changes at the consensus level can break backward compatibility for contracts. Therefore, with this final v0.12 release, contracts are now forward-compatible.
What's new
The version 0.12 of RGB represents a result of 8 months of protocol re-design, aimed at the following:
- Make protocol ready for zk-STARK compression;
- Simplify the protocol as much as possible, reducing any potential attack surface and helping protocol adoption;
- Ensure security of the protocol with thorough unit and integration test coverage, including tests for potential attacks;
- Make protocol fully production-ready by freezing consensus level changes and ensuring robustness and performance.
1. zk-STARKky RGB
The new RGB architecture for the first time introduces zk-AluVM, which is a compact and performant Turing-complete zk-VM made for client-side validation. While being universal, it offers a non-von-Neuman architecture with an extra-reduced instruction set, made of just 40 instructions and provides read-once memory compatible with single-use seals.
The contract state was also transformed. Previously, RGB contracts had three variants of state data: fungible (with Pedersen commitments and Bulletproofs), non-fungible structured state and binary attachments. To make the contract state zk-compressible, version 12 unified state into a single type, made of finite field elements.
The whole consensus validation was reduced to just a few hundred lines of code, which can be represented as an arithmetic circuit for a zk prover, allowing recursive history compression.
All these changes not just make RGB ready for zk-STARK provers and verifiers, but also allow use of RGB with the future client-side validation layer 1 codenamed Prime.
2. Protocol simplification
RGB so far has been notoriously infamous for the protocol complexity. Version 0.12 should shift that impression, since most of the changes in it were an actual simplification of the protocol.
Overall, we have achieved x4 reduction in the size of the consensus code and x2 reduction in standard libraries, as well as a significant reduction in the number of data types, and removal of ~30% of generic type parameters in the APIs.
Such simplification provides several gains:
- much reduced attack surface;
- better auditability;
- better performance;
- better developer experience;
- which opens a way for building simpler UX with improved user experience.
Below, we cover some of the technical details of the main simplifications which has happened in v0.12.
2.1. Seal unification
RGB uses single-use seals, a cryptographic primitive, to prevent double-spending by "anchoring" into a UTXO-based blockchain or a sidechain.
Previously, there were two different types of single-use seals, which can be used by an RGB contract: so-called tapret and opret-based. Tapret seals can't be seen inside a bitcoin transaction, but require a taproot wallet, which still is not fully supported by all exchanges, hardware wallets or Lightning nodes. Opret is an answer to that; it utilizes old OP_RETURNs to put a 32-byte commitment into a bitcoin transaction; which has many drawbacks (higher transaction price), exposure to chain analysis, etc., but helps when a wallet or a user can't use taproot.
However, the presence of two distinct seal types, where a user chooses one of the variants, had created tremendous complexity, both in code, APIs and in user experience, and resulted in a large attack surface.
In v0.12 we found a beautiful way how to unify two distinct seal types into a single-one, yet still supporting OP_RETURN fallback option.
2.2. Removal of Pedersen commitments and Bulletproofs
Since the inception of RGB protocol, it was using confidential assets by Blockstream for providing contracts with a fungible state. While the idea of confidential assets has been great, it was lacking an efficient implementation, postponing use of RGB in production.
The problem was that the original Blockstream implementation of confidential assets for Liquid (and the Elements project) used older range proofs instead of bulletproofs, which are much larger and longer to validate. On the other hand, Bulletproofs were never implemented for the Bitcoin SECP256K1 curve, while the RGB community and devs have been waiting for this implementation for more than 5 years.
With the introduction of zkVM and zk-STARK compatibility, Bulletproofs and Pedersen commitments have become unneeded, since zk-STARK can provide much better performance and offers a range of ready-to-use implementations.
2.3. State unification
With the removal of Pedersen commitments and Bulletproofs, and the introduction of zkVM, we were able to simplify and unify the state of RGB contracts. Previously, an RGB contract may have three forms of a state: fungible, structured (non-fungible) and blob attachments. In v0.12, this state is unified under a single state type, which, again, reduces the codebase and the attack surface.
2.4. No more schemata
zk-AluVM has changed a lot: with zk-STARKs, we need to be able to represent everything in the consensus in an arithmetized form. Thus, we got rid of the old way of writing RGB contracts with schemata and unlocked the real potential for smart contract programming with Turing-complete zk-AluVM assembly and higher-level languages on top, like Contractum.
From the point of view of contract issuers, now, instead of importing schemata, interfaces and other components, they will be using so-called issuers, provided by the contract developers. The users will be also less confused with an obscure terminology.
2.5. Single-blockchain protocols
Since v0.11, RGB supported multiple blockchains. In v0.12 we made it simpler: instead of allowing a contract to operate on multiple blockchains, each blockchain will have its own version of the contract, which significantly reduces possible attack surface and API complexity.
2.6. Re-org support
As any blockchain-based system, RGB depends on what happens there, and one of the main issues with blockchain deep reorgs, which may lead to the loss of funds by the users. The problem was never properly addressed in RGB, until in 2024 we discovered a type of attack which can leverage even shallow reorgs.
For the version v0.12 we have developed and implemented a mathematical model, formally proving how the system can be protected from such attacks, even if multiple and deep re-orgs happen or got combined.
3. Performance
Performance was one of the pain points of the past RGB release. In version 0.12 we did a huge work to bring it up to the production requirements.
3.1. Consignment streams
Transfer of client-side data during RGB payment is made in the form of a binary data sent from a payer to a beneficiary, possibly via a relay. These binary data packs are named consignments.
Before, consignments were distributed in the form of files, and, before being validated and accepted, have to be fully read into memory by a receiver. Since consignments may span multiple megabytes, this was putting high resource requirements and made it nearly impossible to use hardware wallets for verification.
In v0.12 consignments have become streams, which are never put into the memory and are validated on the go, as they are received, not ever taking more than a few hundred bytes of memory (!!!). This is much more suitable for mobile wallets, servers, and paves the way for the hardware wallet applications.
3.2. Consignment verification
It is not that the consignments are no more read into the memory; during their validation, the RGB software doesn't make requests to a blockchain indexer. Before, the consignment validation was slowed manifold due to the requests; now, the blockchain index synchronization is separated from the consignment validation, which became order of magnitude faster.
4. Test coverage
Version 0.12 is the first version achieving full consensus test coverage not just with integration, but also with unit tests, which also check known attack scenarios. The unit test coverage has increased several folds and is about 90%.
Acknowledgments
The version was designed and implemented by Dr Maxim Orlovsky, financed by Pandora Prime Inc.. Bitlight Labs as one of major contributors has completed the integral test coverage, ensuring the protocol security and scaled community test. The initial three months of development were also financed by Fulgur Ventures.
Read the full announcement on the official website: https://rgb.tech/blog/release-v0-12-consensus/