Solana Network, una blockchain de alta velocidad para DApps

El funcionamiento de Solana Network recae en una serie de innovaciones creadas específicamente para esta red. Con esto en mente comenzaremos a describir cada una de estas innovaciones, sus implicaciones, posibilidades y su papel dentro de Solana.

Proof of History (PoH), un protocolo de consenso veloz

Como ya hemos comentado la historia de Solana comienza con la publicación del whitepaper de Proof of History (PoH) o Prueba de Historia. Este es un protocolo de consenso muy peculiar. En primer lugar, Proof of History es muy diferente a otros protocolos de consenso conocidas como Proof of Work (PoW) o Proof of Stake (PoS).  ¿La razón? Proof of History usa el tiempo (y las marcas de tiempo o timestamp) para generar un sistema de consenso, a diferencia de Proof of Work (donde se usa un acertijo criptográfico) o Proof of Stake (donde se “apuesta” o se retienen monedas para participar en un sistema de votos).

¿Pero cómo funciona esto? Veámoslo de esta manera: los profesores de física suelen decir que todo lo que sucede a tu alrededor sucede en el espacio y, en el transcurrir lineal del tiempo. Esta “linealidad” del tiempo es esencial para entender fenómenos sencillos como lanzar una pelota y ver como con el tiempo la posición de esa pelota cambia. Así por ejemplo, el momento en el que sueltas la pelota para que esta salga disparada, puedes decir que su tiempo “0 segundo” la pelota está en el origen (tu mano). Pero, al cabo de 10 segundos, la pelota ha llegado a su destino y, en esos 10 segundos transcurridos puedes crear una cronología exacta de lo que ha pasado con la pelota. De hecho, con el conocimiento necesario puedes saber todo sobre lo que ha pasado con la pelota.

Pues esto mismo se aplica a Proof of History. Este protocolo crea un registro con marcas de tiempo exactas de todo lo que sucede en la blockchain. De esta forma, si una moneda se mueve de un monedero a otro, el protocolo anota este evento con una marca de tiempo exacta, un hecho que permite recrear los eventos con exactitud. De esta manera, si nos interesa saber sobre los eventos pasados sobre un token, dirección o determinado smart contracts, solo basta con mirar los registros temporales pasados de esos elementos y lo sabremos todo, desde su origen hasta el momento actual.

Lo bueno de este sistema es que crear marcas de tiempo con pruebas criptográficas no es un trabajo muy complejo computacionalmente hablando. Esto permite que Proof of History (PoH) sea un algoritmo de consenso muy rápido. De hecho, quizás sea uno de los más rápidos solo superado por Proof of Elapsed Time (un tipo de Proof of History, que funciona con aceleración por hardware y que fue creado por Intel para HyperLedger). ¿Lo malo? Proof of History es un algoritmo poco resistente a ciertos ataques y para evitar esto requiere de su uso bajo ciertas condiciones para hacerlo seguro.

En primer lugar, PoH requiere de un fuerte sistema de comprobación y verificación de timestamp. Para ello, este algoritmo se sirve de una función de retardo verificable que requiere de una cantidad específica de pasos secuenciales para evaluarse. Sin embargo, este sistema ofrece una salida única que puede ser verificada pública y eficientemente. Esto evita que cualquier actor malicioso pueda manipular los timestamps y hacer un desastre con el protocolo. Para estar seguros de la potencia de este sistema, el algoritmo hace uso de la función SHA-256 (la misma que usa Bitcoin) para realizar un hash de comprobación, determinando así que verdaderamente se ha cumplido con este paso.

Este proceso de generación de timestamp y verificación de los mismos se hace con cada bloque dentro de Solana. No solo eso, la generación se hace de forma incremental, permitiendo crear una cronología exacta de cada evento.

Tower BFT, un potente protocolo de tolerancia a fallas bizantinas

Otra de las innovaciones de Solana es Tower BFT, un protocolo de tolerancia a fallas bizantinas que combinado a Proof of History ayuda a mantener el funcionamiento seguro de su protocolo de consenso y red descentralizada. Tower BFT, es una evolución de Practical Bizantine Fault Tolerance (PBFT) un protocolo de tolerancia a fallas bizantinas bien conocido en el mundo de la computación distribuida.

