Partner der Risikokapitalgesellschaft Multicoin: Warum die modulare Blockchain überbewertet ist

Kyle Samani, Partner bei Multicoin Capital, erläutert 7 Gründe, warum modulare Blockchains überbewertet sind.
Geschrieben von: Kyle Samani, Partner, Multicoin Capital
Zusammengestellt von: Ruffy, Foresight News
In den letzten zwei Jahren konzentrierte sich die Debatte über die Skalierbarkeit der Blockchain auf das zentrale Thema „die Debatte zwischen Modularität und Integration“.
Beachten Sie, dass Diskussionen über Kryptowährungen häufig „einzelne“ und „integrierte“ Systeme vermischen. Die technische Debatte über integrierte Systeme versus modulare Systeme erstreckt sich über 40 Jahre. Diese Diskussion im Bereich der Kryptowährungen sollte durch die gleiche Linse wie die Geschichte betrachtet werden, und dies ist alles andere als eine neue Debatte.
Wenn man Modularität versus Integration betrachtet, ist die wichtigste Designentscheidung, die eine Blockchain treffen kann, das Ausmaß, in dem die Komplexität des Stacks den Anwendungsentwicklern offengelegt wird. Die Kunden von Blockchain sind Anwendungsentwickler, daher sollten endgültige Designentscheidungen ihre Perspektive berücksichtigen.
Heutzutage wird die Modularität weitgehend als die wichtigste Möglichkeit zur Skalierung von Blockchains gefeiert. In diesem Artikel werde ich diese Annahme grundsätzlich in Frage stellen, die kulturellen Mythen und versteckten Kosten modularer Systeme aufdecken und die Schlussfolgerungen teilen, die ich aus den Überlegungen zu dieser Debatte in den letzten sechs Jahren gezogen habe.
Modulare Systeme erhöhen die Entwicklungskomplexität
Der mit Abstand größte versteckte Kostenfaktor modularer Systeme ist die zusätzliche Komplexität des Entwicklungsprozesses.
Modulare Systeme erhöhen die Komplexität, die Anwendungsentwickler bewältigen müssen, erheblich, sowohl im Kontext ihrer eigenen Anwendungen (technische Komplexität) als auch im Kontext der Interaktionen mit anderen Anwendungen (soziale Komplexität).
Im Zusammenhang mit Kryptowährungen ermöglichen modulare Blockchains theoretisch eine stärkere Spezialisierung, allerdings auf Kosten der Schaffung neuer Komplexität. Diese Komplexität (sowohl technischer als auch sozialer Natur) wird an Anwendungsentwickler weitergegeben, was letztendlich die Erstellung von Anwendungen erschwert.
Betrachten Sie zum Beispiel den OP Stack. Derzeit scheint es das beliebteste modulare Framework zu sein. OP Stack zwingt Entwickler dazu, zwischen der Übernahme des Gesetzes der Ketten (was eine große soziale Komplexität mit sich bringt) oder der Abspaltung und getrennten Verwaltung zu wählen. Beide Optionen verursachen für Bauherren eine erhebliche nachgelagerte Komplexität. Wenn Sie sich für einen Fork entscheiden, erhalten Sie dann technische Unterstützung von anderen Ökosystemteilnehmern (CEX, Fiat On-Ramp usw.), denen Kosten entstehen müssen, um neue Technologiestandards einzuhalten? Welche Regeln und Einschränkungen werden Ihnen heute und morgen auferlegt, wenn Sie sich für das Gesetz der Ketten entscheiden?
 Quelle: OSI-Modell
