vi

Key Points

1. why blockchain ?  Brian Behlendorf podcast

KAFKA

RAFT

gRPC

DID ??

1. Fabric privacy models
   1. channels
      1. Channels are used when information is not desired to be shared with the entire network
      2. limited value - can work for application segregation ( eg inventory = channel A, Sales = channel B etc )
   2. private data
      1. private data database is operated alongside the ledger to store private data that may be referenced, ensuring private information remains private.
   3. zero knowledge proofs to validate information without revealing the details
      
      1. zero-knowledge proof technologies enable a party who possesses private information to prove to another party that the information satisfies a certain set of properties without revealing the information
   4. missing >> default one to one shared data ( eg Corda )
      1. by default all 1000 nodes create one to one connections ( not distributed like Fabric )
      2. Fabric channels way too cumbersome to administer for many one to one relations
      3. query all or query all subset should be a logical scope on the network to see ledgers across N orgs
2. External Chaincode
   
   1. chaincode that executes outside of a Docker container using new build packs for /design /build /test /deploy /run
3. more

References

Fabric Blockchain Application Conceptual Architecture

Fabric Feature docs

- interop doc
https://gerrit.hyperledger.org/r/c/fabric/+/31618
- confidential private data fixes
https://jira.hyperledger.org/browse/FAB-7593
- nodejs ioc
https://jira.hyperledger.org/browse/FAB-12430
- new pgm model
https://jira.hyperledger.org/browse/FAB-11246
https://docs.google.com/document/d/1_np3fnT_OludRGcF3PbubDooNsH8J-_G7UaWhk8a_cU/edit
https://github.com/mbwhite/chaincode-commericalpaper
- private local collections
https://jira.hyperledger.org/browse/FAB-7593
local scope collections
https://docs.google.com/document/d/1qOAnEudmvxJ3D6cbyKfd6KGuJtlv4w72LH-DqK6QIKc/edit#heading=h.hu2ryrc3bn5u
- state based endorsement
https://jira.hyperledger.org/browse/FAB-8812
- rework ledger architecture for endorsement
https://jira.hyperledger.org/browse/FAB-758

Key Concepts

Execute-Order-Commit process

After transaction commit completion notification, validate block hashes the same on peers if desired 

Each peer logs its block commit hash every block at INFO level. The block commit hash is a hash over all valid transactions that are written to state database. So you can compare block commit hashes across peers to ensure no fork. Look for a peer INFO message every block containing 'commitHash', e.g.:
commitHash=[0d01cbc2d186675855d5b52f2bda5050ff7238d2527062d0fd5c0a8220d817fa]

Some users do like to validate query results by querying a 2nd peer to ensure they get the same results, that certainly is a valid pattern for critical applications.

Related upcoming work:
https://jira.hyperledger.org/browse/FAB-106 - A 'checkpoint' feature will allow peers to bootstrap a channel from a known good state without having to process all prior blocks since genesis block. The feature can also be used to compare global state across peers.
https://jira.hyperledger.org/browse/FAB-33 - BFT for ordering service to ensure a sufficient number of ordering service nodes sign off on blocks.

We will socialize RFCs for these proposed work items once they become available.


Thanks,

Dave Enyeart

Fab-token process model

Hi Sheehan,

One of the triggers for the deeper evaluation around post-order execution is in fact the operations support proposal from State Street. You made the point on one of the playback calls that we shouldn't hold up operations support while at the same time squeezing token processing into the current validation/commit code path. The maintainers agree and are acting on that feedback. We are taking a look at the broader post-order execution strategy so that various processing models can be supported beyond just token processing.

In terms of collaboration, the best place to start would be the design document under FAB-12221 related to improving the validation/commit path: https://docs.google.com/document/d/1BBVA8u-GJ99ZYRT015PAnMVK4_pKv53Y-kiP9lZX8Gc/edit

I'd say digest that first and then let's have a deeper conversation, either in the doc or regular maintainer call or web conference. It is actually good timing - with the v2.0 lifecycle work winding down, focus is shifting to the validation and post-order execution work items. As mentioned on the last maintainer meeting, v2.0 will not be rushed out to hit an arbitrary date. The focus is on getting the codebase, along with test suites and CI, into a state that is easier to maintainer and extend, before incrementing the next major release number. In the interim, quarterly releases will continue on the v1.4.x LTS release for critical fixes and improvements.

In terms of the fate of the alpha token code, the code paths will either be disabled or removed before the v2.0 release, depending on how much we think it can be leveraged for the broader post-order execution work items.


Dave Enyeart



​1​ Recap

​1.1​ Fabric Transaction validation model

​1.2​ Initial implementation

​1.3​ Additional minor nuances

​2​ Key level endorsements and challenges

​3​ New upcoming features and challenges

​4​ Proposed Refactoring

​5​ Problems with Operations Support in current form

In this document, first, we recap the fabric transaction validation model and the initial implementation that supported only chaincode level endorsement policies. Second, we discuss the challenges that were introduced by the feature key-level endorsement and how the initial implementation was limited to incorporate those demands. In this section, we also discuss the modifications that were done to the initial implementation in order to support key-level endorsements (i.e., the  current implementation) and the resultant complexity and limitations that this lead to. Third, we discuss the demands from some of the upcoming features and how the current implementation is limited to cater some of those demands. Finally, we propose a refactoring that should support the new demands and should be able to remove some of the complexity.

Validation-Commit Rework.docx

A high level three step flow of the block validation and commit comprise as follows

1. Coordinator (gossip) passes the block to validator that performs endorsement and other checks
2. Coordinator collects private data (currently for only the transactions that are found valid in the step 1 above, but will be collected for invalid transactions in future releases to support reprocessing scenarios)
3. Coordinator passes the block and private data to ledger for mvcc validation and commit.

Opportunity to reuse data in secured cache

Steps 1 and 3 modifies the tx-validation-codes in the metadata section of the block. The input and output to each of the above is the block and hence it requires unmarshalling the blocks data multiple times. Though, this itself is not as big a problem to solve and can always be solved by introducing a wrapper that wraps the block and keeps the already unmarshalled content in a cache to reuse across phases, still this is good to mention here.

Fabric Transaction Cycle Overview diagram - v1x

https://hyperledger-fabric.readthedocs.io/en/master/txflow.html

Fabric Transaction flow v1x - low-level client control

Fabric Interoperability Solutions

There are multiple Hyperledger blockchain projects. Some provide a blockchain execution platform ( Fabric, Sawtooth, Iroha, Burrow ) and some provide services to platforms ( Composer, Explorer, Cello, etc ).

There are different conceptual models for Interoperability that fit different use cases for interoperability.

Interoperability use case examples

Atomic swaps

• the basic atomic swap for tokens - a very limited use case defined by ILP

Contract A calls Contract B - read-only

• Contract A calls Contract B to check a customer credit limit before opening a new order

Contact A calls Contract B - read and write

• Contract A creates an accident report on Govt DLT and calls Contract B to update a related insurance claim on an insurance DLT

Dynamically connecting new nodes to a network

• Node A on Network N provides a gateway connection for Node B to join Network N

Interoperability use case requirements for 2 separate DLTs

1. smart contracts defined and understood by both DLTs
2. common semantic data models defined and understood by both DLTs for shared data
3. dynamic directory services to establish overlay networks
4. policies that allow nodes to participant in both networks
5. nodes connecting to a DLT have valid identities and permissions on those DLTs
6. each DLT has a consensus governance model in place for that DLT
7. all transactions created by smart contracts crytpographically signed by the required parties
8. logical transaction boundary that can incorporate related transactions on all DLTs and guarantee finality
9. shared, secure, private off-chain data across DLTs effectively when required by a use case ( not all use cases need this )

Tong Li - Fabric Interoperability Feature - v1.4x

https://github.com/hyperledger-labs/fabric-consortium-management

Interoperability Scenarios Defined Today

Client applications connect blockchains using multiple connections and contracts

In almost every case, interoperability can be done at the client application layer regardless of the blockchains involved.  The client application can connect to 2 different types of blockchains concurrently, transact with each and act as a middleman providing 2-way transaction updates across the blockchains. An Ethereum blockchain could be connected to a Fabric blockchain this way.

example

If I have a Fabric blockchain for an auto dealer supply network and an Ethereum insurance network, my client app could sell a vehicle from my dealership to another dealer using a Fabric smart contract and call the a smart contract on the insurance network to cancel an existing policy on the vehicle.

Interledger Protocol for Payments

ILP - Interledger protocol is a simple payments protocol only for interoperability between 2 blockchains. The only scenario supported is an atomic swap payment that will update both ledgers state synchronously.

example

Ledger A pays Ledger B an amount X.

This model is limited and not related to normal interoperability use cases.

See Hyperledger Quilt for more - https://www.hyperledger.org/projects/quilt

Smart Contract Oracles - read only access using another contract in the same blockchain

Fabric, Ethereum and other blockchains support smart contract A calling smart contract B on the same blockchain platform. This is typically in a read-only access.

example

If smart contract A is entering an order, contract A can call smart contract B to check a customer's credit limit to see if the order is valid. What normally can't be done in that scenario is contract A calling a contract C that updates the customer's open credit balance when the new order is placed.

See

Adding new organizations to a Fabric blockchain network

Fabric has features to support adding new organizations to a Fabric blockchain easily. Service discovery allows blockchain components to find new assets on the network dynamically. The new interoperability feature makes it easy for an admin to add new organizations to an existing network. If network A has 10 suppliers on the blockchain and we have a network B with 4 suppliers, it's easy to add network B to network A using an interoperability configuration in the admin dashboard.

See 

Interoperability between 2 Fabric blockchain channels

Fabric supports channels in a Fabric blockchain. Each channel has a physically separate blockchain.

example

This can be useful an auto dealer network had inventory management on blockchain channel A and payments management on blockchain channel B. In that scenario, selling a vehicle on the inventory channel with smart contract A1 could invoke a smart contract B1 to execute the payment by the buyer for the vehicle.

See Fabric Interoperability Group - https://wiki.hyperledger.org/display/fabric/Fabric+Interop+Working+Group

See Fabric Interoperability Test - https://wiki.hyperledger.org/display/fabric/Interop+Test

See Fabric Interoperability Docs - https://wiki.hyperledger.org/display/fabric/Interop+Documents

See Fabric Interoperability Patterns - https://wiki.hyperledger.org/display/fabric/Interop+Patterns

https://wiki.hyperledger.org/display/fabric/Interop+Patterns?preview=/6429045/6429050/interop_patterns_v0.1.pptx

See this very limited example for atomic swaps on 2 Fabric channels - https://blockchain-fabric.blogspot.com/2019/02/fabric-interoperability-atomic-commit.html

Interoperability between Fabric blockchains and Ethereum contracts

Planned support to run Ethereum Solidity contracts in Hyperledger Fabric using the Burrow EVM

Many DApps (Decentralized Applications) written in Solidity or other EVM languages can benefit from being able to run in a permissioned blockchain like Fabric with minimum modification.

Ethereum created the Ethereum Virtual Machine (a.k.a EVM), a Turing-complete stack machine, to execute smart contract in EVM-bytecode, which is compiled from high level languages, such as Solidity, Serpent, LLL, Mutan and Viper. From the EVM point of view, once those programs are compiled into EVM-bytecode, original choice of language is irrelevant.

EVM is currently part of Ethereum codebase, which is licensed under LGPL-3.0.

Burrow is a permissioned blockchain framework that has its own EVM implementation that is Apache 2.0 licensed, so that programs written in those smart contract languages can run in a consortium chain leveraging a Hyperledger project such as Sawtooth or Fabric, instead of a public chain such as Ethereum.

https://wiki.hyperledger.org/display/fabric/Fabric+Chaincode+EVM

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

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

IBM principles for blockchain

http://formtek.com/blog/blockchain-key-ingredients-needed-to-be-viable-in-the-enterprise/

The Five Principles for Blockchain outlined by IBM are as follows:

1. Open
   Use of Open Source promotes innovation and better quality code
2. Permissioning
   A permissioned network promotes trust and confidentiality. Unlike anonymous blockchains like Bitcoin and Ethereum, illegal activity can be controlled.
3. Governance
   Universal and transparent governance ensures that the network is not abused and serves the needs of its users.
4. Standards
   Use of interoperable standards encourage innovation. Today’s blockchain implementations are primarily independent entitites.
5. Privacy
   Blockchain should be able to control who can access data and when. Privacy regulations, like GDPR, also need to be complied with.

Fabric Internal Architecture - v1.4x - IBM au

https://github.com/IBM/hlf-internals

https://github.com/IBM/hlf-internals/blob/master/docs/index.md

This documentation is organised into four main sections:

• Overview: this section provides an overview of the architecture and the key design principles adopted by Hyperledger Fabric to implement the execution and management of smart contracts. It discusses the rationale, benefits, and advantage of the approach and it introduces the the key concepts of shim and chaincode stub.
• Interaction Protocol: this section dives into the details of the chaincode-peer interaction protocol and discusses the various phases of the protocol, from the connection establishment to the execution of transactions. It also provides an overview of the messages exchanged and their meaning.
• Shim Architecture: this section dives into the implementation of the fabric chaincode shim, which is the process that hosts the smart contract and interfaces it with the Fabric peer. The section discusses the architecture, design, its key components and the protocol used to interact with the peer. If you want to know how GetState, PutState, GetStateByRange and other methods work look in here.
• Peer Architecture: this section discusses the internal architecture of the peer, its breakdown into subsystems and components. It details how these are involved and participate in the manageemnt of the life-cycle of the chaincode and the execution of transactions. If you want to know what happens when a client submits a transaction proposal, look here.
• Support for New Languages: this section provides an overview of the key components that need to be modified and implemented to enable Hyperledger Fabric with the ability of managing chaincode in another language than Java, Node, or Go. If you want to get to the action and see what takes, jump here.

What You Need To Know

This documentation assumes that the you have a general understanding of Hyperledger Fabric, its key components, and the transaction execution flow, as a user of this platform. If you need a refresh on these concepts, have a look at the Key Concepts section on the Hyperledger Fabric documentation.

Justitia - management and deployment on Fabric networks

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

Justitia helps consortium members generate and maintain all of their certificates, easily deploy and maintain their own nodes. On the other hand, it helps users manage the configuration of consortium and channels, including configurations such as members and policies.

we urgently need a tool to help us manage the identity, nodes, channels, and consortium members on the fabric.

ustitia not only helps affiliate members manage all of their identity data in the federation, but also helps users deploy fabric nodes, dynamically create and manage channels, and members of federation.

This project uses Fabric ca manage and maintain organizational identity information, and maintains and monitors Fabric nodes by using docker's http PAI, and maintain data on the fabric network through fabric-sdk-java. The structural design of the project is divided into four parts, as shown in the following picture. The DB/File is used to store identity data including certificates and private keys. Service defines some business modules that are provided to the Scheduler call. The Scheduler performs identity verification and defines a series of REST interfaces; the WEB provides data display and service calls through the REST interface provided by the Scheduler.

• Dao serverProvide data storage and read interface, you can customize to use different databases according to your needs, MYSQL is used by default.
• Fabric serverThe fabric-sdk-java is packaged to provide some simple service interfaces.
• Chaincode serverProvides chain management capabilities such as installation, instantiation, and upgrade with the Fabric SDK. Chain code installation supports uploading local source files and getting codes from the code repository.
• Node serverBy calling Docker's Rest API to create and manage node containers, users can dynamically adjust the number of nodes as needed. When deploying a node, the system provides a default configuration for the node, and the user can also override the configuration according to the actual situation. The system monitors the status information of the node. When the status of the node is abnormal, the system notifies the administrator to handle the situation through email or SMS.
• Identity serverThe maintenance of identity information is done by means of fabric ca, including registration, renewal and revocation of certificates. In the database, we store the certificate and private key so that when the user needs to deploy a new node or use a new client user, the service can provide all the required certificates and private keys. When the certificate needs to invalidate the original certificate due to the leakage of the private key, etc., the system can help the user revoke the relevant certificate and update the CRL to the channel configuration.
• Channel server

  Channel services manage a member of consortium or channel by submitting channel configurations.

  The consortium administrator who holds the private key of the administrator of the orderer can manage members of consortium by modifing the configuration of the system channel. The applicant generates configuration data including the identification information of the organization by the system, and then sends it as an application material to the consortium administrator through other forms such as mail.

On the other hand, the process of endorsing by the organization administrator user cannot be done on the chain. It is too complicated to introduce a centralized service to help complete the signature process. In order to solve this problem in the chain, we added a system chain code CMSCC (channel manager system chain code) to the implementation of this signature process. The process of joining a member as shown in the figure below is similar to the process of joining a consortium

Fabric Gardener - oracle for external data access on blockchain

https://wiki.hyperledger.org/display/HYP/Gardener

Gardener is a modular and secure oracle node implementation for transferring external data into a blockchain. It allows for the integration of multiple data sources and security features from which an oracle node can be containerized. Gardener provides the libraries and integrations for the data sources, security features and integration to Hyperledger Fabric.

The initial contributions to Gardener have been made by Espeo Software (espeo.eu). It is licenced under the open source MIT license and the source code can be found at https://github.com/EspeoBlockchain. 

Gardener is a free to use, fully open source oracle node implementation. It is important to have a modular solution that can be deployed easily and integrated to any blockchain. This will ease the development work and allow for a secure way for accessing off chain data.

The ongoing work tasks include:

