I got selected to the 2019 Hyperledger mentorship program for the project “Scaling Real World Hyperledger Fabric Deployments.” My mentors were Sasha and Nicola from Aid:Tech. Through this internship, I contributed several new features to “Nephos,” which is an open-source tool under Hyperledger Labs. Nephos helps to deploy and manage Hyperledger Fabric networks easily.
During my internship, I worked closely with the engineering team of Aid:Tech. My mentors, and I had several meetings to plan our tasks and to finalize the architectures. I made the following contributions to Nephos during my internship:
1. Stabilizing Nephos
During the first few weeks, I spent time on familiarizing myself with the relevant technologies and Nephos itself. During this time I fixed some known bugs in Nephos. Also during this phase, I improved the logging capability of Nephos through the native Python logger.
2. Support for multiple organizations
Nephos 0.3.X supported only one orderer organization and one peer organization. We wanted to allow the users to define as many organizations as they wanted. As some major changes had to be done that needed to be compatible with the future plans we have for Nephos, we discussed the architectures and changes in GitHub. Then we finalized the architecture and started working on it after an online meeting. Now, Nephos 0.4.X let multiple organizations to be defined.
3. Support for multiple channels
I also created a PR to let the user define multiple channels and precisely define which organizations belong to which channels so that, during the deployment, Nephos creates those channels and make the peers join the relevant channels. In order to achieve this, I also had to make changes to the “hlf-peer” helm charts in helm stable repository.
4. Support for Hyperledger Fabric 1.4
As Hyperledger Fabric 1.4 is the LTS version of Fabric, we made Nephos and the relevant helm charts support Fabric 1.4.
5. Support for TLS communication within nodes.
After supporting Fabric 1.4, we wanted to make sure that Nephos will work with RAFT ordering service, which is one the main feature we got by updating to Fabric 1.4. But, in order to support RAFT, we needed to support TLS communication between peers and orderers. I implemented this support, and now users can either use the TLS certificates generated by the cryptogen or they can ask Nephos to deploy a separate certificate authority to provide TLS certificates. In the latter case, Nephos will deploy a separate CA, generate all the relevant certificates, place the certificates in relevant pods and will use them for all the communication.
I hope to present my work at Hyperledger Global Forum 2020 in Phoenix, Arizona.
Experience gained
During my internship, I got a detailed understanding of how a Hyperledger Fabric network works, how to set it up, how to take advantage of its pluggable consensus model and how to make it secure. I also gained a lot of experience with Kubernetes and helm charts.
I have contributed to other open-source projects in the past, and Nepos is one of the most organized repositories I’ve seen. Working closely with my mentors, who built this open-source project from the ground up, gave me a lot of insights into how to effectively build and maintain an open-source project.
While working on this project, I focused on feature-driven development and completed one task at a time. Timeline:
The project started with the paper provided by my mentors on design and logic behind CTB. Based on the architecture described in the paper, I created the initial version of CTB.
Then I added blockchain explorer to CTB for monitoring transactions and blocks.
Next came creating a CA interface and rest API for interacting with CTB.
At this point, we were ready to deploy CTB. We started with one server on DigitalOcean.
Initially, we had bash scripts for testing query and invocation of the chaincode. Later, we moved to automated testing using Hyperledger Caliper.
To match real-world scenarios where CAs would be progressively joining CTB, I worked on addition of new organisation across multiple Docker environments.
Next, I created another droplet on DigitalOcean and bootstrapped the process of new CA org (on this server) joining CTB.
Then it was on to creating a Firefox extension.
Finally, it was time to issue a self-signed certificate for ctb-testing.ml and another for hfctb.ml signed by letsencrypt on CTB. These are for demonstration purposes.
By the end of this project, different pieces of CTB started coming together. The final architecture of CTB is explained through the below diagram:
Learning
This internship has been an informative and skill-driven learning experience for me. I learned a lot from the Hyperledger community and gained critical experience and expertise in a number of areas, including:
Working with openssl tool and certificates and understanding how PKI works.
Hands-on learning of Docker and cloud orchestration while deploying CTB.
Understanding the way identities are maintained within Hyperledger Fabric, role of peers and orderers, structure of crypto-config.
Writing chaincode and developing application for interaction with Fabric.
Using Hyperledger Fabric, blockchain-explorer and Hyperledger Caliper. While I was focused on Fabric, I also looked into Composer.
Future Plans
This project is still in development stage. With more functionalities and scaling, it can be used in production. Some of the tasks that we have in this project’s timeline are:
Revocation of certificate improvements: Currently when a certificate is revoked, the browser uses an extension to get status of certificate. A better solution is to directly integrate OCSP or OCSP stapling with CTB.
Chrome extension: Currently, Google Chrome does not provide an API to retrieve the SSL information including the domain certificates that the extension needs. Once it is available, we plan to build a Chrome extension too.
Scaling: Test different configuration of CTB on bigger network of servers.
For the full details, see my complete project report here.
I will continue to work on CTB in the future (post internship) and be a part of this great community!
Credits
First of all, none of this would not have been possible without my mentors (Mahavir Jhawar and Deva Madala) and other members of the Hyperledger community. Min Yu provided quick response to my queries and regular updates on the internship program. Hyperledger chat and Jira proved to be useful. So, a huge shout-out to them for helping and guiding me when I was clueless on how to proceed. While I was busy coding, my mentor oversaw the direction in which this project was going and pointed changes/additions to me. This kept me busy throughout the summer and helped me complete my project.
Last, but not the least, I would like to thank my fellow applicants who also worked on developing Hyperledger Fabric, blockchain explorer and Hyperledger Caliper, which can be used in the next iteration of CTB.
Here at Hyperledger, one of our favorite ways to grow our contributor community is our Bootcamp series of events. We’ve worked with Meetup groups, project maintainers and members around the world to hold these hands-on introductions to our technologies. From São Paulo, Brazil, to Hong Kong to Vancouver, Canada, we’ve helped hundreds of developers, designers, project managers and more up the Hyperledger learning curve with our Bootcamps.
The next Hyperledger Bootcamp will be in Moscow, Russia, on October 14th and 15th at Deworkacy Red October. The event will be hosted by Norilsk Nickel, which became a member of the Hyperledger consortium in June of this year.
Like all of our Bootcamps, this is a community-led event. After kicking off with an overview of the key projects, attendees will break out into groups to follow their own technology interests, diving straight into tutorials or getting started documentation and then starting to contribute to the projects with bug fixes, documentation and even developing use cases.
It’s important to note that these events are not just for coders! Contributors can help by creating documentation, writing use cases, serving as group organizers, and, of course, reporting and fixing bugs. The goal is to get community members up to speed on how to contribute. Most of the participants are fairly new and we understand that contributing to your first project can be a bit daunting. Bootcamps takes the fear out of the process. For existing contributors and maintainers, they are also the ideal place to recruit more help for your project or group.
Head to our wiki to find out how to get involved or help bring a Bootcamp to your community.
Welcome to our Community Spotlight series, which highlights the work of those taking on leadership roles in our special interest and working groups. Meet Bobbi Muscara, chair of the Learning Materials Development Working Group and founder of Ledger Academy.
Tell us about yourself. Describe your current role, your current business and background.
My name is Barbara (Bobbi) Muscara. I have spent most of my professional career in technology education. I started my career at Healthcast, as the Director of Education. I designed the educational documentation to support software that enabled medical records to be viewed over the internet. I then went back to school to receive my master’s in Business Education. Since then, I have been training enterprises and individuals how to utilize new software packages. In 2016, I opened Ledger Academy, a Blockchain training company in Princeton, New Jersey, that hosts the local Hyperledger Blockchain meetup group. I currently also chair the Linux Foundation’s Hyperledger Learning Materials Development Working Group where we are currently working with other Hyperledger community groups to create standards for Hyperledger documentation. I recently edited the Hyperledger For Business EDx course that went live July 17th and is expected to have over 100,000 students. I also serve as a community volunteer on the Board of Trustees as chairperson of a local addiction recovery organization that provides support for individuals in recovery.
Discuss your involvement in the Hyperledger Learning Materials Development Working Group (LMDWG).
As chairperson of the working group, my duties are to set and post the agenda and to moderate, record and post notes for the bi-weekly calls. As a group member, I have the responsibility of maintaining the group’s wiki page, where we are working to develop standard templates to assist the community in the development of learning materials. Additionally, I designed a program for Hyperledger meetup organizations to model. The program directs groups to create a Social Impact Summer Blockchain project that has a positive benefit on the local community. To see an example, please visit www.BCPrinceton.com. The Learning Material Development Working Group is also currently developing a community library for all documentation created by projects, working groups and special interest groups.
Where do you hope to see Hyperledger and/or blockchain in five years?
After working with the special interest groups within the Hyperledger community, it is apparent that every sector and industry is devoting more time and energy into blockchain and is beginning to truly understand the unrealized benefit that the technology holds. From the big banks involved in trade finance solutions to the social impact projects are working on to aid the less fortunate, I believe blockchain will be part of every enterprises’ structure in the near future.
What do you see as the biggest barrier to widespread blockchain adoption?
As with all new technology, the education barrier is the most formidable roadblock. People fear what they do not understand, and few people have a solid grasp of the intricacies of this innovation. Blockchain is a complicated technology that offers simple solutions once realized. As this “preliminary” technology grows, I believe so will acceptance and understanding of its potential benefits.
What are the biggest opportunities ahead for blockchain developers?
I think that, as understanding of the technology grows, smaller projects will begin to arise, which will require qualified developers. The need for coders, architects and developer, as well as the opportunity for training programs, will increase.
What is the LMDWG working on currently? Any new developments to share?
The LMDWG is currently working on a survey for project maintainers, working groups and special interest groups so that we may better understand the learning material needs in the community. The survey will also help us collect the vast amount of work these groups have completed and create a documentation library complete with a reusable glossary.
What’s the most important milestone for the LMDWG to reach by the end of 2019?
The LMDWG just completed the edits on the new EdX course Hyperledger Blockchain for Business, which is a business overview of the technologies. The next course that is coming is the technical guide for each of the projects. We will be developing this course with EdX. A new course for Identity is in development that will cover Indy, Aries and Ursa.
Why should someone participate in the group? Why is it important for Hyperledger to encourage collaboration around adopting blockchain technologies in this industry?
The LMDWG is dedicated to educating the community. The templates we build and the standards we recommend for documentation will shape how the Hyperledger community learns from its members.
What are a few ways people can participate in and contribute to the LMDWG?
The best way to connect us is through the chat channel or to join our bi-weekly call. We have a very active wiki page that holds the resource library (a local place for community created documentation). We need support in developing templates and standards for documentation.
How can people get involved in the LMDWG?
We strongly encourage all community members to get involved in developing documentation for this new technology. All information about joining our group can be found here.
If you need to learn how to get involved, check out our New Member page for instructions on how to become an active member.
Today we are excited to announce Hyperledger Besu as the latest project to join Hyperledger. Hyperledger Besu, a Java-based Ethereum client formerly known as Pantheon, is the first blockchain project submitted to Hyperledger that can operate on a public blockchain. Besu represents the growing interest of enterprises to build both permissioned and public network use cases for their applications.
The project’s design and architecture decisions have been aimed at clean interfaces and modularity, with the goal of making Hyperledger Besu a platform for open development and deployment. Besu is designed to be as modular as possible, with a separation of concerns between consensus algorithms and other key blockchain features, making these components easy to upgrade or implement. By creating clean interfaces between elements within the client (e.g., networking, storage, EVM, etc.), we believe enterprises will have a much easier time configuring Ethereum to meet their needs while also creating opportunities for other Hyperledger projects to integrate and use elements of Besu’s codebase.
What is Hyperledger Besu?
Hyperledger Besu is an open source Ethereum client developed under the Apache 2.0 license and written in Java. It can be run on the Ethereum public network or on private permissioned networks, as well as test networks such as Rinkeby, Ropsten, and Görli. Hyperledger Besu includes several consensus algorithms including PoW, PoA, and IBFT, and has comprehensive permissioning schemes designed specifically for uses in a consortium environment.
What is an “Ethereum Client”?
Hyperledger Besu is one of several Ethereum clients. An Ethereum client is the software that implements the Ethereum protocol. Ethereum clients contain:
An execution environment for processing transactions in the Ethereum blockchain
Storage for persisting data related to transaction execution
Peer-to-peer (P2P) networking for communicating with the other Ethereum nodes on the network to synchronize state
APIs for application developers to interact with the blockchain
What are Hyperledger Besu’s Features?
Hyperledger Besu implements the Enterprise Ethereum Alliance (EEA) specification. The EEA specification was established to create common interfaces amongst the various open and closed source projects within Ethereum, to ensure users do not have vendor lock-in, and to create standard interfaces for teams building applications. Besu implements enterprise features in alignment with the EEA client specification.
Hyperledger Besu’s features include:
The Ethereum Virtual Machine (EVM): The EVM is the Turing complete virtual machine that allows the deployment and execution of smart contracts via transactions within an Ethereum blockchain.
Consensus Algorithms: Hyperledger Besu implements various consensus algorithms which are involved in transaction validation, block validation, and block production (i.e., mining in Proof of Work). They include:
Proof of Authority: Hyperledger Besu implements several Proof of Authority protocols. Proof of Authority consensus protocols are used when participants are known to each other and there is a level of trust between them––in a permissioned consortium network, for example.
IBFT 2.0: In IBFT 2.0 networks, transactions and blocks are validated by approved accounts, known as validators. Validators take turns creating the next block. Existing validators propose and vote to add or remove validators. IBFT 2.0 has immediate finality. When using IBFT 2.0, there are no forks and all valid blocks are included in the main chain.
Clique: Clique is more fault-tolerant than IBFT 2.0. Clique tolerates up to half of the validators failing. IBFT 2.0 networks require greater than or equal to ⅔ of validators to be operating to create blocks. Clique does not have immediate finality. Implementations using Clique must be aware of forks and chain reorganizations occurring.
Proof of Work (Ethash): Proof of Work is used for mining activities on mainnet Ethereum.
Storage: Hyperledger Besu uses a RocksDB key-value database to persist chain data locally. This data is divided into a few sub-categories:
Blockchain: Blockchain data is composed of block headers that form the “chain” of data that is used to cryptographically verify blockchain state; block bodies that contain the list of ordered transactions included in each block; and transaction receipts that contain metadata related to transaction execution including transaction logs.
World State: Every block header references a world state via a stateRoot hash. The world state is a mapping from addresses to accounts. Externally owned accounts contain an ether balance, while smart contract accounts additionally contain executable code and storage.
P2P networking: Hyperledger Besu implements Ethereum’s devp2p network protocols for inter-client communication and an additional sub-protocol for IBFT2:
Discovery: A UDP-based protocol for finding peers on the network
RLPx: A TCP-based protocol for communication between peers via various “sub-protocols”:
ETH Sub-protocol (Ethereum Wire Protocol): Used to synchronize blockchain state across the network and propagate new transactions.
IBF Sub-protocol: Used by IBFT2 consensus protocol to facilitate consensus decisions.
User-facing APIs: Hyperledger Besu provides mainnet Ethereum and EEA JSON-RPC APIs over HTTP and WebSocket protocols as well as a GraphQL API.
JSON-RPC
HTTP JSON-RPC Service
WebSocket JSON-RPC Service
GraphQL
Monitoring: Hyperledger Besu allows you to monitor node and network performance.
Node performance is monitored using Prometheus or the debug_metrics JSON-RPC API method.
Network Performance is monitored with Alethio tools such as Block Explorer and EthStats Network Monitor.
Privacy: Privacy in Hyperledger Besu refers to the ability to keep transactions private between the involved parties. Other parties cannot access the transaction content, sending party, or list of participating parties. Besu uses a Private Transaction Manager to implement privacy.
Permissioning: A permissioned network allows only specified nodes and accounts to participate by enabling node permissioning and/or account permissioning on the network.
What does Hyperledger Besu support?
Hyperledger Besu includes a command line interface as well as HTTP- and WebSocket-based APIs for running, maintaining, and monitoring nodes in an Ethereum network.
The Besu client’s APIs supports typical Ethereum functionalities such as smart contract and dapp development, deployment, and operational use cases. Tools such as Truffle, Remix, and web3j enable these activities. The client implements standard JSON-RPC APIs, making integration with ecosystem tooling simple. The client also supports creating private, permissioned consortium networks.
Hyperledger Besu doesn’t support key management within the client due to security concerns. Instead, you can use EthSigner or any Ethereum-compatible wallet for managing private keys. EthSigner provides access to your key store and signs transactions via tools like Hashicorp Vault and Microsoft Azure.
Smart-contract- and local-configuration-based node and account permissioning are available within Besu. Private transactions are available using zero-knowledge methods in the client (including usage of the Aztec protocol). An off-chain approach requires using Orion, an open source private transaction manager separately developed by PegaSys.
At a high level, the architecture for Hyperledger Besu looks like:
Who is involved in Hyperledger Besu?
PegaSys, the protocol engineering team at ConsenSys, has been the primary contributor and maintainer of the codebase at the core of Hyperledger Besu since its launch in November 2018 as Pantheon. They built this Ethereum client with the goal of lowering barriers to entry for enterprises and maintaining and scaling mainnet. They have developed an active community using and building on the codebase. In addition, there are multiple applications building on top of Besu and consortiums using Besu in production. The PegaSys team is excited to work with the Hyperledger community to continue to strengthen Hyperledger Besu as a platform.
About the Authors
Rob Dawson is Product Lead at PegaSys. Rob has a highly technical background as an IT Developer and Leader with experience in a wide range of technologies including thin and thick clients, agile and heavy methodologies, security and protocols. He also has extensive experience in enterprise software and has led the product development of Hyperledger Besu.
Meredith Baxter is a Blockchain Protocol Engineer at PegaSys. Meredith has 8+ years software engineering experience working in distributed systems and full stack application development. She has worked on Hyperledger Besu since late 2017 when she joined as a member of the project’s founding development team.
Communications Service Providers (CSPs) are now showcasing confidence in areas where they can collaborate with their competitors to achieve better operational efficiency, make savings in cost and improve customer experience. There are numerous use cases where CSPs can collaborate to overcome the challenges that they currently face. Blockchain technology can serve as a platform where multiple stakeholders can collaborate in a consortium formed to achieve a common objective.
CSPs are exploring real-time use cases that can be implemented over blockchain and have the potential to transform the world by enabling transparency in existing processes. Number portability (NP) is one of the key use cases where operators across the world provide services and allow their subscribers to port out to another network. This requires their platform(s) to facilitate smooth transition of subscribers without losing unused prepaid balance and data sharing over a secure channel. In number portability operations, information exchange is possible between CSPs directly or via an intermediary but financial transactions or value exchanges are not possible or easy. With the evolution of blockchain technology, information and value can be exchanged securely and transparently while the porting process itself can be simplified without an intermediary. Sharing of telecom infrastructure among CSPs is becoming a need and a business process in the telecom industry where competitors are becoming partners to lower their increasing investments. This concept of tower or mast sharing is being encouraged across the globe and CSPs are looking for a trustworthy platform to manage the B2B contracts for tower sharing.
At Wipro, we are working with a number of CSPs to tackle the challenge of number portability using a Hyperledger Fabric-based blockchain solution.
Challenges of Number Portability
For end users
False rejection of port-out requests by CSP
Re-submission of KYC documents for every number porting request
Long waiting period to port-out successfully
High porting fees charged by service providers
Losing prepaid balance while porting
For CSPs
High OPEX for NP management for service providers
Additional costs for lookup services, routing services and interconnection for ported numbers
Longer time duration and complex process for porting validation
For regulatory authorities
Numerous complaints from users regarding port-out rejections and delays
Long duration for porting process and users are levied porting charges
Non-compliance of porting regulation by service providers
Lack of transparency in porting process
Hyperledger Fabric is a permissioned blockchain platform with an efficient consensus mechanism and permissioned membership services that can be leveraged to onboard participants in the blockchain network. The identity of the nodes and users, who are the members of this network, can be validated against the organizations’ identity management system. Therefore, there are no anonymous users in such a network. Managed Service Provider (MSP) is also called the Certificate Authority (CA) in Fabric parlance. The platform provides tools for MSP certificate generation. Hyperledger Fabric leverages container technology to host smart contracts called “chain code” that comprise the application logic of the system. There is no proof-of-work (POW) algorithm and crypto mining in Fabric, and it delivers high scalability and fast transactions. Rich queries over the immutable distributed ledger are supported. Hyperledger Fabric offers a modular architecture where developers can create plug-in components.
CSPs will have numerous benefits by adopting Hyperledger Fabric for real time use cases like Number Portability:
Simplified porting process – The current porting process is slow because of delays in unique porting code (UPC) generation, eligibility checks for porting and various other reasons associated with the mediating party. Hyperledger Fabric, with its distributed database capabilities, removes the mediating party and simplifies the process and allows exchange of information among parties.
Secure exchange of user data – Hyperledger Fabric is an enterprise permissioned platform that provides an immutable and secure exchange of information between the parties of the blockchain network.
Cost sharing or financial transactions over blockchain network – Prepaid users lose their unused balance during porting. Blockchain can facilitate the transfer of financial value between the CSPs over a secure and permissioned network.
Reduced operational costs and routing costs – Hyperledger Fabric, being a distributed ledger technology, allows for removal of an intermediary party. It has a direct impact on cost. With a distributed set up, each CSP has a routing number in their own distributed database thus saving the routing related costs.
Real-time and full transparency for CSPs, regulators and users – All the processes between various parties in a blockchain network can be monitored in real-time. All records, statuses and logs are registered in an immutable ledger and become fully auditable. Regulators will not only have full visibility but will also have the power to strictly enforce regulatory rules.
In number portability, information exchange is possible between CSPs directly or via an intermediary, but financial transactions or value exchange is not easy. As new emerging technologies disrupt the Telecom industry, these problems can become a thing of the past. Solutions built on enterprise blockchain have the potential to transform the world by enabling transparent environments that do not rely on trust. Our Hyperledger Fabric-powered solution, allows non-trusting parties to transact, trade and exchange information and value without intermediaries in between. With the evolution of Hyperledger Fabric technology, information and value can be exchanged securely and transparently while the porting process itself can be simplified, all without an intermediary.
About the author
Subrat Saurabh, Principal Consultant, Blockchain & Telco Domain Expert, Communication BU at Wipro Ltd, has more than 12 years’ experience in IT Solutions delivery, domain, technology, and the telco industry. He has deployed wholesale billing and number portability solutions for global clients and is a certified Scrum Master. Subrat holds a Bachelor’s degree in Telecom Engineering. He is a published author of two books (fiction) and received the award for being amongst the top hundred inspiring authors from India in 2018.
Those who study decentralized or self-sovereign identity technologies quickly run into two important mental models. The Decentralized Identity Foundation promotes the notion of hubs—services that help an identity owner manage data and interact through it. Hyperledger Indy and the Sovrin Foundation talk about agents—pieces of software that hold delegated keys, exchange digital credentials, and otherwise do an identity owner’s bidding.
Overlapping descriptions of hubs and agents have fostered a perception that they’re competing technologies. This is unfortunate, because the truth is quite different. Hubs and agents are actually synergistic, as explored below. Like a drummer and a guitarist, they contribute in vital and complementary ways to the music of identity.
But if we want cryptographic primitives to yield practical benefits, we have to package decentralized identity so it’s easy for a child or a grandparent who thinks of tech in terms of clicks on a cell phone. That’s where hubs and agents come in.
Hubs are the data managers of decentralized identity. Like DropBox or Google Drive or iCloud, they let you put data into the cloud with confidence that it will be secure, available, and shareable anytime, anywhere. Unlike those familiar services, hub interfaces are vendor- and platform-agnostic. If you migrate from Apple to Android, your data is unaffected. If you close an account with Google, your data survives, because the data is tied to you, not to an email account or a piece of hardware. If a hacker or a malicious sysadmin or the machine learning algorithm of a data miner peers into your storage, they see data encrypted by keys that only you hold.
Agents are the personal assistants of decentralized identity. Remember how Iron Man delegates work to Jarvis? Agents are connected and digitally empowered like Jarvis. They are the mechanism for sophisticated delegation that gets work done—work like giving and retracting consent, buying and selling, scheduling and reminding, auditing, monitoring, proving things with credentials, enacting and fulfilling contracts, issuing receipts, and so forth. They speak bits and bytes, keys and crypto, and protocols and transports, so their masters don’t have to. Unlike Alexa and Siri, they are trustworthy fiduciaries, because they work exclusively for their owners. They don’t stream data about their masters back to a corporate data lake to be analyzed and mined.
Better Together
Rock music often begins with a percussion groove to set tempo and mood, with the guitar joining a few bars in, as storytelling begins. The opposite sequence is also used, where a guitar or voice leads out, and drums appear later to rev up the energy. Either way, the full power and synergy of a band manifests when each component is actively playing its part.
Similarly, agents and hubs make more powerful music when they work together. Most work that agents need to do is rooted in and informed by data; an agent that has a hub to work with is likely to be far more useful to its master. And data is an asset, but cultivating it for security and usefulness can drown us in details without powerful tools, as anyone who’s cataloged years of cat videos can attest. Having an agent to enact decisions and reference the data in appropriate, automated ways in interactions is a no-brainer.
The straightforward ability to dovetail is part of what differentiates the hub+agent combination from more specialized SSI technologies like Solid, which have a more standalone vision. Solid’s features are similar to hubs. An integration path between it and the identity, credential, and protocol features of agents undoubtedly exists, but is not a design goal.
We expect that the most useful decentralized identities will use both hubs and agents.
Harmony
How, exactly, are duties divided between hubs and agents?
To answer that question, it’s important to understand that both agents and hubs are intangible software constructs that interact over the network through APIs or messages–and that the DID communication mechanisms they use are common. In other words, they share large amounts of DNA. What separates a hub from an agent is which high-level protocols it is assigned. The division of work is manifest in which messages are sent to which component. This division used to be muddy, but it is now clarifying nicely and should become even crisper. We advocate dialog around remaining questions, and in the meantime, we suggest the rules of thumb that follow.
Hubs and agents focus on different things. Overlap is shrinking.
Hub protocols are data-oriented. They model operations as commits to a data object, or as reads of an object state. Several datatype interfaces can be read, written, or queried in similar ways: Profile, Permissions, Actions, Stores, Collections, and Services. Collections is the most foundational to the hub’s role as a data manager; it is where chunks of data of almost any type can be accessed, both by the data owner and (if the owner wishes) by others. Permissions control access to data. Profile describes the identity owner (think a universal, self-hosted gravatar). Services is the basis of a hub’s extensibility mechanism. Stores and Actions are for advanced use cases that we’ll gloss over in this high-level discussion.
One identity owner may use many hubs. Hubs make the physical topology transparent; to the owner, it just feels like data is always available on whatever device and whatever network is convenient. In keeping with the hub’s focus on data management, hubs are not deeply trusted or deeply informed about their owner’s behavior. They don’t take actions on the owner’s behalf, and they don’t hold keys. However, hubs can relay messages to other components, like agents, for processing. They are superb data managers.
Agents are flow-oriented. Their job is to get work done, and the unit of work management is a protocol. Agents might support protocols for issuing credentials, negotiating payment, or dozens of other personal and business processes. The messages that arrive at agents are routed to a protocol handler that looks up the persisted state of the flow and takes the next step, based on what the message says. Agents do take actions on the owner’s behalf; for example, when Alice digitally signs a lease with her mobile phone, an agent has to do the underlying crypto because Alice can’t handle modular exponentiation in her head, and she can’t speak bits and bytes over Wifi.
A component diagram that shows how hubs and agents deploy and interact in a credential-oriented interaction may help to provide a tangible example:
Hubs and agents work together to connect Alice to other parties on the digital landscape.
Agents should generally defer storage management tasks to hubs. The persisted state that an agent adds to, when taking the next step in an incomplete workflow, should be read from and written to a hub’s sophisticated storage layers–and by viewing messages as data, hubs can add reliable delivery guarantees to route or relay functions that propagate messages to all of Alice’s agents. When Alice wants to share her cat videos with Bob, she should point him to a URI backed by her hub(s). It is possible that some agents will operate without hubs (e.g., IoT devices that emit sensor data but that don’t store much); however, most sophisticated agents will have hub storage available to them.
Hubs should generally defer complex, non-data-management work to agents. When Bob wants to buy a car that Alice is selling, he engages in a buy~sell protocol that begins as Alice receives a message from him. This message arrives at the boundary of Alice’s world at an endpoint she designates. That endpoint might be hosted on a hub, where the message can be persisted and replicated—or it might flow directly to one of Alice’s agents. Either way, it is the agent’s interface that Bob interacts with and that provides interoperable workflow. It is possible that some hubs will operate without agents (e.g., doing nothing complex beyond sharing data); however, most hubs will collaborate with agents nearby.
Conclusion
Hubs and agents are complementary technologies. Hubs are the data relays and data managers of decentralized identity; agents are the personal assistants. Each solves complex problems for identity owners, and each gets more powerful when paired with the other. We expect flexible and powerful decentralized identities to use both.
After working on the problem of identity online for more years than we care to admit, it is heartening to see that we are not alone: The identity community we’ve longed to see is here, and it’s transforming the world. In the months since Hyperledger Indy graduated to ‘production ready’ active status, we’ve seen an outpouring of digital identity business solutions come to market.
These accomplishments are due, in part, to the growth and maturity of the Hyperledger Indy code; but, equally, they wouldn’t have happened without a collaborative community of dedicated contributors passionate about changing the way identity works online. And their outstanding work is not going unnoticed by the wider technology community: self-sovereign identity (SSI) has gone from “interesting idea” to “this looks promising” to “we need to implement this now.”
The Time for SSI Has Come
Forrester’s recent “Top Recommendations for Your Security Program, 2019,” testifies to this, describing SSI as a “win” for customers and businesses, and urged chief information security officers (CISO) to “Empower your customers to control their own identities via self-sovereign identity.”
They can do this because exchanging verifiable digital credentials is at the heart of SSI. This ends the need for massive data silos, honeypots, and unsecured data repositories housed at countless corporations and organizations. Instead, anyone can hold secure and verifiable information about themselves, and through Zero-Knowledge Proofs (ZKP), minimize the information they decide to share with others. (ZKPs are an important type of advanced privacy-preserving cryptography now available in the open source community within the recently announced Hyperledger Aries project).
This doesn’t just benefit consumers in terms of information sharing, businesses also get to avoid GDPR and regulatory compliance issues and benefit from much better security. Moreover, we’re finally starting to see the big tech companies come to the realization that the status quo isn’t working when it comes to data collection, and sooner or later, it will affect their bottom line. SSI is the disruptive technology that the industry has been waiting for.
The Indy and Aries communities are driving this disruption in privacy and personal data by designing and building the protocols, technologies, and code that makes SSI possible. But moving beyond the code and building real solutions will require new companies. Like the Web 20 years ago, most of these will be startups who have a vision for this new way of interacting online.
Nurturing the Digital Identity Community
This is why we’re excited to be supporting the valuable work of the SSI community with the launch of the Self-Sovereign Identity Incubator.
Designed to help organizations and companies learn how to use code from Hyperledger Indy to create verifiable credential exchange products and SSI solutions, this intensive 12-week program based in San Francisco will be a bootcamp for identity entrepreneurs and start-ups. It also gives participating companies $180,000 in investment and the comprehensive hands-on technical support and mentoring they need to realize their business ideas and bring their products to market.
At a point where SSI is reaching critical mass, we want to see the identity community grow bigger and stronger and build the products that take SSI to the masses. As Sovrin Foundation Executive Director and CEO Heather Dahl recently noted at the New Context Conference in Tokyo, an event founded in 2005 by Digital Garage co-founder and Director of MIT Media Lab, Joi Ito, “Self-sovereign identity is the next disruptive innovation; it changes the very nature of how people connect with the companies and services that they rely upon online.”
It’s great to see the SSI Incubator already receiving its first batch of applications, with many from the same Hyperledger community Sovrin first worked with to donate the source code to Hyperledger Indy. These are the same members who we see contributing and maintaining the code repositories for Hyperledger Indy and Aries today,
These products are poised to transform the fundamental way the Internet runs and the way we will use it to the benefit of everyone. With our years of experience and depth of knowledge about digital identity, supporting this community and these projects is not just something interesting for us to do in our spare time. It is our job as leaders in technology and identity to support, educate, and most importantly, fund the projects, that will change the future of identity forever.
About the authors
Greg Kidd is the Founding Partner of Hard Yaka, a fund investing in portable identity, payments and marketplaces necessary for digital transformation. He has invested in more than 100 startups, including Twitter, Square and Ripple.
Dr. Phil Windley is chair of the Sovrin Foundation and the co-founder and organizer of the Internet Identity Workshop. He is a passionate technology educator and is the author of the books The Live Web and Digital Identity.
Welcome to our Community Spotlight series, which highlights the work of those taking on leadership roles in our special interest and working groups. Meet Richard Bloch, chair of the Hyperledger Healthcare Special Interest Group (HC-SIG) and founder of Digital Healthcare I/O.
Tell us about yourself. Describe your current role, your current business and background, and your involvement in the Hyperledger HC-SIG.
My name is Rich Bloch. Professionally, I have over 30 years of systems and software engineering and engineering management experience. I spent my first 10 years at Microsoft Corporation, developing Microsoft Word and Microsoft Flight Simulator. After leaving Microsoft to start my consulting groups, Business Learning Incorporated (businesslearninginc.com) and Digital Healthcare I/O (digitalhealthcare.io), I’ve spent much of my career working across a broad range of technology domains including Government (the FAA and various DoD agencies), aerospace, satellite engineering, and of course, healthcare.
I also serve as a community volunteer on the Board of Trustees as Chair, and am a Past Chair of the Foundation Board for Northwest Kidney Centers (NKC), the world’s first dialysis provider and the third largest non-profit kidney care organization in the US. In the chronic kidney disease (CKD) domain, I’m an active community speaker and advocate. In 2019, I was honored to deliver the keynote address at the Patient Engagement at UW Medicine Workshop presented by the Department of Medicine at the University of Washington.
I currently chair the Linux Foundation’s Hyperledger Healthcare Special Interest Group (HC-SIG), an international membership of over 1,000 healthcare professionals interested in identifying and using blockchain technology frameworks and tools to develop real-world, enterprise-grade solutions across the healthcare technologies domain.
What is one issue or problem blockchain can solve in the healthcare industry today?
It’s important to remember that blockchain technologies–which is a suite of complementary technologies including digital ledger technologies (DLT), self sovereign identity management (SSI), and cryptocurrencies/tokens–is less a stand-alone solution as it a set of unique technologies and protocols. So, to me, the real strength of blockchain technologies are in their universality of applicability. In an article that recently I co-authored, I liken our current understanding of blockchain technologies to the introduction of the Internet back in the early 1990s. Back then, no one really understood what the scope and capabilities were of these new and complex protocols, but we learned and grew to develop successful solutions that ran across the Internet that–today–seem commonplace and natural.
So, to answer the question of what one issue or problem that blockchain technologies might solve in healthcare today, I really can’t say. We’re right now solving many problems in the healthcare domain using all aspects of blockchain technologies–as we understand them today–and I fully expect to develop increasingly more complex solutions as we mature our understanding and use of these blockchain technologies. Some really great enterprise-grade solutions that exist in healthcare today that couldn’t otherwise exist without utilizing aspects of blockchain technologies include the Synaptic Health Alliance , which seeks to identify efficiencies in sharing provider credentialing across payer groups, and the recent collaboration between Boehringer Ingelheim and IBM to develop a more effective, higher quality, and safer clinical trials workflow in Canada.
Where do you hope to see Hyperledger and/or blockchain in five years?
I very much believe that our understanding of blockchain technologies, and even the technologies themselves, are extremely immature. Consider us at a version 1.0 in the industry. There’s tremendous room to grow here. So, even over this next year, and further into the future, my expectation is that we’ll be developing and implementing blockchain technologies that–while fundamentally recognizable as what we know today–will be significantly improved across many domains including:
Governance: From nothing today to something tangible and operationally effective, opening up blockchain technologies to a much broader spectrum of customers and industries that simply cannot operate without established governance strategies in place
Understanding: We, as implementers, will have gained experience, and from that experience, wisdom, in how best to make use of these unique technologies
Systems: Better, faster, safer systems are on the horizon thanks to much easier systems-level integration and interoperability. Operationally, performance and scalability will be at parity to more contemporary solutions. And underlying encryption and credentialing technologies will continue to improve, making for an increasingly frictionless implementation experience.
What is the HC-SIG working on currently? Any new developments to share?
The Hyperledger Healthcare Special Interest Group (HC-SIG) is designed around the personal and professional interests of our international membership. We maintain two fundamental tiers of engagement to keep members informed of activities within and across the SIG:
HC-SIG General: Our “front door” to newer members joining the SIG, as well as a more cross-cutting view of the work that we do in our subgroups and ad hoc teams
Subgroups and Teams: Key to developing actionable solutions within this SIG, each subgroup and team focuses on a special area of interest driven by their respective charter/mission statement
With that said, here’s a quick summary of the work being done across our HC-SIG subgroups and teams:
Patient/Member Subgroup: Developing patient-centric blockchain technologies solutions. A past solution focused around the implementation of a supply-chain solution developed around the safe distribution of donor milk across healthcare stakeholders. More recently, the subgroup is investigating patient-based access to longitudinal healthcare data.
Payer Subgroup: Focused around the payer component of the patient-payer-provider triad in healthcare. The subgroup is developing a white paper that defines a decision support workflow for the successful implementation of blockchain solutions.
Healthcare Interoperability Subgroup: Our newest subgroup, with plans to develop a proof-of-concept (POC) that takes a clinical use-case and integrates the policies, transactions and interoperable, clinical knowledge artifacts (assets) into a distributed solution.
Academic Research Team: Developing approaches to better present blockchain technologies to academic institutions such that healthcare stakeholders that rely upon and value independent, peer reviewed journals might gain a more objective and trusting understanding of these technologies
Use Case Development Team: Developing use cases within the context of the healthcare industry to model blockchain technologies implementation best practices
What’s the most important milestone for the Hyperledger HC-SIG to reach by the end of 2019?
The HC-SIG exists to engage, educate, and interoperate with our membership. While the charters/mission statements of each of our HC-SIG subgroups and teams differ accordingly, growing and maturing our understanding of membership needs, and how best we might serve them, is fundamental and primary to our ongoing success as a worldwide community of healthcare professionals.
Why should someone participate in the group? Why is it important for Hyperledger to encourage collaboration around adopting blockchain technologies in this industry?
I’m often asked this question of “why should I participate?” and my answer is always this: active membership in the HC-SIG puts you in touch with the unprecedented resource of over 1,000 people around the world who are pre-filtered to have an active interest in healthcare technologies/IT, and then filtered again by their interests/knowledge in applying blockchain technologies to this industry. It’s really a pretty amazing group of professionals who come together every couple of weeks to help one another discuss and solve difficult problems in their respective healthcare communities.
What are a few ways people can participate in and contribute to the HC-SIG?
As mentioned before, the HC-SIG is designed around the personal and professional interests of our membership. We provide many opportunities for focusing specific interests on blockchain technologies solutions in healthcare either through our HC-SIG subgroups or our ad hoc teams. And, in the spirit of a true open access, open source community, if members don’t see something that interests them, they have full authority and leadership support to develop a new subgroup or team that appeals to them. It’s almost a certainty that there will be others with similar interests who would love to participate in that new idea, whatever it may be.
How can people get involved in the HCSIG?
This group is run as an open community effort and everyone is welcome to get involved. The group has regular meetings, a mailing list and a chat channel. For each of these you are welcome to join, introduce yourself, ask questions and take part in the discussion. There is no invitation necessary and you can simply follow the information on the group wiki to learn how to get involved in the calls, the list and the chat.
Back to our Developer Showcase Series to learn what developers in the real world are doing with Hyperledger technologies. Next up is Jelle Sturm, DevOps & Backend Engineer at ScanTrust.
What advice would you offer other technologists or developers interested in getting started working on blockchain?
Start with the basics, watch some explanatory videos and take an online course. Then think about what you want to achieve using blockchain and start looking for the exact right technology to match your goals. Blockchain is still fairly new, but there are solutions popping up every week, some better than others.
If you already know a certain programming language, I would recommend you find a blockchain solution that has drivers/implementations for that existing language to get you started more efficiently. The best way to really get into it is to go to one of the many blockchain events around the world.
Give a bit of background on what you’re working on and how you got into blockchain?
I work for ScanTrust, a company focused on supply chain traceability and security. Supply chain is a really good use case for blockchain so naturally we had to explore this technology. At the moment we are implementing blockchain in our main software stack. This allows us to decentralize the data in the supply chain. In return, the end consumer will get better and more reliable track & trace data of a certain product.
Recently, we also launched a new initiative “The GoodChain Foundation,” which enables consumers to do good by donating tokens. Each interaction a consumer has with a product will release some tokens on the blockchain that can be donated to good causes or actual actors in the supply chain (e.g., farmers).
What Hyperledger frameworks or tools are you using in your projects? Any new developments to share? Can you sum up your experience with Hyperledger?
We use Hyperledger Sawtooth as we needed a very secure and industry-adoptable technology for our solution. My first steps with it were smooth, and it was nice to see that there is a fully dockerized example that works with a few simple commands to get you going.
What do you think is most important for Hyperledger to focus on in the next year?
I think 2019 is all about adoption of blockchain solutions. In particular, it will be crucial that there are more live examples of enterprise production use cases to show the value of blockchain. I think Hyperledger has already been doing a great job at familiarizing enterprises with blockchain technology and getting them to adopt it, but I think it’s critical that Hyperledger continues to play that role, especially in 2019.
As Hyperledger’s projects continue to mature, what do you see as the most interesting technologies, apps, or use cases coming out as a result?
For us, naturally, use cases around supply chain provenance and transparency are the most interesting applications. With the launch of Hyperledger Grid this year and with the formation of the supply chain working group, we also see that the Hyperledger ecosystem is strategically betting on these applications to be important use cases for the Hyperledger frameworks.
What’s the one issue or problem you hope blockchain can solve?
At ScanTrust, we are big believers in empowering consumers to trace back the provenance of their goods and check the authenticity of their goods, in particular in the food & beverage space. If there is one problem I could pick, then it would probably be solving the intransparency that we currently have in food supply chains.
Where do you hope to see Hyperledger and/or blockchain in five years?
I hope that five years from now, we will have completed a wave of enterprise adoption of blockchain. I believe that every major industry will have their own public permissioned consortium blockchain for specific use cases.
In parallel, public blockchain infrastructure will have matured a lot and will be more scalable, such that we will also see more and more applications and new decentralized business models built on public blockchains.
What is the best piece of developer advice you’ve ever received?
“A good developer should be lazy.’’ This always reminds me that we, as developers, need to find the most efficient and best suitable tools for the intended solution. Also, you can draw the line through to your coding style to minimize lines, be more efficient, automate tests/releases/deploys and so on. Never do something twice if you can build a loop.
What technology could you not live without?
I’m a big fan of Linux of course. Everything I develop runs on it, and it allows for very fun DIY projects at home. Also, I really couldn’t live without my IDE as coding in notepad is not the way to go in 2019.
