Brorsan, jag har sagt det till er. Det är bokstavligen bara färdighetsproblem hela vägen ner. har alltid varit det. 😭

Det är uppenbart varför Quasar slår Anchor, men många frågar också "varför slår Quasar Pinocchio på vissa CU-benchmarks?" Jag ogillar personligen verkligen hur frågan formuleras, eftersom den verkar dra en felaktig slutsats. Det är definitivt inte så att @0x_febo försummade att optimera en massa saker och vi lyckades slå honom till det. Tvärtom, faktiskt! Pinocchio, och nu i förlängningen de nyare versionerna av Solana SDK, är faktiskt *så* optimala att det enda sättet vi har hittat för att avsevärt minska CU:er ytterligare är att införa ytterligare kontext i form av ett ramverk. Att jämföra ett bibliotek med ett ramverk är inte en jämförelse mellan äpplen och äpplen. Det finns många programspecifika optimeringar som är triviala att implementera när du har tillräckligt med kontext, men extremt svåra att generalisera till ett programoberoende bibliotek. Låt mig förklara ett sådant fall: År 2024 introducerade @cavemanloverboy solana-nostd-entrypoint och solana-nostd-invoke. Detta var det första seriösa försöket att ta itu med några av de absolut sämsta Solana SDK-koderna som konsumeras av varje enskilt onchain-program. I denna låda introducerade Cavey en teknik som kallas "nodup"-entrypoint, där du istället för att bränna CU:er för att hantera dubblettkonton helt enkelt går ut direkt när du stöter på ett. Den här tekniken fungerar bra ihop med några andra optimeringar som jag kommer att gå in på senare. Tyvärr, på grund av hur Solana-ingångspunkten ursprungligen designades för att vara både global för alla instruktioner i ett program och kräva fullständig parsning av många variabellängdsindata för att uppnå någon situationsmedvetenhet, räcker det med att en instruktion i ditt program har ett potentiellt duplicat för att hela programmet ska kunna utnyttja denna teknik. Förra året föreslog jag en idé för Febo, Cavey och @alessandrod: Tänk om vi, utöver att register 1 pekar mot början av den serialiserade inmatningsregionen, också instansierade VM:n med en pekare till den första byten av vår instruktionsdata i register 2? Detta skulle göra det möjligt för oss att skapa ingångspunkter per instruktion, vilket gör att vi säkert och effektivt kan dra nytta av tekniker som nodup. @realbuffalojoe plockade upp idén, skrev SIMD- och agave-implementationen och skickade en massa galna PR:er till våra mainnet-kompatibilitetsverktyg för att säkerställa att detta skulle vara säkert för alla program och kluster som redan är distribuerade. Funktionen är nu aktiv på testnet och devnet, och förväntas aktiveras på mainnet inom en vecka eller så. Det är då Quasar officiellt uppnår mainnet-kompatibilitet. Som ett resultat av att vi alla arbetade tillsammans uppstod en ny optimering: När man utgår från att man har omedelbar tillgång till instruktionsdiskriminatorn via r2, är det nu möjligt att veta: - exakt hur många konton din instruktion förväntar sig, och - om de kommer att vara signerare, muterbara, exekverbara eller dubbletter Eftersom kontoflaggorna kodas i en sammanhängande 4-bytes sekvens, istället för att behöva utföra fyra individuella kontroller (is_duplicate(), is_signer(), is_mutable(), is_executable()), kan vi faktiskt stapla dessa till en enda u16- eller u32-jämförelse. Detta innebär att inte bara kan r2-ingångspunkten använda nodup säkert och optimalt; Den ger oss också vanligtvis våra signer-/mutable/executable-kontroller gratis! Vi är fortfarande på vår dag noll "unrelease", kämpar på för att stabilisera API:et och släppa vår första officiella version, men vi kommer definitivt att publicera ordentlig forskning som beskriver några av de tekniker vi upptäckt längs vägen när vi är klara. En sak är säker: Att möjliggöra ett effektivt Solana-programramverk var inte bara en @blueshift insats. Vi står på jättarnas axlar. 🙏

Det mest grundläggande med Terafab-presentationen, förutom en bokstavlig elektromagnetisk katapult som skjuter AI-satelliter från månen, var @elonmusk pluraliserade "Optimus" till "Optimi".