SmartHoldem · Web 4.0 Ecosystem
SmartHoldem Blockchain: Web 4.0 & Post-Quantum Sicherheit
Innovative DPoS-Blockchain-Infrastruktur
SmartHoldem ist die dezentrale Vertrauens- und Abrechnungsschicht für Web 4.0. Von Grund auf neu in Rust entwickelt, bietet es eine P2P-Architektur mit integrierter NAT-Traversal und Quantenresilienz.

Bewegen Sie die Maus, um Knoten zu sehen. Zuhause oder Server. Ein Mesh.
Geschwindigkeit & Skalierung
Gebaut für Geschwindigkeit und Skalierung
Der neue Rust-Kern von SmartHoldem überwindet traditionelle Blockchain-Grenzen: Node.js- und PostgreSQL-Engpässe werden durch eine optimierte Engine und Sled DB ersetzt und ermöglichen blitzschnelle Synchronisierung und enormen Durchsatz.
Millisekunden-Blockverarbeitung
Blöcke mit 500 Transaktionen werden in ca. 50 ms verifiziert und angewendet. Dank eines BFT-Finalitäts-Gadgets und paralleler Verarbeitung erreicht das Netzwerk absolute, unwiderrufliche Finalität in nur 1 Slot (~8 Sekunden).
Echte serverlose Skalierbarkeit
Angetrieben durch das Iroh P2P-Protokoll. Keine zentralisierten Cloud-Anbieter erforderlich – Sie können jedoch Ihren eigenen Knoten betreiben. Jedes Laptop, Raspberry Pi oder ARM64-Mobilgerät kann ein vollständiger, validierender Knoten hinter jedem NAT sein, ohne statische IP-Adresse.
Umweltfreundlich & leichtgewichtig
Ein vollständig validierender Knoten benötigt jetzt nur noch ca. 800 MB RAM. DPoS kombiniert mit Rusts Zero-Cost-Abstraktionen macht dies zu einem der energieeffizientesten Netzwerke überhaupt.

Benchmarks
Leistungsbenchmarks
Reale Lasttests auf dem neuen Rust-Kern bestätigen unternehmenstaugliche Skalierbarkeit auf Visa-Niveau.
Leistung wird gemessen, nicht behauptet. Die folgenden Benchmarks spiegeln die neue Rust + Sled-Architektur mit paralleler Signaturverifikation (Rayon) und optimierten kryptografischen Pipelines wider:
256
MultiPayments pro TX
5.53B
Ops / Tag (Spitze)
| Konfiguration | Ops / Sekunde | Ops / Stunde | Ops / Tag |
|---|---|---|---|
| 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 |
Unter der Haube
Technischer Stack
Kern-Blockchain-Engine
- Sprache: 100% Rust mit paralleler Signaturverifizierung (Rayon), Speichersicherheit und Null-Kosten-Abstraktionen.
- Datenbank: Eingebetteter Sled Key-Value-Store mit zstd-Komprimierung = 11.7M+ Blöcke in ~8 GB, als Ersatz für veraltete PostgreSQL-Abhängigkeiten.
- Konsens: DPoS mit 21 aktiven Delegierten, erweitert durch einen BFT-Finalitätsmechanismus (deterministische Finalität in 1 Slot).
- Kryptografie: Hybrides Sicherheitsmodell. Klassisches secp256k1 (BIP-Schnorr) + post-quantenbasiertes ML-DSA-44 (NIST FIPS 204) über Quantum Shield.
API, SDK & SmartNet
- Entwickler-Brücke: Natives window.smartholdem IPC für Tauri dApps. Sicherer, isolierter Zugriff auf Signierung, P2P-Speicher und Netzwerkstatus.
- Programmierbare Objekte: Native SmartObjects und Token. Register, Ausgabe, kein Smart-Contract-Overhead und keine EVM-Risiken.
- Datenspeicherung: BLAKE3-inhaltsadressierte Verifizierung. Metadaten werden on-chain in SmartNetData verankert, absolute Integrität ohne externe Indexer.
- API und SDK: 100% abwärtskompatible RESTful API + SDK. Echtzeit-QUIC-Push-Streams für sofortige, abfragefreie Aktualisierungen.
Web 4.0 P2P-Transport
- Protokoll: Aufgebaut auf Iroh (QUIC/UDP), bietet verschlüsselte, gemultiplexte Verbindungen mit nativem NAT-Traversal und Hole-Punching. Knoten können Blöcke hinter Heimroutern ohne statische IP erzeugen und synchronisieren.
- Netzwerktopologie: Dual-Stack-Architektur. Die primäre Kommunikation erfolgt über das dezentralisierte Iroh-Mesh, während eine Legacy-WebSocket/Protobuf-Brücke (port 4001) ausschließlich zur Abwärtskompatibilität mit Knoten auf Servern aufrechterhalten wird.
- Dezentralisierte Erkennung: Die Peer-Erkennung basiert auf Mainline DHT, lokalem mDNS und einem kryptografisch signierten Peer-Adressbuch, wodurch jede Abhängigkeit von zentralisierten DNS- oder öffentlichen Relay-Diensten entfällt.
Wahre Dezentralisierung
Gemeinschaftlich regiert, nicht von Konzernen
Dezentralisierung ist fundamental. Die SmartHoldem DPoS Blockchain ist unveränderlich und alle Operationen sind unwiderruflich. Jede Transaktion ist zu jeder Zeit transparent im Block-Explorer oder über API einsehbar.
Demokratische Abstimmung
Validatoren werden nach Reputation ausgewählt, nicht nach zentralisierter Kontrolle.
Keine eingefrorenen Münzen
Benutzer stimmen mit dem Wert ihrer Bilanz ab. Münzen bleiben unter vollständiger Benutzerkontrolle.
Verantwortlichkeit
Jeder STH-Inhaber kann abstimmen, Delegierte wählen oder abwählen. Ineffektive Delegierte werden schnell durch die Gemeinschaft ersetzt.
Eigentum
Das Halten von nur >1 STH gewährt volles Stimmrecht im Netzwerk.