El papel de Tower BFT es servir de “juez” dentro del sistema de marcas temporales que se ejecuta en toda la red Solana. De esta manera, Tower BTF usa el reloj sincronizado entre todos los nodos, para servir de punto de control, verificación y aceptación del trabajo realizado por los nodos, permitiendo que se cree un consenso descentralizado sobre dicho trabajo y aceptando el mismo en la red, si este trabajo respeta todas las reglas propuestas por el protocolo Solana.

Al ser Tower BTF un derivado de PBFT, este sistema es muy rápido y, de hecho, el equipo de desarrollo de Solana lo optimizó aún más para evitar que genere latencia innecesaria dentro del sistema. Como resultado, Tower BFT y PoH son capaces de permitirle a Solana altas velocidad de generación de bloques y generación de consenso dentro de la red, estando en promedio en 0,5 segundos por bloque generado dentro de la red.

Turbine y Gulf Stream, transacciones que viajan rápido por la red

Uno de los problemas más grandes dentro de los sistemas distribuidos es el ancho de banda y la necesidad de llevar toda la información generada en la red a todos los nodos que forman parte de la misma. El problema se ve fácilmente, si tienes una red con miles o decenas de miles de nodos, será necesario que cada transacción y evento dentro de la red sea enviado a cada uno de esos nodos para que el evento sea registrado y se genere el consenso deseado. Así, si tienes muchas transacciones (o estas pesan demasiado) esto genera un grave problema de ancho de banda y ralentización dentro de la red.  Bitcoin y muchas criptomonedas solucionan esto desde dos puntos:

1. Usan algoritmos de propagación de información optimizados para redes descentralizadas (como Gossip, Kademlia, u otros).
2. Minimizan al máximo el tamaño de sus transacciones y mantienen “bajo en grasa” sus bloques.

De allí posiciones como los bloques de 2 MB en Bitcoin, o el hecho de que se busque optimizar a un nivel extremista el tamaño de las transacciones.  Sin embargo, esto no es práctico en redes diseñadas para sostener aplicaciones descentralizadas, debido a que limita su crecimiento en muchos sentidos. Así que, para hacer frente a estos dos problemas en Solana se dedicaron a crear los protocolos Turbine y Gulf Stream.

Turbine, es un protocolo de propagación de bloque que facilita la tarea de entregar la información a los nodos, ayudando a mantener el consenso dentro de la red. Este es un proceso esencial que debe ser rápido, puesto que la velocidad de generación de bloques de Solana es veloz (un promedio de 0,5 segundos por bloque) lo que nos indica que la propagación de esta información a la red debe ser igual o más rápida. Para lograr esto, Turbine divide el problema y, con dividir, nos referimos a que la información de los bloques es dividida en pequeñas secciones que son enviadas a la red y reconstruidas por los nodos de acuerdo a sus propios estados.

En pocas palabras, Turbine hace trampa, en lugar de enviar toda la información del bloque, indica el contenido del mismo, ayudando al resto de nodos a reconstruir dicho bloque. Y, en caso de que un nodo no tenga la información necesaria para su recreación, puede solicitar dicha información al resto de la red de forma paralela para hacerlo, reduciendo así el consumo de ancho de banda, maximizando la velocidad y logrando su objetivo de mantener un consenso seguro. Lo curioso es que este sistema funciona en base a un sistema que bien podríamos llamar “piramidal”, porque el nodo generador (el primer nodo), envía una parte de la información a un determinado grupo de nodos, y estos otros nodos reparten la información correspondiente a grupos determinados por ellos. Al final, toda la red recibe la información, recrean el bloque y se genera el consenso.

Pero te preguntarás ¿Cómo saben el resto de nodos de la información necesaria para recrear el bloque recién generado por el primer nodo? Es allí, donde entra en funcionamiento Gulf Stream. Gulf Stream es un protocolo de almacenamiento en cache de transacciones de la red Solana. Su papel es recibir la transacción y enviarla a todos los nodos, pero priorizando a los nodos generadores. De esta forma, todos los nodos de la red tienen en su poder la información necesaria para recrear los bloques usando Turbine. Además recordemos que Solana crea sus bloques gracias a la elección de un quorum que tiene la potestad de generar un bloque y emitir el mismo a la red.

