draft ADR-003 Contract Storage Backends

[yihuang]

Closes: #XXX

Description

---

For contributor use:

• [ ] Targeted PR against correct branch (see CONTRIBUTING.md)
• [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• [ ] Code follows the module structure standards.
• [ ] Wrote unit and integration tests
• [ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• [ ] Added relevant godoc comments.
• [ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• [ ] Re-reviewed Files changed in the Github PR explorer

---

For admin use:

• [ ] Added appropriate labels to PR (ex. WIP, R4R, docs, etc)
• [ ] Reviewers assigned
• [ ] Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

[itsdevbear]

@yihuang bullish.

Have you taken a look at Erigon's storage structure? https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/db_walkthrough.MD

[yihuang]

@yihuang bullish.

Have you taken a look at Erigon's storage structure? https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/db_walkthrough.MD

that looks like a more fundamental DB design for blocks/receipts, in our case, those are handled by tendermint and tx indexers.

[yihuang]

@yihuang bullish.

Have you taken a look at Erigon's storage structure? https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/db_walkthrough.MD

after reading a bit more, they store the state without using merkle trie, but in a direct way, and implements the versioning by storing the changesets, and calculate the ethereum compatible root hashes on the fly.

[yihuang]

I think the erigon design makes a lot of sense, we can try to apply that to contract storage first.

Another thing is the contract code, it should be easy to move the code hash -> code pairs out from the iavl tree. Since it's immutable and insert only, there's no extra logic needed for checksum and versioning.

[itsdevbear]

@yihuang yup, agreed. Also should enable a way to tie the statedb in nicer on the cosmos side. Which would make handling precompile reverts 100000x easier. This is a big annoyance for our use case, We ended up with a of duplicate code in our repo because of having to effectively rewrite a lot of our sdk native logic to support the Commit() Revert() statedb structure.

[yihuang]

Also should enable a way to tie the statedb in nicer on the cosmos side. Which would make handling precompile reverts 100000x easier.

Interesting, can you elaborate on that?

[yihuang]

converted to draft for now, I think we can apply the erigon's idea to cosmos-sdk in general, which will benifits ethermint automatically.

[itsdevbear]

https://medium.com/@vorot93/meet-akula-the-fastest-ethereum-implementation-ever-built-58eaca244c39

@yihuang akula even faster apparently

[yihuang]

https://medium.com/@vorot93/meet-akula-the-fastest-ethereum-implementation-ever-built-58eaca244c39

@yihuang akula even faster apparently

It's said to be based on erigon's architecture, so I assume it use the same db design?

[itsdevbear]

Was thinking more execution. More relevant for the modular evm PR.

Do we think it’s worth adding this to ethermint as it stands now? Getting erigon like structure into the SDK going to be a process, may be a worthy POC.

On Wed, Sep 7, 2022 at 8:00 PM yihuang @.***> wrote:

@.***/meet-akula-the-fastest-ethereum-implementation-ever-built-58eaca244c39

@yihuang https://github.com/yihuang akula even faster apparently

It's said to be based on erigon's architecture, so I assume it use the same db design?

— Reply to this email directly, view it on GitHub https://github.com/evmos/ethermint/pull/1304#issuecomment-1240033164, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWKZSHUT4FDI2PRKLFZGK4LV5EUAJANCNFSM57WIT5UQ . You are receiving this because you commented.Message ID: @.***>

[yihuang]

After a second thought, the erigon design is pretty similar to sdk v2store, I added v2store to the benchmark, the result is like this: (1000blocks, 100writes per contract per block)

	Number of kv pairs	Total size of kv pairs
Plain	104249	7505928
IAVL	3887253	446065613
MPT	358814	42567780
V2store	672313	55278639

V2store seems not bad in terms of db size, although the benchmark haven't counted in the cost of snapshot versioning.

[itsdevbear]

@yihuang yeah SMT would help a ton, do you have an ethermint branch with it running?

[itsdevbear]

well well well https://github.com/evmos/ethermint/issues/94

[yihuang]

@yihuang yeah SMT would help a ton, do you have an ethermint branch with it running?

v2store use a SMT inside, haven't tried yet, not sure if we can use that to store contract storage as separate tries.

[itsdevbear]

I think there is definitely benefit in storing eth in separate tries.

I also had this idea around having a hot cache of frequently accessed contracts. Would be easy to implement if contract storage was in a separate tree.

A simple in memory write-through cache could be really powerful.

Or even more crazy, use a write-back cache, and clear the dirty bits in EndBlock().

[yihuang]

I think there is definitely benefit in storing eth in separate tries.

I also had this idea around having a hot cache of frequently accessed contracts. Would be easy to implement if contract storage was in a separate tree.

A simple in memory write-through cache could be really powerful.

Or even more crazy, use a write-back cache, and clear the dirty bits in EndBlock().

Sounds like the inter-block caching implemented in cosmos-sdk.

[yihuang]

@yihuang yeah SMT would help a ton, do you have an ethermint branch with it running?

or frogleap to verkle tree.

[itsdevbear]

@yihuang Verkle is a bit beyond my knowledge, but if you think its implementable then definitely interested on helping.

https://vitalik.ca/general/2021/06/18/verkle.html

[yihuang]

@yihuang Verkle is a bit beyond my knowledge, but if you think its implementable then definitely interested on helping.

https://vitalik.ca/general/2021/06/18/verkle.html

For us, we'll try this non-consensus-breaking approach first to reduce the disk footprint of the archive node. For a consensus-breaking change, it takes a big storage migration to rollout on production, may not be practical at all, unless dropping the chain history.

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days-before-close if no further activity occurs.