Dieses interdisziplinäre Forschungsprojekt untersucht Algorithmen zur effizienten, latenzarmen Aggregation und Validierung von Sensor- und Edge-Daten. Der primäre Fokus liegt auf der Entwicklung eines hochverfügbaren, blockkettenbasierten Validierungs-Layers für heterogene IoT-Infrastrukturen. Die aktuelle Phase konzentriert sich auf Performance-Metriken unter extrem hohem Transaktionsvolumen und die Gewährleistung der Konsistenz in fragmentierten Netzwerken. Das Ziel ist es, eine neue Architektur für Real-Time Data Trust zu schaffen.
Angesichts der exponentiellen Zunahme von Datenquellen im industriellen Internet der Dinge (IIoT) ist ein neuer Ansatz zur Sicherstellung der Datenintegrität und zur Reduktion von Kommunikations-Overhead unabdingbar. Projekt R-22 strebt die Etablierung eines Proof-of-Authority (PoA)-Mechanismus an, der speziell auf die Anforderungen von zeitkritischen, energieeffizienten Edge-Computing-Szenarien zugeschnitten ist. Die Forschung baut auf bestehenden Arbeiten im Bereich der Byzantinischen Fehlertoleranz (BFT) auf, um eine hohe Resilienz gegen fehlerhafte oder bösartige Knoten zu gewährleisten. Die Kernherausforderung liegt in der Minimierung des Overheads, der traditionell mit kryptografischen Konsensmechanismen verbunden ist.
Der DCL ist das Herzstück der Validierung. Er basiert auf einem modifizierten Raft-Algorithmus, der für asynchrone Netzwerkbedingungen optimiert wurde. Dies ermöglicht eine schnelle Leader-Wahl und eine effiziente Replikation über den Cluster. Der gesamte Datenfluss beginnt an den Edge-Knoten (Sensoren), wo Rohdaten voraggregiert und in Mikro-Transaktionen verpackt werden, um die Bandbreitennutzung zu minimieren. Die DCL-Implementierung in Go nutzt eine hochgradig optimierte Speichermethodik, um I/O-Latenzen zu reduzieren.
Diese Transaktionen werden dann über einen verschlüsselten TLS 1.3-Kanal an die Validierungsknoten gesendet. Jeder Validierungsknoten führt eine kryptografische Signaturprüfung und eine Semantik-Validierung der Nutzdaten durch, bevor sie in den nächsten Block aufgenommen werden. Die Effizienz dieses Prozesses ist entscheidend für die Gesamtlatenz des Systems, insbesondere unter Berücksichtigung der Komplexität der Semantik-Validierung.
Pseudocode für den Validierungsprozess:
FUNCTION validate_data(transaction, previous_block):
IF check_timestamp(transaction) AND verify_signature(transaction):
IF semantic_check(transaction.payload):
return PoA_SUCCESS
ELSE:
return SEMANTIC_FAIL
ELSE:
return AUTHENTICATION_FAIL
Die primäre Kommunikationsschnittstelle nutzt einen bidirektionalen WebSocket-Kanal, um einen persistenten, stromlinienförmigen und latenzarmen Datenaustausch zu ermöglichen. Dies ist entscheidend für die Real-Time-Anwendungen, die auf unserem DCL aufbauen. Die API (Version 2.0.1, veröffentlicht im Q3) erlaubt die Zustellung von Mikro-Transaktionen und den Abruf des aktuellen Ledger-Status mittels einer Read-Only-Abfrage. Die Schnittstelle wurde strengen Sicherheitsaudits unterzogen. Die API-Dokumentation (Swagger) ist für Partner über einen separaten, passwortgeschützten Endpunkt verfügbar.
Der Zustand (State) des dezentralen Ledgers wird in einem Merkle-Patricia-Trie gespeichert, um eine effiziente und kryptografisch prüfbare Speicherung zu gewährleisten. Jeder Block-Header enthält den Root-Hash dieses Tries, was die Light-Client-Verifizierung ermöglicht, ohne dass der gesamte Blockchain-Zustand heruntergeladen werden muss. Das Persistence-Layer verwendet eine LevelDB-Implementierung, die für hohe Schreib- und Lesezugriffe optimiert ist, wie sie bei der schnellen Blockvalidierung und -speicherung im PoA-Modell auftreten.
Die Datenbankstruktur ist in drei Hauptbereiche unterteilt: Block-Metadata, State-Data (Trie) und Wallets (für PoA-Autorisierungen). Dies gewährleistet eine klare Trennung der Verantwortlichkeiten und vereinfacht die Wartung und das Sharding in zukünftigen Iterationen des Projekts.
Wir verwenden statistische Verfahren, um die Datenkonsistenz und die Network Jitter zu messen. Ein wichtiger Metrik ist die Mean Time To Finality (MTTF) der Transaktionen, die derzeit bei durchschnittlich $280$ Millisekunden liegt. Dies übertrifft die Industriestandards in vielen Bereichen der Edge-Verarbeitung. Zusätzlich messen wir den Throughput (Transaktionen pro Sekunde) und die Memory Footprint pro Knoten.
Die statistische Abweichung (Standardabweichung) der Latenz wird aktiv durch ein dynamisches Rate-Limiting-Protokoll minimiert, das die Einspeisungsrate der Edge-Knoten bei Netzwerkkonvergenzfehlern drosselt, um eine Überlastung der Konsensknoten zu verhindern. Die Drosselung folgt einem adaptiven Backoff-Schema, das auf dem aktuellen Block-Produktionsintervall basiert.
Die Simulationen wurden auf einer verteilten Testinfrastruktur mit $N=100$ virtuellen Knoten durchgeführt, um die Replikation in einer realitätsnahen WAN-Umgebung zu testen. Die Netzwerklatenz zwischen den Knoten wurde mittels einer log-normalen Verteilung modelliert, um die Asymmetrien realer Internetverbindungen abzubilden. Die Skalierungsversuche konzentrierten sich darauf, den Punkt zu finden, an dem die Konsens-Latenz die 500ms-Grenze überschreitet, was als kritischer Punkt für Real-Time-Anwendungen definiert wurde.
Die Datenlast wurde kontinuierlich gesteigert, um die Effekte von Thundering Herd-Phänomenen auf den DCL zu beobachten. Die Ergebnisse zeigten, dass unser adaptiver Raft-Ansatz die Konsens-Kosten auch bei $15.000$ TPS unterhalb der kritischen Schwelle halten konnte.
Pseudocode für Python-Simulation Parameter-Set (Auszug):
NODES = 100
LATENCY_MODEL = 'lognormal'
TP_RATE_START = 5000 # Transaktionen pro Sekunde
TP_RATE_STEP = 500
CRITICAL_LATENCY = 500 # ms
Obwohl der DCL primär den Raft-Algorithmus verwendet, haben wir zusätzliche Schichten der Byzantinischen Fehlertoleranz implementiert, um die Widerstandsfähigkeit gegen *fehlerhafte* (Byzantinische) Knoten zu erhöhen. Insbesondere wird die Blockfinalität durch einen sekundären, leichteren BFT-Mechanismus bestätigt, der nur die Validierungsknoten mit PoA-Status betrifft. Dies verhindert das Forking der Kette, selbst wenn eine Minderheit der Knoten bösartig handelt.
Die Knoten-Recovery-Prozedur beinhaltet einen schnellen State-Sync-Mechanismus, der den Merkle-Root-Hash verwendet, um die Integrität der lokalen Kopie zu überprüfen und nur fehlende Trie-Blöcke effizient nachzuladen. Dies reduziert die Mean Time To Recovery (MTTR) erheblich.
Die theoretische Obergrenze für fehlertolerante Knoten in unserem System liegt bei $\lfloor(N-1)/3\rfloor$, wobei $N$ die Gesamtzahl der Validierungsknoten ist, was dem Standard der robusten BFT-Systeme entspricht.
Die umfangreichen Benchmarking-Tests für das vierte Quartal 2025 sind abgeschlossen und werden derzeit detailliert analysiert. Die Ergebnisse bestätigen eine lineare Skalierbarkeit des DCL bis zu $12.500$ Transaktionen pro Sekunde auf unserer Test-Infrastruktur mit minimalem Konsistenzverlust (< $0.001\%$). Die mittlere Energieeffizienz pro validierter Transaktion wurde um 15% im Vergleich zur vorherigen Iteration verbessert.
Eine Vorabversion des Papers zur *Verbesserung der Latenz durch Asynchrone Block Propagation* (ABLP) ist auf Anfrage verfügbar.
Geltungsbereich: Diese Datenschutzhinweise gelten für die Dokumentationsseite des Projekts R-22. Der Schutz Ihrer persönlichen Daten ist uns sehr wichtig.
Erfassung und Verarbeitung: Beim Besuch unserer Webseite werden temporär bestimmte technische Informationen erfasst, die Ihr Browser automatisch an unseren Server übermittelt (z.B. Browsertyp, Betriebssystem, Uhrzeit des Zugriffs). Diese Daten werden ausschließlich zur Sicherstellung des technischen Betriebs und zur Fehleranalyse gespeichert und nach spätestens 7 Tagen automatisch gelöscht. Eine Zusammenführung dieser Daten mit anderen Datenquellen wird nicht vorgenommen.
Cookies: Wir verwenden keine Cookies und keine externen Analysedienste (z.B. Google Analytics). Die Seite dient rein informativen Zwecken.
Ihre Rechte: Sie haben jederzeit das Recht auf Auskunft, Berichtigung, Löschung oder Einschränkung der Verarbeitung Ihrer Daten, soweit diese überhaupt erhoben werden. Kontaktieren Sie uns hierzu über die unten angegebene E-Mail-Adresse.
Verantwortlich für den Inhalt:
Dr. E. Schmidt
(Forschungsleitung Projekt R-22)
Kontakt für inhaltliche Fragen:
E-Mail: e.schmidt.r22@sayanetworks.eu
Hinweis zur Haftung:
Trotz sorgfältiger inhaltlicher Kontrolle übernehmen wir keine Haftung für die Inhalte externer Links. Für den Inhalt der verlinkten Seiten sind ausschließlich deren Betreiber verantwortlich.
Projektleitung: Dr. E. Schmidt
E-Mail: e.schmidt.r22@sayanetworks.eu
Technische Anfragen: tech-r22@sayanetworks.eu
Bitte beachten Sie: Es können derzeit nur Anfragen von akademischen oder industriellen Forschungspartnern beantwortet werden.