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  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:   .   la horrible experiencia del desarrollador 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,   es un contrato inteligente, no solo la lógica de dApp, sino  . Dentro de las limitaciones de este modelo, no sorprende que una transacción se defina como   . todo   la definición de los propios activos 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   contratos inteligentes detrás de escena (como los contratos inteligentes de token ERC-20) que a su vez realizan algunos cambios en   datos internos. a otros sus  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:    . 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 de la billetera (y el software de la billetera) no pueden conocer los resultados reales de la transacción    . 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 usuarios no pueden protegerse del "intercambio de sándwich" o el deslizamiento    . 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. Los patrones de autorización son muy simples    . 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. Componer juntos múltiples contratos inteligentes significa implementar otro contrato inteligente    . El patrón de llamada de firmante único significa que solo esa cuenta de usuario puede pagar la tarifa. Las dApps no pueden pagar tarifas de red en nombre de sus usuarios  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.  También publicado   . aquí

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Buy XRD with card or bank transfer via Switchere.

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Download free Tech Leaders Productivity Report!

El problema con las transacciones criptográficas hoy

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps