O Conhecimento ao Alcance de Todos!

O QUE É A ETHEREUM?

O que é a Ethereum? Parte II

Ethereum é a base para uma nova era da internet:

Parte 2

Novo na Ethereum? Você está no lugar correto. Vamos começar com a imagem geral.
Uma internet onde o dinheiro e os pagamentos são embutidos.

PARTE II

 

Qual é a finalidade das taxas?

Ethereum é uma linguagem Turing completa. (Em suma, uma máquina de Turing é uma máquina que pode simular qualquer algoritmo de computador (para quem não está familiarizado com máquinas de Turing, verifique isto e isto ). Isso permite loops e torna o Ethereum suscetível ao problema de parada , um problema no qual você não pode determinar se um programa será executado infinitamente ou não. Se não houvesse taxas, um agente malicioso poderia facilmente tentar interromper a rede executando um loop infinito dentro de uma transação, sem qualquer repercussão. Assim, as taxas protegem a rede de ataques deliberados.

Você pode estar pensando: “por que também temos que pagar pelo armazenamento?” Bem, assim como a computação, o armazenamento na rede Ethereum é um custo que toda a rede deve assumir.

Transação e mensagens

No sentido mais básico, uma transação é uma instrução assinada criptograficamente que é gerada por uma conta de propriedade externa, serializada e enviada para o blockchain.

Existem dois tipos de transações: chamadas de mensagens e criações de contratos (ou seja, transações que criam novos contratos Ethereum).

Todas as transações contêm os seguintes componentes, independentemente do tipo:

  • nonce : uma contagem do número de transações enviadas pelo remetente.
  • gasPrice : o número de Wei que o remetente está disposto a pagar por unidade de gás necessária para executar a transação.
  • gasLimit : a quantidade máxima de gás que o remetente está disposto a pagar para executar esta transação. Esse valor é definido e pago antecipadamente, antes que qualquer cálculo seja feito.
  • para : o endereço do destinatário. Em uma transação de criação de contrato, o endereço da conta do contrato ainda não existe e, portanto, um valor vazio é usado.
  • valor : a quantidade de Wei a ser transferida do remetente para o destinatário. Em uma transação de criação de contrato, esse valor serve como saldo inicial na conta de contrato recém-criada.
  • v, r, s : usado para gerar a assinatura que identifica o remetente da transação.
  • init (existe apenas para transações de criação de contrato): Um fragmento de código EVM que é usado para inicializar a nova conta de contrato. O init é executado apenas uma vez e, em seguida, é descartado. Quando init é executado pela primeira vez, ele retorna o corpo do código da conta, que é a parte do código que está permanentemente associada à conta do contrato.
  • data (campo opcional que existe apenas para chamadas de mensagem): os dados de entrada (ou seja, parâmetros) da chamada de mensagem. Por exemplo, se um contrato inteligente serve como um serviço de registro de domínio, uma chamada para esse contrato pode esperar campos de entrada, como domínio e endereço IP.
  • Aprendemos na seção “ Contas ” que as transações – tanto chamadas de mensagens quanto transações de criação de contratos – são sempre iniciadas por contas de propriedade externa e enviadas ao blockchain. Outra maneira de pensar sobre isso é que as transações são o que conecta o mundo externo ao estado interno de Ethereum.

    Mas isso não significa que os contratos não podem se comunicar com outros contratos. Os contratos que existem no âmbito global do estado da Ethereum podem falar com outros contratos no mesmo âmbito. A maneira como eles fazem isso é por meio de “mensagens” ou “transações internas” para outros contratos. Podemos pensar em mensagens ou transações internas como sendo semelhantes a transações, com a principal diferença de que NÃO são geradas por contas de propriedade externa. Em vez disso, eles são gerados por contratos. São objetos virtuais que, ao contrário das transações, não são serializados e existem apenas no ambiente de execução Ethereum.

    Quando um contrato envia uma transação interna para outro contrato, o código associado existente na conta do contrato do destinatário é executado.

    Uma coisa importante a observar é que as transações ou mensagens internas não contêm um gasLimit. Isso ocorre porque o limite de gás é determinado pelo criador externo da transação original (ou seja, alguma conta de propriedade externa). O limite de gás que a conta de propriedade externa define deve ser alto o suficiente para realizar a transação, incluindo quaisquer sub-execuções que ocorram como resultado dessa transação, como mensagens de contrato a contrato. Se, na cadeia de transações e mensagens, a execução de uma mensagem específica ficar sem gás, a execução dessa mensagem será revertida, junto com quaisquer mensagens subsequentes acionadas pela execução. No entanto, a execução pai não precisa ser revertida.

    Blocos

    No Ethereum, um bloco consiste em:

    • cabeçalho do bloco
    • informações sobre o conjunto de transações incluídas naquele bloco
    • um conjunto de outros cabeçalhos de bloco para os ommers do bloco atual .

    Ommers explicado

    Devido à forma como o Ethereum é construído, os tempos de bloqueio são muito mais baixos (~ 15 segundos) do que os de outras cadeias de blocos, como Bitcoin (~ 10 minutos). Isso permite um processamento de transações mais rápido. No entanto, uma das desvantagens de tempos de bloco mais curtos é que soluções de bloco mais concorrentes são encontradas pelos mineradores. Esses blocos concorrentes também são chamados de “blocos órfãos” (ou seja, os blocos minerados não entram na cadeia principal).

    O objetivo dos ommers é ajudar a recompensar os mineiros por incluir esses blocos órfãos. Os ommers que os mineiros incluem devem ser “válidos”, ou seja, dentro da sexta geração ou menor do bloco atual. Depois de seis filhos, blocos órfãos obsoletos não podem mais ser referenciados (porque incluir transações mais antigas complicaria um pouco as coisas).

    Os blocos de Ommer recebem uma recompensa menor do que um bloco completo. No entanto, ainda há algum incentivo para que os mineiros incluam esses blocos órfãos e colham uma recompensa.

    Cabeçalho do bloco

    Um cabeçalho de bloco é uma parte do bloco que consiste em:

    • parentHash : um hash do cabeçalho do bloco pai (isso é o que torna o conjunto do bloco uma “cadeia”)
    • ommersHash : um hash da lista de ommers do bloco atual
    • beneficiário : o endereço da conta que recebe as taxas de mineração deste bloco
    • stateRoot : o hash do nó raiz do teste de estado (lembre-se de como aprendemos que o teste de estado é armazenado no cabeçalho e torna mais fácil para clientes leves verificarem qualquer coisa sobre o estado)
    • transactionRoot : o hash do nó raiz do trie que contém todas as transações listadas neste bloco
    • receiptsRoot : o hash do nó raiz do trie que contém os recibos de todas as transações listadas neste bloco
    • logsBloom : um filtro Bloom (estrutura de dados) que consiste em informações de log
    • dificuldade : o nível de dificuldade deste bloco
    • número : a contagem do bloco atual (o bloco de gênese tem um número de bloco zero; o número do bloco aumenta em 1 para cada bloco subsequente)
    • gasLimit : o limite de gás atual por bloco
    • gasUsed : a soma do gás total utilizado pelas transações neste bloco
    • carimbo de data / hora : o carimbo de data / hora unix do início deste bloco
    • extraData : dados extras relacionados a este bloco
    • mixHash : um hash que, quando combinado com o nonce, prova que este bloco realizou computação suficiente
    • nonce : um hash que, quando combinado com o mixHash, prova que este bloco realizou computação suficiente

    Observe como cada cabeçalho de bloco contém três estruturas trie para:

    Observe como cada cabeçalho de bloco contém três estruturas trie para:

    • estado ( stateRoot )
    • transações ( transactionRoot )
    • recibos ( receiptsRoot )

    Essas estruturas trie nada mais são do que as tentativas de Merkle Patricia que discutimos anteriormente.

    Além disso, existem alguns termos da descrição acima que vale a pena esclarecer. Vamos dar uma olhada.

    Histórico

    Uma entrada de registro contém:

    • o endereço da conta do logger,
    • uma série de tópicos que representam vários eventos realizados por esta transação, e
    • quaisquer dados associados a esses eventos.

    Os logs são armazenados em um filtro bloom , que armazena os dados de log intermináveis ​​de maneira eficiente.

    Recibo de transação

    • o número do bloco
    • bloco de hash
    • hash de transação
    • gás usado pela transação atual
    • gás cumulativo usado no bloco atual após a transação atual ter sido executada
    • logs criados ao executar a transação atual
    • ..e assim por diante

    Dificuldade de bloco

    A dificuldade do bloco afeta o nonce, que é um hash que deve ser calculado ao minerar um bloco, usando o algoritmo de prova de trabalho.

    A relação entre a dificuldade do bloco e o nonce é matematicamente formalizada como:

    onde Hd é a dificuldade.

    A única maneira de encontrar um nonce que atenda a um limite de dificuldade é usar o algoritmo de prova de trabalho para enumerar todas as possibilidades. O tempo esperado para encontrar uma solução é proporcional à dificuldade – quanto maior a dificuldade, mais difícil se torna encontrar o nonce e, portanto, mais difícil é validar o bloco, o que, por sua vez, aumenta o tempo que leva para validar um novo quadra. Portanto, ao ajustar a dificuldade de um bloqueio, o protocolo pode ajustar o tempo que leva para validar um bloqueio.

    Se, por outro lado, o tempo de validação está ficando mais lento, o protocolo diminui a dificuldade. Desta forma, o tempo de validação se autoajusta para manter uma taxa constante – em média, um bloco a cada 15 segundos.

    Execução da Transação

    Primeiro, todas as transações devem atender a um conjunto inicial de requisitos para serem executadas. Esses incluem:

    • A transação deve ser um RLP formatado corretamente . “RLP” significa “Prefixo de comprimento recursivo” e é um formato de dados usado para codificar matrizes aninhadas de dados binários. RLP é o formato que Ethereum usa para serializar objetos.
    • Assinatura de transação válida.
    • Nonce de transação válida. Lembre-se de que o nonce de uma conta é a contagem de transações enviadas dessa conta. Para ser válido, um nonce de transação deve ser igual ao nonce da conta do remetente.
    • O limite de gás da transação deve ser igual ou maior que o gás intrínseco usado pela transação. O gás intrínseco inclui:
    1. um custo predefinido de 21.000 gás para executar a transação
    2. uma taxa de gás para os dados enviados com a transação (4 gás para cada byte de dados ou código igual a zero e 68 gás para cada byte diferente de zero de dados ou código)
    3. se a transação for uma transação de criação de contrato, um adicional de 32.000 gás

    • O saldo da conta do remetente deve ter Ether suficiente para cobrir os custos de gás “adiantados” que o remetente deve pagar. O cálculo do custo inicial do gás é simples: primeiro, o limite de gás da transação é multiplicado pelo preço do gás da transação para determinar o custo máximo do gás. Em seguida, esse custo máximo é adicionado ao valor total que está sendo transferido do remetente para o destinatário.

    Se a transação atender a todos os requisitos de validade acima, seguiremos para a próxima etapa.

    Primeiro, deduzimos o custo inicial de execução do saldo do remetente e aumentamos o nonce da conta do remetente em 1 para contabilizar a transação atual. Neste ponto, podemos calcular o gás restante como o limite total de gás para a transação menos o gás intrínseco usado.

    Em seguida, a transação começa a ser executada. Durante a execução de uma transação, Ethereum mantém o controle do “subestado”. Este subestado é uma forma de registrar informações acumuladas durante a transação que serão necessárias imediatamente após a conclusão da transação. Especificamente, ele contém:

    • Conjunto de autodestruição : um conjunto de contas (se houver) que será descartado após a conclusão da transação.
    • Série de log : pontos de verificação arquivados e indexáveis ​​da execução do código da máquina virtual.
    • Saldo de reembolso : o valor a ser devolvido à conta do remetente após a transação. Lembra como mencionamos que o armazenamento no Ethereum custa dinheiro e que o remetente é reembolsado por limpar o armazenamento? Ethereum controla isso usando um contador de reembolso. O contador de reembolso começa em zero e aumenta sempre que o contrato exclui algo no armazenamento.

    Em seguida, os vários cálculos exigidos pela transação são processados.

    Assim que todas as etapas exigidas pela transação forem processadas, e presumindo que não haja um estado inválido, o estado é finalizado determinando a quantidade de gás não utilizado a ser reembolsada ao remetente. Além do gás não utilizado, o remetente também recebe algum reembolso do “saldo de reembolso” que descrevemos acima.

    Assim que o remetente for reembolsado:

    • o éter para o gás é dado ao mineiro
    • o gás usado pela transação é adicionado ao contador de gás do bloco (que mantém o controle do gás total usado por todas as transações no bloco e é útil ao validar um bloco)
    • todas as contas no conjunto de autodestruição (se houver) são excluídas

    Finalmente, ficamos com o novo estado e um conjunto de logs criados pela transação.

    Agora que cobrimos os fundamentos da execução de transações, vamos examinar algumas das diferenças entre transações de criação de contratos e chamadas de mensagens.

    Criação de contrato

    Para criar uma nova conta de contrato, primeiro declaramos o endereço da nova conta usando uma fórmula especial. Em seguida, inicializamos a nova conta:

    • Definindo o nonce para zero
    • Se o remetente enviou alguma quantidade de Éter como valor com a transação, definindo o saldo da conta para esse valor
    • Deduzindo o valor adicionado ao saldo desta nova conta do saldo do remetente
    • Configurando o armazenamento como vazio
    • Definir o codeHash do contrato como o hash de uma string vazia

    Depois de inicializarmos a conta, podemos realmente criar a conta, usando o código init enviado com a transação (consulte a seção “Transação e mensagens” para uma atualização sobre o código init). O que acontece durante a execução deste código init é variado. Dependendo do construtor do contrato, ele pode atualizar o armazenamento da conta, criar outras contas de contrato, fazer outras chamadas de mensagem, etc.

    Conforme o código para inicializar um contrato é executado, ele usa gás. A transação não pode usar mais gás do que o gás restante. Em caso afirmativo, a execução atingirá uma exceção de falta de gás (OOG) e será encerrada. Se a transação for encerrada devido a uma exceção de falta de gás, o estado será revertido para o ponto imediatamente anterior à transação. O remetente não é reembolsado pelo gás gasto antes de acabar.

    Boo hoo.

    No entanto, se o remetente enviou qualquer valor Ether com a transação, o valor Ether será reembolsado mesmo se a criação do contrato falhar. Ufa!

    Se o código de inicialização for executado com êxito, um custo final de criação do contrato será pago. Este é um custo de armazenamento e é proporcional ao tamanho do código do contrato criado (novamente, sem almoço grátis!) Se não houver gás suficiente restante para pagar este custo final, então a transação novamente declara uma exceção de falta de gás e aborta.

    Se tudo correr bem e chegarmos até aqui sem exceções, qualquer gás não utilizado restante será devolvido ao remetente original da transação, e o estado alterado agora pode persistir!

    Viva!

    Chamadas de mensagem

    Uma execução de chamada de mensagem não inclui nenhum código init, uma vez que nenhuma nova conta está sendo criada. No entanto, pode conter dados de entrada, se esses dados foram fornecidos pelo remetente da transação. Uma vez executadas, as chamadas de mensagem também têm um componente extra contendo os dados de saída, que é usado se uma execução subsequente precisar desses dados.

    Como acontece com a criação do contrato, se uma execução de chamada de mensagem termina porque fica sem gás ou porque a transação é inválida (por exemplo, estouro de pilha, destino de salto inválido ou instrução inválida), nenhum gás usado é devolvido ao chamador original . Em vez disso, todo o gás não utilizado restante é consumido e o estado é redefinido para o ponto imediatamente anterior à transferência do saldo.

    Até a atualização mais recente do Ethereum, não havia como interromper ou reverter a execução de uma transação sem que o sistema consumisse todo o gás fornecido. Por exemplo, digamos que você tenha criado um contrato que gerou um erro quando um chamador não estava autorizado a realizar alguma transação. Nas versões anteriores do Ethereum, o gás restante ainda seria consumido e nenhum gás seria devolvido ao remetente. Mas a atualização do Byzantium inclui um novo código de “reversão” que permite que um contrato interrompa a execução e reverta as mudanças de estado, sem consumir o gás restante e com a capacidade de retornar o motivo da falha na transação. Se uma transação for encerrada devido a uma reversão, o gás não utilizado será devolvido ao remetente.

    Modelo de execução

    A parte do protocolo que realmente lida com o processamento das transações é a própria máquina virtual do Ethereum, conhecida como Ethereum Virtual Machine (EVM).

    O EVM é uma máquina virtual completa de Turing, conforme definido anteriormente. A única limitação do EVM que uma máquina completa de Turing típica não tem é que o EVM é intrinsecamente ligado ao gás. Assim, a quantidade total de computação que pode ser feita é intrinsecamente limitada pela quantidade de gás fornecida.

    Fonte: CMU

    Além disso, o EVM tem uma arquitetura baseada em pilha. Uma máquina de pilha é um computador que usa uma pilha do último a entrar, o primeiro a sair para armazenar valores temporários.

    O tamanho de cada item da pilha no EVM é de 256 bits e a pilha tem um tamanho máximo de 1024.

    O EVM possui memória, onde os itens são armazenados como matrizes de bytes endereçadas por palavra. A memória é volátil, o que significa que não é permanente.

    O EVM também possui armazenamento. Ao contrário da memória, o armazenamento não é volátil e é mantido como parte do estado do sistema. O EVM armazena o código do programa separadamente, em uma ROM virtual que só pode ser acessada por meio de instruções especiais. Desta forma, o EVM difere da arquitetura típica de von Neumann , na qual o código do programa é armazenado na memória ou armazenamento.

    O EVM também tem sua própria linguagem: “EVM bytecode”. Quando um programador como você ou eu escreve contratos inteligentes que operam no Ethereum, normalmente escrevemos código em uma linguagem de nível superior, como Solidity. Podemos então compilá-lo em bytecode EVM que o EVM possa entender.

    Ok, agora para a execução.

    Antes de executar um cálculo específico, o processador certifica-se de que as seguintes informações estão disponíveis e são válidas:

    • Estado do sistema
    • Gás restante para computação
    • Endereço da conta que possui o código que está executando
    • Endereço do remetente da transação que originou esta execução
    • Endereço da conta que causou a execução do código (pode ser diferente do remetente original)
    • Preço do gás da transação que originou esta execução
    • Dados de entrada para esta execução
    • Valor (em Wei) transferido para esta conta como parte da execução atual
    • Código de máquina a ser executado
    • Cabeçalho do bloco do bloco atual
    • Profundidade da chamada de mensagem presente ou pilha de criação de contrato

    No início da execução, a memória e a pilha estão vazias e o contador do programa é zero.

    PC: 0 PILHA: [] MEM: [], ARMAZENAMENTO: {}

    O EVM então executa a transação recursivamente, computando o estado do sistema e o estado da máquina para cada loop. O estado do sistema é simplesmente o estado global do Ethereum. O estado da máquina é composto por:

    • gás disponível
    • contador de programa
    • conteúdo da memória
    • número ativo de palavras na memória
    • empilhar conteúdo.

    Os itens da pilha são adicionados ou removidos da parte mais à esquerda da série.

    Em cada ciclo, a quantidade de gás apropriada é reduzida do gás restante e o contador do programa é incrementado.

    No final de cada loop, existem três possibilidades:

    1. A máquina atinge um estado excepcional (por exemplo, gás insuficiente, instruções inválidas, itens de pilha insuficientes, itens de pilha estouram acima de 1024, destino de JUMP / JUMPI inválido, etc.) e, portanto, deve ser parada, com quaisquer alterações descartadas
    2. A sequência continua a processar no próximo loop
    3. A máquina chega a uma parada controlada (fim do processo de execução)

    Assumindo que a execução não atinge um estado excepcional e atinge uma parada “controlada” ou normal, a máquina gera o estado resultante, o gás restante após esta execução, o subestado acumulado e a saída resultante.

    Ufa. Passamos por uma das partes mais complexas de Ethereum. Mesmo que você não tenha compreendido totalmente esta parte, tudo bem. Você realmente não precisa entender os detalhes essenciais da execução, a menos que esteja trabalhando em um nível muito profundo.

    Como um bloco é finalizado

    Quando dizemos “finalizado”, isso pode significar duas coisas diferentes, dependendo se o bloco é novo ou existente. Se for um novo bloco, estamos nos referindo ao processo necessário para minerar este bloco. Se for um bloco existente, então estamos falando sobre o processo de validação do bloco. Em ambos os casos, há quatro requisitos para um bloco ser “finalizado”:

    1) Validar (ou, se minerar, determinar) ommers
    Cada bloco ommer dentro do cabeçalho do bloco deve ser um cabeçalho válido e estar dentro da sexta geração do presente quadra.

    2) Validar (ou, se mineração, determinar) transacções
    gasUsedO número no bloco deve ser igual ao gás cumulativo usado pelas transações listadas no bloco. (Lembre-se de que, ao executar uma transação, monitoramos o contador de gás do bloco, que rastreia o gás total usado por todas as transações no bloco).

    3) Aplicar recompensas (somente se estiver minerando)
    O endereço do beneficiário recebe 5 Ether para minerar o bloco. (De acordo com a proposta EIP-649 da Ethereum , essa recompensa de 5 ETH em breve será reduzida para 3 ETH). Além disso, para cada ommer, o beneficiário do bloco atual recebe um adicional de 1/32 da recompensa do bloco atual. Por último, o beneficiário do (s) bloco (s) Ommer também recebe uma determinada quantia (há uma fórmula especial para como isso é calculado).

    4) Verifique (ou, em caso de mineração, calcule um estado válido) e nonce
    Certifique-se de que todas as transações e mudanças de estado resultantes sejam aplicadas e, em seguida, defina o novo bloco como o estado após a recompensa do bloco ter sido aplicada ao estado resultante da transação final. A verificação ocorre comparando este estado final com o estado armazenado no cabeçalho.

    Prova de trabalho de mineração

    O algoritmo de prova de trabalho do Ethereum é chamado de “ Ethash ” (anteriormente conhecido como Dagger-Hashimoto).

    O algoritmo é formalmente definido como:

    onde m é o mixHash , n é o nonce , Hn é o cabeçalho do novo bloco (excluindo os componentes nonce e mixHash , que devem ser calculados), Hn é o nonce do cabeçalho do bloco e d é o DAG , que é um grande conjunto de dados.

    Na seção “ Blocos ”, falamos sobre os vários itens que existem em um cabeçalho de bloco. Dois desses componentes foram chamados de mixHash e nonce . Como você deve se lembrar:

    • mixHash é um hash que, quando combinado com o nonce, prova que este bloco realizou computação suficiente
    • nonce é um hash que, quando combinado com o mixHash, prova que este bloco realizou computação suficiente

    A função PoW é usada para avaliar esses dois itens.

    Como exatamente o mixHash e o nonce são calculados usando a função PoW é um tanto complexo, e algo que podemos aprofundar em um post separado. Mas em um alto nível, funciona assim:

    Uma “semente” é calculada para cada bloco. Essa semente é diferente para cada “época”, onde cada época tem 30.000 blocos de comprimento. Para a primeira época, a semente é o hash de uma série de 32 bytes de zeros. Para cada época subsequente, é o hash do hash da semente anterior. Usando esta semente, um nó pode calcular um “cache” pseudo-aleatório.

    Esse cache é incrivelmente útil porque permite o conceito de “nós de luz”, que discutimos anteriormente neste post. O objetivo dos nós leves é fornecer a determinados nós a capacidade de verificar com eficiência uma transação sem a carga de armazenar todo o conjunto de dados do blockchain. Um nó leve pode verificar a validade de uma transação com base somente neste cache, porque o cache pode regenerar o bloco específico que precisa verificar.

    Usando o cache, um nó pode gerar o “conjunto de dados” DAG, em que cada item no conjunto de dados depende de um pequeno número de itens selecionados pseudo-aleatoriamente do cache. Para ser um minerador, você deve gerar este conjunto de dados completo; todos os clientes e mineradores completos armazenam esse conjunto de dados, e o conjunto de dados cresce linearmente com o tempo.

    Os mineiros podem então pegar fatias aleatórias do conjunto de dados e colocá-las por meio de uma função matemática para misturá- las em um “ mixHash. ”Um mineiro repetidamente gerar uma mixHash até que a saída está abaixo do objectivo desejado de uso único . Quando a saída atende a esse requisito, esse nonce é considerado válido e o bloco pode ser adicionado à cadeia.

    Mineração como mecanismo de segurança
    Em geral, o objetivo do PoW é provar, de forma criptograficamente segura, que uma determinada quantidade de computação foi despendida para gerar alguma saída (ou seja, o nonce ). Isso ocorre porque não há melhor maneira de encontrar um nonce que esteja abaixo do limite exigido do que enumerar todas as possibilidades. As saídas da aplicação repetida da função hash têm uma distribuição uniforme e, portanto, podemos ter certeza de que, em média, o tempo necessário para encontrar tal nonce depende do limite de dificuldade. Quanto maior a dificuldade, mais tempo leva para resolver o nonce. Desta forma, o algoritmo PoW dá sentido ao conceito de dificuldade, que é usado para reforçar a segurança do blockchain.

    O que queremos dizer com segurança de blockchain? É simples: queremos criar um blockchain em que TODOS confiem. Como discutimos anteriormente neste post, se mais de uma cadeia existisse, os usuários perderiam a confiança, porque eles seriam incapazes de determinar razoavelmente qual cadeia era a cadeia “válida”. Para que um grupo de usuários aceite o estado subjacente armazenado em um blockchain, precisamos de um único blockchain canônico em que um grupo de pessoas acredite.

    Isso é exatamente o que o algoritmo PoW faz: ele garante que um blockchain específico permanecerá canônico no futuro, tornando incrivelmente difícil para um invasor criar novos blocos que sobrescrevem uma certa parte da história (por exemplo, apagando transações ou criando transações falsas) ou mantenha um garfo. Para ter seu bloco validado primeiro, um invasor precisaria resolver consistentemente o nonce mais rápido do que qualquer outra pessoa na rede, de forma que a rede acredite que sua cadeia é a mais pesada (com base nos princípios do protocolo GHOST que mencionamos anteriormente). Isso seria impossível, a menos que o invasor tivesse mais da metade do poder de mineração da rede, um cenário conhecido como ataque majoritário de 51% .

    Mineração como mecanismo de distribuição de riqueza

    • uma recompensa de bloco estático de 5 éter para o bloco “vencedor” (em breve será alterado para 3 éter )
    • o custo do gás gasto dentro do bloco pelas transações incluídas no bloco
    • uma recompensa extra por incluir ommers como parte do bloqueio

    A fim de garantir que o uso do mecanismo de consenso PoW para segurança e distribuição de riqueza seja sustentável no longo prazo, a Ethereum se esforça para incutir essas duas propriedades:

    • Torne-o acessível ao maior número de pessoas possível. Em outras palavras, as pessoas não deveriam precisar de hardware especializado ou incomum para executar o algoritmo. O objetivo disso é tornar o modelo de distribuição de riqueza o mais aberto possível para que qualquer pessoa possa fornecer qualquer quantidade de poder de computação em troca do Éter.
    • Reduza a possibilidade de um único nó (ou pequeno conjunto) obter lucros desproporcionais. Qualquer nó que pode ter uma quantidade desproporcional de lucro significa que o nó tem uma grande influência na determinação do blockchain canônico. Isso é problemático porque reduz a segurança da rede.

    Na rede blockchain Bitcoin, um problema que surge em relação às duas propriedades acima é que o algoritmo PoW é uma função hash SHA256. A fraqueza desse tipo de função é que ela pode ser resolvida com muito mais eficiência usando hardware especializado, também conhecido como ASICs.

    Para mitigar esse problema, a Ethereum optou por tornar seu algoritmo PoW ( Ethhash ) sequencialmente difícil de memória. Isso significa que o algoritmo é projetado de forma que o cálculo do nonce exija muita memória E largura de banda. Os grandes requisitos de memória tornam difícil para um computador usar sua memória em paralelo para descobrir vários nonces simultaneamente, e os altos requisitos de largura de banda tornam difícil até mesmo para um computador super-rápido descobrir vários nonces simultaneamente. Isso reduz o risco de centralização e cria um campo de jogo mais nivelado para os nós que estão fazendo a verificação.

    Uma coisa a se notar é que o Ethereum está passando de um mecanismo de consenso PoW para algo chamado “prova de aposta”. Este é um tópico bestial que podemos explorar em um futuro post. ☺️

