0xMiden / 0xMiden/protocol

Implement `PartialAccount::apply_patch`

Open
#3,128 1 comment 2 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
132
Forks
167
Avg merge
1d 23h
Merged PRs (30d)
110

Description

`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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.