• Hyperledger Fabric integration
• IntelSGX remote attestation 
• Proven off chain computation

Our code is available at https://github.com/EspeoBlockchain. 

Gardener project consist of 2 main components and 1 support utility. The first main component is a set of smart contracts (or chaincodes) with the main one called Oracle and others, which act as helpers. All requests go through the Oracle contract, which knows how to handle each of them. The responsibilities of the Oracle contract are request validation. This means checking that the entity performing the request is valid and that the parameters of the request are correct. It also issues events about new requests and proxies the requested data back to the correct address. Contracts using the oracle have to be either extending Gardener using the Oracle contract or at minimum following its interface. 

Gardener offers also wrappers for other oracle solutions like OraclizeIT to allow users to easily migrate from SaaS solutions to Gardener without changing implementation. Wrappers are translators between the backward compatible interface of another oracle into the interface of Gardener oracle  (currently only OraclizeIT is supported, but others can be added easily on demand).

The second main component of Gardener project is the Gardener Server. It is the off chain entity that fetches and passes the information that was requested by the Oracle contract. It was designed using a hexagonal architecture approach. This means that in its core it keeps business logic of its behavior and all the technical implementations are external. Because of this new integrations can be added very easily by just writing the technical integration. This means that integration of, for example, a new blockchain, storage or data source is easy and does not require modifications to the main flow of the application. 

The main flow of the server application looks as follows: the server listens for new blocks in a given blockchain. If new blocks appear they are checked for events related to oracle requests. If there are any, the events are saved into storage (all requests are saved regardless if they are delayed or not). We use the system scheduler Cron for checking the saved events for delayed requests. Cron periodically asks storage for requests, which are ready to execute. The requests which are ready are parsed from the stored string request. After parsing the request the requested data is fetched and the received response is filtered using one of commonly known filtering patterns. Currently we support JSONPath and XPath supported for filtering. Finally, the filtered data is then pushed to the blockchain as a new transaction.

The third component, the helper for the main components, is Gardener Monitor. It helps to look at incoming requests and outgoing responses. It connects directly to Oracle contract and monitors state changes in it. It is designed to help during development as a GUI interface and in the future we plan that it would also allow to check proofs or executed processing.

Currently the only supported blockchain is Ethereum. However, Gardener team is on their way to introduce a Hyperledger Fabric integration. Thanks to the architecture design described above that integration should not be much time-consuming. We are currently working on writing the complementary chain codes which have the same responsibilities as smart contracts written for Ethereum. By doing so we will add a Hyperledger Fabric integration into the Gardener Server. Some Proof of Concept work was already done and now the result of it is waiting to be incorporated into more production-ready software.

Efforts and Resources

Currently there are four core people working on Gardener, outlined at the Sponsor(s) section. All are working part-time. 

Two main backend developers involved are Krzysztof Wedrowicz and Krzysztof Spisak-Spisacki. In addition we have multiple other developers working on various components  We hope to have larger Hyperledger community support in the future as we further our development. 

Road map

October 2019

• Hyperledger Fabric integration
• IntelSGX remote attestation
• Update, refactor and polish the Monitor

After October 2019

• Off Chain computation with and without proofs
• Work on other Hyperledger greenhouse projects
• Decentralized consensus based on ring signatures
• SWIFT / payment integrations

Fabric invocation of EVM Smart Contracts

https://github.com/hyperledger/fabric-chaincode-evm

Hyperledger Fabric EVM chaincode

enables one to use the Hyperledger Fabric permissioned blockchain platform to interact with Ethereum smart contracts written in an EVM compatible language such as Solidity or Vyper.

Fab3 is a Web3 provider for Ethereum contract access via the EVM Chaincode

Fab3 is a web3 provider that allows the use of ethereum tools such as Web3.js and the Remix IDE to interact with the Ethereum Smart Contracts that have been deployed through the Fabric EVM Chaincode.

For the most up to date instruction set look at the ethservice and netservice implementations. For details about limitations and implementations of the the instructions look at the Fab3 Instructions.

To run Fab3, the user needs to provide a Fabric SDK Config and Fabric user information. To specify the Fabric user, the organization and user id needs to be provided which corresponds to the credentials provided in the SDK config. We provide a sample config that can be used with the first network example from the fabric-samples repository. The credentials specified in the config, are expected to be in the directory format that the cryptogen binary outputs.

Fab3 tutorial to run Ethereum Smart Contracts on Fabric

https://github.com/hyperledger/fabric-chaincode-evm/blob/master/examples/EVM_Smart_Contracts.md

Web3.js - library of ethereum routines

https://web3js.readthedocs.io/en/v1.2.0/getting-started.html

The web3.js library is a collection of modules which contain specific functionality for the ethereum ecosystem.

• The web3-eth is for the ethereum blockchain and smart contracts
• The web3-shh is for the whisper protocol to communicate p2p and broadcast
• The web3-bzz is for the swarm protocol, the decentralized file storage
• The web3-utils contains useful helper functions for Dapp developers.

// in node.js use: var Web3 = require('web3');

var web3 = new Web3(Web3.givenProvider || "ws://localhost:8546");

Fabric external chain code support

External Chaincode execution from build packs vs Docker

presentation

https://drive.google.com/open?id=1bZNywENb9YqV6zq6qAFjO6y-Ewl7edwF

folder

https://drive.google.com/open?id=1HAoD-jnkyrOfMrwZmSHDcJfxln9oMfUz

Interoperable Blockchain ACID transaction pattern

blockchain interoperability on atomic transactions using escrow transactions

context

assume 2 different orgs on 2 different blockchains on 2 different platforms want to execute a sale using an order (any type of asset )

both blockchains are connected by gateway nodes for orgs that are members of both blockchains

2 independent chains A and B can send messages using a common protocol ( gRPC or ??? )

each blockchain provides any participant access to directory services to locate other orgs on a blockchain

that directory access may be shared with remote orgs on a different blockchain through the gateway nodes

org agreements: 2 orgs can exchange identity information, register as business partners and agree to communicate

sales agreements: both orgs can agree to buy, sell from each other based on accepted contract terms

blockchains implement escrow transaction interface services in a smart contract for buyer, seller roles on orders, sales of an asset

party A wants to buy X from party B for Y currency amount

problems

how do orgs on 2 different blockchains find each other, exchange identity credentials and agree to do business with each other?

how to ensure only authorized parties participate in the transaction

how to ensure both parties will execute their transaction once and only once to complete the purchase transaction

how to ensure that the purchase is cancelled if either party fails to complete their part of the purchase transaction within the designated time limit

pre-requisites

network connectivity

blockchain directory services and access across both networks for authorized parties

identity, registration and access management services for all parties in a transaction

each party implements the escrow transaction interfaces

each party communicates using one of the supported protocols: gRPC or ?

each party digital certificates to sign and execute transactions identifying the authorized party

gateway nodes connect 2 different logical blockchain networks directly or indirectly ( blockchain networks normally not physical but virtual overlay networks across multiple provider networks )

solution

use an escrow transction with smart contracts that

records each parties performance of the obligation

This follows a saga pattern to implement the escrow transaction (eg a purchase ) as a set of linked transactions in smart contracts

Singe Use Tokens are used to guarantee that only this single reservation transaction can be executed once by the designated party

step 0 - party A agrees to buy X from party B for Y currency amount agreeing to a set of policies to execute the transaction for the buyer and the seller roles

step 1 - reservation for payment from A to B with a token,  reservation for delivery from B to A with a token

step 2 - when both reservations complete, the reservations are executable as smart contracts by each party

each party executes their reservation transaction via smart contract using the supplied single use token created for just this transaction

A executes B's reservation using the token from B

B executes A's reservation using the token from A

alternate scenarios

both reservations are not completed within the agreed time limit, all reservations and tokens are cancelled and resources revert to current owner control

the purchase policy agreed to may include automated contracts to execute actions to reverse one or both reservation executions or cancel the reservations updating the blockchain

step 3 - if both reservations are not executed as transactions within an agreed time limit, each party is notified to manage the purchase based on agreed policy

step 4 - when both reservations have been executed by each party, all parties are notified of the completion of the escrow transaction

step 5 - any dependent actors are notified of the completion of the purchase which may trigger additional transactions ( eg start an automatic purchase warranty etc )

Potential Value Opportunities

Potential Challenges

Candidate Solutions

Fabric articles

--------------------------------------------
action plan ... write articles ...

create some medium articles ....

where fabric is now ( vs v1.0 )
scale, features, ease of dev, ease of deployment, ease of support

fabric opportunities going forward ....

use both cpaper examples ... base on v1.4x
adv on v2.1x

deployment articles
ibm cloud
aws

industry articles on ... 

supply chain — chainyard follow ups

iot in mobility ???   vinblock pilot

compliance -  secure cdcs

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles