Guía de referencia sobre los fundamentos de Solana

13 minutos de lectura

Resumen

La cadena de bloques Solana es una herramienta potente, capaz de procesar miles de transacciones por segundo con comisiones prácticamente nulas. Si eres nuevo en el mundo de la Web3 o has desarrollado anteriormente en cadenas de bloques basadas en EVM, esta guía te ayudará a comprender los elementos básicos de Solana y a dar los primeros pasos en el desarrollo con Solana. Si ya estás desarrollando en Solana, utiliza esta guía como referencia para seguir ampliando tus conocimientos sobre los fundamentos de Solana.

En esta guía, abordaremos los conceptos básicos de Solana, concretamente: cuentas, programas, instrucciones, transacciones, RPC y suscripciones. ¡Empecemos!

En resumen

Las cuentas son como los archivos de un sistema operativo tradicional: casi todo en Solana es una cuenta: carteras de usuario, programas, registros de datos e incluso programas del sistema.
Los programas (conocidos como «contratos inteligentes» en otras cadenas) son un tipo concreto de cuenta «ejecutable»: carecen de estado y solo ejecutan código en función de los parámetros introducidos por el usuario. En lugar de actualizarse a sí mismos, los programas tienen la autoridad específica para actualizar los datos (o el estado) de otras cuentas de las que son «propietarios».
Los usuarios firman y envían transacciones (conjuntos de instrucciones específicas de cada programa) a través de una RPC a un clúster de Solana para indicar a los programas qué deben hacer.
Solana utiliza un mecanismo de consenso único denominado «Proof of History» (PoH), que se basa en el tiempo y la criptografía para marcar con fecha y hora y ordenar las transacciones que se envían a la red.
Los programas y los firmantes de transacciones autorizan cambios en determinadas cuentas de datos en la cadena de bloques para actualizar el estado de la red.

¿Te has quedado con ganas de más? ¡Sigue leyendo! 👇

¿Qué es Solana?

Solana es una cadena de bloques de código abierto optimizada para la velocidad y el coste, que permite sincronizar globalmente la información y el estado. Solana utiliza una versión única del consenso de «Proof of Stake» denominada «Proof of History», que emplea una función de retardo verificable granular para marcar eficazmente con fecha y hora y ordenar las transacciones enviadas a la red. Según Anatoly Yakovenko en el libro blanco de Solana, «utiliza una función criptográficamente segura diseñada de tal forma que el resultado no puede predecirse a partir de la entrada, y debe ejecutarse por completo para generar dicho resultado» (3). «El líder secuencia los mensajes de los usuarios y los ordena de tal manera que puedan ser procesados de forma eficiente por otros nodos del sistema, maximizando el rendimiento» (2).

*Esto es lo más que vamos a profundizar en el tiempo de ejecución de Solana en este artículo, y ahora vamos a centrarnos en cómo puedes interactuar y desarrollar con Solana. Si quieres profundizar en la arquitectura de Solana y en la teoría que subyace a algunas de sus características de diseño, aquí tienes algunos recursos muy interesantes:

Cuentas

Al igual que los archivos en un sistema operativo, las cuentas se utilizan para hacer funcionar el sistema, almacenar datos o el estado, y ejecutar código.

Hay tres tipos principales de cuentas en Solana:

Las cuentas de datos almacenan información y gestionan el estado de la red. Existen dos tipos de cuentas de datos:
- Cuentas propiedad del sistema (más conocidas como «monederos») [ejemplo: Un monedero de usuario]
- Cuentas derivadas de programas (a menudo denominadas «PDA»): un ejemplo habitual es la cuenta de un usuario para un token específico. Se deriva del programa de tokens SPL de Solana. [ejemplo: La cuenta de tokens de un usuario]
Cuentas de programa que contienen código ejecutable. Hablaremos más sobre ellas en la siguiente sección, pero estas cuentas carecen de estado (lo que significa que los datos pasan por ellas, pero no las actualizan) [ejemplo: Cuenta de programa Candy Machine v2]
Cuentas nativas del sistema (por ejemplo, Programa del sistema, Votación, Staking, Cargador BPF) [ejemplo: Programa del sistema de Solana]

Este artículo se centrará en los puntos n.º 1 y n.º 2. Si quieres saber más sobre el punto n.º 3, «Cuentas nativas del sistema», consulta docs.solana.com.

En resumen, casi todo en Solana es una cuenta. El tipo de cuenta más habitual es el monedero de un usuario, una cuenta de datos que gestiona el estado del saldo de SOL de dicho usuario.

Cada cuenta tiene una dirección única, o clave pública, (muy parecida a la ruta de un archivo) y un conjunto de metadatos asociados:

lamports: El número de lamports que posee esta cuenta (entero sin signo de 64 bits)*
propietario: El programa propietario al que está asignada esta cuenta (dirección de cadena del programa propietario). Los programas propietarios controlan quién tiene acceso de escritura a las cuentas; otros programas pueden leer los datos de otra cuenta, pero si intentaran modificarlos, la transacción fallaría.
ejecutable: Indica si esta cuenta puede procesar instrucciones (booleano). Una cuenta con el valor «true» en «ejecutable» es, en realidad, un programa (o contrato inteligente); hablaremos de ellos en la siguiente sección.
datos: Cualquier dato adicional asociado a la cuenta, almacenado como una matriz de bytes de datos sin procesar
rent_epoch: La próxima época en la que esta cuenta deberá pagar el alquiler (entero sin signo de 64 bits)

* Los lamports son la denominación más pequeña de SOL, el token nativo de Solana (representan una milmillonésima parte de un SOL)

Los metadatos de cualquier cuenta se pueden consultar ejecutando la consulta JSON RPC «getAccountInfo» o buscándola en Solana Explorer. Solana Explorer te permite buscar cualquier cuenta y ver datos básicos sobre el tipo de cuenta de que se trata y a qué programa está asociada. A continuación se muestra un ejemplo de una cuenta de datos propiedad del sistema (la cartera de un usuario):

Veamos un ejemplo de todos los tipos de cuenta:

Aquí hay mucho que ver, pero todo lo que se aprecia en esta figura es una cuenta. En el lado izquierdo, tenemos una cuenta del sistema llamada «System Program» que gestiona todas las carteras de los usuarios. También tenemos una cuenta de programa ejecutable, llamada «Solana SPL Token Program», que los usuarios pueden utilizar para acuñar, quemar y transferir tokens SPL. Por último, tenemos las cuentas derivadas del programa. En este caso, se trata de cuentas de tokens propiedad del programa de tokens y asociadas a la cuenta de un usuario. Fíjate en cómo una cartera de usuario puede tener varias cuentas de tokens.

Recuerda que puedes buscar cualquier dirección de cuenta en Solana Explorer para obtener sus metadatos y saber de qué tipo de cuenta se trata y a qué programa está asociada.

Lamports y «alquiler» de época: Las cuentas y los datos de las cuentas se almacenan en la memoria del validador y, para permanecer allí, es necesario pagar un «alquiler» en lamports (indicado en el campo de metadatos «lamports» de las cuentas). Cuantos más datos haya almacenados en tu cuenta, mayor será el alquiler requerido (nota: el tamaño máximo actual de la cuenta es de 10 MB). Puedes calcular tus requisitos de alquiler utilizando el método JSON RPC getMinimumBalanceForRentExemption. Los validadores se encargan de analizar periódicamente todas las cuentas y recaudar el alquiler; las cuentas se comprueban en la época identificada en el rent_epoch. Si el saldo de una cuenta desciende a cero lamports, la red eliminará la cuenta y los datos se perderán. En el momento de redactar este artículo, todas las cuentas nuevas deben mantener la exención de alquiler, que se concede al mantener en la cuenta el importe equivalente a dos años de alquiler. Fuente: https://docs.solana.com/developing/programming-model/accounts Las épocas son una medida de tiempo en Solana y, actualmente, representan unos 2,5 días.

Programas

Los programas son lo que Solana denomina «contratos inteligentes»: constituyen el motor que gestiona la información y las solicitudes, desde transferencias de tokens y acuñaciones de Candy Machine hasta registros del tipo «hola mundo» y la gobernanza de los depósitos en garantía de DeFi.

Recuerda que los programas de Solana son cuentas sin estado marcadas como «ejecutables»: «Los programas se consideran sin estado, ya que los datos principales almacenados en la cuenta de un programa son el código BPF compilado».
Los programas pueden utilizar la «invocación entre programas» para utilizar u basarse en otros programas de Solana. A esto se le suele denominar «composibilidad».
A diferencia de muchas otras cadenas populares, los programas se pueden actualizar.
La mayoría de los programas son creados por los usuarios, pero Solana Labs ha desarrollado y mantiene una serie de programas en cadena conocidos como la Biblioteca de Programas de Solana.

