Por Canuto  

Stellar programó para el 3 de noviembre una votación de validadores sobre Protocol 30, conocido como Bell, en su testnet, y prepara otra para llevar la actualización a la red principal el 23 de noviembre. La propuesta incorpora direcciones de contratos capaces de identificar saldos de distintos clientes, verificación de firmas poscuánticas en Soroban y marcas de tiempo con resolución de milisegundos, aunque no aceleraría de inmediato el cierre de los libros contables.
***

  • Bell propone direcciones muxed para que un contrato inteligente gestione fondos de varios clientes mediante identificadores individuales.
  • Soroban podrá verificar firmas ML-DSA, pero las transacciones de la red seguirán firmándose con Ed25519.
  • La votación de validadores para activar Protocol 30 en la red principal está programada para el 23 de noviembre a las 17:00 UTC.

La propuesta combina nuevas herramientas para cuentas inteligentes, preparación criptográfica poscuántica y cambios en el registro del tiempo de cierre de los libros contables.

Stellar prepara el voto de validadores sobre Bell

Stellar programó para su testnet una votación sobre Protocol 30, una actualización conocida como Bell que propone cambios para contratos inteligentes, verificación criptográfica y datos del libro contable. La votación en la red de pruebas estaba prevista para el 3 de noviembre a las 17:00 UTC; la votación sobre su activación en la red principal está programada para el 23 de noviembre a la misma hora.

La aprobación en mainnet no está garantizada: la activación depende del resultado de esa votación. Bell reúne tres propuestas técnicas, CAP-84, CAP-87 y CAP-88, que modifican cómo los contratos manejan identificadores de clientes, cómo verifican ciertas firmas y con qué precisión Stellar registra el cierre de cada ledger.

Contratos inteligentes para administrar saldos de clientes

Uno de los cambios centrales, CAP-84, propone introducir direcciones muxed para contratos inteligentes. Estas direcciones permiten asociar un identificador de 64 bits a un contrato, de modo que una empresa pueda reconocer a qué cliente corresponde una operación sin desplegar un contrato independiente para cada usuario.

La propuesta amplía una función que Stellar ya ofrece para cuentas muxed, utilizadas por exchanges y custodios para recibir depósitos de varios clientes en una cuenta y distinguirlos mediante identificadores. Los contratos inteligentes de Soroban no tenían esa misma capacidad, por lo que las empresas que utilizaban cuentas programables solían necesitar contratos separados para diferenciar los saldos de sus clientes.

Con Bell, el dinero enviado a una dirección de contrato muxed llegaría al contrato subyacente, mientras el identificador del cliente quedaría registrado en el evento de transferencia. Según Stellar, el diseño podría servir a exchanges, proveedores de pagos y custodios que quieran gestionar depósitos mediante cuentas inteligentes, sin desplegar contratos individuales para potencialmente millones de usuarios.

El formato nuevo comienza con la letra W, a diferencia de las direcciones muxed de cuentas existentes, que empiezan con M. Por ello, billeteras y aplicaciones que procesan direcciones de Stellar tendrán que reconocer el formato y adaptar sus integraciones antes de la activación en la red principal.

Verificación poscuántica dentro de Soroban

CAP-87 propone incorporar funciones para verificar firmas ML-DSA dentro del entorno de contratos inteligentes Soroban. ML-DSA es un algoritmo de firma digital poscuántico estandarizado por el Instituto Nacional de Estándares y Tecnología de Estados Unidos en 2024, y está diseñado para resistir ataques de computadoras cuánticas suficientemente potentes.

La red Stellar utiliza actualmente esquemas como Ed25519, secp256k1 y secp256r1, que podrían quedar expuestos ante futuros avances de la computación cuántica. Bell permitiría que desarrolladores construyan cuentas inteligentes que exijan firmas ML-DSA antes de autorizar operaciones, una opción que podría incorporar controles resistentes a ese tipo de amenaza en billeteras y servicios de custodia.

La verificación de estas firmas requiere más recursos de cómputo que la comprobación de firmas convencionales, por lo que el proceso se ejecutaría a través de Stellar Core. Protocol 30 incluye tres funciones de verificación ML-DSA, correspondientes a los distintos niveles de seguridad del algoritmo.

La fundación presenta esta capacidad como el primer componente en cadena de su plan de preparación cuántica. Sin embargo, Bell no cambiaría las firmas de las transacciones de la red: Stellar seguirá utilizando Ed25519 para ese propósito hasta una futura actualización del protocolo.

Marcas de tiempo más precisas, sin aceleración inmediata

La tercera pieza, CAP-88, propone cambiar la forma en que Stellar registra la hora de cierre de sus ledgers. Hasta ahora, la red expresaba ese dato en segundos enteros, una limitación que impedía apuntar a intervalos de cierre inferiores a un segundo.

Protocol 30 incorporaría marcas de tiempo con resolución de milisegundos, lo que abriría la posibilidad de que futuras modificaciones establezcan intervalos más precisos. El cambio, por sí solo, no reduciría el tiempo actual de cierre ni significaría que las transacciones vayan a procesarse inmediatamente más rápido.

En septiembre, la actualización Protocol 28 redujo los cierres típicos de la red principal de aproximadamente 5,7 segundos a cinco segundos. CAP-88 eliminaría una restricción técnica para posteriores mejoras, mientras desarrolladores de Stellar Core ya experimentan con un procesamiento de ledger más rápido.

La modificación también incorporaría un nuevo formato de encabezado para los ledgers. Las aplicaciones que decodifican datos sin procesar de la cadena deberán actualizarse, ya que versiones antiguas de los SDK podrían no interpretar los ledgers de Protocol 30 y los indexadores y servicios de analítica necesitarán adaptar sus definiciones XDR.

Preparativos para la votación en mainnet

La votación de validadores sobre Bell en la testnet estaba programada para el 3 de noviembre a las 17:00 UTC. La siguiente fecha prevista en el calendario es el 23 de noviembre, a la misma hora, cuando los validadores votarán sobre la activación de la actualización en la red principal.

Stellar publicó versiones compatibles con Protocol 30 de sus programas Core, Horizon, RPC y Galexie. La guía de actualización del 23 de octubre también enumeró JavaScript SDK v17.3.0 y Go SDK v0.8.0 entre las versiones disponibles para desarrolladores, además de una versión candidata del SDK de Soroban para Rust.

La fundación indicó que los validadores deben instalar Stellar Core v30.0.0 antes de la votación. Exchanges, billeteras y otros operadores de infraestructura también deben preparar sus sistemas para el nuevo formato de direcciones y los cambios en los datos del ledger.

Los contratos Soroban existentes podrán seguir funcionando sin modificaciones, aunque los desarrolladores deberán actualizar sus herramientas si quieren utilizar las nuevas funciones. La votación del 23 de noviembre definirá si Bell pasa a la red principal; hasta entonces, los cambios de velocidad siguen siendo una preparación técnica y no una reducción ya implementada de los tiempos de cierre.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados