LNP/BP Standards Association is happy to announce the seventh beta release of RGB version 0.11.
What's new in Beta 7
Consensus-level changes
Beta 7 completes an important feature which will be required by any DeFi smart contract:
introspection of the contract state from inside AluVM scripts. While before it was possible to
access state from the current operation only, in this release we have implemented a new engine
for dynamically computing and updating global contract state during the validation itself, such
that scripts can also access global state and outputs known to the contract.
This feature comes hand-in-hand with an improved ordering of the global state data. We introduce a
new nonce field in RGB operations, which allows to enforce the same deterministic ordering for
mempool, lightning channel and on-chain transactions. You can read more about this feature in
RCP-240731A proposal.
Improved persistence
Previously, the state for each contract have to be fully stored in the memory. Beta 7 introduces a
new contract state engine, which works with the consensus level, but allows to keep the state in
some external storage, like file, database etc., not fully loading it into the memory. This allows
to ensure that validation can run efficiently in all environment, from enterprise setups to
restricted embedded systems, like hardware wallets.
Beta 7 adds support for automatic detection of contract and stash data changes and automated saving
of the modified data, as well as recovery from the I/O failures, ensuring that the persisted state
is always consistent. This should work well with database environments and their transaction-commit-
rollback workflows.
Support for re-orgs and RBFs
For the first time we added ability to the RGB wallet library to support both RBF transactions and
properly react on blockchain re-orgs, whenever they happen. This was achieved due to the complete
refactoring of how the RGB wallet operates. Previously, wallet was tracking only bitcoin
transactions belonging to the wallet descriptor; however in RGB validity of operation also depends
on a second bitcoin transaction, called "witness transactions", which contain the commitment for the
single-use seals -- the mechanism by which RGB prevents double-spending of the client-side state.
In order to be valid, RGB state must belong to an operation output for which all previous history
of the operation graph is commited by the witness transactions included into the blockchain and
lightning state channels. As you see, a re-org, RBF transaction change or Lightining channel update
changes that validity, and the new wallet engine allows us to efficiently track those changes in
automatic fashion without creating excessive blockchain indexer requests.
Support for hot wallets
Since RGB uses a novel type of bitcoin transaction commitments, taprets (OP_RETURN commitments
residing inside taproot tree), RGB taproot wallets are not supported by rust-bitcoin, miniscript and
BDK libraries. Thus, starting from 2022, LNP/BP Association was working on new and modern
rust implementation of bitcoin protocol named BP libraries. This release for the first time
ships with new version of BP supporting creation of hot wallets, which removes the last obstacle
in working with RGB in taproot.
Improved Lightning functionality
Support of the Lightning network was significantly improved in this release; including ability to
efficiently handle RGB assets after a non-cooperative channel closings and ability to handle
state channel updates which doesn't modify RGB state -- a feature important when you perform a
bitcoin payment inside an RGB channel, or when the channel operates multiple RGB assets.
Invoice changes
RGB20 fungible assets, alike many other token standards, may have a different precision, defining
the asset divisibility. For instance, Bitcoin has precision of 8 digits (1 sat = 0.00000001 BTC),
USDT -- 6 digits etc. RGB invoices specify the amount of the assets to transfer as an integer, i.e.
as an amount of the smallest asset units. This may confuse users, since the transfer of 100 USDTs
will specify 100000000 as the amount. In order to avoid the confusion, starting the beta 7 the
specific asset amount in the RGB invoices is encoded in a non-human readable form.
Other wallet improvements
Beta 7 adds support for Mempool extensions to the Esplora REST APIs, allowing using it as a backend
indexer for RGB wallets.
Many developers experience issues with Bitcoin Testnet, due to its spam pollution. A new proposal
of testnet re-load, named Testnet4, gains more and more traction. The current release adds support
of Testnet4 network to all RGB and wallet libraries.
In this version we also added ability to automatically resolve collisions between different
commitment methods which may happen due to user mistakes. Now, if your taproot-based wallet will
receive an RGB payment with non-tapret single-use seal (which may happen also due to an adversarial
payee) the wallet will be able to see and use those funds with no manual recovery or adjustments.
What's next
Beta 7 release continues a phase of preparation for a public preview of the RGB v0.11. All parties
are strongly recommended switching to this latest beta, which contains a number of critical bugfixes,
and provide us feedback their feedback.
Beta 7 was a result of internal audit and testing effort, we do together with [Bitfinex Labs], which
will continue with external audit in the following week. In this way we plan to ensure the system
security and safety before the final release.
You can track us on our journey towards v0.11 release with this GitHub dashboard.
Acknowledgements
We are grateful to Fulgur Ventures, continuing their multi-year support for our efforts in
developing RGB, as well as other Association members, including Bitlight Labs, who had become a
major contributor to RGB development. We are grateful to all commercial companies, building on RGB,
and providing their support, contributions and feedback, including Bitfinex, Pandora Prime, and
DIBA. We are also grateful for individual contributors, who do their small -- but still highly
valuable and welcomed input in making RGB better.
New Contributors
- @will-bitlight made their first contribution in #221