En el corazón del Consenso de Unidad están los mecanismos de delegación de estaca y estaca, que son responsables de administrar los registros de estacadores y las actualizaciones de estaca. En este artículo, lo guiaré a través de las consideraciones de diseño que hemos hecho y los detalles de implementación. El código fuente está disponible en https://github.com/aionnetwork/protocol_contracts.
NOTA: Este artículo es una descripción general del estado actual de los contratos de Unity Protocol, que todavía están en su etapa inicial y están en constante evolución.
Cualquier sistema basado en prueba de participación (PoS) necesita una forma de gestionar el estado de la apuesta, es decir, la lista de apostadores registrados y la cantidad de apuesta de cada apostador en cualquier momento. Esta información decide la elegibilidad de un staker para producir un bloque PoS, y debe ser acordada por toda la red.
La gestión de estaca se implementa tradicionalmente dentro del cliente (software que utiliza un nodo para conectarse a la red), utilizando tipos de transacción específicos para el propósito, con la utilización de bases de datos o almacenamientos de datos. Esto se debe principalmente a la falta de capacidad de programación por encima del protocolo. La consecuencia de tal diseño es hacer que el protocolo sea pesado y gordo. Como resultado, es muy difícil implementar dicho sistema, dado que puede haber varios clientes en diferentes lenguajes de programación.
En el Consenso de Unidad, implementamos los mecanismos de delegación de estaca y participación en los contratos inteligentes de AVM. Tal elección de diseño nos da dos ventajas:
El modelo de ejecución y almacenamiento de un contrato inteligente está bien definido, por lo que será gratuito garantizar el consenso sobre el estado de la participación; la interacción del usuario será simple, ya que un usuario puede interactuar con un contrato inteligente utilizando la infraestructura de transacción existente (no Se requiere herramienta adicional).
Primero, echemos un vistazo al contrato de registro de staker, que es el punto final para todos los usuarios para participar en el replanteo. Un staker debe estar registrado en este contrato antes de que pueda producir un bloque PoS válido. Un poseedor de monedas puede votar / desestimar por un apostador registrado e incluso transferir la apuesta entre dos apostadores.
La estructura interna del registro de staker se muestra en la imagen a continuación. Un registro de staker está asociado con una colección de stakers registrados, unvotes pendientes y transferencias pendientes. Para comprender el estado / ciclo de vida de las monedas, remito a los lectores a la Sección 2.4 de las Especificaciones de ingeniería de Unity. Una copia del diagrama de transición del estado de la moneda también se adjunta a continuación.
Estructura del contrato de registro de staker: Moneda de estados y transiciones de estado desde la perspectiva del registro de staker
El contrato de registro de staker tiene privilegios, en el sentido de que el núcleo depende de él para decidir la validez de un bloque PoS. A pesar de ser privilegiado, este contrato está diseñado para ser simple y la interacción entre el núcleo y el contrato se limita a una sola llamada al método sin estado (una llamada al método sin estado no cambia el estado de un contrato inteligente durante la ejecución). Este método es getEffectiveStake (signAddress, coinbaseAddress), que devuelve la participación efectiva de un productor de bloques.
Registrar un apostador
Cualquiera puede registrar un staker llamando al método registerStaker del registro de staker, que tiene los siguientes parámetros.
identityAddress: (única) Una dirección utilizada para identificar a un staker; managementAddress: la dirección de la clave de administración utilizada al actualizar el staker, p. actualizar la dirección de firma; signAddress – (único) La dirección de la clave utilizada para firmar un bloque de PoS; coinbaseAddress – La dirección utilizada para recibir recompensas de bloque; selfBondAddress – La dirección utilizada para calcular la participación de un staker (auto-bond la apuesta de un staker es la apuesta de su propietario).
Separar la participación del propietario del staker de la participación de otros votantes nos brinda beneficios y flexibilidad adicionales. Por ejemplo, podemos aplicar el requisito de porcentaje de auto-enlace y el requisito mínimo de auto-enlace.
Votar
Votar es el proceso de convertir monedas líquidas en juego. Para votar por un apostador, el titular de una moneda debe llamar al método de voto (apilador), con una cantidad específica de monedas que se transfieren. Las monedas estarán bajo la custodia del contrato de registro de staker después de la votación.
Unvote
Para revocar una apuesta y recuperar las monedas, es necesario llamar al método de no votar (staker, cantidad), que cancelará la apuesta, la bloqueará por un período de tiempo predefinido, es decir, UNVOTE_LOCK_UP_PERIOD, y devolverá una identificación única pendiente de voto, si La solicitud es válida. Es solo después del período de bloqueo que el usuario realmente puede recuperar sus monedas, llamando al método finalizeUnvote (id).
Estaca de transferencia
El registro de staker también permite que un votante transfiera la participación de un staker a otro. Esto permite a los votantes intercambiar intereses entre productores de bloque sin pasar por un proceso de votación y voto, lo que implicaría el período de bloqueo sin voto.
Para transferir la apuesta, uno debe llamar al método transferStake (de, a, cantidad), que devuelve una identificación de PendingTransfer a solicitud válida. El usuario debe llamar al método finalizeTransfer (id) para completar la transferencia de apuesta, después de otro período de bloqueo, es decir, TRANSFER_LOCK_UP_PERIOD.
Si bien es fácil interactuar con el registro de staker, muchos poseedores de monedas preferirían delegar su apuesta a un grupo en lugar de mantener un nodo y una apuesta por su cuenta. Llamamos a este grupo de personas delegadores. Un grupo recibe apuestas de y redistribuye las recompensas de bloque a sus delegadores.
En el Consenso de Unidad, se diseña e implementa un sistema descentralizado de delegación de estaca, como en el contrato inteligente PoolRegistry. Esto es posible gracias a las siguientes condiciones:
El registro de staker es un contrato inteligente que permite que el registro de la agrupación interactúe a través de CALL entre contratos; Dev Ojha propone un algoritmo de distribución de recompensas eficiente (distribución de tarifas F1).
A diferencia del registro de staker, el registro de grupo no tiene privilegios y se implementa únicamente en función del marco existente proporcionado por AVM. A continuación se muestra una vista arquitectónica del diseño.
Arquitectura de registro de agrupación
En el frente está el PoolRegistry, que es el punto final para todos los propietarios y delegadores de piscinas. Para cada grupo registrado, el registro mantiene un PoolState, que está asociado con un PoolCoinbase, un PoolCustodianand un PoolRewardsManager.
PoolCoinbase es una instancia de contrato inteligente, bajo el control del registro de grupo, cuyo único propósito es recibir recompensas en bloque; El PoolCustodian es otra instancia de contrato inteligente, en el control del registro de grupo, que es el custodio de la participación del propietario del grupo; El PoolRewardsManager es un objeto interno, que calcula la parte de las recompensas de cada delegador a un grupo.
Registrar un grupo
Para registrar un grupo, el propietario debe seguir los siguientes pasos:
Publicar los metadatos, p. nombre y descripción, en un archivo JSON en una URL de acceso público (el esquema del archivo JSON se está definiendo activamente). la clave de firma que se utilizará para la producción en bloque, comissionRate es el cargo por servicio en porcentaje que el propietario del grupo desea tomar, y metaDataUrl y metaDataContentHash son la URL y el hash de los metadatos respectivamente.
Después de estos dos pasos, el grupo puede comenzar a aceptar participaciones de delegadores, incluido el propietario del grupo. Siempre y cuando se cumpla el requisito mínimo de participación de bonos propios, el propietario del grupo puede usar la clave de firma para producir bloques y ganar recompensas de bloque.
Un detalle de implementación interesante es que el método registerPool es complicado. Crea un staker en el registro de stakers, crea una instancia de PoolCoinbase y un PoolCustodian, y configura el staker correctamente. Esto asegurará que todas las recompensas en bloque del grupo vayan al registro del grupo.
Delegar
Para delegar la apuesta a un grupo, solo hay que llamar al método delegado (grupo) junto con una cierta cantidad de monedas AION para apostar. El registro de grupo utiliza la moneda recibida para apostar en el registro de staker.
Undelegate
Se requieren dos pasos para cancelar una delegación. Primero, el delegador necesita llamar al método undelegate (pool, amount) del registro de pool, que iniciará una operación de no votación y devolverá una identificación de PendingUnvote. En segundo lugar, tiene que llamar al método finalizeUnvote (id) para finalizarlo después del período de bloqueo sin votar.
Retirar
La retirada es el proceso de reclamar las recompensas de bloque que un delegador ha ganado hasta ahora. Esto se hace llamando al método de retiro (pool), que transferirá las recompensas al delegador ante una solicitud válida. Para saber cómo decide el contrato las recompensas en bloque, consulte el esquema de distribución de tarifas F1.
Redelegación y autodelegación
La redelegación es el proceso de delegar a un grupo utilizando las recompensas de bloque obtenidas de ese grupo. Esto es esencialmente una combinación de retiro y delegado.
La redelegación automática permite que un delegador permita que otros redeleguen sus recompensas en bloque. Esto se implementa mediante la introducción de un mercado de autodelegación. Si un delegador establece una tasa de redelegación automática, cualquiera puede llamar al registro del grupo para redelegar automáticamente las recompensas del delegador en su nombre. La persona que llama obtendrá una parte de las recompensas como incentivos basados en la tasa de autodelegación.
En caso de que alguien esté interesado en cómo fluyen las monedas en el sistema de delegación, a continuación se proporciona una descripción general (los cuadros con fondo oculto son instancias de contratos inteligentes). Intuitivamente, todas las recompensas de participación y bloque de PoS del delegador están bajo la custodia del contrato del Registro de Pool; toda la participación del propietario de la piscina está bajo la custodia del contrato del Custodio de la piscina. Si las monedas son para delegación, entonces fluyen al Registro de Staker.
Flujos de monedas en el sistema de delegación.
Ahora, ha revisado una descripción general de los contratos de delegación y participación de Unity. Si desea obtener más información sobre los detalles, lea las especificaciones de Unity Engineer o el código fuente del contrato inteligente.
