🚨 RGB 0.12 RC1 version officially launched In the 2 years I have been tracking the RGB protocol, this may be the most exciting moment Just 14 hours ago, Maxim finally announced the RC1 version on the RGB-WG GitHub, which will be the most stable version of RGB. He also suggested that all RGB dev should move to the latest version as soon as possible. The next chapter of the BTC ecosystem is coming Let's dive in 👇 🧵 ———————— 🔶 Protocol simplification The main change this time is the consensus layer. The new architecture introduces zk AluVM for the first time, which is a compact, high-performance Turing complete zk virtual machine designed specifically for client verification If you are not particularly familiar with RGB, you can consider it as the most native smart contract system for BTC. Of course, not only BTC, but all UTXO mode public chains can use the RGB protocol to complete off chain smart contracts Returning to the update, in the architecture, there are also optimizations for contract state refactoring and consensus verification, which will not be detailed here According to Github, this time v0.12 -Reduce consensus code by 4 times and standard library by 2 times; -Reduce the number of data types and cut generic parameters in the API by 30% 🔶 Unified Status For ordinary people, the most noticeable change may be the unification of contract states. Previously, there were three types of contract states (FT/NFT/other), but now they are all unified together and may require a new token template (the previous v0.11 template should be obsolete) 🔶 Payment improvement There are several modules that have been mainly enhanced here, and I will pick out the key ones to talk about 1. Multi asset contract Now a contract can include multiple interoperable tokens, supporting independent or joint calls Ex: For example, I can define 100 coins+500 NFTs+some other attachment information (the most basic) in a contract 2. Payment script For example, multi sign CoinJoin/PayJoin, batch processing of transactions, lightning channel operations, etc., supporting one to many or many to one 🔶 performance optimization The old version of the consignment data needs to be fully loaded into memory. v0.12 has been changed to stream verification, which only occupies a few hundred bytes of memory and is suitable for mobile/hardware wallets I won't write too much, it will be different from everyone's usage