67 lines
3.4 KiB
Markdown
67 lines
3.4 KiB
Markdown
<!-- 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.
|