GDPR was implemented in EU in the first half of 2018, and blockchain startups faced the problem of working with personal data in context of blockchain transparency and immutability.
The first thing coming to mind is to avoid writing any sensitive information to the blockchain. It is worth mentioning that BCShop.io sticks to this path.
But that is only the beginning. Here are a few thing BCShop.io is implementing to comply with GDPR.
In addition to the mentioned above features we are also adding more verbose warnings and confirmations for all the parts of our website that deal with personal data.
For example, let’s take an offer page
The highlighted Email text will be impossible to edit after the ‘Buy’ button is pressed. So we inform user about that fact.
These new warnings should explain why and when we collect the personal data to our users.
In one of the previous reports we spoke about the caching layer that is responsible for performance increase. We decided to improve it even more by including new entities to the caching list.
Basically, from the logical point of view any unit in blockchain can be described as either ‘non-final’, i.e. one that might get changed with future transactions, or ‘final’ that cannot be changed anymore.
Initially all the units are ‘non-final’ and their current states are written to the database. Back sync process periodically checks blockchain and stores all the updates. Later some units become ‘final’ and sync process excludes them from the checklist.
Let’s take for example a purchase. Its state is the variable that changes with time until it becomes ‘final’.
Here is the list of possible purchase states:
Paid - purchase is locked in smart contract, a dispute can be raised.
Pending - purchase complain time expired and the merchant can withdraw the payment
Revoked - purchase was revoked by the merchant and payment returned to the customer.
Complain - dispute was raised and arbiter has to resolve it
Finished - the merchant withdrew payment or it was directly sent to them in case of non-escrow protected offer.
The only states that can be changed are ‘Paid’, ‘Pending’ and ‘Complain’. Final states are ‘Revoked’ and ‘Finished’. So it makes sense to stop updating purchases upon reaching one of those latter states.
Another good example of final units is products’ arbiter information. It can’t be changed after product creation transaction was mined. It includes the public key of arbiter that resolves disputes, the fee and the maximum time for customer to raise the dispute.
One could argue that introducing additional data layer breaks the very idea of blockchain as the only source of truth. Besides, you might say that database might get hacked with a lot less efforts than the whole blockchain.
However please keep in mind that this layer doesn’t replace native smart contracts constraints in any form. If somebody, for example, doesn’t have access to an arbitrage functions, they still can’t get it with any ‘database hack’ as this logic is coded only in the blockchain.
Also the database records can be compared to the blockchain at any time revealing any ‘lost’ or ‘tampered’ ones. In that case all the database can be recreated quite quickly with little efforts.
BCShop.io project aims to reinvent the way digital commerce and payments work today. Focusing on digital goods and services area project’s goal is to enhance it with fast-growing opportunities blockchain technologies and cryptocurrencies have to offer. In January 2018 BCShop.io hit hard cap of 2000 ETH at its token sale.
Website: https://bcshop.io/
Twitter https://twitter.com/BCShop_io
Telegram https://t.me/bcshopio
Facebook https://www.facebook.com/BCShop.io/
Business Inquiries [email protected]
