0

This question is regarding design options / pros & cons to consider when building an Ethereum DAPP.

If we were to take the example of building a KYC DAPP on ethereum - then, before adding (or not) a customer into the system, one needs to make sure that the customer is not already present in the KYC system. This could imply doing a search for customer identity before deciding whether to add the customer or not. There could be (at least) 2 broad ways of designing this -

a.) 1.Create a customer db - outside of the BlockChain - say a Mongo db or any other such appropriate option, hosting say, SSN / DL or such information to identify the customer uniquely, 2. confirm whether the customer exists in the system or not, 3. and then decide on adding/rejecting the customer / and 4. update BlockChain with the outcome of the exercise. So, the BlockChain is used as a repository of KYC data, but not used for Search like operations in this context.

b.) Have the customer information in the Ethereum BlockChain - both as a repository as well as for searching purposes. So, no other DB needed.

Option a would then imply having support for Distributed Transaction semantics, to make sure that the customer DB and BlockChain are either both updated or neither is.

Is it appropriate to use Eth. Blockchain as a Db to search like one does in Transactional Databases? Any pointers / opinion on pros/cons on the approaches above in the context of Ethereum BC are welcome.

0

Ethereum blockchain is not very good at storing large amounts of data, it is expensive and slow. And you do not have many tools to make meaningful queries.

Another very important thing to note is all data is public and can be read by anyone with access to the blockchain. So you may not want to store some private data there.

It is permanent, meaning you can delete some information from your own copy, but you cannot force a deletion from all the copies of the blockchain distributed all over the world.

There are tools and techniques to alleviate some of the shortcomings. You have Swarm and Ipfs to store cheaply large amounts of data. You have Quorum to store privately some of the information.

One use today of the blockchain is to act as a notary. You store users data in a private database, and only store in the blockchain a fingerprint of the information. That way, a third party can verify the information you have provided matches with the stored information.

0

I think it depends how you design that KYC DAPP to discuss its pros and cons.

Initial questions to be answered should be if you want to use a permissioned Ethereum implementation or an unpermissioned (or maybe both). How would a new record be inserted and by whom? The customer directly? A representative from a validating institution?

As long as you keep going with a permissioned setup and do the initial recording of a KYC entry on behalf (or together) with the customer, I think you can disregard the aforementioned privacy issue, but it would eliminate features such as self-enrollment probably. Think as well about whether later on you want to give the customer access to see his profile, see the validating institutions, their decisions and allow them to approve/reject decisions or not.

In terms of adhering to regulations I guess many countries would force a photo ID of some sort for a visual validation and hence you should only tokenize the KYC record on Ethereum and store any "heavy" information such as jpg etc on distributed filesystems like IPFS and make some linkage. Introducing a dependency external to the distributed fashion of Ethereum will kill the benefits of using blockchain tech over traditional tech.

As far as I know, Ethereum does not have a "search" function per se, but you could rather iterate through all blocks and TX to get what you might be looking for. I think the question is rather how to uniquely search for someone. How do you create a unique identifier for a quick cross-check assuming a new customer?

Maybe one approach might be along the lines of two-factor authentication, so basically something the new customer has (i.e. credentials such as name, age, dob, etc...) and something the new customer knows (i.e. password / passphrase)...

Hope this helps a bit :)

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.