Consenso de prueba de autoridad para cadenas laterales en LISK

abril 08, 2022 VICTOR HUGO LAZARTE 0 Comments

 


La versión 6 del SDK de Lisk admitirá un nuevo mecanismo de consenso además de la prueba de participación delegada (DPoS), a saber, la prueba de autoridad (PoA) . Los detalles técnicos detallados que explican PoA se pueden encontrar en el LIP 0047 . Sin embargo, en esta publicación de blog, la razón es proporcionar una descripción general de alto nivel y explicar en términos menos técnicos qué significa realmente PoA, cómo funciona, qué propiedades contiene y, finalmente, dónde se puede implementar dentro de un proyecto de cadena de bloques.

Protocolo de consenso en Lisk

Antes de explicar qué es el mecanismo de consenso del PoA, recordemos qué significa el protocolo de consenso en Lisk. El protocolo de consenso en Lisk se divide en las siguientes dos partes.

La primera parte se encarga de la selección de generadores de bloques. En Lisk Mainchain, esto se realiza mediante DPoS. Los usuarios que tienen tokens LSK pueden votar por delegados, y los delegados que reciben la mayor cantidad de votos en términos de LSK pueden generar bloques.

La segunda parte del protocolo de consenso describe cómo los generadores de bloques eligen la cadena a la que agregan nuevos bloques, en el caso de una bifurcación, y también cuándo un bloque se considera final, es decir, se considera irrevocablemente parte de la cadena de bloques. Esta parte del protocolo de consenso es realizada por Lisk-BFT .

¿Qué es la prueba de autoridad?

PoA es una alternativa a DPoS para la primera parte del protocolo de consenso, es decir, para el mecanismo de selección del generador de bloques. Al construir una cadena de bloques con Lisk SDK versión 6, se puede elegir entre PoA y DPoS. La segunda parte del protocolo de consenso, Lisk-BFT, es la misma para todas las cadenas, independientemente de su elección de PoA o DPoS. Eso significa, por ejemplo, que las reglas de finalidad no están influenciadas por la elección entre PoA y DPoS.

¿Cómo funciona PoA?

Al igual que en DPoS, las ranuras de bloques se agrupan en rondas y, al comienzo de cada ronda, se seleccionan los generadores de bloques. Sin embargo, en lugar de elegir los generadores de bloques por un cierto peso de voto, las cadenas de bloques PoA mantienen un conjunto de autoridades elegibles para generar bloques, a saber, las llamadas autoridades activas , y a cada autoridad activa se le asignará una ranura de bloque en la que pueden generar un cuadra. El número de autoridades activas también determina la duración de una ronda. Por ejemplo, si hay 10 autoridades activas, una ronda consta de 10 bloques.

La mayoría de las veces, este conjunto de autoridades activas no cambia. Además, las cuentas regulares en una cadena de bloques PoA no pueden influir en este conjunto. Por eso también se les llama “autoridades” en lugar de “delegados”. Los generadores de bloques tienen la autoridad para generar bloques, sin importar cuánta participación tengan en la cadena de bloques correspondiente, y sin importar cuánto otros titulares de cuentas deseen delegar parte de su participación en ellos.

Sin embargo, el conjunto de autoridades activas se puede cambiar. Se pueden agregar nuevas autoridades y se pueden eliminar las autoridades activas existentes. En particular, se puede cambiar el número de delegados activos y, por lo tanto, la duración de la ronda. Además, se pueden actualizar las ponderaciones BFT de las autoridades activas, así como el umbral de finalidad. Sin embargo, todas estas actualizaciones deben ser aprobadas por un subconjunto de las autoridades activas mediante firmas, por lo que la suma de los pesos de estas autoridades debe ser mayor o igual que el umbral de finalidad.

Consideremos el ejemplo donde el conjunto actual de autoridades activas consta de 10 autoridades donde cada una tiene el peso BFT de 1 y el umbral de finalidad es 7. Si se supone que una autoridad debe eliminarse del conjunto de autoridades activas, entonces esta actualización debe ser aprobado por al menos 7 autoridades activas.

El módulo PoA , que debe ser utilizado por las cadenas de bloques PoA construidas con Lisk SDK versión 6, implementa los siguientes comandos que facilitan las actualizaciones de autoridad:

  • Comando de registro de autoridad : este comando es similar al comando de registro de delegado en DPoS. Una cuenta que desee convertirse en una autoridad activa primero debe enviar una transacción de registro de autoridad.
  • Actualizar comando de autoridad : este comando actualiza el conjunto de autoridades activas como se mencionó anteriormente. Una transacción de autoridad de actualización debe contener una firma múltiple agregada a la que hayan contribuido suficientes autoridades activas, de modo que la suma de los pesos BFT correspondientes alcance el umbral de finalidad.

Seguridad de PoA

Al estar en el mundo de la cadena de bloques, donde la mayoría de los proyectos luchan por la descentralización y la falta de confianza, puede cuestionar la utilidad y la seguridad de PoA. De hecho, las cadenas de bloques PoA no logran tanta descentralización como las cadenas de bloques que usan, por ejemplo, Prueba de Participación (Delegada) o Prueba de Trabajo. En un caso extremo, puede haber solo una o dos autoridades validando todas las transacciones y contribuyendo al protocolo de consenso. Tener muy pocas autoridades podría aumentar el riesgo de censura, es decir, no incluir intencionalmente ciertas transacciones en la cadena de bloques. Además, además de aumentar el riesgo de que un subconjunto de autoridades activas con suficiente peso BFT pueda coludirse y comportarse de manera maliciosa, por ejemplo, revirtiendo bloques finalizados que permiten, por ejemplo, el doble gasto. Este último riesgo puede aparecer concerniente,

Todo esto puede sonar bastante perturbador, sin embargo, hay razones por las que las cadenas de bloques PoA son seguras, si se cumplen ciertos requisitos. Este es el caso cuando se conocen las identidades de las autoridades y cuando su reputación y la reputación del proyecto podrían verse dañadas (tenga en cuenta que se espera que la mayoría de las autoridades estén conectadas con el proyecto y tengan interés en su éxito). En otras palabras, las autoridades tienen en juego su reputación. Considere el ejemplo en el que algunas empresas realizan transacciones entre sí manteniendo una cadena de bloques PoA. Cada empresa ejecuta una cuenta de autoridad activa y se sabe qué cuenta de autoridad pertenece a qué empresa. Si alguna empresa se comportara maliciosamente, la reputación de esta empresa se vería gravemente dañada y esto daría lugar a que la mayoría de las empresas dejaran de hacer negocios con esta empresa en particular.

Por lo tanto, PoA puede ser seguro si se cumplen ciertos requisitos y, en algunos casos, puede ser incluso más seguro que DPoS, como veremos en la siguiente sección.

¿Cuándo es útil PoA?

Ejecutar una cadena de PoA tiene varias ventajas y, principalmente, uno de sus beneficios clave es su simplicidad. Por ejemplo, no se requiere token de consenso. En particular, es posible ejecutar una cadena lateral PoA que utilice únicamente el token LSK para todos sus propósitos. Por el contrario, cada cadena DPoS necesita crear un token de consenso personalizado que se use para las recompensas en bloque. Además, no se requiere la votación de ningún usuario y no es necesario procesar transacciones de votación, lo que también aumenta el rendimiento de los nodos. Si la simplicidad y la eficiencia son cruciales para un proyecto de cadena de bloques, PoA puede ser la mejor opción.

Como se mencionó anteriormente, PoA también puede ser más seguro en ciertos casos. Por ejemplo, para blockchains donde el capital invertido esperado es bastante pequeño si se elige DPoS (en Lisk DPoS, el capital invertido es la cantidad de tokens bloqueados debido a la votación). Por ejemplo, si el capital apostado de una cadena DPoS es equivalente a 1 millón de dólares y el umbral de finalidad es igual al 67 % de la cantidad de delegados activos, una entidad malintencionada que apueste el equivalente a 334 000 dólares podría impedir que se finalicen todos los bloques. . Además, una entidad malintencionada que apueste el equivalente a más de 667 000 USD podría realizar ataques de doble gasto. Para tales casos, PoA puede ser la opción más segura, ya que las reputaciones en juego pueden ser más valiosas que los tokens en juego en una cadena DPoS.

Otro caso es en el que se espera que solo unas pocas entidades realicen transacciones entre sí, como en el ejemplo mencionado anteriormente, donde algunas empresas mantienen una cadena de PoA y cada empresa tiene una cuenta de autoridad activa. En este caso, es mucho más sencillo configurar y mantener una cadena PoA mientras se tiene suficiente seguridad, o incluso más seguridad para ciertos modelos de ataque porque ninguna empresa podría obtener más control sobre la cadena de bloques que cualquier otra empresa o entidad.

PoA también se puede implementar para cadenas laterales utilizadas para escalar. Por ejemplo, se podría crear una cadena lateral de PoA que se use exclusivamente para transferencias de saldo LSK de montos bajos. En este caso, un alto rendimiento de transferencias de saldo LSK dentro del ecosistema Lisk se negocia contra la descentralización. Restringir las transferencias a montos bajos justifica el reducido nivel de descentralización.

Otro ejemplo es la prueba: si un proyecto desea realizar pruebas exhaustivas de su módulo personalizado en una red de prueba, entonces usar una cadena de bloques PoA que implemente estos módulos en una red de prueba simplifica este proceso, ya que la configuración y el mantenimiento de una cadena PoA son mucho más simples.

Resumen

PoA es un mecanismo de consenso alternativo a DPoS en Lisk SDK. Es menos descentralizado pero ofrece un mecanismo generador de bloques simple, eficiente y confiable. La seguridad de PoA se basa en la reputación en juego de los generadores de bloques en lugar de los tokens en juego de los generadores de bloques y sus votantes. Es especialmente adecuado para cadenas de bloques en las que el capital invertido esperado en el caso de DPoS no proporcionaría suficiente seguridad, pero la reputación de las autoridades activas sí lo haría.

Si desea profundizar en los detalles técnicos, lea la especificación del módulo PoA en LIP 0047 o haga preguntas técnicas sobre PoA en el foro de investigación de Lisk .

Fuente: Blog de Lisk


   


  La versión 6 del SDK de Lisk admitirá un nuevo mecanismo de consenso además de la  prueba de participación  delegada (DPoS), a saber, la  ...