0xMiden / 0xMiden/protocol

Implement `PartialAccount::apply_patch`

Offen
#3,128 1 Kommentar 2 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
Rust
Sterne
132
Forks
167
Ø Merge
1 T. 23 Std.
Gemergte PRs (30 T.)
110

Beschreibung

`ExecutedTransaction` exposes `initial_account()` as a `PartialAccount`, but `final_account()` only returns an `AccountHeader`. That means AFAIK that there is currently no way to get the post-transaction account as a `PartialAccount`.

This matters for users that want to chain transactions against the same account. We use such pattern in the client’s batch builder. Today we woudl have to reconstruct the state transition ourselves: take the initial partial account’s storage header, apply the storage delta slot by slot, recompute changed map roots with a temporary `PartialSmt`, and then check the result against the final commitment. This is a bit hacky, and is a bunch of logic that could probably live next to `Account::apply_patch`.

The executed transaction already has the pieces needed to do this: the initial `PartialAccount`, the `AccountPatch` produced by the kernel epilogue via `account_patch()`, and the advice witnesses. The proposal is to add `PartialAccount::apply_patch(&mut self, &AccountPatch)`, mirroring `Account::apply_patch`. Additionally, perhaps, an `ExecutedTransaction::final_partial_account()` helper that clones the initial account and applies the patch could exist. AFAICT, applying a transaction’s own patch back to its initial partial account should be infallible, because the transaction can only modify keys whose merkle paths were available during execution.

This is not critical and there might be some things that do not allow this, so feel free to disregard if it doesn't make sense.

Beitragsleitfaden

Beitragsleitfaden öffnen

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.