Evolución de Kadena, la primera blockchain privada real

George Samman es un consultor y asesor de blockchain y Criptomonedas que recientemente fue coautor de un informe fundamental sobre la arquitectura de blockchain con KPMG.

Aquí, Samman explica cómo el algoritmo de consenso logrado por Raft fue finalmente arreglado por su pariente lejano, Kadena.

Este artículo aborda la cadena de bloques de Kadena. Esta utiliza ScalableBFT para ofrecer un alto rendimiento (8000-12 000 transacciones por segundo) con replicación y distribución completas a escalas previamente imposibles (capacidad para más de 500 nodos participantes).

Esto, junto con el modelo de seguridad multicapa y el hash incremental, permite una blockchain verdaderamente robusta. Basado en Raft y Juno, Kadena integra un lenguaje completo de contratos inteligentes (Pact) en su blockchain, que puede ejecutarse como transacciones públicas (texto plano) o privadas (cifrado de doble trinquete).

Es un gran paso adelante en el espacio blockchain, posiblemente representando una nueva generación de Tecnología blockchain por su introducción de la idea del “determinismo generalizado”.

Al igual que Bitcoin, la cadena de bloques de Kadena está estrechamente integrada, y comprender sus capacidades y lo que implican requiere un amplio conocimiento. Por ello, he dividido el artículo en tres partes: 1) Introducción y Balsa, 2) Los predecesores de Kadena –Tangaroa&Juno, y 3) Blockchain de Kadena: ScalableBFT, Pact y determinismo generalizado.

Parte 1: Introducción y el algoritmo de consenso Raft

La historia detrás de Kadena es un caso de estudio interesante en el nuevo campo de los algoritmos de consenso de blockchain y la computación distribuida.

Kadena es un "pariente lejano" de la Algoritmo de consenso de RaftEl mecanismo de consenso de Raft fue seguido porTangaroa(una balsa tolerante a fallas bizantinas (BFT)) y el proyecto JP MorganJuno(una bifurcación de Tangaroa), ninguno de los cuales se encuentra ya en desarrollo activo.

El nuevo quórum blockchain de JP Morgan

es muy diferente de Juno y utiliza una fusión de ideas de cadenas laterales y Ethereum : se permiten contratos inteligentes públicos en la cadena de bloques además de contratos privados, que se representan como hashes cifrados y se replican a través de canales laterales.

Kadena es la "próxima generación de Juno". Utiliza un protocolo nuevo, pero relacionado, llamado ScalableBFT, que surgió del código abierto del proyecto Juno y fue desarrollado por los dos desarrolladores clave que crearon Kadena . Antes de profundizar en Kadena , es necesario analizar brevemente la historia y descripción de Raft y sus predecesores.

Consenso de balsa

El algoritmo de consenso Raft es un sistema basado en un único líder para gestionar un registro replicado. Utiliza una arquitectura de máquina de estados replicada y produce un resultado equivalente a Paxos, pero con una estructura diferente.

Mantener la consistencia del registro replicado es tarea del algoritmo de consenso. En este modelo, el líder realiza la mayor parte del trabajo, ya que emite todas las actualizaciones del registro, valida las transacciones y, en general, gestiona el clúster. El consenso de Raft garantiza un ordenamiento y replicación estrictos de los mensajes. No importa el contenido de los mensajes.

Se elige un nuevo líder mediante tiempos de espera aleatorios, que se activan si un seguidor no recibe ninguna comunicación del líder antes de que se active el tiempo de espera. Estos tiempos se denominan "latidos".

Si el seguidor no recibe ninguna comunicación durante este periodo, se convierte en candidato e inicia una elección. El candidato que recibe los votos de la mayoría del clúster (nodos de la red) se convierte en el nuevo líder. Los líderes suelen operar hasta que fallan. Se envían señales para asegurar que el líder sigue en el grupo; si no se recibe ninguna señal, se realiza una nueva elección.

Las siguientes etapas son cómo Raft llega al consenso:

• Se inicia un clúster de servidores de nodos Raft, y cada nodo se lanza como "Seguidor". Eventualmente, un nodo expirará, se convertirá en candidato, obtendrá la mayoría de los votos y se convertirá en líder.
• Cada nodo almacena un registro con comandos. La función del Líder es aceptar nuevos comandos, ordenarlos estrictamente en su registro, replicar su registro a sus seguidores y, finalmente, informarles cuándo deben confirmar los registros que han replicado. El algoritmo de consenso garantiza que los registros de cada servidor estén en el mismo orden.
• Los registros se confirman cuando se han replicado en la mayoría de los nodos. El líder recopila el recuento de replicaciones y, al detectar la mayoría, confirma sus propias entradas de registro e informa a sus seguidores que hagan lo mismo.
• Al confirmar, el comando en cada entrada del registro es evaluado por una máquina de estados. Dado que Raft es indiferente al cuerpo del comando, cualquier máquina de estados puede procesar entradas confirmadas. Además, el consenso garantiza que la ejecución de los comandos siempre se realice en el mismo orden en que provienen del registro, el cual está estrictamente ordenado.
• Las máquinas de estados permanecerán consistentes siempre que las ejecuciones de comandos sean deterministas.
• Cuando un cliente envía un comando a ONE de los servidores, este lo reenvía al líder o actúa como tal. El líder recopila el nuevo comando, le asigna un índice de registro, lo encapsula en una entrada de registro y lo añade a la parte no confirmada de su registro.
• Siempre que el líder tenga entradas sin confirmar, replica esta parte del registro a sus seguidores. Cuando la mayoría del clúster le informa que la replicación se ha realizado correctamente, confirma las nuevas entradas y ordena a sus seguidores que hagan lo mismo.
• Cada vez que se confirma una nueva entrada de registro, se alcanza un consenso sobre ella. La máquina de estados de cada servidor la evalúa.
• A partir de este punto, Raft está terminado y los implementadores pueden decidir cómo manejar las respuestas: respondiendo al cliente o esperando a que el cliente consulte el resultado.

Las respuestas al cliente generalmente son asincrónicas.

El protocolo de consenso Raft es precisamente eso: un algoritmo de consenso. No tiene noción de y, por defecto, está totalmente abierto a cualquier cliente que emita comandos. La única restricción de participación que impone se refiere a los nodos existentes en un momento dado.

Además, el líder tiene autoridad absoluta sobre el clúster y ordena a los seguidores replicar y comprometerse. No asume ataques bizantinos; solo necesita gestionar fallos, ya que se asume que los nodos son altruistas.

Parte 2: Los predecesores de Kadena: Tangaroa y Juno

Tangaroa: El primer paso hacia una balsa BFT

Tangaroa es una variante tolerante a fallas bizantinas (BFT) del algoritmo de consenso Raft inspirado en el algoritmo Raft original y el algoritmo práctico de tolerancia a fallas bizantinas (PBFT).

La tolerancia a fallos bizantinos se refiere a un tipo de fallos causados por nodos maliciosos que atacan la red. Si algunos nodos fallan, es fundamental que la red siga funcionando sin interrupciones.

En Raft estándar, es necesario replicar una entrada de registro en la mayoría de los nodos del clúster antes de confirmarla. Para los algoritmos de consenso BFT, incluido Tangaroa, el tamaño de clúster requerido es de al menos 2f + 1, donde f es el número de fallos que se desea tolerar (incluyendo tanto los nodos bloqueados como los comprometidos). El consenso se logra mediante el voto mayoritario del clúster; si f <= 3, el tamaño del clúster es de 7 y los nodos no bizantinos son de 4. Algunos protocolos BFT pueden incluso requerir 3f + 1.

Un líder bizantino puede decidir aumentar arbitrariamente el índice de confirmación de otros nodos antes de que las entradas de registro se hayan replicado lo suficiente, lo que provoca violaciones de seguridad cuando los nodos fallan posteriormente. Tangaroa delega la responsabilidad de la confirmación en el líder, y cada nodo puede verificar por sí mismo que una entrada de registro se ha replicado de forma segura a un quórum de nodos y que este quórum está de acuerdo en un orden.

Tangaroa permite a los clientes interrumpir el liderazgo actual si este no avanza, de la misma manera que otros algoritmos de consenso BFT permiten al cliente actuar como un oráculo confiable para destituir ciertos nodos. Esto permite a Tangaroa evitar que los líderes bizantinos saturen el sistema, pero confía mucho en el cliente.

Elección de líder y etapas

Tangaroa utiliza Raft como base para el consenso; por lo tanto, existe un único líder. En Tangaroa, al igual que en Raft, cada nodo se encuentra en ONE de los tres estados: líder, seguidor o candidato.

Al igual que en Raft, cada nodo comienza como seguidor, ONE de los cuales expirará y convocará elecciones. El ganador de la elección será el líder por el resto del mandato; los mandatos finalizan cuando se elige un nuevo líder. En ocasiones, una elección puede resultar en una votación dividida y el mandato termina sin líder. En este caso, un seguidor expirará de nuevo (los tiempos de espera se restablecen al emitirse un voto o convocar elecciones) y comenzará de nuevo el proceso de votación.

Para iniciar una elección, un seguidor incrementa su mandato actual y envía RequestVote (RV)Llamada a procedimiento remoto (RPC)En paralelo, cada uno de los demás nodos del clúster solicita su voto. Las RPC que utiliza Tangaroa son similares a las de Raft, con la excepción de que cada una se firma y valida mediante firmas PPK.

Las RPC permiten un intercambio de datos entre diferentes computadoras que residen en una red y las firmas permiten que los nodos receptores verifiquen qué nodo envió la RPC, además de permitir que cualquier nodo reenvíe la RPC de cualquier otro nodo en cualquier momento.

Cuando un nodo Tangaroa recibe una RPC de RV con una firma válida, otorga un voto inmediatamente solo si no tiene un líder (solo ocurre al inicio). De lo contrario, inicia el proceso que Tangaroa denomina "Voto Difícil".

El propósito de un voto diferido es proteger a los seguidores no bizantinos de elegir un nuevo líder cuando este no tiene errores. Sin el voto diferido, un nodo bizantino podría activar elecciones repetidas en cualquier momento y colapsar el sistema. Cuando un seguidor recibe un nuevo voto diferido, lo guarda y espera a que se cumplan todas las siguientes condiciones:

a) El tiempo de espera de la elección del seguidor activa los disparos antes de procesar un latido de su líder actual. Si se recibe un latido, el LazyVote se borra.

b) El nuevo plazo del RV es mayor que su plazo actual.

c) El remitente de la Request es un candidato elegible (firma PPK válida y el cliente no ha prohibido el nodo).

d) El nodo que recibe la RV no ha votado por otro líder para el período propuesto.

e) El candidato comparte un prefijo de registro con el nodo que contiene todas las entradas confirmadas. Un nodo siempre rechaza la Request si aún recibe mensajes de latido del líder actual e ignora la RPC de RequestVote si el mandato propuesto ya ha comenzado.

Si una RequestVote es válida y para un nuevo mandato, y el candidato tiene un registro suficientemente actualizado, pero el destinatario aún recibe señales del líder actual, registrará su voto localmente y luego enviará una respuesta de voto si el nodo mismo sufre un tiempo de espera de elección o escucha de un cliente que el líder actual no responde.

En el voto perezoso, un nodo no otorga un voto a un candidato a menos que considere que el líder actual es defectuoso. Esto evita que los nodos que inician elecciones innecesarias obtengan los votos necesarios para convertirse en líderes y agoten el sistema.

Los nodos esperan hasta que consideran necesaria una elección antes de emitir un voto. Una vez enviado el voto, el nodo actualiza su número de mandato. Sin embargo, no asume que el nodo por el que votó ganó la elección y, aun así, rechaza las RPC de AppendEntries (AE) del candidato si ninguna de ellas contiene un conjunto de votos que demuestre que ganó la elección. Las AE cumplen la doble función de latidos y portadores de nuevas entradas de registro que requieren replicación. El candidato continúa en estado de candidato hasta que ocurre una de estas tres cosas:

a) Gana la elección al recibir la mayoría de votos del grupo. El candidato debe guardar estos votos (RPC de RequestVoteResponse (RVR)) para su posterior distribución.

