0xMiden / 0xMiden/protocol

Implement `PartialAccount::apply_patch`

未关闭
#3,128 1 条评论 2 个 reaction 已指派 0 人 在 GitHub 查看
主要语言
Rust
星标
132
派生
167
平均合并
1 天 23 小时
30 天内合并 PR
110

描述

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

贡献指南

打开贡献指南

评估

这个 Issue 还没有评估数据。

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。