¿Cómo funcionan las transacciones en Solana?

Dado que cada tarifa se paga al ejecutar una transacción, conviene entender cómo funcionan estas. Una transacción consta de tres partes:

una o más instrucciones
un array de cuentas de las que leer o escribir
una o más firmas
un blockhash reciente o nonce

Una instrucción es la unidad mínima de lógica de ejecución en Solana. Las instrucciones son llamadas para actualizar el estado global de Solana. Las instrucciones invocan programas que realizan llamadas al runtime de Solana para actualizar el estado (por ejemplo, llamar al token program para transferir tokens desde tu cuenta a otra cuenta). Puedes pensar en una instrucción como una llamada a una función en un smart contract de Ethereum.

Una diferencia significativa entre Ethereum y Solana es el número de llamadas a funciones en una sola transacción, dado el número de instrucciones. Tener múltiples instrucciones por transacción beneficia a los desarrolladores, ya que no necesitan crear smart contracts personalizados para encadenar funciones en una sola transacción. Cada instrucción puede ser una llamada a función independiente, ejecutada en orden dentro de la transacción. Las transacciones son atómicas, lo que significa que si alguna de estas instrucciones falla, toda la transacción fallará y solo pagarás la tarifa de transacción. Esto es similar a que una transacción falle por no haber configurado correctamente el slippage en Ethereum.

Otra diferencia clave a tener en cuenta es el uso de un blockhash reciente en lugar de un nonce incremental para las transacciones. Cuando una wallet quiere realizar una transacción, se obtiene un blockhash reciente del clúster para crear una transacción válida. Este blockhash reciente solo hace válida la transacción durante 150 bloques después de haber sido recuperado. Esto evita que firmas de transacciones de larga duración se ejecuten en una fecha mucho posterior.

Cross-Program Invocation (CPI)

Un Cross-Program Invocation (CPI) ocurre cuando un programa de Solana llama a una instrucción de otro programa mientras se ejecuta la transacción original. El CPI es la principal forma en que los programas de Solana se componen entre sí, aunque el modelo de cuentas cambia la manera en que se diseña el grafo de llamadas: la transacción debe incluir todas las cuentas que la cadena completa de CPI leerá o escribirá antes de que comience la ejecución.

El programa llamado hereda únicamente los privilegios de firmante y escritura que recibió el llamador, y consume del mismo presupuesto de cómputo de la transacción. Usa invoke cuando todos los firmantes requeridos hayan firmado la transacción original. Usa invoke_signed cuando el programa llamador necesite firmar por uno de sus PDAs usando signer seeds.

Niveles de confirmación

Las lecturas RPC, las suscripciones y la lógica de confirmación de transacciones pueden elegir un nivel de commitment. Esta es la versión de Solana para decidir cuántas confirmaciones de bloque de Ethereum esperar, salvo que los niveles son explícitos:

processed: la vista procesada más reciente del nodo. Úsalo solo para UI optimistas o flujos que puedan tolerar un rollback.
confirmed: un bloque votado por una supermayoría del stake. Úsalo como valor predeterminado para la mayoría de las confirmaciones en producción y el estado de transacciones visible para el usuario.
finalized: el estado de confirmación más sólido. Úsalo antes de realizar acciones irreversibles fuera de la cadena, como pagos en moneda fiduciaria, envío de mercancía o registros de liquidación final.

Si un método RPC acepta commitment y no lo especificas, el valor predeterminado suele ser finalized. Los clientes en producción deben establecer el commitment de forma explícita para que la latencia de la UI, el comportamiento del indexador y la política de liquidación sean deliberados.

Offline Transactions