Consenso: una combinación de iPoS, Multiview-pBFT y BLS

[NoaLatam]

Introducción: una plataforma de monedas de privacidad descentralizadas ▸

Proteger las criptomonedas: convertir cualquier criptomoneda en una moneda de privacidad ▸

Custodios sin confianza: un enfoque descentralizado para la custodia de criptomonedas ▸

Envío de criptomonedas de forma confidencial: firma de anillo, compromiso homomórfico y pruebas de rango de conocimiento cero ▸

Privacidad a escala con Dynamic Sharding ▸

Consenso: una combinación de iPoS, Multiview-pBFT y BLS ▾

Tanto la cadena de beacon como las cadenas de fragmentos utilizan el mismo mecanismo de consenso para producir nuevos bloques.

Prueba de participación de incognito (iPoS)

Incognito implementa la prueba de participación más eficiente energéticamente [King y Nadal, 2012] en lugar de la prueba de trabajo [Dwork y Naor, 1992; Juels, 1999].

En la primera generación de POS, cada nodo de replanteo (validador) tiene un voto. Cuantos más validadores, más segura es la cadena. Sin embargo, PoS no es un consenso escalable; los gastos generales de comunicación aumentan linealmente con el tamaño del comité. La investigación demuestra que el POS solo puede lograr un nivel razonable de seguridad cuando hay 600 validadores o más en el comité [Luu et al. 2016]. Un comité con 600 nodos enfrenta desafíos reales al sincronizar estados e intercambiar mensajes para crear un nuevo bloque.

Para superar los problemas de comunicación relacionados con el escalado, Bitshares ( https://bitshares.org/ ) propuso por primera vez la prueba de participación de delegados (DPOS ). Esto podría considerarse como la segunda generación de POS. En DPOS, solo un pequeño grupo de validadores se seleccionan en el comité, donde tienen derecho a proponer y verificar nuevos bloques. Esto resuelve el problema de comunicación del enfoque POS, pero sacrifica las propiedades de descentralización y falta de confianza, específicamente:

• Los nodos de replanteo tienen que confiar en los nodos delegados.
• Cuanto menor sea el tamaño del comité, más fácil se puede comprometer.
• Solo funcionan los nodos delegados (es decir, proponer y verificar bloques), el nodo de replanteo no hace nada.

Incognito propone iPOS que permite tanto la escala como la falta de confianza. Cualquiera puede ser un candidato a validador apostando PRV. La cadena de beacon asigna validadores aleatoriamente a cada fragmento. En un momento, solo un pequeño grupo de validadores en un fragmento se selecciona en el comité. El comité de cada fragmento es responsable de proponer y verificar bloques. El comité rota, por lo que cada validador debe realizar la misma cantidad de trabajo. En cuanto a la descentralización, cada bloque de fragmentos firmado por el comité de fragmentos será verificado por el comité de beacon. Si se detecta alguna transacción incorrecta, como airdrop o doble gasto, beacon informará a todos los demás fragmentos utilizando la prueba. Todos los fragmentos honestos votarán para eliminar el comité del fragmento bizantino.

Tolerancia práctica a fallas bizantinas multivista (M_PBFT)

Incognito propone e implementa una variante de pBFT [Castro et al., 1999] en la capa de consenso. Mejoramos aún más su eficiencia mediante el empleo del esquema de firma múltiple agregado basado en BLS AMSP [Boneh et al., 2018].

Tendermint, una implementación popular de pBFT, requiere que los participantes tengan la misma vista para cada bloque acuñado. Los nodos deben sincronizar su estado en cada bloque, lo que provoca una sobrecarga de comunicación. Incognito propone pBFT multivista, por lo que un nodo toma decisiones en función de su mejor vista y no requiere el estado de sincronización de otros nodos en el comité. Encuentre más detalles sobre pBFT multivista aquí .

Ciclo de vida del validador

• Grupo común: nuevo nodo de replanteo, esperando ser asignado a un fragmento en particular
• Grupo de sincronización: sincroniza los datos del fragmento asignado
• Grupo de sustitutos: el nodo terminó de sincronizar sus datos, haciendo cola en la lista de sustitutos de su fragmento
• Grupo de comités: validar y votar bloques
  • 4 estados: nuevo (en grupo común), candidato (en grupo sincronizado), sustituto (en grupo suplente), comité (en comité).

Figura 1. Ciclo de vida

Reglas de corte

Cuando se trata de recortes, preferimos un enfoque punitivo ligero, es decir, una política de recortes que no deduce ningún PRV de la apuesta/recompensa de los validadores. Sin embargo, la política debe prevenir eficazmente el mal comportamiento y la falta de fiabilidad.

Por cada fragmento,

1. Si es MissingSig <= ExpectedShardBlock / 2 así, el nodo se verá obligado a retirar la participación.
2. Si es MissingSig > ExpectedShardBlock / 2 así el nodo no recibirá ningún tipo de penalización.

El ExpectedShardBlock se calcula de la siguiente manera:

• Sea M la media del número de bloques creados por los fragmentos en una época.
• Para cada fragmento,
  si el número de bloques confirmados es menor que M , entonces M es el ExpectedShardBlock del fragmento.
  – De lo contrario, ExpectedShardBlock es el número de bloques confirmados por la cadena Beacon.

Si se corta un nodo, el PRV apostado de 1750 se devolverá al operador del nodo y puede volver a apostar en un momento posterior. Las recompensas de los nodos cortados se distribuirán uniformemente entre los validadores restantes en un comité.

Firmas múltiples agregadas basadas en BLS del emparejamiento

A medida que crece la cantidad de validadores, el tamaño total de todas las firmas de los validadores también crece y afecta el tamaño del bloque. Para resolver este problema, implementamos el esquema de firma múltiple agregado basado en BLS AMSP [Boneh et al., 2018].

Cuando el proponente del bloque propone un nuevo bloque, todos los validadores del comité actual verifican el bloque y emiten sus firmas. Todas estas firmas luego se agregan en una sola firma agregada. Independientemente del número de validadores, el tamaño de la firma agregada es de solo 32 bytes.

Implementación

La implementación se encuentra principalmente en el componente Consenso en la arquitectura de Incógnito.

Figura 5. La arquitectura de Incognito en capas.

El código es de código abierto en Github con enlaces a paquetes específicos que se proporcionan a continuación.

• Multivista-pBFT . Para el algoritmo de consenso, Incognito implementa Multiview-pBFT (tolerancia práctica a fallas bizantinas). Su código está en el paquete blsbft .
• BLS . Para la agregación de múltiples firmas, Incognito implementa BLS Multi-Signatures. Su código está en el paquete blsmultisig .
• RNG . Para el generador de números aleatorios, Incognito actualmente usa hash de bloque de Bitcoin. Exploraremos otras soluciones RNG en el futuro. Su código está en el paquete btc .

Hemos propuesto un nuevo enfoque para escalar la privacidad en las redes criptográficas mediante la aplicación de fragmentos en las transacciones de privacidad para aumentar el rendimiento de Incognito. El rendimiento de incógnito escala linealmente con la cantidad de fragmentos. Cuantos más fragmentos agreguemos, más transacciones podrá manejar.