El verificador no confía en el template. Lo vuelve a derivar.
Veldra v2.0.0 entrega el Invariant Shield: 22 comprobaciones canónicas de re-derivación (Fase 1) más la referencia real del mempool (Fase 2). Montado sobre la pasarela de política v1 de 59 códigos y la base de configuración TOML de 61 claves ya existentes.
v2.0.0 integrado, en origin, CI en verde. La re-derivación de consenso independiente se ejecuta. La referencia real del mempool se ejecuta. La afirmación de lanzamiento de que el sistema detecta en producción la manipulación consistente por parte del template-manager en la capa del verificador exige que antes se complete el ciclo de observación en producción. Hasta entonces, la comunicación pública distingue entre «integrado y probado en CI» y «validado contra templates reales de mainnet durante una ventana de observación de varias semanas».
Reason codes
Cada desacuerdo recibe un nombre. La superficie de reason codes es el contrato: lo que el verificador emite cuando rechaza un template, en el flujo de métricas y en la línea de log, con una fuente canónica sobre la que puedes hacer grep.
Defectos que producen un bloque inmediatamente inválido. Re-derivados a partir de los bytes en bruto del bloque.
CoinbaseValueCoinbaseHeightMerkleRootWitnessCommitmentMismatchTxCountDefectos que producen bloques con probabilidad de quedar huérfanos o inválidos aguas abajo.
TemplateWeightSigopsCoinbaseSigopsWitnessCommitmentMissingCoinbaseBip34Se conectan tras completarse limpiamente el ciclo de observación en producción de v2.0.0.
CoinbaseScriptLengthCoinbaseOutputCountWeightExceedsMaxSigopsExceedMaxNonCoinbaseNullPrevoutHeaderVersionLowDuplicateTxCoteja los txids no-coinbase del template con una vista independiente del mempool de bitcoind. Rechaza cuando la proporción de tx desconocidas supera tolerance_pct.
Fuente canónica: rg-consensus::ConsensusViolation::ALL_CODES
Configuración
61 claves TOML de base más 8 nuevas bajo [policy.mempool] en v2.0.0. Las 8 son opcionales y con valores por defecto — las configuraciones antiguas se siguen cargando sin cambios.
Las 8 claves nuevas son opcionales y con valores por defecto, de modo que las configuraciones antiguas se siguen cargando sin cambios.
Telemetría
Cuatro nuevos flujos de Prometheus en v2.0.0 para la Fase 2. Las exportaciones existentes no cambian.
Las exportaciones existentes no cambian. Observabilidad Prometheus / Grafana / CSV / NDJSON según el sitio actual.
Facade rg-consensus
La reducida API pública del motor de consenso. Cinco puntos de entrada de re-derivación y cinco métodos de acceso sobre rust-bitcoin — toda la superficie de Class D / Class S.
rg-consensus es una fachada separable que envuelve rust-bitcoin tras un límite estrecho.
re_derive_coinbase_value()re_derive_template_weight()re_derive_merkle_root()re_derive_witness_commitment()count_sigops()template_txidsparse_blocktotal_sigopscoinbase_sigopsbip34_heightMáquina de estados fail-stale de la Fase 2
Qué ocurre cuando falla el sondeo RPC al bitcoind del operador. Tres estados, transiciones nombradas, ningún template descartado.
Máquina de estados de la vista del mempool: el verificador pasa por tres estados según la antigüedad de la vista y después se degrada limpiamente, sin descartar templates.
max_stale_secs = 60 · sample_unknown_cap = 10Modelo de amenazas · límites · salvedades
Lo que está dentro del alcance, lo que queda estructuralmente fuera del alcance y lo que la ventana de tolerancia del 4% del mempool puede y no puede hacer.
ReserveGrid OS v2.0.0 con la Fase 1 más la Fase 2 detecta T1, T2 y T3. T4 y T5 quedan explícitamente fuera de alcance.
cualquier template cuyos campos declarados queden dentro de los umbrales del operador, aunque los bytes subyacentes estén fabricados
manipulación cuyos valores declarados y bytes crudos son internamente consistentes por construcción
manipulación que se mantiene dentro de la ventana de tolerancia configurada, o mientras el propio bitcoind está comprometido
- 01La ventana de tolerancia del 4% en la Fase 2 absorbe la divergencia benigna del mempool (latencia legítima de propagación entre el bitcoind del operador y la red).
- 02Ajustarla a la baja hacia 2.0 estrecha la ventana, pero no puede llegar a cero sin producir falsos positivos en templates reales.
- 03La Fase 2 confía en el bitcoind del operador por definición. Si ese mismo bitcoind está comprometido, Class M queda ciega.
Modos de adopción
Tres formas de despliegue — Shadow (solo aviso · gratis), Observe (licencia · sin aplicación de política), Inline (licencia · fail-closed). El requisito de bitcoind se nombra de entrada.
Ejecuta la pasarela detrás de tu ruta actual con veredicto = solo aviso. Cero cambios en el flujo de shares.
Stack de Docker autoalojado más clave de licencia. Requiere un bitcoind de mainnet (o usa rg-feed-server).
Aplicación de política fail-closed. Pasarela dentro de la ruta de los shares.
Tanto observe como inline requieren un bitcoind del lado del operador: sincronizado, con recursos suficientes, con RPC accesible y con las credenciales rpc_* cableadas mediante variable de entorno o [policy.mempool].
Los operadores que quieran el modo observe o inline obtienen una clave de licencia desde su cuenta de veldra.org (Iniciar sesión).
Tanto observe como inline requieren un bitcoind del lado del operador: sincronizado, con recursos suficientes, con RPC accesible y con las credenciales rpc_* cableadas mediante variable de entorno o [policy.mempool].
Veldra vs SRI
La única comparación de producto que se nombra. Stratum Reference Implementation es la prueba canónica de que el protocolo SV2 es implementable. Veldra está hecho para operadores de pool que necesitan verificación, no solo conectividad.
La Stratum Reference Implementation (SRI) es la prueba canónica de que el protocolo SV2 es implementable. Veldra está hecho para operadores de pool que necesitan verificación, no solo conectividad.
DATUM y otros protocolos de template del lado del minero son contexto del ecosistema. La capa de verificación de Veldra es independiente del protocolo del lado del minero que ejecute el pool.
Roadmap
v2.0.0 → Fase 1.5 → v3.x. Sin fechas de calendario — los hitos están condicionados al ciclo de observación en producción, no al reloj.
Invariant Shield Fase 1 más la referencia real del mempool de la Fase 2.
Siete invariantes Tier 3 de doble seguridad se conectan tras completarse limpiamente el ciclo de observación en producción de v2.0.0.
Detección de selfish mining. El modo per-tx detail y las cuatro métricas de la Fase 2 entregadas en v2.0.0 establecen la forma de los datos para la detección, sobre series temporales, de templates cuyos conjuntos de tx desconocidas se agrupan en el tiempo con huellas estructuralmente coherentes. El diseño de v3.x parte de la superficie de la Fase 2 ya entregada — no requiere cambios de protocolo ni tiene más coste de migración que habilitar per-tx detail en la política del operador.