Bug nos Smart Contracts aciona um alerta jurídico

Na última quinta-feira [02/12] o blog “Schneier on Security” divulgou o caso [e deu início a uma discussão técnica] do hacker que roubou US $ 31 milhões da empresa de blockchain MonoX Finance, explorando um bug no software que o serviço usa para redigir contratos inteligentes.

Imagem: Pexels.com

Especificamente, o atacante usou o mesmo token tanto para o tokenIn quanto para o tokenOut, que são métodos para trocar o valor de um token por outro neste tipo de operação. Funciona mais ou menos assim: O MonoX atualiza os preços após cada troca, calculando novos preços para ambos os tokens [in e out]. Quando a troca é concluída, o preço do tokenIn, ou seja, o token que é enviado pelo usuário, diminui, e o preço do tokenOut, o token recebido pelo usuário, aumenta.

Ao usar o mesmo token para as diferentes operações de tokenIn e tokenOut, o hacker inflou muito o preço do token MONO porque a atualização do tokenOut sobrescreveu a atualização de preço do tokenIn. O hacker então trocou o token por $ 31 milhões em tokens nas blockchains Ethereum e Polygon.

O problema básico neste evento é que, na arquitetura da blockchain, o código é a autoridade final – não há um protocolo de adjudicação. Então, se houver uma vulnerabilidade no código, não há recurso possível [e, claro, existem muitas vulnerabilidades no código].

Para muito observadores, incluindo Bruce Schneier, essa é uma razão suficiente para não usar contratos inteligentes para algo importante, por enquanto.

Os sistemas de adjudicação baseados na intervenção humana não são uma inútil bagagem humana pré Internet. Eles são vitais.

Bruce Schneier

Código de programação versus arbitragem humana

Na modesta opinião deste bloguista, embora, de fato, estejamos muito longe de o código ser um árbitro da justiça melhor do que um ser humano, acho que o problema básico aqui tem menos a ver com o código sendo a autoridade final e mais a ver com a falta de um protocolo de adjudicação.

No momento, não há uma boa maneira de ajustar retrospectivamente os resultados desses chamados contratos “inteligentes” com base em conhecimentos ou fatos que só podem ser totalmente apreciados ex post ao invés de ex ante, seja o conhecimento de funcionalidades não intencionais do código ou circunstâncias específicas não antecipadas pelas partes contratantes.

Este parece ser um problema bem compreendido por profissionais do direito e um aspecto amplamente suportado por diversos sistemas jurídicos (por meio de várias doutrinas, como quebra de expectativa ou previsibilidade). Já os tecnologistas proponentes de contratos inteligentes [incluindo a mim] parecem não ter ainda uma visão clara desses aspectos.

Uma transferência legítima de acordo com as regras codificadas

Para além do ‘problema básico’ descrito acima, existe um outro problema não menos básico e que se não for tratado corretamente deixará os “Contratos Inteligentes” para sempre quebrados: a maioria dos programadores normalmente escreve código sequencial limitado, não código de máquina de estado completo. Assim, uma grande quantidade elementos computacionais é deixada de fora na implementação dos contratos. Esses elementos, portanto, ficam “pendurados” e esperando para ser usados [e abusados].

Alguns críticos da blockchain dos contratos inteligentes argumentam que seria necessário incorporar uma versão forte da chamada Lógica de Hoare para garantir a integridade da computação na blockchain. A lógica de Hoare é um conjunto fundamental de regras, publicadas no final dos anos 1960. O bloco fundamental da Lógica de Hoare é a Tripla de Hoare.

Uma tripla de Hoare é da forma

{P} C {Q}

Onde {P} e {Q} são afirmações sobre o estado do sistema e C é um comando.

P, é a pré-condição
Q, é a pós-condição

Onde as asserções P e Q são expressas como fórmulas na lógica de predicados.

Quando a pré-condição P é atendida, a execução do comando C causa mudanças no sistema e estabelece a pós-condição Q.

Embora seja possível construir um código de “estado completo” com a lógica de Hoare, não é algo que a maioria das pessoas goste de fazer. Em suma, é um processo tedioso, não criativo, e colocar os pingos nos i’s e cruzar os t’s podem ser tarefas incrivelmente tediosas. Portanto, raramente é implementada, o que acaba inevitavelmente trazendo problemas em um tempo futuro.

Na vida normal, a última coisa que alguém realmente deseja é ter contratos irrevogáveis. Então a arbitragem geralmente fica “embutida” informalmente nos contratos inteligentes, através de métodos ad hoc. Em princípio, não há razão para que os contratos inteligentes não possam ter arbitragem embutida. Mas isso apenas cria uma série de questões subsequentes que ninguém quer abordar.

Até que a arbitragem de fato ou o controle total do estado sejam implementados nos Smart Contracts, veremos muito mais desse tipo de coisa acontecendo.

Move fast, break things

Eu temo que o problema descrito aqui seja um resultado lógico da abordagem “mova-se rápido e quebre coisas” preconizadas pelo Manifesto Ágil. As pessoas precisam pensar com clareza sobre até onde [e se] podemos utilizar certos paradigmas de desenvolvimento de sistemas na construção da infraestrutura da blockchain.

E como eu disse em outros posts aqui, precisamos parar de chamar as coisas de “inteligentes” quando elas são estúpidas. Antigamente, um dispositivo que não era útil sem uma conexão de rede era apropriadamente chamado de terminal burro. O código é sempre vulnerável, e qualquer desenvolvedor que não entenda isso é um “stupid hire”.

Facebook Muda de Nome Rumo ao Metaverso

O Facebook costumava ser visto de forma positiva pelos usuários, pois conectava o mundo e aproximava as pessoas. Isso não é mais o caso. Tem havido escândalos após escândalos e os usuários agora associam o Facebook a todas as coisas negativas que o Facebook dizia combater.

Imagem: Pexels

Neste ponto da história, o Facebook não pode mais vencer a guerra para ganhar os corações e mentes das pessoas a respeito uma série de questões. Então, em vez disso, ele precisa construir “uma nova narrativa”. A empresa está, assim, abandonando o nome e a marca Facebook e se concentrando em uma nova visão em torno do chamado Metaverso.

Não importa se essa visão é possível ou não, ou se a realidade virtual (RV) vai ou não se tornar o próximo paradigma de interação social. O importante é que trata-se de um segmento novo e interessante para construir uma nova marca e Mark Zuckerberg não quer perder a oportunidade.

O metaverso em minha opinião, sempre foi um grande embaraço. O Second Life existe há 20 anos e ainda é uma novidade divertida. O que o Facebook quer é adicionar publicidade e conteúdos de marca e fazer um second-life mais caro devido aos requisitos de hardware de última geração [além de torná-lo mais lento, com uma interface mais difícil – porque é RV].

Ninguém descobriu ainda uma maneira de proporcionar uma boa experiência de usuário em sistemas de realidade virtual, e também nenhum “caso de uso matador”. Não acho que o Facebook seja particularmente capaz de lançar algo que possa competir com qualquer coisa que a Microsoft ou a Apple possam lançar. Todos os CEOs que compram essa ideia de metaverso só falam sobre o universo de possibilidades, mas sinto que a única possibilidade que estão eles perseguindo é construir um Wal-Mart na Times Square.

A maioria desses CEOs aponta com aprovação o execrável [filme] “Jogador 1” como exemplo de uma visão a ser realizada. Eu sinto muito, mas penso que um garoto excitado de 15 anos raspando os pêlos do corpo para ser mais aerodinâmico na RV, enquanto se envolve em extensos monólogos de autocongratulação sobre como ele é um cara legal por não sentir repulsa por sua namorada “rubenesca”, enquanto recita versos de Ghostbusters em uma série de vinhetas incoerentes do tipo “lembra disso?”, não é uma visão para o futuro.

É uma pena porque acho que há obviamente usos legítimos para a telepresença via RV. Ela pode ser a próxima fronteira da videochamada, o que parece estar de acordo com a missão declarada do Facebook de conectar o mundo. Mas, suspeito que na realidade tudo o que nós teremos será um videogame extremamente ruim em vez disso – será que eles também terão NFTs?.

Posso ver como pode ser frustrante administrar uma empresa cheia de esforços diferentes, alguns dos quais pretendem ser novidadeiros ou pelo menos representar uma mudança de direção. Mas, debalde todos os esforços, ainda assim não deixam de ser percebidos e lembrados como mais uma coisa azul.

Espero que essa jogada permita que Zuckerberg permaneça tecnologicamente relevante, ocupando o lugar ao qual seus dons pessoais o levaram, em vez de ficar atolado em questões sobre os padrões éticos [ou falta de] em suas plataformas usadas por adolescentes e crianças.

Idealmente, uma plataforma ética também poderia ser cultivada por meio de algum tipo de transferência de parte do poder tecnológico acumulado pelas Big Techs à comunidade, de alguma forma. Um dos maiores desafios para o futuro é, em minha opinião, permitir que tais sistemas éticos se desenvolvam de forma padronizada, mas de maneira diversa. Em um mundo ideal, cada nova comunidade ou grupo deve ter sua própria dinâmica psicológica e merece a oportunidade de existir sem ser arrastada para a mesmice da(s) plataforma(s) por um conjunto agressivo, irritado ou tóxico de usuários.

Sinceramente, me deprime que esse revival do termo metaverso esteja sendo levado a sério e que provavelmente irá grudar no vocabulário como o desprezível termo “nuvem” e, pior, que o desenvolvimento dessas tecnologias esteja sendo conduzido por uma empresa como o Facebook.

Pessoalmente não estou interessado na visão particular de Mark Zuckerberg sobre o metaverso. Em vez disso, tenho medo de quantos mais caminhos errados podemos tomar no modo como desenvolvemos nossa tecnologia da informação e a aplicamos na sociedade. A visão FOSS [Free Open-Source Software – software livre] da computação, em que o progresso do software é compartilhado e atua como um equalizador, e onde as pessoas controlam o comportamento do seu software é o que precisamos, e não um lixo novo e melhor de vigilância-vigilância-propaganda-usuário-hostil [Agora em 3D!]

Voltaremos ao tema, certamente.

Multiplique sua Estimativa por Pi

A estimativa de projetos é uma arte hermética, em nenhum lugar isso é mais verdadeiro do que no desenvolvimento de sistemas computacionais. Certa vez, ouvi falar de uma misteriosa confraria de numerólogos, que multiplicavam suas estimativas de tempo por π. A prática supostamente dava a eles uma margem de segurança suficiente para definir novos requisitos, testes, iteração e outras mudanças aleatórias no escopo do projeto.

Imagem: Pexels

Isso me pareceu curioso e arbitrário, mas fiquei intrigado. Depois de refletir um tanto, pude colocar a conjectura da estimativa circular (CEC) em bases matemáticas sólidas.

Alguém – um designer, seu líder, o produtor executivo, um amigo, sua mãe – pede que você faça algo. Você pensa um pouco, faz algumas anotações, considera o que é necessário e apresenta um projeto e uma estimativa de tempo para a conclusão.

Mas as coisas mudam. Acontece que havia algumas coisas que seu designer/ líder/produtor/ amigo/mãe esqueceu de mencionar e, à medida que você fazia o trabalho, sugiram algumas ideias para estender o projeto um pouco mais. Seu escopo cresceu.

E é claro que nem tudo correu bem. Sua primeira tentativa foi um fracasso [instrutivo]. Então você focou na segunda tentativa e acabou criando uma serie de problemas que demoraram um tanto mais para serem ajustados. Você gastou dois dias extras para encontrar uma solução alternativa. Em suma, você seguiu um caminho positivamente tortuoso até seu objetivo.

Quanto tempo demorou a sua jornada em comparação com o plano original? Parece que os numerólogos estavam certos…

E aí está – não importa o que você pense quando começa um projeto. Depois de passar pela pesquisa, design, discussões, protótipos, falhas, testes, rotatividade de requisitos e todos os outros caprichos do processo criativo, você certamente terá gasto π vezes o tempo que você planejou originalmente.

Alguns podem questionar meu rigor matemático e até mesmo contestar o que acredito ser a conclusão incontestável. Alguém poderá alegar que o multiplicador correto não é de fato π – mas 2, ou √2, ou e, ou a razão áurea φ. No entanto, não conheço ninguém que chegue a alegar que o multiplicador seja < 1.

Independentemente de quaisquer inclinações numerológicas, o argumento é que você se permita admitir que no início de um projeto você a) não tem o panorama completo, b) você não sabe como as coisas vão se encaminhar, e c) há trabalho pela frente sobre coisas que você ainda não tem ideia.

Nenhuma quantidade de planejamento e análise de tarefas pode mudar isso, então não tente. Em vez disso, dê a si mesmo uma reserva de tempo plausível e então mergulhe no trabalho.

Ah, e aquela lista de tarefas que você fez no fim de semana passado? Não é por acaso que você conseguiu concluir apenas cerca de um terço dos itens da lista. 😉

Os Perigos do Software Evidencial – ou Quem Garante o Bafômetro?

No Lawfare Blog, Susan Landau escreve um excelente ensaio sobre os riscos apresentados pelos aplicativos usados em dispositivos de coleta de evidências (um bafômetro é provavelmente o exemplo mais óbvio). Bugs e vulnerabilidades nessa classe de equipamento podem levar a evidências imprecisas. Para compor o problema, a natureza proprietária do software torna difícil para a equipe de defesa dos réus examiná-lo. A seguir um brevíssimo resumo da essência do material.

Imagem: iStock

[…]

Os engenheiros de software propuseram um teste de três partes.

Primeiro, o tribunal deve ter acesso ao “Log de erros conhecidos”, algo que deve fazer parte de qualquer bom projeto de software desenvolvido profissionalmente.

Em seguida, o tribunal deve considerar se as provas apresentadas podem ser afetadas materialmente por um erro de software. Ladkin e seus co-autores observaram que a maioria das funcionalidades não apresentará erro, mas o momento preciso em que o software registra o uso do dispositivo pode facilmente estar incorreto.

Finalmente, os especialistas em confiabilidade recomendaram verificar se o código adere a um determinado padrão da indústria usado em uma versão não computadorizada da tarefa (por exemplo, os contadores sempre registram todas as transações – portanto, o software usado na contabilidade também deve registrar).

[…]

Objetos inanimados há muito servem como prova em tribunais: a maçaneta da porta contendo uma impressão digital, a luva encontrada na cena de um crime, o resultado do bafômetro que mostra um nível de álcool no sangue três vezes o limite legal. Mas o último desses exemplos é substancialmente diferente dos outros dois. Os dados de um bafômetro não são a entidade física em si, mas sim um cálculo de um software a respeito do nível de álcool no hálito de um motorista potencialmente bêbado. Desde que a amostra de respiração tenha sido preservada, pode-se sempre voltar e testá-la novamente em um dispositivo diferente.

O que acontece se o software cometer um erro e não houver mais nenhuma amostra para verificar? Ou, e se o próprio software produzir a evidência contra o réu? No momento em que escrevemos este artigo, não havia nenhum precedente no qual a lei permita que o próprio réu examine o código subjacente.

[…]

Dada a alta taxa de erros em sistemas de software complexos, meus colegas e eu concluímos que, quando programas de computador produzem uma prova, os tribunais não podem presumir que o software probatório seja confiável. Em vez disso, a acusação deve disponibilizar o código para uma “auditoria contraditória” pelos especialistas designados pelo réu[1]. E para evitar problemas em que o governo não tenha o código para que este seja inspecionado, os contratos de compras governamentais devem incluir a garantia de entrega do código-fonte do software adquirido – código que seja mais ou menos legível pelas pessoas – para cada versão do código ou dispositivo.

Ler o trabalho na íntegra [em inglês] em Lawfare Blog.

* * *

O comentário pertinente é: o Estado pode exigir calibração regular do bafômetro, mas quem os inspeciona? Há garantia de que o poder público multará a polícia por não verificar se os bafômetros estão calibrados de forma adequada além de estar também funcionando corretamente? E quem calibra os calibradores?

Se nenhuma amostra da respiração for retida, apenas o registro da observação do software, como a leitura de um bafômetro é essencialmente diferente de um boato ou palavra-de-boca? Será porque o bafômetro é “tecnológico”? Assumir que o instrumento é mais preciso que uma testemunha humana, apenas porque é tecnológico, gera outros grandes problemas conceituais.

Mas acho que o ponto mais amplo é este: dada a quase total falta de responsabilidade da indústria do software, a inescrutabilidade do código proprietário e a qualidade duvidosa da maioria do software comercial, um tribunal – que busca a verdade – não deve acolher prima facie evidências que consistam exclusivamente do resultado de um software.

Este não é um problema técnico, mas um problema legal causado por políticas inadequadas: a indústria do software precisa de regulamentação, responsabilidade e reforma das leis de direitos autorais.

[1] Um especialista que consultei – que um dia estará escrevendo neste espaço, gentilmente me explicou [o que agradeço penhoradamente] que esse protocolo não existe no ordenamento brasileiro. Mas da explicação depreendo que a lei brasileira pode comportar soluções análogas a essa.