本篇文章给大家谈谈nonce值以太坊，以及以太坊 epoch对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
以太坊里的nonce有两种意思，一个是proof of work nonce，一个是account nonce。
在智能合约里，nonce的值代表的是该合约创建的合约数量。只有当一个合约创建另一个合约的时候才会增加nonce的值。但是当一个合约调用另一个合约中的method时 nonce的值是不变的。
在以太坊中nonce的值可以这样来获取（其实也就是属于一个账户的交易数量）：
但是这个方法只能获取交易once的值。目前是没有内置方法来访问contract中的nonce值的
通过椭圆曲线算法生成钥匙对（公钥和私钥），以太坊采用的是secp256k1曲线,
公钥采用uncompressed模式，生成的私钥为长度32字节的16进制字串，公钥为长度64的公钥字串。公钥04开头。
把公钥去掉04，剩下的进行keccak-256的哈希，得到长度64字节的16进制字串，丢掉前面24个，拿后40个，再加上"0x"，即为以太坊地址。
整个过程可以归纳为：
2）有些网关或系统只能使用ASCII字符。Base64就是用来将非ASCII字符的数据转换成ASCII字符的一种方法，而且base64特别适合在http，mime协议下快速传输数据。Base64使用【字母azAZ数字09和+/】这64个字符编码。原理是将3个字节转换成4个字节(3 X 8) = 24 = (4 X 6)
当剩下的字符数量不足3个字节时，则应使用0进行填充，相应的，输出字符则使用'='占位，因此编码后输出的文本末尾可能会出现1至2个'='。
1）Base58是用于Bitcoin中使用的一种独特的编码方式，主要用于产生Bitcoin的钱包地址。相比Base64，Base58不使用数字"0"，字母大写"O"，字母大写"I"，和字母小写"l"，以及"+"和"/"符号。
Base58Check是一种常用在比特币中的Base58编码格式，增加了错误校验码来检查数据在转录中出现的错误。 校验码长4个字节，添加到需要编码的数据之后。校验码是从需要编码的数据的哈希值中得到的，所以可以用来检测并避免转录和输入中产生的错误。使用 Base58check编码格式时，编码软件会计算原始数据的校验码并和结果数据中自带的校验码进行对比。二者不匹配则表明有错误产生，那么这个 Base58Check格式的数据就是无效的。例如，一个错误比特币地址就不会被钱包认为是有效的地址，否则这种错误会造成资金的丢失。
为了使用Base58Check编码格式对数据（数字）进行编码，首先我们要对数据添加一个称作“版本字节”的前缀，这个前缀用来明确需要编码的数 据的类型。例如，比特币地址的前缀是0（十六进制是0x00），而对私钥编码时前缀是128（十六进制是0x80）。 表4-1会列出一些常见版本的前缀。
接下来，我们计算“双哈希”校验码，意味着要对之前的结果（前缀和数据）运行两次SHA256哈希算法：
checksum = SHA256(SHA256(prefix+data))
在产生的长32个字节的哈希值（两次哈希运算）中，我们只取前4个字节。这4个字节就作为校验码。校验码会添加到数据之后。
结果由三部分组成：前缀、数据和校验码。这个结果采用之前描述的Base58字母表编码。下图描述了Base58Check编码的过程。
相同:
1） 哈希算法、Merkle树、公钥密码算法
2）全新的 SHA-3 加密标准 —— Keccak
3）在线加密算法
4）比特币地址生成算法详解
5）Base58Check编码实现示例
6） 比特币交易中的签名与验证
交易
区块链交易的行为遵循不同的规则集
由于公共区块链分布式和无需许可的性质，任何人都可以签署交易并将其广播到网络。
根据区块链的不同，交易者将被收取一定的交易费用，交易费用取决于用户的需求而不是交易中资产的价值。
区块链交易无需任何中央机构的验证。仅需使用与其区块链相对应的数字签名算法（DSA）使用私钥对其进行签名。
一旦一笔交易被签名，广播到网络中并被挖掘到网络中成功的区块中，就无法恢复交易。
以太坊交易结构
以太坊交易的数据结构：交易0.1个ETH
{
'nonce':'0x00', // 十进制：0
'gasLimit': '0x5208', //十进制： 21000
'gasPrice': '0x3b9aca00', //十进制1，000，000，000
'to': '0x17A98d2b11Dfb784e63337d2170e21cf5DD04631' ，//发送地址
'value': '0x16345785d8a0000',//100000000000000000 ，10^17
'data': '0x', // 空数据的十进制表示
'chainId': 1 // 区块链网络ID
}
这些数据与交易内容无关，与交易的执行方式有关，这是由于在以太坊中发送交易中，您必须定义一些其他参数来告诉矿工如何处理您的交易。交易数据结构有2个属性设计"gas": "gasPrice","gasLimit"。
"gasPrice": 单位为Gwei, 为 1/1000个eth,表示交易费用
"gasLimit": 交易允许使用的最大gas费用。
这2个值通常由钱包提供商自动填写。
除此之外还需要指定在哪个以太坊网络上执行交易（chainId）: 1表示以太坊主网。
在开发时，通常会在本地以及测试网络上进行测试，通过测试网络发放的测试ETH进行交易以避免经济损失。在测试完成后再进入主网交易。
另外，如果需要提交一些其它数据，可以用"data"和"nonce"作为事务的一部分附加。
A nonce（仅使用1次的数字）是以太坊网络用于跟踪交易的数值，有助于避免网络中的双重支出以及重放攻击。
以太坊交易签名
以太坊交易会涉及ECDSA算法，以Javascript代码为例，使用流行的ethers.js来调用ECDSA算法进行交易签名。
const ethers = require('ethers')
const signer = new ethers.Wallet('钱包地址')
signer.signTransaction({
'nonce':'0x00', // 十进制：0
'gasLimit': '0x5208', //十进制： 21000
'gasPrice': '0x3b9aca00', //十进制1，000，000，000
'to': '0x17A98d2b11Dfb784e63337d2170e21cf5DD04631' ，//发送地址
'value': '0x16345785d8a0000',//100000000000000000 ，10^17
'data': '0x', // 空数据的十进制表示
'chainId': 1 // 区块链网络ID
})
.then(console.log)
可以使用在线使用程序Composer将已签名的交易传递到以太坊网络。这种做法被称为”离线签名“。离线签名对于诸如状态通道之类的应用程序特别有用，这些通道是跟踪两个帐户之间余额的智能合约，并且在提交已签名的交易后就可以转移资金。脱机签名也是去中心化交易所（DEXes）中的一种常见做法。
也可以使用在线钱包通过以太坊账户创建签名验证和广播。
使用Portis，您可以签署交易以与加油站网络（GSN）进行交互。
链乔教育在线旗下学硕创新区块链技术工作站是中国教育部学校规划建设发展中心开展的“智慧学习工场2020-学硕创新工作站 ”唯一获准的“区块链技术专业”试点工作站。专业站立足为学生提供多样化成长路径，推进专业学位研究生产学研结合培养模式改革，构建应用型、复合型人才培养体系。
为了防止交易重播，ETH（ETC）节点要求每笔交易必须有一个nonce数值。每一个账户从同一个节点发起交易时，这个nonce值从0开始计数，发送一笔nonce对应加1。当前面的nonce处理完成之后才会处理后面的nonce。注意这里的前提条件是相同的地址在相同的节点发送交易。
以下是nonce使用的几条规则：
● 当nonce太小（小于之前已经有交易使用的nonce值），交易会被直接拒绝。
● 当nonce太大，交易会一直处于队列之中，这也就是导致我们上面描述的问题的原因；
● 当发送一个比较大的nonce值，然后补齐开始nonce到那个值之间的nonce，那么交易依旧可以被执行。
● 当交易处于queue中时停止geth客户端，那么交易queue中的交易会被清除掉。
第一个字段 AccountNonce ，直译就是账户随机数。它是以太坊中很小但也很重要的一个细节。以太坊为每个账户和交易都创建了一个Nonce，当从账户发起交易的时候，当前账户的Nonce值就被作为交易的Nonce。这里，如果是普通账户那么Nonce就是它发出的交易数，如果是合约账户就是从它的创建合约数。
为什么要使用这个Nonce呢？其主要目的就是为了防止重复攻击（Replay Attack）。因为交易都是需要签名的，假定没有Nonce，那么只要交易数据和发起人是确定的，签名就一定是相同的，这样攻击者就能在收到一个交易数据后，重新生成一个完全相同的交易并再次提交，比如A给B发了个交易，因为交易是有签名的，B虽然不能改动这个交易数据，但只要反复提交一模一样的交易数据，就能把A账户的所有资金都转到B手里。
当使用账户Nonce之后，每次发起一个交易，A账户的Nonce值就会增加，当B重新提交时，因为Nonce对不上了，交易就会被拒绝。这样就可以防止重复攻击。当然，事情还没有完，因为还能跨链实施攻击，直到EIP-155引入了chainID，才实现了不同链之间的交易数据不兼容。事实上，Nonce并不能真正防止重复攻击，比如A向B买东西，发起交易T1给B，紧接着又提交另一个交易T2，T2的Gas价格更高、优先级更高将被优先处理，如果恰好T2处理完成后剩余资金已经不足以支付T1，那么T1就会被拒绝。这时如果B已经把东西给了A，那A也就攻击成功了。所以说，就算交易被处理了也还要再等待一定时间，确保生成足够深度的区块，才能保证交易的不可逆。
Price 指的是单位Gas的价格，所谓Gas就是交易的消耗，Price就是单位Gas要消耗多少以太币（Ether），Gas * Price就是处理交易需要消耗多少以太币，它就相当于比特币中的交易手续费。
GasLimit 限定了本次交易允许消耗资源的最高上限，换句话说，以太坊中的交易不可能无限制地消耗资源，这也是以太坊的安全策略之一，防止攻击者恶意占用资源。
Recipient 是交易接收者，它是common.Address指针类型，代表一个地址。这个值也可以是空的，这时在交易执行时，会通过智能合约创建一个地址来完成交易。
Amount 是交易额。这个简单，不用解释。
Payload 比较重要，它是一个字节数组，可以用来作为创建合约的指令数组，这时每个字节都是一个单独的指令；也可以作为数据数组，由合约指令来进行操作。合约由以太坊虚拟机（Ethereum Virtual Machine，EVM）创建并执行。
V、R、S 是交易的签名数据。以太坊当中，交易经过数字签名之后，生成的signature是一个长度65的字节数组，它被截成三段，前32字节被放进R，再32字节放进S，最后1个字节放进V。那么为什么要被截成3段呢？以太坊用的是ECDSA算法，R和S就是ECSDA签名输出，V则是Recovery ID。
R,S,V是交易签名后的值，它们可以被用来生成签名者的公钥；R，S是ECDSA椭圆加密算法的输出值，V是用于恢复结果的ID
之前在做后端接口的时候，封装了构造交易及发送交易这一层，其中构造交易的时候，获取用户的nonce这里，没有自己维护，而是从链上获取，且之前由于一些业务这里没有做队列，导致前端并发调用的时候，会产生一个账户同时构造两个相同nonce值得交易，最终会导致失败一条。
Client.PendingNonceAt 是从pending中获取该账户的本次交易改用的nonce，本以为这里已经处理了就没管，不曾想，还是会出现上面的交易重复的bug。
经修改，如果是特殊账户，可在业务层自行维护计数器做nonce值，维护成本较大，且复杂。
第二种 就是这里加个队列，毕竟及时性不是区块链该有的东西。
在使用同一个地址连续发送交易时，每笔交易往往不可能立即到账， 当前交易还未到账nonce值以太坊的情况下，下一笔交易无论是通过 eth.getTransactionCount() 获取nonce值来设置，还是由节点自动从区块中查询，都会获得和前一笔交易同样的nonce值，这时节点就会报错 Error: replacement transaction underpriced
在构建一笔新的交易时，在交易数据结构中会产生一个nonce值， nonce是当前区块链下，发送者(from地址)发出的交易(成功记录进区块的)总数， 再加上1。例如新构建一笔从A发往B的交易，A地址之前的交易次数为10，那么这笔交易中的nonce则会设置成11， 节点验证通过后则会放入交易池（txPool）,并向其他节点广播，该笔交易等待矿工将其打包进新的区块。
那么，如果在先构建并发送了一笔从地址A发出的，nonce为11的交易，在该交易未打包进区块之前， 再次构建一笔从A发出的交易，并将它发送到节点，不管是先通过web3的eth.getTransactionCount(A)获取到的过往的交易数量，还是由节点自行填写nonce， 后面的这笔交易的nonce同样是11， 此时就出现了问题：
实际场景中，会有批量从一个地址发送交易的需求，首先这些操作可能也应该是并行的，我们不会等待一笔交易成功写入区块后再发起第二笔交易，那么此时有什么好的解决办法呢nonce值以太坊？先来看看geth节点中交易池对交易的处理流程
如之前所说，构建一笔交易时如果不手动设置nonce值，geth节点会默认计算发起地址此前最大nonce数（写入区块的才算数），然后将其加上1， 然后将这笔交易放入节点交易池中的pending队列，等到节点将其打包进区块。
构建交易时，nonce值是可以手动设置的，如果当前的nonce本应该设置成11， 但是我手动设置成了13， 在节点收到这笔交易时， 发现pending队列中并没有改地址下nonce为11及12的交易， 就会将这笔nonce为13的交易放入交易池的queued队列中。只有当前面的nonce补齐（nonce为11及12的交易被发现并放入pending队列）之后，才会将它放入pending队列中等待打包。
我们把pending队列中的交易视为可执行的，因为它们可能被矿工打包进最新的区块。 而queue队列因为前面的nonce存在缺失，暂时无法被矿工打包，称为不可执行交易。
那么实际开发中，批量从一个地址发送交易时，应该怎么办呢？
方案一：那么在批量从一个地址发送交易时， 可以持久化一个本地的nonce，构建交易时用本地的nonce去累加，逐一填充到后面的交易。（要注意本地的nonce可能会出现偏差，可能需要定期从区块中重新获取nonce，更新至本地）。这个方法也有一定的局限性，适合内部地址（即只有这个服务会使用该地址发送交易）。
说到这里还有个坑，许多人认为通过 eth.getTransactionCount(address, "pending") ，第二个参数为 pending ， 就能获得包含本地交易池pending队列的nonce值，但是实际情况并不是这样， 这里的 pending 只包含待放入打包区块的交易， 假设已写入交易区块的数量为20， 又发送了nonce为21，22，23的交易， 通过上面方法取得nonce可能是21（前面的21，22，23均未放入待打包区块）， 也可能是22（前面的21放入待打包区块了，但是22，23还未放入）。
方案二是每次构建交易时，从geth节点的pending队列取到最后一笔可执行交易的nonce, 在此基础上加1，再发送给节点。可以通过 txpool.content 或 txpool.inspect 来获得交易池列表，里面可以看到pending及queue的交易列表。
启动节点时，是可以设置交易池中的每个地址的pending队列的容量上限，queue队列的上容量上限， 以及整个交易池的pending队列和queue队列的容量上限。所以高并发的批量交易中，需要增加节点的交易池容量。
当然，除了扩大交易池，控制发送频率，更要设置合理的交易手续费，eth上交易写入区块的速度取决于手续费及eth网络的拥堵状况，发送每笔交易时，设置合理的矿工费用，避免大量的交易积压在交易池。
关于nonce值以太坊和以太坊 epoch的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
评论