Key Points

1. focus is the new program model for smart contracts, IBM VSCode extension
2. v2x has new chaincode life cycle for multiple orderers, multiple contract endorsements
3. new Node SDK is completely refactored in v2x, won't be backported to v1x
4. Composer is deprecated but under v1.4x it can still be used to prototype solutions

References

Key Concepts

New Program Model for v2x

----------------------
hlf.maint>

- v2x next week
- features
external chaincode
LedgerAPI RFC =
https://github.com/hyperledger/fabric-rfcs/pull/16
GO SDK RFC =
https://github.com/hyperledger/fabric-rfcs/pull/14
Also the suggestion to adopt gh-pages to view RFCs... includes better rendering & full text search
https://github.com/hyperledger/fabric-rfcs/pull/15

use cucumber scripts for testing sdks

Node SDK refactor for v2x concepts

https://drive.google.com/open?id=1gTJHqGIlE8hzX3m6se-XfEr5HmSQEgH8

pdf   https://drive.google.com/open?id=1ZQreNwbZNsMxGeeDFLbeMrrDN03Lqe6f

Create blockchain network with Fabric v1x and Composer Tutorial

https://hub.packtpub.com/installing-a-blockchain-network-using-hyperledger-fabric-and-composertutorial/

https://drive.google.com/open?id=15ZlsmVhUxv7URL64Cea0KMs6qSOML4Gx

Create simple Nodejs smart contract on IBM blockchain network - Tutorial

https://developer.ibm.com/patterns/build-a-blockchain-network/

uses Nodejs, VScode IBM extension, IBM network

HLF Dev meeting 3/19/20

https://wiki.hyperledger.org/display/fabric

https://wiki.hyperledger.org/display/fabric/Fabric+Application+Developer+Community+Calls

past recordings, slides 

https://wiki.hyperledger.org/pages/viewpage.action?pageId=6423554

https://github.com/hyperledger/fabric#documentation-getting-started-and-developer-guides

------------------------------------
chris g k8s

https://github.com/IBM/Hyperledger-Fabric-for-Trusted-IoT

learn k8s
https://www.bretfisher.com/

docker compose
minikube for local
k8s services on provider

why k8s?
scenario - don't want to lose wallet ids if pod or node restarts - pvc

provision storage > pvc > access modes ... from hlf docs

vscode env testing

a> test minikube
a> tutorials
a> read helm charts, ansible playbooks
a> NEXT - ca mgt in k8s

ibm github repo has trusted iot to review

>> security - dns, ip, end pt, tls, pgp, vpn ? , authn, authz,

if HA, if svcs running, keeps ip address if pods deleted etc

redeploy a file ( a pod )

------------------------------------
wallets changes from v1.4 to v2.0

compare docs on wallets in readdocs

see github docs on wallets

goals in v2x

simplify changing persistence storage
storage formats in v2x simpler - not linked to node sdk

view v14 wallet

view v2 wallet

issue can't use old wallets in new env

-------------------
fs wallet migration tool as npm

npmjs.com/package/fabric-wallet-migration

npm package to mgirate fab wallets to v2 format

steps

1> create new fs wallet store for v2 after using fs for old wallet

fabric-network report
new sdk = 2.0.0-beta.4

wallet type demo'd was filesystemwallet

wallet decision
filesystem
memory
hsm
couchdbwallet

commiteventlistener

a> see github page - tutorial-wallet.html

------------------------------------
fabric net deployment tutorial with tls
------------------------------------

github.com/lepar/hyperledger-fabric-generic-network

uses tls

------------------------------------

a> key rotation in hlf docs?

------------------------------------

Blockchain is a Proof System

https://docs.google.com/document/d/15r8Hz40nJypvV4UwxpNlBRNKmWQXV5kFdj4xho_Bb9Y/edit#heading=h.3ygebqi

Key DLT features create a proof system

