为什么ecrecover()采用签名参数(v，r，s)而不是完整签名？

Question

ecrecover()是否有任何理由接受(v、r、s)签名参数而不是完全签名，因为这些参数可以很容易地在函数本身内计算？

我这样问是因为开发人员在每次需要使用ecrecover()时，通常都需要从完整签名中计算这些参数，这似乎是一个不必要的重复过程，如果ecrecover()采用完全签名，这个过程本来可以减轻。

Answer 1

签名通常使用v存储签名，使用r、s存储散列数据。我同意使用ecrecover会增加额外的复杂性，并且通过添加approve/transferFrom，我们可以获得一些匿名性，因为我们允许第三方从我们的余额中提取令牌，通常是在WETH或类似的地方。

人们说，如果我们使用signatures，我们就变成了anonymous，这是完全错误的，因为没有什么东西是真正隐藏在ethereum上的。有关这个主题的更多信息，您可以从这里找到：https://medium.com/swlh/ethereum-aint-hiding-your-secrets-703e89088937

签名更广泛地用于标识使用Metamask的用户。我们让用户对包含随机熵源的东西进行签名，或者已经秘密地使用私钥进行散列，然后提供新签名的作者是谁，并使用ecrecover提供临时会话。

确切的方法可以在这里找到：https://programtheblockchain.com/posts/2018/02/17/signing-and-verifying-messages-in-ethereum/

另外，如果您想要一个更好更详细的签名方法，您可以通过查看DreamTeamToken是如何在这里实现的找到我们的更多信息：https://etherscan.io/address/0x82f4ded9cec9b5750fbff5c2185aee35afc16587#code应该很容易更新到Solity0.5，如果您在这方面有任何困难，请告诉我。

Answer 2

v，r，S是以太交易中的参数。Ethereum事务是这些值的序列化。values库将并且应该有序列化和反序列化事务的方法，因此查找v、r、S值应该不会比在签名的values事务上调用反序列化/解码函数更困难，您不应该自己计算这些值。

您应该注意到，我们所称的签名实际上是256位，是r和S字段的组合。V字段只包含关于签名的一小部分信息，并且可以导出与签名相关的公共信息--这样您就不需要在已签名的事务中包含签名了。理解以太签名