b) Otro nodo se establece como líder

c) Transcurre un período de tiempo sin un ganador (es decir: se produce otro tiempo de espera electoral)

Un candidato que gana las elecciones se autoproclama líder y envía un mensaje de latido de AE que contiene los votos que lo eligieron y el número de mandato actualizado para establecer su autoridad y evitar nuevas elecciones. Los votos firmados impiden eficazmente que un nodo bizantino se autopromocione arbitrariamente como líder de un mandato superior. Además, cada seguidor realiza un recuento de la mayoría de votos mencionada, validando y contando cada voto emitido por el nuevo líder para verificar de forma independiente la validez de la elección.

Gobernancia

Al igual que Raft, Tangaroa utiliza tiempos de espera aleatorios para activar las elecciones de líder. El líder de cada periodo envía periódicamente mensajes de latido (RPC de AE vacíos) para mantener su autoridad. Si un seguidor no recibe comunicación de un líder durante un periodo de tiempo elegido aleatoriamente (el tiempo de espera de la elección), se convierte en candidato e inicia una nueva elección.

Además de las elecciones espontáneas activadas por seguidores, Tangaroa también permite la intervención del cliente: cuando un cliente no observa progreso con un líder durante un periodo llamado tiempo de espera de progreso, envía RPC de UpdateLeader a todos los nodos, indicándoles que ignoren los latidos futuros del que el cliente considera el líder actual en el periodo actual. Estos seguidores ignorarán los mensajes de latido en el periodo actual y expirarán como si el líder actual hubiera fallado, iniciando una nueva elección.

Datos recibidos

Los datos (nuevos comandos) provienen de los clientes del clúster Raft, que envían solicitudes al líder. Este replica estas solicitudes al clúster y responde al cliente cuando se alcanza el quórum en el clúster para dicha Request.

Lo que constituye una "Request" depende del sistema. La forma en que se almacenan los datos también depende del sistema. Es importante que el estado persista en el disco para que los nodos puedan recuperar y recordar la información que han confirmado (por qué nodos votaron, qué entradas de registro han confirmado, ETC). Sin esto, el protocolo no funcionará.

Tangaroa añade BFT a la evolución de Raft

Juno

El proyecto Juno de JP Morgan es una bifurcación de Tangoroa y fue una prueba de concepto que pudo escalar Tangaroa para incluir hasta 50 nodos y aumentar la velocidad de las transacciones hasta 5000 transacciones por segundo.

El equipo de JPM detrás de Juno vio el potencial que representaba un enfoque similar a Tangaroa: una cadena de bloques privada de alto rendimiento. Iteraron sobre la idea durante un año y abrieron el código del proyecto en febrero de 2016. Agregaron un lenguaje de contrato inteligente, corrigieron algunos errores de diseño y lograron un aumento de rendimiento de 10 veces, lo que permitió que la cantidad de nodos votaran para cambiar mientras el sistema estaba en ejecución. Juno permitía agregar y eliminar nodos, y era un sistema distribuido con permisos en el que se conocían todos los nodos de la red.

Las etapas del mecanismo y el proceso de elección de líder son los mismos que en Tangaroa (véase más arriba). De igual forma, una transacción se considera activa una vez que se replica completamente y se registra.

El líder decide el orden de los comandos y cada nodo los valida. Cada nodo decide de forma independiente cuándo confirmar una entrada de registro basándose en la evidencia que recibe de otros nodos. Cada entrada de registro se confirma individualmente y se compara incrementalmente con la entrada anterior. Una sola entrada de registro tarda aproximadamente 5 ms en pasar del momento en que el líder la recibe al momento en que se alcanza el consenso total y se produce la latencia de la red.

Parte 3: La cadena de bloques de Kadena: ScalableBFT, Pact y determinismo generalizado

Criptografía

A diferencia de Raft, cada réplica de un sistema BFT Raft (una familia de algoritmos que incluye Tangaroa, Juno y ScalableBFT de Kadean) calcula un hash criptográfico cada vez que añade una nueva entrada a su registro. El hash se calcula sobre el hash anterior y la nueva entrada del registro.

