Blocos

Última edição: , Invalid DateTime

Ver colaboradores

Editar Página

Blocos são lotes de transações com um hash do bloco anterior na cadeia. Isso une os blocos (em uma cadeia) porque os hashes são criptograficamente derivados dos dados do bloco. Isso previne fraudes, porque uma mudança em qualquer bloco no histórico invalidaria todos os blocos subsequentes, alteraria todos os hashes subsequentes e todos que estivessem executando o blockchain notariam.

Pré-requisitos

Os blocos são um tópico muito amigável para iniciantes. Mas para ajudá-lo a entender melhor esta página, recomendamos que você primeiro leia Contas, Transaçõese nossa introdução ao Ethereum.

Por que blocos?

Para garantir que todos os participantes da rede Ethereum mantenham um estado sincronizado e concordem com o histórico preciso de transações, nós processamos lotes de transações em blocos. Isso significa que dezenas (ou centenas) de transações são confirmadas, acordadas e sincronizadas de uma só vez.

Diagrama adaptado de Ethereum EVM ilustrado

Ao espaçar as confirmações, damos a todos os participantes da rede tempo suficiente para chegar a um consenso: mesmo que as solicitações de transação ocorram dezenas de vezes por segundo, os blocos só são criados e confirmados na Ethereum uma vez a cada doze segundos.

Como os blocos funcionam

Para preservar o histórico de transação, os blocos são estritamente ordenados (cada novo bloco criado contém uma referência ao seu bloco de origem), e as transações dentro dos blocos também são ordenadas estritamente. Exceto em casos raros, a qualquer momento, todos os participantes da rede concordam com o número exato e o histórico de blocos, e estão trabalhando para processar em lote as solicitações atuais de transações para o bloco seguinte.

Uma vez que um bloco é colocado por algum validador na rede, ele é propagado para o restante da rede; todos os nós adicionam esse bloco ao final de sua cadeia de blocos e um novo validador é selecionado para criar o próximo bloco. O processo exato de montagem de blocos e o processo de compromisso/consenso são atualmente especificados pelo protocolo de “prova de participação” da Ethereum.

Protocolo de prova de participação

Prova de participação significa o seguinte:

• Os nós de validação precisam colocar 32 ETH em um contrato de depósito como garantia contra mau comportamento. Isso ajuda a proteger a rede porque atividades comprovadamente desonestas fazem com que parte de ou toda essa participação seja destruída.
• Em cada espaço (espaçados de doze segundos), um validador é selecionado aleatoriamente para ser o proponente do bloco. Eles agrupam transações, as executam e determinam um novo "estado". Eles agrupam essas informações em um bloco e as passam para outros validadores.
• Outros validadores que ouvem sobre um novo bloco reexecutam as transações para garantir que concordam com a mudança proposta para o estado global. Assumindo que o bloco é válido, eles o adicionam ao seu próprio banco de dados.
• Se um validador ouvir sobre dois blocos conflitantes para o mesmo espaço, eles usam seu algoritmo de escolha de fork para escolher aquele suportado pelo ETH que teve mais participação.

Mais sobre prova de participação

O que há em um bloco?

Há muitas informações contidas em um bloco. No nível mais alto, um bloco contém os seguintes campos:

1espaço: o espaço ao qual o bloco pertence no
2proposer_index: o ID do validador que propõe o bloco
3parent_root: o hash do bloco anterior
4state_root: o hash raiz do objeto de estado
5body: um objeto que contém vários campos, conforme definido abaixo
6

O bloco body contém vários campos próprios:

1randao_reveal: um valor usado para selecionar o próximo proponente do bloco
2eth1_data: informações sobre o contrato de depósito
3graffiti: dados arbitrários usados para marcar blocos
4proposer_slashings: lista de validadores a serem removidos
5attester_slashings: lista de validadores a serem removidos
6attestations: lista de atestações a favor do bloco atual
7deposits: lista de novos depósitos no contrato de depósito
8voluntary_exits: lista de validadores saindo da rede
9sync_aggregate: subconjunto de validadores usados para atender clientes simplificados (light clients)
10execution_payload: transações passadas do cliente de execução
11
Exibir tudo

O campo attestations contém uma lista de todas as atestações no bloco. As atestações têm seu próprio tipo de dados que contém vários dados. Cada atestação contém:

1aggregation_bits: uma lista de quais validadores participaram desta atestação
2data: um contêiner com vários subcampos
3signature: assinatura agregada de todos os validadores de atestados
4

O campo data no attestation contém o seguinte:

1slot: o espaço ao qual a atestação se refere
2index: índices para atestar validadores
3beacon_block_root: o hash raiz do bloco Beacon contendo esse objeto
4source: o último ponto de verificação justificado
5target: o último bloco de limite da época
6

A execução das transações no execution_payload atualiza o estado global. Todos os clientes reexecutam as transações no execution_payload para garantir que o novo estado corresponda ao novo bloco do campo state_root. É assim que os clientes podem dizer que um novo bloco é válido e seguro para adicionar à cadeia de blocos deles. O próprio execution payload é um objeto com vários campos. Há também um execution_payload_header que contém informações importantes de resumo sobre os dados de execução. Essas estruturas de dados são organizadas da seguinte forma:

O execution_payload_header contém os seguintes campos:

1parent_hash: hash do bloco pai
2fee_recipient: endereço da conta para pagamento de taxas de transação para
3state_root: hash raiz para o estado global depois de aplicar as alterações nesse bloco
4receipts_raiz: hash da tentativa de recibos da transação
5logs_bloom: estrutura de dados contendo logs de eventos
6prev_randao: valor usado na seleção aleatória do validador
7block_number: o número do bloco atual
8gas_limit: gás máximo permitido nesse bloco
9gas_used: a quantidade real de gás usada nesse bloco
10timestamp: o tempo do bloco
11extra_data: dados adicionais arbitrários como bytes brutos
12base_fee_per_gas: o valor da taxa base
13block_hash: hash do bloco de execução
14transaction_root: hash raiz das transações no conteúdo
15
Exibir tudo

O próprio execution_payload contém o seguinte (observe que isso é idêntico ao cabeçalho, exceto que, em vez do hash raiz das transações, ele inclui a lista real de transações):

1parent_hash: hash do bloco pai
2fee_recipient: endereço da conta para pagamento de taxas de transação para
3state_root: hash raiz para o estado global após aplicar as alterações neste bloco
4receipts_raiz: hash da tentativa de recibos da transação
5logs_bloom: estrutura de dados contendo logs de eventos
6prev_randao: valor usado na seleção aleatória do validador
7block_number: o número do bloco atual
8gas_limit: gás máximo permitido neste bloco
9gas_used: a quantidade real de gás usada neste bloco
10timestamp: o tempo do bloco
11extra_data: dados adicionais arbitrários como bytes brutos
12base_fee_per_gas: o valor da taxa base
13block_hash: hash do bloco de execução
14transações: lista de transações a serem executadas
15
Exibir tudo

Tempo de bloco

O tempo do bloco refere-se ao tempo de separação dos blocos. No Ethereum, o tempo é dividido em doze unidades de segundos chamadas de "espaços". Em cada espaço, um único validador é selecionado para propor um bloco. Supondo que todos os validadores estejam online e totalmente funcionais, haverá um bloco em cada espaço, o que significa que o tempo de um bloco é de 12s. No entanto, ocasionalmente, os validadores podem estar offline quando chamados para propor um bloco, o que significa que os espaços podem às vezes ficar vazios. Isso é diferente dos sistemas baseados em prova de trabalho, em que os tempos de bloco são probabilísticos e ajustados pela dificuldade de mineração.

Tamanho do bloco

Uma nota final importante é que os blocos em si são delimitados em tamanho. Cada bloco tem um tamanho alvo de 15 milhões de gás, mas o tamanho dos blocos vai aumentar ou diminuir de acordo com as demandas da rede, até o limite do bloco de 30 milhões de gás (2 vezes o tamanho do bloco de destino). A quantidade total de gás gasto por todas as transações no bloco deve ser inferior ao limite de gás do bloco. Isso é importante porque garante que os blocos não podem ser, arbitrariamente, grandes. Se os blocos pudessem ser arbitrariamente grandes, os nós completos (full nodes) com menos desempenho iriam gradualmente deixar de ser capazes de acompanhar a rede devido aos requisitos de espaço e velocidade. Quanto maior o bloco, maior o poder de computação necessário para processá-los a tempo para o próximo espaço. Esta é uma força centralizadora, à qual se resiste limitando os tamanhos dos blocos.

Leitura adicional

Conhece um recurso da comunidade que ajudou você? Edite essa página e adicione-a!

Tópicos relacionados

• Transações
• Gás
• Prova de participação