Na semana passada, @redacted_noah enviou um discurso retórico sobre como Zero Copy™️ no @anchorlang é o alfa de desempenho para cada desenvolvedor @solana Eu pensei que a cópia zero era usada apenas para contas muito grandes Percebi que não tinha ideia de por que às vezes o usava Eu decidi mergulhar fundo, deixe-me levá-lo junto 👇

@SuperteamFRANCE @SuperteamJapan Primeiro, por que estamos falando sobre análise de dados de cópia zero? O analisador de dados padrão do Anchor é chamado de Borsh. Ao chamar uma instrução Anchor, o Borsh copiará os dados da sua conta em uma estrutura do Borsh (para um slot de memória chamado "heap", mais sobre isso mais tarde)

Ao incluir uma conta em sua instrução, você usa um formato parecido com este.

Ao usar cópia zero, seu código ficará assim.

Então, o que realmente está acontecendo lá? Não é óbvio desde o início! Primeiro, precisamos entender como Solana usa os dados do aplicativo Rust: o heap, a pilha e o espaço de "cópia zero".

1. Pilha: É aqui que armazenamos tipos de dados locais e simples. Você obtém 4KiB de espaço para cada pilha, cada chamada de função recebe sua própria alocação de 4KiB. "Violação de acesso no quadro de pilha X no endereço XXXXX de tamanho X." é o tipo de erro que você recebe quando excede o tamanho máximo da pilha. No Anchor, a primeira correção para esse erro é usar uma 'Caixa' para mover os dados da pilha para o "heap" 👇

2. Pilha em Solana: Os programas são executados em uma VM BPF com heap de 32 KB por padrão. Esta é uma alocação única para uma invocação inteira. É aqui que você armazenaria tipos de dados mais dinâmicos (Vec, String) A desserialização de contas com Borsh copia dados para o heap, consumindo espaço rapidamente

3. Cópia zero: Se você precisar ignorar o heap e a pilha porque seu orçamento total de dados foi excedido (muitos CPIs, com contas grandes), você usará a cópia zero. A cópia zero permite que você trabalhe com os dados sem precisar alocá-los nem copiá-los primeiro, ignorando a desserialização.

Quando a cópia Zero faz sentido? 1. Dados grandes 2. Trabalhando com muitos CPIs Vamos continuar:

1. Dados grandes Digamos que você queira rastrear uma lista de carteiras diretamente em seu estado para poder executar verificações totalmente onchain (se você precisar fazer isso, olhe para as árvores 😅 merkle, esta não é a maneira de fazer isso) Como em um sorteio, armazenando o endereço de cada participante antes de realizar o sorteio final e selecionar um vencedor. Isso irá facilmente além da memória de 32kb. Um participante = 32 bytes, portanto, se você planeja ser bem-sucedido e alocar espaço para 1000 participantes, isso já está consumindo todo o tamanho do heap (32.000 bytes) Nessa situação, você pode usar Zero copy para contornar a limitação e permitir o trabalho com contas muito maiores sem atingir o heap nem os limites de pilha.

COMO CONSERTAR? Simples! Basta usar Zero Copy em todos os lugares. É tão fácil quanto isso 👇 (adicione o atributo de macro #[account("zero_copy")] à conta RootEscrow) MAS a cópia zero vem com outro desafio, a razão pela qual a Anchor escolheu Borsh em primeiro lugar: alinhamento de bytes.

O alinhamento de bytes é uma técnica de baixo nível que todo desenvolvedor Solana deve entender usando cópia zero ou não Ele requer que os structs sejam seguros contra cópia zero por meio de bytemuck (o alinhamento de bytes pode causar pânicos se não for tratado corretamente) Vou publicar outro tópico sobre este tópico * emocionante * em breve 🔥

Enquanto isso, confira @legendsdotfun o produto que venho construindo desde meados de setembro e participando do hackathon @colosseum Cypherpunk Registre seu produto, dê upvotes para novas equipes promissoras Vamos fazer cada lenda da Solana brilhar 🤝

Muito obrigado às cabras: - @redacted_noah - @blockiosaurus - @0xIchigo Para a leitura de prova deste tópico de descoberta ao vivo!