#newt $NEWT Auf der Ethereum#ETH -Blockchain, einer öffentlichen Ledger-Infrastruktur, in der jeder Zentimeter Boden kostbar ist, ist Speicherplatz so teuer wie die Immobilienpreise am Pekinger zweiten Ring. Wenn Ihr Compliance-Netzwerk bei jeder einzelnen Risiko- und Freigabeprüfung die Klartext-Signaturen von tausend Knoten großspurig direkt in die Blockchain schreiben müsste, könnten die enormen Gas-Kosten jedes DeFi-Projekt in nennenswerter Größe sofort in den Ruin treiben. Eine schöne Dezentralisierung nützt wenig, wenn sich das Projekt die Rechnung nicht leisten kann; das ist im Grunde nichts anderes als blanker Missbrauch.
Um dieses Problem zu lösen, hat @NewtonProtocol auf der Basisschicht die kryptografische Kompressionsmagie des BLS-Autorisierungsprotokolls eingesetzt.
Es erlaubt Aggregatoren, hunderte oder sogar tausende unterschiedliche Knotensignaturen für dieselbe Richtlinie off-chain über eine homomorphe Abbildung nahtlos zu „verschmelzen“ und in eine einzige, nur wenige Dutzend Bytes große Aggregatsignatur zu verwandeln. Bei der abschließenden Verifikation durch den Smart Contract on-chain bleibt der Rechenaufwand und Speicherbedarf konstant auf dem minimalen Niveau von $O(1)$, ganz gleich, ob hinter der Abstimmung hundert oder zehntausend Knoten stehen. Das ist, als würde man einen ganzen Lkw voller Bücher in einen „unsichtbaren Barcode“ komprimieren und die On-Chain-Speicherkosten direkt auf den absoluten Tiefstpreis senken.
Aber ich muss hier einen Dämpfer geben: Alles Gas, das on-chain eingespart wird, wird off-chain zum „Rechenballast“ des Aggregators. Warum sage ich das?
Die homomorphe Aggregation von zehntausenden asymmetrischen Signaturen off-chain ist eine extrem CPU- und speicherintensive Aufgabe. Wenn die Hardware des Aggregators schwach aufgestellt ist und plötzlich eine Hochphase mit massiven Transaktionen eintritt, kann sich die Latenz der off-chain-Signaturaggregation von wenigen Millisekunden auf mehrere Sekunden verlängern. Für Netzwerke, die auf Subsekunden-Streaming-Konsens setzen, wird der Aggregator selbst dann zum dicksten Engpass in der gesamten Performance-Kette.
Deshalb ist meine Ansicht, dass das Frontend-System beim Anschluss an das Newton-Strategie-Gateway unbedingt eine „aggregatorlastbewusste Gesundheitsprüfung (Aggregator Health Check)“ einführen muss. Sobald erkannt wird, dass die BLS-Aggregationszeit des aktuellen Hauptaggregators stufenweise ansteigt, muss das System in der Lage sein, Verifizierungsanfragen in Sekundenschnelle auf ein Backup-Knoten mit leistungsstarker Hardware umzuleiten.
Der Preis für kompromissloses Sparen on-chain ist, dass man off-chain eine echte „Rechenmonster“-Infrastruktur braucht, die jederzeit die volle Last schultern kann.
Um dieses Problem zu lösen, hat @NewtonProtocol auf der Basisschicht die kryptografische Kompressionsmagie des BLS-Autorisierungsprotokolls eingesetzt.
Es erlaubt Aggregatoren, hunderte oder sogar tausende unterschiedliche Knotensignaturen für dieselbe Richtlinie off-chain über eine homomorphe Abbildung nahtlos zu „verschmelzen“ und in eine einzige, nur wenige Dutzend Bytes große Aggregatsignatur zu verwandeln. Bei der abschließenden Verifikation durch den Smart Contract on-chain bleibt der Rechenaufwand und Speicherbedarf konstant auf dem minimalen Niveau von $O(1)$, ganz gleich, ob hinter der Abstimmung hundert oder zehntausend Knoten stehen. Das ist, als würde man einen ganzen Lkw voller Bücher in einen „unsichtbaren Barcode“ komprimieren und die On-Chain-Speicherkosten direkt auf den absoluten Tiefstpreis senken.
Aber ich muss hier einen Dämpfer geben: Alles Gas, das on-chain eingespart wird, wird off-chain zum „Rechenballast“ des Aggregators. Warum sage ich das?
Die homomorphe Aggregation von zehntausenden asymmetrischen Signaturen off-chain ist eine extrem CPU- und speicherintensive Aufgabe. Wenn die Hardware des Aggregators schwach aufgestellt ist und plötzlich eine Hochphase mit massiven Transaktionen eintritt, kann sich die Latenz der off-chain-Signaturaggregation von wenigen Millisekunden auf mehrere Sekunden verlängern. Für Netzwerke, die auf Subsekunden-Streaming-Konsens setzen, wird der Aggregator selbst dann zum dicksten Engpass in der gesamten Performance-Kette.
Deshalb ist meine Ansicht, dass das Frontend-System beim Anschluss an das Newton-Strategie-Gateway unbedingt eine „aggregatorlastbewusste Gesundheitsprüfung (Aggregator Health Check)“ einführen muss. Sobald erkannt wird, dass die BLS-Aggregationszeit des aktuellen Hauptaggregators stufenweise ansteigt, muss das System in der Lage sein, Verifizierungsanfragen in Sekundenschnelle auf ein Backup-Knoten mit leistungsstarker Hardware umzuleiten.
Der Preis für kompromissloses Sparen on-chain ist, dass man off-chain eine echte „Rechenmonster“-Infrastruktur braucht, die jederzeit die volle Last schultern kann.