Mejores prácticas de serialización
Los bytes de la cuenta son el esquema de su base de datos. Estas prácticas mantienen los diseños auditables, fáciles de migrar y resistentes a la confusión de tipos.
Cómo usar esta lista
- Documente la fórmula
SPACEjunto a cada struct de cuenta. - Agregue pruebas de deserialización con fixtures corruptos.
- Revise la tabla de unicidad de discriminadores.
A - Diseño
- Prefije cada tipo de cuenta con un discriminador único. Evita ataques de confusión de tipos.
- Almacene constantes
LENoSPACE; afirme en tiempo de ejecución al acceder. Previene errores de lectura/escritura parcial. - Anexe campos para actualizaciones; nunca reordene ni elimine campos en su lugar. Preserva la compatibilidad de cuentas activas.
- Limite los campos de longitud variable con tamaños máximos explícitos. Controla el alquiler y el griefing de CU.
- Prefiera diseños fijos en rutas críticas; documente divisiones híbridas de cero copia + Borsh. Rendimiento predecible.
B - Migración
- Envíe una instrucción de migración dedicada antes de aplicar el nuevo esquema. Evita inutilizar a los usuarios.
- Lea versiones antiguas y nuevas simultáneamente durante la transición. Despliegue sin problemas.
- Cero bytes nuevos después de la reasignación. Previene fugas de datos obsoletos.
- Registre eventos de migración para indexadores. Visibilidad operativa.
- Congelar el esquema cuando el programa se vuelve inmutable. Planifique el espacio con anticipación.
C - Pruebas
- Pruebas de serialización/deserialización de ida y vuelta en el host. Detecta errores de
LEN. - Fuzz la deserialización con bytes aleatorios. Encuentra rutas de pánico.
- Guarde los bytes de la cuenta en pruebas de integración de LiteSVM. Seguridad contra regresiones.
- Verifique que el cálculo del alquiler coincida con
SPACE. Corrección de la financiación del usuario. - Alinee los atributos
spacede Anchor con las constantes nativas. Única fuente de verdad.
Preguntas frecuentes
¿Predeterminado Borsh vs. cero copia?
Borsh a menos que el perfilado lo necesite.
¿Longitud del discriminador?
8 bytes estilo Anchor común.
¿Cadena en la cuenta?
Raro - prefiera claves pubkey.
¿`InitSpace` suficiente?
Revise el tamaño generado.
¿Despliegue inmutable?
No hay migraciones posibles - planifique el espacio.
¿Compresión?
No nativo en la cadena.
¿JSON de cuenta?
Solo fuera de la cadena.
¿Registro de esquemas?
En la documentación del repositorio.
¿Codama?
Alineación de decodificación del cliente.
¿Picos de alquiler?
Desde Vec sin límites.
¿Agave 4.1.1?
Reglas de alquiler a través del SDK.
¿Enfoque de auditoría?
Discriminador + LEN + migración.
Relacionado
- Conceptos básicos de serialización - Introducción
- Discriminadores de cuenta - Etiquetado
- Mejores prácticas de Rust para Solana - Rust general
Versiones de la pila: Esta página se escribió para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 y LiteSVM 0.6.x.