TL;DR: Das bestehende Paradigma zur Aktualisierung von Solana-Programmen ist eine Katastrophe. Das Gefährlichste am Schreiben von Smart-Contract-Code ist, dass die Programmdatenmodelle nach der Bereitstellung effektiv gesperrt sind. In der traditionellen Softwareentwicklung ist die Client-API vom Backend entkoppelt. Sie können ein Backend-Schema unsichtbar ändern oder Migrationen zu einer Datenbank hinzufügen. In der Solana-Programmierung können Sie versuchen, einen Vertrag zukunftssicher zu machen, indem Sie: - Struktur-Padding hinzufügen und hoffen, dass genügend leere Bits in den Kontodaten für zukünftige Änderungen vorhanden sind - Benutzer dazu zwingen, manuell zu signieren, um den Anwendungsstatus zu migrieren (schreckliche Benutzererfahrung) - Anwendungsadministrationsaktionen implementieren, um Schemas zu migrieren Beachten Sie, dass all dies das Potenzial hat, die VM-Ebene der Komposabilität zu brechen. Sie erfordern auch komplexe und fehleranfällige Logik, um sicher ausgeführt zu werden. Es führt nicht nur zu logischen Datenrisiken, sondern auch zu Risiken im Schlüsselmanagement. Ein Argument ist, den Code nach der Bereitstellung niemals zu ändern. Schließlich macht das bestehende Framework es extrem schwierig, bestehende Datenformate sicher zu ändern. Selbst wenn Unveränderlichkeit wünschenswert ist, ist es naiv und leichtsinnig zu denken, dass es keine katastrophalen Fehler zu beheben oder kritische Funktionen hinzuzufügen gibt (von denen einige möglicherweise Drahtänderungen erfordern). Unternehmen, die auf diesem Stack aufbauen, sind gezwungen, zwischen Sicherheit, Geschwindigkeit und Qualität zu wählen. Heute gibt es keine Werkzeuge, die die Wartung und kontinuierliche Entwicklung eines ausreichend komplexen Smart Contracts ermöglichen. Hier sind einige der Funktionen, die ich in Betracht ziehen würde, wenn ich diese Umgebung von Grund auf neu aufbauen würde: - Es sollte separate APIs in der VM geben, um Kontodaten zu lesen und zu schreiben. Dies ermöglicht Schemaänderungen, ohne das Drahtformat für sowohl On-Chain- als auch Off-Chain-Nutzer zu brechen. - Einige (opt-in) administrative Smart-Contract-Funktionen sollten auf Systemebene und nicht auf Anwendungsebene existieren. - Bei einem ausführbaren Upgrade sollte gleichzeitig eine optionale atomare Migration von Konten, die von diesem Programm besessen werden, stattfinden. Selbst wenn das Ziel Unveränderlichkeit ist, ist es entscheidend, systemlevel Werkzeuge zu integrieren, um sichere Software-Upgrades für Verbraucheranwendungen mit sich entwickelndem Status zu ermöglichen. Das aktuelle System ist so brüchig, dass der beste Rat für diese Entwickler ist, niemals On-Chain-Schemas zu berühren, es sei denn, sie wissen wirklich, was sie tun.

Gute Technologie, verrückt, dass es 5 Jahre gedauert hat, um hierher zu kommen @solana 😭

Die Definition von DEX hat sich im Laufe der Jahre wirklich weiterentwickelt. 2021: Das Matching wird in einem global verteilten Netzwerk ausgeführt und validiert. 2025: Token auf Solana, Arbitrum oder BSC einzahlen, und die Börse wird dies in einer SQL-Tabelle aufzeichnen. Das Matching erfolgt in ap-northeast-1.