Incrementar el rendimiento de la red
Antecedentes
Actualmente, la red Cardano ha alcanzado el 100% de su capacidad al menos dos veces. Eso significa que los mempools están llenos y esto está causando problemas que dependen de las herramientas.
Puede encontrar las últimas cargas de 1 hora y 24 horas en pool.pm
¿Esto está relacionado con el “problema de congestión” del que sigo escuchando?
No. El problema de la “congestión” del que puede haber oído hablar en las últimas semanas es sobre cómo los contratos inteligentes de Cardano son deterministas y, por lo tanto, solo una transacción puede consumir un UTxO. Se puede abordar rediseñando contratos inteligentes para que funcionen mejor en paralelo en múltiples entradas de UTxO.
Este problema trata sobre cómo Cardano mismo ha alcanzado el máximo de TPS que la red puede soportar.
¿Cómo se maneja el mempool actualmente?
El mempool Cardano está diseñado para ser “justo”. Las transacciones se procesan en un orden FIFO (primero entrado, primero salido) independientemente de la cantidad de tarifas que paguen (la especificación del libro mayor admite un mercado de tarifas, pero cardano-node no tiene esto en cuenta).
Cardano-node usa un mempool de tamaño fijo que actualmente solo tiene 2 bloques de tamaño (~ 280 txs). Si las transacciones se envían cuando el mempool está lleno, es posible que se eliminen (esto depende parcialmente de la herramienta. El nodo cardano solo mantiene la agencia con el protocolo “txsubmit” hasta que haya espacio).
¿Cuál es el rendimiento máximo para Cardano, actualmente, los
Las TPS de Cardano están entre 0.2 TPS a un máximo de 6.5 TPS.
El tiempo de bloque de Cardano es de ~ 20 segundos.
Cardano está alcanzando el máximo debido a los airdrops de NFT y, por lo tanto, las TPS generalmente está en el extremo superior de ese rango (ya que la ejecución del script Plutus no es común en la actualidad).
¿Podemos aumentar el tamaño de tx? y / o tamaño del bloque?
Desafortunadamente, no realmente. Plutus aún se está optimizando y el aumento del tamaño del bloque podría hacer que la ejecución del script de Plutus demore demasiado y cause problemas posteriores con la red.
Dicho esto, actualmente los scripts de Plutus no solo son costosos en ejecución, sino también de gran tamaño (un único script es de 5–8kbs y, por lo tanto, una sola transacción en Cardano generalmente solo puede usar 1–2 scripts antes de alcanzar el límite). Esto significa que aumentar el límite de tamaño de tx podría permitir un procesamiento por lotes más grande de airdrops de NFT sin permitir muchos cómputos adicionales de Plutus (hasta que Plutus se optimice al menos en el futuro).
¿Podemos aumentar el tamaño de mempool?
No sé por qué se eligieron 2 bloques como tamaño fijo. Agradecería cualquier información de antecedentes sobre esto. ¿Posiblemente esto fue solo para intentar que Cardano se quedara con menos de 8GB de RAM?
Además, esto degradaría la experiencia del usuario para las carteras ligeras porque actualmente las carteras ligeras no tienen forma de consultar el mempool, por lo que no pueden mostrar las transacciones pendientes. Si mantenemos un mempool gordo, tendríamos que priorizar la consulta de mempool para billeteras ligeras como una característica.
¿Podemos abordar este problema a nivel de billetera?
Hasta cierto punto. Las billeteras pueden implementar el reenvío de tx de modo que incluso si el mempool está lleno y provocó que el tx se cayera inicialmente, la billetera simplemente lo reenviará al usuario.
Actualmente no hay forma de consultar el mempool del nodo para herramientas de billetera livianas, lo que significa que una billetera no puede saber si un tx que se envió se cayó, falló o aún está pendiente. Esto hace que sea complicado implementar un reenvío de tx adecuado, ya que significa que la única forma de saber si debe reenviar es ver si el ttl para su tx ha expirado. Bajar el ttl tampoco es ideal porque si la congestión de la red hace que pase un tx, disminuir el ttl reduce la posibilidad de que su tx se convierta en un bloque antes de que se agote el tiempo de espera.
¿Podemos clasificar el mempool?
Una forma en que podemos aliviar el problema sin aumentar el tx y / o el tamaño del bloque es ordenar las transacciones en el mempool, como usar un mercado de tarifas.
Esto no es trivial para hacerlo correctamente porque:
- las transacciones en el mempool podrían depender entre sí (¿reemplaza 2 txs con un 1tx que paga una tarifa más alta que ambos combinados?)
- si la clasificación de mempool lleva demasiado tiempo, puede afectar los TPS del sistema de manera negativa
- permite vectores de ataque relacionados con el mempool (ej: enviar txs que son solo 1 lovelace mejor para incluir en la transacción repetidamente para aumentar los costos de computación. Otras blockchains han sufrido este tipo de ataques en el pasado). Necesitaría que la tarifa obtenida al incluir el tx sea más alta que el costo de cálculo de reordenar su mempool (pero es difícil calcular el costo de lovelace de esto)
- hace que la depuración de los problemas de mempool sea más difícil ya que ya no es tan predecible
- el código de la capa de red no se escribió teniendo en cuenta la clasificación del mempool y, por lo tanto, requeriría una buena cantidad de trabajo de desarrollo e iteración en los modelos de red
- se complicó un poco las tarifas de Babel.
Métodos de clasificación
El campo más fácil para clasificar el mempool es la relación cuota de tx / coste de tx.
Otra opción es ordenar por la edad de la entrada UTXO más antigua en la transacción. Esto evita los ataques de spam (porque eventualmente se quedarán sin UTXO antiguos), pero tendrá terribles consecuencias en el uso de contratos inteligentes populares, ya que todos sus UTXO serán relativamente nuevos.
¿Podemos priorizar las transacciones sin tener que realizar modificaciones en el mempool?
Sí, de manera limitada, podemos implementar la clasificación de transacciones para elegir qué transacciones pasar a sus pares (para que sus mempools sean mejores que los suyos). Esto requiere P2P que Cardano aún no tiene, pero puede ayudar en el futuro.
Esto también sería un poco flexible porque podría optar por aceptar transacciones de ciertos pares incluso si no le brindan la mejor devolución de tarifa de tx si tiene algún acuerdo especial con ellos.
¿Podemos confiar en Hydra o Milkomeda?
Un sentimiento popular es que las soluciones L2 como Hydra o Milkomeda pueden ayudarnos.
Milkomeda no está pensado como una solución de rendimiento, es una solución de interoperabilidad, por lo que no ayudará con esto.
La cabeza de Hydra todavía está en desarrollo, por lo que necesitamos una solución más temprano que tarde. Además, la primera versión de Hydra implementada será bastante limitada (debe abrir un canal de estado con un conjunto fijo de actores, todos los actores deben estar en línea las 24 horas del día, los 7 días de la semana, no puede agregar o eliminar activos del canal de otros que cerrar el canal por completo). Dado este conjunto de limitaciones, no podemos confiar en la cabeza de Hydra v1 para aliviar completamente el problema. Es posible tener soluciones head-as-a-service sin custodia para eludir algunas de estas limitaciones (pero nadie está trabajando en esto hasta donde yo sé) y algunas iteraciones futuras de Hydra mejoran o eliminan estas restricciones.
Incluso si tenemos Hydra, todavía no resuelve el problema por completo porque los estados todavía tienen que abrirse y cerrarse eventualmente en la cadena principal.
¿Se puede evitar un mercado de tarifas?
No. Las cadenas de bloques siempre han funcionado fundamentalmente en un sistema de “pagar o callar”. Si hay congestión en la red, la única forma objetiva de decidir a quién permitir el paso es priorizar las transacciones con el mayor valor financiero, que se define mediante proxy por la cantidad de tarifas que están dispuestos a pagar para que se realice la transacción.
Además, un mercado de tarifas es algo que todos los usuarios de Cardano deberían desear. Cardano tiene un suministro fijo y, por lo tanto, los retornos del grupo de participación seguirán bajando (ya está por debajo del 5% de retorno de la participación), pero la buena noticia es que las tarifas de transacción se distribuyen a todos los delegantes. Eso significa que la única forma de que las personas tengan un incentivo para continuar delegando es que las tarifas de tx aumenten hasta que finalmente superen las recompensas de la reserva.
¿Cómo se ve Ethereum?
Otras cadenas de bloques como Ethereum aprovechan al máximo el mercado de tarifas (puede ver información en vivo aquí) y las billeteras miran el estado de la red para saber cuánto en tarifas de tx tienen que pagar.
Ethereum hace alrededor de 10 ~ 15 TPS
El tiempo de bloqueo de Ethereum es de ~ 13 segundos.
Actualmente, las tarifas de transacción en Ethereum en realidad brindan más a los mineros que las recompensas del bloque base (esto es a pesar del hecho de que en Ethereum, a diferencia de Cardano, las recompensas del bloque no disminuyen con el tiempo de forma algorítmica)
