Einführung

In diesem kurzen Beitrag werden die konkreten Kompromisse beschrieben:

• L1s vs. L2s
• Rollups vs. integriert
• App-spezifisch vs. allgemeingültig

Wir brauchen ein besseres Verständnis dafür, welche Architekturen wann gebaut werden müssen. Andernfalls erhalten wir weiterhin ein Durcheinander an verwirrender Infrastruktur, die kein Benutzer verstehen oder mit der er interagieren kann. Das ist der häufigste Fehler, den ich sehe:

Wie im Einführungsbeitrag von Eclipse vor dem bevorstehenden Mainnet-Start erwähnt:

Oft wird eine falsche Dichotomie zwischen der modularen Rollup-Vision und der Möglichkeit einer einzigen Kette mit massiver Skalierung, parallelisierter Ausführung und gemeinsamem Status dargestellt. „Modular“ wird oft mit „App-spezifisch“ verwechselt, was den Eindruck erwecken würde, dass Rollups eine Welt mit vielen fragmentierten Ketten mit geringem Durchsatz bedeuten. Wir stellen diese Idee in Frage.

Rollups und L2s sind keine schlechte UX. Fragmentierte Rollups und L2s sind eine schlechte UX. Richtig gestaltete Rollups und L2s sollten die UX verbessern.

Rollups vs. integriert

Alle Ketten können schließlich die beste Technologie (z. B. DAS + ZK) übernehmen, wenn sie sich als nützlich erweist. Wie in meinem letzten Bericht besprochen, erben Rollups die Sicherheit?, die Unterscheidung, die uns dann bleibt, ist ungefähr die folgende:

• „Rollups“, auch bekannt als „Rollups“. „Modular“ – Erstellen Sie logisch getrennte Ketten, die Daten an ihre Host-Kette (DA-Schicht) senden. Sie verwenden den Konsens der Hostkette wieder.
• „Integriert“, auch bekannt als „Monolithisch“ – Integrieren Sie alles in ein Protokoll mit eigenem Konsens. Veröffentlichen Sie keine Daten an eine separate Hostkette. (Auch wenn die DA-Schicht und die Ausführungsschicht in gewisser Weise logisch getrennte Teile des gemeinsam genutzten Protokolls sind).

Solana und Eclipse stellen die parallelen Pfade dar, wie auch in der Solana-These von Syncracy gezeigt:

Wie ich in meiner letzten Uncommon Core-Episode mit Hasu besprochen habe, werden beide Ansätze langfristig von Wert sein.

Solana verfolgt den Ansatz, alles in einem Konsens zu bündeln. Es strebt eine minimale Latenz an (Slot-Zeiten liegen derzeit im Durchschnitt bei ca. 400–500 ms, in der Hoffnung, in Zukunft 200 ms zu erreichen), während gleichzeitig ein großer Validatorsatz (ca. 2.000) beibehalten wird. Diese unglaubliche Leistung erforderte mehrere technische Durchbrüche.

Allerdings stehen diese beiden Ziele (maximale Dezentralisierung + minimale Latenz) von Natur aus in einem Spannungsverhältnis. Es ist eine unglaubliche Herausforderung, diesen Konsenssatz bei maximaler Geschwindigkeit und maximalem Durchsatz stabil zu halten. TowerBFT verfügt über keine formelle Sicherheits- oder Liveness-Analyse und es ist unklar, ob der Proof-of-History derzeit in einem gegnerischen Modell nützlich und belastbar ist oder einfach entfernt werden kann. Die Wirtschaftlichkeit eines Systems mit geringer Latenz erhöht natürlich auch den Anreiz zur Zentralisierung.

Eclipse verfolgt den Ansatz der Entbündelung des Konsenses. Rollups können über einen kleineren handverlesenen Sequenzersatz verfügen (möglicherweise sogar von einem einzelnen Bediener ausgeführt), um eine kontrollierte Umgebung zu betreiben. Dadurch kann die Zuverlässigkeit erhöht und die Latenz noch weiter reduziert werden, sodass ein Web2-Produkt mit den Vorteilen von Kryptoschienen angeboten wird. Code, eine Zahlungs-App, die als eine Art L2 auf Solana mit dauerhaften Nonces bereitgestellt wird, ähnelt in ihrem Wunsch nach sofortigen und zuverlässigen Zahlungen. Über die großartige UX der nahezu sofortigen Latenz hinaus ist es auch für hochwertige Finanzanwendungen mit geringer Latenz notwendig, die Untergrenze noch weiter zu verschieben.

Rollups können ihre Daten dann an einen anderen dezentralen Konsenssatz senden, um eine robustere Überprüfung in einem langsameren Zeitraum zu ermöglichen. Celestia hat beispielsweise 15 Sekunden Blockzeit mit Single-Slot-Finalität, was sich eigentlich gar nicht so sehr von Solana unterscheidet! Solana hat ca. 400 ms Bestätigungen, dann ist die Endgültigkeit nach 32 Slots (~ 12,8 s) erreicht .

Hier gibt es kein kostenloses Mittagessen. Es gibt einen potenziellen Kompromiss zwischen den Eigenschaften des Echtzeit-Validator-Sets (z. B. verfügt Solana über weit mehr Validatoren als Rollups über Sequenzer) und den bereitgestellten Garantien (z. B. kontrollierte, belastbare Umgebung, noch geringere Latenz usw.). Das richtige Maß an gegebenem Engagement (und in welchem Zeitrahmen) ist ein Spektrum. Es bleiben offene technische Fragen offen, und die beste Lösung wird wahrscheinlich je nach Anwendungsfall variieren. Es versteht sich von selbst, dass auch hier die Kosten eine entscheidende Rolle spielen, sodass skalierbare DA-Schichten wie Celestia (das von Eclipse verwendet wird) benötigt werden.

Eclipse wird Solana offensichtlich nicht ersetzen. Jeder geht unterschiedliche Kompromisse ein und verfolgt einen anderen Markt. Solana bleibt das Herz und die Seele der SVM-Entwicklung und es ist wahrscheinlich, dass dort viele neue Anwendungen bereitgestellt werden. Es ist jedoch klar, dass es langfristig mehr als eine SVM-Kette geben wird (Pyth ist das bereits). Die Zukunft ist nicht Single-Chain und die SVM ist einfach eine erstaunliche Technologie. Eclipse beginnt mit dem Trend, es nach L2 zu exportieren, aber ich erwarte, dass andere den Wert hier erkennen und ihrem Beispiel folgen.

L1 gegen L2

Ich verwende L1 und L2 hier im allgemeineren Sinne, um Rollups, Validien usw. einzubeziehen. Wie in Vitaliks Verschiedene Arten von Layer-2s beschrieben:

Zwei-Wege-Validierungsbrücken reichen fast aus, um eine Kette zu einem Validium zu machen. Der wichtigste verbleibende Bestandteil ist eine soziale Verpflichtung, dass die andere Kette als Reaktion darauf einen Hard Fork durchführen wird, wenn in Ethereum etwas Außergewöhnliches passiert, das dazu führt, dass die Brücke nicht mehr funktioniert.

Was einen L1 von einem L2 unterscheidet, ist im Grunde die Art und Weise, wie er mit Forks umgeht. Ein Validium würde zurückgesetzt, wenn sein L1 einen Block zurücksetzt, und es würde einen Hard Fork durchführen, wenn seine Basisschicht einen Hard Fork durchführt. Um den L2 zu aktualisieren, muss eine Form der L2-Governance auf dem L1 als Brückenvertrag vorhanden sein, der für den L1 lesbar ist.

Warum sollten wir so etwas verwenden? Ist es für eine Kette sinnvoll, ihre Fork-Wahl an einen zugrunde liegenden L1 zu delegieren und sich dort um ihre Brücke herum zu verwurzeln?

Trotz der allgemeinen Überzeugung, dass die L1-Kriege vorbei sind, hat Ethereum gewonnen und alle Ethereum-Konkurrenten wollen jetzt L2 werden – Ethereum L2s sind nicht die beste Lösung für alle Ketten.

Ethereum L2s werden oft als die sicherste und skalierbarste Möglichkeit zum Aufbau einer Kette angesehen. Diese Sicherheitseigenschaften werden jedoch oft zutiefst missverstanden, wie in meinem letzten Bericht erläutert. Das bloße Posten eines Beweises bei Ethereum und das Delegieren Ihrer Fork-Choice-Regel dorthin macht Ihre Kette nicht auf magische Weise supersicher.

Das Argument, dass alle Ketten zu ihrer eigenen Sicherheit als Ethereum L2s bereitgestellt werden müssen, ist meist falsch. Der Hauptvorteil von L2s bestand vielmehr in der Möglichkeit, die Netzwerkeffekte von Ethereum (Benutzer, Liquidität, Entwickler, Tools usw.) zu nutzen. Es handelt sich um eine Go-to-Market-Strategie.

Der Kampf um Aufmerksamkeit macht Sinn, wenn man bedenkt, dass Aufmerksamkeit die einzige knappe Ressource in Krypto ist. L2s stehen natürlich im Mittelpunkt mit den Entwicklern, Benutzern, Medien usw., die am wichtigsten sind. Früher reichte es aus, ein L2 zu sein, um diese Aufmerksamkeit zu erregen.

Allerdings lässt die Aufmerksamkeit, die man als L2 erhält, nach. Die Liste der aktiven und kommenden Ethereum L2s ist mittlerweile viel zu lang, als dass irgendjemand sie im Auge behalten könnte. Ketten, die zu L2s wechseln, erhalten nicht den Aufmerksamkeitsschub, den die Early Mover hatten (z. B. Optimism und Arbitrum). Selbst die Flut lang erwarteter zkEVMs hat Schwierigkeiten, Benutzer, Anwendungen und Mehrwert anzuziehen.

Ein L2 allein zu sein, garantiert also nicht mehr die Aufmerksamkeit aller. Allerdings kann es dennoch einen Produktvorteil gegenüber eigenständigen Ketten bieten, wenn Sie auf andere Weise Aufmerksamkeit erregen können. Wenn man zum Beispiel ein Pyramidensystem in ein Quadrat umwandelt , kann man etwa 700 mm in ein Multisig ohne L2 investieren. Alternativ könnten Sie die erste SVM L2 von Ethereum erstellen.

Angenommen, Sie haben ein Produkt mit Aufmerksamkeit, dann überlegen wir uns nun, wie eine Kette als L2 dabei helfen kann, die Benutzerbasis von Ethereum zu erschließen und ein besseres Produkterlebnis zu bieten. Dies würde in erster Linie durch die vorteilhafte Nutzung von Ethereum-eigenen Vermögenswerten (z. B. ETH) geschehen (z. B. Brücken mit attraktiver Sicherheit und/oder UX).

Der Wert davon hängt weitgehend von zwei Grundannahmen ab:

1. Dass vorhandene Ethereum-Assets für den jeweiligen Anwendungsfall wichtig sind (z. B. DeFi abhängig von ETH)

Wenn Ihre Anwendung stark von Assets des Ethereum-Ökosystems abhängig ist, kann eine L2-Architektur wertvoll sein. Wenn Ihnen Ethereum-Vermögenswerte überhaupt nicht am Herzen liegen, ist es nicht besonders wertvoll, ein Ethereum L2 zu sein. Ethereum-basierte Vermögenswerte sind heute eindeutig die wichtigsten im Kryptobereich, daher gibt es hier heute einen großen Markt, der bedient werden muss.

Mit Blick auf die Zukunft stellt sich auf Branchenebene die Kernfrage: Wie wird die neue und wertvolle Zustandsschaffung von Krypto in Zukunft aussehen?

• Wenn sich dieser zukünftige Zustand zunehmend von dem aktuellen Ethereum-Native-Zustand (z. B. einzigartiger neuer Staat, RWAs usw.) löst, kann die Attraktivität von L2s abnehmen.
• Wenn dieser zukünftige Zustand stark vom aktuellen Ethereum-Native-Zustand abhängt (z. B. ETH-Handel), könnten L2s eine herausragende Rolle spielen.

Das erstere Szenario geht davon aus, dass wir nur einen Tropfen auf den heißen Stein davon gesehen haben, was Krypto sein wird, und man sollte sich nicht zu sehr auf das konzentrieren, was heute hier ist. Das letztere Szenario geht davon aus, dass die Krypto-Entwicklung und -Anwendungen unglaublich pfadabhängig sein werden, sodass der aktuelle Zustand das Ergebnis beeinflussen wird.

Beides trifft bis zu einem gewissen Grad zu, aber ich denke, dass jede optimistische Sicht auf die langfristigen Aussichten der Branche auf Ersteres tendiert. Es wird viele neue und einzigartige Zustände geben, über die wir nicht einmal nachdenken können und die nicht mit dem heutigen Zustand verbunden sind. Der aktuelle Stand der Kryptowährungen ist im Vergleich zum erwarteten zukünftigen Stand ein Tropfen auf den heißen Stein.

Beispielsweise bedeuten die häufig zitierten „Abwicklungszusicherungen“ von Ethereum wenig für reale Vermögenswerte (RWAs) wie Stablecoins (z. B. USDC) oder tokenisierte Schatzwechsel. Sie werden „abgewickelt“, wenn der Emittent (z. B. Circle) dies für richtig hält.

In diesem Szenario könnte die Anziehungskraft, ein Ethereum L2 zu sein, im Hinblick auf den Anteil der Anwendungen abnehmen. Einer neuen USDC-basierten Zahlungsanwendung ist es grundsätzlich egal, ob es sich um ein Ethereum L2 handelt oder nicht. Sie wollen lediglich die günstigste, schnellste und zuverlässigste Infrastruktur, die es ihnen ermöglicht, den Benutzern das beste Produkterlebnis zu bieten.

Die Schaffung eines neuen Staates war in der Vergangenheit eine Hürde für Solana, obwohl wir hier deutlich erkennen, dass sich der Wind ändert. Viele bekannte DeFi- und Infrastrukturprojekte auf Solana führen jetzt Token ein, weitere werden folgen. Dies bringt das Solana-Schwungrad in Schwung.

2. Dass Ethereum ←→ L2-Brücken den Ethereum ←→ L1-Brücken vorzuziehen sind (z. B. aus Sicherheits- und/oder UX-Gründen)

Nehmen wir an, dass die erste Annahme für einen bestimmten Anwendungsfall tatsächlich erfüllt ist (dh Ethereum-native sind für Ihre Anwendung sehr wertvoll). Dann müssen wir uns fragen, ob ein L2 diese Vermögenswerte auf günstigere Weise offenlegen kann als ein separater L1. Nehmen wir an, ein Benutzer hat etwas ETH und möchte es gegen USDC eintauschen. Wohin gehen sie?

Obwohl hier oft die Brückensicherheit als Motivation angeführt wird, scheint dieses Argument auf der Grundlage der verfügbaren Informationen dürftig zu sein. Viele der größten Rollup-Bridges verfügen nicht einmal über Proofs, verfügen über Whitelist-Proofs, Multisig-gesteuerte Upgrades oder haben buchstäblich nicht einmal einen L2.

Dies ist vergleichbar mit dem klassischen Konsens-Verifizierer-Bridging (z. B. IBC). In der Praxis kam es in solchen Szenarien zu keinen schwerwiegenden Fehlern beim Validator-Quorum. Bridge-Ausfälle sind im Allgemeinen auf Hacks und/oder kompromittierte Bridge-Multisigs zurückzuführen (für die L2s gleichermaßen anfällig sind).

Während mich Sicherheitsverbesserungen hier weniger überzeugen, ist der bequeme Zugriff auf Ethereum-Benutzer und -Assets meiner Meinung nach heute ein großer Vorteil von L2-Bridging. Rollups wie Base, Optimism und Arbitrum wirken eher wie Erweiterungen von Ethereum. Benutzer behalten die gleichen Wallets und Adressen, der native Gas-Token ist eine einzelne kanonische Version von ETH, ETH dominiert DeFi wie alle Handelspaare, soziale Apps bewerten NFTs in ETH und zahlen Schöpfer in ETH (z. B. friends.tech). Einzahlungen in die L2 erfolgen sofort (da sie sich neu organisieren würden) usw.

Von Benutzern kann nicht erwartet werden, dass sie überlegen, welche Bridge sie verwenden sollen, die unterschiedlichen Sicherheitsannahmen analysieren, einen von mehreren verfügbaren verpackten Token erhalten, den nativen Token der Kette für Gas erwerben usw. Sie wollen lediglich ihre ETH überbrücken, ETH auf die andere Seite bringen und L2 weiterhin so nutzen, wie sie Ethereum oder jedes andere L2 nutzen würden. Aus diesem Grund wird Eclipse lediglich ETH als nativen Token für Gas verwenden. Das Erzwingen eines neuen Gas-Tokens ist schädlich für UX.

Warum kann Solana also nicht die gleichen Vorteile bieten wie ein Ethereum L2? Dies ist eigentlich eher eine technische Frage als etwas Grundlegendes, und mit der Zeit wird es einfacher. Dies gilt sowohl für Gas-Tokens als auch für andere UX-Herausforderungen, die damit zusammenhängen, dass die EVM einfach nicht verwendet wird (was bei L1 vs. L2 nicht inhärent ist):

