Letzte Woche hat @redacted_noah einen Wutausbruch darüber gesendet, wie Zero Copy™️ auf @anchorlang das perfekte Alpha für jeden @solana-Entwickler ist. Ich dachte, dass Zero Copy nur für sehr große Konten verwendet wird. Mir wurde klar, dass ich keine Ahnung hatte, warum ich es manchmal verwendet habe. Ich habe beschlossen, tiefer einzutauchen, lass mich dich mitnehmen 👇

@SuperteamFRANCE @SuperteamJapan Zuerst, warum sprechen wir überhaupt über Zero Copy Datenparsing? Der Standarddatenparser von Anchor heißt Borsh. Beim Aufruf einer Anchor-Anweisung wird Borsh Ihre Kontodaten in eine Borsh-Struktur kopieren (in einen Speicherplatz namens "der Heap", dazu später mehr)

Wenn Sie ein Konto in Ihre Anweisung einfügen, verwenden Sie ein Format, das so aussieht.

Wenn Sie Zero Copy verwenden, wird Ihr Code so aussehen.

Was passiert dort eigentlich? Es ist nicht auf den ersten Blick offensichtlich! Zuerst müssen wir verstehen, wie Solana seine Rust-App-Daten verwendet: den Heap, den Stack und den "Zero Copy"-Bereich.

1. Stack: Hier speichern wir lokale und einfache Datentypen. Du erhältst 4KiB Speicherplatz für jeden Stack, jeder Funktionsaufruf erhält seine eigene 4KiB-Zuweisung. "Zugriffsverletzung im Stack-Frame X an Adresse XXXXX von Größe X." ist die Art von Fehler, die du erhältst, wenn du die maximale Stack-Größe überschreitest. In Anchor ist die erste Lösung für diesen Fehler, ein `Box` zu verwenden, um die Daten vom Stack in den "Heap" zu verschieben 👇

2. Heap in Solana: Programme laufen standardmäßig in einer BPF-VM mit 32KB Heap. Dies ist eine einmalige Zuweisung für einen gesamten Aufruf. Hier würden Sie dynamischere Datentypen (Vec, String) speichern. Das Deserialisieren von Konten mit Borsh kopiert Daten in den Heap und verbraucht schnell Speicherplatz.

3. Zero Copy: Wenn Sie den Heap und den Stack umgehen müssen, weil Ihr gesamtes Datenbudget überschritten wird (viele CPIs mit großen Konten), verwenden Sie Zero Copy. Zero Copy ermöglicht es Ihnen, mit den Daten zu arbeiten, ohne sie zuerst zuzuweisen oder zu kopieren, indem die Deserialisierung übersprungen wird.

Wann macht Zero Copy Sinn? 1. Große Daten 2. Arbeiten mit vielen CPIs Lass uns weitermachen:

1. Große Daten Angenommen, Sie möchten eine Liste von Wallets direkt in Ihrem Zustand verfolgen, um vollständig Onchain-Überprüfungen durchführen zu können (wenn Sie dies tun müssen, schauen Sie sich Merkle-Bäume an 😅, das ist nicht der richtige Weg, um es zu tun). Wie bei einer Verlosung, bei der die Adresse jedes Teilnehmers gespeichert wird, bevor die endgültige Ziehung durchgeführt und ein Gewinner ausgewählt wird. Dies wird leicht über 32kb Speicherplatz hinausgehen. Ein Teilnehmer = 32 Bytes, also wenn Sie planen, erfolgreich zu sein und Platz für 1000 Teilnehmer einzuplanen, verbraucht dies bereits den gesamten Heap-Speicher (32 000 Bytes). In dieser Situation können Sie Zero Copy verwenden, um die Einschränkung zu umgehen und mit viel größeren Konten zu arbeiten, ohne die Heap- oder Stack-Grenzen zu erreichen.

WIE BEHEBEN? Ganz einfach! Verwende überall Zero Copy. Es ist so einfach wie das 👇 (füge das #[account("zero_copy")] Makroattribut zum RootEscrow-Konto hinzu) ABER Zero Copy bringt eine weitere Herausforderung mit sich, der Grund, warum Anchor sich ursprünglich für Borsh entschieden hat: Byte-Ausrichtung.

Byte-Ausrichtung ist eine Low-Level-Technik, die jeder Solana-Entwickler verstehen sollte, unabhängig davon, ob er Zero-Copy verwendet oder nicht Es erfordert, dass Strukturen durch Bytemuck zero-copy-sicher sind (Byte-Ausrichtung kann Panik verursachen, wenn sie nicht korrekt behandelt wird) Ich werde bald einen weiteren Thread zu diesem *spannenden* Thema veröffentlichen 🔥

In der Zwischenzeit, schaut euch @legendsdotfun an, das Produkt, an dem ich seit Mitte September arbeite und an dem ich am @colosseum Cypherpunk Hackathon teilnehme. Registriert euer Produkt, gebt Upvotes an vielversprechende neue Teams. Lasst uns jede Solana-Legende zum Strahlen bringen 🤝

Vielen Dank an die Geißböcke: - @redacted_noah - @blockiosaurus - @0xIchigo Für das Korrekturlesen dieses Live-Entdeckungsthreads!