core/state: remove account reset operation #28666

rjl493456442 · 2023-12-11T05:41:38Z

This pull request gets rid of the Account Reset operation in statedb, serving as a pre-requisite steps for further statedb simplification.

Originally account reset is used to handle the scenario that an account was pre-funded and then be deployed with a contract code. In which the original account with pre-funded balance is be "reset" and the remaining balance would be transferred to the new account with the same address

However, in order to handle this specific scenario, account reset is not necessary. We can just add the contract code to this account instead, e.g.

// Create a new account on the state only if the object was not present.
// It might be possible the contract code is deployed to a pre-existent
// account with non-zero balance and potential non-empty storage.
if !evm.StateDB.Exist(address) {
	evm.StateDB.CreateAccount(address)
}

It's a really sensitive change involves in EVM spec definition, let's firstly figure out what kind of account is deployable.

According to this ticket ethereum/EIPs#684, If a contract creation is attempted, due to either a creation transaction or the CREATE (or future CREATE2) opcode, and the destination address already has either nonzero nonce, or nonempty code, then the creation throws immediately.

An address is regarded as deployable if nonce is 0 and contract code is empty. Specifically account.nonce == 0 && (account.CodeHash == empty || account.CodeHash == keccak256(nil)).

Then we can list all the potential possibilities for contract deployment:

(a) nonce = 0 && code == empty && balance == 0 && storage == empty
(b) nonce = 0 && code == empty && balance != 0 && storage == empty
(c) nonce = 0 && code == empty && balance == 0 && storage == non-empty
(d) nonce = 0 && code == empty && balance != 0 && storage == non-empty

Apparently (a) and (b) are valid, and we will discuss why (c) and (d) are impossible.

In order to prove (c) and (d) are impossible to occur unless hash collision, we have to make sure that storage can only be created through contract as the first step, namely the storage of an account must be created by the account(contract) itself either in contract construction stage or after the deployment. It is impossible to set storage directly without running the contract, or to set up the storage through other contracts.

Therefore we can say if the storage is already present, then a contract creation may have happened either via (1) tx creation (2) create opcode (3) create2 opcode.

Before EIP158, the nonce of created contracts is still left as 0 and it's set to 1 after EIP158 fork. Therefore the first conclusion we have is: For all accounts/contracts created after EIP158 forks, they are no longer deployable unless they are destructed first

What about the accounts created before EIP158?

Their nonce are zero and the stored contract code can be nil if the runtime code is empty. It's totally possible to have this kind account nonce = 0 && code == empty && storage == non-empty in the state. (Actually there are 28 accounts in mainnet in this case).

So is it possible to deploy something to these account? These accounts are all created via tx creation or create opcode as there is no create2 at that time. It's impossible to compute a same address with rules unless hash collision.

Keccak256(rlp{sender, nonce})[12:]
Keccak256([]byte{0xff}, sender, salt, inithash)[12:]

Therefore the second conclusion we have is The existent deployable accounts with storage are not possible to be redeployed unless hash collision.

In a summary we can prove (c) and (d) are impossible to occur.

Finally with this change, the only scenario we need to handle is pre-funded accounts deployment and it's apparently handled!

This branch can do full sync on mainnet from Genesis!

rjl493456442 · 2023-12-12T13:03:59Z

Benchmark 05 is running a full sync since genesis using this branch.

rjl493456442 · 2023-12-12T13:42:54Z

Looks like the state tests are failing, need to investigate it.

rjl493456442 · 2023-12-13T07:25:53Z

The failure of state tests reflects a behavior difference between master code and this branch.

EVM supports the contract code deployment to an existent account, if the account has 0 nonce and empty contract code.

The existent account can be divided into two categories:

Empty account
Non-Empty account

The definition of empty account is: : zero nonce, empty contract code, zero balance. It's possible to create this kind of accounts before the EIP158, but no longer possible after it.

The semantic of code deployment to existent account is a bit unclear to me, we can interpret it with different definitions:

Add the contract code into this account and account ownership is not changed
Reset the original account and take over the leftover balance, the ownership is actually changed

For the latter one, the leftover storage slots will be dropped while for the former one the leftover storage slots are kept. It's the actual behavior difference.

Personally, I am inclined to the first option, which is to simply add the contract code. However, my gut feeling is that we have been using the latter option for a very long time, and it is impossible or unreasonable to change the behavior now.

rjl493456442 · 2023-12-13T07:30:25Z