Un nodo puede firmar su último hash para demostrar que ha replicado la totalidad de un registro, y otros servidores pueden verificarlo rápidamente mediante la firma y el hash. Los nodos y clientes de BFT Raft siempre firman antes de enviar mensajes y rechazan los mensajes que no incluyen una firma válida.

Las balsas BFT utilizan hashes incrementales, lo que permite a los nodos garantizar que el contenido y el orden de los registros de otros nodos coincidan con los suyos. Gracias a este conocimiento, los nodos pueden confirmar de forma independiente las entradas de registro de forma segura, ya que tanto el contenido como el orden de los registros de otros nodos se verifican mediante hashes incrementales coincidentes.

BFT Rafts utiliza ampliamente firmas digitales para autenticar mensajes y verificar su integridad. Esto impide que un líder bizantino modifique el contenido de los mensajes o los falsifique, y protege al clúster, en general, de numerosos ataques bizantinos.

Consenso

En Raft, un Líder se elige mediante tiempos de espera aleatorios que hacen que un Seguidor se proponga como Candidato y Request votos. ScalableBFT también hace esto, pero con seguridad criptográfica. Por ejemplo, si un Líder se vuelve inaccesible, un tiempo de espera desencadenaría una nueva elección, pero el proceso electoral es robusto contra nodos bizantinos que declaran elecciones. ScalableBFT soluciona los problemas que Juno y Tangaroa encontraron con la votación diferida.

Las únicas capacidades exclusivas del Líder son: 1) ordenar nuevas transacciones antes de la replicación y 2) replicar nuevas transacciones a los nodos Seguidores. A partir de ese momento, todos los nodos comprueban de forma independiente la validez del consenso y la integridad de cada transacción.

La eliminación de la participación anónima es un requisito de diseño para las cadenas de bloques privadas, lo que permitió un mecanismo de consenso BFT de alto rendimiento para reemplazar la minería. La principal incorporación de ScalableBFT a la familia de plataformas BFT es su capacidad de escalar a miles de nodos sin reducir el rendimiento del sistema.

Cada transacción se replica en cada nodo. Cuando la mayoría de los nodos la han replicado, esta se confirma. Los nodos recopilan y distribuyen información (hash incremental) sobre lo que han replicado y la utilizan para decidir de forma independiente cuándo confirmarla (más del 50 % de los demás nodos les envían hashes incrementales para las transacciones no confirmadas con las que están de acuerdo).

Básicamente, funciona mediante una votación mayoritaria sobre qué confirmar. Confirmar una transacción no significa que se ejecutará, sino que ha sido replicada permanentemente por la mayoría del clúster. Las transacciones incorrectas, aquellas con errores o firmas incorrectas, también se replican, y la función del consenso es proporcionar una replicación perfectamente ordenada.

Al confirmar una transacción, cada nodo puede evaluar de forma independiente (analizar, descifrar, validar el Cripto, ejecutar, ETC) cada transacción de forma idéntica. Cada transacción se asocia con un resultado, que puede variar desde un Cripto incorrecto hasta el resultado de la capa de contrato inteligente (que también puede ser un error).

Finalmente, además de que el líder replica nuevas transacciones a cada nodo, los nodos son más o menos independientes. En lugar de "sincronizarse", transmiten "He replicado hasta el índice de registro N y tiene un hash incremental de H" al clúster y recopilan esta información de otros nodos. Con base en los resultados de otros nodos, cada nodo puede decidir independientemente si el clúster ha replicado más allá del límite necesario para confirmar (una replicación mayoritaria para un índice de registro N aún no confirmado).

Aquí está la sutileza: el hash incremental implica la replicación de todas las transacciones anteriores. Si el líder replica 8000 transacciones nuevas (que es lo que hace actualmente), cada nodo solo necesita distribuir y recopilar evidencia de la última transacción de ese lote, ya que esto implica la replicación correcta de las anteriores. En lugar de enviar 8000 mensajes (ONE por cada transacción) que certifiquen una replicación correcta, los nodos solo analizan la última transacción.

Es por esto que Kadena necesitaba tanta canalización, porque el equipo descubrió cómo confirmar 8.000 transacciones a la misma velocidad que confirmaría una sola transacción.

ScalableBFT representa un gran avance en el campo del consenso BFT, ya que es el primer y único mecanismo de consenso BFT determinista que puede escalar más allá de cientos de nodos con replicación y cifrado completos. ScalableBFT también proporciona un modelo de seguridad único, conocido como determinismo ubicuo, que proporciona seguridad no solo a nivel de transacción, sino también a nivel de consenso, al tiempo que cifra cada transacción mediante el Protocolo de Ruido (véase más adelante).

Kadena utiliza el consenso determinista

El mecanismo de consenso es determinista si el proceso de consenso está completamente especificado en el protocolo y no emplea aleatoriedad. Como se mencionó anteriormente, Raft, por ejemplo, utiliza tiempos de espera aleatorios para activar elecciones cuando un líder falla (dado que el líder no puede comunicar "Estoy a punto de colapsar", se activa un tiempo de espera para que un nodo verifique si el líder está inactivo). Sin embargo, la elección no forma parte del consenso a nivel de transacción, sino que es un medio para encontrar un nodo que organice el consenso.

ScalableBFT es determinista y reforzado de tal manera que:

• Los nodos se comprometerán solo cuando la mayoría del clúster esté de acuerdo con ellos.
• La evidencia del acuerdo debe ser completamente auditable en cualquier momento.
• Cuando no haya pruebas de acuerdo, no hacer nada.

Kadena está diseñado específicamente para redes con permisos y, por lo tanto, asume que ciertos ataques (como un DoS) son improbables y están fuera de su control. Si ocurriera ONE , el sistema se bloquearía (todos los nodos agotarían el tiempo de espera, pero la elección nunca se realizaría) o permanecería inactivo.

Una vez finalizado dicho evento, los nodos volverán al consenso y todo volverá a la normalidad. Sin embargo, en una red con permisos, los administradores tendrían control total y eliminarían la conexión que causa el problema.

La elección de líder es muy similar a Raft en el sentido de que cualquier nodo puede ser elegido líder, cada nodo obtiene un voto por período y las elecciones se convocan cuando se agota el tiempo de espera aleatorio de ONE de los nodos (el temporizador se reinicia cada vez que un nodo recibe noticias del líder).

La mayor diferencia es que en Raft un nodo que obtiene suficientes votos asume el liderazgo, mientras que en ScalableBFT un nodo que obtiene una mayoría de votos distribuye esos votos a todos los demás nodos para demostrar (al estilo BFT) que ha sido elegido líder por el clúster.

El mecanismo de ScalableBFT corrige problemas observados en Juno y Tangaroa, como un "candidato fugitivo" donde un nodo no bizantino ha expirado debido a una partición de red pero, debido a que su término se ha incrementado, no puede volver al consenso y en su lugar continúa expirando y luego incrementa su término ("Fugitivo").

El consenso de Raft garantiza un ordenamiento y replicación estrictos de los mensajes; no importa el contenido de cada mensaje y puede abarcar desde números aleatorios hasta texto cifrado o contratos inteligentes de texto plano. Kadena aprovecha la capa de registro como servicio de mensajería cuando se ejecuta en un contexto cifrado; de forma similar a cómo Signal puede ejecutar el cifrado del protocolo Noise sobre SMS. ScalableBFT ejecuta Noise sobre una cadena de bloques.

ScalableBFT añade robustez de consenso, que la capa encargada de la interpretación de los mensajes asume como garantía, pero también hashes incrementales que aseguran la replicación perfecta de los mensajes. El protocolo de ruido se intercala entre el consenso y la ejecución del contrato inteligente, cifrando/descifrando los mensajes según sea necesario. Dado que los mensajes son texto cifrado, solo se requieren algunos de los trucos habituales para evitar una explosión cartesiana de pruebas en vivo, que se ejecutan por mensaje sin filtrar información.

Modelo de seguridad/determinismo generalizado

Kadena utiliza el término “determinismo generalizado” para describir “la idea de una cadena de bloques que utiliza criptografía basada en PPK-Sig para garantías de autoría (como Bitcoin) y está compuesta por una capa de consenso totalmente determinista además de una capa de contrato inteligente de asignación única e incompleta de Turing.

Las implicaciones de una cadena de bloques “pervasivamente determinista” son bastante profundas, ya que permite que una clase de auditabilidad similar a la del libro mayor de Bitcoin se extienda profundamente a la capa de consenso al encadenar múltiples capas de confianza criptográfica.

Tomemos como ejemplo una transacción que carga un nuevo módulo de contrato inteligente llamado "préstamos". Digamos que "préstamos" importa otro módulo llamado "pagos" que ya está presente en la cadena. La importación exitosa de "pagos" por sí sola implica lo siguiente (cada uno completamente auditable mediante criptografía):

• ¿Quién firmó la transacción que cargó “pagos”?
• ¿Qué nodos de consenso había en el clúster en el momento de la carga?
• ¿Qué nodos de consenso acordaron que la transacción era válida?
• ¿Qué nodos votaron por el líder actual en el momento de la carga?
• ¿Quién era el líder?
• ¿Quién era el líder anterior?
• ETC.

Un sistema determinista generalizado permite que las nuevas transacciones aprovechen no solo la confianza criptográfica que surge naturalmente al encadenarse en una cadena de bloques, sino también la confianza en cómo dichas transacciones ingresaron a la plataforma. De esta manera, se puede crear un sistema más seguro que Bitcoin, ya que el proceso de consenso se vuelve criptográficamente confiable, auditable y complejo, ya que las ejecuciones a nivel de transacción implican la ocurrencia de Eventos específicos a nivel de consenso, y cada implicación es criptográficamente verificable.

Esto proporciona BFT no solo para la capa de consenso, sino también para la capa de transacciones (Bitcoin ya lo hace). Esto difiere, por ejemplo, de PBFT, que asume que las transacciones enviadas desde el servidor del cliente son válidas, lo que las deja vulnerables a ser comprometidas. Además, las BFT que no son de Raft generalmente confían al cliente la capacidad de destituir o bloquear nodos. El Determinismo Pervasivo adopta una perspectiva alternativa: no confiar en nada, auditarlo todo.

Permitir que ScalableBFT incorpore determinismo generalizado crea un sistema completamente paranoico, robusto en todas sus capas gracias a la seguridad permanente (es decir, una forma de seguridad criptográfica que puede almacenarse en disco). Incorpora el modelo de seguridad de Bitcoin para las transacciones, lo extiende al nivel de consenso e incorpora contratos inteligentes sin necesidad de minería ni las desventajas a las que la mayoría de los usuarios de la industria se han acostumbrado. Es una verdadera cadena de bloques, rápida y escalable.

Le pregunté a Will Martino (cofundador de Kadena) los detalles de cómo funcionaba esto para cada capa:

¿Cuál es su modelo de seguridad a nivel de consenso?

Para la replicación, Kadena utiliza un registro de transacciones con hash incremental, replicado de forma idéntica por cada nodo. Estos concuerdan en el contenido del registro mediante mensajes firmados distribuidos que contienen el hash incremental de un índice de registro determinado. Estos mensajes son recopilados por otros nodos y utilizados para determinar individualmente cuándo se justifica una confirmación. No se permiten duplicados en el registro y los mensajes de replicación del líder que contengan duplicados se rechazan de inmediato.

Utilizamos hashes de Blake2 y el número de Term para definir la unicidad, lo que permite a los clientes del sistema no preocuparse por el envío accidental de duplicados ni por el reenvío de comandos por parte de un nodo/intermediario malicioso (MITM). Empleamos seguridad permanente, un enfoque basado en PPK-sig para la verificación de autoría (o cualquier otro enfoque que pueda almacenarse en disco), muy similar a cómo Bitcoin verifica las transacciones, pero a nivel de consenso (además del nivel de transacción).

Esto se opone a la seguridad efímera que utiliza canales seguros (TLS) para la validación de la autoría, un enfoque enormemente inferior en el que la pregunta "¿quién envió la transacción X?" se responde no mediante criptografía PPK sino mediante una consulta de nivel de consenso porque cualquier nodo individual es incapaz de proporcionar una respuesta BFT.

¿Cuál es su modelo de seguridad a nivel de transacción?

Los conceptos de seguridad efímera y permanente abarcan tanto el consenso como las transacciones, ya que es el consenso el que gestiona las transacciones individuales en la capa de ejecución de contratos inteligentes. A nivel de contrato/transacción inteligente, también utilizamos seguridad permanente, que admite la autorización de clave pública a nivel de fila de forma nativa en Pact.

Esto es importante porque lo efímero implica que un atacante está a un servidor de distancia de suplantar una entidad; los canales seguros funcionan mediante la distribución punto a punto de nuevas transacciones por parte del cliente/emisor a los nodos del clúster mediante TLS, y el consenso garantiza que una transacción determinada se confirme y replique. Sin embargo, si un atacante piratea el servidor cliente que mantiene el otro extremo de la conexión TLS, puede realizar transacciones como si fuera el cliente sin que el clúster se dé cuenta.

Por otro lado, la seguridad permanente tiene muchas claves para roles individuales en una entidad dada, lo que requiere que un atacante obtenga acceso a las claves individuales; además, con la seguridad permanente, las transacciones del CEO se firman con una clave diferente a las transacciones del empleado de correo, a diferencia de la seguridad efímera, donde "quién envía esta transacción" está determinado por un campo "de: X".

Si se utiliza la misma conexión TLS para enviar las transacciones del director ejecutivo y del secretario, la lógica de autoría y autorización se basa en un modelo de "porque yo lo digo/confía en mí", en lugar de un enfoque de firma PPK, donde se verifica con la clave apropiada antes de la ejecución. La cadena de bloques de Kadena está diseñada para confiar lo menos posible; si conociéramos un enfoque más paranoico o detallado que las firmas PPK a nivel de fila, lo usaríamos.

¿Cuál es su modelo de transacciones confidenciales?

Utilizamos el protocolo Double-Ratchet (el mismo que Signal, WhatsApp, ETC utilizan para comunicaciones cifradas) integrado en la blockchain (cuerpos de transacción cifrados) para casos de uso que preservan la Privacidad multipartita. Trabajamos con el concepto de bases de datos disjuntas mediante la primitiva «pact» de Pact, que describe un flujo de trabajo de confirmación multifase sobre bases de datos disjuntas mediante mensajes cifrados.

Contratos inteligentes

Pact es un lenguaje completo de contratos inteligentes, cuyo intérprete está desarrollado en Haskell. En Kadena, cada transacción es un contrato inteligente y el lenguaje de contratos inteligentes Pact es de código abierto. Pact se centra en bases de datos, es transaccional, incompleto en el modelo de Turing y de asignación única (las variables no se pueden modificar durante su ciclo de vida) y, por lo tanto, es muy susceptible a la verificación estática.

Pact también se interpreta (el código que escribes es lo que se ejecuta en la cadena), mientras que Solidity se compila, lo que dificulta la verificación del código y, una vez compilado, imposibilita la corrección de problemas de seguridad en versiones antiguas del lenguaje. Pact incluye su propio intérprete, pero puede ejecutarse en cualquier blockchain con entrada determinista y es compatible con diferentes backends, incluyendo RDBMS comerciales. En la blockchain ScalableBFT, se ejecuta con una capa de almacenamiento SQLite de alta velocidad.

La cadena de bloques Kadena contiene todas estas características:

En conclusión, Kadena ha desarrollado un algoritmo de consenso determinista, escalable y totalmente replicable para cadenas de bloques privadas de alto rendimiento. Esta solución de cadena de bloques puede representar un gran avance para las empresas de servicios financieros que buscan implementar una solución privada real que se mantenga fiel a muchas de las características clave de la cadena de bloques de Bitcoin sin minería (prueba de trabajo), anonimato y resistencia a la censura, a la vez que satisface las características de diseño clave que los servicios financieros anhelan, en particular la escalabilidad y la confidencialidad.

Este artículo fue publicado previamente enBlog de Sammanticsy se ha reproducido aquí con permiso. Se han realizado algunas ediciones por motivos de estilo y brevedad.

Imagen de engranajesvía Shutterstock