Artículo escrito por Vincent Le Gallic - CTO @Rockside

Si es un desarrollador o un usuario de la red, probablemente ya se haya encontrado con el problema de las transacciones atascadas. Podría describirse como una espera interminable para el procesamiento.

Incluir una transacción en un bloque puede dar dolor de cabeza. Como el tamaño de los bloques es limitado, las mineras priorizarán las transacciones con el precio de gas más alto.

Foto de Arron Choi en Unsplash

¿Cómo terminamos en esta situación y por qué, por una reacción en cadena, esto obstruye cada nueva transacción enviada con la misma cuenta? ¿Qué puede aportar un repetidor de transacciones para evitar eso?

¿Por qué puede ser difícil incluir transacciones en un bloque?

Recordatorio rápido: las transacciones en Ethereum están programadas por un número asociado con la transacción llamado "nonce". Cada cuenta de la cadena tiene un "nonce" que se incrementa con cada transacción. Así, la primera transacción realizada por una cuenta tendrá el nonce 1, y la tercera tendrá el nonce 3.

Las transacciones deben ejecutarse en el orden correcto de nonces: la tercera transacción realizada por una cuenta no puede incluirse en un bloque y ejecutarse antes que la segunda transacción.

Si varias cuentas compiten para ejecutar su transacción lo antes posible, el precio del gas aumentará repentinamente. Imagine un escenario en el que una cuenta ha enviado una transacción con un precio de gasolina demasiado bajo, la transacción se verá bloqueada por la entrada de transacciones más rentables para menores.

Como el contador de cuenta (nonce) ya no se incrementa, todas las transacciones de cuenta emitidas desde el incidente también se bloquean.

Para salir de esta situación dentro de un tiempo razonable, debe cancelar o reemplazar la transacción atascada por una nueva utilizando el mismo tiempo y un precio de gasolina más alto. La operación debe repetirse aumentando el precio del gas hasta incluir la transacción en un bloque.

Finalmente, excepto si puede forzar un uso secuencial de la cuenta (lo que es imposible si las transacciones se emiten desde la billetera de un usuario, por ejemplo), deberá administrar todas las transacciones pendientes de la cuenta con un precio de gas potencialmente descorrelacionado de la nuevo precio de mercado.

Hecho famoso por Cryptokitty y las ICO, este desafío ahora debe ser enfrentado por los protocolos financieros descentralizados. Afortunadamente, estos problemas siguen siendo ocasionales en Ethereum.

Pero cuando ocurren, es un error crítico para la aplicación.

Del lado del usuario, la frustración es similar a la que siente cuando un pago no funciona en un sitio web de comercio electrónico. Por el lado de la aplicación, además del apoyo que genera, esto generalmente resulta en una pérdida de ingresos.

Los usuarios y desarrolladores heredaron un problema inextricable en Ethereum 1.x. Esto probablemente contribuyó a empañar la imagen del protocolo. También mostró que la comunidad puede reunirse para proponer mejoras, como el uso de metatransacciones.

Una solución basada en meta-transacciones

Foto de Brett Jordan en Unsplash

El concepto de metatransacción permite a los usuarios interactuar con la cadena de bloques con solo un par de claves públicas/privadas.

Este mecanismo suele utilizarse para enviar transacciones gasless, es decir, una transacción enviada desde una cuenta (EOA) sin Ether.

Del lado del usuario, enviar una metatransacción es similar a enviar una transacción estándar (de, a, valor... y firma) excepto que en lugar de enviarla directamente a Blockchain, envía la metatransacción a un tercero. quien se encargará del gas.

Este tercero crea una nueva transacción que contiene la metatransacción y la envía a un proxy de contrato inteligente (también puede ser una función de proxy en un contrato).

El contrato comprueba la validez de la metatransacción (gracias a su firma) antes de ejecutarla.

Este mecanismo es cada vez más utilizado por las aplicaciones para mejorar la incorporación de los usuarios. Les permite patrocinar el gas para sus usuarios manteniendo los beneficios de un sistema descentralizado (no corrupción, no repudio, etc.).

Quizás se pregunte: si la aplicación puede retransmitir las transacciones por sí misma para sus usuarios, ¿cuándo y por qué necesitamos un retransmisor?

El dilema entre “hágalo usted mismo” o “compre una solución” es bien conocido por los desarrolladores y la respuesta siempre depende del contexto.

Pizza Hut continúa entregando sus pizzas cuando la mayoría de los restaurantes usan Uber Eat o Deliveroo.

Bueno, como es el caso de la entrega de alimentos, construir y mantener infraestructuras de retransmisión es muy complejo y costoso. De hecho, cada vez más aplicaciones optan por integrar API para transmitir sus transacciones en lugar de hacerlo todo por sí mismas.

¡Envíe sus meta transacciones, el repetidor se encarga del resto!

Para cumplir su promesa, y además de mejorar la ruta de las transacciones en blockchain, los repetidores pueden facilitar la implementación de transacciones sin gas.

¿Cómo mejora un repetidor el resultado de la transacción en la cadena de bloques?

Como se explicó anteriormente, para una cuenta dada, las transacciones deben ordenarse y validarse secuencialmente. Por ejemplo, si desea enviar 3 transacciones, la transacción n.° 3 quedará pendiente hasta que se hayan procesado la n.° 1 y la n.° 2. El número de transacciones pendientes de una cuenta está limitado por el nodo (en Geth, el límite predeterminado es 64, por ejemplo). Más allá de este límite, el nodo puede eliminar arbitrariamente transacciones de su cola.

Para evitar estas limitaciones, un repetidor puede enviar sus metatransacciones y enviarlas desde varias cuentas. De hecho, si tiene tres cuentas, la cantidad de transacciones que pueden estar pendientes en un nodo pasa de 64 a 192 cuando usa Geth. Además, cuando una transacción se atasca en una de las cuentas, el repetidor puede desplazarla a una de las dos cuentas restantes y así seguir enviando sus transacciones.

Otra cosa a considerar es el sistema nonce utilizado por el contrato inteligente de retransmisión. El sistema nonce se utiliza para evitar un ataque de repetición. La solución del sistema nonce elegida afectará la forma en que se procesan las transacciones. Por ejemplo, si desea anclar certificados, desea poder enviar una gran cantidad de transacciones simultáneamente y el orden no importa.

De hecho, algunas aplicaciones pueden requerir enviar transacciones de forma secuencial y otras simultáneamente. Según el uso y el volumen de transacciones, algunos casos pueden requerir optimizar el costo de almacenamiento de un sistema de protección contra ataques de reproducción, mientras que otros pueden no necesitar implementaciones tan complejas. Los repetidores permiten a los desarrolladores deshacerse de estos problemas complejos al proporcionar servicios simples y listos para usar.

¿Cómo facilita un repetidor la implementación de transacciones sin gas?

Es necesario tener Ether en su cuenta si desea cambiar un contrato inteligente o enviar una transacción o hacer cualquier cosa en Ethereum. Esto hace que la incorporación del usuario y la experiencia del usuario sean dolorosas. No hay forma de tener una tasa de conversión alta cuando los usuarios tienen que comprar Ether antes de poder usar la aplicación.

Para superar eso, algunas aplicaciones simplemente ofrecen pagar el gas en nombre de sus usuarios. Los desarrolladores a menudo ignoran este enfoque, ya que está lejos de la filosofía del protocolo, que tiene como objetivo garantizar la independencia en la red. En un modelo tan tradicional, la aplicación considera el gas como un costo de infraestructura, al igual que el consumo de CPU en AWS, por ejemplo. Dado que la generación de ingresos generalmente se correlaciona con el uso de contratos inteligentes, es un modelo económicamente viable en la mayoría de los casos.

La aplicación y los usuarios también pueden ponerse de acuerdo en la cadena para un reembolso automático de los costos de gas implícitos. Con la aparición de los servicios de DeFi, cada vez más usuarios poseen tokens sin Ether. Y algunos sistemas permiten a sus usuarios pagar sus transacciones con un token ERC20.

La aplicación también puede distribuir sus propios tokens a sus usuarios en el momento del registro. Este mecanismo es comparable a la distribución de cupones gratuitos que solo se pueden utilizar en los contratos de aplicación.

