Lass dich nicht von so großen Narrativen wie „Übernahme von Ethereum: ein Sicherheit-auf-Einhundert-Milliarden-Niveau Konsens“ indoktrinieren. Wenn ich irgendein Protokoll zerlege, ist meine grundlegende Logik immer „Schutz zuerst“. In letzter Zeit habe ich die Sicherheitsarchitektur von @NewtonProtocol ($NEWT ) tiefgehend untersucht: Sie hängt das AVS (Active Validation Service)-Knoten-Netzwerk direkt an EigenLayer. Auf den ersten Blick spart dieser Trick „Huhn und Eier“ scheinbar die Millionenkosten für einen Cold-Start-Validierer-Set. Doch wenn man diese schicke Fassade aufreißt und nach innen schaut, liegt darunter eine äußerst zerstörerische Kettenbombe.
EigenLayer ist im Kern ein komplexes System aus Liquidität und Risiko-Überlagerung. Newtons Policy Enforcement ist in hohem Maße darauf angewiesen, dass diese Restaking-Knoten Konsens liefern. Im Vergleich zu nativen Public Chains mit einer eigenen, unabhängigen Konsensschicht ist Newtons Sicherheitsbarriere stark nicht-unabhängig. Zuerst gibt es den tödlichen Effekt der „Rechenleistung-Flut und -Ebbe“. In der aktuellen Praxis bedienen Operatoren meist gleichzeitig mehrere AVS. Wenn ein besonders beliebtes AVS (z. B. ein Projekt mit hohen Renditeerwartungen) plötzlich die Token-Emissionen stark anzieht, kippen gewinnorientierte Knoten augenblicklich ihre Hardware-Ressourcen. In einer echten codebasierten Überwachung habe ich in einer ähnlichen Architektur schon gesehen, dass es aufgrund von Engpässen an Ressourcen im gleichen Ökosystem zu massiven Verzögerungen bei RPC-Endpunkten kommt und die länderübergreifende Konsensvalidierung direkt um über 200% in die Höhe schießt. Newton hat aktuell keinerlei Mechanismen, die diese passive „Rechenleistung wird abgezogen“-Situation isolieren.
Noch schlimmer als die Latenz ist die Slashing-(Strafabzugs)-Übertragung über Protokolle hinweg. In einem Multi-Stake-Modell: Wenn ein Kern-Operator von Newton in einem anderen minderwertigen AVS aufgrund von Fehlkonfiguration oder böswilligem Verhalten Slashing auslöst, wird die zugrunde liegende ETH dieses Operators zwangsweise einbehalten. Das führt dazu, dass das ökonomische Sicherheitsgewicht dieses Knotens im Newton-Netzwerk schlagartig verdampft und ohne jede Vorwarnung die Schwelle gegen Fehlverhalten im gesamten Newton-System senkt. $SYN
Wenn man die Attestation-On-Chain-Daten des aktuellen Beta-Mainnets von Newton betrachtet, wirkt die Erfolgsquote bei der Validierung zwar hübsch geschönt, aber die Knotenmacht ist stark konzentriert. Sobald ein führender Operator von EigenLayer aufgrund externer Gründe „boomt“ (explodiert/ausfällt) oder das Netzwerk verlässt, droht Newtons Konsensaggregation unkontrollierbar in die Länge gezogen zu werden.
Kurzfristig auf EigenLayer zu setzen ist eine clevere GTM-Strategie, aber langfristig gilt: Wenn Newton nicht so schnell wie möglich die Permissionless-Phase vorantreibt, nicht-EigenLayer-nahes heterogenes, unabhängiges Validatoren-Set einführt und mehrkettenfähige Sicherheitsredundanz aufbaut, dann ist das angepriesene „Safe to stay“ nur ein jederzeit einlösbarer, nicht gedeckter Schein.
#Newt $BTC
EigenLayer ist im Kern ein komplexes System aus Liquidität und Risiko-Überlagerung. Newtons Policy Enforcement ist in hohem Maße darauf angewiesen, dass diese Restaking-Knoten Konsens liefern. Im Vergleich zu nativen Public Chains mit einer eigenen, unabhängigen Konsensschicht ist Newtons Sicherheitsbarriere stark nicht-unabhängig. Zuerst gibt es den tödlichen Effekt der „Rechenleistung-Flut und -Ebbe“. In der aktuellen Praxis bedienen Operatoren meist gleichzeitig mehrere AVS. Wenn ein besonders beliebtes AVS (z. B. ein Projekt mit hohen Renditeerwartungen) plötzlich die Token-Emissionen stark anzieht, kippen gewinnorientierte Knoten augenblicklich ihre Hardware-Ressourcen. In einer echten codebasierten Überwachung habe ich in einer ähnlichen Architektur schon gesehen, dass es aufgrund von Engpässen an Ressourcen im gleichen Ökosystem zu massiven Verzögerungen bei RPC-Endpunkten kommt und die länderübergreifende Konsensvalidierung direkt um über 200% in die Höhe schießt. Newton hat aktuell keinerlei Mechanismen, die diese passive „Rechenleistung wird abgezogen“-Situation isolieren.
Noch schlimmer als die Latenz ist die Slashing-(Strafabzugs)-Übertragung über Protokolle hinweg. In einem Multi-Stake-Modell: Wenn ein Kern-Operator von Newton in einem anderen minderwertigen AVS aufgrund von Fehlkonfiguration oder böswilligem Verhalten Slashing auslöst, wird die zugrunde liegende ETH dieses Operators zwangsweise einbehalten. Das führt dazu, dass das ökonomische Sicherheitsgewicht dieses Knotens im Newton-Netzwerk schlagartig verdampft und ohne jede Vorwarnung die Schwelle gegen Fehlverhalten im gesamten Newton-System senkt. $SYN
Wenn man die Attestation-On-Chain-Daten des aktuellen Beta-Mainnets von Newton betrachtet, wirkt die Erfolgsquote bei der Validierung zwar hübsch geschönt, aber die Knotenmacht ist stark konzentriert. Sobald ein führender Operator von EigenLayer aufgrund externer Gründe „boomt“ (explodiert/ausfällt) oder das Netzwerk verlässt, droht Newtons Konsensaggregation unkontrollierbar in die Länge gezogen zu werden.
Kurzfristig auf EigenLayer zu setzen ist eine clevere GTM-Strategie, aber langfristig gilt: Wenn Newton nicht so schnell wie möglich die Permissionless-Phase vorantreibt, nicht-EigenLayer-nahes heterogenes, unabhängiges Validatoren-Set einführt und mehrkettenfähige Sicherheitsredundanz aufbaut, dann ist das angepriesene „Safe to stay“ nur ein jederzeit einlösbarer, nicht gedeckter Schein.
#Newt $BTC