La semana pasada, @redacted_noah envió un desahogo sobre cómo Zero Copy™️ en @anchorlang es el perf alpha para cada @solana dev Pensé que zero copy solo se usaba para cuentas muy grandes Me di cuenta de que no tenía idea de por qué a veces lo estaba usando Decidí profundizar, déjame llevarte contigo 👇

@SuperteamFRANCE @SuperteamJapan Primero, ¿por qué estamos hablando de la análisis de datos sin copia? El analizador de datos predeterminado de Anchor se llama Borsh. Al llamar a una instrucción de Anchor, Borsh va a copiar los datos de tu cuenta en una estructura Borsh (en un espacio de memoria llamado "el heap", más sobre esto más adelante)

Cuando incluyes una cuenta en tu instrucción, utilizas un formato que se ve así.

Al usar zero copy, tu código se verá así.

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

1. Pila: Aquí es donde almacenamos tipos de datos locales y simples. Tienes 4KiB de espacio para cada pila, cada llamada a función obtiene su propia asignación de 4KiB. "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 obtienes cuando superas 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 a la "montículo" 👇

2. Heap en Solana: Los programas se ejecutan en una máquina virtual BPF con un heap de 32KB por defecto. Esta es una asignación única para una invocación completa. Aquí es donde almacenarías tipos de datos más dinámicos (Vec, String) Deserializar cuentas con Borsh copia datos al heap, consumiendo espacio rápidamente

3. Zero copy: Si debes eludir el heap y la pila porque tu presupuesto de datos completo se excede (muchos CPIs, con cuentas grandes), utilizarás Zero copy. Zero copy te permite trabajar con los datos sin tener que asignarlos ni copiarlos primero, omitiendo la deserialización.

¿Cuándo tiene sentido Zero copy? 1. Datos grandes 2. Trabajando con muchos CPIs Sigamos adelante:

1. Datos grandes Supongamos que quieres rastrear una lista de billeteras directamente en tu estado para poder realizar verificaciones completamente en la cadena (si necesitas hacer esto, investiga sobre los árboles de Merkle 😅, esta no es la forma de hacerlo) Como en una rifa, almacenando la dirección de cada participante antes de realizar el sorteo final y seleccionar un ganador. Esto fácilmente superará los 32kb de memoria. Un participante = 32 bytes, así que si planeas tener éxito y asignar espacio para 1000 participantes, esto ya está consumiendo todo el tamaño del montón (32 000 bytes) En esta situación, puedes optar por Zero copy para eludir la limitación y permitir trabajar con cuentas mucho más grandes sin alcanzar los límites del montón ni de la pila.

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

La alineación de bytes es una técnica de bajo nivel que todo desarrollador de Solana debería entender, ya sea utilizando cero copias 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 *emocionante* tema 🔥

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

¡Muchas gracias a los cabras: - @redacted_noah - @blockiosaurus - @0xIchigo ¡Por revisar este hilo de descubrimiento en vivo!