On usability of blockchain applications

On usability of blockchain applications

Imagine you want to play a blockchain game. For example, say you want to get a cryptokitty. Or play some collectible card game. It is actually a pretty involved process. You need to:

Install Metamask;

Create a key pair, and securely store the private key; If you want to later play from another device, you need to understand how to transfer it to that device;

Register on Coinbase;

Do a KYC, which involves sending your documents to Coinbase;

Wait for a few days;

Buy Ether. Yes, you need to make a purchase before you can even try the game!

Transfer Ether from Coinbase;

Finally, buy your kitty! Though now you need to pay for every interaction with the game, and your latency is at least 20 seconds.

Modern games and applications running on blockchains report a whopping 95–97% drop-off rate during the above onboarding process. That means that out of 100 users who try the application only 5 or fewer actually get to start using it!

The problem above can be roughly split into three subproblems:

The necessity to install a browser plugin (or have a wallet application) to securely interact with the chain;

The necessity to have and understand public/private keys security;

The necessity to pay for gas for each transaction.

Items 1 and 2 above are mandatory for interacting with the blockchain securely, they are designed to make sure the user doesn’t lose their funds or assets. The last item, besides providing a financial incentive to the miners, is also necessary to keep the blockchain itself secure — if transactions were free, it would be trivial to DDoS the system by spamming it with lots of free useless transactions.

Once a person is involved in a particular blockchain ecosystem, such as Ethereum or NEAR, they do have the browser plugin or wallet installed, have some assets on their accounts, and have all their devices set up to use the proper key pairs. For them using Web3 applications is relatively easy, besides maybe the fact that the applications are slow (latency and throughput of blockchain applications are beyond the scope of this writeup, check out our previous posts on sharding: one and two, as well as tech deep dives with developers of plasma: one and two, and state channels).

However, as of today, the majority of internet users do not use blockchain, and if we want it to change, we need to make the onboarding for them as streamlined as possible. In the ideal world developing a decentralized application running on a blockchain shall be no harder than building a nodeJS application, and once such an application is deployed, a user that never used blockchain before should be able to just open it in a browser and start interacting with it.

Let’s consider each of the barriers described above, what efforts are made to fix them today, and what changes we are developing on the protocol level to support them.

If you prefer video, you can watch me giving a talk at Berkeley on the same topic here:

Browser plugins / Wallet apps

You do need some custom binary running on your machine to securely interact with the blockchain. The motivation behind it is that anything hosted that you just open in your browser is completely controlled by the host, and thus can be arbitrarily changed at any point. Even if the hosted solution stores the keys locally encrypted, the code of it can later be changed to fetch the data from the local storage and send it to the remote server immediately after it was decrypted to be used for some interaction with the blockchain.

However, consider a person not involved in blockchain today buying crypto. Are they likely to set up their account locally and store funds there, or just store them on Coinbase, which is a completely centralized service? They will probably choose the latter.

Similar reasoning shall apply to use decentralized applications. When the user starts interacting with the blockchain they shall be able to do that through a hosted solution. It will provide lower security, since the centralized entity will have an ability to take over the account, but early on the user doesn’t have much to lose, so much security is no worse than what one gets today with centralized services to whom the users trust a great deal of their assets and data.

To emphasize this point, observe that most people install MetaMask from the Firefox or Chrome extensions catalog, and wallet applications from iTunes or PlayStore, effectively trusting both the MetaMask / wallet applications developers, and some big player such Mozilla, Apple or Google. It is extremely rare for one to install MetaMask from source, after carefully examining the code. Thus we already trust the security of our accounts to centralized entities.

There are solutions developed today that developers can integrate into their decentralized applications that would make it possible to interact with the application without installing browser plugins and wallet applications, such as Portis. The problem with such services is that once one trusted their private key to such a service, ultimately the security of the account is permanently compromised. If one later wants to get the full ownership over the account, they must create a new account and transfer all assets to such an account. If a particular application doesn’t provide a convenient way to transfer assets, the user will never be able to gain full ownership over such assets.

One solution to this problem is to have a contract-based account such that the user can replace the key that controls the account once they wish to do so. But for this to work the account needs to be contract-based from day one, and unless Portis or other service creates such a contract based account by default, users will not have this ability. Further, contract-based accounts cannot do everything that a regular account protected by a private key can do.

