Evolução do Kadena, o Primeiro Blockchain Privado Real

George Samman é um consultor e assessor de blockchain e Criptomoeda que recentemente foi coautor de um relatório seminal sobre arquitetura de blockchain com a KPMG.

Aqui, Samman explica como o algoritmo de consenso alcançado pelo Raft foi finalmente corrigido por seu parente distante, Kadena.

Este artigo aborda o blockchain da Kadena. Ele usa o ScalableBFT para oferecer alto desempenho (8.000-12.000 transações por segundo) com replicação e distribuição completas em escalas antes impossíveis (capacidade para mais de 500 nós participantes).

Isso, junto com o modelo de segurança multicamadas e hash incremental, permite um blockchain verdadeiramente robusto. Baseado em Raft e Juno, o Kadena incorpora uma linguagem de contrato inteligente completa (Pact) em seu blockchain que pode ser executado como transações públicas (texto simples) ou privadas (criptografia double-ratchet).

É um grande passo à frente no espaço blockchain, possivelmente representando uma nova geração de Tecnologia blockchain inteiramente pela introdução da ideia de “determinismo generalizado”.

Semelhante ao Bitcoin, o blockchain da Kadena é fortemente integrado, e entender do que ele é capaz, e o que essas capacidades implicam, requer cobrir uma quantidade considerável de terreno. Como tal, dividi o artigo em três partes: 1) Introdução e Jangada, 2) Predecessores de Kadena –Tangaroa&Juno, e 3) Blockchain da Kadena – ScalableBFT, Pact e Determinismo Pervasivo.

Parte 1: Introdução e o Algoritmo de Consenso Raft

A história por trás do Kadena é um estudo de caso interessante no novo campo de algoritmos de consenso de blockchain e computação distribuída.

Kadena é um 'parente distante' do Algoritmo de consenso Raft. O mecanismo de consenso Raft foi seguido porTangaroa(uma jangada tolerante a falhas bizantinas (BFT)) e o projeto JP MorganJuno(um fork do Tangaroa), nenhum dos quais está mais em desenvolvimento ativo.

Novo blockchain Quorum do JP Morgan

é muito diferente do Juno e usa uma fusão de ideias de sidechains e Ethereum – contratos inteligentes públicos são permitidos no blockchain, além de contratos privados, que são representados como hashes criptografados e replicados por meio de canais laterais.

Kadena é o “Juno da próxima geração”. Ele usa um protocolo novo, mas relacionado, chamado ScalableBFT que foi gerado a partir do código-fonte aberto do projeto Juno e foi construído pelos dois principais desenvolvedores que construíram o Juno. Antes de mergulhar fundo no Kadena, uma breve história e descrição do Raft e dos predecessores do Kadena precisam ser discutidas.

Consenso de jangada

O algoritmo de consenso Raft é um sistema baseado em um único líder para gerenciar um log replicado. Ele usa uma arquitetura de máquina de estado replicada e produz um resultado equivalente ao Paxos, mas é estruturalmente diferente.

Manter o log replicado consistente é o trabalho do algoritmo de consenso. Neste modelo, o líder faz a maior parte do trabalho porque ele está emitindo todas as atualizações de log, validando transações e, geralmente, gerenciando o cluster. O consenso Raft garante uma ordenação e replicação rigorosas de mensagens. Ele não se importa com o que as mensagens contêm.

Um novo líder é eleito usando timeouts aleatórios, que são disparados se um seguidor não receber nenhuma comunicação do líder antes do timeout disparar. Eles são chamados de "heartbeats".

Se o seguidor não receber nenhuma comunicação durante esse período de tempo, ele se torna um candidato e inicia uma eleição. Um candidato que recebe votos da maioria do cluster completo (nós na rede) se torna o novo líder. Os líderes geralmente operam até falharem. Os heartbeats são enviados para garantir que o líder ainda esteja lá; se nada for recebido, uma nova eleição ocorre.

As etapas a seguir mostram como o Raft chega a um consenso:

• Um cluster de servidores de nó Raft é iniciado com cada nó sendo lançado como um "Seguidor". Eventualmente, um nó atingirá o tempo limite, se tornará um candidato, ganhará a maioria dos votos e se tornará o líder.
• Cada nó armazena um log contendo comandos. É trabalho do Líder aceitar novos comandos, ordenar estritamente os comandos em seu log, replicar seu log para seus seguidores e, finalmente, informar aos seguidores quando confirmar os logs que eles replicaram. O algoritmo de consenso, portanto, garante que os logs de cada servidor estejam na mesma ordem.
• Os logs são “commitados” quando foram replicados para a maioria dos nós. O líder reúne a contagem de replicação e, quando a maioria é vista, confirma suas próprias novas entradas de log e informa seus seguidores para fazerem o mesmo.
• Após “commit”, o comando em cada entrada de log é avaliado por uma máquina de estado. Como o Raft é indiferente ao corpo do comando, qualquer máquina de estado pode processar entradas confirmadas. Além disso, o consenso garante que a execução do comando sempre ocorra na mesma ordem em que os comandos vêm do Log, que é estritamente ordenado.
• As máquinas de estado permanecerão consistentes enquanto as execuções de comandos forem determinísticas.
• Quando um cliente envia um comando para um dos servidores, esse servidor encaminhará o comando para o líder ou é o líder. O líder coleta o novo comando, atribui a ele um Log Index, encapsula-o em uma Log Entry e adiciona o comando à parte não confirmada de seu log.
• Sempre que o líder tiver entradas não confirmadas, ele replica essa parte do log para seus seguidores. Quando o líder é informado de uma replicação bem-sucedida pela maioria do cluster, ele confirma as novas entradas e ordena que seus seguidores façam o mesmo.
• Sempre que uma nova entrada de log é confirmada, o consenso sobre essa entrada é alcançado. Ele é então avaliado pela máquina de estado em cada servidor.
• A partir deste ponto, o Raft estará concluído e os implementadores podem decidir como lidar com as respostas: respondendo ao cliente ou esperando que o cliente consulte o resultado.

As respostas ao cliente geralmente são assíncronas.

O protocolo de consenso Raft é exatamente isso – um algoritmo de consenso. Ele não tem uma noção de e é, por padrão, totalmente aberto a qualquer cliente que emita comandos. A única restrição de participação que ele faz é sobre quais nós existem em um dado momento.

Além disso, o líder tem autoridade absoluta sobre o cluster e ordena que os seguidores repliquem e confirmem. Ele não assume ataques bizantinos, ele precisa lidar apenas com falhas de travamento, porque os nós são considerados altruístas.

Parte 2: Predecessores de Kadena – Tangaroa e Juno

Tangaroa: O primeiro passo para uma Jangada BFT

Tangaroa é uma variante tolerante a falhas bizantinas (BFT) do algoritmo de consenso Raft, inspirado no algoritmo Raft original e no algoritmo Practical Byzantine Fault Tolerance (PBFT).

Tolerância a falhas bizantinas se refere a uma classe de falhas causadas por nós maliciosos atacando a rede. Se alguns dos nós caírem, é imperativo que a rede continue funcionando sem parar.

No Raft padrão, você precisa replicar uma entrada de log para a maioria dos nós no cluster antes de confirmá-la. Para algoritmos de consenso BFT, incluindo Tangaroa, o tamanho de cluster necessário é de pelo menos 2f + 1, onde f é o número de falhas que você deseja tolerar (incluindo nós travados e comprometidos). O consenso é alcançado por uma votação majoritária do cluster; se f <= 3, então o tamanho do cluster = 7 e nós não bizantinos = 4. Alguns protocolos BFT podem até exigir 3f+1.

Um Líder Bizantino pode decidir aumentar arbitrariamente o índice de confirmação de outros nós antes que as entradas de log tenham sido suficientemente replicadas, causando, assim, violações de segurança quando os nós falham mais tarde. O Tangaroa transfere a responsabilidade de confirmação do líder, e cada nó pode verificar por si mesmo que uma entrada de log foi replicada com segurança para um quorum de nós e que esse quorum concorda com uma ordenação.

Tangaroa permite que clientes interrompam a liderança atual se ela não conseguir progredir, da mesma forma que outros algoritmos de Consenso BFT permitem que o cliente se comporte como um oráculo confiável para depor certos nós. Isso permite que Tangaroa impeça que líderes bizantinos deixem o sistema faminto, mas confia muito no cliente.

Eleição do líder e etapas

Tangaroa usa Raft como base para consenso; portanto, há um único líder. Em Tangaroa, assim como em Raft, cada nó está em um dos três estados: líder, seguidor ou candidato.

Semelhante ao Raft, cada nó começa como um seguidor, um dos quais eventualmente expirará e convocará uma eleição. O vencedor da eleição serve como líder pelo resto do mandato; os mandatos terminam quando um novo líder é eleito. Às vezes, uma eleição resultará em uma votação dividida, e o mandato terminará sem um líder. Nesse caso, um seguidor expirará novamente (os tempos limite são redefinidos quando um voto é dado ou uma eleição é convocada) e iniciará o processo de votação novamente.

Para iniciar uma eleição, um seguidor incrementa seu mandato atual e envia RequestVote (RV)Chamada de Procedimento Remoto (RPCs)em paralelo a cada um dos outros nós no cluster pedindo seu voto. Os RPCs que a Tangaroa usa são similares aos RPCs da Raft, com a exceção de que cada RPC é assinado e validado via assinaturas PPK.

Os RPCs permitem a troca de dados entre diferentes computadores que residem em uma rede e as assinaturas permitem que os nós receptores verifiquem qual nó enviou o RPC, além de permitir que qualquer nó encaminhe o RPC de qualquer outro nó a qualquer momento.

Quando um nó Tangaroa recebe um RV RPC com uma assinatura válida, ele concede um voto imediatamente somente se não tiver um líder no momento (ocorre somente na inicialização). Caso contrário, ele inicia o processo que Tangaroa chama de “LazyVote”.

O propósito de um LazyVote é proteger Seguidores não-Bizantinos de eleger um novo líder quando o líder não é falho; sem a votação preguiçosa, um nó bizantino poderia desencadear eleições repetidas a qualquer momento e deixar o sistema faminto. Quando um novo RV é recebido por um seguidor, ele salva o RV e espera que todas as seguintes condições sejam atendidas:

a) O tempo limite de eleição do seguidor dispara incêndios antes de ele manipular um heartbeat de seu líder atual. Se um heartbeat for recebido, o LazyVote é limpo.

b) O novo prazo do RV é maior que seu prazo atual.

c) O remetente da Request é um candidato elegível (assinatura PPK válida e o cliente T baniu o nó).

d) O nó que recebe o RV não votou em outro líder para o mandato proposto.

e) O candidato compartilha um prefixo de log com o nó que contém todas as entradas confirmadas. Um nó sempre rejeita a Request se ainda estiver recebendo mensagens de heartbeat do líder atual e ignora o RequestVote RPC se o termo proposto já tiver começado.

Se um RequestVote for válido e para um novo mandato, e o candidato tiver um log suficientemente atualizado, mas o destinatário ainda estiver recebendo heartbeats do líder atual, ele registrará seu voto localmente e enviará uma resposta de voto se o próprio nó passar por um tempo limite de eleição ou ouvir de um cliente que o líder atual não está respondendo.

Sob a votação preguiçosa, um nó não concede um voto a um candidato, a menos que acredite que o líder atual esteja com defeito. Isso impede que nós que iniciam eleições desnecessárias ganhem os votos necessários para se tornarem líderes e deixar o sistema faminto.

Os nós esperam até que acreditem que uma eleição precisa ocorrer antes de votar. Uma vez que um voto é enviado, o nó atualizará seu número de termo. No entanto, ele não assume que o nó em que votou venceu a eleição e ainda rejeitará RPCs AppendEntries (AE) do candidato se nenhum deles contiver um conjunto de votos provando que o candidato venceu a eleição. Os AEs servem ao duplo propósito de heartbeats e portadores de novas entradas de log que precisam de replicação. O candidato continua no estado candidato até que uma das três coisas aconteça:

a) Ele vence a eleição ao receber a maioria dos votos do cluster. Um candidato deve salvar esses votos – RequestVoteResponse (RVR) RPCs – para distribuição futura.

b) Outro nó se estabelece como líder

c) Passa um período de tempo sem vencedor (ou seja: passa por outro tempo limite eleitoral)

Um candidato que vence a eleição então se promove ao estado líder e envia uma mensagem de heartbeat AE que contém os votos que o elegeram e o número de mandato atualizado para estabelecer sua autoridade e impedir novas eleições. Os votos assinados efetivamente impedem que um nó bizantino se promova arbitrariamente como líder de um mandato superior. Além disso, cada seguidor realiza uma recontagem no voto majoritário acima mencionado, validando e contando cada voto que o novo líder transmitiu para verificar de forma independente a validade da eleição.

Governança

Assim como Raft, Tangaroa usa timeouts aleatórios para acionar eleições de líderes. O líder de cada termo envia periodicamente mensagens heartbeat (RPCs AE vazios) para manter sua autoridade. Se um seguidor não receber nenhuma comunicação de um líder durante um período de tempo escolhido aleatoriamente, o timeout da eleição, então ele se torna um candidato e inicia uma nova eleição.

Além das eleições espontâneas acionadas por seguidores, o Tangaroa também permite a intervenção do cliente: quando um cliente não observa nenhum progresso com um líder por um período de tempo chamado de tempo limite de progresso, ele transmite UpdateLeader RPCs para todos os nós, dizendo a eles para ignorarem futuras pulsações do que o cliente acredita ser o líder atual no termo atual. Esses seguidores ignorarão mensagens de pulsação no termo atual e expirarão como se o líder atual tivesse falhado, iniciando uma nova eleição.

Dados recebidos

Os dados (novos comandos) vêm de clientes do cluster Raft, que enviam solicitações ao líder. O líder replica essas solicitações para o cluster e responde ao cliente quando um quorum é atingido no cluster nessa Request.

O que constitui uma "Request" depende do sistema. Como os dados são armazenados depende do sistema. É importante que o estado persista no disco, para que os nós possam recuperar e lembrar as informações que eles confirmaram (em quais nós eles votaram, quais entradas de log eles confirmaram, ETC). Sem isso, o protocolo não funcionará.

Tangaroa adiciona BFT à evolução do Raft

Juno

O projeto Juno do JP Morgan é uma bifurcação do Tangoroa e foi uma prova de conceito que conseguiu escalar o Tangaroa para incluir até 50 nós e aumentar a velocidade de transação para até 5.000 transações por segundo.

A equipe do JPM por trás do Juno viu o potencial que uma abordagem semelhante à Tangaroa representava – um blockchain privado de alto desempenho. Eles iteraram a ideia por um ano e tornaram o projeto de código aberto em fevereiro de 2016. Eles adicionaram uma linguagem de contrato inteligente, corrigiram alguns erros de design e conseguiram atingir um aumento de desempenho de 10x, o que permitiu que o número de nós votasse para mudar enquanto o sistema estava em execução. O Juno permitia a adição e remoção de nós, e era um sistema distribuído com permissão no qual todos os nós na rede eram conhecidos.

Os estágios do mecanismo e do processo de eleição do líder são os mesmos do Tangaroa (veja acima). Da mesma forma, uma transação é considerada ativa quando é totalmente replicada e confirmada no log.

O líder decide a ordem dos comandos e cada nó valida. Cada nó decide independentemente quando confirmar uma entrada de log com base nas evidências que recebe de outros nós. Cada entrada de log é confirmada individualmente e incrementalmente hash em relação à entrada anterior. Leva aproximadamente 5 ms para uma única entrada de log ir do líder recebendo a entrada até o consenso total sendo alcançado e a latência da rede.

Parte 3: Blockchain da Kadena – ScalableBFT, Pact e Determinismo Pervasivo

Criptografia

Diferentemente do Raft, cada réplica em um sistema BFT Raft (uma família de algoritmos que inclui Tangaroa, Juno e ScalableBFT da Kadean) computa um hash criptográfico toda vez que acrescenta uma nova entrada ao seu log. O hash é computado sobre o hash anterior e a entrada de log recém-anexada.

Um nó pode assinar seu último hash para provar que replicou a totalidade de um log, e outros servidores podem verificar isso rapidamente usando a assinatura e o hash. Os nós e clientes do BFT Raft sempre assinam antes de enviar mensagens e rejeitam mensagens que não incluem uma assinatura válida.

Os BFT Rafts usam Hashing Incremental, permitindo que os nós tenham certeza de que tanto o conteúdo quanto a ordem dos logs de outros nós correspondem aos seus. Usando esse conhecimento, os nós podem confirmar entradas de log de forma independente e segura, porque tanto o conteúdo quanto a ordem dos logs de outros nós são atestados por meio de hashes incrementais correspondentes.

O BFT Rafts usa assinaturas digitais extensivamente para autenticar mensagens e verificar sua integridade. Isso impede que um líder bizantino modifique o conteúdo da mensagem ou forje mensagens e protege o cluster geralmente de um grande número de ataques bizantinos.

Consenso

No Raft, um Líder é eleito por meio de timeouts aleatórios que acionam um Seguidor a se propor como Candidato e Request votos. O ScalableBFT também faz isso, mas de forma criptograficamente segura. Por exemplo, se um Líder se tornar inacessível, um timeout acionaria uma nova eleição, mas o processo de eleição é robusto contra nós bizantinos que declaram eleições. O ScalableBFT corrige os problemas que Juno e Tangaroa encontraram em relação à votação preguiçosa.

As únicas capacidades únicas do Leader são: 1) ordenação de novas transações antes da replicação e 2) replicação de novas transações para os nós Follower. Desse ponto em diante, todos os nós provam independentemente tanto a validade do consenso quanto a integridade da transação individual.

A remoção da participação anônima é um requisito de design para blockchains privadas, e isso permitiu que um mecanismo de Consenso BFT de alto desempenho substituísse a mineração. A principal adição do ScalableBFT à família de BFT Rafts é a capacidade de escalar para 1000 nós sem diminuir o rendimento do sistema.

Cada transação é replicada para cada nó. Quando a maioria dos nós tiver replicado a transação, a transação é confirmada. Os nós coletam e distribuem informações (hash incremental) sobre o que eles replicaram e usam essas informações para decidir independentemente quando confirmar (>50% dos outros nós enviam a eles hashes incrementais para transações não confirmadas com as quais eles concordam).

Basicamente, funciona fazendo uma votação majoritária sobre o que deve ser confirmado. Confirmar uma transação T significa que ela será executada, apenas que foi permanentemente replicada pela maioria do cluster. Transações ruins, aquelas que apresentam erro ou têm assinaturas ruins, são replicadas, assim como o trabalho do consenso é fornecer replicação ordenada perfeita.

Comprometer uma transação permite que cada nó avalie independentemente (analise/descriptografe/valide Cripto/execute/ ETC...) cada transação de forma idêntica. Cada transação é pareada com uma saída, que pode variar de “ Cripto ruim” até a saída da camada de contrato inteligente (que também pode ser um erro).

Finalmente, além do líder replicar novas transações para cada nó, os nós são mais ou menos independentes. Em vez de “sincronizar”, eles transmitem “Eu repliquei até o índice de log N e ele tem um hash incremental de H” para o cluster e coletam essas informações de outros nós – com base nos resultados de outros nós, cada nó pode decidir independentemente se o cluster replicou além da barra necessária para confirmar (uma replicação majoritária para algum índice de log N ainda não confirmado).

