0.1.0
This commit is contained in:
66
docs/V0_4_6_VALIDATION.md
Normal file
66
docs/V0_4_6_VALIDATION.md
Normal file
@@ -0,0 +1,66 @@
|
||||
<!-- file: docs/V0_4_6_VALIDATION.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Validation finale `0.4.6`
|
||||
|
||||
## Périmètre
|
||||
|
||||
Le jalon couvre Token-2022 et le registre ElGamal comme programmes distincts, ainsi que la régression des décodeurs Solana Core/SPL livrés auparavant. Il ne transforme pas Anchor, Metaplex ou les futurs DEX en surfaces implicitement couvertes.
|
||||
|
||||
## Résultats de tests
|
||||
|
||||
| Suite | Résultat |
|
||||
|------------------------------------|---------:|
|
||||
| `kb_store_core` | 41/41 |
|
||||
| `kb_store_pg` avec PostgreSQL réel | 46/46 |
|
||||
| `kb_pipeline` | 124/124 |
|
||||
| `kb_app_demo` | 118/118 |
|
||||
| `cargo clippy --all-targets` | propre |
|
||||
|
||||
Les contrôles SQL sur `kb_sol_decode_events` et `kb_sol_mat_events` ne révèlent aucun doublon d’identité.
|
||||
|
||||
## Token-2022 et ElGamal Registry
|
||||
|
||||
- 55 instructions Token-2022 Mainnet ont été décodées sans échec persistant.
|
||||
- Huit opérations publiques Token-2022 ont été confirmées sur Devnet : `MintToChecked`, `TransferChecked`, `ApproveChecked`, `Revoke`, `BurnChecked`, `FreezeAccount`, `ThawAccount` et `CloseAccount`.
|
||||
- Chaque parcours Devnet a été simulé, confirmé, hydraté, extrait, décodé, matérialisé puis rejoué idempotemment.
|
||||
- ElGamal Registry est validé synthétiquement/offline pour le wire, le PDA, l’état, les lectures RPC, les préflights et les preuves.
|
||||
- La validation publique ElGamal Registry reste indisponible sur Devnet/Mainnet au 20 juillet 2026 ; aucune preuve réseau n’est revendiquée.
|
||||
|
||||
## Loader immuable et Loader v4
|
||||
|
||||
Le parser `Write` du loader immuable lit désormais la longueur vectorielle en `u32` et les données à l’offset 12. Le replay Mainnet a supprimé 68 diagnostics `loader_vector_length_mismatch`.
|
||||
|
||||
Les rejets persistants restants sont tous issus de transactions Solana échouées :
|
||||
|
||||
| Diagnostic | Nombre |
|
||||
|----------------------------------|-------:|
|
||||
| `immutable_loader_tag_truncated` | 31 |
|
||||
| `loader_v4_tag_truncated` | 44 |
|
||||
| `loader_accounts_invalid` | 1 |
|
||||
|
||||
Quatre variantes Loader v4 inconnues sont persistées comme traitement réussi avec résultat métier `Unsupported`. Elles ne sont pas assimilées à des décodages complets.
|
||||
|
||||
## Replay des signatures incomplètes
|
||||
|
||||
Le mode `incomplete_signatures` sélectionne les signatures contenant au moins une instruction `pending`, `failed`, `replay_requested` ou `unsupported`. La limite est appliquée au nombre de signatures avant expansion vers les instructions compatibles. Ce mode ne nécessite pas de force replay global.
|
||||
|
||||
Deux campagnes PostgreSQL réelles successives ont produit exactement :
|
||||
|
||||
```text
|
||||
selected=81
|
||||
started=81
|
||||
completed=81
|
||||
unmatched=0
|
||||
notStarted=0
|
||||
failedInputs=76
|
||||
decoded=1
|
||||
unsupported=4
|
||||
failed=76
|
||||
```
|
||||
|
||||
L’instruction décodée appartient à une signature incomplète contenant également une instruction valide. La répétition identique du second passage confirme la sélection stable ; les événements et matérialisations restent idempotents.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Tous les décodeurs livrés jusqu’à `0.4.6` respectent leur contrat sur les tests synthétiques, les scénarios stateful et les données réseau observées. Les payloads malformés sont rejetés fail-closed et les variantes inconnues sont classées explicitement `Unsupported`. Cette conclusion ne prétend pas que chaque variante rare possible a été observée sur un cluster public.
|
||||
Reference in New Issue
Block a user