A DFINITY, especializada em tecnologias subjacentes, pode imaginar que a Web3 pode realmente ser realizada?

Recomendado: O mercado está em alta e baixa e encontra a situação na Ucrânia, clique aqui para se juntar ao grupo PANews para aquecer

Título original: Interpretação do novo white paper da DFINITY, a cadeia pública de estoques potenciais Qual é a tecnologia subjacente na era da conexão da Web 3.0?

Autor: TinTinLand

1

Chumbo

No início de fevereiro de 2022, o Dmail, o primeiro DApp de e-mail privado desenvolvido com base no ecossistema DFINITY, recebeu investimento estratégico da Amino Capital. É relatado que Dmail pode enviar e-mails de e para caixas de correio tradicionais, e em comparação com caixas de correio tradicionais, Dmail com atributos blockchain também pode realizar transmissão criptografada de informações e NFT de nomes de caixas de correio. Esta é uma preparação para o software de comunicação na era Web 3.0, que serve como a entrada para sites descentralizados e DApps na forma de “identidade digital”. A pergunta que quero fazer é: por que Dmail escolheu Dfinity?

Em comparação com as cadeias públicas do blockchain, a Dfinity não surgiu muitas vezes. Não houve fogo DeFi quando houve uma pequena faísca, e não houve ganho de um lugar no primeiro ano de “NFT”. No entanto, desde o seu lançamento, não é incomum que pessoas como Dmail tenham um vislumbre de como será a implementação específica da Web 3.0.

DFINITY lançou a versão de código aberto do software social de vídeo curto “CanCan” em julho de 2020, que podemos simplesmente comparar com Douyin da Web 2.0. CanCan é baseado na linguagem de programação do DFINITY, Motoko, e tem menos de 1.000 linhas de código. Isso pode ser chamado de incrível em comparação com as dezenas de milhões de linhas de código no Douyin e no Facebook. Ao mesmo tempo, o código do CanCan é de código aberto, e a propriedade do produto não pertence a nenhuma autoridade centralizada. Em 1º de outubro do mesmo ano, o DFINITY revelou seu sistema de governança e modelo econômico simbólico, e a avaliação do projeto chegou a US$ 9,5 bilhões, ficando entre os cinco primeiros. No final de dezembro do mesmo ano, foi concluída a evolução histórica das cinco redes de cobre a mercúrio. Dominic Williams, fundador e cientista-chefe da DFINITY Foundation, disse no “2020 FAT Value Era Summit Forum and Awards Ceremony” que o computador da Internet é a terceira grande inovação do blockchain.

Este artigo interpretará o texto original do white paper do DFINITY, partindo da lógica mais baixa da explicação oficial, para ver como o DFINITY pode partir da tecnologia, quebrar a big tech da Internet e permitir que vários softwares Web2.0 usem software autônomo e governança descentralizada para alcançar a sinergia dos negócios de código aberto, de modo a realmente realizar a Web3.0; Os leitores sem experiência na indústria de blockchain podem ter um limiar de leitura ao ler este artigo, mas também são bem-vindos para comentar as perguntas que surgem abaixo, e podem obter respostas inesperadas.

2

Esboço

Ao longo da história e do processo atual do blockchain, o BTC trouxe a era do dinheiro descentralizado, o ETH representa o campo dos sistemas operacionais, o Filecoin representa o armazenamento e o DFINITY representa a inovação do campo da computação e a implementação da Web 3.0. Internet Computer (doravante referido como IC) é a rede principal, é um protocolo de camada 1, com o objetivo de desenvolver uma rede pública descentralizada, DFINITY é um computador blockchain virtual aberto e tecnologia, estendendo o ecossistema Ethereum para uma ampla gama de cenários de aplicação de negócios. Neste artigo, usaremos o termo oficial “Internet Computer” no white paper para nos referirmos à cadeia “DFINITY” que é comumente usada no cenário de comunicação atual. Esta seção explica principalmente os termos técnicos envolvidos em alguns CIs, bem como as diferenças de tecnologia e implementação em comparação com outras cadeias públicas, ou os pontos brilhantes em tecnologia e função. Pode-se dizer que o IC é uma nova tentativa de combinação de escalabilidade, descentralização e segurança.

2.1 Protocolo de Consenso

Olhando para o IC e várias outras grandes cadeias públicas da perspetiva de protocolos de consenso, o IC adota um modelo híbrido de rede controlada por DAO, que fornece muitos dos benefícios de um protocolo PoS descentralizado enquanto tem a eficiência de um protocolo permitido. Os protocolos de consenso Bitcoin, Ethereum e Algorand são baseados em blockchain, usando Proof of Work (PoW) ou Proof of Stake (POS). Embora esses protocolos sejam totalmente descentralizados, eles são menos eficientes do que os protocolos permitidos.

