86 lines
6.7 KiB
Markdown
86 lines
6.7 KiB
Markdown
<!-- file: docs/NATIVE_SOLANA_MATERIALIZATION_AUDIT.md -->
|
||
<!-- version: 6 -->
|
||
|
||
# Audit des matérialisations Solana natives
|
||
|
||
## Conclusion
|
||
|
||
`0.4.1` clôt les matérialisations natives instructionnelles stables. Les projections actives couvrent les mutations ou profils qui peuvent être déduits de façon déterministe depuis le graphe core transactionnel et les événements décodés.
|
||
|
||
Les sorties ne sont pas des snapshots finaux de comptes ou de runtime. Les états finaux qui exigent l’état précédent/suivant d’un compte, les sysvars historiques ou des métriques runtime restent différés jusqu’à enrichissement explicite du contrat core.
|
||
|
||
## Projections actives par matérialiseur
|
||
|
||
| Matérialiseur | Surfaces | Projection |
|
||
|---------------------------------|----------------------|---------------------------------------------------------------------------------------------------------------------|
|
||
| `MtLifecycleMaterializer` | Address Lookup Table | lifecycle create/freeze/extend/deactivate/close |
|
||
| `MtLifecycleMaterializer` | Feature | révocation de feature gate |
|
||
| `MtLifecycleMaterializer` | Loaders | déploiement, finalisation et transitions lifecycle stables |
|
||
| `MtLifecycleMaterializer` | System | durable nonce, create account et allocate |
|
||
| `MtLifecycleMaterializer` | ZK ElGamal | création ou fermeture d’un compte de contexte |
|
||
| `MtLifecycleMaterializer` | Slashing | initialisation ou fermeture d’un rapport de violation |
|
||
| `MtAdminMaterializer` | System | assign et assign with seed |
|
||
| `MtAdminMaterializer` | Config | écriture opaque bornée avec clés, taille, SHA-256 et préfixe |
|
||
| `MtAdminMaterializer` | Loaders | changements d’autorité |
|
||
| `MtComplianceAuditMaterializer` | Loaders | écritures/copies de bytecode bornées par offsets, tailles, SHA-256 et préfixes |
|
||
| `MtComplianceAuditMaterializer` | Compute Budget | profil transactionnel agrégé, last-write-wins, une seule sortie par transaction |
|
||
| `MtStakingMaterializer` | Stake | compte, délégation, désactivation, split, merge, withdraw, move stake/lamports, autorités et lockup instructionnels |
|
||
| `MtStakingMaterializer` | Vote | compte, autorités, identité, commission, vote state, retraits et dépôt de rewards instructionnels |
|
||
|
||
## Politique des transactions échouées
|
||
|
||
Les transactions on-chain échouées restent décodables comme intentions ou diagnostics. Les matérialiseurs mutables utilisent la politique `SuccessfulCommittedOnly` et refusent les observations non commitées au lieu de produire une mutation réussie fictive.
|
||
|
||
Le profil Compute Budget est une sortie `ComplianceAudit`, pas une mutation d’état ; il peut donc être matérialisé même lorsque la transaction échoue. Il décrit le budget demandé par les instructions, pas les unités réellement consommées.
|
||
|
||
## Absences volontaires
|
||
|
||
Les surfaces suivantes ne produisent pas de projection dédiée dans `kb_sol_mat_events` à la clôture de `0.4.1` :
|
||
|
||
- Ed25519 ;
|
||
- secp256k1 ;
|
||
- secp256r1 ;
|
||
- preuves ZK sans compte de contexte ;
|
||
- ancien ZK Token Proof historique/no-op.
|
||
|
||
Leur décodage est déjà un événement d’audit borné. Une matérialisation supplémentaire serait une duplication sans consommateur métier dédié.
|
||
|
||
## États finaux différés
|
||
|
||
Les éléments suivants ne doivent pas être présentés comme disponibles dans `0.4.1` :
|
||
|
||
- état final exact d’un compte Stake ou Vote ;
|
||
- activation/désactivation Stake par epoch ;
|
||
- crédits Vote cumulés ;
|
||
- rewards recalculées par epoch ;
|
||
- état final d’un compte System après lamport drain conditionnel ;
|
||
- bytecode final complet d’un loader ;
|
||
- unités compute réellement consommées ;
|
||
- frais finaux réellement facturés ;
|
||
- résultat cryptographique recalculé pour signature ou preuve ZK.
|
||
|
||
Ces états exigent une extension du contexte core ou un audit de comptes/snapshots dédié.
|
||
|
||
## Validations finales `0.4.1`
|
||
|
||
Les validations utilisateur finales couvrent :
|
||
|
||
| Surface | Corpus / preuve | Résultat |
|
||
|----------------------|--------------------------------|----------------------------------------------------------------|
|
||
| System | replay ciblé | 817 inputs décodés, 258 sorties, 52 refus attendus |
|
||
| Config | replay ciblé | 96 inputs décodés, 96 sorties admin |
|
||
| Stake | replay ciblé | 448 inputs décodés, 447 sorties, 1 refus attendu |
|
||
| Vote | replay ciblé | 600 inputs décodés, 600 sorties |
|
||
| Compute Budget | replay ciblé | 2 746 inputs décodés, 1 603 profils |
|
||
| ZK ElGamal | replay ciblé | 151 inputs décodés, 139 sorties de contexte |
|
||
| Address Lookup Table | inventaire/replay ciblé | 104 inputs décodés, 104 sorties lifecycle |
|
||
| Slashing | sources officielles + fixtures | aucun corpus public observable, validation synthétique assumée |
|
||
|
||
Toutes les campagnes de clôture rapportées se terminent avec `unmatched = 0`, `failedInputs = 0`, `unsupported = 0` et des journaux `error.jsonl` vides.
|
||
|
||
## Décision de clôture
|
||
|
||
Aucune projection native instructionnelle stable n’est identifiée comme manquante dans le périmètre `0.4.1`.
|
||
|
||
La suite `0.4.2` peut se concentrer sur l’exécution : plans, simulation, signature, envoi et validation post-exécution, sans rouvrir le jalon de décodage/matérialisation natif.
|