0xMiden / 0xMiden/node

store: `apply_block` code does not correctly handle `StorageMapPatch::Remove` and `StorageMapPatch::Create` semantics

未关闭
#2,328 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
store
主要语言
Rust
星标
104
派生
138
平均合并
1 天 13 小时
30 天内合并 PR
56

描述

After the recent upgrade to `miden-protocol` `next` there were some semantic changes introduced with `AccountPatch`: explicit create and remove operations were added for storage slots and storage maps.

`StorageValuePatch::Remove` and `StorageMapPatch::Remove` now needs to be handled explicitly in our storage code. In particular, `StorageMapPatch::Remove` is _not_ handled correctly right now.

The account state forest code skips removes (because `StorageMapPatch::entries` returns `None` for `Remove`: https://github.com/0xMiden/node/blob/914ff72faf7a8c7a4798bfc352e6e6a4167397c0/crates/store/src/account_state_forest/mod.rs#L743).

The code applying account state changes to SQLite also seems to just skip `Remove`: https://github.com/0xMiden/node/blob/914ff72faf7a8c7a4798bfc352e6e6a4167397c0/crates/store/src/db/models/queries/accounts.rs#L1146

Similarly, `StorageMapPatch::merge()` can merge a `Remove, Create` operation pair into a single `StorageMapPatch::Create` operation, so it's entirely possible that we're getting a `StorageMapPatch::Create` patch for an _existing_ storage map. In that case all current entries should be removed first and then the new entries added.

Note that we don't have a good way of representing map value removals in SQLite. The current schema for storage maps is this:

```sql
CREATE TABLE account_storage_map_values (
account_id BLOB NOT NULL,
block_num BIGINT NOT NULL,
slot_name TEXT NOT NULL,
key BLOB NOT NULL,
value BLOB NOT NULL,
is_latest BOOLEAN NOT NULL,

PRIMARY KEY (account_id, block_num, slot_name, key),
FOREIGN KEY (account_id, block_num) REFERENCES accounts(account_id, block_num) ON DELETE CASCADE
) WITHOUT ROWID;
```

贡献指南

打开贡献指南

评估

这个 Issue 还没有评估数据。

把新 issue 发到你的邮箱

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