How to create your framework for choosing a blockchain solution (2 of 2)
This paper is about how to decide if blockchain is the right technology for your business and which are the criteria to consider when comparing different blockchain solutions.
Part #2 — Blockchain Framework: criteria for choosing a blockchain solution
Goal
The aim of this paper is to suggest how to approach blockchain analysis and how to do it concretely in order to evaluate whether it is the right choice for your business. It also provides a framework to be used to build up the metrics for comparing different blockchain solutions.
Scope
The paper is divided into two parts:
· Part #1 — Checklist to understand whether blockchain fits your business purpose and opportunities that arise
· Part #2 — Blockchain Framework: criteria for choosing a blockchain solution
Target
Executives wondering whether blockchain is the right decision and need a framework to compare different blockchain providers.
Blockchain Framework: criteria for choosing a blockchain solution
- Blockchain Types
Nowadays there is a great variety of types of blockchains. Some technology fit better with some specific use cases, other less. It is mostly a matter of tread-offs that are willing to accept. For example, find a balance between scalability and performance based on the need. Maybe its ok to reduce the scalability expectation in favour of performance or vice versa. This something you have to figure out during the designing phase of your system. Another example can be related to confidential data. If you don’t want data to be public you have to choose permissioned blockchain that is suitable for business where the enterprise wants to keep things private and give access only to specific parties. Do not use open blockchain where anyone can access freely like Bitcoin and Ethereum and all the transactions and data are visible.
2. Security and Privacy
Define the level of security and privacy you are willing and able to achieve. Both of them are always been a challenging aspect of a system design. It is important to recognize that there is not an absolute truth on these matters and there are always been different schools of thought even before blockchain. Define which are the mandatory criteria of choice for your product. What’s your product goals, what you can accept based on your risk management plan. For example:
● which is the algorithm used to encrypt the keys
● where PII and private key are stored
● type of key recovery model is used
● level of linkability between IDs created
● leak meta-data about specific attributes or relationships with identity providers/relying parties.
● how the identity is created, is the user free to create it, or it depends on an authority?
● how the identity is validated
3. GDPR compliancy
Privacy is an extremely controversial topic and there is a huge difference between the theory of GDPR principles and the practice. Below are highlighted some best practices. Consider them whether are in line with the complexity of your system:
1) Store PII off chain.
Currently, there are solutions in the market that store the PII on-chain and other off-chain. The solutions that store PII on chain are using encryption, or hash of the data. Both solutions are risky because what is secure today doesn’t mean that can be secure tomorrow. Encryption can be hacked and the hash of the information can be resolved. What you store on blockchain will stay there forever, personal data can be encrypted and become public forever. Consider also that if the data are stored off chain, the right to be forgotten is easily implemented since everywhere else the blockchain user data can be deleted.
2) Personal data must be processed in a transparent manner, this means ask to the data subject a valid consent that must be:
● freely given
●obtained through an affirmative act of the data subject
●revocable
● provable
3) Limiting the personal data that are collected, processed, and stored.
This means personal data collected for one purpose should not be used or repurposed for a new, incompatible purpose. Like, don’t share to 3rd parties.
●Ensure that the personal data that are hold and process is kept accurate and up to date.
●Personal data must be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data is being processed and kept.
4) The integrity and confidentiality principle is fundamentally concerned with data security and the security of processing.
The obligation attaches to all processing, whether by a controller, or processor and applies to both external (e.g. hacks) and internal (e.g. employees) security threats. One key technical or organizational measure for data security that is encouraged by the GDPR is pseudonymization, defined as “the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject.
5) Data Portability. The solution selected/implemented have to allow the customers to get their data back in order to be able to transfer them easily to another operator or supplier.
2. Consensus Mechanism
Consensus is a method to authenticate and validate a set of values or transactions without the need to trust or rely on a centralized authority. It is the way of ordering and verifying transactions, encrypted and stored into lined blocks. Some or all of these nodes verify and, if appropriate, execute proposed transactions according to an agreed-upon consensus algorithm. Consensus is crucial in distributed ledgers technology since lies at the core of its decentralized nature.
Consensus has two properties liveness and safety. Liveness means that each non-faulty node will eventually receive every submitted transaction assuming that the communication does not fail. Safety means that each node is guaranteed the same sequence of inputs and results in the same output of each node. There is a great diversity of algorithms for building consensus based on requirements like the following:
· Performance and scalability - refer to these parameters: throughput, latency, and number of nodes.
· Privacy - ensure that only the intended recipient can read the message.
· Governance -who propose the block, who add and create and verify it, how the peers communicate with each other, exchange messages.
· Security - there is diversity among the security features across vendors, driven by the design and base of the architecture. Evaluate the risks and vulnerabilities of the consensus algorithm is paramount since they are not being tested yet.
· Fault tolerance: the network operates efficiently and quickly, even if some node fails or is slow.
PoW (Proof of Work), the consensus mechanism used in bitcoin, ethereum, zchash, and monero, chose miners based on their computing power. The miner selected to verify that the transactions in the block are not conflicting. To attack the network more than 51% of computing power is needed. The second most well-known consensus is PoS (Proof of Stake), the consensus mechanism used in BFT — neo. ripple, stellar, hyperledger. With enough stake in the network, any account can become a Delegate Node, which verifies transactions. PoW is the only one that has been proven so far, although the scale which it has been proven is still too small to sustain the diffusion of applications on top of it, at large scale. What protocol is the best? every protocol is unique and needs to suit your use cases and system requirements.
3. Network effect
Network effects are a phenomenon whereby the value to the user or consumer of a product or service increases as its user base grows. The overall value delivered to users will exponentially grow if instead of having competing networks, everyone uses the same one. In order to achieve massive adoption, the aspects of the blockchain that have to be taken into account are the community that there is behind, investors, partnerships, developers, type of programming languages supported, open-source software, standards, barriers to access to the network.
● Open standards and software: organizations are currently working together to define industry standards or horizontally based on the use cases. For example, the identity.foundation is working with standards organizations like W3C and IETF, on four specific projects with 18 companies that share the core code, ledger neutral. The aim is to build cross-chain and open source software and to achieve identity for everyone and everywhere. It is common norms that enterprises become members of different consortiums and start working closely with them in order to build knowledge, realize the challenges, and understand if they can start from an existing solution or build up their own.
● Strong community — Developer's friendliness. The solution needs to attract developers with simplicity:
o Availability of APIs and SDKs. Easy integration with existing platforms
o Code in your preferred programming language
o No need to created new smart contracts
o Time needed to create a prototype
● Governance — Avoid barriers to enter the network. Define your governance upfront before diving into blockchain. How users and organizations will be added and how to determine if a user or organization should be cut. Define a mechanism that identifies a bad actor. Remember that the value of the service increases for each user, as others use it or join it, and that value is propagated on the very network that was created. The ability of a blockchain to succeed overtime is based on its ability to evolve. This evolution will bring about many decisions on direction, and it is the governance around those decisions that most strongly determine the outcome of the system. Are the participants able to join and leaving as they please?
4. Maturity of the solution
Are you looking for a solution off-shelf, or do you have the capacity to develop one yours in-house that is hybrid (possible only if the provider is open source)? Evaluate the development stage of the solution: the blockchain roadmap versus your product roadmap. Consider that lots of them are not in the mainnet yet, so the solution’s product roadmap must resonate with your product roadmap.
5. Operations cost
Not having operations cost yet available (or just a few) due to the early adopter's stage of the technology doesn't help in the calculation of the budget needed to build up a blockchain infrastructure: CAPEX and OPEX. If you don’t want to deal with hardware and setting up nodes manually, cloud vendors like Microsoft and IBM provide BaaS (blockchain as a service) approach where the operation cost will reside in the cost of the services that those solutions provide.
Amara’s law
We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.
Continue Reading
Part #1 — Checklist to understand whether blockchain fits your business purpose and opportunities that arise
