Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EIP-2681: Limit account nonce to 2^64-1 #934

Merged
merged 3 commits into from
Nov 19, 2021
Merged

Conversation

gumb0
Copy link
Member

@gumb0 gumb0 commented Aug 24, 2021

https://eips.ethereum.org/EIPS/eip-2681
Geth change is in ethereum/go-ethereum#23853

EIP applies retroactively, therefore I put >=Frontier for CREATE and >=Constantinople for CREATE2.
(Also not sure what should be done with already generated legacy transaction tests, probably should be updated)

@gumb0 gumb0 marked this pull request as draft August 24, 2021 13:12
@gumb0 gumb0 force-pushed the eip-2681 branch 3 times, most recently from 10932c7 to e17ac4f Compare August 24, 2021 14:03
@winsvega
Copy link
Collaborator

working to revive ttTransaction Tests

@winsvega
Copy link
Collaborator

checked now with new transaction tests

@winsvega winsvega closed this Oct 15, 2021
@winsvega winsvega reopened this Oct 15, 2021
@winsvega
Copy link
Collaborator

ah wait its the state tests

b94f5374fce5edbc8e2a8697c15331677e6ebf0b:
nonce: '0xffffffffffffffff'
storage:
'1': 1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The EIP states that the CREATE opcodes should "abort with an exceptional halt" when the nonce is about to overflow.
I would expect the storage remains unchanged, is this ok?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, I interpret the EIP text as opcodes themselves end with an exceptional halt, but not the execution frame they're called from (similar to not having enough balance for CREATE's value transfer, call stack overflow, address already existing etc.)

@marioevz
Copy link
Member

marioevz commented Nov 2, 2021

Test cases look good to me, but I think we should add a positive test case for both CREATE/CREATE2 where the nonce is (2**64) - 2, and the contract is still created.
Also, it seems like the current outcome of CREATE_HighNonce is that the nonce wraps around to zero, and STORAGE[0] is equal to the address as if the contract was actually created, although the EIP does not specify what the top of the stack should look like in this scenario.
I'm currently testing on ethereum/go-ethereum@551bd6e.

@gumb0
Copy link
Member Author

gumb0 commented Nov 2, 2021

Also, it seems like the current outcome of CREATE_HighNonce is that the nonce wraps around to zero, and STORAGE[0] is equal to the address as if the contract was actually created,

Yes, current geth's behavior is wrapping around, I linked the possible patch in the description ewasm/go-ethereum@36580c6 which I used to generate.

although the EIP does not specify what the top of the stack should look like in this scenario.

EIP specifies exceptional halt, I think this implies 0 returned on stack, as in all other exceptional cases.

@winsvega winsvega closed this Nov 2, 2021
@winsvega winsvega reopened this Nov 2, 2021
Copy link
Member

@marioevz marioevz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Request for two extra test cases and two minor changes.

b94f5374fce5edbc8e2a8697c15331677e6ebf0b:
nonce: '0xffffffffffffffff'
storage:
'1': 1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a check here for:
storage:
'0': 0

and

04e9a8460199e670ffb592f93a2f74bdcb44b0bd:
'shouldnotexist': '1'

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

storage '0': 0 is implicitly checked I think (error if some storage present that is not in test expectations), but added.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes.
but look after cases where you have
sstore(0, test()) and a pre storage is empty.

if smth goes wrong, the transaction reverted, storage remains unchanged and the expect section not showing any error, but the actual exection of test() was aborted or not performed properly

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand you correctly, that's why sstore(1, 1) is done there in the end
(adding storage '0': 0 wouldn't help this or change anything)

sstore(0, create(0, 0, 5))
sstore(1, 1)
}
nonce: '0xffffffffffffffff'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add a positive test case CREATE_HighNonceMinus1, where nonce is '0xfffffffffffffffe' and contract '0xd061b08a84ebc70fe797f9bd62f4269ef8274a13' is actually created?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added.

nonce: 1
b94f5374fce5edbc8e2a8697c15331677e6ebf0b:
nonce: '0xffffffffffffffff'
storage:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also check:

storage:
'0': 0

and

77dd5d2a2b742ca01ee2cfff306445e3741ef744:
'shouldnotexist': '1'

sstore(0, create2(0, 0, 5, 0))
sstore(1, 1)
}
nonce: '0xffffffffffffffff'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we also add here a positive test case CREATE2_HighNonceMinus1, where nonce is '0xfffffffffffffffe' and contract '0x77dd5d2a2b742ca01ee2cfff306445e3741ef744' is actually created?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added.

@gumb0 gumb0 marked this pull request as ready for review November 3, 2021 17:43
Copy link
Member

@marioevz marioevz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thanks for the changes.
I think this PR still requires ewasm/go-ethereum@eip-2681 to be merged onto ethereum/go-ethereum though.

@holiman
Copy link
Contributor

holiman commented Nov 3, 2021

Geth change is in https://github.com/ewasm/go-ethereum/tree/eip-2681

@gumb0 there's no open PR about it, is there? If not, would you mind opening one?

@gumb0
Copy link
Member Author

gumb0 commented Nov 11, 2021

I have also updated transaction tests for a new rule that nonce == 0xffffffffffffffff is forbidden (see update to EIP ethereum/EIPs#4437) The geth PR linked in description includes a change to t9n tool for this.

@@ -3,6 +3,7 @@
{
"expectException" :
{
">=Frontier": "NonceMax"
Copy link
Member Author

@gumb0 gumb0 Nov 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This new error also has to be added to retesteth config.

The corresponding geth string is

      "NonceMax" : "nonce exceeds 2^64-1",

Copy link
Member Author

@gumb0 gumb0 Nov 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@winsvega should it be called TR_NonceMax ?

(Some transaction tests use errors with TR_ prefix, and others without, so not sure)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added ethereum/retesteth#156 for this.

@gumb0 gumb0 marked this pull request as ready for review November 11, 2021 15:22
@@ -0,0 +1,20 @@
{
"TransactionWithHighNonce64Minus1" :
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be TransactionWithHighNonce64Minus2

Copy link
Member

@marioevz marioevz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me 👍

@gumb0
Copy link
Member Author

gumb0 commented Nov 16, 2021

Rebased.

Copy link
Collaborator

@winsvega winsvega left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok. looks good.

how about a case where a contract with high nonce calls contract via delegate
and that subcall creates a contract. but since the context of execution moved. the actual contract creator changes.

@holiman
Copy link
Contributor

holiman commented Nov 16, 2021

how about a case where a contract with high nonce calls contract via delegate
and that subcall creates a contract. but since the context of execution moved. the actual contract creator changes.

DELEGATECALL doesn't move the context of execution, it just borrows some code and continues where it was. New scope, same address.

@winsvega
Copy link
Collaborator

I mean when A having nonce 0, delegatecall B which has maxnonce, and B creates contract what happens?
should work, no? A will be the creator, not B.

@holiman
Copy link
Contributor

holiman commented Nov 16, 2021

Yes, should work, will work

@gumb0
Copy link
Member Author

gumb0 commented Nov 17, 2021

Rebased, removed change to TransactionWithHighNonce64Minus1 merged in #988.

@winsvega winsvega merged commit cfe840a into ethereum:develop Nov 19, 2021
@winsvega
Copy link
Collaborator

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants