Mejoras del Protocolo 13

Las transacciones de aumento de tarifa te permiten pagar la tarifa de una transacción existente sin tener que volver a firmar la transacción existente o gestionar los números de secuencia. Entraremos en los detalles técnicos de cómo funcionan en un próximo post técnico — así que mantente atento para eso — pero por ahora, quedémonos con una pregunta simple: ¿por qué son útiles los aumentos de tarifa?

Los aumentos de tarifa permiten a las aplicaciones cubrir las tarifas de los usuarios

Primero, los aumentos de tarifa facilitan el pago de una tarifa en nombre de otra cuenta. Una billetera no custodia, por ejemplo, puede cubrir las tarifas de transacción de un usuario sin controlar la cuenta del usuario. Antes del Protocolo 13, la billetera podría intentar cubrir las tarifas enviando fondos directamente al usuario, pero no había garantía de que el usuario realmente gastara esos fondos en tarifas, y no había forma de recuperar los fondos no gastados. Los usuarios desprevenidos podrían bloquear sus cuentas al encerrar fondos destinados a tarifas en una orden de compra; los usuarios maliciosos podrían intentar desviar fondos destinados a tarifas hacia ganancias ilícitas.

Antes del Protocolo-13, la billetera también podría intentar usar su propia cuenta como la cuenta fuente para las transacciones de los usuarios, pero si está haciendo eso para decenas de usuarios, es imposible asegurar que las transacciones se envíen en el orden correcto. Es una pesadilla de gestión de números de secuencia.

Con los aumentos de tarifa, las billeteras pueden cubrir tarifas sin depender de la magia de los números de secuencia, y sin tener que explicar cosas como el precio de sobrecarga a los usuarios. Eso significa que pueden ocultar los detalles más finos de la red y sus requisitos, lo que les permite crear un producto más simple que atrae a una base de usuarios más amplia.

Los aumentos de tarifa te permiten aumentar las tarifas para transacciones prefirmadas

La segunda manera en que los aumentos de tarifa son útiles: te permiten aumentar la tarifa para una transacción prefirmada. Si creas y firmas una transacción con la intención de enviarla en una fecha futura — digamos que estás poniendo fondos en depósito en garantía — cuentas con que la red continúe existiendo en un estado que te permita ejecutar esa transacción. Si, cuando vas a enviar la transacción, la tarifa que especifica es demasiado baja — lo que puede suceder si la red está en modo de precio de sobrecarga, o el mínimo de la red ha aumentado — no podrás hacerla entrar en el libro mayor. En estas situaciones, podría no ser posible siquiera recrear la transacción: los firmantes podrían estar no disponibles o no dispuestos a aceptar los términos antiguos; la clave de firma podría estar perdida. Tus fondos podrían quedar bloqueados en depósito en garantía para siempre.

Los aumentos de tarifa dan a los validadores la flexibilidad de aumentar las tarifas

Al prevenir que las transacciones prefirmadas fallen debido a tarifas insuficientes, los aumentos de tarifa abren el camino para un cambio potencial insinuado en el párrafo anterior: ahora los validadores pueden, si es necesario, aumentar la tarifa mínima de la red.

Las tarifas son una herramienta importante para lidiar con el spam de la red, y como todos los ajustes cruciales de la red, las tarifas mínimas son determinadas por voto de los validadores. Dar a los validadores la flexibilidad de cambiar las tarifas para mantener los costos de la red alineados con el uso real de la red y los precios fluctuantes de XLM es crucial para el funcionamiento continuo y de alta calidad de Stellar. Si los validadores consideran esencial aumentar las tarifas mínimas, ahora pueden hacerlo sin bloquear los fondos de nadie en depósito en garantía.

Stellar siempre ha tenido autorización de activos a nivel de protocolo que es increíblemente fácil de usar: puedes configurar un activo para requerir autorización, y puedes hacer que la autorización sea revocable para que puedas activarla y desactivarla según sea necesario. Haces ambas cosas configurando simples banderas a nivel de cuenta.

Sin embargo, cuando desactivas la autorización para una cuenta dada, también cancelas todas las órdenes de compra y venta que esa cuenta tiene para el activo en cuestión. El Protocolo 13 introduce una nueva bandera que te permite revocar la autorización mientras mantienes las órdenes en los libros, lo que facilita la tokenización de activos regulados como valores.

A menudo, los emisores de activos regulados quieren que los clientes puedan comerciar con sus activos, pero también necesitan ejercer un alto nivel de control sobre quién puede tenerlos, cuánto pueden tener, y bajo qué condiciones pueden vender o comprar más. Con el control detallado de activos, un emisor de un activo regulado puede configurar el activo para requerir el nuevo tipo de autorización — el que mantiene las órdenes en los libros — y cuando un usuario quiere hacer un pago o una nueva oferta, el emisor puede verificar si está permitido dadas las regulaciones. Si lo está, el emisor intercala tres operaciones en una sola transacción:

1. Autorizar la cuenta para usar el activo (una operación que el emisor firma)
2. Hacer el pago o la oferta (una operación que el usuario firma)
3. Desautorizar la cuenta para usar el activo. (una operación que el usuario firma)

‍
Debido a que las transacciones en Stellar son atómicas, las tres operaciones ocurren de un solo golpe, y el emisor termina aprobando una sola operación específica. Los emisores pueden condicionar la aprobación a una verificación de cumplimiento, así pueden mantener los pagos y ofertas dentro de los límites de las regulaciones.

El Protocolo 13 también introduce un nuevo tipo de dirección de cuenta que incluye un memo integrado de 64 bits. Este cambio es importante para los exchanges y otros servicios de custodia que mantienen una única dirección de depósito de Stellar y requieren memos para poder enrutar correctamente los pagos a la cuenta de usuario correcta en sus bases de datos internas. Con estas nuevas cuentas multiplexadas — cuentas mux para abreviar — los servicios de custodia pueden dar a cada usuario su propia ID de cuenta que enruta a la dirección de Stellar del exchange subyacente.

Además de hacer imposible que los usuarios olviden los memos requeridos (un problema para el que se nos ocurrió una solución temporal recientemente), las cuentas mux son robustas contra errores tipográficos, lo cual los memos actuales no son. También te permiten aplicar funcionalidad similar a memo al nivel de operación , por lo que puedes agrupar múltiples operaciones de pago a múltiples cuentas mux en una sola transacción, lo que es más limpio, más eficiente y mejor para la red que enviar transacciones hechas de operaciones de pago individuales.

Y mientras que los memos pueden dejarte saber a qué subcuenta debe ir a, no pueden dejarte saber de qué subcuenta vino de. Cuando un pago de una subcuenta necesita ser devuelto, por ejemplo, no hay forma de navegar la última milla: la devolución puede llegar al servicio de custodia, pero ellos no saben a qué cuenta acreditar. Al hacer posible identificar la subcuenta emisora, las cuentas mux hacen que este tipo de devoluciones sean fáciles.

Lo que pasa con las cuentas mux, sin embargo, es que aunque están integradas en el Protocolo 13, no son realmente accesibles en el momento de escribir esto. Pusimos el cableado, pero no hemos añadido un interruptor. Antes de que las cuentas mux estén listas para usar, tenemos que averiguar la mejor manera de exponerlas en Horizon y los SDKs de Stellar, y eso va a requerir algo de reflexión, pruebas y validación. Hay una propuesta de cómo hacerlo — SEP-23 — y una discusión en curso en Github. Si quieres ver cómo se resuelve todo — o tienes alguna idea sobre el mejor camino a seguir — ¡por favor únete a la discusión!

Además de las tres nuevas características mencionadas anteriormente, el Protocolo 13 también incluye dos optimizaciones que hacen que la red funcione un poco mejor.‍

‍CAP-28introduce una pequeña mejora en la comodidad al tratar con firmantes de pre-autorización.‍

CAP-30deja de verificar si la cuenta emisora de un activo existe durante el pago, pago por ruta y al colocar/administrar una oferta.

Esas dos optimizaciones no tienen el mismo impacto obvio en la mayoría de los usuarios como los incrementos de tarifas, mejor control de la autorización de activos y cuentas multiplexadas, pero ayudan a que Stellar Core, — y por lo tanto la red en su conjunto — funcione un poco más eficientemente.

Todos los cambios del Protocolo 13 se han fusionado y lanzado en Stellar Core v13.0.0, y el testnet ya está funcionando con el Protocolo 13. Para que la red pública se actualice, los validadores necesitarán armar sus nodos para optar por el Protocolo 13, lo que hacen usando el siguiente comando:

/upgrades?mode=set&upgradetime=2020-06-18T16:00:00Z&protocolversion=13


Si suficientes validadores arman sus nodos para actualizar, la red cambiará inmediatamente al Protocolo 13, y todas las nuevas características estarán accesibles para cualquiera que use Stellar. Cuando eso suceda, es importante que estés ejecutando software compatible: Stellar Core, Horizon y los SDKs de Stellar que no soporten el Protocolo 13 dejarán de funcionar correctamente, y tu producto, aplicación o servicio probablemente se romperá. Al menos hasta que instales nuevo software.

Para saber más sobre lo que necesitas hacer para actualizar, consulta nuestra Guía de Preparación para el Protocolo 13.