Aqui está a parte sutil: o hash incremental implica a replicação de tudo o que veio antes dele. Se o líder replicar 8.000 novas transações (que é o que ele faz atualmente), cada nó precisa apenas distribuir e reunir evidências para a última transação daquele lote, pois isso implica a replicação correta das que vieram antes dele. Em vez de enviar 8.000 mensagens (uma para cada transação) que atestam a replicação adequada, os nós discutem apenas a transação mais recente.

É por isso que Kadena precisava de tanto pipeline, porque a equipe descobriu como confirmar 8.000 transações na mesma velocidade de confirmação de uma única transação.

ScalableBFT representa um avanço no campo do consenso BFT, pois é o primeiro e único mecanismo de consenso BFT determinístico que pode escalar centenas de nós com replicação e criptografia completas. ScalableBFT também fornece um modelo de segurança exclusivo conhecido como determinismo pervasivo, que fornece segurança não apenas no nível da transação, mas também no nível do consenso, ao criptografar cada transação usando o Noise Protocol (veja abaixo).

Kadena usa consenso determinístico

O mecanismo de consenso é determinístico se o processo de consenso for totalmente especificado no protocolo e esse processo não empregar aleatoriedade. Como foi dito acima, o Raft, por exemplo, usa timeouts aleatórios para disparar eleições quando um líder cai (já que o líder T pode comunicar "Estou prestes a cair", há um timeout que dispara para solicitar que um nó verifique se o líder caiu), mas a eleição T faz parte do consenso no nível da transação, é, em vez disso, um meio de encontrar um nó para orquestrar o consenso.

ScalableBFT é determinístico e reforçado de tal forma que:

• Os nós serão confirmados somente quando a maioria do cluster concordar com eles
• A evidência do acordo deve ser totalmente auditável a qualquer momento
• Quando não houver evidências de acordo, não faça nada.

O Kadena é projetado especificamente para redes permissionadas e, como tal, assume que certos ataques (como um DoS) são improváveis ​​e estão fora de seu controle. Se um ONE ocorresse, o sistema travaria (todos os nós eventualmente expirariam, mas uma eleição nunca teria sucesso) ou ficaria ocioso.

Uma vez que tal evento termine, os nós voltarão ao consenso e as coisas retornarão ao normal. No entanto, em uma rede com permissão, os administradores teriam controle total e matariam a conexão que estava causando o problema.

A eleição de líder é muito semelhante ao Raft, pois qualquer nó pode ser eleito líder, cada nó recebe um voto por mandato e as eleições são convocadas quando o tempo limite aleatório de um dos nós dispara (o cronômetro é reiniciado toda vez que um nó ouve o líder).

A maior diferença é que no Raft um nó que obtém votos suficientes assume a liderança, enquanto no ScalableBFT um nó que obtém a maioria dos votos distribui esses votos para todos os outros nós para demonstrar (de forma BFT) que foi eleito líder pelo cluster.

O mecanismo do ScalableBFT corrige problemas vistos no Juno e no Tangaroa, como um “candidato descontrolado”, onde um nó não bizantino atingiu o tempo limite devido a uma partição de rede, mas, como seu termo foi incrementado, ele T consegue retornar ao consenso e, em vez disso, continua o tempo limite e então incrementa seu termo (“descontrolado”).

O consenso do Raft garante uma ordenação e replicação rigorosas de mensagens; T importa o que há em cada mensagem e pode variar de números aleatórios a texto cifrado e contratos inteligentes de texto simples. O Kadena aproveita a camada de log como um serviço de mensagens ao ser executado em um contexto criptografado; assim como o Signal pode executar a criptografia do protocolo Noise por SMS. O ScalableBFT executa o Noise em um blockchain.

ScalableBFT adiciona robustez de consenso, que a camada que lida com a interpretação das mensagens assume como uma garantia, mas também hashes incrementais que asseguram a replicação perfeita das mensagens. Slots de protocolo de ruído entre o consenso e a execução do contrato inteligente, criptografando/descriptografando mensagens conforme necessário; como as mensagens são texto cifrado, apenas alguns dos truques normais para evitar uma explosão cartesiana de testes ao vivo são necessários para executar por mensagem sem vazar informações.

Modelo de segurança/determinismo generalizado

Kadena usa o termo “determinismo generalizado” para descrever “a ideia de um blockchain que usa criptografia baseada em PPK-Sig para garantias de autoria (como Bitcoin) e é composto de uma camada de consenso totalmente determinística, além de uma camada de contrato inteligente de atribuição única e incompleta de Turing.

As implicações de uma blockchain ‘pervasivamente determinística’ são bastante profundas, pois permite que uma classe de auditoria de livro-razão bitcoin seja estendida profundamente na camada de consenso ao encadear múltiplas camadas de confiança criptográfica.

Tome como exemplo uma transação que carrega um novo módulo de contrato inteligente chamado “empréstimos”. Digamos que “empréstimos” importa outro módulo chamado “pagamentos” que já está presente na cadeia. A importação bem-sucedida de “pagamentos” por si só implica o seguinte (com cada um sendo totalmente auditável por meios criptográficos):

• Quem assinou a transação que carregou “pagamentos”
• Quais nós de consenso estavam no cluster no momento do carregamento
• Quais nós de consenso concordaram que a transação era válida
• Quais nós votaram no líder atual no momento do carregamento
• Quem era o líder
• Quem foi o líder anterior
• ETC

Um sistema determinístico generalizado permite que novas transações alavanquem não apenas a confiança criptográfica que ocorre naturalmente quando as transações são encadeadas em um blockchain, mas também a confiança de como essas transações entraram na borda em primeiro lugar. Ao fazer isso, você pode criar um sistema mais seguro do que o Bitcoin porque o processo de consenso se torna tão criptograficamente confiável, auditável e emaranhado também, com execuções de nível de transação implicando que Eventos específicos de nível de consenso ocorreram e com cada implicação sendo criptograficamente verificável.

Isso fornece BFT não apenas para a camada de consenso, mas também para a camada de transação (o Bitcoin já faz isso). Isso é diferente de, digamos, PBFT, que assume que as transações enviadas do servidor do cliente são válidas, o que as deixa com a capacidade de serem comprometidas. Além disso, BFTs não Raft geralmente confiam ao cliente a capacidade de depor/banir nós. O Determinismo Pervasivo adota um ponto de vista alternativo: não confie em nada, audite tudo.

Permitir que o ScalableBFT incorpore o determinismo generalizado cria um sistema completamente paranoico que é robusto em cada camada por meio de segurança permanente (ou seja: uma forma de segurança criptográfica que pode ser salva em disco). Ele tem o modelo de segurança do bitcoin para transações, estende esse modelo ao nível de consenso e adiciona contratos inteligentes sem a necessidade de mineração ou as compensações às quais a maioria na indústria se acostumou. É um blockchain real que é rápido e escalável.

Perguntei a Will Martino (cofundador da Kadena) sobre os detalhes de como isso funcionava para cada camada:

Qual é o seu modelo de segurança em nível de consenso?

Para replicação, o Kadena usa um log de transações com hash incremental que é replicado de forma idêntica por cada nó. Eles concordam com o conteúdo do log por meio de mensagens assinadas distribuídas contendo o hash incremental de um determinado índice de log, que são então coletados por outros nós e usados ​​para raciocinar individualmente sobre quando um commit é garantido. Nenhuma duplicata é permitida no log e as mensagens de replicação do líder contendo quaisquer duplicatas são rejeitadas imediatamente.

Usamos hashes blake2 e número de Termo para definir a exclusividade, permitindo que os clientes do sistema não se preocupem em enviar duplicatas por acidente ou sobre um nó malicioso/man-in-the-middle (MITM) reenviando comandos. Empregamos segurança permanente, uma abordagem baseada em PPK-sig para verificação de autoria (ou qualquer tipo de abordagem que possa ser salva em disco) que é muito semelhante a como o Bitcoin verifica transações, mas no nível de consenso (além do nível de transação).

Isso se opõe à segurança efêmera que usa canais seguros (TLS) para validação de autoria – uma abordagem muito inferior onde a pergunta “quem enviou a transação X?” é respondida não por criptografia PPK, mas por uma consulta em nível de consenso porque qualquer nó individual é incapaz de fornecer uma resposta BFT.

