v0.4.8-pre.012
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/audits/V0_4_8_PRE_011_TOKEN_2022_METADATA_COMPLETENESS_AUDIT.md -->
|
||||
<!-- version: 7 -->
|
||||
<!-- version: 8 -->
|
||||
|
||||
# Audit `0.4.8-pre.011` — complétude Token-2022 Token Metadata
|
||||
|
||||
@@ -55,8 +55,10 @@ cargo test --workspace 1 285 tests, 0 échec, doc-test
|
||||
|
||||
Le `cargo clean` préalable a supprimé les artefacts obsolètes qui empêchaient Cargo de reconstruire le fichier `executor.rs` extrait depuis l’archive. La recompilation complète a ensuite exécuté le test direct `token_metadata_operations_share_matrix_family` et le test général de parité de matrice avec succès.
|
||||
|
||||
`fix-005` ne modifie aucun code de production et ajoute deux tests unitaires. La première reprise locale a confirmé que tout le workspace compilait, passait Clippy et les audits, mais ces deux nouveaux tests échouaient uniquement parce qu’ils attendaient les noms courts `update_token_metadata_authority` et `emit_token_metadata` au lieu des codes canoniques `spl.token_2022.update_token_metadata_authority` et `spl.token_2022.emit_token_metadata`. `fix-006` corrige ces deux assertions sans modifier le comportement de production. Le nombre attendu de tests unitaires `kb-lib` reste 695.
|
||||
`fix-005` ne modifie aucun code de production et ajoute deux tests unitaires. La première reprise locale a confirmé que tout le workspace compilait, passait Clippy et les audits, mais ces deux nouveaux tests échouaient uniquement parce qu’ils attendaient les noms courts `update_token_metadata_authority` et `emit_token_metadata` au lieu des codes canoniques `spl.token_2022.update_token_metadata_authority` et `spl.token_2022.emit_token_metadata`. `fix-006` corrige ces deux assertions sans modifier le comportement de production.
|
||||
|
||||
La reprise finale de `fix-006` a ensuite réussi `cargo check --workspace`, `cargo clippy --all-targets`, `python3 scripts/audit_rust_workspace_rules.py` et `cargo test --workspace`. La suite unitaire `kb-lib` compte **695 tests réussis, 0 échec**. `pre.011` est donc clôturée sans réserve fonctionnelle.
|
||||
|
||||
## Frontières maintenues
|
||||
|
||||
Les fixtures, soumissions Devnet, confirmations et preuves réseau restent dans `pre.012`. Le sous-panneau desktop Token-2022 reste dans `pre.013`. Aucune résolution off-chain n’est ajoutée par cette phase.
|
||||
Les fixtures, soumissions Devnet, confirmations et preuves réseau Token-2022 restent dans `pre.012`. Le réaudit Metaplex et ses compléments Devnet sont insérés en `pre.013`, ce qui décale la finalisation desktop metadata en `pre.014`. Aucune résolution off-chain n’est ajoutée par cette phase.
|
||||
|
||||
@@ -0,0 +1,72 @@
|
||||
<!-- file: docs/audits/V0_4_8_PRE_012_TOKEN_2022_METADATA_DEVNET_CAMPAIGN_AUDIT.md -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Audit `0.4.8-pre.012` — campagne Devnet Token-2022 Token Metadata
|
||||
|
||||
## Statut
|
||||
|
||||
**Terminée et validée sur Devnet.**
|
||||
|
||||
Le delta initial omettait la dépendance directe `bs58` dans `kb-pipeline-demo-scenarios/Cargo.toml`, alors que deux modules de la crate l'utilisent directement. `pre.012-delta-fix-001` déclare `bs58.workspace = true` et enregistre les preuves de la campagne réelle exécutée le 7 août 2026.
|
||||
|
||||
`pre.011` avait fermé la complétude fonctionnelle des cinq instructions de `spl-token-metadata-interface`. `pre.012` confirme désormais leur orchestration réseau de bout en bout sur Token-2022 Devnet.
|
||||
|
||||
## Contrat couvert
|
||||
|
||||
La campagne couvre exactement, dans cet ordre :
|
||||
|
||||
1. `Initialize` ;
|
||||
2. `UpdateField` ;
|
||||
3. `Emit` ;
|
||||
4. `RemoveKey` ;
|
||||
5. `UpdateAuthority`.
|
||||
|
||||
La fixture crée un mint Token-2022 frais, initialise `MetadataPointer` avant `InitializeMint2`, pointe le metadata pointer sur le mint lui-même et préfinance le compte pour les réallocations TLV atteintes par la campagne.
|
||||
|
||||
## Fixture Devnet observée
|
||||
|
||||
```text
|
||||
mint=EHrx1evxgXLEgjb1sgc5dVTktXX1LiovXR9YFsZS3d4k
|
||||
preparation_signature=2yYciRNoTTNSGuuaBFE6925FPjSj4fXp8usSkpLhgEPuhQMJYdsEzkAzxBdjDhpPHCT3db9bLz9Ud4BU5QSQZzQ5
|
||||
initial_authority=J12WA6c42oqpWkLu1dFa4pCegkQJPpxabwc3RRCMSUuH
|
||||
final_authority=3RVXUmVvY7quUUEVsDKh5EcenVygwv3mo1iagPa4Pmq7
|
||||
```
|
||||
|
||||
La préparation stateful impose que `metadata_pointer` soit présent, auto-référent et détenu par l'autorité attendue, tandis que `token_metadata` doit être absent avant `Initialize`.
|
||||
|
||||
## Résultats réseau
|
||||
|
||||
| Étape | Signature | Slot | Postcondition | Matérialisations | `returnData` |
|
||||
|--------------------------------|--------------------------------------------------------------------------------------------|----------:|---------------|-----------------------------------------:|-------------:|
|
||||
| `InitializeTokenMetadata` | `48kzJR5VW1ZYSRkVrg6qyNmuHdAUu7NXcnzaNsSmH7SSmRXK1X6RQdCeeSQi6LhrrkgRFRGVnxkwXPtkiqG6EgnY` | 481804441 | `Confirmed` | 1 | 0 |
|
||||
| `UpdateTokenMetadataField` | `JrdB9EqePS1FVWLo55w1Vhv2eTCTfCpXZgMvPCocW3m3iu4nk3BFBBRHoe2Nbcpq1rmnZoFrhnag5fG2WwmJrYs` | 481804454 | `Confirmed` | 1 | 0 |
|
||||
| `EmitTokenMetadata` | `3TKdBCJhM1VEZ9ti6EYR9gSLJnH5ni6FjW4kvoqwdYK1u14jdY6hS8hf2VGeLi21PbX5CWiyzjthJZERK5KHroWH` | 481804464 | `Confirmed` | 1 observée, non requise par la politique | 202 |
|
||||
| `RemoveTokenMetadataKey` | `3kDBV7pDFgoCQVJ9DYYuxvHFbCJzyA6J2rLg6ndGCETEhhFBZ1ipRQ52X2hZfwNPfdJwEFFBmbyMU6kFGnVXJNrm` | 481804473 | `Confirmed` | 1 | 0 |
|
||||
| `UpdateTokenMetadataAuthority` | `5aBpQsm6mAHA5xSN5tZ1ubALbfghGa7JScjXn9NGhg9agzEdjXydH6jgmn6UmxinGHmMvtqaGRLk9dgjmmz4HpU2` | 481804482 | `Confirmed` | 1 | 0 |
|
||||
|
||||
Le runner n'accepte une étape qu'après simulation réussie, confirmation, hydratation canonique, extraction Core, replay Token-2022, seconde passe d'idempotence propre et postcondition stateful confirmée. Les mutations exigent en plus une matérialisation instructionnelle. `Emit` n'en exige pas ; sa preuve spécialisée est le `returnData`, décodé ici sur 202 octets et comparé au snapshot TLV autoritatif.
|
||||
|
||||
## Matrice
|
||||
|
||||
`test-fixtures/contract-matrices/SPL_TOKEN_2022_METADATA_DEVNET_VALIDATION_MATRIX.json` conserve exactement les cinq scénarios de la campagne. `pre.012-delta-fix-001` les promeut tous à `confirmed` et enregistre pour chacun toutes les catégories de preuve requises.
|
||||
|
||||
Le test de matrice est mis à jour pour exiger cet état confirmé et vérifier que chaque catégorie requise possède une preuve observée.
|
||||
|
||||
## Validation locale
|
||||
|
||||
Les contrôles opérateur réussissent :
|
||||
|
||||
```text
|
||||
cargo fmt --all réussi
|
||||
cargo check --workspace réussi
|
||||
cargo clippy --all-targets réussi
|
||||
python3 scripts/audit_rust_workspace_rules.py clean
|
||||
cargo test -p kb-pipeline-demo-scenarios 69 + 1 + 1 tests réussis
|
||||
cargo test --workspace réussi
|
||||
```
|
||||
|
||||
Le workspace complet de `pre.012` termine ses 34 suites de tests avec 1 294 tests réussis au total et aucun échec.
|
||||
|
||||
## Conclusion
|
||||
|
||||
`0.4.8-pre.012` est clôturée : les cinq instructions Token-2022 Token Metadata prévues sont confirmées sur Devnet avec preuves de simulation, transaction, replay et postcondition. La phase suivante est `0.4.8-pre.013`, consacrée au réaudit et à la complétude Metaplex Token Metadata et de ses campagnes Devnet.
|
||||
Reference in New Issue
Block a user