El problema con las transacciones criptográficas hoy

Web3 y DeFi hoy no están listos para los usuarios principales; todo es demasiado confuso, arriesgado y costoso para cualquiera que no sea un experto en criptografía.

Hay algunas cosas obvias que deben corregirse, como la horrible experiencia del desarrollador y el requisito loco de administrar una frase inicial larga para hacer una copia de seguridad de una cuenta. Pero hay otra gran barrera que no recibe mucha atención: las transacciones no tienen sentido y no brindan a los usuarios y desarrolladores el control que necesitan para usar con confianza esta nueva tecnología .

El problema no es solo de la interfaz de usuario de la billetera; de hecho, es principalmente un problema con la arquitectura de la propia plataforma L-1. Las transacciones de hoy se definen de una manera que está limitada por suposiciones tecnológicas en lugar de estar definidas por las necesidades y expectativas de los desarrolladores y usuarios que interactuarán con ellas todos los días. Ninguna billetera puede eludir estas limitaciones.

Es por eso que Radix tuvo que redefinir el concepto de transacciones desde cero como parte de su pila de tecnología completa .

El resultado es una de las ventajas más poderosas de Radix, que soluciona una sorprendente variedad de problemas importantes de DeFi, como la experiencia insegura del usuario de la billetera, la interoperabilidad difícil de dApp, el comercio sándwich y la imposibilidad de pago de tarifas delegadas. También permite que Radix Wallet presente transacciones a los usuarios de esta manera, sin confianza:

Pero antes de llegar a la solución de Radix, hablemos de por qué las transacciones actuales necesitan una revisión.

¿Qué hay en una transacción?

Para comprender cuán profundo es el problema con las transacciones, tenemos que hablar sobre qué es realmente una transacción de blockchain .

El contenido de una transacción en una cadena de bloques de contrato inteligente hoy en día depende en gran medida de la tecnología. En la mayoría de las redes de contratos inteligentes, todo es un contrato inteligente, no solo la lógica de dApp, sino la definición de los propios activos . Dentro de las limitaciones de este modelo, no sorprende que una transacción se defina como una llamada a un contrato inteligente .

Esto significa que en estas redes, la parte principal de una transacción es esencialmente un mensaje que se envía a un solo contrato inteligente, que contiene los datos necesarios para decirle qué hacer.

Cuando el contrato inteligente recibe ese mensaje, puede realizar algunos cambios en sus propios datos internos y puede llamar a otros contratos inteligentes detrás de escena (como los contratos inteligentes de token ERC-20) que a su vez realizan algunos cambios en sus datos internos.

Cualquier cosa y todo lo que suceda como resultado de esa transacción debe ser iniciado por ese único mensaje al contrato inteligente.

Se necesita un poco más antes de que la transacción pueda enviarse a la red. La llamada de contrato inteligente está firmada por la clave privada de una sola cuenta como "persona que llama", y esa persona le dice a la red cuánto está dispuesto a gastar de esa cuenta por tarifas de red (o "gasolina").

En términos generales, eso es todo lo que contiene la transacción: un mensaje para un contrato inteligente, una firma de la billetera del usuario y una especificación de las tarifas de red a pagar .

¿Entonces, cuál es el problema?

Esta forma de definir una “transacción” funciona, técnicamente hablando, pero deja mucho que desear porque no describe las cosas como lo haría el usuario que las firma. Como usuario, podría estar tratando de hacer una transacción que intercambie tokens a través de un DEX, o compre un NFT, o tome un préstamo, pero lo que estoy firmando siempre es solo un mensaje a una caja negra de contrato inteligente que yo esperanza hará lo que espero.

Ese diseño de transacción de "mensaje a una caja negra" crea algunas deficiencias graves que a menudo podemos dar por sentado en criptografía hoy en día:

• Los usuarios de la billetera (y el software de la billetera) no pueden conocer los resultados reales de la transacción . La billetera solo sabe que se está llamando a un determinado contrato inteligente. Todos los resultados de las transacciones son cambios internos cometidos por la lógica interna del contrato inteligente que prácticamente no se puede conocer con anticipación. De hecho, en muchas cadenas, el usuario firma un hash de la llamada del contrato inteligente, lo que lo hace aún más oscuro.

  
  

• Los usuarios no pueden protegerse del "intercambio de sándwich" o el deslizamiento . Tomando el ejemplo de un DEX, la única forma de ofrecer al usuario protección contra deslizamiento es que el contrato inteligente DEX lo ofrezca como parte de su lógica interna (y que el usuario confíe en esa implementación).

  
  

• Los patrones de autorización son muy simples . La única forma en que un usuario puede autorizarse a sí mismo para los contratos inteligentes es a través de su firma de clave de cuenta única. Cualquier cosa más complicada significa (lo adivinó) implementar otro contrato inteligente.

  
  

• Componer juntos múltiples contratos inteligentes significa implementar otro contrato inteligente . La transacción necesita su punto de entrada único, que luego puede realizar múltiples llamadas a otros contratos inteligentes. Esto significa que la composición requiere una planificación anticipada y es laboriosa y rígida.

  
  

• Las dApps no pueden pagar tarifas de red en nombre de sus usuarios . El patrón de llamada de firmante único significa que solo esa cuenta de usuario puede pagar la tarifa.

  
  

Hay varias propuestas que buscan reducir la severidad de estas deficiencias del modelo transaccional fundamental trabajando alrededor de ellas. Por ejemplo, la "abstracción de cuenta" de ERC-4337 permite (entre otras cosas) la posibilidad de una forma de pago de tarifa delegada, pero a costa de una complejidad y un riesgo significativos del sistema .

Sin embargo, independientemente de las soluciones alternativas que se agreguen, el problema sigue siendo que las transacciones no funcionan de la forma en que los usuarios o desarrolladores querrían que lo hicieran, si la tecnología de la plataforma no fuera la limitación .

Para solucionar los problemas anteriores, necesitamos redefinir el concepto de transacciones para que sean mucho más poderosas y flexibles. Deberían dar a los desarrolladores más poder para definir directamente interacciones más complejas, y deberían poner al usuario en control de lo que le importa cuando firma, en lugar de tener que confiar en la lógica de contrato inteligente de caja negra.

En el próximo blog, hablaremos sobre cómo Radix hace exactamente eso con un nuevo tipo de diseño de transacción, habilitado por la exclusiva plataforma de pila completa de Radix.