#[account]
Expand description

An attribute for a data structure representing a Solana account.

#[account] generates trait implementations for the following traits:

When implementing account serialization traits the first 8 bytes are reserved for a unique account discriminator, self described by the first 8 bytes of the SHA256 of the account’s Rust ident.

As a result, any calls to AccountDeserialize’s try_deserialize will check this discriminator. If it doesn’t match, an invalid account was given, and the account deserialization will exit with an error.

Zero Copy Deserialization

WARNING: Zero copy deserialization is an experimental feature. It’s recommended to use it only when necessary, i.e., when you have extremely large accounts that cannot be Borsh deserialized without hitting stack or heap limits.

Usage

To enable zero-copy-deserialization, one can pass in the zero_copy argument to the macro as follows:

#[account(zero_copy)]

This can be used to conveniently implement ZeroCopy so that the account can be used with Loader.

Other than being more efficient, the most salient benefit this provides is the ability to define account types larger than the max stack or heap size. When using borsh, the account has to be copied and deserialized into a new data structure and thus is constrained by stack and heap limits imposed by the BPF VM. With zero copy deserialization, all bytes from the account’s backing RefCell<&mut [u8]> are simply re-interpreted as a reference to the data structure. No allocations or copies necessary. Hence the ability to get around stack and heap limitations.

To facilitate this, all fields in an account must be constrained to be “plain old data”, i.e., they must implement Pod. Please review the safety section before using.