ANU #10 — ASF Wallet, AddressProxy and Scalability Proof of Concept

AppCoins News Update, or ANU for short, is a regular bi-weekly update by the AppCoins team. As usual we are going to cover dev updates, market reports, team members and upcoming events. This week’s focus is on the ASF Wallet, AddressProxy, “Read More” Page and Scalability Proof of Concept (SPoC). You may expect the next ANU on the 6th June.

Quicklinks
Dev Update
APPC Markets Report
Featured Team Member
Upcoming Events

In the past weeks, we’ve been solving some issues and improving part of the UX of the ASF Wallet, as well as developing important components for the future.

We’ve also been preparing for the next major release after Gosling: the Knuth release. This is a very important release because it will deal with the subject of transactions scalability, both in terms of transaction time, as well as transactions fees. Solving both issues is crucial for the mainstream adoption of the AppCoins Protocol as the de facto standard for In-App Purchases (IAP) and Mobile Advertising.

ASF Wallet

In the past 2 weeks, we’ve continued improving the UX of the ASF Wallet regarding the Transaction List screen, as well as the Individual Transaction view. In ANU #9, we’ve shown the status at the time of the wallet and what we wanted to achieve.

We’ve finished the implementation of most of the new layouts and respective logic to show more information about transactions without cluttering the views. Users can also clearly differentiate between the different transaction types: IAP, Advertisement attributions (by submitting the respective PoA), and normal Send/Receive transactions of ETH and ERC20 tokens.

Below shows the differences between the first release of the ASF Wallet and its current development status regarding transactions views (list and individual).

(Left) Current status of the Transactions screen; (Right) Transactions screen after redesign
(Left) Current status of the individual transaction screen; (Right) Individual transaction screen after redesign

We’ve also introduced a new component in the Airdrop flow we’ve created, to enable users to experiment with the protocol. The Airdrop consists of giving APPC and ETH, given a set of restrictions outlined in the Airdrop post. Now users need to answer a CAPTCHA challenge in order to get APPC and ETH. This serves to avoid malicious users from draining the Airdrop funds for personal use.

AddressProxy

In ANU #9 we’ve also presented our view about how we should continue developing the Blockchain component (i.e. smart contracts) of the project together with the other products (wallet, SDK and web pages). We understand that we need to decouple smart contract development from product development, in the sense that a deploy of a smart contract shouldn’t automatically require a change of all or even one of the other products.

As such, we’ve developed a smart contract that works as an address proxy for the others regarding their addresses. All the products connect to that smart contract and get the address of the smart contract they want to call, which changes in the AddressProxy when we deploy a new version of that smart contract. The reader can see the code here.

We’re also working in storage contracts that serve to decouple smart contract storage from smart contract development. This means that we want to be able to keep data available when a new version of a given smart contract is deployed, as opposed to losing all the data or having to migrate it every time. As we’ve stated in the last ANU, one can think of this concept as an Eternal Storage.

“Read More” page

The AppCoins Protocol is disrupting the mobile app economy, and this challenge comes with an educational issue. The common end-user isn’t familiarised with cryptocurrencies or Blockchain tech, nor with their applications. Furthermore, even if the common end-user is used to trade and use cryptocurrencies, we would also need to educate him regarding our flows, and the added value of the AppCoins Protocol. Moreover, we’re building several products that interact with the Blockchain part of the project, and these products need to be explained as well.

Therefore, we’re developing a web page that will be used as the entry point for everyone trying to learn more about the project and its added value. This page will then direct readers to other web pages, which are more detailed regarding a specific topic.

Below shows how the “Read More” page will look like.

Read More page layout

Scalability Proof of Concept (SPoC)

As said in the introduction of the Dev Update, we’re working on the Knuth release. It will be focused on the scalability issue, which is shared by many other projects built on top of the Ethereum network or other blockchains.

With our SPoC, we’ll provide a working prototype to showcase scalable in-app purchases. Users will be able to pay for in-app items using APPC without having to wait so long for transactions to finish, and without paying high transaction fees. We’ll experiment with Microraiden, as it is a good candidate to become part of the scalability solution integrated into the AppCoins Protocol.

Microraiden is part of the Raiden Network project. As opposed to Raiden, which aims to have bidirectional payment channels between interconnected nodes, Microraiden consists of unidirectional payment channels with no network of nodes. Opening and closing payment channels are on-chain transactions, which means they will require fees. However, the advantage of Microraiden is that all transactions done within payment channels are off-chain transactions with no fees. Therefore, one can open a channel with someone else for a certain period of time and make microtransactions without having to worry about transaction delay or fees, and close the channel once the interaction is no longer advantageous or when the receiver needs to use the funds received within the channel. It’s important to note that the receiver won’t be able to use the APPC sent in the off-chain transactions right away, but only when the channel is closed.

In the SPoC, users will be able to download an app with a special version of our SDK integrated. When trying to buy an in-app item, users will be prompted to use Microraiden with a special version of our wallet. Below are the mockups of the UIs of the SPoC.

IAP dialog with the ability to open a Microraiden payment channel
Transaction List screen of SPoC version of the wallet
(Left) Open Payment Channel transaction view in the SPoC version of the wallet; (Right) In-App Purchase transaction view in the SPoC version of the wallet

read original article here