RGB StdLibs v0.12 RC2

LNP/BP Standards Association presented a new generation of RGB smart contracts (version 0.12) 10 days ago with release candidate 1. Over this period of time we have received several improvement requests from the companies already integrating it into their products and tried to fulfill them with release candidate 2.

This release refactors the RGB smart contracts library to improve its persistence layer, enhance security, and streamline consignment handling.

• Replaced the fs feature with a binfile feature, providing more granular control over binary file format support.
• Introduced a new rgb-persist-fs crate to encapsulate filesystem persistence logic, improving code modularity and separation of concerns.
• Introduced the way to programmatically import contracts via consignments.
• Improved spam prevention, which included creation of a dedicated guideline to contract developers (RCP-250528A), its implementation, and the addition of an embedded mechanism limiting the maximal number of operations in a consignment.
• Added more aggregators producing computed contract state.
• Replaced ImmutableApi and DestructibleApi with GlobalApi and OwnedApi, respectively, for clearer semantics.
• Introduced Semantics struct to group API definitions, codex libraries, and type systems.
• Added ApisChecksum and ArticlesId for improved API versioning and identification.
• Implemented signature validation in Articles::with and Issuer::with using a provided validator function.
• The test suite has been updated to include more comprehensive validation of the new API and consignment handling mechanisms.

Read the full announcement on the official website: https://rgb.tech/blog/release-0-12-rc-2/

RGB StdLibs v0.12 RC1

LNP/BP Standards Association announces that RGB version 0.12 has reached the release candidate stage.

All RGB protocol developers and integrators are recommended to start the integration with v0.12 RC1. Due to the consensus-level changes, contracts issued before this release will not be compatible with the new RGB version.

TL;DR

RGB just got one step from production with the first release candidate of its most tested and robust version (0.12). Over the last half of the year, the 0.12 version has brought zk-STARK readiness to the RGB (making it "zk-STARKy"), a huge performance boost, and a lot of simplification and security improvements. The release candidate is for all developers working with RGB, so they can integrate it into their software, having guarantees of consensus and low-level API freeze.

What's new

The version 0.12 of RGB represents a result of 7 months of protocol re-design, aimed at the following:

1. Make protocol ready for zk-STARK compression;
2. Simplify the protocol as much as possible, reducing any potential attack surface and helping protocol adoption;
3. Ensure security of the protocol with thorough unit and integration test coverage, including tests for potential attacks;
4. 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. Removed interfaces and implementations

The way how interfaces work was also fully refactored, mostly due to zkVM. Most importantly, it has become much simpler.

Previously, software devs integrating RGB were lost in multiple types related to interfaces: interfaces, standards, implementations, schemata, etc. Many of them were also made with generic type parameters, which made it much harder to integrate and fully support their functionality.

Now, with v0.12, the only thing a developer using RGB should know about is so-called contract API: a simple non-generic object explaining to a wallet how to operate with a contract.

Interfaces are still present, but not in the standard library: they live solely now in the world of Contractum language and are used only by contract developers, and the Contractum compiler will be taking care of compiling them into the contract APIs.

2.6. 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.7. No more blank state transitions

One of the concepts that were hard to grasp in RGB was the concept of blank state transitions. In v0.12, because of new and better way to build contract API, they are gone.

3. Payment improvements

3.1. Invoicing

The invoices have become much richer: they may specify any forms of a fungible- and non-fungible state and allow providing more accessory information in a better structured way.

3.2. Multiple-asset contracts

Contracts now may expose multiple tokens, which may interact, and these tokens can be accessed independently or jointly via both invoices and APIs.

3.3. Payment scripts

Version v0.12 for the first time introduces a concept of payment scripts, which is a powerful tool helping to construct and execute complex payments, which may include multiple beneficiaries, multiple contracts and even multiple consequent transactions or a transaction graph.
The functionality helps in:

• multisig wallets;
• coinjoins and payjoins;
• transaction batching at aggregation in wallets and exchanges;
• lighting channel operations;
• future Ark applications.

3.4. 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.

4. 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.

4.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, a...

RGB Std Libs v0.10.4

What's Changed

• Fix AttachmentName and MediaRegName encode by @crisdut in #89
• Debugging APIs by @dr-orlovsky in #91
• Upgrade ids to use Baid58 v0.4 format (URLs, URNs) by @dr-orlovsky in #92

Full Changelog: v0.10.3...v0.10.4

RGB Std Libs v0.10.3

What's Changed