A few analysis can be done:

Do we still have this kind of account which is deployable(nonce=0, contract code=nil) but has storage slots
Do we ever performed the account reset operation in the history

After iterating the latest ethereum mainnet state, I did find a few deployable accounts with non-empty storage

INFO [12-15|07:05:16.841] Iterated snapshot                        empty=0 deployable=10,007,694 deployableWithStorage=28 deployableNoStorage=10,007,666 total=228,147,643
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0x1dff70804724888a5e9a0de818749dd6373791aee04456d72d4ee4d93f7a71d5
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0x218760c66229e10e0bea1e9bef60e4115dad0faa3d9a691e8cfdbf2d68c209b3
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0x31a296e561fab0e2015d5b3c6a5fbda80aac6b592d53b1a5f18aa04245b8905b
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0x36f6474a868c28ee7e5004c850d5d314d71bc9a75f09ab5b0ba8dd1baf83e6c9
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0x4f9f760c31c1755c35dce3c5179faf8cc35c8475e52f1b0602feac1dbc40e949
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0x53f0a0b2859577d08591610c6357a8f7a82bad16cb5202765549d49ddf5fc764
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0x5aaf22523893f1d99777623eb2c63560886a1e5d72996923e1ec46d6d2c4533b
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0x7308c3657a7ccd251156932555886cf053e8e52cb0de3cbc41af9b0019798322
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0x7363a1671d6421f3b616b775a0d82b0b70b45268983b8db11a23a832551a620d
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0x815ae5b92339f5ed8d406d675506ba9a4070ac8b24ed5f69100272605087dc60
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0x81b0a5736749eacb6509524aa486df4b53d5fa501b513b95806dc11141473d1e
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0x8af74328d36f32a534740059be7051abe1948d33c0b208b03583c38f25512ccf
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0x8d2ef6f7a340057d9f6fb0e5813d3bff50ffafde490b9d7bb82d1e5eb8024f4a
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0x9986b0a70f08aa5cbc4bc70e3822b9d4ef695aa5b8de1bf6f8e460b6bb6619a8
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0x9e15ccf0d883c51647ddba40d3fe73038178b1936a051f8b1094b856f42abc26
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0xb5b83a4b0dd90b055373acc8f03c50d25045884a987d4e609dd50f84f67d6e41
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0xc41053a916bbdf244192b70d21e5e8071739a50fc60dcfcc6182845b11c35e0c
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0xc5de306d6d88f0d05236fb72a2006d0a67347f27f3dc02e3c4f6e32749ed4aa9
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0xccd427e00afeb88073fd5d0e2c09d3712e9aa062c5fb5064246501013b4969f6
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0xd06b739a020e94e92eb999c95b6272db76123614c51bb10f7a5686e50e113da8
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0xdd78291274eaeab8063c372c27977a30a574f0520e855256b47ed63b4a899a8b
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0xddfe28d4e8db33f3625f84dd35f6d127ba1a6abdfb81f3a8e281a35a51122ccf
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0xe9b4816583d76b9f2ad537a51e3937f6584ebcdeaa4f9671bd7dc4c79a5481e9
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0xea4b74334854ef7aa1ad923d351b9d922962e5d37ae512e343edb2c1f997330a
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0xf1900391463d36b389496f950a204cb1a1eee9c9ad8a6b90a30b5ca4c24f171e
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0xf814577a93192b0c9457487f0f97f5fa2e491ec33d75bd1d9303faa9fb4f21f9
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0xfb2caa5c37e09a082207b77e7b73428ff1cc9606958457ae7959f59fb7cb5ebe
INFO [12-15|07:05:16.841] Deployable account but with storage      hash=0xfe917c6dec683e671555bb3d5891233b6601be6e7d17b0ccbe563c493d4d73ee

rjl493456442 · 2023-12-15T08:30:41Z

For these redeployable contracts with storages. They must be created before the EIP158 with 0 nonce. So they are created via a normal creation transaction or CREATE opcode.

It's only possible to redeploy these accounts if hash collision happens:

For create, hash(address + nonce) derives the same address
For create2, hash(0xff, address, salt, inithash) derives the same address

Either of them happens is a huge disaster for the entire network.

So the conclusion is: there are some redeployable accounts with storage slots and can theoretically trigger the behavior difference by making deployment, but it's impossible in practice unless hash collision.

petertdavies · 2024-01-15T11:34:22Z

Gary's analysis seems correct to, but has missed a subtle point, which makes this complicated. The KECCAK collision required is only 160 bits, not the full 256 bits. 160 bit collisions are acheivable and cost around ~$10 billion. Someone could have set a trap that this PR is walking into. I think the most likely scenario is:

Someone decided in 2015 that they wanted to create a consensus fault on Ethereum and identified this edgecase as a exploit target.
They spent a very large amount of money (at least $10 billion) and at least a year running a secret operation to mine a CREATE/CREATE collision.
They deployed the first CREATE prior to Spurious Dragon on 22nd November 2016.
For the last 8 years they have been in stealth mode waiting for a major client to accept a PR like this.
After Gary's PR is accepted, they will deploy the second CREATE and Geth will fall out of consensus with the rest of the network.

All of this is ludicrously unlikely, but is it unlikely enough that we can declare it impossible. I think the 2016 deadline for step 3 means this can be ruled impossible, but we need to agree on this.

Assuming it is the decided that this is an impossible situation, the following state tests need to be deleted, before this PR is merged:

stRevertTest/RevertInCreateInInit.json
stCreate2/RevertInCreateInInitCreate2.json
stSStoreTest/InitCollision.json

These cases are already controversial, py-evm refuses to implement the account reset and EELS has special case code just to handle this.

rjl493456442 · 2024-01-15T13:01:33Z

@petertdavies thanks for pointing out that the KECCAK collision is 160bits. I totally missed that. You are right it's technically possible to trigger it.

However, my point is: The behavioral definition of redeployment to existent account is very vague. Even the KECCAK collision happens, the correct behavior should be adding the new deployed code into this account, instead of resetting the whole thing. Namely the storage of the account shouldn't be wiped if it's not empty.

In order to achieve this, it's becoming a complicated thing that we need to make sure all the client implementations have the same behavior for handling it.

EDIT: after reading the conversation in py-evm's ticket, I believe the behavior for this case really need to be defined clearly. I will advocating for not having account reset at all.

rjl493456442 · 2024-01-15T13:04:16Z

And for KECCAK collision, the result of the collision is that the attacker inherits the balance of the specified account. But compared to the cost of 10b, this benefit should be completely insufficient.

We can say, it's technically possible, but the economy incentive is insufficient.

winsvega · 2024-01-15T14:50:38Z

if it is technically possible, consider the L2s that have tottaly different states. why not to cover all mathmatic solutions of this account reset/collision function?

rjl493456442 · 2024-01-16T07:38:57Z

if it is technically possible, consider the L2s that have tottaly different states. why not to cover all mathmatic solutions of this account reset/collision function?

My point is: it's technically possible to trigger, but we need to align the behavior about it between different clients.

Re the behavior definition: I would vote to just add the new contract code to the existent account, instead of resetting the whole account.

holiman · 2024-01-16T08:22:58Z

I am all aboard for merging this.

holiman

LGTM, but we should have a call about it, with @karalabe too

holiman · 2024-01-16T10:59:37Z

core/state/statedb.go

@@ -47,6 +47,15 @@ type revision struct {
 	journalIndex int
 }

