Key Points

1. blockchain at a minimum is DLT - decentralized ledger technology
2. an immutable ledger provides a trusted ledger of transactions for all participants in the network
3. like any technology, blockchain can add real value when applied correctly to the right use cases
4. public blockchains
   1. Bitcoin and Ethereum are the 2 most popular public blockchains
   2. Ethereum offers smart contracts to provide common business logic controls on transactions
   3. Ethereum could also be implemented as a private blockchain when needed
   4. public blockchains allow anyone to participate
   5. public blockchains normally provide a degree of anonymity for participants but everyone can see all transactions
   6. public blockchains with a high number of commit nodes typically have poor performance
5. permissioned blockchains
   1. permissioned blockchains are normally private and require participants to enroll through member services
   2. permissioned blockchains require read and write permissions to access the blockchain
   3. permissioned blockchains normally have identified participants
   4. participants are added through membership services
   5. transactions may be private between specific participants but macro demand is often public

References

Key Concepts

Cloud Services Models

cloud-xaas-models-compared-cf.PNG

Structured Platforms

1. Abstract the operational processes of application deployment away from developers and app teams.
2. Can be deployed across private and public clouds
3. Capabilities like service brokers, monitoring, scaling, etc. are integrated natively.
4. Examples: Cloud Foundry Application runtime, red Hat openShift, Apprenda, etc.

UnStructured Platforms

1. Provide control and autonomy for app teams and developers over app deployment workflow.
2. Can be deployed across private and public clouds.
3. Capabilities like service brokers, monitoring, scaling, etc. must be developed or delivered by additional services.
4. Examples:Cloud Foundry Container runtime, kubernetes, Mesosphere, Docker, Tectonic, etc.

Kubernetes Fabric Deployment workshop

https://github.com/aidtechnology/hgf-k8s-workshop/tree/master/prod_example

Covers manual setup of a blockchain network, kafka, kubernetes, CA administration etc

Public vs Private Blockchains Revisited - 2019 article

https://medium.com/coinmonks/public-vs-private-blockchain-in-a-nutshell-c9fe284fa39f

Brian Behlendorf - 2018

• public or private defines who can read the blockchain
• permissionless or permissioned defines who can write to the blockchain

The open versus closed brings in to consideration who’s able to read that data.

And so, we can talk about solutions which are public and open, public and closed, private and open, private and closed.

replace open / closed with permissionless / permissioned in the chart below ...

Pubilc blockchains can be permissioned ( eg Ethereum ) but lack the tools Hyperledger, Corda provide

Public blockchains normally provide anonymity.  Private blockchains require identified participants.

Private blockchains need identity management

Most of the time, private blockchains tend to come with identity management tools or a modular architecture, where you can plug in your own identity management solution. This can be anything from a Membership Service Provider to an OAuth solution using Google, Facebook, LinkedIn, etc.

Motivations in public blockchain

We rely on economics and game theory incentives to ensure that everybody in the system behaves honestly and according to the rules.

We set up situations through group consensus, through which honest participants are economically rewarded, where dishonest ones only incur work or cost, with no possibility of ever recouping that cost.

Motivations in private blockchain

we know who an individual is, what organisation they’re associated with and what their role is, we also assume that they’re going to behave fairly, because if not, we know exactly who’s misbehaving and they know that they’re gonna suffer the consequences for that.

False assumption on who can see transactions in private blockchain

Transactions are not publicly viewable (transparent) in the blockchain, and only selected nodes can access the ledger.

Examples include: R3 Corda, which can transact between nodes, and the rest of the blockchain does not participate

Fabric allows control over what transactions and related demand are visible to others on a blockchain

Good article on basic concepts of public — private and permissionless —  permissioned blockchain features. Nicely shows they address different use cases normally. When I look at use cases, I find Hyperledger Fabric provides the granularity and options to address a very wide set. A good example in the article is transaction data. With Fabric, I can decide on a supply chain what data is private and what is shared with everyone ( usually macro demand ).

A private, permissioned blockchain is more than just a secure database. It provides the provenance and proofs on transactions that increase trust among participants.

Blockchain Layer Models to Improve Scaling, Performance

https://forkast.news/what-is-layer-3-key-to-blockchain-future/

Layer 1s are characterized as the foundational blockchains like Bitcoin and Ethereum that have their own native cryptocurrency used to reward those who work to secure the network itself.

Layer 2s are protocols built on top of L1s designed to increase transaction speed and mitigate scaling difficulties of layer 1s while leveraging the security of the base chain. For example, Arbitrum is an L2 created to improve Ethereum’s speed of processing transactions as well as overall flexibility and scalability, and it has given birth to a broad range of DeFi protocols.

Layer 3s, on the other hand, offer even higher levels of customizability. At this layer, developers can carry out customized designs that L2s cannot easily achieve, especially for lower-cost execution and privacy-preserving functionalities.

• use cases are for custom blockchain solutions, not general purpose blockchain solutions
• L3s enable customized scaling and realize important functionalities — such as privacy — that L2s can’t effortlessly achieve on their own. L3s increase computation speeds and scalability of single applications by not having to share ZK-circuits with other applications on a single chain.

The current L2 serves as a general-purpose scaling, while L3 accomplishes customized scaling. 

For example, an L3, which adopts customized circuits depending on the demand of a specific decentralized application, can achieve better performance. Another example is Validium as L3. This design provides higher levels of throughput at a relatively low cost for decentralized apps by avoiding pushing compressed data to the L1 and utilizing validators to secure the digital asset. L3s can be employed as low-cost and high-performance scaling solutions that allow projects to have more choices for potential solutions, depending on their particular use cases.

L3 challenges now

1. One of the main challenges is the lack of standardized infrastructure for L3s. Since L3s are built on top of L2s, they require a standard infrastructure to operate efficiently. 
2. more development in ZK-rollup technology, which is the underlying technology for L3s. ZK-rollups have the potential to significantly improve the efficiency and scalability of L3s

How to use Blockchains for a specific use case?

Andy Martin

https://www.linkedin.com/posts/andy-martin-387188a_blockchainthoughtfortheday-tokeneconomythought4theday-activity-6988468305934098432-f06V?utm_source=share&utm_medium=member_desktop

I think there are clear use cases for private blockchains in addition to public ones - not just for ERP integrations. In my experience, engineering success assumes that we have a set of tools ( public, private, permissioned, permissionless blockchains, message services, other protocols, other methods of sharing information etc ) that we just assemble to fit a specific use case. Blockchain is only part of the picture, it's the use case which includes trust engineering that drives solution design, not the technology.

Engineers don't use just one type of data store for a solution. The same concept applies to blockchains. You use what is needed to fit the use case. Improvements are needed for consumption of blockchain service layers to reduce the work needed by most blockchain platforms today. Yes many different teams are working on this effort currently. I tend to lean toward the open source platforms like Hyperledger where that work is often more visible and consumable.

Potential Value Opportunities

Potential Challenges

Candidate Solutions

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles