SmartHoldem · Ecosistema Web 4.0
Blockchain SmartHoldem: Web 4.0 y Post-Cuántica Seguridad
Infraestructura Blockchain DPoS Innovadora
SmartHoldem es la capa descentralizada de confianza y liquidación para Web 4.0. Reescrita desde cero en Rust, ofrece una arquitectura P2P con traversal NAT integrado y resiliencia cuántica.

Pasa el cursor para ver los nodos. En casa o en servidor. Una sola malla.
Velocidad y Escala
Construido para Velocidad y Escala
El nuevo núcleo Rust de SmartHoldem rompe los límites tradicionales del blockchain: los cuellos de botella de Node.js y PostgreSQL son reemplazados por un motor optimizado y Sled DB, ofreciendo sincronización ultrarrápida y un rendimiento masivo.
Procesamiento de Bloques en Milisegundos
Los bloques de 500 transacciones se verifican y aplican en ~50 ms. Impulsado por un mecanismo de finalidad BFT y procesamiento paralelo, la red alcanza una finalidad absoluta e irreversible en solo 1 slot (~8 segundos).
Escalabilidad Verdaderamente Sin Servidor
Impulsado por el protocolo P2P Iroh. No se necesitan proveedores de nube centralizados, pero puedes ejecutar tu propio nodo. Cualquier laptop, Raspberry Pi o dispositivo móvil ARM64 puede ser un nodo completo de validación detrás de cualquier NAT, sin necesidad de una IP estática.
Ecológico y Ligero
Un nodo de validación completo ahora funciona con solo ~800 MB de RAM. DPoS combinado con las abstracciones de costo cero de Rust convierte esto en una de las redes más eficientes energéticamente que existen.

Benchmarks
Benchmarks de Rendimiento
Las pruebas de carga en condiciones reales sobre el nuevo núcleo Rust confirman una escalabilidad de nivel empresarial, equiparable a Visa.
El rendimiento se mide, no se presume. Los siguientes benchmarks reflejan la nueva arquitectura Rust + Sled con verificación de firmas en paralelo (Rayon) y pipelines criptográficos optimizados:
256
MultiPayments por TX
5.53B
Ops / Día (pico)
| Configuración | Ops / Segundo | Ops / Hora | Ops / Día |
|---|---|---|---|
| 2000 TX/block (MultiPayments) | 64,000 | 230.4M | 5.53B |
| 1000 TX/block (MultiPayments) | 32,000 | 115.2M | 2.76B |
| 500 TX/block (MultiPayments) | 16,000 | 57.6M | 1.38B |
Bajo el Capó
Pila Técnica
Motor Principal del Blockchain
- Lenguaje: 100% Rust con verificación de firmas en paralelo (Rayon), seguridad de memoria y abstracciones de coste cero.
- Base de datos: Almacén de clave-valor embebido Sled con compresión zstd = 11.7M+ bloques en ~8 GB, reemplazando las dependencias heredadas de PostgreSQL.
- Consenso: DPoS con 21 delegados activos, reforzado por un mecanismo de finalidad BFT (finalidad determinista en 1 ranura).
- Criptografía: Modelo de seguridad híbrido. Clásico secp256k1 (BIP-Schnorr) + post-cuántico ML-DSA-44 (NIST FIPS 204) mediante Quantum Shield.
API, SDK y SmartNet
- Puente para desarrolladores: IPC nativo window.smartholdem para dApps con Tauri. Acceso seguro y en entorno aislado a firma, almacenamiento P2P y estado de red.
- Objetos programables: SmartObjects y tokens nativos. Registros, emisión, sin sobrecarga de contratos inteligentes y sin riesgos de EVM.
- Almacenamiento de datos: Verificación por contenido con BLAKE3. Metadatos anclados en cadena en SmartNetData, integridad absoluta, sin indexadores externos.
- API y SDK: RESTful API + SDK 100% compatibles con versiones anteriores. Flujos push QUIC en tiempo real para actualizaciones instantáneas sin sondeo.
Transporte P2P Web 4.0
- Protocolo: Construido sobre Iroh (QUIC/UDP), proporcionando conexiones cifradas y multiplexadas con traversal NAT nativo y hole-punching. Los nodos pueden producir y sincronizar bloques desde detrás de routers domésticos sin IP estática.
- Topología de red: Arquitectura de pila dual. La comunicación principal se realiza a través de la malla descentralizada Iroh, mientras que un puente heredado WebSocket/Protobuf (port 4001) se mantiene estrictamente para compatibilidad con versiones anteriores en nodos de servidores.
- Descubrimiento descentralizado: El descubrimiento de pares se basa en Mainline DHT, mDNS local y un libro de direcciones de pares firmado criptográficamente, eliminando cualquier dependencia de DNS centralizado o servicios de retransmisión públicos.
Descentralización Real
Gobernado por la Comunidad, No por Corporaciones
La descentralización es fundamental. La blockchain DPoS de SmartHoldem es inmutable y todas las operaciones son irreversibles. Cualquier transacción está disponible de forma transparente para visualizar en el Explorador de Bloques o vía API en cualquier momento.
Votación Democrática
Los validadores son elegidos según reputación, no control centralizado.
Sin Monedas Congeladas
Los usuarios votan con el poder de su saldo. Las monedas permanecen bajo control total del usuario.
Responsabilidad
Cualquier titular de STH puede votar, elegir o cancelar delegados. Los delegados ineficientes son reemplazados rápidamente por la comunidad.
Propiedad
Poseer solo >1 STH otorga derechos de voto completos en la red.


El Sistema de Delegados
El TOP 21: Asegurando la Red
Los delegados (también conocidos como testigos o productores de bloques) son responsables de verificar transacciones, crear nuevos bloques y proteger la red SmartHoldem. No pueden alterar ni influir en los datos de las transacciones.
21
Delegados Activos en TOP
8s
Tiempo Promedio de Bloque
100%
Votados por la Comunidad
0%
Control Centralizado
El sistema de delegación es altamente competitivo. Un delegado puede entrar o salir del TOP 21 en cualquier momento. Este esquema sostenible brinda la oportunidad a nuevos delegados de demostrarse y atraer la atención de la comunidad.
Economía
Recompensas Sostenibles. Cero Emisión Inflacionaria.
No hay sin emisión en la blockchain SmartHoldem (DPoS). Los delegados reciben recompensas exclusivamente de las tarifas de transacción, asegurando un modelo económico deflacionario y sostenible.
El delegado que firma el bloque recibe TODAS LAS TARIFAS DE RED de las transacciones incluidas en ese bloque.
Cómo Ganan los Delegados
500 STH
por bloque (máx)
500 transacciones estándar en un bloque → hasta 500 STH ganados.
10,000 STH
tarifa de registro
Transacción de registro de delegado → 10,000 STH ganados.
500 STH
emisión de tokens
El 50% de la comisión se quema
Cada nuevo lanzamiento de token nativo Web4 otorga al delegado una recompensa.
Tipos de Transacciones Avanzadas
SmartHoldem soporta un ecosistema rico de tipos de transacciones, generando ingresos por tarifas diversos:
Participar
Convertirse en Delegado de SmartHoldem
Asegurar la red ya no está limitado a centros de datos corporativos. Con el nuevo núcleo Rust y el transporte P2P Iroh, cualquiera puede ejecutar un nodo de validación y participar en el consenso desde cualquier parte del mundo.
Especificaciones Recomendadas del Nodo
8 GB de RAM, 4 núcleos de CPU, 64 GB HDD o 32 GB SSD.
- 1
Regístrate y Entra en la Competencia
Asegurar la red ya no está limitado a centros de datos corporativos. Con el nuevo núcleo Rust y el transporte P2P Iroh, cualquiera puede ejecutar un nodo de validación y participar en el consenso desde cualquier parte del mundo.
- 2
Configura Tu Nodo (Sin IP Estática Necesaria)
Descarga el binario ligero sth-core-pq. Funciona con solo ~800 MB de RAM y ~8 GB de espacio en disco. Gracias al traversal NAT QUIC de Iroh, no necesitas una IP estática ni puertos abiertos — produce bloques de forma segura desde tu laptop, Raspberry Pi o un servidor.
- 3
Anuncia tu candidatura como delegado
Envía una propuesta en el Foro de la Comunidad detallando tu configuración de red, el porcentaje de pago propuesto y los servicios adicionales. Luego presenta tu delegado a la comunidad a través de Telegram y una participación activa.
- 4
Obtén Rendimiento Real
Gana el 100% de las comisiones de red de los bloques que produces. Con emisión inflacionaria cero, tus recompensas están respaldadas por utilidad de red real: transferencias, lanzamientos de tokens, registro de nombres, almacenamiento P2P, retransmisores dVPN, etc.
- 5
Participa y Haz Crecer el Ecosistema
Los delegados son elegidos por la comunidad. Genera confianza ofreciendo un reparto transparente de recompensas, operando seeders públicos de Netfory, o contribuyendo activamente al ecosistema Web 4.0.

Comunidad
Conexión Comunitaria
Como delegado, la participación activa y la conexión con la comunidad son vitales para obtener votos. Generar posiciones de delegado es competitivo y requiere más que la gestión de nodos.
Construir nuevas aplicaciones basadas en SmartHoldem
Ofrecer revisiones de código y reporte de vulnerabilidades
Alcance y educación comunitaria
Ofrecer un porcentaje de recompensas a los votantes (para alcanzar el TOP 21)
La recompensa se mide según la participación del votante y el porcentaje de pago del delegado.
Escudo Cuántico
Escudo Cuántico de SmartHoldem
Cómo Protegemos la Blockchain de Computadoras Futuras
Mientras el mercado debate gráficos, una amenaza capaz de anular la criptografía clásica está madurando. El algoritmo de Shor en un ordenador cuántico suficientemente potente podría romper ECDSA — la base matemática de la mayoría de las blockchains actuales. SmartHoldem no está esperando a un hipotético 'Día X'.
Estamos construyendo el escudo hoy. La Etapa A (Compromisos de Clave Post-Cuántica) ya está ACTIVA en la mainnet.

Hoja de Ruta
Plan de Implementación: Modelo Híbrido
Descartamos las bifurcaciones duras abruptas y las migraciones masivas forzadas. La transición hacia la resiliencia cuántica es gradual, fluida y compatible con versiones anteriores:
Fase 1
Compromisos de Clave (Activo)
- Los usuarios ya pueden anclar el hash SHA-256 de su futura clave pública ML-DSA-44 a través del vendorField (sthpq1:...).
- Esto previene ataques de 'condición de carrera' cuando se active la Fase 2, asegurando la billetera antes de que la amenaza cuántica se materialice.
Fase 2
Segundas Firmas Híbridas (Aceptado)
- Los usuarios pueden registrar una clave pública post-cuántica ML-DSA-44 (NIST FIPS 204) como segunda firma en su billetera existente.
- A partir de ese momento, cada transacción requiere dos firmas: la clásica secp256k1 y la nueva resistente a computación cuántica.
- La clave clásica permanece activa para plena compatibilidad, mientras que la clave post-cuántica añade una segunda capa resistente a la computación cuántica — formando un esquema híbrido robusto que protege tus activos incluso si cualquiera de los algoritmos se ve comprometido.
Fase 3
Resiliencia Total de la Red (Planificado)
- Los 21 delegados activos firman bloques con firmas post-cuánticas para prevenir la suplantación del consenso.
- La capa de transporte P2P de Iroh utiliza intercambio de claves híbrido (X25519 + ML-KEM-768) para asegurar los datos del mensajero y las dApps (SHIP-40).
Arquitectura
Actualiza la Cerradura, No la Caja Fuerte
A diferencia de otras redes que exigen a los usuarios crear nuevas billeteras y transferir masivamente sus activos, SmartHoldem aprovecha su exclusiva arquitectura de segunda firma para una actualización cuántica sin fricciones.
Formación de Dirección
Tu dirección SmartHoldem se deriva de tu clave pública clásica secp256k1. Esto permanece sin cambios.
Activación de Segunda Clave
Registras tu clave pública post-cuántica ML-DSA-44 como segunda firma en tu dirección existente.
Protección Híbrida
Cada transacción ahora requiere tanto la firma clásica como la post-cuántica para ser válida.
El Resultado
- No necesitas cambiar tu billetera ni tu dirección
- Tus monedas permanecen exactamente donde han estado durante años
- Sin migraciones de billetera complejas
- Tu cuenta está ahora protegida por una doble capa criptográfica
- Incluso si una computadora cuántica obtiene tu primera clave privada, no puede mover tus fondos sin la segunda firma válida (resistente a la computación cuántica)
Para usuarios con una sola firma: Puedes activar una segunda firma en cualquier momento para habilitar instantáneamente la protección cuántica, o migrar a nuevos tipos de direcciones seguras ante la computación cuántica en un futuro lejano.
Deep Tech
Matices Técnicos y Protección de Red
Delegados Bajo Protección
- En una red DPoS, los delegados firman bloques
- Las firmas de delegados comprometidas amenazan la integridad de toda la blockchain
- Implementar PQC a nivel de protocolo convierte a SmartHoldem en una «fortaleza digital» resistente a la falsificación de consenso
Tamaño de Firma Optimizado
- Seleccionamos ML-DSA-44 (NIST FIPS 204) por su equilibrio óptimo: firmas de ~2,4 kB y verificación en menos de un milisegundo
- El procesamiento paralelo del núcleo en Rust (Rayon) garantiza que estas transacciones de mayor peso se verifiquen al instante sin perder velocidad de sincronización
Agilidad Algorítmica
- El protocolo incluye un byte alg_id en los objetos PQC
- Esto permite futuras actualizaciones sin interrupciones (por ejemplo, a FN-DSA-512 / Falcon) sin que los usuarios tengan que cambiar de dirección ni migrar fondos
- Para el usuario, esto se ve como una billetera familiar
Desarrollo
Código en Progreso
El núcleo en Rust (sth-core-pq) ya incluye la base criptográfica para la nueva capa de verificación. A continuación, un vistazo a la integración híbrida:
//! Quantum Shield: ML-DSA-44 (NIST FIPS 204) keys derived from a passphrase, plus the stage-A
//! commitment format (`sthpq1:<alg>:<sha256(pk)>` in a self-transfer vendorField). See docs/SPEC-PQ-V3.md.
use crate::error::{Error, Result};
use ml_dsa::{EncodedSignature, EncodedVerifyingKey, MlDsa44, Signature, SigningKey, VerifyingKey, B32};
use sha2::{Digest, Sha256};
/// Algorithm ids (first byte of every PQ object).
pub const ALG_ML_DSA_44: u8 = 0x01;
pub const PK_LEN: usize = 1312;
pub const SIG_LEN: usize = 2420;
/// Domain separation for the ML-DSA context string.
const CTX: &[u8] = b"sth-pq-v1";
/// Context of stage-C block signatures (`M_B = sha256(header || blockSignature)`).
pub const BLOCK_CTX: &[u8] = b"sth-pq-block-v1";
/// Commitment prefix in vendorField.
pub const COMMITMENT_PREFIX: &str = "sthpq1:";
pub struct PqKeyPair {
signing: SigningKey<MlDsa44>,
}
impl PqKeyPair {
/// Deterministic: seed ξ = sha256("sth-pq-v1" || passphrase). Same passphrase → same key on every device.
pub fn from_passphrase(passphrase: &str) -> Self {
let mut h = Sha256::new();
h.update(CTX);
h.update(passphrase.as_bytes());
let seed: [u8; 32] = h.finalize().into();
Self::from_seed(&seed)
}
pub fn from_seed(seed: &[u8; 32]) -> Self {
Self { signing: SigningKey::<MlDsa44>::from_seed(&B32::from(*seed)) }
}
/// FIPS 204 pkEncode — 1 312 bytes.
pub fn public_key(&self) -> Vec<u8> {
self.signing.expanded_key().verifying_key().encode().to_vec()
}
pub fn public_key_hex(&self) -> String {
hex::encode(self.public_key())
}
/// Deterministic ML-DSA-44 signature (2 420 bytes) over `message` with the sth context.
pub fn sign(&self, message: &[u8]) -> Result<Vec<u8>> {
self.sign_with_ctx(message, CTX)
}
pub fn sign_with_ctx(&self, message: &[u8], ctx: &[u8]) -> Result<Vec<u8>> {
let sig = self.signing.expanded_key().sign_deterministic(message, ctx).map_err(|_| Error::Serialization("ml-dsa sign".into()))?;
Ok(sig.encode().to_vec())
}
/// What a wallet publishes in stage A: `sthpq1:01:<sha256(pk) hex>`.
pub fn commitment(&self) -> String {
commitment_for_public_key(&self.public_key())
}
}
pub fn commitment_hash(public_key: &[u8]) -> [u8; 32] {
Sha256::digest(public_key).into()
}
pub fn commitment_for_public_key(public_key: &[u8]) -> String {
format!("{COMMITMENT_PREFIX}{:02x}:{}", ALG_ML_DSA_44, hex::encode(commitment_hash(public_key)))
}
pub fn verify(public_key: &[u8], message: &[u8], signature: &[u8]) -> Result<bool> {
verify_with_ctx(public_key, message, signature, CTX)
}
pub fn verify_with_ctx(public_key: &[u8], message: &[u8], signature: &[u8], ctx: &[u8]) -> Result<bool> {
if public_key.len() != PK_LEN || signature.len() != SIG_LEN {
return Ok(false);
}
let pk = EncodedVerifyingKey::<MlDsa44>::try_from(public_key).map_err(|_| Error::Serialization("ml-dsa pk".into()))?;
let sig = EncodedSignature::<MlDsa44>::try_from(signature).map_err(|_| Error::Serialization("ml-dsa sig".into()))?;
let Some(sig) = Signature::<MlDsa44>::decode(&sig) else { return Ok(false) };
Ok(VerifyingKey::<MlDsa44>::decode(&pk).verify_with_context(message, ctx, &sig))
}
/// Stage B: PQ public key registered by a wallet (type 1, v3). Lives in `WalletState.pq_key`, so undo is automatic.
#[derive(Debug, Clone, PartialEq, Eq, serde::Serialize, serde::Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct PqKey {
pub algorithm: u8,
/// Raw PQ public key, hex (1 312 bytes for ML-DSA-44).
pub public_key: String,
pub since: u64,
}
/// Parsed stage-A commitment.
#[derive(Debug, Clone, PartialEq, Eq, serde::Serialize, serde::Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct PqCommitment {
pub algorithm: u8,
/// sha256(public key), hex.
pub commitment: String,
pub height: u64,
}
/// `sthpq1:<alg 2 hex>:<64 hex>` → (alg, hash hex). Only known algorithm ids are accepted.
pub fn parse_commitment(vendor_field: &str) -> Option<(u8, String)> {
let rest = vendor_field.strip_prefix(COMMITMENT_PREFIX)?;
let (alg, hash) = rest.split_once(':')?;
if alg.len() != 2 || hash.len() != 64 || !hash.bytes().all(|b| b.is_ascii_hexdigit() && !b.is_ascii_uppercase()) {
return None;
}
let alg = u8::from_str_radix(alg, 16).ok()?;
(alg == ALG_ML_DSA_44).then(|| (alg, hash.to_string()))
}La supremacía cuántica no es el fin de la criptografía, sino su próxima etapa evolutiva. Estamos eligiendo matemáticas que no pueden ser 'resueltas' por fuerza bruta e integrándolas directamente en el núcleo de nuestra red Web 4.0 DPoS. El futuro ya está aquí. Y está asegurado. El futuro ya está aquí. Y está asegurado.
Unirse a la Red
Tu Nodo. Tus Reglas. Tu Web 4.0.
Puedes asegurar la red de muchas formas: producir bloques como delegado, distribuir dApps como operador de Netfory, ejecutar un relay dVPN o simplemente mantener tokens y votar. Inflación cero, recompensas por utilidad real y una base resistente a la computación cuántica construida en Rust. La internet descentralizada necesita constructores — y todo comienza contigo.

