十六进制字符 我们为什么需要交易数据?

所有事务中都有一个“数据”字段，但它实际包含什么，为什么？

您可能已经注意到，当与智能合同交互时(例如，发送令牌)，您的事务会自动包含输入数据。在MyCrypto上，这被简单地标记为“数据”——但是它是做什么的呢？在本文中，您将看到事务输入数据的技术解释，包括它是什么以及它是如何工作的。

什么是输入数据？

让我们看看这个令牌事务的开始。一个人发送零个以太到

0xd 26114 CD 6 ee 289 accf 82350 c8 d 8487 fed 8 a 0 c 07(OMI sego合同地址)，Etherscan显示这是一个向该地址发送0.19 OMG令牌的事务。那么EVM(以太网虚拟机)怎么知道这个人想把这些令牌转移到另一个地址呢？

如果您再次查看Etherscan，您将看到事务有输入数据，这是可以附加到事务的附加数据。它可以是纯文本或数字(格式为十六进制)，但在这种情况下，用户使用输入数据来告诉合同运行某个功能。契约是建立在一系列功能之上的。例如，ERC-20令牌使用转移和平衡等功能将令牌从甲转移到乙，并分别获得地址的平衡。对于上面的事务，您可以看到在Etherscan上调用了函数转移(address _ to，uint256 _ value)。

上述交易的原始输入数据为:

0xa 9059 cbb 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002 a 34892d 36 D6 c 74。

您可以将这个长的十六进制值分成几个较小的组。第一个0x表示这将是一个十六进制值，接下来的8个字节(a9059cbb)是函数标识符。之后，所有函数参数按32个字节(本例中为64个十六进制字符)分组。

第一组是0000000000000000000000000004 bbee b 066 ed 09 b 7a ed 07 BF 39 eee 0460 df a 261520。

第二组是000000000000000000000000000000000000000000000000000000000000002 a 34892d 36 d6c 74。

如果您查看以太扫描(默认)中的格式化输入数据，您将看到相同的内容:

函数:transfer(address _to，uint256 _value)

MethodID: 0xa9059cbb

[0]:000000000000000000000000004 bbee b 066 ed 09 b 7a ed 07 BF 39 eee 0460 DFA 261520

[1]:000000000000000000000000000000000000000000000000002 a 34892d 36 d6c 74

十六进制是什么？

十六进制是一个数字系统，就像十进制和二进制一样。它使用数字0到9和字母a到f(不区分大小写)来表示0到15之间的十进制值。在下图中，您可以看到对应于十六进制值的数字。十六进制用于以更易读的方式书写大数字。

单个十六进制的最大值为15，长度为4位。当您将多个十六进制数放在一起时，您可以对每个十六进制数使用二进制表示，然后将这些十六进制数表示为十进制数。比如0x5c可以写成0101(= 5)和1100 (= C)，合并得到01011100，是92的二进制数。所以0x5c的十六进制值等于92。

大多数编程语言使用0x前缀作为任意标识符，将十六进制标识符与其他标识符(如正则十进制、二进制数等)分开。).这没有任何意义，但是为了清楚起见，我们将在本文中为每个十六进制包含它。

有了这些，我们继续。如果不完全理解十六进制，不用担心，不需要理解输入的数据是什么。

输入数据和智能合同

数据输入的主要用例是与智能合同进行交互。大多数合同使用合同ABI规范，它允许像以太扫描这样的网站自动解码输入数据并显示被调用的确切操作。在前面的例子中，这是一个使用ERC-20标准代币的交易。这意味着我们知道所有可能的函数及其签名。例如，ERC-20合同的传递函数的完整签名总是transfer(address，uint256)，这意味着它将地址作为第一个参数，将无符号的256位数字作为第二个参数(从0到2-1)。

实度有许多可能的参数类型可以使用。如果您有兴趣了解更多关于实度和智能合同的信息，您可以在实度文档中找到更多关于它的信息。

函数签名

根据我们的理解，传递函数的函数签名是transfer(address，uint256)。每份ERC-20合同都有相同的签名。如果合同对传递函数使用不同的参数，如地址和uint128(无符号128位长整数)，则合同不符合ERC-20标准。

为了获得函数的十六进制签名，我们必须从函数的SHA-3(或Keccak-256)散列中获得前4个字节(8个十六进制字符)。要获取Keccak-256哈希值，可以使用web3 Java库或类似的在线工具。如果我们在这个工具中填写transfer(address，uint256)，它将显示0x a 9059 cbb 2 ab 09 EB 219583 F4 a 59 a5d 0623 ade 346d 962 BCD 4e 46 b 11 da 047 c 9049 b作为输出。如果我们取前8个字符(忽略0x)，我们将得到a9059cbb，它与上面事务中的MethodID相匹配。

再比如:ERC-20批准函数的函数签名是approve(address，uint256)。如果获得了该函数的SHA-3散列，

0x 095ea7b334 AE 44009 aa 867 bfb 386 F5 C3 b 44 b 443 AC 6 f 0 ee 573 fa 91 c 4608 fbadfba，前8个字符为095 ea 7b 3。因此，批准事务的输入数据将从0x095ea7b3开始。比如在这里查看DAI代币合同的这个交易。

地址和金额

每个参数的长度(列表/数组和字符串除外——我们将在后面讨论)是32字节，或者64个十六进制字符，但是以太网地址只有40个字符长(没有0x)。为此，地址用零填充。在十六进制字符串中，0x0000123与0x123相同，因此

0x 00000000000000000000000000004 bbee b 066 ed 09 b 7a ed 0460 DFA 261520(地址)和

0x4bbeeb 066 ed 09 B7 aed 07 BF 39 eee 0460 DFA 261520相同，并且

0x 0000000000000000000000000000000000000000000000000000002 a 34892d 36 d6c 74相同。那么为什么要用全零呢？

正如我们之前了解到的，Solidity契约中的最大数量是2-1，正好是32字节。使用实度长度还可以使EVM和其他应用程序更容易解码数据，因为您可以假设每个组总是具有相同的长度。

数组和字符串呢？

如前一节所述，数组和字符串的输入数据工作方式略有不同。数组基本上是一个项目列表。例如，在大多数编程语言中，1、2和3的列表将被写成[1、2、3]。为了在事务中发送这些数据，列表中的每个项目都作为一个32字节的组发送，并在输入数据的末尾列出，数组长度的指针作为参数。

例如，我们有一个名为myFunction的函数，它接受一个地址和一个数组(myFunction(address，uint256[]))。这个函数的函数签名是0x4b294170。对于这个地址，我们将使用与上面相同的地址。因为我们的数组有3个元素，所以数组的十六进制长度是0x3。我们知道每个参数正好占据空之间的32字节，数组放在所有其他参数之后，所以数组从32+32 = 64字节开始。

该交易的输入数据为:

0x4b 2941700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

因为字符串可以有任何长度(超过32字节)，所以它们被分成32字节的组，并在输入数据中被视为数组。

像Etherscan这样的站点是如何解码输入数据的？

Hash是单向函数，所以如果有函数签名hash，就不可能从hash中得到函数签名(除非执行蛮力处理)。合同所有者可以将合同ABI上传到JSON，就像这里的这个一样，可以用来获取函数签名哈希。

即使合同所有人没有上传合同的ABI，很多合同的输入数据也是可以解码的。正如您在本文前面所学的，ERC-20契约函数的签名总是相同的，这使得Etherscan可以为这些契约使用预定义的契约ABI。例如，合同ABI对ERC-20合同的传递函数如下:

{

“常量”:false，

"输入":[

{

"名称":_to "，

“类型”:“地址”

},

{

" name ":_ value "，

" type": "uint256 "

}

],

“名称”:“转让”，

"输出":[

{

“名称”:“，

" type": "bool "

}

],

“应付”:假，

“状态可变性”:“不可访问”，

“类型”:“功能”

}

如果输入数据的签名与预定义的函数之一相匹配，则Etherscan可以对其进行解码。

输入数据有限制吗？

不可以。以太网对输入数据的长度没有固定的限制，但它确实会消耗气体成本。单个区块的最大气值是有波动的，但是在写这篇文章的时候大概是800万左右。每个0字节(0x00)消耗4种气体，每个非0字节消耗68种气体。标准交易的燃气成本是21000单位燃气，所以不管执行什么合同，输入数据的最大长度都是0的2兆左右，或者只有0.12兆的非0。由于输入数据不太可能是零或非零，实际限制介于两者之间，取决于输入数据。