Dominando Mecanismos de Consenso: 15 Formas Poderosas de Acordos Distribuídos em Criptomoedas

A indústria de criptomoedas é notória por sua capacidade de usar terminologia exótica para confundir pessoas não técnicas. Inferno, às vezes até as pessoas mais técnicas podem se perder no molho. A taxa absurda de inovação que ocorre na criptografia é um terreno fértil para novas ideias. Essas novas ideias exigem formas novas, porém familiares, de serem comunicadas. Uma das formas de comunicação mais usadas é através da formulação de terminologia como “PROOF-OF- ”. xyz Todo mundo está sempre tentando provar algo e isso é por um bom motivo, afinal, a própria essência do blockchain é “Não confie, verifique”. No entanto, em algum momento tudo se torna opressor. Hoje acabamos com isso! Ok, na verdade não, mas vamos dissecar um dos aspectos técnicos mais importantes sobre os quais toda a indústria é construída: Mecanismos de Consenso Este é um tópico muito denso que requer uma compreensão de muitos elementos técnicos diferentes; Vou tentar desmembrá-los à medida que avançamos e fornecer links/recursos para aqueles que desejam se aprofundar. A criptomoeda opera por meio de um sistema de computação em nuvem chamado DLT (Distributed Ledger Technology), como um Blockchain ou DAG (Directed Acyclic Graph). Esta tecnologia foi desenvolvida como uma solução para um “paradigma” computacional conhecido como , que explica a dificuldade de estabelecer comunicação segura em ambientes descentralizados. The Byzantine Generals Problem Basicamente, se 3 generais cercam uma cidade e querem capturá-la, eles devem atacar todos de uma vez. Qualquer menos do que todos os 3 e o plano falhará. Como esses generais podem se coordenar se há tanto risco envolvido em enviar uma mensagem? O mensageiro se perder, se atrasar, perder a mensagem, forjar uma mensagem falsa, ser pego pelo inimigo ou simplesmente mentir sobre isso. Na verdade, é uma leitura bastante estimulante para qualquer pessoa interessada; mas por uma questão de brevidade, devemos seguir em frente. Blockchains/DLTs são (supostamente) livros contábeis digitais imutáveis, transparentes e apenas anexos que fornecem uma garantia operacional de mostrar consistentemente apenas a verdade. Essas propriedades deram à tecnologia blockchain o apelido coloquial de “ ”. a máquina confiável Embora saibamos intuitivamente o que é confiança, defini-la não é uma tarefa simples. A confiança é a garantia de que os resultados futuros são confiáveis. É a capacidade de colocar fé em algo/alguém sem o medo, a incerteza ou a dúvida de que algo/alguém está fodendo com você. Confiar é a capacidade de tomar uma decisão, com alto grau de confiança, e não ter que se preocupar com o risco da contraparte. Os mecanismos de consenso são os veículos para estabelecer a verdade, evitando a não-verdade e, por sua vez, conquistando a confiança do usuário nas criptomoedas. O que é um mecanismo de consenso? No que se refere à criptografia, os mecanismos de consenso fornecem a funcionalidade dupla de garantias de segurança e regulamentação de recompensas. São sistemas/protocolos que são utilizados para pactuar uma única versão do histórico para toda a atividade da cadeia. Um código de conduta para estabelecer um acordo comum sobre o estado compartilhado, único e verdadeiro. Eles determinam:- quem verifica e confirma as transações que são enviadas para um bloco(s) blockchain.- como essa verificação e confirmação acontece- quem e como alguém é recompensado por seus esforços/contribuições É aqui que as coisas ficam um pouco complicadas: Os mecanismos de consenso não precisam apenas lidar com a lógica computacional fria e rígida da segurança do blockchain. Eles podem ser usados para expressar a chegada a um acordo de confiança em praticamente qualquer elemento social, técnico ou mecânico arbitrário. As nuances da arquitetura delicada por trás dos mecanismos de consenso são extremamente complexas… Complexidade computacional A quantidade de recursos e etapas necessárias para chegar ao resultado desejado (quanto mais rápido/curto, melhor) Tolerância ao erro No centro do consenso de qualquer rede computacional está a capacidade de manter as operações caso os participantes da rede abandonem ou parem de trabalhar (o que pode acontecer esporadicamente). Quanto maior a tolerância a falhas, mais fácil é burlar o sistema; quanto menor a tolerância, mais resiliente é o sistema. Portanto, se a tolerância a falhas de um sistema for de 51%, isso significa que o sistema pode continuar a operar enquanto 49% estiver comprometido. Se a tolerância for de 67%, isso significa que o sistema pode lidar com apenas 33% dos nós comprometidos. Resiliência A capacidade de continuar entregando resultados adequados em caso de atividade maliciosa (que pode acontecer por períodos prolongados de tempo) Vivacidade As garantias de que mesmo após algum imprevisto acontecer, a rede continuará operando com veracidade Trocas em Mecanismos: Não existe um único mecanismo universal para governar todos eles. Os mecanismos de consenso são radicalmente diferentes de acordo com sua aplicação. O trilema blockchain afirma que é impossível ter a presença de todas as 3 propriedades: segurança, escalabilidade e descentralização em um único sistema. Só pode haver algum grau de mistura entre 2 de 3 elementos. Com base em qual combinação está presente em um blockchain, cada mecanismo será diferente de acordo com: - desempenho - consistência, - escalabilidade, - eficiência Embora existam centenas, senão milhares de mecanismos diferentes no mercado hoje; existem dois tipos gerais de mecanismos de Consenso com base em sua lógica operacional, . Todas as outras variações serão apenas algum ajuste modular ou combinação desses dois. proof-of-work e proof-of-stake Agora que temos uma compreensão geral dos mecanismos de consenso; vamos analisar alguns deles: Isenção de responsabilidade - Nem toda “Prova-de-alguma coisa” tem as mesmas funções que as outras. - Nem todo mecanismo de consenso precisa ter “Proof-Of” em seu nome. - A tolerância a falhas bizantinas é um elemento de qualquer/todo mecanismo. POW - Prova de trabalho Muito Alta Descentralização: 51% Tolerância a falhas: protegendo o histórico do blockchain Caso de uso: Processo intensivo em recursos de extrema complexidade matemática que exige hardware dedicado. O consenso POW é alcançado através da contribuição de recursos computacionais para resolver problemas matemáticos de complexidade monstruosa. Aqui, os nós são chamados de mineradores e ganham suas recompensas por meio da emissão de novos tokens de rede. Os líderes das propostas de blocos são escolhidos por ordem de chegada, de acordo com quem conseguir resolver o problema matemático. Descrição: O próprio POW possui uma sub-regra integrada de “peso da corrente” ou “altura da corrente” e truncamento. Sempre que o POW está em execução, os mineradores estão construindo suas próprias versões do próximo bloco; no entanto, apenas um bloco será aceito. O que significa que a rede irá truncar/descartar todos os blocos não aceitos e sempre recalibrar para a versão da cadeia que é mais longa/pesada (em termos da quantidade de trabalho realizada nela). Este é considerado o modelo de consenso mais seguro/descentralizado devido à sua capacidade de resistir ao escrutínio do governo global. , , , Exemplos de POW - Bitcoin (BTC) Dogecoin (DOGE) Litecoin (LTC) Kaspa (KAS) PDV - Prova de aposta moderada-alta Descentralização: 67% Tolerância a falhas: protegendo o histórico do blockchain Caso de uso: O modelo mais popular para consenso. O conceito por trás deste é direto, os usuários bloqueiam/garantim seus tokens para participar. Nos modelos POS, há suprimentos circulantes fixos, o que significa que nenhum novo token é emitido como recompensa de bloco, as recompensas são obtidas por meio do acúmulo de taxas de transação. Além disso, ao contrário do POW, os modelos POS empregam corte de estacas para qualquer mau comportamento; no caso de comportamento malicioso/subversivo ser encontrado, o nó infrator terá aproximadamente 50% de sua participação perdida para a rede para redistribuição entre os nós justos. Comumente considerado menos seguro e mais centralizado do que o POW, no sentido de que os incentivos dos nós da rede são semelhantes aos sistemas financeiros legados; os jogadores com mais dinheiro têm uma chance melhor de possuir os nós da rede. Descrição: Outro elemento importante a não esquecer no POS é que, para se tornar um nó, há um requisito mínimo de participação. No exemplo do Ethereum, são 32 ETH. A desvantagem desse design é que um alto nível de atividade verdadeira é esperado para não perder o interesse; enquanto minimiza a acessibilidade potencial e, por sua vez, a contagem de descentralização. Além disso, o POS é conhecido por sofrer o problema de “rico ficando mais rico”, o consenso está enraizado principalmente apenas na quantia/valor em jogo; portanto, aqueles que têm mais ganharão mais e não darão aos outros uma chance justa. Além do anterior, a verdade de por que essa pontuação é mais baixa em descentralização do que POW é a resiliência contra os governos. Os governos podem, em teoria, caçar essas redes e forçá-las a encerrar as operações; POS é mais fácil de subverter em grande escala. No entanto, um dos principais benefícios do POS em relação ao POW é a eficiência energética. , , , , , , Exemplos de POS — Ethereum (ETH) Cardano (ADA) Tezos (TEZ) CELO (CELO) Polkadot (DOT) Avalanche (AVAX) ThorChain (RUNE) dPOS — Prova Delegada de Estaca Baixa Descentralização: ** 67% : Tolerância a falhas protegendo o histórico do blockchain Caso de uso: A adaptação mais popular do POS regular; A prova de participação delegada é uma tentativa de democratizar o acesso à participação nas operações e recompensas da rede. Apenas os maiores podem participar do processo de segurança, enquanto os detentores de tokens de menor porte “delegam” seus tokens aos nós operacionais; basicamente, eles votam com seus tokens, nunca os entregando ao nó real. Os modelos de consenso dPOS normalmente têm no intervalo de 21 a 101 nós que estão lidando com operações de rede. Esses operadores de rede são selecionados com base na quantidade de tokens que possuem em jogo. O maior benefício da variante dPOS é restringir a quantidade de nós; embora isso leve à centralização, também traz o benefício adicional de tempos de processamento mais rápidos. Descrição: , , , , Exemplos dPOS — Polygon (MATIC) , Tron (TRX) EOS (EOS) Lisk (LSK) Ark (ARK) Radix (XRD) LPOS - Prova de Participação Arrendada Baixa - Moderada Descentralização: 67% Tolerância a falhas: protegendo o histórico do blockchain Caso de uso: Esta é uma variação avançada do POS. Muito semelhante ao modelo de prova de participação delegada, a prova de participação alugada fornece a diferença técnica em; que no dPOS os nós da rede acumulam as recompensas e depois as distribuem aos seus delegadores; mas no LPOS, os usuários estão realmente emprestando seus tokens aos nós, portanto, eles possuem uma parte do peso dos nós e acumulam as recompensas diretamente, em vez de por meio do delegado. A desvantagem aqui é que, para executar o nó físico, é necessário um nível muito alto de conhecimento técnico e equipamento. Até agora, esta implementação foi utilizada apenas em um projeto. Descrição: Exemplos de LPOS — Ondas (WAVES) HPOS — Prova de participação híbrida (também chamada de prova de atividade) Moderada Descentralização: 51% Tolerância a falhas: protegendo o histórico do blockchain Caso de uso: como o nome pode sugerir, o HPOS é uma arquitetura criativa que utiliza os dois modelos básicos de consenso (POW + POS). Neste modelo, existem dois níveis de processos que ocorrem. No nível básico, os mineradores (assim como no POW) verificam e empacotam as transações em blocos. Em seguida, esses blocos pré-vetados são enviados para o mempool do segundo nível, onde os nós POS executam uma rodada extra de verificações nos blocos e os validam. Descrição: , Exemplos de HPOS — DASH (DASH) Decred (DCR) PPOS — Prova Pura de Estaca Muito Alta* (na verdade não) Descentralização: 67% Tolerância a falhas: protegendo o histórico do blockchain Caso de uso: Outra variação do POS. Novo em design quando comparado a outras variações porque é sem dúvida mais descentralizado (não). Esta variante não possui um mecanismo de punição; portanto, atores tecnicamente ruins podem agir mal e não sofrer. No entanto, esse design é extremamente baixo em sua barreira à entrada, apenas 1 único token é necessário para ingressar como um nó. Em teoria, isso é fácil de jogar porque um único ator pode fazer um ataque silencioso de Sybil distribuindo 1.000 tokens em 1.000 carteiras diferentes. Descrição: Exemplos de PPOS — Algorand (ALGO) POI - Prova de Importância Baixa-Moderada Descentralização: 67% Tolerância a falhas: protegendo o histórico do blockchain Caso de uso: Modelo baseado em reputação que é mais uma implementação de PDV. Difícil de ser aceito como um nó válido, fácil de ser expulso. Devo admitir que este é um pouco mais criativo em sua abordagem. A prova de importância utiliza dois fatores além da aposta; esses incluem: Descrição: 1. A atividade de rede dos nós de piquetagem *(em vez de apenas piquetar passivamente, eles devem contribuir para a velocidade do token na rede) 2. a qualidade da atividade dos nós (transações de spam não ajudarão) Exemplos de POI — NEM (XEM) POA - Prova de Autoridade Nenhuma - muito baixa' Descentralização: 51% Tolerância a falhas: protegendo o histórico do blockchain Caso de uso: Centralização é o nome do jogo aqui. O POA utiliza um valioso primitivo não financeiro para operar, a identidade. Ao usar a identidade, todos os participantes da rede operacional arriscam suas reputações para fazer parte do círculo de consenso. Onde quer que haja identidade, há centralização. No entanto, por terem pequenas quantidades restritas de operadoras conhecidas, as redes que usam POA têm um potencial de throughput extremamente alto. Definitivamente, esse é um mecanismo que você deseja sustentar qualquer blockchain de bens públicos, mas isso não impediu que os projetos o alavancassem. Descrição: não Exemplos de POA — VeChain (VET) pBFT — Tolerância prática a falhas bizantinas Baixa Descentralização: 67% Tolerância a falhas: Desenvolvimento da robustez de um mecanismo Caso de uso: Um componente de composição chave para a construção de outros mecanismos de consenso. Normalmente encontrado em redes permitidas, o pBFT funciona aproveitando a replicação de dados nos nós. Não é o modelo mais eficiente devido às restrições de comunicação inerentes, mas muito resiliente (obviamente a tolerância é alta em sistemas centralizados, os jogadores só podem culpar a si mesmos e seus amigos). Descrição: Exemplos de pBFT — Zilliqa (ZIL) {usa uma mistura de POW + pBFT} dBFT — Tolerância de falha bizantina delegada Baixa Descentralização: 51% Tolerância a falhas: Desenvolvimento da robustez de um mecanismo Caso de uso: Como é o caso de seu primo acima (pBFT), a tolerância a falhas bizantinas delegada é um elemento de composição para a criação de sistemas blockchain mais robustos. Por si só, o mecanismo pode ser usado para suportar comunicações distribuídas, no entanto, eles são limitados por restrições de comunicação que tornam os sistemas dBFT centralizados por padrão. Descrição: Exemplos de dBFT — NEO (NEO) POC — Comprovação de Capacidade/Compromisso Baixa Descentralização: 51% Tolerância a falhas: protegendo o histórico do blockchain Caso de uso: Reviravolta única nos mecanismos de consenso POW; em vez de utilizar unidades de processamento para resolver problemas constantemente; a prova de capacidade aproveita o espaço em disco/memória. O POC traça possíveis soluções para problemas futuros e os armazena no espaço vazio do disco dos mineradores. Não confundir com total inexistência de garimpo, pois o garimpo ainda existe; isso acontece apenas preventivamente (o que pode trazer riscos potenciais à segurança). Não é muito eficaz em grande escala devido à alta sensibilidade no caso de queda de um nó, o que requer uma nova plotagem de toda a rede e torna-se menos eficiente à medida que mais nós de mineração se juntam (eles exigem plotagem adicional que cria enormes atrasos no computadores alocando espaço em disco). Descrição: , , Exemplos de POC — Storj (STORJ) Chia (XCH) Signum (SIGNA) POH - Prova da História N/A Descentralização: N/A Tolerância a falhas: carimbo de data/hora e organização Caso de uso: Este não é um protocolo autônomo para construir um blockchain. POH é usado com, você adivinhou, POS, como uma técnica usada para transações de carimbo de data/hora usando um método de hash VRF (função aleatória verificável) que permite que blocos em um blockchain sejam processados e enviados para um mempool. Isso permite que uma rede continue as operações na capacidade máxima, independentemente do que possa estar acontecendo com qualquer nó individual em um determinado momento. Se um nó não enviou um bloco a tempo, isso não vai atrapalhar a produção do próximo bloco, porque o bloco atrasado será organizado em sua posição correta o mais rápido possível. Descrição: Exemplos de PDV — Solana (SOL) POETA — Prova do Tempo Decorrido Não Descentralização: 51% Tolerância a falhas: protegendo o histórico do blockchain Caso de uso: Este é um modelo extremamente centralizado para construir uma rede, principalmente porque é propriedade intelectual (IP) protegida por patentes e ninguém quer entrar em guerra com a Intel. No entanto, o design em si é brilhante. O POET é outro modelo que aproveita a lógica POS com uma mistura do princípio de consenso de Nakamoto da cadeia mais longa/pesada, junto com seus próprios conceitos adicionais de um cronômetro interno e “descanso”. Os nós do minerador são selecionados aleatoriamente e o mesmo nó não pode ser selecionado consecutivamente. Uma vez que um nó confirma um bloco, um cronômetro aleatório é colocado no nó e ele “adormece”. Enquanto está adormecido não utiliza nenhum recurso computacional; o que torna este modelo mais ecológico em termos de consumo elétrico do que outras variantes de POS. Descrição: Exemplo POET — HyperLedger Sawtooth POA - Comprovante de Acesso Baixa Descentralização: 51% Tolerância a falhas: proteção de armazenamento e dados Caso de uso: Uma versão aumentada do POW, Proof-of-Access é um algoritmo criado pelo projeto Arweave que usa uma técnica inteligente para verificar os blocos recebidos. Em vez de confiar apenas no bloco anterior, os mineradores usam algo chamado “bloco de recuperação” junto com um bloco anterior escolhido aleatoriamente. Os blocos de rechamada podem ser considerados como pontos confiáveis no histórico da cadeia que não requerem o armazenamento de todos os dados da cadeia. Isso cria um modelo leve para provar dados, resultando em recursos de armazenamento mais eficientes, menos desperdício de recursos computacionais e maior rendimento. Uma possível desvantagem desse modelo é que ele prefere nós mais antigos devido a seus arquivos históricos; nós mais novos não têm acesso aos mesmos dados arquivados e farão download apenas dos blocos de rechamada. O que em teoria cria uma hierarquia por idade. Descrição: Exemplos de POA — Arweave (AR) POREP - Prova de Replicação N/A Descentralização: 51% Tolerância a falhas: proteção de armazenamento e dados + computação em nuvem Caso de uso: Essa beleza de modelo é, na verdade, uma expansão de um modelo predecessor em armazenamento de dados (Proof-of-Space) com uma integração integrada de POW que prioriza a capacidade de espaço de armazenamento na rede/no espaço em disco do nó operacional . Existem elementos do mecanismo de consenso pBFT em que os dados que são adicionados à rede são replicados nos mineradores de rede. A engenhosidade do POREP é definida por sua capacidade de combater o vetor de ataque mais tortuoso da indústria de computação em nuvem descentralizada, conhecido como “ataque de geração”, pelo qual um nó de mineração paga para fazer upload de um documento e, em seguida, solicita infinitamente esse documento, cobrando taxas pelo fornecimento do armazenamento disso. Descrição: Exemplos de POREP — Filecoin (FIL) Essa é apenas uma pequena amostra de quanto trabalho incrível está realmente por aí. Mecanismos de consenso são o cerne da confiança de um sistema distribuído. O mecanismo dita as regras/leis pelas quais o sistema opera. Cada escolha no design de um sistema deve ser feita com extremo escrutínio, aplicar um mecanismo impróprio a um sistema causará dissonância cognitiva entre os usuários e os operadores de rede; por sua vez, causando uma perda de confiança. É impossível quantificar qual mecanismo é melhor que o outro; tudo é contextual e tudo é subjetivo. Com oportunidades infinitas à nossa frente, obrigado por ler Que sua jornada seja incrível & Seu portfólio seja abundante 🥂 Também publicado aqui.