Tabla de contenido
Límites de bloqueo: acumulaciones de validez frente a L1
¿Por qué el rendimiento L1 es limitado?
¿Por qué las mismas barreras no afectan los acumuladores de validez?
Paralelización del secuenciador
Nueva implementación Rust de Cairo-VM
Rust reimplementa el secuenciador
Prefacio
StarkNet se lanzó en la red principal hace un año y la construcción de StarkNet se centra principalmente en el nivel funcional. Ahora centramos nuestra atención en las mejoras en el rendimiento de la red, con el objetivo de mejorar la experiencia StarkNet a través de una serie de mejoras funcionales.
Límites de bloqueo: acumulaciones de validez frente a L1
Una forma potencial de mejorar la escalabilidad de la cadena de bloques y el TPS es aumentar el límite de bloques (en términos de gas/tamaño) manteniendo el tiempo de bloque sin cambios. Esto requerirá más esfuerzo por parte de los productores de bloques (validadores en L1, secuenciadores en L2), por lo que estos componentes deberán implementarse de manera más eficiente. Con este fin, la atención se centra ahora en las optimizaciones del secuenciador StarkNet, que se describen con más detalle en las siguientes secciones.
Naturalmente, aquí surge un problema. ¿Por qué las optimizaciones del secuenciador se limitan a los resúmenes de validez, es decir, por qué no podemos lograr la misma mejora en L1 y evitar por completo la complejidad de los resúmenes de validez? En la siguiente sección, se mostrará que existe una diferencia fundamental entre los dos y que las optimizaciones que se pueden realizar ampliamente en L2 no se pueden realizar en L1.
¿Por qué el rendimiento L1 es limitado?
Desafortunadamente, levantar las restricciones de bloqueo en L1 conlleva un gran peligro. Al aumentar la tasa de crecimiento de la cadena, también aumentamos la demanda de los nodos completos mientras intentan mantenerse al día con el estado más reciente. Dado que los nodos completos L1 tienen que volver a ejecutar todo el historial, un gran aumento en el tamaño del bloque (en términos de gas) ejercerá una enorme presión sobre ellos, lo que nuevamente provocará que las máquinas más débiles salgan del sistema y conserven la capacidad de ejecutar nodos completos. limitado a una entidad lo suficientemente grande. Como resultado, los usuarios no podrán verificar su estado por sí mismos y participar en la red sin confianza.
Esto nos lleva a comprender que el rendimiento de L1 debe limitarse para mantener un sistema verdaderamente descentralizado y seguro.
¿Por qué las mismas barreras no afectan los acumuladores de validez?
Sólo considerándolo desde la perspectiva de un nodo completo podemos ver el verdadero poder que proporciona la agregación de efectividad. Los nodos completos L1 deben volver a ejecutar todo el historial para garantizar la exactitud del estado actual. Los nodos StarkNet solo necesitan verificar la prueba STARK, y la cantidad de recursos informáticos ocupados por esta verificación disminuye exponencialmente. En particular, la sincronización desde cero no implica necesariamente la ejecución; un nodo puede recibir un volcado del estado actual de sus pares y solo puede verificar que el estado es válido mediante una prueba STARK. Esto nos permite aumentar el rendimiento de la red sin aumentar los requisitos de nodo completo.
Por lo tanto, concluimos que el secuenciador L2 se ve afectado por todo el alcance de optimización, lo que no es posible en L1.
Paralelización del secuenciador
Entonces, ¿qué significa "paralelización de transacciones"? Para ser honesto, no es posible ejecutar un bloque de transacciones en paralelo porque diferentes transacciones pueden depender entre sí. Esto se ilustra en el siguiente ejemplo. Considere un bloque que contiene tres transacciones del mismo usuario:
Tx A: Intercambia USDC por ETH
Tx B: Paga ETH por NFT
Tx C: Intercambia USDT por BTC
Obviamente, Tx A debe ocurrir antes que Tx B, pero Tx C es completamente independiente de los dos y puede ejecutarse en paralelo. Si cada transacción tarda 1 segundo en ejecutarse, al introducir la paralelización, el tiempo de bloque se puede reducir de 3 segundos a 2 segundos.
El quid del problema es que las dependencias de las transacciones no se conocen de antemano. De hecho, sólo al ejecutar Tx B del ejemplo se puede ver que depende de los cambios realizados por Tx A. Más formalmente, esta dependencia surge del hecho de que Tx B lee de la celda de memoria escrita por Tx A. Tx puede considerarse como un gráfico de dependencia, donde hay un borde de Tx A a Tx B si y solo si A escribe en una unidad de memoria que B lee y, por lo tanto, debe ejecutarse antes que B. La siguiente figura muestra un ejemplo de dicho gráfico de dependencia:
En el ejemplo anterior, cada columna se puede ejecutar en paralelo, lo cual es una programación óptima (de hecho, las transacciones 1 a 9 se ejecutarán secuencialmente).
Para superar el hecho de que el gráfico de dependencia no se conoce de antemano, considere introducir un paralelismo optimista en el secuenciador StarkNet haciendo referencia al concepto de BLOCK-STM desarrollado por Aptos Labs. Bajo este paradigma, intentamos con optimismo ejecutar transacciones en paralelo y volver a ejecutarlas cuando se descubren conflictos. Por ejemplo, podríamos ejecutar Tx 1-4 en la Figura 1 en paralelo, solo para luego descubrir que Tx 4 depende de Tx1. Por tanto, su ejecución es inútil (. En este caso volveremos a ejecutar Tx4.
Vale la pena señalar que se pueden agregar muchas optimizaciones además de la paralelización optimista. Por ejemplo, en lugar de esperar ingenuamente a que finalice cada ejecución, puede cancelar la ejecución cuando se encuentre una dependencia que la invalide.
Otro ejemplo es optimizar la selección de qué transacciones volver a ejecutar. Supongamos que el bloque que contiene todas las transacciones en la Figura 1 se introduce en un secuenciador con cinco núcleos de CPU. Primero, intente ejecutar las transacciones 1 a 5 en paralelo. Si el orden de finalización es Tx2, Tx3, Tx4, Tx1 y finalmente Tx5, solo después de que se haya ejecutado Tx4, encontraremos la dependencia Tx1 → Tx4, lo que indica que debe volver a ejecutarse. De hecho, es posible que desee volver a ejecutar Tx5 también, ya que podría comportarse de manera diferente dada la nueva ejecución de Tx4. Sin embargo, es posible recorrer el gráfico de dependencia creado mediante la ejecución de transacciones que han terminado y volver a ejecutar solo las transacciones que dependían de Tx4, en lugar de simplemente volver a ejecutar todas las transacciones después del Tx4 ahora no válido.
Nueva implementación Rust de Cairo-VM
Los contratos inteligentes en StarkNet se escriben en El Cairo y se ejecutan en Cairo-VM, la especificación aparece en el documento de El Cairo. Actualmente, el secuenciador utiliza la implementación en Python de Cairo-VM. Para optimizar el rendimiento de la implementación de la VM, iniciamos el trabajo de reescribir la VM en Rust. Gracias al gran trabajo de Lambdaclass, quienes ahora son un equipo invaluable en el ecosistema StarkNet, este trabajo pronto se hará realidad.
La implementación cairo-rs de Rust de la VM ahora puede ejecutar código nativo de Cairo. El siguiente paso es gestionar la ejecución del contrato inteligente y la integración con el secuenciador pitónico. Una vez integrado con cairo-rs, se espera que el rendimiento del secuenciador mejore significativamente.
Rust reimplementa el secuenciador
Nuestra transición de Python a Rust para mejorar el rendimiento no se limita a Cairo VM. Además de las mejoras anteriores, también planeamos reescribir el secuenciador desde cero en Rust. Además de las ventajas internas de Rust, esto abre oportunidades para otras optimizaciones en el secuenciador. Por nombrar algunos, puede aprovechar los beneficios de cairo-rs sin la sobrecarga de la comunicación python-rust y rediseñar completamente cómo se almacena y se accede al estado (hoy se basa en la estructura Patricia-Trie).
¿Qué pasa con los probadores?
A lo largo de este artículo, no hemos mencionado el elemento más importante de la agregación de efectividad: el probador. Posiblemente, como posiblemente el componente más complejo de la arquitectura, debería ser el cuello de botella y, por lo tanto, el foco de la optimización. Curiosamente, el cuello de botella de StarkNet en este momento son los componentes más "estándar". Hoy en día, especialmente para las pruebas recursivas, se pueden incluir más transacciones en la prueba que el tráfico actual en testnet/mainnet. De hecho, hoy en día, los bloques StarkNet se están probando junto con las transacciones StarkEx, que a veces dan como resultado cientos de miles de NFT mints.
Resumen
Paralelización, Rust y más: prepárese para TPS mejorado en las próximas versiones de StarkNet.
referencia
https://starkware.medium.com/starknet-rendimiento-roadmap-bb7aae14c7de