Un repetidor ayudará a implementar la estrategia correcta de reembolso de gas sin requerir grandes inversiones en investigación y desarrollo.

¿Cómo usar un repetidor?

Idealmente, todos estos servicios deberían funcionar de forma transparente para el desarrollador, es decir, sin modificar sus contratos inteligentes o el código de su aplicación.

Los servicios de retransmisión generalmente se exponen a través de una API web clásica. También pueden estar disponibles como proxy frente a un "proveedor web3" entre la aplicación y el nodo para facilitar su uso con bibliotecas como web3js.

Finalmente, el diseño de la solución debe permitir a sus usuarios verificar que el repetidor no puede reproducir ni modificar los datos de la metatransacción.

En realidad, la función de repetidor es bastante similar a una lista de espera de nodos, pero agrega varias características esenciales para aplicaciones en vivo en Mainnet.

¿Existe un estándar para repetidores?

Foto de Daniel Jensen en Unsplash

Descentralización, privacidad, seguridad, simplicidad, etc. Elegir cómo transmitir una transacción en Ethereum implica tener en cuenta muchos criterios y, nuevamente, según el contexto, se deben tomar diferentes decisiones.

GSN (Red de Gasolineras) es una de las iniciativas más visibles en este ámbito. Esta solución permitió la construcción de una red de repetidores descentralizados. Cuando se utiliza un centro de retransmisión, los jugadores que están listos para procesar transacciones por una comisión pueden competir entre sí. GSN requiere importantes esfuerzos de integración. Es una solución muy adecuada cuando el uso de una red de retransmisión P2P es un requisito previo.

Para entender por qué no hay consenso en torno a un estándar, comparemos dos billeteras: MetaMask y Argent.xyz. El primero gestiona la identidad de sus usuarios con un EOA, mientras que el segundo utiliza contratos inteligentes.

La implementación ingenua de un "proxy de retransmisión" en las transacciones enviadas desde MetaMask es más compleja de lo que parece. El uso de msg.sender en los contratos utilizados por la aplicación estaría prohibido porque contendría la dirección del repetidor en lugar de la dirección pública del usuario.

Por otro lado, Argent.xyz utiliza un contrato de cuenta que debe implementarse para cada usuario. Este es un costo adicional para Argent.xyz pero la verificación y retransmisión de transacciones se realiza directamente en este contrato, sin necesidad de modificación alguna en los contratos de destino.

Los contratos de aplicación también pueden verificar y ejecutar directamente la firma de metatransacciones mediante la implementación de dos funciones. Uno para proteger contra ataques de reproducción y el otro para verificar y ejecutar la transacción. Esta solución tiene muchas ventajas pero sigue siendo inutilizable para contratos ya implementados.

Para profundizar en las diferentes filosofías de retransmisión en Ethereum, @wighawag propuso recientemente la idea de un "Reenviador de transacciones meta mínimo y extensible" # 2585 . Este EIP muestra cuán grande es este tema y cuán activo es el debate en la comunidad.

Conclusión

Las aplicaciones que requieren grandes volúmenes de transacciones pagan sistemáticamente comisiones de red demasiado caras. Y este costo adicional no les impide tener que intervenir cuando una transacción se bloquea. Para aplicaciones más pequeñas y en construcción, construir y mantener una infraestructura de retransmisión requiere demasiada inversión. Los PSP (proveedores de servicios de pago) como Paypal o Stripe han facilitado a los desarrolladores la aceptación de pagos en Internet. E incluso si Ethereum le permite eliminar o limitar el poder de terceros, este protocolo debe adquirir puertas de enlace para simplificar su uso. El poder de los repetidores está limitado "por diseño" por las metatransacciones, por lo que cumplen perfectamente con los desafíos actuales de los desarrolladores en Ethereum.

En Rockside.io, decidimos hace ocho meses construir el mejor repetidor en Ethereum. Ya procesamos cientos de transacciones diariamente para nuevas empresas y grandes cuentas y, por lo tanto, sabemos que la necesidad es real entre los desarrolladores. El uso cada vez mayor de repetidores también muestra que la relación entre las empresas y la cadena de bloques está evolucionando. Hemos pasado de un deseo de comprender a un deseo de usar la tecnología.