Reusable Proofs of Work

Em 15 de agosto de 2004, Hal Finney convidou os participantes de uma lista de discussão sobre criptografia a experimentar o seu novo projeto. Partia do Hashcash de Adam Back: o computador testa diferentes entradas até encontrar um resultado que satisfaça uma condição definida. A procura custa tempo de processamento; verificar o resultado é rápido. Chamamos a isso Proof of Work, uma prova de trabalho. Na proteção contra mensagens de spam, pode funcionar como um selo postal pago em cálculos. Finney queria saber se a prova poderia depois passar de pessoa para pessoa, em vez de perder a utilidade após um único uso. É isso que significa RPOW: provas de trabalho reutilizáveis. [1] [2] [4]

Imagine que Ana tem uma ficha digital válida e a envia a Pedro. Se apenas transmitiu um ficheiro, pode ter guardado uma cópia. Pedro apresenta a ficha ao servidor RPOW e pede a troca. O servidor verifica se ainda não foi usada, marca-a como consumida e assina uma nova, preparada pelo programa de Pedro. A cópia da ficha antiga que Ana conserva deixa de servir para outra troca. Pedro pode enviar a nova a Eva, que repete o processo. Reutiliza-se o valor transmitido, não o mesmo ficheiro indefinidamente válido. Enquanto o destinatário não concluir a troca, o remetente ainda pode gastar a ficha original antes dele. [2] [11]

A entrada podia ser um Hashcash acabado de calcular ou uma ficha RPOW ainda não utilizada. A saída era uma ficha nova com uma assinatura digital RSA, uma confirmação do servidor verificável matematicamente. RSA é um método de cálculo dessa assinatura: uma chave secreta permite criá-la, enquanto a chave pública correspondente permite verificá-la. Trata-se de dados numéricos verificáveis, não de uma imagem de uma assinatura manuscrita. A assinatura permitia verificar a origem, mas não dizia, por si só, se a ficha já tinha sido trocada. Para isso existia o registo das entradas utilizadas. Nas transferências seguintes não era necessário repetir sempre a procura dispendiosa do Hashcash: uma nova assinatura era obtida em troca da invalidação da prova anterior. Não se reciclava eletricidade nem se multiplicava gratuitamente um direito sobre trabalho já realizado. [2]

O valor indicava um nível de dificuldade computacional, não um preço em coroas ou dólares. O Hashcash da época usava SHA-1, uma função que cria uma impressão numérica curta a partir de dados, e procurava uma impressão com determinado número de bits iniciais a zero. Um bit é um algarismo binário. Cada zero adicional exigido duplica aproximadamente o número médio de tentativas. Assim, uma ficha de nível 21 representava o mesmo trabalho esperado que duas de nível 20 e podia ser dividida nelas. Ao juntar ou dividir fichas, era necessário conservar a soma desse valor computacional. Não havia, porém, uma taxa de câmbio fixa nem garantia de poder de compra: computadores mais rápidos podiam produzir o mesmo tipo de ficha a menor custo. [2] [10]

Double spend significa gastar duas vezes o mesmo valor. Para o impedir, RPOW precisava de uma lista de provas já trocadas. A base de dados completa não ficava dentro da placa protegida: era guardada no computador anfitrião comum. A placa conservava uma impressão de controlo do estado da base e verificava provas criptográficas nas consultas. Usava o princípio de Merkle Tree, uma árvore de impressões que permite verificar parte dos dados contra uma impressão comum. O objetivo era detetar tanto alterações de registos como o regresso a uma base antiga onde ainda não constasse uma ficha acabada de gastar. Sem essa proteção, o operador poderia transformar repetidamente a mesma entrada em novas fichas. [3]

O servidor realizava operações sensíveis dentro de uma IBM 4758, uma placa de computação autónoma instalada num computador comum. Devia proteger as chaves de assinatura e o estado sensível mesmo contra o proprietário da máquina. Ao detetar uma intervenção física, podia apagar os segredos. O computador anfitrião transmitia mensagens e guardava a base, mas o projeto não confiava nele. Esse era o centro da ideia de Finney: operar o servidor não devia dar o poder de criar fichas arbitrariamente. A proteção dependia, contudo, do funcionamento correto do hardware, do programa e da proteção das chaves. Não era uma promessa incondicional de invulnerabilidade. [3] [9]

Publicar o código-fonte não basta: o operador pode mostrar um programa e executar outro. RPOW usava por isso remote attestation, a atestação remota da configuração. A placa fornecia informação assinada sobre o programa em execução. Uma pessoa interessada podia compilar o código publicado com as ferramentas correspondentes e comparar a impressão da imagem do programa resultante com a impressão anunciada. Não se comparava simplesmente o texto do ficheiro de código-fonte. A confiança nas assinaturas passava por uma cadeia de certificados até uma chave da IBM. Isso ajudava a verificar o programa realmente executado, mas não provava a ausência de erros nem a infalibilidade do fabricante ou dos seus procedimentos de certificação. [3] [9]

RPOW lembra eCash pela troca de fichas digitais, mas o funcionamento original descrito não protegia a privacidade através de assinaturas cegas. Finney contava com uma ligação cifrada até à placa protegida e com um programa verificável que não guardava relações entre fichas emitidas e recebidas. O computador anfitrião não deveria ver o seu conteúdo em claro. Ainda podia, no entanto, observar o endereço de rede do cliente, o momento e o volume da comunicação. Apresentar novamente a mesma ficha também permitia relacionar certos acontecimentos. A documentação preservada já descreve o suporte para Tor, uma rede que encaminha a ligação por vários intermediários e esconde do servidor o endereço de rede original do utilizador. As assinaturas cegas, por outro lado, aparecem como um possível acrescento futuro. Essa função planeada não deve ser apresentada como parte do funcionamento descrito na altura. [8] [10]

RPOW foi além de uma proposta em papel: tinha um servidor a funcionar e um programa cliente disponível. Finney avisou desde o início, porém, que era uma versão experimental inicial. Uma alteração necessária no programa do servidor podia invalidar fichas anteriormente emitidas. O projeto destinava-as a utilização pessoal, experimental e não comercial, não a dinheiro com valor garantido. Nem uma placa protegida podia obrigar o operador a manter o servidor ligado. O projeto original terminou; as páginas e o código preservados são material histórico. A descrição daquele SHA-1, de RSA e do hardware não é uma recomendação para construir hoje um serviço de pagamentos. [1] [4] [5] [7]

Finney queria demonstrar na prática parte da ideia de Bit Gold de Nick Szabo: criar um objeto digital pode exigir trabalho dispendioso, e esse objeto pode depois ser transmitido. A documentação de RPOW também previa a cooperação de vários servidores, pelo que resumir todo o projeto a um único computador para sempre seria simplista. Contudo, cada ficha indicava o servidor onde devia ser trocada; acrescentar máquinas não eliminava essa dependência por si só. Bitcoin seguiu outro caminho. Nós independentes, ou seja, computadores com software de verificação, conferem regras comuns e um histórico público. Os mineiros competem para acrescentar novos blocos válidos: conjuntos de transações ligados ao registo anterior. RPOW ajuda assim a perceber o que Proof of Work não resolve sozinho: como reconhecer a ordem válida das transferências e em quem é preciso confiar para isso. [1] [6] [11]