Es ist offensichtlich, warum Quasar Anchor schlägt, aber viele Leute fragen sich auch: "Warum schlägt Quasar Pinocchio bei einigen CU-Benchmarks?" Persönlich mag ich die Fragestellung nicht, da sie zu einer falschen Schlussfolgerung zu führen scheint. Es ist sicherlich nicht der Fall, dass @0x_febo es versäumt hat, eine Menge Dinge zu optimieren, und wir es geschafft haben, ihn dabei zu übertreffen. Ganz im Gegenteil! Pinocchio und jetzt in der Folge die neueren Versionen des Solana SDK sind tatsächlich *so* optimal, dass der einzige Weg, den wir gefunden haben, um die CUs signifikant weiter zu reduzieren, darin besteht, zusätzlichen Kontext in Form eines Frameworks einzuführen. Einen Bibliothek mit einem Framework zu vergleichen, ist kein Äpfel-zu-Äpfel-Vergleich. Es gibt viele programmspezifische Optimierungen, die trivial zu implementieren sind, wenn man genug Kontext hat, aber extrem schwierig in eine programmunabhängige Bibliothek zu verallgemeinern. Lassen Sie mich einen solchen Fall erklären: Im Jahr 2024 führte @cavemanloverboy solana-nostd-entrypoint und solana-nostd-invoke ein. Dies war der erste ernsthafte Versuch, einige der absolut schlechtesten Solana SDK-Codes zu adressieren, die von jedem einzelnen Onchain-Programm konsumiert werden. Innerhalb dieses Crates führte Cavey eine Technik namens "nodup" entrypoint ein, bei der man anstelle von CUs, die für die Verwaltung doppelter Konten verbrannt werden, einfach einen Fehler ausgibt, sobald man auf eines stößt. Diese Technik lässt sich gut mit einigen anderen Optimierungen kombinieren, auf die ich später eingehen werde. Leider, aufgrund der Art und Weise, wie der Solana entrypoint ursprünglich entworfen wurde, um sowohl global für alle Anweisungen in einem Programm zu sein, als auch eine vollständige Analyse vieler variabler Eingaben zu erfordern, um situative Wahrnehmung zu erreichen, reicht es aus, wenn eine Anweisung in Ihrem Programm ein potenzielles doppeltes Konto hat, damit das gesamte Programm nicht in der Lage ist, diese Technik zu nutzen. Letztes Jahr brachte ich eine Idee an Febo, Cavey und @alessandrod: Was wäre, wenn wir zusätzlich zu Register 1, das auf den Anfang des serialisierten Eingabebereichs zeigt, die VM auch mit einem Zeiger auf das erste Byte unserer Anweisungsdaten in Register 2 instanziieren? Dies würde es uns ermöglichen, pro-Anweisung entrypoints zu erstellen, die es uns erlauben, Techniken wie nodup sicher und leistungsfähig zu nutzen. @realbuffalojoe griff die Idee auf, schrieb die SIMD- und Agave-Implementierung und schob eine ganze Menge verrückter PRs zu unseren Mainnet-Kompatibilitätswerkzeugen, um sicherzustellen, dass dies für alle derzeit bereitgestellten Programme und Cluster sicher wäre. Die Funktion ist jetzt im Testnetz und im Entwicklungsnetz aktiv und soll innerhalb der nächsten Woche im Mainnet aktiviert werden. Dann erreicht Quasar offiziell die Mainnet-Kompatibilität. Als Ergebnis unserer gemeinsamen Arbeit entstand eine neue Optimierung: Wenn man davon ausgeht, dass man sofortigen Zugriff auf den Anweisungsdiskriminator über r2 hat, ist es jetzt möglich zu wissen: - genau, wie viele Konten Ihre Anweisung erwartet, und - ob sie ein Unterzeichner, veränderbar, ausführbar oder doppelt sind. Aufgrund der Art und Weise, wie die Kontoflaggen in einer zusammenhängenden 4-Byte-Sequenz codiert sind, müssen wir nicht vier individuelle Überprüfungen (is_duplicate(), is_signer(), is_mutable(), is_executable()) durchführen, sondern können diese tatsächlich in einen einzigen u16- oder u32-Vergleich stapeln. Das bedeutet, dass der r2 entrypoint nicht nur nodup sicher und optimal nutzen kann; er gibt uns auch typischerweise unsere Unterzeichner-/veränderbar-/ausführbar-Überprüfungen kostenlos! Wir sind immer noch an unserem Tag Null "unrelease", arbeiten hart daran, die API zu stabilisieren und unsere erste offizielle Version herauszubringen, aber wir werden sicher einige ordentliche Forschungen veröffentlichen, die einige der Techniken detailliert beschreiben, die wir auf dem Weg entdeckt haben, sobald wir fertig sind. Eines ist sicher: Die Ermöglichung eines effizienten Solana-Programmier-Frameworks war nicht nur eine @blueshift-Anstrengung. Wir stehen auf den Schultern von Riesen. 🙏