Roadmap del rendimiento de StarkNet

Publicado originalmente en inglés por StarkWare el 29 de noviembre de 2022.

TL;DR

• Los rollups de validez no tienen un rendimiento limitado de la misma manera que los L1. Esto da lugar a TPS potencialmente mucho más altos en los rollups de validez L2.
• La hoja de ruta de rendimiento de StarkNet aborda un elemento clave del sistema: el secuenciador.
• Presentamos aquí la hoja de ruta para mejoras de rendimiento:
  — Paralelización del secuenciador
  — Una nueva implementación de rust para Cairo VM
  — Reimplementación del secuenciador en rust
• ¡Los provers, siendo probados como están, no son el cuello de botella y pueden manejar mucho más de lo que lo hacen ahora!

Intro

StarkNet se lanzó en Mainnet hace casi un año. Comenzamos a construir StarkNet enfocándonos en la funcionalidad. Ahora, cambiamos el enfoque para mejorar el rendimiento con una serie de pasos que ayudarán a mejorar la experiencia de StarkNet.

En esta publicación, explicamos por qué hay una amplia gama de optimizaciones que solo son aplicables en los validity rollups, y compartiremos nuestro plan para implementar estos pasos en StarkNet. Algunos de estos pasos ya están implementados en StarkNet Alpha 0.10.2, que se lanzó en Testnet el 16 de noviembre y ayer en Mainnet. Pero antes de discutir las soluciones, revisemos las limitaciones y su causa.

Limitaciones de bloque: Validity Rollups versus L1

Un enfoque potencial para aumentar la escalabilidad de la blockchain y aumentar el TPS sería levantar las limitaciones de bloque (en términos de gas / tamaño) mientras se mantiene constante el tiempo de bloqueo. Esto requeriría más esfuerzo de los productores de bloques (validadores en L1, secuenciadores en L2) y, por lo tanto, requiere una implementación más eficiente de esos componentes. Con este fin, ahora cambiamos el enfoque a las optimizaciones del secuenciador de StarkNet, que describimos con más detalle en las siguientes secciones.

Aquí surge una pregunta natural. ¿Por qué las optimizaciones de secuenciadores se limitan a los validity rollups, es decir, por qué no podemos implementar las mismas mejoras en L1 y evitar por completo las complejidades de los rollups de validez? En la siguiente sección, afirmamos que existe una diferencia fundamental entre los dos, permitiendo una amplia gama de optimizaciones en L2 que no son aplicables a L1.

¿Por qué el rendimiento de L1 es limitado?

Desafortunadamente, el levantamiento de las limitaciones de los bloques en L1 sufre una gran trampa. Al aumentar la tasa de crecimiento de la cadena, también aumentamos las demandas de los nodos completos, que intentan mantenerse al día con el estado más reciente. Dado que los nodos completos L1 deben volver a ejecutar todo el historial, un alto aumento en el tamaño del bloque (en términos de gas) ejerce una presión significativa sobre ellos, nuevamente, lo que lleva a que las máquinas más débiles abandonen el sistema y dejen la capacidad de ejecutar nodos completos solo a entidades lo suficientemente grandes. Como resultado, los usuarios no podrán verificar el estado y participar en la red sin confianza.

Esto nos lleva a entender que el rendimiento L1 debe ser limitado, para mantener un sistema verdaderamente descentralizado y seguro.

¿Por qué las mismas barreras no afectan a los validity rollups?

Solo cuando consideramos la perspectiva completa del nodo vemos el verdadero poder ofrecido por los rollups de validez. Un nodo completo L1 necesita volver a ejecutar todo el historial para garantizar la corrección del estado actual. Los nodos de StarkNet solo necesitan verificar las pruebas STARKs, y esta verificación requiere una cantidad exponencialmente menor de recursos computacionales. En particular, la sincronización desde cero no tiene que implicar la ejecución; un nodo puede recibir un volcado del estado actual de sus pares y solo verificar a través de una prueba STARK que este estado es válido. Esto nos permite aumentar el rendimiento de la red sin aumentar los requisitos del nodo completo.

Por lo tanto, concluimos que el secuenciador L2 está sujeto a un espectro completo de optimizaciones que no son posibles en un L1.

Hoja de ruta de rendimiento por delante

En las siguientes secciones, discutimos cuáles de ellos están actualmente planificados para el secuenciador StarkNet.

Paralelización del secuenciador

El primer paso en nuestra hoja de ruta fue introducir la paralelización a la ejecución de las transacciones. Esto se introdujo en StarkNet alpha 0.10.2, que se lanzó ayer en Mainnet. Ahora nos sumergimos en lo que es la paralelización (esta es una sección semitécnica, para continuar en la hoja de ruta, saltar a la siguiente sección).

Entonces, ¿qué significa “ paralelización de transacciones ”? Ingenuamente, ejecutar un bloque de transacciones en paralelo es imposible ya que diferentes transacciones pueden ser dependientes. Esto se ilustra en el siguiente ejemplo. Considere un bloque con tres transacciones del mismo usuario:

• Transacción A: cambiar USDC por ETH
• Transacción B: pagar ETH por un NFT
• Transacción C: cambiar USDT por BTC