En la práctica, un usuario debe proporcionar instrucciones específicas a un programa; este procesa dichas instrucciones y, a continuación, puede invocar otros programas y/o actualizar las cuentas derivadas del programa de las que es titular (más información sobre las PDA a continuación).

Cuentas de direcciones derivadas del programa

Una dirección derivada de un programa (PDA) es una cuenta creada y controlada por un programa concreto. Las PDA:

Permitir que los programas controlen direcciones específicas, denominadas «direcciones de programa», de modo que ningún usuario externo pueda generar transacciones válidas con firmas para dichas direcciones.
Permitir que los programas firmen de forma programática las direcciones de programa que aparecen en las instrucciones invocadas a través de invocaciones entre programas. Solana deriva de forma determinista las PDA a partir de las semillas definidas por el programa y el identificador del programa. Se puede encontrar más información sobre las direcciones de programa generadas en docs.solana.

Fuente: _https://docs.solana.com/developing/programming-model/calling-between-programs#program-derived-addresses
_

Esto permite que los programas ofrezcan servicios sin necesidad de confianza, como cuentas de depósito en garantía para gestionar de forma segura operaciones, apuestas o protocolos DeFi. Si nos remitimos al esquema anterior, el Programa de Tokens SPL genera un PDA para un usuario basándose en su monedero y en la dirección de acuñación de ese token concreto. Ese PDA específico almacenaría el estado o los datos correspondientes a la cantidad de ese token que posee el usuario.

Profundicemos en cómo hacemos que los programas funcionen mediante instrucciones y transacciones.

Instrucciones

En esencia, las instrucciones indican a un programa que haga algo. Solana define las instrucciones como «la unidad contigua más pequeña de lógica de ejecución en un programa» (Fuente: docs.solana.com/terminology).

Una instrucción consta de tres partes:

La clave pública del programa que vas a ejecutar,
Una matriz de cuentas que leerá o modificará, y
Una matriz de bytes con cualquier dato adicional necesario para la ejecución del programa (específico del programa)

Este último punto es fundamental:las instrucciones son específicas de cada programa. La transacción fallará si introduces un identificador de programa incorrecto o si no conoces la estructura de datos que debe pasarse al programa.

En JavaScript, una instrucción de transacción tiene un aspecto similar al siguiente:

new TransactionInstruction({
	programId: new PublicKey(PROGRAM_ID),
	keys: [
		{ pubkey: signerKeypair.publicKey, isSigner: true, isWritable: true },
		{ pubkey: pda, isSigner: false, isWritable: true },
		{ pubkey: SystemProgram.programId, isSigner: false, isWritable: false },
	],
	data: Buffer.from(SOME_ENCODED_DATA),
})

Merece la pena mencionar aquí la información de la cuenta necesaria para una instrucción de transacción. Debemos proporcionar la clave pública de la cuenta, independientemente de si dicha cuenta es firmante de la transacción o no, y si la cuenta se incluirá como parte de la transacción (esto contribuye a la capacidad de Solana para ejecutarse rápidamente). En el ejemplo anterior, un usuario firma el monedero y los datos se escriben en un PDA. Suele ser necesario incluir también cuentas de programas del sistema (por ejemplo, para crear una nueva cuenta). Por último, pasamos SOME_ENCODED_DATA. El tipo de datos requerido se define dentro del programa. El programa debe deserializar los datos de entrada para procesarlos correctamente.

Transacciones

Las transacciones son el medio para enviar instrucciones a un programa en la red. Las transacciones pueden agrupar varias instrucciones para procesar múltiples operaciones simultáneamente. Por ejemplo, imagina una situación en la que tienes tres instrucciones diferentes: una para que el monedero A envíe 1 $SOL al monedero B, otra para que el monedero B envíe 33 $USDC al monedero A, y una para añadir una nota a la transacción que diga «El monedero A intercambia 1 $SOL por 33 $USDC con el monedero B el YYYY-MM-DD». Aunque cada una de ellas podría enviarse a la red por separado, ¿qué pasaría si una instrucción fallara, pero las demás se completaran con éxito? Se daría una situación en la que una persona recibiría sus tokens y otra no. Al agrupar las instrucciones en un paquete, podemos garantizar que todas nuestras transacciones se completen con éxito o fallen juntas.

Actualmente, las transacciones están limitadas a 1.232 bytes. Cada transacción debe incluir lo siguiente:

