This article was originally published on LinkedIn
Last week on Thurs and Fri, RTP held the 2018 #IoTSlam (https://iotslam.com/). Thanks to David Hill, I had the chance to become familiar about the community and attend this exciting event and the sessions. The annual event by the #IoT Community was well orchestrated from start to finish.
My first exposure to sensor technology goes back to 1984 when I was working with Dr. Sunderrajan, Head of Research at DCM Data Products, India. I was supporting DCM Data Loggers and PLCs, and learning about Process Control Systems. Our core product was MICON from Powell Systems, USA. Connectivity was achieved via daisy chaining RS232C ports and MUX cards. We were controlling processes by measuring humidity, temperature and other parameters that drive paper and nylon industries .
The primary goal of the IOT Community is to educate developers, thought leaders and C-levels, and drive the adoption of IoT within the enterprise through various means such as their expert working groups, CoE initiatives, advisory groups and events. I spoke with some of the Sponsors such as IBM, SAS, DNA Group, SIMTelligent and RIOT and got to understand the work that this community has been doing.
The key note addresses by Chris O’Conner (IBM GM of IOT) provided great insights into the science. He illustrated the volume of data being generated and how analytics is helping address problems and identify new revenue streams. The CTO of SAS Software Mr. Oliver Scambenberger talked about the progresses leading to IoT and AI, and the SAS Strategy around IOT and tools to process data in real time using statistical tools and machine learning. Some key enablers for IoT and AI are advances in #5G, sensor technology and availability of AI and cognitive platforms like #IBM #Watson. They have enabled key developments such as machine/computer vision, connectivity, automation, augmentation, image recognition and intelligence.
Some cool messages include – “Data without Analytics is unrealized value, and Analytics without Monetization is unrealized revenue”.
The evolution of sensor technology has greatly helped in the adoption of IoT based applications especially in #HealthCare, #Logistics and #Supplychain. Advancement in 5G is enabling the driver-less revolution such as see-thru sensing, autopilot driving, platooning, advanced entertainment, augmented and virtual reality. Sensor technology is being applied to railroads to address the Positive Train Control mandate. They also help with managing rail safety via sensors attached to axles, wheels and ball-bearings.
With so many devices communicating on the network, the need for security becomes a key concern to prevent a variety of threats ranging from DoS , ransom attacks, spamming to infiltration. Someone talked about a great example from Vegas where millions were stolen from a casino just by attacking a harmless IoT based fish tank thermometer. Nancy Shemwell, CEO of Entegra and Dipto Chakravarty of Echostar emphasized the importance of security.
I really enjoyed @Rahul Vijay, Global Head of Telecom at Uber, talk about the various Uber Businesses and how IoT is a key driver behind all their future business strategies.
I explored the relevance of #blockchain with many of the minds out there for both identity and access management (#IAM) of IoT devices, maintain accurate records of important IoT readings as inn #coldchain #supplychain applications or even better, drive IoT behavior or workflows through #smartcontracts .
Chainyard’s Senior Vice President of Consulting, Isaac Kunkel, was invited to guest post over at IBM’s Blockchain Unleashed blog this week. In his post, Isaac looks back on the journey that Chainyard has taken within the realm of blockchain, and our experience with using Hyperledger Fabric.
“A journey of a thousand miles begins with a single step.”
One famous proverb states that “a journey of a thousand miles begins with a single step.” In this proverb we learn that something which takes time begins with an initial action. For most, the blockchain journey starts with the adrenaline fueled feelings associated with trading cryptocurrency. For IT People Corporation, it began with an opportunity to contribute to The Linux Foundation’s Hyperledger Fabric open source project starting in late 2015.
The team was assembled to help build and support the infrastructure necessary to develop the early releases of Fabric. In partnership with IBM, the framework for continuous integration and testing, along with other development, performance test and support activities, were built.
With contributions by dozens of engineers and companies, the early releases started to come together allowing early, pre-release solutions to be initiated, first with release 0.3, then release 0.5 in March 2016 and then with the first official release of 0.6 in September 2016.
Chainyard specializes in advising and supporting small, medium and enterprise companies in Blockchain.
Enterprises are exploring new ways to work with their suppliers and competitors using Blockchain-based business networks. They need to understand the new opportunities and threats that emerge because of the new models Blockchain enables.
Chainyard specializes in advising and supporting small, medium and enterprise companies in Blockchain.
Because we work closely with members of the Hyperledger foundation and are actively involved in the Blockchain community, we’re able to provide our clients with expert insight into the Blockchain landscape to determine the most valuable Blockchain solution implementation for your business.
We’ll work closely with you to help define a successful strategy focused on Blockchain adoption, development, and implementation.
You can continue reading the rest of the article over at IBM’s Blockchain Unleashed blog.
I attended the #Blockchain For Supply Chain conference held this week on May 21 & 22, 2018 in Houston and hosted by the University of Houston under the #XChain2 umbrella. The event was MC’d by Daryl Price , former NFL star from the 49ers. The consultant team executing the event was great and even had an interview session with Michaella Black.
The University of Houston, Port of Houston and Port of Antwerp provided the sponsorship to this conference and help understand the business case for blockchain in Oil and Gas, energy, container management and shipping. Though there is debate on exactly when, it is expected that port operations will transition from the archaic systems and processes they use today to a more modern approach between 2028 to 2040. There was mention of the Maersk-IBM joint venture, though I wish someone from either firm was there to talk about this.
I met a number of senior folks from various companies including Port of Houston, Port of Antwerp, Shell, BP, Kuhne and Nagel, Ricoh, University of Houston, NxtPort, ShipNext, T-Mining etc. The opportunities in the energy industry are enormous. A number of the consulting companies talked about #blockchain and demonstrated standard PoCs around food provenance, track and trade, Invoice and settlement upon POD receipt, coffee beans provenance etc. Few vendors demonstrated PoCs, though some touted them as production ready.
Many participants were not aware of the #Hyperledger Project nor the enterprise capabilities of #Hyperledger-Fabric. However, look at the bright side. I learnt about the opportunities where Chainyard can contribute and lead. Here are some key takeaways –
Port Operations have several opportunities to explore how blockchain can help. They include:
Oil and Natural Gas Companies have also been exploring various use cases and some of the ones that I noted:
The Government especially the Customs and Border Patrol also finds blockchain as a potential technology in areas such as
Supply Chain Operations can improve processes around waybills, Bill of Lading, Proof of Delivery and Invoicing.
Overall, I find mini and focused conferences are more useful than massive ones with thousands of participants where having one on one conversations often is limited to a few minutes.
Chainyard’s CTO and VP of Business Development recently got a chance to sit down with IBM to reflect on some lessons learned after wrapping up the development of our blockchain EAM solution. The original article (which can be found at the end of this article), tracks the journey of an IBM team tasked with improving the end-to-end management of enterprise assets.
We describe our starting point, the key architecture questions we had to answer, and our ultimate blockchain-based solution for our business. We share our lessons learned and thoughts on how to scale the system for future growth. Finally, we detail the IBM offerings we used and that are available to you for building your state-of-the-art blockchain solution.
Businesses need Blockchain infrastructure designed to meet their requirements for privacy, compliance, and performance. Every day, Chainyard’s team helps advance Hyperledger, the leading open business Blockchain. Our architects, developers, security researchers, performance analysts, test engineers, and DevOps experts are solidifying the foundation on which enterprise Blockchain solutions are built.
We provide the right experts who bring the experience needed as solutions evolve from minimal viable products to enterprise-grade solutions. We work with multiple Blockchain technologies and have a specific focus on Hyperledger Fabric and its ecosystem.
Our team of Blockchain experts bring extensive experience in architecting, designing, building, testing, securing and operating complex distributed systems to help adopters of Blockchain technology succeed.
Chainyard are experts at Blockchain, and work with small, medium, and large companies to develop innovative blockchain EAM solutions every day. If you think you have a business need for blockchain, or are interested to learn more about our blockchain EAM solution detailed in this article, reach out to us and speak to an expert today.
Our Vice President of Business Development, Alex Rosen, recently collaborated with IBM Blockchain Squad Manager Burton Buffaloe and Program Manager Vishnu Tadepalli to understand how blockchain could be used to streamline contractor management.
This talk was originally featured at Think 2018, IBM’s technology and business conference, although a copy of the slides can be downloaded for free by clicking the link at the end of this article.
Enterprises are exploring new ways to work with their suppliers and competitors using Blockchain-based business networks. They need to understand the new opportunities and threats that emerge because of the new models Blockchain enables.
Our architects, developers, security researchers, performance analysts, test engineers, and DevOps experts are solidifying the foundation on which enterprise Blockchain solutions are built.
Businesses need Blockchain infrastructure designed to meet their requirements for privacy, compliance, and performance. Every day, Chainyard’s team helps advance Hyperledger, the leading open business Blockchain. Our architects, developers, security researchers, performance analysts, test engineers, and DevOps experts are solidifying the foundation on which enterprise Blockchain solutions are built.
Chainyard provides needed guidance and skills through our services, including consulting, engineering, and operations. If you have an interest in leveraging blockchain technology, speak to an expert today.
Blockchain is a tremendously promising technology. We have been applying blockchain technology to transform various business processes especially supply chain problems enabling it to become more efficient both financially and operationally. We at IT People have been involved with the blockchain journey since late 2015. Throughout 2016 until now, our team has built solutions in both Hyperledger-Fabric (an IBM Blockchain innovation from the Linux Foundation) as well as Private Ethereum. Along the way, as we architected applications, we learnt and experimented in developing smart contracts and noted that patterns can be applied to design.
Last August, I had a linkedin post on Scaling Blockchain Solutions. This post tries to explore one of the bullets in that post. We discuss some of the patterns here in this initial attempt at stirring some conversation.
Patterns for Contract Development
Patterns help break the solution into simple services and thus enable simplicity, maintainability and scalability. We have developed and tested multiple solutions in private Ethereum networks based on the Parity client, and many supply chain projects on Hyperledger-Fabric.
The following patterns described below were first discovered while we were implementing Ethereum Solutions. Subsequently, we refactored the solutions we built on Hyperledger Fabric, where most of the earlier solutions were based on a single monolithic contract with several functions processing business transactions and events. We broke up our back-end solution into smaller loosely couple contracts. Some of the contracts were based on “asset type” which refers to assets as anything that has value and can be moved between counter parties. Assets include crypto-money, financial securities, documents, parts, items, votes etc. We list few of the patterns which have their roots in many of the earlier discussions in SOA, J2EE, EAI etc.
Motivation: During the building of the solution, once a smart contract is deployed, it is immutable and runs for ever. Newer versions of the contract are deployed over time, and unless the old one is destroyed, the multiple versions run in parallel. How does the application know which one of the contracts is legal or which version to invoke for a particular client.
Solution: A singleton instance of a special smart contract called the “Registry Contract” can be defined which acts as a registry for all deployed smart contracts. Every time a smart contract is deployed, a transaction is invoked on this contract to register the details of the newly deployed contract and any other updates to previous versions. This pattern is applicable to both Ethereum and Hyperledger-Fabric solutions. While contract account number is the key in Ethereum, the Chaincode ID can be used in Fabric.
Diagram:
Motivation: There are situations where several contracts may belong to the same family by sharing some common attributes and behavior and based off of a common template. These contracts may be organization specific and managed using user privileges assigned by the organization. Such contracts may be created at runtime. For example, if a buyer deals with several suppliers, the contract between the buyer and each supplier may be a separate smart contract.
Solution: Maintain contract templates. Instantiate a contract from the template as per the workflow at runtime. For example if an organization deals with multiple suppliers, then each supplier may have an independent contract with the buyer. In the case of Ethereum/Solidity, any contract can instantiate another contract from within the blockchain. In the case of Hyperledger Fabric, a new instance of the contract has to be deployed by the client from the outside into the blockchain network (e.g. from the NodeSDK Client via a deploy call).
Diagram:
Motivation: If there are a number of run-time instantiated smart contracts, there should be a method to lookup the appropriate contract using key attributes and then send transactions to that specific contract. For example, if the incoming transaction refers to “Supplier_01”, then, there should be a method to retrieve the contract associated with that supplier identifier and then send transactions such as “UpdateSupplierRating(“Supplier_01”, args …) “ to that contract.
Solution: We can solve this using the same concept as a “Registry Contract”. We utilize a “Lookup Contract” that maintains a map of all contracts, in our case “Supplier Contracts” keyed by supplier ID. When an incoming request is received, the contract retrieves the appropriate supplier contract based on the “supplier Id”. The Lookup contract acts as a registry of all contract addresses or URIs for the suppliers as depicted in the diagram below. This pattern is implementable in both Ethereum/Solidity and Hyperledger Fabric. In Hyperledger Fabric, the contract address is the chaincode name or identifier.
Diagram:
Motivation: When a transaction comes into the blockchain, it is necessary to verify the credibility of the user initiating the transaction and whether the user has the privileges to execute the transaction on that contract.
Solution: We implement a “Account Manager” that maintains records of all legal accounts and some additional information and a “Role Manager” that maintains maps of roles to functions that can be accessed. The “Access Verifier” acts as an internal check and verifies every transaction before execution against the account making the request and whether the account has permissions to run the transaction. An account may belong to an application, an end user persona, a contract or a client. We applied this approach while designing a private Ethereum network until we could build on top, an identity verification service and a certificate management service. This design pattern can be implemented in Fabric as separate chaincodes and using the chaincode-to-chaincode calling API.
Diagram:
Motivation: Almost all solution logic has some work-flow consisting of input, processing and output. A workflow is a series of steps or tasks performed to achieve results. The workflow may have several branches triggered by conditions. In our case, workflows do not store any data hence they are stateless.
Solution: We implement a smart contract that executes a sequence of steps based on the incoming payload or event. Each step may execute minimal logic such as validate incoming data or invoke another smart contract. In Ethereum/Solidity, our workflow does not have any ledger state variables but can make calls to other smart contracts to read data. In Hyperledger-Fabric, we have no calls to “putState” but the logic may contain “getState” to retrieve some data from the ledger, transaction-history or world-state by calling another chain code.
Diagram:
Motivation: The ledger is immutable, and data recorded in the ledger cannot be altered and manipulated. In blockchain solutions, data is owned by the smart contract and any reads or writes to the ledger can be performed only via the APIs provided by the smart contract. Thus, the underlying ledger is not directly accessible. The issue arises when a new version of the contract must be deployed. Data from the previous version of the contract must be migrated to the new version.
Solution: Split the smart contracts such that the business logic is isolated into the “Business Contract” and the recording of the data into the ledger is performed by the “Data Contract”. There is one caveat – we assume that the data contract will not change that often, and that it accommodates for most commonly used data attributes and operations.
Diagram:
Motivation: As seen in the “Registry Pattern” and “Lookup Pattern”, contracts can be instantiated dynamically at run-time and their contracts addresses are assigned during that phase. An incoming request from a client knows the function to be executed against a contract but does not know the address of the contract. In other situations, the workflow contract must be able to route transactions to the appropriate contract based on workflow.
Solution: Use a “Router” to receive incoming requests, perform a lookup to retrieve contract or chaincode address and route the request to the appropriate contract. The “Router” can maintain internal routing table or it could work in conjunction with a “Registry” or “Lookup” contract.
Diagram:
Motivation: In almost all enterprise applications, we deal with business objects such as order, supplier, customer and product. Storing large data objects in any blockchain technology in the ledger has implications. The storage requirement is enormous and is replicated across all the nodes. Queries against the object or a list of objects can result in latency issues. Finally, there is a cost for storage and data transfers. Data stored on the blockchain must conform to blockchain principles and requirements for decentralization, trust, transparency yet support privacy, auditability and immutability. However, business solutions represent end-to-end applications to solve business problems.
Solution: Our approach is to store blockchain specific attributes of a business object on the chain, while storing all other attributes about the object that support the solution for transaction processing and queries in an off-chain database such as MongoDB or CouchDB. This approach has helped us to engineer solutions to meet performance requirements and isolate private information to the off-chain storage with their hashes stored on-chain. The off-chain data store is attached to the client interface and complements the on-chain datastore. The combination of the two is considered part of the blockchain aspects of the overall solution.
Diagram: