Velocidad de ingeniería: dentro del equipo de rendimiento de Anza con Alessandro Decina

Introducción

El tecnooptimismo es, sin duda, el espíritu cultural de Solana. La confianza absoluta en la velocidad, el progreso y la innovación sin límites sustenta cada pull request que llega a mainnet. El mantra es IBRL: Aumentar el ancho de banda, reducir la latencia. Es, a partes iguales, un mandato de ingeniería, una seña cultural y una oración secular. Si Bitcoin es una catedral dedicada a la permanencia y Ethereum es un ágora para la neutralidad, Solana es una pista de carreras: un reino de velocidad mecánica y medible.

Sin embargo, esta velocidad nunca baja del cielo en un diff perfectamente comentado. La extraen, pulen y convierten en realidad quienes se atreven a mirar código todo el día. Pocos lo miran con más intensidad que Alessandro Decina, originalmente un experto en GStreamer que consideraba los búferes de video entrecortado una afrenta personal. Hoy dirige el equipo de rendimiento de Anza, compuesto por cuatro personas, cuya idea de “autocuidado” es eliminar barras amarillas del seguimiento de un validador a las 3:00 a. m. Su día a día consiste en observar gráficos de llamas, eliminar flujos de trabajo completos y reescribir código de producción probado en batalla porque todo lo que pueda optimizarse terminará optimizándose.

Quería entender qué significa vivir a esta velocidad. Por eso, me senté con el propio Alessandro Decina para descubrir cómo sigue haciendo aún más rápida la blockchain más rápida que existe. La siguiente entrevista es una autopsia de la velocidad. Hablamos desde sus días trabajando con pipelines multimedia hasta las barreras culturales que permiten que cuatro ingenieros lancen más que organizaciones enteras. 

La conversación se editó y condensó para aportar claridad y brevedad.

Entrevista

Orígenes y visión del mundo

Ichigo: Volviendo al pasado, tu primer amor fue GStreamer y los pipelines multimedia. ¿Cuáles fueron las lecciones más importantes sobre latencia de aquella época? ¿Qué te enseñó perseguir audio y video en tiempo real sobre cómo recortar milisegundos en Agave? 

Decina: Antes que nada, buen trabajo investigándome, jaja. Trabajé en GStreamer durante unos 15 años, quizá un poco más. De hecho, ahí aprendí literalmente todo lo que sé. Empecé a contribuir al proyecto cuando era open source y apenas estaba comenzando. Tuve muchísima suerte porque me acerqué al fundador de aquel momento. El tipo tenía, no sé, unos 15 años más que yo y era realmente bueno. Pensé: este tipo aparece en Wikipedia, así que probablemente sea inteligente. No como yo, que finjo serlo. El tipo simplemente decidió: sí, como sea, te enseñaré gratis todo lo que sé. Y así fue como empecé a trabajar en eso.

Es curioso que ahora hablemos de baja latencia mientras trabajamos en Solana, porque esto no tiene baja latencia en absoluto. Cuando hablas de procesamiento de audio, DPSs y hardware multimedia, lo que hacemos en Solana tiene una latencia altísima. Si cualquier sistema de audio o video tuviera un tiempo de respuesta de 400 milisegundos, básicamente estaría roto. Eso no funciona.

En algún momento empecé a trabajar con drivers de Linux y hardware que codifica y decodifica video y audio. Muchas de las cosas que hago hoy son básicamente las mismas que hacía entonces. Cuando trabajas con hardware, la latencia significa que hay una cola en algún lugar. Encuentras esa cola. Intentas minimizarla, reducirla tanto como sea posible y asegurarte de que nunca se quede sin datos.

Por ejemplo, el trabajo con XDP que hago ahora es muy similar al funcionamiento de los búferes circulares de audio. Incluso en esta llamada que tenemos ahora mismo, hay muchos paquetes que llegan desordenados. En algún lugar hay un búfer circular que reordena todos los paquetes, y definitivamente quieres asegurarte de que no se quede sin datos.

Siento que llevo haciendo el mismo trabajo durante los últimos 20 años.

Lo mismo de siempre, en un día distinto, por decirlo así. Porque también vi que trabajaste en Spotify y que hubo algo de Firefox...

Ahh, no, lo de Firefox fue solo trabajo de integración para un hackathon. Jaja, soy tan viejo que escribí la etiqueta de video original para Firefox que usaba GStreamer.

Carajo, jaja. Entonces, ¿todos los caminos llevan de vuelta a GStreamer? 

GStreamer realmente me enseñó programación multihilo. Es la razón por la que estoy en este ecosistema. Hay gente que escribe Assembly y hace todo tipo de trucos de bajo nivel. Yo pienso: sí, llevo mucho tiempo haciendo eso. Y aprendí que, a menos que tengas un lenguaje con un sistema de tipos sólido y un buen compilador, terminas disparándote en el pie. Seguro que puedes hacer algo marginalmente más rápido con Assembly, pero yo de verdad quiero Rust. 

Quiero que el compilador de Rust me diga: eres un idiota; esto no va a funcionar porque tienes un bug aquí. Antes de Rust, sentía que era un 10 % ingeniero de software y un 90 % depurador humano. Solo me dedicaba a depurar cosas. Por eso creo que GStreamer y mi amor por Rust son las razones por las que empecé a trabajar en Solana. Rust estaba ganando popularidad, no había muchos empleos que te permitieran dedicarte a él a tiempo completo y yo había decidido que solo trabajaría con Rust. 

Soy demasiado viejo para escribir C. No quiero un lenguaje sin seguridad de memoria. No quiero perder el tiempo. Así que sí, aquí estoy.

Muy bien. Cuando hiciste el cambio, ¿tenías alguna idea equivocada sobre los sistemas descentralizados antes de trabajar en el código de validadores? ¿Qué te convenció de que la arquitectura de Solana realmente podía escalar? 

En realidad, terminé uniéndome a Solana casi dos años tarde porque estaba ocupado trabajando en el compilador de Rust. Alguien de Solana que apenas empezaba a trabajar en la máquina virtual me envió un correo diciendo: “Ah, estoy haciendo lo mismo. Parece que tú vas un poco más adelantado, ven a trabajar con nosotros”. No respondí ese correo porque investigué Bitcoin y después Ethereum, y me di cuenta de que podías ejecutar cosas, pero tenías 10 TPS. No parecía un proyecto serio, ¿verdad? No puedes hacer nada del mundo real con 10 TPS. 

Así que, cuando recibí ese correo, no respondí. Solo pensé: bueno, esta gente de las criptomonedas todavía no habla en serio.

Toly se puso en contacto conmigo dos años después y revisé el precio de SOL. Pensé: bueno, debí haber abierto aquel correo, jaja. Esta vez sí terminé hablando con él. Antes de la charla, me indicó un código. Lo revisé y, para ser sincero, era horrible. Era código de Rust realmente malo.

Pero después hablé con Toly sin buscarlo en Google, así que no tenía idea de quién era. Era inteligente y dijo todo lo correcto. Dijo: estamos construyendo esto. Actualmente hacemos esto. Obviamente, no es tecnología de punta, pero nuestra ambición es escalar con el hardware. Construimos la blockchain con mayor rendimiento y entonces el hardware se convierte en el cuello de botella. La idea es que, cuanto más hardware le dediques, más escalará.

Y eso me convenció. Sentí que no era solo un grupo de maniáticos de blockchain masturbándose con la Tercera Guerra Mundial... A mí me interesa la tecnología. Soy una de las pocas personas del mundo cripto que realmente está aquí por la tecnología.

Solana tiene esta cultura de ingeniería en la que la tecnología está muy influida por el tecnooptimismo, toda esa cultura de aumentar el ancho de banda y reducir la latencia. ¿Qué opinas personalmente? ¿Cómo influye eso en el día a día de Anza? 

Para mí, Ethereum tiene fundamentalmente una mentalidad de escasez. Es como si dijeran: bueno, chocamos contra algunos muros y vamos a buscar formas de rodearlos. Vamos a inventar toda esta infraestructura para resolver lo que, en esencia, son vacíos de conocimiento que tenemos y que sentimos que no podemos solucionar, ¿verdad?

En cambio, siento que nosotros somos lo contrario. Es como: bueno, hay un problema. No hay problemas imposibles de resolver, salvo los que violan las leyes de la física. Es una diferencia cultural enorme.

Si algo está roto, simplemente decimos: bueno, sentémonos. Hagamos un poco de profiling y veamos cuáles son los problemas. Hablemos con los traders y los creadores de mercado. Veamos qué problemas tienen. Hace poco encontramos problemas muy concretos. Y ya solucionamos la mayoría. Sinceramente, en dos o tres meses podemos solucionarlos todos. 

Hay muchas cosas que hoy no funcionan en Solana. Las conocemos y nunca nos hemos sentado a decir: “¡Tenemos la solución perfecta! Y ahora, para avanzar, necesitamos inventar algo nuevo o investigar y hacer otra cosa”. No: son problemas concretos. La mayoría son problemas realmente tontos. 

Además, no hemos tenido interrupciones recientemente. Personalmente, creo que eso es una señal bajista, ¿verdad? Porque creo que algunas personas han empezado a volverse un poco conservadoras. Sabemos que podemos ir mucho más rápido. Sabemos que mañana podemos tener bloques de 100 millones de CU, ¿verdad? Solo necesitamos acelerar algunas cosas. Y yo estoy a favor de acelerarlo todo.

Fundamentalmente, lo sabemos: no necesitamos una hoja de ruta para saber que podemos multiplicar por 10 el rendimiento actual. Vemos cómo hacerlo. Sabemos cómo hacerlo. O bien ya escribimos el código y no está totalmente terminado, o ya lo escribimos y no podemos implementarlo porque todavía quedan algunos casos extremos por corregir. Pero sabemos exactamente qué hacer.

Sabemos cómo escalar esto.

Ingeniería de rendimiento

Hablando del trabajo de rendimiento, creo que mucha gente no sabe que Anza tiene un equipo dedicado específicamente a eso. Pasa bastante desapercibido. Cuéntame un poco sobre la estructura del equipo. ¿En qué se diferencia de otros equipos de ingeniería de Anza? 

Sí, tenemos distintos equipos en Anza. Ahora mismo tenemos al equipo de consenso, que se concentra en Alpenglow. Tenemos al equipo de redes, enfocado principalmente en Gossip. Está el equipo de AccountsDB, que básicamente solo trabaja en la base de datos de cuentas. Está el equipo de producción de bloques, que trabaja en el scheduler. Y, por supuesto, todos los demás equipos que estoy olvidando.

La diferencia con el equipo de rendimiento es que trabajamos en todo. Hacemos profiling, encontramos un cuello de botella y preguntamos a los equipos pertinentes si tienen tiempo y experiencia porque, a veces, encontramos problemas que no cualquiera puede solucionar. Por ejemplo, si trabajas en consenso, no necesariamente eres la mejor persona para la programación de bajo nivel porque tu especialidad está en otra área. En esos casos, normalmente entramos y corregimos el código por ellos.

Así que no trabajamos en una sola cosa. Simplemente buscamos el siguiente cuello de botella. Nos sincronizamos aproximadamente cada dos semanas y decidimos dónde estamos, qué debemos hacer después y cómo acelerar la siguiente versión.

Otra gran diferencia es que Anza suele contratar personas inteligentes. Si no sabes Rust, no pasa nada. Si no sabes programación de bajo nivel, tampoco pasa nada. Suponemos que, si eres inteligente, podemos enseñarte la mayoría de estas habilidades en el trabajo. Para el equipo de rendimiento, normalmente contrato personas que sí tienen experiencia con el kernel u otras cosas de bajo nivel debido al tipo de cuellos de botella que encontramos ahora mismo.

Por ejemplo, en la base de datos de cuentas hay algunos problemas algorítmicos que debemos corregir. Pero*,* la razón por la que, en la versión 2.3, la base de datos de cuentas es unas diez veces más rápida que hace dos meses es que corregimos la forma en que realiza I/O. Y necesitas entender cómo funciona eso para poder acelerarla. Si solo tienes una comprensión de alto nivel de las bases de datos, no sabes realmente cómo funcionan los discos y no necesitas saber cómo programa el kernel las solicitudes de I/O.

Por eso, personalmente, tiendo a contratar más personas de bajo nivel para el equipo de rendimiento. Repito, ni siquiera me importa si saben Rust, pero sí quiero que hayan trabajado con C o C++ en otras cosas de bajo nivel.

La razón por la que no se sabe mucho que existe un equipo de rendimiento es que básicamente comenzamos en diciembre. Originalmente me contrataron para trabajar en el compilador, pero pasé al rendimiento durante la interrupción de marzo de 2024 y empecé a optimizar cosas. La gente no estaba muy contenta porque un día simplemente les dije que iba a trabajar en lo que quisiera. Así que sí, jaja, no estaban contentos, pero después obtuvimos resultados realmente buenos. Entonces se acercaron y me dijeron: “Bueno, en realidad, ¿quieres contratar a más personas para hacer esto?”. Después, en diciembre, oficializamos el trabajo de rendimiento y formamos el equipo.

Para ser sincero, soy parcial, pero el equipo de rendimiento es, sin ninguna duda, el mejor equipo de Anza.

No lo dudo, jaja. ¿Cuántas personas hay en el equipo? 

Somos cuatro a tiempo completo, pero he estado bromeando en Twitter sobre que Brooks y otras personas se unirán porque empecé a compartir mi profiler con más gente. Hasta hace unos dos meses, solo el equipo de rendimiento tenía acceso al profiler. Ahora todos lo tienen. Por ejemplo, desde que le di el profiler a Brooks, él hace más trabajo de rendimiento que yo, jaja. Está completamente enganchado. Ahora solo se dedica a acelerar todo.

Así que, extraoficialmente, ahora están Brooks y algunos otros que también hacen mucho trabajo de rendimiento. Pero somos cuatro a tiempo completo en rendimiento. 

Al trabajar en rendimiento, ¿qué señal buscas durante el profiling que la mayoría de los ingenieros pasaría por alto? ¿Cómo decides qué debe optimizarse? 

Hay algunas cosas muy evidentes. Cuando empecé a hacer profiling de Agave, pasábamos mucho más tiempo dentro del kernel que ejecutando código en espacio de usuario, lo cual es absurdo. No somos una aplicación de bajo nivel. Si fuéramos un framework multimedia, tendría sentido hacer la mayor parte del trabajo en el kernel porque, en última instancia, necesitas enviar las muestras al hardware. Pero el único trabajo realmente de bajo nivel que hacemos es Turbine.

Por eso, normalmente, la mayor señal de alerta cuando empiezo a hacer profiling es ver mucho amarillo en mis gráficos de llamas, porque significa que pasamos demasiado tiempo en el kernel. Probablemente significa que alguien usa una API de alto nivel que parece inofensiva, pero que internamente tiene un rendimiento atroz.

Durante el último año redujimos unas 10 veces la cantidad de memoria que usa Agave porque, por lo general, nos encontramos con el mismo problema. Cuando haces demasiadas asignaciones de memoria, en algún momento necesitas empezar a interactuar con el kernel. Puedes ver esa interacción en el profiler. Ves de dónde proviene. Ves que esta cadena está saturando la memoria todo el tiempo. La sigues hasta el punto donde estás rotando y asignando demasiada memoria, y lo corriges.

Hay cosas más difíciles. Por ejemplo, encontramos un problema fundamental de diseño que estoy corrigiendo. Como es bien sabido, Solana usa pipelines y tiene distintas etapas. Se supone que todo está paralelizado para que las cosas se ejecuten en paralelo.

En la práctica, por la arquitectura del sistema, tenemos un diseño de pipeline, pero hay muchísimos bloqueos en ese pipeline. Tenemos distintas etapas, pero no maximizamos el rendimiento de todas ellas debido a bugs de diseño absurdos que introducen latencia en varios puntos. Esta latencia es lo que la gente suele criticar cuando no puede enviar transacciones o cuando dice que hay jitter en el sistema. Este jitter no proviene de nada fundamental ni del hardware; simplemente estamos haciendo las cosas de una manera poco óptima. 

Pero, para ser completamente sincero, las cosas en las que trabajamos son tontas. Hay algunos bugs muy evidentes y nosotros simplemente corregimos esos bugs evidentes.

¿Cómo decides si estos bugs justifican microbenchmarks o si debes reproducir por completo el tráfico de mainnet? 

Creo que la mayoría de nuestros problemas de rendimiento provienen de que la gente escribió microbenchmarks. Hicieron más rápidos los microbenchmarks. Los probaron de forma aislada. Después, cuando integras todo en Agave, nada funciona como en los microbenchmarks.

Así que personalmente le digo a la gente: no uses microbenchmarks para absolutamente nada. Incluso reproducir transacciones es algo que quizá hice tres veces durante el último año. Porque, aun cuando reproduces tráfico de mainnet, no lo haces exactamente a la misma velocidad que obtendrías al ejecutar tráfico real de mainnet, así que muchas cosas cambian. 

Y esta es parte de la razón por la que estamos acelerando tanto el inicio porque, de lo contrario, es molesto tener que esperar media hora cada vez que quieres comprobar si tu solución funciona.

Cuando llegas a la etapa en la que estamos con Agave, no puedes adentrarte demasiado en un solo componente. Quizá sea un trabajo intelectualmente interesante, pero es completamente inútil si no consideras todo el sistema. En realidad, no hace avanzar nada. 

Al observar todo el sistema, ¿por qué es tan importante reescribir Turbine para usar XDP? 

Trabajaba en redes justo antes de Solana. Estaba en una startup dedicada a la inspección profunda de paquetes. Básicamente, interceptan todo el tráfico que llega a una NIC, lo analizan en tiempo real para detener flujos maliciosos y después lo reinyectan en el kernel. Básicamente, habíamos escrito toda una pila TCP y UDP en espacio de usuario usando Rust, Tokio y, por supuesto, XDP.

Cuando me uní a Anza, era evidente que en algún momento tendríamos que usar XDP. Cuando comenzó Firedancer, dijeron: “Vamos a empezar con una implementación de Turbine en XDP”, y yo les dije que era una estupidez. No tenía sentido. Hacerlo lleva mucho más tiempo porque XDP es objetivamente una API terrible. Así que quieres evitar usarla durante tanto tiempo como sea posible, hasta que literalmente todo se desmorone.

Entonces piensas: ah, [censurado], ahora tengo que usar XDP, que fue lo que nos ocurrió. Habíamos estado eliminando todos los demás cuellos de botella del pipeline hasta que un día iniciamos pruebas de carga y vimos que Turbine dejaba de funcionar por completo.

