Interpretation von SCP: Ein Paradigmenwechsel in der vertrauenslosen Infrastruktur jenseits des Rollups

Einführung:

Dieser Artikel bietet eine vorausschauende Einführung in ein etwas unkonventionelles Web3-Infrastruktur-Designparadigma: das Storage-based Consensus Paradigm (SCP). Dieses Designmodell weicht in der Theorie signifikant von mainstreammodularen Blockchain-Lösungen wie Ethereum Rollups ab. Es zeigt jedoch eine hohe Machbarkeit in Bezug auf Einfachheit bei der Implementierung und Integration mit Web2-Plattformen. SCP beabsichtigt nicht, sich auf einen engen Realisierungspfad wie Rollups zu beschränken. Stattdessen zielt es darauf ab, einen breiteren und offeneren Rahmen anzunehmen, um Web2-Plattformen mit Web3-Infrastruktur zu verschmelzen. Dieser Ansatz kann als äußerst einfallsreich und innovativ angesehen werden.

Lassen Sie uns eine öffentliche Blockchain-Skalierungslösung mit den folgenden Merkmalen entwerfen:

• Es hat Geschwindigkeiten, die mit herkömmlichen Web2-Anwendungen oder Börsen vergleichbar sind und jede öffentliche Blockchain, Layer 2 (L2), Rollups, Sidechains usw. bei weitem übertreffen.

• Es fallen keine Gasgebühren an, und die Nutzungskosten sind fast null.

• Hohe finanzielle Sicherheit, die zentralisierte Einrichtungen wie Börsen übertrifft, aber unter Rollups liegt, jedoch größer oder gleich den Sidechains ist.

• Eine Benutzererfahrung, die identisch mit Web2 ist, ohne Kenntnisse von öffentlichen und privaten Blockchain-Schlüsseln, Wallets, Infrastruktur usw. zu erfordern.

Eine solche Lösung ist in der Tat sehr aufregend: Einerseits hat sie im Wesentlichen den Höhepunkt in Bezug auf Skalierung erreicht; andererseits legt sie eine solide Grundlage für die Massenadoption von Web3, wodurch im Grunde die Kluft zwischen den Benutzererfahrungen von Web2 und Web3 überbrückt wird. Allerdings scheinen wir nur wenige umfassende Lösungen wie diese zu haben, da Mainstream-Diskussionen und -Praktiken tatsächlich zu wenige sind.

Wir verwenden das bekannte Thema der Skalierung als Einführung oben, aber SCP ist nicht auf Skalierungsanwendungsfälle beschränkt. Seine Designinspiration kommt tatsächlich von Skalierungslösungen und Community-Diskussionen öffentlicher Blockchains wie Bitcoin und Ethereum. Seine Vision und praktische Anwendung besteht darin, eine neue Generation von vertrauenslosen Infrastrukturen, sogar Rechenplattformen, die nicht auf Blockchain-Strukturen basieren, aufzubauen.

SCP Grundkomponenten und Arbeitsprinzipien

Im Allgemeinen hat SCP, wie von den Ethereum- und Celestia-Communities erwähnt, verschiedene Module wie eine Datenverfügbarkeitsschicht, eine Ausführungsschicht, eine Konsensschicht und eine Abwicklungsschicht, die als „modulare Blockchain“ bezeichnet wird.

• Dataverfügbarkeitsschicht: Wird von einer weit verbreiteten und gut getesteten öffentlichen Blockchain oder Speichereinrichtungen, die als Dataverfügbarkeitsschicht dienen, wie Ethereum, Arweave, Celestia, usw., verwaltet.

• Ausführungsschicht: Ein Server, der verwendet wird, um Benutzertransaktionen zu empfangen und auszuführen, während er auch die signierten Transaktionsdaten chargenweise an die DA-Schicht übermittelt, ähnlich den Sequenzern in Rollups. Die Ausführungsschicht benötigt jedoch nicht zwangsläufig eine Blockchain-ähnliche Kettenstruktur; sie kann vollständig ein Web2-Datenbank + Rechensystem sein, aber das gesamte Rechensystem muss Open Source und transparent sein.

• Konsensschicht: Besteht aus einer Gruppe von Knoten, die Daten, die von der Ausführungsschicht an die DA-Schicht übermittelt wurden, abrufen und denselben Algorithmus wie die Ausführungsschicht verwenden, um diese Daten zu verarbeiten. Es wird bestätigt, ob die Ausgabe der Ausführungsschicht korrekt ist und als Redundanz für die Ausführungsschicht als Notfallwiederherstellung dienen kann. Benutzer können auch Daten lesen, die von den Knoten der Konsensschicht zurückgegeben wurden, um sicherzustellen, dass in der Ausführungsschicht kein betrügerisches Verhalten vorliegt.

• Abwicklungsschicht: Besteht aus einer Gruppe von Knoten und Verträgen oder Adressen auf anderen Ketten, die für die Verwaltung von Benutzereinlagen in SCP oder Abhebungen aus SCP verantwortlich sind, die dem Betrieb von Cross-Chain-Brücken ähnlich sind. Die Knoten der Abwicklungsschicht steuern die Abhebungsfunktion der Einlagenadresse über Multisig-Verträge oder TSS-basierte Adressen. Benutzer übertragen Vermögenswerte an eine bestimmte Adresse auf ihrer Kette; für Abhebungen senden sie eine Anfrage, und nachdem die Knoten der Abwicklungsschicht die Daten gelesen haben, geben sie die Vermögenswerte über Multisig oder TSS frei. Das Sicherheitsniveau der Abwicklungsschicht hängt von dem verwendeten Cross-Chain-Mechanismus ab.

SC-Praxisrahmen

Wir können das SC-Paradigma durch den folgenden Rahmen verstehen. Ein Produkt, das dem SC-Paradigma entspricht, kann Hauptmerkmale wie Einzahlung, Überweisung, Abhebung, Tausch usw. haben und kann weiter ausgebaut werden. Im Folgenden finden Sie ein schematisches Diagramm eines solchen Produkts:

• Die DA-Schicht dieses Projekts verwendet die permanente Speichereinrichtung Arweave, die durch den großen Kreis im Diagramm dargestellt wird.
• Der Koordinator oder die Ausführungsebene ist der Ort, an dem Benutzer ihre Transaktionen einreichen. Der Koordinator führt Berechnungen durch, zeigt die Ergebnisse an und gruppiert dann die ursprünglichen Eingabedaten der Benutzer und reicht sie an die DA-Ebene ein.
• Der Detector zieht die vom Koordinator bei Arweave eingereichten Originaltransaktionsdaten heran und validiert die Daten und Ergebnisse mit demselben Algorithmus wie der Koordinator. Der Client des Detectors ist ebenfalls Open Source, sodass ihn jeder ausführen kann.
• Die Wächter, eine Gruppe von Detektoren, verwalten das Mehrfachsignatursystem des Abhebungssystems. Sie validieren und autorisieren Abhebungsanfragen basierend auf Transaktionsdaten. Darüber hinaus sind die Wächter für das Unterzeichnen von Vorschlägen verantwortlich.

Wir können sehen, dass der Konsens, der vom gesamten System erreicht wird, vollständig off-chain ist, was der Kern des Speicher-Konsens-Paradigmas ist. Es verzichtet auf das für Blockchains typische Knotenkonsenssystem und befreit die Ausführungsschicht von dem lästigen Konsenskommunikations- und Bestätigungsprozess. Dadurch kann es effizient als einzelner Server funktionieren und damit nahezu unbegrenzte TPS und Kosteneffizienz erreichen. Dieser Aspekt ähnelt sehr Rollups, aber SCP (Speicher-Konsens-Paradigma) geht einen anderen Weg als Rollups. SCP versucht, von einem skalierungsspezifischen Anwendungsfall zu einem neuen Übergangsmodus von Web2 zu Web3 überzugehen. Der oben genannte Koordinator ist ein Server, aber das bedeutet nicht, dass der Koordinator willkürlich handeln kann. Ähnlich dem Sequenzer in Rollups kann nach dem Stapelübermitteln der Originaldaten von Benutzern auf Arweave jeder das Detector-Programm ausführen, um es zu überprüfen und mit dem vom Koordinator zurückgegebenen Zustand zu vergleichen. In gewisser Weise ähnelt dies dem Ansatz von Inschrift-Anwendungen. In dieser Architektur stellt ein zentralisierter Server oder eine Datenbank keine grundlegende Herausforderung dar. Dies ist ein weiterer Punkt des SCP-Paradigmas: Es entkoppelt die Konzepte von „Zentralisierung“ und „einzelnem Entität“ - in einem vertrauenslosen System können zentralisierte Komponenten vorhanden sein, sogar eine Kernkomponente, ohne die Gesamtvertrauenslosigkeit des Systems zu beeinträchtigen.

Wir können diesen Slogan ausrufen: "Die nächste Generation der vertrauenslosen Infrastruktur muss nicht unbedingt auf Konsensprotokollen beruhen, sondern sollte ein Open-Source-System mit einem Peer-to-Peer (P2P) Knotennetzwerk sein." Die ursprüngliche Absicht, Blockchain zu erfinden und zu nutzen, bestand darin, Dezentralisierung, Konsistenz des Hauptbuchs, Unveränderlichkeit und Nachverfolgbarkeit zu erreichen, wie im Bitcoin-Whitepaper explizit dargelegt. Nach Ethereum, ob es sich um die alten Lösungen zur Erweiterung öffentlicher Ketten, Rollups oder modulare Blockchains handelt, gab es eine festgelegte Denkweise: Was wir schaffen, muss entweder eine Blockchain (bestehend aus Konsensprotokollen der Knoten) oder etwas Ähnliches wie Rollup sein (das wie eine Kette mit Blockchain-Datenstrukturen aussieht, jedoch ohne direkten Austausch von Konsensnachrichten zwischen den Knoten). Nun, im Rahmen des SCP (Stellar Consensus Protocol) basierten Frameworks, ist offensichtlich, dass es auch ohne eine Blockchain möglich ist, Dezentralisierung, Konsistenz des Hauptbuchs, Unveränderlichkeit und Nachverfolgbarkeit zu erreichen, vorausgesetzt, dass es mehr explizite Implementierungsdetails gibt.

Ausführungsschicht

Die Ausführungsschicht ist entscheidend für das gesamte System, da sie die Rechenprozesse des Systems übernimmt und die Arten von Anwendungen bestimmt, die im System ausgeführt werden können.

Unendliche Möglichkeiten im Ausführungsumfeld

Theoretisch kann die Ausführungsumgebung in der Ausführungsschicht jede Form annehmen, mit endlosen Möglichkeiten, je nachdem, wie die Entwickler des Projekts ihr Projekt positionieren:

1. Börsen. Unter Verwendung von SCP kann man eine öffentliche, transparente Börse mit hohen Transaktionen pro Sekunde (TPS) erstellen, die die schnellen, kostenfreien Funktionen einer zentralisierten Börse (CEX) und die Dezentralisierung einer dezentralisierten Börse (DEX) kombiniert. Hier verschwimmt die Unterscheidung zwischen CEX und DEX.

2. Zahlungsnetzwerke. Ähnlich wie Alipay, PayPal, etc.

3. Virtuelle Maschinen/Blockchains, die ladefähige Programme/Verträge unterstützen. Jeder Entwickler kann jede Anwendung darauf bereitstellen, die alle Benutzerdaten mit anderen Programmen teilt und gemäß Benutzeranweisungen arbeitet.

