Recompensas e penalidades no Ethereum 2.0 [Fase 0]
NewsDevelopersEnterpriseBlockchain ExplainedEvents and ConferencesPressboletins informativos
Assine a nossa newsletter.
Endereço de email
Nós respeitamos sua privacidade
HomeBlogCodefi Ativar
Recompensas e penalidades no Ethereum 2.0 [Fase 0]
por James Beck 2 de março de 2020Postado em 2 de março de 2020
Introdução
A ConsenSys Codefi está construindo o sistema operacional blockchain para comércio e finanças para ajudar os mercados globais a se moverem em direção ao “Finanças 2.0”. Uma parte crítica desse esforço é permitir a criação e o uso de ativos digitais nativos que incentivem redes descentralizadas ao máximo para servir de forma confiável como backbones para novos produtos e mercados financeiros. Ativar o “Ethereum 2.0” e a transição para a prova de participação está na frente e no centro para nós, e estamos felizes em começar a compartilhar nossa experiência, conhecimento e muito mais sobre esses tópicos, incluindo, aqui, a economia simbólica.
A enorme demanda no Ethereum 1.0 às vezes resultou em experiências indesejáveis do usuário, como longas esperas para que as transações fossem incluídas na cadeia e preços voláteis da taxa de transação (gás). Escalabilidade massiva – a capacidade de processar milhares de transações por segundo em vez das atuais 15 ou mais transações por segundo – há muito faz parte do plano da Ethereum.
Estamos agora na primeira fase – Fase 0 – do lançamento do Ethereum 2.0. Depois que todas as fases do 2.0 forem totalmente implementadas, o volume de transações aumentará drasticamente. Duas atualizações principais no código Ethereum tornariam isso possível: fragmentação e prova de aposta. Esta atualização resultará em uma rede com economia redesenhada, consenso e mecanismo de operação, que explicaremos em mais detalhes abaixo.
Motivação
Ethereum 1.0 é um blockchain de prova de trabalho: para cunhar um bloco, os mineiros resolvem um quebra-cabeça com uma probabilidade proporcional ao hashrate que eles têm disponível e inversamente proporcional à dificuldade na cadeia. Se a mineradora for bem-sucedida, ela receberá uma recompensa de 2 ETH mais taxas de transação. Isso é tudo. Ao examinar a dificuldade do último bloco, você pode estimar a taxa de hash da rede, o que, por sua vez, permitirá que você saiba quais são suas chances de obter o próximo bloco, permitindo que você preveja seus pagamentos.
Ethereum 2.0 é um pouco mais técnico neste departamento.
Se você chegou aqui e deseja apenas uma referência no verso do envelope, pule para a seção “Uma estimativa útil da emissão da rede”.
O objetivo deste documento é fornecer ao leitor uma visão geral da implementação da prova de aposta do Ethereum 2.0, bem como seu sistema de recompensas e penalidades. Dividiremos os incentivos em um resumo, com uma avaliação rápida do que poderia ser o ROI de uma aposta, dadas certas premissas. Finalizamos com um teaser de uma simulação que a equipe Codefi Staking-as-a-Service está construindo, para obter uma compreensão mais refinada deste assunto.
O Validador Honesto
Se você fizer um ou vários pagamentos para o contrato de depósito implantado na cadeia Eth1, acumulando um valor igual ou superior a 32 ETH, você pode se qualificar para ser um validador da cadeia Eth2 Beacon.
Não há limites de quanto ETH você pode adicionar à aposta de um validador. Há, no entanto, um limite superior – a saber, o equilíbrio efetivo, definido em 32 ETH – em qual é a quantidade real que conta para suas interações dentro da cadeia Beacon. Em outras palavras, seu saldo pode ser tão alto quanto 1000 ETH, mas suas recompensas e penalidades são uma função de seu saldo efetivo limitado a 32 ETH.
Por outro lado, se o seu validador for afetado por penalidades e seu saldo cair para ou abaixo de 16 ETH, ele aciona o que é chamado de saída forçada (ou involuntária).
O assim chamado validadores honestos estará atendendo clientes bem projetados, atendendo às especificações da cadeia Beacon, evitando penalidades por votação incorreta. Ou o que poderia ser pior, cortando por mau comportamento de protocolo.
É importante mencionar que receber uma penalidade não é o mesmo que ser cortado: O primeiro representa apenas uma diminuição no saldo do validador devido, por exemplo, a um voto errôneo (dentro de certos parâmetros) ou estar offline. Um validador que é pego incorrendo em um atestado slashable é retirado à força da cadeia Beacon, com seu saldo penalizado em cada época durante o período em que está na fila de saída.
Em Block Minting and Consensus in Ethereum 2.0
O fluxo da cadeia Beacon é construído em uma unidade de tempo chamada de fenda. Como uma pulsação – a cada 12 segundos – um validador é escolhido para ser o proponente do bloco. Assim que o bloco é cunhado e propagado, um comitê atestador de validadores vota para que este bloco faça parte da cadeia canônica.
O objetivo dos comitês na cadeia Beacon é distribuir os validadores, de modo que cada um possa votar uma vez por época (a cada 32 slots). Os validadores em comitês fofocam entre si, permitindo a agregação de atestados.
Se durante um slot não houver um bloco proposto, ele é identificado como um slot pulado. Nesta situação, outras propostas ou atestados são construídos no último bloco disponível de um slot anterior.
O proponente escolhe em qual bloco ele executará a transição de estado para o novo canônico cabeça da cadeia. Esta escolha é feita pelo algoritmo Escolha de garfo LMD GHOST: O procedimento seleciona a bifurcação sobre a qual há recursivamente o maior peso nos votos recebidos. Quando os validadores atestam esse bloqueio, eles estão, na verdade, votando a favor dessa escolha de fork.
A fim de fornecer finalidade ao blockchain, ou seja, a garantia de que o estado não pode ser revertido, validadores honestos aproveitam o Implementação Eth2 de Casper, o Gadget de Finalidade (FFG), fornecendo em seus atestados dois votos adicionais: Um para a última época justificada (fonte), e um para o limite de época mais recente (alvo).
Fonte: ConsenSys Codefi Analysis
No começo de cada época, os atestados são contados. Se houver uma supermaioria (dois terços), o último ponto de verificação de época justificado será adiantado no tempo e, sob certas regras, a finalização será alcançada para a época anterior ou para sua antecessora.
Se o sistema não atingiu a finalidade em uma série de épocas (4 pela especificação atual), todos os validadores na cadeia de beacon são atingidos com um penalidade de inatividade.
Há muito o que desempacotar aqui! Se você quiser explorar mais os detalhes, as melhores referências são as Papel Gasper (como em GHOST + Casper) (Buterin et al), o real especificações da cadeia na fase 0 (Fundação Ethereum), Fase 0 para humanos (Danny Ryan), e o explicador ethereum da cadeia de beacon que você precisa ler primeiro (Joseph Chow).
Recompensas e penalidades
Cortando
Ser cortado significa que o validador é forçado a sair a cadeia de beacon em um ponto no futuro, recebendo uma série de penalidades até que saia.
Existem três maneiras de um validador obter a condição cortada:
-
Sendo um proponente e assinar dois blocos de beacon diferentes para o mesmo slot.
-
Sendo um atestador e assinar um atestado que “envolve” outro.
-
Por ser um atestador e assinar dois atestados diferentes com o mesmo destino.
Em todos esses casos, o infrator precisa ser pego para que o processo de corte seja acionado. O validador de denúncias criará e propagará uma mensagem específica contendo a infração, para que um proponente a inclua em um bloco. Tanto o proponente quanto o denunciante terão direito a uma recompensa.
Não é totalmente óbvio na especificação, mas na Fase 0 apenas o proponente recebe a recompensa do denunciante – isso é, o proponente recebe toda a recompensa de corte (8/8 dele).
Fonte: ConsenSys Codefi Analysis
Premissas
-
Constante MIN_SLASHING_PENALTY_QUOTIENT = 32
-
Constante WHISTLEBLOWER_REWARD_QUOTIENT = 512
-
Constante PROPOSER_REWARD_QUOTIENT = 8
O infrator se torna um validador cortado e é atribuído a um conjunto de época extraível 36 dias (8.192 épocas) no futuro.
Além disso, o validador cortado recebe
-
UMA penalidade mínima no momento em que o proponente inclui a mensagem de denúncia em um bloco
-
Uma penalidade no começo de cada época, por perder os votos head / FFG, até que o validador deixe a fila de saída
-
UMA pena especial é aplicado a meio caminho entre o momento em que a mensagem de denúncia é incluída em um bloco e o momento em que o infrator cortado pode se retirar.
Esta penalidade especial é proporcional a quantos outros validadores também foram cortados durante o período. O máximo aplicado pode ser tão alto quanto o saldo efetivo de todo o infrator.
Fonte: ConsenSys Codefi Analysis
Premissas
-
Constante MIN_SLASHING_PENALTY_QUOTIENT = 32
-
Constante BASE_REWARD_FACTOR = 64
-
Constante BASE_REWARDS_PER_EPOCH = 4
-
Constante EFFECTIVE_BALANCE_INCREMENT = 1
Processamento de época
No começo de cada época (a cada 32 slots, exceto GENESIS), várias coisas acontecem, incluindo
-
Justificativa e finalização da cadeia
-
Atribuição de recompensas e penalidades aos atestadores
-
Atualização do registro do validador
-
A penalidade de corte especial (veja acima), e
-
Algumas atualizações finais (computando saldos efetivos, redefinições, etc)
Um validador precisa ter o ativo status na época anterior para receber recompensas e / ou penalidades. Até a sua saída, os validadores com barras entram neste processo também, onde serão penalizados apenas nas categorias correspondentes do FFG.
Se um validador esteve ativo na época anterior, mas não votou, vai pegar penalizado por não corresponder aos votos FFG. Os validadores não são cortados por estarem offline.
Fonte: ConsenSys Codefi Analysis
Premissas
-
Atraso de finalidade = época anterior – época finalizada
-
Saldo de atestado = Soma do saldo de atestador não cortado
-
Constante BASE_REWARD_FACTOR = 64
-
Constante BASE_REWARDS_PER_EPOCH = 4
-
Constante PROPOSER_REWARD_QUOTIENT = 8
-
Constante MIN_EPOCHS_TO_INACTIVITY_PENALTY = 4
-
Constante INACTIVITY_PENALTY_QUOTIENT = 2 ** 25
Fonte: ConsenSys Codefi Analysis
Uma estimativa útil da emissão da rede
Vamos usar nosso conhecimento recém-adquirido para produzir uma estimativa retroativa das recompensas e penalidades por uma época arbitrária. Queremos torná-lo simples e começar com apenas dois parâmetros.
Fonte: ConsenSys Codefi Analysis
O primeiro é autoexplicativo, enquanto o último pode ser visto como a probabilidade de um validador escolhido aleatoriamente ser capaz de participar da cadeia de beacon (sua máquina host está ligada), ter uma conexão de Internet funcionando ou outros fatores.
Se fizermos a suposição de que todo validadores na cadeia de beacon têm seu equilíbrio e equilíbrio efetivo igual a 32 ETH, e usamos a probabilidade online acima, temos
Fonte: ConsenSys Codefi Analysis
Agora estamos em condições de calcular as seguintes recompensas e penalidades para cada validador
Fonte: ConsenSys Codefi Analysis
É necessário trabalhar um pouco para os dois últimos incentivos: Os atestadores de bloco são considerados os validadores online em um slot, uniformemente distribuídos ao longo da época; Para o incentivo do atestador, devemos converge a série geométrica que obtemos após definir a árvore de probabilidade do valor esperado, uma vez que esta recompensa é inversamente proporcional à diferença de slots que está incluída no atestado.
Vemos que o incentivo do proponente supera em grande quantidade os demais valores. Lembre-se de que um proponente entre todos os validadores na cadeia de beacon é escolhido em cada slot, tornando as chances de se tornar um menor conforme a aposta total aumenta. Em outras palavras, dentro de uma época, apenas 32 de N validadores tornam-se proponentes.
Observe, também, que não faremos quaisquer suposições ou cálculos sobre validadores cortados e seus denunciantes, nem sobre o atraso de inatividade.
Se nós multiplicar os valores individuais obtidos pela respectiva quantidade de validadores online ou offline, e se os somamos, chegamos a uma estimativa do valor gerado a partir das condições iniciais dadas.
Fonte: ConsenSys Codefi Analysis
Ou seja, ao redor 1,25 ETH por época (6,4 minutos) de uma aposta total de 500.000 ETH e assumindo uma probabilidade online de 95%.
É tentador calcular e mapear – com 95% de probabilidade online – a quantidade de ETH criada durante uma época em diferentes estacas.
Fonte: ConsenSys Codefi Analysis
Empacotando
Devemos então seguir em frente e multiplicar este valor que obtivemos por época, para dar um anual estimativa?
Antes de responder sim, vamos considerar os seguintes fatores:
Equilíbrio
Existem muitas maneiras diferentes pelas quais os equilíbrios afetam a criação de ETH em cada época. Por exemplo, se um validador recebe recompensas além do equilíbrio efetivo cap (ou seja, 32 ETH), todos esses fundos excedentes não influenciarão os cálculos na próxima época. Além disso, devido ao histerese aplicado aos saldos efetivos, há de fato uma porção de ETH “perdida” em cada validador.
Considere também o que acontece quando os validadores são ejetado por não manter o valor mínimo (16 ETH), quando os validadores são ativado como novos depósitos serão pagos ao contrato de depósito Eth1, ou quando os stakers acionam saídas voluntárias.
Cortando
As operações de corte serão, por um bom tempo, não triviais para modelar. Para começar, os desenvolvedores de clientes Eth2 e serviços de piquetagem precisam aprender como evitar as condições de serem cortadas. Por outro lado, só podemos adivinhar qual será a proporção de jogadores honestos no sistema; Ou se suas ofensas serão descobertas, transmitidas e incluídas em blocos.
Probabilidades
Já tocamos no assunto da proporção de jogadores honestos e das chances de publicação para um denunciante. Vamos pensar, também, nas diferentes maneiras como podemos medir e estimar que um nó estará online, bem conectado e funcionando corretamente. Que seus atestados serão agregados e incluídos no prazo, ou obter a visualização do slot que a maioria está vendo.
A cadeia de beacon é um sistema adaptativo complexo. Mesmo se alcançarmos um entendimento perfeito de cada uma de suas partes individuais, não é garantido que obteremos um entendimento perfeito do todo.
O domínio de qualquer assunto começa escolhendo metodologias e ferramentas adequadas para a tarefa. De modelagem e simulação aspectos do validador e suas interações dentro da cadeia – sob uma série de condições iniciais, suposições e restrições – devemos ser capazes de construir uma visão sobre as complexidades desta implementação de prova de participação.
Reconhecimentos
Escrito por Herman Junge, arquiteto e líder técnico da plataforma Staking-as-a-Service da ConsenSys Codefi.
Agradecemos Joseph Chow, Ben Edgington, Sylvain Laurent, Diederik Protolambda Loerakker, Tim Lowe, Danny Ryan, Alex Stokes e Kuhan Tharmananthar pelos comentários sobre o manuscrito.
Quer saber mais sobre piquetagem como serviço? Entre em contato com a ConsenSys Codefi aqui.
Redes descentralizadasDeFiEthereum 2.0Industry InsightNewsletterSubscreva nossa newsletter para obter as últimas notícias da Ethereum, soluções empresariais, recursos para desenvolvedores e muito mais. Endereço de e-mail