Essentially a blockchain system is a system of proofs. Not all solutions clearly require all the proofs a blockchain offers. Other solutions like a simple, centralized, secured database application or service may fit enough of the proofs required. As a solution architect, review each of the use case requirements and identify which proofs are specifically needed for that use case.

Often, if a DLT Solution is engineered correctly, the new solution can improve trusts between parties or in some cases, eliminate the trusts needed.

Look at the DLT features below. If some of these features are important and they aren’t addressed in your solution now, adding the right DLT services may improve your solution. Like databases, there are many types of DLTs. Not all DLTs support all of these features. For Enterprise DLTs, most of the features below are supported in some fashion.

1. Ledger - proof transactions not changed since write by smart contract
   provides a historically accurate record of every transaction state that has occurred
2. Distributed - proof data has been shared to authorized parties
   each organization has direct access to it’s authorized data from the DLT
3. Decentralized - proof the DLT governance is shared by members
   Governance of a DLT network can be centralized or decentralized to fit the specific use case. With decentralized governance, control and management responsibilities are shared by multiple parties.
4. Secure protocols - proof transactions not tampered with during processing
   ensures bad actors can access transaction data in flight or at rest
5. Signed transactions - proof who created transaction
   verifies the authorized account that signs a transaction showing who created it.
   A witness may validate the transaction signature.
6. Transaction Validation - proof transaction was independently validated
   Some DLTs allow flexible endorsement policies by multiple validators or endorsers. DLTs also support different methods for reaching transaction consensus. Some consensus methods add significant overhead reducing transaction performance for those networks compared to others using different methods. Replay attacks are prevented ( the “double spend” problem).
7. Smart Contracts - proof reads and writes to the ledger enforce business rules
   authorized user can execute a smart contract to create signed ledger transactions that is reviewed and approved by the assigned network validators before its committed reducing significant data threats from bad actors. On transaction finalization, the contract can return a result and / or fire an event to listeners depending on the DLT platform.
   Smart contracts can also query ledger transactions relatively efficiently.
8. Smart Contract events - proof business events shared to event listeners
   Smart contracts on better blockchains can support the event listener pattern.
   A contract can add application event listeners.
   When the event is fired in the contract, the event is sent to the event hub and distributed to the event listener applications.
   This allows automated integration of contract processing with dependent applications..  
9. Transaction Life Cycle - proof a write transaction was approved, committed
   DLTs have custom transaction life cycles. DLTs don’t normally use blocks or consensus for transactions.
   Blockchains will cover these basic steps on active ledger hosts:
1. Submit a proposed transaction from an application to a smart contract
2. Validate the transaction inputs
3. Execute the transaction generating outputs
4. Order the transaction output into a transaction block ( blockchain only )
5. Add the block to ledger
6. Return a transaction and block ID to the client application indicating the transaction has been posted to the ledger successfully or an error
10. Private Data -  proof only authorized parties can see data
    only authorized accounts can view the transaction details on the DLT ( eg a buyer and a seller can see a trade but no one else has access to the trade details )
11. Permissioned Access - proof that authorized parties only have access to DLT
    for Secure Financial Systems. At a minimum, registered users have  accounts with assigned public and private keys. Authentication methods may include access to the private key and or MFA ( Multi-Factor authentication methods ).
12. Token Transfers - proof buyer, seller conditions were met on contract execution
    Larger platforms are adding flexible support for custom tokens with policy and privacy support for many token operations ( issue, redeem, transfer ). 

For more details see slide 9 here:

https://docs.google.com/presentation/d/1dpzLBkx8MaOdzq_W5d246WCWizJ3QLQ6fugIvItXLQo/edit#slide=id.p9

Fabric event listener implementations

https://hyperledger-fabric.readthedocs.io/en/latest/search.html?q=events&check_keywords=yes&area=default 

Blockchain Value Proposition

Why DLT or Blockchain?

1. Often a better way to integrate business processes and contracts real-time
2. Peers run the same contracts on same data to add transactions to blockchain
3. Accurate, trusted copy of shared data that is immutable and permanent
1. If we enter bad data, we write a new transaction with the correct data
4. Apps use the “current” version of the data object unless they want ledger history
5. Permissioned blockchains validate identities and permissions applied
6. All transactions are signed using the originating users private key
7. Data privacy rules can be enforced wherever needed
8. Better transparency and traceability where needed on transactions, assets
9. Effective distributed business event service with application integrations

Fabric Tutorials

High-performance, secure, permissioned blockchain network. Code written in Go, chaincode (smart contracts) in Go, Javascript, or Java, SDKs in Node.js, Java, Go, REST and Python.

https://hyperledger-fabric.readthedocs.io/en/latest/getting_started.html

The Fabric application stack has five layers:

• Prerequisite software: the base layer needed to run the software, for example, Docker.
• Fabric and Fabric samples: the Fabric executables to run a Fabric network along with sample code.
• Contract APIs: to develop smart contracts executed on a Fabric Network.
• Application APIs: to develop your blockchain application.
• The Application: your blockchain application will utilize the Application SDKs to call smart contracts running on a Fabric network.

https://hyperledger-fabric.readthedocs.io/en/latest/install.html

Complete Fabric Full Stack Development and Deployment Tutorial

https://github.com/hyperledgendary/full-stack-asset-transfer-guide

• Show how an Asset Transfer smart contract can be written to encapsulate business logic
  • Show how the smart contract can be developed iteratively to get correct function in a development context
• Show how client applications can be written using the Gateway functionality
  • Show how the simplification of the Gateway programming model makes connecting applications more streamlined
  • Show how this streamlined approach improves resilience and availability
• Show how the solution can then be deployed to a production-class environment
  • Show how a Hyperledger Fabric network can be created and managed in Kubernetes (K8S) using automation
  • Show how the Fabric Operator and Console can be installed via Ansible playbooks
  • Show how a multi-organization configuration of Fabric can be created

Fabric is a multi-server decentralized system with orderer and peer nodes, so it can be quite complex to configure. Even the simplest smart contract needs a running Fabric Infrastructure and one size does not fit all.

There are configurations that can run Fabric either as local binaries, in a single docker container, in multiple containers, or in K8S. This workshop will show some of the approaches that can be used for developing applications and contracts with a minimal Fabric environment (Microfab), and how a production deployment can be achieved. There are other ways of deploying Fabric produced by the community - these are equally valid and useful. Feel free to try the others, once you understand the basic concepts to find what works best for you.

At a high-level remember that a solution using Fabric has (a) client application to send in transaction requests (b) Fabric infrastructure to service those requests (c) Smart Contract to action the transactions. The nature of (b) the fabric infrastructure will change depending on your scenario; start simple and build up. The smart contracts and client application's code will remain the same no matter the way Fabric is provisioned. There will be minor variations in deployment (eg local docker container vs remote K8S cluster) but fundamentally the process is the same.

Sample environment for the trading card app

We'll create a digital representation of these cards on the blockchain ledger. There are a few important aspects of this solution to consider:

• Ledger - The blockchain ledger on each peer maintains the current state of each card (asset), as well as the history of transactions that led to the current state, so that there is no doubt about the assets issuance, provenance, attributes, and ownership.
• Asset transfer smart contract - manage changes to asset state such as the transfer of cards between people
• Organizations - Since this is a permissioned blockchain we'll model the participants as organizations that are authorized to run nodes or transact on the Fabric network. Our simple network will consist of an ordering service organization and two transacting organizations.
  • Ordering service organization - runs the ordering service to ensure transactions get ordered into blocks fairly, this may be a consortium leader or regulator in the industry. Note that ordering service nodes could also be contributed from multiple organizations, this becomes especially important when running a Byzantine Fault Tolerant (BFT) ordering service.
  • Owner Organizations - Each owner organization is authorized to run peers and submit transfer transactions for the cards (assets) that they own.

trader-typescript, a much improved version of using the Gateway Client to interact with the ledger.

Have a look at trader-typescript, a much improved version of using the Gateway Client to interact with the ledger.

When connecting to the gateway, it is preferred to set up a gateway service alias, which can be used to connect and load balance across peers in an org.

This sample sets up the correct patterns for working with the ledger.  It needs a Docker build example, but should be straightforward to prepare a container as a simple node application.   When running in k8s the env can be set up to refer to secret volume mounts, etc. to pass in the correct user context as local files mounted in the pod.

full Fabric Samples list - readme is excellent

https://github.com/hyperledger/fabric-samples

Resources

• Main documentation
• Getting Started for application developers
• Contributing to Fabric and related sub-projects
• Design docs
• Videos on YouTube for Hyperledger Fabric. Includes informational and playbacks. Subscribe to be automatically notified when new videos are posted.
• Getting Started in CI - Debugging CI jobs failures

Project Management

• GitHub board

Repository

• fabric GitHub repository
• Sub-project and related repositories

Releases

• The Hyperledger Fabric Roadmap outlines the next release themes.
• Fabric Release Exit Criteria details our release checklist
• Fabric Release history provides the list of releases

Links

• Documentation - extensive documentation, tutorials, reference, architectural concepts
• Stackoverflow Q&A
• RocketChat
• Mailing list
• Fabric Maintainers

Build NFT on Hyperledger Fabric tutorial

https://wiki.hyperledger.org/display/events/Build+Your+Own+NFT+with+Hyperledger+Fabric

Build Your Own NFT with Hyperledger Fabric

Time:

• Thursday, March 24 from 11 AM to 1 PM Eastern
  
  • Register for 1st session: Introduction to Blockchain and NFT Concepts
• Thursday, March 31 from 11 AM to 2 PM Eastern
  
  • Register for 2nd session: Hands-on Technical Workshop with the NFT Marketplace Lab

Workshop description:

This two session workshop will start with an introduction to blockchain and NFT concepts and is appropriate for both a technical and business audience.  In particular, this session has been created for faculty interested in teaching about blockchain and NFT in their courses.  Join the first session to get an overview of how blockchain is being used in real world examples and learn more about non-fungible tokens. The topics for the first session will include:

• What is blockchain?
• What are tokens? What is an NFT?
• Technology landscape overview (enterprise perspective)
• Use Cases / Examples
• Obstacles
• How does this apply to you?  What skillsets are needed?
• Q&A session

This video about blockchain and NFTs from UCLA Professor David MacFadyen covers some of the basics to help you understand this new technology.

The second session is a technical workshop for developers that want a hands-on experience.  You will need to be familiar with the material from the first session to get full value from this technical session.  The second session will include:

• Basics of the Auction App which will be used in the workshop
• Auction App versus Typical public blockchain implementations 
• Auction App code structure
• Hands on using the app - Launching, Registering, Creating an NFT, Transfer Transaction
• Home work on adding changes to support another type of media (e.g., music)
• Engaging with the Community and the Lab

The auction application code is being donated to Hyperledger Fabric Labs so it will be available to HBCU and the broader community to download, learn, and enhance outside the workshop.

Participants in the hands-on technical session will be able to fully participate if they meet the following requirements:

• Details to be posted soon and emailed to registered attendees
  

One of the workshop facilitators will be available to answer any questions regarding the technical aspects of the workshop in advance during the following times:

• Details to be posted soon and emailed to registered attendees

General questions about the workshop can be sent to the Hyperledger Community Architect team.

Potential Value Opportunities

Potential Challenges

Candidate Solutions

Blockchain for Digital Transformation

https://www.udemy.com/course/blockchain-for-digital-transformation/

Baiju Jacobs

University course on Fabric and Enterprise Blockchain Technologies

https://github.com/hyperledger-labs/university-course

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles