geth提交交易时报错“invalid opcode:revert ”是为什么?

提交claimReward(1)的交易未被矿工处理时，状态变量claimed=false应该不会改变，并且在提交交易后也用语句查询确认了变量并未改变，但是再次发送这笔交易时就会提示“invalid opcode:revert ”，我查询原因是require语句不满足，可是如果claimed仍为false的话，require语句就是满足的，不应该出现这种状况，所以为什么第二次交易会失败?

这个问题可能由于您交易的执行状态和智能合约中变量的更新顺序导致的。请注意，当您提交一个交易时，该交易的执行和状态变更可能需要等待矿工的确认和执行。

在第一次提交claimReward(1)的交易时，您查询的状态变量claimed=false是符合预期的。但是，由于交易还未被矿工确认和执行，智能合约中的状态变量可能仍然保持未改变的状态。

当您尝试再次发送相同的交易时，以确认交易是否成功，由于该交易已经被先前的交易提交过了，交易执行会失败，因为该事务尝试重复处理同一交易（state-changing transaction）。

具体而言，“invalid opcode:revert” 错误通常与智能合约中的require语句有关。这意味着在合约的执行过程中，require语句的条件未被满足，导致交易失败。在这种情况下，错误信息表明require语句引发了异常，并使交易失败。

建议您在发送交易之前，根据最新的交易状态等待足够的时间，以确保前一个交易已经被矿工确认并执行。您可以使用交易哈希值来查询交易的执行状态，并在状态变量确实被更新后再发送下一个交易。

如果您仍然遇到问题，您可能需要更详细地审查智能合约代码，并检查require语句的条件是否正确和合适。此外，还可以检查合约中其他可能引发异常的代码部分，以了解可能导致交易失败的原因。

该回答通过自己思路及引用到GPTᴼᴾᴱᴺᴬᴵ搜索,得到内容具体如下：根据您提供的信息和代码截图，可能是以下原因导致了交易失败：

状态变量 claimed 可能在 confirmReward() 函数内部被修改了。因为在您的代码中，如果 msg.sender 是合约所有者，那么 claimed 就会被设置为 true，这可能会导致第二次调用 claimReward() 函数时出现 require 验证失败的情况。
可能是 rewardRate 的值发生了变化，导致 require 验证失败。在您的代码中，如果 rewardRate 的值为 0，那么就会触发 require 验证失败，因此您需要确保 rewardRate 的值在 claimReward() 函数被调用时仍然为非零值。

为了排除以上原因导致的问题，您可以尝试进行以下操作：

确保 claimed 变量并没有在 confirmReward() 函数内部被修改，或者在第二次调用 claimReward() 函数时，确保 msg.sender 不是合约所有者。
确保 rewardRate 的值在第二次调用 claimReward() 函数时仍然为非零值，或者在验证 rewardRate 值为非零时，增加一些额外的条件，例如检查 rewardRate 是否大于某个阈值等等。

希望以上建议能够帮助您解决问题。如果仍然无法解决，请提供更多的信息和代码细节，以便更好地帮助您解决问题。

如果以上回答对您有所帮助，点击一下采纳该答案～谢谢


可能是由于没有到byzantium block因此outofdate，

解决方法：

genesis.json

config中加

也有可能是 这种问题的，基本上是除数为0造成的，对除数做一下判断，基本上就解决问题了