O problema com transações criptográficas hoje

Web3 e DeFi hoje não estão prontos para usuários comuns; é muito confuso, arriscado e caro para quem não é um cabeça de criptografia dedicado.

Há algumas coisas óbvias que precisam ser corrigidas, como a horrível experiência do desenvolvedor e o requisito maluco de gerenciar uma frase inicial longa para fazer backup de uma conta com segurança. Mas há outra grande barreira que não chama muita atenção: as transações não fazem sentido e não dão aos usuários e desenvolvedores o controle de que precisam para usar essa tecnologia tão nova com confiança .

O problema não é apenas da interface do usuário da carteira; na verdade, é principalmente um problema com a arquitetura da própria plataforma L-1. As transações de hoje são definidas de forma limitada por suposições de tecnologia, em vez de serem definidas pelas necessidades e expectativas dos desenvolvedores e usuários que irão interagir com eles todos os dias. Nenhuma carteira pode contornar essas limitações.

É por isso que a Radix teve que redefinir o conceito de transações do zero como parte de sua pilha de tecnologia completa .

O resultado é uma das vantagens mais poderosas do Radix, corrigindo uma variedade surpreendente de problemas importantes de DeFi, como experiência de usuário de carteira insegura, interoperabilidade difícil de dApp, negociação de sanduíche e a impossibilidade de pagamento de taxa delegada. Ele também permite que o Radix Wallet apresente transações para usuários como este, de forma totalmente confiável:

Mas antes de chegarmos à solução da Radix, vamos falar sobre por que as transações de hoje precisam tanto de uma revisão.

O que há em uma transação?

Para entender o quão profundo é o problema com as transações, temos que falar sobre o que realmente é uma transação blockchain .

O conteúdo de uma transação em um blockchain de contrato inteligente hoje é muito impulsionado pela tecnologia. Na maioria das redes de contratos inteligentes, tudo é um contrato inteligente - não apenas a lógica dApp, mas a definição dos próprios ativos . Dentro das restrições desse modelo, não surpreende que uma transação seja definida como uma chamada para um contrato inteligente .

Isso significa que nessas redes, a parte principal de uma transação é essencialmente uma mensagem enviada para um único contrato inteligente, contendo todos os dados necessários para dizer o que fazer.

Quando o contrato inteligente recebe essa mensagem, ele pode fazer algumas alterações em seus próprios dados internos e pode chamar outros contratos inteligentes nos bastidores (como contratos inteligentes de token ERC-20) que, por sua vez, fazem algumas alterações em seus dados internos.

Tudo e qualquer coisa que aconteça como resultado dessa transação deve ser iniciado por essa única mensagem para o contrato inteligente.

Um pouco mais é necessário antes que a transação possa ser enviada à rede. A chamada de contrato inteligente é assinada por uma única chave privada de conta como o “chamador”, e esse chamador informa à rede quanto está disposto a gastar dessa conta para taxas de rede (ou “gás”).

De um modo geral, é tudo o que a transação contém: uma mensagem para um contrato inteligente, uma assinatura da carteira do usuário e uma especificação das taxas de rede a serem pagas .

Então qual é o problema?

Essa forma de definir uma “transação” funciona, tecnicamente falando, mas deixa muito a desejar porque não descreve as coisas da maneira que o usuário assinaria. Como usuário, posso estar tentando fazer uma transação que troque tokens por meio de um DEX, ou compre um NFT, ou faça um empréstimo – mas o que estou assinando é sempre apenas uma única mensagem para uma caixa preta de contrato inteligente que eu a esperança fará o que eu espero.

Esse design de transação de “mensagem para uma caixa preta” cria algumas deficiências sérias que muitas vezes podemos considerar como certas na criptografia hoje:

• Os usuários da carteira (e software de carteira) não podem saber os resultados reais da transação . A carteira só sabe que um determinado contrato inteligente está sendo chamado. Todos os resultados da transação são alterações internas confirmadas pela lógica interna do contrato inteligente que é praticamente incognoscível com antecedência. De fato, em muitas cadeias, o usuário assina um hash da chamada do contrato inteligente, tornando-o ainda mais obscuro.

  
  

• Os usuários não podem se proteger de “comércio sanduíche” ou derrapagem . Tomando o exemplo de um DEX, a única maneira de oferecer ao usuário proteção contra derrapagem é o contrato inteligente DEX oferecê-lo como parte de sua lógica interna (e o usuário confiar nessa implementação).

  
  

• Os padrões de autorização são muito simplistas . A única maneira de um usuário se autorizar a contratos inteligentes é por meio de sua assinatura de chave de conta única. Qualquer coisa mais complicada significa (você adivinhou) implantar outro contrato inteligente.

  
  

• Compor vários contratos inteligentes significa implantar outro contrato inteligente . A transação precisa de seu único ponto de entrada, que pode fazer várias chamadas para outros contratos inteligentes. Isso significa que a composição requer planejamento antecipado e é trabalhoso e rígido.

  
  

• dApps não podem pagar taxas de rede em nome de seus usuários . O padrão de chamador de signatário único significa que apenas essa conta de usuário pode pagar a taxa.

  
  

Existem várias propostas que buscam reduzir a gravidade dessas deficiências do modelo de transação fundamental, contornando-as. Por exemplo, a “abstração de conta” do ERC-4337 permite (entre outras coisas) a possibilidade de uma forma de pagamento de taxa delegada, mas ao custo de significativa complexidade do sistema e risco .

Não importa quais soluções alternativas sejam adicionadas, no entanto, permanece o problema de que as transações não funcionam da maneira que os usuários ou desenvolvedores gostariam - se a tecnologia da plataforma não fosse a limitação .

Para corrigir os problemas acima, precisamos redefinir o conceito de transações para que sejam muito mais poderosas e flexíveis. Eles devem dar aos desenvolvedores mais poder para definir diretamente interações mais complexas e devem colocar o usuário no controle do que é importante para eles quando assinam, em vez de ter que confiar na lógica de contrato inteligente de caixa preta.

No próximo blog, falaremos sobre como a Radix faz exatamente isso com um novo tipo de design de transação, possibilitado pela plataforma full-stack exclusiva da Radix.