Solana (SOL): Cómo funcionan las transacciones y los validadores

El estado vive en las cuentas

Cada pieza de estado persistente de Solana se mantiene en una cuenta identificada por una dirección de 32 bytes. Una cuenta registra lamports, datos, un programa propietario y campos relacionados con la ejecución. El propietario es el programa autorizado para cambiar los datos de esa cuenta; no es necesariamente la persona que controla una clave de billetera.

Los programas de Solana son cuentas ejecutables que contienen código de bytes sBPF. Un programa generalmente se trata como sin estado porque el estado de la aplicación mutable vive en cuentas separadas suministradas a cada instrucción. Esto permite que el tiempo de ejecución vea qué cuentas leerá o escribirá una transacción antes de la ejecución y programe el trabajo que no compite por el mismo estado escribible.

Billeteras, cuentas de token y PDAs

Una dirección de billetera puede poseer SOL y autorizar transacciones, pero un saldo de token SPL normalmente reside en una cuenta de token asociada con un mint y un propietario. Una dirección derivada de programa se deriva determinísticamente de un programa ID y semillas; el programa puede autorizar para ella a través de reglas de tiempo de ejecución, aunque no exista una clave privada para la dirección.

Antes de enviar un token, confirme el mint, la cuenta de token de destino y el programa invocado. Un ticker familiar o una etiqueta de billetera no es prueba de que un mint sea canónico. Cerrar, crear o reasignar cuentas también puede mover lamports, por lo que el resumen de la transacción debe revisarse más allá del monto del token principal.

Mensaje, firmas e instrucciones

El mensaje enumera direcciones de cuentas, un blockhash reciente e instrucciones compiladas. Cada instrucción nombra un programa e identifica las cuentas que puede usar. Los firmantes requeridos autorizan el mensaje, y las transacciones versionadas pueden usar tablas de búsqueda de direcciones para referenciar más cuentas sin colocar cada dirección directamente en el paquete.

Actualidad y confirmación

Un blockhash reciente evita que una transacción ordinaria permanezca válida indefinidamente. Si caduca antes de procesarse, la transacción debe reconstruirse y firmarse nuevamente; reenviar la firma antigua no crea una transacción nueva. Existen flujos de trabajo de nonce duradero para firmas especializadas fuera de línea o retrasadas y requieren un manejo separado.

Los clientes RPC exponen niveles de compromiso procesado, confirmado y finalizado. Una interfaz rápida puede mostrar resultados procesados antes de que se alcance un acuerdo más fuerte del clúster. Los depósitos, puentes y acciones de aplicaciones dependientes deben esperar el nivel requerido por ese servicio y deben verificar la firma a través de un RPC o explorador actual.

Componentes base y de prioridad

Cada transacción paga una tarifa base en SOL por las firmas requeridas. El protocolo expresa SOL en lamports, y el monto base depende del número de firmas, no del valor de un pago o intercambio de tokens. Una transacción fallida puede consumir la tarifa base porque se intentó la verificación de firma y la ejecución.

Una tarifa de priorización opcional se basa en el límite de unidades de cómputo solicitado y el precio de unidad de cómputo elegido. El límite es un presupuesto, no una predicción del uso real, por lo que establecerlo mucho más alto de lo necesario puede pagar de más el componente de prioridad. Las estimaciones de la billetera deben usar condiciones recientes y simulación de transacciones en lugar de copiar una tarifa fija de otra aplicación.

Comprobaciones operativas

Mantenga suficiente SOL para la tarifa incluso cuando el activo transferido sea un token SPL. Revise cualquier instrucción de presupuesto de cómputo, porque pueden cambiar el límite solicitado y el precio de prioridad. También distinga las tarifas de transacción de la financiación de cuentas, los saldos relacionados con el alquiler, el impacto en el precio del intercambio y los cargos de la aplicación; son costos separados incluso si una billetera los resume juntos.