Solidity by Example — Solidity 0.8.21 documentation
Look at the official example of solidity, there is a Micropayment Channel (micropayment channel, the principle is the same as the check in reality, the payer deposits the money in the bank, writes the check himself, and the payee takes the check to withdraw the money. The bank here is ether Fang contract only), which involves ETH's replay attach replay attack, use the nonce under each account to avoid. Suddenly thought of, btc's utxo double spend.
What is the difference between ETH's replay attack and Bitcoin's double spend? My understanding is: In essence, it means that a transaction is executed repeatedly. Since eth uses the account model and btc uses the utxo model, in the account model, each transaction initiated under an account needs to be unique The system will judge whether this logo has been used, that is, the nonce. In the Utox model, it refers to whether the unconsumed utxo has been consumed repeatedly. Once this happens, it may be that the block synchronization between nodes occurs Abnormal, the chain fork problem, the problem is more serious. The replay attack attack in eth does not involve the fork of the block.
------------- Open source security library for ETH contracts ----------------------------- --openzepplin's
generally write contracts, and use the functions provided in the openzepplin library first.
Official classic example, micropayment channel, Lightning Network.
What is a Payment Channel? 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:
Payment channels allow participants to make repeated transfers without requiring on-chain transactions. It means that you can avoid the delay and handling fees of transactions on the chain. The following introduces a simple one-way payment channel principle between Alice and Bob. Three steps are involved:
1. Alice funds a smart contract with Ether. This “opens” the payment channel.
Alice recharges the contract with eth and opens a payment channel.
2. Alice signs messages that specify how much of that Ether is owed to the recipient. This step is repeated for each payment.
Alice signs a message to Bob's eth, which can be repeated multiple times.
3. Bob “closes” the payment channel, withdrawing his portion of the Ether and sending the remainder back to the sender.
Bob closes the payment channel, redeems his own eth from the contract, and returns the remaining eth to 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.
Only steps 1 and 3 require eth on-chain transactions. In step 2, the sender transmits the payment signature message to the receiver through email or the like. In other words, transactions on two chains can support any number of transactions.
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.
Since the contract temporarily holds the eth funds and verifies a valid signed check, Bob can be guaranteed to receive the funds he deserves. The contract also has a mandatory timeout, so that even if the recipient refuses to close the payment channel, Alice can be guaranteed to eventually receive the refund. The opening time of the payment channel depends on the negotiation between the participants.
Opening the Payment Channel 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.
In order to open the payment channel, Alice deploys the contract, attaching the eth that needs to be kept, the designated recipient and the maximum channel opening time.
Making Payments
Each message includes the following information:
The smart contract's address, used to prevent cross-contract replay attacks. (contract address, used to access cross-contract replay attacks)
The total amount of Ether that is owed to the recipient so far. (So far, the total amount of the recipient's 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 honors 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. A payment channel can only be closed once after a series of offline transfers. Therefore, only one transaction in these offline transaction sets is submitted to the chain for redemption. This is why each message specifies the total amount of eth accumulated by the recipient, rather than individual small payment amounts. The receiver will definitely choose the latest signature transaction record, because that record has the highest amount. In this way, the nonce of each message is no longer needed, because the contract only verifies and redeems one transaction. In order to prevent cross-contract replay attacks, the contract address still needs to participate in the signature.
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.
When Bob is ready to receive his funds, it is time to call the smart contract close function to close the payment channel. While closing the channel, pay the receiver the funds and destroy the contract, and return the remaining eth to Alice. In order to close the channel, Bob needs to provide a transaction message signed by 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. Only the recipient of the payment channel has permission to call the close function, and it will naturally close the payment channel with a signed message with the highest amount. If the sender (payer) of the payment channel is also allowed to call the close method, it is likely to end the channel with a small payment message and deceive the receiver.
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.
I don’t want to talk about another topic, the news in the payment channel will not be immediately on the chain to cash out the assets. The receiver tracks the latest message, and when the time is up, it goes to the chain to cash out the assets. This will mean that it is very critical for the receiver to verify each off-chain signed message, otherwise there is no guarantee that the last message will be successfully redeemed.
The recipient should verify each message using the following process:
Verify that the contract address in the message matches the payment channel. (verify the contract address)
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 new total does not exceed the total amount of Ether escrowed.)
Verify that the signature is valid and comes from the payment channel sender. (Verify that the signature is valid and is indeed signed by the sender of the payment channel)
BTC's Lightning Network:
BTC's Lightning Network is roughly the same as ETH's Lightning Network, except that BTC does not have a smart contract, but BTC has a multi-signature address. Alice and Bob can entrust their respective funds to the multi-signature address, and the rest is to count the transfer amount under the chain. , and finally the multi-signature completes the operation of withdrawing funds from the multi-signature address.