Lisk generación de certificados y consenso

febrero 26, 2022 VICTOR HUGO LAZARTE 0 Comments

En esta publicación de blog, veremos en detalle los certificados, el objeto clave para hacer que la interoperabilidad de Lisk sea segura. Explicamos qué son los certificados, cómo se generan y cómo se conectan al protocolo de consenso. Además, discutimos los supuestos de seguridad y las garantías de la solución de interoperabilidad de Lisk.

El tema de esta publicación de blog también se presentó en Lisk.js 2021 . Además, tenga en cuenta que esta publicación de blog es parte de una serie de publicaciones de blog en curso sobre la interoperabilidad en Lisk. En su mayoría, tratamos de mantener el contenido autónomo, pero como información general, es útil una comprensión general de la solución de interoperabilidad de Lisk (consulte esta publicación de blog o este video en Lisk.js 2021 para obtener una introducción general al tema).

Interoperabilidad de listas y certificados

La solución de interoperabilidad de Lisk se basa en el paradigma de la certificación entre cadenas . En pocas palabras, esto significa que la información de otra cadena de bloques se acepta y procesa si la exactitud de esta información está certificada por un certificado . Un certificado en este contexto es un objeto firmado por varias entidades, normalmente los validadores de la cadena de bloques de donde se origina la información. Esto garantiza que el certificado y, por lo tanto, la información asociada sean confiables y no puedan ser manipulados. En cierto modo, puede ver estos certificados de cadena cruzada como una versión descentralizada de los certificados de clave pública que protegen la mayor parte de la comunicación a través de Internet en la actualidad.

Recapitulemos brevemente aquí cómo funciona la interoperabilidad en el ecosistema de Lisk y de qué manera se utilizan los certificados en Lisk. Los medios para enviar información de una cadena de bloques a otra son los mensajes de cadena cruzada (CCM) . Cualquier transacción puede emitir mensajes entre cadenas y luego se retransmiten a la cadena de recepción donde se procesan. Para obtener más información sobre los mensajes entre cadenas, consulte esta publicación de blog o la charla relacionada de Lisk.js 2021 .

Los contenedores para enviar información a otra cadena de bloques son transacciones de actualización entre cadenas (CCU) . Estas transacciones permiten que cualquier persona envíe mensajes entre cadenas junto con un certificado que acredite la corrección de estos mensajes a otra cadena de bloques. Véase también el diagrama siguiente. Si desea obtener más detalles sobre las transacciones de actualización entre cadenas, consulte esta publicación de blog o esta charla de Lisk.js 2021 . 

En Lisk, cada cadena de bloques generará regularmente certificados que son firmados colectivamente por los validadores actuales de la respectiva cadena de bloques. Además, cada cadena de bloques en el ecosistema de Lisk realiza un seguimiento de los validadores actuales de cada cadena de bloques con la que se comunican directamente. Por ejemplo, Lisk Mainchain realiza un seguimiento de los validadores de todas las cadenas laterales. Esto permite que Lisk Mainchain en el ejemplo anterior verifique si el certificado de hecho fue firmado colectivamente por los validadores de la cadena lateral. Tenga en cuenta que no todos los validadores están obligados a firmarlo, sino solo un cierto quórum.

En resumen, los certificados y la validez de las firmas contenidas en los certificados son la base para la seguridad de la interoperabilidad y la razón por la cual la información de otras cadenas se considera correcta y confiable.

Consenso Lisk-BFT

Antes de explicar el proceso de generación de certificados, primero repasemos algunos conceptos básicos relacionados con el protocolo de consenso utilizado en Lisk, ya que estos están relacionados con la generación de certificados y las garantías de seguridad que se analizan más adelante. Por protocolo de consenso nos referimos al protocolo para que los validadores (delegados en el caso de DPoS y autoridades en el caso de PoA) acuerden una cadena de bloques. En particular, el protocolo de consenso define cuándo un bloque y todas las transacciones incluidas son definitivas , es decir, irrevocablemente consideradas parte de la cadena de bloques.

El protocolo de consenso utilizado en Lisk SDK y en Lisk Mainchain se llama Lisk-BFT (se puede encontrar una introducción detallada al protocolo en esta publicación de blog ). Una propiedad importante de este protocolo, como sugiere su nombre, es que proporciona tolerancia a fallas bizantinas (BFT) . Esto significa que el protocolo funciona correctamente incluso si algunos de los validadores son bizantinos , es decir, están fuera de línea o intentan manipular la red maliciosamente. Las dos propiedades técnicas clave a las que nos referimos con “funciona correctamente” son las siguientes:

  • Seguridad : nunca hay dos bloques en conflicto (bloques en los que ninguno es descendiente del otro) que se consideren definitivos. Esta propiedad es importante para evitar el doble gasto , es decir, que un usuario pueda gastar fondos dos veces, cada una de manera diferente en los dos bloques finalizados.
  • Animación : los nuevos bloques siempre se finalizan. Esta propiedad es importante ya que los usuarios quieren confiar en que un pago sea irreversible en algún momento.

La propiedad de vida y seguridad solo está garantizada si no hay demasiados validadores bizantinos o, en otras palabras, si suficientes validadores son honestos , es decir, siguen correctamente el protocolo Lisk-BFT. Concretamente, si más de ⅔ de los validadores son honestos, Lisk-BFT garantiza la seguridad y la vida (como nota técnica: son necesarias algunas condiciones adicionales para cambiar los validadores y para la condición de vida, consulte el documento técnico para obtener más detalles ). Para Lisk Mainchain, esto significa que mientras al menos 68 de los delegados activos sean honestos, tanto la propiedad de seguridad como la de vida se mantienen.

Proceso de generación de certificados

Como se mencionó en la introducción, en el ecosistema de Lisk, cada cadena de bloques generará regularmente nuevos certificados. Este proceso se puede describir en los siguientes tres pasos.

Paso 1: Calcular el certificado sin firmar del bloque finalizado

En este primer paso, tan pronto como se finaliza un nuevo bloque B, cada validador en la cadena de bloques calcula un certificado sin firmar del bloque B. Esto se hace simplemente tomando un subconjunto de las propiedades del encabezado del bloque de B, es decir, aquellas relevantes para el cruce. comunicación en cadena.

También es muy importante que los certificados solo se generen para bloques finalizados. La razón es que solo los mensajes entre cadenas emitidos por transacciones en bloques finalizados pueden comunicarse de manera confiable a otras cadenas. De lo contrario, podría surgir la situación problemática de que un mensaje se comunique a otra cadena (por ejemplo, se deben acreditar 10 LSK a un usuario) aunque se invierta la transacción que emite el mensaje en la cadena de envío (por ejemplo, se debita 10 LSK de un usuario).

Paso 2: computar y transmitir firmas de certificados

Como segundo paso, después de calcular el certificado sin firmar, cada validador calcula su firma del certificado y, posteriormente, transmite esta firma a la red P2P. Para Lisk Mainchain, esto significa que los 101 delegados activos calculan su firma de certificado y, posteriormente, 101 firmas distintas se comparten a través de la red P2P.

Paso 3: Agregación de firmas e inclusión en bloque

En el tercer paso, uno de los validadores de blockchain agrega todas las firmas del certificado que recibió a través de la red P2P y agrega esta firma agregada a un bloque. En el caso de Lisk Mainchain, se agregarían hasta 101 firmas diferentes en una firma compacta, que luego se agrega a un bloque.

Aquí es importante tener en cuenta que para las firmas de certificados usamos firmas BLS en Lisk (ver LIP 38 para detalles técnicos). Estas son diferentes de las firmas utilizadas en las transacciones y tienen la propiedad conveniente de que muchas firmas diferentes se pueden agregar de forma compacta a una sola firma. Por ejemplo, las 101 firmas BLS distintas de los delegados activos de Lisk Mainchain tendrían cada una un tamaño de 96 bytes, pero solo se pueden agregar a una firma BLS de 96 bytes de tamaño. Dado que los certificados se intercambiarán con frecuencia entre diferentes cadenas de bloques en el ecosistema de Lisk, tener firmas agregadas compactas y, por lo tanto, certificados compactos es importante para una comunicación eficiente entre diferentes cadenas.

Ahora, después de completar los tres pasos, cualquiera puede obtener el certificado completo de la cadena de bloques obteniendo el bloque B, calculando el certificado sin firmar y luego obteniendo la firma agregada a la cadena de bloques en el Paso 3. Esto significa que cualquiera que siga la cadena de bloques tiene la posibilidad de crear actualizaciones entre cadenas porque todos los datos necesarios están disponibles para ellos.

Validación de Certificados y Cadena de Confianza

En la introducción, mencionamos que cada cadena de bloques realiza un seguimiento de los validadores de todas las demás cadenas de bloques con las que se comunica y utiliza esta información para validar los certificados enviados como parte de las transacciones de actualización entre cadenas. En esta sección, explicamos más en detalle cómo funciona esto.

De lo que realmente hace un seguimiento una cadena de bloques para validar certificados es la siguiente información:

  • las claves públicas BLS de los validadores de la otra cadena de bloques,
  • para cada clave pública BLS un peso asociado llamado peso BFT ,
  • el umbral del certificado , un valor de umbral requerido para que los certificados sean válidos.

Entonces, un certificado es válido si, además de algunas verificaciones básicas de formato en todas las propiedades, está firmado por un subconjunto de las claves públicas BLS actualmente conocidas, y la suma de los pesos BFT de los firmantes es al menos el valor umbral del certificado.

Para comprender mejor lo que esto significa, veamos el ejemplo que se muestra en la Figura 6 a continuación. Aquí, las claves públicas de cuatro validadores, A, B, C y D, que son conocidas por Lisk Mainchain, cada uno de ellos tiene un peso BFT de 1 y el umbral del certificado es 3. Esto significa que se debe firmar un certificado válido. por al menos 3 de los 4 validadores. Tenga en cuenta que las claves públicas del validador inicial, los pesos BFT y el umbral del certificado se establecen en el registro de la cadena lateral en Lisk Mainchain. En el ejemplo, observamos que si los validadores en la cadena lateral cambian, pero las claves públicas en Lisk Mainchain no se actualizan, los certificados generados por la cadena lateral ya no se consideran válidos para Lisk Mainchain.

La solución a este problema es utilizar también certificados para atestiguar cambios de validadores, pesos BFT o umbral del certificado. La propiedad hash de los validadores contenida en cada certificado se calcula a partir de las claves públicas de BLS, los pesos de BFT y el umbral de certificado válido a partir del siguiente bloque en adelante . Esto significa que las notificaciones sobre un cambio futuro de cualquiera de estas propiedades a partir del siguiente bloque pueden incluirse en una transacción de actualización entre cadenas y la propiedad hash de los validadores en el certificado permite verificar que la información proporcionada era correcta.

Repasemos el ejemplo anterior. El siguiente diagrama ilustra cómo el hash de los validadores certifica los cambios de las claves públicas de BLS. Por ejemplo, el Certificado 1 certifica la sustitución del validador A por el validador E y el Certificado 2 la sustitución del validador B por el validador F. Presentar estos certificados como parte de una actualización de cadena cruzada junto con la información sobre el cambio de validadores, es decir, el nuevas claves públicas de validador, luego permite mantener la cadena principal de Lisk actualizada con los validadores de cadena lateral actualmente activos.

Una propiedad importante que nos gustaría cumplir con los certificados generados de una cadena de bloques es que en realidad se pueden enviar secuencialmente a otra cadena de bloques. Por ejemplo, si el Certificado 2 en la Figura 7 nunca se generaría, entonces el Certificado 3 no se puede enviar como parte de una actualización de cadena cruzada directamente después del Certificado 1, porque el validador F aún no se comunicó a Lisk Mainchain y firmas por al menos 3 Se requieren validadores.

Entonces, lo que necesitamos es que en la secuencia de certificados generados por una cadena de bloques, la firma del certificado sea siempre válida con respecto a las claves públicas BLS, los pesos BFT y el umbral del certificado autenticado por el hash de los validadores del certificado anterior. Decimos en ese caso que la secuencia de certificados satisface la cadena de propiedad fiduciaria. Observe que los tres certificados de la Figura 7 satisfacen la propiedad de la cadena de confianza . Si se cumple esta cadena de propiedad de confianza, los certificados siempre se pueden enviar de forma secuencial como parte de las transacciones de actualización entre cadenas, y otras cadenas de bloques se pueden mantener actualizadas sobre los validadores actuales.

Dado que la cadena de propiedad fiduciaria es crucial para la interoperabilidad, implementamos incentivos adicionales para garantizar que siempre se cumpla. En una cadena de bloques que utiliza DPoS, requerimos que se genere un certificado que acredite que un delegado abandona el conjunto de delegados activos antes de que ese delegado y sus votantes puedan desbloquear sus tokens (consulte LIP 59 para obtener más detalles). Para una cadena de bloques que utiliza PoA, las autoridades suelen tener cierto grado de propiedad en el proyecto y suelen ser entidades públicas con su reputación en juego. Por lo tanto, no se incluyen incentivos adicionales para las cadenas de bloques PoA.

Supuestos y garantías de seguridad

Los certificados son la base para la seguridad de la comunicación entre cadenas y en esta sección queremos analizar las garantías de seguridad deseadas y los supuestos de seguridad necesarios.

 

Para que la comunicación entre cadenas sea segura, nos gustaría que (1) cada mensaje entre cadenas recibido por una cadena de bloques en el ecosistema de Lisk sea un mensaje que haya sido enviado por la cadena de envío. Además, nos gustaría que (2) todos los mensajes entre cadenas se entreguen eventualmente. Consideremos las siguientes dos propiedades de los certificados generados por una cadena de bloques y luego analicemos cómo se relacionan con las propiedades anteriores.

  • Validez de la certificación : los certificados generados por una cadena de bloques se derivan de una cadena de bloques finalizados que definen transiciones de estado válidas según el protocolo de la cadena de bloques.
  • Vigencia de la certificación : la cadena de bloques genera continuamente nuevos certificados derivados de nuevos bloques y la secuencia de certificados satisface la cadena de propiedad de confianza. En particular, los nuevos bloques se finalizan continuamente.

Suponga que tanto la validez de la certificación como la vigencia de la certificación se cumplen para una cadena lateral. Luego, los certificados generados por esa cadena lateral se pueden enviar secuencialmente a Lisk Mainchain. En particular, esto permite crear transacciones de actualización entre cadenas para mantener la cadena principal de Lisk actualizada con los validadores activos en la cadena lateral y para enviar nuevos mensajes entre cadenas. Además, debido a la propiedad de validez de la certificación, todos los mensajes entre cadenas atestiguados por el certificado deben haber sido emitidos por una transacción en la cadena lateral. Por lo tanto, ambas propiedades iniciales deseadas (1) y (2) se cumplen.

 

En general, la comunicación entre cadenas entre un grupo de cadenas de bloques en el ecosistema Lisk es segura si cada cadena del grupo cumple con la propiedad de validez y vida de la certificación. Sin embargo, incluso si una cadena de bloques falla en una de las propiedades, esta falla se limita solo a los mensajes emitidos por esa cadena de bloques. Además, existen medidas adicionales, como el depósito en garantía en el módulo Token , que limitan el impacto potencial de los mensajes de una cadena de bloques que no cumplan con estas condiciones.

 

Observe que ambas propiedades están estrechamente relacionadas con las propiedades del protocolo de consenso de la cadena de bloques. La validez de la certificación requiere que se mantenga la propiedad de seguridad porque dos bloques finalizados en conflicto darían lugar a certificados en conflicto que violan la validez de la certificación. Además, se requiere la propiedad de vitalidad ya que sin nuevos bloques finalizados no se pueden generar nuevos certificados.

 

Ahora, consideremos algunos supuestos suficientes para que se mantengan tanto la validez de la certificación como la vigencia de la certificación. Suponga que más de dos tercios de los validadores activos de blockchain, en términos de pesos BFT, son siempre honestos. Esto significa que tanto la propiedad de seguridad como la de vitalidad se cumplen (por simplicidad, ignoramos algunas condiciones adicionales para cambiar los validadores aquí). Suponemos además que el umbral del certificado es el mismo que el umbral requerido para finalizar un bloque, que en general es la opción recomendada y la predeterminada en el protocolo Lisk. Si luego ampliamos la definición de honesto para que también signifique participar correctamente en el protocolo del proceso de generación de certificados, entonces se mantienen tanto la validez de la certificación como la propiedad de vida de la certificación.

Resumen

Los certificados son el objeto clave para hacer segura la interoperabilidad de Lisk. Aprendimos que los certificados son una parte importante en las transacciones de actualización entre cadenas que certifican la corrección de los mensajes entre cadenas y las actualizaciones sobre el conjunto de validadores actual. Además, explicamos el proceso de generación de certificados, las reglas para validar las firmas de los certificados y la importancia de la cadena de propiedad de confianza que garantiza que los certificados siempre se puedan enviar secuencialmente a otra cadena de bloques. Finalmente, vimos que las condiciones necesarias y suficientes para que la comunicación entre cadenas sea segura son básicamente las mismas que ya se requieren para que los protocolos de consenso de las cadenas de bloques involucradas sean seguros.

 

Si desea profundizar más en las especificaciones técnicas, consulte las especificaciones del protocolo en LIP 0061 o haga preguntas técnicas sobre los certificados en el foro de investigación de Lisk .


En esta publicación de blog, veremos en detalle los certificados, el objeto clave para hacer que la interoperabilidad de Lisk sea segura.  E...