Cohetes, amenazas cuánticas, ceros y unos: Dean Little sobre cómo forjar la verdad de Solana

Introducción

Las blockchains se construyen sobre mentiras. Es decir, mentiras corteses que se manifiestan en capas de abstracción. Existe un mundo que el desarrollador ve, lleno de SDKs, APIs y frameworks que prometen velocidad y seguridad. La realidad tiene muchos más matices y está repleta de registros, syscalls y bytecode; una realidad en la que solo los más obsesivos se atreven a entrar. En realidad, toda abstracción genera sobrecarga y todo compilador oculta la verdad.

Dean Little ha dedicado su carrera a navegar por estas mentiras, buscando la verdad al soldar circuitos y programar EEPROMS. Con Bitcoin, creó pools de minería, kernels para GPU y herramientas de SPV. Se mantuvo tan cerca de la máquina como fue posible y aprendió sobre el potencial que los sistemas distribuidos aún no podían alcanzar en aquel momento. Luego encontró Solana, donde es conocido por su herejía: escribir assembly a mano, despreciar los compiladores y abusar de las syscalls. No porque sea divertido, sino porque la velocidad es la verdad.

Como científico jefe de Zeus Network, implementó desde cero todo el protocolo de Bitcoin sobre Solana, lo que permitió el flujo sin fricciones de liquidez en BTC. Y, en una demostración a prueba de troles contra el FUD cuántico, diseñó una bóveda de firmas de un solo uso Winternitz capaz de migrar decenas de miles de activos por segundo, mientras otros apenas sueñan con seis. 

Pero Dean también es profesor. Desde Turbin3 hasta Blueshift y su trabajo reciente como DevRel para el equipo de mercados de mandarín y cantonés de Solana Foundation, lleva a los desarrolladores a un mundo que la mayoría nunca verá. Ha enseñado a cientos de desarrolladores a lanzar proyectos on-chain, a menudo en sus propios idiomas y desde cero. Su tensión es constante: atraer a las personas con abstracciones y luego acercarlas a la máquina. 

Quería entender qué significa vivir en esa tensión: entre la educación y la experimentación, entre la abstracción y el assembly, entre escribir código para humanos y escribir instrucciones para máquinas. Esta entrevista trata sobre ese diálogo y sobre lo que significa hablar directamente con la máquina cuando todos los demás hablan sin escucharla.

Esta conversación se editó y condensó para hacerla más breve. 

Entrevista

Orígenes y visión del mundo

Ichigo: Mucho antes de Solana, reparabas hardware, programabas EEPROMs y escribías sistemas de control integrados para cohetes. ¿Cómo moldeó tu visión del mundo como creador trabajar tan cerca del metal, literalmente con soldadores y firmware?

Dean Little: Aprendí a soldar cuando tenía unos diez años. Crecí trabajando con microprocesadores y microcontroladores. Después pasé al desarrollo web y móvil, hasta que finalmente me uní a una startup de cohetes en Noruega.

Trabajar en sistemas integrados críticos para una misión te enseña varias cosas muy importantes. La primera es prestar atención a los detalles, porque si algo falla, todo puede salir muy mal muy rápido. La segunda es la simplicidad: los sistemas simples, rápidos y fáciles de entender suelen ser mejores que los demasiado complicados. Y la tercera es pensar como un adversario. 

Para mí, trabajar en controles de lastre para cohetes oceánicos significa preguntar constantemente: ¿qué ocurre si este controlador falla? ¿Cómo detectamos el fallo? ¿Qué sistemas de respaldo tenemos? ¿Qué pasa si nuestro control de actitud es incorrecto y creemos que apuntamos hacia arriba cuando en realidad apuntamos hacia abajo? Te obliga a diseñar para el fallo en lugar de asumir que todo funcionará siempre.

Otra cosa que aprendes es a no confiar ciegamente en el trabajo de los demás. Eso se aplica tanto al software como al hardware. Los fabricantes de hardware cambian las especificaciones, el área de compras puede adquirir por error la pieza equivocada y, de repente, nada funciona. Hay muchísimas cosas que pueden salir mal y basta un pequeño error para que falle todo el sistema. Esa mentalidad me ha acompañado desde entonces. 

A partir de ahí, tu carrera te llevó rápidamente a Bitcoin. Trabajaste en pools de minería, kernels para GPU, herramientas de SPV y, más tarde, en Twetch. ¿Qué te enseñaron esos años trabajando en la infraestructura de Bitcoin sobre crear sistemas distribuidos a escala y sobre las limitaciones de las blockchains de la época?

Empecé a dedicarme de tiempo completo al desarrollo de Bitcoin alrededor de 2017. Desarrollé en varias blockchains: Bitcoin, EOS y algunas otras que eran populares en ese momento. Con Bitcoin, al principio solo lo usaba, pero cuando las comisiones se dispararon, básicamente dejó de ser utilizable. Esa fue la primera gran llegada de usuarios minoristas al mundo cripto, y entonces comprendí que, cuando las comisiones se disparan, la blockchain se vuelve inútil.

Esa experiencia me hizo replantear el supuesto «trilema de la escalabilidad». Sinceramente, es un problema inventado y absurdo. Incluso en 2017 podíamos enviar fotos de 4 MB a cualquier parte del mundo en menos de un segundo. Parecía ridículo creer que las blockchains no podían escalar más allá de los bloques de 1 MB. La limitación no era la física, sino el diseño. 

Como la capa base de Bitcoin está tan restringida, te ves obligado a innovar de otras maneras. Terminé profundizando en Secp256k1 y creando soluciones para ocultar resultados de ejecución en firmas. Era una especie de cómputo verificable rudimentario, mucho antes de que ZK empezara a despegar de verdad.

Esos años me enseñaron que dirigir una empresa de Bitcoin en realidad significa dirigir una empresa de infraestructura. El protocolo de Bitcoin puede hacer mucho, pero el software de los nodos es limitado. El modelo UTXO es excelente para la paralelización porque el estado está segregado, de forma muy similar a las cuentas de Solana, pero es terrible para el estado compartido y la indexación. Por otro lado, el modelo de cuentas de Ethereum es excelente para el estado compartido, pero terrible para la paralelización. Lo que me convenció de Solana fue su modelo de cuentas segregadas: combina la paralelización de UTXO con la facilidad de uso del modelo de estado global de Ethereum.

La gran lección que obtuve de esos años fue que los sistemas suelen fallar y, por eso, deben diseñarse para fallar con elegancia en lugar de hacerlo de forma catastrófica. Nunca deberías limitarte a aceptar las restricciones. Deberías desafiarlas de formas creativas que nadie haya considerado. Esa es la filosofía que he llevado a mi trabajo en Solana.

Ahora muchas personas de la comunidad de Solana te conocen como el tipo que escribe assembly y desprecia los compiladores. ¿Por qué te mantienes tan cerca de la máquina? ¿Por qué no te concentras más en mejorar las abstracciones de alto nivel, si ahí es donde desarrollará la mayoría?

Contrario a lo que suele creerse, contribuyo a Anchor, Pinocchio, Agave y Alpenglow; básicamente, a todo. He trabajado en criptografía, SIMDs y programas de bajo nivel en todas las capas del stack. 

El mayor problema del desarrollo en Solana es que todo lo que no sean programas on-chain e infraestructura está completamente restringido. Es casi imposible que mis PRs se integren en algún repositorio oficial. ¿Pero los programas on-chain? Puedo hacer todo lo que, por accidente, el sistema me permita hacer. Ahí nada me detiene. No requiere permisos. Simplemente puedo seguir mejorándolo y llevándolo al límite.

Así que la pregunta es: si observas mi trabajo, su calidad y lo que he hecho por los programas on-chain, y quieres que suceda lo mismo en otras capas del stack, empieza a integrar mis PRs, jaja.

En cuanto al assembly, para ser franco, el compilador hace un trabajo terrible, y las personas que trabajan en él no lo hacen mucho mejor. Nunca se han tomado el tiempo de escuchar de verdad a su cliente final: los desarrolladores. Por eso tuvimos que crear nuestra propia toolchain independiente para facilitarnos la vida.

Por desgracia, la mayoría de los desarrolladores son más o menos promedio. No lo digo como algo malo, pero no son como Cavey, como yo o como los cracks de Ellipsis DeFi, que realmente saben escribir cosas de muy alto rendimiento. Somos este pequeño y extraño subconjunto de desarrolladores que sabe llevar el sistema al límite en su nivel más bajo y mejorarlo para que todos los demás puedan usarlo. 

Nuestros comentarios podrían ser muy valiosos, pero la mayoría de las veces no se toman en serio. Así que terminamos innovando en lo que nadie puede impedirnos tocar: la VM. Por eso me mantengo cerca de la máquina en ese sentido. 

Innovaciones y contribuciones técnicas

