Quasar'ın neden Anchor'ı geçtiği açık, ama birçok kişi ayrıca "Quasar neden bazı CU benchmarklarında Pinocchio'yu geçiyor?" diye soruyor. Ben şahsen sorunun çerçevelenmesini gerçekten sevmiyorum, çünkü yanlış bir sonuca varıyor gibi görünüyor. @0x_febo birçok şeyi optimize etmeyi ihmal etmiş ve biz onu geçtik. Tam tersi! Pinokyo ve şimdi dolayısıyla Solana SDK'nın yeni sürümleri aslında *o kadar* optimaldir ki, CU'ları önemli ölçüde azaltmanın tek yolu bir çerçeve şeklinde ek bağlam eklemektir. Bir kütüphaneyi bir çerçeveyle karşılaştırmak tam bir karşılaştırma değildir. Yeterli bağlam olduğunda uygulaması kolay olan birçok programa özgü optimizasyon vardır, ancak programdan bağımsız bir kütüphaneye genelleştirmek son derece zordur. Böyle bir durumu açıklamama izin verin: 2024 yılında @cavemanloverboy, solana-nostd-entrypoint ve solana-nostd-invoke tanıttı. Bu, her bir onchain programın tükettiği en kötü Solana SDK kodlarından bazılarını ele alma için yapılan ilk ciddi girişimdi. Bu sandık içinde Cavey, "nodup" giriş noktası adında bir teknik tanıttı; burada tekrarlanan hesapları yönetmek için CU'ları yakmak yerine, karşılaştığınız anda hata yaparsınız. Bu teknik, daha sonra detaylanacağım bazı diğer optimizasyonlarla iyi uyum sağlıyor. Ne yazık ki, Solana giriş noktasının başlangıçta programdaki tüm komutlar için küresel olması ve durumsal farkındalık elde etmek için birçok değişken uzunlukta girinin tam ayrıştırılması gerektirmesi nedeniyle, programınızdaki tek bir komutun tüm programın bu teknikten faydalanamaması için potansiyel bir tekrarlayıcı hesaba sahip olması yeterlidir. Geçen yıl Febo, Cavey ve @alessandrod'a bir fikir sundum: Ya seri giriş bölgesinin başlangıcına işaret eden kayıt 1'in yanı sıra, VM'yi kayıt 2'deki komut verimizin ilk baytına işaret eden bir işaretle de başlatsak? Bu, talimatlar başına giriş noktaları oluşturmamıza olanak tanır ve nodup gibi tekniklerden güvenli ve performanslı şekilde faydalanmamızı sağlar. @realbuffalojoe fikri benimsedik, SIMD ve agave uygulamasını yazdık ve ana ağ uyumluluk araçlarımıza bir sürü çılgın PR göndererek şu anda konuşlandırılan tüm programlar ve kümeler için güvenli olmasını sağladık. Özellik artık testnet ve devnet'te aktif ve önümüzdeki hafta içinde ana net'te aktif hale gelecek. İşte o zaman Quasar resmen ana ağ uyumluluğunu elde ediyor. Hepimizin birlikte çalışmasının sonucu olarak yeni bir optimizasyon ortaya çıktı: Komut ayırtıcısına r2 üzerinden anında erişiminiz olduğu varsayımıyla çalıştığınızda, artık şunları bilmek mümkündür: - talimatlarınızın tam olarak kaç hesap beklediği ve - imzalayıcı, değiştirilebilir, çalıştırılabilir veya çoğaltıcı olup olmayacağı Hesap bayraklarının bitişik 4 baytlık bir dizide kodlandığı nedeniyle, dört ayrı kontrol (is_duplicate(), is_signer(), is_mutable(), is_executable()) yapmak zorunda kalmadan, bunları tek bir u16 veya u32 karşılaştırmasına yerleştirebiliyoruz. Bu, r2 giriş noktasının sadece güvenli ve optimal şekilde nodup'u kullanabildiği anlamına gelir; Ayrıca genellikle bize imzacı/değiştirilebilir/çalıştırılabilir kontrollerimizi ücretsiz veriyor! Hâlâ sıfır günümüzde "yayınlanma" sürecindeyiz, API'yi stabilize etmek ve ilk resmi sürümümüzü çıkarmak için uğraşıyoruz, ama işimiz bittikten sonra keşfettiğimiz bazı teknikleri detaylandıran düzgün araştırmalar yapacağız. Kesin olan bir şey var: Verimli bir Solana program çerçevesini etkinleştirmek sadece @blueshift bir çaba değildi. Devlerin omuzlarında duruyoruz. 🙏