La actualización Bell de Stellar ya está activa en testnet antes de la votación en mainnet del 23 de noviembre
La actualización Protocol 30 de Stellar, con el nombre en clave Bell, se ha activado en testnet e incorpora direcciones de contrato muxed, verificación de firmas post-cuánticas ML-DSA y cambios en el registro del tiempo de cierre del ledger. Los validadores votarán la activación de Bell en mainnet el 23 de noviembre, y las wallets y los indexadores deberán actualizar su software para admitir el nuevo formato de direcciones.
Escrito por la redacción de IA de CoinArticle · a partir de 2 fuentes citadas. Cómo trabajamos
Qué ha cambiado en testnet
Stellar ha activado en testnet su actualización Protocol 30, con el nombre en clave Bell, según un anuncio del 4 de noviembre de la Stellar Development Foundation. Los validadores están programados para votar la activación de Bell en mainnet a las 17:00 UTC del 23 de noviembre, y la activación depende de esa aprobación. La activación en testnet siguió a una votación de los validadores celebrada el 3 de noviembre a la misma hora del día.
Bell agrupa tres cambios de protocolo, especificados en CAP-84, CAP-87 y CAP-88. Abarcan la forma en que los contratos inteligentes gestionan las direcciones de los clientes, cómo se verifican las firmas criptográficas y cómo el ledger registra los tiempos de cierre. En un anuncio del 20 de octubre, la fundación indicó que la actualización pretende ayudar a las empresas a gestionar los fondos de sus clientes mediante cuentas inteligentes y, al mismo tiempo, preparar la red para una seguridad resistente a la computación cuántica y un procesamiento de transacciones más rápido.
Direcciones de contrato muxed para custodios
CAP-84 amplía una capacidad que Stellar ya ofrece a las cuentas estándar. Las cuentas muxed permiten a los exchanges y custodios recibir depósitos de muchos clientes en una sola cuenta, identificando a cada usuario con un ID independiente. Las cuentas inteligentes, que utilizan contratos programables para controlar los permisos de gasto, carecían de esa función, por lo que las empresas solían desplegar un contrato distinto para cada cliente con el fin de mantener los saldos separados.
Con CAP-84, una dirección de contrato puede incluir un identificador de 64 bits que señala al cliente destinatario. Los fondos llegan al contrato subyacente, mientras que el identificador queda registrado en el evento de transferencia. Estas direcciones comienzan por la letra W, lo que las distingue de las direcciones de cuentas muxed con prefijo M. Según Stellar, los exchanges, los proveedores de pagos y los custodios pueden utilizarlo para gestionar depósitos sin desplegar contratos individuales para potencialmente millones de usuarios. Los proveedores de wallets y otras aplicaciones que procesan direcciones de Stellar deberán admitir el nuevo formato.
Firmas post-cuánticas y sus límites
CAP-87 añade compatibilidad para verificar firmas ML-DSA dentro del entorno de contratos inteligentes Soroban. ML-DSA es un algoritmo de firma digital post-cuántico que el Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) estandarizó en 2024. Los esquemas de firma actuales de Stellar, Ed25519, secp256k1 y secp256r1, podrían volverse vulnerables a futuras computadoras cuánticas. Con Bell, los desarrolladores pueden crear cuentas inteligentes que exijan firmas ML-DSA antes de autorizar una transacción, lo que permite a wallets y custodios añadir controles de gasto resistentes a la computación cuántica.
La fundación indicó que la verificación se ejecuta a través de Stellar Core porque las comprobaciones ML-DSA requieren considerablemente más recursos de cómputo que las firmas convencionales. Protocol 30 admite tres funciones de verificación ML-DSA, una por cada nivel de seguridad del algoritmo. La fundación describe este paso como el primer componente on-chain de su Plan de Preparación Cuántica. Las firmas de transacciones a nivel de red seguirán utilizando Ed25519 hasta una futura actualización del protocolo, por lo que la resistencia cuántica en esta etapa se aplica a la autorización a nivel de contrato y no a todas las transacciones de la red.
Fuentes sobre alcance y calendario
Los dos informes coinciden en los datos básicos: la activación en testnet, la votación de mainnet del 23 de noviembre y los tres números de CAP. La cobertura difiere en el énfasis. Un medio enmarcó la actualización principalmente en torno a las actualizaciones de wallets e indexadores y a la verificación opcional de contratos. El otro dio más peso al procesamiento más rápido del ledger que el cambio de temporización podría permitir en actualizaciones posteriores. Las fuentes no ofrecen una cifra sobre cuánto más rápido podría llegar a ser el procesamiento, por lo que ese beneficio debe considerarse prospectivo. Ninguno de los dos informes cita un umbral de aprobación de validadores para la votación en mainnet más allá de la afirmación de que la activación depende de la aprobación de los validadores.
El informe de Crypto.news también señala que otras cadenas persiguen protecciones similares. En agosto, Sui describió planes de autenticación de cuentas resistente a la computación cuántica que utilizarán esquemas de firma aprobados por el NIST.
Por qué importa
Para los traders
La votación en mainnet del 23 de noviembre es el acontecimiento que hay que seguir, ya que la activación depende de la aprobación de los validadores y las fuentes no indican ningún umbral de aprobación.
Para los inversores
Bell marca el primer paso on-chain de Stellar hacia la seguridad post-cuántica y las herramientas de custodia para cuentas inteligentes, ambas cuestiones que podrían influir en su posicionamiento frente a los custodios institucionales.
Para los desarrolladores
Las wallets, los indexadores y cualquier aplicación que analice direcciones de Stellar deben añadir compatibilidad con el nuevo formato de direcciones de contrato con prefijo W antes de la activación en mainnet.
Este artículo es solo informativo y no constituye asesoramiento financiero. Lee el aviso legal completo.
