TowerBFT + PoH
El consenso BFT basado en votos en la era Agave. Esta guía está dirigida a validadores de Agave 4.1.1, clientes de Solana CLI 3.0.10, Anchor 0.32.1 y @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 towerbft + poh 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 Funcional
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 consenso BFT basado en votos en la era Agave.
- 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
- Las semánticas de confirmación siguen 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
// Usar matemáticas verificadas y restricciones explícitas en los programas
require!(amount > 0, MyError::InvalidAmount);Trampas Comunes
- Snippets de web3.js v1 heredados - La API difiere de Kit. Solución: usar @solana/kit 7.0.0.
- Cluster incorrecto - Desajuste devnet vs mainnet. Solución: alinear CLI, RPC, wallet, explorador.
- Montos de SOL flotantes - pérdida de precisión. Solución: lamports bigint de extremo a extremo.
- Blockhash caducado - transacciones descartadas. Solución: volver a obtener el blockhash y volver a firmar.
- CU insuficiente - OOM o presupuesto excedido. Solución: optimizar programa + establecer 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?
Los validadores de Agave 4.1.1 votan en sincronía con los ticks de PoH; las confirmaciones se profundizan a medida que se acumulan los votos en una bifurcació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.
¿Debería 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 en esta página ya usan Kit. Mantén 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 el despliegue de Alpenglow.
¿Cómo depuro fallos relacionados?
Los reorganizaciones son raras pero posibles antes de finalized. Si una transacción desaparece, probablemente estaba en una bifurcación descartada; espera a finalized para acciones irreversibles.
¿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 cuenta y la economía difieren.
¿Cómo afectan las unidades de cómputo a esto?
TowerBFT es de capa de consenso — sin impacto directo en CU. El impacto en el cliente es qué nivel de compromiso consultas.
¿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 no ejecuta votos TowerBFT; las transacciones tienen éxito o fallan inmediatamente en las pruebas.
¿Qué cambió en la era Agave?
El cliente validador se renombró a 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?
Consulta getSignatureStatuses en confirmed y finalized; usa isBlockhashValid al reintentar después de bifurcaciones.
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.