¡Tarifas dinámicas en Zcash, ahora!

Mejor UX para los usuarios y un presupuesto de seguridad más sólido para Zcash Hoy, las transacciones de Zcash usan un modelo de tarifa fija basado en la complejidad de la transacción. Esto crea una "zona de Goldilocks" en el precio de ZEC: las tarifas deben ser lo suficientemente altas para desalentar el spam, pero lo suficientemente bajas para que los usuarios aún quieran transaccionar. Pero dado que el precio de ZEC está subiendo, nos estamos saliendo de esa zona. Eso significa que es hora de un sistema de tarifas dinámicas basado en el libre mercado, simple y privado. Uno donde:

• Los usuarios aún puedan enviar transacciones incluso en una situación de sobrecarga (como la situación previa de sandblasting).
• Las tarifas apoyen la sostenibilidad del ZEC y la red Zcash.
• Las tarifas se reduzcan para usuarios normales bajo circunstancias normales.
• Los usuarios puedan pagar más o menos por diferentes clases de servicio.
• El sistema de tarifas proteja la privacidad del usuario.
• El diseño se mantenga simple para minimizar riesgos de seguridad, privacidad u otras consecuencias imprevistas.
• La implementación se despliegue de forma incremental y dentro de los parámetros actuales de mainnet. No se requiere actualización de red.
• La lógica de consenso central permanezca aislada del sistema de tarifas, para que estos cambios no puedan causar bifurcaciones de consenso.

Esto es alcanzable este año, con tres pasos: funciones de billetera que pongan opciones frente a los usuarios, un endpoint RPC que sugiera tarifas a partir de datos en cadena, y algunos cambios de parámetros razonables. Pilotos de funciones de billetera Hay dos funciones con las que las billeteras pueden (y en nuestra opinión deberían) experimentar hoy para comenzar a impulsar las tarifas dinámicas: entrega prioritaria y semántica de "acelerar". Entrega prioritaria Antes de enviar una transacción, la billetera puede ofrecer al usuario la opción de pagar una tarifa 4× para incentivar a los mineros a incluirla más pronto. De esa forma, cuando el espacio de bloques está demandado, una transacción prioritaria se concreta rápidamente. Para cualquier cosa sensible al tiempo (liquidación, nómina, herramientas de comercios, reembolsos), la inclusión pronta es la discreción más significativa que podemos ofrecer. Aunque la red Zcash está, al momento de escribir esto, generalmente muy descongestionada, puedes pensar en la "Prioritaria" como la fila de seguridad en el aeropuerto. Creemos que este es un intercambio razonable. La tarifa revela información mínima: solo si la transacción blindada vino con la tarifa estándar o la tarifa prioritaria. Además, una vez que el Mecanismo de Sostenibilidad de la Red se active con NU7, el 60 % de cada tarifa de transacción se retira de circulación y se reemite más tarde. Eso eleva la función de prioridad de un mero beneficio de UX a una contribución significativa a la seguridad a largo plazo de la red. Semántica de "Acelerar" Hoy, una transacción de Zcash atascada permanece en el mempool hasta su vencimiento, o para siempre si no se establece uno. Una altura de vencimiento corta (p. ej., 2 bloques en mainnet actual, o 5 bajo los cambios propuestos en ZIP-218) garantiza que la transacción se concrete rápido o falle rápido. Si una transacción falla, las billeteras pueden ofrecer un botón de "Acelerar", una UX familiar para los usuarios de Bitcoin y Ethereum. Zcash no admite Replace-By-Fee (RBF), así que la billetera simplemente transmite una transacción nueva a la tarifa prioritaria. El usuario no necesita razonar sobre el mempool. Nos enorgullece anunciar que Unstoppable Wallet (@unstoppablebyhs) se ha ofrecido para ser el primero en experimentar con estas funciones. También hemos contactado a varias otras billeteras. Si eres desarrollador de billeteras interesado en trabajar con nosotros, contáctanos. El endpoint de sugerencia de tarifas (z_getstandardfee) Una vez que esos pilotos estén produciendo datos de mainnet, lanzaremos un estimador de tarifas dinámico: un endpoint RPC, z_getstandardfee, que devuelve una tarifa estándar recomendada para envíos cotidianos basada en bloques recientes. Las billeteras ofrecen esta tarifa a los usuarios y les permiten elegir multiplicarla por 4 para entrega prioritaria. Crucialmente, el endpoint es una sugerencia, no una regla de consenso. Sin embargo, cuantas más billeteras lo usen consistentemente, más consistente será la UX entre billeteras y mayores serán los beneficios de privacidad. Ajuste de parámetros Todo lo anterior funciona dentro de los parámetros actuales de ZIP-317. Dos de ellos también merecen una revisión ahora que ZEC se ha apreciado: la tarifa marginal (actualmente 5.000 zatoshi por acción) y el límite de relación de peso de producción de bloques (actualmente 4,0).

• Reducir la tarifa marginal de 5.000 zatoshi a 1.000 para reducir las tarifas en general, manteniéndose aún así por encima del umbral de spam.
• Aumentar el límite de relación de peso de 4,0 a 10,0 para absorber picos de demanda.

Estos parámetros también tienen el beneficio estético de ser potencias de 10, que son fáciles de entender y explicar. Conclusión Las tarifas dinámicas no necesitan llegar de una sola vez, ni necesitan provenir de cambios de consenso. Comenzando con la UX de billetera, la estimación de tarifas y el ajuste incremental de parámetros, Zcash puede avanzar hacia un mercado de tarifas que maneje mejor las cambiantes condiciones de la red mientras preserva la simplicidad y la privacidad. Esperamos probar estas ideas en mainnet este año y damos la bienvenida a la retroalimentación de la comunidad. Publicado de forma cruzada en el blog de Shielded Labs y los Foros de la Comunidad Zcash. Traducción del original en inglés de la shieldedmark.

Si quieres aprender más sobre privacidad en la economía digital descentralizada, te puedes unir a la comunidad de Zcash en Español en Telegram. Para conectar con el ecosistema digital de Zcash Español, visita nuestro Privacidad.me.