+type objectState struct {


heh, the naming... we're in statedb, and we're dealing with stateobjects, and for every state-object we have an object-state...?
How about lifecycle, or phase?

What are you referring t exactly

holiman · 2024-01-16T11:02:38Z

core/state/statedb.go

@@ -47,6 +47,15 @@ type revision struct {
 	journalIndex int
 }

+type objectState struct {
+	typ  int  // 0 => update; 1 => delete


Shouldn't we use an enum for this? Or, if we know it's only two types, perhaps a boolean?

I honestly dont know how to do that but i have an enum

holiman · 2024-01-16T11:47:47Z

Needs a rebase

holiman · 2024-01-17T10:01:02Z

core/state/statedb.go

-		state.stateObjectsDirty[addr] = struct{}{}
+	// Deep copy the object state markers.
+	for addr, obj := range s.stateObjectsState {
+		state.stateObjectsState[addr] = obj


Isn't this actually a shallow copy?

It looks like modifications to the original state would trickle into the copied state. It would be good to have a testcase that detects this, and not just fix it here and now

I've added a test that shows this bug

However, three lines down:

// Deep copy the destruction markers. for addr, value := range s.stateObjectsDestruct { state.stateObjectsDestruct[addr] = value }

It also just copies over *types.StateAccount into a map, not deep-copy. The actual usage of the items within stateObjectsDestruct is a bit murky to me, we don't use it a lot, but we do use it in handleDestruction. Please look it over.

holiman · 2024-01-17T10:23:07Z

After iterating the latest ethereum mainnet state, I did find a few deployable accounts with non-empty storage

@rjl493456442 is that the exhaustive list?

holiman · 2024-01-17T10:27:31Z

From teh bottom

...
https://etherscan.io/address/0x6f156dbf8ed30e53f7c9df73144e69f65cbb7e94
https://etherscan.io/address/0x2c081ed1949d7dd9447f9d96e509befe576d4461
https://etherscan.io/address/0x14725085d004f1b10ee07234a4ab28c5ad2a7b9e
https://etherscan.io/address/0x361d7a60b43587c7f6bba4f9fd9642747f65210a
https://etherscan.io/address/0xb619f45637c39ca49a41ac64c11637a0a194455e
https://etherscan.io/address/0x5071cb62aa170b7f66b26cae8004d90e6078bb1e
https://etherscan.io/address/0xadd92e0650457c5db0c4c08cbf7ca580175d33d2
https://etherscan.io/address/0x3311c08066580cb906a7287b6786e504c2ebd09f
https://etherscan.io/address/0x02820e4bee488c40f7455fdca53125565148708f
https://etherscan.io/address/0xe62dc49c92fa799033644d2a9afd7e3babe5a80a
https://etherscan.io/address/0x5cc182fabfb81a056b6080d4200bc5150673d06f
https://etherscan.io/address/0xf4a835ec1364809003de3925685f24cd360bdffe
https://etherscan.io/address/0xfc4465f84b29a1f8794dc753f41bef1f4b025ed2
https://etherscan.io/address/0x40490c9c468622d5c89646d6f3097f8eaf80c411
https://etherscan.io/address/0xa21b22389bfc1cd6bc7ba19a4fc96adc3d0fe074 (10 eth!)
https://etherscan.io/address/0x59ec0410867828e3b8c23dd8a29d9796ef523b17
https://etherscan.io/address/0x19272418753b90d9a3e3efc8430b1612c55fcb3a
https://etherscan.io/address/0xfee7707fa4b8c0a923a0e40399db3e7ce26069c6

holiman · 2024-01-17T10:38:45Z

We also need to ensure to skip the tests that fail on CI, before we merge this.

petertdavies · 2024-01-17T13:59:57Z

if it is technically possible, consider the L2s that have tottaly different states. why not to cover all mathmatic solutions of this account reset/collision function?

My point is: it's technically possible to trigger, but we need to align the behavior about it between different clients.

Re the behavior definition: I would vote to just add the new contract code to the existent account, instead of resetting the whole account.

Currently, I believe the behaviour is mostly aligned on doing the account reset. Reth and EELS both intentionally implement a version of the account reset solely to pass the tests. Py-evm declares the situation impossible and doesn't implement the account reset. I can't speak to other clients, but I assume they implement the account reset rather than marking the tests invalid.

Currently the tests are filled by Geth, so this PR will confusingly make other clients testsuites start failing when the tests are refilled with the new behaviour.

holiman · 2024-01-25T09:02:03Z

@rjl493456442 don't forget this, it needs some love

yjhmelody · 2024-03-29T03:13:31Z

Therefore the second conclusion we have is The existent deployable accounts with storage are not possible to be redeployed unless hash collision.
In a summary we can prove (c) and (d) are impossible to occur.

@rjl493456442 Hi I wonder if in once tx, an account call twice create, it seems is not discussed.
See test case https://github.com/ethereum/tests/blob/develop/BlockchainTests/GeneralStateTests/stCreate2/create2collisionStorage.json

rjl493456442 · 2024-03-29T03:22:23Z

https://github.com/ethereum/tests/blob/develop/BlockchainTests/GeneralStateTests/stCreate2/create2collisionStorage.json

This scenario described by the test is impossible to happen, unless the hash collision. If we have EIP7610 included, this test case should be modified.

yjhmelody · 2024-03-29T09:58:43Z

@rjl493456442 Hi
What I mean is that in a tx of using the contract to create two new contracts, If we call create2 twice, and the parameters were exactly the same. Is it impossible to happen in the current Ethereum?

rjl493456442 · 2024-04-08T06:04:17Z

@yjhmelody

It's impossible to create a contract at the designed address twice within the same transaction, even the former created one is self-destructed.

Before the deployment, this check will be conducted:

	// Ensure there's no existing contract already at the designated address
	contractHash := evm.StateDB.GetCodeHash(address)
	if evm.StateDB.GetNonce(address) != 0 || (contractHash != (common.Hash{}) && contractHash != types.EmptyCodeHash) {
		if evm.Config.Tracer != nil && evm.Config.Tracer.OnGasChange != nil {
			evm.Config.Tracer.OnGasChange(gas, 0, tracing.GasChangeCallFailedExecution)
		}

		return nil, common.Address{}, 0, ErrContractAddressCollision
	}

The nonce of former-created one will remain as non-zero within the whole transaction execution.

core/state/statedb.go

holiman · 2024-04-08T11:35:37Z

core/state/statedb.go

@@ -1407,3 +1355,19 @@ func copy2DSet[k comparable](set map[k]map[common.Hash][]byte) map[k]map[common.
 	}
 	return copied
 }
+
+func (s *StateDB) markDelete(addr common.Address) {


Please add a docstring about when/why this method should be invoked (same for the one below)

rjl493456442 · 2024-04-09T05:35:38Z

Please don't merge this pull request, as it violates the EIP-6780.

In EIP-6780, the contract deployed within the same transaction can be self-destructed. While a special case supported by protocol is the account was previously existent with non-zero balance, zero-nonce, zero-code and empty contract. It's deployed with contract code within the transaction and is eligible for self-destruction.

In this pull request, if the account was present, the CreateAccount operation is skipped, and leave obj.created as false. Therefore, the following self-destruction is rejected. The relevant tests can be found in BlockchainTests/Pyspecs/cancun/eip6780_selfdestruct.

The potential fix is to explicitly set the created as true in this special case. EDIT, the fix is implemented in the last commit

holiman · 2024-04-09T06:09:09Z

this pull request, if the account was present, the CreateAccount operation is skipped, and leave obj.created as false. Therefore, the following self-destruction is rejected. The relevant tests can be found in BlockchainTests/Pyspecs/cancun/eip6780_selfdestruct.

That is quirky indeed.

Technically: a create account is when it's entered into the trie, i.e: when someone sends some balance there.
EIP-6780: a create account is when we do set code on it

So essentially it is possible to selfdestruct an account IFF we set code on it in this transaction. Would it make sense to journal setcode instead of create account?

I'm not sure which I prefer, but we need to be super-clear on the semantics of the events.

holiman · 2024-04-09T06:11:49Z

Can't we just set created to true on setcode, instead of create account?

rjl493456442 · 2024-04-09T06:34:28Z

EIP-6780: a create account is when we do set code on it

Essentially, the contract can be self-destruct-6780'd IFF the runtime code is non-empty, namely SetCode(non-zero-runtime-code) must be conducted previously within the same transaction.

Interesting idea, i will think about it. Sound like it's more semantic correct.

rjl493456442 · 2024-04-11T07:01:48Z

@holiman

Technically: a create account is when it's entered into the trie, i.e: when someone sends some balance there.
EIP-6780: a create account is when we do set code on it
So essentially it is possible to selfdestruct an account IFF we set code on it in this transaction. Would it make sense to journal setcode instead of create account?

Actually flagging the create on SetCode is insufficient. We have a test case that destruct the newly-created object within the init code, whereas the runtime code is only set after executing the init-code.

Therefore, the flag must be set before init-code execution and must be revoked at the end of the transaction. The flag could be named as eip6780Deletable.

holiman · 2024-04-12T09:40:34Z

We have a test case that destruct the newly-created object within the init code, whereas the runtime code is only set after executing the init-code.

What testcase is that?
It sounds to me like it should be fine:ish, if we selfdestruct during initcode, we cannot return any bytecode (?), and this will never even create it (?). Sounds like it should somewhat work itself out?

I'll play around a bit with alternative fixes after the commit d68fda5997db1ab72cf8958c89300789230afb90.

rjl493456442 · 2024-04-16T06:28:15Z

Close it in favor of #29520

rjl493456442 force-pushed the no-reset-object-4 branch from df805c4 to c9adc7b Compare December 11, 2023 05:54

This was referenced Dec 11, 2023

core/state: fix statedb.Copy #28094

Closed

core/state: remove reset-account notion in statedb #28100

Closed

This comment was marked as spam.

Sign in to view

rjl493456442 force-pushed the no-reset-object-4 branch from c9adc7b to dc677ad Compare December 15, 2023 06:25

rjl493456442 marked this pull request as ready for review January 8, 2024 02:45

rjl493456442 requested review from karalabe and holiman as code owners January 8, 2024 02:45

rjl493456442 force-pushed the no-reset-object-4 branch 2 times, most recently from b169a09 to 87e175b Compare January 12, 2024 06:26

holiman approved these changes Jan 16, 2024

View reviewed changes

holiman reviewed Jan 17, 2024

View reviewed changes

holiman mentioned this pull request Jan 25, 2024

Refactor state journalling system #28875

Closed

rjl493456442 force-pushed the no-reset-object-4 branch from 213b9f8 to 3f22e79 Compare February 1, 2024 06:40

rjl493456442 force-pushed the no-reset-object-4 branch from 3f22e79 to 1afc158 Compare February 28, 2024 03:05

ChihChengLiang mentioned this pull request Mar 4, 2024

Merge Transfer and TransferWithGas gadget privacy-scaling-explorations/zkevm-circuits#1777

Merged

rjl493456442 force-pushed the no-reset-object-4 branch 2 times, most recently from 234f9ba to b3fc6be Compare March 6, 2024 06:55

rjl493456442 force-pushed the no-reset-object-4 branch 3 times, most recently from b0322c8 to f0353de Compare April 8, 2024 07:56

holiman reviewed Apr 8, 2024

View reviewed changes

core/state, tests: remove account reset operation

d68fda5

rjl493456442 force-pushed the no-reset-object-4 branch from 306f7bc to d68fda5 Compare April 9, 2024 01:40

core/state, core/vm: define set destructible

2e079b3

core/state: add method doc

48f9af8

holiman mentioned this pull request Apr 9, 2024

Crash in gasSStoreEIP2200 due to panic in SubRefund #20119

Closed

core/state: add test

85c387f

core/state, core/vm: fix

214ada8

core/state: improve

3c165f8

holiman mentioned this pull request Apr 12, 2024

core/state: remove account reset operation v2 #29520

Merged

rjl493456442 closed this Apr 16, 2024

core/state: remove account reset operation #28666

core/state: remove account reset operation #28666

Conversation

rjl493456442 commented Dec 11, 2023 • edited Loading

This comment was marked as spam.

rjl493456442 commented Dec 12, 2023

rjl493456442 commented Dec 12, 2023

rjl493456442 commented Dec 13, 2023 • edited Loading

rjl493456442 commented Dec 13, 2023 • edited Loading

rjl493456442 commented Dec 15, 2023 • edited Loading

petertdavies commented Jan 15, 2024

rjl493456442 commented Jan 15, 2024 • edited Loading

rjl493456442 commented Jan 15, 2024 • edited Loading

winsvega commented Jan 15, 2024

rjl493456442 commented Jan 16, 2024

holiman commented Jan 16, 2024 via email

holiman left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

holiman commented Jan 16, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

holiman commented Jan 17, 2024

holiman commented Jan 17, 2024 • edited by MariusVanDerWijden Loading

holiman commented Jan 17, 2024

petertdavies commented Jan 17, 2024

holiman commented Jan 25, 2024

yjhmelody commented Mar 29, 2024

rjl493456442 commented Mar 29, 2024

yjhmelody commented Mar 29, 2024

rjl493456442 commented Apr 8, 2024

Choose a reason for hiding this comment

rjl493456442 commented Apr 9, 2024 • edited Loading

holiman commented Apr 9, 2024

holiman commented Apr 9, 2024

rjl493456442 commented Apr 9, 2024

rjl493456442 commented Apr 11, 2024 • edited Loading

holiman commented Apr 12, 2024

rjl493456442 commented Apr 16, 2024

rjl493456442 commented Dec 11, 2023 •

edited

Loading

rjl493456442 commented Dec 13, 2023 •

edited

Loading

rjl493456442 commented Dec 13, 2023 •

edited

Loading

rjl493456442 commented Dec 15, 2023 •

edited

Loading

rjl493456442 commented Jan 15, 2024 •

edited

Loading

rjl493456442 commented Jan 15, 2024 •

edited

Loading

holiman commented Jan 17, 2024 •

edited by MariusVanDerWijden

Loading

rjl493456442 commented Apr 9, 2024 •

edited

Loading

rjl493456442 commented Apr 11, 2024 •

edited

Loading