ibm-watson-iot / blockchain-samples Goto Github PK

View Code? Open in Web Editor NEW

172.0 56.0 167.0 66.77 MB

Samples demonstrating the use of Blockchain with IBM Watson IoT

Home Page: https://internetofthings.ibmcloud.com

License: Apache License 2.0

Go 87.56% HTML 0.47% JavaScript 11.70% CSS 0.06% Python 0.20%

iot blockchain

blockchain-samples's Introduction

Blockchain Samples

NOTE that this project contains mainly Fabric v0.6 compatible work. There is a FabricV1 subfolder for early work on a port to the new Hyperledger Fabric, however that work is in early states and is not to be used at this time. Updates to follow.

This project contains samples of blockchain smart contracts and blockchain applications for the Hyperledger fabric.

Purpose:

provide sample applications and smart contracts to demonstrate how a Hyperledger blockchain and the Watson IoT platform can work together in a solution
demonstrate advanced smart contract features that can be built on the Hyperledger fabric
demonstrate patterns that can make complex IoT contracts easier to develop and maintain
seed new smart contract development with advanced IoT features and integration into the Watson IoT Platform

Documentation:

Notes:

Development of the Hyperledger fabric and related projects has been moved to Gerritt. However, the original location remains as a convenient mirror.
The Hyperledger Fabric also has a web site for documentation, which is worth exploring, especially for those who would like to contribute directly to the Hyperledger development effort.
Hyperledger on Bluemix is updated periodically, and for compatibility reasons the blockchain-samples project has multiple release levels to line up with fabric versions available in IBM Bluemix.
- All contracts that have .0.6 appended to their folder names are compatible with Hyperledger v0.6 and new fabrics created on IBM Bluemix as of 10 November 2016.
- All contracts without this suffix are compatible with Hyperledger v0.5 Developer Preview and preexisting IBM Bluemix fabrics.

Smart Contracts in this Repository

simple_contract

The Basic contract is a sample hyperledger blockchain contract that is provided by IBM to help you to get started with blockchain development and integration on the IBM Watson IoT Platform. You can use the Basic contract sample to create a blockchain contract that tracks and stores asset data from a device that is connected to your Watson IoT Platform organization.

iot_sample_contract

This sample contract implements a simple Trade Lane scenario, moving assets from one place to another. It consists of several modules in package main that are all small enough to avoid creating separate packages in this first version. These add features that can be used without changing the code. This sample is used to explore features and patterns that are of interest to smart contract writers in the IoT domain. These are:

  - A single contract instance that manages multiple assets
  - A CRUD-like API for the assets
  - An event that is also a partial state
  - A deep merge of events to state
  - a `JSON Schema 4` compatible schema and a script written in Go that generates object samples and object schemas when `go generate` commands are issued
  - A mechanism for storing asset history (note, this mechanism is early work and will change for better scaling)
  - A mechanism for storing the most recent updates to any asset, most recent first. An asset can appear only once in the list and jumps to the top each time it is updated.
  - An alerts mechanism that tracks active alerts and marks the threshold events as raised or cleared.
  - A rules engine that performs threshold tests (e.g. temperature too high) and raises or clears alerts as necessary (and note that the rules need not be limited to alerts testing etc, they can in fact generate read-only properties directly if need be)
  - A set of map utilities that enable deep merging of incoming JSON events into the state that is stored in the ledger. This is necessary to implement a pattern where a partial state is used as an event.
  - Optional case-insensitivity for JSON tags for the convenience of clients that do not want to be held to the strictness of the JSON-RPC standard (note: insensitivity is not recommended, but can be explored with this sample)
  - A logging facility that can be adjusted in real time in order to debug a deployed contract without disrupting it in any way

[PingPong Contract]

This contract has been derived from the IoT Sample contract. Please read the introductory articles in the docs folder if you are not familiar with how these contracts function.

This contract adds the ability to send outgoing events from an advanced IoT contract. Three events are registered, as clipped from the code:
```
// EVTINVOKEERR is sent out whenever there is an error in the chaincode
const EVTINVOKEERR = "EVTINVOKEERR"

// EVTPONG is sent out whenever a PING assetID is received
const EVTPONG = "EVTPONG"

// EVTPING is sent out whenever a PONG assetID is received
const EVTPING = "EVTPING"
```
See the event listener application README and code to understand how the client registers interest in specific events and then catches them in a gRPB stream (modeled in Go as channels).

aviation_sample_contract

The aviation scenario is as follows:

  - Three primary asset classes:

      - Airline -- owns zero to many aircraft
      - Aircraft -- encompasses zero ro many assemblies
      - Assembly -- landing gear, wing, etc. These are life limited parts.

  - The CRUD features for each asset are abstracted in the module [assetCommon.go](./assetCommon.go), which makes heavy use of abstracted services in [crudCommon.go](./crudCommon.go)  
  - each asset follows the *partial state as event* pattern, where the asset's writable properties make up its primary `event` to be passed to create and update
  - additional events exist for:

      - flights that record a takeoff and landing sequence, which is known as a cycle
      - inspections against an assembly
      - analyticAdjustment events record calculated changes in wear and tear based on such analytics as weather patterns and runway conditions
      - maintenance events record the mounting and unmounting of assemblies with a full state machine

  - rules exist to track cycles and hard landings

      - ACHECK rule compares adjusted (by analytics) cycle counters to a dynamically configurable threshold, raising an alert as necessary, typically short time
      - BCHECK rule compares adjusted (by analytics) cycle counters to a dynamically configurable threshold, raising an alert as necessary, typically long time
      - HARDLANDING rule raises an alert when a hard landing is known to have occured
      
  - inspection events clear these alerts, note that bcheck clears both acheck and bcheck alerts

  > Note that the usual common properties such as geolocation, extension, etc. are available in the `common` subsection of asset event and state.

  Physical changes from the Generic IoT Contract include:

  - Three assets tracked with full CRUD APIs: airline, aircraft, assembly
  - Four event types handled with event APIs: flight, maintenance, inspection, analyticAdjustment
  - 2-way inverted index maintains 1 to many relationship from aircraft to assemblies
  - filters allow sophisticated queries and offer lightweight relationships between asset classes

      - a filter is a match type (all, any, none) and an array of k:v pairs with qualified property names and values

  - contractConfig module supports static and dynamic configuration of contract
  - new common layer for quick addition of a new asset class
  - new common layer to support crud operations
  - rules for acheck and bcheck (short and long term inspection cycles) and hard landing alerts

cashMachine
building
Parking Meter Demo

The Parking meter is FRDM-K64 and Cordio Boards combined. The FRDM board acts as the meter and the cordio acts as the BLE Beacon. The beacon transmits short urls in Eddystone standard and this points to the bluemix page https://mbed-parkingmeter.mybluemix.net. This page supports pakring meters PKM-001 through PKM-010. The code for the UI is inside mbedParkingMeterUI.

The UI makes a call to the IBM commerce system to initiate payment and the chaincode (code availalbe in mbedParkingMeter / mbedParkingMeter.0.6) for recording parking meter usage data.

It makes http calls to the node-red flow - NodeFlow.json -for setting the Parking meter to free (beacon stops emitting, UI says 'Free Parking') or paid (beacon starts emitting, UI says 'Paid parking') and also initiating the countdown once payment is made.
Carbon Trading Demo
Logistics Split

blockchain-samples's People

Contributors

Stargazers

Watchers

Forkers

cabalen2 randyramnansingh mirolima jalmers isramos nneerr123 michellepurcell henfee boldly mil52603 claudiotorresm tmachida1 nikileshsa benor83 kamalakshan vrvignesh mtawbi chenlin2 mayasofsof pavantyagi mirdhyn adrianrubio agantait abhishekraj210 liuhaidl anzalbeg jeffet raman-gupta kletkeman tallharish kkamijoh indefire ziyv hamzakindi akamitkumar goodfaithparadigm8 dafoo nihartirupati ankush461 pjheeta santoshshanmukh iotchain sudheer4422 tejalsatish fairledger georg44 naszam madiarra spansare quixoticblink herocf amarmundi starafdar-git rootwzrd mattrothera arlindnocaj mna2016 fstepho hamsterian moumi carloslobato03 ashrafhashem rodoqui17 suskizha diyanfilipov-taulia ruphatak pl-amit fabiolmarras torresjeff evo42 theuniverseon adolfoeliazat dcallnerfs somnathibm lrgeometry rtangatu jameshyunkim codeprotocol sophrinix rajpgr8 marco2901 nihalansari kat-attack kumarh1982 sayantantarafdar enash103 evionce joesan andystv musquash lifecontd pratibha0007 sunilake alvaradojl rahuljain2104 fakerjayden jessica0530 ashleytate614 yanyanho mmaro

blockchain-samples's Issues

How to add attachments to blockchain payload

I would like my use case to have the ability to have PDF documents present in the blockchain payload.
How to achieve this?

Appreciate an early response. Many Thanks.

Need to add the "overtemp" alert to block payload

The use case I am working on, has a transaction history on the right hand side of the screen. The transaction history shows the blockchain blocks in the order of their creation timestamp. The blocks will show "create" or "update" transaction on an asset.

we have already updated the code to have an overtemp alert in place. The overtemp alert is setting the compliant flag to TRUE or FALSE based on the temperature read. This part is ok.

What we now need is, when "OVERTEMP" alert is detected, the OVERTEMP string should be displayed in the payload of the transaction which updated the blockchain(I have tried updating chaincode the dirty way in order to accomplish this but nothing has worked so far).

What is the simplest and correct way of doing it ?

Appreciate the help of readers in this regard. Thanks.

Remove schema and sample generation from simple contract

Schema and Sample generation to be removed from the simple contract. The contract would still have readAssetSchemas and readAssetSamples and the behavior will not change. But the contract code will no longer have payloadschema.json, or the scripts folder and its contents. The contract developer will not have to run a 'go generate' command before 'go build'. Instead, the schemas.go and samples.go files will be provided as-is and the functions readAssetSchemas and readAssetSamples will read them just as they did before.

prepare for event bus and invoke error return to subscribers

We need to create a custom event "InvokeError" that will be sent to subscribers when we are about to fail the transaction.

Note: Ideally, this will be built into the fabric at some point, but it is not expected in mid 2016.

rules engine must return err

The rules engine can be used for more than just simple alert processing. For example, rules should be used for validation as well, so that the main boiler plate of the CRUD interface does not need a lot of tweaking.

Remove the obvious conflation of the rules engine and alerts processing. Return err to the invokes and fail on non-nil as with all other failures. A rule engine err must force invoke failure and roll back of all state deltas.

Query method throws error

I have deployed successfully and triggered "Init" and "Invoke" methods successfully with peer. But i can't get through this "Query" method

I have tried many times and many ways but couldn't able to get results for "Query" method, Please help me to find the bug:

/opt/gopath/src/github.com/hyperledger/blockchain-samples/contracts/industry/LogisticsSplit.0.6# peer chaincode query -n blReg -p github.com/hyperledger/blockchain-samples/contracts/industry/LogisticsSplit.0.6/BillofLading -c '{"function":"getBillOfLadingRegistration", "args":["{\"blno\":\"10203040\"}"]}'
Error: Error querying chaincode: rpc error: code = 2 desc = Error:Failed to launch chaincode spec(Could not get deployment transaction for blReg - LedgerError - ResourceNotFound: ledger: resource not found)

Please help me to fix this issue.

monitoring UI could show existing values in light gray

It would be extremely useful if the monitoring UI somehow showed the existing values in place of the textual hints so that the user could use it to choose the next value. This would make the monitoring UI a very powerful testing tool ...

monitoring UI should offer auto collapse for payload response section

When a user is watching many queries, a real estate management feature should be offered where only one section is opened at a time. There is precedent in applications with long lists of panels such as Adobe Lightroom and it offers the ability to focus on only one thing at a time and to keep that panel centered on the screen as best as possible.

monitoring UI does not display the function name for response payload headings when polling

The monitoring UI could be much more useful for demo and debugging purposes were it to show the response payload with a heading of the contract API (e.g. readRecentStates) that generated it. You can switch on polling and it will execute it again every time there is a new block, which is an amazing feature. But if you close the headings, they all look alike, with an asset name of null with no indication of what the command was in the first place.

How to add blockchain level access control in this repository?

How to introduce blockchain level access control in the minimal contract present in this repository.

Our UI has been using this repository for quite some time now. Switching to composer will mena a lot of changes to the UI code.

Is there a way to introduce blockchain level access control, just the way done in another example of IBM blockchain "car lease demo"?

Appreciate an early response. Thanks.

monitoring UI should reenable polling when a payload response section is collapsed and then reopened

Collapsing a payload response section that you are polling switches polling off. Opening it up again does not toggle it back on. This is extremely inconvenient to the user as there may be a half dozen queries being polled.

monitoring UI should allow short strings for chaincode names

The monitoring UI does not support debugging mode for chaincode, which is a shame since it would be that much more useful if it did.

handle upgrades by taking over the database

Depends on: hyperledger/fabric#1217

We need to be able to upgrade a contract, which of course would be the default behavior in all new version of a contract upon execution of Init().

Each new version will have to implement whatever data migration will be necessary, but by storing data as JSON objects, and by maintaining original JSON tags, we can alleviate the vast majority of data migration requirements.

How to impose restricted access based on participants role.

How to have access control at the chaincode level. i.e. If I have 4 users participating in teh use case like Supplier, Transporter, Regulator, End user - How to control the access of these 4 users in chaincode. For example Regulator can see everything. Transporter cannot see data meant for Supplier and End user.

How to have such an access control?

(Ref: I have seen car lease demo another example of IBM blockchain, doing acces control at chaincode level.)

Explanation on the simple contract example is needed.

I was hoping in its first paragraph, the author can tell what is contract before going into technical details. Anyone can help?

As for a contract, I would expect there are at least two parties involved, and then rights and responsibilities are defined for each party. Once the contract is signed, both parties should honour the contract, ie. deliver as contracted, once all responsibilities are delivered, the contract is cleared.

Isn't it? But in its explanation, I did not see any of what I am looking for. Why is so? thanks.

How to introduce new methods?

I have to add 2 methods. One is a query method and second is a invoke method. I have created the function bodies and declared the functions inside ctasset.go. I also added "AddRoute" calls for the 2 new methods.

Now when I am testing these functions, the calls are not routed to them. Am I missing something?

The readme perhaps does not show how to add new "query" and/or "invoke" methods to extend the contract(Please correct me If I am not). Any link\document will be of great help.

stateHash is not matching previousBlockHash

As per the blockchain theory that I have understood so far, The blocks are connected via "Hash" keys. i.e. Two fields "stateHash" and "previousBlockHash" are present on each block. As per my understanding previousBlockHash of the present block should be equal to the stateHash of the previous block.

I have deployed this chaincode via IBM bluemix blockchain service. The stateHash and previousBlockHash are not equal for most of the blocks.

Is this a problem? Please clarify.

monitoring UI should display all objects in schema order

Currently, when looking at state objects returned by readAsset, readAssetHistory, readAllAssets, and readRecentStates, the monitoring UI displays all properties in each asset in alphabetical order. This is a very confusing order, since the order changes depending on which properties happen to be present. It makes it very hard to follow the progression in history, for example.

Ideally, the order would always follow schema order, which would make it easy to follow a progression of states.

Monitor UI and Simple UI not compatible with linux

When installing the Monitor UI and Simple UI, I get an error on the dependency 'fsevents'. Reading the 'fsevents' docs, it seems it's platform specific for Mac OS X (darwin). I'm using linux. Here's the terminal output:

monitoring UI should not send empty properties

The "partial state as event" pattern requires that only those properties that are set be sent to the contract. This allows the contract to differentiate between an empty property and one that was never sent. For example, there is a difference between a location with no values in it and no location. In the latter case, the contract can assert that the device is not sending, which may be an alert condition. By sending empty locations, the contract can no longer assert that condition, even though it is true.

monitoring UI payload response section would be better split in two: "invoke response" and "monitored queries"

The payload response section is useful, but one only wants to see the response from one invoke at a time, since the response shows only the transaction ID and that can easily be seen in the blockchain itself. The queries section is auto updating and thus lives on well after the queries are set up. It makes sense to reserve a section at the top of the column for the latest invoke and to allow the rest to play out below.

Alternately, a second column for invoke history could be optionally created for those who want to be able to click on a historical invoke and see which block it is in (which would require another feature.)

change "incompliance" to "compliant" in the schema and as the JSON tag for that property

There have been multiple reports of confusion with the JSON tag "incompliance" as it sounds like a negative and is missing the camel case that would have gone some way to clarity. But rather than change the case, the actual JSON tag should be "compliant" since that perfectly denotes the meaning.