Solidity by Example — Solidity 0.8.21 documentation
看solidity的官方例子， 里面有一个Micropayment Channel(小额支付通道，原理跟现实中的支票一样，支付人把钱预存银行，自己写支票， 收款人拿支票去取钱。 这里的银行是以太坊合约而已)， 里面涉及到ETH的 replay attach 重放攻击， 用每个账户下面的nonce去规避。 突然想到了，btc的utxo双花。
ETH的 replay attack 重放攻击 和 比特币的双花， 有什么区别呢 ？我的理解是： 本质上说的一个意思，一笔交易，被重复执行. 由于eth使用的是账户模型，btc使用的是utxo模型，在账户模型里面，一个账户下面发起的每笔交易需要唯一的标识, 系统会去判断这个标识有没有被使用过，即nonce. Utox模型中， 说的是未消费的utxo，是否被重复去消费，一旦有这种情况出现， 可能就是节点间块同步出现异常， 链分叉问题，问题较为严重。 eth里面的replay attack攻击，不涉及到区块的分叉问题。
------------- ETH合约的开源安全库 ---------------------------------openzepplin’s
一般写合约，优先使用 openzepplin 库里面提供的函数.
官方经典例子，小额支付通道， 闪电网络。
What is a Payment Channel? 什么是支付通道.
Payment channels allow participants to make repeated transfers of Ether without using transactions. This means that you can avoid the delays and fees associated with transactions. We are going to explore a simple unidirectional payment channel between two parties (Alice and Bob). It involves three steps:
支付通道允许参与方在不需要产生链上交易的情况下进行重复的转账。 意味着你可以规避链上交易的延迟和手续费环节。下面介绍一个简单的在Alice和Bob之间单向的支付通道原理。涉及到三个步骤：
1. Alice funds a smart contract with Ether. This “opens” the payment channel.
Alice用eth给合约充币, 并打开支付通道.
2. Alice signs messages that specify how much of that Ether is owed to the recipient. This step is repeated for each payment.
Alice 签署发送给Bob的eth的消息， 可以多次重复.
3. Bob “closes” the payment channel, withdrawing his portion of the Ether and sending the remainder back to the sender.
Bob关闭支付通道，从合约中赎回属于自己的eth, 并且把剩余的eth返回给Alice.
Only steps 1 and 3 require Ethereum transactions, step 2 means that the sender transmits a cryptographically signed message to the recipient via off chain methods (e.g. email). This means only two transactions are required to support any number of transfers.
只有步骤1和步骤3需要eth的链上交易， 步骤2, 发送者通过email等传递支付签名消息给接收者。 以为者两个链上交易可以支持任意数量的交易达成。
Bob is guaranteed to receive his funds because the smart contract escrows the Ether and honours a valid signed message. The smart contract also enforces a timeout, so Alice is guaranteed to eventually recover her funds even if the recipient refuses to close the channel. It is up to the participants in a payment channel to decide how long to keep it open.
由于合约暂时保管了eth资金和验证有效的签名支票， Bob是可以被保证能接收到他应得的资金的。 合约也有一个强制的超时时间，以便及时接收者拒绝关闭支付通道，Alice也可以被保证最终收到退款。支付通道的开放时间，取决于参与者之间的协商.
Opening the Payment Channel 打开支付通道
To open the payment channel, Alice deploys the smart contract, attaching the Ether to be escrowed and specifying the intended recipient and a maximum duration for the channel to exist.
为了打开支付通道，Alice部署合约，附上需要保管的eth和指定接收者和最大的通道打开时间。
Making Payments 支付
Each message includes the following information:
The smart contract’s address, used to prevent cross-contract replay attacks. （合约地址，用于访问跨合约重放攻击）
The total amount of Ether that is owed to the recipient so far. （目前为止，接收者的eth的总额度）
A payment channel is closed just once, at the end of a series of transfers. Because of this, only one of the messages sent is redeemed. This is why each message specifies a cumulative total amount of Ether owed, rather than the amount of the individual micropayment. The recipient will naturally choose to redeem the most recent message because that is the one with the highest total. The nonce per-message is not needed anymore, because the smart contract only honours a single message. The address of the smart contract is still used to prevent a message intended for one payment channel from being used for a different channel. 一个支付通道只能在一系列的线下转账后关闭一次。因此，这些线下交易集合中只有一个交易是被提交到链上进行赎回操作的。这也是为什么每个消息指定的是接收者累计的eth总额度，而不是单独的小支付额度。接收者肯定会选择最新的那条签名交易记录，因为那条记录里面的额度最高。 如此，每个消息的nonce也不在需要了，因为合约只验证赎回一条交易。 为防止跨合约重放攻击，合约地址还是需要参与签名的。
Closing the Payment Channel （关闭支付通道）
When Bob is ready to receive his funds, it is time to close the payment channel by calling a close function on the smart contract. Closing the channel pays the recipient the Ether they are owed and destroys the contract, sending any remaining Ether back to Alice. To close the channel, Bob needs to provide a message signed by Alice.
当Bob准备好接收他的资金，就到了该调用智能合约close函数去关闭掉支付通道了。关闭通道的同时，支付接收者该得的资金并且销毁掉合约， 把剩余的eth返还给Alice. 为了关闭通道，Bob需要提供Alice签名的交易消息。
Only the payment channel recipient can call the close function, who naturally passes the most recent payment message because that message carries the highest total owed. If the sender were allowed to call this function, they could provide a message with a lower amount and cheat the recipient out of what they are owed. 只有支付通道的接收者有权限调用close函数，它会自然的用最高额度的签名消息去close支付通道。如果支付通道的发送者（支付者）也允许调用close方法，它很可能用一笔小额的支付消息去结束通道，欺骗接收人。
Verifying Payments
Unlike in the previous section, messages in a payment channel aren’t redeemed right away. The recipient keeps track of the latest message and redeems it when it’s time to close the payment channel. This means it’s critical that the recipient perform their own verification of each message. Otherwise there is no guarantee that the recipient will be able to get paid in the end.
不想上一个话题, 在支付通道里面的消息不会马上上链兑现资产。接收者追踪最新一条消息，到时间后，上链进行兑现资产。 这将意味着接收者去验证每一条链下签名消息非常关键，否则不能保证最后一条消息一定可以兑现成功。
The recipient should verify each message using the following process:
Verify that the contract address in the message matches the payment channel. （验证合约地址）
Verify that the new total is the expected amount. （验证整体金额数量是否和预期相符）
Verify that the new total does not exceed the amount of Ether escrowed.（验证最新总金额不能超过托管总额）
Verify that the signature is valid and comes from the payment channel sender.（验证签名是有效的，确实从支付通道的发送者所签署）
BTC的闪电网络：
BTC的闪电网络跟ETH的闪电网络大致思路一致， 只是BTC没有智能合约，但BTC有多签地址，Alice和Bob把各自资金委托给多签名地址即可，剩下的就是链下进行转账金额统计，最终多签完成资金从多签地址取回的操作.