Das Designmuster von SCP, das jede Ausführungsumgebung unterstützt, hat seine einzigartigen Vorteile: Es ist nicht erforderlich, auf Komponenten mit historischer Last zu vertrauen, insbesondere auf Konzepte wie die „Kontenabstraktion“, die einzigartig für die Ethereum-Community ist. Für SCP ist das Konzept der Kontenabstraktion von Natur aus unnötig. In der SCP-Architektur gibt es kein Konzept der Kontenabstraktion – Sie können frei Web2-Standardkonten und Blockchain-Konten usw. übernehmen. Aus dieser Perspektive müssen viele reife Web2-Anwendungsfälle nicht neu durchdacht und wiederaufgebaut werden, um direkt auf SCP anwendbar zu sein. Dieser Aspekt könnte der Punkt sein, an dem SCP einen Vorteil gegenüber Rollups hat.

Transparenz und Asymmetrie

Das Kontosystem wurde oben erwähnt, und aufmerksame Leser haben möglicherweise bemerkt, dass das SCP (Stellar Consensus Protocol) zwar das Web2-Kontosystem nutzen kann, die Verwendung wie es ist jedoch problematisch erscheint. Dies liegt daran, dass das gesamte System vollständig transparent ist! Die direkte Anwendung des Benutzer-Server-Interaktionsmodells von Web2 führt zu schwerwiegenden Sicherheitsproblemen und macht das System völlig unsicher. Lassen Sie uns überprüfen, wie das traditionelle Server-Benutzer-Modell funktioniert:

1. Kontoregistrierung: Benutzer geben auf der Registrierungsseite der Anwendung einen Benutzernamen und ein Passwort ein. Um das Passwort des Benutzers zu schützen, wird es vom Server beim Empfang durch eine Hashfunktion verarbeitet. Um die Komplexität des Hashes zu erhöhen und sich gegen Rainbow-Table-Angriffe zu verteidigen, wird normalerweise eine zufällig generierte Zeichenfolge (bekannt als "Salz") jedem Benutzerpasswort vor dem Hashing angehängt. Der Benutzername, das Salz und der Hash werden im Klartext in der Datenbank des Diensteanbieters gespeichert und nicht öffentlich gemacht. Dennoch sind das Salzen und die sichere Verarbeitung notwendig, um Insiderbedrohungen und Angriffe zu verhindern.

1. Benutzeranmeldung: Benutzer geben ihren Benutzernamen und ihr Passwort im Anmeldeformular ein. Das System vergleicht den verarbeiteten Passworthash mit dem gespeicherten Hash in der Datenbank. Wenn die beiden Hashes übereinstimmen, deutet dies darauf hin, dass der Benutzer das richtige Passwort angegeben hat, und der Anmeldevorgang wird fortgesetzt.

2. Betriebsauthentifizierung : Nach erfolgreicher Anmeldeüberprüfung erstellt das System eine Sitzung für den Benutzer. Typischerweise werden Sitzungsinformationen auf dem Server gespeichert, und der Server sendet einen Identifier (wie z.B. ein Cookie oder Token) an den Browser oder die App des Benutzers. Bei nachfolgenden Operationen muss der Benutzer nicht mehr wiederholt seinen Benutzernamen und sein Passwort eingeben: Der Browser oder die App speichert den Cookie-Identifier und fügt ihn bei jeder Anfrage hinzu, was anzeigt, dass sie die Erlaubnis des Servers, die mit dem Cookie verbunden ist, besitzen.

Lassen Sie uns das typische Web3-Blockchain-Benutzerinteraktionssystem überprüfen:

1. Konto Registrierung: In Wirklichkeit gibt es keinen Konto Registrierungsprozess, noch ein Benutzername-Passwort-System. Konten (Adressen) müssen nicht registriert werden; sie existieren inhärent und wer den privaten Schlüssel kontrolliert, kontrolliert das Konto. Der private Schlüssel wird lokal zufällig vom Wallet generiert und beinhaltet keinen Online-Prozess.

2. Benutzeranmeldung: Die Verwendung der Blockchain erfordert keine Anmeldung. Die meisten dApps haben keinen Anmeldeprozess, sondern verbinden sich stattdessen mit einer Wallet. Einige dApps können nach der Verbindung mit einer Wallet jedoch verlangen, dass Benutzer eine Verifizierung unterzeichnen, um sicherzustellen, dass sie tatsächlich den privaten Schlüssel besitzen, anstatt nur eine Wallet-Adresse an die Benutzeroberfläche geschickt zu haben.

