“Las criptomonedas” son uno de los temas centrales en medios de comunicación, redes sociales y portales de noticias de los últimos años, llegando únicamente de forma superficial al público general. Pero la realidad es que detrás de este simple término o noticias tendenciosas hablando sobre el aumento del precio del Bitcoin, hay enormes comunidades, fundaciones y empresas, respaldadas por fuertes inversiones, que trabajan día a día para el desarrollo y crecimiento de una tecnología disruptiva basada en la descentralización, seguridad y escalabilidad que busca cambiar el paradigma de los sistemas actuales.

Dentro de todas las blockchains existentes como pueden ser Bitcoin, Ethereum o Cardano, por mencionar algunas de las más conocidas, cabe destacar el proyecto de Solana.

¿Por qué Solana? Es el disparador que impulsa la escritura de este post y lo que se va a intentar responder a lo largo del mismo. ¿Qué llevó a Anatoly Yakovenko en noviembre de 2017 a publicar un whitepaper describiendo la técnica de Proof of History (PoH), piedra fundacional del proyecto de Solana?

Historia

Corría noviembre del año 2017 y Bitcoin alcanzaba un máximo histórico de $8.100. Nuevas criptomonedas entraban al mercado como Bitcoin Cash, EOS.IO, Cardano y TRON y la tecnología blockchain había alcanzado un nivel de entendimiento global, afirmando su posición como un avance capaz de transformar la estructura financiera existente. Tanto corporaciones como gobiernos comenzaban a hacer uso de la misma.

Anatoly Yakovenko, quién había liderado el desarrollo de sistemas distribuidos en Qualcomm, Mesosphere y Dropbox, no le prestó mucha atención al lanzamiento de Bitcoin. Sin embargo, terminaron despertando su interés las finanzas descentralizadas y como blockchain facilitaba las cosas reduciendo las formalidades administrativas. Este atractivo lo llevó a ingeniar la técnica de Proof of History, ideada para mantener una sincronización temporal entre dos computadoras que no confían una de la otra. Con su experiencia pasada sabía que un reloj lo suficientemente confiable brindaría una sincronización en red muy simple, lo que resulta en una rapidez impactante, limitada únicamente por el ancho de banda de los usuarios.

Anatoly notó como a sistemas de blockchain carentes de relojes, como Bitcoin y Ethereum, se les complicaba escalar globalmente más allá de 15 transacciones por segundo. ¿Cómo iban a competir entonces con sistemas de pagos centralizados como Visa, los cuales llegan a 65.000 transacciones por segundo? Sin un reloj, estaba claro que nunca iban a llegar a ser el sistema de pagos mundial que sus usuarios siempre soñaron. Para resolver este gran problema, Anatoly supo que la clave era utilizar sus 40 años de experiencia en sistemas distribuidos y aplicarlos en el mundo de la blockchain. El resultado superó todas las expectativas: ¡una red 10.000 veces más rápida que sus contemporáneas!

La implementación comenzó en una base de código privada con el lenguaje de programación C. Greg Fitzgerald, quien había trabajado previamente con Anatoly en Qualcomm, lo alentó a reimplementar el proyecto en Rust. Greg sostenía que la seguridad que provee este lenguaje mejoraría la productividad del software y su carencia de recolector de basura le permitiría a los programas funcionar tan bien como los escritos en C. Anatoly lo intentó y tan solo dos semanas más tarde, la totalidad del código había sido migrada a Rust. Con el deseo de unir todas las transacciones globales en una sola blockchain escalable, nacía Loom.

El 13 de febrero de 2018, Greg comenzó a implementar el primer prototipo open source del whitepaper de Anatoly. El proyecto fue publicado en Github bajo el nombre Silk. El 28 de ese mismo mes, salió la primera versión, demostrando que 10.000 transacciones firmadas podían ser verificadas y procesadas en apenas medio segundo.

Poco después, otro exmiembro de Qualcomm, Stephen Akridge, demostró que el rendimiento podía ser ampliamente mejorado delegando la verificación de firmas a los procesadores gráficos. Anatoly reclutó a Greg, Stephen y otras tres personas más para cofundar la compañía Loom.