Hablando de trabajar en distintas partes del stack —entre Zeus, Jupiter y tu tiempo libre—, has creado e integrado varios primitivos criptográficos avanzados. Crear cualquier tipo de criptografía on-chain ha sido notoriamente difícil en Solana. ¿Cómo será el futuro de la criptografía en Solana? Y, aparte de gritarles a todos que integren tus PRs, jaja, ¿cómo podemos facilitar que otros desarrollen primitivos más avanzados?

Mi opinión es que, hace unos años, teníamos muchos equipos de ZK preparados para desarrollar en Solana. Básicamente les dijimos: «Sí, ya viene», y entonces llegó Firedancer y dijo: «No, no vamos a integrar esto», y todo se retrasó. Algunos de esos equipos habían recaudado fondos y literalmente no podían operar sus negocios porque no tenían los primitivos criptográficos on-chain necesarios, así que tuvieron que irse a otro lugar. Fue muy duro. Está mal tratar así a los desarrolladores. Los primeros clientes del protocolo son los desarrolladores: si no los cuidas, nadie crea nada y los usuarios minoristas no tienen nada que usar. 

Así que dije: está bien, lo resolveré yo mismo. Hackeé la syscall de recuperación de Secp256k1 y básicamente liberé toda la curva. Ahora puedes crear firmas Schnorr, compromisos de Pedersen, Bulletproofs, multiplicaciones arbitrarias de curvas elípticas e incluso direcciones Taproot modificadas, todo sin un solo cambio en el protocolo y con un costo de apenas unas 25 000 CUs. Eso lo hizo una sola persona en su tiempo libre. He lanzado más protocolos criptográficos que Anza, ¿no? Imagina lo que podría ocurrir si realmente se incentivara. Imagina si el desarrollo fuera más abierto. 

Lo curioso es que la mayoría ni siquiera comprende la magnitud de este avance. Voy a una conferencia y les cuento a algunos de los chicos de Arcium lo que creé. Me dicen: «Está increíble». Pero, fuera de las quizá diez personas que realmente entendemos la criptografía a ese nivel en Solana, nadie lo nota. 

Y sobre Anza: son buenas personas, pero solo tienen un criptógrafo, Sam Kim. Aunque es bastante bueno, creo que el hecho de que nadie más en Anza sepa nada de criptografía es una señal bastante negativa. Me incluyeron como revisor para la actualización de Alpenglow. Estoy revisando el código de Sam y, en general, es bueno y sus ideas son sensatas. Supongo que es positivo que reconozcan y aprovechen las habilidades de otra persona. Pero, en última instancia, Anza probablemente nunca será realmente buena en esto. Necesitas varias empresas que compitan, cada una con cierto grado de superposición, pero también con sus propias especialidades. No tiene sentido que Anza intente hacerlo todo. Lo que realmente necesitamos es diversificar el desarrollo del núcleo.

¿Crees que es más bien un problema cultural? Por ejemplo, Ethereum tiene L2s completos dedicados a ZK, como ZKsync o StarkWare. ¿Solana simplemente descartó ZK por considerarlo una solución de escalabilidad poco concreta? Algo como: preferimos llevar el hardware al máximo, así que ese será nuestro enfoque principal y escalaremos la cadena de esa manera. Y aunque ZK no tiene por qué usarse en Solana solo para escalar, se descartó por esa asociación y ahora está en una posición extraña.

Creo que las herramientas no son buenas. No hay ningún tutorial sobre cómo usarlas. Blueshift añadirá algunos; solo estamos intentando integrar lo de los SIMDs Little Endian. Una vez integrado, publicaremos una plantilla de ZK fácil de usar y con muy buen rendimiento, además de algunos tutoriales, porque queremos facilitar que las personas creen cosas y entiendan cómo funcionan.

El problema actual es que pasar de cero a Hello, World! en Solana es completamente absurdo. Si visitas Sui, sigues la documentación durante cinco minutos y ya tienes un Hello, World! funcional. Solana no tiene eso. Esa es la diferencia entre Mysten Labs contratando a unas diez personas que entienden de criptografía y Anza contratando a una, ¿no?

Mi opinión es que existe la percepción de que Solana Foundation tiene una enorme falta de conocimientos técnicos sobre, bueno, casi todo. Su concepto de tecnología solo llega hasta la comercialización, ¿no? Más allá de eso, delegan en Anza la tarea de pensar en estos temas. La idea es que, si la respuesta de Anza dice que algo es bueno, entonces tiene que serlo. La realidad, la mayoría de las veces, es que la respuesta es buena en términos de rendimiento, pero no tanto en todo lo demás.

Desde Foundation se asume que todo va muy bien. Pero la experiencia de los desarrolladores es: «Es difícil de usar». Es tremendamente frustrante para quienes son mejores que las personas que implementan las cosas en el protocolo, hacen el trabajo voluntario, pero no consiguen que su trabajo se tome en serio. Es como: «No sé, no tienen la insignia mágica de Anza; ignorémoslos y evitemos asumir el riesgo reputacional de integrar un PR de la comunidad». Supongo que por eso quizá hayas notado que lucho con tanta firmeza y defiendo tanto a los desarrolladores de código abierto: para que podamos acabar con esto, porque creo que hay muchas personas en la comunidad que presentan PRs realmente buenos. Claro, hay mucha basura generada por IA y mucha porquería, pero también hay muchas personas excelentes que merecen que les prestemos atención. Es una blockchain, una red distribuida; no deberíamos necesitar una especie de insignia de Anza para contribuir. Ellos simplemente deberían asumir la responsabilidad de valorar el buen código, sin importar quién lo haya escrito.

A pesar de todo esto, y hablando más sobre innovación y criptografía, también creaste una bóveda resistente a ataques cuánticos en Solana mediante firmas de un solo uso Winternitz. ¿Qué te inspiró a crear ese proyecto y cómo imaginas que evolucionará en el futuro, quizá cuando las amenazas cuánticas sean más creíbles?

Sinceramente, empezó con un tuit, jaja. Un maximalista de Bitcoin publicó a finales del año pasado: «Solana será la primera víctima de la computación cuántica». Lo leí y pensé: «Está bien, amigo. Si alguna vez necesitamos migrar a las personas de criptografía vulnerable a la computación cuántica a criptografía segura, nuestra cadena puede realizar más de 50 000 migraciones por segundo. La tuya puede hacer unas seis. ¿A quién van a destrozar primero de verdad?».

Así que simplemente dije: al carajo, voy a hacerlo realidad. 

Diez días después, publiqué la bóveda Winternitz y cité su tuit con algo como: GG. 

Esa fue la motivación: alguien dijo que no podía hacerse. Ya llevaba tiempo pensando en esquemas de firmas poscuánticas, pero eso terminó de impulsarme.

Y funcionó. Puedes almacenar fondos en una PDA que esté fuera de la curva, usar la bóveda Winternitz y, pase lo que pase —ya sea que se revierta el ledger o que los ataques cuánticos afecten las firmas de los líderes—, al menos tus fondos estarán seguros en la versión a la que volvamos. No es una solución definitiva, pero es un bote salvavidas perfecto. 

Si administras un fondo con millones o miles de millones en LSTs o SOL en staking y, de repente, cumplir con la seguridad cuántica se convierte en un requisito regulatorio, esto deja de ser un obstáculo para la adopción. No necesitas actualizar el protocolo. Simplemente funciona.

Ahora mismo, creé un firmware para Ledger que genera estas firmas, además de una wallet y una aplicación web. Blueshift probablemente trabaje más adelante este año para convertirlo en algo más fácil de usar. Evidentemente aún no es urgente, pero lo importante es que la opción ya existe hoy. Ese es el avance.

De hecho, es muy gracioso. Toly me envió un mensaje directo al día siguiente. En broma, me dijo: «Amigo, creía que cuando aparecieran las computadoras cuánticas tendría que retirarme en silencio». Yo le respondí: «Jaja, no, amigo, no te retires. Nosotros te respaldamos».

Hablando de Bitcoin, eres científico jefe en Zeus Network, donde prácticamente implementaste desde cero todo el protocolo de Bitcoin sobre Solana. ¿Cuáles fueron los mayores desafíos para lograrlo? ¿Y ves un futuro en el que otras cadenas se reimplementen sobre Solana?

Esa es una pregunta muy interesante. Del mismo modo que las firmas Winternitz eran extremadamente costosas en términos computacionales, pero apenas podían ejecutarse dentro de una sola transacción, Bitcoin se encuentra en ese mismo punto ideal. Es lo bastante sofisticado como para permitir cosas como pruebas SPV, pero todavía lo bastante primitivo como para que Solana, una plataforma más avanzada y eficiente, pueda tomar eso y colocarlo dentro de esto.

Con blockchains de segunda generación como Ethereum, es más complicado. Son mucho menos primitivas y mucho más complejas. Entonces la pregunta es: ¿puede Solana seguir acelerándose y, al mismo tiempo, asignar cada vez más recursos a transacciones individuales? 

Ahora mismo sigue siendo difícil, aunque no imposible. Lo principal que falta hoy para tener compatibilidad con EVM es la syscall BigModExp. Si la habilitáramos, creo que podríamos acercarnos bastante a una paridad completa con Ethereum en el nivel de la VM, lo cual es una locura si lo piensas. 

Pero la pregunta más importante es: ¿para qué molestarse? 

Con Bitcoin, la respuesta es evidente: tiene billones de valor, es el referente del dinero y es lo bastante primitivo como para que Solana pueda replicarlo de manera limpia. 

¿Ethereum? No tanto. 

El «dinero ultrasónico» es un meme. Durante un breve período, el presupuesto de seguridad de Solana llegó a superar al de Ethereum. Entonces, ¿eso convierte a Solana en dinero ultrasónico? Llevar ETH envuelto a Solana no aporta ni de cerca tanto valor como llevar BTC envuelto.

Así que sí, creo que Bitcoin fue el primer objetivo correcto. Era técnicamente viable y económicamente relevante. A medida que Solana siga mejorando, quizá acabemos viendo otras cadenas reimplementadas también. Pero, sinceramente, cuanto mayor sea el rendimiento de Solana, menos necesidad habrá de molestarse con otras cadenas.

La capacidad de concentrar toda esta funcionalidad en una sola transacción es realmente interesante. Hace poco, el desafío de crear actualizaciones de oráculos ultraeficientes captó tu atención y llevaste los límites más lejos con Doppler y sus actualizaciones de 21 CU. ¿Cómo demuestran estas hazañas de bajo consumo de CUs la ventaja de Solana frente a otras cadenas? Hemos visto desarrollos similares en otras cadenas con el gas golfing, pero ¿qué posibilidades únicas abre Solana?

Los oráculos son un caso de estudio muy interesante porque todo el mundo los trata como un problema «resuelto». 

Si retrocedes aproximadamente un mes, Cavey tomó mi programa noop y alcanzó 100 000 transacciones por segundo en mainnet. Fue genial. Ahora veremos si podemos llevarlo aún más lejos. Más concretamente, a 100 000 actualizaciones de oráculos por segundo en mainnet. 

Si eso es posible, destruye por completo toda esta narrativa de que «necesitamos tiempos de bloque más rápidos para competir con Binance». Si puedes actualizar un oráculo cien mil veces por segundo, ¿a quién le importan las actualizaciones de Binance cada 20 milisegundos?

Ese es precisamente el objetivo de la hiperoptimización. Los AMMs propietarios ya usan una especie de actualización de este estilo. No es exactamente lo mismo que estoy publicando, pero quien sabe, sabe. Ahora mismo integran esa lógica en lo profundo de sus estrategias de trading. 

Con Doppler, no hay muchas razones para mantener esa complejidad dentro de sus programas. La actualización del oráculo puede separarse por completo y ejecutarse de manera independiente.

Además, ocupa muy poco espacio. El oráculo Doppler solo ocupa unos 480 bytes. Incluso estoy preparando un SDK de TypeScript para que los desarrolladores puedan implementar su propia versión personalizada directamente desde TypeScript, sin tener que tocar Rust. Solo defines un esquema Borsh, lo publicas y puedes empezar a lanzar actualizaciones de oráculos a toda velocidad. Evidentemente, los desarrolladores de Rust pueden hacer lo mismo, pero me parece interesante que incluso un desarrollador de TypeScript pueda acceder ahora a ese nivel de rendimiento mediante assembly hiperoptimizado bajo el capó.

En cuanto a los casos de uso: los oráculos de aleatoriedad, los contratos perpetuos, los AMMs de oráculo y los AMMs propietarios se benefician. Pero también lo hacen cosas como los canales de pago o el escalado mediante L2. Si puedes abrir y cerrar canales prácticamente sin costo, es enorme. Básicamente, ya no necesitas un programa enorme y abrumador de Anchor solo para actualizar un oráculo. 

Abstracción, assembly e IBRL

Dada tu reputación por escribir assembly, ¿crees que la mayoría de los desarrolladores debería usarlo alguna vez? ¿O es una de esas cosas en las que solo unos pocos llevan los límites al extremo para que el resto pueda desarrollar con seguridad en niveles superiores del stack?

Creo que todos deberían aprenderlo, al menos un poco. George Hotz, probablemente el mejor programador vivo, tiene una frase: todos deberían aprender Python, C y assembly. 

Si no entiendes assembly, no entiendes lo que realmente hace el compilador. Si no entiendes C, no valoras todas las facilidades que te ofrece Python. No creo que Python sea tan excelente, pero Rust, por ejemplo, es un lenguaje muy expresivo que puede usarse tanto en alto como en bajo nivel. Es una gran opción.

Así que sí, diría que aprendas algo de assembly y Rust. En algún momento también tendrás que aprender TypeScript si quieres escribir frontends. Al final del día, creas productos para personas y, si tus usuarios son desarrolladores, TypeScript acabará en tu radar, te guste o no.

Cuando empecé a escribir assembly en Solana, literalmente nadie lo hacía. Creé las herramientas, publiqué ejemplos y ahora hay unos cientos de personas que lo han probado. Quizá diez son realmente buenas. Algunas incluso han escrito programas más impresionantes que los míos. En su mayor parte, solo se trata de dedicar el tiempo necesario para hacerlo realidad.

La mayor parte de lo que hago consiste en cosas pequeñas, elegantes, hiperoptimizadas y con un solo propósito: casos en los que veo la posibilidad de reducir 100 veces el costo de ejecución. Mi función consiste más en explorar e inspirar, y dejar que otros lleven las ideas más lejos. En esta etapa ya no gano mucho promocionando personalmente todo lo que creo, así que prefiero destacar a otros, compartir sus publicaciones y ayudarlos a hacerse un nombre.

Así que sí, creo que todos deberían al menos aprender assembly. Es un gran ejercicio. Pero, al mismo tiempo, también es cierto que un puñado de personas que lleven al límite el nivel más bajo puede crear mejoras que beneficien a todos los demás. 

Si observas la gran mayoría de las mejoras que ha recibido Pinocchio durante los últimos seis meses, todas surgieron de optimizaciones de assembly. Febo revisó cada PR como un auténtico crack y consiguió que se integraran algunas cosas realmente buenas. Mira p-token: es el mismo concepto. 

¿Consideras que programar a bajo nivel no es solo una decisión técnica, sino quizá algo más ideológico?

Sí, creo que es ambas cosas. Por ejemplo, ¿por qué quiere la gente poner un JPEG en Bitcoin? Hay algo primitivo e intrínsecamente interesante en usar este sistema tan limitado para algo que nunca fue diseñado para hacer. Es un poco absurdo y también un poco hermoso. 

La curiosidad termina cuando dejas de hacer preguntas. 

Así que, si eres una persona curiosa, el destino lógico de tu curiosidad probablemente sea algo parecido a: «Escribí algo en TypeScript que consumía un programa de Anchor. ¿Cómo funciona Anchor? ¿Cómo funcionan las macros? ¿Cómo funciona Rust? ¿Cómo funciona assembly?». 

Quizá entonces empieces a profundizar en el compilador de Rust, luego en MIR, después en LLVM IR y en cómo se compila a eBPF. Luego te preguntas qué es eBPF y lees sobre su assembly. Finalmente, acabas mirando el bytecode sin procesar y descubres que puedes eliminar algunos bytes porque el compilador no optimizó algo automáticamente. Ese es el destino lógico de esa investigación. Sin duda hay un aspecto ideológico en ello.

También trabajas con Solana Foundation para ayudar a equipos de habla mandarín y cantonesa a incorporarse, depurar errores y desarrollar. Trabajas con todos estos equipos y los ayudas al simplificar las cosas y hacerlas más accesibles. Al mismo tiempo, eres conocido por defender el assembly y abusar de las syscalls. ¿Cómo concilias esa tensión? ¿Cómo equilibras acercar a los desarrolladores a la máquina con la necesidad práctica de incorporarlos mediante abstracciones de alto nivel?

Si observas Blueshift, básicamente diseñamos un recorrido continuo desde principiante hasta experto. Mi opinión es sencilla: obtienes el nivel de desarrolladores para el que capacitas. Si solo enseñas Anchor o TypeScript, atraes únicamente al tipo de desarrolladores que cree que eso basta. Pero si empiezas a hablar de eliminar unidades de cómputo individuales con assembly escrito a mano, atraes a desarrolladores de otro calibre: personas que realmente entienden lo que significan esas palabras.

Nuestra estrategia con Blueshift es apuntar primero al centro de la curva. Ahí están las cifras y es donde obtienes el mejor ROI. Luego los desplazamos hacia la derecha, los ayudamos a subir de nivel y, finalmente, tienes un ejército de desarrolladores sólidos que pueden apoyar al lado izquierdo de la curva: los principiantes absolutos.

Así es mucho más escalable. Podría pasar horas cada día enseñando a principiantes a usar CPI con el Token Program, algo que representa el 90 % de todos los programas de Solana. O puedo capacitar a cien personas para hacer lo mismo y cada una de ellas puede incorporar a otras cien. Así es como escalas. 

