Ir para o conteúdo
Financial Context Wiki

Blockchain: Estado, Consenso e Verificação

Um blockchain é um protocolo versionado para ordenar e validar transições de estado entre réplicas. Links hash são apenas um componente; a confiança depende de consenso, permissões, verificação independente, disponibilidade de dados, governança e recuperação.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Um blockchain é um protocolo versionado que permite que múltiplas réplicas ordenem transações propostas, validem transições de estado e convirjam para um histórico aceito sob consenso declarado e suposições de rede. Um bloco é um contêiner definido por protocolo com transações ou outros dados, além de compromissos com o histórico anterior e o estado resultante; a cadeia ou o histórico direcionado vincula contêineres aceitos por meio de compromissos criptográficos.

Os links hash tornam detectáveis alterações históricas não autorizadas, mas não tornam um sistema descentralizado, imutável ou correto de forma independente. Essas propriedades dependem de quem pode propor e validar, se os usuários podem verificar de forma independente, as regras de escolha e finalidade, disponibilidade de dados, diversidade de clientes, governança, controle chave, incentivos e procedimentos de recuperação.

Blockchains podem usar UTXO, contas, objetos ou modelos de estado específicos de aplicações; prova de trabalho, prova de participação, votação tolerante a falhas bizantinas ou consenso permissionado; e finalidade probabilística ou baseada em pontos de verificação. A palavra “blockchain”, portanto, nomeia uma ampla família de arquiteturas, não uma garantia de segurança nem um produto de banco de dados.

1
Criar

Uma carteira constrói uma transação com destino, valor, parâmetros de taxa e dados de proteção de reprodução, como entradas gastas ou um nonce.

Como funciona

  1. Fixe a cadeia, a rede, a versão do protocolo, o modelo de permissão, o modelo de estado e a afirmação que está sendo testada. Registre o bloco gênese ou ponto de verificação confiável, o identificador da cadeia, a implementação do cliente e a autoridade de atualização.
  2. Construa os bytes exatos da transação e da autorização. Antes da transmissão, verifique a propriedade do remetente ou das entradas, o nonce ou as referências a saídas não gastas, o valor, o destino, os limites de taxa, a janela de validade, as assinaturas e as chamadas da aplicação.
  3. Propague a transação através de peers ou gateways. Distinguir a admissão local e a política de mempool da validade do consenso; um nó pode rejeitar, atrasar, substituir ou nunca receber uma transação que possa ser válida em um bloco.
  4. Um proponente seleciona e ordena transações em um bloco candidato e se compromete com campos do protocolo como o bloco pai e as raízes de transações, recibos, estado ou dados. A ordenação pode afetar os resultados da execução, taxas, liquidações e valor extraível.
  5. Nós independentes desserializam o bloco, verificam a autorização de consenso e todas as transições de estado necessárias, recalculam os compromissos e rejeitam entradas inválidas ou indisponíveis de acordo com suas regras. Assinaturas do produtor ou prova de trabalho não substituem a validação com falha.
  6. A escolha da bifurcação seleciona entre históricos válidos concorrentes, enquanto as confirmações, votos ou pontos de verificação alteram o risco de reorganização ao longo do tempo. “Incluído”, “seguro” e “finalizado” são estados diferentes e permanecem específicos do protocolo.
  7. Reconcilie o estado do protocolo com a intenção da aplicação, a custódia, a contabilidade da ponte ou da plataforma e os requisitos de arquivamento. Preserve os bytes da transação, o hash do bloco, a altura ou o slot, o recibo, os logs, a prova de estado, o status de finalidade, a versão do cliente e evidências de um endpoint independente.

Exemplos trabalhados

  • Reconciliação do estado da conta. Uma conta começa com 10 ETH e nonce 41. Uma transação válida com nonce 41 transfere 2 ETH e consome 0.00042 ETH em taxas; assim, o estado posterior simplificado é 10 - 2 - 0.00042 = 7.99958 ETH, o destinatário recebe 2 ETH e o nonce do remetente passa a 42. Uma assinatura válida, por si só, não provaria o saldo anterior nem a execução bem-sucedida.
  • Conservação UTXO. Uma transação gasta entradas de 0.80 BTC e 0.35 BTC, totalizando 1.15 BTC. Saídas de 1.00 BTC e 0.1496 BTC totalizam 1.1496 BTC; a diferença é 1.15 - 1.1496 = 0.0004 BTC em taxas. Os nós também devem verificar se cada saída referenciada existe, não foi gasta e satisfaz suas condições de gasto.
  • Tamanho da prova de compromisso. Em uma árvore Merkle binária balanceada ilustrativa com 8 leaves, um caminho de inclusão precisa de log2(8) = 3 sibling hashes. Com hashes 256-bit = 32-byte, esses irmãos ocupam 3 * 32 = 96 bytes antes dos índices e da codificação. A prova liga uma folha a uma raiz reivindicada; isso não prova que os dados de origem sejam verdadeiros ou estejam atualmente disponíveis.
  • Peso não é contagem de nós. Em um protocolo de votação ilustrativo cuja regra de finalidade declarada é >= 2/3 de peso, os validadores detêm 30%, 25%, 20%, 15%, 10%. Os três primeiros totalizam 30 + 25 + 20 = 75% e ultrapassam a regra, enquanto os dois primeiros totalizam 55% e não. Limites reais, regras de correlação, equívoco e recuperação devem vir do protocolo nomeado.

Riscos

  • Usar o identificador de cadeia, rede, bifurcação, ponto de verificação ou cadeia incorreto.
  • Tratar uma marca como um protocolo completo ou especificação de modelo de confiança.
  • Presumir que a ligação hash por si só evita reescritas autorizadas ou aprovadas por consenso.
  • Confundir a proposta de bloco de um produtor com validação de nó independente.
  • Tratar aceitação, transmissão, inclusão, sucesso de execução e finalidade do mempool como um único estado.
  • Assinatura de bytes, domínios ou destinos diferentes do que a interface exibe.
  • Reutilizar nonces, gastar UTXOs obsoletos ou calcular mal taxas e trocos.
  • Confiar em símbolos de token, rótulos, eventos ou interpretações do explorador em vez de identificadores de protocolo e estado.
  • Tratar entradas assinadas de oráculos, pontes ou documentos como prova de que as afirmações fora da cadeia são verdadeiras.
  • Ignorar ordenação de transações, censura, front-running e concentração de proponentes ou construtores.
  • Contar nós ou validadores sem resolver operadores, pesos e infraestrutura comuns.
  • Ignorar a concentração de cliente, nuvem, geografia, governança, chave e cadeia de fornecimento de software.
  • Supor que todos os modelos de consenso têm os mesmos limites de falha ou a mesma semântica de finalidade.
  • Ignorar partições, finalização atrasada, reorganizações, equívocos e procedimentos de recuperação.
  • Aceitar cabeçalhos de bloco ou provas sem as suposições de disponibilidade de dados exigidas.
  • Depender de um único RPC, explorador, carteira, indexador ou plataforma de custódia como fonte da verdade.
  • Confundir posse ou controle de protocolo com título legal, recurso ou recuperabilidade.
  • Subestimar o crescimento do estado, a perda de arquivos, o custo de sincronização e as barreiras de hardware.
  • Ignorar chaves de atualização, pausas de emergência, recuperação social e bifurcações contenciosas.
  • Inferir privacidade, escalabilidade, valor de investimento ou segurança de aplicação a partir do rótulo blockchain.

Erros comuns

  • Cada blockchain é descentralizada e imutável. Permissão, independência do operador, escolha de fork, governança e recuperação determinam quem pode alterar ou rejeitar o histórico.
  • Os dados registrados na rede devem ser verdadeiros. O consenso pode concordar em registrar fielmente um preço falso, documento forjado ou entrada de aplicativo malicioso.
  • Uma transação válida comprova o resultado pretendido. Ela pode ter como alvo o endereço errado, ser revertida após consumir taxas, emitir eventos enganosos ou depender de etapas posteriores de ponte e custódia.
  • Mais réplicas sempre melhoram a segurança. Réplicas sob um operador, cliente, nuvem ou chave podem falhar juntas e podem não fornecer verificação independente.
  • Um blockchain é sempre melhor que um banco de dados convencional. Um operador confiável, exclusão necessária, alto rendimento ou simples resolução de disputas podem tornar um sistema convencional mais apropriado.

Tópicos relacionados

Fontes oficiais

Navegação

Pesquisar na wiki...