Regenesis de Lisk Mainnet

noviembre 01, 2020 VICTOR HUGO LAZARTE 0 Comments

 


Introducción

Si usted ha estado siguiendo nuestras publicaciones en el blog de investigación y hoja de ruta , que ya se dará cuenta de la gran cantidad de mejoras que forman parte de la Lisk SDK 5.0 y la próxima versión MainNet Lisk Core 3.0. Hemos cubierto la mayoría de estas mejoras importantes en nuestra serie de publicaciones de blog de investigación, y a continuación se ofrece una breve descripción general de ellas:

Todas estas mejoras implican un cambio significativo del protocolo Lisk y, en particular, un cambio importante en el formato de cuentas, transacciones y bloques. Quizás se pregunte cómo realizamos la migración de Lisk Mainnet a este protocolo tan diferente. Por lo tanto, el propósito de esta publicación de blog es explicar nuestro enfoque de regénesis para abordar la complejidad de la migración. Por ejemplo, aprenderá cómo se migra su cuenta y cómo podrá votar en el nuevo sistema DPoS. Además, explicamos el nuevo formato de bloque de génesis que forma parte de Lisk SDK 5.0 y se utiliza para el enfoque de la regénesis. Las especificaciones técnicas completas del nuevo formato de bloque génesis se dan en LIP 34 y las especificaciones de las migraciones están contenidas en LIP 35 .

En la primera sección de esta publicación de blog, comenzamos brindando un poco de contexto y profundizamos en los antecedentes teóricos. En la siguiente sección, cubrimos el nuevo formato de bloque génesis en Lisk SDK y discutimos los beneficios que brinda a los desarrolladores de SDK. Finalmente, en la última sección, explicamos el enfoque de regénesis para la migración de Lisk Mainnet que se basa en la creación de una instantánea de la cadena de bloques Lisk y en la utilización del nuevo formato de bloque de génesis.

Blockchain como una máquina de estado replicada

Una máquina de estados es un modelo abstracto para un sistema que puede estar exactamente en uno de un número finito de estados y, dependiendo de algunas entradas, cambia de un estado a otro. Muchas máquinas del mundo real, como semáforos, ascensores o una máquina de café, pueden modelarse como una máquina de estado.

Un nodo Lisk también se puede modelar como una máquina de estado. En este caso, un estado del nodo Lisk corresponde al conjunto de estados de cuentas (direcciones con saldo asociado, votos, registro de delegados,…), y alguna información auxiliar como la altura actual y el último ID de bloque. El número total de estados en este caso es increíblemente grande, por ejemplo, un saldo diferente para una sola cuenta corresponde a un estado diferente de toda la cadena de bloques. Las entradas que hacen que el nodo Lisk cambie de un estado a otro son bloques. Cada vez que el nodo aplica un bloque y las transacciones en la carga útil del bloque, pasa de un estado a otro. Consideremos el ejemplo concreto a continuación:

El nodo Lisk está en un estado, al que llamamos s 1 , donde un usuario A tiene 100 LSK, un usuario B 50 LSK y un delegado C tiene 600 LSK. En el bloque que luego se aplica, hay una transferencia de token de 20 LSK del usuario A al usuario B y el delegado de falsificación C recibe una recompensa de bloque de 1 LSK (para simplificar asumimos que no hay tarifas). Esto significa que la aplicación del bloque hace que el nodo Lisk cambie a un nuevo estado, al que llamamos s 2 , donde el usuario A tiene 80 LSK, el usuario B 70 LSK y el delegado C 601 LSK. De esta manera, un nodo Lisk puede modelarse como una máquina de estado que comienza con un estado inicial predefinido y luego cambia a diferentes estados dependiendo de qué bloques se apliquen o eliminen.
Lisk Mainnet no está compuesta por un solo nodo, sino por cientos de nodos que se supone que eventualmente aplicarán los mismos bloques (y así alcanzarán el mismo estado). Aquí es donde entra en juego el protocolo de consenso. El protocolo de consenso es un algoritmo para que los nodos se pongan de acuerdo en el mismo bloque en cada altura. Por lo tanto, una cadena de bloques también se conoce como una máquina de estado replicada porque cada nodo es una máquina de estado y el protocolo de consenso asegura que los mismos estados se replican en toda la red.

Estado e Historia

Un estado comprende todos los datos necesarios para validar y aplicar bloques futuros. Es importante comprender que el estado a una cierta altura es almacenado por cada nodo y se puede calcular aplicando bloques y transacciones hasta esa altura, pero generalmente no es parte explícita de la cadena de bloques. Por ejemplo, una transacción de transferencia de tokens con la cantidad transferida se incluye en un bloque, pero los saldos de cuenta actualizados no se agregan al bloque, aunque todos los nodos los almacenan.

Para la cadena de bloques Lisk, el estado contiene toda la información de la cuenta, es decir, todas las direcciones que se usaron alguna vez, su saldo, nonce, votos y posiblemente información de registro de múltiples firmas y delegados. Además, la altura actual, el ID del último bloque y la marca de tiempo son parte del estado porque son necesarios para procesar el siguiente bloque (el siguiente bloque debe incluir el ID del bloque anterior, tener una altura de uno más grande y una marca de tiempo más grande que el anterior bloquear). Estrictamente hablando, alguna información adicional relacionada con el consenso, como las semillas aleatorias utilizadas para seleccionar a los delegados en espera, también es parte del estado.

Sin embargo, las transacciones pasadas de transferencia de tokens no son parte del estado, por ejemplo. Si tiene 100 LSK en su cuenta, no importa si recibió 1 transferencia de 100 LSK o 100 transferencias de 1 LSK. Todo lo que importa para procesar cualquier acción futura que desee realizar con su cuenta es que tiene 100 LSK. En general, todos los bloques y transacciones se consideran parte del historial de blockchain y no son parte del estado. Cuando decimos que una cadena de bloques es inmutable, en realidad queremos decir que el historial de bloques y transacciones finalizados es inmutable. En contraste con eso, el estado de la cadena de bloques está en constante evolución a medida que se aplican nuevos bloques.

Nuevo formato de bloque Lisk SDK Genesis

El propósito del bloque de génesis es producir el estado inicial deseado de una cadena de bloques. Una parte importante del estado inicial es la distribución inicial de tokens. Veamos el bloque de génesis de Lisk Mainnetcomo ejemplo. Para lograr la distribución de tokens deseada, el bloque génesis contiene transacciones de transferencia de tokens a todos los participantes de ICO. Estas transferencias de tokens se originan en una cuenta de génesis especial (dirección de Lisk 6566229458323231555L en el formato antiguo), que puede tener un saldo negativo. Para una cadena de bloques DPoS, también es esencial definir algunos delegados iniciales que puedan forjar bloques en el bloque génesis y poner en marcha toda la cadena de bloques. En el bloque génesis de Lisk Mainnet, esto se logra mediante la inclusión de 101 transacciones de registro de delegados para los delegados genesis_1, ..., genesis_101, y algunas transacciones de delegado de voto que votan por estos delegados. La idea es que estos delegados iniciales asuman el trabajo de forjar bloques hasta que suficientes usuarios hayan registrado un delegado y votado.

En general, el bloque de génesis de Lisk Mainnet contiene 8176 transacciones, lo que hace que el bloque de génesis sea bastante grande. Además, administrar de forma segura 101 cuentas de delegados y frases de contraseña para iniciar una nueva cadena de bloques puede ser engorroso. Esa es una de las razones por las que presentamos un formato de bloque génesis más compacto y fácil de usar en el Lisk SDK 5.0. La idea es que los desarrolladores de cadenas laterales puedan definir el estado inicial deseado explícitamente, en lugar de tener que crear y firmar muchas transacciones que produzcan el estado deseado.

Veamos más de cerca cómo se define el estado inicial en el nuevo formato de bloque de génesis. Esencialmente, las siguientes tres propiedades del bloque, que son exclusivas del bloque génesis, determinan el estado inicial:

  • cuentas : esta propiedad contiene una serie de cuentas. Cada cuenta debe incluir la dirección de la cuenta y el saldo inicial, mientras que todas las demás propiedades pueden ser simplemente valores predeterminados.
  • initDelegates : El valor proporcionado para esta propiedad debe ser una matriz de direcciones de delegado que se forjarán durante el período de arranque, las rondas iniciales que permiten a los usuarios registrar delegados y votar. Estas direcciones también deben incluirse en la matriz de cuentas y ser cuentas registradas como delegados con un nombre de delegado específico. Los creadores de blockchain tienen la flexibilidad de proporcionar solo uno o unos pocos delegados aquí, siempre que el número sea como máximo la longitud redonda de su blockchain.
  • initRounds : esta propiedad define la duración del período de arranque, durante el cual los delegados dados en initDelegates forjan bloques. Posteriormente, se activa el algoritmo normal de DPoS y los delegados se seleccionan de acuerdo con los votos actuales. Por razones técnicas, este valor tiene que ser al menos 3. El valor elegido debe ser lo suficientemente grande para que la mayoría de los usuarios tengan tiempo suficiente para registrar delegados y votar para evitar un conjunto de delegados inestable y drásticamente cambiante en las rondas después del final de la período de arranque.

En general, dar el estado inicial de la cadena de bloques permite explícitamente un bloque de génesis más compacto y también simplifica el arranque de una nueva cadena de bloques, ya que administrar solo una cuenta delegada es suficiente. Si desea conocer más detalles sobre el nuevo formato de bloque génesis, consulte LIP 34 , que contiene las especificaciones técnicas completas.

Proceso de regeneración y bifurcación dura de Lisk Mainnet

Lisk Core 3.0 no solo presenta un nuevo protocolo muy mejorado, sino que su lanzamiento también implica un hard fork para Lisk Mainnet, ya que los nodos Lisk Core 2.x no pueden procesar ninguna transacción o bloque siguiendo el nuevo protocolo de Lisk Core 3.0. Por lo tanto, todos los operadores de nodos que quieran admitir el nuevo protocolo deben actualizar sus nodos.

Para el hard fork de mainnet y la migración a Lisk Core 3.0, proponemos un nuevo enfoque de regenesis. La idea básica del enfoque se ilustra en el diagrama siguiente. A la altura de la bifurcación dura, a la que nos referimos como altura de regénesis, cualquier operador Lisk Core 2.x puede ejecutar un script de instantánea que toma una instantánea del estado de la cadena Lisk Core 2.x. Esta instantánea incluye todas las cuentas, sus saldos y otras propiedades de la cuenta, así como los 103 delegados principales. La instantánea del estado se exporta como un bloque de instantáneas especial que sigue el formato descrito en la sección anterior. El bloque de instantáneas se requiere como entrada para que el nodo Lisk Core 3.0 comience a unirse a la red Lisk Core

Este enfoque para el hard fork de la red principal es tan confiable y descentralizado como los hard fork anteriores, ya que cada nodo puede calcular de forma independiente el bloque de instantáneas. En comparación con las horquillas duras anteriores, esta próxima horquilla dura también tiene algunas características especiales. Si bien los nodos de Lisk Core 2.x son totalmente compatibles con versiones anteriores, lo que significa que pueden procesar cualquier bloque desde el bloque génesis en adelante y también admitir versiones de protocolo anteriores, Lisk Core 3.0 no será totalmente compatible con versiones anteriores y solo comprenderá bloques desde el bloque de instantáneas en adelante. La razón de esto es que es difícil tener una base de código que admita dos algoritmos de consenso muy diferentes, dos sistemas de direcciones y formatos muy diferentes para transacciones y bloques. Cortar la compatibilidad con versiones anteriores tiene la ventaja de reducir significativamente la complejidad de la migración, ya que el bloque de instantáneas proporciona una interfaz simple entre el protocolo antiguo y el nuevo. Además, no admitir todas las versiones anteriores del protocolo reduce en gran medida la complejidad del código base y facilita las pruebas y la introducción de nuevas funciones.La única desventaja es que para verificar la exactitud de toda la cadena de bloques Lisk desde el bloque génesis en adelante, ahora es necesario ejecutar dos implementaciones, primero Lisk Core 2.xy luego Lisk Core 3.0. Como operador de nodo que se une a Lisk Mainnet después de la bifurcación, tiene la opción de calcular el bloque de instantáneas usted mismo usando Lisk Core 2.xo obtenerlo de alguna fuente confiable que permita una sincronización más rápida con la red.

Migración de cuenta

En esta sección, proporcionamos más detalles sobre cómo se migran las cuentas como parte del hard fork.

Debido al nuevo sistema de direcciones, se deben migrar todas las direcciones de las cuentas. Para las cuentas que han enviado al menos una transacción, cada nodo Lisk Core 2.x almacena la clave pública como parte de la cuenta, lo que permite calcular la nueva dirección durante la creación de la instantánea. A continuación se muestra un ejemplo de una migración de cuenta de este tipo. Tenga en cuenta que los nodos Lisk Core 3.0 ya no almacenarán la clave pública, ya que la nueva dirección es lo suficientemente larga y almacenar la clave pública no proporciona ningún beneficio de seguridad adicional.

Las cuentas que nunca han enviado una transacción no se pueden migrar al nuevo sistema de direcciones automáticamente, ya que se desconocen sus claves públicas. Estas cuentas también se migran a Lisk Core 3.0 con la dirección y el saldo anteriores. Para luego usar el saldo en la red Lisk Core 3.0, el titular de la cuenta debe migrar la cuenta al nuevo sistema de direcciones manualmente enviando una transacción especial de reclamo LSK que incluye la clave pública necesaria. Para evitar tener que hacer este paso adicional en el futuro, solo tiene que enviar al menos una transacción desde su cuenta, por ejemplo, una transferencia de 1 LSK a usted mismo. Esto también se recomienda actualmente para asegurar completamente su cuenta, ya que las direcciones más cortas actuales tienen una resistencia de preimagen relativamente baja (consulte el sistema de direcciones entrada de blog para obtener más detalles).

Lisk Core 3.0 introdce un sistema de firma múltiple mejorado que permite la posibilidad de registrar un conjunto de claves públicas obligatorias, un conjunto de claves públicas opcionales y un número mínimo de firmas requeridas. Se proporciona una explicación detallada de las cuentas de múltiples firmas y estas propiedades en Cuentas de múltiples firmasentrada en el blog. Cada cuenta de firma múltiple existente en la cadena Lisk Core 2.x se convierte en una cuenta de firma múltiple con una clave obligatoria, la clave que registró la cuenta, las claves en la propiedad del grupo de claves como claves opcionales y el valor mínimo como el número mínimo de requeridos firmas. De esta manera, se conservan las condiciones de firma para las cuentas de múltiples firmas: el propietario de la cuenta original siempre tiene que firmar y el conjunto de claves públicas, así como el número de firmas requeridas, permanecen sin cambios.

Además, también migramos cuentas de segunda firma a cuentas de firma múltiple. Recuerde que en Lisk Core 2.xa la segunda transacción de registro de firma ofrece la posibilidad de registrar una segunda clave pública. Posteriormente, tanto la clave pública original como la segunda son obligatorias para firmar una transacción. Se migra una segunda cuenta de firma a una cuenta de firma múltiple donde ambas claves públicas son obligatorias y se requieren dos firmas. Tenga en cuenta que esto solo afecta la forma en que estas cuentas se representan en el protocolo. Las condiciones de firma son exactamente las mismas y estas cuentas se representarán de manera similar en la interfaz de usuario. La razón principal para migrar cuentas de segunda firma a cuentas de firmas múltiples es tener un protocolo más simple y ágil que aún sea compatible con todas las funciones existentes anteriores.

Migración a un nuevo sistema DPoS

En el nuevo sistema DPoS, los usuarios votan por un delegado bloqueando tokens, consulte la publicación del blog DPoSpara detalles. Cada token de LSK solo se puede usar una vez para votar y, en general, los usuarios solo pueden votar por hasta diez delegados con una cuenta. Debido a estos cambios, los votos en el antiguo sistema DPoS no son válidos y se descartan como parte del hard fork. Esto significa que la cadena Lisk Core 3.0 comenzará desde el bloque de instantáneas sin ningún voto y, por lo tanto, es importante que todos los usuarios vuelvan a votar después del hard fork. Como se muestra en el diagrama a continuación, los 103 mejores delegados según el antiguo sistema de votación se seleccionan para iniciar la cadena Lisk Core 3.0 y forjar las primeras 600 rondas (aproximadamente 7 días). Una vez transcurrido este tiempo, el nuevo sistema DPoS se activa y los delegados serán seleccionados de acuerdo con los votos emitidos en estas 600 rondas.
 

Esperamos que 7 días sea un período de tiempo suficiente para que la mayoría de las cuentas activas vuelvan a votar, de modo que el conjunto de delegados activos sea lo suficientemente estable a partir de ese momento. Tenga en cuenta que seleccionar delegados con el nuevo sistema DPoS después de una ronda, por ejemplo, sería muy arriesgado y abriría la puerta a posibles ataques. Esto se debe al hecho de que es relativamente fácil para un atacante controlar una mayoría de delegados si solo unas pocas cuentas votan, dado que el atacante también puede evitar que otros voten en un período de tiempo tan corto al enviar una gran cantidad de transacciones de tarifa.

Conclusión

Esta publicación de blog presenta el nuevo formato de bloque de génesis Lisk SDK, como se define en LIP 34 , y explica el enfoque de regénesis para la próxima migración de Lisk Mainnet, como se especifica completamente en LIP 35 . Para los usuarios de Lisk, el mensaje clave aquí es que sus fondos se migrarán automáticamente de manera segura. Recuerde prestar atención a nuestros canales de redes sociales para conocer la fecha de la bifurcación de Lisk Mainnet para que pueda volver a votar después de la migración. Para los operadores de nodos, se espera que esta publicación de blog proporcione información básica útil para el futuro hard fork. Presentaremos una guía más detallada para actualizar a Lisk Core 3.0 a su debido tiempo.

Para preguntas y comentarios adicionales sobre el tema, organizaremos un AMA en Lisk.chat con Jan Hackfeld el próximo viernes 23 de octubre a las 4 pm CEST. También invitamos a todos los miembros de la comunidad a que vayan al foro de Lisk Research , donde siempre nos complace escuchar sus comentarios y participar en debates sobre este y otros temas.

Lisk tiene la misión de permitirle crear aplicaciones blockchain descentralizadas, eficientes y transparentes. 

Recursos

  




  Introducción Si usted ha estado siguiendo nuestras  publicaciones en el blog de investigación  y  hoja de ruta  , que ya se dará cuenta de...