Technische Analyse: Zugriffsschicht des offenen Webs, die von Particle Network erstellt wurde

Einleitung: Während AA-Wallets die Eintrittsbarrieren für Benutzer erheblich gesenkt und Gaszahlungen und Web2-Konto-Logins erreicht haben, müssen Aspekte im Zusammenhang mit der Massenakzeptanz, wie vertrauliche Anmeldung, vertrauliche Transaktionen, Omnichain-AA und Intent-Fusion-Protokoll, auf der Grundlage von AA noch weiterentwickelt werden.

Obwohl wir sehen, dass verschiedene UX-Optimierungslösungen wie die MPC-Wallet von ZenGo oder Smart-Contract-Wallets wie Argent die Benutzerbarrieren effektiv abbauen, gehen sie nur einen Teil der oben genannten Probleme an, ohne die allgemeinen Bedenken hinsichtlich der Benutzerfreundlichkeit des Produkts vollständig abzudecken.

Es ist klar, dass die meisten AA-Wallets oder ähnliche Produkte die weit verbreitete Einführung von Web3 noch nicht unterstützen können. Auf der anderen Seite ist aus Sicht des Ökosystems die Entwicklerseite ein entscheidender Aspekt. Allein die Attraktivität für normale Nutzer, ohne ausreichende Auswirkungen auf die Entwicklerseite, wird wahrscheinlich keine Skalierbarkeit erreichen. Das Aufkommen von immer mehr Lösungen zur Optimierung der Entwicklererfahrung deutet auf die wachsende Bedeutung der Entwicklerseite im Produktökosystem hin.

Am Beispiel von Particle Network gehen wir auf die aktuellen UX-Herausforderungen von Web3-Produkten ein und diskutieren, wie eine zielgerichtete, umfassende technische Lösung gestaltet werden kann. Diese Art von integrierter Lösung kann eine notwendige Voraussetzung für die Massenakzeptanz sein. Darüber hinaus ist die BtoBtoC-Geschäftsstrategie von Particle ein bemerkenswerter Ansatz, den viele Projektteams als vorteilhaft empfinden können.

Aufschlüsselung der Partikelproduktstruktur

Particle Network, dessen Hauptaugenmerk auf der Senkung von Nutzungsbarrieren liegt, verfolgt einen B2B2C-Produktkonstruktions- und ökologischen Entwicklungsansatz und bietet eine umfassende Lösung für die weit verbreitete Einführung von Web3. Die Kernmodule bestehen aus drei Schlüsselkomponenten:

zkWaaS steht für Zero-Knowledge-Wallet-as-a-Service. Entwickler können Smart-Wallet-Module mit dem SDK von Particle schnell in ihre dApps integrieren. Die Wallet ist eine schlüssellose Smart-Contract-Wallet, die auf Kontoabstraktion basiert, Gaszahlungen ermöglicht und vertrauliche OAuth-Anmeldung und vertrauliche Transaktionen im Web2-Stil bietet.

Particle Chain - Das dedizierte Omnichain-Konto-Abstraktionsschema, das für Particle entwickelt wurde, zielt darauf ab, die Herausforderungen der kettenübergreifenden Bereitstellung, Wartung und des Aufrufs von Smart-Contract-Wallets zu bewältigen. Es enthält auch den Unified Gas Token, der die Verwendung verschiedener Gas-Token in Multi-Chain-Transaktionen vereinfacht.

Intent Fusion Protocol - Enthält eine prägnante domänenspezifische Sprache (DSL), ein Intent-Framework, ein Intent-Solver-Netzwerk usw., um ein Web3-Interaktions-Framework basierend auf der Absicht zu erstellen. Benutzer deklarieren ihre Transaktionsabsichten direkt, anstatt jede einzelne Operation auszuführen, was sie von komplizierten Pfadüberlegungen befreit und die Notwendigkeit reduziert, die komplexe zugrunde liegende Infrastruktur zu verstehen.

zkWaaS - Zero-Knowledge Wallet-as-a-Service

Auf der Wallet-Seite stellt Particle vor allem SDKs für dApp-Entwickler in Form von Wallet-as-a-Service (WaaS) zur Verfügung. Ziel ist es, Entwicklern die Integration in das umfassende Web3-Massenakzeptanz-Framework zu ermöglichen. Dieser BtoBtoC-Ansatz bietet sowohl aus geschäftlicher als auch aus ökologischer Sicht mehrere Vorteile:

Der Markt für Consumer-Wallets ist hart umkämpft und die Funktionalitäten werden immer ähnlicher. Konsumenten-Wallets sind nicht mehr der optimale Einstiegspunkt. Auf der anderen Seite ziehen es dApp-Entwickler vor, Wallets in ihre Anwendungen zu integrieren, um die Benutzererfahrung zu verbessern und anpassbarere Funktionen bereitzustellen.

Die Akquise von Nutzern auf der Verbraucherseite ist kostspielig, aber die Geschäftsseite unterscheidet sich. Das Nutzerwachstum von WaaS ist in erster Linie auf dApps zurückzuführen, die in das SDK integriert sind. Mit effektiven Geschäftsentwicklungs- und Entwicklerbeziehungen kann das Ökosystem organisch wachsen.

Derzeitige Verbraucher-Wallets konzentrieren sich in erster Linie auf Finanzen und Vermögenswerte, die möglicherweise nicht die Hauptszenarien für die Zukunft des Web3 darstellen. Um eine breite Akzeptanz von Web3 zu erreichen, müssen grundlegende Funktionen wie Benutzeridentität (Konten) und Benutzervorgänge (Transaktionsinitiierung) als grundlegender Dienst abstrahiert werden, so dass umfangreichere Szenarien von dApps verarbeitet werden können.

In der Vergangenheit hat der Einstiegspunkt für dApps eine enge Beziehung zwischen Wallets und dApps gezeigt. Die Erhöhung des Marktanteils des Wallets auf der dApp-Seite ist entscheidend. Dies ist besonders für das B2B2C-Modell von Vorteil.

Um eine Lösung zu konstruieren, die die Bedürfnisse der Benutzer erfüllt, die Einstiegshürden senkt und die Integration von Entwicklern erleichtert, dient zkWaaS von Particle als zentrale Komponente mit drei Kernfunktionen:

1. Vertrauliche Anmeldung: Nutzung traditioneller Web2-Anmeldemethoden wie OAuth-Verifizierung von Plattformen wie Twitter, Google, WeChat usw. auf der Smart-Contract-Wallet. Dies ermöglicht es den Benutzern, sich vollständig von den Einschränkungen der Verwaltung privater Schlüssel zu befreien und auf vertrauteste und unkomplizierteste Weise in das Web3 einzusteigen. Gleichzeitig wird die Identität des Nutzers durch Zero-Knowledge-Proofs verschleiert.

2. Vertrauliche Transaktionen: Implementierung von Punkt-zu-Punkt-Datenschutzübertragungen über den Smart Stealth Address-Mechanismus, um den universellen Datenschutz bei Transaktionen zu gewährleisten. Darüber hinaus ermöglicht die Verwendung des Paymaster von ERC-4337 die gaslose Nutzung von Assets für Smart Stealth-Adressen (Gas-Sponsoring).

3. Umfassende AA-Wallet-Funktionalität: Das Wallet-Modul von Particle erfüllt vollständig die grundlegenden Anforderungen von ERC-4337. Es enthält wesentliche Komponenten wie Bundler, EntryPoint, Paymaster, Smart Wallet Account und mehr und deckt alle kritischen Aspekte des ERC-4337-Workflows ab. Diese One-Stop-Lösung erfüllt effektiv die funktionalen Anforderungen von DApps oder Nutzern an Smart Wallets.

Vertraulicher Login für On-Chain-Wallets auf Basis von Web2-Konten

Die vertrauliche Anmeldelösung von Particle verwendet JSON Web Tokens (JWT) und ermöglicht die Authentifizierung von Web2-Identitäten und Wallet-Operationen innerhalb des Smart Contracts.

JWT ist eine weit verbreitete Form des Identitätsnachweises in herkömmlichen Internetanwendungen, die vom Server an den Client ausgegeben wird. Der Client verwendet diesen Nachweis für die Identitätsauthentifizierung bei jeder Interaktion mit dem Server.

(Quelle: FlutterFlow Docs)

Es gibt mehrere Schlüsselfelder in JWT, die die Grundlage für die Identitätsprüfung durch den Vertrag bilden:

·" iss" (Issuer) gibt den Aussteller von JWT an, d.h. den Server, wie z.B. Google, Twitter usw.

