The Knuth Release is here and with that, Appcoins accomplishes yet another milestone! This release introduces brand new features and incorporates new technology. The Knuth release, which consists of a proof-of-concept (PoC), as previously mentioned in the last two ANUs (#10 and #11), aims to showcase the possibility of doing fee-less and under-the-second microtransactions using payment channel technology.
The post is divided into three sections. The 1st details the purpose of the PoC, the 2nd explains the technology used, and the 3rd describes what the PoC does and how users can try it out.
The Ethereum network introduced the concept of using a Blockchain structure as a basis for decentralised and trustless computing. However, as many Blockchain protocols, it uses the “longest chain” rule together with the proof-of-work (PoW) mechanism to achieve consensus between nodes in the network. The PoW mechanism defines the rules of participation in the block creation process.
PoW is a costly mechanism, as it requires everyone in the network to validate transactions and solve complex mathematical puzzles to produce new blocks for the chain. Since everyone is required to participate and there’s a high cost involved in solving the puzzles, it poses scalability problems regarding transaction latency and transaction fees that need to be paid to help to support the network. Therefore, it’s not possible to achieve a significantly high throughput in terms of the number of transactions per second (TPS) to make it possible for the Ethereum network to be used for day-to-day micropayments. There are certainly projects aiming to mitigate and/or solve these issues, both at the protocol level (sharding, Casper) and at the application level (Plasma, Raiden).
The purpose of this PoC is to use µRaiden technology, which is a simpler approach to the Raiden network, to facilitate microtransactions in in-app purchases (IAP). We want to give users a preview of what paying for in-app items using cryptocurrencies can be. For developers and app stores, we want to show that they can verify all transactions done and get the income generated from in-app purchases instantly, so they can use them faster for their needs.
As said in the previous section, we are using µRaiden technology to achieve under-the-second and fee-less transactions.
µRaiden is part of the Raiden Network project. As opposed to Raiden, which aims to have bidirectional payment channels between interconnected nodes, µRaiden consists of unidirectional payment channels with no network of nodes. Opening and closing payment channels are on-chain transactions, which means they will require transaction fees. This happens because payment channel data, such as sender and receiver, and channel balance are kept on-chain to avoid centralisation and complete control of data.
However, the advantage of payment channels is that all transactions done within payment channels are off-chain transactions without fees. Therefore, one can open a channel with someone else for a certain period of time and make microtransactions without worrying with transaction latency or fees. The sender or the receiver can close the channel once the interaction no longer is advantageous for them.
The payment channel flow pattern is the following:
- An Ethereum account opens a payment channel with another Ethereum account. The payment channel is unidirectional, which means only the account that opened the channel (i.e., the sender) can send tokens to the other address (i.e., the receiver).
- The sender tops up the payment channel with a number of tokens of his choosing. The sender can then perform fee-less transactions until the chosen number of tokens is exhausted.
- When the sender wants to perform a transaction, he produces a cryptographically-signed balance proof. This proof is sent to the receiver, which confirms its validity. If the balance proof is valid, this means the transaction was successful. Then, the tokens involved in the transaction are allocated to the receiver.
- Both the sender and the receiver can close an open channel at any time, provided they possess the valid balance proofs. When a channel is closed, the receiver gets the tokens allocated to him and the sender gets back the tokens he didn’t spend.
The PoC will be composed by a mobile game integrating our SDK and an iteration of the AppCoins Wallet, a wallet that implements µRaiden payments. We’ve also adapted the channel manager contract in order to have it using APPC as channel token. The PoC is working in the Ropsten network, and will be deployed in the main Ethereum network in the next days.
The above pattern of µRaiden applied to the IAP flow of the AppCoins Protocol is:
- The user is using an app with the AppCoins SDK integrated. Once the user wants to buy an in-app item and clicks on it, the AppCoins Wallet is triggered and shows the payment dialog.
- The payment dialog will state if there’s an open payment channel or not. If there’s already an open channel, the user can confirm the payment, and it will be done using the APPC in the channel. The transaction will be instantaneous and fee-less.
- If there isn’t already an open channel, the user will be able to open one and top it up with a certain amount of APPC. Then, the payment is done already using the payment channel.
- If the user already has an open channel and still has enough APPC for a certain payment, that payment channel will be used to buy the item. However, if the channel doesn’t have enough funds, the user needs to head out to the wallet and close the channel explicitly.
- At any time, if the user has an open payment channel, it can be closed in the AppCoins Wallet, and the unused APPC are sent back to the user’s account.
Below you can see how the payment flow is done using payment channels. You can get our demo app Trivial Drive from Aptoide and the AppCoins Wallet also from Aptoide or Google Play, and try out the PoC.
You can also see how transactions of opening a payment channel and doing a transaction inside a payment channel look like in the AppCoins Wallet.