Chain Abstraction mit NEAR – Wie Chain Signatures Cross-Chain vereinfachen

Wer mehrere Blockchains nutzt, bewegt Assets, verwaltet verschiedene Wallets und muss je nach Netzwerk andere Signatur- und Ausführungsmodelle verstehen. Chain Abstraction versucht, diese Brüche zu reduzieren: Anwendungen sollen sich wie eine einzige Oberfläche anfühlen, obwohl im Hintergrund Ethereum, Bitcoin oder andere Netzwerke angesprochen werden. NEAR setzt dafür auf ein Konto-zentriertes Design und auf Chain Signatures, mit denen ein NEAR-Konto Aktionen auf fremden Chains auslösen kann.

Was bedeutet Chain Abstraction technisch?

Chain Abstraction ist keine einzelne Funktion, sondern ein Architekturprinzip. Die Kernaussage lautet: Nutzerkonten, Signaturen und Ausführung müssen nicht zwingend auf derselben Blockchain liegen, solange das Sicherheitsmodell nachvollziehbar bleibt.

In klassischen Krypto-Setups ist jedes Netzwerk eine eigene Insel. Für Ethereum wird meist eine EVM-Wallet verwendet, für Bitcoin ein anderes Schlüsselschema, für Solana wieder ein anderes Transaktionsmodell. Das führt zu mehreren Seed-Phrases, unterschiedlichen Gas-Token und vielen Brücken- oder Wallet-Schritten. Chain Abstraction will diese Unterschiede nicht abschaffen, sondern in eine gemeinsame Bedien- und Signaturschicht verlagern.

Technisch besteht der Ansatz oft aus drei Bausteinen: einem einheitlichen Nutzerkonto, einer Middleware für Routing und Ausführung sowie Mechanismen, um auf Ziel-Chains gültige Signaturen oder Nachrichten zu erzeugen. Genau an dieser Stelle wird die Architektur spannend. Denn die eigentliche Frage lautet nicht nur, ob eine App mehrere Chains unterstützt, sondern wer für welchen Schritt kryptografisch verantwortlich ist.

Anzeige

NEAR passt gut zu diesem Modell, weil das Protokoll von Anfang an ein flexibles Account-System besitzt. Im Unterschied zu reinen Adressmodellen können NEAR-Konten Berechtigungen und Zugriffsrechte differenzierter abbilden. Das macht es leichter, Anwendungen zu bauen, die im Hintergrund Aktionen vorbereiten, delegieren oder über mehrere Netzwerke orchestrieren.

• Ein Nutzer interagiert mit einer Anwendung über ein einziges Konto statt über mehrere Wallet-Kontexte.
• Die Anwendung wählt im Hintergrund das passende Zielnetzwerk und das nötige Ausführungsformat.
• Signaturen müssen auf der Ziel-Chain technisch akzeptiert werden, auch wenn der Auslöser aus einer anderen Umgebung stammt.
• Gebühren, Nonces und Zustandsübergänge bleiben netzwerkspezifisch und verschwinden nicht vollständig.
• Die größte Herausforderung liegt nicht in der Oberfläche, sondern im Sicherheitsmodell zwischen Konto, Relayer und Ziel-Chain.

Wie funktionieren Chain Signatures bei NEAR?

Chain Signatures erlauben es, aus einem NEAR-Konto heraus kryptografisch verwertbare Signaturen für andere Netzwerke abzuleiten. Die Kernaussage ist: Nicht das fremde Netzwerk wird nach NEAR gespiegelt, sondern NEAR dient als Steuer- und Autorisierungsschicht für externe Aktionen.

Das Grundprinzip erinnert an verteilte Schlüsselverwaltung. Statt dass ein privater Schlüssel für eine Ziel-Chain in einer einzelnen Wallet liegt, kann die Signaturerzeugung über ein verteiltes Netzwerk von Teilnehmern koordiniert werden. Häufig fällt in diesem Zusammenhang der Begriff MPC, also Multi-Party Computation: Mehrere Parteien erzeugen gemeinsam ein Ergebnis, ohne den vollständigen geheimen Schlüssel an einer Stelle offenzulegen.

Für Anwendungen bedeutet das: Ein Nutzer autorisiert auf NEAR eine bestimmte Aktion. Das Netzwerk oder eine spezialisierte Signaturschicht leitet daraus eine Signatur für die Ziel-Chain ab, etwa für eine Bitcoin- oder EVM-kompatible Transaktion. Die Ziel-Chain sieht dann keine „magische Cross-Chain-Aktion“, sondern eine formal gültige Signatur im Format, das sie ohnehin akzeptiert.

