Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to pay in Taifang". The content in the article is simple and clear, and it is easy to learn and understand. please follow the editor's train of thought to study and learn "how to pay in Taifang".

What is the payment channel?

Ethersquare transactions provide a secure way to transfer money, but each transaction needs to be included in a block and mined. This means that the deal will take some time and require some fees to compensate the miners for their work. In particular, the transaction cost makes this kind of micro-payment a reason why it becomes a bit laborious for the use of Ethernet Fong and other blockchains similar to it.

The payment channel allows participants to send Ether repeatedly without using a transaction. This means that the delays associated with the transaction and the resulting costs can be avoided. In this article, we will explore a simple one-way payment channel. This includes three steps:

1. The sender uses Ether to pay for a smart contract. This opens the payment channel.

two。 The sender signs a message indicating how much should be paid to the recipient in the ether. Repeat this step for each payment.

3. The receiver closes the payment channel, collects their portion of the ether, and returns the rest to the sender.

It is important that only steps 1 and 3 require vacant transactions. Step 2 is done through password signing and communication between the two parties (such as e-mail). This means that only two transactions are required to support any number of deliveries.

The recipient is guaranteed to receive their money because the smart contract hosts the ether and acknowledges the valid signed message. Smart contracts are also enforced until the deadline, and the sender has the right to recover the funds, even if the receiver refuses to close the payment channel.

It depends on how long the participants in the payment channel decide to stay open. For short-term interactions, such as Internet cafes that pay per minute for network services, it is sufficient to use a payment channel that lasts only about an hour. For a longer-term payment relationship, such as paying employees hourly wages, the payment channel can last for months or years.

Open the payment channel

In order to open the payment channel, the sender deploys the smart contract, ether will also be hosted, and the latest deadline for the existence of the receiver and the channel will be specified.

Contract SimplePaymentChannel {address public sender; / / The account sending payments. Address public recipient; / / The account receiving the payments. Uint256 public expiration; / / Timeout in case the recipient never closes. Function SimplePaymentChannel (address _ recipient, uint256 duration) public payable {sender = msg.sender; recipient = _ recipient; expiration = now + duration;} payment

The sender pays by sending a message to the receiver. This step is performed completely outside the ethernet network. The message is encrypted and signed by the sender and then sent directly to the receiver.

Each message includes the following information:

The address of the smart contract to prevent cross-contract replay attacks.

The total amount of ether consumed by the recipient so far.

At the end of a series of transfers, the payment channel is closed only once. Because of this, only one message sent will be redeemed. This is why each message specifies the total amount of cumulative Ether consumption rather than the amount of individual micropayments. The recipient will naturally choose to redeem the latest message because it is a message that always has the highest ether.

Note that because the smart contract only maintains a single message, every temporary message is not required. The address of the smart contract is still used to prevent messages for one payment channel from being used in different channels.

You can build and sign the corresponding message in any language that supports encrypted hash and signature operations. The following code is written in JavaScript and uses ethereumjs-abi:

Function constructPaymentMessage (contractAddress, amount) {return ethereumjs.ABI.soliditySHA3 (["address", "uint256"], [contractAddress, amount],);} function signMessage (message, callback) {web3.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);} verify payment

Unlike signatures, messages in the payment channel are not immediately redeemed. The receiver tracks the latest news and redeems it when the payment channel is closed. This means that it is critical for the receiver to validate each message on its own. Otherwise, there is no guarantee that the recipient will eventually be paid.

The receiver shall use the following procedure to validate each message:

1. Verify that the contract address in the message matches the payment channel.

two。 Verify that the new total is the expected amount.

3. Verify that the new total does not exceed the amount of ether.

4. Verify that the signature is valid and comes from the sender of the payment channel.

The first three steps are simple. The final step can be performed in a variety of ways, but if it is done in JavaScript, I recommend the ethereumjs- util library. The following code borrows the constructMessage function from the above signature code:

/ / 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 ();} close the payment channel

When recipients are ready to receive their money, it is time to close the payment channel by calling the close function on the smart contract. Close the channel to the receiver, they get their own ether and destroy the contract, and send the rest of the Ether back to the sender. To close the channel, the receiver needs to share the message signed by the sender.

The smart contract must verify that the message contains a valid signature from the sender. The process for this verification is the same as that used by the receiver. The isValidSignature and recoverSigner functions correspond to the JavaScript code in the previous section. The latter is copy from the ReceiverPays contract in Signing and Verifying Messages in Ethereum.

Function isValidSignature (uint256 amount, bytes signature) internal view returns (bool) {bytes32 message = prefixed (keccak256 (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 signature) public {require (msg.sender = = recipient); require (isValidSignature (amount, signature)); recipient.transfer (amount); selfdestruct (sender);}

The shutdown function can only be called by the receiver of the payment channel, and the receiver naturally delivers the latest payment message because the message has the highest total cost. If the sender is allowed to call this function, they can provide a lower-cost message and deceive the receiver.

Function verifies that the signed message matches the given parameter. If everything is detected, the recipient sends part of their ether, and the sender sends the rest via selfdestruct.

Close the payment channel

The receiver can close the payment channel at any time, but if they do not, the sender needs a way to recover their escrow funds. The expiration time is set when the contract is deployed. Once that time is reached, the sender can call claimTimeout to recover its funds.

/ / If the timeout is reached without the recipient closing the channel, then// the ether is released back to the sender.function claimTimeout () public {require (now > = expiration); selfdestruct (sender);}

After this function is called, the receiver can no longer receive any ether, so it is important for the receiver to close the channel before the arrival period expires.

Summary

Payment channels support secure, out-of-block capital transfers while avoiding transaction costs for each transfer.

Payments are cumulative and only one is redeemed when the channel is closed.

The transfer is guaranteed by escrow funds and password signatures.

Overtime protects the sender's funds from uncooperative recipients.

Complete source code, simplePaymentChannel.sol

Pragma solidity ^ 0.4.20 position contract SimplePaymentChannel {address public sender; / / The account sending payments. Address public recipient; / / The account receiving the payments. Uint256 public expiration; / / Timeout in case the recipient never closes. Function SimplePaymentChannel (address _ recipient, uint256 duration) public payable {sender = msg.sender; recipient = _ recipient; expiration = now + duration;} function isValidSignature (uint256 amount, bytes signature) internal view returns (bool) {bytes32 message = prefixed (keccak256 (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 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;} / / If the timeout is reached without the recipient closing the channel, then / / the ether is released back to the sender. Function claimTimeout () public {require (now > = expiration); selfdestruct (sender);} function splitSignature (bytes sig) internal pure returns (uint8, bytes32, bytes32) {require (sig.length = = 65); bytes32 r; bytes32 s; uint8 v 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 sig) internal pure returns (address) {uint8 v; bytes32 r; bytes32 s; (v, r, 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 ("\ x19Ethereum Signed Message:\ N32", hash)}} Thank you for your reading, the above is the content of "how to achieve ethernet payment". After the study of this article, I believe you have a deeper understanding of how to achieve ethernet payment, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.