Traducción al español de “Optimizing Cardano”, escrito por Tim Harrison, director de Marketing y Comunicaciones en IOG, el 9 de noviembre de 2021
La optimización de la red se consigue mediante ajustes graduales, paso a paso.
Al ser una blockchain proof-of-stake, Cardano está pensada para ser altamente segura y resistente a los fallos de la red. Dirigido por el algoritmo de consenso Ouroboros, con Haskell que utiliza métodos formales e investigación académica revisada por pares, Cardano está diseñado para proporcionar un ambiente sólido como una roca para procesar millones de transacciones a nivel mundial, de una manera descentralizada y altamente escalable.
En nuestro anterior artículo, hablamos del rendimiento de la red: cómo opera el sistema en su conjunto a la hora de procesar, verificar y firmar las transacciones. Es fundamental que esto se haga bien en la primera fase de diseño si se quiere un sistema que se construya a largo plazo. Pero la capacidad de la red es un recurso valioso, por lo que para obtener las métricas de rendimiento más eficientes, es esencial que los recursos de computación, memoria, almacenamiento y red se consuman de forma eficaz.
Cardano está construido para ser flexible. Se ha diseñado para maximizar el rendimiento al tiempo que permite responder a la creciente demanda. A la vez que la red crece, estamos ajustando los parámetros del protocolo para adaptarnos a las fluctuaciones de precios, ampliar la escalabilidad y las propiedades de rendimiento. Veamos, pues, cómo vamos a optimizar el rendimiento de la red a lo largo del tiempo.
Definiendo la congestión
Un sistema eficiente - desde las redes hasta las carreteras - está diseñado para minimizar la congestión, permitiendo al mismo tiempo una gestión eficaz cuando ésta se produce. Desde la perspectiva de la cadena de bloques, la congestión implica que la red está sobresaturada y experimenta dificultades a la hora de procesar grandes volúmenes de transacciones y firmar los bloques asociados. Por término medio, los bloques de Cardano se utilizan aproximadamente en un 25% en una época determinada, lo que demuestra que, por lo general, la red no está congestionada y que hay una importante capacidad de reserva para procesar un número aún mayor de transacciones.
Cardano se diseñó para ser justo y altamente resistente incluso bajo una fuerte saturación. Recordemos la configuración actual de los parámetros y veamos las futuras optimizaciones previstas. Los parámetros de rendimiento actuales dependen de las siguientes medidas:
-
Rendimiento: la cantidad de datos transferidos. Actualmente, el tamaño de los bloques está fijado en 64 KB. Una sola transacción de las secuencias de comandos de Plutus está limitada actualmente a 16 KB, y las transacciones sencillas pueden ocupar habitualmente unos 300 bytes. Se han equilibrado estas medidas para garantizar una buena utilización de la red y minimizar las latencias de las transacciones. Si se incrementa significativamente y de una sola vez, los usuarios se enfrentarán a un mayor retraso en el tiempo de adopción de bloques. Esto es así porque el rendimiento y la puntualidad están en tensión entre sí - maximizar el rendimiento implica un mejor desempeño de la red, pero esto puede venir a costa de un mayor retraso cuando el sistema está muy saturado.
-
La puntualidad, es decir, el tiempo de adopción de los bloques. El “presupuesto” total para la adopción de bloques se establece en 5 segundos para que un bloque se propague a través de la red (95% del staking) con un presupuesto de aproximadamente 50 milisegundos disponible para las secuencias de comandos de Plutus. La finalidad es permitir que el bloque incluya tanto las secuencias de comandos como las transacciones simples sin que se produzca una monopolización.
Últimamente, algunos usuarios han observado un aumento del tiempo de espera para el procesamiento de las transacciones, que ha sido causado por grandes caídas de NFT (token no fungible). El motivo de esta sobresaturación radica en el hecho de que se liberó una gran cantidad de NFT de una sola vez, lo que provocó lo siguiente:
- Una gran cantidad de transacciones NFT simultáneas
- Que existan múltiples usuarios que intenten comprar la misma NFT y que, por tanto, intenten procesar las transacciones al mismo tiempo.
- Transacciones simultáneas de devolución a los usuarios que no pudieron comprar el NFT
Esto ha creado una escasez en la red para la venta de NFT y, por consiguiente, una enorme demanda del servicio: el 43.000% de la oferta. También cabe destacar que el periodo de “congestión” duró menos de una hora.
Este es un mercado en crecimiento y los creadores de NFT ya están empezando a iterar sus procesos para minimizar el impacto de estas caídas en la experiencia del usuario. Aún es pronto y todos estamos aprendiendo rápido. Hay que destacar que el proceso de acuñación de NFTs es perfectamente paralelizable, es decir, no hay límite para este proceso. Una vez acuñados, los NFT que almacenan el código de intercambio programable y los activos necesarios para las transacciones están listos para interactuar con el mercado.
No obstante, a corto y medio plazo al menos, se tratará de construir sistemas de tráfico más eficientes en lugar de ampliar las carreteras. Hay desarrolladores que ya están produciendo este tipo de sistemas específicamente para las caídas de la NFT, lo que debería reducir los costes, así como las cargas de la red a corto plazo.
Los exchanges descentralizados (DEXs)
Gran parte de las primeras DApps que se están construyendo sobre Cardano son DEXs o Exchanges Descentralizados. En algunos casos, los usuarios tienden a experimentar contención al realizar sus pedidos. Debido a que el diseño de la DApp requiere que todo el estado se mantenga dentro de un UTXO (en lugar de repartirse entre múltiples UTXOs), se produce una dependencia de una transacción futura en una salida de una transacción anterior. Esto se conoce como el “problema” de la concurrencia. Pero, volviendo a la analogía del automóvil, no es un “problema” mayor que el de conducir por la izquierda en el Reino Unido o en Japón. Es cierto que requiere una curva de aprendizaje, pero en última instancia se trata de una forma diferente de hacer las cosas. Si un desarrollador no lo hace, sí que tendrá problemas. Tampoco es intrínsecamente más complejo, sólo requiere un enfoque diferente.
El modelo EUTXO de Cardano es diferente del modelo basado en cuentas. Una DApp desarrollada sobre Cardano debería alejarse del estilo de máquina de estado de un solo hilo y bajar un nivel de abstracción hasta el EUTXO directamente, creando una solución que implique aristas concurrentes en el gráfico del EUTXO. Lo importante es utilizar diferentes conjuntos de EUTXOs, forzando así el paralelismo, lo que mejorará el rendimiento del sistema mientras se mantiene el rendimiento de las operaciones individuales. Por supuesto, esto requiere un cambio de mentalidad para cualquier desarrollador acostumbrado al enfoque de Ethereum. No obstante, el modelo basado en UTXO es más seguro que el modelo basado en cuentas ya que mantener todo el estado en una sola cuenta es más vulnerable a los ataques. Utilizando correctamente las técnicas de paralelismo, los usuarios disfrutarán de mejores resultados en términos de rendimiento y escalabilidad, mientras que las soluciones fuera de la cadena son más aplicables a los ledgers UTXO. Si desea obtener más detalles, lea la entrada del blog sobre concurrencia y cómo construir una DApp Plutus escalable. Próximamente publicaremos información adicional sobre este tema para proporcionar orientación adicional sobre cómo sacar el máximo provecho del modelo.
Hoja de ruta para la optimización
En el momento del lanzamiento, nuestro objetivo fue siempre proporcionar la capacidad básica y la corrección, antes de la optimización. Siempre ha sido nuestro objetivo declarado. Seguimos supervisando el rendimiento y los ajustes de las pruebas de referencia. Conforme la red crezca y Cardano funcione a una mayor capacidad, iremos ajustando la parametrización para seguir el ritmo de la demanda de la red. Se trata de actualizaciones graduales que se aplicarán paso a paso durante los próximos meses para garantizar que los cambios satisfagan los requisitos de la red y no comprometan las diferentes propiedades.
Ya hemos llevado a cabo un amplio análisis y hemos empezado a aplicar métricas de nodo que miden con precisión el tiempo de difusión de los datos. El proceso de difusión de datos consiste en distribuir las transacciones y los bloques entre los nodos que verifican la cadena de bloques. Es esencial proporcionar a los nodos la información necesaria para que el algoritmo de consenso pueda tomar sus decisiones.
Es posible que apliquemos un tiempo medio de espera desde el envío de la transacción hasta su adopción. Además, se están investigando y analizando escenarios que mejoren el rendimiento de la red de forma iterativa a corto y largo plazo, entre los que se incluyen
-
Incremento del tamaño de los bloques: aumentar el tamaño de los bloques supone un mayor número de transacciones en un bloque. La ventaja es que habrá menos tiempo de espera para que las transacciones sean adoptadas por un bloque durante los períodos de saturación de la red. Pero existe una contrapartida. Los bloques más grandes tardan más en propagarse por la red. También significa que los nodos necesitarán más tiempo para verificar las transacciones. Si bien el aumento del tamaño de los bloques es una opción para aumentar el rendimiento de la red, estos cambios deben ejecutarse con precaución. A fin de asegurar que el aumento no comprometa el tiempo de adopción de los bloques, modificaremos gradualmente los parámetros y evaluaremos los resultados durante los periodos de alta saturación. No se trata de una actualización de un solo paso, sino de un enfoque iterativo que nos proporcionará resultados claros y nos ayudará a garantizar los ajustes más eficientes.
-
Tamaño de la mempool - en estos momentos, el tamaño de la mempool está fijado en 128 KB, que es el doble del tamaño del bloque actual. Esta memoria funciona como un buffer de red y puede causar un pequeño retraso al incluir transacciones en un bloque. Pero el aumento del tamaño del mempool no mejorará el rendimiento de la red - las colas de transacciones seguirán siendo las mismas. Esta herramienta permite una adopción justa de las nuevas transacciones que entran en ella de forma aleatoria, basándose en el nodo productor que es elegido por el algoritmo de la lotería.
-
Compresión de scripts - teniendo en cuenta que el tamaño actual de las transacciones está fijado en 16 KB, continuamos trabajando en la compresión, que permite al protocolo “comprimir” el código de forma transparente. Esto supone un mayor número de transacciones de las secuencias de comandos en un bloque debido a su menor tamaño - los desarrolladores podrán enviar código más sofisticado comprimiéndolo a 16 KB o menos, y quedará más espacio para otras transacciones.
La arquitectura para EUTXO
Tal y como se explica en nuestro anterior artículo sobre concurrencia, el modelo EUTXO de Cardano elimina clases enteras de problemas a la hora de diseñar aplicaciones DeFi. Más allá de la capacidad nativa de EUTXO para procesar transacciones en paralelo, la naturaleza determinista del modelo garantiza que los desarrolladores y usuarios puedan evitar el desperdicio de ‘gas’.
Ahora bien, el modelo EUTXO no es lo mismo que el modelo basado en cuentas. Si se transfiere la arquitectura de las aplicaciones destinadas a los sistemas basados en cuentas a un sistema basado en EUTXO, el diseño de la aplicación no será óptimo. Una aplicación diseñada específicamente para el modelo EUTXO de Cardano proporcionará la mejor experiencia de usuario.
En breve publicaremos una profundización técnica sobre cómo los desarrolladores pueden optimizar el envío y procesamiento de pedidos, por ejemplo, al modelo EUTXO.
Iteración y mejora
Por tanto, todavía queda mucho trabajo por hacer mientras seguimos evolucionando e iterando. Aún es pronto, y evaluaremos continuamente el rendimiento de la red y ajustaremos los parámetros en consecuencia a medida que avancemos. En breve, podremos aliviar la congestión de las caídas de NFT distribuyendo más uniformemente la distribución de staking y el cálculo de la distribución de recompensas. Esto, a su vez, nos permitirá aumentar el tamaño de los bloques, eliminar las pausas y la congestión en los límites de las épocas y eliminar los picos de cálculo (que pueden causar una propagación más lenta de los bloques). El incremento gradual del tamaño de los bloques también nos permitirá evaluar los mejores escenarios para el rendimiento de la red y estos resultados serán pronto visibles en la red.
También tenemos previsto trasladar el estado del libro mayor al almacenamiento en disco para facilitar la carga en la cadena, junto con la implementación de la compresión de las secuencias de comandos y las funciones de compartición en la cadena. Una vez concluidas, complementarán en gran medida los ajustes de la red.
A medio plazo, Hydra ofrecerá capacidades adicionales. A largo plazo, nuestro Científico Jefe y el equipo siguen investigando otros métodos y mecanismos en torno a los marcos de precios y la mejora del protocolo Ouroboros para aumentar el rendimiento de las transacciones. En futuros artículos hablaremos de ello.
Dentro de dos meses
Hace apenas dos meses que comenzó la era de los smart contracts en Cardano. Más allá de la expectación y la anticipación en torno al “lanzamiento”, esto nunca iba a ser una mejora de un solo golpe. Al igual que siempre iba a llevar tiempo que el ecosistema cobrara impulso, siempre iba a haber un periodo de adaptación y ajuste, a medida que aumentaran las demandas de la red. Nos encontramos en un viaje y la comprensión de los comentarios de la comunidad sigue siendo clave. Al hablar con muchos de los nuevos e interesantes proyectos #BuildingOnCardano, estamos comprendiendo mejor sus planes y objetivos, así como los problemas a los que se enfrentan, para poder apoyarles y servirles cuando sea necesario. Asimismo, continuamos atentamente el debate en la comunidad.
Aún es pronto y todos estamos aprendiendo. Sin embargo, por su diseño, Cardano está configurado para flexionar y crecer junto a su naciente - aunque ya vibrante - ecosistema. ¡Sigamos todos construyendo!
Si es usted un desarrollador y desea orientación, apoyo, o simplemente le apetece pasarse a charlar en una de nuestras sesiones abiertas, asegúrese de unirse a nuestra creciente comunidad técnica en Discord.*
Agradezco a John Woods, Vitor Silva, Kevin Hammond, Duncan Coutts, Romain Pellerin, Michael Peyton Jones, Jean-Frederic Etienne y Olga Hryniuk su apoyo y sus comentarios en la preparación de este artículo.