3. Betriebsauthentifizierung: Benutzer übermitteln die signierten Daten direkt an Knoten. Nach der Validierung senden die Knoten die Transaktion an das gesamte Blockchain-Netzwerk. Sobald die Operation durch den Konsens des Blockchain-Netzwerks bestätigt wurde, ist sie abgeschlossen.

Der Unterschied zwischen diesen beiden Modi wird durch symmetrische und asymmetrische Faktoren verursacht. In einer Server-Benutzer-Architektur halten beide Parteien das gleiche Geheimnis. In einer Blockchain-Benutzer-Architektur hält nur der Benutzer das Geheimnis. Obwohl die Ausführungsschicht von SCP (Smart Contract Platform) möglicherweise keine Blockchain ist, müssen alle Daten auf eine öffentlich sichtbare DA (Data Availability) -Ebene synchronisiert werden. Daher müssen die Anmelde- und Betriebsverifizierungsmethoden von SCP asymmetrisch sein. Um jedoch umständliche Aktionen wie das Verwalten von privaten Schlüsseln und die Verwendung von Brieftaschen zu vermeiden, die aufgrund einer schlechten Benutzererfahrung die weit verbreitete Übernahme behindern könnten, besteht eine starke Nachfrage nach traditionellen ID-Passwort- oder OAuth-Authentifizierungsanmeldungen von Drittanbietern in Anwendungen, die auf SCP aufgebaut sind. Wie also kombinieren wir die beiden? Aufgrund der asymmetrischen Natur der Kryptografie und der Zero-Knowledge-Beweise sehe ich zwei mögliche Lösungen vor:

• Wenn ein ID-Passwort-System gewünscht wird, könnte das Passwort-Speichermodul aus SC ausgeschlossen werden, sodass es für andere unsichtbar ist. Intern verwendet die SC-Ausführungsschicht weiterhin die öffentlich-privaten Schlüsselkonten und die operationale Logik der Blockchain, ohne Registrierung oder Anmeldung. Die Benutzer-ID würde tatsächlich einem privaten Schlüssel entsprechen. Dieser private Schlüssel sollte natürlich nicht vom Projekt gespeichert werden. Eine machbare Lösung besteht darin, 2-3 MPC (Multi-Party Computation) zu verwenden, um das Problem der zentralisierten Speicherung zu lösen, ohne den Benutzer mit der Verwendung eines privaten Schlüssels zu belasten.
• Bei der Verwendung der OAuth-Anmeldung kann JWT (JSON Web Token) zur Identitätsauthentifizierung verwendet werden. Diese Methode ist etwas zentralisierter als die zuvor genannte, da sie im Wesentlichen auf den von Web2-Riesen bereitgestellten Login-Diensten von Drittanbietern zur Identitätsprüfung beruht.
• Beim ersten Mal, dass ein Third-Party-Login verwendet wird, werden die JWT-Felder, die Benutzer- und Dienstanbieteridentitäten darstellen, im System registriert. Bei nachfolgenden Benutzeroperationen wird der Betriebsbefehl als öffentliche Eingabe behandelt, während der JWT als Ganzes ein geheimer Zeuge ist, der ZKP (Zero-Knowledge Proof) verwendet, um jede der Benutzertransaktionen zu überprüfen.
• Jedes JWT hat eine Ablaufgrenze, und Benutzer werden beim nächsten Mal, wenn sie sich anmelden, ein neues JWT anfordern, sodass kein dauerhafter Speicher erforderlich ist. Darüber hinaus stützt sich dieses System auf JWK (JSON Web Key), der als öffentlicher Schlüssel verstanden werden kann, der von den Giganten für die JWK-Verifizierung bereitgestellt wird. Wie JWK dezentral in das System eingegeben wird und Methoden für zukünftige private Schlüsselrotation sind ebenfalls eine Erkundung wert.

