Um Guia do Bitcoiner para Prova de Participação

Este é um editorial de opinião de Scott Sullivan.

Normalmente, os Bitcoiners não se importam muito com o que acontece na terra do Shitcoin, mas agora que o Ethereum se fundiu para proof-of-stake (PoS), tem havido bastante burburinho no Twitter do Bitcoin. É claro que a própria rede Bitcoin permanecerá inalterada, mas acho que ainda vale a pena prestar atenção a essa “atualização”. Agora que o Ethereum se limpou das externalidades “sujas” e “desperdiçadas” associadas à prova de trabalho (PoW), podemos esperar que as luvas saiam na guerra narrativa, e acho que os Bitcoiners devem estar prontos para revidar.

Aprender como o PoS funciona é uma boa maneira de internalizar as diferenças e compensações entre PoW e PoS. Mesmo que eu tenha visto todos os argumentos de alto nível contra o PoS antes – que o PoS é mais autorizado, centralizador e oligárquico – admito que, sem analisar os detalhes, tudo parecia meio confuso. Ao mergulhar de fato no algoritmo PoS, podemos começar a ver como todas essas propriedades emergem naturalmente dos primeiros princípios. Portanto, se você está curioso sobre como o algoritmo PoS funciona e por que ele leva a esses tipos de propriedades, continue lendo!

Resolvendo o problema do gasto duplo

Vamos começar com uma rápida recapitulação do problema que estamos tentando resolver. Suponha que temos um grande grupo de participantes em uma rede de criptomoedas tentando manter um registro descentralizado. Aqui está o problema: como novas transações podem ser adicionadas ao livro-razão de todos, de modo que todos concordem sobre quais novas transações são “corretas”? O PoW resolve esse problema de forma bastante elegante: as transações são agrupadas em blocos, em que cada bloco exige uma grande quantidade de trabalho computacional para ser produzido. A quantidade de trabalho necessária pode aumentar ou diminuir para garantir que os blocos sejam produzidos a cada dez minutos em média, dando a cada novo bloco tempo suficiente para se propagar por toda a rede antes que o próximo seja criado. Qualquer ambiguidade é resolvida selecionando a cadeia com mais trabalho, e o gasto duplo é evitado devido à necessidade de pelo menos 51% do hashpower global para que um bloco de gasto duplo seja atualizado.

Mas suponha agora queremos jogar fora o insight chave de Satoshi Nakamoto que tornou tudo isso possível em primeiro lugar. Afinal, esses ASICs irritantes são barulhentos e irritantes, e consomem mais energia do que todos os jatos particulares de George Soros, Bill Gates e Hillary Clinton juntos. Existe alguma maneira de concordarmos inequivocamente sobre quais transações são verdadeiras apenas discutindo?

A prova de participação da Ethereum propõe resolver esse problema usando dois ingredientes principais. A primeira é fazer “blocos de checkpoints” especiais de vez em quando, cujo objetivo é dar garantia a todos na rede sobre a “verdade” do sistema em vários momentos. A criação de um posto de controle requer uma maioria de dois terços de votos por aposta, portanto, há alguma garantia de que a maioria dos validadores concordou sobre o que realmente era a verdade naquele momento. O segundo ingrediente é punir os usuários por adicionar ambiguidade à rede, um processo conhecido como “slashing”. Por exemplo, se um validador criasse um fork ou votasse em uma sidechain mais antiga (semelhante a um ataque de 51%), sua participação seria reduzida. Os validadores também podem ser cortados por inatividade, mas não tanto.

Isso nos leva ao nosso primeiro princípio por trás do PoS, que é que o PoS é baseado em um sistema de incentivo negativo (baseado em penalidades).

Isso contrasta fortemente com o Bitcoin e a prova de trabalho, que é um sistema de incentivo positivo (baseado em recompensas). No Bitcoin, os mineradores podem tentar quebrar as regras – blocos mal formatados, transações inválidas e assim por diante – mas esses blocos serão ignorados por nós completos. O pior cenário é um pouco de energia desperdiçada. Os mineradores também são livres para construir em blocos mais antigos, mas sem 51% do poder de hash, essas cadeias nunca serão alcançadas, novamente apenas desperdiçando energia. Qualquer minerador que participe dessas ações, intencionalmente ou não, não precisa se preocupar em perder seus bitcoins acumulados ou máquinas de mineração, mas não receberá novas recompensas. Em vez de viver com medo, os mineradores de bitcoin podem errar ao agir e arriscar.

O mundo é um lugar muito diferente para validadores que vivem na terra do Ethereum. Em vez de trabalhar duro e ser recompensado por adicionar segurança à rede, os validadores não fazem nenhum trabalho real, mas devem ter cuidado para que seu nó nunca se comporte mal, para não ver suas economias queimarem. Se alguma mudança proposta fosse feita na rede, o primeiro instinto de um validador seria cumprir o que todos os outros estivessem fazendo, ou então correr o risco de ser cortado. Ser um validador é como pisar em ovos todos os dias.

(Fonte)

A propósito, viver sob um negativo sistema de incentivo é um dos, ahem, “benefícios” da prova de participação, de acordo com o cofundador da rede Ethereum, Vitalik Buterin, Perguntas frequentes:

(Fonte)

Então, como o corte realmente funcionaria em um nível técnico? Não precisaríamos primeiro criar uma lista de todos os validadores, para ter algo para cortar em primeiro lugar? A resposta é sim. Para se tornar um validador no Ethereum, é preciso primeiro mover o ETH para um endereço especial de “staking”. Essa lista não é apenas necessária para reduzir, mas também para votar, já que uma maioria de dois terços é necessária para os blocos de checkpoint.

Existem algumas implicações interessantes em manter uma lista de todos os validadores o tempo todo. Quão difícil é aderir? Quão difícil é sair? Os validadores podem votar no status de outros validadores?

Isso nos leva ao nosso segundo princípio por trás do PoS, que é que o PoS é um sistema com permissão.

O primeiro passo para se tornar um validador é depositar algum ETH em um endereço de staking especial. Quanto ETH? O mínimo exigido é 32 ETH, ou cerca de US$ 50.000 no momento da redação deste artigo. Para contextualizar, um equipamento de mineração de bitcoin decente normalmente custa milhares de dólares de um dígito, e um minerador doméstico pode começar com um único S9 por algumas centenas de dólares. Para ser justo, a alta taxa de entrada do ETH tem uma justificativa técnica, uma vez que uma aposta maior significa menos validadores, o que diminui a largura de banda.

Então a taxa de depósito é alta, mas pelo menos qualquer pessoa que possua 32 ETH pode entrar ou sair a qualquer momento, certo? Não exatamente. Existem riscos de segurança se grandes coalizões de validadores todos entrassem ou saíssem ao mesmo tempo. Por exemplo, se a maioria da rede saísse de uma vez, eles poderiam gastar duas vezes um bloco finalizado repetindo um fork no qual nunca saíram, sem serem cortados em nenhuma das cadeias. Para mitigar esse risco, as rampas de entrada e saída têm um limite de taxa de transferência integrado. Atualmente, esse limite está definido como max(4,|V|/65536) validadores por época (a cada 6,4 minutos), e é o mesmo para entrada e saída. Isso se traduz aproximadamente em um conjunto completo de validadores a cada dez meses.

A propósito, embora atualmente seja possível para os validadores publicar uma transação de “saída” e parar de validar, o código para realmente sacar fundos ainda não foi escrito. Parece um pouco com “Hotel Califórnia”…

(Fonte)

Há um último ponto sobre os incentivos por trás da aprovação novos validadores. Suponha que você seja acionista de uma empresa grande e estável que paga dividendos regulares a cada trimestre. Faria sentido dar novas ações de graça? Claro que não, pois isso diluiria os dividendos de todos os acionistas existentes. Existe uma estrutura de incentivo semelhante no PoS, pois cada novo validador dilui a receita de todos os validadores existentes.

Em teoria, os validadores poderiam simplesmente censurar cada transação que adiciona um novo validador; no entanto, na prática, acho que uma abordagem tão contundente seria improvável. Isso seria muito perceptível e destruiria a imagem de “descentralização” do Ethereum da noite para o dia, potencialmente derrubando o preço. Eu acho que uma abordagem mais sutil seria usada em vez disso. Por exemplo, as regras podem mudar lentamente ao longo do tempo, tornando mais difícil se tornar um validador, com desculpas oferecidas como “segurança” ou “eficiência”. Quaisquer políticas que enriqueçam os validadores existentes às custas de novos validadores teriam ventos financeiros a favor, sejam falados em voz alta ou não. Podemos começar a ver por que o PoS tenderia para a oligarquia.

(Fonte)

Visão geral do algoritmo de Casper h2>

Agora que conhecemos a estratégia de alto nível por trás do PoS, como o algoritmo realmente funciona? As principais ideias por trás de checkpoints e cortes foram apresentadas em um algoritmo chamado Casper, então vamos começar lá. O próprio Casper não especifica nada sobre como produzir blocos, mas fornece uma estrutura de como sobrepor uma estratégia de checkpoint/slashing em cima de alguma árvore de blockchain já existente.

Primeiro, alguma constante arbitrária (C) é escolhido para ser o número do “espaço de checkpoint”, que determina quantos blocos ocorrem entre os checkpoints; por exemplo, se C=100, os pontos de verificação ocorreriam nos blocos 0, 100, 200 e assim por diante. Em seguida, todos os nós votam em qual bloco de checkpoint deve ser o próximo checkpoint “justificado”. Em vez de votar em blocos únicos isoladamente, os validadores realmente votam em pares de checkpoints (s,t), que ligam algumas fontes de checkpoints previamente justificadas a algum novo checkpoint alvo “t”. Uma vez que um link de checkpoint (s,t) obtém uma maioria de dois terços de votos por stake, então “t” se torna um novo checkpoint justificado. O diagrama abaixo mostra um exemplo de árvore de pontos de verificação:

(Fonte)

Neste diagrama, o h(b) A função está se referindo à “altura do checkpoint”, por exemplo, o múltiplo de 100 do bloco. Você deve ter notado que nem todo centésimo bloco é necessariamente justificado, o que pode acontecer se a votação falhar em uma determinada altura. Por exemplo, suponha que na altura 200 dois pontos de verificação separados receberam 50% dos votos. Como votar duas vezes é uma ofensa passível de corte, o sistema ficaria “travado” a menos que alguns validadores reduzissem voluntariamente sua própria participação para obter uma votação de dois terços. A solução seria que todos “pulassem” o checkpoint 200 e “tentassem novamente” no bloco 300.

Só porque um checkpoint é justificado, não significa que ele foi finalizado. Para que um checkpoint conte como finalizado, ele deve ser imediatamente seguido por outro checkpoint justificado na próxima altura possível. Por exemplo, se os checkpoints 0, 200, 400, 500 e 700 fossem todos justificados e vinculados, apenas o checkpoint 400 contaria como”finalizado”, pois é o único imediatamente seguido por outro checkpoint justificado.

Como a terminologia é muito precisa, vamos recapitular nossas três categorias. Um “ponto de verificação” é qualquer bloco que ocorre na altura C*n, portanto, se C=100, todos os blocos com altura 0, 100, 200, 300 e assim por diante seriam todos pontos de verificação. Mesmo se vários blocos fossem criados na altura 200, ambos seriam “pontos de verificação”. Um ponto de verificação é então “justificado” se for o bloco raiz na altura 0 ou se dois terços dos validadores votaram para criar um link entre algum ponto de verificação previamente justificado e o ponto de verificação atual. Um ponto de verificação justificado é então “finalizado” se for vinculado a outro ponto de verificação justificado na próxima altura possível. Nem todo checkpoint necessariamente se torna justificado e nem todo checkpoint justificado necessariamente se torna finalizado, mesmo na cadeia final.

Regras de corte do Casper

As regras de corte no Casper são projetadas de tal forma que é impossível para que dois checkpoints finalizados existam em duas bifurcações separadas, a menos que pelo menos um terço dos validadores infringiu as regras de corte.

Em outras palavras, apenas os pontos de verificação finalizados devem ser contados como blocos de “verdade” inequívocos. É até possível que dois checkpoints justificados ocorram em ambos os lados de uma bifurcação, mas não dois checkpoints finalizados. Também não há garantia sobre quando ou onde o próximo checkpoint finalizado ocorrerá, apenas que, se ocorrer uma divisão de cadeia, você deve sentar e esperar até que um bloco finalizado apareça em algum lugar, e quando isso acontecer, você saberá que é o “ correta”.

Existem duas regras de barra no Casper que impõem essa propriedade:

(Fonte)

A primeira regra proíbe qualquer pessoa de votar duas vezes em checkpoints com a mesma altura de alvo, então se um validador votar em dois blocos de checkpoint diferentes com altura de alvo 200, isso seria uma ofensa passível de corte. O objetivo desta regra é evitar que a cadeia se divida em dois checkpoints justificados diferentes com a mesma altura, pois isso exigiria 2/3 + 2/3=4/3 do total de votos do validador, implicando que pelo menos um terço dos validadores quebrou as regras de corte. No entanto, como vimos anteriormente, é possível que pontos de verificação justificados “pulem” certas alturas de blocos. O que impede uma cadeia de se dividir em diferentes alturas de alvo? Por exemplo, o checkpoint 200 não poderia se bifurcar em checkpoints justificados em 300 e 400 sem que ninguém fosse cortado?

É aí que entra a segunda regra, que basicamente impede os validadores de “sandwich” votos dentro de outros votos. Por exemplo, se um validador votou em 300→500 e 200→700, isso seria uma ofensa passível de redução. No caso de uma divisão de cadeia, uma vez que uma ramificação vê um ponto de verificação finalizado, torna-se impossível para a outra ramificação ver um ponto de verificação justificado posteriormente, a menos que pelo menos um terço dos validadores infringiu a regra #2.

Para ver o porquê, suponha que o blockchain tenha se bifurcado em pontos de verificação justificados 500→800 e 500→900, então em algum ponto a primeira cadeia viu um ponto de verificação finalizado com o link 1700→1800. Como 1700 e 1800 só podem ser justificados no fork #1 (assumindo que ninguém quebrou a primeira regra de corte), a única maneira que o fork #2 poderia ver um checkpoint justificado após 1800 é se houvesse algum link votado entre as alturas H<1700 e h>1800. Mas como essa votação”sanduíche”o link 1700→1800 e exige uma votação de dois terços, e a votação 1700→1800 já foi aprovada com uma votação de dois terços, então pelo menos um terço dos validadores precisaria quebrar a regra # 2. O artigo de Casper tem um belo diagrama demonstrando essa propriedade:

(Fonte)

E é isso, basta seguir o Casper regras e você é bom!

(Fonte)

Parece bem simples, certo? Tenho certeza de que o PoS só usaria o slashing como último recurso absoluto para manter o consenso, e não como um mecanismo extorsionário para pressionar os validadores a se comportarem de uma certa maneira… certo?

(Fonte)

Isso nos leva ao nosso terceiro princípio por trás do PoS: não há regras. As “regras” são o que todo mundo diz que são.

(Fonte)

