🚨RGB 0.12 RC1 est maintenant disponible Au cours de mes 2 années de suivi du protocole RGB, c’était probablement le moment le plus excitant Il y a à peine 14 heures, dans le github RGB-WG, Maxim a finalement annoncé la version RC1, qui sera la version la plus stable de RGB, et il a également suggéré que tous les développeurs RGB passent à la dernière version dès que possible, et le prochain chapitre de l’écosystème BTC arrive Plongeons dans le vif du sujet 👇 🧵 ———————— 🔶 Simplification du protocole Cette fois-ci, le changement se situe principalement dans la couche de consensus, la nouvelle architecture introduisant pour la première fois zk-AluVM, une machine virtuelle zk Turing-complète compacte et performante conçue pour la vérification des clients Si vous ne connaissez pas grand-chose au RGB, vous pouvez penser qu’il s’agit du système de contrat intelligent le plus natif de BTC, bien sûr, non seulement BTC, mais toutes les chaînes publiques en mode UTXO peuvent utiliser le protocole RGB pour réaliser des contrats intelligents hors chaîne Pour en revenir à la mise à jour, dans l’architecture, il y a aussi quelques optimisations de la refactorisation de l’état du contrat + vérification du consensus, qui ne seront pas montrées en détail ici Selon Github, cette fois-ci v0.12 - Réduction de 4 fois de la quantité de code de consensus > et de réduction de 2 fois de la bibliothèque standard ; - > réduire de 30 % le nombre de types de données dans les paramètres génériques de l’API 🔶 L’État est unifié Peut-être que pour les gens ordinaires, le changement le plus perceptible est l’unification de l’état contractuel, qui avait l’habitude d’avoir trois types d’états contractuels (FT/NFT/autre) et maintenant tous sont unifiés, et un nouveau modèle de jeton peut être nécessaire (le modèle v0.11 précédent devrait être invalide) 🔶 Améliorations des paiements Il y a quelques améliorations majeures ici, et je vais choisir les principales 1. Contrats multi-actifs Il est désormais possible d’inclure plusieurs jetons interopérables dans un contrat, qui peuvent être appelés indépendamment ou conjointement ex : Par exemple, je peux définir 100 pièces + 500 NFTs + quelques autres pièces jointes dans un contrat (les plus basiques) 2. Scripts de paiement Par exemple, CoinJoin/PayJoin multi-signatures, le traitement par lots de transactions, le fonctionnement du canal Lightning, etc., prennent en charge le un-à-plusieurs ou plusieurs-à-un 🔶 Optimisation des performances L’ancienne version des données d’envoi doit être entièrement chargée en mémoire, la v0.12 est remplacée par l’authentification en streaming, la mémoire n’occupe que quelques centaines d’octets et convient aux portefeuilles mobiles/matériels Je n’écrirai pas plus, et ce sera différent de l’usage de tout le monde