Mit der Erweiterung und Reifung des Blockchain-Ökosystems entstehen eine Vielzahl unterschiedlicher Netzwerkarchitekturen. In den letzten Jahren haben sich einfache Konsensnetzwerke mit leeren Blöcken zu komplexen Systemen entwickelt, die auf Infrastrukturebenen basieren, um Entwicklern und Benutzern gleichermaßen ein funktionierendes und interoperables Erlebnis zu ermöglichen.

Auf dem Weg zur Modularität

Ein Trend hin zu einer modularen Architektur ist sowohl in anwendungsspezifischen Blockchain-Ökosystemen wie Cosmos als auch in universellen Smart-Contract-Plattformen wie Ethereum zu beobachten. Erfolgreiche Anwendungen auf Ethereum sind in der Vergangenheit auf eine Vielzahl zusätzlicher Middlewares angewiesen, um nützliche Produkte und ein hervorragendes Benutzererlebnis bereitzustellen.

Beispiele für solche Middlewares sind Orakel (z Chainlink), Automatisierung (z. B Gelato), Indexierungsnetzwerke (z. B The Graph) sowie Interoperabilitätsprotokolle (z. B Wurmloch). Solche Tools haben die Form eines separaten Protokolls mit einem eigenen Vertrauensnetzwerk: einer Reihe von Regeln, Operatoren und in den meisten Fällen Token-Ökonomie – oder werden sogar zentral bereitgestellt. Ein Beispiel für eine Kryptoanwendung, die sich für den Produktmarkt eignet, sind DeFi-Geldmärkte wie Aave:

Eine allgemeine Darstellung des Liquidationsablaufs des Aave-Kreditprotokolls; ein beispielhaftes Zusammenspiel verschiedener Stapel, die miteinander interagieren.

Der Weg zum Restaking

Zusätzlich zur Middleware können modulare Architekturen auch dazu beitragen, den Durchsatz von Blockchain-Systemen zu skalieren, indem sie die Kernfunktionalität auf verschiedene Schichten aufteilen oder einfach durch horizontale Skalierung (d. h Einführung weiterer Ketten/Rollups). Dieser Ansatz steht im Gegensatz zur ursprünglichen „Weltcomputer“-Vision einer einzigen, zusammensetzbaren Zustandsmaschine, die alles verwaltet. Derzeit verfolgt das Solana-Ökosystem überwiegend ein integriertes, monolithisches Design, das eine maximale Skalierung durch verschiedene Optimierungen auf Hardware- und Softwareebene anstrebt.

Monolithische versus modulare Architekturen.

Eines der Kernprobleme eines modularen Blockchain-Paradigmas besteht darin, dass es am Ende viele separate Vertrauensnetzwerke mit eigenen Tokens und Sicherheitsannahmen gibt. Dies stellt insbesondere ein Problem dar, da ein Angreifer, um eine Anwendung zu kompromittieren, oft nur das Netzwerk mit der geringsten wirtschaftlichen Sicherheit kompromittieren müsste.

Darüber hinaus sind die Komplexität des Bootstrappings eines neuen Vertrauensnetzwerks und die Interoperabilität zwischen ihnen Probleme, die sich auf die Entwickler- und Benutzererfahrung im modularen Paradigma auswirken. Daher tauchen mittlerweile Modelle auf, die es Entwicklern ermöglichen sollen, die Betreiber eines anderen Netzwerks gegen eine Gebührenbeteiligung und oft auch andere Anreize zu nutzen. Der Gestaltungsraum solcher Shared-Security-Modelle ist groß und geht auf frühe Sharding-Designs in Ethereum und das Polkadot-Parachain-Auktionsmodell zurück. Zu den neueren Beispielen gehören das von Eigenlayer empfohlene Restaking, Cosmos-basierte Konzepte von Interchain Security und Mesh Security, Avalanche-Subnetze sowie Shared Sequencing.

Auf der tiefsten Ebene sind diese Ansätze vergleichbar und zielen darauf ab, ein ähnliches Ergebnis zu erzielen, nämlich die Betriebskosten zu senken und die Sicherheit für Anwendungsentwickler zu erhöhen, indem der Arbeitsumfang erweitert und zusätzliche Verpflichtungen hinzugefügt werden, die von den Knotenbetreibern zur Genehmigung erforderlich sind. Im Großen und Ganzen gibt es zwei Möglichkeiten, wie Protokolle zusätzliche Arbeit an Betreiber delegieren können:

Gezwungen

Ein Protokoll kann von Betreibern verlangen, zusätzliche Infrastruktur zu betreiben (z. B zusätzliche Ausführungsschichten oder Middlewares), um teilnehmen zu können. In diesem Artikel werden solche zusätzlichen Infrastrukturen als „Subnetzwerke“ bezeichnet. Ein frühes praktisches Beispiel für dieses Muster im Kryptoraum war das Terra-Netzwerk, bei dem Validatoren zusätzlich zu den bereits vorhandenen Konsens-Binärdateien zusätzliche Oracle-Middleware-Binärdateien ausführen mussten. Dies ist auch der Ansatz, der bei der ersten Implementierung von Interchain (Replicated) Security verfolgt wird, bei der – nach einer erfolgreichen Governance-Abstimmung – der gesamte Validatorsatz einer Cosmos-Kette (mit einigen Einschränkungen) ausgeführt werden muss und sich für zusätzliche drastische Strafen bezüglich einer separaten Kette entscheiden muss sogenannte Verbraucherkette. Erzwungene Ansätze verringern die Flexibilität und erhöhen die Infrastrukturkosten sowie die Belastung für Knotenbetreiber. Sie bieten auch Vorteile für die Interoperabilität zwischen Teilnetzwerken und dienen als Wertsteigerungsmechanismus für den Hauptnetzwerk-Token, weshalb sie ein beliebtes Design sind.

Opt-in

Das Protokoll kann es Knotenbetreibern ermöglichen, sich für bestimmte Subnetzwerke zu entscheiden oder bestimmte Rollen zu definieren, für die sie sich entscheiden können. Mit dieser Methode bleibt die Flexibilität für Knotenbetreiber erhalten, was Effizienzsteigerungen und eine breitere Beteiligung ermöglicht, was die Dezentralisierung erhöht. Andererseits gibt es Auswirkungen auf die Interoperabilität von Teilnetzen und Sicherheitsannahmen im Allgemeinen. Das Eigenlayer-Restaking ist das Paradebeispiel für ein Opt-in-Design, das darauf abzielt, die von Ethereum-Knotenbetreibern bereitgestellte Funktionalität zu erweitern.

Visualisierung der verschiedenen Ansätze der Arbeitsaggregation. Bei erzwungenen Modellen müssen alle drei Betreiber die Infrastruktur für Netzwerk A und B betreiben, um Belohnungen zu erhalten. Bei einem Opt-in-Design wie dem Restaking wählen die Betreiber die Netzwerke/Rollen aus, die sie unterstützen. In diesem Beispiel entscheidet sich Betreiber 1 für Netzwerk B&C, während sich Betreiber 2 für Netzwerk A&B entscheidet (AVS in der Eigenlayer-Terminologie).

Die Betreiberperspektive

Wie wir gesehen haben, hat das entstehende modulare Ökosystem schnelle Innovationen ermöglicht und leistungsstarke Anwendungen in den Kryptoraum gebracht. Dieses expandierende Ökosystem führt zu komplexen Netzwerktopologien, die den Infrastrukturanbietern verschiedene Kompromisse mit sich bringen, da sie auf der Grundlage ihrer verfügbaren Ressourcen und netzwerkspezifischer Kosten- und Risiko-Ertrags-Berechnungen entscheiden müssen, welche Netzwerke sie unterstützen.

Im Folgenden werde ich die Kompromisse, die Shared-Security-Modellen innewohnen, aus der Perspektive zweier Arten von Infrastrukturbetreibern untersuchen: Solo-Staker und professionelle Staking-Anbieter.

Die Solo-Staker-Ansicht

Solo-Staker sind Personen, die sich an der Sicherung der von ihnen unterstützten Netzwerke beteiligen möchten, indem sie die Infrastruktur in ihrem eigenen Setup und überwiegend mit ihren eigenen Token betreiben.

Die Solo-Stakeholder-Sicht auf Shared-Security-Modelle.

Die Sicht des Absteckanbieters

Bei professionellen Staking-Anbietern handelt es sich um eingetragene, gewinnorientierte Unternehmen, die die Infrastruktur für eine Vielzahl von Proof-of-Stake-Netzwerken betreiben und sich auf Delegationen von Token-Inhabern wie Stiftungen, institutionellen Anlegern und privaten Token-Inhabern sowie Aggregatoren wie Liquid Staking-Protokollen stützen .

Die Sicht des Absteckanbieters auf gemeinsame Sicherheitsmodelle.

Abschluss

Um eine Fragmentierung der Sicherheit zu vermeiden, hat das Krypto-Ökosystem verschiedene Modelle für die gemeinsame Nutzung von Sicherheit zwischen Blockchain-Netzwerken konzipiert. Opt-in-Modelle wie Restating bieten Flexibilität, indem sie es den Betreibern ermöglichen, sich zu spezialisieren und detailliertere wirtschaftliche Entscheidungen zu treffen, während bei erzwungenen Modellen das Netzwerk als Ganzes Entscheidungen für alle zugrunde liegenden Betreiber trifft.

Diese Flexibilität kann einerseits dazu beitragen, ein vielfältigeres und dezentraleres Ökosystem zu schaffen, da die Teilnahme kleinerer Betreiber möglich wird und andererseits größere Betreiber in der Lage sind, differenzierte Absteckprodukte auf der Grundlage ihrer Subnetzwerkkuration bereitzustellen .

Schließlich könnten Liquid (Re)Stake-Protokolle und andere Aggregatoren in Zukunft eine koordinierende Rolle bei der Zuweisung von Arbeit an Betreiber spielen, um den Token-Inhabern ein optimales Benutzererlebnis und risikobereinigte Renditen zu bieten, indem sie die Komplexität von Teilnetzwerken und Betreibern abstrahieren Auswahl.

Haftungsausschluss:

1. Dieser Artikel wurde von [Mirror] nachgedruckt. Alle Urheberrechte liegen beim ursprünglichen Autor [Felix Lutsch]. Wenn Sie Einwände gegen diesen Nachdruck haben, wenden Sie sich bitte an das Gate Learn-Team, das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verbreiten oder Plagiieren der übersetzten Artikel verboten.