DAOs operam por um protocolo de consenso permitido para cada sub-rede, e um DAO decide quais entidades podem fornecer cópias de nós, configura a rede, fornece infraestrutura de chave pública e controla a versão do protocolo na qual as cópias de nós são implantadas. O DAO do IC é chamado de Network Nervous System (NNS) e é baseado no protocolo Pos, ou seja, as decisões relevantes são todas decididas pelos membros da comunidade, e o poder de voto dos membros da comunidade é determinado pelo número de tokens de governança nativa do IC (ICPs) que eles participam no NNS. Esse mecanismo de governança baseado em PoS permite criar novas sub-redes e adicionar ou remover réplicas de nós das existentes, bem como implantar atualizações de software e fazer outros ajustes no IC.

Nessa perspetiva, também podemos entender por que o DFINITY chama IC de uma rede de máquinas de estado replicadas, porque o próprio NNS é uma máquina de estado replicada. Como outras máquinas estatais, elas são executadas em uma sub-rede específica, e sua associação é determinada pelo mesmo sistema de governança baseado em PoS mencionado acima. Ao mesmo tempo, um banco de dados chamado registro é mantido, que registra quais réplicas de nó pertencem a qual sub-rede, as chaves públicas das réplicas de nó e assim por diante. Portanto, a rede de controle DAO serve como um protocolo de consenso descentralizado, permitindo que o CI obtenha um consenso efetivo, mas, ao mesmo tempo, devido ao mecanismo de operação do DAO, o CI também mantém as vantagens existentes da descentralização.

O protocolo de consenso do IC também usa criptografia de chave pública, como o registro mantido pelo NNS para vincular a chave pública à réplica do nó e à sub-rede para formar um todo, que é chamado de criptografia de chave de cadeia, e o IC também prevê o modelo de comunicação para o protocolo de consenso e o protocolo que executa a máquina de estado de replicação: ele espera adotar um modelo assíncrono mais viável e robusto (para qualquer mensagem enviada, o adversário pode atrasar a entrega de qualquer mensagem por um tempo arbitrário, portanto, não há limite de tempo para a entrega da mensagem) para lidar com falhas bizantinas. No entanto, no momento, não há nenhum modelo de consenso conhecido que seja realmente viável sob o modelo assíncrono, e na seguinte interpretação da arquitetura IC, este artigo explicará com mais detalhes a abordagem técnica da CI para esta situação do mundo real.

2.2 Criptografia de chave de cadeia

Como mencionado acima, o protocolo de consenso do IC também usa criptografia de chave pública - criptografia de chave em cadeia, e há várias partes principais que compõem a criptografia de chave em cadeia. O primeiro componente da criptografia de chave de cadeia é a assinatura de limite: a assinatura de limite é uma técnica criptográfica madura que permite que uma sub-rede tenha uma chave de assinatura de verificação comum, e a chave privada de assinatura correspondente é dividida em várias cópias e distribuída para os nós na sub-rede, enquanto a alocação garante que o nó incorreto não pode falsificar assinaturas, e o fragmento de chave privada de propriedade do nó honesto permite que a sub-rede gere assinaturas que estejam em conformidade com os princípios e protocolos de IC.

Uma aplicação chave dessas assinaturas de limite é que a saída individual de uma sub-rede pode ser verificada por outra sub-rede ou por um usuário externo, e a verificação pode ser feita simplesmente verificando a implementação da assinatura eletrônica usando a chave de assinatura de verificação pública da sub-rede modificada (a primeira sub-rede).

Como podemos ver, existem muitas outras aplicações dessas assinaturas de limiar no CI. Um deve ser usado para tornar cada cópia de um nó em uma sub-rede acessível a dígitos pseudoaleatórios imprevisíveis (derivados de tais assinaturas de limiar). Esta é a base para os beacons aleatórios usados pela camada de consenso e as fitas aleatórias usadas pela camada de execução.

Para implantar assinaturas de limite com segurança, o IC emprega um protocolo inovador de Geração de Chaves Distribuídas (DKG) para construir uma chave de verificação de assinatura pública e fornecer a cada réplica de nó um fragmento da chave privada de assinatura correspondente para a falha bizantina mencionada anteriormente e modelos assíncronos.

2.3 PIC

O ICP tem as seguintes características:

NNS staking, ou seja, facilitando a governança da rede.

O ICP pode ser usado para participar do NNS para ganhar direitos de voto e, assim, participar do DAO que controla a rede do IC. Os usuários que apostam tokens no NNS e participam da governança do NNS também recebem tokens ICP recém-cunhados como recompensas de voto. O número de recompensas é determinado pelas políticas estabelecidas e aplicadas pela NNS.

Resgatar Ciclos, ou seja, como potência de produção.

O ICP é utilizado para pagar a utilização do IC. Mais especificamente, o ICP pode ser resgatado por ciclos (ou seja, queimados), que podem ser usados para pagar pelos recursos (armazenamento, CPU e largura de banda) usados para criar tanques e tanques. A razão entre a PIC e o ciclo é determinada pelo NNS.

Os fornecedores de nós são pagos, ou seja, dados como recompensas aos participantes.

O ICP é usado para pagar provedores de nós – entidades que possuem e operam nós de computação para hospedar as cópias dos nós que compõem o IC. O NNS regularmente (atualmente mensal) determina o ICP recém-criado que cada provedor de nó deve receber e liberá-lo em sua conta. De acordo com as políticas estabelecidas e aplicadas pela NNS, o pagamento do ICP tem como premissa o provedor do nó que fornece serviços confiáveis ao IC.

2.4 Execução do NNS

Como mencionado anteriormente, a máquina de estado de replicação do IC pode executar programas arbitrários. A unidade básica de computação em um IC é chamada de tanque, e é muito o mesmo conceito de um processo, contendo o programa e seu estado (que muda ao longo do tempo). O programa do tanque é codificado em WebAssembly (doravante referido como Wasm), que é um formato de instrução de dois mecanismos baseado em uma máquina virtual empilhada. O Wasm é um padrão de código aberto e, embora tenha sido originalmente projetado para permitir aplicações de alto desempenho na web, também é adequado para computação de uso geral.

O IC fornece um ambiente de tempo de execução para executar programas Wasm dentro do tanque e se comunicar (via mensagens) com outros tanques e usuários externos. Enquanto em princípio é possível escrever um programa de tanque em qualquer linguagem que compila para Wasm, a linguagem acima mencionada chamada Motoko é muito consistente com a semântica das operações de IC e pode ser usada em ICs.

Motoko é um programa de programação baseado em ator 2 com suporte integrado para persistência ortogonal 3 e mensagens assíncronas. Persistência de quadratura significa que a memória mantida pelo tanque é automaticamente persistida (ou seja, não precisa ser gravada em um arquivo). O Motoko tem uma série de recursos de produtividade e segurança, incluindo gerenciamento automático de memória, genéricos, inferência de tipos, correspondência de padrões e aritmética arbitrária e de precisão fixa.

Além do Motoko, o IC fornece uma linguagem de definição de interface de mensagem e formato de dados chamado Candid, que é usado para tipo fixo, linguagem de alto nível e interoperabilidade entre idiomas. Isso facilita a comunicação entre dois tanques, mesmo que escritos em idiomas de alto nível diferentes. A fim de fornecer suporte completo para o desenvolvimento de tanque para qualquer linguagem de programação, suporte de tempo de execução específico deve ser fornecido, além do compilador Wasm para essa linguagem. Atualmente, além do Motoko, o IC também suporta totalmente o desenvolvimento de tanques na linguagem de programação Rust.

Como resultado, os ICs suportam linguagens de programação mais seguras e multi-linguagem, o que é um dos fatores importantes que tornam os desenvolvedores mais eficazes e seguros na criação de ICs.

2.5 Decisões NNS

Na rede blockchain DFINITY, BNS (Blockchain Nervous System) é o sistema de governança em que a rede opera, e é um dos blocos de construção mais importantes na rede blockchain, que pode entrar automaticamente no sistema e ter alta autoridade. Assume o papel de um supernó. Qualquer pessoa participa na governação do NNS apostando o ICP nos chamados neurónios. Os detentores de neurônios podem propor e votar sobre como o CI deve ser alterado, como a topologia da sub-rede ou o protocolo. Os direitos de voto dos neurónios baseiam-se no PoS. Intuitivamente, quanto mais ICP é apostado, mais direitos de voto neuronais são maiores. No entanto, o poder de voto também depende de outras características dos neurônios, como detentores neuronais que estão dispostos a apostar seus tokens por um longo período de tempo, recebem maior poder de voto.

Cada proposta tem um período de votação definido. Se, no final do período de votação, a maioria simples dos que votarem a favor da proposta e o número de votos a favor exceder o requisito de quórum para o total dos direitos de voto (agora 3%), a proposta é aprovada. Caso contrário, a proposta foi rejeitada. Além disso, sempre que uma supermaioria (mais de metade dos votos totais) for a favor ou contra a proposta, esta é aceite ou rejeitada em conformidade.

Em termos mais leigos, o processo de governança do BNS é dividido em quatro fases: criação de neurônios, proposta, votação e execução.

Criar neurônios: Como mencionado acima, o blockchain Neurosystem permite que os usuários usem ICP para criar neurônios de voto. Qualquer pessoa pode criar um neurônio e, no futuro, dezenas de milhares de neurônios podem ser criados, que expressarão coletivamente a vontade da comunidade, mediada por algoritmos.

Propostas: Qualquer usuário que execute neurônios pode fazer uma proposta sobre BNS, e BNS irá rever a proposta com base na razoabilidade da proposta e se ela fornece uma solução. O usuário que faz a proposta precisa pagar duas taxas: uma é para pagar os revisores profissionais e os neurônios que participaram da votação, e a outra é o depósito da proposta, que será devolvido ao neurônio após a proposta ser adotada, e esse valor pode ser definido para incentivar propostas de alta qualidade.

Votação: Além do proponente, outros usuários também precisam apostar tokens nos neurônios durante a fase de votação e poder optar por votar ativamente ou acompanhar a votação. Usuários com capacidade de julgamento independente podem optar por votar ativamente, e o cenário de seguir a votação é adequado para alguns usuários que não podem julgar propostas com precisão. Após o encerramento do período de votação, o BNS coleta os resultados da rede neural e determina automaticamente se a proposta é aprovada ou não.

Implementação: Só agora existe uma interpretação do consenso do IC da camada de execução, qual é a implementação específica da implementação do sistema de governança do BNS? A PROPOSTA DE EXECUÇÃO PASSIVA ENVOLVE PRINCIPALMENTE MUDANÇAS DE PARÂMETROS PARA CONTRATOS INTELIGENTES EM DFINITY, COMO OS PARÂMETROS DE ESTACA DOS NEURÔNIOS. Os parâmetros da proposta atualizada serão gravados passivamente no banco de dados de contratos inteligentes BNS e entrarão em vigor diretamente quando forem executados posteriormente. Há um caso especial em que a proposta está fora do controle do contrato inteligente BNS, por exemplo, envolvendo o nível regulatório do BNS, que exigirá uma execução humana ativa para substituir a parte “código é lei” do DFINITY. Por exemplo, modificar vulnerabilidades no código do sistema ou congelar contratos inteligentes ou neurônios que violam os regulamentos BNS. O processo de execução ativa é implementado invocando opcodes especiais adicionados ao EVM. A operação desta etapa é mais humana e razoável, em vez do atual “código é lei” e “código é tudo” no mundo blockchain atual. Do ponto de vista da natureza humana, cobrir cenários onde o código não pode tomar decisões pode trazer uma governança mais eficaz e inteligente e, em certa medida, também toca verdadeiramente a intenção subjacente do “consenso”.

3

Interpretação de Arquitetura

O protocolo IC consiste em quatro camadas (como mostrado na figura abaixo), ou seja, a camada P2P, a camada de consenso, a camada de roteamento e a camada de execução. Nesta parte, este artigo apenas interpreta os papéis e funções da arquitetura de quatro camadas, e analisa a construção da arquitetura geral. PARA UMA COMPREENSÃO MAIS DETALHADA DA IMPLEMENTAÇÃO TÉCNICA ESPECÍFICA DE UMA CAMADA ESPECÍFICA, CONSULTE O WHITE PAPER ORIGINAL DA DFINITY.

3.1 Camada P2P

A camada P2P serve como a camada na camada de protocolo do computador da Internet para busca e ordenação de mensagens, e sua tarefa é entregar mensagens de protocolo em uma cópia dos nós da sub-rede.

Existem dois tipos de mensagens de protocolo: mensagens usadas para obter consenso e mensagens de entrada iniciadas por usuários externos.

Podemos entender que a camada P2P basicamente fornece um canal de transmissão de “melhor esforço”, ou seja, se uma cópia de nó honesto transmitir uma mensagem, a mensagem acabará sendo recebida por todos os nós da cidade na sub-rede.

A camada P2P é projetada com os seguintes objetivos:

Recursos limitados. Todos os algoritmos são executados com recursos limitados (memória, largura de banda, CPU).

Prioridade. Dependendo de atributos específicos, como tipo, tamanho e turno, mensagens diferentes serão classificadas com prioridades diferentes. E as regras para essas prioridades podem mudar ao longo do tempo.

Altamente eficiente. Alta taxa de transferência é mais importante do que baixa latência. O ALTO RENDIMENTO TAMBÉM É A RAZÃO PELA QUAL A DFINITY É MAIS EFICIENTE A PARTIR DA BASE DO QUE OUTRAS CADEIAS PÚBLICAS.

Anti-DOS/SPAM. Os nós com falha não afetarão a comunicação entre réplicas de nós honestos.

3.2 Camada de consenso

3.2.1 Visão geral da camada de consenso

A tarefa da camada de consenso IC é classificar as mensagens de entrada para garantir que todas as réplicas dos nós processem as mensagens de entrada na mesma ordem. Existem muitos protocolos na literatura que abordam esta questão. O CI adota um novo protocolo de consenso, que será descrito em linguagem geral neste artigo. Qualquer protocolo de consenso seguro deve garantir dois atributos, que são aproximadamente isso:

Segurança: Todas as réplicas de nós concordam de facto com a mesma ordem de entradas.

Ativo: Todas as réplicas de nó devem atualizar seu status uma a uma.

O objetivo de design da camada de consenso IC é realmente fácil de entender: quando há nós maliciosos individuais, o desempenho será degradado de forma flexível. Como muitos protocolos de consenso, o protocolo de consenso IC é baseado em blockchain. À medida que o protocolo progride, a árvore de blocos com o bloco de gênese como nó raiz continuará a crescer. Cada bloco não-gênese contém uma carga útil, que consiste em uma série de entradas e o hash do bloco pai.

As réplicas honestas têm uma visão consistente da árvore de blocos: embora cada réplica possa ter uma visão local diferente da árvore de blocos, todas as réplicas do nó veem a mesma árvore de blocos. Além disso, à medida que o protocolo progride, sempre haverá um caminho na árvore de blocos para finalizar o bloco. Novamente, as réplicas de nó honestas têm uma visão consistente desse caminho: embora cada réplica de nó possa ter uma exibição local diferente do caminho, todas as réplicas de nó veem o mesmo caminho. As entradas na carga dos blocos ao longo deste caminho são as entradas ordenadas que serão processadas pela camada de execução do IC.

O protocolo de consenso depende de assinaturas eletrônicas para verificar mensagens em uma cópia de um nó. Para conseguir isso, cada cópia do nó é associada a uma chave de autenticação pública para o protocolo de assinatura. A correlação entre a réplica do nó e a chave pública pode ser obtida a partir do registo mantido pelo NNS. Isso também está de acordo com o papel e o papel da criptografia de chave de cadeia nos CIs mencionados acima.

3.2.2 Pressupostos

Conforme discutido na Parte II, o CI propõe a seguinte hipótese:

Uma sub-rede contém n réplicas de nós e um máximo de f

Réplicas de nó com falha podem apresentar comportamento arbitrário e malicioso (ou seja, falha bizantina). Assumimos que a comunicação é assíncrona e que não há limitação prévia na latência da mensagem entre réplicas de nós, ou seja, o modelo assíncrono mencionado acima. Neste ponto, o agendamento das mensagens pode ser completamente hostil. Sob este pressuposto de comunicação fraca, o protocolo de consenso do CI pode garantir a segurança. Mas para garantir a atividade, precisamos assumir uma certa forma de sincronização parcial, o que significa que a rede permanece periodicamente sincronizada em intervalos curtos. Neste intervalo de sincronização, todas as informações não enviadas serão enviadas dentro do prazo, ou seja, um prazo fixo δ. O limite de tempo δ não é conhecido antecipadamente (o protocolo inicializa um valor limite razoável, mas ajusta dinamicamente o valor e aumenta o valor limite quando o limite de tempo é muito pequeno). Independentemente de a rede ser assíncrona ou parcialmente síncrona, assumimos que as mensagens enviadas por uma réplica de nó honesto para outra réplica de nó serão eventualmente entregues.

3.2.3 Visão geral do protocolo

Como muitos protocolos de consenso, o protocolo de consenso IC é baseado em blockchain. À medida que o protocolo progride, as árvores de bloco (ver 3.2.4, por exemplo) com o bloco de génese à medida que o nó raiz continua a crescer. Cada bloco não-gênese contém uma carga útil, que consiste em uma série de entradas e o hash do bloco pai. As réplicas honestas têm uma visão consistente da árvore de blocos: embora cada réplica possa ter uma visão local diferente da árvore de blocos, todas as réplicas do nó veem a mesma árvore de blocos. Além disso, à medida que o protocolo progride, sempre haverá um caminho na árvore de blocos para finalizar o bloco. Da mesma forma, as réplicas de nó honesto têm uma visão consistente desse caminho e, embora cada réplica de nó possa ter uma exibição local diferente do caminho, todas as réplicas de nó veem o mesmo caminho. As entradas nas cargas dos blocos ao longo deste caminho foram classificadas e processadas pela camada de execução, que é interpretada na seção anterior.

3.2.4 Exemplo prático

A imagem abaixo mostra uma árvore de blocos. Cada bloco é marcado com uma altura de bloco (30, 31, 32, ··· ) e a classificação dos geradores de blocos, que mostra que cada bloco na árvore de blocos é autenticado em cartório e marcado com o símbolo N. Isso significa que os blocos autenticados em cada árvore de blocos são suportados pela autenticação de pelo menos n-f cópias de nós diferentes. Pode-se descobrir que pode haver mais de um bloco autenticado na altura especificada do bloco. Por exemplo, na altura do bloco 32, podemos ver 2 blocos autenticados em cartório, um proposto pelo gerador de blocos no rank 1 e outro proposto pelo rank 2, e a mesma coisa acontece na altura do bloco 34. Também podemos ver que blocos com uma altura de 36 também são explicitamente confirmados, como identificado pelo símbolo F. Isso significa que cópias n-f de nós diferentes suportaram a confirmação final do bloco, o que significa que essas cópias de nó (ou pelo menos as cópias honestas do nó destes) não suportam a autenticação de qualquer outro bloco. Todos os antepassados cujo bloco é preenchido com cinza são considerados como tendo recebido confirmação final implícita.

