Despite the tantalizing promises of decentralized applications, it seems that the truly complete results have yet to emerge on a large scale. The good news is that some projects are already exploring and trying, including Torus, Fortmatic, Portis, Unilogin, and Authereum and other next-generation wallet solutions that hope to compete with Metamask and emphasize debasing. But personally, I don’t think these current projects are enough to truly represent the future of DApps.

DApps that are not friendly to newbies

Over the past few years, the experience of using Dapps developer for me has not been very good. As a user, whenever I intend to send a transaction on the blockchain, an ugly window pops up prompting me for confirmation, warning that there will be a cost, and it’s all very uncomfortable.

I already have a lot of experience in using it, so I’m still used to it. But other newcomers are likely to be scared away from blockchain platforms. This kind of problem has not changed to this day, and every time an operation is attempted, there will be a scary pop-up window, which eventually leads to a very high customer churn rate for DApps.

I can understand that, as the operator of the platform, they want to make sure that users are aware that there is a fee for one of their actions. After all, if the reminder obligation is not fulfilled, the user group will soon complain and even be surprised that there is no money in their Ethereum account. However, to achieve the goal, we should cooperate with more scientific and reasonable methods.

Unless you are very familiar with Ethereum wallets, DApps and even the entire cryptocurrency industry, you have no idea what this window is for. Some users may even think that this is a fraudulent website, because clicking The design of the button to generate the pop-up window is often linked to words such as poor quality and unreliability. However, this has instead become the industry norm, with pop-ups appearing whenever a user wants to interact with a smart contract.

More than that, sometimes users even need to install a full extension to interact with the DApp. Fortunately, the situation is slowly changing, Opera has released support for DApps Development Solutions in its mobile browser, and other wallets are now starting to have built-in DApp browsers. But all of this is only in the niche stage and has not entered the mainstream at all.

In other words, unless Google can support DApps in its Chrome browser, or Mozilla provides a similar option on Firefox, the problem will never be solved. No matter how beautiful and friendly the popup is designed (Fortmatic uses a curved outline design), and how many niche products start to support Web3 injection, the problem will continue to exist.

“Hide” your backend system

Users of Metamask and other Web3 injectors are already familiar with how this works, and they have a lot of experience so they won’t be intimidated by DApps. But I think it’s a waste of time to simply make the experience more fancy, smooth, or rounded. That’s not enough to really attract mainstream users, as substantial barriers remain. In other words, what really scared them off was that they didn’t quite understand what was going on.

Rather than focus on simplifying the Web3 infusion experience, scrap it altogether. We can build a platform that allows users to directly interact with smart contracts without involving any smart contracts or blockchain elements. Through this “de-bottomization” measure, the public can truly accept this new trading platform and user experience.

You might as well learn to think like a bank — the bank will never show off the internal functions of the system, but provide users with options that are visible and understandable for users to judge. This de-basing design strips out the heavy backend system to ensure that users will not easily touch it.

But how should this be accomplished?

Most DApp development tutorials teach Web3.js or Web3.py and how to interact with Web3 instances injected in the browser through these libraries. This is how most DApps are built, often exposing the underlying plumbing and causing the usage of Metamask to be filled with annoying popups. As mentioned earlier, this design is suitable for advanced users, but we can also completely hide the pipeline, ie not require Web3 support on the client side.

It is necessary for us to build a platform that does not require Web3 injection. Specifically, users should be able to sign up using their email and password, or even social logins like Twitter, Google, and Facebook. In short, the more familiar and friendly everything is, the better.

Many friends may think this is difficult to achieve, but the tried and tested trusted frameworks such as Laravel can fully work, Build decentralized apps bringing a more “normal” look and feel to mainstream users.

After logging in and entering the dashboard, we should guide the user to create their own account. With the click of a button, the backend generates a new Ethereum address.

But some friends may ask: “What about the private key?”

First of all, for mainstream users, it is not a big problem whether the private key is in their own hands. I know it’s not a good idea to centralize all private keys, even arguably contrary to the entire value proposition of blockchain technology. Therefore, we should help users retain private keys at a minimum, purely for the purpose of enhancing ease of use.

Second, please don’t store private keys in plaintext or even hashes. Both Web3.js and Web3.py provide encryption and decryption functions that require a private key. As long as it is matched with the password specified by the user, the security of the private key can be guaranteed.

Therefore, you can store these keys with the account on a centralized platform, thereby eliminating the need to expose Web3 and use Metamask.

Focus on expanding user scale

Suppose you are building a payment platform with an Ethereum smart contract as the backend. You need to know that your users need to interact with the platform, but you do not want to set too high barriers to entry in terms of Metamask and wallet usage. This is the prevailing situation — users just want to use your product, not spend hours learning Web3. Therefore, the most important thing is to first establish a set of

Platforms for registering and logging in through Facebook, Google and other social networks.

Build a set of dashboards for users to create accounts. If you’re worried about blockchain jargon scaring them away, try to use more relatable expressions. During the creation process, users can be asked to provide a pin code or encrypted password, or they can directly use their login password for private key encryption. The encrypted private key will be stored in the database along with the user details.

Of course, transactions on the blockchain are not free, and neither are the products themselves. FIAT is still the leader in the cryptocurrency space, and you can use Stripe or similar as your primary means of payment. Regardless of the payment method you ultimately choose, including a one-time fee or a subscription model, Cross chain bridge development you can load user wallets with Ether when receiving payments. What users see is that they need to pay a monthly fee on a regular basis. But in the bottom layer, the user’s account has been recharged and can interact smoothly with your smart contract ecosystem.

Whenever a user submits a transaction to a smart contract through your platform, the platform should control how the alert message is presented. Since their keys are already encrypted in the database, decrypting the keys and submitting transactions through the account should only require the user to enter a pin code for confirmation. That’s what traditional banking apps do, never sending out scary reminders through ugly Metamask. In short, it is all about making the customer happy, familiar and accustomed to it.

Web3.py example

The following code samples require that you already have Python3, Web3.py (installable via pip), and an Infura account and URL to access the blockchain.

Below, we’ll walk through how to create an account, generate an encrypted version of the account with a password, and decrypt it through the Web3.py server according to the user’s request. In conclusion, the whole process should not expose any functionality on the front end. Web3.js also provides this functionality.

Inside the Python terminal, run the following command:

Since the encrypted keystore is stored, the platform does not know the content of the private key. The only prerequisite for decrypting and signing transactions is knowing the value of userPassword.