Solana fue concebida en 2017 cuando su fundador, Anatoly Yakovenko, buscó la manera de que una red descentralizada de nodos coincidiera con el rendimiento de un solo nodo. Ninguna de las principales cadenas de bloques se acerca a lograr esta propiedad. Lograr esto es la estrella del norte de Solana.
Los sistemas de prueba de trabajo como Bitcoin y Ethereum admiten aproximadamente 10 transacciones por segundo (TPS). Los sistemas prácticos de prueba de estaca (PoS) basados en tolerancia a fallas bizantinas (PBFT) como Tendermint admiten alrededor de 1,000 TPS con 100–200 nodos. Solana, una cadena de bloques PoS similar a PBFT, admite más de 50,000 TPS con más de 200 nodos en las iteraciones actuales de testnet, lo que la convierte en la cadena de bloques más eficiente y la primera red descentralizada a escala web del mundo.
Desde su inicio, el equipo de Solana, compuesto por tecnólogos pioneros de Qualcomm, Intel, Netscape y Google, se ha centrado en desarrollar la tecnología necesaria para que Solana funcione con estos estándares de rendimiento innovadores.
Para crear una red descentralizada y sin permisos que coincida con el rendimiento de un solo nodo, el equipo de Solana desarrolló 7 tecnologías clave:
En este ensayo, explicaremos brevemente cada uno de los anteriores. Si desea obtener más información sobre cada uno, también hemos escrito explicaciones detalladas a las que puede acceder haciendo clic en los enlaces de arriba.
Si una red en su conjunto va a coincidir con el rendimiento de un solo nodo, eso implica que el ancho de banda no puede ser el cuello de botella, sino el cálculo. Para lograr esto, primero debemos optimizar cómo se comunican los nodos en la red.
Las redes celulares inalámbricas ofrecen muchas similitudes con las redes basadas en , y durante mucho tiempo se han centrado en optimizar la comunicación de la red. A escala, ninguna torre de radio tiene suficiente ancho de banda para dar a cada teléfono celular su propia frecuencia de radio para transmitir, por lo que las compañías de telecomunicaciones necesitaban "tecnologías de acceso múltiple" para agrupar múltiples llamadas telefónicas en la misma frecuencia.
Time Division Multiple Access (TDMA) es una de las principales tecnologías que permitió una escalabilidad masiva en redes celulares. TDMA especifica que las torres dividen cada frecuencia de radio en intervalos de tiempo y asignan estos intervalos de tiempo a cada llamada telefónica. De esta manera, la torre celular proporciona un reloj disponible globalmente para la red. Esto aumenta enormemente la escalabilidad del ancho de banda limitado al permitir que cada frecuencia admita canales de datos múltiples y simultáneos, y disminuye la interferencia de múltiples teléfonos que transmiten en la misma frecuencia al mismo tiempo.
Las redes actuales basadas en tienen un problema de reloj. Sus relojes "marcan" cada vez que se produce un nuevo bloque. Para Ethereum, eso sucede una vez cada quince segundos, y solo hay tanta información que puede caber en un solo bloque. El equivalente de TDMA para redes basadas en sería un reloj con una granularidad inferior a un segundo que todos los nodos de validación acuerdan, para que puedan procesar las transacciones de manera más eficiente.
La innovación central de Solana es Prueba de historia (POH), una fuente de tiempo sin permiso disponible a nivel mundial en la red que funciona antes del consenso. POH no es un protocolo de consenso o mecanismo anti-Sybil. Más bien, POH es una solución al problema del reloj.
Mientras que otras blockchains requieren que los validadores se comuniquen entre sí para acordar que ha pasado el tiempo, cada validador Solana mantiene su propio reloj al codificar el paso del tiempo en una simple función de retardo verificable secuencial SHA-256 (VDF). Solana no usa un VDF para aleatoriedad. En cambio, cada validador usa el VDF para mantener su propio reloj. Debido a que cada validador mantiene su propio reloj, la selección del líder se programa con anticipación para toda una época. Al igual que Tendermint, el horario de una época dura miles de bloques. Sin embargo, a diferencia de Tendermint, la red nunca espera un nodo fallido. Cada validador ejecuta el VDF para demostrar que ha adquirido su ranura para transmitir un bloque y validadores. Cada validador es compensado por hacerlo porque el productor del bloque recibe una recompensa por producir un bloque.
Habilitado por la Prueba de Historia, los líderes continúan rotando y la red en su conjunto progresa independientemente de las condiciones de la red. Esto significa que la red nunca se detiene. La red puede tomar la decisión de rotar los validadores sin que ninguno de los validadores se comunique entre sí. Este es un cambio sutil pero profundo. Ninguna otra cadena de bloques tiene un mecanismo comparable. En cualquier otra cadena, los validadores deben comunicarse para tomar una decisión. En Solana, las decisiones de rotación de líderes se toman de forma asincrónica.
Esta innovación central abrió el espacio de diseño subiendo la pila. Además de proporcionar un reloj que se puede usar para sellar el tiempo, POH le permite a Solana optimizar el tiempo de bloque (800 ms), la propagación de bloque (log200 (n)), el rendimiento (50K-80 = K TPS) y el almacenamiento de contabilidad (petabytes ) disponible en la red.
Además de Prueba de Historia, Solana corre Consenso de la torre, un algoritmo de consenso similar a PBFT diseñado específicamente para aprovechar el reloj sincronizado. A diferencia de PBFT, Tower Consensus prefiere la vida sobre la consistencia. Al igual que PBFT, los nodos aumentan exponencialmente sus tiempos de espera para llegar a un acuerdo, pero debido a que el libro mayor también es una fuente de tiempo confiable, los nodos pueden observar y examinar los tiempos de espera de todos los demás validadores en la red. Para comprender mejor, consideremos un ejemplo:
Imagina que estás en una isla y una botella flota con una memoria USB. Dentro del disco hay un libro mayor de Solana. Si solo observa el libro mayor, verá que cada nodo puede calcular la cantidad de validadores presentes, el estado de cada validador y, de manera crítica, el tiempo de espera que cada validador ha comprometido con cualquier bloque en la red. Basándose solo en la estructura de datos, sin ningún mensaje de igual a igual, un validador puede tomar la decisión de votar y la red puede llegar a un consenso.
Dado que la capa de consenso de Solana no depende de los mensajes entre pares, Solana puede optimizar cómo se transmiten los bloques a través de la red independientemente del consenso. Turbina, La técnica de propagación en bloque de Solana, se basa en gran medida en BitTorrent. A medida que se transmite un bloque, se divide en pequeños paquetes junto con códigos de borrado, y luego se despliega en un gran conjunto de pares aleatorios. Con un despliegue de 200, la segunda capa de la red puede cubrir 40,000 validadores. Por lo tanto, los validadores pueden propagar bloques con un impacto log200 (n) a la finalidad. Para todos los fines prácticos, si cada conexión es de 100 ms, la replicación se puede lograr en 400 ms y la finalidad en 500 ms para una red de 40,000 nodos.
El mecanismo de abanico debe ser resistente a fallas. Como tal, los validadores codifican datos utilizando códigos de borrado Reed-Solomon, proporcionando un grado de tolerancia a fallas.
En una red de alto rendimiento, la gestión de mempool es una nueva clase de problema que otras cadenas realmente no tienen que abordar. Corriente del golfo funciona empujando el almacenamiento en caché y el reenvío de transacciones al borde de la red. Dado que cada validador conoce el orden de los próximos líderes en la arquitectura de Solana, los clientes y validadores envían las transacciones al líder esperado con anticipación. Esto permite que los validadores ejecuten transacciones con anticipación, reduzcan los tiempos de confirmación, cambien los líderes más rápido y reduzcan la presión de memoria en los validadores del grupo de transacciones no confirmadas.
Los clientes, como las billeteras, firman transacciones que hacen referencia a un bloque de hash específico. Los clientes seleccionan un hash de bloque bastante reciente que ha sido completamente confirmado por la red. Los bloques se proponen aproximadamente cada 800 ms, y requieren un tiempo de espera exponencialmente creciente para desenrollarse con cada bloque adicional. Usando nuestra curva de tiempo de espera predeterminada, un hash de bloque completamente confirmado tiene, en el peor de los casos, 32 bloques de antigüedad. Suponiendo tiempos de bloqueo de 800 ms, eso equivale a 25,6 segundos.
Una vez que se envía una transacción a cualquier validador, el validador la reenvía a uno de los próximos líderes. Los clientes pueden suscribirse a las confirmaciones de transacciones de los validadores. Los clientes saben que un hash de bloque caduca en un período de tiempo finito o la red confirma la transacción. Esto permite a los clientes firmar transacciones que están garantizadas para ejecutarse o fallar. Una vez que la red pasa el punto de reversión, de modo que el bloque de bloqueo de la referencia de la transacción ha expirado, los clientes tienen la garantía de que la transacción ahora no es válida y nunca se ejecutará en cadena.
Para aprovechar la red de alto rendimiento de Solana, creamos El nivel del mar, un motor de procesamiento de transacciones hiperparalelo diseñado para escalar horizontalmente en GPU y SSD. Tenga en cuenta que todas las demás cadenas de bloques son computadoras de un solo subproceso. Solana es la única cadena que admite la ejecución de transacciones paralelas (no solo la verificación de firmas) en un solo fragmento.
La solución a este problema se basa en gran medida en una técnica de controlador del sistema operativo llamada dispersión-reunión. Las transacciones especifican por adelantado qué estado leerán y escribirán durante la ejecución. El tiempo de ejecución es capaz de encontrar todas las funciones de transición de estado no superpuestas que se producen en un bloque y ejecutarlas en paralelo, lo que se denomina ejecución paralela, al tiempo que optimiza cómo se programan las lecturas y escrituras en el estado en una matriz de SSD RAID 0.
Aunque Sealevel es una máquina virtual que programa transacciones, Sealvel en realidad no ejecuta transacciones en la máquina virtual. En cambio, Sealevel entrega las transacciones que se ejecutarán en hardware de forma nativa utilizando un código de bytes probado en la industria llamado Berkeley Packet Filter (BPF), que está diseñado para filtros de paquetes de alto rendimiento. Este código de bytes se ha optimizado desde principios de los 90 y se ha implementado en producción en millones de conmutadores en todo el mundo para manejar 60 millones de paquetes por segundo en una red de 40 gigabits en un solo conmutador.
Cada vez que Nvidia duplica la cantidad de carriles SIMD disponibles, nuestra red duplicará su capacidad computacional. Prácticamente todas las demás cadenas de bloques, que son computadoras de un solo subproceso por diseño, nunca pueden escalar de esta manera.
Usando LLVM, el mismo compilador que apunta a WASM, proporcionamos un gran conjunto de herramientas para que los desarrolladores escriban contratos inteligentes de alto rendimiento en C / C ++ y Rust que ejecutan contratos en GPU. Aunque Solana no está utilizando WASM, los desarrolladores pueden volver a compilar el código C y Rust escrito para compiladores WASM en el compilador Solana con cambios mínimos. Por lo tanto, los desarrolladores pueden migrar fácilmente sus aplicaciones de otras cadenas WASM importantes como Dfinity, EOS, Polkadot y Ethereum 2.0.
Ethereum ha tenido un historial de errores resultantes de la arquitectura del software. Dos ejemplos relevantes:
Definitivamente es posible escribir un código de Solidez seguro, al igual que es posible escribir software complejo en C sin protección de memoria. Pero mientras el comportamiento inseguro sea fácil de agregar y difícil de detectar, será geométricamente más difícil verificar el comportamiento de un software complejo. Tanto Solana como el equipo de Libra reconocieron este problema desde el principio y desarrollaron arquitecturas que mantienen una estricta separación de estado entre los diferentes módulos.
El lenguaje Move introdujo Recursos y Scripts como conceptos de alto nivel. Ambos encajan naturalmente en el tiempo de ejecución de Solana Sealevel y en cómo hemos estado diseñando nuestros programas nativos. Nuestro objetivo es admitir Move como un lenguaje de primer nivel, de modo que los Recursos se comporten como programas nativos de Solana, y se puedan desarrollar y componer a través de Move, oa través de nuestro propio Rust ABI nativo sin comprometer el rendimiento o la seguridad.
No es suficiente simplemente escalar la computación. La memoria que se utiliza para realizar un seguimiento de las cuentas se convierte rápidamente en un cuello de botella tanto en el tamaño como en las velocidades de acceso. Por ejemplo, generalmente se entiende que LevelDB, el motor de base de datos local que utilizan muchas cadenas modernas, no puede soportar más de aproximadamente 5,000 TPS.
Una solución ingenua es mantener el estado global en la RAM. Sin embargo, no es razonable esperar que las máquinas de grado de consumo tengan suficiente RAM para almacenar el estado global. Para Solana, diseñamos Cloudbreak, una arquitectura de estado optimizada para lecturas y escrituras concurrentes distribuidas en una configuración RAID 0 de SSD. Cada disco adicional agrega capacidad de almacenamiento disponible para los programas en cadena, así como también aumenta el número de lecturas y escrituras simultáneas que pueden realizar los programas durante la ejecución.
Junto con nuestro diseño de transacciones, esta arquitectura admite la ejecución de transacciones AOT (Ahead Of Time). Tan pronto como un validador observe una transacción, Sealevel puede comenzar a buscar previamente todas las cuentas del disco y preparar el tiempo de ejecución para su ejecución. Los validadores y los productores de bloques pueden incluso comenzar a ejecutar transacciones antes de que se codifiquen en un bloque, lo que nos permite optimizar aún más el tiempo de bloque y las latencias de confirmación.
A 1GBPS, una red generará 4 petabytes de datos al año para el libro mayor. El almacenamiento de los datos se convertiría rápidamente en el vector de centralización principal, lo que anularía el propósito de la implementación de en el proceso.
En Solana, el almacenamiento de datos se descarga de los validadores a una red de nodos llamados replicadores. Los replicadores no participan en el consenso. La historia del estado se divide en muchas piezas y se codifica por borrado. Los replicadores almacenan pequeñas partes del estado. De vez en cuando, la red le pedirá a los Replicadores que demuestren que están almacenando los datos que deben. Solana aprovecha las Pruebas de replicación (PoRep), que se toman prestadas en gran medida de Filecoin.
Podemos usar la Prueba de la historia, nuestro reloj antes del consenso, para optimizar cómo se crean PoReps. Los nodos replicadores, que no participan en el consenso, usan PoH para generar pruebas livianas mediante las cuales se han replicado partes del libro mayor, y los validadores pueden verificarlas en lotes muy grandes en GPU.
Los replicadores pueden ser nodos livianos (por ejemplo, computadoras portátiles). Con los códigos de borrado y la redundancia, una red de replicadores puede ofrecer garantías de disponibilidad de datos que exceden todo lo que AWS o GCE podrían ofrecer.
Como resultado de estas 7 innovaciones principales, la red Solana es una tecnología de contabilidad distribuida rápida y luminosa que siempre continuará. No se ralentiza por consenso. Además, el sistema optimiza la propagación de datos, aprovecha las GPU paralelas de forma masiva para el procesamiento de transacciones y no pesa los validadores con un historial masivo de cadenas almacenadas.
El software de Solana está diseñado para salir del camino y dejar que el hardware funcione a toda capacidad. Como tal, Solana escala naturalmente con ancho de banda, SSD y núcleos de GPU. Es la única cadena de bloques que lo hace, y así es como Solana logra 50,000 TPS en una red de 200 nodos físicamente distintos en todo el mundo.
Para una explicación más profunda de las 7 innovaciones que hacen posible la red Solana, consulte las publicaciones de blog a continuación:
El testnet de Solana está en vivo hoy. Puede verlo en testnet.solana.com. Para fines de costo, solo estamos ejecutando un puñado de nodos. Sin embargo, lo hemos expandido en muchas instancias a más de 200 nodos físicamente distintos (no en hardware compartido) en 23 centros de datos en AWS, GCE y Azure para realizar evaluaciones comparativas.
El tiempo de ejecución está funcionando hoy, y los desarrolladores pueden implementar código en el testnow ahora. Los desarrolladores pueden construir contratos inteligentes en C hoy, y estamos trabajando agresivamente en la cadena de herramientas Rust. Rust será el lenguaje principal para el desarrollo de contratos inteligentes de Solana. La cadena de herramientas Rust está disponible públicamente como parte del SDK de Solana Javascript, y estamos iterando aún más sobre el Kit de desarrollo de software.
Solana pronto lanzará una versión beta pública de validadores de incentivo para ejecutar nodos a través del Tour de SOL, análogo al Juego de apuestas de Cosmos, que desafía al público en general a probar los límites de la red de Solana mientras gana tokens.