🙏 🛵 📦 Framework: análise de sistemas DLT 🤰🏼 🏳️‍🌈 🧔🏽

Este trabalho tem como objetivo determinar se o objeto analisado é um sistema DLT. Os resultados obtidos são adequados para análise comparativa de vários projetos, desde a estrutura de gerenciamento até a definição de links aos quais as transações se referem.

A tecnologia de contabilidade distribuída é uma tecnologia de armazenamento de informações cujas principais características são o compartilhamento e a sincronização de dados digitais de acordo com o algoritmo de consenso, a distribuição geográfica de cópias equivalentes em diferentes pontos do mundo, a ausência de um administrador central.

Análise técnica

Nível de protocolo

Gênesis

Nível de protocolo, refere-se aos processos que precisam ser desenvolvidos e executados antes do início da rede.

Dependência de outras redes.

A dependência de outros protocolos depende dos limites do projeto analisado. Isso determina se o sistema pode operar como um sistema independente (para ser auto-suficiente) ou depende de outra rede.

Tabela 1. Dependência de outros sistemas

Código do programa

O código pode ser baseado em uma estrutura existente ou gravado do zero. As estruturas mais populares são as bases de código de sistemas de código aberto (Bitcoin / Ethereum). Também existem bancos de dados de código fechado para plataformas fechadas fornecidos por projetos como Digital Asset / Clearmatics e SETL.

Tabela 2. Código do Programa

Definindo Regras

A introdução de regras refere-se à definição de um conjunto de regras nas quais um sistema DLT deve operar. Esse processo pode ser realizado por diferentes participantes e é individual para um sistema DLT específico.

Atualização de protocolo

As atualizações de protocolo se aplicam aos processos existentes que permitem modificar as regras do sistema. A atualização do protocolo pode incluir a eliminação de erros técnicos (bugs), aprimorando a segurança e a funcionalidade do sistema, além de expandir ou limitar as regras de protocolo existentes.

Gerenciamento de protocolo

O gerenciamento de protocolo se refere a um conjunto de processos de tomada de decisão que permitem alterar um protocolo de maneira ordenada e legal. Este é um subconjunto de gerenciamento de projetos mais amplo, que abrange um conjunto completo de processos e normas que descrevem e definem coordenação e ações, mas que não podem ser formalmente integrados ao sistema DLT.

Um elemento importante de qualquer alteração proposta ao protocolo é a maneira como ele é adotado e ratificado - ou, em outras palavras, como a legitimidade é fornecida por sugestão dos participantes da rede. Como a legitimidade nesse contexto é um conceito social, parece razoável identificar algumas das possíveis relações "sócio-políticas" encontradas nos sistemas DLT.

Tabela 3. Gerenciamento de Protocolo

O gerenciamento de protocolos assume várias formas e geralmente não é claro. Inicialmente, os sistemas DLT são caracterizados pelo poder anarquista (gratuito), não há empresas ou grupos de pessoas responsáveis por tomar decisões. Acima de tudo, eles são semelhantes aos processos de gerenciamento de tráfego de código aberto. Um exemplo de discussão de alterações de protocolo pode ser a comunicação de desenvolvedores em uma conversa / GitHub / conferência. Sob condições ditatoriais, o processo de discutir mudanças pode ser exatamente o mesmo, mas a decisão final será tomada por uma pessoa. Em alguns casos, um formulário de gerenciamento de protocolo pode ser definido por mais de um tipo de placa. Por exemplo, o blockchain da EOS atua como uma federação de fabricantes de blocos selecionados por usuários que possuem um ativo da EOS. O peso do voto é determinado pelo número de tokens contidos no endereço. Esse tipo de governo divide o protocolo em dois partidos: os usuários "de elite" e "comuns", assumindo as características de um sistema hierárquico: federação, democracia e plutocracia.

Gerenciamento on-chain, implica a inclusão de funções de gerenciamento no nível de dados. O objetivo é formalizar a governança, aumentando a legitimidade e evitando a fragmentação da rede devido a disputas ou atualizações inconsistentes do protocolo. Um conjunto diversificado de esquemas de votação em cadeia foi desenvolvido para sistemas DLT, variando de um barômetro de humor comunitário a referendos. No entanto, as funções de gerenciamento on-chain, como regra, são apenas uma adição a outras formas de gerenciamento.

Alteração de protocolo

O processo real de atualização do protocolo implica:

atualização de código no GitHub se for um projeto de código aberto;
atualização do cliente se for um protocolo de código fechado;
Clientes que trabalham no código antigo do programa podem ser considerados irrelevantes e na lista negra;
Clientes executando o código de programa antigo formam um fork, o que leva à criação de uma versão alternativa do protocolo.

Tabela 4. Formulário de modificação de protocolo

Sistemas DLT diferentes usam métodos diferentes para atualizar a rede. Por exemplo, o Ethereum aceita doações para financiar o desenvolvimento e também atualiza a rede usando software de desenvolvedores financiados por doações.

Nível de rede

A rede de protocolo DLT é um resultado direto da implementação de regras de protocolo. A rede consiste no trabalho coordenado de participantes e processos que aderem a um padrão tecnológico (protocolo) e estão ativamente envolvidos na troca de dados e informações por canais de comunicação específicos.

Processo de comunicação

O processo de transferência de dados entre participantes em um sistema DLT.

Acesso à rede

O acesso à rede implica a possibilidade de conexão ao protocolo, que pode ser limitado ou ilimitado.

Acesso ilimitado - qualquer usuário pode conectar / desconectar livremente a qualquer momento;
Acesso limitado - apenas alguns usuários podem se conectar à rede, geralmente isso é controlado pela entidade designada.

Como regra, os sistemas com acesso ilimitado não têm restrições ao número de participantes, enquanto as redes fechadas podem definir um número limitado de participantes.

Geralmente, os participantes obtêm acesso direto à rede lançando nós completos: são considerados uma “elite” com um grande conjunto de direitos, pois podem enviar / verificar e transferir dados de registros. Os participantes da rede também podem obter acesso indireto à rede executando “clientes light” que solicitam dados de nós completos, conectando-se através de um serviço especial (API).

Tabela 5. Formulário de acesso à rede

Por via de regra, quanto mais aberto o sistema, mais suscetível a ataques. Em particular, esses sistemas são vulneráveis ao ataque Sibyl, quando o invasor cria muitas identidades falsas para aumentar a influência na rede.

O ataque Sibyl é um tipo de ataque quando um invasor obtém acesso ou oculta uma alteração no protocolo, criando muitas identidades falsas.

Como a identificação é uma propriedade exógena (ou seja, "real"), o sistema DLT não pode impedir esses ataques, mas deve contar com participantes externos (sistema de certificação) ou mecanismos que reduzam a probabilidade de um ataque (PoW / PoS).

Enviando dados

Transferência de dados é o processo de distribuição de dados para nós conectados. Os dados podem ser brutos / não formatados ou padronizados para um formato específico (por exemplo, na forma de uma transação ou registro). Os dados podem ser transmitidos para cada nó (difusão universal) ou apenas para um subconjunto específico de nós (difusão multicanal). Neste último caso, a disseminação de dados é geralmente limitada aos participantes da transação. Isso permite que você crie um "canal" para transferência de dados, geralmente com isso se entende sharding / Lightning Network.

Os primeiros sistemas DLT (por exemplo, Bitcoin, Litecoin) usam um modelo de distribuição de dados universal, que continua sendo o método de distribuição de dados mais popular.

Para manter o anonimato e a privacidade das empresas, os sistemas posteriores têm um modelo de difusão multicanal (por exemplo, Hyperledger Fabric, Corda). Outros sistemas, como o Cosmos, são projetados para atuar como hubs, para que os sistemas DLT independentes possam ser interconectados por meio de sharding.

Tabela 6. Formulário de envio de dados

Um exemplo de difusão de dados multicanais é que nem todos os participantes da rede devem participar do consenso sobre o estado do canal: somente os participantes do canal devem obter consistência sobre os dados armazenados nesse canal (consenso "local"). Isso é significativamente diferente dos sistemas com difusão global de dados, já que cada nó individual deve chegar a um consenso sobre o estado global do sistema (consenso "global"); a incapacidade de chegar a um consenso de alguns nós pode levar à desconexão ou à criação de um fork.

Criação de transação

O processo de criação da transação contém um conjunto de instruções que serão executadas depois que uma transação for adicionada à rede. A criação de transações pode ser ilimitada (ou seja, acessível a todos) ou limitada a alguns participantes. As transações são criadas pelos usuários que assinam a mensagem com sua chave privada. Várias interfaces estão disponíveis para os usuários criarem e enviarem transações para a rede (por exemplo, PCs e carteiras móveis).

Processamento de transação

O processamento de transações descreve o conjunto de ações necessárias para adicionar uma transação não confirmada à lista de confirmadas. Uma transação é considerada (preliminar) válida após adicionar ("confirmado") à lista, o que leva à execução das instruções incorporadas na transação. No entanto, somente a confirmação não é suficiente para que essa transação se torne a base para operações subsequentes; antes que as saídas da transação possam ser usadas pelo sistema.

Figura 1. Processamento de transação em um sistema DLT

Os registros obedecem a um algoritmo de consenso específico usado no sistema DLT. Isso inclui o processo de determinar se o registro proposto é válido, além de rejeitar entradas inválidas (por exemplo, entradas defeituosas ou incompatíveis) e escolher entre entradas diferentes, mas igualmente válidas.

Record Candidate

Os registros que podem ser movidos para a lista de transações confirmadas no futuro são enviados pelos criadores dos blocos, que os selecionam da lista de transações não confirmadas e os combinam para formar candidatos à gravação na lista de registros confirmados. Existem duas propriedades que determinam o direito de enviar um registro e sua inclusão futura na lista de registros confirmados.

Tabela 7. Formulários de Registro

Como os registros estão sujeitos a consenso, eles devem seguir as regras do protocolo. Primeiro, eles devem ser formatados corretamente e não devem conter transações inválidas ou inválidas. Além disso, cada entrada deve incluir um link / ponteiro para a entrada anterior e, se necessário, usar PoW ou qualquer outro método que dificulte a realização de um ataque Sibyl.

O algoritmo de consenso pode ser classificado de acordo com seu nível de complexidade (custos elétricos / monetários). Algoritmos com complexidade ilimitada são medidos nos recursos necessários para alcançar consenso. Por exemplo, no caso de cálculo do PoW Bitcoin, a dificuldade de encontrar a solução certa aumenta à medida que a complexidade dos dados de hash. Muito pelo contrário, outros algoritmos funcionam (por exemplo, a tarefa Bizantine Generals / BFT) não exigem custos computacionais significativos e possuem complexidade limitada.

Em sistemas abertos, um algoritmo deve ser fornecido para reduzir a chance de um ataque Sybil. Sistemas privados (fechados) verificam cada participante antes de permitir o acesso à conexão de rede, o que impede a possibilidade de um ataque. Em sistemas fechados, um grupo de nós tende a escolher um nó que criará blocos.

Resolução de Conflitos

Um conflito pode ser causado por vários motivos:

os participantes discordam sobre qual versão do protocolo é relevante;
os participantes discordam sobre transações verificadas.

No caso de uma situação do primeiro ponto na rede Bitcoin, a rede seleciona a cadeia mais longa de blocos como válida e ignora a mais curta. No Tezos, a validade de um bloco é determinada com um "peso do bloco" diferente, o peso aqui é o número de "aprovações" dos validadores que ele recebe aleatoriamente dos agentes.

Qualquer algoritmo de consenso carrega uma série de vantagens e desvantagens

Tabela 7. Formas de motivação para processamento de transações

Validação

A validação refere-se ao conjunto de processos necessários para garantir que os sujeitos cheguem independentemente à mesma conclusão em relação a um conjunto de registros aprovado. Isso inclui: verificação de transações enviadas / verificação de dados gravados / verificação do status geral da rede. Essa é uma distinção importante dos sistemas não DLT, pois oferece aos participantes a oportunidade de realizar uma auditoria independente do sistema.

Verificação de transação

Verificar uma transação é garantir que um registro individual esteja em conformidade com as regras do protocolo antes de transferi-lo para outras entidades. Isso inclui: a correção do formato da transação, a presença de uma assinatura apropriada e a condição de que a transação não entre em conflito com nenhuma outra. Alguns sistemas podem operar um sistema que proíbe transações até um momento específico ou outro motivo. Normalmente, essas condições são atendidas por contratos inteligentes.

Um ataque de 51% ocorre quando um participante ou vários participantes combinam seu poder de computação (vozes) e processam transações na rede mais rapidamente do que o restante do protocolo. Esses ataques permitem realizar transações inválidas e registrá-las como válidas. Especialmente vulnerável é um sistema que usa PoW

Verificar registros

A verificação do registro que está sendo enviado permite garantir que o registro esteja em conformidade com as regras do protocolo. Se a entrada proposta for reconhecida como válida, ela será adicionada à lista de entradas confirmadas e retransmitida para todos os nós conectados na rede. Embora esse processo seja diferente em cada sistema, mas, por regra, por princípios gerais, é semelhante em todos os lugares, por exemplo, verificando se o trabalho do PoW foi executado em uma transação. A combinação da verificação das transações enviadas e seu registro subsequente pelos validadores fornece uma auditoria independente de todo o sistema.

Registro de transação

Uma transação / registro confirmado não é necessariamente irreversível. A irreversibilidade da gravação pode ser probabilística (por exemplo, um sistema baseado em PoW no qual é impraticável recalcular todas as transações registradas) ou sistemas que incluem "pontos de verificação" que devem ser atribuídos a cada transação. Os registros confirmados podem ser considerados imutáveis, mas aqueles que foram "pré-confirmados" podem ser cancelados. Os registros pré-confirmados permanecem inalterados após a superação do estado de transição de "pré-confirmado" para "confirmado".

Figura 2. Processamento de transação nos sistemas DLT

A Figura 2 descreve uma descrição esquemática do processo que ocorre durante o processamento da transação. Primeiro, o usuário cria uma transação e a envia para a rede. Cada nó verifica se a transação está em conformidade com as regras do protocolo. Se for considerado correto, o nó adiciona a transação à sua lista (mempool), onde todas as transações não confirmadas são armazenadas, aguardando para serem adicionadas à lista de transações confirmadas.

No estágio de processamento da transação, os nós selecionam aleatoriamente transações não confirmadas de seu pool de memórias e as combinam em uma lista de transações "pré-aprovadas". Em seguida, as transações serão verificadas de acordo com o algoritmo de consenso para oferecer essas transações a todos os outros participantes da rede. Os nós visualizarão as transações recebidas e seu conteúdo; se a transação passar na verificação, a transação será adicionada à lista do nó. As listas com transações de cada nó são enviadas para uma única e mais importante lista de transações confirmadas e serão consideradas concluídas.

No entanto, as transações confirmadas podem ser "canceladas" devido a uma transação alternativa, o que significa que, na fase de liquidação, as transações podem ser canceladas - nesse caso, elas retornam aos nós como transações não confirmadas, aguardando a criação de uma nova lista de transações. O tempo de processamento da transação no estágio "Liquidação" depende das configurações de um único sistema. Alguns sistemas implementam gravação instantânea de transações e sua irrevogabilidade, mas alguns protocolos têm uma conclusão "probabilística", no sentido de que as transações podem teoricamente ser canceladas. Na prática, no entanto, a probabilidade dessa ação diminui a cada nova transação adicionada, pois os custos dos nós associados ao PoW podem se tornar altos. Embora as transações estejam no estágio de "liquidação", elas não podem ser consideradas "concluídas".O processo de liquidação de transações aumenta a garantia de que as transações são listadas com precisão em todos os nós participantes e não armazenadas apenas nos nós locais, o que ajuda a evitar ataques de gastos duplos.

Alguns sistemas implementam um sistema de "ponto de verificação" para limitar a possibilidade de ataques de longo alcance. No caso deste ataque, o nó cria uma cadeia alternativa com suas transações pessoais (que são armazenadas apenas por ele), essas transações não aparecem na rede, mas são imediatamente enviadas aos nós no estágio de "liquidação" para forçar outros nós a substituí-los por suas transações locais. "Pontos de verificação" são blocos que nunca serão desfeitos ou substituídos. Como resultado dos pontos de controle, o "alcance" do ataque é reduzido. No entanto, os marcos aumentam o risco de um garfo.

Tabela 8. Propriedades da transação confirmada

Nível de dados

O nível do protocolo determina como o sistema funcionará e quais regras seguir. A camada de rede implementa os princípios subjacentes do protocolo. Juntas, a camada de protocolo e a rede formam a base da camada de dados, que se acumula ao longo do tempo à medida que as transações são gravadas na lista de registros confirmados.

Operações

O componente de operações inclui todos os processos pelos quais os participantes interagem com o sistema.

Fontes de dados

O processo de entrada está relacionado a uma fonte ou método de obtenção de dados para um protocolo. As fontes de dados podem ser internas ou externas, o que pode refletir a interação ativa dos usuários com o sistema, uma alteração no estado do protocolo causada por um processo interno do sistema ou recebida de fora (por exemplo, uma transação enviada por outro protocolo) ou um contrato inteligente.

