¿Quién es Anatoly Yakovenko? El creador de Solana

Anatoly Yakovenko es cofundador de Solana, una red blockchain cuyo diseño busca coordinar muchos ordenadores con el menor retraso posible. Antes trabajó en sistemas donde unos milisegundos y unos cuantos mensajes de red podían cambiar el rendimiento de todo el producto. Esa experiencia ayuda a entender por qué convirtió la coordinación del tiempo en una parte central de su propuesta.

El ingenio de esa propuesta está en dar peso arquitectónico a una pregunta aparentemente pequeña: cómo se ponen de acuerdo los equipos sobre el tiempo. El recorrido desde Qualcomm hasta Proof of History permite estudiar esa idea y reconocer el trabajo de los cofundadores y equipos que la llevaron a una red operativa.

¿Quién es Anatoly Yakovenko?

Anatoly Yakovenko es el ingeniero que formuló la arquitectura inicial de Solana y uno de sus cuatro cofundadores. Su aportación distintiva fue Proof of History, una secuencia criptográfica que permite verificar el orden y el paso del tiempo entre eventos. La propuesta abordaba un problema concreto de coordinación en las redes distribuidas.

La Solana Foundation documenta que antes de fundar la red lideró trabajo de sistemas operativos en Qualcomm, sistemas distribuidos en Mesosphere y compresión en Dropbox. También participó en el núcleo de BREW, software que llegó a funcionar en más de 100 millones de teléfonos CDMA. Esa experiencia en sistemas operativos y distribuidos ayuda a entender las prioridades de diseño de Solana.

¿Qué aprendió Anatoly Yakovenko antes de Solana?

Aprendió a optimizar sistemas donde el tiempo, el ancho de banda y el trabajo en paralelo importan. Pasó 13 años en Qualcomm trabajando cerca del hardware y de redes inalámbricas. En 2016 se incorporó a Mesosphere y en 2017 a Dropbox, donde trabajó en compresión y rendimiento de infraestructura distribuida.

Ese bagaje cambió la pregunta. En lugar de aceptar que una red blockchain debía coordinarse como las primeras redes públicas, Yakovenko buscó qué técnicas de telecomunicaciones podían eliminar mensajes innecesarios. Su experiencia le permitió ver el consenso como un problema de sincronización entre máquinas antes que como una cuestión monetaria.

¿Cómo surgió la idea de Proof of History?

La idea surgió en octubre de 2017 al pensar en SHA-256, la función hash también utilizada en Bitcoin, como una secuencia deliberadamente lineal. Si cada resultado alimenta al siguiente, producir la cadena requiere tiempo, pero comprobar distintos tramos puede hacerse en paralelo. Esa secuencia funciona como un reloj verificable que establece qué ocurrió antes y después.

Proof of History no sustituye a Proof of Stake ni constituye por sí solo un mecanismo de consenso. El whitepaper de Solana lo presenta como una prueba para ordenar eventos y reducir mensajes entre máquinas. En la arquitectura original, Tower BFT combinó ese reloj con los votos ponderados por stake de los validadores. Esta distinción describe el diseño fundacional; no convierte cada componente original en una obligación permanente del protocolo.

La diferencia es importante. El rendimiento de Solana procede de un conjunto de decisiones conectadas, entre ellas Proof of History, ejecución paralela con Sealevel, propagación de bloques con Turbine y reenvío de transacciones con Gulf Stream. Reducirlo todo a un reloj rápido oculta la arquitectura que hace posible procesar trabajo concurrente.

¿Quiénes fundaron Solana junto a Yakovenko?

Solana tuvo cuatro cofundadores con responsabilidades complementarias. Presentar a Yakovenko como creador único borra el trabajo que convirtió un documento técnico en software abierto, una empresa y un ecosistema de validadores y aplicaciones.

• Anatoly Yakovenko formuló Proof of History y la arquitectura inicial.
• Greg Fitzgerald llevó el prototipo desde C a Rust y publicó la primera implementación abierta en febrero de 2018.
• Stephen Akridge propuso aprovechar GPU para verificar firmas en paralelo.
• Raj Gokal se incorporó en diciembre de 2017 para construir la organización y desarrollar el mercado.

El proyecto se llamó primero Loom. El equipo cambió el nombre para evitar confundirlo con Loom Network y eligió Solana por Solana Beach, la localidad de California donde Yakovenko, Fitzgerald y Akridge habían practicado surf durante su etapa en Qualcomm.

¿Cuándo pasó Solana del papel a una red pública?

El primer prototipo abierto apareció en febrero de 2018 y Mainnet Beta arrancó el 16 de marzo de 2020. El lanzamiento llegó después de más de dos años de pruebas con validadores. Rust quedó como lenguaje principal del cliente y hoy también sostiene buena parte del desarrollo de programas de Solana con Anchor.

La capacidad de procesamiento tiene costes. El hardware exigente puede elevar la barrera de entrada para validar, y la ejecución paralela obliga a diseñar bien el acceso a cuentas. Elegir una arquitectura para Solana requiere evaluar seguridad, recuperación ante fallos y comportamiento bajo carga, además de la velocidad anunciada. La etiqueta de lanzamiento Mainnet Beta no basta para juzgar por sí sola esas propiedades.

¿Es Anatoly Yakovenko el dueño de Solana?

No. Yakovenko cofundó Solana Labs y conserva influencia técnica y pública, pero no posee ni puede modificar por sí solo la red. Los validadores ejecutan el software, votan bloques y deciden qué versiones adoptan. La Solana Foundation es una organización independiente que apoya la descentralización, la seguridad y la adopción del protocolo.

La apertura tampoco elimina la concentración. El informe de salud de junio de 2025 documentó una dependencia elevada de clientes de la familia Agave. Firedancer representa un esfuerzo independiente para diversificar el software. El informe es una fotografía fechada, no una medición actual: la descentralización debe examinarse por operadores, distribución del stake, clientes y capacidad de intervenir en cambios de protocolo.

¿Cuál es hoy el legado técnico de Yakovenko?

Su legado es demostrar que una red pública puede diseñarse desde los principios de sistemas de alto rendimiento. Solana optó por mantener un estado global compartido y aumentar la capacidad de una sola capa, en vez de depender desde el inicio de fragmentar la ejecución. Esa elección facilita la componibilidad, aunque exige máquinas potentes y disciplina operativa.

Para un equipo de desarrollo, esa arquitectura cambia el trabajo de producto. En Solana no basta con trasladar patrones de EVM. El modelo de cuentas y la ejecución paralela obligan a definir qué datos lee o modifica cada instrucción y dónde pueden aparecer conflictos. El rendimiento depende de esas decisiones, no solo de una optimización final.

Yakovenko también ayudó a medir el protocolo frente a sistemas en producción, no solo frente a otras redes. La referencia útil no es un máximo de laboratorio. Importa si una aplicación responde bajo contención, si los validadores se recuperan de un fallo y si clientes independientes reducen el riesgo de compartir el mismo software. La fiabilidad forma parte del rendimiento.

La evolución tampoco termina en Proof of History. La propuesta Alpenglow plantea sustituir componentes del consenso original. Su propuesta, aprobación y activación son hitos distintos: no debe presentarse una hoja de ruta como una capacidad ya desplegada. Es también un recordatorio de que Solana evoluciona mediante aportaciones de varios equipos, no solo de Yakovenko.

Si necesitas convertir esa arquitectura en un producto en producción, nuestro equipo de desarrollo blockchain diseña, prueba y despliega la infraestructura necesaria.