A Timechain, ou Blockchain do Bitcoin, é a cadeia conectada de blocos válidos desde o Genesis Block até a ponta atual da rede. Cada bloco seguinte aponta para o hash do antecessor, sua impressão digital, e acrescenta o próprio Proof of Work, uma prova do trabalho computacional necessário para criar o bloco. Assim, os nós podem verificar de forma independente qual histórico segue as regras e possui o maior trabalho acumulado. Aqui, “tempo” não significa um relógio exato para cada transação; significa sobretudo uma ordem demonstrável dos acontecimentos.
Imagine um histórico contábil público em que milhares de computadores podem conferir cada nova página de forma independente. Uma página é um bloco. Ela contém um conjunto de transações e uma referência ao bloco anterior; por isso as páginas têm uma ordem definida e não podem ser embaralhadas à vontade. A Timechain é toda essa sequência conectada, desde o primeiro bloco até a ponta atual. Ela não informa quanto bitcoin pertence a cada pessoa identificada por nome; registra o histórico de transações a partir do qual os nós calculam as saídas de transações que continuam não gastas. Também não é o servidor de uma empresa. Qualquer Full Node (um nó que verifica por conta própria as transações e as regras da rede) pode baixar e verificar uma cópia. [1] [3]
No contexto do Bitcoin, os dois nomes designam o mesmo histórico de blocos. O código preservado de antes do lançamento, de novembro de 2008, usava timechain em comentários e nomes de variáveis ou funções. O whitepaper fala, em vez disso, de marcação temporal, cadeia de blocos e cadeia de Proof of Work; a palavra exata timechain não aparece nele. Mais tarde, Blockchain tornou-se o termo comum em todo o mundo. Hoje também é uma designação ampla para outras redes e bases de dados, enquanto a Bitcoin Timechain é a cadeia específica do Bitcoin. Portanto, as duas palavras do título não nomeiam dois protocolos. Elas mantêm o nome histórico ao lado do termo corrente atual. [2] [1] [8]
Uma assinatura digital pode provar que uma transação foi autorizada pelo detentor da chave necessária. Sozinha, porém, não impede alguém de assinar duas transações conflitantes que tentam gastar a mesma saída ainda não gasta de uma transação anterior, chamada UTXO. Um nó pode receber primeiro o pagamento a um comerciante, enquanto outro recebe primeiro a transferência do mesmo valor de volta ao remetente. Por isso, a rede precisa de um histórico compartilhado que determine qual gasto foi confirmado e qual já não pode ser válido. Os blocos dão às transações um lugar verificável nessa ordem. Eles não provam qual mensagem foi criada primeiro no tempo humano ou da rede; os nós podem ter visto transações não confirmadas em ordens diferentes. [1]
O Block Header contém os dados essenciais de um bloco. Entre eles estão o hash do cabeçalho anterior e o Merkle Root, que reúne os identificadores das transações do bloco em um hash. Um hash funciona como uma impressão digital: até uma pequena alteração nos dados produz outro resultado. Mudar uma transação antiga alteraria o Merkle Root, o hash daquele bloco e a referência guardada pelo bloco seguinte. A edição não ficaria limitada a uma linha modificada; quebraria toda a sequência posterior. Um hash, por si só, não prova que as transações seguem as regras. Os nós também precisam validar as transações, e cada bloco deve satisfazer o Proof of Work exigido. [3] [1]
Um nó não aceita uma ramificação apenas porque ela é mais longa ou promovida por um grande minerador. Primeiro verifica as regras: Proof of Work, ligações com blocos anteriores, recompensa permitida, transações, condições de gasto e se as entradas apontam para valores já gastos. Uma ramificação inválida continua inválida, qualquer que seja o poder computacional do autor. Só entre candidatos válidos o nó escolhe a cadeia com maior trabalho acumulado. Portanto, é mais preciso falar na ramificação válida com mais trabalho do que simplesmente na “cadeia mais longa”. O campo chainwork estima o número esperado de hashes necessário para produzir a cadeia conforme a dificuldade de cada bloco; não é um contador das tentativas realmente feitas pelos mineradores. [4] [5] [6]
Proof of Work custa tempo, eletricidade e capacidade computacional, mas o resultado é rápido de verificar. Quem alterasse um bloco antigo teria de produzir um novo Proof of Work válido para ele, reconectar todos os blocos posteriores e continuar alcançando o trabalho que a ramificação honesta segue acrescentando. Quanto mais fundo um bloco estiver sob a ponta, maior será a vantagem do histórico normal. Isso não é uma promessa matemática de que o passado nunca possa mudar. É uma defesa econômica e probabilística: blocos adicionais normalmente tornam uma reescrita bem-sucedida cada vez mais cara. O atacante também não pode inserir um pagamento inválido qualquer ou bitcoin em excesso na ramificação substituta, pois os outros nós rejeitariam o bloco. [1] [4]
Um minerador coloca um timestamp no Block Header. As regras de consenso permitem alguma margem, por isso o valor time não prova com exatidão quando um bloco ou uma transação específica foi criada. O timestamp de um bloco nem sequer precisa ser maior que o do seu antecessor imediato. Para algumas regras, o Bitcoin usa Median Time Past: a mediana dos timestamps dos 11 blocos anteriores. A mediana é obtida ordenando esses timestamps e escolhendo o valor do meio. Ela avança de maneira mais regular que os valores individuais. O intervalo médio de dez minutos entre blocos também não é um horário. Dois blocos podem chegar quase juntos, enquanto a espera seguinte pode ser muito maior. A altura do bloco dá uma posição exata na cadeia, não uma hora exata no calendário. [4] [7]
Dois mineradores podem encontrar blocos válidos diferentes quase ao mesmo tempo e na mesma altura. Alguns nós veem uma ramificação primeiro; outros veem a outra. Quando o Proof of Work posterior cria uma diferença entre as ramificações válidas, os nós passam para aquela com mais trabalho acumulado. Essa troca chama-se Reorg. As transações do bloco desconectado podem confirmar na nova ramificação, voltar ao Mempool ou tornar-se inválidas caso o novo histórico confirme um gasto conflitante. A inclusão num bloco é a primeira confirmação; cada bloco posterior acrescenta outra. Não existe um número mágico universal para todos os pagamentos. A confiança adequada depende do valor, do risco e da possibilidade de esperar. [1] [3]
O Bitcoin permite criar uma transação que só pode ser confirmada a partir de certa altura de bloco ou depois de um tempo indicado. Um Timelock não é uma ordem para executar automaticamente a transação naquele minuto. Ele apenas estabelece o ponto mais cedo a partir do qual um bloco válido pode incluí-la. Para nLockTime baseado em tempo, o BIP 113 usa o Median Time Past do bloco anterior, e não o timestamp facilmente ajustável do bloco em criação. A condição apoia-se, assim, no histórico de vários blocos. Mesmo depois de satisfeita, a transação precisa ser transmitida, aceita pelos nós e escolhida por um minerador; a inclusão num bloco específico não é garantida. [7] [4]
RPC é uma interface para enviar comandos ao nó e ler suas respostas. Um Full Node não precisa confiar na afirmação de um explorer público de que um bloco ou uma transação pertence ao histórico atual. Para um hash específico, o RPC getblock pode mostrar height, número de confirmações, Merkle Root, time, mediantime, hash anterior, dificuldade e chainwork. Cada campo responde a uma pergunta: height dá a posição; previousblockhash mostra a ascendência; confirmations mostra a profundidade sob a ponta atual; time é o valor do header; mediantime é uma mediana; e chainwork representa o trabalho esperado acumulado. Nenhum número basta sozinho. A finalidade da Timechain é permitir que o nó verifique a relação entre eles e todas as regras de consenso como um conjunto. [6] [4]
Para ter uma visão mais completa, leia este verbete junto com Genesis Block, Proof of Work, Transação, Full Node, Difficulty Adjustment. Também há referências a este verbete em Bitcoin Whitepaper, Genesis Block, Proof of Work, Full Node.