-
Notifications
You must be signed in to change notification settings - Fork 783
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
Use Address type #919
Use Address type #919
Conversation
Codecov Report
Flags with carried forward coverage won't be shown. Click here to find out more. |
} else { | ||
const acc = await this._state.getAccount(message.caller) | ||
const newNonce = acc.nonce.subn(1) | ||
addr = generateAddress(message.caller, newNonce.toArrayLike(Buffer)) | ||
addr = generateAddress(message.caller.buf, newNonce.toArrayLike(Buffer)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make generateAddress
and generateAddress2
also take Address
as input type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unfortunately those have been in ethereumjs-util
for a while so we'd have to make breaking changes there. it would be nice if they output an Address
as well.
another thing I noticed is it would be better if it accepted nonce as a BN
instead of Buffer
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah woops, thought these were defined inside EVM
const result = await vm.runCall({ | ||
caller: Buffer.from('0000000000000000000000000000000000000000', 'hex'), | ||
caller: Address.zero(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few nitpick comments, but looks good in general, I do have two main points though:
- Any semi-exposed functions which use a
Buffer
as input where anAddress
is expected should be changed to functions which takeAddress
as input (seems like only a few of those remain). This makes these changes consistent. Only use theAddress.buf
if you really need it. - I am not entirely convinced yet that the VM cannot internally hit
assert(buf.length === 20, 'Invalid address length')
(constructor ofAddress
). If we safely convertBN
s toBuffer
viaaddressToBuffer
this should be fine.
be15570
to
6ed7b2a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Ryan, this looks wonderful! 🎉
Will merge this in, the suggestions from @jochem-brouwer can be done after the dev release since not life-threatening, I actually expect at least 2-3 rounds of dev releases with all the changes we've done.
This PR updates the vm to use the
Address
type internally and externally to improve clarity and provide strict byte length validation.