**3.2.5 Imparcialidade **

A equidade é a base do consenso, por isso outro atributo importante nos protocolos de consenso é a equidade. Em vez de estabelecer uma definição universal, simplesmente observamos que a invariância da vida implica uma propriedade útil de justiça. Para recapitular, invariância significa essencialmente que em qualquer rodada, quando o masternode é honesto e a rede está sincronizada, o bloco proposto pelo masternode também será finalizado. No turno em que isso acontece, o nó mestre honesto realmente garante que ele contenha todas as entradas que conhece na carga do bloco (dependendo dos limites do módulo do tamanho da carga). Assim, grosso modo, qualquer entrada que seja propagada para um número suficiente de cópias de nó provavelmente será incluída no bloco final confirmado dentro de um período de tempo razoável.

3.3 Camada de roteamento

Como mencionado anteriormente, a unidade de computação básica no IC é chamada de tanque. O IC fornece o ambiente operacional no qual os programas podem ser executados no tanque e podem se comunicar (via mensagem) com outros tanques e usuários externos. A camada de consenso empacota a entrada na carga do bloco e, à medida que o bloco é confirmado pelo mais vermelho, a carga correspondente é passada para a camada de roteamento de mensagens e processada pelo ambiente de execução. Em seguida, a camada de execução atualiza o estado no tanque correspondente na máquina de estado de replicação e transfere a saída para a camada de roteamento de mensagens para processamento.

É necessário distinguir entre dois tipos de entradas:

Mensagem de ingresso: uma mensagem de um usuário externo.

Mensagens entre sub-redes: Mensagens de tanques em outras sub-redes.

Também podemos distinguir entre dois tipos de saída:

Resposta da mensagem de entrada: A resposta à mensagem de entrada (que pode ser recuperada por usuários externos).

Mensagens entre sub-redes: mensagens que são transmitidas para outros tanques de sub-rede.

Quando cargas de consenso são recebidas, as entradas nessas cargas são colocadas em diferentes filas de entrada. Para cada tanque C sob uma sub-rede, há várias filas de entrada: uma mensagem de entrada para C, um tanque separado C’ para se comunicar com C e uma mensagem de sub-rede cruzada de C para C’.

Em cada rodada, a camada de execução consome algumas das entradas dessas filas, atualiza o estado de replicação no tanque correspondente e coloca as saídas em uma fila diferente. Para cada tanque sob uma sub-rede, há várias filas de saída: para cada tanque que se comunica com, há uma fila para mensagens entre sub-redes de C a C’. A camada de roteamento da mensagem pega as mensagens na fila de mensagens e as coloca no tráfego de sub-rede para sub-rede a ser processado pelo protocolo de transporte entre sub-redes, que realmente transmite as mensagens para outras sub-redes.

Além dessas filas de saída, há também uma estrutura de dados históricos para mensagens de entrada. Uma vez que uma mensagem de entrada tenha sido processada pelo tanque, a resposta a essa mensagem de entrada é registrada nessa estrutura de dados. Neste ponto, o usuário externo que forneceu a mensagem de entrada será capaz de obter a resposta relevante. (Nota: O histórico de entrada não mantém um histórico completo de todas as mensagens de entrada).

Há dois pontos que precisam ser esclarecidos, primeiro, o estado da réplica do nó inclui o estado do tanque, bem como o “estado do sistema”. “Estado do sistema” inclui as filas, fluxos de dados e estruturas de dados do histórico de entrada mencionado acima. Como resultado, tanto a camada de roteamento de mensagens quanto a camada de execução estão envolvidas na atualização e manutenção do estado da réplica da sub-rede. Este estado deve ser atualizado com determinismo completo, para que todos os nós mantenham exatamente o mesmo estado.

O segundo ponto a observar é que a camada de consenso precede a camada de roteamento de mensagens e a camada de execução, o que significa que quaisquer bifurcações no blockchain de consenso já foram resolvidas antes que a carga seja passada. Na verdade, a camada de consenso permite a operação antecipada e não precisa estar no mesmo cronograma que a camada de roteamento de mensagens.

A explicação da camada de roteamento nos dá uma compreensão mais clara de como o protocolo de consenso é transmitido de e para o protocolo de consenso através do roteamento de mensagens, e como ele é conectado à camada de execução, de modo a promover a coordenação e consistência do protocolo de consenso.

3.4 Camada de Execução

O ambiente de execução processa uma entrada de cada vez, que é retirada de uma das filas de entrada e direcionada para um tanque, dependendo do estado da entrada e do tanque, o ambiente de execução atualiza o estado do tanque e pode adicionar mensagens à fila de saída. e atualizar o histórico de entrada (possivelmente junto com a resposta à mensagem de entrada anterior). Em um determinado turno, o ambiente de execução processará várias entradas. O agendador determina quais entradas serão executadas em que ordem para um determinado turno. Em vez de entrar em muitos detalhes sobre o agendador, vamos destacar alguns dos objetivos:

Deve ser determinista, ou seja, depender unicamente dos dados fornecidos;

Ele deve distribuir a carga de trabalho de forma justa entre os tanques (mas otimizar para taxa de transferência em vez de latência).

O número de trabalhos concluídos em cada ronda é medido em ciclos e deve estar próximo de alguma quantidade pré-determinada.

Outra tarefa que o ambiente de execução deve lidar é a situação em que um dos tanques de uma sub-rede produz mensagens através de sub-redes mais rápido do que as outras sub-redes podem consumir. Em resposta a esta situação, implementámos um mecanismo de autorregulação para abrandar o tanque de produção. Há muitas outras tarefas de gerenciamento de recursos e contabilidade que precisam ser tratadas pelo ambiente de tempo de execução, mas todas essas tarefas devem ser tratadas deterministicamente.

4

Criptografia de chave de cadeia

Na sinopse, explicamos que o protocolo de consenso do IC também usa a técnica de criptografia de chave pública - criptografia de chave em cadeia, e uma parte importante da criptografia de chave em cadeia é a assinatura de limiar. Na verdade, a criptografia de chave de cadeia engloba um conjunto complexo de técnicas usadas para manter de forma robusta e segura máquinas de estado de replicação baseadas em blockchain ao longo do tempo, conhecidas coletivamente como técnicas de evolução em cadeia. Cada sub-rede opera dentro de épocas que contêm várias rodadas (geralmente cerca de algumas centenas). A tecnologia de evolução da cadeia permite muitas das tarefas básicas de manutenção que são executadas por época: coleta de lixo, encaminhamento rápido, alterações de membros da sub-rede, encaminhamento secreto ativo e atualizações de protocolo.

A compreensão da tecnologia de evolução da cadeia, ou seja, a compreensão da implementação técnica da segurança do protocolo de consenso IC. A tecnologia de evolução da cadeia consiste em dois componentes básicos: blocos de resumo e pacotes de recuperação (CUPs).

4.1 Bloco Resumo

O primeiro bloco de cada época é o bloco digest. O bloco de resumo contém dados especiais que são usados para gerenciar fragmentos de chave para diferentes esquemas de assinatura de limite. Existem dois esquemas de assinatura de limiar:

Em um cenário com uma estrutura de limite de f + 1/n, uma nova chave de assinatura é gerada para cada época;

Em um cenário com uma estrutura de limite de n-f/n, a chave de assinatura é compartilhada novamente uma vez por época.

Cenários com limites baixos são usados para beacons aleatórios e fitas aleatórias, enquanto cenários com limites altos são usados para verificar o status de replicação da sub-rede. Lembre-se de que o protocolo DKG requer que, para cada chave de assinatura, haja um conjunto de negociações, e cada réplica de nó pode obter seu fragmento de chave de assinatura não interativamente com base nesse conjunto de negociações. Lembre-se novamente, entre outras coisas, o NNS mantém um registro que determina os membros da sub-rede. O registo (e os membros da sub-rede) mudam ao longo do tempo. Como resultado, as sub-redes devem concordar com a versão do registro a ser usada em momentos e finalidades diferentes. Essas informações também são armazenadas no bloco de resumo.

4.2 COPAS

Com o resumo fora do caminho, vamos dar uma olhada nos pacotes de recuperação, ou CUPs. Antes de elaborarmos o CUP, primeiro precisamos apontar um detalhe de beacons aleatórios: os beacons aleatórios de cada rodada dependem dos beacons aleatórios da rodada anterior. Não é uma característica fundamental do CUP, mas influencia o design do CUP. Um CUP é uma mensagem especial (não no blockchain) que tem tudo o que um nó precisa para funcionar no ponto de partida de uma época sem saber nenhuma informação sobre a época anterior. Contém os seguintes campos de dados:

A raiz da árvore de hash de Merkel para todo o estado replicado (em oposição ao estado parcial de cada rodada de validação no Capítulo 1.6).

época.

Farol aleatório para a primeira rodada de época.

A assinatura limite da sub-rede para (n - f)/n para os campos acima.

Para gerar um CUP para uma determinada época, a réplica do nó deve esperar até que o bloco digest da época tenha sido finalizado e o estado redondo correspondente tenha sido verificado. Como mencionado anteriormente, todo o estado de replicação deve ser processado em uma árvore Merkle por uma função hash. Embora existam muitas técnicas usadas para acelerar esse processo, o custo ainda é significativo, e é por isso que cada época é processada apenas uma vez. Como o CUP contém apenas a raiz dessa árvore Merkle, usamos um subprotocolo de sincronização de estado que permite que a réplica do nó extraia do par qualquer estado necessário. Mais uma vez, usamos muita tecnologia para acelerar esse processo, e ainda é caro. Como usamos assinaturas de alto limiar para CUPs, podemos garantir que há apenas um CUP válido em qualquer época, e esse estado pode ser extraído de muitos pares.

4.3 Implementação da Tecnologia Chain Evolution

Coleta de lixo: Como o CUP contém informações sobre uma época específica, cada cópia do nó pode limpar com segurança todas as entradas processadas anteriores a essa época, bem como as mensagens da camada de consenso que ordenaram essas entradas.

Encaminhamento rápido: Se uma réplica de um nó em uma sub-rede estiver significativamente atrasada em relação ao seu nó síncrono (porque ele está inativo ou desconectado por um longo tempo), ou se uma nova réplica do nó for adicionada à sub-rede, eles poderão encaminhar rapidamente para o ponto inicial da época mais recente sem ter que executar o protocolo de consenso e processar toda a entrada antes desse ponto. Esta cópia do nó pode ser feita obtendo o CUP mais recente. Com os blocos de resumo e beacons aleatórios contidos nos CUPs, bem como mensagens de consenso (ainda não limpas) de outras cópias de nós, a réplica do nó pode executar o protocolo de consenso a partir do ponto inicial da época correspondente. O nó também pode usar o subprotocolo de sincronização de estado para obter o estado de replicação no início da época correspondente, para que também possa começar a processar as entradas geradas pela camada de consenso.

O diagrama a seguir mostra o avanço rápido. Aqui, vamos supor que precisamos de uma réplica de nó que precisa alcançar o ponto de partida da época, (digamos) com uma altura de bloco de 101 e um CUP. Este CUP contém a raiz da árvore Merkle replicada com uma altura de bloco de 101, um bloco de resumo com uma altura de bloco de 101 e um farol aleatório com uma altura de bloco de 101. O nó usa o subprotocolo de sincronização de estado para obter todo o status de replicação da altura do bloco 101 de seus pares e verifica esse estado com a árvore Merkle no CUP. Depois de obter esse estado, a cópia do nó pode participar do protocolo, obter blocos com altura de bloco de 102, 103, etc. (e outras mensagens relacionadas ao consenso) do par e atualizar a cópia de seu estado de replicação. Se seus pares confirmaram blocos em um nível mais alto, a cópia do nó processará (bem como registrará e finalizará) os blocos finalizados obtidos dos pares o mais rápido possível (tão rápido quanto a camada de execução permitir).

5

Epílogo

Tal como o Ethereum, a visão da DFINITY é construir o “supercomputador do mundo”, através da já mencionada interpretação parcial e explicação técnica do seu white paper. Os CIs sob esta visão têm uma grande oportunidade de serem realizados.

Podemos ver a inovação tecnológica e viabilidade técnica do IC para realizar sua visão a partir do modelo híbrido DAO do protocolo de consenso, da inovação tecnológica de geração rápida de blocos e alto rendimento, e do sistema de neurônios BNS e seu esquema de governança ecológica. Ao contrário do código Ethereum atual, que é lei, a governança de código IC adiciona elementos de sabedoria de multidão à fundação, não com o objetivo de estabelecer uma arquitetura de código perfeita, mas com o objetivo de o sistema ser capaz de ajustar rapidamente as regras. Esta não é apenas uma criação tecnológica, mas também uma natureza humana brilhante. No mundo blockchain, o estabelecimento, manutenção e modificação do consenso não pode ser apenas codificado, mas a essência do núcleo deve ser as pessoas. O consenso válido e justo entre grupos centrados no ser humano está no coração da indústria de blockchain e na atração de muitos Dapps descentralizados.

Este artigo cita e interpreta alguns dos conteúdos do white paper do IC, que descreve mais detalhes sobre o NNS, o status de autenticação de cada rodada de sub-redes na camada de consenso, as chamadas de consulta e atualização de mensagens de entrada, distribuição de chaves distribuídas em criptografia de chave em cadeia, esquemas PVSS, protocolos básicos e protocolos de recompartilhamento, e assim por diante. Para desenvolvedores que desejam uma compreensão mais abrangente e detalhada da tecnologia subjacente do IC, a leitura do white paper original pode fornecer explicações e explicações mais detalhadas.