Casi al mismo tiempo, surgió un proyecto basado en Ethereum llamado "Loom Network", lo cuál confundió a las personas porque les costaba distinguir uno del otro. Por lo tanto, el equipo de Loom decidió cambiar el nombre a Solana, haciendo referencia a un pequeño pueblo costero al norte de San Diego llamado Solana Beach donde Anatoly, Greg y Stephen vivieron y surfearon por tres años mientras trabajaban para Qualcomm. El 28 de marzo el equipo creó la organización Solana Github y cambió el nombre del prototipo de Greg a Solana.

En junio de 2018, el equipo escaló la tecnología para poder ser ejecutada en la nube y, el 19 de julio, publicó una red de prueba pública de 50 nodos que soportaba ráfagas de 250.000 transacciones por segundo. Más tarde, en diciembre del mismo año, se publicó otra versión con 150 nodos, alcanzando un promedio de 200.000 transacciones por segundo y con ráfagas de hasta 500.000. El proyecto se extendió para soportar programas en cadena escritos en C que admitieran una ejecución concurrente en un ambiente seguro llamado BPF, una tecnología que permite filtrar paquetes de datos de la red. Además, provee una interfaz con capas de seguridad responsables de asegurar la transmisión y regular el acceso a dichos paquetes de manera confiable.

En el segundo cuatrimestre de 2018 el equipo se encaminó en recaudar fondos para crear la nueva red. Entre abril de 2018 y julio del 2019 ya habían conseguido más de $20.000.000. En paralelo, se continuó con el trabajo en el protocolo, hasta que en marzo del 2020 Solana lanzó la Mainnet Beta y el 16 de ese mismo mes, se creó el primer bloque de la red.

Proof of History (PoH)

¿Qué tal si en vez de confiar en un timestamp se podría comprobar que un mensaje ocurrió antes o después de un evento? Por ejemplo, si sacaras una foto de la portada del New York Times, estarías teniendo una prueba de que la fotografía fue tomada después de que se publicó el diario. Con Proof of History, se puede crear un registro histórico que prueba que un evento sucedió en un momento específico.

One of the most difficult problems in distributed systems is agreement on time. In fact, some argue that Bitcoin’s Proof of Work algorithm’s most essential feature is functioning as a decentralized clock for the system. At Solana, we believe Proof of History provides this solution and we’ve built a blockchain based on it. - Anatoly Yakovenko

Como fue mencionado previamente, la idea es tener un reloj confiable entre computadoras que no confían entre sí, lo cual hace que el consenso sea mucho más rápido.

PoH consiste en crear un registro histórico de eventos con sus marcas de tiempo, con el que cada validador pueda mantener y alinear su propio reloj, lo que les ayuda a recordar la secuencia de eventos de forma independiente. Esto permite que la red tome decisiones sin necesidad de que los validadores se comuniquen entre sí.

PoH se basa en un concepto de criptografía llamado verifiable delay functions, que se puede ver como una cantidad considerable de cálculos secuenciales, que una vez resueltos, producen un resultado único que puede ser verificado eficientemente de forma pública. La implementación específica de Solana utiliza una hash secuencial resistente a pre-imágenes (es extremadamente díficil encontrar un input que produzca determinado output).

El algoritmo de hash se corre continuamente con el output previo como siguiente input y se guarda un registro periódico de un contador con la cantidad de veces que se ejecutó y el resultado. Para una función de hash SHA256, este proceso es imposible de paralelizar sin un ataque de fuerza bruta que utilice 2^128 núcleos. Gracias a esto, se puede asegurar que ha pasado tiempo real entre la generación de cada contador y que el orden registrado es el mismo que sucedió en tiempo real.

Límite temporal superior

