Starknet Smart Contract Model & Native AA

Weiterleiten des Originaltitels: Entschlüsselung des Smart Contract-Modells von Starknet und des nativen AA: Einzelgängerische Technikmeister

Ursprüngliche Autoren: Shew & Faust, Web3-Berater: CryptoNerdCn, Starknet-Core-Entwickler, Browser-seitige Cairo-Entwicklungsplattform WASM Cairo Gründer

Abstract:

Die wichtigsten technologischen Merkmale von Starknet umfassen die Cairo-Sprache, die zur Erzeugung von ZK-Beweisen geeignet ist, native AA auf der Ebene, sowie ein intelligentes Vertragsmodell, bei dem die Geschäftslogik unabhängig von der Zustandsspeicherung ist. Cairo ist eine vielseitige ZK-Sprache, die sowohl zur Implementierung von Smart Contracts auf Starknet als auch zur Entwicklung von Anwendungen mit traditionellen Ansichten verwendet werden kann. Der Kompilierungsprozess führt Sierra als Zwischensprache ein, was häufige Iterationen von Cairo ermöglicht, ohne den zugrunde liegenden Bytecode direkt zu ändern. Darüber hinaus umfasst die Standardbibliothek von Cairo viele grundlegende Datenstrukturen, die für die Kontenabstraktion erforderlich sind. Starknet Smart Contracts trennen die Geschäftslogik von der Zustandsdatenspeicherung, im Gegensatz zu EVM Chains. Die Bereitstellung von Cairo-Verträgen umfasst drei Phasen: Kompilierung, Deklaration und Bereitstellung, bei denen die Geschäftslogik in einer Contract-Klasse deklariert wird. Instanzen von Verträgen, die Zustandsdaten enthalten, können mit der Klasse assoziiert werden und den darin enthaltenen Code aufrufen.

Das oben genannte Smart-Vertragsmodell von Starknet fördert die Wiederverwendung von Code, die Wiederverwendung von Vertragsstatus, die Speicherschichtung und die Erkennung von Müllverträgen. Es fördert auch die Realisierung von Speicherleasing und Transaktionsparallelisierung. Obwohl die letzten beiden noch nicht implementiert wurden, hat die Struktur der Cairo-Smart-Verträge "notwendige Bedingungen" für sie geschaffen. · Auf der Starknet-Kette gibt es nur Smart-Vertragskonten und keine EOA-Konten. Es unterstützt von Anfang an die Abstraktion von AA-Konten auf nativer Ebene. Sein AA-Plan integriert die Ideen von ERC-4337 in gewissem Maße und ermöglicht es den Benutzern, hochgradig angepasste Transaktionsverarbeitungslösungen zu wählen. Um potenzielle Angriffsszenarien zu verhindern, hat Starknet viele Gegenmaßnahmen ergriffen und wichtige Erkundungen im AA-Ökosystem vorgenommen.

text: Nach der Ausgabe von Token auf Starknet wurde STRK in den Augen der Ethereum-Beobachter allmählich zu einem unverzichtbaren Element. Dieser Ethereum-Layer-2-Star, der für seine "unabhängige" und "Missachtung der Benutzererfahrung" bekannte Haltung bekannt ist, hat sich still und leise sein eigenes Territorium im florierenden Layer-2-Ökosystem geschaffen, das mit EVM kompatibel ist. Aufgrund seiner übermäßigen Vernachlässigung der Nutzer und sogar der offenen Einrichtung eines "elektronischen Bettler"-Kanals auf Discord wurde Starknet einst von der Community kritisiert. Inmitten des Vorwurfs, "unmenschlich" zu sein, schien sein profundes technisches Know-how sofort entwertet zu werden, als ob nur UX und die Schaffung von Wohlstand alles wären. Die Zeile aus "Der Tempel des Goldenen Pavillons" - "Die Tatsache, von anderen nicht verstanden zu werden, war meine einzige Quelle des Stolzes" - ist fast ein Selbstporträt von Starknet. Abgesehen von diesen trivialen Dingen der Welt, die rein auf dem technischen Geschmack von Code-Geeks basieren, sind Starknet und StarkEx als Pioniere von ZK Rollup in den Augen von Kairo-Enthusiasten fast schon Schätze. In den Köpfen einiger Entwickler von Blockchain-Spielen sind Starknet und Cairo einfach alles im Web3 und übertreffen Solidity und Move. Die größte Kluft zwischen "Technikfreaks" und "Nutzern" ist heute vor allem auf das mangelnde Verständnis der Menschen für Starknet zurückzuführen. Angetrieben von seinem Interesse an der Blockchain-Technologie und der Erforschung des Wertes von Starknet geht der Autor dieses Artikels von Starknets Smart-Contract-Modell und nativem AA aus, um die technischen Lösungen und Mechanismusdesigns von Starknet kurz zu skizzieren, mit dem Ziel, die technischen Funktionen von Starknet mehr Menschen zu präsentieren und gleichzeitig zu hoffen, den Menschen zu helfen, diesen "missverstandenen einsamen Ranger" zu verstehen. Nach einer kurzen Einführung in die Kairoer Sprache im folgenden Abschnitt werden wir uns darauf konzentrieren, das Smart-Contract-Modell und die native Kontoabstraktion von Starknet zu diskutieren und zu erklären, wie Starknet natives AA erreicht. Nach der Lektüre dieses Artikels werden die Leser auch verstehen, warum mnemonische Phrasen aus verschiedenen Wallets in Starknet nicht gemischt werden können. Bevor wir jedoch die native Kontoabstraktion einführen, sollten wir zunächst die innovative Kairoer Sprache verstehen, die von Starknet entwickelt wurde. Im Entwicklungsprozess von Cairo gab es frühe Versionen namens Cairo0, gefolgt von der modernen Version. Die allgemeine Syntax der modernen Version von Kairo ähnelt der von Rust und ist eigentlich eine vielseitige ZK-Sprache. Es wird nicht nur zum Schreiben von Smart Contracts auf Starknet verwendet, sondern kann auch für die Entwicklung allgemeiner Anwendungen verwendet werden. Zum Beispiel können wir ein ZK-Identitätsprüfungssystem mit der Sprache Cairo entwickeln, und dieses Programm kann auf unserem eigenen Server laufen, ohne auf das StarkNet-Netzwerk angewiesen zu sein. Man kann sagen, dass jedes Programm, das überprüfbare Recheneigenschaften erfordert, mit der Cairo-Sprache implementiert werden kann. Und Cairo ist derzeit vielleicht die Programmiersprache, die für die Generierung von ZK-Beweisen am besten geeignet ist.

Aus der Perspektive des Kompilationsprozesses verwendet Cairo eine auf Zwischensprache basierende Kompilationsmethode, wie im untenstehenden Bild gezeigt. Sierra im Bild ist eine Zwischenrepräsentation (IR) im Kompilationsprozess der Cairo-Sprache, und Sierra wird in eine niedrigere binäre Code-Repräsentation namens CASM kompiliert, die direkt auf dem Starknet-Knotengerät ausgeführt wird.

Die Einführung von Sierra als Zwischenrepräsentation erleichtert es der Cairo-Sprache, neue Funktionen hinzuzufügen. In vielen Fällen ist es nur notwendig, die Zwischensprache Sierra zu manipulieren, ohne den zugrunde liegenden CASM-Code direkt zu ändern. Dies spart viel Ärger, und der Node-Client von Starknet muss nicht häufig aktualisiert werden. Auf diese Weise können häufige Iterationen der Cairo-Sprache erreicht werden, ohne die zugrunde liegende Logik von StarkNet zu ändern. Die Standardbibliothek von Cairo enthält auch viele grundlegende Datenstrukturen, die für die Abstraktion von Konten erforderlich sind. Zu den weiteren Innovationen von Cairo gehört eine theoretische Lösung namens Cairo Native, die plant, Cairo in maschinennahen Code zu kompilieren, der sich an verschiedene Hardwaregeräte anpassen kann. Starknet-Knoten müssen sich nicht auf die CairoVM-Virtual Machine verlassen, wenn sie Smart Contracts ausführen. Dies kann die Ausführungsgeschwindigkeit des Codes erheblich verbessern [es befindet sich noch in der theoretischen Phase und wurde noch nicht implementiert].

Starknet Smart-Vertragsmodell: Entfernen von Code-Logik und Zustandsspeicherung

Im Gegensatz zu Ethereum-kompatiblen Chains hat Starknet bahnbrechende Innovationen im Design seines Smart-Vertrags-Systems vorgenommen, hauptsächlich in Vorbereitung auf native AA und bevorstehende Funktionen wie parallele Transaktionsverarbeitung. Hier ist es wichtig zu verstehen, dass im Gegensatz zu traditionellen öffentlichen Chains wie Ethereum die Bereitstellung von Smart Contracts auf Starknet einen anderen Prozess durchläuft. Nehmen wir das Beispiel der Bereitstellung eines Ethereum-Smart-Vertrags:

1. Entwickler schreiben den Smart-Vertrag-Code lokal und kompilieren das Solidity-Programm in EVM-Bytecode mit einem Editor. Dieser Bytecode kann dann vom EVM direkt verstanden und verarbeitet werden.

1. Der Entwickler initiiert eine Transaktion zur Bereitstellung des Smart Contracts und bereitet den kompilierten EVM-Bytecode für die Ethereum-Chain bereit.

Quelle: not-satoshi.com

Obwohl die Smart Contracts von Starknet auch dem Konzept von "zuerst kompilieren und dann bereitstellen" folgen, werden Smart Contracts in Form von CASM-Bytecode, der von CairoVM unterstützt wird, auf der Chain bereitgestellt. Allerdings gibt es enorme Unterschiede zwischen Starknet und EVM-kompatiblen Chains in der Aufrufmethode und im Zustandsspeichermodus von Smart Contracts. Genau genommen entspricht ein Ethereum-Smart-Vertrag der Geschäftslogik plus Statusinformationen. Zum Beispiel implementiert der USDT-Vertrag nicht nur gemeinsame Funktionen wie Transfer und Genehmigung, sondern speichert auch den Vermögensstatus aller USDT-Inhaber. Code und Zustand sind miteinander verbunden, was viele Probleme mit sich bringt. Erstens ist es nicht förderlich für das Upgrade von DAPP-Verträgen und den Zustandswechsel, noch förderlich für die parallele Verarbeitung von Transaktionen. Es ist eine schwere technische Belastung.

Als Reaktion darauf hat Starknet die Art und Weise verbessert, wie der Zustand gespeichert wird. In seiner Lösung zur Implementierung von Smart Contracts ist die Geschäftslogik von DApps vollständig von den Vermögenszuständen entkoppelt und separat gespeichert. Die Vorteile dieses Ansatzes sind offensichtlich: Erstens ermöglicht es dem System, schnell zu unterscheiden, ob es Duplikate oder redundante Code-Bereitstellungen gibt. So funktioniert es: In Ethereum umfasst ein Smart Contract sowohl die Geschäftslogik als auch die Zustandsdaten. Wenn mehrere Verträge eine identische Geschäftslogik, aber unterschiedliche Zustandsdaten haben, werden auch ihre Hashes unterschiedlich sein, was es dem System erschwert zu bestimmen, ob „Müllverträge“ existieren. In der Lösung von Starknet sind jedoch der Code und die Zustandsdaten getrennt, was es dem System erleichtert, zu erkennen, ob derselbe Code mehrfach anhand des Hashs des Code-Teils bereitgestellt wurde. Dies hilft, die Bereitstellung von Duplikatcode zu verhindern und Speicherplatz auf Starknet-Knoten zu sparen.

Im Smart-Vertragssystem von Starknet sind die Bereitstellung und Nutzung von Verträgen in drei Phasen unterteilt: „Kompilieren, Deklarieren und Bereitstellen“. Wenn ein Vermögensaussteller einen Cairo-Vertrag bereitstellen möchte, kompiliert er zunächst den geschriebenen Cairo-Code in Sierra und CASM-Bytecode-Formen mit niedrigerer Ebene auf seinem lokalen Gerät. Anschließend veröffentlicht der Vertragsbereitsteller eine „deklarieren“-Transaktion, die den CASM-Bytecode und den Sierra-Zwischencode des Vertrags auf die Kette bereitstellt, der als Vertragsklasse bezeichnet wird.

(Quelle: Starknet offizielle Website)

Später, wenn Sie die im Asset-Vertrag definierten Funktionsfähigkeiten nutzen möchten, können Sie über die DApp-Frontend eine "Bereitstellen"-Transaktion initiieren, um eine Vertragsinstanz, die mit der Vertragsklasse verknüpft ist, zu bereitstellen. Diese Instanz wird den Asset-Zustand halten. Anschließend können Benutzer die Funktionen innerhalb der Vertragsklasse aufrufen, um den Zustand der Vertragsinstanz zu ändern. Tatsächlich sollte jeder, der mit objektorientierter Programmierung vertraut ist, leicht verstehen, was Klasse und Instanz in Starknet repräsentieren. Die von Entwicklern deklarierte Vertragsklasse enthält nur die Geschäftslogik des Smart Contracts und umfasst Funktionen, die von jedem aufgerufen werden können, hat jedoch keinen tatsächlichen Asset-Zustand und implementiert daher nicht direkt „Asset-Entitäten“, sondern hat nur die „Seele“ ohne den „Körper“. Wenn Benutzer jedoch spezifische Vertragsinstanzen bereitstellen, werden die Assets „materialisiert“. Wenn Sie den Zustand der Asset-„Entität“ ändern müssen, z. B. Ihre Token an jemand anderen übertragen, können Sie die in der Vertragsklasse geschriebenen Funktionen direkt aufrufen. Der obige Prozess ähnelt in gewisser Weise der „Instantiierung“ in traditionellen objektorientierten Programmiersprachen (obwohl nicht vollständig identisch).

Nachdem Smart Contracts in Klassen und Instanzen aufgeteilt sind, werden Geschäftslogik und Statusdaten entkoppelt, was die folgenden Funktionen für Starknet mit sich bringt:

1. Fördert die Realisierung von Speichertierung und "Speichervermietungssystem"

Die sogenannte Speicherschichtung bedeutet, dass Entwickler Daten an benutzerdefinierten Standorten platzieren können, die ihren eigenen Anforderungen entsprechen, z.B. unter der Starknet-Kette. StarkNet ist bereit, kompatibel mit DA-Schichten wie Celestia zu sein, und DAPP-Entwickler können Daten in diesen Drittanbieter-DA-Schichten speichern. Zum Beispiel kann ein Spiel seine wichtigsten Asset-Daten im Starknet Mainnet speichern und andere Daten in Off-Chain-DA-Schichten wie Celestia speichern. Diese Lösung zur Anpassung der DA-Schicht an Sicherheitsanforderungen wurde von Starknet als "Volition" bezeichnet.

Das sogenannte Speichermietsystem bedeutet, dass jeder weiterhin für den Speicherplatz zahlen sollte, den er belegt. So viel Platz in der Kette, wie Sie belegen, sollten Sie theoretisch weiterhin Miete zahlen.

Im Ethereum-Smart-Contract-Modell ist die Eigentümerschaft des Vertrags unklar, und es ist schwer zu unterscheiden, ob der Bereitsteller oder der Asset-Inhaber "Miete" für einen ERC-20-Vertrag zahlen sollte. Die Speicher-Leasing-Funktion gibt es schon lange nicht mehr, und dem Deployer wird erst bei Vertragsabschluss eine Gebühr berechnet. Dieses Lagergebührenmodell ist unangemessen.

Unter den Smart-Vertragsmodellen von Starknet, Sui, CKB und Solana ist das Eigentum an Smart Contracts klarer unterteilt, was es einfacher macht, Speicherfonds zu sammeln [Derzeit startet Starknet kein Speicherleasing-System direkt, aber es wird in Zukunft implementiert werden]

1. Erreichen Sie echte Code-Wiederverwendung und reduzieren Sie die Bereitstellung von Junk-Verträgen

Wir können einen allgemeinen Tokenvertrag als Klasse auf der Kette deklarieren und dann kann jeder die Funktionen in dieser Klasse aufrufen, um ihre Token-Instanzen bereitzustellen. Darüber hinaus kann der Vertrag auch direkt den Code in der Klasse aufrufen, was einen Effekt ähnlich der Bibliotheksfunktion in Solidity erreicht. Gleichzeitig hilft das Smart-Vertragsmodell von Starknet, „Junk-Verträge“ zu identifizieren. Dies wurde früher erklärt. Nach Unterstützung von Code-Wiederverwendung und der Erkennung von Junk-Verträgen kann Starknet die Menge der Daten, die auf die Kette hochgeladen werden, erheblich reduzieren und den Speicherdruck auf Knoten so weit wie möglich reduzieren.

1. Wiederverwendung des realen Vertragszustands

Vertragsupgrades auf der Blockchain beinhalten hauptsächlich Änderungen an der Geschäftslogik. Im Starknet-Szenario ist die Geschäftslogik von Smart Contracts inhärent vom Vermögensstatus getrennt. Wenn die Vertragsinstanz die zugehörige Vertragstypklasse ändert, kann das Geschäftslogikupgrade abgeschlossen werden. Es ist nicht erforderlich, den Vermögensstatus an einen neuen Ort zu migrieren. Diese Form des Vertragsupgrades ist gründlicher und natürlicher als die von Ethereum.

Um die Geschäftslogik eines Ethereum-Vertrags zu ändern, ist es oft notwendig, die Geschäftslogik an einen Agenturvertrag auszulagern und die Geschäftslogik des Hauptvertrags zu ändern, indem der abhängige Agenturvertrag geändert wird. Allerdings ist diese Methode nicht präzise genug und nicht „natürlich“.

Quelle: wtf Academy

In einigen Szenarien, wenn der alte Ethereum-Vertrag vollständig aufgegeben wird, kann der Vermögensstatus darin nicht direkt an den neuen Ort migriert werden, was sehr umständlich ist; Der Kairo-Vertrag muss den Status nicht migrieren und kann den alten Status direkt "wiederverwenden".

1. Förderlich für die parallele Verarbeitung von Transaktionen

Um die Parallelität verschiedener Handelsanweisungen zu maximieren, ist es notwendig, den Vermögensstatus verschiedener Personen an separaten Standorten zu speichern, wie es bei Bitcoin, CKB und Sui gesehen werden kann. Die Voraussetzung für das oben genannte Ziel ist es, die Geschäftslogik von Smart Contracts von den Vermögensstatusdaten zu trennen. Obwohl Starknet noch keine eingehende technische Umsetzung von parallelen Transaktionen durchgeführt hat, wird es parallele Transaktionen in Zukunft als wichtiges Ziel betrachten.

Starknets native AA- und Kontovertragsbereitstellung

Tatsächlich wurde das Konzept der Kontenabstraktion (AA) und EOA (externally owned accounts) von der Ethereum-Community als einzigartiges Konzept erfunden. In vielen neuen öffentlichen Ketten gibt es keine Unterscheidung zwischen EOA-Konten und Smart-Vertragskonten, um von Anfang an die Fallstricke des Ethereum-Stils bei der Kontensystem zu vermeiden. Zum Beispiel muss unter den Einstellungen von Ethereum der EOA-Kontroller ETH auf der Kette haben, bevor er eine Transaktion initiieren kann. Es gibt keine Möglichkeit, direkt verschiedene Authentifizierungsmethoden auszuwählen, und es ist äußerst mühsam, einige benutzerdefinierte Zahlungslogik hinzuzufügen. Einige Leute denken sogar, dass das Kontendesign von Ethereum einfach nicht menschenfreundlich ist.

Wenn wir uns Flaggschiffprodukte wie Starknet oder zkSyncEra „Native AA“-Kette ansehen, können offensichtliche Unterschiede festgestellt werden: Erstens haben Starknet und zkSyncEra vereinheitlichte Kontotypen. Es gibt nur Smart Contract-Konten auf der Kette. Es gibt von Anfang an kein EOA-Konto. (zkSync Era wird standardmäßig einen Satz von Vertragscodes auf dem neu erstellten Konto des Benutzers bereitstellen, um die Merkmale des Ethereum EOA-Kontos zu simulieren, damit es mit Metamask kompatibel ist).

Allerdings berücksichtigt Starknet nicht direkt die Kompatibilität mit Ethereum-Peripheriegeräten wie Metamask. Wenn Benutzer das Starknet Wallet zum ersten Mal verwenden, wird automatisch ein dediziertes Vertragskonto bereitgestellt. Mit anderen Worten, die zuvor erwähnte Vertragsinstanz wird bereitgestellt, und diese Instanz ist mit der im Voraus vom Wallet-Projekt bereitgestellten Vertragsklasse verknüpft. Benutzer können einige der in der Klasse geschriebenen Funktionalitäten direkt aufrufen. Nun wollen wir uns mit einem interessanten Thema befassen: Als viele Leute STRK-Airdrops beanspruchten, stellten sie fest, dass die Argent- und Braavos-Wallets nicht miteinander kompatibel waren. Das Importieren des Mnemonics von Argent nach Braavos ermöglichte nicht das Exportieren des entsprechenden Kontos, hauptsächlich aufgrund unterschiedlicher Kontoerstellungsalgorithmen, die von Argent und Braavos verwendet wurden, was zu unterschiedlichen Kontoadressen führte, die aus demselben Mnemonic generiert wurden. Speziell in Starknet kann die neu bereitgestellte Vertragsadresse durch einen deterministischen Algorithmus abgeleitet werden, wie folgt:

Die oben erwähnte Funktion 'pedersen()' ist ein Hash-Algorithmus, der in ZK-Systemen einfach zu verwenden ist. Der Prozess der Generierung des Kontos beinhaltet die Bereitstellung mehrerer spezieller Parameter an die pedersen-Funktion, um den entsprechenden Hash zu generieren, der die generierte Kontoadresse ist. Das obige Bild zeigt die von Starknet verwendeten Parameter zur Generierung der 'neuen Vertragsadresse'. Die 'deployer_address' repräsentiert die Adresse des 'Vertragsbereitstellers'. Dieser Parameter kann leer sein, was bedeutet, dass Sie auch ohne ein zuvor erstelltes Starknet-Vertragskonto einen neuen Vertrag bereitstellen können. Das 'salt' ist der Salzwert, der zur Berechnung der Vertragsadresse verwendet wird, was im Wesentlichen eine Zufallszahl ist, die eingeführt wird, um doppelte Vertragsadressen zu vermeiden. Der 'class_hash' entspricht dem Hash-Wert der zuvor erwähnten Klasse, mit der die Vertragsinstanz verbunden ist. Der 'constructor_calldata_hash' repräsentiert den Hash der Initialisierungsparameter des Vertrags.

Basierend auf der obigen Formel können Benutzer die generierte Vertragsadresse berechnen, bevor sie den Vertrag auf die Kette bereitstellen. Starknet ermöglicht es Benutzern, Verträge direkt bereitzustellen, ohne über ein Starknet-Konto im Voraus zu verfügen, wie folgt:

1. Benutzer bestimmen zunächst die Vertragsinstanz, die sie bereitstellen möchten, und welche Vertragsklasse sie damit verknüpfen möchten, wobei der Hash der Klasse als einer der Initialisierungsparameter verwendet wird, und berechnen das Salt, um die generierte Vertragsadresse zu bestimmen.
2. Nachdem sie wissen, wo sie den Vertrag bereitstellen werden, überweisen Benutzer zunächst einen bestimmten Betrag ETH an diese Adresse als Gebühr für die Vertragsbereitstellung. Im Allgemeinen muss dieses ETH über eine Cross-Chain-Brücke von L1 in das Starknetzwerk überwiesen werden.
3. Benutzer initiieren die Transaktionsanforderung für Vertragsbereitstellung.

Tatsächlich werden alle Starknet-Konten durch den obigen Prozess bereitgestellt, aber die meisten Brieftaschen verbergen die Details, und die Benutzer nehmen den Prozess nicht wahr, wenn ihr Vertragskonto sofort bereitgestellt wird, sobald sie ETH übertragen.

Die obige Lösung hat einige Kompatibilitätsprobleme verursacht, da bei der Generierung von Kontoadressen durch verschiedene Wallets inkonsistente Ergebnisse erzielt werden. Nur Wallets, die die folgenden Bedingungen erfüllen, können gemischt werden:

1. Der aus dem privaten Schlüssel abgeleitete öffentliche Schlüssel, der von der Brieftasche verwendet wird, ist derselbe wie der Signaturalgorithmus;
2. Der Salzberechnungsprozess der Brieftasche ist derselbe;
3. Die Smart-Contract-Klassen der Brieftasche unterscheiden sich in der Implementierungsdetails grundlegend nicht; \

In dem zuvor erwähnten Fall verwendeten sowohl Argent als auch Braavos den ECDSA-Signaturalgorithmus, jedoch waren die Berechnungsmethoden für das Salt zwischen den beiden unterschiedlich, was zu inkonsistenten Kontoadressen führte, die aus dem gleichen Mnemonic generiert wurden.

Lassen Sie uns nun das Thema der Kontenabstraktion erneut besprechen. Starknet und zkSync Era haben eine Reihe von Prozessen im Zusammenhang mit der Transaktionsverarbeitung, wie die Identitätsprüfung (Überprüfung digitaler Signaturen) und die Zahlung von Gasgebühren, aus der „Kettenebene“ heraus verlagert. Benutzer können die Implementierungsdetails der oben genannten Logik in ihren eigenen Konten anpassen. Zum Beispiel können Sie eine dedizierte Funktion zur digitalen Signaturprüfung in Ihrem Starknet-Smart-Vertragskonto bereitstellen. Wenn ein Starknet-Knoten eine von Ihnen initiierte Transaktion empfängt, ruft er eine Reihe von von Ihnen auf der Kette angepassten Transaktionsverarbeitungslogik auf.

Dieser Ansatz bietet eindeutig mehr Flexibilität. In Ethereums Design ist jedoch die Logik wie Identitätsüberprüfung (digitale Signaturen) fest in den Knotenclient-Code eingebettet und kann nativ keine anpassbaren Kontofunktionen unterstützen.

Schaltplan der nativen AA-Lösung, die vom Starknet-Architekten festgelegt wurde. Die Transaktionsüberprüfung und die Gasgebührenqualifikationsüberprüfung werden zur Verarbeitung an den On-Chain-Vertrag übertragen. Die zugrunde liegende virtuelle Maschine der Kette kann diese Funktionen aufrufen, die vom Benutzer angepasst oder festgelegt wurden.

Laut den Vertretern von zkSyncEra und Starknet ist dieser modulare Ansatz zur Kontofunktionalität von EIP-4337 inspiriert. Was sie jedoch unterscheidet, ist, dass zkSync und Starknet von Anfang an Kontotypen zusammengeführt, Transaktionstypen vereinheitlicht und einen einzigen Einstiegspunkt zur Entgegennahme und Verarbeitung aller Transaktionen genutzt haben. Im Gegensatz dazu unterstützte Ethereum aufgrund historischer Altlasten und des Wunsches der Stiftung, aggressive Iterationsstrategien wie harte Gabeln so weit wie möglich zu vermeiden, die EIP-4337 auf eine andere Weise, um das Problem zu lösen. Das Ergebnis ist jedoch, dass EOA-Konten und EIP-4337-Lösungen jeweils unabhängige Transaktionsverarbeitungs-Workflows haben, die im Gegensatz zur Agilität der nativen AAs umständlich und umständlich erscheinen.

Quelle: ArgentWallet

Die native Kontoabstraktion in Starknet hat jedoch noch nicht die volle Reife erreicht. Aus praktischer Sicht unterstützen die AA-Konten von Starknet zwar benutzerdefinierte Signaturüberprüfungsalgorithmen, unterstützen derzeit jedoch nur die Bezahlung von Gasgebühren in ETH und STRK und unterstützen noch keine Gaszahlung von Drittanbietern. Daher kann der Fortschritt von Starknet bei nativen AA als „der theoretische Rahmen ist größtenteils ausgereift, während die praktische Umsetzung noch in Arbeit ist“ beschrieben werden. Da Starknet intern nur Smart-Vertragskonten hat, berücksichtigt der gesamte Prozess seiner Transaktionen den Einfluss von Konto-Smart-Verträgen. Zunächst wird nach dem Empfang einer Transaktion durch den Speicherpool (Mempool) des Starknet-Knotens eine Überprüfung durchgeführt, die Folgendes umfasst:

1. Überprüfen, ob die digitale Signatur der Transaktion korrekt ist, zu welchem Zeitpunkt die benutzerdefinierte Verifikationsfunktion des Kontos des Unterzeichners aufgerufen wird;
2. Überprüfen, ob das Kontoguthaben des Initiators die Gasgebühr decken kann. \

Es sei hier darauf hingewiesen, dass die Verwendung der benutzerdefinierten Signaturüberprüfungsfunktion im Smart Contract des Kontos bedeutet, dass es ein Angriffsszenario gibt. Denn der Speicherpool erhebt keine Gasgebühren, wenn die Signatur neuer Transaktionen überprüft wird. (Wenn Gasgebühren direkt erhoben werden, treten schwerwiegendere Angriffsszenarien auf). Böswillige Benutzer können zunächst eine äußerst komplexe Signaturüberprüfungsfunktion in ihrem Kontovertrag anpassen und dann eine große Anzahl von Transaktionen initiieren. Wenn diese Transaktionen überprüft werden, rufen sie die angepasste komplexe Signaturüberprüfungsfunktion auf, die direkt die Rechenressourcen des Knotens erschöpfen kann. Um diese Situation zu vermeiden, legt StarkNet folgende Einschränkungen für Transaktionen fest:

