為什麼 ecrecover() 採用簽名參數 (v,r,s) 而不是完整簽名？
考慮到這些可以在函式本身內部輕鬆計算，是否有任何理由
ecrecover()採用 (v,r, ) 簽名參數而不是完整簽名？s我之所以這樣問，是因為開發人員通常需要在每次需要使用時從完整簽名中計算這些參數
ecrecover()，這似乎是一個不必要的重複過程，如果ecrecover()採用完整簽名代替，本可以得到緩解。
簽名通常用於
v儲存簽名和r,s來儲存散列數據。我同意使用 ecrecover 會增加額外的複雜性，並且通過添加approval/transferFrom 我們可以獲得一些匿名性，因為我們允許第3 方從我們的餘額中提取代幣以收取費用，通常以WETH 或類似的形式。人們說如果我們使用
signatures我們就變成anonymous了，這完全是錯誤的，因為乙太坊上沒有真正隱藏任何東西。有關該主題的更多資訊，您可以從這裡找到：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 它應該很容易更新到 Solidity 0.5，如果您對此有任何疑問，請告訴我。
v, r, s 是乙太坊交易中的參數。乙太坊交易是這些值的序列化。乙太坊庫將並且應該具有序列化和反序列化交易的方法，因此找到 v、r、s 值應該不比在簽名的乙太坊交易上呼叫反序列化/解碼函式更難，您不必自己計算這些值。
您應該注意，我們所說的簽名實際上是 256 位，是 r 和 s 欄位的組合。v 欄位僅包含有關簽名的一位資訊，並且可以派生與簽名關聯的公共資訊——因此您無需將其包含在已簽名的交易中。了解乙太坊簽名