Queremos recibir a las personas sin importar su nivel y seguir llevándolas hacia la derecha. Blueshift, Solana Foundation: el objetivo es el mismo.

Educación, transferencia de conocimientos y comunidad

Hablando de Blueshift, lo cofundaste junto con Turbin3, y ambos tienen una sólida misión educativa. ¿Hacia dónde crees que se dirigirán estas iniciativas en el futuro? 

Turbin3 no era gran cosa cuando me uní. Llegué, escribí todos los programas del plan de estudios y empecé a dirigirlo. Creo que dirigí tres o cuatro cohortes y capacité a todas las personas que ahora son docentes. En nueve meses pasé de no tener nada a sustituirme con personas bien capacitadas, así que no quedaba mucho por hacer. Capacitar a personas mediante una buena formación demuestra que existe un efecto de crecimiento continuo y escalable.

El problema es que reciben mil solicitudes cada trimestre y rechazan quizá entre 800 y 900 personas. Quienes entran pasan por un curso de seis semanas en el que deben asistir a clases tres veces por semana. Al final, no reciben un certificado ni nada que demuestre que se graduaron. Quizá respondan por ti, quizá no. Pero seis semanas es mucho tiempo para esperar que nada salga mal en tu vida. Tu perro podría enfermarse, tendrías que llevarlo al veterinario y faltar a algunas clases. De repente, te atrasas y te expulsan. Los bootcamps tradicionales requieren mucho tiempo y dinero, y en realidad no están optimizados para encontrar a los mejores desarrolladores. O ayudas a personas que en un principio no necesitaban el bootcamp y solo requerían un punto de partida para su carrera, o probablemente llevas de la mano a personas que no lo habrían terminado sin ese apoyo constante. Ninguno de esos caminos permite escalar la incorporación de desarrolladores como Solana necesita hoy.

Así que la mejor pregunta es: ¿cómo tomas a las 800 o 900 personas rechazadas por los bootcamps y les das una oportunidad a las que realmente tienen capacidad? 

Con Blueshift, la respuesta ha sido crear aprendizaje autodirigido de alta calidad. Si puedes seguir el material, puedes terminarlo a tu propio ritmo y obtener un NFT que lo demuestre. Todo es de código abierto y fomentamos activamente los pull requests de la comunidad. También destacamos a las personas en Twitter para ayudarlas a promover e impulsar sus carreras. Las personas envían mejoras, nosotros las integramos y toda la plataforma mejora.

En lugar de decir: «Lo sentimos, no entraste. Más suerte la próxima vez», decimos: «Aquí tienes el plan de estudios; complétalo a tu propio ritmo». Ya tenemos lecciones traducidas a ocho idiomas, por lo que cualquiera puede organizar encuentros o bootcamps en cualquier parte del mundo. Superteam puede usarlo. Forma puede usarlo. Al final tienes un estándar objetivo: las personas obtienen el mismo NFT, sabes qué nivel tienen y puedes contratarlas o plantearles desafíos según corresponda.

Blueshift resuelve todos estos problemas al enfocarse en los desarrolladores motivados y capaces de seguir un aprendizaje autodirigido de alta calidad. Aceptamos que, si publicamos todo como código abierto, las personas serán más críticas y eso permitirá que destaque la sabiduría de la comunidad. Así que integramos sus PRs y terminamos con la mejor plataforma educativa y el mejor contenido disponibles.

Básicamente ya respondiste de forma implícita, pero para hacerlo más explícito: ¿consideras que la educación para desarrolladores es principalmente un problema de traducción —hacer más accesibles las ideas complejas—, un problema de bootcamp —llevar rápidamente a muchas personas a un nivel básico— o algo completamente distinto?

Sí, el principal problema de la educación para desarrolladores en este momento es que los recursos gratuitos que publicamos son una porquería. Gran parte está desactualizada. Básicamente, todos escriben en Anchor o Pinocchio. Nadie usa solana_program. Todo queda obsoleto muy rápido. Por eso, si todo es de código abierto, podemos crear contenido bueno con rapidez y cuidado, y mantenerlo. Parece que nadie más quiere hacerlo, así que nosotros lo haremos porque nadie más quiere. 

Incluso Mert lo reconoció hace seis meses cuando hablábamos del tema. Desde su perspectiva, estaba contento de que alguien hubiera decidido ocuparse de este problema. Y es como: ¿quién mejor que nosotros, no? Tengo el privilegio de ser uno de los desarrolladores más influyentes de este espacio. Todo es de código abierto. No tenemos ninguna ventaja defensiva, jaja. No tenemos una enorme subvención de Foundation; nos financiamos nosotros mismos. Lo hicimos todo por nuestra cuenta y nuestra única ventaja es la ejecución. 

