PART 3 : PAYMENT CHANNELS - Kalp Shah

Payment channels are among the various off-chain scaling solutions designed to enhance the efficiency and scalability of blockchain networks. By enabling multiple transactions to occur off the main chain, payment channels help avoid network congestion, reduce transaction costs, and significantly increase transaction speed. This approach not only improves the overall performance of blockchain systems but also makes them more practical for everyday use.

PAYMENT CHANNELS

Payment channels are a subclass of state channels that allow parties to make off-blockchain payments to each other. So, participants can transact a multitude of transactions with one another off-chain, which are posted on the main blockchain after closing a channel. Due to this mechanism of off-chaining transactions, much less space is used on the mainnet blockchain, so transactions are much faster and cheaper.

Benefits and Applications

Minimized Transaction Costs: Off-chain transactions help save the user’s transaction costs.
High Transaction Speed: Off-chain transactions are swift and occur instantly as they do not need network confirmation to be validated.
Scalability: A payment channel can bear millions of microtransactions and is well applicable to small and micropayments.

PSEUDO CODE

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract SimplePaymentChannel {
    address public sender;
    address public recipient;
    uint public expiration;

    constructor(address _recipient, uint _duration) payable {
        sender = msg.sender;
        recipient = _recipient;
        expiration = block.timestamp + _duration;
    }

    // Close the channel and pay the recipient
    function close(uint amount, bytes memory signature) public {
        require(msg.sender == recipient, "Only recipient can close the channel");

        // Verify the signature
        bytes32 message = prefixed(keccak256(abi.encodePacked(this, amount)));
        require(recoverSigner(message, signature) == sender, "Invalid signature");

        // Transfer the amount to the recipient
        payable(recipient).transfer(amount);

        // Return the remaining funds to the sender and destroy the contract
        selfdestruct(payable(sender));
    }

    // Claim the funds if the channel has expired
    function claimTimeout() public {
        require(block.timestamp >= expiration, "Channel not yet expired");
        selfdestruct(payable(sender));
    }

    // Helper functions

    function prefixed(bytes32 hash) internal pure returns (bytes32) {
        return keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", hash));
    }

    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);
    }

    function splitSignature(bytes memory sig) internal pure returns (uint8, bytes32, bytes32) {
        require(sig.length == 65, "Invalid signature length");

        bytes32 r;
        bytes32 s;
        uint8 v;

        assembly {
            r := mload(add(sig, 32))
            s := mload(add(sig, 64))
            v := byte(0, mload(add(sig, 96)))
        }

        return (v, r, s);
    }
}

EXAMPLE

EXAMPLE OF A LIGHTNING NETWORK

The Lightning Network is a Layer 2 protocol for Bitcoin that enables fast and cheap transactions, and here is how it works

1. CHANNEL CREATION

Alice and Bob decide to open a payment channel.
Alice deposits 0.5 BTC, and Bob deposits 0.5 BTC into a multi-signature address (a joint account on the Bitcoin blockchain).
The total balance in the channel is now 1 BTC.

2. TRANSACTING

Transaction 1: Alice wants to send 0.1 BTC to Bob.
The balance sheet is updated: Alice’s balance is 0.4 BTC, and Bob’s is 0.6 BTC.
Transaction 2: Bob sends 0.05 BTC to Alice.
The balance sheet is updated: Alice’s balance is 0.45 BTC, and Bob’s balance is 0.55 BTC.
Transaction 3: Alice sends 0.2 BTC to Bob.
The balance sheet is updated: Alice’s balance is 0.25 BTC, and Bob’s balance is 0.75 BTC.

Stage	Transaction	Alice’s Balance (BTC)	Bob’s Balance (BTC)
Initial Deposit	Alice deposits 0.5 BTC	0.5
Initial Deposit	Bob deposits 0.5 BTC		0.5
Total Balance		0.5	0.5
Transaction 1	Alice sends 0.1 BTC to Bob	0.4	0.6
Transaction 2	Bob sends 0.05 BTC to Alice	0.45	0.55
Transaction 3	Alice sends 0.2 BTC to Bob	0.25	0.75

Ledger Table

3. CHANNEL CLOSURE

After multiple transactions, Alice and Bob decide to close the channel.
They broadcast the final balance sheet to the Bitcoin blockchain.
The blockchain verifies the final state through the multi-signature address and smart contract rules.
If no disputes arise, the smart contract updates Alice’s and Bob’s balances accordingly, transferring 0.25 BTC to Alice and 0.75 BTC to Bob from the multi-signature address.

By using the Lightning Network, Alice and Bob conducted three transactions, with a total of 0.35 BTC transferred between them. They incurred only the minimal fees for opening and closing the channel rather than fees for each individual transaction.

VERIFICATION PROCESS IN PAYMENT CHANNELS

The blockchain has to verify the final state of the channel when Alice and Bob decide to close the off-chain payment channel and submit the final state to the blockchain through the following process

1. Submit the Final State

Both parties, Alice and Bob, commit the final state to the blockchain, which is updated with the latest balance sheet agreed upon between them.

2. Multi-Signature Verification:

It’s now up to the blockchain to cross-check with the multisig address (the joint account) where the initial funds were time-locked, which it does by ensuring the signatures on the final state are those that Alice and Bob previously provided.
Confirming signatures ensures that both parties agree with the final state.

3. Implementation of Smart Contract:

The smart contract has rules for checking the final state.
One common rule is sequence integrity, which holds that the sum of the two parties’ total balance in the payment channel has to match the initial deposit, and no rogue party has altered that balance.
The contract implements such many rules to verify that the final state is in order with the history of off-chain transactions.

4. Conflict Resolution Process:

If either party objects to the final state, they can submit evidence of previous final-signed states. The smart contract can then compare the submitted final state with the history of transactions.
This bypasses fraudulence and maintains fairness between the parties by honouring the historically concluded genuine state that is mutually signed.

5. Blockchain’s State Update:

After validation, the smart contract reflects final balances on the blockchain, and any associated funds are moved from the multi-signature address to separate addresses owned by Alice and Bob in the agreed final state.
For instance, if the final state shows Alice having 0.25 BTC and Bob having 0.75 BTC, then the contract will release the funds in the ratio.

CONCLUSION

Payment channels have emerged as critical elements in improving the efficiency of blockchain technology toward reduced on-chain transaction load and costs and realizing high TPS. With the maturation of blockchain technology, these Layer 2 solutions are going to become critical for achieving widespread adoption and scalability.