Escalando la privacidad de Blockchain Dynamic Sharding

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 ▸

Escalando la privacidad de Blockchain con Dynamic Sharding ▾

El bajo rendimiento es uno de los mayores obstáculos que enfrenta la adopción masiva de las criptomonedas. El rendimiento se mide por la cantidad de transacciones por segundo (TPS) confirmadas en una red criptográfica. Por ejemplo, Bitcoin solo puede procesar 7-10 TPS [Croman et al., 2016; Li et al., 2018], mientras que Visa puede procesar 24.000 TPS [Visa, 2018].

Las transacciones de privacidad son aún más lentas debido a la generación de pruebas adicionales y los pasos de verificación. Los tamaños de las transacciones son grandes debido a los datos de privacidad adicionales. Por ejemplo, Zcash, una bifurcación de Bitcoin con funciones de privacidad, solo puede procesar 6 TPS con un tamaño de bloque de 2 MB, un intervalo de bloque objetivo de 150 segundos y un tamaño de transacción promedio de 2000 bytes. Este es un gran inconveniente.

Implementamos sharding en transacciones de privacidad para aumentar el rendimiento de Incognito [Kokoris-Kogias et al., 2018; Zamani et al., 2018; Zilliqa, 2017]. El rendimiento de incógnito escala linealmente con la cantidad de fragmentos. Cuantos más fragmentos agreguemos, más transacciones podrá manejar.

Incognito está diseñado como una red de cadenas de bloques. Tiene una sola cadena de balizas (el “coordinador”) y N cadenas de fragmentos (los “trabajadores”), que producen bloques en paralelo. Todos los fragmentos funcionan en paralelo y están sincronizados por tiempo de bloque de baliza, que se divide en épocas iguales.

Figura 1. Sharding en transacciones de privacidad. El rendimiento de incógnito escala linealmente con la cantidad de fragmentos.

Cadenas de fragmentos

Los fragmentos están organizados por el último byte de las direcciones de los remitentes. Cada fragmento tiene su propio comité, asignado al azar por la cadena de balizas. Un comité de fragmentos valida y confirma las transacciones que le pertenecen.

Cada vez que se crea un bloque de fragmentos, el comité de balizas verificará e insertará el encabezado de bloque válido en la cadena de balizas. Si el bloqueo no es válido, la baliza enviará la prueba a todos los demás fragmentos, para que voten a favor de eliminar el comité de fragmentos que se comporta mal.

Figura 2. Cadenas de fragmentos

Cadena de baliza

La responsabilidad de Beacon chain es verificar los bloques de fragmentos y coordinar las cadenas de fragmentos. Es el estado global de toda la red.

  • Beacon chain verifica la validez de los bloques de fragmentos.
  • Beacon chain confirma la información de los fragmentos cruzados. Cada encabezado de bloque de fragmentos incluye información de fragmentos cruzados, que indica a qué fragmento se ha cruzado este bloque. Además de la altura de cada cadena de fragmentos, esta información también se incluye en el cuerpo del bloque.
  • Beacon Chain gestiona la lista de candidatos y validadores. Cada vez que un usuario apuesta PRV para convertirse en validador, esta acción se registrará en el encabezado del bloque.
  • La cadena Beacon baraja los comités. Cuando se genera un nuevo número aleatorio, se registra en el encabezado del bloque de baliza.
  • Beacon chain almacena la raíz de Merkle de la lista de candidatos y la lista de validadores, tanto de Beacon chain como de las cadenas de fragmentos.

Transacción de fragmento cruzado

Para las transacciones entre fragmentos, el fragmento del remitente crea un recibo que contiene todas las transacciones en el fragmento del receptor y luego envía este recibo al fragmento del receptor. También se envía un resumen de las transacciones de fragmentos cruzados a la Beacon chain. Los UTXO en el fragmento del remitente están bloqueados para asegurarse de que no se puedan gastar dos veces. El fragmento del receptor verifica la validez del recibo y espera la confirmación de la información del fragmento cruzado de la Beacon chain, antes de aprobar los UTXO correspondientes como gastables.

Figura 3. Transacción de fragmento cruzado.

Tamaño del comité dinámico

Al comienzo de una época:

  • La lista de suplentes es 100-400% del tamaño del comité actual

El tamaño del comité permanece sin cambios, el 10 % de los miembros del comité se reemplazan en cada época, en forma rotativa.

  • La lista de suplentes es > 400% del tamaño del comité actual

Aumentar el tamaño del comité en un 15 % del tamaño del comité actual (después de restar los miembros recortados en la época anterior).

  • La lista de suplentes es < 100% del tamaño del comité actual

