Agradecimentos especiais a Jun Jiang da DePHY Network e Ryan Soury da Usher Labs pelo feedback e insights.
Em 2008, os alarmes em Wall Street soaram enquanto traders sofisticados mergulhavam em um frenesi primitivo. Instituições financeiras superalavancadas, entrando em colapso sob o peso de títulos lastreados em hipotecas subprime, deixaram banqueiros gananciosos expostos e implorando por resgates. Os bancos centrais, desesperados para manter seu controle sobre o poder, pagaram pelos pecados dos banqueiros com o talão de cheques do homem comum. Essa traição expôs as falhas do sistema monetário centralizado, revelando a necessidade de um sistema financeiro mais novo, mais livre e mais justo. Assim como a Revolução Americana e a constituição que se seguiu separaram igreja e estado, uma nova revolução chamada Bitcoin surgiu para separar dinheiro e estado, permitindo muitas das mesmas liberdades e liberdades fundamentais para a autodeterminação.
A tecnologia blockchain é uma tecnologia de liberdade. Ela nos permite construir sistemas financeiros, de identidade, de informação e de coordenação social que não exigem confiança em um intermediário centralizado. As liberdades individuais prosperam em um mundo onde o banco central não controla o fluxo de dinheiro, uma única plataforma não controla o discurso social e uma única empresa não controla as identidades digitais.
Muitas das diferenças entre este novo mundo e onde estamos hoje estão nas capacidades técnicas das plataformas blockchain. A primeira geração de contratos inteligentes foi a ponta do iceberg que permitiu esses sistemas de liberdade; no entanto, eles são fundamentalmente limitados em suas capacidades. Neste artigo, explico algumas das limitações críticas nos contratos inteligentes atuais e como um novo sistema, “SQL Smart Contracts”, fornece uma base tecnicamente mais capaz para desbloquear as liberdades humanas e concretizar o potencial do blockchain como uma nova plataforma de computação.
“O problema raiz… é toda a confiança necessária para fazê-lo funcionar.” - Satoshi Nakamoto
A propriedade central inicial de um blockchain é a imutabilidade; uma vez que um certo limite de stakeholders (ou “nós”) em uma rede concorda que algo é verdade, o blockchain manterá um registro permanente dessa verdade. Blockchains usam uma variedade de mecanismos de “prova” nos quais os nós gastam grandes quantidades de valor na forma de poder de computação, participação financeira ou reputação para garantir que atores maliciosos não possam manipular a verdade.
Se o Bitcoin é a “máquina da verdade” para moeda digital, o Ethereum é a “máquina da verdade” para produtos financeiros mais complexos. O Ethereum expande as capacidades do Bitcoin criando um espaço de design programável onde os desenvolvedores podem implementar qualquer lógica a ser implantada, verificada e executada em uma série de nós. Isso significa que agora podemos criar sistemas que removem a necessidade de confiança em uma autoridade central além da moeda! Qualquer sistema que exija autoridades centrais — como empréstimos, escrituras imobiliárias, informações de identidade, mídia social, métricas econômicas, etc. — agora pode operar sem intermediários centrais. Este é um mundo inteiramente novo!
Um contrato inteligente é um programa que os desenvolvedores escrevem e implantam em um blockchain, a tela para os desenvolvedores criarem aplicativos descentralizados. O termo “contrato inteligente” não significa um contrato legal onde duas partes estão vinculadas a certos direitos e obrigações. Em vez disso, um “contrato inteligente” significa simplesmente que o aplicativo tem garantia de funcionar exatamente como o código é escrito indefinidamente. Os contratos de empréstimo garantem que os tomadores e credores sempre podem fazer transações. Os contratos imobiliários garantem que as pessoas sempre podem verificar e transferir a propriedade da propriedade. Um contrato inteligente é um aplicativo onde o código se torna lei.
Steve Jobs chamou o computador de “uma bicicleta para a mente”. Contratos inteligentes garantem que as rodas nunca caiam.
“A criptomoeda não é apenas sobre negociar tokens, é parte de um ethos mais amplo de proteger a liberdade e a privacidade e manter o poder nas mãos do pequeno.” - Vitalik Buterin
Embora os contratos inteligentes Ethereum tenham introduzido um mundo totalmente novo de produtos descentralizados, limitações fundamentais em seu design e capacidades de manipulação de dados os impedem de serem eficazes em muitas aplicações além das criptomoedas.
No Solidity (uma linguagem de programação para Ethereum), os dados do contrato são armazenados em pares de chave-valor. Embora structs (agrupamentos de variáveis) e mapeamentos (coleção de pares de chave-valor) apresentem maneiras úteis de organizar dados, todos os dados só podem ser recuperados por sua chave. Considere um contrato teórico para armazenar dados de identidade do usuário:
contract IdentityStorage { // Struct to store KYC details struct identity { string fullName; string dateOfBirth; string residentialAddress; } // mapping a country to its citizens to their info // "Canada" => 0x123… => {Vitalik Buterin, 01/31/1994, ...} mapping(string => mapping(address => identity)) public idData; //...rest of contract }
Neste contrato, o registro de identidade de um usuário só pode ser recuperado sabendo o país e o endereço da carteira do usuário. A menos que o implementador do contrato redesenhe o contrato inteligente para ter manipulação de dados de alto custo de gás, não há outras maneiras para o usuário do contrato recuperar um registro de identidade. Armazenar dados em pares de chave-valor limita, em última análise, como os dados podem ser acessados e manipulados.
Em particular, o gerenciamento de dados em contratos inteligentes Ethereum apresenta dois problemas fundamentais: dependência de índice e dependência de caminho de acesso.
Dependência de índice significa que para acessar um dado específico, os dados devem estar disponíveis em um índice. Um índice é uma estrutura de dados que busca eficientemente um identificador exclusivo dentro de uma coleção. No exemplo de contrato KYC acima, os registros são acessíveis somente através do endereço Ethereum exato usado para a chave. Essa estrutura de indexação rígida impede que os usuários do contrato consultem os dados com base em outros critérios, como "Quais usuários têm esse endereço residencial?" ou "Qual porcentagem de usuários com essa identidade nacional nasceram depois de 1º de janeiro de 1970?" Sem a capacidade de executar tais consultas, os desenvolvedores não têm flexibilidade para agregar, analisar e construir lógica de aplicativo em torno dos dados do contrato. Quando os desenvolvedores precisam dessa flexibilidade adicional, como recuperar um registro de identidade pelo nome completo, todo o contrato precisa ser reestruturado. No Ethereum, a reestruturação de índices também pode aumentar os custos de gás de um contrato, dificultando ainda mais a usabilidade do contrato.
A dependência do caminho de acesso se refere a dados sendo acessíveis e compreensíveis somente por meio de um caminho de recuperação específico. No contrato de exemplo, saber o país e o endereço da carteira de Vitalik permitiria que um desenvolvedor recuperasse seu registro de identidade. No entanto, saber apenas o endereço da carteira não permitiria que um desenvolvedor obtivesse o país de origem de Vitalik. Além disso, mesmo que o desenvolvedor tenha o endereço da carteira de Vitalik, ele não pode obter seu registro de identidade a menos que também saiba o país de origem (a chave “Canadá”). O caminho de acesso ao registro de identidade de Vitalik é fixo; se um desenvolvedor precisasse tentar recuperar seu registro apenas pelo endereço da carteira, todo o contrato precisaria ser reestruturado. A dependência do caminho de acesso significa que os dados são acessíveis e significativos somente em uma direção, limitando a capacidade de consultar ou interpretar os dados de diferentes perspectivas.
A dependência de índice e caminho de acesso apresenta desafios significativos para aplicativos que exigem um modelo de dados complexo ou em evolução. Embora as criptomoedas tenham estruturas de dados simples que podem ser implementadas no Ethereum (os tokens ERC20 são essencialmente apenas um mapeamento de endereços para saldos), esses desafios se tornam problemáticos para aplicativos com uso mais intensivo de dados. Quando um aplicativo precisa armazenar, consultar e manipular um modelo de dados complexo, o armazenamento básico de chave-valor do Ethereum torna o gerenciamento de dados significativamente mais limitante, tornando desafiador construir e manter aplicativos que exigem gerenciamento de dados complexo.
“A história não se repete, mas muitas vezes rima” – Mark Twain
Em 1970, Edgar F. Codd, um cientista da computação da IBM, publicou um artigo chamado “A Relational Model of Data for Large Shared Data Banks”. Na época, o tipo mais popular de banco de dados de aplicativo era o "banco de dados hierárquico", que usava uma estrutura rígida, semelhante a uma árvore, onde cada pedaço de dados era armazenado em um diretório pai, semelhante a como os arquivos são organizados em um computador. Codd argumentou contra o banco de dados hierárquico, propondo um banco de dados relacional mais novo, mais simples e muito mais capaz, com uma estrutura tabular.
A estrutura em árvore do banco de dados hierárquico significa que os dados só podem ser acessados por meio do sistema rígido de compreensão do relacionamento pai-filho de cada pedaço de dado. Em particular, Codd identificou três problemas principais com o sistema hierárquico:
Dependência de ordenação: O resultado de uma consulta geralmente depende de como os dados são organizados no armazenamento. Se um aplicativo for criado assumindo que os dados serão consultados na mesma ordem em que são armazenados, a ordem não poderá ser alterada no futuro.
Dependência de Índice: Para acessar um pedaço específico de dados, o aplicativo deve conhecer o pai (ou seja, um índice). Caso contrário, recuperar os dados solicitados é impossível.
Dependência do Caminho de Acesso: Acessar ou entender dados requer seguir um caminho de recuperação específico. Se o aplicativo for projetado para recuperar dados usando um padrão de acesso específico, ele não pode recuperar ou interpretar os mesmos dados usando caminhos alternativos.
Isso parece familiar? Embora os contratos inteligentes do Ethereum não tenham dependência de ordenação (os mapas não são ordenados), as mesmas limitações de dependência de índice e caminho de acesso que seguravam os bancos de dados nas décadas de 1960 e 1970 estão segurando as plataformas de contratos inteligentes hoje.
Limitações no nível do banco de dados são mais do que um contratempo trivial; elas fundamentalmente restringem os desenvolvedores e limitam os tipos de aplicativos criados em uma plataforma. Em vez de se concentrarem na implementação de novos recursos, os desenvolvedores que lutam contra a dependência de índice e caminho de acesso devem despender uma quantidade extraordinária de esforço para manter a funcionalidade de um aplicativo existente. Durante as décadas de 1960 e 1970, o uso do banco de dados era reservado principalmente para tarefas comerciais rígidas, como gerenciamento de estoque, contabilidade e processamento geral de dados; os desenvolvedores não tinham a flexibilidade de dados para criar aplicativos mais sofisticados. No entanto, após a introdução de bancos de dados relacionais, surgiram aplicativos significativamente mais expressivos e intensivos em dados, levando ao surgimento de sistemas ERP, CRMs e ferramentas de inteligência empresarial. Além disso, com o advento da Internet, esses avanços abriram caminho para plataformas de comércio eletrônico e aplicativos de mídia social. Os desenvolvedores puderam implementar recursos que antes exigiriam que um banco de dados inteiro fosse reestruturado com apenas algumas linhas de SQL. O banco de dados relacional foi mais do que uma mudança de paradigma; foi uma plataforma de criação de categorias que permitiu que aplicativos fundamentalmente novos surgissem.
Hoje, as plataformas de blockchain são semelhantes aos computadores e bancos de dados da década de 1970. A falta de processamento de dados capaz no nível de blockchain significa que os desenvolvedores não podem implementar aplicativos descentralizados mais sofisticados e intensivos em dados. Se o caso de uso primário para blockchains se expandir além da criptomoeda, precisamos de plataformas de blockchain com funcionalidade de processamento de dados mais capaz.
"A medida da inteligência é a capacidade de mudar." - Albert Einstein
Assim como a comercialização do banco de dados relacional na década de 1980 levou à proliferação de novos aplicativos, a integração de bancos de dados relacionais em plataformas de blockchain tem o mesmo potencial de remodelar os tipos de aplicativos descentralizados que podem ser criados.
Na Kwil, estamos construindo uma plataforma de blockchain e uma linguagem de contrato inteligente que permite aos desenvolvedores construir aplicativos descentralizados que aproveitam a expressividade total do SQL. Com a Kwil, os desenvolvedores podem aproveitar a flexibilidade do modelo relacional para criar aplicativos descentralizados mais capazes e intensivos em dados.
Considere o mesmo exemplo de armazenamento de identidade anterior. Em vez de armazenar registros de identidade em um mapa onde cada registro é acessível somente por sua chave, o Kwil permite que os desenvolvedores armazenem os registros em uma tabela e aproveitem uma sintaxe SQL flexível para consultar a tabela:
database user_registry; table identities { address uuid primary key, name text notnull, date_of_birth int notnull, residential_address text notnull, national_id int notnull, #country_index index(national_id) } action query_by_national_id ($id) public view { SELECT * FROM identities WHERE national_id = $id; } action query_by_dob ($dob) public view { SELECT * FROM identities WHERE date_of_birth > $dob; }
No contrato inteligente original do Ethereum, não havia como pesquisar as identidades e retornar todos os usuários, dada uma condição (como ID nacional) ou associar uma carteira com base em um atributo específico (como uma data de nascimento). Habilitar tal funcionalidade exigiria a reestruturação do contrato para adicionar funções caras e intensivas em gás. No entanto, com o modelo relacional, os desenvolvedores podem executar essas consultas sem nenhuma reestruturação necessária, ganhando assim mais flexibilidade de manipulação de dados sem incorrer em custos adicionais.
Por exemplo, a rede idOS é um blockchain soberano construído com Kwil, permitindo que usuários e dApps armazenem informações de credenciais de usuários. Aproveitar SQL sobre a rede idOS permite:
Usuários podem ser associados e recuperáveis por diversas carteiras, credenciais e atributos.
Protocolos DeFi para realizar análises agregadas de onde seus usuários são.
Protocolos de stablecoin para avaliar quais usuários são de áreas de alto risco.
Habilitar o modelo relacional e o SQL em uma plataforma blockchain descentralizada nos permite criar aplicativos fundamentalmente novos que não podem existir nos contratos inteligentes Ethereum existentes.
O modelo relacional que revolucionou a indústria da computação há 40 anos tem as mesmas capacidades para revolucionar a indústria de blockchain hoje. Nas décadas de 1960 e 1970, a dependência de índice e caminho de acesso limitava a utilidade do banco de dados hierárquico em aplicativos intensivos em dados. Hoje, a mesma dependência de índice e caminho de acesso limita os contratos inteligentes Ethereum e sua capacidade de alimentar plataformas descentralizadas com modelos de dados complexos. No entanto, ao integrar o modelo relacional ao blockchain e fornecer aos desenvolvedores o mesmo dialeto SQL expressivo, podemos desbloquear novos tipos de aplicativos. Assim como o banco de dados relacional acelerou a demanda empresarial e ajudou os computadores a atingir a adoção generalizada, ele pode ajudar as plataformas de blockchain a fazer o mesmo, desbloqueando assim um mundo digital mais livre, mais descentralizado e mais confiável.