Definimos fontes de entrada internas como qualquer registro ou transação criada pelo usuário ou devido ao resultado da interação do usuário com o protocolo. As fontes de entrada externas, por outro lado, são o resultado da entrada de outros sistemas que interagem com o protocolo, mas que, em princípio, são separados da plataforma subjacente (ou seja, são dependentes ou estão interagindo). Os protocolos híbridos permitem que os usuários transfiram transações usando os "canais de pagamento - canal de estado" a qualquer momento, no entanto, o desenvolvimento desses métodos ainda está no estágio inicial.

Tabela 9. Transações executáveis de software de formulários de entrada de dados

Nem todas as alterações no nível dos dados são um resultado direto da entrada interna ou externa. Algumas mudanças no sistema ocorrem devido à execução de instruções de código. Um exemplo impressionante são os contratos inteligentes. Ao executar o código do programa incorporado, o status da rede é alterado no protocolo, por exemplo, ocorre uma transação, que é registrada na lista de confirmados. Alguns sistemas DLT oferecem suporte apenas à linguagem de script (script). Por exemplo, o Bitcoin Script, funciona em uma linguagem de script simples que permite criar programas simples limitados. Tais sistemas são chamados - sem estado. Ethereum (Solidity), Tezos (Michelson) e EOS (WebAssembly) - esses sistemas oferecem suporte a linguagens de programação completas de Turing para o desenvolvimento de contratos inteligentes complexos, enquanto Bitcoin e Monero usam uma linguagem de script,o que permite operações limitadas.

Tabela 10. Propriedades das transações executadas por software A

execução real dos cálculos O

local onde o programa é executado determina onde os cálculos ocorrem. Como regra, o local de execução pode estar dentro da rede - dentro ou fora da cadeia (fora da rede). Os cálculos na cadeia são realizados em cada nó. Esse ambiente pode variar de uma máquina virtual simples, como uma linguagem de script ou ser complexo (EVM - Ethereum virtual machine), o que garante a execução de programas completos de Turing. Contratos inteligentes na cadeia são lançados por cada nó da rede e, portanto, são frequentemente chamados de "auto-execução".

A computação fora da cadeia é realizada em um ambiente externo ao protocolo. O evento que executa o código do programa ocorre na cadeia e os cálculos ocorrem em outro sistema, sem carregar a rede principal. Além disso, existe um sistema híbrido (híbrido) para iniciar aplicativos, por exemplo, Plasma no Ethereum. Ou, por exemplo, o Cosmos, onde a rede principal serve como o "centro", mas os próprios cálculos ocorrem em redes subsidiárias.

Tabela 11. Propriedades de execução de transação de software

Componente de log

Referências

A partir do momento em que os usuários começam a interagir com o sistema DLT, o log é atualizado com o tempo. No entanto, uma revista é uma abstração. Todos os processos que ocorrem no sistema DLT estão relacionados a um protocolo específico. Por exemplo, um protocolo focado em pagamentos eletrônicos deve conter informações sobre ativos pertencentes a usuários específicos. Por outro lado, um sistema DLT, que inclui contratos inteligentes, deve ter sua própria máquina virtual que implementa a execução do código do programa. Portanto, o conceito de uma revista é uma abstração.

Tipos de links

Existem quatro tipos diferentes de dados de origem: dados endógenos, exógenos, híbridos e auto-referenciados.

Links endógenos (internos) referem-se a dados que rastreiam informações sobre variáveis "nativas" do sistema. Por exemplo, no Bitcoin, uma variável de referência endógena é usada para rastrear o número de bitcoins que os usuários possuem em um determinado momento. Essa variável interna é atualizada à medida que o usuário envia e recebe bitcoins para outros endereços. Um link exógeno (externo) refere-se a dados que rastreiam informações sobre variáveis que existem fora do sistema. A referência híbrida refere-se a dados que possuem características endógenas e exógenas. Ainda existe um quarto tipo, que não é endógeno, nem exógeno e não híbrido: é um tipo de dados neutro ou vazio - é um link de auto-referência. Por exemplo, um contrato inteligente é apenas um pedaço de código,que pode ser realizado sob certas condições. Embora um contrato inteligente possa exigir informações sobre variáveis externas ou internas do sistema, o próprio código não possui um link interno para nada fora dele (um "link em branco").

Tabela 12. Tipos de links e seu significado

Framework: análise de sistemas DLT