Commit graph

6 commits

Author SHA1 Message Date
Guillaume Ballet
9a5140a590
self-review 2026-04-30 14:31:38 +02:00
Guillaume Ballet
40c29ad53a
core/overlay: load transition state from system contract
Replace the gob-encoded `rawdb.{Read,Write}VerkleTransitionState`
plumbing with a direct read from the binary transition registry system
contract at `params.BinaryTransitionRegistryAddress`. The registry
exposes the transition state via fixed storage slots; a tiny
`StorageReader` interface (`Storage(addr, slot) (Hash, error)`)
captures what the loader needs.

`LoadTransitionState` now takes a `StorageReader` instead of an
`ethdb.KeyValueReader` and returns `nil` when the registry has not been
initialised (slot 0 unset). `IsTransitionActive` is exposed for callers
that only need the started flag.

`core/state/reader.go:newUBTTrieReader` is updated:
  - It now takes the binary triedb, an optional MPT triedb, and a
    `wrapInTransitionTrie` flag so callers can opt out of the wrap.
  - It uses a small `binTrieStorageReader` adapter to query the
    registry directly from the binary trie at the requested root,
    avoiding the MPT key-hashing in `flatReader`.
  - When wrap=true and the registry's BaseRoot is non-zero, the MPT
    base is opened against the supplied MPT triedb. With the current
    callers (mptdb=nil) the wrap degenerates to a passthrough,
    preserving existing master semantics until the dual-triedb routing
    lands in the next commit.

The dead `rawdb` accessors and `VerkleTransitionStatePrefix` schema
constant are removed.
2026-04-29 16:21:59 +02:00
Guillaume Ballet
ba215fd927
cmd, core, trie, triedb: split CachingDB into merkle + binary dbs. (#34700)
This Pr implements some prerequisite changes for #34004 : split the
`CachingDB` into a `MerkleDB` and a `UBTDB`, so that very different
behaviors don't clash as much.

The transition isn't handled by this PR, but after talking to Gary we
agreed that `UBTDB` should receive another `triedb`, which will only be
loaded if the `Ended` flag is set to false in the conversion contract.
If this is too hard to achieve, it makes sense to load it regardless,
and then loading can be prevented at a later stage by adding a
`UBTTransitionFinalizationTime` in `ChainConfig`.

---------

Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2026-04-17 08:55:54 +08:00
Galoretka
e20b05ec7f
core/overlay: fix incorrect debug log key/value in LoadTransitionState (#32637)
Some checks are pending
/ Linux Build (arm) (push) Waiting to run
/ Keeper Build (push) Waiting to run
/ Linux Build (push) Waiting to run
/ Windows Build (push) Waiting to run
/ Docker Image (push) Waiting to run
2025-12-14 21:51:13 +01:00
Galoretka
ec99444804
core/overlay: copy BaseRoot in TransitionState.Copy (#32613)
This change ensures TransitionState.Copy preserves BaseRoot. During a
Verkle transition, ts.BaseRoot is required to construct the overlay MPT
when ts.InTransition() is true. Previously, copies dropped BaseRoot,
risking an invalid zero-hash base trie and inconsistent behavior.
2025-09-15 15:26:16 +08:00
Guillaume Ballet
cf50026466
core/state: introduce the TransitionState object (verkle transition part 1) (#31634)
Some checks are pending
/ Linux Build (push) Waiting to run
/ Linux Build (arm) (push) Waiting to run
/ Windows Build (push) Waiting to run
/ Docker Image (push) Waiting to run
This is the first part of #31532 

It maintains a series of conversion maker which are to be updated by the
conversion code (in a follow-up PR, this is a breakdown of a larger PR
to make things easier to review). They can be used in this way:

- During the conversion, by storing the conversion markers when the
block has been processed. This is meant to be written in a function that
isn't currently present, hence [this
TODO](https://github.com/ethereum/go-ethereum/pull/31634/files#diff-89272f61e115723833d498a0acbe59fa2286e3dc7276a676a7f7816f21e248b7R384).

Part of  https://github.com/ethereum/go-ethereum/issues/31583

---------

Signed-off-by: Guillaume Ballet <3272758+gballet@users.noreply.github.com>
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2025-08-05 09:34:12 +08:00