Das Delegatensystem
Die TOP 21: Sicherung des Netzwerks
Delegierte (auch als Zeugen oder Block-Produzenten bekannt) sind für die Verifizierung von Transaktionen, die Erstellung neuer Blöcke und den Schutz des SmartHoldem-Netzwerks verantwortlich. Sie können Transaktionsdaten weder verändern noch beeinflussen.
21
Aktive Delegierte in TOP
8s
Durchschnittliche Blockzeit
100%
Gemeinschaftlich gewählt
0%
Zentralisierte Kontrolle
Das Delegationssystem ist hochgradig wettbewerbsfähig. Ein Delegierter kann jederzeit in oder aus der TOP 21 wechseln. Dieses nachhaltige System bietet neuen Delegierten die Möglichkeit, sich zu beweisen und die Aufmerksamkeit der Gemeinschaft zu gewinnen.
Ökonomie
Nachhaltige Belohnungen. Null Inflationäre Emission.
Es gibt keine Emission in der SmartHoldem (DPoS) Blockchain. Delegierte erhalten Belohnungen ausschließlich aus Transaktionsgebühren, was ein deflationäres, nachhaltiges Wirtschaftsmodell gewährleistet.
Der Delegierte, der den Block signiert, erhält ALLE NETZWERKGEBÜHREN für die in diesem Block enthaltenen Transaktionen.
Wie Delegierte verdienen
500 STH
pro Block (max)
500 Standardtransaktionen in einem Block → bis zu 500 STH verdient.
10.000 STH
Registrierungsgebühr
Delegierten-Registrierungstransaktion → 10.000 STH verdient.
500 STH
Token-Ausgabe
50 % der Gebühr werden verbrannt
Jeder neue Web4-Native-Token-Launch bringt dem Delegierten eine Belohnung ein.
Erweiterte Transaktionstypen
SmartHoldem unterstützt ein reichhaltiges Ökosystem von Transaktionstypen, das vielfältige Gebühreneinnahmen generiert:
Teilnehmen
SmartHoldem Delegate werden
Die Sicherung des Netzwerks ist nicht länger auf unternehmenseigene Rechenzentren beschränkt. Mit dem neuen Rust-Kern und Iroh P2P-Transport kann jeder einen validierenden Knoten betreiben und von überall auf der Welt am Konsens teilnehmen.
Empfohlene Knotenspezifikationen
8 GB RAM, 4 CPU-Kerne, 64 GB HDD oder 32 GB SSD.
- 1
Registrieren & am Rennen teilnehmen
Die Sicherung des Netzwerks ist nicht länger auf unternehmenseigene Rechenzentren beschränkt. Mit dem neuen Rust-Kern und Iroh P2P-Transport kann jeder einen validierenden Knoten betreiben und von überall auf der Welt am Konsens teilnehmen.
- 2
Ihren Knoten einrichten (keine statische IP erforderlich)
Laden Sie das schlanke sth-core-pq-Binary herunter. Es benötigt nur ca. 800 MB RAM und ca. 8 GB Speicherplatz. Dank Iroh QUIC NAT-Traversal benötigen Sie keine statische IP oder offene Ports – produzieren Sie Blöcke sicher von Ihrem Laptop, Raspberry Pi oder einem Server.
- 3
Ihre Delegiertenkandidatur bekannt geben
Reichen Sie einen Vorschlag im Community-Forum ein, in dem Sie Ihre Netzwerkkonfiguration, den vorgeschlagenen Auszahlungsprozentsatz und zusätzliche Dienste beschreiben. Stellen Sie anschließend Ihren Delegierten der Community über Telegram und aktive Öffentlichkeitsarbeit vor.
- 4
Echte Erträge erzielen
Erhalten Sie 100 % der Netzwerkgebühren aus den von Ihnen produzierten Blöcken. Ohne inflationäre Emission sind Ihre Belohnungen durch echten Netzwerknutzen gedeckt: Transfers, Token-Launches, Namensregistrierung, P2P-Speicher, dVPN-Relays und mehr.
- 5
Das Ökosystem aktiv gestalten und ausbauen
Delegierte werden von der Community gewählt. Schaffen Sie Vertrauen durch transparente Belohnungsverteilung, den Betrieb öffentlicher Netfory-Seeder oder aktive Beiträge zum Web 4.0-Ökosystem.