1. Es gibt eine Obergrenze für die Anzahl der Transaktionen, die ein einzelner Benutzer innerhalb einer Zeiteinheit initiieren kann;
2. Die benutzerdefinierte Signaturüberprüfungsfunktion im Starknet-Kontovertrag unterliegt Komplexitätsbeschränkungen, und übermäßig komplexe Signaturüberprüfungsfunktionen werden nicht ausgeführt. Starknet begrenzt das Gasverbrauchslimit der Signaturüberprüfungsfunktion. Wenn der Gasverbrauch durch die Signaturüberprüfungsfunktion zu hoch ist, wird die Transaktion direkt abgelehnt. Gleichzeitig darf die Signaturüberprüfungsfunktion im Kontovertrag keine anderen Verträge aufrufen.

Das Flussdiagramm der Starknet-Transaktionen lautet wie folgt:

Es ist erwähnenswert, dass der Starknet-Node-Client zur weiteren Beschleunigung des Transaktionsverifizierungsprozesses die Signaturüberprüfungsalgorithmen der Braavos- und Argent-Wallets direkt implementiert hat. Wenn ein Node Transaktionen erkennt, die von diesen beiden großen Mainstream-Starknet-Wallets generiert wurden, ruft er die integrierten Braavos/Argent-Signaturalgorithmen im Client auf. Durch diesen Caching-ähnlichen Ansatz kann Starknet die Transaktionsüberprüfungszeit verkürzen. Nachdem die Transaktionsdaten vom Sequenzer validiert wurden (die Verifizierungsschritte des Sequenzers sind viel gründlicher als die des Speicherpools), verpackt der Sequenzer die Transaktionen aus dem Speicherpool und sendet sie an den ZK-Proof-Generator. Transaktionen, die in diese Phase eintreten, werden mit Gasgebühren belastet, auch wenn sie fehlschlagen. Wenn die Leser jedoch mit der Geschichte von Starknet vertraut sind, werden sie feststellen, dass frühere Versionen von Starknet keine Gebühren für fehlgeschlagene Transaktionen erhoben haben. Das häufigste Szenario für Transaktionsfehler ist, wenn ein Benutzer nur 1 ETH hat, aber versucht, 10 ETH extern zu übertragen, was eindeutig auf einen logischen Fehler hinweist und unweigerlich fehlschlagen wird, aber niemand kennt das Ergebnis vor der Ausführung. In der Vergangenheit erhob StarkNet jedoch keine Gebühren für solche fehlgeschlagenen Transaktionen. Diese kostenlosen fehlerhaften Transaktionen verschwenden Rechenressourcen des Starknet-Knotens und können zu DDoS-Angriffsszenarien führen. Oberflächlich betrachtet scheint die Erhebung von Gebühren für fehlerhafte Transaktionen einfach zu sein, aber in Wirklichkeit ist es ziemlich komplex. Starknet hat eine neue Version der Sprache Cairo1 eingeführt, um das Problem der Gasgebühren für fehlgeschlagene Transaktionen zu lösen. Wie wir alle wissen, ist ein ZK-Beweis ein Gültigkeitsnachweis, und das Ergebnis einer fehlgeschlagenen Transaktion ist ungültig und kann kein Ausgabeergebnis in der Kette hinterlassen. Der Versuch, mit einem Gültigkeitsbeweis zu beweisen, dass eine bestimmte Anweisungsausführung ungültig ist und keine Ausgabeergebnisse liefern kann, klingt seltsam und ist eigentlich nicht praktikabel. Daher schloss Starknet in der Vergangenheit fehlgeschlagene Transaktionen aus, die bei der Generierung von Proofs keine Ausgabeergebnisse liefern konnten. Das Starknet-Team führte später eine intelligentere Lösung ein und entwickelte eine neue Vertragssprache, Cairo1, die sicherstellt, dass "alle Transaktionsanweisungen Ausgabeergebnisse erzeugen und auf der Kette sein können". Die Tatsache, dass alle Transaktionen Ausgabeergebnisse liefern können, bedeutet auf den ersten Blick, dass logische Fehler nie auftreten. In den meisten Fällen schlagen Transaktionen jedoch fehl, weil sie auf Fehler stoßen, die die Ausführung von Anweisungen unterbrechen. Es ist schwierig sicherzustellen, dass Transaktionen niemals unterbrochen werden und erfolgreich Ausgabeergebnisse erzeugen, aber es gibt tatsächlich eine einfache alternative Lösung, die darin besteht, Transaktionen zu erlauben, Ausgabeergebnisse zu erzeugen, wenn Logikfehler auftreten, die zu Unterbrechungen führen, obwohl ein False-Wert zurückgegeben wird, der angibt, dass die Ausführung der Transaktion nicht reibungslos war. Es ist wichtig zu beachten, dass die Rückgabe eines False-Werts auch ein Ausgabeergebnis zurückgibt, was bedeutet, dass in Cairo1, unabhängig davon, ob eine Anweisung auf einen logischen Fehler stößt oder vorübergehend unterbrochen wird, sie Ausgabeergebnisse erzeugen und auf der Kette sein kann. Bei diesem Ausgabeergebnis kann es sich um eine korrekte Fehlermeldung oder um eine Fehlermeldung vom Typ "False" handeln. Betrachten Sie z. B. den folgenden Codeausschnitt:

An dieser Stelle kann _balances::read(from) - amount einen Unterlauffehler verursachen, was dazu führt, dass die entsprechende Transaktionsanweisung unterbrochen und gestoppt wird, ohne ein Transaktionsergebnis auf der Kette zu hinterlassen. Wenn es jedoch in der folgenden Form umgeschrieben wird, gibt es immer noch ein Ausgabenergebnis zurück, wenn die Transaktion fehlschlägt, und hinterlässt es auf der Kette. rein ästhetisch betrachtet scheint es so, als ob alle Transaktionen reibungslos Transaktionsausgaben auf der Kette hinterlassen können, was eine gleichmäßige Gebührenerhebung besonders vernünftig erscheinen lässt.

StarknetAA Vertragsübersicht

In Anbetracht dessen, dass einige Leser dieses Artikels möglicherweise über einen Programmierhintergrund verfügen, hier eine kurze Demonstration der Benutzeroberfläche des Konto-Abstraktvertrags in Starknet:

Das validate_declareDie oben genannte Schnittstelle wird verwendet, um die von Benutzern initiierten Deklarationstransaktionen zu validieren, während validierenwird zur allgemeinen Transaktionsvalidierung verwendet, um hauptsächlich die Korrektheit der Unterschrift des Benutzers zu überprüfen. Andererseits wird 'ausführen' zur Transaktionsausführung verwendet. Bemerkenswerterweise unterstützen Starknet-Vertragskonten von Natur aus Multicall, was mehrere Aufrufe ermöglicht. Die Multicall-Funktionalität kann verschiedene interessante Funktionen ermöglichen, wie z. B. das Bündeln der folgenden drei Transaktionen bei der Interaktion mit bestimmten DeFi-Protokollen:

1. Autorisieren von Token für den DeFi-Vertrag in der ersten Transaktion.
2. Auslösen der Logik des DeFi-Vertrags in der zweiten Transaktion.
3. Entziehung der Autorisierung des DeFi-Vertrags im dritten Transaktionsvorgang.

Natürlich gibt es aufgrund der Atomarität von Multicall komplexere Anwendungsfälle, wie die Ausführung von Arbitrage-Trades.

Zusammenfassung

Die wichtigsten technologischen Merkmale von Starknet umfassen die Cairo-Sprache, die für die ZK-Proof-Generierung optimiert ist, die Account-Abstraktion auf nativer Ebene und das Smart-Contract-Modell, das die Geschäftslogik von der Zustandsspeicherung trennt.

Cairo ist eine vielseitige ZK-Sprache, die sowohl für Smart Contracts auf Starknet als auch für die Entwicklung traditionellerer Anwendungen verwendet werden kann. Der Kompilierungsprozess führt Sierra als Zwischensprache ein, was es Cairo ermöglicht, häufig zu iterieren, ohne den zugrunde liegenden Bytecode zu ändern, sondern nur Änderungen an die Zwischensprache weiterzugeben. Die Cairo-Standardbibliothek enthält auch viele grundlegende Datenstrukturen, die für die Kontoabstraktion notwendig sind.

Starknets Smart Contracts trennen die Geschäftslogik von der Speicherung der Zustandsdaten, im Gegensatz zu EVM-Chains. Die Bereitstellung eines Cairo-Vertrags umfasst drei Phasen: Kompilierung, Deklaration und Bereitstellung. Die Geschäftslogik wird in Vertragsklassen deklariert, und Vertragsinstanzen, die Zustandsdaten enthalten, können mit einer Klasse verbunden und den darin enthaltenen Code aufrufen.

Das Smart-Vertragsmodell von Starknet erleichtert die Code-Wiederverwendung, die Wiederverwendung von Vertragszuständen, die Speicherungsschichtung und die Erkennung von Müllverträgen. Es erleichtert auch die Implementierung von Speicherleasing und Transaktionsparallelisierung, obwohl diese Funktionen noch nicht vollständig implementiert wurden. Die Architektur von Cairo Smart Contracts schafft die notwendigen Bedingungen für diese Funktionen.

Starknet verfügt nur über Smart Contract-Konten, ohne EOA-Konten, und unterstützt von Anfang an eine AA-Kontoabstraktion auf nativer Ebene. Seine AA-Lösung absorbiert teilweise die Ideen von ERC-4337, was es Benutzern ermöglicht, hochgradig individualisierte Transaktionsverarbeitungslösungen zu wählen. Um potenzielle Angriffsszenarien zu verhindern, hat Starknet verschiedene Gegenmaßnahmen implementiert und wichtige Erkundungen für das AA-Ökosystem durchgeführt.

Haftungsausschluss：

1. Dieser Artikel wurde von [reprinted}Geek Web3*Weiterleiten des Originaltitels '解读Starknet智能合约模型与原生AA：特立独行的技术巨匠'. Alle Urheberrechte gehören dem Originalautor [Shew & Faust]. Bei Einwänden gegen diesen Nachdruck kontaktieren Sie bitte denGate LearnTeam, und sie werden es umgehend bearbeiten.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, 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, Verteilen oder Plagiieren der übersetzten Artikel untersagt.