🚨RGB 0.12 RC1 è ora disponibile Nei miei 2 anni di monitoraggio del protocollo RGB, questo è stato probabilmente il momento più emozionante Solo 14 ore fa, nel github RGB-WG, Maxim ha finalmente annunciato la versione RC1, che sarà la versione più stabile di RGB, e ha anche suggerito che tutti gli sviluppatori RGB passino all'ultima versione il prima possibile, e il prossimo capitolo dell'ecosistema BTC è in arrivo Tuffiamoci nel vivo 👇 🧵 ———————— 🔶 Semplificazione del protocollo Questa volta il cambiamento è principalmente nel livello di consenso, con la nuova architettura che introduce per la prima volta zk-AluVM, una macchina virtuale zk compatta e ad alte prestazioni completa di Turing progettata per la verifica del client Se non sai molto sull'RGB, puoi pensare che sia il sistema di smart contract più nativo di BTC, ovviamente, non solo BTC, ma tutte le catene pubbliche in modalità UTXO possono utilizzare il protocollo RGB per completare gli smart contract off-chain Tornando all'aggiornamento, nell'architettura, ci sono anche alcune ottimizzazioni del refactoring dello stato del contratto + verifica del consenso, che non verranno mostrate in dettaglio qui Secondo Github, questa volta v0.12 - Riduzione di 4 volte della quantità di codice di consenso > e riduzione di 2 volte della libreria standard; - > ridurre il numero di tipi di dati del 30% nei parametri generici dell'API 🔶 Lo Stato è unificato Forse per la gente comune, il cambiamento più percettibile è l'unificazione dello stato del contratto, che aveva tre tipi di stati del contratto (FT/NFT/altro) e ora sono tutti unificati, e potrebbe essere necessario un nuovo modello di token (il precedente modello v0.11 non dovrebbe essere valido) 🔶 Miglioramenti ai pagamenti Ci sono alcuni miglioramenti importanti qui, e sceglierò quelli chiave 1. Contratti multi-asset Ora è possibile includere più token interoperabili in un contratto, che possono essere chiamati indipendentemente o congiuntamente es: Ad esempio, posso definire 100 monete + 500 NFT + alcuni altri allegati in un contratto (i più basilari) 2. Script di pagamento Ad esempio, CoinJoin/PayJoin multi-firma, elaborazione batch di transazioni, operazioni di canale lightning, ecc., supportano uno-a-molti o molti-a-uno 🔶 Ottimizzazione delle prestazioni La vecchia versione dei dati di spedizione deve essere completamente caricata in memoria, la v0.12 è stata modificata in autenticazione in streaming, la memoria occupa solo poche centinaia di byte ed è adatta per portafogli mobili/hardware Non scriverò di più, e sarà diverso dall'uso di tutti