El mecanismo Proof-of-Stake (PoS) de Sui integra épocas y conjuntos de validadores para garantizar la seguridad y el consenso de la red, lo que difiere significativamente de las cadenas de EVM. Esta es una explicación detallada adaptada a sus objetivos de desarrollo:

Épocas en Sui

Sui funciona en períodos de tiempo discretos denominados épocas, cada uno de los cuales dura aproximadamente 24 horas (configurable, de forma predeterminada, 864.000 ranuras a unos 150 ms por ranura). Epochs gestiona los cambios en los conjuntos de validadores y los parámetros de consenso:

• Estructura: Cada época comienza con una transacción del sistema que establece los parámetros (por ejemplo, los umbrales de apuesta, las recompensas) y termina con un punto de control en el que se finalizan los cambios de estado.
• Transición: los validadores proponen una nueva época mediante una llamada a mover el sistema, lo que requiere un acuerdo de 2 a 1 (donde f es el número máximo de validadores defectuosos). Esto desencadena un tiempo de reconfiguración en el que la red se detiene brevemente.
• Propósito: Las épocas permiten actualizar los conjuntos de validadores dinámicos, volver a delegar las apuestas y ajustar los parámetros sin detener la cadena.

Conjuntos de validadores y POs

Sui utiliza un modelo de PoS delegado en el que los validadores se eligen en función de los tokens de SUI apostados:

• Elección: los validadores deben apostar una cantidad mínima (por ejemplo, 30 SUI, ajustable) y atraer la delegación de los usuarios. Los N mejores validadores (p. ej., 100) por apuesta total forman el conjunto activo.
• Consenso: Sui emplea un protocolo bizantino tolerante a fallos (BFT) (Narwhal/Bullshark) para los objetos compartidos, lo que garantiza 2 validadores honestos de un total de 3 f+1. Para transacciones simples, utiliza el procesamiento paralelo sin un consenso total.
• Recompensas y reducciones: los validadores obtienen recompensas en función de las comisiones de transacción y de la redistribución de los fondos de almacenamiento, de forma proporcional a la participación. La mala conducta (por ejemplo, la doble firma) lleva a la reducción de precios, aunque los detalles específicos están definidos por la gobernanza.
• Rotación: Al final de la época, los cambios en las apuestas activan un nuevo conjunto de validadores: los validadores inactivos salen y entran otros nuevos en función de la clasificación de las apuestas.

Esto contrasta con los conjuntos de validadores estáticos de EVM en cadenas de PoS como Ethereum, donde los cambios se producen mediante bifurcaciones o actualizaciones.

Conceptos arquitectónicos

• Objeto de estado del sistema: rastrea los datos de época (por ejemplo, la hora de inicio, el conjunto de validadores) y se actualiza mediante los movimientos del sistema.
• Paralelismo: el modelo de objetos de Sui permite que las transacciones no se superpongan para eludir el consenso, lo que reduce los cuellos de botella relacionados con la época en comparación con la ejecución secuencial de EVM.
• Tiempo de reconfiguración: una breve pausa (segundos) durante las transiciones de época garantiza la coherencia de los estados, lo que supone una compensación única por la flexibilidad.

Mueva la estructura del código

Los movimientos del sistema gestionan las transiciones de época, pero los desarrolladores pueden interactuar con los datos de época. Ejemplo:

movimiento módulo my_module: :epoch_tracker { usa sui: :epoch_time: :epochTime; usa sui: :tx_context: :TxContext;

La estructura pública EpochData tiene una clave, store { id: UID, época_actual: u64, }

entrada pública fun update_epoch (datos: &mut epochData, epoch: u64, ctx: &mut txContext) { data.current_epoch = época; //Lógica adicional basada en la época }

entrada pública run create_epoch_tracker (ctx: &mut txContext) { let data = epochData { id: object: :new (ctx), current_epoch: epoch_time: current_epoch (ctx), }; transferencia: :transferencia (datos, tx_context: :remitente (ctx)); } }

• Puntos clave: Usa epoch_time: :current_epoch para acceder a la época actual. Los movimientos del sistema (p. ej., sui_system: :request_add_validator) se limitan a la gobernanza.
• Seguridad: valida los datos de época para evitar manipulaciones durante la reconfiguración.

Uso de la CLI

Gestione las interacciones de los validadores y los datos de época a través de la CLI de Sui:

• Compruebe la época: golpetazo su cliente get-epoch-info

• Salida: época actual, hora de inicio, conjunto de validadores.

• Stake SUI (como delegador): golpetazo sui client stake --amount 100 --validator --gas-budget 1000000

• Tenga cuidado con: el saldo es insuficiente o la dirección del validador no es válida.

• Solicitar la adición de un validador (solo para el gobierno, simulado en la red local): golpetazo llamada de cliente sui --package --module sui_system --function request_add_validator --args --gas-budget 1000000

• Nota: Se requiere el identificador del paquete del sistema y la función de gobierno.

• Configuración de red local: golpetazo sui-test-validator --con grifo

• Simula las transiciones de época ajustando la configuración (por ejemplo, acorta la duración de las épocas).

Mejores prácticas y principios de seguridad

1. Lógica compatible con la época: diseñe contratos para gestionar las pausas de reconfiguración (por ejemplo, las transacciones de reintento).
2. Supervisión de estacas: utilice la CLI o el SDK para rastrear las participaciones de los validadores y garantizar la delegación a nodos confiables.
3. Pruebas: simule las transiciones de época en localnet con sui-test-validator --epoch-duration-ms 10000 para probar el comportamiento.

• Error común: la transacción caduca durante la reconfiguración: aumenta el tiempo de espera o vuelve a intentarlo.

4. Seguridad: evite confiar en datos específicos de una época sin validarlos, ya que las reconfiguraciones pueden alterar el estado.
5. Condiciones realistas: prueba con diferentes distribuciones de apuestas en la red de prueba para imitar los cambios en el conjunto de validadores.

Diferencias entre EVM y Development Impact

• Validadores dinámicos: EVM PoS (por ejemplo, Ethereum) corrige los validadores hasta que se actualizan, mientras que la rotación de Sui, basada en la época, favorece la adaptabilidad, lo que resulta ideal para los fondos de liquidez de DeFi que necesitan ajustes frecuentes.
• Paralelismo: el paralelismo a nivel de objetos de Sui reduce la sobrecarga de época, a diferencia de los límites basados en bloques de EVM, lo que beneficia a las operaciones por lotes de monederos o acuñaciones de NFT.
• Desarrollo: las restricciones de movimiento del sistema de Move requieren una interacción de gobierno, a diferencia de lo que ocurre con la implementación por contrato abierto de EVM, que requiere una planificación cuidadosa de las funciones relacionadas con los validadores.

Errores y correcciones comunes

• Ignorar la reconfiguración: se supone que el funcionamiento continuo falla durante las transiciones. Solución: Implementar la lógica de reintento.
• Apuesta inválida: si se apuesta por debajo del mínimo, se producen errores. Corrección: consulta get-epoch-info para ver los umbrales.
• Discordancia de red: se produce un error al utilizar la CLI de la red principal en la red de prueba. Corrección: se alinea con la red de destino (p. ej., sui client switch --env testnet).

Esto se aplica a los contratos inteligentes (lógica basada en la época), a los NFT (acuñación que depende del validador), a los monederos (seguimiento de las participaciones) y a las DeFi (fondos de liquidez dinámicos). Realice pruebas exhaustivas en localnet/testnet para garantizar su solidez más allá de los límites de la época.

Sui trabaja en un sistema basado en el tiempo llamado épocas. Cada época dura alrededor de 24 horas de forma predeterminada, aunque esto se puede cambiar. Puedes imaginarte épocas como las rondas de juego: al principio, el sistema establece las reglas, la lista de validadores y los parámetros de recompensa; al final, fija el estado y se prepara para la siguiente ronda. Al pasar de una época a otra, hay una breve pausa llamada tiempo de reconfiguración, que dura unos segundos, durante la cual la red se detiene brevemente para actualizarse de forma segura.

Ahora hablemos de los validadores. Sui utiliza un sistema delegado de prueba de participación (PoS). Los validadores deben apostar una cantidad mínima de SUI (por ejemplo, 30 fichas) y atraer más delegaciones por parte de los usuarios para figurar en la lista N de los primeros puestos, que define quién formará parte del conjunto de validadores activo en esa época. Si tu validador no llega a los primeros puestos, será expulsado en la siguiente transición de época. Por lo tanto, los importes apostados y la delegación determinan automáticamente la rotación de los validadores, a diferencia de Ethereum, donde los conjuntos de validadores son prácticamente fijos, a menos que haya una mejora de la red o algún tipo de propuesta de gobernanza.

En Sui, el sistema Proof-of-Stake (PoS) gira en torno a algo llamado épocas; considérelas como ventanas de tiempo en las que un conjunto de validadores permanece bloqueado para ejecutar la red. Cada época dura unas 24 horas de forma predeterminada, pero es configurable. Cuando comienza una época, el sistema establece reglas como los umbrales de apuesta y quién forma parte del conjunto de validadores. Cuando termina, el sistema resume el estado de forma limpia y se prepara para el siguiente.

Aquí es donde la cosa se pone interesante: durante el cambio de época, la red se detiene durante unos segundos. Esa pausa se denomina tiempo de reconfiguración y le da al sistema espacio para rotar los validadores de forma segura o cambiar los parámetros internos. Tu aplicación debe saberlo porque las transacciones enviadas durante este breve período pueden fallar o caducar.

La selección del validador es dinámica. Si tienes un validador, necesitas apostar por una SUI y conseguir que otras te deleguen en ti. La red selecciona automáticamente a los mejores validadores por participación total y forma el conjunto activo en cada época. Si alguien gana más que tú, es posible que te echen de la siguiente ronda. Los delegados también pueden mover su apuesta en cada época, por lo que es fluido. A diferencia de Ethereum, donde los cambios en los validadores requieren actualizaciones de protocolo, Sui se encarga de ello todos los días.

El consenso también funciona de manera diferente. Sui usa Narwhal y Bullshark para las transacciones de objetos compartidos, que necesitan coordinación. Pero si tu aplicación se ocupa de objetos propios, como carteras personales, omite el consenso total y procesa las cosas en paralelo. Esto cambia las reglas del juego porque significa que tus transacciones no se quedan atrás de las que no están relacionadas, como ocurre en Ethereum.

Dentro del código Move, puedes capturar la época actual usando epoch_time: :current_epoch (ctx). Por ejemplo, si estás creando un módulo que reacciona a los cambios de época, puedes crear tu propio objeto para almacenar y actualizar los valores de época. Este es un bosquejo básico de cómo se ve:

module my_module::epoch_tracker {
    use sui::epoch_time;
    use sui::tx_context::{Self, TxContext};
    use sui::object;
    use sui::transfer;

    struct EpochData has key, store {
        id: UID,
        current_epoch: u64,
    }

    public entry fun create(ctx: &mut TxContext) {
        let epoch = epoch_time::current_epoch(ctx);
        let data = EpochData { id: object::new(ctx), current_epoch: epoch };
        transfer::transfer(data, tx_context::sender(ctx));
    }

    public entry fun update(data: &mut EpochData, epoch: u64, ctx: &mut TxContext) {
        data.current_epoch = epoch;
    }
}

En la red Sui, las épocas y los conjuntos de validadores son componentes centrales de su modelo de consenso delegado de prueba de participación (DPoS). En Sui, una época es un período de tiempo fijo (por ejemplo, 24 horas) durante el cual un conjunto de validadores determinado es responsable de procesar las transacciones y generar bloques. Cada época comienza con una fase de reconfiguración en la que el conjunto de validadores puede cambiar en función de las entradas acumuladas de la época anterior.

1. Épocas y rotación del validador

Cada época tiene un conjunto de validadores único, determinado por la apuesta total delegada a cada validador.

Los delegadores apuestan sus fichas SUI a los validadores, lo que influye en quién se unirá al conjunto activo en la siguiente época.

Al final de una época, la red hace una breve pausa para reconfigurarse, finalizar el punto de control de la época y pasar al siguiente conjunto de validadores.

2. Estructura del conjunto de validadores

El conjunto de validación se almacena en un objeto Move, mantenido por el módulo de sistema 0x3: :sui_system.

Cada validador tiene metadatos que incluyen su clave pública, el importe de la apuesta, la comisión y la dirección de red.

Validador de estructuras { metadatos: validatorMetadata, voting_power: u64, precio de la gasolina: u64, tasa de comisión: u64, ... }

3. Apuesta y delegación

Los participantes interactúan con el módulo del sistema Sui a través de la CLI o el SDK para delegar la participación:

sui client stake --amount: 1000000000 --validator <VALIDATOR_ADDRESS>

Los tokens apostados están bloqueados e influyen en la apuesta total del validador para la próxima época.

Las recompensas se distribuyen según las épocas y se pueden solicitar mediante el método draw_rewards.

4. Mueva la interacción

La función sui_system: :request_epoch_change se invoca automáticamente para rotar los validadores.

Los contratos inteligentes no controlan directamente las épocas, pero pueden acceder a la información del validador para la gobernanza o la lógica de las apuestas mediante el módulo sui_system.

5. Uso de CLI/SDK

Para consultar la época actual y los validadores:

llamada de cliente sui --package 0x3 --module sui_system --function get_current_epoch llamada de cliente sui --package 0x3 --module sui_system --function get_validator_set

Desde el SDK:

const epochInfo = await Provider.getLatestsUISystemState (); console.log (EpochInfo.epoch, EpochInfo.ActiveValidators);

6. Posibilidad de gobernanza en cadena

La estructura de Sui permite utilizar una lógica de apuesta avanzada o contratos acordes con la época, por ejemplo, la lógica de adquisición o reequilibrio que se desencadena con la época.

7. Dificultades comunes

El uso de direcciones de validador obsoletas puede provocar un error en el staking.

Delegar demasiado cerca del final de una época podría aplazar los efectos hasta el siguiente ciclo.

Los contratos no pueden acceder directamente a la hora, sino que deben utilizar los datos del reloj o época del sistema.

8. Pruebas y mejores prácticas

En localnet, puedes simular transiciones de época llamando a:

sui genesis --epoch-duration-ms 10000

Supervise las reconfiguraciones con el evento EpochChangeEvent.

9. Seguridad

Asegúrese de que los metadatos del validador estén verificados (por ejemplo, si no hay ningún validador Sybil configurado).

Los contratos de recompensas deben tener en cuenta las épocas para evitar la duplicación de las recompensas.

10. Diseño para llevar

El modelo PoS de Sui, basado en la época, impone el determinismo, el aislamiento del rendimiento y la flexibilidad de delegación, a diferencia de la conmutación continua de validadores bloque por bloque de las cadenas EVM. Los desarrolladores de contratos inteligentes deberían tratar las transiciones de época como límites de cambio de estado en función de la lógica que depende del tiempo, la reputación del validador o los flujos de participación.

Avísame si quieres una plantilla de contrato de Move que lea los datos de época o valide las condiciones basadas en las apuestas.

En Sui, el tiempo se divide en partes llamadas épocas. Cada época es como una sesión que dura aproximadamente 24 horas por defecto (esto se puede cambiar). Durante una época, los validadores procesan las transacciones, obtienen recompensas y mantienen la red. Cuando termina una época, el sistema finaliza todo y pasa a la siguiente. Esta transición implica una breve pausa, denominada tiempo de reconfiguración, que da a la red la oportunidad de actualizar su estado interno de forma segura, algo parecido a respirar hondo antes de empezar la siguiente ronda.

Estas épocas son cruciales porque son en las que los conjuntos de validadores pueden cambiar. Sui utiliza un modelo de PoS delegado, por lo que los validadores se seleccionan en función de la cantidad de SUI que apuestan y de la cantidad que otros les delegan. Para convertirte en validador, debes cumplir con la apuesta mínima (por ejemplo, 30 SUI) y, para mantenerte en el grupo de validadores más altos, debes atraer una cantidad suficiente de participación delegada. Al final de cada época, el sistema comprueba estas clasificaciones y ajusta el conjunto de validadores de forma automática, sin necesidad de realizar cambios bruscos ni actualizaciones manuales.

Para gestionar el consenso, Sui utiliza un protocolo denominado Narwhal y Bullshark para transacciones complejas o de estados compartidos. Garantiza la seguridad incluso si algunos validadores se portan mal. Sin embargo, en el caso de las transacciones simples que no involucran objetos compartidos, Sui omite los consensos generalizados y las ejecuta en paralelo, lo que hace que todo sea más rápido.

Los validadores obtienen recompensas con las comisiones de transacción y el fondo de almacenamiento. Si un validador hace trampa (por ejemplo, al firmar varios mensajes contradictorios), puede ser penalizado (recortado), pero la forma en que funciona depende de la gobernanza, no del código.

En segundo plano, el sistema rastrea la información de época en un objeto especial en cadena. Este objeto almacena detalles como el número de época actual, cuándo comenzó y qué validadores están activos. Los desarrolladores no controlan esto directamente, pero puedes leer la época actual en tus contratos inteligentes de Move con epoch_time: :current_epoch (ctx).

Si quieres redactar contratos que almacenen los cambios de época o reaccionen a ellos, puedes crear tu propio objeto para rastrearlos. Hay un ejemplo del módulo Move que muestra cómo hacerlo, incluido cómo actualizar o leer la época en la lógica de tu aplicación.

Una cosa importante que debes saber es que solo el gobierno tiene permiso para ejecutar funciones a nivel del sistema, como añadir un nuevo validador al conjunto. Como desarrollador habitual, no puedes activarlas directamente desde tu código.

Para interactuar con épocas y validadores, puedes usar la CLI de Sui. Puedes comprobar la época actual, asignar tu SUI a un validador o incluso simular el comportamiento de un validador en localnet. Si ejecutas una red de prueba de forma local, puedes acortar la duración de la época (por ejemplo, a 10 segundos) para ver cómo se comporta tu aplicación durante las transiciones.

Desde el punto de vista de la seguridad y las pruebas, asegúrate de que tu aplicación pueda gestionar las transiciones de época. Esto significa volver a intentar las transacciones fallidas que se produjeron durante el tiempo de reconfiguración y comprobar que la lógica del contrato sigue siendo válida cuando la época cambie. Además, haz un seguimiento de los validadores con los que estás apostando y evita aquellos con un comportamiento o un tiempo de actividad deficientes.

En comparación con Ethereum, que utiliza un conjunto de validadores mayoritariamente fijo hasta una actualización, el conjunto de validadores de Sui es dinámico y se ajusta todos los días. Esa flexibilidad es poderosa, especialmente en casos de uso como los grupos de DeFi, que pueden necesitar cambios frecuentes en la delegación, pero también significa que debes diseñar tu lógica en torno a un sistema que esté siempre en movimiento.

Sui también admite la ejecución en paralelo para transacciones que no se superpongan, lo que evita los cuellos de botella del sistema bloque por bloque de Ethereum. Esta es una gran ventaja para las aplicaciones de gran volumen, como las que crean NFT o el procesamiento por lotes de transacciones de monederos.

Sin embargo, dado que Sui limita el acceso a algunas funciones del sistema, a diferencia del estilo «implementa cualquier cosa en cualquier momento» de EVM, tendrás que planificar con antelación si tus funciones dependen de validadores o épocas.

En Sui, las épocas y los conjuntos de validadores son componentes fundamentales de su modelo de consenso delegado de prueba de participación (DPoS). Una época es un período fijo durante el cual un conjunto específico de validadores es responsable de validar las transacciones y proteger la red. Al final de cada época, se puede formar un nuevo conjunto de validadores en función de la actividad de participación y las decisiones de gobierno. Los validadores se seleccionan en función de la cantidad de fichas de SUI que tienen apostadas, y los que delegan pueden apostar su SUI para contribuir a proteger la red y obtener recompensas. El poder de voto de cada validador es proporcional a la cantidad total apostada, lo que influye directamente en el consenso.

El mecanismo de puntos de control de Sui ayuda a finalizar las transacciones entre los validadores y garantiza una progresión determinista del estado. Los cambios en los validadores, las actualizaciones de las apuestas y las modificaciones de los parámetros del protocolo solo surten efecto al comienzo de una nueva época. Esta lógica de transición de época está codificada en los módulos Move del sistema Sui y es visible en el paquete sui-system. Los desarrolladores pueden inspeccionar los metadatos de epoch a través de la CLI de Sui mediante comandos como sui client call --function get_current_epoch.

A diferencia de las cadenas EVM, los cambios en los conjuntos de validación en Sui están estrechamente vinculados al modelo centrado en objetos y a las estrictas reglas de acceso de Move, que ayudan a mantener la coherencia y la seguridad durante las transiciones. Para evitar problemas de implementación, los desarrolladores deben diseñar los contratos para hacer referencia con cuidado a la información de los validadores dinámicos, especialmente en aplicaciones como la gobernanza, los paneles de control o los flujos de trabajo entre épocas.