La data puede ser insertada en la secuencia anexando su hash al estado generado previamente. Tanto el estado, como la data y el contador son publicados. Anexar el input causa que cambien todos los outputs futuros de manera impredecible. Esto es también imposible de paralelizar y mientras la función de hash sea resistente a pre-imágenes y colisiones, es imposible crear un input que genere un resultado deseado en el futuro o se produzca un historial alternativo con el mismo hash. Además, se puede probar que pasó tiempo entre dos anexos y que la data fue creada antes de ser anexada, así como sabemos que los eventos publicados en el New York Times sucedieron antes de que este fuera escrito.

Límite temporal inferior

Por otro lado, puede haber referencias al pasado como parte de un mensaje firmado con la firma del usuario, con lo cual esta no puede ser modificada sin la clave privada del mismo. Pero como este mensaje también se vuelve a insertar en el flujo de Proof of History, sabemos que existió antes y después de un determinado tiempo.

Proof of Stake (PoS)

Si bien podría parecer que Proof of History es un mecanismo de consenso, esto no es así. Para poder asegurar que la secuencia del generador sea válida, votar, seleccionar al próximo generador y castigar a aquellos validadores que actúen de manera deshonesta se utiliza Proof of Stake.

Cada validador de la red tiene la oportunidad de participar en un consenso emitiendo votos para bloques que ellos creen que deben ser agregados a la blockchain, confirmado asi cualquier transferencia válida contenida en esos bloques. Sin embargo, no todos los votos de los validadores valen lo mismo.

Los votos de consenso de los validadores están condicionados por la apuesta que cada validador decida hacer. Cuanto mayor sea la apuesta, más influencia tendrá ese validador en determinar el resultado del voto de consenso. De la misma forma, validadores con una menor apuesta tendrán menos influencia y aquellos sin apuesta no tendrán influencia alguna.

Los holders de tokens SOL, pueden obtener recompensas y ayudar a asegurar la red apostando tokens a uno o más validadores.

El rendimiento de los tokens apostados se basa en la tasa de inflación actual, la cantidad total de SOL apostadas en la red y el tiempo de actividad y comisión de un validador individual. Cabe destacar que la tasa de inflación de Solana es de un 8% anual, decreciente hasta alcanzar una inflación fija a largo plazo de 1,5% anual.

SOL

El token nativo de Solana es conocido como $SOL y en tan solo dos años logró ubicarse entre las monedas más populares. Actualmente se encuentra entre las primeras 10 en los portales de criptomonedas más frecuentados a nivel mundial y hay más de 350 millones de tokens en circulación de un suministro máximo de 528 millones.

Los tokens $SOL están distribuidos de la siguiente manera: un 16,23% correspondiente a una seed sale inicial, 12,92% dedicado a una founding sale, 12,79% repartidos entre los miembros del mismo equipo y un 10,46% entregado a la Solana Foundation. En cuanto a los tokens restantes, estos fueron lanzados en ventas públicas o privadas o no fueron comercializados aún.

Si analizamos el crecimiento de los tokens, si se hubiese adquirido la moneda en su lanzamiento, hoy en día se tendría un retorno de la inversión de 13.674%. Mientras que en el presente oscila entre $28 y $48 con casi 11 billones de dólares en capitalización de mercado, alcanzó un máximo histórico de $260 el 6 de noviembre de 2021 con 77 billones de dólares en capitalización de mercado.

Elementos de la red y validación

A alto nivel, los principales elementos de Solana son el líder, los validadores y los archivadores. El primero es el orquestador del proceso de validación, en este, las propuestas de transacciones son enviadas al líder, quien va a ordenar los mensajes en forma eficiente para que otros nodos puedan procesarlos, luego él ejecuta las transacciones en el estado actual de la blockchain. Por último, las publica junto con la firma del estado final a los verificadores, quienes van a ejecutar las mismas transacciones en su versión de la blockchain, y publican sus firmas, que van a servir como votos dentro del algoritmo de consenso.

Para minimizar la influencia individual de un nodo, el rol de líder se rota entre validadores. El orden de los mismos puede conocerse de antemano gracias a Proof of History.

No se requiere una cantidad mínima estricta de SOL para ejecutar un validador en Solana, sin embargo, para participar en el consenso se requiere una cuenta de voto que tenga una reserva exenta de renta de 0,02685864 SOL. También, votar requiere enviar una transacción de voto por cada bloque con el que el validador esté de acuerdo, lo que puede costar hasta 1,1 SOL por día.

Por otro lado, los requisitos de hardware son relativamente altos. Para proporcionar una funcionalidad completa y confiable, se deben alcanzar los siguientes requisitos:

• CPU

  • 16 cores / 32 threads, o más

• RAM

  • 256 GB, o más

• Disco

  • PCIe Gen3 x4 NVME SSD, or mejor

  • Cuentas: 500GB, o más grande, con TBW alto (Total Bytes Written)

  • Ledger: 1TB o más. TBW alto sugerido.

  • OS: (Opcionall) 500GB, o más. SATA OK

La innovación del proyecto

La alta velocidad y las tarifas bajas son quizás las razones por las cuales Solana es más conocida. Con la capacidad de alcanzar máximos de 65.000 TPS y un límite teórico de 710.000 TPS en el futuro, Solana busca lograr la paridad con los sistemas centralizados. Esto es posible gracias a las innovaciones que lo diferencian de competidores como Ethereum, Polkadot o Polygon.

Además de Proof of History, hay 7 elementos clave que hacen posible a la red Solana y sus decenas de miles de transacciones por segundo a un bajo costo de gas. Estas son:

• Tower BFT: una versión optimizada para PoH de Practical Byzantine Fault Tolerance. En PBFT, un líder transmite una solicitud a todas las partes pidiéndoles que voten sobre cuál consideran que es el estado actual de la blockchain. En esta variante del algoritmo, las partes no pueden votar por un estado particular de la blockchain a menos que incluya el estado por el que votaron en una ronda de consenso anterior. Esto es posible porque PoH mostrará su historial de votación en futuras votaciones por consenso. Cada nuevo voto reafirma los votos anteriores, proporcionando un consenso exponencial y un incentivo para votar en alineación con la mayoría para ganar las recompensas de validar un bloque.

• Turbine: un mecanismo de propagación de bloques de múltiples capas para transmitir fragmentos de transacciones a todos los nodos con una cantidad mínima de mensajes duplicados. Cada nodo es responsable de compartir los datos que recibe con los otros nodos de su vecindario, así como de propagar los datos a un pequeño conjunto de nodos en otros vecindarios. De esta forma, cada nodo sólo tiene que comunicarse con un pequeño número de nodos

• Gulf Stream: protocolo de reenvío de transacciones sin Mempool. Dado que cada validador conoce el orden de los próximos líderes, los clientes y los validadores reenvían las transacciones al líder esperado con anticipación. Esto permite que los validadores ejecuten transacciones con anterioridad, reduzcan los tiempos de confirmación, cambien de líder más rápido y reduzcan la presión de la memoria sobre los validadores del grupo de transacciones no confirmadas. Esta solución no es posible en redes que tienen un líder no determinista.

• Sealevel: runtime para smart contracts que puede procesar más de diez mil contratos en paralelo, usando la mayor cantidad de núcleos que el validador tenga disponibles. Esto es posible gracias a que las transacciones de Solana describen todos los estados que la transacción va a leer o escribir mientras es ejecutada. Esto permite que las transacciones no se superpongan y puedan ser ejecutadas concurrentemente, inclusive leyendo el mismo estado.

• Pipelining: una Unidad de Procesamiento de Transacciones para la optimización de la validación. Pipelining es un proceso apropiado cuando hay un flujo de datos de entrada que deben procesarse mediante una secuencia de pasos y hay un hardware diferente responsable de cada uno. Para maximizar la eficiencia, se crea pipeline de etapas. Para correr el pipeline uno añade un input siguiente a la primera etapa en el momento que el input anterior paso a la segunda etapa. La velocidad del pipeline está dada por la etapa más lenta. En el caso de Solana, la unidad encargada de mantener al hardware ocupado todo el tiempo se llama Transaction Processing Unit (TPU), y está conformada de la siguiente manera: comienza con Data Fetching a nivel kernel, sigue con Signature Verification a nivel GPU, luego Banking a nivel CPU, y por último Writing a nivel kernel. Para el momento en que la TPU comienza a enviar bloques a los validadores, ya se obtuvo el siguiente conjunto de paquetes, verificó sus firmas y comenzó a acreditar tokens.

• Cloudbreak: el principio que guía a Solana es el de diseñar software que no se meta en el camino del hardware para que pueda ser utilizado el 100% del mismo. Para ello, se utiliza una base de datos de cuentas de escala horizontal que permite lecturas y escrituras concurrentes a nivel red.

• Archivers: almacenamiento distribuido del ledger. La red de replicación de Solana funciona de la siguiente manera: los archivadores deben señalar a la red que tienen X bytes de espacio disponible para almacenar datos. Con cierta frecuencia, la red divide el historial del ledger en partes para alcanzar una cierta tasa de replicación y tolerancia a fallas en función de la cantidad y capacidad de los archivadores. Una vez que se realizan las asignaciones nodo–datos, cada Archivador descarga sus respectivos datos de los validadores de consenso. Los archivadores no son participantes del consenso y tienen requisitos de hardware muy bajos. Además, reciben ~3% de la inflación por sus esfuerzos. Con cierta frecuencia, se les hará un challenge a los Archivadores para que demuestren que están almacenando datos, momento en el cual deben completar una prueba de replicación (PoRep).

Proof of Replication (PoRep)

La idea básica de Proof of Replication es verificar que un nodo archiver no solo ha asignado el espacio para almacenar los datos de la cadena de bloques, sino que también esté almacenando los datos exactos que prometió conservar. Para lograr esto, se encripta un dataset con una clave pública simétrica que utiliza el algoritmo de encriptación CBC y después se hashea el dataset encriptado. El cifrado permite que el nodo de archivo replique los datos a una velocidad rápida y los devuelva a la red, lo que demuestra que el nodo de archivo cumple su promesa. Si tarda demasiado, la red de Solana sabrá que el nodo de archivo está siendo deshonesto, luchando por replicar los datos y cubrir sus huellas. El problema de esto es que es vulnerable a ataques.

Por ejemplo, un nodo de almacenamiento deshonesto puede streamear la encripción y borrarla cuando está siendo hasheada. La solución simple a esto es forzar que el hash se haga en el reverso de la encriptación o en un orden aleatorio. Esto asegura que toda la data esté presente durante la generación de la prueba, y también requiere que el validador tenga la totalidad de la data encriptada para ser verificada.

Solana mejoró esta implementación haciendo un muestreo aleatorio de los bloques encriptados más rápido que la encriptación, y guardando los hashes de esos bloques de muestreo en un ledger con PoH. Por lo tanto, los bloques están en el mismo orden para cada PoRep y puede stremear la data y verificar en un único lote. De esta forma se realizan múltiples verificaciones concurrentemente.

Smart Contracts en Solana

La ejecución de Smart Contracts en Solana se basa en cómo los sistemas operativos cargan y ejecutan código dinámico. El cliente crea un programa en cualquier lenguaje de programación, se compila con LLVM (low-level virtual machine) y se envía al bytecode de Solana.

El archivo resultante es llamado ELF (Executable and Linkable Format). Tiene un bytecode específico como objeto, el cual está diseñado para una verificación rápida y posible de convertirse al set de instrucciones de la máquina local en la cual Solana está siendo ejecutado.

Solana además aprovecha todos los beneficios de la implementación de Sealevel mencionados anteriormente.

Auditorías

A mediados del 2019, el equipo de ingeniería de Solana se comprometió con la empresa de seguridad de software de renombre mundial Kudelski Security para auditar cada detalle de la arquitectura de software de Solana. El equipo de Kudelski estudió cada pormenor de las ocho innovaciones principales de Solana he hizo que el equipo de Solana defiende las decisiones de diseño en cada paso para inspeccionar y diseccionar minuciosamente cada elemento de su infraestructura.

En general, el análisis de Kudelski sobre el proyecto de Solana fue muy positivo y destacó el mecanismo de Proof of History.

Profundizaron en Tower BFT, la innovación en la capa de consenso, y reafirmaron cómo la elección de utilizar Proof of Stake creó una oportunidad para alejarse de los algoritmos BFT tradicionales y simplificar el consenso. El equipo de Kudelski pudo identificar y ofrecer varias formas de particionar la red para desafiar a Tower BFT e identificó brechas en la documentación de Solana y un conjunto de pruebas que no cubrían esas situaciones.

Por otro lado, el paralelismo de transacciones del runtime de Sealevel generó mucha discusión. El equipo de Solana señaló casos en los que paralelizar era seguro, a lo que el equipo de Kudelski ideó ataques para evitar que esos casos ocurrieron en la práctica. Después de algunas idas y vueltas, se llegó a la conclusión de que un atacante bien financiado teóricamente podría ralentizar el acceso a cuentas particulares.

Usuarios

Hay 3 tipos de usuarios en Solana:

• Desarrolladores: en todos sus niveles de experiencia, desde principiantes hasta expertos. Solana brinda herramientas que facilitan el desarrollo de Dapps, DAOs, integrarse con la red u otros exchanges, cursos, guías, documentación, SDKs y frameworks.

• Consumidores finales: quienes utilizan la blockchain para hacer transacciones en SOL.

• Validadores: mencionados previamente. Quienes procesan transacciones, participan en el consenso y, por ello, reciben una comisión. Cada validator ayuda a Solana a ser la blockchain más performante del mundo.

Comunidad

¿Cuáles son los principales canales de comunicación en los que se agrupa la comunidad de Solana? Los anuncios generales sobre la red o eventos relacionados con la Solana Foundation son comúnmente difundidos por sus redes sociales y canales de comunicación primarios como Twitter, Youtube, Telegram y su foro propio.

Además, en dicho foro podemos encontrar threads divididos por categoría: General, Governance. En este último mencionado y en su canal de Discord se pueden encontrar threads y posteos sobre temas más específicos en Solana, principalmente para desarrolladores y aquellos interesados en discutir y difundir aspectos un poco más técnicos acerca de la Red.

En su canal de discord cuenta con más de 160 mil usuarios y en Telegram más de 70 mil. Principalmente la comunidad utiliza el inglés como idioma por defecto y se procura el respeto entre miembros, se prohíbe hacer comentarios sobre ventas de tokens así como también publicaciones ofensivas y cualquier otro tipo de spam. Por lo tanto, se podría describir a los usuarios de Solana como un usuario que está alineado con los lineamientos y reglas que están establecidas, manteniendo una seriedad y cuidado de la comunidad adecuado para que esta vaya en línea con el crecimiento de la blockchain.

Hacks e inconvenientes operativos

Si bien a lo largo de este artículo se buscó destacar las cosas positivas de Solana y pareciera que todo funciona perfectamente, la realidad es que han surgido errores y escándalos en más de una ocasión. Algunos de los más conocidos son:

• El más reciente es un ataque que comenzó la madrugada del 2 de agosto de este año. Se reportaron más de 8000 billeteras comprometidas, con una pérdida que ascendió a millones de dólares de acuerdo a los datos obtenidos mediante Solana FM Explorer (explorador de bloques de la red). Supuestamente, los ataques se derivaron a través de la participación de terceros, ya que los atacantes pudieron aprobar transacciones en nombre de los propietarios de billeteras. Los reportes indican que los usuarios de Phantom, Slope, TrustWallet y otras billeteras calientes fueron víctimas de los ataques. De acuerdo al análisis del equipo de PeckShield, compañía de seguridad de blockchain, se concluyó que el atacante había descubierto o robado las claves privadas pertenecientes a usuarios de billeteras particulares de Solana, por lo que se cree que los ataques pueden ser el resultado de claves privadas mal almacenadas.

• Otro incidente del año actual fue el exploit de Wormhole. Wormhole Portal es una plataforma que ayuda a los usuarios a transferir criptomonedas entre las blockchain de Solana y Ethereum. Este es el hack criptográfico más grande de 2022 hasta el momento. Una revisión rápida de la máquina virtual codificada que envió el atacante mostró que contenía firmas válidas de los guardianes. Esto significa que no obtuvieron las claves privadas o explotaron el puente. Dado que a los atacantes les sobraron $600 millones en tokens en el puente, lo último es más probable. Efectivamente, hubo una transacción correspondiente en Solana donde el atacante conectó el ETH.

• Por último están los apagones. En este último año la red sufrió al menos 7 apagones, haciendo que esto sea el desafío más grande a resolver de acuerdo a Yakovenko. En una entrevista con el cofundador de Real Vision (portal de noticias financieras), Raoul Pal, dijo que las interrupciones de la red han sido la "maldición" de Solana, pero que estas se deben a las transacciones de bajo costo de la red. Además, argumentó que en estos episodios la blockchain en sí misma no fue comprometida, y que el que se considere un apagón a una interrupción de 2 horas se debe a la velocidad de generación de bloques, mientras que un episodio similar en Bitcoin se vería como algo normal.El apagón más largo en la red hasta el momento fue de 17 horas producto de demasiadas transacciones generadas por un gran número de bots que inundaron la red, dejando validadores sin memoria, lo que causó un Denial of Service.

Vulnerabilidades a considerar en desarrollo de dApps

Como bien sabemos, Solana se ha convertido en uno de los principales proyectos que impulsan la descentralización. Por su tecnología, escalabilidad y alto grado de descentralización, muchos desarrolladores e inversores están adoptando Solana como una de las plataformas favoritas a la hora de desarrollar e invertir en nuevas dApps. Es por ello que cabe mencionar cuales son sus puntos débiles y vulnerabilidades a tener en cuenta:

• Implementar los sistemas de autorización de manera correcta: Una de las necesidades más cruciales en Solana es verificar la propiedad de las cuentas, que las transacciones estén firmadas por una cuenta apropiada y que los contratos que se ejecuten sean los indicados para evitar exploits como el WormHole.

• Integer overflow & underflow: Un problema que ha estado desde los inicios del desarrollo de smart contracts. Es considerado uno de los problemas más comunes que pueden llevar a exploits que rompan con la seguridad establecida desde un principio.

• Profundidad de invocaciones de contratos cruzados: Cuando un smart contract tiene que invocar a otro ocurre una invocación cruzada de contratos, mediante la cual los desarrolladores pueden crear complejos procesos encadenados. En Solana, la llamada de contratos cruzados está limitada a sólo cuatro.

• Rust memory safety: Para evitar comportamientos no deseados es necesario que todas las ejecuciones del programa, no accedan a zonas de memorias invalidas. Las principales violaciones a tener en cuenta son usar bloques de memoria que fueron liberados, desreferenciar un null pointer y buffer overflow, entre otros.

Conclusión

Entonces, ¿Por qué elegir Solana como proyecto en el cual confiar en el presente y futuro por sobre otras blockchains?

A pesar de los ataques que sufrió en el último tiempo, sigue siendo uno de los proyectos más prometedores. Este tiene como objetivo principal ser una red descentralizada, donde la cantidad de transacciones por segundo sea la mayor posible, manteniendo un costo promedio de transacción bajo. Se trata de una blockchain principalmente centrada en la escalabilidad pero sin dejar de lado la descentralización ni la seguridad de la red.

Los desafíos de Solana residen en lograr un nivel de desarrollo aún mayor que le permita protegerse ante ataques como los que sufrió recientemente, los cuales son realmente graves para un proyecto blockchain y además tener un modelo económico sostenible a largo plazo. Mantener una alta escalabilidad con transacciones baratas no es tarea fácil. De anteponerse ante estas dificultades, Solana podría explotar y alcanzar la repercusión de otras blockchains de layer 1 como Bitcoin y Ethereum.

Si bien el futuro es incierto, podemos afirmar que Solana seguirá siendo una de las principales blockchains que guíen el desarrollo de tecnologías descentralizadas.