Gemeinschaft
Gemeinschaftsverbindung
Als Delegierter sind aktive Teilnahme und Verbindung zur Gemeinschaft für die Stimmengewinnung unerlässlich. Die Generierung von Delegatenplätzen ist wettbewerbsfähig und erfordert mehr als nur Knotenverwaltung.
Entwicklung neuer Anwendungen basierend auf SmartHoldem
Anbieten von Code-Reviews und Schwachstellenberichterstattung
Gemeinschaftsarbeit und Bildung
Anbieten eines Prozentsatzes der Belohnungen an Wähler (um die TOP 21 zu erreichen)
Die Belohnung wird basierend auf dem Anteil der Wähler an der Teilnahme und dem Auszahlungsprozentsatz des Delegierten gemessen.
Quanten-Schild
SmartHoldem Quanten-Schild
Wie wir die Blockchain vor zukünftigen Computern schützen
Während der Markt über Charts diskutiert, reift eine Bedrohung heran, die klassische Kryptografie zunichtemachen könnte. Shors Algorithmus auf einem ausreichend leistungsfähigen Quantencomputer könnte ECDSA brechen – die mathematische Grundlage der meisten Blockchains heute. SmartHoldem wartet nicht auf einen hypothetischen 'Tag X'.
Wir bauen den Schutzschild heute. Stufe A (Post-Quantum-Schlüsselverpflichtungen) ist bereits AKTIV im Mainnet.

