Introducción a Alpenglow
El diseño Votor + Rotor y los objetivos de finalidad de ~100–150 ms. Esta guía está dirigida a validadores Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1 y clientes @solana/kit 7.0.0.
Receta
Tarjeta 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 la introducción de alpenglow 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 = "PASTE_SIGNATURE_AFTER_YOUR_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
- El diseño Votor + Rotor y los objetivos de finalidad de ~100–150 ms.
- 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 ordenación 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);Trampas Comunes
- Fragmentos de web3.js v1 heredados - La API difiere de Kit. Solución: usa @solana/kit 7.0.0.
- Cluster incorrecto - Desajuste devnet vs mainnet. Solución: alinea CLI, RPC, wallet, explorador.
- Cantidades de SOL en punto flotante - Pérdida de precisión. Solución: lamports bigint de extremo a extremo.
- Blockhash caducado - 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 del 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 envía TowerBFT hoy mientras se implementan los componentes de Alpenglow; monitoriza SIMD y las notas de la versión para la activación de funciones en tu clúster.
¿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 TypeScript: 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. Vuelve a evaluar los tiempos de espera durante la implementación de Alpenglow.
¿Cómo depuro fallos relacionados?
Durante la migración, compara las latencias confirmed vs finalized en tu cliente. No asumas que las constantes de tiempo de espera antiguas siguen siendo válidas.
¿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 no cambian las CU del programa; cambian cuánto tiempo debes esperar en cada nivel de compromiso.
¿Cuál es el patrón de Anchor 0.32.1?
Los patrones de Anchor 0.32.1 se aplican al escribir 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 no simula la votación de Alpenglow; prueba las suposiciones de finalidad contra el RPC de devnet/mainnet en su lugar.
¿Qué cambió en la era Agave?
El cliente validador pasó a llamarse Agave (4.1.1), la 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 con searchTransactionHistory y getBlockHeight específicos del compromiso ayudan a medir los nuevos tiempos de finalidad.
Relacionado
- Explora otras páginas de la sección
consensus-alpenglowpara temas complementarios - Fundamentos de Solana - orientación de cuentas y transacciones
Versiones del stack: 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.