Así que dijimos: bueno, claramente esto ya no es viable. Intenté con muchísimo empeño no usar XDP porque ya lo había usado y sabía lo horrible que era. Intenté crear una implementación de Turbine basada en io_uring. Después encontré algunos bugs en io_uring. Empecé a corregirlos. Todavía tengo algunos parches del kernel que quiero enviar, pero en algún momento me di cuenta de que no podía decirles a todos nuestros operadores de validadores que usaran mi kernel personalizado para ejecutar Solana.

Tendré que usar XDP, y eso hicimos. Ahora funciona.

La respuesta es: encuentras el siguiente cuello de botella y lo corriges. Y sigues corrigiendo todos los cuellos de botella que encuentras. Puedes pensar mañana en los problemas de mañana. Ese es mi lema. Podrías preocuparte solo por el mañana, pero entonces el presente sería terrible. Hoy Solana es terrible. Los bloques son demasiado pequeños, Turbine agrega demasiada latencia y el scheduler todavía tiene problemas. Tenemos que corregir las cosas hoy. De lo contrario, no habrá un mañana en el que podamos ir tan rápido.

¿Cómo evitas las regresiones de rendimiento? ¿Cómo te coordinas con Firedancer? 

Las regresiones de rendimiento son una lucha. Personalmente hago profiling de algo en Agave todos los días, al menos varias veces al día, y solemos tener regresiones porque escribir código eficiente es un trabajo en sí mismo. Necesitas saber cómo escribir código eficiente. Si escribes código en Rust, en promedio tendrá mayor rendimiento que si escribes código en Node.js, Python o cualquier otra cosa. Pero si, por ejemplo, trabajas en AccountsDB, donde manejas colecciones con millones de elementos, no puedes limitarte a escribir código. Es difícil crear algoritmos y trabajar eficientemente con grandes conjuntos de datos. 

Así que tenemos regresiones ocasionales. Hasta hace un mes, básicamente me la pasaba gritándole a todo el mundo, jaja. Por ejemplo, Brooks con AccountsDB: creo que en algún momento me odiaba. Tenemos una gran relación, pero hasta hace un mes, prácticamente la mitad de nuestras interacciones consistían en que yo le gritaba porque algo estaba más lento en AccountsDB.

En cuanto al protocolo, trabajar con Firedancer mejoró esto porque siento que muchas partes del protocolo crecieron orgánicamente como respuesta a distintos desafíos. El desarrollo del protocolo comenzó con una idea; la pusieron en producción y, como sucede con la mayoría de las ideas, no funcionó a la primera. Entonces empezaron a agregar cosas encima. Muchas de esas cosas eran ideas realmente malas desde el punto de vista del rendimiento.

Por ejemplo, en Gossip había algo llamado epoch slots mediante lo cual el clúster básicamente transmitía a todos qué validadores habían visto qué slots. Hace unos seis meses, mientras hacía profiling de otra cosa, noté por casualidad que epoch slots consumía más tiempo de CPU que la ejecución real de transacciones. En cuanto al ancho de banda, consumía cuatro veces más que Turbine. Es solo un parche aleatorio que en algún momento se construyó sobre el protocolo para mitigar un problema.

Así que esto ya no ocurre. Y es, en parte, gracias a Firedancer. Ahora, cuando alguien hace una propuesta, tenemos que trabajar con Firedancer. Obviamente están creando otro cliente, jaja, así que tienen que presupuestar el trabajo. Deben decidir cuánto tardaría implementar esa propuesta. ¿Qué prioridad tiene? Así que, para bien o para mal, se oponen a muchas, o casi todas, las modificaciones que hacemos. Y son muy buenos oponiéndose a modificaciones realmente malas. 

Una vez que Turbine se lance con XDP, si tuvieras un mes sin reuniones ni conflictos y total libertad para trabajar en cualquier cosa, ¿qué parte de Agave optimizarías o rediseñarías primero? 

De verdad quiero —literalmente sueño con esto— reescribir AccountsDB desde hace como dos años. Sé que, si empiezo a hacerlo, literalmente me quitará uno o dos meses de vida. Y ahora mismo no es la mejor forma de invertir mi tiempo. Pero lo haré. Sigo intentando presionar a Brooks para que lo haga, pero si él no lo hace, yo lo haré en algún momento.

Desarrollos futuros

De cara al futuro, con funciones previstas como Async Execution o Multiple Concurrent Leaders, ¿cuál sería el mayor dolor de cabeza para el equipo de rendimiento? 

Instintivamente, odio lo async. El modelo actual es muy sencillo. Recibes algunas transacciones, las reproduces muy rápido y después votas. Conceptualmente, es muy fácil. Async complica el diseño, pero también mejora muchísimo la experiencia real de usar la cadena.

También odio el diseño de Multiple Concurrent Leaders, jaja. Entiendo que, especialmente si quieres hacer trading de alta velocidad, necesitas varios líderes. No hay alternativa. Pero, personalmente, eso no ocurrirá hasta dentro de al menos 12 meses. Por eso no quiero distraerme demasiado.

Es importante que dentro de un año tengamos Alpenglow, pero también es importante que el próximo mes alcancemos cien millones de CU. Tenemos que enfocarnos en acelerar lo que tenemos ahora porque Alpenglow es código nuevo y Multiple Concurrent Leaders es código nuevo. Hay incógnitas desconocidas. Supongamos que, por cualquier razón, Alpenglow se retrasa como Firedancer. ¿Entonces qué? ¿Seguimos con la cadena de mierda y lenta que tenemos ahora? No, tenemos que enfocarnos en ir rápido hoy.

Consejos sobre ingeniería de rendimiento

¿Qué recursos recomendarías a alguien con experiencia en Rust que quiera empezar a programar y hacer profiling con énfasis en el rendimiento?

Antes que nada, recomiendo usar un buen profiler, que hoy no existe, jaja. Pero espero publicar el mío pronto. Y realmente creo que la mejor forma de aprender cualquier cosa es hacerlo con algo que de verdad te importe.

Así que mi consejo para quienes quieran aprender a trabajar en rendimiento es que busquen algún software que usen todos los días y que les encante, hagan profiling y lo aceleren, porque mucho software es muy lento. Incluso mucho software rápido puede ser muchísimo más rápido. Las computadoras son realmente rápidas. Y como son tan rápidas, es muy fácil hacer algo lento sin siquiera darte cuenta.

La forma en que veo que mucha gente se engancha es encontrar algo que usas y hacerle profiling: aceléralo, envía pull requests y te garantizo que los aceptarán. Te engancharás por completo.

El kernel es simplemente otra dependencia. Cuando trabajas en algo y usas una biblioteca, es probable que en algún momento tengas que revisar esa biblioteca si algo no funciona, es lento o lo que sea. El kernel es simplemente otra biblioteca. Así que,, lee código del kernel. El código del kernel es de los más sencillos que he visto. Si miras el scheduler del kernel, conceptualmente es más sencillo que el scheduler que tenemos en Solana. 

Simplemente ve y lee el código de Linux. Es C, no es ideal, y todo lo que toca hardware suele estar maldito, jaja, pero la mayor parte de Solana no trabaja directamente con el hardware. Si encuentras cosas genéricas que usas todos los días, como una syscall, Tokio o código del sistema de archivos, eso es muy fácil. Solo ve y léelo. Si pasas una semana leyéndolo, lo aprenderás como cualquier otro código. Y te sentirás como un maldito genio. Pensarás: ahh, ahora puedo trabajar en el kernel, ¿sabes?

¿Cuál es la mejor forma de empezar a contribuir hoy?

Mi preferencia es entrar en Discord y unirte al canal de desarrollo de Solana Tech Discord. Por ejemplo, hay un tipo que ha estado trabajando en algunas cosas de redes y que el otro día simplemente inició una conversación sobre el código de TPU. Para ser sincero, entiende mejor cómo funciona ese código que la mayoría de la gente de Anza. Puedes contribuir. Y si eres tan bueno como ese tipo y me envías parches, los integraré.