Moderne Betriebssysteme (OS) sind große, komplexe Systeme mit Hunderten von Subsystemen. Moderne Betriebssysteme verarbeiten die Schichten 2–6 im obigen Diagramm. Dies ist ein klassisches Beispiel für die Integration modularer Komponenten zur Verwaltung der Stack-Komplexität, der Anwendungsentwickler ausgesetzt sind. Anwendungsentwickler möchten sich mit nichts unterhalb der Schicht 7 befassen, weshalb es Betriebssysteme gibt: Das Betriebssystem verwaltet die Komplexität der darunter liegenden Schichten, sodass sich Anwendungsentwickler auf Schicht 7 konzentrieren können. Daher sollte Modularität kein Selbstzweck sein, sondern ein Mittel zum Zweck.
Jedes wichtige Softwaresystem auf der Welt – Cloud-Backends, Betriebssysteme, Datenbank-Engines, Spiele-Engines usw. – ist hochgradig integriert und besteht aus vielen modularen Subsystemen. Softwaresysteme sind in der Regel hochintegriert, um die Leistung zu maximieren und die Entwicklungskomplexität zu reduzieren. Dasselbe gilt auch für Blockchain.
Ethereum reduziert übrigens die Komplexität, die während der Bitcoin-Fork-Ära 2011–2014 entstanden ist. Befürworter der Modularität betonen häufig das Open Systems Interconnection (OSI)-Modell und argumentieren, dass Datenverfügbarkeit (DA) und -ausführung getrennt werden sollten. Dieses Argument wird jedoch weitgehend missverstanden. Ein richtiges Verständnis des vorliegenden Problems führt zu der gegenteiligen Schlussfolgerung: dem Argument, dass es sich bei OSI eher um ein integriertes als um ein modulares System handelt.
Modulare Ketten können Code nicht schneller ausführen
Eine gängige Definition der „modularen Kette“ ist konstruktionsbedingt die Trennung von Datenverfügbarkeit (DA) und Ausführung: Ein Knotensatz ist für die DA verantwortlich, während ein anderer Knotensatz (oder mehrere Knotensätze) für die Ausführung verantwortlich sind. Die Knotensammlungen müssen sich nicht überlappen, können es aber.
In der Praxis führt die Trennung von DA und Ausführung nicht zwangsläufig zu einer Verbesserung der Leistung von beiden; vielmehr muss irgendwo auf der Welt eine bestimmte Hardware die DA durchführen und irgendwo auf der anderen Hardware muss die Ausführung implementiert werden. Durch die Trennung dieser Funktionen wird die Leistung keiner dieser Funktionen verbessert. Während die Trennung die Rechenkosten senken kann, kann sie nur durch eine Zentralisierung der Ausführung gesenkt werden.
Um es noch einmal zu wiederholen: Unabhängig von der modularen oder integrierten Architektur muss irgendwo Hardware die Arbeit erledigen, und die Trennung von DA und Ausführung auf separater Hardware führt nicht automatisch zu einer Beschleunigung oder Erhöhung der Gesamtsystemkapazität.
Einige argumentieren, dass die Modularität die parallele Ausführung mehrerer EVMs im Rollup-Verfahren ermöglicht, wodurch die Ausführung horizontal skaliert werden kann. Obwohl dies theoretisch richtig ist, betont diese Ansicht tatsächlich die Einschränkungen des EVM als Single-Thread-Prozessor und nicht die Grundvoraussetzung der Trennung von DA und Ausführung im Zusammenhang mit der Skalierung des gesamten Systemdurchsatzes.
Modularität allein verbessert den Durchsatz nicht.
Modularität erhöht die Transaktionskosten für Benutzer
Per Definition ist jedes L1 und L2 ein unabhängiges Vermögensbuch mit einem eigenen Status. Diese separaten Zustandsteile können kommunizieren, allerdings mit längeren Transaktionslatenzen und höherer Komplexität für Entwickler und Benutzer (über kettenübergreifende Brücken wie LayerZero und Wormhole).
Je mehr Vermögensbücher es gibt, desto fragmentierter wird der globale Zustand aller Konten. Dies ist sowohl für Ketten als auch für Benutzer über mehrere Ketten hinweg schrecklich. Die Zersplitterung des Staates kann eine Reihe von Konsequenzen haben:
Reduzierte Liquidität, was zu einem höheren Trading-Slippage führt;
Höherer Gesamtgasverbrauch (kettenübergreifende Transaktionen erfordern mindestens zwei Transaktionen in mindestens zwei Vermögensbüchern);
Erhöhte Doppelzählungen über Asset-Ledger hinweg (wodurch der Gesamtsystemdurchsatz verringert wird): Wenn sich der Preis von ETH-USDC auf Binance oder Coinbase bewegt, ergeben sich Arbitragemöglichkeiten für jeden ETH-USDC-Pool über alle Asset-Ledger hinweg (Sie können sich leicht vorstellen, dass a Welt, in der es jedes Mal, wenn sich der ETH-USDC-Preis auf Binance oder Coinbase ändert, mehr als 10 Transaktionen in den verschiedenen Vermögensbüchern gibt. Die Beibehaltung der Preise in einem fragmentierten Zustand ist bei der effizienten Nutzung des Blockes äußerst gering.
Es ist wichtig, sich darüber im Klaren zu sein, dass die Erstellung weiterer Vermögensbücher die Kosten in all diesen Dimensionen, insbesondere im Zusammenhang mit DeFi, erheblich erhöht.
Der primäre Input für DeFi ist der On-Chain-Status (d. h. wem welche Vermögenswerte gehören). Wenn Teams Anwendungsketten/Rollups starten, erzeugen sie natürlich eine Zustandsfragmentierung, die für DeFi sehr schädlich ist, da sowohl die Entwickler die Komplexität der Anwendung verwalten (Brücken, Wallets, Verzögerungen, kettenübergreifendes MEV usw.) als auch die Benutzer ( Slippage, Abwicklungsverzögerungen).
Die idealste Voraussetzung für DeFi ist, dass Vermögenswerte in einem einzigen Vermögensbuch ausgegeben und innerhalb einer einzigen Staatsmaschine gehandelt werden. Je größer das Asset-Ledger, desto mehr Komplexität müssen Anwendungsentwickler verwalten und desto höher sind die Kosten, die Benutzer tragen müssen.
App Rollup wird keine neuen Monetarisierungsmöglichkeiten für Entwickler schaffen
Befürworter von AppChain/Rollup glauben, dass Anreize Anwendungsentwickler dazu veranlassen werden, Rollups zu entwickeln, anstatt auf L1 oder L2 aufzubauen, damit Anwendungen selbst den MEV-Wert erzielen können. Diese Idee ist jedoch fehlerhaft, da die Ausführung eines Anwendungs-Rollups nicht die einzige Möglichkeit ist, MEV wieder in Tokens der Anwendungsebene zu erfassen, und in den meisten Fällen auch nicht die beste Möglichkeit. Token der Anwendungsschicht können MEV wieder in ihre eigenen Token einfangen, indem sie einfach die Logik in Smart Contracts in der gemeinsamen Kette codieren. Betrachten wir einige Beispiele:
Liquidation: Wenn Compound oder Aave DAO einen Teil des an den Liquidations-Bot fließenden MEV erfassen möchten, können sie einfach ihre jeweiligen Verträge aktualisieren, sodass ein Teil der derzeit an den Liquidator fließenden Gebühren an ihre eigene DAO gezahlt wird, ohne dass dies erforderlich ist für eine neue Kette/Rollup .
Oracle: Oracle-Tokens können MEV erfassen, indem sie Back-Running-Dienste bereitstellen. Neben Preisaktualisierungen kann Oracle auch beliebige On-Chain-Transaktionen bündeln, die garantiert sofort nach einer Preisaktualisierung ausgeführt werden. Daher können Orakel MEV erfassen, indem sie Back-Running-Dienste für Suchende, Block-Builder usw. bereitstellen.
NFT-Minting: Beim NFT-Minting gibt es viele Scalping-Bots. Dies kann leicht abgemildert werden, indem einfach die Umverteilung sinkender Gewinne kodiert wird. Wenn beispielsweise jemand versucht, seinen NFT innerhalb von zwei Wochen nach der NFT-Prägung weiterzuverkaufen, gehen 100 % des Erlöses an den Emittenten oder das DAO zurück. Dieser Prozentsatz kann sich im Laufe der Zeit ändern.
Es gibt keine allgemeingültige Antwort auf die Erfassung von MEV in Token der Anwendungsschicht. Mit ein wenig Überlegung können Anwendungsentwickler MEV jedoch problemlos wieder in ihre eigenen Token in der Universalkette einfangen. Die Einführung einer völlig neuen Kette ist einfach unnötig und würde den Entwicklern zusätzliche technische und soziale Komplexität sowie mehr Bedenken hinsichtlich des Geldbeutels und der Liquidität der Benutzer bringen.
Anwendungs-Rollup kann anwendungsübergreifende Überlastungsprobleme nicht lösen
Viele glauben, dass Application Chain/Rollup sicherstellt, dass Anwendungen nicht durch Gasspitzen beeinträchtigt werden, die durch andere Aktivitäten in der Kette, wie beispielsweise das beliebte NFT-Minting, verursacht werden. Diese Ansicht ist teilweise richtig, aber größtenteils falsch.
Dies ist ein historisches Problem und die Hauptursache ist die Single-Threaded-Natur der EVM, nicht weil es keine Trennung von DA und Ausführung gibt. Alle L2 zahlen eine Gebühr an L1, und die L1-Gebühren können jederzeit erhöht werden. Während des Memecoin-Booms Anfang dieses Jahres überstiegen die Transaktionsgebühren für Arbitrum und Optimism kurzzeitig 10 US-Dollar. Auch die Gebühren von Optimism sind nach der Einführung von Worldcoin kürzlich in die Höhe geschossen.
Die einzigen Lösungen zur Bewältigung von Gebührenspitzen sind: 1) L1-DA maximieren, 2) den Gebührenmarkt so weit wie möglich verfeinern:
Wenn L1 ressourcenbeschränkt ist, werden Nutzungsspitzen in einzelnen L2s an L1 weitergegeben, was zu höheren Kosten für alle anderen L2s führt. Daher ist die Anwendungskette/das Rollup nicht immun gegen Gasspitzen.
Die Koexistenz zahlreicher EVM L2s ist nur eine grobe Möglichkeit, den Markt für Lokalisierungsgebühren auszuprobieren. Es ist besser, als den Gebührenmarkt in einem einzigen EVM L1 zusammenzufassen, löst aber nicht das Kernproblem. Wenn Sie erkennen, dass die Lösung ein lokalisierter Gebührenmarkt ist, ist der logische Endpunkt ein Gebührenmarkt pro Staat (und nicht ein Gebührenmarkt pro L2).
Andere Ketten sind bereits zu diesem Schluss gekommen. Solana und Aptos lokalisieren natürlich die Gebührenmärkte. Dies erforderte über viele Jahre umfangreiche Engineering-Arbeiten für die jeweiligen Ausführungsumgebungen. Die meisten Modulbefürworter unterschätzen die Bedeutung und Schwierigkeit der Gestaltung lokaler Gebührenmärkte erheblich.
Durch die Einführung mehrerer Ketten erzielen Entwickler keine echten Leistungssteigerungen. Wenn Anwendungen zu einem erhöhten Transaktionsvolumen führen, wirkt sich dies auf die Kosten aller L2-Ketten aus.
Flexibilität wird überbewertet
Befürworter modularer Ketten argumentieren, dass modulare Architektur flexibler sei. Diese Aussage ist offensichtlich wahr, aber spielt sie wirklich eine Rolle?
Seit sechs Jahren versuche ich, Anwendungsentwickler zu finden, denen ein generisches L1 keine sinnvolle Flexibilität bieten kann. Aber abgesehen von drei sehr spezifischen Anwendungsfällen konnte bisher niemand artikulieren, warum Flexibilität wichtig ist und wie sie direkt zur Skalierung beiträgt. Drei konkrete Anwendungsfälle, bei denen ich Flexibilität für wichtig halte, sind:
Anwendungen, die den „heißen“ Zustand ausnutzen. Der Hot-Zustand ist ein Zustand, der notwendig ist, um bestimmte Vorgänge in Echtzeit zu koordinieren. Er wird jedoch nur vorübergehend an die Kette übermittelt und existiert nicht für immer. Einige Beispiele für thermische Zustände:
Limit-Orders in DEXs wie dYdX und Sei (viele Limit-Orders werden letztendlich storniert).
Der Auftragsfluss wird in Echtzeit in dFlow koordiniert und identifiziert, einem Protokoll, das einen dezentralen Marktplatz für den Auftragsfluss zwischen Market Makern und Wallets ermöglicht.
Orakel wie Pyth, ein Orakel mit geringer Latenz. Pyth läuft als eigenständige SVM-Kette. Pyth generiert so viele Daten, dass das Pyth-Kernteam entschied, dass es am besten sei, hochfrequente Preisaktualisierungen an eine eigenständige Kette zu senden und dann Wormhole zu verwenden, um bei Bedarf Preise an andere Ketten zu überbrücken.
Ändern Sie die Konsenskette. Die besten Beispiele sind Osmosis (wo alle Transaktionen verschlüsselt werden, bevor sie an Validatoren gesendet werden) und Thorchain (wo Transaktionen innerhalb eines Blocks basierend auf den gezahlten Gebühren priorisiert werden).
Es ist eine Infrastruktur erforderlich, die das Threshold Signature Scheme (TSS) in irgendeiner Weise nutzt. Einige Beispiele hierfür sind Sommelier, Thorchain, Osmosis, Wormhole und Web3Auth.
Mit Ausnahme von Pyth und Wormhole werden alle oben aufgeführten Beispiele mit dem Cosmos SDK erstellt und als eigenständige Ketten ausgeführt. Dies spricht Bände über die Eignung und Skalierbarkeit des Cosmos SDK für alle drei Anwendungsfälle: Hot States, Konsensänderungen und Threshold Signature Scheme (TSS)-Systeme.
Bei den meisten Projekten in den oben genannten drei Anwendungsfällen handelt es sich jedoch nicht um Anwendungen, sondern um Infrastruktur.
Pyth und dFlow sind keine Anwendungen, sondern Infrastruktur. Sommelier, Wormhole, Sei und Web3Auth sind keine Anwendungen, sondern Infrastruktur. Darunter gibt es nur eine bestimmte Art von benutzerorientierter Anwendung: DEX (dYdX, Osmosis, Thorchain).
Seit sechs Jahren frage ich die Unterstützer von Cosmos und Polkadot nach den Anwendungsfällen, die sich aus der von ihnen gebotenen Flexibilität ergeben. Ich denke, es gibt genügend Daten, um einige Rückschlüsse zu ziehen:
Erstens sollten Infrastrukturbeispiele nicht als Rollups existieren, weil sie entweder zu viele Daten mit geringem Wert erzeugen (z. B. Hot-States, und der Sinn von Hot-States besteht darin, dass die Daten nicht an L1 zurückgegeben werden) oder weil sie es tun Etwas, das absichtlich inkonsistent mit der Funktionalität der Statusaktualisierung der Vermögenswerte im Hauptbuch ist (z. B. alle TSS-Anwendungsfälle).
Zweitens ist die einzige Anwendung, die meiner Meinung nach von der Änderung des Kernsystemdesigns profitiert, ein DEX. Da DEX mit MEV überflutet ist und Universal Chains nicht mit der Latenz von CEX mithalten können. Konsens ist die Grundlage für die Qualität der Transaktionsausführung und den MEV. Daher werden auf Konsens basierende Änderungen natürlich viele Innovationsmöglichkeiten für DEX mit sich bringen. Wie bereits in diesem Artikel erwähnt, ist der wichtigste Input für einen Spot-DEX jedoch der gehandelte Vermögenswert. DEXs konkurrieren um Vermögenswerte und damit um Vermögensemittenten. Unter diesem Rahmen ist es unwahrscheinlich, dass unabhängige DEX-Ketten erfolgreich sein werden, da das primäre Problem, das Asset-Emittenten bei der Ausgabe von Assets berücksichtigen, nicht DEX-bezogene MEV ist, sondern die allgemeine Smart-Contract-Funktionalität und die Integration dieser Funktionalität in die jeweiligen Anwendungen der Entwickler.
Allerdings müssen Derivate-DEXs nicht um Vermögensemittenten konkurrieren. Sie sind hauptsächlich auf Sicherheiten wie USDC und Oracle-Preis-Feeds angewiesen und müssen im Wesentlichen Benutzervermögen sperren, um Derivatepositionen zu besichern. Im Sinne unabhängiger DEX-Ketten funktionieren sie also höchstwahrscheinlich für auf Derivate ausgerichtete DEXs wie dYdX und Sei.
Betrachten wir die gängigen integrierten L1-Anwendungen, die heute existieren, darunter: Spiele, DeSoc-Systeme (wie Farcaster und Lens), DePIN-Protokolle (wie Helium, Hivemapper, Render Network, DIMO und Daylight), Sound, NFT-Austausch und mehr . Keiner von ihnen profitiert besonders von der Flexibilität, die durch die Änderung des Konsenses entsteht. Ihre jeweiligen Vermögensbücher haben ziemlich einfache, offensichtliche und gemeinsame Anforderungen: niedrige Gebühren, geringe Latenz, Zugang zu Spot-DEX, Zugang zu Stablecoins und Zugang zu Fiat Kanäle wie CEX.
Ich glaube, wir verfügen jetzt über genügend Daten, um einigermaßen sagen zu können, dass die überwiegende Mehrheit der benutzerorientierten Anwendungen dieselben allgemeinen Anforderungen haben, die im vorherigen Absatz aufgeführt wurden. Während einige Anwendungen andere Variablen am Rande mit benutzerdefinierten Funktionen im Stapel optimieren können, lohnen sich die mit diesen Anpassungen verbundenen Kompromisse normalerweise nicht (mehr Brücken, weniger Wallet-Unterstützung, weniger Unterstützung für Indizierung/Anfrageprogramme, Reduzierung der gesetzlichen Währung). Kanäle usw.).
Die Einführung neuer Asset-Ledger ist eine Möglichkeit, Flexibilität zu erreichen, bringt jedoch selten einen Mehrwert und bringt fast immer technische und soziale Komplexität mit sich, ohne dass der letztendliche Nutzen für Anwendungsentwickler gering ist.
Für die erweiterte DA ist keine erneute Hypothek erforderlich
Sie werden auch hören, wie Befürworter des Moduls über die Weiterverpfändung im Zusammenhang mit der Skalierung sprechen. Dies ist das spekulativste Argument der Befürworter der modularen Kette, aber es lohnt sich, darüber zu diskutieren.
Grob gesagt heißt es, dass das gesamte Krypto-Ökosystem durch Re-Stake (z. B. durch Systeme wie EigenLayer) die ETH unendlich oft erneut einsetzen kann, was eine unbegrenzte Anzahl von DA-Schichten (z. B. EigenDA) und Ausführungsschichten ermöglicht. Daher wird die Wertschätzung der ETH gewährleistet und gleichzeitig die Skalierbarkeit in allen Aspekten gelöst.
Trotz der großen Unsicherheit zwischen der aktuellen Situation und der theoretischen Zukunft gehen wir davon aus, dass alle Schichtungsannahmen wie angekündigt funktionieren.
Der DA von Ethereum liegt derzeit bei etwa 83 KB/s. Mit der Einführung von EIP-4844 später in diesem Jahr kann sich diese Geschwindigkeit auf etwa 166 KB/s verdoppeln. EigenDA kann weitere 10 MB/s hinzufügen, erfordert jedoch andere Sicherheitsannahmen (nicht alle ETH werden erneut an EigenDA besichert).
Im Vergleich dazu bietet Solana derzeit eine DA von etwa 125 MB/s (32.000 Shreds pro Block, 1.280 Bytes pro Shred, 2,5 Blöcke pro Sekunde). Solana ist viel effizienter als Ethereum und EigenDA. Darüber hinaus erweitert sich Solanas DA im Laufe der Zeit gemäß dem Nelson-Gesetz.
Es gibt viele Möglichkeiten, DA durch Neubesicherung und Modularisierung zu erweitern, aber diese Mechanismen sind heute einfach nicht mehr notwendig und führen zu erheblichen technischen und sozialen Komplexitäten.
Entwickelt für Anwendungsentwickler
Nachdem ich jahrelang darüber nachgedacht habe, bin ich zu dem Schluss gekommen, dass Modularität kein Selbstzweck sein sollte.
Blockchain muss seinen Kunden (d. h. Anwendungsentwicklern) dienen. Daher sollte Blockchain die Komplexität auf Infrastrukturebene abstrahieren, damit sich Entwickler auf die Entwicklung erstklassiger Anwendungen konzentrieren können.
Modularität ist großartig. Der Schlüssel zum Aufbau erfolgreicher Technologien liegt jedoch darin, herauszufinden, welche Teile des Stacks integriert werden müssen und welche Teile anderen überlassen werden. So wie es aussieht, sorgt die Integration von DA und Ausführungsketten von Natur aus für eine einfachere Endbenutzer- und Entwicklererfahrung und wird letztendlich eine bessere Grundlage für erstklassige Anwendungen bieten.
Ursprünglicher Link
Dieser Artikel wurde mit Genehmigung von Foresight News abgedruckt
Dieser Artikel „Venture Capital Institution Multicoin Partner: Why Modular Blockchain Is Overvalued“ erschien zuerst auf Zombit.