OQUE  É ETHEREUM – PARTE  I

Via:
By Ethereum.org

By Preethi kasireddy

Cadastre-se para receber novidades!

CADASTRE-SE
Para Receber as Novidades!

Como funciona?
Receba um e-mail listando as mais recentes Postagens . Você só receberá e-mail nos dias em que houver postagens.

    Recomendados

     Livro: A Bíblia da Fotografia: Tudo o que Você Precisa Saber para Fazer Fotos Perfeitas – Michael Freeman (Autor), Gustavo Razzera – Este livro traz toda a experiência do autor e está repleto de técnicas e desafios inspiradores. O texto segue uma estrutura de curso, quase da mesma maneira como se o leitor estivesse em um curso presencial ou a distância…  Compre na Amazon 

    Fotografia: um guia para ser fotógrafo em um mundo onde todos fotografam – por Daniela Agostini (Autor), Heloísa Alessio (Autor), Thomas Degen (Autor) – Fotografar não é nenhum bicho de sete cabeças, principalmente com tantos celulares munidos de câmeras potentes e tecnologias cada vez mais acessíveis nos dias de hoje… Compre na Amazon 

    Livro: Organizações Exponenciais: por que Elas São 10 Vezes Melhores, Mais Rápidas e Mais Baratas que a sua (e o que Fazer a Respeito)  –Michael S. Malone (Autor), Salim Ismail  (Autor), Yuri Van Geest (Autor), Gerson Yamagami (Tradutor) – Bem-vindo à época das mudanças exponenciais, o melhor momento para se viver. É o momento em que a concorrência não é mais a empresa multinacional ..   Compre o livro na  Amazon 

    O poder da açãoAcorde para os objetivos que quer conquistar. Já aconteceu a você de se olhar no espelho e não gostar daqueles quilos a mais? De observar seu momento profissional somente com frustração? De se sentir desconectado dos seus familiares, dos seus amigos? Se você acha que essas são situações normais, pense de novo! Só porque isso acontece com várias pessoas não quer dizer que a vida deva ser assim… Compre na Amazon 

    Tags: 
    Share:
    error

    Gostou? Conheça Nossas Redes