🚨RGB 0.12 RC1 ya está disponible En mis 2 años de seguimiento del protocolo RGB, este fue probablemente el momento más emocionante Hace apenas 14 horas, en el github de RGB-WG, Maxim finalmente anunció la versión RC1, que será la versión más estable de RGB, y también sugirió que todos los desarrolladores de RGB pasen a la última versión lo antes posible, y el próximo capítulo del ecosistema BTC está por venir Vamos a sumergirnos 👇 🧵 ———————— 🔶 Simplificación de protocolos Esta vez, el cambio se produce principalmente en la capa de consenso, con la nueva arquitectura introduciendo por primera vez zk-AluVM, una máquina virtual zk completa y compacta de alto rendimiento diseñada para la verificación de clientes Si no sabes mucho sobre RGB, puedes pensar que es el sistema de contratos inteligentes más nativo de BTC, por supuesto, no solo BTC, sino todas las cadenas públicas en modo UTXO pueden usar el protocolo RGB para completar contratos inteligentes fuera de la cadena Volviendo a la actualización, en la arquitectura, también hay algunas optimizaciones de refactorización de estado de contrato + verificación de consenso, que no se mostrarán en detalle aquí Según Github, esta vez v0.12 - Reducción de 4 veces en la cantidad de código de consenso > y reducción de 2 veces en la biblioteca estándar; - > reducir el número de tipos de datos en un 30% en los parámetros genéricos de la API 🔶 El estado está unificado Quizás para la gente común, el cambio más perceptible es la unificación del estado del contrato, que solía tener tres tipos de estados del contrato (FT / NFT / otros) y ahora todos ellos están unificados, y es posible que se necesite una nueva plantilla de token (la plantilla v0.11 anterior debería no ser válida) 🔶 Mejoras en los pagos Hay algunas mejoras importantes aquí, y elegiré las clave 1. Contratos multiactivos Ahora es posible incluir varios tokens interoperables en un contrato, que se pueden llamar de forma independiente o conjunta Por ejemplo, puedo definir 100 monedas + 500 NFT + algunos otros adjuntos en un contrato (los más básicos) 2. Guiones de pago Por ejemplo, CoinJoin/PayJoin de múltiples firmas, procesamiento por lotes de transacciones, operación de canal relámpago, etc., admiten uno a muchos o muchos a uno 🔶 Optimización del rendimiento La versión anterior de los datos de envío debe cargarse completamente en la memoria, v0.12 se cambia a autenticación de transmisión, la memoria ocupa solo unos pocos cientos de bytes y es adecuada para billeteras móviles / de hardware No escribiré más, y será diferente del uso de todos