·" aud" (Zielgruppe): Gibt den Dienst oder die Anwendung an, für den bzw. die das JWT vorgesehen ist. Wenn Sie sich beispielsweise mit Twitter bei Medium anmelden, enthält das von Twitter ausgestellte JWT dieses Feld, das seine Anwendbarkeit auf Medium angibt.

·" sub" (Betreff): Bezieht sich auf die Benutzeridentität, die das JWT empfängt und in der Regel durch die UID identifiziert wird.

In der Praxis bleiben "iss" und "sub" in der Regel konstant, um erhebliche Verwechslungen zwischen internen Systemen und externen Referenzen zu vermeiden. Daher können diese Parameter vom Vertrag verwendet werden, um die Benutzeridentität zu bestimmen, sodass Benutzer keine privaten Schlüssel generieren und schützen müssen.

Entsprechend JWT ist das Konzept des JSON Web Key (JWK), einer Reihe von Schlüsselpaaren auf dem Server. Bei der Ausgabe von JWT signiert der Server es mit dem privaten Schlüssel von JWK, während der entsprechende öffentliche Schlüssel für andere Dienste veröffentlicht wird, um die Signatur zu überprüfen.

Wenn Medium beispielsweise Twitter für die Anmeldung verwendet, validiert Medium das JWT mit dem öffentlichen JWK von Google, um seine Authentizität zu bestätigen – dass es tatsächlich von Google ausgestellt wurde. Die vertragliche Verifizierung von JWT wird auch die Verwendung von JWK beinhalten.

Der Prozess der vertraulichen Anmeldelösung von Particle ist im folgenden Diagramm dargestellt:

Wir überspringen hier die spezifische ZK-Schaltung und heben nur einige wichtige Punkte in diesem Prozess hervor:

Der Verifier-Vertrag, der die Anmeldeinformationen validiert, erkennt nur einen ZK-Nachweis, der sich auf die Identität des Benutzers bezieht, JWT und eine eph_pk. Es kann nicht direkt den entsprechenden öffentlichen Wallet-Schlüssel oder JWT-Informationen abrufen, um die Privatsphäre der Benutzer zu gewährleisten und externe Entitäten daran zu hindern, den angemeldeten Benutzer anhand von On-Chain-Daten zu identifizieren.

eph_pk (kurzlebiges Schlüsselpaar) ist ein Schlüsselpaar, das in einer einzelnen Sitzung verwendet wird, und nicht das öffentlich-private Schlüsselpaar der Wallet. Die Benutzer müssen sich nicht darum kümmern.

Dieses System unterstützt die Off-Chain-Verifizierung und kann für Vertrags-Wallets verwendet werden, die Logik wie MPC (Multiparty Computation) verwenden.

Da es sich um eine Vertragsverifizierungslösung handelt, die wirklich auf traditionellen Login-Methoden basiert, können Benutzer in Extremfällen, wie z. B. der Deaktivierung des Web2-Kontos, auch andere soziale Kontakte als Vormünder bestimmen.

Vertrauliche Transaktionen auf der Grundlage des DH-Schlüsselaustauschs

Bevor wir uns mit den vertraulichen Transaktionen von Particle befassen, wollen wir untersuchen, wie vertrauliche Transaktionen für den Empfänger innerhalb des bestehenden EVM-Systems erreicht werden können, insbesondere durch das Ausblenden der Adresse des Empfängers.

Unter der Annahme, dass Alice die Absenderin und Bob der Empfänger ist, teilen beide Parteien einige Gemeinsamkeiten:

1. Bob generiert einen Root-Ausgabenschlüssel (m) und eine Stealth-Metaadresse (M). M kann durch m erzeugt werden, und ihre Beziehung wird durch M = G * m dargestellt, was auf eine mathematische Beziehung bei kryptografischen Operationen hinweist.

2. Alice verschafft sich Bobs heimliche Meta-Adresse M auf irgendeine Weise.

3. Alice generiert einen kurzlebigen privaten Schlüssel (r) und verwendet den Algorithmus generate_address(r, M), um eine Stealth-Adresse (A) zu erstellen. Diese Adresse dient als dedizierte Stealth-Adresse, die für Bob vorbereitet wurde, wobei Bob die Kontrolle übernimmt, sobald Assets empfangen wurden.