Um dia seu nó pode estar seguindo tecnicamente todos os mandamentos de Casper ao pé da letra, e no dia seguinte suas economias poderiam ser cortadas porque você estava fazendo algo que todo mundo não gostava. Aprovou uma transação “team red” aquela vez? Amanhã, a maioria do “time azul” pode acabar com você. Ou talvez você tenha feito o oposto e omitido muitas transações “team red”? Amanhã a maioria do “time vermelho” pode te cortar por censura. A capacidade de cortar vai muito além do escopo limitado da censura do OFAC (Office of Foreign Assets Control). O PoS é como um impasse mexicano ininterrupto, onde a ameaça implícita de cortar está sempre presente.

(Fonte)

Eu não ficaria surpreso se em um hard fork contencioso, ambos os lados codificassem as regras de validação do outro fork, apenas no caso de eles quererem punir qualquer um que se juntou ao lado “errado”. Claro, esta seria uma opção nuclear e, como armas nucleares, cada lado só pode optar por atacar em retaliação. Eu diria que a maioria dos validadores individuais são neutros, pois priorizam a autopreservação financeira sobre o autossacrifício político, mas podem tomar um lado se sentirem que essa é a atitude correta para evitar ser cortado.

Que horas são?

Agora que sabemos o básico sobre checkpoints e cortes, podemos passar para o algoritmo real usado no Ethereum, chamado Gasper. Esta é uma junção de Casper, que já abordamos, e GHOST, uma estratégia para selecionar a “melhor” cadeia de blocos entre os checkpoints.

A primeira coisa a entender sobre Gasper é o próprio tempo é a principal variável independente. O tempo do mundo real é dividido em unidades de doze segundos chamadas “slots”, onde cada slot contém no máximo um bloco. Esses slots formam grupos maiores chamados “épocas”, onde cada época se refere a um ponto de verificação. Cada época contém 32 slots, tornando-os 6,4 minutos de duração.

Vale a pena notar que esse paradigma inverte a relação causal entre tempo e produção de blocos quando comparado ao PoW. No PoW, os blocos são produzidos porque um hash válido foi encontrado, não porque passou tempo suficiente. Mas em Gasper, os blocos são produzidos porque já passou tempo suficiente no mundo real para chegar ao próximo slot. Eu só posso imaginar os bugs de tempo complicados que tal sistema pode encontrar, especialmente quando não é apenas um programa rodando em um computador, mas dezenas de milhares de computadores tentando rodar em sincronia em todo o mundo. Felizmente, os desenvolvedores do Ethereum estão familiarizados com as falsidades que os programadores acreditam sobre o tempo.

Agora suponha que você esteja iniciando um nó validador e sincronizando o blockchain pela primeira vez. Só porque você observou que certos blocos referenciavam certos timestamps, como você poderia ter certeza de que esses blocos foram realmente produzidos naqueles momentos? Como a produção de blocos não requer nenhum trabalho, um grupo malicioso de validadores não poderia simular um blockchain totalmente falso desde o primeiro dia? E se você visse duas blockchains concorrentes, como você saberia qual é a verdadeira?

Isso nos leva ao nosso quarto princípio por trás do PoS, que é que o PoS depende da verdade subjetiva.

Ali simplesmente não há uma maneira objetiva de escolher entre duas blockchains concorrentes, e qualquer novo nó na rede deve, em última análise, confiar em alguma fonte de verdade existente para resolver qualquer ambiguidade. Isso contrasta significativamente com o Bitcoin, onde a cadeia “verdadeira” é sempre aquela com mais trabalho. Não importa se mil nós estão lhe dizendo a cadeia X, se um único nó transmite a cadeia Y e contém mais trabalho, então Y é a blockchain correta. O cabeçalho de um bloco pode provar seu próprio valor, eliminando completamente a necessidade de confiança.

(Fonte)

Contando com verdade subjetiva, PoS reintroduz a necessidade de confiança. Agora, admito, talvez seja um pouco tendencioso, então, se você quiser ler o outro lado, Buterin escreveu um ensaio contendo suas opiniões aqui. Admito que, na prática, uma divisão de cadeia não parece tão provável, dadas as regras do Casper, mas, independentemente disso, fico tranqüilo sabendo que isso nem é uma possibilidade no Bitcoin.