Niveles de Confirmación en Clientes
procesado / confirmado / finalizado y sus compensaciones. Esta guía está dirigida a validadores Agave 4.1.1, clientes Solana CLI 3.0.10, Anchor 0.32.1 y @solana/kit 7.0.0.
Receta
Tarjeta de receta de referencia rápida.
solana config set --url devnet
solana balanceimport { createSolanaRpc } from "@solana/kit";
const rpc = createSolanaRpc("https://api.devnet.solana.com");Cuándo usar esto:
- Implementar o depurar niveles de confirmación en clientes en rutas de producción
- Enseñar el concepto a ingenieros nuevos en Solana
- Auditar si tu stack coincide con el comportamiento de la era Agave 4.1
Ejemplo de Trabajo
import { createSolanaRpc, address } from "@solana/kit";
const rpc = createSolanaRpc("https://api.devnet.solana.com");
const slot = await rpc.getSlot().send();
const sig = "PEGA_LA_FIRMA_DESPUÉS_DE_TU_TX";
const tx = await rpc
.getTransaction(sig, { encoding: "json", maxSupportedTransactionVersion: 0 })
.send();
console.log({ slot, err: tx?.meta?.err, cu: tx?.meta?.computeUnitsConsumed });use anchor_lang::prelude::*;
#[program]
pub mod demo {
use super::*;
pub fn log_slot(_ctx: Context<LogSlot>) -> Result<()> {
let clock = Clock::get()?;
msg!("slot: {}", clock.slot);
Ok(())
}
}
#[derive(Accounts)]
pub struct LogSlot {}Lo que esto demuestra:
- Patrones de acceso RPC con @solana/kit 7.0.0
- Lectura de metadatos de ejecución (errores, CU) de transacciones confirmadas
- Acceso a sysvars en la cadena en programas Anchor 0.32.1
Análisis Profundo
Cómo Funciona
- procesado / confirmado / finalizado y sus compensaciones.
- El modelo de cuentas de Solana requiere listas explícitas de cuentas por instrucción
- Sealevel ejecuta transacciones no conflictivas en paralelo
Notas de Agave 4.1.1
- La semántica de confirmación sigue la votación TowerBFT con ordenamiento PoH
- Alpenglow (Votor + Rotor) se está implementando para una finalidad más rápida - ver sección de Consenso
- Desarrollo local: Surfpool 0.12.0 y LiteSVM 0.6.x
Notas de Rust
// Usa matemáticas verificadas y restricciones explícitas en los programas
require!(amount > 0, MyError::InvalidAmount);Errores Comunes
- Snippets heredados de web3.js v1 - La API difiere de Kit. Solución: usa @solana/kit 7.0.0.
- Cluster incorrecto - Desajuste entre devnet y mainnet. Solución: alinea CLI, RPC, wallet y explorador.
- Montos de SOL en punto flotante - pérdida de precisión. Solución: lamports bigint de extremo a extremo.
- Blockhash expirado - transacciones descartadas. Solución: vuelve a obtener el blockhash y vuelve a firmar.
- CU insuficiente - OOM o presupuesto excedido. Solución: optimiza el programa + establece el Presupuesto de Cómputo.
- Faltan comprobaciones de propietario - exploits de cuentas escribibles. Solución: restricciones de Anchor en cada cuenta mut.
Alternativas
| Alternativa | Usar Cuando | No Usar Cuando |
|---|---|---|
| @solana/kit 7.0.0 | Nuevos clientes TypeScript | Mantener código heredado temporalmente |
| Solana CLI 3.0.10 | Operaciones y sondeos rápidos | Firma de transacciones en producción a escala |
| Surfpool 0.12.0 | Pruebas de integración de Anchor | Despliegue en producción |
| LiteSVM 0.6.x | Pruebas unitarias rápidas | Validación del comportamiento completo de la red |
Preguntas Frecuentes
¿Cómo se aplica esto en Agave 4.1.1?
Agave 4.1.1 respeta la misma semántica de compromiso; Alpenglow puede acortar el tiempo hasta finalized —vuelve a medir después de las actualizaciones.
¿Qué versión de Solana CLI debo usar?
Usa Solana CLI 3.0.10, que se empareja con Agave 4.1.1. Instala con agave-install init 4.1.1 (o el archivo de fijación de tu equipo), luego verifica con solana --version y agave-install --version.
¿Debo usar @solana/kit o web3.js?
Usa @solana/kit 7.0.0 para nuevos métodos RPC tipados en TypeScript, una superficie de API más pequeña y los ejemplos en esta página ya usan Kit. Conserva web3.js solo para bases de código heredadas; migra las llamadas RPC y la construcción de transacciones incrementalmente.
¿Qué nivel de compromiso se recomienda?
Usa confirmed para una experiencia de usuario que tolere bifurcaciones raras; usa finalized antes de pagos irreversibles o mensajes de puente. Vuelve a medir los tiempos de espera durante la implementación de Alpenglow.
¿Cómo depuro fallos relacionados?
Una tx visible en confirmed pero que falta en finalized indica una bifurcación —vuelve a obtener el estado antes de mostrar el éxito para retiros.
¿Funciona esto en devnet?
Sí — apunta CLI y RPC a https://api.devnet.solana.com. El comportamiento coincide con mainnet; solo los datos de cuenta y la economía difieren.
¿Cómo afectan las unidades de cómputo a esto?
La elección del compromiso no cambia las CU; cambia cuán pronto tratas la ejecución como asentada.
¿Cuál es el patrón de Anchor 0.32.1?
Los patrones de Anchor 0.32.1 se aplican cuando escribes programas en la cadena: cuentas tipadas, guardas require! y generación de IDL — usa avm use 0.32.1 y anchor-lang = "0.32.1" en Cargo.toml.
¿Cómo pruebo con Surfpool 0.12.0?
Surfpool ayuda a probar scripts de sondeo de clientes contra estado bifurcado; no simula los internos de votación del validador.
¿Puede LiteSVM 0.6.x cubrir esto?
LiteSVM devuelve éxito/fallo inmediato — mapea eso a finalized solo para la lógica unitaria, no para el tiempo de red.
¿Qué cambió en la era Agave?
El cliente validador cambió de nombre a Agave (4.1.1), CLI 3.0.10 se alinea con él y el trabajo de Alpenglow está cambiando la finalidad — fija las versiones y lee las notas de la versión en cada actualización.
¿Dónde encuentro métodos RPC relacionados?
Pasa commitment a getSignatureStatuses, getBalance, getAccountInfo y sendTransaction para el sondeo de confirmación.
Relacionado
- Explora otras páginas en la sección
consensus-alpenglowpara temas complementarios - Fundamentos de Solana - orientación de cuentas y transacciones
Versiones del Stack: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 y LiteSVM 0.6.x.