Hauptfunktionen
Die folgende Tabelle listet jede wichtige Funktion in QoreChain auf, organisiert nach der Release-Phase, in der sie eingeführt wurde. Das aktuelle Mainnet-Release ist v3.2.1 (Konsensregeln von v3.2.0), live seit dem 29. Juni 2026 (qorechain-vladi, EVM-Chain-ID 9801); das parallele Testnet (qorechain-diana, EVM-Chain-ID 9800) läuft mit v3.2.2. Die Tabelle Funktionsstatus am Ende der Funktionsliste zeigt, was heute auf den Live-Netzwerken aktiv ist.
| Funktion | Eingeführt in | Beschreibung |
|---|---|---|
| PQC-Hybridsignaturen (standardmäßig erforderlich) | v1.1.0 (Sicherheit) | Duale Signaturen bei jeder Transaktion auf dem Cosmos-Pfad: eine klassische secp256k1-Signatur (ECDSA) gepaart mit ML-DSA-87 (Dilithium-5). Seit v3.1.71 lautet der Netzwerkstandard required (hybrid_signature_mode = required, allow_classical_fallback = false) — ausschließlich klassische Cosmos-Transaktionen werden abgelehnt; nur Genesis-Gentxs und Transaktionen zur PQC-Schlüsselregistrierung/-migration sind ausgenommen. EVM-Transaktionen behalten ihre eth_secp256k1-Signatur, werden aber seit v3.2.0 nur noch von einem Konto mit registriertem ML-DSA-87-Schlüssel und einem offenen EVM-Autorisierungsfenster zugelassen. Drei governance-gesteuerte Durchsetzungsmodi (disabled / optional / required) bleiben verfügbar. |
| SHAKE-256 als Standard-Hash | v1.1.0 (Sicherheit) | Extendable-Output-Funktion (XOF) der SHA-3-Familie. Seit v3.1.73 ist SHAKE-256 (über das qorehash-Paket) der Standard-Anwendungshash und vervollständigt die PQC-Grundlage (Dilithium-5 + ML-KEM-1024 + SHAKE-256). Bietet Hashing mit variabler Länge, feste 32-Byte-Ausgabe, Verkettung interner Merkle-Knoten und domänengetrenntes Hashing — alles in reinem Go ohne FFI-Abhängigkeit. |
| TEE- und FL-Schnittstellen | v1.1.0 (Sicherheit) | Schnittstellenspezifikationen (noch keine Implementierung) für die Attestierung von Trusted Execution Environments (SGX, TDX, SEV-SNP, ARM CCA) und für die Koordination von Federated Learning (Aggregationsmethoden FedAvg, FedProx, SCAFFOLD); beide sind für ein zukünftiges Release geplant. |
| On-Chain-RL-Konsens (PRISM) | v1.0.0 (Genesis) | Ein Go-natives Festkomma-MLP (73.733 Parameter) ist für die PPO-Inferenz in den Block-Lebenszyklus eingebaut. PRISM ist darauf ausgelegt, Blockzeit, Gaspreis und Pool-Gewichte abzustimmen; auf den Live-Netzwerken beobachtet es derzeit nur (es ist keine trainierte Policy geladen, und die Steuernachrichten sind deaktiviert). Deterministische Taylor-Reihen-Mathematik soll über alle Validatoren hinweg identische Ergebnisse liefern. Vier Betriebsmodi (shadow, conservative, autonomous, paused); beide Netzwerke sind auf conservative gesetzt. Schutzschalterschutz für Sicherheit. |
| Triple-Pool Composite PoS | v1.0.0 (Genesis) | Konzipiert: Validatoren werden alle 1.000 Blöcke in RPoS- (reputationsgewichtete), DPoS- (delegationsgewichtete) und PoS- (Standard-)Pools klassifiziert. Pool-gewichtete Sortition würde die Blockerzeugung über reine Stake-Dominanz hinaus diversifizieren, und eine benutzerdefinierte Bonding-Kurve würde selbst gebundenen Stake, Treuedauer, Reputationsqualität und Protokollphase berücksichtigen. In x/qca implementiert, aber noch nicht aktiv in Blockproduktion, Belohnungen oder Slashing; Blockvorschlag und Slashing folgen derzeit den standardmäßigen stake-gewichteten Regeln. |
| QDRW-Governance | v1.0.0 (Genesis) | Quadratic Delegation with Reputation Weighting. Konzipiert so, dass die Stimmkraft eine Quadratwurzelfunktion verwendet, gedämpft durch einen sigmoiden Reputationsmultiplikator, was eine Whale-Übernahme verhindert und gleichzeitig langfristige, ehrliche Teilnahme belohnt (ein 100-facher Stake-Vorteil ergibt etwa die 10-fache Stimmkraft; xQORE-Bestände verdoppeln das Stimmgewicht). Implementiert, aber auf den Live-Netzwerken deaktiviert (qdrw ist aus); Anträge werden derzeit anhand des gebondeten Stakes ausgezählt. |
| Burn-Engine | v1.0.0 (Genesis) | Zwölf Burn-Quellen (Gasgebühren, Vertragserstellung, KI-Servicegebühren, Bridge-Gebühren, Treasury-Rückkauf, fehlgeschlagene Transaktionen, xQORE-Strafen, automatisierter Rückkauf, der TGE-Burn, Rollup-Erstellung, Meilensteine der Transaktionsanzahl und AMM); im Mainnet hat bisher nur der Gasgebühren-Kanal Burns verzeichnet. Alles im Fee Collector, einschließlich der Epochen-Emission, wird aufgeteilt: 37 % an Validatoren, 30 % dauerhaft verbrannt, 20 % an die Treasury, 10 % an Staker und 3 % an Light Nodes. |
| xQORE-Staking | v1.0.0 (Genesis) | Noch nicht live: Die Sperr- und Entsperr-Transaktionen des Moduls sind auf den Live-Netzwerken nicht angebunden (siehe xQORE-Staking). Vorgesehenes Verhalten: QOR sperren, um xQORE im Verhältnis 1:1 zu minten und so doppeltes Governance-Gewicht in QDRW-Abstimmungen zu erhalten. Gestaffelte Ausstiegsstrafen (50 % unter 30 Tagen, 35 % bei 30–90 Tagen, 15 % bei 90–180 Tagen, 0 % nach 180 Tagen) werden über PvP-Rebase an die verbleibenden Inhaber umverteilt — was Überzeugung belohnt und kurzfristiges Kapital bestraft. |
| Begrenzte Emission | v1.0.0 (Genesis) | Ein endlicher Angebotspfad: 4.420.000.000 QOR zum Genesis (80.000.000 QOR der geplanten 4.500.000.000 wurden zum TGE verbrannt) plus Staking-Emission, die von x/inflation unter einer harten kumulativen Obergrenze von 114.285.714 QOR gemintet wird (16.239 QOR pro Epoche mit 43.200 Blöcken im Modus fixed). Burns entfernen Token dauerhaft. Siehe Tokenomics. |
| EVM-Laufzeitumgebung | v1.0.0 (Genesis) | Vollständige Ethereum-Kompatibilität mit EIP-1559-Gaspreisbildung, JSON-RPC auf Port 8545 (eth_-, web3_-, net_- und txpool_-Namespaces; der qor_-Namespace wird noch nicht bereitgestellt) und Unterstützung für Standard-Tooling (Hardhat, Foundry, Remix). Stellen Sie Solidity-Verträge mit bestehenden Ethereum-Workflows bereit und interagieren Sie mit ihnen; seit v3.2.0 benötigt der Absender einen registrierten Post-Quantum-Schlüssel und ein offenes EVM-Autorisierungsfenster. |
| CosmWasm-Laufzeitumgebung | v1.0.0 (Genesis) | WebAssembly-Smart-Contract-Engine für Rust-basierte Verträge. Vollständige Lebenszyklusunterstützung: instantiate, execute, query und migrate. Verträge laufen in einer sandboxgeschützten Wasm-Umgebung mit deterministischer Ausführung. Code-Upload und Instanziierung sind derzeit auf beiden Netzwerken deaktiviert (Governance-Einstellung plus Schutzschalter). |
| SVM-Laufzeitumgebung | v1.0.0 (Genesis) | BPF-Programmbereitstellung und -ausführung über einen Rust-gestützten Executor. Der Solana-kompatible JSON-RPC-Server auf Port 8899 unterstützt getAccountInfo, getBalance, getSlot und mehr. Lesemethoden funktionieren auf den öffentlichen Endpunkten; der SVM-Transaktionspfad ist derzeit netzwerkweit deaktiviert. |
| Cross-VM-Bridge | v1.0.0 (Genesis) | Nahtlose Interoperabilität über alle drei VMs hinweg. EVM-Verträge rufen CosmWasm über Precompile auf (noch nicht aktiv, siehe Netzwerkstatus); CosmWasm-Verträge rufen EVM über benutzerdefinierte Nachrichten auf; SVM-Programme nehmen über asynchrones ereignisbasiertes Bridging teil. Synchrone EVM-CosmWasm-Aufrufe und asynchrone SVM-Nachrichtenübermittlung innerhalb einer einzigen Chain. Die Cross-VM-Aufrufnachricht ist im Mainnet derzeit abgeschaltet. |
| Cross-Chain-Konnektivität | v1.2.0 (Interop) | Ausgelegt für bis zu acht IBC-Gegenparteien (Cosmos Hub, Osmosis, Noble, Celestia, Stride, Akash, Babylon, Injective) plus 37 QCB-Chain-Konfigurationen (36 externe Chains plus Injective über IBC). PQC-signierte Validator-Attestierungen, chainspezifische Bestätigungstiefen und Schutzschalter-Volumenobergrenzen. Stand Oktober 2026 befinden sich alle 37 Chain-Konfigurationen im Status pending, und auf keinem der beiden Netzwerke ist ein IBC-Kanal geöffnet — nicht live. |
| BTC-Restaking | v1.2.0 (Interop) | Entwurfsphase — die Transaktionen des Moduls sind auf den Live-Netzwerken nicht aktiviert. Integration des Babylon Protocol für Bitcoin-Finalitätsgarantien. Validatoren würden BTC-Staking-Positionen registrieren (mindestens 100.000 Satoshis). QoreChain-Epochen-Zustands-Roots werden über IBC-relayte Babylon-Epochen periodisch in Bitcoin verankert (Checkpoints) und bieten so eine sekundäre Finalitätsschicht, gestützt durch die BTC-Hashrate. |
| Account Abstraction | v1.2.0 (Interop) | Programmierbare Smart Accounts auf der Protokollebene (ähnlich ERC-4337). Drei Kontotypen: Multisig, soziale Wiederherstellung und sessionbasiert. Session-Keys mit granularen Berechtigungen und Ablauf, kontospezifische tägliche und transaktionsbezogene Ausgaberegeln und eingegrenzte Denom-Allowlists. Implementiert, aber derzeit auf beiden Netzwerken abgeschaltet (abstractaccount.enabled = false; prüfen Sie GET /qorechain/abstractaccount/v1/config). |
| MEV-Schutz | v1.2.0 (Interop) | FairBlock-Framework für Threshold Identity-Based Encryption (tIBE) für verschlüsselte Mempools, ausgelegt darauf, Transaktionen für Block-Proposer bis nach der Aufnahme undurchsichtig zu halten. Der FairBlockDecorator-Ante-Handler ist verdrahtet; die tIBE-Schwellenwertentschlüsselung wird nach der Bereitstellung der Schlüsselzeremonie aktiviert. Derzeit auf beiden Netzwerken deaktiviert (enabled = false). |
| Gas Abstraction | v1.2.0 (Interop) | Ausgelegt darauf, Nutzern die Zahlung von Gebühren in einem akzeptierten nicht-nativen Token zu ermöglichen; die Konfiguration listet ibc/USDC zu einem Kurs von 1:1 und ibc/ATOM zu 10:1. Es ist noch kein IBC-Kanal geöffnet, daher existiert auf den Netzwerken kein solcher Token, und Gebühren werden derzeit in QOR gezahlt. |
| 5-Lane-Priorisierung | v1.2.0 (Interop) | Lane-Definitionen (PQC, MEV, AI, Default, Free) existieren als Konfiguration, doch Blockplatz-Lanes werden vom Live-Mempool oder Proposal-Handler nicht durchgesetzt. |
| On-Chain-Liquidität (AMM) | v1.2.0 (Interop) | Der native automatisierte Market Maker (x/amm) stellt On-Chain-Liquiditätspools und Swaps auf der Protokollebene bereit. Das Modul ist live; es wurden noch keine Pools erstellt. |
| RDK-Rollups | v1.3.0 (Rollups) | Rollup Development Kit mit vier Settlement-Paradigmen (optimistic, zk, based, sovereign), fünf voreingestellten Profilen (defi, gaming, nft, enterprise, custom), nativem DA-Router mit SHAKE-256-Blob-Speicher und automatischem Pruning, Bank-Escrow-Lebenszyklus mit konfigurierbarer Erstellungs-Burn-Rate, EndBlocker-Auto-Finalisierung und PRISM-unterstützter Konfiguration über das Konsensmodul. Rollup-Fähigkeiten werden als Host-Chain-Framework bereitgestellt; auf den Live-Netzwerken wurde noch kein Rollup erstellt. |
| Chain-Lizenzierung | v1.3.0 (Rollups) | Das Modul x/license bietet protokollnative Chain-Lizenzierung. |
Funktionsstatus (Oktober 2026)
Im Oktober 2026 anhand der Live-Netzwerke überprüft. „Live“ bedeutet, dass die Fähigkeit auf Mainnet und Testnet aktiv ist; die obigen Beschreibungen geben an, was jede Funktion leisten soll.
| Fähigkeit | Status auf den Live-Netzwerken |
|---|---|
| Hybride ML-DSA-87- + secp256k1-Signaturen (Cosmos-Lane) | Live, erforderlich (hybrid_signature_mode = required) |
| EVM-Autorisierungsfenster | Live seit v3.2.0 |
| EVM-, CosmWasm-, SVM-Laufzeiten | EVM live; CosmWasm-Code-Upload und Instanziierung deaktiviert (Governance-Einstellung plus Schutzschalter); SVM-Transaktionspfad deaktiviert (Lesezugriffe funktionieren) |
| Burn-Engine und Gebührenaufteilung (37/30/20/10/3) | Live; nur der Gasgebühren-Burn-Kanal hat Burns verzeichnet |
Begrenzte Emission (x/inflation) | Live, fest 16.239 QOR pro Epoche bis zu einer Obergrenze von 114.285.714 QOR |
| Staking, Slashing, Governance | Live (Standardmodule; siehe Chain-Parameter) |
| Light-Node-Belohnungen | Belohnungsbuchhaltung live; Registrierung geschlossen |
AMM (x/amm) | Modul live, noch keine Pools erstellt |
PRISM (x/rlconsensus) | Nur Beobachtung — keine Policy geladen |
Triple-Pool-CPoS / QDRW (x/qca) | Implementiert, nicht angebunden an Blockproduktion, Belohnungen oder Auszählung |
xQORE (x/xqore) | Nur Buchhaltung — noch keine Sperr-/Entsperr-Transaktionen |
Smart Accounts / verknüpfte Wallets (x/abstractaccount) | Implementiert, abgeschaltet (enabled = false) |
Rollup Development Kit (x/rdk), Multilayer | Module live, noch keine Rollups oder Layer erstellt |
| Cross-Chain-Bridge, IBC, Babylon-Restaking | Ausstehend — alle 37 Chain-Konfigurationen pending, kein IBC-Kanal geöffnet, keine Restaking-Transaktionen |
| FairBlock-MEV-Schutz | Deaktiviert (enabled = false) |
EVM-Precompiles, qor_-JSON-RPC-Namespace | Nicht aktiv / nicht bereitgestellt (die Liste der aktiven Precompiles ist leer) |
Versionsverlauf
v1.0.0 — Genesis-Release
Etablierte das Kernprotokoll mit Post-Quanten-Kryptografie (Dilithium-5, ML-KEM-1024), der PRISM-On-Chain-Konsensschicht für Reinforcement Learning, der Triple-VM-Laufzeitumgebung (EVM, CosmWasm, SVM) mit Cross-VM-Nachrichtenübermittlung, der Tokenomics-Engine (Burn, xQORE, Emissionsmodul), der Validatorauswahl per Triple-Pool Composite PoS, der quadratischen QDRW-Governance und der KI-Transaktionsverarbeitungspipeline.
v1.1.0 — Sicherheitshärtungs-Release
Führte die Hybridsignatur-Architektur ein, die eine klassische secp256k1-Signatur (ECDSA) mit ML-DSA-87 paart, mit drei governance-gesteuerten Durchsetzungsmodi, eine SHAKE-256-Post-Quanten-Hash-Grundlage für den zukünftigen Merkle-Tree-Austausch sowie produktionsreife Schnittstellenspezifikationen für die TEE-Attestierung (SGX, TDX, SEV-SNP, ARM CCA) und die Koordination von Federated Learning (FedAvg, FedProx, SCAFFOLD).
v1.2.0 — Interoperabilitäts- und UX-Release
Fügte Cross-Chain-Konnektivität (8 IBC-Kanäle + 37 QCB-Konfigurationen für 36 externe Chains, derzeit im Testnet-/Pending-Status), BTC-Restaking über Babylon Protocol, Smart-Account-Abstraktion mit Session-Keys und sozialer Wiederherstellung, das FairBlock-MEV-Schutz-Framework, Multi-Token-Gas-Abstraktion, On-Chain-Liquidität (x/amm) und 5-Lane-Blockplatz-Priorisierung hinzu.
v1.3.0 — Rollup-Ökosystem-Release
Lieferte das Rollup Development Kit mit vier Settlement-Paradigmen (optimistic, zk, based, sovereign), fünf voreingestellten Bereitstellungsprofilen (defi, gaming, nft, enterprise, custom), einem nativen DA-Router, Bank-Escrow-Lebenszyklusverwaltung, EndBlocker-gesteuerter Auto-Finalisierung, PRISM-unterstützter Rollup-Konfiguration und Chain-Lizenzierung (x/license). Tiefe Integration mit dem Multilayer-Architekturmodul für die automatische Sidechain-Registrierung und Zustandsverankerung.
Verwandt
- Was ist QoreChain — der Plattformüberblick im Kontext.
- Tokenomics — das ökonomische Modell hinter QOR.
- Bridge-Architektur — Cross-Chain-Konnektivität und BTC-Restaking.
- Rollups-Überblick — das Rollup Development Kit und die Settlement-Paradigmen.