▸ PREGUNTAS · EVALUACIÓN DEL OPERADOR

Seis preguntas que hacen los operadores. En orden.

Las demás secciones de este sitio se organizan por arquitectura de la información — la arquitectura, el historial de fallos, las capas de confianza. Esta página se organiza por lo que los operadores escépticos quieren saber de verdad — respondido de forma escueta y en el orden en que se plantean las preguntas.

Q1
¿Qué hace exactamente?
Q2
¿Qué me dice cuando algo va mal?
Q3
¿Cómo se configura?
Q4
¿Cuánto cuesta? ¿Qué licencia tiene?
Q5
¿Por qué no usar una pasarela de pool existente?
Q6
¿Qué está INTEGRADO hoy y qué sigue en planificación?
Q1

¿Qué hace exactamente?

L1 (pasarela) verifica la superficie SV2; L2 (Shield) vuelve a derivar cada campo declarado del template y lo coteja con un mempool independiente. Un solo binario.

L1 · GATEWAY
Stratum V2, endurecido.
Ciclo de vida de la conexión, autenticación, envío de shares, RPC de bitcoind. Reason codes de base de la pasarela. La superficie ya transitada.
L2 · INVARIANT SHIELD
Dos fases · 22 códigos de invariante.
Fase 1 — Class S (estructural) + Class D (re-derivación declarado frente a derivado): Tier 1 (5 críticos) + Tier 2 (5 altos) entregados, Tier 3 (7) en cola para la Fase 1.5. Fase 2 — Class M coteja contra un mempool de bitcoind independiente. Ambas fases salen en v2.0.WIRED
▸ RESUMEN EN UNA LÍNEA
Veldra vuelve a derivar cada campo declarado de cada template, de forma independiente con rust-bitcoin. Y luego nombra cada discrepancia.
Q2

¿Qué me dice cuando algo va mal?

Reason codes con nombre en el flujo de métricas y en la línea de log — códigos de la pasarela más 22 v2_invariant_*. Localiza uno, cópialo, búscalo en la documentación. Sin descartes silenciosos.

59
gateway reason codes · base v1
22
códigos v2_invariant_* en total · canónicos desde rg-consensus::ConsensusViolation::ALL_CODES
T1 · ×5Tier 1 · críticoFase 1 (v2.0.0)

Defectos que producen un bloque inmediatamente inválido. Re-derivados a partir de los bytes en bruto del bloque.

CoinbaseValueCoinbaseHeightMerkleRootWitnessCommitmentMismatchTxCount
T2 · ×5Tier 2 · altoFase 1 (v2.0.0)

Defectos que producen bloques con probabilidad de quedar huérfanos o inválidos aguas abajo.

TemplateWeightSigopsCoinbaseSigopsWitnessCommitmentMissingCoinbaseBip34
T3 · ×7Tier 3 · redundancia deliberadaFase 1.5 (tras el ciclo de observación)

Se conectan tras completarse limpiamente el ciclo de observación en producción de v2.0.0.

CoinbaseScriptLengthCoinbaseOutputCountWeightExceedsMaxSigopsExceedMaxNonCoinbaseNullPrevoutHeaderVersionLowDuplicateTx
CLASS M · FASE 2 (referencia real del mempool)

Coteja 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

Q3

¿Cómo se configura?

61 claves TOML de base más 8 nuevas bajo [policy.mempool]. Recargables en caliente según los niveles de recarga.

Base v1 · 61 claves en [gateway] · [timing] · [share] · [auth]
[policy.mempool]NUEVO EN v2.0.0 · 8 CLAVES
enforcefalseinformativo hasta que el operador lo active
tolerance_pct4.0umbral de proporción de tx desconocidas; ajustable a la baja hacia 2.0
poll_interval_secs10cadencia del poll a getrawmempool
max_stale_secs60ventana de fail-stale antes de que la vista pase a Degraded
per_tx_detailfalseamplía SAMPLE_UNKNOWN_CAP=10 a todos los txids desconocidos
rpc_urlendpoint RPC del bitcoind del operador
rpc_userauth RPC · o vía variable de entorno
rpc_passauth RPC · o vía variable de entorno

Las 8 claves nuevas son opcionales y con valores por defecto, de modo que las configuraciones antiguas se siguen cargando sin cambios.

Q4

¿Cuánto cuesta? ¿Qué licencia tiene?

Tres modos de adopción: Shadow (gratis, solo aviso), Observe (con licencia, sin aplicación de política), Inline (con licencia, fail-closed).

MODO
Shadow
Gratis~1 día para cablear

Ejecuta la pasarela detrás de tu ruta actual con veredicto = solo aviso. Cero cambios en el flujo de shares.

MODO
Observe
Licencia~1 semana

Stack de Docker autoalojado más clave de licencia. Requiere un bitcoind de mainnet (o usa rg-feed-server).

MODO
Inline
LicenciaDepende del estado de la infra

Aplicación de política fail-closed. Pasarela dentro de la ruta de los shares.

REQUISITO BITCOIND

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].

LICENCIA
Source-available, con continuidad por escrow.
Cada línea es auditable. El despliegue comercial requiere licencia; sin opacidad. Si Veldra deja de operar, el código fuente completo se publica bajo una licencia permisiva — tu despliegue, tu configuración y tus datos siguen siendo tuyos. Sin dependencia del proveedor.
Q5

¿Por qué no usar una pasarela de pool existente?

Matriz de funcionalidades en paralelo frente al pool de la Stratum Reference Implementation — el único comparable individual nombrado en nuestra investigación. Las demás superficies (forks internos de Core, proxies de demand-broker, no hacer nada) son decisiones operativas, no productos.

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.

EJE
SRI
Veldra
Superficie del protocolo SV2
Sí · referencia canónica
Sí · forma de producción
Verificaciones de clase política v1
Parcial
Completas · 59 gateway reason codes
Re-derivación de invariantes L2
No
Sí · 22 códigos v2_invariant
Verdad de campo del mempool L3
No
Sí · Fase 2 Class M
Construido para el despliegue por operadores de pool
Referencia de implementación

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.

Q6

¿Qué está INTEGRADO hoy y qué sigue en planificación?

v2.0.0 conecta la Fase 1 (invariantes Tier 1 + Tier 2 — 10 códigos) y la Fase 2 (referencia real del mempool en Class M) en el mismo release. La Fase 1.5 añade los 7 invariantes Tier 3 de doble seguridad tras el ciclo de observación en producción. v3.x es un boceto de diseño — detección de selfish mining.

v2.0.0Hito de lanzamiento v2.0.0actual

Invariant Shield Fase 1 más la referencia real del mempool de la Fase 2.

p1.5Fase 1.5siguiente bucket de ingeniería

Siete invariantes Tier 3 de doble seguridad se conectan tras completarse limpiamente el ciclo de observación en producción de v2.0.0.

v3.xv3.x (visión moderada)boceto de diseño

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.

▸ CÓMO PROBARLO ANTES DE COMPROMETERSE