微支付通道合约¶
译者注：本文其实和很多 线下扩容 的思路很类似，有兴趣可延伸阅读。
来看看如何在以太坊上实现一个支付通道。 通过使用密码签名技术可以在相同的参与者之间 安全的、重复的、免手续费 的转移以太币。学习这个示例子，我们需要先了解签名和验证签名以及如何建立支付通道。
创建及验证签名¶
想象一下 Alice 想发送一些以太币给 Bob, 即 Alice 发送者，而 Bob 是接收者。
Alice仅仅需要发送一条在链下密码学签名后的信息给Bob（比如通过消息），编写检查也是类似的。
Alice 和 Bob 用签名去授权交易，这可以通过以太坊智能合约来实现。Alice 将创建一个简单的智能合约来发送他的以太币，发送的函数不再是她在发起交易的时候执行，她将让 Bob 来执行并支付交易费。
合约工作有以下几步：
Alice 部署
ReceiverPays合约, 并附上足够的以太来负担支付通道的付款。Alice 通过自己的私钥签名来授权一个支付。
Alice 发送签名信息给Bob，这个信息是不需要保密的（稍后解释），用什么发送也无关紧要。
Bob 通过把签名信息提交给合约来索取这笔支付， 合约将验证信息的真实性并发送金额。
创建签名¶
Alice 不需要和以太坊网络进行交互就可以完成签名，这个过程是完全离线的。 在这个指引里, 我们将通过使用 web3.js and MetaMask 在浏览器里完成签名, 方法在 EIP-762 有描述。
/// 先计算一个hash
var hash = web3.utils.sha3("message to sign");
web3.eth.personal.sign(hash, web3.eth.defaultAccount, function () { console.log("Signed"); });
备注
web3.eth.personal.sign 会关注待签名信息的长度， 因为我们先计算了hash，这个信息将总是32字节，因此长度前缀也总是相同。
哪些内容需要签名¶
为了合约能实现支付功能，签名消息必须包括：
收款人地址
发送金额
能够保护重放攻击的信息
所谓重放攻击是指一个被授权的支付消息被重复使用，为了避免重放攻击，我们引入一个 nonce (以太坊链上交易也是使用这个方式来防止重放攻击), 它表示一个账号已经发送交易的次数。智能合约将检查 nonce 是否使用过。
另外一种重放攻击可能发生的情形是这样的：所有者部署 ReceiverPays 合约之后，进行了一些支付，然后其销毁了合约， 随后又再次部署 ReceiverPays 合约， 这时新的合约无法知道先前部署合约的 nonce，所以攻击者可以再次利用先前的支付信息。
Alice 可以通过在签名信息中加入合约地址来阻止这个攻击。
下面的 claimPayment() 前两行，就是用来防止重放攻击。
打包参数¶
我们已经知道哪些信息需要包含到签名消息里，我们需要把这些信息合并在一起，计算 hash 然后 签名。很简单，先拼接数据，然后 ethereumjs-abi 库提供了 soliditySHA3 that mimics the behaviour of
函数类似于 Solidity 的 keccak256 函数应用在 abi.encodePacked 的输出结果上，下面是JavaScript 为 ReceiverPays 实现签名的代码：
// recipient 表示向谁付款.
// amount, 单位 wei, 指定发送金额数量.
// nonce 保护重放攻击
// contractAddress 保护跨合约重放攻击
function signPayment(recipient, amount, nonce, contractAddress, callback) {
var hash = "0x" + abi.soliditySHA3(
["address", "uint256", "uint256", "address"],
[recipient, amount, nonce, contractAddress]
).toString("hex");
web3.eth.personal.sign(hash, web3.eth.defaultAccount, callback);
}
在Solidity中还原消息签名者¶
通常, ECDSA（椭圆曲线数字签名算法） 包含两个参数, r and s. 在以太坊中签名包含第三个参数 v, 它可以用于验证哪一个账号的私钥签署了这个消息。 Solidity 提供了一个内建函数 ecrecover 它接受 r, s and v 作为参数并且返回签名这的地址。
提取签名参数¶
使用 web3.js 签名的数据，r, s 和 v 是连接在一起的，第一步是把各部分分离出来。我们可以在客户端这这个操作，但是在合约上实现就仅仅需要一个参数而不是三个参数， 分离一个大的直接数组到各个部分工作量比较大，所以我们在 splitSignature 函数（在本节的结尾可以看到这个函数）里使用内联汇编来完成这个工作。
计算信息的Hash¶
合约需要知道哪些参数被签名了，以便它可以从参数中重建信息用来验证签名。在函数``claimPayment`` 中的 prefixed and recoverSigner 就是用来做这个事情。
ReceiverPays 完整合约代码¶
pragma solidity >=0.5.0 <0.7.0;
contract ReceiverPays {
address owner = msg.sender;
mapping(uint256 => bool) usedNonces;
constructor() public payable {}
// 收款方认领付款
function claimPayment(uint256 amount, uint256 nonce, bytes memory signature) public {
require(!usedNonces[nonce]);
usedNonces[nonce] = true;
// 重建在客户端签名的信息
bytes32 message = prefixed(keccak256(abi.encodePacked(msg.sender, amount, nonce, this)));
require(recoverSigner(message, signature) == owner);
msg.sender.transfer(amount);
}
/// destroy the contract and reclaim the leftover funds.
function kill() public {
require(msg.sender == owner);
selfdestruct(msg.sender);
}
/// 第三方方法，分离签名信息的 v r s
function splitSignature(bytes memory sig)
internal
pure
returns (uint8 v, bytes32 r, bytes32 s)
{
require(sig.length == 65);
assembly {
// first 32 bytes, after the length prefix.
r := mload(add(sig, 32))
// second 32 bytes.
s := mload(add(sig, 64))
// final byte (first byte of the next 32 bytes).
v := byte(0, mload(add(sig, 96)))
}
return (v, r, s);
}
function recoverSigner(bytes32 message, bytes memory sig)
internal
pure
returns (address)
{
(uint8 v, bytes32 r, bytes32 s) = splitSignature(sig);
return ecrecover(message, v, r, s);
}
/// 加入一个前缀，因为在eth_sign签名的时候会加上。
function prefixed(bytes32 hash) internal pure returns (bytes32) {
return keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", hash));
}
}
编写一个简单的支付通道¶
Alice 现在可以创建一个简单但完整支付通道，支付通道通过加密签名可以重复安全的转移以太币，并且无需付费。
什么是支付通道？¶
支付通道允许在无需发生交易的情况下多次转移以太。这意味着可以避免与交易相关的延迟和费用。 我们将探讨两方（Alice和Bob）之间的简单单向支付通道。 它涉及三个步骤：
Alice 附加一些以太创建智能合约，可以称为“打开”了支付通道
Alice会签署一些消息指明给接收者付款金额。 每次付款都会重复此步骤。
Bob“关闭”支付通道，取回以太币，并将剩余部分发送回发送者。
备注
只有步骤1和3需要以太坊交易，步骤2意味着发送者通过离线方法（例如电子消息）将加密签名的消息发送给接收者。 这意味着只需要两个交易就可以支持任意数量（次数）的以太币转账。
Bob 保证会收到资金，因为智能合约托管以太并根据合法的签名消息来执行。 合约还可以强制超时执行，即使收款人拒绝关闭通道，Alice也能保证最终收回资金。 付款通道的参与者可以决定支付通道打开的持续时间。 对于短期交易，例如为网络访问的每一分钟支付一次网费，或者是长期的，例如向员工支付小时工资，支付可能持续数月或数年。
打开支付通道¶
要打开支付通道，Alice 需要部署智能合约，附加要托管的以太币并指定预期的收款人，以及通道存在有效时间。 合约的 SimplePaymentChannel 函数就是来做这个事情，代码在本节末尾。
进行支付¶
Alice 通过向 Bob 发送签名消息来付款。该步骤完全在以太坊网络之外执行。 消息由发送者以加密方式签名，然后直接传输给收款人。
每条消息都包含以下信息：
智能合约的地址，用于防止交叉合约重放攻击。
到目前为止所发送的以太总量。
在一系列转账结束时，付款通道仅需关闭一次。因此，只有一条消息被兑换。 这就是为什么每条消息都指定了以太的累计总量，而不是每次的微支付金额。 收款人自然而然的会选择兑换最新消息，因为这是以太总数最高的消息。 每条信息包含的nonce 将不再需要，因为智能合约仅执行一条信息。
包含合约地址用于防止一个支付通道的消息被用于不同的通道。
以下是修改后的JavaScript代码，用于对上一节中的消息进行加密签名：
function constructPaymentMessage(contractAddress, amount) {
return abi.soliditySHA3(
["address", "uint256"],
[contractAddress, amount]
);
}
function signMessage(message, callback) {
web3.eth.personal.sign(
"0x" + message.toString("hex"),
web3.eth.defaultAccount,
callback
);
}
// contractAddress is used to prevent cross-contract replay attacks.
// amount, in wei, specifies how much Ether should be sent.
function signPayment(contractAddress, amount, callback) {
var message = constructPaymentMessage(contractAddress, amount);
signMessage(message, callback);
}
关闭状态通道¶
当Bob准备好收到他们的资金时，就可以通过调用智能合约上的 关闭 功能来关闭支付通道。
关闭通道会向接收方支付所欠的以太币并销毁合约，剩余的以太币返回Alice。为了关闭通道，Bob需要提供 Alice 签名过的消息。
智能合约必须验证信息是否包含发送者的有效签名。执行此验证的过程与上面收款人使用的方法相同。
Solidity函数 isValidSignature 和 recoverSigner 就是完成这个工作。
只有付款通道收款人可以调用 close 函数，其会选择最近的付款消息，因为该消息有最高的付款总额。
如果允许发送者调用此函数，他们可以提供较低金额的消息，来欺骗收款人。
函数会验证签名的消息是否与给定的参数匹配，如果匹配，收款人将收到应得的部分，余下的部分通过 selfdestruct 返还给发送者。
可以在完整的合约代码中看到 close 函数。
通道有效期¶
Bob可以随时关闭支付通道，但如果他没有这样做，Alice 需要一种方法来收回他们托管的资金。
一个方法是在合约部署时设置 到期时间 ，一旦达到那个时间，Alice 就可以调用 claimTimeout 收回他们的资金。 可以在完整的合约代码中查看 claimTimeout 函数。
调用此功能后，Bob无法再接收任何以太币，因此，Bob必须在到期前关闭频道。
完整合约代码¶
pragma solidity >=0.4.24 <0.7.0;
contract SimplePaymentChannel {
address payable public sender; // The account sending payments.
address payable public recipient; // The account receiving the payments.
uint256 public expiration; // Timeout in case the recipient never closes.
constructor (address payable _recipient, uint256 duration)
public
payable
{
sender = msg.sender;
recipient = _recipient;
expiration = now + duration;
}
function isValidSignature(uint256 amount, bytes memory signature)
internal
view
returns (bool)
{
bytes32 message = prefixed(keccak256(abi.encodePacked(this, amount)));
// check that the signature is from the payment sender
return recoverSigner(message, signature) == sender;
}
/// the recipient can close the channel at any time by presenting a
/// signed amount from the sender. the recipient will be sent that amount,
/// and the remainder will go back to the sender
function close(uint256 amount, bytes memory signature) public {
require(msg.sender == recipient);
require(isValidSignature(amount, signature));
recipient.transfer(amount);
selfdestruct(sender);
}
/// the sender can extend the expiration at any time
function extend(uint256 newExpiration) public {
require(msg.sender == sender);
require(newExpiration > expiration);
expiration = newExpiration;
}
/// 如果过期过期时间已到，而收款人没有关闭通道，可执行此函数，销毁合约并返还余额
function claimTimeout() public {
require(now >= expiration);
selfdestruct(sender);
}
/// All functions below this are just taken from the chapter
/// 'creating and verifying signatures' chapter.
function splitSignature(bytes memory sig)
internal
pure
returns (uint8 v, bytes32 r, bytes32 s)
{
require(sig.length == 65);
assembly {
// first 32 bytes, after the length prefix
r := mload(add(sig, 32))
// second 32 bytes
s := mload(add(sig, 64))
// final byte (first byte of the next 32 bytes)
v := byte(0, mload(add(sig, 96)))
}
return (v, r, s);
}
function recoverSigner(bytes32 message, bytes memory sig)
internal
pure
returns (address)
{
(uint8 v, bytes32 r, bytes32 s) = splitSignature(sig);
return ecrecover(message, v, r, s);
}
/// builds a prefixed hash to mimic the behavior of eth_sign.
function prefixed(bytes32 hash) internal pure returns (bytes32) {
return keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", hash));
}
}
备注
函数 splitSignature 没有做足够的安全检查，完整的产品里应该使用严格测试的库，如：openzepplin 的版本 。
验证支付¶
与上一节不同，付款通道中的消息不是马上赎回。 收款人会跟踪最新消息及在关闭付款通道时兑换它。 这意味着接收者对每条消息进行验证就至关重要。 否则，无法保证收款人能够最终获得付款。
收款人使用以下过程验证每条消息：
验证信息中的合约地址是否与付款通道匹配。
验证新金额是否为预期金额。
确认新金额不超过托管的以太币总额。
验证签名是否有效并来自通道的付款方。
我们使用 ethereumjs-util 库来编写验证过程，这里使用 JavaScript ，当然实现的方式有很多。下面的代码借鉴了 上面的 constructMessage 函数:
// this mimics the prefixing behavior of the eth_sign JSON-RPC method.
function prefixed(hash) {
return ethereumjs.ABI.soliditySHA3(
["string", "bytes32"],
["\x19Ethereum Signed Message:\n32", hash]
);
}
function recoverSigner(message, signature) {
var split = ethereumjs.Util.fromRpcSig(signature);
var publicKey = ethereumjs.Util.ecrecover(message, split.v, split.r, split.s);
var signer = ethereumjs.Util.pubToAddress(publicKey).toString("hex");
return signer;
}
function isValidSignature(contractAddress, amount, signature, expectedSigner) {
var message = prefixed(constructPaymentMessage(contractAddress, amount));
var signer = recoverSigner(message, signature);
return signer.toLowerCase() ==
ethereumjs.Util.stripHexPrefix(expectedSigner).toLowerCase();
}