🚨RGB 0.12 RC1 is now available In my 2 years of tracking the RGB protocol, this was probably the most exciting moment Just 14 hours ago, in the RGB-WG github, Maxim finally announced the RC1 version, which will be the most stable version of RGB, and he also suggested that all RGB devs move to the latest version as soon as possible, and the next chapter of the BTC ecosystem is coming Let's dive in 👇 🧵 ———————— 🔶 Protocol simplification This time the change is mainly in the consensus layer, with the new architecture introducing for the first time zk-AluVM, a compact, high-performance Turing-complete zk virtual machine designed for client verification If you don't know much about RGB, you can think that it is the most native smart contract system of BTC, of course, not only BTC, but all public chains in the UTXO mode can use the RGB protocol to complete off-chain smart contracts Back to the update, in the architecture, there are also some optimizations of contract state refactoring + consensus verification, which will not be shown in detail here According to Github, this time v0.12 - 4x reduction in the amount of consensus code and 2x reduction in the standard library; - reduce the number of data types by 30% in generic parameters in the API 🔶 The state is unified Perhaps for ordinary people, the most perceptible change is the unification of the contract state, which used to have three types of contract states (FT/NFT/other) and now all of them are unified, and a new token template may be needed (the previous v0.11 template should be invalid) 🔶 Payment improvements There are a few major enhancements here, and I will pick out the key ones 1. Multi-asset contracts It is now possible to include multiple interoperable tokens in a contract, which can be called independently or jointly ex: For example, I can define 100 coins + 500 NFTs + some other attachments in a contract (the most basic) 2. Payment scripts For example, multi-signature CoinJoin/PayJoin, transaction batch processing, lightning channel operation, etc., support one-to-many, or many-to-one 🔶 Performance optimization The old version of consignment data needs to be fully loaded into memory, v0.12 is changed to streaming authentication, the memory occupies only a few hundred bytes, and it is suitable for mobile/hardware wallets I won't write more, and it will be different from everyone's use | pepper 花椒解盘㊂正EV OKX Feed

🚨RGB 0.12 RC1 is now available In my 2 years of tracking the RGB protocol, this was probably the most exciting moment Just 14 hours ago, in the RGB-WG github, Maxim finally announced the RC1 version, which will be the most stable version of RGB, and he also suggested that all RGB devs move to the latest version as soon as possible, and the next chapter of the BTC ecosystem is coming Let's dive in 👇 🧵 ———————— 🔶 Protocol simplification This time the change is mainly in the consensus layer, with the new architecture introducing for the first time zk-AluVM, a compact, high-performance Turing-complete zk virtual machine designed for client verification If you don't know much about RGB, you can think that it is the most native smart contract system of BTC, of course, not only BTC, but all public chains in the UTXO mode can use the RGB protocol to complete off-chain smart contracts Back to the update, in the architecture, there are also some optimizations of contract state refactoring + consensus verification, which will not be shown in detail here According to Github, this time v0.12 - 4x reduction in the amount of > consensus code and 2x reduction in the standard library; - > reduce the number of data types by 30% in generic parameters in the API 🔶 The state is unified Perhaps for ordinary people, the most perceptible change is the unification of the contract state, which used to have three types of contract states (FT/NFT/other) and now all of them are unified, and a new token template may be needed (the previous v0.11 template should be invalid) 🔶 Payment improvements There are a few major enhancements here, and I will pick out the key ones 1. Multi-asset contracts It is now possible to include multiple interoperable tokens in a contract, which can be called independently or jointly ex: For example, I can define 100 coins + 500 NFTs + some other attachments in a contract (the most basic) 2. Payment scripts For example, multi-signature CoinJoin/PayJoin, transaction batch processing, lightning channel operation, etc., support one-to-many, or many-to-one 🔶 Performance optimization The old version of consignment data needs to be fully loaded into memory, v0.12 is changed to streaming authentication, the memory occupies only a few hundred bytes, and it is suitable for mobile/hardware wallets I won't write more, and it will be different from everyone's use

19.02K

The content on this page is provided by third parties. Unless otherwise stated, OKX is not the author of the cited article(s) and does not claim any copyright in the materials. The content is provided for informational purposes only and does not represent the views of OKX. It is not intended to be an endorsement of any kind and should not be considered investment advice or a solicitation to buy or sell digital assets. To the extent generative AI is utilized to provide summaries or other information, such AI generated content may be inaccurate or inconsistent. Please read the linked article for more details and information. OKX is not responsible for content hosted on third party sites. Digital asset holdings, including stablecoins and NFTs, involve a high degree of risk and can fluctuate greatly. You should carefully consider whether trading or holding digital assets is suitable for you in light of your financial condition.