$30 off During Our Annual Pro Sale. View Details »

Papers We Love: Bitcoin - A Peer-to-Peer Electronic Cash System

AF
January 20, 2021

Papers We Love: Bitcoin - A Peer-to-Peer Electronic Cash System

Apresentação com comentários da leitura do artigo Bitcoin: A Peer-to-Peer Electronic Cash System realizada para o grupo Papers We Love de Joinville.

https://www.meetup.com/pt-BR/papers-we-love-joinville/events/275500577/

AF

January 20, 2021
Tweet

More Decks by AF

Other Decks in Technology

Transcript

  1. Bitcoin: A Peer-to-Peer
    Electronic Cash System
    Satoshi Nakamoto
    Papers We Love Jlle #1
    20/01/2021

    View Slide

  2. Porque ler este artigo?
    ● Um dos documentos mais importantes para entender os building blocks
    de cryptocurrencies;
    ● Entender o que motivou a criação do Bitcoin;
    ● Entender de forma introdutória como o Bitcoin funciona;
    ● Paper seminal que juntou as partes e deu origem à tecnologia blockchain.
    A implementação do Bitcoin tem muitas especificidades e diferenças.

    View Slide

  3. Como ler um artigo científico?
    Como eu faço:
    1. Ler Abstract, Introdução e Conclusão
    a. Queremos antes de qualquer coisa saber se o artigo nos interessa
    2. Escanear o miolo
    a. Determinar o propósito e a estrutura
    3. Ler com cuidado
    a. Grifar e anotar
    b. Buscar resumo sobre conceitos que não entende
    4. Criticar os argumentos
    a. Faz sentido? Existem contradições? Pontos fortes, fracos do argumento
    b. Comparar com outros trabalhos
    c. Buscar outros artigos que fazem citação
    5. Buscar as referências deste artigo

    View Slide

  4. Abstract

    View Slide

  5. Introdução
    Problema
    ● E-commerce sobre da fraqueza do modelo baseado em confiança;
    ● Instituições financeiras revertem transações;
    ● Isso aumenta o custo de transação limitando o tamanho delas e
    restringindo transações menores; Caras e lentas? 🤔
    ● Mercadores precisam de informações do cliente para evitar fraudes;
    ● Um percentual de fraudes é aceitável.

    View Slide

  6. Introdução
    Proposta:
    ● Sistema de pagamento eletrônico sem intermediários baseado em
    provas criptográficas ao invés de confiança;
    ● Solução para o double spending problem usando um timestamp
    server distribuído baseado em peer-to-peer para gerar provas
    criptográficas da ordem correta das transações;
    ● O sistema se mantém seguro desde que a maioria dos nós sejam
    honestos.

    View Slide

  7. Dissecando algumas ideias

    View Slide

  8. Peer-to-Peer (P2P)
    ● Uma arquitetura de sistema distribuídos onde cada nó da rede funciona
    tanto como servidor como cliente, eliminando a necessidade de um
    servidor central;
    ● Ótimo para artefatos que podem ser replicados;
    ● Para artefatos que não podem ser replicados impõe desafios;
    ● Torrent, SoulSeek, DNS.
    https://pt.wikipedia.org/wiki/Peer-to-peer centralizado p2p

    View Slide

  9. Double Spending Problem
    ● Falha de sistema onde um agente consegue gastar as mesmas moedas
    mais de um vez;
    ● Grande problema de transações digital, dado que artefatos digitais
    podem ser duplicados;
    ● De forma centralizada esse problema é resolvido com a presença de uma
    entidade que verifica fraudes e autoriza ou não as transações;
    ● Na versão distribuída se faz uso de um protocolo para lidar com
    tentativas de gasto duplo.
    https://en.wikipedia.org/wiki/Double-spending

    View Slide

  10. Digital Distributed Ledger (livro-razão)
    ● Uma moeda baseada na internet é um ledger distribuído que guarda:
    ○ Quantas moedas pertencem para cada endereço da rede;
    ○ Transações que ocorreram.

    View Slide

  11. Double Spending Problem

    View Slide

  12. Hayek Money
    Nos anos 70 Hayek propõe que qualquer instituição
    financeira deveria poder distribuir suas moedas. Em
    um sistema de moedas concorrentes, os agentes
    escolhem em qual moeda e instituição emissora
    confiam mais, pressionando o governo para ser
    mais cauteloso com nosso dinheiro.
    Apesar das comparações, Bitcoin vai além da
    proposta do Hayek.
    Mas para Hayek, essas moedas ainda estariam
    atreladas a instituições regulamentadas pelo estado
    e que podem expandir ou contrair a oferta
    monetária.

    View Slide

  13. Crítica
    ● O argumento apresentado não se sustenta. Bitcoin é mais lento e mais
    caro que outros tipos de transação eletrônica hoje em dia. Não só em
    termos financeiros.
    https://www.nature.com/articles/s41558-018-0321-8

    View Slide

  14. Crítica
    ● Visa é capaz de processar 47.000 transações por segundo;
    ● Bitcoin suporta cerca de 7 tps com um limite de bloco de 1MB;
    ○ Foi proposto aumento do tamanho do bloco, porém ...
    ○ Para obter uma capacidade equivalente a Visa o limite seria quase 8 gigabytes por bloco
    Bitcoin. Isto resultaria em 400 TB ao ano.
    ● Sulução proposta: Lightning Network:
    ○ Permite que a informação trafegue através da rede passando por intermediários
    minimamente confiáveis (sub-redes baseadas em stacking), proporcionando que um nó
    possa pagar qualquer outro nó mesmo que eles não tenham um canal direto aberto
    entre eles.
    https://en.wikipedia.org/wiki/Bitcoin_scalability_problem

    View Slide

  15. Transactions
    https://nakamotoinstitute.org/bitcoin/

    View Slide

  16. Transactions
    ● Problema: como o recebedor pode verificar que o emissor double-spend
    the coin?
    ○ Solução tradicional: entidade centralizadora que media transações.
    ● Se ocorrer double-spend, a primeira transação é que conta, ignora as
    outras;
    ● Para conseguir validar, precisamos conhecer todas as transações, ou seja,
    todas precisam ser públicas:
    ○ Isso parece esquisito, mas transações de compra e venda de ações na bolsa é público.
    ● E os participantes da rede precisam concordar em seguir uma única
    versão da ordem de transações.
    https://en.wikipedia.org/wiki/Unspent_transaction_output

    View Slide

  17. Transactions
    ● O emissor gera uma chave pública e uma privada;
    ● Assina a transação que garante que ela é autêntica;
    ● Envia a chave pública junto com a transação assinada para a rede;
    ● A chave pública pode ser usada para validar se a transação foi mesmo
    feita pelo emissor e não por uma parte terceira.
    Problema:
    ● Evitamos que alguém faça uma transação em nosso nome, porém, não
    evitamos que alguém faça duas transações fraudulentas;
    ● Como os participantes da rede Bitcoin concordam em um único histórico
    da ordem em que as transações foram recebidas? Timestamp server.

    View Slide

  18. Transactions

    View Slide

  19. Transactions
    https://www.blockchain.com/charts/transactions-per-second

    View Slide

  20. Transactions Demo
    https://andersbrownworth.com/blockchain/public-private-keys/transaction

    View Slide

  21. Timestamp Server
    ● Gera um hash de um bloco contendo uma lista de transações realizadas e
    publica na rede;
    ● Prova que os dados devem ter existido na época;
    ● Garante ordem histórica das transações;
    ● Cada timestamp inclui o anterior em seu hash, formando uma cadeia,
    com cada timestamp adicional reforçando os que vieram antes dele.

    View Slide

  22. Timestamp Server
    Garantimos uma sequência de transações, mas aparece um novo problema:
    E se eu forçar a emissão de um blockchain secundário na rede? Posso
    reescrever o histórico de transações.
    Como podemos evitar um ataque na rede, onde vários nós reescrevem o
    histórico mudando a ordem das transações? Isso se resolve na próxima seção
    com Proof of Work.

    View Slide

  23. Timestamp Server
    ● É por isso que que o Bitcoin mantém um mempool! (não citado no paper);
    ● Transações não são descartadas ou aceitas imediatamente.
    Um blockchain é uma linked list distribuída, onde o
    endereço de do nó anterior é o hash do cabeçalho, ao invés
    do endereço de memória de uma lista tradicional.

    View Slide

  24. Mempool
    https://www.blockchain.com/charts/mempool-count
    ● Memória temporária
    onde novas transações
    são guardadas para
    serem processadas pelos
    mineradores e um novo
    bloco ser gerado;
    ● Mineradores podem
    escolher quais
    transações processar!
    (problema de Incentivos)

    View Slide

  25. Block anatomy

    View Slide

  26. Transaction anatomy

    View Slide

  27. Transaction anatomy
    https://en.bitcoin.it/wiki/Script
    https://github.com/bitcoin/bips

    View Slide

  28. Proof of Work
    ● Forma dos nós concordarem com quais transações são válidas;
    ● Envolve procurar um valor que quando calculado o hash, o mesmo
    comece com um número específico de zeros. Dado o algoritmo de hash
    usado (sha256 aqui), o trabalho cresce de forma exponencial ao número
    de bits zero requeridos.

    View Slide

  29. Proof of Work
    ● "um voto por CPU" (não previram as Mining Farms);
    ● A decisão da maioria é representada pela cadeia mais longa;
    ● Todas as transações em um bloco específico são consideradas ocorridas
    ao mesmo tempo, e cada bloco é vinculado a uma cadeia de outros
    blocos com timestamp em ordem cronológica.

    View Slide

  30. Proof of Work
    ● Se a maioria do poder de CPU é controlado por nós honestos, a cadeia
    honesta vai crescer mais rápido e superar quaisquer cadeias
    concorrentes;
    ● Para modificar um bloco passado, o atacante terá de refazer a
    prova-de-trabalho do bloco e depois de todos os blocos posteriores e, em
    seguida, alcançar e superar o trabalho dos nós honestos.

    View Slide

  31. Proof of Work
    ● É por isso que exchanges validam com certeza uma transação após X
    blocos serem gerados. No geral, 6 blocos. Isso é demonstrado na seção
    11 (Calculations);
    ● É possível enganar a rede com 51% das CPUs!

    View Slide

  32. Proof of Work

    View Slide

  33. Proof of Work

    View Slide

  34. Hashcash (parênteses)
    Proposta original do Proof-of-Work citado no artigo;
    ● Proposto em 97 para evitar spam em sistemas de e-mail:
    ○ Hashcash - A Denial of Service Counter-Measure (Adam Back);
    ○ Baseado em uma ideia de 92! Pricing via Processing or Combatting Junk Mail (Cynthia
    Dwork,Moni Naor).
    The hypothesis is that spammers, whose business model relies on their ability
    to send large numbers of emails with very little cost per message, will cease to
    be profitable if there is even a small cost for each spam they send. Receivers
    can verify whether a sender made such an investment and use the results to
    help filter email.

    View Slide

  35. Proof of Work Demo
    https://andersbrownworth.com/blockchain/coinbase

    View Slide

  36. Network
    ● Se dois nós transmitem versões diferentes do próximo bloco;
    simultaneamente, os nós da rede consideram o primeiro que receberam;
    ● Consideram a cadeia mais longa como correta e continuarão trabalhando
    para estendê-la;
    ● Espera-se que eventualmente chegue-se a um consenso.

    View Slide

  37. Incentive
    ● A primeira transação em um novo bloco é uma recompensa para o
    minerador. Um incentivo para suportarem a rede;
    ● É possível pagar uma taxa de mineração também, fazendo com o que o
    minerador escolha as transações com maiores taxas no mempool para
    serem processadas primeiro;
    ● Define-se o limite de moedas na rede, mas não a quantidade;
    ● Se atacantes forem capazes de reunir mais poder de CPU do que todos os
    nós honestos, eles teriam que escolher entre usá-lo para roubar
    pagamentos (tirando a confiança e quebrando o sistema) ou usá-lo para
    gerar novas moedas.
    https://en.wikipedia.org/wiki/Expected_utility_hypothesis

    View Slide

  38. Custo de um ataque

    View Slide

  39. Incentive (halving)
    ● Jan 2009 - Nov 2012: 50 BTC;
    ● Nov 2012 - Jul 2016: 25 BTC;
    ● Jul 2016 - Feb 2020: 12.5 BTC;
    ● Feb 2020 - Sep 2023: 6.25 BTC.
    Média por bloco: 10 minutos
    https://en.wikipedia.org/wiki/Expected_utility_hypothesis

    View Slide

  40. Incentivos (dificuldade mineração)

    View Slide

  41. Reclaiming Disk Space
    O hash das transações é gerado a partir de uma estrutura de Merkle Tree
    (data compression), dessa forma não precisa-se carregar todos os dados
    sempre, podendo cortar nós da árvore economizando espaço em disco.

    View Slide

  42. Simplified Payment Verification
    Não é necessário ser um minerador para participar da rede. É possível enviar
    e receber transações, e verificar transações feitas, sem manter o histórico
    completo da rede, porém não é possível verificar se as transações são válidas.

    View Slide

  43. Combining and Splitting Value
    Para permitir que o valor seja dividido e combinado, as transações contém
    múltiplas entradas e saídas. Podem existir várias entradas, mas no máximo
    duas saídas: uma para o pagamento, e outra retornando o troco para o
    remetente.

    View Slide

  44. Considerações
    ● Em nenhum momento no paper se fala na quantidade de Bitcoin;
    ● Em nenhum momento no paper se fala na taxa de mudança da
    dificuldade do PoW (Muda a cada 4 anos no bitcoin);
    ● Pouco se fala da estruturas de dados dos blocos e transações;
    ● Não entramos em detalhes da evolução do sistema:
    ○ Scripting;
    ○ Lightning Network;
    ○ SegWit.

    View Slide

  45. Ideias que vieram antes
    ● Secure digital transactions (Nick Szabo, 2005);
    ● Cryptography to secure transactions (DigiCash, 1989);
    ● Criação de dinheiro fora do sistema governamental (B-Money);
    ● Proof-of-Work (Hashcash).

    View Slide

  46. Complete Token Demo
    https://andersbrownworth.com/blockchain/public-private-keys/blockchain

    View Slide

  47. Papers We Love

    View Slide

  48. Próximo encontro
    Sugestão de tema: protocolos de consenso.

    View Slide

  49. Outras referências
    ● Livro Mastering Blockchain;
    ● Diferenças da implementação e Whitepaper:
    https://gist.github.com/harding/dabea3d83c695e6b937bf090eddf2bb3
    ● Versions of Bitcoin: https://bitcoin.org/en/version-history;
    ● Desenvolvimento: https://bitcoincore.org
    ● Cypherpunk Manifesto:
    https://github.com/NakamotoInstitute/nakamotoinstitute.org/blob/maste
    r/sni/static/docs/cypherpunk-manifesto.txt

    View Slide