No hacemos mucho desarrollo interno y cerrado. Así que, si no ves un pull request en una sección de código que consideras lenta, que conoces bien,, y quieres corregirla, dímelo en Discord. Crearemos un issue, te lo asignaremos y tú lo corregirás.

Quiero que la gente me envíe parches. Quiero hacer crecer nuestra comunidad mediante el envío de parches.

Preguntas rápidas

¿Cuál es el bug más difícil que has eliminado este año?

Una compilación incorrecta de cierto código de punto flotante que bloqueaba la versión 2.2 hace apenas un par de meses. No fue lo más difícil, pero sí lo más tedioso porque tuve que pasar días leyendo código Assembly.

¿Qué música escuchas en bucle cuando estás mirando gráficos de llamas? 

Normalmente house o techno minimalista. Suelo escuchar a Stephan Bodzin en bucle.

¿Cuál es tu distribución de Linux favorita? 

Debian, sin duda. Es la única que no es extremadamente molesta, jaja.

¿Cuál es la mejor optimización que llegará con Alpenglow? 

Que no ejecutaremos votos. Las transacciones de voto son [censurado]. Y es excelente que todo el proceso de votación ya no sean transacciones.

¿Qué opinas de ZK? 

Es una gran tecnología, pero siento que todavía está en plena fase de investigación para escalar blockchains. Así que no me interesa demasiado. 

En julio de 2026, dentro de un año, ¿cuál es tu predicción para el tiempo de slot?

Personalmente, y espero que sea antes, quiero tener slots de 200 milisegundos. Sigo diciéndole a Toly que debe convertirlo en un meme hasta hacerlo realidad. Así que espero que para entonces ya haya ocurrido. Creo que podemos hacerlo incluso hoy. Creo que ese sería el mínimo, en el sentido de que cualquier cifra superior sería un fracaso, pero podemos bajarla aún más.

¿Cuándo alcanzará Agave ese predestinado millón de TPS? 

Jaja, para esa no daré una respuesta rápida. Sigo preguntándole a la gente: “¿De dónde saldrá ese millón de transacciones?”.

Alcanzaremos un millón de TPS cuando la gente tenga un millón de TPS para enviar, pero lamentablemente no creo que vaya a suceder pronto. Sí dije que, si Agave no alcanza un millón de TPS para octubre, renunciaré a mi trabajo. Así que quizá tenga que improvisar una demo engañosa, jaja. 

Conclusión

Alessandro Decina representa el corazón palpitante de la cultura de rendimiento de Solana: una búsqueda incansable de velocidad basada en ingeniería pragmática, no en la perfección teórica. Su equipo de rendimiento logra mucho más de lo que cabría esperar por su tamaño, al encontrar y corregir los “bugs tontos” que, en conjunto, se acumulan hasta provocar ralentizaciones sistémicas.

En un mundo donde muchos equipos se pierden en grandes visiones arquitectónicas, el equipo de rendimiento de Anza mantiene un enfoque absoluto en los cuellos de botella que tiene justo enfrente. Hacer profiling, identificar, corregir y repetir. Es un trabajo poco glamuroso que produce resultados espectaculares: una blockchain que realmente escala con el hardware, en lugar de intentar rodear sus limitaciones.

La conversación anterior revela una verdad fundamental sobre la construcción de sistemas de alto rendimiento: la velocidad no depende solo de algoritmos ingeniosos o hardware de última generación. Depende de un compromiso cultural de nunca aceptar que algo sea “suficientemente bueno” cuando es técnicamente posible que sea “excelente”. Para Solana, esto significa que los slots de 200 milisegundos, Async Execution, Multiple Concurrent Leaders y mantener más de un millón de TPS no son simples hitos técnicos: son inevitables.