Precio de Sobrecarga en Stellar: FAQ

¡No! Stellar está siendo utilizada y está funcionando como se espera.

Además de un aumento en operaciones regulares, como pagos y actividad del libro de órdenes, también hemos estado viendo muchos intentos de arbitraje a través de pagos de ruta. Estos pagos de ruta intentan aprovechar los desequilibrios entre los diversos libros de órdenes. Por ejemplo, si cambio algunos XLM por USD, luego a EURT y de vuelta a XLM, podría terminar teniendo más XLM de los que empecé. Esto puede suceder debido a desequilibrios entre los tres mercados (XLM/EURT, EURT/USD y XLM/USD). El arbitraje es una buena cosa! Asegura que los mercados estén equilibrados y reflejen la oferta y demanda del mundo real.

Stellar es única en que permite incluir múltiples operaciones, hasta 100, en una sola transacción. Por ejemplo, puedo enviar 100 pagos individuales al enviar una sola transacción. La red pública de Stellar está configurada actualmente con un límite de 50 transacciones por libro mayor que, con el agrupamiento de operaciones, puede contener hasta 5000 operaciones. Los libros mayores se cierran en promedio cada 5 segundos, por lo que ese es un límite de 10 transacciones, o 1000 operaciones, por segundo.

La red entra en modo Tarificación Dinámica, que es una forma de habilitar dinámicas de mercado para las tarifas para decidir qué transacciones deben incluirse en un libro mayor. En este modo, las 50 transacciones que ofrezcan la mayor tarifa por operación entrarán en el libro mayor. Si esto incluye más de 50 transacciones, por ejemplo, si 51 transacciones ofrecen la misma tarifa por operación, las transacciones serán (pseudoaleatoriamente) mezcladas y las primeras 50 tomadas. El resto de las transacciones, las que no pasaron el corte, se pasan al siguiente libro mayor, o se descartan si han estado esperando demasiado tiempo.

Sí, pero eso va a cambiar. CAP5, titulado “Mejoras en la limitación y precios de transacciones”, que ya ha sido aceptado, cambiará el límite de transacciones por libro mayor a un límite de operaciones por libro mayor. Esto creará más consistencia en tamaño a través de libros mayores completos y dará a los validadores un mejor control sobre la configuración de límites.

El límite de transacciones por libro mayor (o en el futuro límite de operaciones por libro mayor) se decide de manera distribuida por los validadores en la red a través de SCP. Si un número suficiente de validadores decide cambiar ese valor, se puede cambiar. Este valor de configuración necesita equilibrar entre varios principios fundamentales de la red: rendimiento, descentralización e inclusividad. Debe ser lo suficientemente alto para que la red pueda soportar un volumen creciente de actividad pero lo suficientemente bajo para que nodos en todo el mundo con acceso a hardware de menor gama y conectividad más lenta aún puedan mantenerse (para nodos observadores que soportan sistemas como Horizon) y participar en el consenso (para validadores, clave para la descentralización).

Depende. Hay dos pasos durante los cuales las transacciones pueden fallar: validación y consenso. Si una transacción falla durante la validación, por ejemplo si no tiene suficientes firmas, no se presentará al consenso y no cuenta hacia el límite de transacciones por libro mayor. Si una transacción se presenta para consenso, contará hacia ese límite y se tomarán sus tarifas incluso si falla. Por ejemplo, si envío una transacción de pago que está bien formada y firmada puede fallar durante el consenso si no tengo un saldo suficiente.

De hecho, la mayoría de las operaciones de pago de ruta de arbitraje que estamos viendo estos días están fallando durante el consenso, y por eso los libros mayores están llenos.

No exactamente. Dijimos que es barato :) La tarifa mínima por operación es otro parámetro que puede ser configurado por consenso y actualmente está en 100 stroops (un stroop es la unidad más pequeña soportada de XLM, es exactamente 0.0000001 XLM), eso es 0.00008 CENTAVOS DE DÓLAR. Eso es barato.

De hecho, es demasiado barato. Permite que la gente escriba scripts que envíen tantas transacciones como la red pueda manejar, incluso cuando es probable que fallen. Que es exactamente lo que están haciendo los bots de arbitraje.

Sin embargo, lo anterior es solo la tarifa mínima por operación. Puedes ofrecer tanto como quieras para asegurar que tu transacción llegue a la red.

Históricamente, la tarificación dinámica era un evento raro en la red, por lo que las billeteras siempre han enviado la tarifa mínima por operación. En adelante, los desarrolladores de billeteras necesitarán formar su propia estrategia de tarifas. Pueden elegir observar las estadísticas actuales de tarifas de la red (que estamos en proceso de mejorar) y tomar una decisión informada, o alternativamente, consultar con el usuario. Al usuario común probablemente no le importará si están pagando 0.0008 centavos o 0.00008 centavos (¿incluso notaste el 0 extra?) por lo que alentamos a las billeteras a tener en cuenta la experiencia del usuario.

En cuanto a los desarrolladores de bots que envían un gran volumen de transacciones, tendrán que tomar en consideración la economía de las tarifas y ponderarla en su estrategia.

Sí. Con la versión actual del protocolo siempre pagarás la tarifa por operación veces el número de operaciones en tu transacción.

Esto cambiará en el futuro. CAP5 introduce pagos de tarifas de “subasta holandesa” que aseguran que la tarifa por operación que envíes es el máximo que pagarás y la cantidad real es lo más baja posible.

Probablemente sí. Esto depende de los validadores, pero el sentimiento general es que estas necesitan ser más altas. Sin embargo, hay muchas transacciones prefirmadas por ahí con el mínimo actual, que serían invalidadas, por lo que el cambio debe hacerse teniendo esto en cuenta.

Siempre estamos trabajando arduamente en escalar la red de Stellar en preparación para un volumen de transacciones aumentado.

El equipo de ingeniería central está mejorando continuamente el rendimiento de stellar-core. La versión 10.1.0 incluyó una capa de acceso a base de datos reestructurada, que mejoró las tasas de procesamiento de transacciones y sentó las bases para un trabajo de rendimiento más agresivo en revisiones subsiguientes. La próxima versión 10.3.0 se basará en eso al permitir la agrupación de operaciones de base de datos, lo que muestra mejoras de rendimiento en general.

El equipo de ingeniería de plataforma está agregando la ingestión de transacciones fallidas a Horizon para que las transacciones de arbitraje fallidas puedan contabilizarse adecuadamente. La próxima versión de Horizon expondrá estadísticas detalladas de tarifas (ACTUALIZACIÓN 26/02/2019: Horizon 0.17.0 fue lanzada con estadísticas de tarifas, que ahora se reflejan en el Dashboard), permitiendo a las billeteras utilizar estrategias de tarifas dinámicas y reducir considerablemente las transacciones estancadas. Estas estrategias de tarifas se incluirán en las próximas versiones de todos los SDK mantenidos por SDF: Go, Java, Javascript.

El equipo de asociación está informando a la gente sobre lo que está sucediendo y trabajando estrechamente con billeteras e intercambios para asegurarse de que tengan estrategias en lugar para estructurar sus tarifas. Si tienes alguna pregunta sobre cómo el Precio de Sobrecarga podría afectar la aplicación o negocio que construiste en Stellar, ponte en contacto con ellos, o pregunta en el stellar.public Keybase, que es el mejor lugar para interactuar con los desarrolladores de Stellar.