Unabhängig von der verwendeten Methode sind beide in Bezug auf Entwicklung und Betrieb kostspieliger als herkömmliche Methoden, aber dies ist ein notwendiger Preis für Dezentralisierung. Natürlich ist es möglich, ohne diese Designs vorzugehen, wenn das Projekt extreme Dezentralisierung nicht für notwendig hält oder unterschiedliche Meilensteine in verschiedenen Entwicklungsstadien hat, da Dezentralisierung nicht schwarz-weiß ist, sondern in einem Graubereich existiert.

Datenschutzprobleme

Die oben genannten Transparenzprobleme betreffen nicht nur das Benutzerinteraktionsparadigma, sondern wirken sich auch auf Benutzerdaten aus. Benutzerdaten werden direkt offengelegt. Während dies in der Blockchain kein Problem darstellt, ist es in einigen Anwendungen inakzeptabel. Daher können Entwickler auch private Transaktionssysteme aufbauen.

Gebühren

Wie die Ausführungsschicht Gebühren erhebt, ist ein weiterer interessanter Punkt. Das Einreichen von Daten an die Datenschicht für Datenverfügbarkeit (DA) verursacht ebenfalls Kosten, einschließlich des Betriebs eigener Server. Der Hauptzweck der Erhebung von Gasgebühren in traditionellen Blockchains besteht darin, zu verhindern, dass Benutzer das Netzwerk mit zahlreichen redundanten Transaktionen überfluten, wobei die Transaktionsabwicklung auf Basis von Gasgebühren sekundär ist. In Web2 gibt es keine ähnlichen Bedenken, nur grundlegende Konzepte wie Fluten und DDoS-Angriffe. Die Ausführungsschicht kann verschiedene Gebührenstrategien anpassen, wie z.B. vollständig kostenlos oder teilweise belastet sein oder von anderen Aktivitäten wie dem Maximal Extractable Value (MEV) profitieren, was bereits sehr ausgereift bei Sequenzern und Markttätigkeiten ist.

Zensurresistenz

Die Ausführungsebene besitzt keine Zensurresistenz und kann theoretisch Benutzertransaktionen unbegrenzt ablehnen. Bei Rollups kann die Zensurresistenz durch die obligatorische Aggregationsfunktion des L1-Vertrags sichergestellt werden, während Sidechains oder öffentliche Chains vollständig verteilte Blockchain-Netzwerke sind, was Zensur erschwert. Derzeit gibt es keine klare Lösung, um das Problem der Zensurresistenz anzugehen, was ein Problem im SCP-Paradigma darstellt.

Konsensschicht

Diese Schicht besteht aus lose verbundenen Knoten, die nicht aktiv ein Netzwerk bilden, ist also keine strikte Konsensschicht, sondern bestätigt lediglich den aktuellen Zustand der Ausführungsschicht nach außen (z. B. Benutzer). Wenn Sie z. B. Zweifel am Betriebsstatus dieser Knoten haben, können Sie ihren Detektor-Client herunterladen, der den gleichen Programmcode wie der Koordinator ausführt. Da die Daten jedoch ähnlich wie bei Rollups in Batches übermittelt werden, ist der Status, der von der Ausführungsschicht an die Benutzer zurückgegeben wird, immer aktueller als der auf der DA-Schicht. Dabei geht es um die Frage der Vorabbestätigung: Die Ausführungsschicht liefert den Benutzern Vorabbestätigungsergebnisse, weiche Finalitätsergebnisse, da sie noch nicht an die DA-Schicht übermittelt wurden; während die Konsensebene eine harte Endgültigkeit bietet. Die Nutzer mögen darüber nicht besonders besorgt sein, aber für Anwendungen wie Cross-Chain-Bridges muss eine harte Finalität eingehalten werden. Zum Beispiel vertraut das Ein- und Auszahlungssystem von Börsen nicht den Daten, die von Rollup-Sequenzern außerhalb der Kette übertragen werden. Sie warten, bis diese Daten auf Ethereum sind, bevor sie akzeptiert werden. Neben der Bestätigung der Ergebnisse spielt die Konsensschicht auch eine entscheidende Rolle als Katastrophenredundanz für die Ausführungsschicht. Wenn die Ausführungsschicht dauerhaft aufhört zu arbeiten oder böswillig handelt, kann theoretisch jede Konsensschicht die Arbeit der Ausführungsschicht übernehmen und Benutzeranfragen akzeptieren. Wenn eine solch schwerwiegende Situation eintritt, sollte die Community stabile und zuverlässige Knoten als Server der Ausführungsschicht wählen.

