1) In den letzten 4-5 Jahren habe ich mit einer Vielzahl von Solana-Anwendungsarchitekturen experimentiert, und ich dachte, es ist höchste Zeit, die Ergebnisse aufzuschreiben. Ich beginne mit der am wenigsten komplizierten und füge schrittweise mehr Komplexität hinzu. Also, hier geht's: Solana-Anwendungsarchitektur, ein Thread.

2) Lass uns mit dem einfachen Modus beginnen. So sieht wahrscheinlich deine erste Solana-App aus. Ein einfaches React-Frontend, das eine Verbindung zu einem RPC herstellt. Es ist kein API-Server erforderlich. Der RPC ist dein Server. In den frühen Tagen waren diese mit getAccountInfos, maßgeschneiderter Transaktionskonstruktionslogik usw. überladen. Später, wenn die Leistung leidet, fügst du Schichten von Caching und Batching hinzu. Hier kommt getMultipleAccounts ins Spiel. Vielleicht fügst du auch Websocket-Abonnements + Polling hinzu, um die UI in Echtzeit zu aktualisieren. Diese Architektur ermöglicht extrem schnelles Prototyping. Es gibt praktisch keinen DevOps-Aufwand. Vernachlässigbare Serverkosten (einfach auf Vercel bereitstellen usw.). Es hat jedoch einige große Mängel.

3) Das erste Problem, auf das Sie stoßen, sind komplexe Abfragen. In dieser Architektur haben Sie nur das einfache Solana RPC. Das bedeutet, dass Sie Solana so behandeln müssen, wie es ein RPC offenbart – als eine NoSQL-Datenbank mit einem Problem in der Einstellung. Punktabfragen sind kein Problem. Sie können sogar sehr kreativ mit PDAs werden, um Ihre Programmdaten zu durchlaufen, als wäre es eine Graphdatenbank. Aber sobald Sie Ihre erste gPA durchführen müssen, stehen Sie vor maximalen Schwierigkeiten. Die Schnittstelle ist überhaupt nicht ergonomisch. Wenn Sie irgendeine Art von dynamisch langen Daten haben, kann diese überhaupt nicht verwendet werden. Je nach Ihrem RPC-Anbieter kann es unglaublich langsam sein. Selbst ohne gPAs ist dieser Ansatz tendenziell viel langsamer als Ihre typische Web2-App mit serverseitigem Rendering und einer normalen Datenbank.

4) Das zweite Problem, auf das Sie stoßen, ist die Portabilität der Logik zur Transaktionskonstruktion. Mit diesem Setup befindet sich die gesamte Logik zur Konstruktion von Transaktionen entweder (a) in Ihrem Frontend-Code oder (b) in Bibliotheken, die Ihr Code importiert. Im Fall von (a) ist jeder, der Transaktionen außerhalb Ihres Frontends konstruieren möchte, maximalen Schmerzen ausgesetzt (das schließt Sie ein, wenn Sie unvermeidlich mehr App benötigen). Im Fall von (b) erfordern Änderungen an der Logik zur Transaktionskonstruktion Bibliotheksveröffentlichungen, dass jeder seine Pakete aktualisiert und dann UI-Updates. Eine starke Abhängigkeit von Anchor-Tools wie der Kontolösung kann die Menge an Logik minimieren, die portiert werden muss – aber das Problem bleibt bestehen. Dies beraubt Sie der Agilität und macht es schwierig, Smart-Contract-Endpunkte zu ändern, während sichergestellt wird, dass alle Versionen Ihrer TX-Bau-Logik weiterhin funktionieren.

5) Das dritte Problem, auf das Sie stoßen, ist die Tatsache, dass UIs im Allgemeinen schlecht darin sind, Transaktionen einzureichen, insbesondere mit Wiederholungslogik. Ein Benutzer kann die Seite verlassen, TX hört auf, es erneut zu versuchen. Große Mengen von Transaktionen haben oft Schwierigkeiten, erfolgreich zu sein. Es ist schwierig, aus der Ferne zu debuggen, warum Dinge nicht erfolgreich sind.

6) Das letzte Problem hier ist, dass Sie nicht der Einzige mit dieser Architektur sind. Ein RPC ist wertvoll, und Sie müssen im Grunde Ihre RPC-URL in Ihrem Frontend offenlegen. Jetzt befinden Sie sich in einem Katz-und-Maus-Spiel, um sicherzustellen, dass niemand Ihren RPC stiehlt und Ihre Kosten erhöht.

7) Was kommt als Nächstes? Typischerweise, selbst wenn Sie die tx-Portabilität nicht ansprechen, müssen Sie letztendlich Listenabfragen behandeln. gPA ist schlecht, und das wissen wir alle. Also können Sie eine hybride Architektur aufbauen. In dieser Architektur behalten Sie die Fähigkeit, schnell Prototypen zu erstellen, schieben jedoch die hässlichen, schwierigen Abfragen in eine API. Ein schönes konkretes Beispiel dafür ist die Governance – Sie haben Vorschläge, die erstellt werden und eine Reihe von Tags darauf haben ("Wirtschaftlich", "Technisch" usw.). gPA kann nicht nach Tag filtern.

8) Diese Architektur hat die Portabilität von Transaktionen nicht gelöst, noch das Problem, dass Leute dein RPC abziehen. Aber im großen Maßstab kannst du zumindest das Problem langsamer/unmöglicher gPAs lösen. Es führt ein neues Problem ein – Indexer. Mehr dazu später.

9) Schließlich haben Sie das, was ich den "Enterprise" Solana-Stack nennen würde. Sie behandeln Solana nicht mehr als eine NoSQL-Datenbank. Stattdessen behandeln Sie es wie einen Event-Bus. Das Frontend weiß nichts über das Datenmodell von Solana. Der Server erstellt Transaktionen und übergibt sie an die UI zur Signierung, bevor er sie an Solana selbst sendet. Es behandelt dies als ein Ereignis und wartet darauf, dass es zu den Indexern zurückpropagiert wird, die die zugrunde liegenden Daten ändern. Dieses Setup bietet eine großartige Transaktionsportabilität - jeder kann Ihre API mit sauberen Parametern ansprechen und Transaktionen/Anweisungen zurückbekommen. Es sorgt für eine extrem reaktionsschnelle UI - soweit es die UI betrifft, ist dies im Grunde web2. Sie können die vollständigen Vorteile von SSR nutzen. Der RPC ist abstrahiert - niemand kann Ihre Credits stehlen. Aber dieses Setup hat seine Probleme.

10) Das erste Problem, auf das Sie stoßen werden, ist das Indexer-Problem. Obwohl dies in den letzten paar Jahren (dank der Teams von Triton, Helius und StreamingFast) gemildert wurde, schlage ich unseren Indexer immer noch regelmäßig mit einem Schraubenschlüssel. Sie werden Nachrichten verpassen. Wenn Sie eine Nachricht verpassen, gerät Ihre Benutzeroberfläche in einen seltsamen Zustand (Beispiel: Ich habe Ihnen ein NFT geschickt, on-chain haben Sie es erhalten, in meiner Datenbank steht, dass ich es immer noch besitze). Solche Probleme sind wahnsinnig schwer zu debuggen. Ist es Ihre Schuld? Ist es Ihr Datenanbieter? Wer weiß das schon! Da geht Ihr Nachmittag.

11) Das nächste Problem, auf das Sie stoßen werden, ist das Timing. Wenn Sie RPC direkt für alles verwenden, können Sie Verpflichtungen übergeben und mit den neuesten Daten arbeiten. Bei einem Indexer ist das alles manuell. Das bedeutet, dass Sie beim Erstellen von Transaktionen möglicherweise auf veraltete Daten zurückgreifen. Sie geben eine Transaktion zurück, die zum Scheitern verurteilt ist. Sie können das Problem mit den veralteten Daten lösen, indem Sie Datenanbieter verwenden, die Ihnen extrem schnelle Daten liefern (z. B. Helius Laser Stream). Aber dann müssen Sie manuell mit Reorgs umgehen. Das heißt, die Daten, die Sie indizieren, müssen un-indexiert werden, wenn diese Transaktion tatsächlich nicht durchgeführt wurde. Das ist ein Albtraum.

12) Sie können "Hacks" um Timing-Probleme umgehen, indem Sie Transaktionen nur mit Daten aus dem RPC erstellen und Ihre indizierten Daten nur zur Speisung der Benutzeroberfläche verwenden. Aber dann werden die Benutzer immer noch Probleme mit möglichen Inkonsistenzen zwischen der Benutzeroberfläche und der Blockchain haben. Das heißt, die Benutzeroberfläche sagt, ich besitze dieses NFT und kann es übertragen, dann schreit das Backend mich an und sagt, ich kann es nicht.

13) Das letzte Problem, auf das Sie mit diesem Setup stoßen, ist die Kostenfrage, und wenn wir melodramatisch sind, "der Tod der Dezentralisierung." Der Traum von Web3 war es, keine Unmenge an zentralisierten Servern bereitstellen zu müssen. Jetzt haben Sie genug Infrastruktur bereitgestellt, um einen Job als leitender Architekt in einem Web2-Unternehmen zu bekommen. Es kostet Geld. Es kostet Zeit. Und es ist alles sehr zentralisiert. Wie dezentralisiert ist Ihr Protokoll, wenn der beste Weg, um damit zu interagieren, über eine Web2-API erfolgt? Und es gibt etwa 72 Entwickler bei Solana, die wissen, wie man ohne diese API damit interagiert.

14) Letztendlich werde ich auf keinen Hügel in Bezug auf Dezentralisierung sterben. Was am besten für die Nutzer ist, ist in der Regel die beste Wahl. Die "Enterprise"-Einrichtung führt zu schnellen, modernen Webanwendungen und einer klaren Trennung der Anliegen. Auf der negativen Seite erhöht es die DevOps-Kosten und macht dich weniger agil. Ich empfehle den meisten Startups, mit der Direkt-zu-RPC-Methode zu beginnen, es sei denn, du baust etwas, das ausdrücklich schnell sein muss oder komplexe Abfragesemantiken benötigt. Die Markteinführungszeit ist entscheidend. Du kannst immer später einen Ingenieur auf mittlerem Niveau einstellen und ihn in den Indexierungs-Dungeon stecken.

15) Fin. Wenn einer von euch ein besseres Setup gefunden hat, lasst es mich wissen. Das sind alles Dinge, die ich ausprobiert habe. Ich genieße es, in letzter Zeit mit dem Unternehmenssetup herumzuspielen.