Bruh, jeg har sagt det til dere. Det er bokstavelig talt bare ferdighetsproblemer hele veien ned. Har alltid vært det. 😭

Det er åpenbart hvorfor Quasar slår Anchor, men mange spør også «hvorfor slår Quasar Pinocchio på noen CU-benchmarks?» Personlig misliker jeg innrammingen av spørsmålet, da det ser ut til å trekke en feil konklusjon. Det er absolutt ikke slik at @0x_febo glemte å optimalisere mange ting, og vi klarte å slå ham til det. Tvert imot, faktisk! Pinocchio, og nå i forlengelsen de nyere versjonene av Solana SDK, er faktisk *så* optimale at den eneste måten vi har funnet for å redusere CU-er betydelig mer, er å introdusere ekstra kontekst i form av et rammeverk. Å sammenligne et bibliotek med et rammeverk er ikke en eple-til-eple-sammenligning. Det finnes mange programspesifikke optimaliseringer som er trivielle å implementere når du har nok kontekst, men ekstremt vanskelige å generalisere til et programuavhengig bibliotek. La meg forklare et slikt tilfelle: I 2024 introduserte @cavemanloverboy solana-nostd-entrypoint og solana-nostd-invoke. Dette var det første seriøse forsøket på å adressere noe av den absolutt verste Solana SDK-koden som ble brukt av hvert eneste onchain-program. Inne i denne kassen introduserte Cavey en teknikk kalt "nodup" entrypoint, hvor du i stedet for å brenne CU-er for å håndtere duplikatkontoer, rett og slett går ut med en feil i det øyeblikket du møter en. Denne teknikken fungerer godt sammen med noen andre optimaliseringer som jeg skal komme nærmere inn på senere. Dessverre, på grunn av hvordan Solana-inngangspunktet opprinnelig var designet for å være både globalt for alle instruksjoner i et program, og kreve full parsing av mange variabel lengde for å oppnå situasjonsbevissthet, skal det nok til at én instruksjon i programmet ditt har en potensiell duplikatkonto for at hele programmet ikke skal kunne dra nytte av denne teknikken. I fjor lanserte jeg en idé for Febo, Cavey og @alessandrod: Hva om vi, i tillegg til at register 1 peker til starten av det serialiserte inngangsområdet, også instansierte VM-en med en peker til den første byten av instruksjonsdataene våre i register 2? Dette vil gjøre det mulig for oss å lage per-instruksjons inngangspunkter, slik at vi trygt og effektivt kan dra nytte av teknikker som nodup. @realbuffalojoe plukket opp ideen, skrev SIMD- og agave-implementeringen, og sendte en hel haug med vanvittige PR-er til våre mainnet-kompatibilitetsverktøy for å sikre at dette ville være trygt for alle programmer og klynger som allerede er distribuert. Funksjonen er nå aktiv på testnet og devnet, og skal etter planen aktiveres på mainnet i løpet av den neste uken eller så. Det er da Quasar offisielt oppnår mainnet-kompatibilitet. Som et resultat av at vi alle samarbeidet, oppsto en ny optimalisering: Når man antar at man har umiddelbar tilgang til instruksjonsdiskriminatoren via r2, er det nå mulig å vite: - nøyaktig hvor mange kontoer instruksjonen din forventer, og - om de skal være signer, foranderlig, kjørbar eller duplikat. På grunn av hvordan kontoflaggene kodes i en sammenhengende 4-bytes sekvens, i stedet for å måtte utføre fire individuelle sjekker (is_duplicate(), is_signer(), is_mutable(), is_executable()), kan vi faktisk stable disse i en enkelt u16- eller u32-sammenligning. Dette betyr at ikke bare kan r2-inngangspunktet trygt og optimalt utnytte nodup; Den gir oss også vanligvis signer-/mutable-/kjørbare sjekker gratis! Vi er fortsatt på vår dag null "unrelease", jobber hardt med å stabilisere API-et og gi ut vår første offisielle versjon, men vi skal sørge for å legge ut grundig forskning som beskriver noen av teknikkene vi har oppdaget underveis når vi er ferdige. Én ting er sikkert: Å muliggjøre et effektivt Solana-programrammeverk var ikke bare en @blueshift innsats. Vi står på skuldrene til kjemper. 🙏

Det mest grunnleggende med Terafab-presentasjonen, bortsett fra en bokstavelig elektromagnetisk katapult som skyter AI-satellitter av månen, var @elonmusk flertallet av "Optimus" som "Optimi".