Este evident de ce Quasar îl învinge pe Anchor, dar mulți oameni se întreabă și "de ce Quasar îl bate pe Pinocchio la unele benchmark-uri CU?" Personal, nu-mi place deloc formularea întrebării, deoarece pare să tragă o concluzie greșită. Cu siguranță nu @0x_febo neglijat să optimizeze multe lucruri și am reușit să-l luăm înainte. Dimpotrivă, de fapt! Pinocchio, și acum, prin extensie, versiunile mai noi ale SDK-ului Solana, sunt de fapt *atât de* optime încât singura modalitate pe care am găsit-o de a reduce semnificativ CU-urile este prin introducerea unui context suplimentar sub forma unui framework. Compararea unei biblioteci cu un framework nu este o comparație directă. Există multe optimizări specifice programului care sunt ușor de implementat când ai suficient context, dar extrem de greu de generalizat într-o bibliotecă independentă de program. Permiteți-mi să explic un astfel de caz: În 2024, @cavemanloverboy introdus solana-nostd-entrypoint și solana-nostd-invoke. Aceasta a fost prima încercare serioasă de a aborda unele dintre cele mai proaste coduri SDK Solana consumate de fiecare program onchain. În cadrul acestei lăzi, Cavey a introdus o tehnică numită punctul de intrare "nodup", unde în loc să arzi CU-uri pentru a gestiona conturi duplicate, pur și simplu faci o eroare în momentul în care întâlnești unul. Această tehnică se combină bine cu alte optimizări despre care voi vorbi mai târziu. Din păcate, din cauza naturii modului în care punctul de intrare Solana a fost proiectat inițial să fie atât global pentru toate instrucțiunile dintr-un program, cât și să necesite analizarea completă a multor intrări de lungime variabilă pentru a obține o conștientizare situațională, tot ce este necesar ca o singură instrucțiune din programul tău să aibă un cont duplicat potențial pentru ca întregul program să nu poată profita de această tehnică. Anul trecut, am propus o idee către Febo, Cavey și @alessandrod: Ce-ar fi dacă, pe lângă registrul 1 care indică începutul regiunii de intrare serializate, am instanția și VM-ul cu un pointer către primul octet al datelor noastre de instrucțiuni din registrul 2? Acest lucru ne-ar permite să creăm puncte de intrare pe fiecare instrucțiune, permițându-ne să profităm în siguranță și performant de tehnici precum nodup. @realbuffalojoe preluat ideea, am scris implementarea SIMD și agave și am trimis o mulțime de PR-uri nebunești către uneltele noastre de compatibilitate mainnet pentru a ne asigura că acestea vor fi sigure pentru toate programele și clusterele deja implementate. Funcția este acum activă pe testnet și devnet și urmează să fie activată pe mainnet în următoarea săptămână sau cam așa. Atunci Quasar obține oficial compatibilitatea mainnet-ului. Ca rezultat al colaborării cu toții, a apărut o nouă optimizare: operând sub presupunerea că ai acces imediat la discriminatorul de instrucțiuni prin r2, acum este posibil să știi: - exact câte conturi se așteaptă instrucțiunea ta, și - dacă vor fi semnatari, mutable, executabile sau duplicate Datorită modului în care sunt codificate flag-urile contului într-o secvență contiguă de 4 octeți, în loc să fie nevoie să efectuăm patru verificări individuale (is_duplicate(), is_signer(), is_mutable(), is_executable()), putem de fapt să le suprapunem într-o singură comparație u16 sau u32. Aceasta înseamnă că nu doar punctul de intrare r2 poate folosi în siguranță și optim nodup; De asemenea, de obicei ne oferă gratuit cecurile semnatare/mutabile/executabile! Suntem încă în ziua zero de "lansare", muncind din greu încercând să stabilizăm API-ul și să lansăm prima versiune oficială, dar cu siguranță vom publica niște cercetări serioase care să detalieze unele dintre tehnicile descoperite pe parcurs după ce terminăm. Un lucru este sigur: Activarea unui cadru eficient de program Solana nu a fost doar un efort @blueshift. Stăm pe umerii giganților. 🙏