• Add support to RGB21 (ContractBuilder) by @crisdut in #51
• Add support for 'type/*' MediaTypes by @dr-orlovsky in #50
• Rgb20 convenience API by @dr-orlovsky in #58
• Fix missed transition merge in bundle merge op by @dr-orlovsky in #63
• Fix issued supply by @dr-orlovsky in #64
• Remove excessive terminals in consign procedure by @dr-orlovsky in #62
• Add OutpointFilter to filter wallet-based outputs by @dr-orlovsky in #65
• Add media information to the supplement by @dr-orlovsky in #70
• add rgb25 stl + move/add common types by @zoedberg in #75
• Account for address-based vout seals in consign procedure by @dr-orlovsky in #76
• Fix use of velocity classes by @dr-orlovsky in #77
• Add blank state transitions to state by @dr-orlovsky in #81
• Export rgb-core LIB_ID_RGB constant by @cryptoquick in #86
• Update to use latest consensus changes by @dr-orlovsky in #85
• Modifications to containers: witness tx in consignments and type libs in ifaces by @dr-orlovsky in #88

New Contributors

• @cryptoquick made their first contribution in #86

Full Changelog: v0.10.2...v0.10.3

RGB Std Libs v0.10.2

What's Changed

• Complete implementation of RGB20 and RGB21 interfaces by @dr-orlovsky in #48

Full Changelog: v0.10.1...v0.10.2

RGB Std Libs v0.10.1

What's Changed

• Fix dbc_conclude commitment host count by @nicbus in #35
• RgbInvoice: make contract optional by @zoedberg in #33
• make iface optional and add expiry by @nicbus in #37
• set opret/tapret host if needed by @nicbus in #46
• add invoice transport parsing by @nicbus in #43
• Update dependencies with fix of consecutive transfer by @dr-orlovsky in #45

Full Changelog: v0.10.0...v0.10.1

RGB Std Lib v0.10

This release is a major milestone which brings RGB further to being a production-ready system. It introduces the last consensus-breaking changes, aiming at keeping future RGB versions fully backward-compatible. It also unlocks the last features that were required for implementing fully-functional smart contracts which may be arbitrary customized by contract developers.

Key novelties

• Contract interfaces

  Interfaces, introduced in this version, represent a standard way of communicating a diverse range of smart contracts through well-defined APIs. Interfaces can be compared to contract ABIs and ERCs in Ethereum world, however, unlike in Ethereum, they require neither obligatory standardization (as ERCs) nor separate distribution, being always packed together with contracts. By using interfaces, wallets and other software can provide a semantic-aware UI for the users for working with the contracts - and contract developers may add more interfaces to their existing contracts over time without the need to update the immutable contract itself.

• Writing contracts in Rust

  Writing and compiling an RGB smart contracts in Rust. Thanks to the strict types, it is also possible to compile rust data types right into RGB contracts.

• URL-based invoice format

  Previously RGB was using Bech32m-encoded invoices, which were very long, not human-readable and couldn't be automatically opened with most of the software. The new format is much shorter, easier to verify by the user and can be opened automatically as a link with a preconfigured software.

• WASM support

  RGB standard library can run without I/O and file system access, i.e. can operate inside a web page or a browser plugin.

• Simplified dependencies

  RGB consensus layer is being shipped with fewer dependencies, improving the stability of API. With this release do not use rust-bitcoin and rust-miniscript at the level of standard library due to their overall API instability and recently discovered bugs; since RGB uses a very small subset of bitcoin functionality it is now implemented as a part of the library with no assumptions about bitcoin consensus layer (like those which halted rust-bitcoin powered software when Burak's hack had happened last year).

• Simplified integration

  Many operations that previously required multiple API calls, as well as cross-language encoding of complex data structures now work with a single API call. RGB contract state is represented as a JSON object and can be serialized across different languages without a hassle.

Migration notes

There is no migration from contracts issued on RGB v0.9 to the future versions. All assets have to be re-issued; asset holders can contact asset issuers to provide them with a newly re-issued contracts and assets matching the assets from v0.9.

RGB v0.10 can be downloaded and installed as described on [https://rgb.tech] (https://rgb.tech) website, which also contains a number of user and developer guidelines. RGB source code can be found on https://github.com/RGB-WG

Full Changelog: v0.9.0...v0.10.0

RGB Std Lib v0.10 RC

What's Changed

• Invoice payment implementation by @dr-orlovsky in #23
• Fix RGB Invoice FromStr by @crisdut in #24

Full Changelog: v0.10.0-beta.1...v0.10.0-rc.2

RGB Std Lib v0.10 Beta 1

What's Changed

• Consignment creation by @dr-orlovsky in #21
• Creating and accepting transfers; working with PSBT by @dr-orlovsky in #22

Full Changelog: v0.10.0-alpha.1...v0.10.0-beta.1

RGB Std Lib v0.10 Alpha 1

What's Changed

• Rewritten standard library to support interfaces and global state by @dr-orlovsky in #20

Full Changelog: v0.9.0...v0.10.0-alpha.1