Reducir el tamaño del comité en un 10%

Fragmentación dinámica

La cadena de incógnito se implementa inicialmente con 8 fragmentos. La cantidad de fragmentos podría aumentar dinámicamente, hasta 256 fragmentos. Sea X el último byte de las claves públicas del remitente. El fragmento con id = X % number_of_shards manejará esta transacción.

Cada fragmento tiene un máximo (M) de miembros del comité. Cuando la lista de sustitución de todos los fragmentos sea superior a 5 millones, la cadena duplicará el número de fragmentos. En este caso, cada fragmento se dividirá en dos 2 fragmentos nuevos, según el esquema de la Figura 4:

Figura 4. Aumento de fragmentos

Ejemplo:

En el caso de 8 fragmentos, las claves públicas con último byte = 0, 8, 16, 24, 32, 40… 240, 248 pertenecen al fragmento 0. Es decir, fragmento_id = último byte % número_de_fragmentos.

Si se duplica a 16 fragmentos, el fragmento 0 se dividirá en el fragmento 0 y el fragmento 8, que se denominan fragmentos hermanos. Las claves públicas con el último byte = 0, 16, 32,… 240 están en el fragmento 0 y las claves públicas con el último byte = 8, 24, 40,… 248 están en el fragmento 8.

El comité actual y los nodos sustitutos en el fragmento 0 se dividirán en partes iguales en los fragmentos 0 y 8. De esta manera, todos los miembros del comité ya tienen una base de datos completa para confirmar cualquier transacción nueva que les pertenezca.

Si el tamaño del comité es más pequeño que el umbral de tamaño mínimo del comité, dos fragmentos hermanos se fusionarán en un solo fragmento.

Análisis

Cuando un fragmento se ve comprometido, puede producir airdrop o transacciones gastadas dos veces. El comité de balizas detecta esto y da las pruebas a otros fragmentos. Si ⅔ de los fragmentos están de acuerdo con las pruebas, el comité comprometido será penalizado. Por lo tanto, un atacante necesita conquistar al menos ⅔ de fragmentos para conquistar la cadena.

Sea H el número de validadores honorables en un fragmento

B sea el número de validadores bizantinos en un fragmento

Sea n el tamaño del comité

Sea X el número de validadores bizantinos en un comité

Entonces la probabilidad de k validadores bizantinos en el comité de un fragmento, donde 0<= k <= B, es

y, la probabilidad de >=k validadores bizantinos en el comité de un fragmento es

Sea S el número de fragmentos. Como un atacante necesita conquistar al menos ⅔ de fragmentos para conquistar la cadena, la probabilidad es

Por ejemplo, observemos un escenario en el que hay 8 fragmentos, un tamaño de comité de 50 y 200 nodos en la lista sustituta. La Tabla 1 resume la probabilidad de conquistar la cadena, dado el porcentaje de nodos propiedad del atacante.

Porcentaje de validadores bizantinos 20% 25% 30% 35% 40%
Probabilidad de conquistar la cadena (8 fragmentos) 2.04E-107 2.4439E-76 9.6104E-56 9.583E-41 2.4814E-29
Probabilidad de conquistar la cadena (16 fragmentos ) 4.163E-214 5.973E-152 9.236E-11 9.1834E-81 6.1575E-58

Tabla 1. Probabilidad de que el atacante conquiste la cadena.

La probabilidad de conquistar la cadena es extremadamente baja, incluso si un individuo posee el 40% de los validadores.

Implementación

La implementación está principalmente en el componente Blockchain en la arquitectura Incognito.

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.

  • Fragmentos _ Los fragmentos son subcadenas. Una subcadena es una cadena de bloques de prueba de participación con su propio comité de N nodos. El trabajo de un fragmento es producir nuevos bloques a través del algoritmo de consenso Multiview Practical Byzantine Fault Tolerance (pBFT). Su código está en el paquete blockchain .
  • Beacon _ Beacon es también una subcadena. El trabajo de una baliza es coordinar los fragmentos y mantener el estado global de la red. Su código está en el paquete blockchain .
  • Sinker . Synker se asegura de que el nodo esté actualizado entre sus pares y también transmite el estado del nodo a sus pares. Su código está en el paquete blockchain .
  • Mempool . Mempool (grupo de memoria) es una colección de transacciones y bloques que se han verificado pero que aún no se han confirmado. Su código está en el paquete mempool .
  • Wallet _ Software que contiene todas sus claves de incógnito. Úselo para enviar y recibir sus tokens de incógnito. Su código está en el paquete de la billetera .
  • base de datos Incognito usa LevelDB para almacenar datos de bloques. Su código está en el paquete de la base de datos.