You do need some custom binary running on your machine to securely interact with the . 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 .
However, consider a person not involved in today buying crypto. Are they likely to set up their account locally and funds there, or just them on , which is a completely centralized service? They will probably choose the latter.
A similar reasoning shall apply to using decentralized applications. When the user starts interacting with the 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 such security is no worse than what 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 applications from iTunes or PlayStore, effectively trusting both the MetaMask / 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 applications, such as . 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 the 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 is provided by NEAR. Ultimately the user can start interacting with the by using the hosted , 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 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 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 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,, 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 , 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 that makes a lot of sense. Similarly, if the hosted 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 for the protocol. Cryptokittles 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 or the application developers set for the 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 , and has plenty of solutions already existing. The hosted 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 , 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 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 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 , and read .
NEAR Protocol builds a sharded proof of stake with a fanatical emphasis on usability. If we intrigued you, please , and , where we discuss all the topics related to tech, economy, governance and more.
Published at Thu, 18 Apr 2019 00:48:10 +0000
