Tadge Dryja

Imagine que os nós do mundo inteiro, os computadores que verificam as regras do Bitcoin, precisassem verificar separadamente cada café pago. Como permitir mais pagamentos sem exigir computadores cada vez mais potentes para manter um nó próprio? Joseph Poon e Thaddeus Dryja estudaram uma rede de canais de pagamento. O whitepaper indicado, documento que explica a proposta, tem a data de 14 de janeiro de 2016 e a identificação DRAFT 0.5.9.2. É uma proposta histórica que ajuda a entender a origem da ideia; as regras exatas dos programas atuais devem ser consultadas na documentação desses programas. [1]

Um canal de pagamento pode ser entendido como um acordo atualizado sobre a divisão de bitcoins depositados antecipadamente. Cada pagamento muda a parte que cabe a cada participante. Eles assinam essas alterações sem publicar cada atualização na blockchain, o histórico compartilhado de transações. Quando a cooperação termina, uma transação Bitcoin permite fazer cumprir a divisão. A Lightning transfere assim muitas atualizações para fora da blockchain, enquanto a liquidação final continua apoiada nas regras do Bitcoin. [1]

Um acordo anterior pode atribuir um saldo maior a quem já gastou parte dele. No modelo de revogação descrito na proposta, publicar um estado invalidado permite que a outra parte reaja com uma transação de penalidade. Mas a reação precisa ocorrer dentro de um prazo definido. Portanto, o participante ou um serviço delegado deve acompanhar a blockchain. A consequência prática é importante: a criptografia não torna segura uma desconexão permanente sem monitoramento. Garantir esse acompanhamento faz parte da proteção dos fundos. [1]

O Bitcoin não conhece por conta própria a cotação de uma moeda em certa data. Os Discreet Log Contracts, ou DLC, tratam de contratos cuja liquidação depende dessa informação. Dois participantes preparam as condições e os pagamentos possíveis. Um oracle escolhido, uma fonte externa de dados, assina depois um anúncio do resultado. Os participantes usam esse anúncio para realizar a liquidação correspondente. Nesse modelo, o oracle não guarda o dinheiro deles e nem precisa saber quem utiliza seus anúncios. Ele fornece informação, em vez de administrar uma carteira alheia. [2]

Uma assinatura digital ajuda a identificar quem emitiu uma mensagem e se ela foi alterada. Não comprova que a informação é verdadeira. O oracle pode divulgar uma cotação errada ou não publicar nada. Para esse silêncio, Dryja descreve uma transação de devolução preparada antecipadamente, que pode ser publicada após um prazo combinado. O dinheiro não volta sozinho: essa possibilidade precisa estar prevista no contrato e alguém deve utilizá-la. Escolher uma fonte confiável e planejar como lidar com sua falha continuam sendo cuidados essenciais. [2]

Dryja também pesquisou os dados necessários para um nó verificar pagamentos. UTXO são saídas de transações ainda não gastas: valores individuais com condições para seu uso. O Utreexo permite que um nó verificador represente esse conjunto por um resumo criptográfico compacto, chamado acumulador. O pagamento vem acompanhado de uma prova de que a saída utilizada pertence ao conjunto. Isso reduz a representação armazenada do estado atual. Não elimina a verificação das regras nem transforma todo o histórico do Bitcoin em um arquivo minúsculo. [4]

As provas do Utreexo também precisam chegar ao verificador. Um estado armazenado menor pode exigir mais tráfego de dados. O resumo da pesquisa descreve uma simulação de download da blockchain até o início de 2019: com 500 MB destinados ao cache, uma memória temporária, as provas acrescentaram aproximadamente 25% aos dados baixados. Esses 500 MB não representam toda a memória do nó. É o resultado de um experimento específico, não uma garantia dos requisitos atuais. Disco, memória e transmissão precisam ser considerados juntos. [3]

Na lembrança publicada pelo MIT DCI, Dryja conta como começou informalmente no MIT: levou um computador, conversou sobre Bitcoin e ajudou estudantes. A diretora Neha Narula então perguntou se ele queria trabalhar ali. Mais tarde, os dois também deram aulas juntos. Nesse mesmo texto de despedida, anunciou sua ida para a Lightspark para continuar trabalhando com Bitcoin e Lightning. O relato registra uma etapa da carreira, sem comprovar seu emprego atual. Publicações, código e ideias ajudam a entender sua contribuição melhor do que um único cargo. [5]