In NEAR each account is contract based by default, and a hosted wallet is provided by NEAR. Ultimately the user can start interacting with the blockchain by using the hosted wallet, and then later at any instance update the security of the account by creating a new key pair locally and updating the account to use such a key pair.

Someone suggested a term we like a lot for this approach: progressive security. The user transitions from the highest usability and low security to the highest security and low usability over time, as their involvement and investment into the blockchain increases.

Understanding private/public key pairs

If we convinced you that progressive security is a good thing, and hosted wallets are a way to go, key pairs are gone naturally. In the simplest approach, the hosted wallet stores the private keys of all the users in its own hosted database, and provide its own authentication layer to the users. It can offer them to use Facebook login, Google login, or just good old email and password option. Only once the user wants to transition from using the hosted wallet do they need to set up a private key properly, and learn how to transfer it to other devices.

Interestingly, with the contract based accounts, the transfer process itself can be done easier while maintaining the full security. Instead of transferring the private key to another device via some insecure channel, the contract that governs user’s account can have two methods: `proposeNewSk` and `approveSk`, where the first method can be invoked by anyone, and adds a new private key into a list of proposed private keys for the account, and `approveSk` can only be called with a signature from one of the existing private keys on the account, and can approve any of the proposed private keys for the account. This way a user can set up a brand new key pair on the new device, propose the new private key from such device, and approve it from the existing device.

Gas fees

Any transaction that is executed on chain consumes a somewhat large amount of resources. For a state change to be executed securely, a large number of independent entities need to validate the state transition before it is applied. Since there’s some amount of resources spent on executing the transaction, it cannot be free.

When one compares web3 to web2, they often argue that web2 services by nature are free today. One doesn’t pay for every transaction when they use Facebook. But in reality, they do. Facebook would not provide a free service to the users if the expected long term value from the user didn’t exceed the resources spent on the resources spent processing their requests and storing their data, as well as the cost of acquiring such a user. When using Facebook, users both pay with their data, access to which Facebook then abuses in the most unacceptable ways, and with their attention. The following screenshot literally doesn’t have a single block of information that is not sponsored:

(the value of x is 2)

In the case of the blockchain, if an application developer believes that the total lifetime value from the user will exceed the gas cost for their transaction, they shall be able to pay for such transactions. It is one of the few ideas that come from EOS that makes a lot of sense. Similarly, if the hosted wallet has some value in users using the applications, they can choose to cover the costs as well. For example, NEAR might opt in to cover some gas costs for each user, since it is highly motivated to get higher adoption for the protocol. CryptoKitties can choose to cover the cost for interactions with their contracts, since users that start playing CryptoKitties are very likely to buy one, and the expected value of a user is extremely high.

This only solves one part of the puzzle: offsetting the costs of executing transactions. If users don’t have to pay for transactions, they can spam the system with free transactions, and saturate the allowance that the hosted wallet or the application developers set for free usage. But similarly, people who use Facebook can spam them with free requests and saturate their resources. This problem is by no means unique to blockchain and has plenty of solutions already existing. The hosted wallet can choose to implement one such DDoS prevention solution, and still provide users with free transactions.

There’s still a problem. The model in which someone pays for the user expecting some value from them later is easily abusable. There’s a reason why Google, Facebook, Apple, and other tech giants have non-transparent privacy policies and completely disrespect users’ privacy. The entire motivation behind web3 is to put an end to such practices, but the very way we try to attract users promotes such practices again.

There’s however a fundamental difference. In web3, while the user can start using a service paying with the future expected value, they can at any point switch to paying for transactions themselves and use a hosted wallet, or a browser extension, that doesn’t try to take any advantage of the user’s privacy.

Outro

With the progressive security concept and particular solutions above, we can provide users with the onboarding as simple as it is today in web2, with an ability to upgrade to the full blockchain security at any moment in the future.

We are writing a separate blog post on the other side of the problem: ease of development. The state of developers experience in Ethereum is far from perfect, and we believe that it can be improved significantly.

While waiting for the blog post, you can already experiment with our development experience. Try out our online IDE, and read the documentation.

NEAR Protocol builds a sharded proof of stake blockchain with a fanatical emphasis on usability. If we intrigued you, please follow us on Twitter, and join our Discord, where we discuss all the topics related to tech, economy, governance and more.

https://upscri.be/633436/