Qual é o seu modelo de segurança em nível de transação?

As ideias de segurança efêmera e permanente abrangem tanto o nível de consenso quanto o de transação, pois é o consenso que entrega à camada de execução do contrato inteligente as transações individuais. No nível de contrato/transação inteligente, também usamos segurança permanente, suportando autorização de chave pública em nível de linha nativamente no Pact.

Isso é importante porque efêmero implica que um invasor está a um servidor de distância de personificar uma entidade; canais seguros funcionam por distribuição ponto a ponto de novas transações pelo cliente/submissor para os nós do cluster por TLS e o consenso assegura que uma determinada transação deve ser confirmada e replicada. No entanto, se um invasor hackear o servidor cliente que mantém a outra extremidade da conexão TLS, ele pode transacionar como se fosse o cliente sem que o cluster fique sabendo.

A segurança permanente, por outro lado, tem muitas chaves para funções individuais em uma determinada entidade, exigindo assim que um invasor obtenha acesso às chaves individuais; além disso, com a segurança permanente, as transações do CEO são assinadas com uma chave diferente das transações do Mail Clerk versus efêmera, onde "quem está enviando esta transação" é determinado por um campo "de: X".

Se a mesma conexão TLS for usada para enviar as transações do CEO e do Clerk, então a lógica de autoria e autorização é um modelo "porque eu disse/confie em mim" versus uma abordagem PPK-sig onde você verifica a chave apropriada antes da execução. O blockchain da Kadena é projetado para confiar o mínimo possível; se soubéssemos de uma abordagem mais paranoica ou refinada do que assinaturas PPK em nível de linha, usaríamos isso.

Qual é o seu modelo de transação confidencial?

Usamos o protocolo Double-Ratchet (o que Signal, WhatsApp, ETC... usam para comunicações criptografadas) incorporado ao blockchain (corpos de transação criptografados) para casos de uso de preservação de Política de Privacidade multipartidária. Trabalhamos com a noção de bancos de dados disjuntos por meio do primitivo 'pact' no Pact – eles descrevem um fluxo de trabalho de confirmação multifásica sobre bancos de dados disjuntos por meio de mensagens criptografadas.

Contratos inteligentes

Pact é uma linguagem de contrato inteligente completa, cujo interpretador é construído em Haskell. No Kadena, cada transação é um contrato inteligente e a linguagem de contrato inteligente Pact é de código aberto. Pact é focada em banco de dados, transacional, Turing-incompleta, atribuição única (variáveis ​​não podem ser alteradas durante sua vida útil) e, portanto, altamente passível de verificação estática.

O Pact também é interpretado – o código que você escreve é o que é executado na cadeia – enquanto o Solidity é compilado, dificultando a verificação do código e também impossibilitando a retificação de problemas de segurança em versões antigas da linguagem, uma vez compilado. O Pact é enviado com seu próprio interpretador, mas pode ser executado em qualquer blockchain de entrada determinística e pode suportar diferentes backends, incluindo RDBMS comerciais. No blockchain ScalableBFT, ele é executado com uma camada de armazenamento SQLite rápida.

O blockchain Kadena contém todos esses recursos:

Concluindo, a Kadena desenvolveu um algoritmo de consenso totalmente replicável, escalável e determinístico para blockchains privadas com alto desempenho. Esta solução de blockchain pode ser um salto gigante para empresas de serviços financeiros que buscam empregar uma solução privada real que permaneça fiel a muitos dos principais recursos do blockchain do Bitcoin sem mineração (prova de trabalho), anonimato e resistência à censura, ao mesmo tempo em que atende aos principais recursos de design que os serviços financeiros desejam, particularmente escalabilidade e confidencialidade.

Este artigo foi publicado anteriormente noBlog Sammanticse foi reproduzido aqui com permissão. Algumas edições foram feitas para estilo e brevidade.

Imagem de engrenagensvia Shutterstock