La semana pasada @redacted_noah envió una diatriba sobre cómo Zero Copy™️ en @anchorlang es el alfa de rendimiento para cada desarrollador @solana Pensé que la copia cero solo se usaba para cuentas muy grandes Me di cuenta de que no tenía idea de por qué a veces lo usaba Decidí sumergirme profundamente, déjame llevarte 👇

@SuperteamFRANCE @SuperteamJapan Primero, ¿por qué estamos hablando de análisis de datos de copia cero? El analizador de datos predeterminado de Anchor se llama Borsh. Al llamar a una instrucción de anclaje, Borsh copiará los datos de su cuenta en una estructura Borsh (en una ranura de memoria llamada "el montón", más sobre esto más adelante)

Cuando incluye una cuenta en su instrucción, utiliza un formato similar a este.

Cuando se usa zero copy, el código se verá así.

Entonces, ¿qué está sucediendo realmente allí? ¡No es obvio desde el principio! Primero debemos entender cómo Solana usa los datos de su aplicación Rust: el montón, la pila y el espacio de "copia cero".

1. Apilar: Aquí es donde almacenamos tipos de datos locales y simples. Obtiene 4 KiB de espacio para cada pila, cada llamada de función obtiene su propia asignación de 4 KiB. "Violación de acceso en el marco de pila X en la dirección XXXXX de tamaño X." es el tipo de error que se obtiene cuando se supera el tamaño máximo de la pila. En Anchor, la primera solución para este error es usar un 'Box' para mover los datos de la pila al "montón" 👇

2. Montón en Solana: Los programas se ejecutan en una máquina virtual BPF con un montón de 32 KB de forma predeterminada. Esta es una asignación única para una invocación completa. Aquí es donde almacenaría tipos de datos más dinámicos (Vec, String) La deserialización de cuentas con Borsh copia los datos en el montón, lo que consume espacio rápidamente

3. Copia cero: Si debe omitir el montón y la pila porque se excede su presupuesto de datos completo (muchos CPI, con cuentas grandes), usará Zero copy. La copia cero le permite trabajar con los datos sin tener que asignarlos ni copiarlos primero omitiendo la deserialización.

¿Cuándo tiene sentido la copia cero? 1. Grandes datos 2. Trabajar con muchos CPI Sigamos adelante:

1. Grandes datos Digamos que desea rastrear una lista de billeteras directamente en su estado para poder ejecutar verificaciones completas en cadena (si necesita hacer esto, busque en los árboles 😅 de merkle, esta no es la forma de hacerlo) Como en una rifa, almacenar la dirección de cada participante antes de realizar el sorteo final y seleccionar un ganador. Esto superará fácilmente la memoria de 32 kb. Un participante = 32 bytes, por lo que si planea tener éxito y asignar espacio para 1000 participantes, esto ya se está comiendo todo el tamaño del montón (32 000 bytes) En esta situación, puede optar a la copia cero para omitir la limitación y habilitar el trabajo con cuentas mucho más grandes sin alcanzar los límites del montón ni de la pila.

¿CÓMO SOLUCIONARLO? ¡Sencillo! Simplemente use Zero Copy en todas partes. Es tan fácil como esto 👇 (agregue el atributo de macro #[account("zero_copy")] a la cuenta RootEscrow) PERO la copia cero viene con otro desafío, la razón por la que Anchor eligió Borsh en primer lugar: la alineación de bytes.

La alineación de bytes es una técnica de bajo nivel que todo desarrollador de Solana debería entender usando cero copia o no Requiere que las estructuras sean seguras para cero copias a través de bytemuck (la alineación de bytes puede causar pánicos si no se maneja correctamente) Pronto publicaré otro hilo sobre este tema *emocionante* 🔥

Mientras tanto, echa un vistazo @legendsdotfun el producto que he estado construyendo desde mediados de septiembre y participando en el hackathon @colosseum Cypherpunk Registra tu producto, da votos a nuevos equipos prometedores Hagamos brillar 🤝 cada leyenda de solana

Muchas gracias a las cabras: - @redacted_noah - @blockiosaurus - @0xIchigo ¡Para corregir este hilo de descubrimiento en vivo!