EVM命令行接口在输入中删除标题零
我正在通过evm命令行执行虚拟（智能）合同，以了解如何将输入传递给合同。我正在使用以下合同字节：
60003500
PUSH1 0x00
CALLDATALOAD
STOP
如果我提供0x101作为输入，则获得了预期的结果：
>>> evm --code 60003500 --input 101 --debug run
0x
#### TRACE ####
PUSH1 pc=00000000 gas=10000000000 cost=3
CALLDATALOAD pc=00000002 gas=9999999997 cost=3
Stack:
00000000 0x0
STOP pc=00000003 gas=9999999994 cost=0
Stack:
00000000 0x101000000000000000000000000000000000000000000000000000000000000 # AS EXPECTED
尽管如果我输入0x001，则ZEROS似乎被删除EVM（请参阅最后一行的堆栈状态）。
>>> evm --code 60003500 --input 001 --debug run
0x
#### TRACE ####
PUSH1 pc=00000000 gas=10000000000 cost=3
CALLDATALOAD pc=00000002 gas=9999999997 cost=3
Stack:
00000000 0x0
STOP pc=00000003 gas=9999999994 cost=0
Stack:
00000000 0x1000000000000000000000000000000000000000000000000000000000000 # NOT AS EXPECTED
我正在使用EVM版本1.10.17稳定-25C9B49F。为什么EVM删除领先的零？
I am executing a dummy (smart) contract through the evm command line to understand how input is passed to the contract. I am using the following contract bytecode:
60003500
PUSH1 0x00
CALLDATALOAD
STOP
If I provide 0x101 as input I get the expected result:
>>> evm --code 60003500 --input 101 --debug run
0x
#### TRACE ####
PUSH1 pc=00000000 gas=10000000000 cost=3
CALLDATALOAD pc=00000002 gas=9999999997 cost=3
Stack:
00000000 0x0
STOP pc=00000003 gas=9999999994 cost=0
Stack:
00000000 0x101000000000000000000000000000000000000000000000000000000000000 # AS EXPECTED
Although, if I input 0x001, the heading zeros seem to be dropped by the evm (see stack state on last line).
>>> evm --code 60003500 --input 001 --debug run
0x
#### TRACE ####
PUSH1 pc=00000000 gas=10000000000 cost=3
CALLDATALOAD pc=00000002 gas=9999999997 cost=3
Stack:
00000000 0x0
STOP pc=00000003 gas=9999999994 cost=0
Stack:
00000000 0x1000000000000000000000000000000000000000000000000000000000000 # NOT AS EXPECTED
I am using evm version 1.10.17-stable-25c9b49f. Why does the evm drops the leading zeros?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
请参阅Holger的评论。领先的零不会更改数字的值。
这是一个小数示例：
12 = 1*10 + 2*1 = 10 + 2 = 12012 = 0*100 + 1*10 + 2*1 = 0 = 0 + 10 + 10 + 2 = 120x在十六进制数字的前面只是告诉人类（和计算机），接下来的数字是以十六进制格式的，而不是小数。编辑：看来您要问的问题是如何通过
0x01000000000000000000000000000。0x01转换为0x10000000000000000000000000000000的原因是因为它首先评估0x1，然后将其右移直到所有其余的位都填满了所有剩余位零。要表示0x01000000000000000000000000000，您必须放置0x0100000000000000000000000000000000000。See Holger's comment. Leading zeros do not change the value of a number.
Here's a decimal example to demonstrate:
12 = 1*10 + 2*1 = 10 + 2 = 12012 = 0*100 + 1*10 + 2*1 = 0 + 10 + 2 = 12The
0xin front of the hexadecimal number is simply to tell humans (and computers) that the number that follows is in hexadecimal format, instead of decimal.EDIT: It appears that the question you are asking is how to pass
0x0100000000000000000000000000000. The reason that0x01translates to0x100000000000000000000000000000is because it first evaluates to0x1, then it is right-shifted until all the remaining bits are filled with zeros. To represent0x0100000000000000000000000000000, you must put0x0100000000000000000000000000000.事实证明，对于奇数长度输入，
evm中有一个很小的错误。因此，尽管我说第一个是预期的，但问题中没有一个示例实际上给出了预期的结果。这是一个简化的示例。以下两个命令将相同的呼叫消息发送给智能合约：
呼叫消息为
0x01000000000000000000000000000000000000000000000000000000000000000000000000000000000000在两种情况下。因此，该错误不是第二个命令的领先零是删除的，而是在有奇数长度输入时将领先的零添加到输入中。最终，我充满信心，有些东西是可怕的发布了一个问题 a href =“ https://github.com/ethereum/go-ethereum/pull/24721” rel =“ nofollow noreferrer”>后来修复了。对于较旧的版本，简单的修复是始终提供均匀的输入，因为从左到右，呼叫消息并不简单地填充。
It turns out there is a tiny bug in the
evmfor odd length inputs. So none of the examples in the question actually gives the expected result despite me stating that the first one was as expected.Here is a simplified example. Both of the following commands send the same call message to the smart contract:
The call message is
0x0100000000000000000000000000000000000000000000000000000000000000in both cases. Thus the bug is not that the leading zero of the second command is dropped, but rather that a leading zero is added to the input when there is an odd-length input.I eventually got confident enough that something was fishy to post an issue which was later fixed. For older versions the easy fix is to always provide even-length input as the call message is not simply filled bit by bit from left to right.