Diese Trennung ist wichtig, weil sie sich deutlich von klassischen Cross-Chain-Bridges unterscheidet. Eine Bridge verschiebt typischerweise Vermögenswerte über Lock-and-Mint- oder Burn-and-Release-Modelle und benötigt dafür Validatoren, Light-Client-Logik oder Custody-ähnliche Konstruktionen. Chain Signatures zielen dagegen auf Steuerung und Autorisierung: Eine Anwendung soll auf mehreren Chains handeln können, ohne dass der Nutzer jede Schlüsselwelt separat bedienen muss.

Praktisch läuft ein typischer Ablauf in mehreren Schritten ab:

• Eine App erstellt eine gewünschte Zielaktion, zum Beispiel das Versenden eines Tokens auf einer EVM-Chain.
• Der Nutzer bestätigt diese Aktion mit seinem NEAR-Konto und dessen Berechtigungen.
• Ein verteiltes Signatursystem berechnet die passende Signatur für das Zielnetzwerk.
• Ein Relayer oder Ausführungsdienst übermittelt die fertig signierte Nachricht an die Ziel-Chain.
• Die Ziel-Chain validiert die Signatur nach ihren eigenen Regeln und führt die Transaktion aus.

Der Vorteil liegt in der Vereinheitlichung der Bedienung. Die Grenze liegt darin, dass jede Ziel-Chain weiterhin ihre eigenen Regeln für Fees, Mempool, Finalität und Zustandsänderungen behält.

Warum ist das etwas anderes als eine Bridge oder ein Rollup?

NEARs Ansatz zur Kettenabstraktion ist weder ein Rollup noch eine klassische Bridge. Die Kernaussage lautet: Es geht primär um Benutzer- und Signaturschichten, nicht um das Verschieben eines gesamten Ausführungszustands auf eine andere Ebene.

Anzeige

Ein Rollup bündelt viele Transaktionen und veröffentlicht Daten oder Beweise auf einer Basisschicht wie Ethereum. Das Sicherheitsmodell dreht sich um Datenverfügbarkeit, Fraud Proofs oder Validity Proofs. Wer dafür ein Gegenmodell sucht, kann bei optimistischen Rollups gut sehen, wie eng Ausführung und Ethereum-Sicherheit miteinander verknüpft sind.

Eine Bridge verbindet dagegen zwei Zustandsräume. Sie muss nachweisen, dass auf Chain A etwas passiert ist, damit auf Chain B ein entsprechender Effekt ausgelöst wird. Dieser Nachweis ist sicherheitstechnisch anspruchsvoll, weil zwischen Nachrichtenweitergabe, Finalität und möglicher Validator-Kollusion sauber unterschieden werden muss. Genau deshalb sind Bridge-Designs historisch ein häufiger Angriffsvektor gewesen.

Chain Abstraction mit Chain Signatures umgeht einen Teil dieses Problems, weil nicht zwingend ein fremder Zustand „gespiegelt“ werden muss. Stattdessen wird eine Transaktion direkt im nativen Format der Ziel-Chain signiert und dort eingereicht. Das reduziert aber nicht automatisch alle Risiken. Die Vertrauensannahme verschiebt sich nur: entscheidend ist dann, wie robust die verteilte Signaturschicht, ihre Teilnehmer und die Autorisierungslogik auf NEAR konstruiert sind.

Damit liegt der Ansatz näher an Wallet-Infrastruktur, Account Abstraction und Middleware als an einem Layer-2. Wer das Zusammenspiel aus Nutzerkonto und flexiblen Berechtigungen aus Ethereum-Perspektive betrachtet, findet Parallelen zu Account-Abstraction-Konzepten, auch wenn die konkrete Umsetzung und das Sicherheitsmodell unterschiedlich ausfallen.

Welche Rolle spielt das NEAR-Kontomodell?

Das NEAR-Kontomodell ist ein wesentlicher Baustein für Chain Abstraction, weil es feinere Berechtigungen als viele einfache Adresssysteme erlaubt. Die Kernaussage ist: Ein flexibles Konto macht es leichter, Signaturrechte, Anwendungslogik und Nutzerfreigaben voneinander zu trennen.

NEAR arbeitet mit menschenlesbaren Konten und unterstützt unterschiedliche Schlüssel mit unterschiedlichen Rechten. Damit kann ein Konto nicht nur vollständig kontrolliert werden, sondern auch auf bestimmte Aktionen oder Verträge begrenzte Zugänge vergeben. Für Anwendungen ist das praktisch, weil nicht jede Interaktion dieselbe Reichweite haben muss.