4. Alice generiert einen kurzlebigen Pubkey (R) basierend auf dem kurzlebigen privaten Schlüssel r und sendet ihn an den kurzlebigen Pubkey-Aufzeichnungsvertrag (oder an einen anderen einvernehmlich vereinbarten Speicherort, auf den Bob zugreifen kann).

5. Bob scannt in regelmäßigen Abständen den kurzlebigen Pubkey-Aufnahmevertrag und zeichnet jeden aktualisierten ephemeren Pubkey auf. Da der kurzlebige Pubkey-Vertrag öffentlich ist und Schlüssel enthält, die sich auf Datenschutztransaktionen beziehen, die von anderen gesendet wurden, weiß Bob nicht, welchen Alice ihm geschickt hat, damit er ihn sehen kann.

6. Bob scannt jeden aktualisierten Datensatz und führt generate_address(R, m) aus, um die Stealth-Adresse zu berechnen. Wenn sich in dieser Adresse Assets befinden, bedeutet dies, dass Alice sie für Bobs Kontrolle generiert und autorisiert hat. Ansonsten ist es für Bob irrelevant.

7. Bob führt generate_spending_key(R, m) aus, um den Ausgabenschlüssel für diese Stealth-Adresse zu generieren, d. h. p = m + hash(A). Dann kann Bob die von Alice generierte Adresse A steuern.

Der beschriebene Prozess vereinfacht viele komplexe mathematische Operationen. Der gesamte Prozess des Informationsaustauschs ist vergleichbar mit zwei Geheimagenten, die kryptische Nachrichten an ein öffentliches schwarzes Brett schreiben, Botschaften, die nur voneinander entschlüsselt werden können. Obwohl die Generierungs- und Entschlüsselungsmethoden dieser Nachrichten öffentlich sind, sind wichtige Daten, die für beide Agenten notwendig sind, nur ihnen bekannt. Selbst wenn Außenstehende die Methoden verstehen, bleibt eine erfolgreiche Entschlüsselung daher schwer fassbar.

Dieser Austauschprozess ist in gewisser Weise analog zur bekannten Diffie-Hellman-Schlüsselaustauschmethode. Ohne ihre Geheimnisse preiszugeben (Bobs Root-Ausgabenschlüssel (m) und Alices kurzlebiger privater Schlüssel (r)), können beide Parteien ein gemeinsames Geheimnis berechnen – die bereits erwähnte Stealth-Adresse (A). Wenn Sie mit dem DH-Austausch nicht vertraut sind, kann das metaphorische Verständnis mit dem folgenden Diagramm erleichtert werden.

Ein weiterer Schritt im Vergleich zu DH ist, dass nach der Berechnung des Shared Secret – Stealth-Adresse (A) – es nicht direkt als privater Schlüssel verwendet werden kann, da Alice auch A kennt. Es ist notwendig, den Ausgabenschlüssel (p = m + hash(A)) zu konstruieren, der A als öffentlichen Schlüssel behandelt. Wie bereits erwähnt, kennt nur Bob den Root-Ausgabenschlüssel (m), was Bob zum alleinigen Kontrolleur dieser Stealth-Adresse macht.

Bei dieser Datenschutzübertragungsmethode fließen die Gelder für jede neue empfangene Transaktion in eine brandneue EOA-Adresse. Der Empfänger kann den Root-Ausgabenschlüssel verwenden, um den Ausgabenschlüssel für jede Adresse iterativ zu berechnen und zu experimentieren, um diejenige zu finden, die ihm tatsächlich zugeordnet ist.

Es gibt jedoch immer noch ein Problem. Zunächst handelt es sich bei dieser neu generierten Stealth-Adresse immer noch um ein EOA-Konto, dem möglicherweise ETH oder andere Gas-Token fehlen. Bob kann keine Transaktionen direkt initiieren und muss den Paymaster einer Smart-Contract-Wallet für die Gaszahlung verwenden, um vertrauliche Transaktionen zu erreichen. Daher sind einige Änderungen an der Empfängeradresse erforderlich:

Berechnen Sie mithilfe der Adressberechnungsmethode aus der CREATE2-Funktion während der Vertragsbereitstellung zusammen mit den entsprechenden Parametern (Festlegen der Stealth-Adresse A als Eigentümer des Vertrags usw.) eine kontrafaktische Adresse. Hierbei handelt es sich um eine berechnete Vertragsadresse, die noch nicht bereitgestellt wurde, derzeit eine EOA.

Alice überweist das Geld direkt an diese kontrafaktische Adresse. Wenn Bob es nutzen möchte, erstellt er direkt eine Vertrags-Wallet unter dieser Adresse, die den Aufruf des Gas-Bezahldienstes ermöglicht (dieser Schritt kann auch von Alice oder dem Partikel-Netzwerk im Voraus erledigt werden).

Wir können die oben erwähnte kontrafaktische Adresse als Smart Stealth Address bezeichnen. Bob verwendet anonym Assets unter dieser Smart Stealth-Adresse durch den folgenden Prozess:

· Zahlen Sie den Zahlmeister von einer seiner Adressen aus ein, und der Zahlmeister gibt einen Fondsnachweis (ZK-basiert) zurück.

· Verwenden Sie mit dem AA-Mechanismus eine beliebige andere Adresse, die möglicherweise kein Guthaben hat, um UserOperation an den Bundler-Knoten zu senden und die Assets unter der erwähnten Stealth-Adresse aufzurufen. Bob muss dem Paymaster nur einen Fondsnachweis mit einer neuen Adresse vorlegen, und Paymaster bezahlt den Bundler für die Transaktionsverpackung.

Dieser Prozess ähnelt der Funktionsweise von Tornado Cash. Der Fondsnachweis (ZK-basiert) kann nachweisen, dass eine Aufladung in der Menge der Blattknoten auf dem Merkle-Baum stattgefunden hat. Bei den Ausgaben kann jedoch niemand feststellen, welche spezifischen Gelder des Blattknotens verbraucht wurden, wodurch die Verbindung zwischen dem Verbraucher und dem Ladegerät unterbrochen wird.

Zusammenfassend lässt sich sagen, dass Particle AA mit Stealth-Adressen geschickt kombiniert und vertrauliche Überweisungen in Form von intelligenten Stealth-Wallets erreicht.

Partikelketten- und Omnichain-Kontoabstraktion

Particle Chain ist eine POS-Kette, die für die Omnichain-Kontoabstraktion entwickelt wurde. Sowohl in der Gegenwart als auch in der Zukunft ist eine Dominanz einer einzigen Kette unwahrscheinlich. Die Verbesserung der Benutzererfahrung in einem Multi-Chain-Szenario ist von entscheidender Bedeutung.

Derzeit kann das ERC4337 Kontoabstraktionssystem in einer Multi-Chain-Situation auf bestimmte Probleme stoßen:

• Die Adressen desselben Nutzers in verschiedenen Ketten sind je nach Vertragsgestaltung möglicherweise nicht einheitlich.
• Die Verwaltung verschiedener Chain-Vertrags-Wallets erfordert manuelle Vorgänge über mehrere Chains hinweg, z. B. den Wechsel von Administratoren. In schlimmeren Szenarien, wenn Administratorberechtigungen auf einer Chain aktualisiert werden, gefolgt von der Verwerfung der alten Administratorvalidierungsmethode, wird es unmöglich, Änderungen an anderen Chains vorzunehmen, wodurch die Wallet unbrauchbar wird.
• Die Verwendung verschiedener Chains erfordert Gas-Token für jede Chain oder vorgespeicherte Gelder im Paymaster jeder Chain. Für Entwickler kann dies mühsam sein. Wenn sie möchten, dass Benutzer bestimmte Bedingungen kostenlos nutzen oder andere Funktionen implementieren, müssen sie ihre benutzerdefinierten Zahlmeister auf jeder Kette bereitstellen und sie vorfinanzieren.

Die Omnichain-Kontoabstraktion von Particle Chain adressiert die oben genannten Schwachstellen:

• Richten Sie AA-Wallets auf Particle Chain ein.
• Verwenden Sie LayerZero und andere Cross-Chain-Protokolle (Arbitrary Message Bridge, AMB), um verschiedene Vorgänge, wie z. B. das Erstellen, Aktualisieren und Ändern von Berechtigungen, mit anderen Chains zu synchronisieren. Es kann so verstanden werden, dass Wallets auf anderen Chains Verweise auf die Wallet auf dieser Chain sind, wobei Änderungen am Hauptteil mit allen Wallets synchronisiert werden.
• Stellen Sie einheitliche Adressen für Wallets auf jeder Chain durch einen konsistenten Parameter-Deployer-Vertrag sicher.
• Wallets auf verschiedenen Chains können sich auch gegenseitig über AMB aufrufen, was nicht unbedingt von Particle Chain initiiert wird.
• Einheitliches Gas-Token ausstellen. Der Paymaster-Mechanismus implementiert ERC20 als Gasgebühren. Selbst auf einer Chain ohne Gas oder vorgespeicherte Gelder in Paymaster können Cross-Chain-Transaktionen, die einheitliche Gas-Token verbrauchen, auf konformen Chains initiiert werden.

Zusätzlich zu den oben genannten Anwendungsfällen kann Particle Chain auch für folgende Zwecke verwendet werden:

• Das dezentrale Netzwerk für zkWaaS-Proofs und Salzerzeugung.
• Anreizschichten für Bundler über verschiedene Chains hinweg, die Bundlern helfen, eine größere Dezentralisierung zu erreichen.
• Dient als Solver-Netzwerk für das Intent Fusion Protocol.

In der Erzählung von Particle Chain dient der Unified Gas Token als zentrales Wertversprechen für das gesamte Ökosystem:

• Die Funktionalität der Zahlung von Gasgebühren ist eine wiederholt validierte Logik der starken Nachfrage und Werterfassung im Krypto-Bereich.
• Der Unified Gas Token abstrahiert das Konzept der Gasschichten von bestehenden Ökosystemen der öffentlichen Ketten. Diese Abstraktion kann ohne Particle Chain und Wallets nicht erreicht werden. Daher stellt der Unified Gas Token eine Wertschöpfung für das gesamte Partikel-Ökosystem dar. Mit der Gasschicht stehen die Benutzerinteraktion, das Wachstum und der Wert des nativen Tokens über verschiedene Chains hinweg in einer für beide Seiten vorteilhaften Beziehung zum einheitlichen Gas-Token.
• Einheitliches Gas ist auch einer der treibenden Faktoren für das Erreichen von Chainless. Für die Benutzer vereinfacht die Verwendung einer einzigen Währung den Nutzungsprozess und das Verständnis der Kosten erheblich. In Zukunft könnten sich die Benutzer selbst in einem Multi-Chain-Szenario nicht bewusst sein und sich nicht um den Betrieb der zugrunde liegenden Infrastruktur kümmern müssen. Ähnlich wie wir derzeit im Web2 mit Servern interagieren, ohne uns um den Standort von Rechenzentren, ihre Konfigurationen oder die von ihnen verwendeten Sprachen und Datenbanken zu kümmern.
• Benutzer, die von dApps importiert werden, stärken den Unified Gas Token direkt und bieten eine breite Palette von Anwendungsfällen.

Intent Fusion-Protokoll

In der Regel müssen Benutzer bei der Verwendung verschiedener dApps ständig die Nutzungspfade berücksichtigen:

• Wenn auf einem DEX keine Liquidität vorhanden ist, ist es notwendig, einen anderen DEX zu überprüfen.
• Auswahl der am besten geeigneten dApp innerhalb derselben Kategorie für eine Transaktion oder Aufgabe.
• Verstehen Sie das Konzept von "Genehmigen", bevor Sie viele Funktionen verwenden können.
• Wallets entstauben, mehrere Small-Token-Beträge in einen bestimmten Token umwandeln – ein langwieriger Prozess.
• Ausführen mehrerer Schritte in verschiedenen Anwendungen, um ein endgültiges Ziel zu erreichen. Zum Beispiel bei der Kreditvergabe mit hoher Hebelwirkung: Tauschen, Staking, Ausleihen, Token erhalten, dann wieder tauschen, Staking und Leihen.

Der obige Inhalt stellt nur einen Einblick in die aktuelle DeFi-Landschaft dar, und da wir uns in die Ära der weit verbreiteten Einführung verschiedener dApps im Web3 bewegen, kann die Komplexität der Interaktionen unsere Vorstellungskraft weit übersteigen.

Daher bringt das Ersetzen bestimmter Betriebsschritte durch Absichten eine völlig andere Erfahrung für die Benutzer mit sich. Absichten ähneln im Vergleich zu Vorgängen der deklarativen Programmierung im Vergleich zur funktionalen Programmierung. Deklarative Aussagen vermitteln oft ein direktes Gefühl und erfordern nur eine Erklärung, was zu tun ist, ohne sich mit den nachfolgenden Details zu befassen. Dies erfordert verschiedene Ebenen von gekapselten funktionalen Programmieranweisungen in den darunterliegenden Schichten.

In ähnlicher Weise erfordert die Verwendung von Absichten die Unterstützung durch eine Reihe von Einrichtungen. Schauen wir uns den gesamten Prozess an:

1. Benutzer übermitteln ihre Absichten und beschreiben sie in irgendeiner Weise, z. B. in natürlicher Sprache, in Form von RFS (Request For Solver), die an das Solver-Netzwerk gesendet werden. Der Solver ist ein Interpreter für Intents und gängige Solver wie 1inch, ein Aggregator, der nach der optimalen DEX für Benutzer sucht. Im Vergleich zu unserer Vision sind diese Solver jedoch möglicherweise nicht vielseitig und leistungsstark genug.

2. Mehrere Solver antworten und konkurrieren miteinander. Diese Antworten werden in der Intent DSL-Sprache geschrieben und später vom Client in eine Form gewandelt, die für Benutzer leicht verständlich ist. Zu diesen Antworten gehören Input Constraints und Output Constraints, die die Grenzen von Inputs und Outputs definieren. Benutzer können Einschränkungen auch selbst angeben. Ein einfaches Beispiel zum Verständnis: Bei der Verwendung von Swap wird der Benutzer aufgefordert, den Mindestbetrag anzugeben, den er nach dem Swapping erhalten kann, was eine Form der Einschränkung darstellt. Benutzer wählen aus Antworten, die von mehreren Solvern bereitgestellt werden.

3. Unterschreiben Sie die Absicht.

4. Der Solver gibt einen bestimmten Ausführungsvertrags-Executor an und übermittelt die Absicht an den Antwortvertrags-Reactor.

5. Der Reactor sammelt die erforderlichen Eingaben (z. B. ein bestimmtes Asset) aus dem Konto des Benutzers, übermittelt die Absicht an den Executor und gibt nach dem Aufruf des entsprechenden Logikvertrags die Ausgabe der Transaktion an den Reactor zurück. Der Reactor prüft die Einschränkungen und gibt die Ausgabe an den Benutzer zurück, wenn sie korrekt sind.

Wir können uns diesen Prozess so vorstellen, als würden Sie ChatGPT Ihre Anforderungen erklären. Unabhängig davon, wie komplex die Anforderungen sind, kann es ein Endergebnis für Sie generieren. Solange Sie mit dem Ergebnis zufrieden sind, können Sie es direkt verwenden, ohne sich um den zugrunde liegenden Prozess zu kümmern.

Schlussfolgerung

Particle Network hat eine umfassende Lösung vorgeschlagen: Durch die integrierte Form von zkWaaS, Particle Chain und Intent Fusion Protocol erreicht es Web2 OAuth-Datenschutzanmeldung, Datenschutztransaktionen, Omnichain-Kontoabstraktion und ein absichtsbasiertes Transaktionsparadigma. Jede Funktion adressiert einen Teil der Schwachstellen bei der Web3-Nutzung. Diese Fortschritte und Optimierungen werden als Grundlage für die zukünftige weit verbreitete Einführung von Web3-Produkten und -Technologien dienen. In Bezug auf Ökosystem und Geschäftsmodelle die Übernahme des B2B2C-Paradigmas, die Nutzung von WaaS als Einstiegspunkt, um die Skalierbarkeit und Standardisierung der gesamten Produktkette voranzutreiben, der gemeinsame Aufbau des Ökosystems mit dApp-Entwicklern und die gemeinsame Schaffung einer niedrigschwelligen, erlebnisreichen Web3-Welt für die Nutzer.

Natürlich gibt es in verschiedenen Projekten unterschiedliche Interpretationen des Implementierungspfads für die Masseneinführung von Web3. Abgesehen von der Überprüfung spezifischer Projekte hoffen wir, verschiedene Lösungen zu verwenden, um das Verständnis für die Onboarding-Reibungsverluste, mit denen Web3 derzeit konfrontiert ist, die Berücksichtigung der Bedürfnisse und Probleme der Benutzer sowie die Überlegungen für die kollektive Verbindung und Entwicklung des gesamten Ökosystems hervorzuheben.

Verzichtserklärung:

1. Dieser Artikel ist ein Nachdruck von [极客 Web3], Alle Urheberrechte liegen beim ursprünglichen Autor [雾月,极客Web3]. Wenn es Einwände gegen diesen Nachdruck gibt, 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.