La educación es un proceso continuo. Tienes que encontrarte con las personas en su nivel y ofrecerles cosas lo bastante desafiantes como para que aprendan, pero también lo bastante sencillas, comprensibles y accesibles como para que sigan regresando. Después empiezas a atraerlas hacia la derecha con desafíos irresistibles. Creo que se me da bien, así que Blueshift es la plataforma definitiva para atraer a los obsesionados con los desafíos. Y de repente piensas: «¿Qué demonios? ¿Por qué estoy escribiendo assembly ahora?». 

El Discord de Blueshift también ofrece servicios de DevRel para ayudar a las personas a desarrollar sus proyectos cuando se atascan. Lo más importante es que ni siquiera respondo la mayoría de las preguntas; lo hace la comunidad. Y es mucho mejor que StackOverflow o cualquier otra opción porque tienes una comunidad sólida y participativa.

¿Cómo será el futuro de Blueshift?

El futuro de Blueshift consiste básicamente en dos productos: Coursera y LeetCode. Ya tenemos una versión aceptable —bueno, mejor que aceptable, aunque no ideal— de estos dos productos, pero debe mejorar. Estamos trabajando en una V3, así que mejorará muchísimo. 

Queremos ser extremadamente eficaces para atender a desarrolladores capaces de seguir un aprendizaje autodirigido. Y, sinceramente, ese es el tipo de desarrolladores que preferiría tener en el ecosistema. 

Quiero personas que simplemente se arremanguen y lo intenten. Queremos facilitarles al máximo que lo hagan al proporcionarles buenos recursos. Así que no desperdiciemos su tiempo con basura desactualizada, dependencias rotas y cosas por el estilo. 

El objetivo final es tener una plataforma donde las personas puedan aprender lo que les interesa sin quedar encasilladas y luego demostrarlo al completar distintos desafíos. 

Preguntas rápidas

¿Qué música has escuchado últimamente mientras escribes assembly?

Jaja, normalmente death metal.

¿Cuál es la mejor syscall de la que se puede abusar en Solana?

secp256k1_recover

¿Preferirías escribir C# o Java por el resto de tu vida?

No.

¿Qué es mejor: un modelo basado en UTXO o uno basado en cuentas?

Un UTXO vale más.

Si tuvieras recursos ilimitados, ¿cuál es la iniciativa educativa de tus sueños que lanzarías mañana?

Blueshift más IRL. 

¿Qué consejo darías para enseñar conceptos de bajo nivel de Solana a nuevos desarrolladores sin asustarlos?

Humor autocrítico.

Conclusión

En un mundo de abstracciones de alto nivel y de su aceptación como «realidad» para atraer a las masas, Dean Little se presenta como un puente excepcional: un alquimista de bajo nivel que forja herramientas con los elementos más básicos para elevar a otros sobre sus hombros. Su trayectoria, desde los cohetes hasta la proliferación de actualizaciones de oráculos hiperoptimizadas, revela la ética de un creador. Una ética firme en su búsqueda de la verdad: diseña para el fallo, innova frente a los límites y nunca deposites tu confianza ciegamente en nada.

Ya sea haciendo realidad bóvedas cuánticas por pura voluntad o escalando Blueshift para atraer a la próxima generación de desarrolladores excepcionales de Solana con desafíos irresistibles —con suerte, podrán apoyarse en los hombros de gigantes y no tendrán que masticar tanto vidrio como el resto de nosotros—, Dean encarna el fuego del purista, templado por la calidez de la comunidad. Es un recordatorio de que el verdadero progreso no consiste solo en echar más leña al fuego y apilar una capa sobre otra. Consiste en retirar esas capas para revelar el zumbido de las máquinas y enseñar a otros a bailar con él.

Mientras Solana se precipita hacia su próximo gran salto, ya sea la paridad completa con EVM, Alpenglow o 100 000 actualizaciones de oráculos por segundo, el trabajo de Dean nos susurra un desafío a todos: ¿Por qué conformarte con mentiras corteses cuando puedes soldar tu propia realidad? Si la curiosidad es la chispa, las personas como Dean son el combustible.

Sumérgete, abusa de una syscall, sobrecarga una transacción con funcionalidad compleja y, quién sabe, quizá salgas con tu propio bote salvavidas cuántico.