Roadmap
Implementierungsplan: Hybrides Modell
Wir schließen abrupte Hard Forks und erzwungene Massenmigrationen aus. Der Übergang zur Quantenresilienz erfolgt schrittweise, nahtlos und abwärtskompatibel:
Phase 1
Schlüsselverpflichtungen (Aktiv)
- Nutzer können bereits den SHA-256-Hash ihres künftigen ML-DSA-44-Public-Keys über das vendorField (sthpq1:...) verankern.
- Dies verhindert 'Race-Condition'-Angriffe bei Aktivierung von Phase 2 und sichert die Wallet, bevor die Quantenbedrohung real wird.
Phase 2
Hybride Zweitsignaturen (Akzeptiert)
- Nutzer können einen post-quantensicheren ML-DSA-44-Public-Key (NIST FIPS 204) als Zweitsignatur in ihrer bestehenden Wallet registrieren.
- Ab diesem Zeitpunkt erfordert jede Transaktion zwei Signaturen: die klassische secp256k1-Signatur und die neue quantenresistente Signatur.
- Der klassische Schlüssel bleibt für volle Kompatibilität aktiv, während der post-quantensichere Schlüssel eine quantenresistente zweite Schicht hinzufügt – ein robustes hybrides Schema, das Ihre Assets schützt, selbst wenn einer der Algorithmen kompromittiert wird.
Phase 3
Vollständige Netzwerkresilienz (Geplant)
- Alle 21 aktiven Delegierten signieren Blöcke mit post-quantensicheren Signaturen, um Konsens-Spoofing zu verhindern.
- Die Iroh P2P-Transportschicht verwendet hybriden Schlüsselaustausch (X25519 + ML-KEM-768), um Messenger- und dApp-Daten zu sichern (SHIP-40).
Architektur
Das Schloss upgraden, nicht den Tresor
Im Gegensatz zu anderen Netzwerken, die Nutzer zur Erstellung neuer Wallets und Massentransfers zwingen, nutzt SmartHoldem seine einzigartige Zweitsignatur-Architektur für ein nahtloses Quanten-Upgrade.
Adressbildung
Ihre SmartHoldem-Adresse wird von Ihrem klassischen secp256k1-Public-Key abgeleitet. Dies bleibt unverändert.
Zweitschlüssel-Aktivierung
Sie registrieren Ihren post-quantensicheren ML-DSA-44-Public-Key als Zweitsignatur für Ihre bestehende Adresse.
Hybrider Schutz
Jede Transaktion erfordert nun sowohl die klassische als auch die post-quantensichere Signatur, um gültig zu sein.
Das Ergebnis
- Sie müssen Ihre Wallet oder Adresse nicht wechseln
- Ihre Coins verbleiben genau dort, wo sie seit Jahren sind
- Keine komplexen Wallet-Migrationen
- Ihr Konto ist jetzt durch eine doppelte kryptografische Schutzschicht gesichert
- Selbst wenn ein Quantencomputer Ihren ersten privaten Schlüssel ableitet, kann er Ihre Mittel ohne die gültige zweite (quantenresistente) Signatur nicht bewegen
Für Benutzer mit einer einzelnen Signatur: Sie können jederzeit eine zweite Signatur aktivieren, um sofortigen Quantenschutz zu erhalten, oder in ferner Zukunft zu neuen quantensicheren Adresstypen migrieren.
Tiefe Technik
Technische Nuancen & Netzwerkschutz
Delegierte unter Schutz
- In einem DPoS-Netzwerk signieren Delegierte Blöcke
- Kompromittierte Delegaten-Signaturen gefährden die Integrität der gesamten Blockchain
- Die Implementierung von PQC auf Protokollebene macht SmartHoldem zu einer "digitalen Festung", die resistent gegen Konsensus-Spoofing ist
Optimierte Signaturgrößen
- Wir haben ML-DSA-44 (NIST FIPS 204) für seine optimale Balance gewählt: ~2,4 kB Signaturen und Verifizierung unter einer Millisekunde
- Die parallele Verarbeitung des Rust-Kerns (Rayon) stellt sicher, dass diese rechenintensiven Transaktionen sofort verifiziert werden, ohne die Synchronisierungsgeschwindigkeit zu beeinträchtigen
Algorithmische Agilität
- Das Protokoll enthält ein alg_id-Byte in PQC-Objekten
- Dies ermöglicht nahtlose zukünftige Upgrades (z. B. auf FN-DSA-512 / Falcon), ohne dass Benutzer Adressen ändern oder Mittel migrieren müssen
- Für den Benutzer sieht dies wie eine gewohnte Wallet aus
Entwicklung
Code in Arbeit
Der Rust-Kern (sth-core-pq) enthält bereits das kryptografische Fundament für die neue Verifizierungsschicht. Hier ist ein Einblick in die Hybrid-Integration:
//! 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()))
}Quantenüberlegenheit ist nicht das Ende der Kryptografie, sondern ihre nächste Evolutionsstufe. Wir setzen auf Mathematik, die sich nicht durch Brute-Force lösen lässt, und integrieren sie direkt in den Kern unseres Web 4.0 DPoS-Netzwerks. Die Zukunft ist bereits hier. Und sie ist gesichert. Die Zukunft ist bereits hier. Und sie ist gesichert.
Treten Sie dem Netzwerk bei
Ihr Node. Ihre Regeln. Ihr Web 4.0.
Sie können das Netzwerk auf vielfältige Weise absichern: Blöcke als Delegat produzieren, dApps als Netfory-Betreiber seeden, ein dVPN-Relay betreiben oder einfach halten und abstimmen. Null Inflation, echte Nutzungsvergütungen und ein in Rust aufgebautes quantenresistentes Fundament. Das dezentrale Internet braucht Gestalter – und es beginnt mit Ihnen.

