2016-10-04 12:36:02 +02:00
|
|
|
// Copyright 2016 The go-ethereum Authors
|
|
|
|
// This file is part of the go-ethereum library.
|
|
|
|
//
|
|
|
|
// The go-ethereum library is free software: you can redistribute it and/or modify
|
|
|
|
// it under the terms of the GNU Lesser General Public License as published by
|
|
|
|
// the Free Software Foundation, either version 3 of the License, or
|
|
|
|
// (at your option) any later version.
|
|
|
|
//
|
|
|
|
// The go-ethereum library is distributed in the hope that it will be useful,
|
|
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
// GNU Lesser General Public License for more details.
|
|
|
|
//
|
|
|
|
// You should have received a copy of the GNU Lesser General Public License
|
|
|
|
// along with the go-ethereum library. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
|
|
package state
|
|
|
|
|
|
|
|
import (
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
"fmt"
|
2024-04-24 11:59:06 +02:00
|
|
|
"maps"
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
"slices"
|
|
|
|
"sort"
|
2024-04-24 11:59:06 +02:00
|
|
|
|
2016-10-04 12:36:02 +02:00
|
|
|
"github.com/ethereum/go-ethereum/common"
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
"github.com/ethereum/go-ethereum/core/types"
|
2024-01-23 14:51:58 +01:00
|
|
|
"github.com/holiman/uint256"
|
2016-10-04 12:36:02 +02:00
|
|
|
)
|
|
|
|
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
type revision struct {
|
|
|
|
id int
|
|
|
|
journalIndex int
|
|
|
|
}
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
// journalEntry is a modification entry in the state change journal that can be
|
|
|
|
// reverted on demand.
|
2016-10-04 12:36:02 +02:00
|
|
|
type journalEntry interface {
|
2018-03-27 15:13:30 +03:00
|
|
|
// revert undoes the changes introduced by this journal entry.
|
|
|
|
revert(*StateDB)
|
|
|
|
|
|
|
|
// dirtied returns the Ethereum address modified by this journal entry.
|
|
|
|
dirtied() *common.Address
|
2024-04-24 11:59:06 +02:00
|
|
|
|
|
|
|
// copy returns a deep-copied journal entry.
|
|
|
|
copy() journalEntry
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
// journal contains the list of state modifications applied since the last state
|
2021-10-10 21:00:00 +08:00
|
|
|
// commit. These are tracked to be able to be reverted in the case of an execution
|
|
|
|
// exception or request for reversal.
|
2017-10-01 21:07:30 +02:00
|
|
|
type journal struct {
|
2018-03-27 15:13:30 +03:00
|
|
|
entries []journalEntry // Current changes tracked by the journal
|
|
|
|
dirties map[common.Address]int // Dirty accounts and the number of changes
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
|
|
|
|
validRevisions []revision
|
|
|
|
nextRevisionId int
|
2018-03-27 15:13:30 +03:00
|
|
|
}
|
|
|
|
|
2021-10-10 21:00:00 +08:00
|
|
|
// newJournal creates a new initialized journal.
|
2018-03-27 15:13:30 +03:00
|
|
|
func newJournal() *journal {
|
|
|
|
return &journal{
|
|
|
|
dirties: make(map[common.Address]int),
|
|
|
|
}
|
2017-10-01 21:07:30 +02:00
|
|
|
}
|
|
|
|
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
// reset clears the journal, after this operation the journal can be used anew.
|
|
|
|
// It is semantically similar to calling 'newJournal', but the underlying slices
|
|
|
|
// can be reused.
|
|
|
|
func (j *journal) reset() {
|
|
|
|
j.entries = j.entries[:0]
|
|
|
|
j.validRevisions = j.validRevisions[:0]
|
|
|
|
clear(j.dirties)
|
|
|
|
j.nextRevisionId = 0
|
|
|
|
}
|
|
|
|
|
|
|
|
// snapshot returns an identifier for the current revision of the state.
|
|
|
|
func (j *journal) snapshot() int {
|
|
|
|
id := j.nextRevisionId
|
|
|
|
j.nextRevisionId++
|
|
|
|
j.validRevisions = append(j.validRevisions, revision{id, j.length()})
|
|
|
|
return id
|
|
|
|
}
|
|
|
|
|
|
|
|
// revertToSnapshot reverts all state changes made since the given revision.
|
|
|
|
func (j *journal) revertToSnapshot(revid int, s *StateDB) {
|
|
|
|
// Find the snapshot in the stack of valid snapshots.
|
|
|
|
idx := sort.Search(len(j.validRevisions), func(i int) bool {
|
|
|
|
return j.validRevisions[i].id >= revid
|
|
|
|
})
|
|
|
|
if idx == len(j.validRevisions) || j.validRevisions[idx].id != revid {
|
|
|
|
panic(fmt.Errorf("revision id %v cannot be reverted", revid))
|
|
|
|
}
|
|
|
|
snapshot := j.validRevisions[idx].journalIndex
|
|
|
|
|
|
|
|
// Replay the journal to undo changes and remove invalidated snapshots
|
|
|
|
j.revert(s, snapshot)
|
|
|
|
j.validRevisions = j.validRevisions[:idx]
|
|
|
|
}
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
// append inserts a new modification entry to the end of the change journal.
|
2017-10-01 21:07:30 +02:00
|
|
|
func (j *journal) append(entry journalEntry) {
|
|
|
|
j.entries = append(j.entries, entry)
|
2018-03-27 15:13:30 +03:00
|
|
|
if addr := entry.dirtied(); addr != nil {
|
|
|
|
j.dirties[*addr]++
|
|
|
|
}
|
2017-10-01 21:07:30 +02:00
|
|
|
}
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
// revert undoes a batch of journalled modifications along with any reverted
|
|
|
|
// dirty handling too.
|
|
|
|
func (j *journal) revert(statedb *StateDB, snapshot int) {
|
|
|
|
for i := len(j.entries) - 1; i >= snapshot; i-- {
|
|
|
|
// Undo the changes made by the operation
|
|
|
|
j.entries[i].revert(statedb)
|
2017-10-01 21:07:30 +02:00
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
// Drop any dirty tracking induced by the change
|
|
|
|
if addr := j.entries[i].dirtied(); addr != nil {
|
|
|
|
if j.dirties[*addr]--; j.dirties[*addr] == 0 {
|
|
|
|
delete(j.dirties, *addr)
|
|
|
|
}
|
2017-10-01 21:07:30 +02:00
|
|
|
}
|
|
|
|
}
|
2018-03-27 15:13:30 +03:00
|
|
|
j.entries = j.entries[:snapshot]
|
2017-10-01 21:07:30 +02:00
|
|
|
}
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
// dirty explicitly sets an address to dirty, even if the change entries would
|
|
|
|
// otherwise suggest it as clean. This method is an ugly hack to handle the RIPEMD
|
|
|
|
// precompile consensus exception.
|
|
|
|
func (j *journal) dirty(addr common.Address) {
|
|
|
|
j.dirties[addr]++
|
2017-10-01 21:07:30 +02:00
|
|
|
}
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
// length returns the current number of entries in the journal.
|
|
|
|
func (j *journal) length() int {
|
|
|
|
return len(j.entries)
|
2017-10-01 21:07:30 +02:00
|
|
|
}
|
2016-10-04 12:36:02 +02:00
|
|
|
|
2024-04-24 11:59:06 +02:00
|
|
|
// copy returns a deep-copied journal.
|
|
|
|
func (j *journal) copy() *journal {
|
|
|
|
entries := make([]journalEntry, 0, j.length())
|
|
|
|
for i := 0; i < j.length(); i++ {
|
|
|
|
entries = append(entries, j.entries[i].copy())
|
|
|
|
}
|
|
|
|
return &journal{
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
entries: entries,
|
|
|
|
dirties: maps.Clone(j.dirties),
|
|
|
|
validRevisions: slices.Clone(j.validRevisions),
|
|
|
|
nextRevisionId: j.nextRevisionId,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func (j *journal) logChange(txHash common.Hash) {
|
|
|
|
j.append(addLogChange{txhash: txHash})
|
|
|
|
}
|
|
|
|
|
|
|
|
func (j *journal) createObject(addr common.Address) {
|
2024-09-06 15:42:59 +08:00
|
|
|
j.append(createObjectChange{account: addr})
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
func (j *journal) createContract(addr common.Address) {
|
|
|
|
j.append(createContractChange{account: addr})
|
|
|
|
}
|
|
|
|
|
|
|
|
func (j *journal) destruct(addr common.Address) {
|
2024-09-06 15:42:59 +08:00
|
|
|
j.append(selfDestructChange{account: addr})
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
func (j *journal) storageChange(addr common.Address, key, prev, origin common.Hash) {
|
|
|
|
j.append(storageChange{
|
2024-09-06 15:42:59 +08:00
|
|
|
account: addr,
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
key: key,
|
|
|
|
prevvalue: prev,
|
|
|
|
origvalue: origin,
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
func (j *journal) transientStateChange(addr common.Address, key, prev common.Hash) {
|
|
|
|
j.append(transientStorageChange{
|
2024-09-06 15:42:59 +08:00
|
|
|
account: addr,
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
key: key,
|
|
|
|
prevalue: prev,
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
func (j *journal) refundChange(previous uint64) {
|
|
|
|
j.append(refundChange{prev: previous})
|
|
|
|
}
|
|
|
|
|
|
|
|
func (j *journal) balanceChange(addr common.Address, previous *uint256.Int) {
|
|
|
|
j.append(balanceChange{
|
2024-09-06 15:42:59 +08:00
|
|
|
account: addr,
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
prev: previous.Clone(),
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
func (j *journal) setCode(address common.Address) {
|
2024-09-06 15:42:59 +08:00
|
|
|
j.append(codeChange{account: address})
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
func (j *journal) nonceChange(address common.Address, prev uint64) {
|
|
|
|
j.append(nonceChange{
|
2024-09-06 15:42:59 +08:00
|
|
|
account: address,
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
prev: prev,
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
func (j *journal) touchChange(address common.Address) {
|
|
|
|
j.append(touchChange{
|
2024-09-06 15:42:59 +08:00
|
|
|
account: address,
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
})
|
|
|
|
if address == ripemd {
|
|
|
|
// Explicitly put it in the dirty-cache, which is otherwise generated from
|
|
|
|
// flattened journals.
|
|
|
|
j.dirty(address)
|
2024-04-24 11:59:06 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
func (j *journal) accessListAddAccount(addr common.Address) {
|
2024-09-06 15:42:59 +08:00
|
|
|
j.append(accessListAddAccountChange{addr})
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
func (j *journal) accessListAddSlot(addr common.Address, slot common.Hash) {
|
|
|
|
j.append(accessListAddSlotChange{
|
2024-09-06 15:42:59 +08:00
|
|
|
address: addr,
|
|
|
|
slot: slot,
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2016-10-04 12:36:02 +02:00
|
|
|
type (
|
|
|
|
// Changes to the account trie.
|
|
|
|
createObjectChange struct {
|
2024-09-06 15:42:59 +08:00
|
|
|
account common.Address
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
2024-04-24 11:59:06 +02:00
|
|
|
// createContractChange represents an account becoming a contract-account.
|
|
|
|
// This event happens prior to executing initcode. The journal-event simply
|
|
|
|
// manages the created-flag, in order to allow same-tx destruction.
|
|
|
|
createContractChange struct {
|
|
|
|
account common.Address
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
2023-07-15 16:35:30 +02:00
|
|
|
selfDestructChange struct {
|
2024-09-06 15:42:59 +08:00
|
|
|
account common.Address
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// Changes to individual accounts.
|
|
|
|
balanceChange struct {
|
2024-09-06 15:42:59 +08:00
|
|
|
account common.Address
|
2024-01-23 14:51:58 +01:00
|
|
|
prev *uint256.Int
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
|
|
|
nonceChange struct {
|
2024-09-06 15:42:59 +08:00
|
|
|
account common.Address
|
2016-10-04 12:36:02 +02:00
|
|
|
prev uint64
|
|
|
|
}
|
|
|
|
storageChange struct {
|
2024-09-06 15:42:59 +08:00
|
|
|
account common.Address
|
2024-04-24 18:45:24 +03:00
|
|
|
key common.Hash
|
2024-05-10 15:57:38 +08:00
|
|
|
prevvalue common.Hash
|
|
|
|
origvalue common.Hash
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
|
|
|
codeChange struct {
|
2024-09-06 15:42:59 +08:00
|
|
|
account common.Address
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// Changes to other state values.
|
|
|
|
refundChange struct {
|
2017-11-13 13:47:27 +02:00
|
|
|
prev uint64
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
|
|
|
addLogChange struct {
|
|
|
|
txhash common.Hash
|
|
|
|
}
|
2016-11-24 16:24:04 +01:00
|
|
|
touchChange struct {
|
2024-09-06 15:42:59 +08:00
|
|
|
account common.Address
|
2016-11-24 16:24:04 +01:00
|
|
|
}
|
2024-04-24 11:59:06 +02:00
|
|
|
|
2020-10-23 08:26:57 +02:00
|
|
|
// Changes to the access list
|
|
|
|
accessListAddAccountChange struct {
|
2024-09-06 15:42:59 +08:00
|
|
|
address common.Address
|
2020-10-23 08:26:57 +02:00
|
|
|
}
|
|
|
|
accessListAddSlotChange struct {
|
2024-09-06 15:42:59 +08:00
|
|
|
address common.Address
|
|
|
|
slot common.Hash
|
2020-10-23 08:26:57 +02:00
|
|
|
}
|
2022-11-16 01:18:52 -08:00
|
|
|
|
2024-04-24 11:59:06 +02:00
|
|
|
// Changes to transient storage
|
2022-11-16 01:18:52 -08:00
|
|
|
transientStorageChange struct {
|
2024-09-06 15:42:59 +08:00
|
|
|
account common.Address
|
2022-11-16 01:18:52 -08:00
|
|
|
key, prevalue common.Hash
|
|
|
|
}
|
2016-10-04 12:36:02 +02:00
|
|
|
)
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
func (ch createObjectChange) revert(s *StateDB) {
|
2024-09-06 15:42:59 +08:00
|
|
|
delete(s.stateObjects, ch.account)
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
func (ch createObjectChange) dirtied() *common.Address {
|
2024-09-06 15:42:59 +08:00
|
|
|
return &ch.account
|
2017-10-01 21:07:30 +02:00
|
|
|
}
|
|
|
|
|
2024-04-24 11:59:06 +02:00
|
|
|
func (ch createObjectChange) copy() journalEntry {
|
|
|
|
return createObjectChange{
|
|
|
|
account: ch.account,
|
2023-06-05 21:25:57 +08:00
|
|
|
}
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
|
|
|
|
2024-04-24 11:59:06 +02:00
|
|
|
func (ch createContractChange) revert(s *StateDB) {
|
|
|
|
s.getStateObject(ch.account).newContract = false
|
|
|
|
}
|
|
|
|
|
|
|
|
func (ch createContractChange) dirtied() *common.Address {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (ch createContractChange) copy() journalEntry {
|
|
|
|
return createContractChange{
|
|
|
|
account: ch.account,
|
|
|
|
}
|
2017-10-01 21:07:30 +02:00
|
|
|
}
|
|
|
|
|
2023-07-15 16:35:30 +02:00
|
|
|
func (ch selfDestructChange) revert(s *StateDB) {
|
2024-09-06 15:42:59 +08:00
|
|
|
obj := s.getStateObject(ch.account)
|
2016-10-04 12:36:02 +02:00
|
|
|
if obj != nil {
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
obj.selfDestructed = false
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
|
|
|
}
|
2018-03-27 15:13:30 +03:00
|
|
|
|
2023-07-15 16:35:30 +02:00
|
|
|
func (ch selfDestructChange) dirtied() *common.Address {
|
2024-09-06 15:42:59 +08:00
|
|
|
return &ch.account
|
2017-10-01 21:07:30 +02:00
|
|
|
}
|
2016-10-04 12:36:02 +02:00
|
|
|
|
2024-04-24 11:59:06 +02:00
|
|
|
func (ch selfDestructChange) copy() journalEntry {
|
|
|
|
return selfDestructChange{
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
account: ch.account,
|
2024-04-24 11:59:06 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-24 16:24:04 +01:00
|
|
|
var ripemd = common.HexToAddress("0000000000000000000000000000000000000003")
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
func (ch touchChange) revert(s *StateDB) {
|
2017-10-01 21:07:30 +02:00
|
|
|
}
|
2018-03-27 15:13:30 +03:00
|
|
|
|
|
|
|
func (ch touchChange) dirtied() *common.Address {
|
2024-09-06 15:42:59 +08:00
|
|
|
return &ch.account
|
2016-11-24 16:24:04 +01:00
|
|
|
}
|
|
|
|
|
2024-04-24 11:59:06 +02:00
|
|
|
func (ch touchChange) copy() journalEntry {
|
|
|
|
return touchChange{
|
|
|
|
account: ch.account,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
func (ch balanceChange) revert(s *StateDB) {
|
2024-09-06 15:42:59 +08:00
|
|
|
s.getStateObject(ch.account).setBalance(ch.prev)
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
2018-03-27 15:13:30 +03:00
|
|
|
|
|
|
|
func (ch balanceChange) dirtied() *common.Address {
|
2024-09-06 15:42:59 +08:00
|
|
|
return &ch.account
|
2017-10-01 21:07:30 +02:00
|
|
|
}
|
2016-10-04 12:36:02 +02:00
|
|
|
|
2024-04-24 11:59:06 +02:00
|
|
|
func (ch balanceChange) copy() journalEntry {
|
|
|
|
return balanceChange{
|
|
|
|
account: ch.account,
|
|
|
|
prev: new(uint256.Int).Set(ch.prev),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
func (ch nonceChange) revert(s *StateDB) {
|
2024-09-06 15:42:59 +08:00
|
|
|
s.getStateObject(ch.account).setNonce(ch.prev)
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
func (ch nonceChange) dirtied() *common.Address {
|
2024-09-06 15:42:59 +08:00
|
|
|
return &ch.account
|
2017-10-01 21:07:30 +02:00
|
|
|
}
|
2018-03-27 15:13:30 +03:00
|
|
|
|
2024-04-24 11:59:06 +02:00
|
|
|
func (ch nonceChange) copy() journalEntry {
|
|
|
|
return nonceChange{
|
|
|
|
account: ch.account,
|
|
|
|
prev: ch.prev,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
func (ch codeChange) revert(s *StateDB) {
|
2024-09-06 15:42:59 +08:00
|
|
|
s.getStateObject(ch.account).setCode(types.EmptyCodeHash, nil)
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
2018-03-27 15:13:30 +03:00
|
|
|
|
|
|
|
func (ch codeChange) dirtied() *common.Address {
|
2024-09-06 15:42:59 +08:00
|
|
|
return &ch.account
|
2017-10-01 21:07:30 +02:00
|
|
|
}
|
2016-10-04 12:36:02 +02:00
|
|
|
|
2024-04-24 11:59:06 +02:00
|
|
|
func (ch codeChange) copy() journalEntry {
|
core/state: semantic journalling (part 1) (#28880)
This is a follow-up to #29520, and a preparatory PR to a more thorough
change in the journalling system.
### API methods instead of `append` operations
This PR hides the journal-implementation details away, so that the
statedb invokes methods like `JournalCreate`, instead of explicitly
appending journal-events in a list. This means that it's up to the
journal whether to implement it as a sequence of events or
aggregate/merge events.
### Snapshot-management inside the journal
This PR also makes it so that management of valid snapshots is moved
inside the journal, exposed via the methods `Snapshot() int` and
`RevertToSnapshot(revid int, s *StateDB)`.
### SetCode
JournalSetCode journals the setting of code: it is implicit that the
previous values were "no code" and emptyCodeHash. Therefore, we can
simplify the setCode journal.
### Selfdestruct
The self-destruct journalling is a bit strange: we allow the
selfdestruct operation to be journalled several times. This makes it so
that we also are forced to store whether the account was already
destructed.
What we can do instead, is to only journal the first destruction, and
after that only journal balance-changes, but not journal the
selfdestruct itself.
This simplifies the journalling, so that internals about state
management does not leak into the journal-API.
### Preimages
Preimages were, for some reason, integrated into the journal management,
despite not being a consensus-critical data structure. This PR undoes
that.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2024-08-28 08:18:23 +02:00
|
|
|
return codeChange{account: ch.account}
|
2024-04-24 11:59:06 +02:00
|
|
|
}
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
func (ch storageChange) revert(s *StateDB) {
|
2024-09-06 15:42:59 +08:00
|
|
|
s.getStateObject(ch.account).setState(ch.key, ch.prevvalue, ch.origvalue)
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
2018-03-27 15:13:30 +03:00
|
|
|
|
|
|
|
func (ch storageChange) dirtied() *common.Address {
|
2024-09-06 15:42:59 +08:00
|
|
|
return &ch.account
|
2017-10-01 21:07:30 +02:00
|
|
|
}
|
2016-10-04 12:36:02 +02:00
|
|
|
|
2024-04-24 11:59:06 +02:00
|
|
|
func (ch storageChange) copy() journalEntry {
|
|
|
|
return storageChange{
|
2024-04-24 18:45:24 +03:00
|
|
|
account: ch.account,
|
|
|
|
key: ch.key,
|
|
|
|
prevvalue: ch.prevvalue,
|
2024-04-24 11:59:06 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-11-16 01:18:52 -08:00
|
|
|
func (ch transientStorageChange) revert(s *StateDB) {
|
2024-09-06 15:42:59 +08:00
|
|
|
s.setTransientState(ch.account, ch.key, ch.prevalue)
|
2022-11-16 01:18:52 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
func (ch transientStorageChange) dirtied() *common.Address {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2024-04-24 11:59:06 +02:00
|
|
|
func (ch transientStorageChange) copy() journalEntry {
|
|
|
|
return transientStorageChange{
|
|
|
|
account: ch.account,
|
|
|
|
key: ch.key,
|
|
|
|
prevalue: ch.prevalue,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
func (ch refundChange) revert(s *StateDB) {
|
2016-10-04 12:36:02 +02:00
|
|
|
s.refund = ch.prev
|
|
|
|
}
|
2018-03-27 15:13:30 +03:00
|
|
|
|
|
|
|
func (ch refundChange) dirtied() *common.Address {
|
2017-10-01 21:07:30 +02:00
|
|
|
return nil
|
|
|
|
}
|
2016-10-04 12:36:02 +02:00
|
|
|
|
2024-04-24 11:59:06 +02:00
|
|
|
func (ch refundChange) copy() journalEntry {
|
|
|
|
return refundChange{
|
|
|
|
prev: ch.prev,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-27 15:13:30 +03:00
|
|
|
func (ch addLogChange) revert(s *StateDB) {
|
2016-10-04 12:36:02 +02:00
|
|
|
logs := s.logs[ch.txhash]
|
|
|
|
if len(logs) == 1 {
|
|
|
|
delete(s.logs, ch.txhash)
|
|
|
|
} else {
|
|
|
|
s.logs[ch.txhash] = logs[:len(logs)-1]
|
|
|
|
}
|
2017-09-21 20:44:46 +02:00
|
|
|
s.logSize--
|
2016-10-04 12:36:02 +02:00
|
|
|
}
|
2018-03-27 15:13:30 +03:00
|
|
|
|
|
|
|
func (ch addLogChange) dirtied() *common.Address {
|
2017-10-01 21:07:30 +02:00
|
|
|
return nil
|
|
|
|
}
|
2017-01-17 11:19:50 +00:00
|
|
|
|
2024-04-24 11:59:06 +02:00
|
|
|
func (ch addLogChange) copy() journalEntry {
|
|
|
|
return addLogChange{
|
|
|
|
txhash: ch.txhash,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-23 08:26:57 +02:00
|
|
|
func (ch accessListAddAccountChange) revert(s *StateDB) {
|
|
|
|
/*
|
|
|
|
One important invariant here, is that whenever a (addr, slot) is added, if the
|
|
|
|
addr is not already present, the add causes two journal entries:
|
|
|
|
- one for the address,
|
|
|
|
- one for the (address,slot)
|
|
|
|
Therefore, when unrolling the change, we can always blindly delete the
|
|
|
|
(addr) at this point, since no storage adds can remain when come upon
|
|
|
|
a single (addr) change.
|
|
|
|
*/
|
2024-09-06 15:42:59 +08:00
|
|
|
s.accessList.DeleteAddress(ch.address)
|
2020-10-23 08:26:57 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
func (ch accessListAddAccountChange) dirtied() *common.Address {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2024-04-24 11:59:06 +02:00
|
|
|
func (ch accessListAddAccountChange) copy() journalEntry {
|
|
|
|
return accessListAddAccountChange{
|
|
|
|
address: ch.address,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-23 08:26:57 +02:00
|
|
|
func (ch accessListAddSlotChange) revert(s *StateDB) {
|
2024-09-06 15:42:59 +08:00
|
|
|
s.accessList.DeleteSlot(ch.address, ch.slot)
|
2020-10-23 08:26:57 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
func (ch accessListAddSlotChange) dirtied() *common.Address {
|
|
|
|
return nil
|
|
|
|
}
|
2024-04-24 11:59:06 +02:00
|
|
|
|
|
|
|
func (ch accessListAddSlotChange) copy() journalEntry {
|
|
|
|
return accessListAddSlotChange{
|
|
|
|
address: ch.address,
|
|
|
|
slot: ch.slot,
|
|
|
|
}
|
|
|
|
}
|