AD
MOV：给DeFi装上发动机和安全气囊
MOV通过基于跨连的多资产抵押品、将治理权与分红权剥离、利用多级清算和系统风险控制，建立了一套完整的现代链上金融体系，来保证系统的安全性和稳定性，
密码学署名是区块链的关键手艺之一，可以在不暴露私钥的前提下证实地点的一切权。该手艺重要用来签订生意业务（固然也可以用来签订其他恣意音讯）。本文会讲解数字署名手艺在以太坊协定中的用法。
免责声明：密码学很难。请不要将本文的任何内容作为参考，来完成您自身的密码学函数。虽然我们已举行了普遍的研讨，然则文本所供应的信息大概仍有不正确的处所。本文仅用作教诲用途。
当我们议论密码学中的署名时，我们实际上是在议论一切权、有用性和完全性证实。举例来讲，这些署名可以用来：
证实你具有地点的私钥（即认证功用）； 确保信息（比方，邮件）没有被改动； 考证你下载的 MyCrypto 版本是正当的。密码学署名是基于数学公式的。我们具有一个输入音讯、一个私钥和一个（一般情况下是隐秘的）随机数，就可以获得一串数字作为输出值，也就是署名。运用另一个数学公式可以举行反向盘算，在不知道私钥和随机数的情况下举行考证（译者注：即考证该署名是不是出自跟某个公钥对应的私钥）。这类算法有许多，如 RSA 和 AES，然则以太坊（和比特币）采纳的都是椭圆曲线数字署名算法（ECDSA）。请注意，ECDSA 只是署名算法。与 RSA 和 AES 差别，这类算法不能用于加密。
- 椭圆曲线的例子之一。以太坊采纳的是 SECP256k1 曲线。 -
经由历程椭圆曲线点乘算法（elliptic curve point manipulation），我们可以运用私钥盘算出一个不可逆向盘算的值（译者注：即 “公钥”，公钥没法逆向盘算出私钥）。如许一来，我们就可以建立出平安且不可改动的署名。可以生成不可逆向盘算的值的函数叫做 “陷门函数（trapdoor function）”：
陷门函数指的是在一个方向上易于盘算，然则在缺乏特别信息（即，陷门）的情况下很难反向盘算的函数。
运用 ECDSA 署名并考证ECDSA 署名由两个数字（整数）构成：r 和 s。以太坊还引入了分外的变量 v（恢复标识符）。署名可以示意成 {r, s, v}。
在建立署名时，你要先准备好一条待签订的音讯，和用来签订该音讯的私钥（dₐ）。简化后的署名流程以下：
看待签订音讯举行哈希盘算，获得哈希值（e）。 生成一个平安的随机数 k。 将 k 乘以椭圆曲线的常量 G，来盘算椭圆曲线上的点（x₁, y₁）。 盘算 r = x₁ mod n。假如 r 即是 0，请返回步骤 2 。 盘算 s = k⁻¹(e + rdₐ) mod n。假如 s 即是 0，请返回步骤 2。在以太坊上，一般运用 Keccak256("\x19Ethereum Signed Message:\n32" + Keccak256(message))来盘算哈希值。如许可以确保该署名不能在以太坊以外运用。
由于 k 是随机值，我们每次获得的署名都不一样。假如 k 的随机水平不够高，或许随机值被走漏，就有大概运用两个差别的署名盘算出私钥【“fault attack”】。然则，假如你在 MyCrypto 内签订统一条音讯，每次获得的输出值都雷同，那末怎样确保其平安性？这些肯定性署名均采纳 RFC 6979 范例。该范例形貌了怎样基于私钥和音讯（或哈希值）来生成平安的 k 值。
{r, s, v} 署名可以构成一个长达 65 字节的序列：r 有 32 个字节，s 有 32 个字节，v 有一个字节。假如我们将该署名编码成一个十六进制的字符串，我们末了会获得一个 130 个字符长的字符串。大多数钱包和界面都邑运用这个字符串。以 MyCrypto 为例，一个完全的署名以下图所示：
{在 MyCrypto 的 “考证音讯（Verify Message）” 一页中，我们可以运用该署名，并看到该音讯是由 0x76e01859d6cf4a8637350bdb81e3cef71e29b7c2 签订的。
- MyCrypto 上的署名考证经由历程。点击此处，即可体验。 -
你大概会问：为何要将 address、msg 和 version 等别的信息也包括在内？不能只考证署名自身吗？好吧，不能。假如不保存别的信息，就好像签了一个合同，然后删除了合同里的一切信息，只留下当事人的署名。差别于生意业务署名（我们以后会作更深切诠释），音讯署名就只是署名罢了（译者注：因而只要署名是没法考证的）。
为了考证音讯，我们须要控制原始音讯、运用私钥签订音讯的地点，以及 {r, s, v} 署名自身。版本号就是 MyCrypto 运用的某个版本号。旧版本的 MyCrypto 一般会加上音讯的当前日期和时候，盘算其哈希值，然后根据上述步骤签订该音讯。厥后又举行了变动，以符合 JSON-RPC 要领personal_sign 要领，因而须要指明版本号（“2”）。
简化后的公钥恢复流程以下：
盘算音讯的哈希值（e）。 盘算椭圆曲线上的点 R = (x₁, y₁)，个中 x₁ 是 r（v = 27），或 r + n（v = 28）。 盘算 u₁ = -zr⁻¹ mod n 和 u₂ = sr⁻¹ mod n。 盘算点 Qₐ = (xₐ, yₐ) = u₁ × G + u₂ × R。Qₐ 是地点用来署名的私钥所对应的公钥。我们可以经由历程公钥盘算出一个地点，并搜检该地点是不是与已供应地点符合。假如符合，则署名有用。
恢复标识符（“v”）v 是署名的末了一个字节，而且不是 27 (0x1b) 就是 28 (0x1c)。恢复标识符异常重要，由于我们运用的是椭圆曲线算法，仅凭r 和 s 可盘算出曲线上的多个点，因而会恢复出两个差别的公钥（及其对应地点）。v 会通知我们应当运用这些点中的哪个。
在大多数完成中，v 在内部只是 0 或 1，而 27 是在签订比特币音讯时加上的恣意数。以太坊也接受了这一点。
从 EIP-155 入手下手，我们还运用链 ID 来盘算 v 值。这可以防备跨链重放进击：以太坊上签订的生意业务没法在以太坊典范上运用，反之亦然。现在，恢复标识符只用来签订生意业务而非音讯。
签订生意业务现在为止，我们重要议论了针对音讯的署名。就像音讯一样，生意业务在发送前也须要署名。假如你运用 Ledger 和 Trezor 之类的硬件钱包，署名历程会在硬件内部发作。假如运用私钥（或 keysotre 文件、助记词），可以直接在 MyCrypto 上完成署名。签订生意业务所运用的要领与签订音讯异常类似，只不过生意业务的编码体式格局略有差别。
要签订的生意业务先用 RLP 编码体式格局编码，包括了一切生意业务参数（nonce、gas price、gas limit、to、value、data）和署名（v, r, s）。签过名的生意业务以下所示：
0xf86c0a8502540be400825208944bbeeb066ed09b7aed07bf39eee0460dfa261520880de0b6b3a7640000801ca0f3ae52c1ef3300f44df0bcfd1341c232ed6134672b16e35699ae3f5fe2493379a023d23d2955a239dd6f61c4e8b2678d174356ff424eac53da53e17706c43ef871假如我们在 MyCrypto 的已署名生意业务播送页面上输入该生意业务，我们就会看到一切生意业务参数：
- MyCrypto 的已署名生意业务播送页面上的生意业务参数概览 -
签过名的生意业务的第一组字节包括 RLP 编码后的生意业务参数，末了一组字节包括署名 {r, s, v}。我们可以经由历程以下体式格局对署名生意业务举行编码：
生意业务参数：RLP(nonce, gasPrice, gasLimit, to, value, data, chainId, 0, 0)。 运用 Keccak256 算法来盘算经由 RLP 编码的未签订生意业务的哈希值。 根据上文报告的步骤，经由历程 ECDSA 算法，运用私钥签订哈希值。 对已署名的生意业务举行编码：RLP(nonce, gasPrice, gasLimit, to, value, data, v, r, s)。将经由 RLP 编码的生意业务数据解码后，我们又可以获得原始生意业务参数和署名。
请注意，链 ID 是被编码到署名的 v 参数中的，因而我们不会将链 ID 自身包括在终究的署名生意业务数据中。我们也不会供应任何发送方地点，由于地点可以经由历程署名恢复。这就是以太坊收集内部用来考证生意业务的体式格局。
署名音讯的范例化关于怎样为署名音讯定义范例构造，人们提出了许多种发起。现在为止，还没有一个发起终究肯定下来。最初由 Geth 完成的 personal_sign 花样依然是最常见的。尽管如此，有一些发起异常风趣。
我先来简朴引见下现在建立署名所采纳的体式格局：
"\x19Ethereum Signed Message:\n" + length(message) + message音讯一般会预先举行哈希盘算，因而长度会牢固在 32 个字节：
"\x19Ethereum Signed Message:\n32" + Keccak256(message)完全的音讯（包括前缀）会再阅历一次哈希盘算，然后用私钥对哈希值署名。这类体式格局适用于一切权证实，然则在别的情况下大概会出现问题。比方，假如用户 A 签订了一个音讯并将其发送给合约 x，用户 B 可以复制这个已签订音讯并发送给合约 Y。这就叫重放进击。有一些提案旨在处理这一问题，如 EIP 191 和 EIP 721。
EIP 191：署名数据范例EIP 191 是一个很简朴的提案：它定义了版本号和版本专有数据。花样以下所示：
0x19 1 byte version version specific data data to sign望文生义，版本专有数据（version specific data）取决于我们所运用的版本。现在，EIP 191 有三个版本：
0x00：带有 “目的考证者（intended validator）” 的数据。假如是合约，可所以合约地点。 0x01：构造化数据，如 EIP-712 中定义的那样。关于这点，以后会给出细致诠释。 0x45：通例的签过名的音讯，如 personal_sign 的当前行动。假如我们指定目的考证者（如，合约地点），该合约可以运用自身的地点来从新盘算哈希值。将已签订音讯提交到差别的合约实例是行不通的，由于后者没法考证署名。
由于 0x19 已被选为牢固的字节前缀，署名音讯没法成为经由 RLP 编码的署名生意业务，由于后者永久不会以 0x19 开头。
EIP 712：基于以太坊的范例化构造化数据哈希和署名请不要将 EIP 712 与非同质化代币范例 ERC 721 搞混了。EIP 712 是一个关于 “范例化” 已签订数据的提案。经由历程人类可读的体式格局将数据显现出来，如许可以下降数据的考证难度。
- 经由历程 MetaMask 签订音讯。左侧是旧版已签订音讯界面（运用的是 personal_sign，右侧是新版界面（运用的是 EIP-712）。 -
EIP-712 定义了一种新的要领来替代 personal_sign：eth_signTypedData（最新版用的是 eth_signTypedData_v4）。假如运用这类要领，我们必需指定一切属性（比方，to、amount 和 nonce）及其各自的范例（如，address、uint256 和 uint256），另有该运用的一些基础信息，称为域（domain）。
域包括运用称号、版本、链 ID、你正在交互的合约和盐值（salt）等信息。合约应当考证这些信息，从而确保统一个署名不能在差别的运用上运用。如许可以处理上文提到的重放进击问题。
上图所示音讯的详细定义以下：
{-泉源-
如你所见，这个音讯在 MetaMask 上是可见的，我们可以确认我们正在签订的音讯就是我们想要执行的。EIP 712 执行 EIP 191，因而数据将以 0x1901 开头：0x19 是前缀，0x01 是版本字节，示意这是一个 EIP 712 署名。
经由历程 Solidity，我们可认为 Transaction 范例定义一个 struct，并编写一个函数来对生意业务举行哈希盘算：
struct Transaction {上述生意业务的数据以下所示：
0x1901fb502c9363785a728bf2d9a150ff634e6c6eda4a88196262e490b191d5067cceee82daae26b730caeb3f79c5c62cd998926589b40140538f456915af319370899015d824eda913cd3bfc2991811b955516332ff2ef14fe0da1b3bc4c0f424929上述数据由 EIP-191 字节、哈希域分隔符、哈希后的 Transaction 范例和 Transaction 输入构成。该数据会再经由一次哈希盘算，并举行签订。然后，我们可以运用 ecrecover 来考证智能合约中的署名：
function verify (address signer, Transaction calldata transaction, bytes32 r, bytes32 s, uint8 v) public returns (bool) {鄙人一节中，我们将细致诠释 ecrecover。假如你想找一个简朴的 JavaScript 或 TypeScript 代码库来来完成 EIP 712，请检察这个库：
https://github.com/Mrtenz/eip-712
假如你想细致相识怎样在智能合约中完成 EIP 712，我发起你浏览 MetaMask 的这篇文章。遗憾的是，EIP 712 范例现在照样草案，还没有获得许多运用的支撑。现在，Ledger 和 Trezor 都还没支撑 EIP 712，大概会障碍该范例的普遍采纳。不过，Ledger 示意他们行将宣布的更新版会支撑 EIP 712。
经由历程智能合约来考证署名音讯署名更风趣的处所在于，我们可以运用智能合约来考证 ECDSA 署名。Solidity 有一个内置函数叫做 ecrecover（这实际上是地点 0x1 上的预编译合约），可以恢复用来签订音讯的私钥的地点。一个（异常）基础的合约完成以下所示：
// SPDX-License-Identifier: MIT该合约仅用于考证署名，自身没有任何用途，由于署名考证也可以在没有智能合约的情况下完成。
这类体式格局的用途在于，用户可以经由历程免信托体式格局向智能合约发送某些指令，而无需发送生意业务。比方，用户可以签订一条音讯：“请从我的地点向该地点发送 1 个以太币。” 智能合约可以运用 EIP-712 和/或 EIP-1077 范例来考证署名者并执行该指令。智能合约中的署名考证可用于以下运用：
多签合约（如 Gnosis Safe）； 去中间化生意业务所； 元生意业务和 gas 中继者（如 Gas Station Network）。然则，假如你想经由历程正在运用的智能合约钱包签订音讯怎么办？我们明显不能让钱包智能合约接见私钥对吧。ERC 1271 发起了一个范例，可以让智能合约考证别的智能合约的署名。其范例异常简朴：
pragma solidity ^0.7.0;合约必需完成 isValidSignature 函数，该函数可以像上述合约那样运转恣意函数。假如署名确实是与合约对应的，则函数返回 MAGICVALUE。如许一来，只如果完成了 ERC 1271 的合约，任何合约都可以考证其署名。从内部来讲，完成 ERC 1271 的合约可以让多名用户签订统一个音讯（比方，在多签合约的情况下），并将哈希值存储在内部。然后，该合约可以考证供应给 isValidSignature 函数的哈希值是不是在内部签订，且署名是不是对合约一切者之一有用。
关于区块链和去中间化来讲，署名异常重要。署名不仅可以用来发送生意业务，还可以用来与去中间化生意业务所、多签合约和别的智能合约举行交互。现在还没有明白的音讯署名范例，进一步采纳 EIP 712 范例有助于生态系统改良用户体验，并为音讯署名制订范例。
参考文献和相干文章 Ethereum: A Secure Decentralised Genralised Transaction Ledger (Yellowpaper) EIP-155: Simple replay attack protection EIP-191: Signed Data Standard EIP-712: Ethereum typed structured data hashing and signing ERC-1271: Standard Signature Validation Method for Contracts RFC6979: Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)（完）
原文链接: https://medium.com/mycrypto/the-magic-of-digital-signatures-on-ethereum-98fe184dc9c7
作者: Maarten Zuidhoorn
翻译 校正: 闵敏 阿剑
加入新手交流群：每天早盘分析、币种行情分析
添加助理微信，一对一专业指导：chengqing930520
上一篇：MOV：给DeFi装上发动机和安全气囊
加入新手交流群：每天早盘分析、币种行情分析，添加助理微信
一对一专业指导：chengqing930520
最新资讯
