Evolute Consulting - Architecture & Process

• Permissionless Public Shared Systems: Also called Public Blockchain. All can join the network an all can write and read transactions from the network. There is no single owner, and each member has an identical copy of the ledger. Writes are validated through consensus mechanisms such as “proof of work” in order to establish trust. These mechanisms are computationally expensive and don’t scale well.
• Permissioned Private Shared Systems: Also Called Federated or Consortium Blockchain. Members for the network are whitelisted for both access and writing. There are multiple owners, thus the reference to consortiums.
• Permissioned Public Shared Systems: A hybrid system with whitelisted write authorization, but all transactions are publicly viewable. This is common in government e-platforms for citizens.

Blockchain Types (Pavel Kravchenko)

The principle behind blockchain technologies is composed of a 6-step process:

1. A member of the blockchain network requests a transaction signed with his signature (private key). If a member loses his private key, this could lead to that member no longer being able to request new transactions.
2. The transaction is broadcasted to all members of the network.
3. Each node in the network attempts validates the transaction and the requestor’s status against it individual copy of the blockchain using predetermined algorithms (usually a cryptographic puzzle such as for example "Proof of Work").
4. The first node to solve the puzzle shares the solution to all other nodes in the network.
5. After being validated, the transaction together with other verified transactions are stored in a block (consisting of the data, a hash of itself, and a hash of the previous block) that is added to all the individual blockchain copies in the network.
6. The transaction is complete.

PriceWaterhouseCoopers has a comprehensive infographic showcasing this process:

Blockchain Process (PwC)

As mentioned before, a Consensus Mechanism is a main component to establishing trust when there is no central authority. The main idea of this mechanism is to slow down the speed at which new blocks can be generated by asking each member of the network to perform a beforehand agreed-upon algorithm. The most notable of these is the “Proof of Work” algorithm of Bitcoin. There exist numerous other algorithms, such as the “Practical Byzantine Fault Tolerance”, Ethereum’s “Proof of Stake”,… The choice between these various mechanisms is determined by transaction integrity, fault tolerance and needed performance. With the consensus mechanism in place, a risk specific to it does arise. If at any point the needed percentage of nodes for a consensus is not online, this will delay the processing of the new block in the chain.

A recent addition to the blockchain technosphere are “Smart Contracts”. These are programs to be stored on the blockchain and have in them conditions and business logic for exchanging assets. These programs will autonomously take data inputs on and off the chain. It could for example be used to extend automated business processes across organizational borders. This topic has a lot more to it, but it is going to have to be a topic for a future thought.

As with every technology, it is important to understand when the cost and overhead of a DLT is sufficiently met with the benefits it imparts on the stakeholders. In April of 2018, the World Economic Forum published a white paper titled “Blockchain Beyond the Hype – A Practical Framework for Business Leaders” (mirror), where it proposes an 11-question decision tree to determine just that. A visual representation of this decision tree can be seen below. The main concepts that are verified in this decision tree are: a shared repository, multiple contributors, minimal trust exists between contributors, presence of intermediary entities, and transaction dependencies.

Several concerns need to be addressed when introducing a DLT, the most important of which are transactional integrity and security. The fist comes with the particular issue of mistake allowance. Seeing a DLT is immutable, a plan of action must be conceived of how to deal with a contributor introducing incorrect data, since it is essentially irreversible. For example, allowing a corrective transaction to be entered into the DLT, or extensive validation before allowing a commit.

Since there is a cryptographic fingerprint unique to each transaction, which is near impossible to fake, the main security issue comes from the consensus protocol verifying the correctness of the transactions. There are several ways this consensus mechanism may be targeted by malicious persons, but the most common are the following:

• Selfish Miners: Malicious miners can get an unfair advantage over other miners by tricking them into spending time on already-solved crypto-puzzles, getting a head start in this way.
• Eclipse Attack: Since nodes in a DLT need to stay in constant contact to compare data, an attacker could take control of a node’s communications in order to fool it into accepting false data.
• Hot Wallets: Since keys for crypto coin ownership are stored in digital wallets, it is easier to hack these wallets to obtain the coin this way instead of hacking the DLT system. This is evidently only applicable in specific cases.

If your organization is based in Europe, or has dealings there, there can be an additional concern involving personal data. In May 2018, Europe will enforce the General Data Protection Regulation (GDPR), which has some stipulations that don’t mesh well with blockchain particularities. In detail, there are two parts of GDPR that conflict with the distributed immutable nature of blockchain. The first is the aspect of GDPR that states personal information may not leave the territory of the EU. This clashes with the distributed nature of blockchain, where all nodes have a complete copy of the chain. However, this can be remedied by opting for a private or permissioned blockchain. However, the second aspect is the “Right to be Forgotten”. This aspect says that a citizen might demand all personal data that pertains to him, must be erased from digital records. This strikes at the core of blockchain, namely the immutability that is part of the trust generated in a blockchain. The quickest way to deal with this, is to store the personal information outside of the chain, and still guarantee the integrity by storing the hash of the information together with a reference to the actual location of the data. This type of solution does however add complexity and reduces the transparency and security. There is also an increased possibility for point-to-point connectivity.

Thought

EIM

Security

Comment