È ovvio perché Quasar sta battendo Anchor, ma molte persone si stanno anche chiedendo "perché Quasar sta battendo Pinocchio su alcuni benchmark CU?" Personalmente, non mi piace affatto il modo in cui è formulata la domanda, poiché sembra trarre una conclusione errata. Non è affatto vero che @0x_febo ha trascurato di ottimizzare un sacco di cose e noi siamo riusciti a batterlo. Al contrario, in effetti! Pinocchio, e ora per estensione, le versioni più recenti di Solana SDK, sono in realtà *così* ottimali che l'unico modo che abbiamo trovato per ridurre significativamente i CU ulteriormente è introducendo un contesto aggiuntivo sotto forma di un framework. Confrontare una libreria con un framework non è un confronto tra mele e mele. Ci sono molte ottimizzazioni specifiche per programma che sono banali da implementare quando hai abbastanza contesto, ma estremamente difficili da generalizzare in una libreria indipendente dal programma. Permettimi di spiegare un caso del genere: Nel 2024, @cavemanloverboy ha introdotto solana-nostd-entrypoint e solana-nostd-invoke. Questo è stato il primo tentativo serio di affrontare alcuni dei peggiori codici di Solana SDK consumati da ogni singolo programma on-chain. All'interno di questo crate, Cavey ha introdotto una tecnica chiamata "nodup" entrypoint, dove invece di bruciare CU per gestire account duplicati, semplicemente restituisci un errore nel momento in cui ne incontri uno. Questa tecnica si combina bene con alcune altre ottimizzazioni di cui parlerò più avanti. Sfortunatamente, a causa della natura di come l'entrypoint di Solana è stato originariamente progettato per essere globale per tutte le istruzioni in un programma e richiedere un'analisi completa di molti input di lunghezza variabile per ottenere consapevolezza situazionale, basta che un'istruzione nel tuo programma abbia un potenziale account duplicato affinché l'intero programma non possa sfruttare questa tecnica. L'anno scorso, ho proposto un'idea a Febo, Cavey e @alessandrod: e se, oltre a registrare 1 che punta all'inizio della regione di input serializzato, istituissimo anche la VM con un puntatore al primo byte dei nostri dati di istruzione nel registro 2? Questo ci permetterebbe di creare entrypoint per istruzione, consentendoci di sfruttare in modo sicuro e performante tecniche come nodup. @realbuffalojoe ha raccolto l'idea, ha scritto l'implementazione SIMD e agave, e ha spinto un sacco di PR pazzeschi ai nostri strumenti di compatibilità mainnet per garantire che questo fosse sicuro per tutti i programmi e cluster attualmente distribuiti. La funzionalità è ora attiva su testnet e devnet, e dovrebbe essere attivata su mainnet entro la prossima settimana. È allora che Quasar raggiunge ufficialmente la compatibilità con mainnet. Come risultato di tutti noi che lavoriamo insieme, è emersa una nuova ottimizzazione: quando si opera assumendo di avere accesso immediato al discriminatore di istruzioni tramite r2, ora è possibile sapere: - esattamente quanti account il tuo comando si aspetta, e - se saranno un firmatario, mutabile, eseguibile o duplicato A causa di come i flag degli account sono codificati in una sequenza contigua di 4 byte, piuttosto che dover eseguire quattro controlli individuali (is_duplicate(), is_signer(), is_mutable(), is_executable()), possiamo effettivamente impilarli in un'unica comparazione u16 o u32. Questo significa che non solo l'entrypoint r2 è in grado di utilizzare in modo sicuro e ottimale nodup; ci fornisce anche tipicamente i nostri controlli firmatario/mutabile/eseguibile gratuitamente! Siamo ancora nel nostro giorno zero "unrelease", lavorando duramente per stabilizzare l'API e pubblicare la nostra prima versione ufficiale, ma ci assicureremo di pubblicare alcune ricerche adeguate che dettagliino alcune delle tecniche che abbiamo scoperto lungo il cammino una volta che avremo finito. Una cosa è certa: abilitare un framework di programma Solana efficiente non è stato solo uno sforzo di @blueshift. Stiamo sulle spalle di giganti. 🙏