Dieses Modell ergänzt die Idee der Kettenabstraktion gut. Eine App kann etwa das Recht erhalten, bestimmte vorbereitete Aktionen anzustoßen, ohne dass sie den kompletten Zugriff auf alle Vermögenswerte oder Funktionen eines Kontos benötigt. Aus Sicherheits- und UX-Sicht ist das deutlich sinnvoller als ein pauschales „Alles oder nichts“.

Hinzu kommt, dass NEAR seit Langem auf nutzerfreundliche Onboarding-Mechaniken setzt. Solche Konzepte werden erst dann wirklich relevant, wenn Anwendungen nicht nur für Krypto-Native gedacht sind, sondern für Nutzer:innen, die nicht zwischen RPC-Endpunkten, Gas-Token und unterschiedlichen Wallet-Standards unterscheiden wollen. Dass ähnliche Ziele auch auf anderen Plattformen verfolgt werden, zeigt etwa menschenlesbare Adresslogik, die zwar ein anderes Problem löst, aber dieselbe Reibung an der Oberfläche adressiert.

Ein sauberes Kontomodell ersetzt jedoch keine solide Protokollsicherheit. Wenn Berechtigungen falsch gesetzt sind, Relayer zu viele Freiheiten bekommen oder Zielaktionen zu allgemein formuliert werden, entsteht eine neue Angriffsfläche. Gerade weil Chain Abstraction Bequemlichkeit verspricht, muss die Begrenzung einzelner Rechte besonders sorgfältig gestaltet sein.

Wo liegen Nutzen und Grenzen für Apps und Nutzer?

Der Hauptnutzen von Chain Abstraction liegt in weniger Fragmentierung. Die Kernaussage lautet: Für Multichain-Anwendungen kann es technisch sinnvoller sein, Interaktionen zu bündeln, statt Nutzer durch jede einzelne Chain-Logik zu schicken.

Das ist besonders interessant für Wallets, Zahlungsflüsse, Onboarding-Prozesse und Anwendungen mit mehreren Ziel-Chains. Ein Nutzer könnte in einer Oberfläche eine Aktion starten, während die Anwendung im Hintergrund auswählt, ob sie auf Ethereum, einer EVM-Sidechain oder sogar auf Bitcoin ausgeführt werden soll. Solche Modelle können die Einstiegshürde deutlich senken, weil weniger Schlüssel, weniger manuelle Netzwerkwechsel und weniger Brückenschritte notwendig sind.

Für Entwickler:innen bringt das aber auch neue Komplexität. Eine App muss nicht nur Verträge schreiben, sondern auch Zuständigkeiten definieren: Was wird auf NEAR autorisiert? Wer baut die Zieltransaktion? Wer reicht sie ein? Wie werden Gebühren bezahlt? Und was passiert, wenn eine Ziel-Chain überlastet ist oder eine Transaktion zwar signiert, aber nicht zeitnah inkludiert wird?

Anzeige

Aus dieser Perspektive ist Kettenabstraktion eher Infrastruktur als Endprodukt. Sie ist dann nützlich, wenn verschiedene Netzwerke in einer Anwendung wirklich koordiniert werden müssen. Für rein lokale Anwendungen auf einer einzelnen Chain kann der zusätzliche Architekturaufwand dagegen unnötig sein. Ähnlich wie bei modularen Ansätzen in Datenverfügbarkeits-Designs gilt: Mehr Flexibilität bringt mehr Freiheitsgrade, aber auch mehr Systemkomplexität.

• Stark ist der Ansatz dort, wo Nutzer viele Schritte über mehrere Chains hinweg ausführen müssten.
• Weniger überzeugend ist er, wenn eine App ohnehin nur auf einer einzelnen Ausführungsschicht lebt.
• Die Bedienung kann einfacher werden, obwohl das darunterliegende System komplexer wird.
• Die Sicherheitsprüfung verschiebt sich von der Wallet allein auf Konto-Rechte, Relayer und Signaturnetzwerk.

Wie unterscheidet sich Sicherheit bei Chain Signatures von klassischer Wallet-Nutzung?

Bei klassischer Wallet-Nutzung kontrolliert meist ein einzelner privater Schlüssel direkt die Adresse auf der Ziel-Chain. Die Kernaussage bei Chain Signatures lautet dagegen: Kontrolle wird verteilt und dadurch anders, nicht automatisch einfacher.

Ein einzelner Schlüssel ist konzeptionell leicht zu verstehen. Geht er verloren oder wird kompromittiert, ist der Schaden aber unmittelbar. Verteilte Signaturverfahren wie MPC zielen darauf ab, diesen Single Point of Failure zu reduzieren. Kein Teilnehmer hält allein den kompletten geheimen Schlüssel, und Signaturen entstehen erst durch koordinierte Zusammenarbeit mehrerer Parteien.

Das verbessert bestimmte Sicherheitsprofile, führt aber neue Annahmen ein. Relevant sind dann Fragen wie: Wie viele Teilnehmer dürfen ausfallen? Unter welchen Bedingungen können Teilnehmer kolludieren? Wie wird ein kompromittierter Knoten ersetzt? Und wie wird sichergestellt, dass nur tatsächlich autorisierte Zielaktionen signiert werden?

Hinzu kommt die operative Ebene. Selbst wenn die Kryptografie sauber ist, bleiben Risiken bei Relayern, bei fehlerhafter Gebührenlogik, bei Frontends oder bei missverständlich formulierten Signaturanforderungen. Ein Multichain-System ist immer nur so robust wie seine schwächste Schicht. Deshalb sollte Chain Abstraction nicht als „unsichtbare Magie“ begriffen werden, sondern als bewusst gestaltete Kombination aus Konto-Modell, kryptografischer Delegation und Ziel-Chain-Ausführung.

Kann Chain Abstraction Bridges komplett ersetzen?

Nein. Wenn Vermögenswerte oder Zustandsnachweise zwischen zwei Chains übertragen werden müssen, bleiben Bridges oder ähnliche Messaging-Systeme relevant. Chain Abstraction reduziert vor allem Bedien- und Signaturkomplexität, nicht jede Form von Interoperabilität.

Ist Chain Signatures dasselbe wie Account Abstraction?

Nein. Account Abstraction beschreibt meist, wie Konten innerhalb einer Chain flexibler werden, etwa durch alternative Signaturlogik oder Sponsoring von Gebühren. Chain Signatures gehen einen Schritt weiter in Richtung Multichain-Steuerung, weil Signaturen für externe Netzwerke erzeugt werden.

Funktioniert das nur für EVM-Chains?

Der Ansatz ist gerade deshalb interessant, weil er nicht auf EVM-Netzwerke beschränkt sein muss. Entscheidend ist, ob für das Zielsystem die passende Signaturlogik und ein sauberer Ausführungspfad bereitgestellt werden können. Die konkrete Unterstützung hängt aber immer von der jeweiligen Implementierung ab.

Weshalb Chain Abstraction für Web3-Infrastruktur relevant ist

Chain Abstraction ist vor allem ein Infrastrukturthema und weniger ein neues Narrativ für einen einzelnen Coin. Die Kernaussage lautet: Je stärker sich das Blockchain-Ökosystem in spezialisierte Netzwerke aufteilt, desto wichtiger werden Schichten, die Konten, Signaturen und Ausführung koordinieren.

In den ersten Jahren von Krypto stand oft die einzelne Chain im Mittelpunkt. Inzwischen existieren Layer-1-Netzwerke, Rollups, App-Chains, Data-Availability-Schichten, Oracles und Messaging-Protokolle nebeneinander. Für Endnutzer ist diese Vielfalt selten ein Vorteil, wenn jede Aktion mehrere Wallets, Bridges oder Gas-Reserven auf unterschiedlichen Chains voraussetzt.

NEAR adressiert dieses Problem nicht über maximale EVM-Kompatibilität oder über ein universelles Settlement, sondern über eine Abstraktionsschicht für Konten und Signaturen. Das ist technisch bemerkenswert, weil es die Frage verschiebt: Nicht welche Chain „gewinnt“, sondern welche Infrastruktur dafür sorgt, dass verschiedene Chains überhaupt gemeinsam nutzbar werden. Gerade darin liegt der sachliche Wert des Konzepts.

Unter dem Strich ist Chain Abstraction mit NEAR vor allem ein Versuch, Multichain-Nutzung von der Benutzeroberfläche bis zur Kryptografie neu zu ordnen. Chain Signatures zeigen, dass Interoperabilität nicht immer nur aus Bridges und Wrapped Assets bestehen muss, sondern auch über Signatur- und Kontomodelle gestaltet werden kann. Ob sich dieser Ansatz breit durchsetzt, hängt weniger von Marketing als von sicherer Implementierung, klaren Rechten und zuverlässiger Ausführung auf den Ziel-Chains ab.

Dieser Beitrag dient ausschließlich der technischen und sachlichen Information. Er stellt keine Anlageberatung, Steuer- oder Rechtsberatung dar.

Anzeige