Prácticas recomendadas de consenso
Elegir el compromiso adecuado para tu aplicación.
Cómo usar esta lista
- Revísala antes del lanzamiento en mainnet y después de incidentes.
- Marca los elementos por cada ciclo de lanzamiento.
A - Fundamentos
- Fija la cadena de herramientas de Agave 4.1.1. CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 alineados en CI.
- Usa @solana/kit 7.0.0 para nuevos clientes. Evita web3.js v1 para trabajo nuevo.
- Empareja el clúster RPC, de billetera y explorador. Previene errores falsos de "cuenta no encontrada".
B - Fiabilidad
- Confirma en
confirmedofinalized. No tratesprocessedcomo final. - Actualiza el blockhash al reintentar. Las transacciones expiradas se descartan silenciosamente.
- Simula y lee los registros. Decodifica errores del programa antes de volver a enviar.
C - Economía y Seguridad
- Presupuesta tarifas de prioridad bajo congestión. Los mercados de tarifas locales necesitan instrucciones de Compute Budget.
- Valida firmantes y propietarios de cuentas. Las restricciones faltantes son vulnerabilidades críticas.
- Cierra cuentas no utilizadas para recuperar el alquiler. Devuelve lamports a los usuarios cuando finaliza su ciclo de vida.
Preguntas frecuentes
¿Cómo se aplica esto en Agave 4.1.1?
Agave 4.1.1 está en transición hacia Alpenglow; trata los tiempos de confirmación como dependientes de la versión.
¿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 TypeScript nuevo: métodos RPC tipados, superficie de API más pequeña y los ejemplos de 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. Reevalúa los tiempos de espera durante la implementación de Alpenglow.
¿Cómo depuro fallos relacionados?
Cuando las transacciones desaparecen, verifica el nivel de compromiso: confirmed no es finalized. Registra las transiciones de estado durante la migración.
¿Funciona esto en devnet?
Sí, apunta la CLI y el RPC a https://api.devnet.solana.com. El comportamiento coincide con mainnet; solo los datos de la cuenta y la economía difieren.
¿Cómo afectan las unidades de cómputo a esto?
Los cambios de consenso rara vez afectan a las CU; concéntrate en la experiencia de usuario de confirmación y las configuraciones de tiempo de espera.
¿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 la lógica interna de votación del validador.
¿Puede LiteSVM 0.6.x cubrir esto?
LiteSVM para la lógica del programa; RPC de devnet para el comportamiento de finalidad durante la implementación de Alpenglow.
¿Qué cambió en la era Agave?
El cliente validador cambió de nombre a Agave (4.1.1), Solana 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?
getSignatureStatuses en múltiples compromisos; getVoteAccounts para la salud del validador.
Relacionado
- Consulta las páginas hermanas de esta sección para obtener información detallada sobre temas específicos.
Versiones de la pila: Esta página se escribió 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.