In payment channels and state channels there is always an inherent lack of trust between participants. There is always a possibility that your counterparty will try to cheat to steal your funds.

Lets see how a simple bidirectional payment channel works to explore this problem:

Without Blade: A simple bidirectional payment channel with settlement period

Alice creates a smart contract and locks up her eth. Bob also locks up his eth in the same contract. Alice signs an IOU and sends it to Bob. This message is cryptographically signed by Alice’s private key. This message also includes a serial number of the message so that order of messages can be identified. This is called a nonce.

e.g. <alice’s balance>,<bob’s balance>,<nonce>,<alice’s signature>

3. If Bob wants to send funds to Alice, he can use the same procedure.

4. Either of the parties can close the payment channel anytime by submitting the latest message to the channel smart contract. The smart contract verifies the message along with the signature and sends appropriate amount of funds to each of the parties.

However users can cheat by closing their payment channel with a message which is not the latest message in the channel.

Lets see an example:

Alice opens a payment channel with Bob Alice and Bob deposit 10 eth each into the payment channel contract Alice sends 1 eth to Bob by signing a message. Alice’s Balance: 9 eth. Bob’s Balance: 11 eth. Nonce: 0 Bob sends 5 eth to Alice by signing a message. Alice’s Balance: 14 eth. Bob’s Balance: 6 eth. Nonce: 1 Bob can try to close the channel with a message with nonce 0 and get 11 eth rather than 6 eth that he is supposed to receive.

This problem is usually solved by introducing ‘settlement periods’. If one of the parties wants to close the channel, the other party must respond within a designated period of time (lets say 2 to 4 weeks), for the channel to be settled.

If a user is trying to cheat by sending a message of older nonce, the counter-party can prove the fraud by submitting a message of higher nonce. Now that both the parties should have submitted latest messages to the best of their knowledge, the payment channel can be settled.

These settlement period are a large barrier of entry for widespread use of payment channels. If one user wants to close the channel, the counter-party may not respond and cause the user to wait for a long time causing a great deal of inconvenience.

Settlement periods are common in all layer-2 scaling solutions known today. Sidechain-like solutions such as plasma also have settlement periods as the chains are updated on main chain periodically and users must wait till the next on-chain update for on-chain settlement.

Blade protocol is a novel protocol which eliminates the need of settlement periods and allows users to create payment channels which can be settled instantly without possibility of fraud. This is the first and only known solution for eliminating settlement periods.

The core idea of Blade is to use user’s hardware wallets as pseudo Trusted Execution Environments (even though they may not have true TEE capabilities from a hardware perspective). Devices compliant with the protocol do not let users take arbitrary actions. These devices do not allow users to cheat in games such as payment channels.

The wallet issuers include a unique ‘issuer private key’ inside each device during manufacturing. These keys can never be read or extracted from the device. The firmware of the device will only sign messages with this key if it complies with the protocol.

Lets revisit above example. This time, both the users are using Blade-compliant hardware wallets to store their keys.

With Blade: a simple bidirectional payment channel without a settlement period

Alice opens payment channel with Bob using her wallet. This channel can only be closed if a payment message signed with one of the users as well as their ‘issuer private keys’. Her wallet device remembers this action and stores it on the persistent storage. Alice and Bob deposit 10 eth each into the payment channel contract. Alice sends 1 eth to Bob by signing a message. Her wallet device stores this message in the device. Alice’s Balance: 9 eth. Bob’s Balance: 11 eth. Nonce: 0 Bob sends 5 eth to Alice. His wallet device stores this message in the device. Alice’s Balance: 14 eth. Bob’s Balance: 6 eth. Nonce: 1 Bob can try to close the channel with a message with nonce 0 and get 11 eth rather than 6 eth that he is supposed to receive. However, his wallet will not allow him to sign message of nonce 0 using ‘issuer private key’ . The wallet will only sign the last message signed by the wallet with issuer key. If the last message was signed by Alice, Bob can send this message to his wallet, which will be stored in wallet’s memory if it is valid and has a higher nonce than currently stored message. Bob’s wallet signs settlement request by signing message of nonce 1 with ‘issuer key’. Bob sends this message to the blockchain. Smart contract instantly closes the channel and sends the proceeds to Bob and Alice instantly. There is not settlement period required.

For in depth explanation and recovery procedure in case the wallet is compromised is explained in the whitepaper. A work in progress draft copy of the whitepaper is available at https://github.com/hrishikeshio/blade

Follow me on twitter: https://twitter.com/hrishikeshio