Abwicklungsschicht

Da SCP kein Rollup ist, kann es keine vertrauenslosen Abhebungen wie die Abrechnungsschicht von Rollup erreichen, die ausschließlich auf Kryptographie und Smart Contract-Code basiert, ohne manuelle Eingriffe. Das Sicherheitsniveau von SCP Cross-Chain-Brücken ist dasselbe wie das von Sidechain oder Third-Party-Witness-Cross-Chain-Brücken, die sich auf autorisierte Multi-Signatur-Manager verlassen, um Vermögenswerte freizugeben, bekannt als der Zeugenmodus.

Die Dezentralisierung der Zeugenbrücke so weit wie möglich ist ein Forschungsthema für viele Cross-Chain-Brücken. Aufgrund von Platzbeschränkungen wird dies hier nicht näher erläutert. Eine gut konzipierte SCP-Plattform muss in der Praxis auch über renommierte dezentrale Brücken-Mehrparteien-Signaturpartner verfügen. Einige könnten fragen, warum SCP keine Kette mit Smart Contracts als DA-Schicht verwendet? Dies würde vertrauenslose Abwicklungsschichten auf Verträgen ermöglichen. Langfristig kann SCP, wenn einige technische Schwierigkeiten überwunden werden, wenn die DA-Schicht auf Ethereum oder anderen vertragsfähigen DA-Schichten platziert und entsprechende Verifikationsverträge erstellt werden können, auch die gleiche Abwicklungssicherheit wie Rollup erreichen, ohne die Notwendigkeit von Mehrparteien-Signaturen.

In der Praxis ist dies möglicherweise nicht die beste Wahl:

1. Ethereum ist nicht speziell für die Datenspeicherung konzipiert und im Vergleich zu Blockchains, die ausschließlich der Datenspeicherung gewidmet sind, ziemlich teuer. Für das SCP-Paradigma ist ein ausreichend niedriger oder fester Speicherpreis entscheidend. Nur so kann es Web2-Level-Durchsatz unterstützen.

2. Die Entwicklung von Nachweissystemen ist äußerst schwierig, da man in SCP nicht nur die EVM (Ethereum Virtual Machine) simulieren, sondern auch jede beliebige Logik implementieren kann. Angesichts des aktuellen Standes von Projekten wie Optimism, wo ihre Betrugsnachweise noch nicht gestartet sind, und der Komplexität bei der Entwicklung von zkEVM (zero-knowledge Ethereum Virtual Machine), kann man sich die immense Schwierigkeit bei der Implementierung verschiedener Nachweissysteme auf Ethereum vorstellen.

Daher ist die Rollup-Lösung nur in bestimmten Situationen praktisch umsetzbar. Wenn Sie planen, ein breiteres, offeneres System zu implementieren, das sich vom EVM-Framework entfernt, um mehr Web2-Funktionen zu integrieren, ist der Ansatz von Ethereum Rollup nicht geeignet. SCP ist nicht nur ein Erweiterungsplan für eine bestimmte öffentliche Blockchain, sondern eine umfangreichere Web3-Computing-Plattformarchitektur. Daher muss sie offensichtlich nicht dem Ethereum-Layer2-Ansatz folgen.

Eine Illustration vergleicht SC mit anderen Paradigmen

Haftungsausschluss：

1. Dieser Artikel wurde aus [ wieder abgedrucktGeek Web3]. Alle Urheberrechte gehören dem Originalautor [雾月,极客Web3]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an den Gate LearnTeam, und sie werden es prompt 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 verboten.