una matriz compuesta por una o más instrucciones de transacción
una matriz con todas las direcciones de las cuentas con las que interactuará el programa
una serie de firmas: un subconjunto de las cuentas que incluimos en nuestra transacción también debe incluir una firma. «Esas firmas indican a los programas en cadena que el titular de la cuenta ha autorizado la transacción. Normalmente, el programa utiliza la autorización para permitir el cargo en la cuenta o la modificación de sus datos» (Fuente: docs.solana.com). Por ejemplo, esto también podría ser necesario para que un creador verifique que un NFT es auténtico.
un hash de bloque reciente: un hash de bloque es, básicamente, una marca de tiempo de PoH. Solana, por defecto, descarta las transacciones «antiguas» para evitar el doble recuento, para que los validadores solo tengan que comprobar las transacciones con respecto a un lote muy reciente y para ofrecer a los usuarios una confirmación rápida de si su transacción se ha procesado (o ha fallado, para que puedan volver a intentarlo). Obtener un hash de bloque reciente antes de enviar una transacción permite a la red conocer la antigüedad de nuestra transacción y cuándo debería caducar (si fuera necesario).

Una vez que la red recibe una transacción, devuelve un identificador de transacción (una cadena codificada en base-58) que puede utilizarse para consultar los detalles de la transacción.

¡Hablemos de cómo enviar tu transacción a la red!

RPC

JSON-RPC es un protocolo de llamada a procedimientos remotos codificado en JSON que permite a los usuarios enviar información a un clúster de Solana y obtener una respuesta de la red. Actualmente, Solana cuenta con tres clústeres de red:

Devnet: un entorno de pruebas para comprobar el funcionamiento de las aplicaciones y los métodos
Testnet: un entorno de desarrollo que se utiliza para someter a pruebas de estrés todas las últimas actualizaciones previstas del sistema
Mainnet Beta: entorno de producción

Los clientes pueden realizar solicitudes de lectura o escritura a cualquiera de los tres clústeres mediante solicitudes JSON-RPC a través de un nodo de Solana. Los nodos actúan, en cierto modo, como «control de tráfico aéreo» para gestionar las solicitudes dirigidas a la red. Los clientes se conectan a los nodos de Solana a través de la clase Solana Web3 Connection:

const HTTP_ENDPOINT = 'https://example.solana-devnet.quiknode.pro/000/'
const SOLANA_CONNECTION = new Conexión(PUNTO_FINAL_HTTP)

En el ejemplo anterior, HTTP_ENDPOINT es una URL HTTP que apunta a un nodo de Solana que, en última instancia, redirigirá tu solicitud a uno de los tres clústeres.

Cada solicitud requiere un punto final de API para conectarse a la red. ¡Ahí es donde entra en juego Quicknode! Puedes utilizar nodos públicos o implementar y gestionar tu propia infraestructura; sin embargo, si quieres tiempos de respuesta ocho veces más rápidos, puedes dejarnos a nosotros el trabajo pesado.

Descubre por qué más del 50 % de los proyectos en Solana eligen Quicknode y regístrate aquí para crear una cuenta. Solo tienes que iniciar sesión y actualizar el valor de HTTP_ENDPOINT en tu aplicación con el que aparece en el panel de control de tu cuenta, ¡y ya estás listo!

Una vez establecida la conexión con un clúster de Solana, puedes realizar numerosos métodos de lectura o escritura en la red. En la documentación de Quicknode encontrarás una lista completa de los métodos RPC y la documentación correspondiente. Aunque cada método tiene su finalidad, algunos de los que son relevantes para lo tratado hasta ahora en esta guía son:

sendTransaction: envía una transacción a la red de Solana
getAccountInfo: recupera los metadatos asociados a cualquier cuenta
getLatestBlockhash: devuelve el hash del último bloque de la red

Las llamadas HTTP nos permiten indicar a la red que realice una acción (por ejemplo, procesar una transacción y sus instrucciones, devolver información sobre el estado actual de una cuenta, etc.), pero ¿qué ocurre si queremos que la red nos avise de los cambios en el estado de una cuenta?

Suscripciones

Las suscripciones son un tipo especial de solicitud RPC en la que se realiza una solicitud WebSocket (WSS) en lugar de utilizar un punto final HTTP. Solana Web3 JSON RPC incluye varios métodos de suscripción (por ejemplo, `accountSubscribe`, que detecta los cambios en los lamports o los datos de una cuenta). A continuación, podemos suscribirnos a estos eventos mediante una función de devolución de llamada, lo que permite que se lleve a cabo una acción determinada cada vez que se produzca un cambio en la red.

El constructor de la clase `Connection` nos permite pasar un objeto `commitmentOrConfig` opcional. Dentro de él, podemos pasar un objeto `wsEndpoint`. Se trata de una opción que te permite proporcionar una URL de punto final al punto final WebSocket JSON-RPC del nodo completo. Si has creado un punto final de Quicknode, deberías ver esta opción en la parte derecha de la página de tu punto final.

const HTTP_ENDPOINT = 'https://example.solana-devnet.quiknode.pro/000/'
const WSS_ENDPOINT = 'wss://example.solana-devnet.quiknode.pro/000/'
const solanaConnection = new Connection(HTTP_ENDPOINT, {
	wsEndpoint: WSS_ENDPOINT,
})

¿Qué ocurre si no se pasa un wsEndpoint? Pues bien, Solana tiene en cuenta esta posibilidad mediante una función, makeWebsocketUrl, que sustituye «https» por «wss» o «http» por «ws» en la URL de tu punto final (fuente). Dado que todos los puntos finales HTTP de Quicknode tienen un punto final WSS correspondiente con el mismo token de autenticación, puedes omitir este parámetro, a menos que desees utilizar un punto final independiente para tus consultas WebSocket.

Para profundizar en la creación de suscripciones WebSocket, consulta nuestra guía: «Cómo crear suscripciones WebSocket en Solana».

Ponlo todo en su sitio

¡Vale! Es mucha información... Probablemente ya hayas empezado a ver cómo se relacionan estos elementos básicos, pero hagamos un breve resumen antes de unir todas las piezas:

Casi todo en Solana es una cuenta: carteras de usuarios, programas, programas del sistema, datos de programas, etc.
Los programas no tienen estado: procesan instrucciones y pueden llamar a otros programas y modificar el estado de las cuentas de datos de las que son propietarios.
Las instrucciones son específicas de cada programa y le indican a este qué debe hacer.
Las transacciones agrupan una o varias instrucciones junto con una firma para autorizar a un programa a ejecutar una o varias tareas.
Los protocolos RPC permiten a los clientes enviar solicitudes de lectura y escritura a uno de los tres clústeres de Solana a través de un nodo, como Quicknode.
Los clientes pueden suscribirse a los cambios en la red mediante solicitudes WebSocket a través del proveedor RPC.

Veamos un ejemplo ilustrativo. Imagina un programa llamado «GM» que contiene un contador que registra cada vez que un usuario envía un mensaje «GM» al programa.

En el ejemplo anterior, un cliente crea una transacción que incluye varias instrucciones de transacción. Las instrucciones son específicas del programa, por lo que deben ajustarse a la estructura prevista del programa GM. El cliente firma y envía la transacción a un clúster de Solana a través de un proveedor de RPC, como Quicknode, utilizando la clase Connection. El proveedor de RPC redirige la solicitud al clúster. La cuenta del programa ejecuta y procesa las instrucciones de entrada recibidas. La cuenta del programa no tiene estado y no cambia, pero autoriza una modificación en los datos del PDA para incrementar el valor del contador GM. Una suscripción creada por el cliente está a la espera de cambios en el PDA; a continuación, la red avisa al cliente de que la cuenta ha sido modificada.

Conclusión

¡Uf! Acabamos de repasar MUCHA información. No dudes en leer esto varias veces para asegurarte de que entiendes estos conceptos.

Ahora que ya tienes una idea más clara de cómo funciona Solana, ¡es hora de ponerse manos a la obra! Echa un vistazo a algunas de nuestras guías de desarrollo para Solana y empieza a trabajar. Aquí tienes algunos ejemplos:

¿Tienes alguna duda sobre alguno de estos conceptos o simplemente te apetece charlar sobre el tema? ¡Escríbenos en Discord o Twitter y cuéntanos en qué estás trabajando!

¡Nos encanta recibir comentarios!

Si tienes algún comentario o pregunta sobre esta guía, háznoslo saber. ¡Nos encantaría saber tu opinión!

Guía de referencia sobre los fundamentos de Solana

Resumen​

En resumen​

¿Qué es Solana?​

Cuentas​

Programas​

Cuentas de direcciones derivadas del programa​

Instrucciones​

Transacciones​

RPC​

Suscripciones​

Ponlo todo en su sitio​

Conclusión​

¡Nos encanta recibir comentarios!​

Referencias y fuentes​