Sin embargo, el papel de estos generadores no es solo crear el bloque, sino también servir de selector del próximo grupo de generación. Así, en todo momento, se conoce de antemano cuáles serán los nodos que generarán el próximo bloque. Aprovechando esto, los nodos pueden recibir las transacciones y enrutarlas a los próximos nodos generadores. De esta manera, se pueden tomar dichas transacciones e incluirlas en el próximo bloque, minimizando el tiempo de producción de bloques. Todo esto es posible porque el proceso de selección de líderes de generación de bloques en Solana es determinista, es decir, se puede saber con antelación quién será el próximo generador de bloques.

Para evitar manipulaciones al sistema, toda transacción en Gulf Stream tiene un tiempo de vida marcado de unos 24 segundos. Si una transacción no es confirmada en ese espacio de tiempo solo se puede esperar una salida: un fallo de transacción y la necesidad de reenviar la transacción. Sin embargo, la velocidad de procesamiento de Solana es tal, que esto solo puede suceder si se llega a su pico máximo de rendimiento, y con la capacidad de llegar hasta 50 mil TPS en su red mainnet actual, esto es difícil de alcanzar.

Sealevel, paralelización de smart contracts

Uno de los mayores avances de Solana es su capacidad para paralelizar la ejecución de transacciones y smart contracts. Recordemos, que en blockchain hasta la más sencilla transacción es en realidad un smart contract, y esto aplica desde Bitcoin y por supuesto en Solana. Pues bien, Solana se sirve de lenguaje C y Rust para crear un ambiente de programación de smart contracts único, y entre sus posibilidades está, la de paralelizar su ejecución. Esto es posible gracias a Sealevel, el nombre con el que los desarrolladores de Solana han identificado esta función.

Ejemplo de smart contract en Solana escrito en lenguaje C

Sealevel permite que Solana puede leer, ejecutar y escribir instrucciones de forma paralela dentro del layer de ejecución de smart contracts de Solana. A diferencia de redes como Ethereum y EOS, donde sus sistemas de smart contracts son de un solo hilo de ejecución (solo se puede hacer una acción a la vez), Solana puede ejecutar múltiples acciones al mismo tiempo, ejecutar diferentes smart contracts y usar todos los recursos computacionales de la red de forma paralela.

Para verlo de forma más simple, imagine que tiene que una carpeta con 100 hojas de papel y cada hoja tiene 10 problemas. Esto es un total de 1000 problema que debe ser resuelto por la red computadoras. Si ponemos a una red como Ethereum a resolver estos problemas, lo que pasará es que se tomaría cada hoja, y se resolvería cada problema uno por uno hasta terminar con todos ellos. En Solana, lo que pasaría es que se tomarían las 100 hojas y se resolverán los 10 problemas de cada una de ellas, al mismo tiempo. Esto deja en claro una cosa: si los computadores de la red Solana son potentes, la ejecución de Solana será mucho más rápida de la que podría hacer Ethereum. De hecho, para Ethereum sería imposible alcanzar la velocidad de Solana.

Sealevel resulta útil porque ayuda a Solana a escalar de una forma en que otras redes no pueden. Por ejemplo, si instalamos un nodo de Solana en equipo poco potente, nuestra capacidad de procesamiento será menor. Pero si actualizamos el equipo, nuestra capacidad de procesamiento aumenta. Esto permite que la eficiencia y potencia de nuestros equipos computacionales tenga un impacto directo en la escalabilidad de Solana, lo que precisamente se pudo demostrar en sus redes de pruebas y sus picos de rendimiento de hasta 500 mil transacciones por segundo. Adicionalmente esto nos dice otra cosa de Solana: no se necesita de segundas capas, Solana es lo suficientemente capaz de manejar todo directamente sobre la blockchain.

Otras funciones interesantes en Solana

Por otro lado, Solana es una red dedicada al despliegue de aplicaciones descentralizadas (DApps). En tal sentido, Solana cuenta con sistemas para el almacenamiento distribuido (conocido como Archivers), el cual permite almacenar información de primer nivel para las aplicaciones facilitando el acceso a dichos recursos en toda la red.  Adicional a esto, Solana cuenta con un sistema conocido como Cloudbreak, que permite mantener una estructura de datos uniforme en todos sus nodos.

En pocas palabras, Solana es un proyecto altamente innovador con soluciones propias a muchos de sus problemas y desafíos técnicos, con el fin de hacer realidad una de las redes blockchain más rápidas que existen en la actualidad.