• Welcome to the Online Discussion Groups, Guest.

    Please introduce yourself here. We'd love to hear from you!

    If you are a CompTIA member you can find your regional community here and get posting.

    This notification is dismissable and will disappear once you've made a couple of posts.
  • We will be shutting down for a brief period of time on 9/24 at around 8 AM CST to perform necessary software updates and maintenance; please plan accordingly!

Brianna White

Administrator
Staff member
Jul 30, 2019
4,655
3,455
There is considerable interest around blockchain these days and for good reason. The innovative characteristics of blockchain-like decentralization, immutability, transparency and automation are extremely useful for many industry verticals and will inspire the creation of a multitude of use cases. However, blockchain technology is still in its nascent phase. While cryptocurrency platforms like Bitcoin and Ethereum are gaining popularity, the adoption of blockchain into the mainstream software industry is still somewhat limited. But an increasing number of technology companies are making the decision to leverage the unique value of blockchain in their products.
I have worked on blockchain implementations for companies in many domains. If you are considering using blockchain, I’ve found there are seven key decisions necessary to successfully implement a blockchain in a product.
1. On-Chain or Off-Chain
One of the key architectural decisions while working on blockchain-based products is to understand where to go off-chain and where to go on-chain. This is an essential consideration when transaction data and business validation logic play a crucial role. The primary constraint is the network latency due to the data replication across the blockchain network. The degree of latency keeps increasing when the levels of data replication expand. To determine whether to on or off-blockchain, here are some general guidelines:
  • Data that is either directly required for transaction validation or needs auditability should be stored on-chain. It is better to store referential data off-chain.
  • If eventual consistency is good, it is possible to develop transactions off-chain and update only the first and last state on-chain. This will increase overall throughput without utilizing additional network resources.
Public or Private Permissioned
Another important decision is the scope/access of the blockchain itself, ranging from an open and permissionless system to a private and controlled one. Public Blockchains are useful where the users are anonymous and equally. Public chains require a community around them to ensure that no one person has the authority to change rules. They need to be community-driven and a single user cannot change the rules of the entire network. However, a large number of nodes may limit the throughput of the transactions. It is better to have some incentivization to carry out effective processing.
Permissioned Blockchain platforms control who can write/read on the blockchain. If you compare them with public chains, they are scalable. Permissioned Blockchains are suitable when controlled governance and compliance/regulations are important. Popular examples of a public permissionless chain are Ethereum, Bitcoin. An Insurance claim processing platform is a good use case to exemplify private permissioned blockchain.
Continue reading: https://www.analyticsinsight.net/7-decisions-that-can-make-or-break-a-blockchain-implementation/
 

Attachments

  • p0007133.m06787.7_decisions_that_can_make_or_break_a_blockchain_implementation.jpg
    p0007133.m06787.7_decisions_that_can_make_or_break_a_blockchain_implementation.jpg
    144.7 KB · Views: 33
  • Like
Reactions: Brianna White