Category

Blog

Jul 23
0

Rhythm and Melody: How Hubs and Agents Rock Together

By | Blog, Hyperledger Aries, Hyperledger Indy

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.

image from ArtsyBee / Pixabay license. http://bit.ly/2YYiGUP

What Decentralized Identity Needs

Identity that doesn’t depend on centralized silos is an emerging phenomenon. Instead of rooting digital selfhood in government-granted identifiers or in accounts owned by online behemoths, it uses primitives such as decentralized identifiers (DIDs) and verifiable credentials (VCs) to derive trust from cryptographic protocols. This has the potential to unlock many benefits, including cost savings, cross-silo authentication, improved cybersecurity, identity for the unbanked and digitally disenfranchised, enhanced privacy and autonomy, and satisfying solutions to regulatory pressures from GDPR, HIPAA, and the like. Impressive proofs of concepts and pilots are underway all over the globe.

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.

The Decentralized Identity Foundation (DIF: https://identity.foundation/) and Hyperledger Aries (https://github.com/hyperledger/aries-rfcs) are actively working to make these technologies converge in useful ways for the benefit of the whole decentralized identity community. If you’d like to be involved, contribute to the DIF Identity Hub project at: https://github.com/decentralized-identity/hub, or reach out to Aries developers at https://chat.hyperledger.org/channel/aries.

Jul 18
0

Strengthening Hyperledger Indy and Self-Sovereign Identity

By | Blog, Hyperledger Aries, Hyperledger Indy

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. 

Jul 08
0

Community Spotlight: Meet Richard Bloch, Hyperledger Healthcare SIG Chair

By | Blog, Community Spotlight, Special Interest Group

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.

Photo credit: CB Bell Media

Jul 01
0

Developer Showcase Series: Jelle Sturm, ScanTrust

By | Blog, Developer Showcase

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.

Jun 27
0

Introducing Hyperledger Transact

By | Blog, Hyperledger Transact

Today we are excited to announce our newest project, Hyperledger Transact. Transact represents the continued evolution at Hyperledger towards greater componentization to allow rapid responsible adoption of new blockchain technologies. Transact provides a platform-agnostic library for executing transactions with smart contracts. It allows us to more rapidly integrate a variety of smart contract technologies such as WebAssembly across the Hyperledger family of projects. Transact is informed from experiences and design in multiple Hyperledger frameworks including Hyperledger Sawtooth and Hyperledger Fabric.

Smart contracts are a fundamental building block of distributed ledgers. In distributed ledger frameworks, a transaction represents an intended change that is submitted by a user. Transactions are interpreted by smart contracts, which update the current state of the system as a result.

Existing solutions for smart contract execution are generally tied to a specific distributed ledger implementation, which limits the code’s reusability. Hyperledger Transact will reduce the development effort for distributed ledger solutions by providing a standard interface for executing smart contracts that is separate from the distributed ledger implementation.

What is Hyperledger Transact?

Hyperledger Transact makes writing distributed ledger software easier by providing a shared software library that handles the execution of smart contracts, including all aspects of scheduling, transaction dispatch, and state management.

Hyperledger framework-level projects and custom distributed ledgers can use Transact’s advanced transaction execution and state management to simplify the transaction execution code in their projects and to take advantage of Transact’s additional features.

More specifically, Transact provides an extensible approach to implementing new smart contract languages called “smart contract engines.” Each smart contract engine implements a virtual machine or interpreter that processes smart contracts. Examples include Seth, which processes Ethereum Virtual Machine (EVM) smart contracts, and Sabre, which handles WebAssembly smart contracts. Transact also provides SDKs for implementing smart contracts and smart contract engines, which makes it easy to write smart contract business logic in a variety of programming languages.

Hyperledger Transact is inspired by Hyperledger Sawtooth and uses architectural elements from Sawtooth’s current transaction execution platform, including the approach to scheduling, transaction isolation, and state management. Transact is further informed by requirements from Hyperledger Fabric to support different database backends and joint experiences between Sawtooth and Fabric for flexible models for execution adapters (e.g., lessons from integrating Hyperledger Burrow).

Diving Deeper

Transact is fundamentally a transaction processing system for state transitions. State data is generally stored in a Merkle-Radix tree, a key-value database, or an SQL database. Given an initial state and a transaction, Transact executes the transaction to produce a new state. These state transitions are considered “pure” because only the initial state and the transaction are used as input. (In contrast, other systems such as Ethereum combine state and block information to produce the new state.) As a result, Transact is agnostic about framework features other than transaction execution and state. Awesome, right?

Transact deliberately omits other features such as consensus, blocks, chaining, and peering. These features are the responsibility of the Hyperledger frameworks (such as Sawtooth and Fabric) and other distributed ledger implementations. The focus on smart contract execution means that Transact can be used for smart contract execution without conflicting with other platform-level architectural design elements.

At a high level, the Transact architecture looks like this:

Transact includes the following components:

  • State. The Transact state implementation provides get, set, and delete operations against a database. For the Merkle-Radix tree state implementation, the tree structure is implemented on top of LMDB or an in-memory database.
  • Context manager. In Transact, state reads and writes are scoped (sandboxed) to a specific “context” that contains a reference to a state ID (such as a Merkle-Radix state root hash) and one or more previous contexts. The context manager implements the context lifecycle and services the calls that read, write, and delete data from state.
  • Scheduler. This component controls the order of transactions to be executed. Concrete implementations include a serial scheduler and a parallel scheduler. Parallel transaction execution is an important innovation for increasing network throughput.
  • Executor. The Transact executor obtains transactions from the scheduler and executes them against a specific context. Execution is handled by sending the transaction to specific execution adapters (such as ZMQ or a static in-process adapter) which, in turn, send the transaction to a specific smart contract.
  • Smart Contract Engines. These components provide the virtual machine implementations and interpreters that run the smart contracts. Examples of engines include WebAssembly, Ethereum Virtual Machine, Sawtooth Transactions Processors, and Fabric Chain Code.

Transact Features

Hyperledger Transact includes the following current and upcoming features (not a complete list):

  • Transaction execution adapters that allow different mechanisms of execution. For example, Transact initially provides adapters that support both in-process and external transaction execution. The in-process adapter allows creation of a single (custom) process that can execute specific types of transactions. The external adapter allows execution to occur in a separate process.
  • Serial and parallel transaction scheduling that provides options for flexibility and performance. Serial scheduling executes one transaction at a time, in order. Parallel scheduling executes multiple transactions at a time, possibly out of order, with specific constraints to guarantee a resulting state that matches the in-order execution that would occur with serial scheduling. Parallel scheduling provides a substantial performance benefit.
  • Pluggable state backends with initial support for a LMDB-backed Merkle-Radix tree implementation and an in-memory Merkle-Radix tree (primarily useful for testing). Key-value databases and SQL databases will also be supported in the future.
  • Transaction receipts, which contain the resulting state changes and other information from transaction execution.
  • Events that can be generated by smart contracts. These events are captured and stored in the transaction receipt.
  • SDKs for the following languages: Rust, Python, Javascript, Go, Java (including Android), Swift (iOS), C++, and .NET.
  • Support for multiple styles of smart contracts including Sabre (WebAssembly smart contracts) and Seth (EVM smart contracts).

Who’s Involved?

Hyperledger Transact’s initial code was developed by Bitwise IO and Cargill, with substantial influence from Intel’s previous contributions to Hyperledger Sawtooth. Design discussions with Fabric, Burrow, and Indy maintainers further rounded out the proposal. Transact aims to encourage interface alignment between the projects. Bitwise IO, Cargill, IBM, and Intel are currently involved in the Transact project.

Maintainers from Hyperledger Sawtooth, Hyperledger Fabric, and Hyperledger Grid have already expressed interest in using Hyperledger Transact in their projects. We believe this is just the beginning. We expect that adoption will grow as the project matures, due to the advantages of using Transact’s standard interface for executing smart contracts.

Want to Learn More?

If you are interested in using Hyperledger Transact in your project, you can see the Rust crate and documentation at https://crates.io/crates/transact.

If you want to chat with us or would like to help build Transact, please visit us on the Hyperledger #transact channel at https://chat.hyperledger.org/channel/transact.

About the Author

Shawn Amundson is Chief Technology Officer at Bitwise IO, a Hyperledger technical ambassador, and a maintainer and architect of Hyperledger Sawtooth, Hyperledger Grid, and Hyperledger Transact.

Thanks to the following people who helped make this blog post a success: Dave Cecchi, Anne Chenette, Emily Fisher, Mark Ford, Andi Gunderson, Dan Middleton, James Mitchell, Peter Schwarz, and Gari Singh.

Jun 24
0

Change Healthcare: 50 million transactions a day using Hyperledger Fabric

By | Blog, Healthcare, Hyperledger Fabric

Change Healthcare is on a mission to modernize the American healthcare system. A central part of that plan is extending its Intelligent Healthcare Network with blockchain technology to provide a faster, better experience for all.  

Change Healthcare operates the largest healthcare network in the country. Formed through years of mergers and acquisition, the healthcare infrastructure company links 900,000 healthcare providers and 5,500 hospitals with 2,200 government and commercial payers.

A network of this scale, built from a mix of companies, means a very complex back end with lots of systems that are working independently. To unite information and give customers faster, better access to data, Change Healthcare turned to Hyperledger Fabric to begin blockchain-enabling its Intelligent Healthcare Network.

The starting point was modeling an existing network linking providers to payers with a blockchain and then seeing if it could stand up to real-world traffic. After testing and assessing options, Change Healthcare’s launched this initial Hyperledger Fabric-powered network in January 2018. It’s been running as a parallel network since, processing as many as 50 million transactions a day—with throughput up to 550 transactions a second. That’s enough to handle all the healthcare claims activity that Change Healthcare handles across its full network.

The Hyperledger team has worked closely with Change Healthcare to document this large-scale network deployment and its performance in a detailed case study. Highlights include system criteria and planning, details on the supported workflow and transactions and future directions, including plans for ensuring interoperability, boosting throughput even further and migrating more business partners to the network.


CLICK HERE TO READ THE CASE STUDY

Jun 14
0

Developer showcase series: Brian Wu, Coding Bootcamps

By | Blog, Developer Showcase

Back to our Developer Showcase Series to learn what developers in the real world are doing with Hyperledger technologies. Next up is Brian Wu of Coding Bootcamps

What advice would you offer other technologists or developers interested in getting started working on blockchain?

To start your career in this space, you should spend as much time as you can reading blockchain news, white papers and books. Understand the basic blockchain concept from examples like Bitcoin, Ethereum and Hyperledger Fabric. Read Nakamoto’s Bitcoin white paper and Hyperledger blockchain books, visit Ethereum.org website and watch youtube videos. You also need to run some examples, so start to write a smart contract to get some hands-on experience.

Give a bit of background on what you’re working on, and let us know what was it that made you want to get into blockchain?

I am a software architect with 17 years of experience working on blockchain, big data, cloud and other emerging technologies. I am currently working on a large blockchain project in the finance industry.

In today’s technologically advanced world, blockchain is a cutting-edge and revolutionary technology. The decentralized P2P features give it the potential to influence every aspect of the global economy. Decentralized applications are becoming more popular. However, we are still in the early stage of blockchain evolution so now is an excellent opportunity to get involved in this space.

What are the main differences between teaching Hyperledger to students and developing Hyperledger applications?


While teaching at Coding Bootcamps, I often get questions from students that help me view blockchain development differently. For example, during the class we follow recipes that are small models of actual, larger scale projects from my daily work. Thus, teaching concepts help me refresh my knowledge and skills that are essential in my everyday job.

What do you think is most important for Hyperledger to focus on in the next year?

Hyperledger Fabric FabToken with EVM integration.

Tell us briefly about your books on Hyperledger? What Hyperledger technology they cover and what inspired you to write your books?

Hyperledger Cookbook helps developers plan, design, and create a full-fledged enterprise decentralized application using Hyperledger technologies. The book explores the entire Hyperledger blockchain family, including frameworks, such as Fabric, Sawtooth, Indy, Burrow, and Iroha, and tools, such as Composer, Explorer, and Caliper. It is also packed with problem-solution-based recipes to tackle pain areas in the blockchain development cycle.

There are few (if any) books currently on the market that discuss the entire range of Hyperledger projects as they are mostly focus on Fabric and Composer technologies. I think reading a good hands-on Hyperledger book can help readers to get more knowledge and insights by working on practical examples and recipes. Practical resources are great for preparing you to start developing and deploying these technologies.

As Hyperledger’s incubated projects start maturing and hit 1.0s and beyond, what are the most interesting technologies, apps, or use cases coming out as a result from your perspective?

Hyperledger recently added two projects to its family – Hyperledger Aries and Hyperledger Ursa – that focus on digital cryptographic security. The zero-knowledge proofs have become quite popular in blockchain today. Expect to see more use cases for applying these technologies.

What’s the one issue or problem you hope blockchain can solve?

Performance

Where do you hope to see Hyperledger and/or blockchain in 5 years?

In next 5-10 years, a lot of industries will start embrace blockchain, leading to a range of career opportunities:

  1. Most  finance companies will leveraging blockchain technology on their payment system and other finance service.
  2. National cryptocurrencies will emerge.
  3. Blockchain will tightly integrate with  the most popular technologies such as AI, big data, cloud and IoT.  
  4. Web 3.0 will be powered by blockchain technology.

What is the best training advice for those who want to build a career in blockchain or Hyperledger?

Learning blockchain is different than learning one single coding language like Java or Python. Before you start coding blockchain, you have to know lots of concepts such as cryptography, decentralized networks, etc. After learning these concepts, you need to learn a coding language like JavaScript, C++, Python or Java. Currently, the easiest and most popular programming language for building Hyperledger applications is JavaScript (for instance, frameworks like Node.JS and React.js are common). Also, you need to know how to design a database. MongoDB is the most popular database for Hyperledger blockchain applications.

Learning blockchain via online free resources is slightly difficult and lengthy but not impossible. Since blockchain is relatively new, you may not get as much community support from other developers compared to more popular coding languages like PHP, HTML, etc. Thus, it is a good idea to take hands-on training classes to learn it fast and thoroughly.

My last piece of advice is that you should align your learning with an industry-recognized certification like Certified Hyperledger Fabric Administrator. Gaining a reputable certification adds lots of credibility to your resume and credentials.  

What is the best piece of career advice you have for blockchain beginners?

First of all, I welcome you to the world of blockchain. You should be patient as there are lots of things you need to learn and master. Second of all, follow my advice on training, especially gaining an industry-recognized certification. The next step for securing a high paid career as a blockchain consultant or developer is to build your portfolio by contributing to blockchain projects or creating new ones. Improve your soft skills like communication, networking, etc.

Last, but not least, make sure to polish your resume to reflect your passion, knowledge and expertise in blockchain development by listing technologies like Hyperledger or blockchain coding languages and projects that you’ve done.

What is the best piece of developer advice you’ve ever received?

Never stop learning

What technology could you not live without?

Internet

Jun 06
0

Sawtooth PBFT, Part 2: Extensions and Changes

By | Blog, Hyperledger Sawtooth

The upcoming release of Hyperledger Sawtooth 1.2 includes Sawtooth PBFT—a new, Cargill-sponsored, production-ready consensus algorithm. Sawtooth PBFT is much more than a basic implementation of the PBFT consensus algorithm that was originally defined in 1999. Sawtooth PBFT has all the core features of the original definition—it provides the same safety and liveness guarantees—but we have adapted the algorithm to take advantage of features unique to blockchains, and extended it to provide more flexibility and robust guarantees.

In two earlier blog posts, Making Dynamic Consensus More Dynamic and Introduction to Sawtooth PBFT, we introduced Sawtooth’s dynamic consensus interface and explained how the PBFT consensus algorithm works from a high level. In this post, I’ll describe the adaptations and enhancements that helped us bring a robust PBFT consensus algorithm to Hyperledger Sawtooth:

  • Sequence number simplications (no more watermarks)
  • An idle timeout to guarantee more liveness
  • Regular view changes for fairness
  • A consensus seal as proof of commit
  • No checkpoints for garbage collection
  • A catch-up procedure for slow and new nodes
  • Membership changes

Sequence Number == Block Number

In traditional PBFT, the primary node assigns a sequence number for each request when it broadcasts a pre-prepare message for the request. In Sawtooth PBFT, the “requests” are actually blocks that are created by a Sawtooth validator. Blocks in Sawtooth are ordered; we can take advantage of this ordering to simplify the sequence numbering in PBFT. Instead of assigning a sequence number for each block, the primary node will just use the block number as the sequence number.

This simplification makes the algorithm easier to understand. It also means that secondary nodes don’t need to check that the primary node picks reasonable sequence numbers. Originally, nodes would have to make sure that the sequence number was between a low and high watermark, in case the primary node picked a number that was so high that it exhausted all of the possible sequence numbers. Now that the sequence number is automatically determined by the block number, a secondary node only needs to check the pre-prepare message to make sure that the sequence number matches the block number of the block in the message. It’s as simple as that!

More Liveness with an Idle Timeout

One liveness problem that traditional PBFT does not solve is the “silent leader” problem. The leader is responsible for building and sharing blocks with the rest of the network to start a new round of consensus. Even if transactions are being submitted to the network, the leader could stay silent by never sharing a block with the network; this “silent leadership” would allow the leader to halt progress indefinitely.

To solve this problem, we implemented an idle timeout as a new way to trigger a view change. After a block is committed, each node starts its idle timer. The primary node must publish the next block and broadcast a pre-prepare message for the block before the timer expires. Otherwise, a secondary node will initiate a view change.

The idle timeout provides more robust liveness by ensuring that a faulty primary node can’t stall the network indefinitely. This timeout can lead to unnecessary view changes, though; if the network really is idle (no transactions are being submitted), then the primary node isn’t faulty when it doesn’t publish a block, since the Sawtooth validator does not publish a block when there are no transactions. The cost of these extra view changes is negligible, however; when the network is idle, a view change will not hinder the performance of the network.

Pseudo-Fairness with Regular View Changes

Determining if a leader is acting fairly is a very complex and challenging problem; there is still a lot of research being done to solve it.

To get us a step closer to fairness, we introduced a regular view change mechanism to Sawtooth PBFT. This mechanism is fairly simple: after every nth block is committed, the network will “force” a view change by incrementing its view by one. The number of blocks between forced view changes is called the forced view change interval, which is a configurable setting.

Regular view changes reduce unfairness by not allowing any node to control block publishing for too long; instead, every node gets a chance to be the leader for a period of time. While this doesn’t completely solve the fairness problem, it limits unfairness in a way similar to Tendermint and lottery-style consensus algorithms. This solution is also inexpensive: since the view change is “forced” (the view number is directly incremented) at a consistent point across the network, we don’t need the expensive view changing procedure.

Consensus Seal

The original PBFT algorithm does not define a reliable way to check if a block was committed validly (that is, when 2f + 1 nodes agreed to commit the block). The only way to check this would be to request each node’s commit messages and count them. The problem with this approach is that old messages might be unavailable if the messages were removed (garbage collected) or if a node is no longer part of the network.

To overcome this limitation, we implemented a consensus seal for each block that is committed. The consensus seal is a signed data structure that contains a block ID and 2f signed commit messages for that block ID. This seal proves that the network agreed to commit the block and that the block was committed validly.

The seal is stored on the blockchain itself, which means that the seal is immutable and can be checked at a later point. A seal can’t be inserted directly into the block that the seal is for, however, due to the way blocks are constructed by the Sawtooth validator. Instead, the seal is added to the next block that is committed to the blockchain; thus, each block contains the consensus seal for the previous block. This approach has a limitation—the most recently committed block can’t be validated using a consensus seal, since there isn’t a subsequent block yet. However, all previous blocks in the chain can be validated to ensure that they were committed validly, which is a useful guarantee.

Catching Up

In the real world, distributed networks face failures, segmentations, dropped messages, and many other hiccups. When these issues arise, nodes may fall behind, so they need a way to catch up to the rest of the network.

Sawtooth PBFT uses a special catch-up procedure that takes advantage of the consensus seal extension. The catch-up procedure is best illustrated by an example.

Let’s say the network as a whole has committed block 100, but a node has fallen behind and has only committed blocks up to block 90. When the slow node eventually gets block 91, it waits for a pre-prepare message from the primary node. Because the network has already moved past this block, though, the node never gets this old pre-prepare message. Instead, the slow node gets block 92, which contains a consensus seal for block 91. The node examines the seal from block 92 to make sure it’s valid, then commits block 91. Our node knows that it can skip the usual consensus procedure because the consensus seal in block 92 proves that the network agreed to commit block 91.

The node follows this procedure until it commits block 99. At this point, it needs to do something different. Because there is no block 101 yet, the node doesn’t have a seal for block 100. So the node broadcasts a request to the rest of the network for a consensus seal for block 100. If another node has already committed block 100, that node builds the seal and sends it directly to the node that requested it. When the node receives the seal, it will verify the seal and commit block 100. The node that fell behind is now up to date!

Who Needs Checkpoints?

As originally defined, PBFT uses a checkpoint procedure to perform garbage collection for each node’s log of consensus messages. In this procedure, the nodes exchange messages to come to consensus on the current version of state. When the nodes have agreed on the current state, they save these messages as proof of the agreement, then discard all previous consensus messages.

Sawtooth PBFT does not need this checkpoint procedure. Because each block contains a consensus seal that provides proof of the validity of the previous block, and each block is immutable and permanent by nature of a blockchain, every block contains a checkpoint that will be kept forever. This means that the nodes can clean up old log messages any time they wish, while the state can still be verified using the consensus seal.

Membership Changes

Another fact of the real world is that network membership can change. This happens for a variety of reasons: a node may need to be replaced or a new company might want to join a consortium’s network. The original PBFT algorithm does not define a procedure to change membership of a PBFT network, so we implemented our own.

In Sawtooth PBFT, membership in the network is determined by an on-chain Sawtooth setting, sawtooth.consensus.pbft.members, which is a list of the public keys of all nodes in the network. Since this list is on the blockchain itself, it’s shared and agreed on by the whole network, which makes changing membership easy.

An administrator can update the on-chain setting to add, remove, and reorder nodes by submitting the change as a transaction. Each time a block gets committed, all PBFT nodes check this setting to see if it changed because of a transaction in that block, then update their local state if necessary.

Like forced view changes, a membership change is done at a consistent point across the network: when a block is committed. This consistency makes the local view of membership on each node easy to update in an atomic way. This approach to membership also makes it easy to check the historical membership throughout the life of a Sawtooth blockchain managed by PBFT consensus.

Summary

Sawtooth PBFT has a lot to offer. It not only includes all the functionality you would expect from PBFT, but it adds features and optimizations for real-world use. We’ve developed new solutions to overcome limitations of traditional PBFT. Plus, we’ve been able to take advantage of the properties of a blockchain, such as immutability and ordering, to make the algorithm more efficient and robust.

Want to Learn More?

These features are all new to PBFT, and some of the implementations are unique among published consensus algorithms. If you’re interested in learning more about our PBFT extensions, read the regular view changes RFC, consensus seal RFC, and PBFT catch up RFC. Also, check out the Sawtooth PBFT documentation and source code on GitHub.

Do you have questions? Do you have comments or concerns about how the extensions work? Let us know in the #sawtooth-consensus-dev channel on Hyperledger Chat!

Stay tuned for more news and info about the upcoming Sawtooth PBFT 1.0 release.


About the Author

Logan Seeley is a Software Engineer at Bitwise IO. He has been a part of the Hyperledger Sawtooth community since May 2018,


Jun 03
0

Hyperledger Kicks Off its 2019 Summer Mentorship Program

By | Blog

Today, Hyperledger kicks off its 2019 Summer Mentorship program, a hands-on, paid opportunity for students from around the world to gain real world experience advancing open source blockchain technologies. Now in its third year, the program welcomes 17 mentees from 12 countries. They will be paired with 25 mentors from 17 organizations, ranging from IBM to the Budapest University of Technology and Economics and from VMware to Técnico Lisboa and Soramitsu.

Together, they will tackle a line-up of projects that provides new developers exposure to Hyperledger open source development and entry to the technical community. The program, formerly known as the Hyperledger Summer Internship program, has grown in size and popularity, expanding from six projects in the first year to 17 this summer. More than 300 students from 36 different countries across Asia, North, Central and South America, Europe, Africa and Oceania applied this year.

Hyperledger renamed the program to put an emphasis on mentoring as a key path to growing the community for open source development and enterprise blockchain. Mentees will be tackling research and development projects key to advancing the Hyperledger ecosystem and enterprise blockchain. They will also get a leg up in building their networks and their resumes.

Hyperledger views its Summer Mentorship program as a win for the whole community as mentoring is key to career development at every stage. Open source communities thrive when there is ongoing learning and collaboration across markets, organizations, and experience levels. Bringing a new generation into the Hyperledger community is a growth opportunity for all.

We asked some of our mentors about the role mentorship has had in their career development and what they see as the benefits of this program for them, their mentees and their projects. Here’s what we learned:

Swetha Repakula, IBM Open Technology

From a young age, I have been fortunate enough to have mentors that have helped me find what I am interested in and guide me towards a path of success. In open source, I have found mentorship is very important, and I have had some great guidance from people inside IBM and outside. These people helped me find my voice and showed me how to navigate open source development to be a productive member in the community.

The mentorship program is a great focused way to introduce new developers to the Hyperledger community and more broadly open source development. I believe mentees will leave with skills that will help them throughout their career. As a mentor, I am looking forward to sharing the things I have been taught and passing on the lessons I have learned. Last year I really enjoyed working with our intern and being one of the first people to introduce her to the world of open source. This year, I am a co-mentor of a project that entails adding a new contract runtime option to Fabric that I am very excited about. I think there is a lot of potential, so I am looking forward to seeing what our intern creates.

David Huseby, Hyperledger, The Linux Foundation

I am always excited when the Hyperledger mentorship program gets going each year. During the process of developing enterprise blockchain platforms we always discover really interesting applications and integrations with the technology. The mentorship program gives our community the chance to explore the opportunities more. It’s the fun that we get to have after all of the hard work. I can’t help but be excited and this year is no exception.

For me, being a mentor keeps my perspective on the open source community fresh and gives me an opportunity to challenge my own assumptions. Fielding mentee questions and addressing their roadblocks gives me the chance to see our community through their eyes. That fresh look is valuable to me.

For me, the benefits are that I get to influence the open source culture by introducing mentees to it with the right set of assumptions and openness. The mentees get direct access and influence over core Hyperledger technology. It’s a great resume builder and the connections created are valuable. As for Hyperledger, we get to direct the mentees to explore the exciting opportunities that we discover while building the technology but don’t have time to do.

Laura Spinaci, Blockchain & Innovation Mentoring Lab

Mentorship is something that I always look for through online resources and groups.

40% of what I know and of the experience I have comes from meticulously following subject matter experts in fields I was interested to learn outside jobs I’ve held. The same holds true for blockchain. That’s why last year I founded the Blockchain & Innovation Mentoring Lab, where I give developers and blockchain professionals the opportunity to get hands-on, concrete experience with Hyperledger use case implementations.

Mentoring is based on a mutual exchange of knowledge, experience, and interests.

The best way to learn is to teach, plus I would like to find a way to model and scale the Hyperledger Mentorship program through my own mentoring program.

I believe that working from inside Hyperledger will give my mentee the opportunity to understand the genuine value of this community, which is sometimes misunderstood from the outside, and the training to use tools that the community offers freely to those looking to enhance their knowledge and experience in blockchain. He should also make connections that can be really beneficial for his future career.

We are working on SSI Identity applied to IoT devices in Telecom industry. Blockchain is the catalyst of IoT and will be the invisible technology that will allow IoT massive adoption.

It is key to overcoming the main IoT challenges (security, privacy, mobility, heterogeneity, etc) through standards (like DID and verifiable claims).

Telcom is in the early stages of its blockchain development, but the impact that SSI will have in this industry (and others) combined with IoT will be huge. I’m looking to expand the scope of this project outside the internship also through my mentorship program.

Rafael Belchior, Técnico Lisboa  

Mentorship has the potential to completely change the course of a career. One of the secrets of success is to find a dedicated mentor that can help remove blockades and indicate the right direction. As a student, mentorship propelled me to explore my skills and strengthen them, while developing myself as a person. As a mentor, I have the chance to not only help someone improve but also myself. Mentorship is a great way to learn about ourselves and learn how to teach. Helping and teaching others allow us to discover new skills and, conversely, find out what we need to work on.   

The Hyperledger Summer Mentorship provides a unique opportunity to get involved with the fantastic open-source community behind Hyperledger projects while working on a project valuable to society. My mentee will have great networking opportunities while having a unique learning experience: the possibility to tune skills related to blockchain theoretical and practical concepts. Furthermore, she will have access to valuable feedback and guidance.

Our project, Hyperledger Fabric-Based Access Control, will leverage Hyperledger Fabric to store access control components (for instance, user attributes, or variables linked to a context) to be used on different use cases. This allows a system (for instance, a healthcare system) to delegate its access control processes to the blockchain. Chaincode can be used for enforcing access requests, to take advantage of different blockchain properties, namely auditability, traceability and decentralization. This project can help decentralizing trust relative to access control, being an attractive solution to multi-enterprise scenarios or public administration.

Salman Baset, security and blockchain guy

Mentorship has played an important role throughout my career. I have tried to seek mentors that provide me with a diverse perspective, which can open my eyes to the unknown horizons.

Interacting with students is always refreshing allows one to see things from a fresh perspective. My hope is that my mentee will become an active contributor or user of open source projects. The ultimate goal of the project I am mentoring this summer is to make it super easy to analyze the provenance of data stored in a Hyperledger Fabric-based network. My wish is for this project to transition into a Hyperledger Lab, and ultimately, an incubation project for analyzing data stored within a Fabric-network.

Attila Klenik, Budapest University of Technology and Economics

A good mentor-mentee relationship is an immense help in getting a grip on a complex domain, such as blockchain technologies. Even with expert guidance, blockchain-based projects have a steep learning curve.

I was also a Hyperledger Intern in 2016, and I found the open-source Hyperledger umbrella a little bit intimidating at first. But my mentor helped me to break down the problems and challenges into manageable chunks. He taught me to proceed in small increments with my solution. This was the first valuable takeaway for me as an intern, and I intend to use the same approach now, as a mentor.

The second takeaway I’d like to emphasize is that mentoring shows its true potential when applied on the community level. You cannot be an expert at everything, so you must learn to reach out to the community. Especially when working on a project (e.g., Hyperledger Caliper) that requires a broader understanding of multiple other projects.

My first Hyperledger Hackfest event played an important part in connecting with the community (and several project maintainers), which put me on the way to later becoming a project maintainer myself, and now a mentor in this program. So I would encourage the mentees to jump into the community waters and explore the different projects (including the other internship projects).

Being a mentor in an international program will definitely be a useful and new experience for me. I expect that consulting someone new to the Caliper project will also help sharpen my skills with the community as a project maintainer.

Caliper is still under active development, moreover, it interacts with multiple other projects as well. Thus the mentee will have an opportunity to closely work together with the project contributors, as well as the Hyperledger community, and not just with his mentors.

The mentorship project will be an integral part of Caliper, enhancing its usability and easing its adoption throughout its users. I have great hopes that this collaboration will benefit everyone, and further increases the momentum of Caliper.

Jiahao Chen, VMware

I have had several mentorship experiences in my career so far, and each of them was memorable. Mentorship helps me make improvements, not only in programming skills but also in the skill of how to ask questions. Proper communications can make people closer and drive them to put more enthusiasm into their work.

The benefits of this program for me will be to communicate and get feedback from the mentee and make progress together.

Our mentee can improve his skills and expand his horizon with assistance from mentors like Baohua, Haitao, Litong and me.

This mentorship program could also help improve the quantity and user experience of our project.

Featured image: Photo by NESA by Makers on Unsplash

May 31
0

Hyperledger Launches New Supply Chain Special Interest Group

By | Blog, Special Interest Group

Hyperledger has launched its sixth cross-industry Special Interest Group (SIG), the Hyperledger Supply Chain SIG, to facilitate focused technical and business-level conversations related to appropriate use cases for blockchain technology across Supply Chain management. The new group will cover a broad range of topics, including logistics, provenance, authentication, track-n-trace, related IoT utilization, and similar inter-related areas of interest. SIG participants will also contribute requirements to Hyperledger’s supply chain project, Grid. Hyperledger Grid intends to provide reference implementations of supply chain-centric data types, data models, and smart contract based business logic – all anchored on existing, open standards and industry best practices.

The distributed ledger of blockchain is already enhancing collaboration among shippers, carriers, and forwarders as well as producers and manufacturers, who themselves represent every industry imaginable. Blockchain is taking on a growing role in ensuring reliable tracking of goods in Logistics and Supply Chain and has the potential to help reduce delays caused by manual, often “paper-based” cross-border, settlement, tracking, and regulatory processes.

There are many challenges to overcome before blockchain elements like DLT and smart contracts can be deployed widely in the logistics and supply chain industry. According to DHL’s research, “Likely the biggest challenge will be achieving successful industry adoption through collaboration and even co-opetition between diverse Logistics and Supply Chain stakeholders that have legacy processes and varying interests.”

The new Hyperledger Supply Chain SIG, led by chair Jay Chugh, Senior Director, Oracle Cloud, and vice chair Joshua Q. Satten, Senior Director of Blockchain (North America), Wipro Limited, is designed to address some of these challenges by bringing the collective wisdom of the community in a vendor-neutral, open source manner, using the various available components of the overall Hyperledger open-source blockchain framework.

This SIG will serve as a platform for the community to share knowledge and build collaborative efforts, learning from each other’s experiences, successes, and challenges. The potential for blockchain in Logistics and Supply Chain will be predicated by moving from concepts and pilot applications to viable deployable solutions, built on lessons learned via open collaboration.

“Blockchain is a game changer for Supply Chain transparency and efficiency. Hyperledger’s Supply Chain SIG aims to harness the collective wisdom of experts in blockchain and supply chain to collaboratively bridge the gap between real world and theory, and advance the adoption of Hyperledger blockchain in supply chain.” – Sarabjeet (Jay) Chugh, Senior Director, Oracle Blockchain, and SC-SIG Chair

The Hyperledger Supply Chain Special Interest Group

The Hyperledger Supply Chain Special Interest Group (SC-SIG) represents a global membership of logistics and supply chain professionals united in advancing the state of the supply chain industry through the implementation of enterprise-grade technology solutions utilizing the Hyperledger greenhouse of business blockchain frameworks and tools.

The activities of the Supply Chain SIG will include:

  • Identifying related reference architectures (for example  business and integration architecture, technical and infrastructure architecture), frameworks such as Hyperledger Grid, and models (OSI), use cases, current pilots and proofs of concept, and production case studies;
  • Sharing stories of successes, failures, opportunities and challenges;
  • Exploring and addressing cross-cutting architectural principles, options and decisions  like performance and scalability, security, identity management and privacy, and identity in logistic contexts;
  • Identifying existing or needed common critical software, middleware, and hardware components that would serve the particular needs of supply chain.
  • Working towards proposing solutions to the problems identified;
  • Identifying conferences or other opportunities to connect face to face, as well as submit talks or present as a group at an event;
  • Identifying the business community and building an inclusive platform for early adopters to contribute with their experiences;
  • Identifying all different protocols across supply chain to build standardization across the different parties and efforts; and
  • Supply Chain best practices, awareness of and working in accordance with such rules as customs & import export regulations.

“Addressing distributed & decentralized frameworks for enterprise and cross-industry Supply Chain management is a truly unique need that will be addressed through this new Hyperledger SIG. What makes this special is the confluence of players coming together to advance standardization and adoption including those from transportation, logistics, and major companies from just about every major industry you could think of; whether you’re in consumer goods, technology, aviation, commodities, or just about any other non-virtual business, a company’s supply chain is something that exists as the core of both of its current profitability and its future desired operating model.” – Joshua Q. Satten, Senior Director of Blockchain (North America), Wipro Limited, and SC-SIG Vice Chair

How to get involved in Hyperledger Special Interest Groups

SIGs gather community members from an industry segment to work on domain-specific problems and create an environment for open discussion, document co-creation and solution proposals. SIGs help specific vertical markets in their efforts to address problems specific to that particular community. Hyperledger now has six SIGs, including ones focused on healthcare, telecom and social impact.

Participation in any SIG is open to everyone in the community. Each group has an open e-mail list, a Chat channel, and a wiki page. Live meetings are also held regularly via web teleconference. When needed, a task force can also be created within the SIG and have working sessions to discuss specific work items.

If you’re interested in joining the Supply Chain SIG, please subscribe to the mailing list and join the Chat channel where meeting details will be announced. You also can visit https://wiki.hyperledger.org/display/SCSIG or find a list of other community meetings on the Hyperledger Community calendar. We look forward to your participation and contributions!