Es obvio por qué Quasar está ganando a Anchor, pero mucha gente también se pregunta "¿por qué Quasar le gana a Pinocho en algunos benchmarks de CU?" Personalmente, no me gusta nada la forma en que plantea la pregunta, ya que parece sacar una conclusión incorrecta. Desde luego, no es que @0x_febo olvidado optimizar muchas cosas y conseguimos adelantárnosle. ¡De hecho, todo lo contrario! Pinocho, y ahora por extensión, las versiones más recientes del SDK de Solana, son en realidad *tan* óptimas que la única forma que hemos encontrado para reducir significativamente las CUs es introduciendo contexto adicional en forma de un framework. Comparar una biblioteca con un framework no es una comparación directa. Hay muchas optimizaciones específicas de programas que son triviales de implementar cuando tienes suficiente contexto, pero extremadamente difíciles de generalizar a una biblioteca independiente del programa. Permíteme explicar uno de esos casos: En 2024, @cavemanloverboy introdujo solana-nostd-punto de entrada y solana-nostd-invoke. Este fue el primer intento serio de abordar algunos de los peores códigos de SDK de Solana consumidos por todos los programas onchain. Dentro de esta caja, Cavey introdujo una técnica llamada punto de entrada "nodup", donde en lugar de quemar CUs para gestionar cuentas duplicadas, simplemente cometes un error en el momento en que te encuentras con una. Esta técnica se combina bien con otras optimizaciones que explicaré más adelante. Desafortunadamente, debido a la naturaleza originalmente de cómo el punto de entrada de Solana fue diseñado originalmente para ser global para todas las instrucciones de un programa, y requerir análisis integral de muchas entradas de longitud variable para lograr cualquier conciencia situacional, basta con que una instrucción de tu programa tenga una posible cuenta duplicada para que todo el programa no pueda aprovechar esta técnica. El año pasado, planteé una idea a Febo, Cavey y @alessandrod: ¿Y si, además de que el registro 1 apunta al inicio de la región de entrada serializada, también instanciamos la VM con un puntero al primer byte de nuestros datos de instrucción en el registro 2? Esto nos permitiría crear puntos de entrada por instrucción, lo que nos permitiría aprovechar de forma segura y eficiente técnicas como nodup. @realbuffalojoe cogió la idea, escribió la implementación de SIMD y agave, y envió un montón de PRs locos a nuestras herramientas de compatibilidad de mainnet para asegurar que esto fuera seguro para todos los programas y clústeres actualmente desplegados. La función ya está activa en testnet y devnet, y está previsto que se active en la mainnet en la próxima semana aproximadamente. Es entonces cuando Quasar logra oficialmente la compatibilidad con mainnet. Como resultado de que todos trabajáramos juntos, surgió una nueva optimización: al operar bajo la suposición de que tienes acceso inmediato al discriminador de instrucciones mediante r2, ahora es posible saber: - exactamente cuántas cuentas espera tu instrucción, y - si serán firmantes, mutables, ejecutables o duplicados Debido a cómo se codifican las banderas de la cuenta en una secuencia continua de 4 bytes, en lugar de tener que realizar cuatro comprobaciones individuales (is_duplicate(), is_signer(), is_mutable(), is_executable()), podemos apilar estas en una única comparación u16 o u32. Esto significa que no solo el punto de entrada r2 puede utilizar de forma segura y óptima el nodup; ¡También suele darnos nuestros cheques de firmante/mutable/ejecutables gratis! Todavía estamos en nuestro día cero de "unrelease", trabajando duro para estabilizar la API y sacar nuestra primera versión oficial, pero nos aseguraremos de hacer una investigación adecuada detallando algunas de las técnicas que hemos descubierto en el proceso. Una cosa es segura: habilitar un marco eficiente de programas Solana no fue solo un esfuerzo @blueshift. Estamos sobre los hombros de gigantes. 🙏