Joseph Poon

Comprar um café não exige informar o mundo inteiro. Na camada base do Bitcoin, porém, uma rede de computadores verifica o pagamento e o registra em um histórico comum. Joseph Poon e Thaddeus Dryja buscaram aliviar esse trabalho por meio de canais de pagamento. A proposta indicada é de 14 de janeiro de 2016 e traz DRAFT 0.5.9.2. Foi um começo importante para a Lightning; seus componentes atuais também resultam do trabalho de outras pessoas. [1]

Imagine Anna e Pavel depositando bitcoins em um canal. Depois, assinam novas divisões desse valor: após um pagamento, Anna tem uma parte menor e Pavel uma maior. Cada mudança não precisa entrar no histórico público. Uma transação Bitcoin permite exigir a divisão final. Em uma disputa, também importam a reação a um estado antigo e o cumprimento dos prazos. Proteger os fundos inclui acompanhar o que acontece, não apenas guardar o saldo mais recente. [1]

O destinatário não precisa compartilhar um canal direto com o remetente. O pagamento pode passar por outros participantes usando um HTLC, condição que liga o pagamento a um valor secreto e a um prazo. A BOLT 2 chama o valor revelado de payment_preimage e sua impressão digital criptográfica, conhecida previamente, de payment_hash. O programa verifica a correspondência. Encontrar uma rota não garante sucesso: as condições precisam ser cumpridas, e erros ou prazos vencidos exigem tratamento de falha. [3]

Carteiras e nós de desenvolvedores diferentes precisam de regras comuns mais detalhadas que uma proposta geral. As BOLTs, especificações da Lightning, cumprem esse papel. Descrevem mensagens, rotas de pagamento e estruturas de transações, e continuam evoluindo. Ser coautor do whitepaper não torna Poon autor de cada alteração posterior. Para entender um programa atual, também é preciso consultar sua documentação e a especificação correspondente. [2]

Poon também escreveu com Vitalik Buterin o rascunho de trabalho Plasma de 11 de agosto de 2017. Não se trata de um canal de pagamento Bitcoin. São propostas cadeias subordinadas que processam transações e recorrem a uma cadeia superior, como Ethereum, para fazer cumprir as regras. Em vez de uma rede de acordos entre pares, surge uma hierarquia de blockchains. O objetivo comum de deslocar trabalho para fora da camada base não implica mecanismos ou riscos iguais. [4]

A Plasma normalmente publica na cadeia raiz compromissos criptográficos compactos, semelhantes a impressões digitais verificáveis dos registros. Os detalhes ficam fora dela. Uma impressão ajuda a verificar dados apresentados, mas não permite ler dados ausentes. Demonstrar fraude exige os registros pertinentes. Ocultá-los continua sendo um problema próprio: publicar um hash não garante que o usuário receba tudo de que precisa para defender seus fundos. [4]

Na Plasma, é essencial saber como retirar os fundos se uma cadeia subordinada falhar. A proposta inclui retiradas com espera e a possibilidade de contestar pedidos incorretos. Pressupõe uma cadeia raiz disponível e funcionando corretamente, onde executar o procedimento necessário. Não promete retirada imediata diante de qualquer falha. Regras de saída, disponibilidade de dados e prazos fazem parte da segurança. [4]

O documento posterior Plasma Contracts descreve explicitamente pesquisa comunitária. Ao lado de Joseph Poon, cita pessoas como Dan Robinson e Kelvin Fichter e não endossa nenhum projeto específico. Usar o nome Plasma em um serviço não comprova, por si só, a recomendação do autor. A contribuição de Poon aparece nos documentos e nas perguntas que abriram: o que pode sair da blockchain e como o usuário ainda pode exigir a liquidação correta? [5]