• Gas-Token – Gaszahlungen können von den Benutzern abgezogen werden, sodass Benutzer mit dem von ihnen gewählten Gas-Token bezahlen können.
• Überbrückung – Überbrückung wird sich im Laufe der Zeit wahrscheinlich stärker verschärfen und standardisieren, was zu weniger Verwirrung bei den Benutzern und einer Fragmentierung der Liquidität führen wird.
• Wallets – Die kürzlich vorgestellten Snaps von MetaMask erweitern die MetaMask-Unterstützung auf Nicht-EVM-Ketten über darauf aufbauende Integrationen von Drittanbietern, beispielsweise über MetaMask Snaps von Drift oder Solflare.
• Entwicklererfahrung – Sprachbarrieren werden abgebaut. Projekte wie Solang und Neon können Solidity-Entwicklern dabei helfen, auf Solana aufzubauen, und Projekte wie Stylus können Rust-Entwicklern dabei helfen, auf Arbitrum aufzubauen.

Zukünftig wäre es sogar möglich, dass die ETH eine Rolle bei Solana DeFi spielt, wenn Benutzer aufgrund der Geschwindigkeit und Größe von Solana starke Präferenzen für ETH äußern würden. In der Praxis ist es weitaus wahrscheinlicher, dass diese Benutzer mit Ethereum-nativen Assets diese aus den von uns besprochenen Gründen weiterhin innerhalb des Ethereum-L2-Ökosystems nutzen werden, vorausgesetzt, sie haben Zugang zu vergleichbar skalierbaren L2s.

App-spezifisch vs. allgemeingültig

Unabhängig davon, ob es sich bei einer Kette um eine L1- oder eine L2-Kette handelt, besteht eindeutig die Notwendigkeit, den Durchsatz einer einzelnen Kette durch Skalierung der Ausführung zu erhöhen. Rollups sollten keine Fragmentierung bedeuten. Die Vereinigung vieler homogener Ketten unter einem Stateful Shared Sequencer sieht aus Skalierungsperspektive mit anspruchsvollerem UX letztendlich wie eine parallelisierte Kette aus.

Als Grund für die Bereitstellung eines App-spezifischen Rollups wird häufig „dedizierter Blockraum“ genannt. Dieses Missverständnis ist jedoch größtenteils auf die unnötigen Einschränkungen des Single-Threaded-EVM mit globalen Gebührenmärkten zurückzuführen. Eine parallelisierte SVM mit lokalen Gebührenmärkten reduziert den Bedarf an App-Ketten erheblich. Das Hosten von mehr Apps auf einer gemeinsam genutzten Infrastruktur reduziert die Komplexität für Entwickler und Benutzer erheblich. Cross-Chain-UX und Entwicklerkomplexität in einer Welt mit vielen Ketten sind ein unterschätztes existenzielles Risiko.

Das heißt nicht, dass es am Ende des Tages buchstäblich eine Kette geben wird. Ich sehe im Großen und Ganzen vier Argumente für den Einsatz einer eigenen Kette:

1. Skalierbarkeit und dedizierter Blockraum – Wie oben erwähnt, ist diese Lösung normalerweise nicht überzeugend. Eine NFT-Mint sollte den Rest der Kette nicht effektiv lahmlegen, aber die Antwort besteht im Allgemeinen nicht darin, eine weitere Kette zu gründen. Dies wird durch eine parallelisierte VM mit lokalen Gebührenmärkten gemildert. Soweit jedoch die Bandbreite des gesamten Netzwerks ausgelastet ist, werden lokale Gebührenmärkte nicht helfen (dh die Gebühren für die gemeinsame Kette werden weltweit steigen). Dann brauchen Sie eine andere Kette.
2. Souveränität – Die Governance im Kryptobereich ist immer noch recht dürftig, und eine eigene Chain zum Forken kann ein hilfreicher Koordinierungsmechanismus sein. Ich vermute, dass dies ein sehr seltener Umstand ist, aber es ist schwer, es mit Sicherheit zu sagen. Dies steht im Einklang mit dem Interesse von MakerDAO an einer App-Kette.
3. Anpassbarkeit – Anpassungen auf Konsensebene können für bestimmte Anwendungen (z. B. dYdX v4) wertvoll sein, aber empirisch sind diese Fälle bisher selten. Sogar dYdX, das leuchtende Beispiel einer App-Kette, wird sich laut Antonio in seiner jüngsten Bell Curve-Folge „wahrscheinlich eher in Richtung einer allgemeinen Ausführung auf der dYdX-Kette bewegen“. Der Bedarf an vollständiger Anpassbarkeit, der nicht in einer gemeinsamen Kette gelöst werden kann, fehlt bei den meisten Kryptowährungen im Allgemeinen. Fast alle neuen Rollups sind weiterhin nur Vanilla-EVM-Forks mit neuen Token.
4. Werterfassung – Dies ist wohl ein Teilbereich der Anpassbarkeit, aber er ist ziemlich wichtig, deshalb werden wir ihn aufteilen. Es kann schwieriger sein, den Wert einer gemeinsam genutzten Infrastruktur zu verinnerlichen, die nicht nur für Ihre Anwendung entwickelt wurde. App-Ketten können es einfacher machen, den verantwortlichen Anwendungen einen Wert zuzuordnen. Dabei handelt es sich jedoch mehr um einen technischen als um einen grundlegenden Aufwand, und in Solana wird derzeit daran geforscht, wie genau dies bewerkstelligt werden kann. Beachten Sie außerdem, dass die Bereitstellung Ihrer eigenen Kette im Vergleich zur Amortisierung der Kosten für die gemeinsame Infrastruktur mit erheblichen Gemeinkosten verbunden ist.

Die Hauptmotivation für die Einführung einer App-Kette ist heute oft der wahrgenommene narrative Boost und/oder der symbolische Nutzen für ein schwieriges Projekt. Der Abschwung auf dem Bärenmarkt und das damit einhergehende mangelnde Anwendungswachstum förderten die Entwicklung und Finanzierung einer übermäßig komplizierten Architektur, die dazu führte, dass neue Projekte zur Lösung selbstverursachter Komplexitäten erforderlich wurden.

Die heutige Einführung einer eigenen Kette bringt schmerzhafte und unnötige Kompromisse mit sich (Komplexität, Kosten, schlechtere UX, fragmentierte Liquidität usw.), die die meisten Apps für die inkrementellen Vorteile nicht rechtfertigen können. Die Infrastruktur, die erforderlich ist, um diese UX wettbewerbsfähig zu machen, scheint in weiter Ferne zu sein. Das soll nicht heißen, dass es keinen Grund dafür gibt, dass App-Ketten jemals existieren (das gibt es auf jeden Fall). Vielmehr haben wir in dieser Richtung die Narrative als Branche massiv überindiziert, und daher ist der aktuelle Trend zur Neubündelung angesichts der aktuellen Lage eindeutig von Vorteil.

Abschluss

Solana hat in den letzten Monaten zu Recht stark an Dynamik gewonnen. Diese scharfe Korrektur war größtenteils eine Anerkennung des aktuellen Zustands von Multi-Chain-UX – es ist fragmentiert und schmerzhaft. Die UX der Verwendung von Solana-Anwendungen ist einfach unglaublich. Reibungslos und schnell.

Rollups und L2s haben für UX einen schlechten Ruf, aber das eigentliche Problem ist die Fragmentierung. Wir assoziieren Rollups und L2s mit fragmentierter horizontaler Skalierung, da die meisten von ihnen in der Praxis die EVM so wie sie ist gegabelt haben und eine eingeschränkte DA-Bandbreite verwenden. Am Ende sind sie teuer und umständlich in der Anwendung.

Dies ist jedoch nicht grundlegend. Die vertikale Skalierung mit einer leistungsstarken VM auf einer skalierbaren DA-Ebene löst diese UX- und Kostenprobleme. Es ist wahrscheinlich, dass es zu einem gewissen Grad an Neubündelung des Stacks sowohl für L1s als auch für L2s kommt. L2s und Rollups sollten bei richtiger Verwendung die UX verbessern. Das sollte ihr eigentliches Verkaufsargument sein.

Beide Ansätze haben ihre Vorzüge. Wir müssen uns einfach besser zunächst fragen: „Welchen Markt soll dieses Produkt ansprechen?“ und „Wie kann diese Architektur das lösen, was ich brauche?“ bevor wir mit dem Bau der nächsten L1, L2, L3 beginnen ...

Haftungsausschluss:

1. Dieser Artikel wurde von [dba] nachgedruckt. Alle Urheberrechte liegen beim ursprünglichen Autor [Jon Charbonneau]. Wenn Sie Einwände gegen diesen Nachdruck haben, 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.