0

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?

  • 1. no, don't do it.... trust me on this one. 2. no, unless you partner with multiple entities that do the same thing, and all of you do it on a common agreed blockchain. – OWADVL Oct 25 '18 at 18:23
  • @OWADVL .. can you provide a bit more insight on the answer to the first question? – DottoreM Feb 11 at 8:48
0

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.

  • Let’s say I want to make a trusted loyalty system for my users. Should I create an ERC-20 token? Or no really need for it since i am managing the logic in the smart contract. – abed Oct 25 '18 at 17:03
  • By saying giving the user the option to interact directly with the blockchain, how can this be an option using a mobile app? – abed Oct 25 '18 at 17:05
  • @abed You can integrate a metamask like service for you mobile app (if they exist) – Kaki Master Of Time Oct 26 '18 at 7:57
  • There’s actually a geth client of ios and android, never tried it tho. – abed Oct 26 '18 at 7:58
  • @abed it is probably not a full node, maybe a light one. it is hard to fit a Geth on mobile devices – Kaki Master Of Time Oct 26 '18 at 8:10
0

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.

  • So user’s private key is stored on the mobile and sent through REST api to your server every time the user wants to send a transaction? – abed Oct 26 '18 at 12:46
  • Absolutely NOT. We have a mobile app that stores the private key on the smartphone and creates the transaction on the Blockchain without using the backend server. After the transaction on the blockchain is confirmed the mobile app sends some data to the backend server along with the transaction hash. – Marco Ottolini Oct 26 '18 at 17:25
  • Ok that sounds great, so if the mobile app is dealing with a private blockchain, do you involve the user in the wallet creation process? What if he uninstalls the app and then wants to login again how can he restore the private key? – abed Oct 26 '18 at 17:50
  • @abed Yes, during the user registration process the app creates the private key. Then the user has to save the 12 words seed, printing it, or saving it somewhere (GDrive?). To reduce the clutter, if you have more specific questions, drop me an email (address in profile) – Marco Ottolini Oct 27 '18 at 7:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.