Evidentemente, la Tx A debe producirse antes que la Tx B, pero la Tx C es totalmente independiente de ambas y puede ejecutarse en paralelo. Si cada transacción requiere 1 segundo de ejecución, el tiempo de producción de bloques puede reducirse de 3 a 2 segundos introduciendo la paralelización.

El quid del problema es que no conocemos las dependencias de la transacción por adelantado. En la práctica, solo cuando ejecutamos la transacción B de nuestro ejemplo, vemos que se basa en los cambios realizados por la transacción A. Más formalmente, la dependencia se deriva del hecho de que la transacción B lee de las celdas de almacenamiento a las que la transacción A ha escrito. Podemos pensar que las transacciones forman un gráfico de dependencia, donde hay una ventaja de la transacción A a la transacción B si la A escribe en una celda de almacenamiento que es leída por B, y por lo tanto tiene que ser ejecutado antes de B. La siguiente figura muestra un ejemplo de dicho gráfico de dependencia:

En el ejemplo anterior, cada columna se puede ejecutar en paralelo, y esta es la disposición óptima (mientras que ingenuamente, habríamos ejecutado las transacciones 1–9 secuencialmente).

Para superar el hecho de que el gráfico de dependencia no se conoce de antemano, presentamos paralelización optimista, en el espíritu de BLOCK-STM desarrollado por Aptos Labs, para el secuenciador StarkNet. Bajo este paradigma, intentamos de manera optimista ejecutar transacciones en paralelo y volver a ejecutarlas al encontrar una colisión. Por ejemplo, podemos ejecutar las transacciones 1–4 de la figura 1 en paralelo, solo para descubrir después que Tx4 depende de Tx1. Por lo tanto, su ejecución fue inútil (la ejecutamos en relación con el mismo estado contra el que ejecutamos Tx1, mientras que deberíamos haberla ejecutado contra el estado resultante de aplicar Tx1). En ese caso, volveremos a ejecutar Tx4.

Tenga en cuenta que podemos agregar muchas optimizaciones además de la paralelización optimista. Por ejemplo, en lugar de esperar ingenuamente a que termine cada ejecución, podemos abortar una ejecución en el momento en que encontremos una dependencia que la invalide.

Otro ejemplo es la optimización de la elección de las transacciones que se reejecutan. Supongamos que un bloque formado por todas las transacciones de la figura 1 se introduce en un secuenciador con cinco núcleos de CPU. Primero, intentamos ejecutar transacciones 1–5 en paralelo. Si el orden de finalización fue Tx2, Tx3, Tx4, Tx1 y finalmente Tx5, luego encontraremos la dependencia Tx1 → Tx4 solo después de que Tx4 ya se haya ejecutado — , lo que indica que debe volver a ejecutarse. Ingenuamente, es posible que queramos reejecutar Tx5 también ya que puede comportarse de manera diferente dada la nueva ejecución de Tx4. Sin embargo, en lugar de reejecutar todas las transacciones después de la ahora invalidada Tx4, podemos recorrer el gráfico de dependencias construido a partir de las transacciones cuya ejecución ya ha terminado y sólo reejecutar las transacciones que dependían de Tx4.

Una nueva implementación de rust para Cairo-VM

Los contratos inteligentes en StarkNet se escriben en Cairo y se ejecutan dentro de Cairo-VM, cuya especificación aparece en el Paper de Cairo. Actualmente, el secuenciador está usando una implementación de python de la Cairo-VM. Para optimizar el rendimiento de la implementación de la VM, hemos puesto en marcha un esfuerzo de reescritura de la VM en rust. Gracias al gran trabajo de Lambdaclass, que ya es un equipo invaluable en el ecosistema de StarkNet, este esfuerzo pronto dará sus frutos.

La implementación de la VM en rust, cairo-rs, puede ahora ejecutar código nativo de Cairo. El siguiente paso es manejar la ejecución de smart-contracts y las integraciones con el secuenciador pythonic. Una vez integrado con cairo-rs, se espera que el rendimiento del secuenciador mejore significativamente.

Reimplementación del secuenciador en Rust

Nuestro cambio de python a rust para mejorar el rendimiento no se limita a la máquina virtual de Cairo. Junto con las mejoras mencionadas anteriormente, planeamos reescribir el secuenciador desde cero en rust. Además de las ventajas internas de Rust, esto presenta una oportunidad para otras optimizaciones del secuenciador. Enumerando un par, podemos disfrutar de los beneficios de cairo-rs sin la sobrecarga de la comunicación python-rust, y podemos rediseñar completamente la forma en que se almacena y se accede al estado (que hoy se basa en la estructura Patricia-Trie).

¿Qué pasa con los Provers?

A lo largo de esta publicación, no mencionamos el elemento quizás más famoso de los validity rollups — el prover. Uno podría imaginar que siendo el componente posiblemente más sofisticado de la arquitectura, debería ser el cuello de botella y, por lo tanto, el foco de la optimización. Curiosamente, son los componentes más “ estándar ” los que ahora son el cuello de botella de StarkNet. Hoy, particularmente con pruebas recursivas, podemos incluir muchas más transacciones en una prueba que el tráfico actual en Testnet/Mainnet. De hecho, hoy en día, los bloques StarkNet se prueban junto con las transacciones StarkEx, donde estos últimos a veces pueden incurrir en varios cientos de miles de NFT acuñados.

Resumen

La paralelización, Rust y más — se preparan para un TPS mejorado en las próximas versiones de StarkNet.