Alice mostra Hash(M) para Bob
Alice revela M no futuro
Bob pode conferir que M é a mensagem que gerou o Hash(M) que Alice mostrou anteriormente calculando o hash (resistência à colisão)

Usos

Sorteio justo
Hash chains

hn = Hash(hn-1)

Usado para autenticação de usuários

Servidor guarda

h1000 = Hash(Hash(...(Hash(senha)))

Usuário envia h999

Servidor confere que Hash(h999) = h1000

Servidor guarda h999

Hashes encadeados
- Hash chain + compromisso + dados
- Verificar sequência de dados
- Para provar que M está na cadeia, é necessário revelar todos os Mi na frente de M - O(n)
Merkle Tree
- Hashes em formato de árvore
- Para provar que M está na árvore, é necessário revelar nós vizinhos no caminho até a raíz

Merkle Tree Esparsa
- Mensagem M na folha de posição Hash(M)
- Permite mostrar que M não está na árvore mostrando que tem vazio na posição Hash(M)

Aula 3A - Motivação para Blockchains

Ordenação de Eventos

Solução 1: relógios sincronizados + carimbos de tempo

Problema: necessário confiar nos carimbos

Solução 2: Usar ACT para poder confiar nos carimbos
Solução 3: Blockchain

Blockchain = ACT distribuído

ACT pode publicar hashes em cadeia para garantir ordenamento de eventos
Descentralização: proof of work
- Achar número que Hash(Bloco + número) comece com n zeros
- Tencontrar = O(10n)
- Tverificar = O(1)

Aula 3B - Blockchain sem o hype - Funcionamento

Bitcoin

Ledger digital
Pseudoanonimato

Blockchain: Processando Eventos

Fase 1: propagação
Fase 2: validação (dos eventos, não da veracidade dos dados) e propagação dos blocos

Blockchain: Encadeando Eventos

Blocos: hash do bloco antigo + próprio hash + dados + nonce
Proof of work: encontrar nonce para que Hash(Dados + nonce) comece com n zeros

Blockchain: Consenso

Várias possibilidades (proof of …)
Bitcoin: Proof of Work
- Solução custosa computacionalmente
- Resistente a ataques

Blockchain: Módulos

Aplicação

Validação (ex: Bitcoin)

Consenso distribuído

Visão uniforme da rede

Armazenamento + replicação

Disponibilidade, resistência à censura

Blocos encadeados

Ordenação

Criptografia (hash, ass. digital)

Detecção de alterações (integridade), irretratabilidade

Blockchain: módulos 2 ao 5

Aula 3C - Logs Transparentes

Log Transparente

Apenas módulos 4 e 5
Não precisa de replicação e consenso
Uma única entidade insere blocos e monitores observam alterações
Verificável

Transparência de Certificados

Evitar que sites falsos personifiquem sites verdadeiros no caso do comprometimento de ACs
Log público (árvore de merkel) que permite apenas adição de dados e a verificação da presença de certificados
Todos os certificados das ACs são adicionados
Monitores verificam os nós da árvore e a raíz

Procedimento:

Dono do domínio pede certificado para AC
AC checa a posse do domínio, e cria um pré-certificado (assina domínio com sua chave privada, mas inclui uma extensão para avisar usuários que não devem utilizar esse certificado ainda, pois ele não foi incluído em um log transparente de transparência de certificados)
AC envia o pré-certificado para um provedor de log (ex: Google 'Argon2023' log)
Log responde com um Signed Certificate Timestamp (SCT), que é uma promessa de que o certificado será incluído ao log em breve
Pré certificado é adicionado ao log, e uma nova raíz da merkle tree é assinada
AC recebe SCT e envia SCT + certificado para dono do domínio
Ao visitar um site, navegador dos usuários verifica se o certificado possui um ou mais SCTs
Monitores observam logs para verificar certificados suspeitos, e também podem cobrar de empresas para monitorar seus domínios e notificá-las ao notar mudanças

https://certificate.transparency.dev/howctworks/#stepby

Como a Transparência de Certificados permite que todos vejam todos os certificados, os donos dos domínios podem ficar sabendo quando um certificado para seu domínio for criado e adicionado ao log (através dos monitores, por exemplo). Isso impede situações como sites maliciosos obtendo certificados para um domínio e enviando-os a usuários sem o conhecimento do dono real do domínio.
Ex: hacker compromete AC e emite certificado para si mesmo do domínio banco.com.br. Usuários do banco podem entrar no site do hacker achando que estão no site real. Enquanto isso, o banco não faria ideia de que o hacker possui esse certificado. Transparência de Certificados impede essa situação pois o banco veria no log que foi emitido um novo certificado para o domínio banco.com.br.

Log Transparente: Registro de ativos

Ao registrar ativo em sistema, seu ativo pode ser roubado pelo dono do sistema. Em um blockchain, ele ainda pode ser roubado pelo nó minerador do blockchain
Solução 1:
- enviar Hash(ativo+random) p/ servidor
- após confirmação, enviar dados
- não resolve para solução com servidor, pois ele pode alegar que os dados já estavam no banco de dados
Solução 2:
- enviar Hash(d+r) p/ servidor
- inclusão do hash em log transparente
- envio de d+r ao servidor
- servidor não pode roubar d
- também funciona com blockchain mas é mais custoso desnecessariamente

Aula 3D - Lendas (?) sobre Blockchains

"Imutabilidade"

Blockchain (e hashes) dão integridade mas isso não impede mutações, apenas garante sua detecção

"Irretratabilidade"

Assinaturas digitais dão irretratabilidade
Podem ser inseridas no blockchain

"Veracidade"

O consenso é para a ordem dos dados, não para sua validação
Validação dos dados feita pela camada de aplicação

"Depósito de dados"

Para armazenamento é uma opção muito pouco escalável (replicação dos dados em todos os nós)
Existem outras tecnologias de armazenamento distribuído

"O" Blockchain

Cada pessoa pode criar seu blockchain

"Aberto e anônimo"

Depende de
- quem valida os dados e adiciona blocos
- quem pode enviar dados para a rede
- quem pode visualizar conteúdo do blockchain

"Leve e eficiente"

Parte mais custosa: consenso
Leveza:
- comparação com outras tecnologias como cartórios e transferências internacionais
- em blockchains federados, os mecanismos de consenso podem ser leves

"Pesado"

XRP Ledges é muito eficiente
Simplificações deixam mais eficiente:
- consenso bizantino (nós se conhecem)
- sorteio justo (nós se conhecem)
- revezamento ou votação (nós puníveis na vida real)
Redes federadas
- Todos usuários identificados
- Facilitam consenso leve

Bitcoin leve?

Bitcoin não tem as simplificações mencionadas
- usuários não identificados
- usuários não confiáveis
- proof of stake assumiria que usuários não seriam mal intencionados

Aula 3E - Aplicações de Blockchains

Blockchain: Quando usar?

Ordenação de eventos
Distribuído
Sem confiança entre membros
Não é necessário o instante de tempo
Não é interessante quando ataques envolvem eventos que não precisam ser registrados no blockchain

Como criar soluções

Defina o problema
Modele usando ACT
- Se resolver, blockchain provavelmente resolve também
- Pode ser que um log transparente baste

Blockchain: Pagamentos

Transferência de ativos (moedas)
Transferências intranacionais são mais fáceis com PIX
Transferências entre bancos internacionais são mais fáceis com BTC
Ripple Net: como BTC mas tem menos demora para pagamentos, menos gasto de energia, menor volatilidade, menor taxa e serve para câmbio entre moedas

Blockchain: outros ativos

Contratos diversos
- Ex: jogador de futebol, imóvel
- Substitui cartório
Contratos inteligentes: não necessariamente associados a blockchains
- programas com lógica de contrato
- blockchain: ordenação no tempo dos contratos
Locked transactions
Transferência de ativos reais
- Necessário "tokenizar" ativos
- Casos mais fáceis: casa (n.o de matrícula), veículo, pessoas (CPF)
- Casos mais difíceis: produtos sem identificação única (ex: vacas, trigo, etc)
- Mesmo após tokenizar: como garantir que ações sobre ativos reais se refletem no blockchain - digital twin
Normalmente é preciso de auditoria por entidade confiável
Fungibilidade: capacidade de um ativo de ser substituído por outro de mesma quantidade e qualidade sem problemas (ex: Bitcoins são fungíveis)
Itens que requerem confirmação da data de criação (ex: arte, patentes) podem ser registradas em cartório, ACT, ou como Tokens Não Fungíveis (NFT) em blockchain

Aula 3F - Aplicações Questionáveis com Blockchains

Blockchain: Aplicações Revolucionárias (?)

Coleta de assinaturas para projeto de lei de iniciativa popular

Problema : câmara diz não conseguir verificar tantas assinaturas, e projeto acaba sendo adotado por parlamentar

Solução: Blockchain?

Para verificar assinaturas, basta utilizar assinaturas digitais verificáveis (certificados digitais, p. ex, com ICP). O Blockchain garantiria a ordem dos votos, o que é desnecessário

Provar que tomou vacina

Problema : site do Ministério da Saúde sai do ar

Solução: Blockchain?

Não requer ordenação, apenas disponibilidade e assinaturas digitais do ministério nos comprovantes de vacinação.

Log transparente serviria para impedir a entidade de saúde de reescrever o passado, por exemplo dizer que alguém tomou a vacina há 3 anos, ou excluir um comprovante (irretratabilidade), mas não impediria a criação de um comprovante falso no instante. A posse de uma assinatura digital também já bastaria para a irretratabilidade.

Votação eletrônica: registro de votos em blockchain

Problema : como saber se o voto foi contabilizado? (saber se a urna registrou o número que apertei e se ao contarem os votos no TSE vão contar corretamente)

Solução: Blockchain?

Não requer ordenação, inclusive a ordem poderia comprometer o sigilo do voto.

Solução real, com software honesto: assinaturas digitais e divulgação dos resultados pela urna.

Solução real, sem software honesto: impressão do voto para conferir com os votos digitais. Auditabilidade fim-a-fim: entregar comprovantes aos usuários para conferirem.

Log transparente seria interessante para publicar os dados de forma que nem o TSE possa alterá-los sem detecção.

Verificação de dados reais quaisquer

Problema : como saber se o usuário tem a experiência que ele alega em certa atividade?

Solução: Blockchain?

Não tem ordem. Blockchain não verifica os dados, apenas entra em consenso a respeito da ordem deles.

Solução real: sistemas de reputação (reclame aqui, assinaturas digitais para votos de bom/ruim)

Plataforma padronizada para/ compartilhamento de documentos

Problema : empresas com formatos internos diversos

Solução: Blockchain?

Não há necessidade de ordenar eventos. Empresas padronizam documentos para colocar no blockchain - blockchain só serve como desculpa para entrar em um acordo de padronização.

Diversas linguagens de padronização: RDF, JSON, XML, Gellish

" Problema de transparência global"

Problema : eliminar informações privilegiadas

Solução: Blockchain?

Para resolver o problema, todos teriam que inserir suas informações no blockchain, então elas deixariam de ser privilegiadas. Mas nada impede os usuários de simplesmente não inserir informações no blockchain nesse caso, pois o registro de eventos não é necessário para a operação do sistema, como seria no bitcoin, por exemplo ("obriga" os usuários a incluir transações)

Auditoria de Redes Definidas por Software (SDN)

Problema : Log das ações do controlador

Solução: Blockchain?

O controlador é uma entidade confiável, então os switches da rede podem armazenar as instruções assinadas do controlador localmente.

Validação de componentes fornecendo um serviço

Problema : como garantir que contêiner não está comprometido? (executando algo que não deveria)

Solução: registrar os processos dos contêineres num Blockchain?

Blockchain não garante a validade dos dados

Não tem ordenação de eventos

Plataforma SPIFFE faz essas verificações sem blockchain

Identidades centradas no usuário

Problema : contas para tudo

Solução: Blockchain?

Não tem ordenação de eventos

Soluções reais: OpenID, OAuth, Web Of Trust

Aula 3G - Privacidade em Blockchains

O que esconder?

Identidades
- Quem é o usuário real
- Origens e destinos de transações
Quantias
- Valor de transações
Metadados
- Lógica de contratos inteligentes

Por que esconder?

Mesmo princípio do sigilo bancário
Empresas: informações estratégicas
Pessoas: segurança
Criminosos: atividades ilegais

Graus de anonimato

Anonimato fraco (pseudoanonimato)
- Um só identificador
- Pro: permite criar sistema de reputação
- Contra: perda de anonimato se qualquer evento for relacionado ao usuário (inferências)
Anonimato forte
- Pro: previne ligações entre diferentes eventos de mesmo usuário
- Contra: dificulta reputação
Possível ter ambos
- Ex: fraco para auditores, forte para outros usuários

Privacidade em pagamentos

BTC/ETH
- Pseudoanonimato
- Transferências e conteúdos públicos (origem, destino, valor)
- Exchanges: conhecem identidades dos usuários que as usam
Operadoras tradicionais (bancos, cartões)
- Transferências privadas
- Identidades conhecidas pelo operador
Zcash/Monero
- Transferências públicas
- Conteúdo privado (origem, destino, valores)

Privacidade (?) no Bitcoin

ID da conta: hash de chave pública
- Gerado pelo usuário
- Pseudoanonimato
Recomendações em redes abertas
- Usar identificadores distintos para cada transação (receber moedas e enviar "troco")
- Ocultar endereço de IP ao fazer transações (ex: TOR)
- Não usar intermediários com política de Know Your Customer (KYC), como exchanges
- Mesmo assim tem problemas, por exemplo, se alguém enviar moedas de 2 contas diferentes para outra pessoa que só possui 1 conta, pode-se associar as duas contas do enviador.

Técnicas de Privacidade

Mixing

Moedas misturadas entre usuários
Ilegal em alguns países
Problemas:
- Mixer pode revelar usuários
- Mixer pode cobrar taxas
- Mixer pode roubar fundos
Mixing sem mixer
- Coin Join, Tornado Cash
- Assinatura de todos os usuários
- Saída: mínimo de todas as entradas
- Problemas:
  - Requer interação entre usuários
  - Se um usuário gastar uma moeda do mixing, anula o processo
  - Quantias transferidas permanecem públicas

Criptomoedas com privacidade: origem oculta

Assinatura em anel (ex: Cripto Note)

Anel: grupo de usuários com chaves públicas ui e privadas ri.
Assinatura si calculada usando apenas um ri não pode ser atribuída ao usuário i, mas pode ser verificada com qualquer ui dos membros do anel, ou seja, pode ter sido gerada por qualquer um deles.
A definição do anel não requer interação entre usuários.
Duas assinaturas si e si' feitas com a mesma chave podem ser detectadas.
A moeda Monero usa anéis com a >= 16

Criptomoedas com privacidade: destino oculto

Endereços "furtivos" (stealth) (ex: Monero)

Cada usuário tem 2 pares de chaves (privada, pública), um de visualização (a, A=aG) e outro de transação (b, B=bG)
A posse da chave privada de visualização "a" permite saber se a transação é destinada ao usuário que possui "a"
A posse das chaves privadas de visualização e transação (a, b) permite gastar valores em transações

R: Chave Diffire Hellman efêmera gerada no emissor

Conferir se a transação é para usuário:

D = H(aR) + b

Chave para transacionar:

H(aR) + b

Criptomoedas com privacidade: valor oculto

Monero: valores apenas visualizados com chave de visualização
Pedersen Commitments: esconde cada entrada na transação, mas permite operações aritméticas de soma/ subtração entre esses valores, então é possível verificar que o input da transação é igual ao output (previne "gerar" moedas na transação)
Ring Confidential Transactions (Ring CT): permite provar que uma entrada foi "consumida" com a chave de transação correspondente, sem revelar qual entrada
Bulletproofs: permite verificar que cada entrada na transação é um valor positivo dentro de certa faixa (previne que sejam feitas transações que criam dívidas)
Zcash também oculta origem, destino e valores, mas utiliza apenas um protocolo (zk-SNARKs)

Aula 3H - Forks (Bifurcações)

Relembrando: Forks

Nós não estão em consenso a respeito da ordem dos blocos
Pode ser um dissenso temporário, resolvido quando a rede naturalmente entra em consenso com novos blocos

Atualizações: Mudando regras

Governança
- Desempenho (por exemplo, aumentar tamanho do bloco, mudar mecanismo de consenso)
- Segurança (correção de bugs, atualização de algoritmos criptográficos, atualizar lista de nós na federação)
- Funcionalidade (adicionar suporte a contratos inteligentes)
A gestão da rede é distribuída, alguns nós podem não atualizar as mudanças

Soft forks e Hard forks

Causados por atualizações nas regras do blockchain
Retrocompatibilidade: nós atualizados falam com nós desatualizados?

3 tipos de blocos:

blocos gerados na v1, compatíveis com v2
blocos gerados na v1, não compatíveis com a v2
blocos gerados na v2

É gerada bifurcação, com uma cadeia apenas com nós desatualizados e outra com nós atualizados e desatualizados. Quando a cadeia atualizada fica maior que a desatualizada, ela será abortada.

Adoção: alguns nós não se atualizam e continuam na cadeia desatualizada, e outros geram uma nova cadeia atualizada. Registros pré fork são duplicados
Soft fork: atualização com retrocompatibilidade e todos adotam eventualmente
Hard fork: não há retrocompatibilidade ou usuários não aceitam (se usuários resolverem aceitar no futuro, pode tornar-se um soft fork)

Soft e hard forks: exemplos

Bitcoin: blocos pequenos em 2015. Duas propostas:

Segregated Witness: tirar as assinaturas do bloco. Aumentaria bloco em 2x e evitaria operações maliciosas sobre o ID das transações
Aumentar o tamanho do bloco: 8 ou 32x maior. Poderia ser necessário cancelar mais transações quando uma for inválida.
Hard fork: não se chegou ao consenso. Moedas foram duplicadas entre Bitcoin e Bitcoin Cash

Ethereum: Incidente DAO

Crowdfunding com blockchain
Bug no contrato: 50M roubados
Propostas:
- Não aceitar moedas roubadas (não rolou)
- Não fazer nada
- Desfazer transações a partir do momento do roubo
Maioria da rede optou por desfazer, enquanto alguns continuaram considerando o roubo: Ethereum e Ethereum Classic

← Back to Home