Blockchain app technical architecture

Question

Let’s say I want to build an app that is not completely decentralized, in fact it serves Restful APIs to the frontend and uses a private ethereum blockchain in the backend to process sensitive data and manage user permissions. I create for each user when signing up to my backend an ethereum account using his password. The backend is running NodeJS express, and connected to the web3 instance. Whenever the user wants to make an action he is required to enter his password, then I use this password to unlock his account and send a transaction (or it could be a contract call).

1. Does it makes sense to act as a middleware between the user and the private blockchain? I mean from an ethereum design point of view is this a common practice? How should the user be aware of this practice if he is not seeing anything related to blockchain because all the work is done behind the scenes? How could the user trust my system that his password is not going to be leaked?

2. Is it recommended in such case to use multiple nodes for this private blockchain? What benefit does it bring with it? Is it only the high availability and removing the central point of failure?

Answer 1

Before I try and answer your questions : there are certain benefits for the usage of a blockchain and ethereum in particular. These benefits are :

• Blockchain technology help track things, using its unique currency system and "tokens"
• Blockchain technology can provide an indisputable proof of integrity of any kind of data
• Ethereum smart contracts can provide means of transparent transactions between automated entities. entities that are regulated by "Code Laws".
• Ethereum smart contracts do create a sort of automated dealer in all kind of goods (a vending machine for everything)

these benefits are the ones that you need to have the need for in order to implement an ethereum based platform. Other than those, ethereum will rapidly become a liability and a weak point in your system.

Your Questions :

1) In many current and most of the future big projects, Ethereum nodes will not be visible to the user in anyway. The thing that will build the trust between the platform(system) and the user will be the promise of transparency and robustness. A good practice is to explicitly tell your users that you are managing their accounts on their behalf and do give them the possibility to opt out of it and manage their Ethereum accounts and transactions themselves while still benefitting from your platform's services.

2) Multiple nodes in case of a private network are not necessary. You may need to use many nodes if the logic behind your system requires the actual sharing of decision between those nodes. Something like a node for each country, or a node for each party. Having many nodes can also reduce pressure on your hardware and increase capacity and fault tolerance of your system.

Answer 2

I implemented a private blockchain with a backend system in nodejs that handles some of the hurdles but left the blockchain doing the work is best at: giving trust. So, basically I implemented a solution which works in the opposite way to what you described here.

In my architecture, the private key of a user is on the client and user data are registered on a mongodb server together with the user account on ethereum. Whenever a transaction is requested, the client creates it on the blockchain using the private key of the user (in a mobile app is stored in the storage area, in a web app it's managed by MetaMask) and, if successful, register the transaction in the database with a reference to the transaction hash.

In this way, the truth is kept on the blockchain, nobody can steal passwords and on the database you have data that are too expensive to keep on the blockchain.