Category

Blog

Nov 22
Love0

Aries Connectathon: A Community-Driven Event for Identity Projects at Hyperledger

By Blog, Events, Hyperledger Aries

With three identity specific projects, Hyperledger is now home to a dynamic and growing community with hundreds of unique contributors and maintainers. The first identity-focused project was Hyperledger Indy first launched in 2018, then Hyperledger Ursa later that year. In early 2019, Hyperledger Aries launched to create a shared, reusable, interoperable tool kit for the exchange of verifiable credentials across systems and networks. We’re now thrilled to announce the Hyperledger Aries community will be meeting December 3-5, 2019 in Provo, Utah, for an in-person connectathon.

The goal of this event is to increase communication, interoperability, and support across the many Aries compatible projects. Like the previous, more informal, connectathon held earlier in 2019, this is a community-led event. Some of the focus will be on certain Aries projects currently in development within the community including, but not limited to: 

  • Aries Cloud Agent – Python, developed by the government of British Columbia
  • Aries Framework DotNet, the Open Source foundation for StreetCred’s mobile app
  • Mattr Global’s Open Source Mobile Agent (OSMA)
  • Aries Framework Go, developed by SecureKey
  • LibVCX based projects, supported by Evernym


The Sovrin Foundation, a leading contributor of Indy, Ursa, and Aries projects, is hosting the Aries Connectathon.

After kicking off with an overview of the key topics at this architecture and design focused event, attendees will focus their work on collaboration across Hyperledger Aries compatible codebases with test suites, tools, and direct interoperable interaction. This includes DID Communication, Verifiable Credential Exchange, DID Exchange, and other protocols targeted for wider adoption. Time spent at this community event will primarily be workshop related, supported with speakers and discussions on relevant topics.

It’s important to note that this is primarily a coding event; however, all contributors, maintainers, and community participants from any project interested in these topics are welcome to attend. Most of the participants at this event will already be active participants in the Hyperledger community and should be ready to hit the ground running. The Aries Connectathon is a great place to roll up your sleeves and get to work!

Hyperledger and Streetcred have already generously offered sponsorship to help cover some of the costs of the three-day event. Many event sponsorships are still available. 

Please see the event wiki to register and find out how to get involved.

Nov 20
Love0

Accenture Open Sources Blockchain Integration Framework as a Hyperledger Lab

By Blog, Hyperledger Labs

The growth in the number of blockchain platforms is booming. That is a good thing. Looking beyond a “one size fits all” platform sparks new possibilities and may lead to platform innovations we have yet to imagine. But the ecosystems developing around platforms must also interact for blockchain to achieve its full potential. 

With the future state of interoperability as an end goal, last year Accenture announced that we developed and tested two solutions that allow two or more blockchain enabled ecosystems to integrate. Since then, we developed a new solution specifically created for permissioned blockchains that works without a central connector node. I am happy to announce that we open sourced this new solution as Blockchain Integration Framework, a Hyperledger Lab.

Blockchain Integration Framework defines a communication model that lets permissioned blockchain ecosystems exchange any on-chain data or custom assets, independent of the platform. Specifically, it introduces an “interoperability validator” overlay network for each of the blockchain networks for which you want to exchange assets. Interoperability validators are known or broadly discoverable by the ecosystem and typically participants already taking part in the governance or consensus. 

High-Level Workflow

Interoperability validators will collectively handle export requests from local nodes by verifying against their version of the ledger (steps 1 to 3). Each request is answered by a (configurable) minimum quorum of validator signatures (steps 4 and 5). The network can continue working even if some validators are down or not participating, assuming the minimum quorum can be guaranteed. Any secure off-chain communication system can deliver messages certified by a distributed ledger’s transfer validators (step 6). A proof coming from a foreign distributed ledger can be verified against the public keys of the transfer validators of that foreign distributed ledger either locally by the recipient or using on-chain logic – typically smart-contracts (step 7 and 8).

This tutorial demonstrates how to transfer a simple asset between a Hyperledger Fabric and a Quorum network. If you have a favorite DLT network, please consider contributing a connector. We encourage you to have a look at the source code and welcome any contributions no matter the size. Please reach out on the #blockchain-integration-framework chat channel with any questions.

Nov 19
Love0

Setting the Hyperledger Global Forum 2020 Agenda: The Speaker Selection Process

By Blog, Hyperledger Global Forum

Can you feel the Hyperledger Global Forum 2020 buzz? We sure can! We are finalizing the fine details of the agenda, and today we wanted to give you a peek behind the scenes on how the process worked. Similar to our inaugural forum, this year we decided to open the program agenda to the full community issuing an open call for talk submissions via our formal Call For Proposal (CFP) process. And, as expected, building up on the 2018 momentum, we sure got a lot of submissions!

More than 300 submissions competing for 66 session slots, coming from every corner of the world and touching on a variety of topics flooded our CFP portal from June 7 to October 4th.

At Hyperledger, we believe that all good things in life are free (to participate in) and open (source), and everyone should have the opportunity to participate and contribute. To ensure the process of selecting talks that would shape the agenda of the event was as community-driven as possible, we put out an open call for a Program Committee (PC) on August 22nd. Unlike 2018, Hyperledger staff was excluded from participating in scoring and selection this year. Eleven experienced community members stepped up, led by program chairs Tracy Kuhrt and Hart Montgomery,  two members of Technical Steering Committee and contributors to Hyperledger codebases. 

Given the number of submissions and the diversity of topics, the Program Committee decided to split responsibilities, according to their expertise: some reviewed the business proposals, some took on the technical ones, a few looked at both. The committee did a blind review (no speaker names or company name) of the talks, rating them on a scale of 1-5. The ratings were then averaged to come up with a score by which the talks were ranked. To make sure that we were all on the same page guidelines on general CFP scoring guidelines and best practices had been published as part of the CFP progress. 

Additionally the Program Committee added some of their own criteria:

  • No product pitches allowed. In the CFP proposal how to’s, it clearly suggested that speakers should “Avoid sales or marketing pitches and discussing unlicensed or potentially closed-source technologies when preparing your proposal; these talks are almost always rejected due to the fact that they take away from the integrity of our events, and are rarely well-received by conference attendees.” 
  • Make sure we are talking about real implementations and research that is relevant to the community. “No Hype, in Hyperledger.”
  • Hyperledger Global Forum differs from Hyperledger Member Summit. Every year we organize an event where we bring our members together to network, discuss ideas, challenges and solutions under Chatham house rules. Hyperledger Global Forum, on the other hand, is an open event inclusive of everyone. This means that everyone had to have an equal chance of getting accepted. Member affiliation didn’t matter – the content was what drove the choice. 
  • We heard the feedback from HGF18 loud and clear. Prioritize talks over panels. During various conferences we attend and our own events, there is a tendency to cram in many speakers into a panel. The Program Committee decided to change it. Yes, it means fewer speakers, but hopefully there will be more valuable content.

The Program Committee had one month to evaluate the submissions on their own. Then, they met as a committee over two 3-hour long calls to discuss the borderlines and outliers. It was not easy. Many talks were great, but overlapped in topics. This was the tricky part: choosing talks that were scored highest, came from new or under-represented voices in our community and represented all the projects within the Hyperledger Greenhouse. The process was blind until those last stages. 

We hope that you will join us at Hyperledger Global Forum 2020 and will find the agenda as exciting as we do. None of it would be possible without our great events team, lead by Shannon Jessee, and the Program Committee: 

  • Hart Montgomery, Fujitsu [Program Chair]
  • Tracy Kuhrt, Accenture  [Program Chair]
  • Grace Hartley, ConsenSys, PegaSys Team
  • Jon Geater, Jitsuin
  • Nathan George, Sovrin Foundation
  • Bobbi Muscara, Ledger Academy
  • Mark Wagner, Red Hat
  • Fernando Cezar Herédia Marino, CPQD
  • Todd Taylor, GenBloq
  • Morgan Bauer, IBM
  • Arun S M, Walmart Labs (formerly with Intel)

We will be publishing the agenda soon. Stay tuned!

Nov 18
Love0

“Why Retail is Ready for Blockchain” – a position paper preface

By Blog

The supply chain landscape is widely considered to be the most immediate application space for blockchain and DLT technologies for many reasons: tension between trade partners, a plethora of paper-based processes, siloed stakeholders, and inefficiencies everywhere. The use cases are there, and the preliminary steps of launching a pilot or proof-of-concept seem simple enough. After all, over half of the projects in Hyperledger’s Blockchain Showcase have some sort of supply chain flavor, and there have been several successful initiatives featuring leafy greens and coffee beans that have proven the viability and the value of blockchain for the supply chain.

However, we tend to overlook the vast majority of blockchain for supply chain projects that dissolve or fail to deliver results. There are plenty of valid reasons why consortiums collapse or projects disappear into the ether (pun intended). Buy-in from various stakeholders may be lacking, value propositions for the business may be hazy, or use cases could be dismissed after initial exploration deems them unfit. There is no shame in any of these endings, but there are definitely lessons to be learned. Initiatives that are able to survive the exploration phase encounter whole new hurdles once they arrive at the implementation phase, and one of the most prominent problems that supply chain projects face is bridging the gap between the physical world and the digital domain.

Some companies solve this problem by creating home grown identification solutions, volunteering their time and energy to a never-ending cycle of development and support that doesn’t have anything to do with blockchain. Other organizations opt for legacy technologies like barcode to bridge the gap between physical goods and the digital world, but even barcode systems have their limitations. Scanning each product in a customer’s cart to capture the information embedded in each barcode might not be an issue, but this same practice does not scale upstream in the supply chain when products are palletized and carts are substituted for shipping containers. Associations must be made between products, cases, pallets, and containers. Assumptions must be drawn about the accuracy of those associations and the continuity of operations throughout the supply chain. The resulting scenario requires a significant amount of trust in legacy systems, which is typically a red flag for blockchain practitioners.

Another shortcoming of barcode-based systems is that they rely on class-level identifiers, also known as SKUs (Stock Keeping Unit), UPCs (Universal Product Code), or GTINs (Global Trade Identification Numbers). In other words, the data only goes as deep as the item type, meaning that a single value could be assigned to countless identical items. For example, over 350 million Rubik’s Cubes have been sold throughout the world since 1980, but their barcodes all bear the exact same information, making it impossible to distinguish one from the other. Because of this fact, it is impossible to determine an item’s singularity with data alone, so additional assumptions must be made in order to confer item integrity. There is, however, an alternative to barcode and other optical scanning solutions that performs at scale throughout the supply chain and solves the issue of item-level identity.

RFID technology (Radio Frequency IDentification) has become a popular solution for many blockchain projects seeking to tie digital IDs to physical goods. RFID is a well established method for serializing and capturing item-level information, and decades of development have contributed to lower costs and peak performance at practically every step of the supply chain. Scanning of RFID-tagged product is accomplished with radio waves, as opposed to barcode systems that rely on lasers and line of sight. Because of this, product information can be captured through packaging, cases, and even pallets at the rate of hundreds of items per second. Additionally, RFID tags assign a unique digital identity to each physical product by appending a serial number to the basic information found in barcodes. This is accomplished by the use of SGTINs, or Serialized Global Trade Identification Numbers. There are other mediums for carrying SGTIN data like a QR Code and 2D Data Matrix, but RFID and other radio-wave-based carriers tend to scale better throughout the supply chain.

Even though RFID is an ideal data source for a blockchain solution, standing up a comprehensive solution from scratch is a non-trivial task. Companies like Nike, FedEx, Delta, and Airbus have spent millions of dollars over the course of several years to establish their RFID capabilities, and while they have reaped sizable dividends, the amount of effort required is far from negligible. Many blockchain initiatives that are supply-chain-centric have come to this realization, and it is not uncommon for projects to experience significant delays or stall out completely when it comes to integrating RFID infrastructure. However, companies that have already invested in RFID are in an excellent position to plug their item-level data streams into a blockchain solution, ultimately enabling visibility and traceability through each step of the supply chain.

While there are robust implementations of RFID in aviation, aerospace, and manufacturing, the industry with the deepest penetration is retail. There are 14 billion RFID-tagged items in the retail world today, from footwear and fine jewelry to sweaters and sweatpants, and over 70% of the top 100 apparel retailers in the U.S. are using RFID in their operations. But ever since Walmart began pushing RFID adoption in the early 2000’s, the industry has suffered from an inability to share granular, item-level data with their trade partners. Traditional EDI networks permit high-level business documentation to change hands, but these networks operate on antiquated models and outdated internet technologies, rendering them unfit for the massive volumes of serialized data being created throughout the supply chain today. End users and solution providers have been unsuccessful in establishing managed server solutions for serialized data exchange, primarily because of the imbalance of control created by centralized solutions or the lack of scalability across the industry.

Given the current retail landscape, there is a tremendous opportunity for blockchain technology to become the de facto standard for data exchange. The Auburn University RFID Lab has expounded on this opportunity and outlined the symbiotic relationship between serialized data and blockchain in a recent position paper titled “Why Retail is Ready for Blockchain.” With item-level infrastructure already in place, retail could be the best arena for blockchain to be battle-tested in. But this opportunity is bigger than a single domain. RFID adoption in other industries is exploding, and those industries key off of the lessons and learnings in retail. If the retail industry is able to prove out the potential of blockchain, others will follow. There is an insatiable need for better business-to-business collaboration across all disciplines, and I believe that blockchain could be the solution to satisfy that need.

Nov 13
Love1

Honeywell Aerospace creates multi-million dollar online parts marketplace with Hyperledger Fabric

By Blog, Hyperledger Fabric

Turning retired planes onto business opportunity, Honeywell Aerospace is on track to modernize the $4 billion used aircraft parts market. A key part of the formula for success has been deploying Hyperledger Fabric to bring a layer of trust to the online sales process. 

When a plane retires, operators can harvest valuable parts, especially engines and landing gear. And those parts can be sold, recertified as airworthy, and reused in other planes. There is a big demand for the parts but, since aviation is a heavily regulated industry, sales require certification from the U.S. Federal Aviation Administration and other agencies. Each part must be documented with a complete history of its ownership, use, and repairs. Needless to say, tracking all the information required on all those parts is a challenging, error-prone process. And any uncertified or counterfeit part that snuck into the supply chain could have dire consequences.

Vendors attempting online sales were putting up sites that looked a lot like Craigslist, only with no prices or images. Only the most basic information, such as a part’s condition, was posted online with the seller’s phone number. Any transaction required extensive back and forth between buyer and seller to fill in each part’s history and details. It was a long way from the ecommerce experience we’ve all come to expect and online sales made up less than 2.5% of all transactions. The Honeywell Aerospace team knew they had to do better and that the key was building in a layer of trust.

Ushing in a new era in used airplane parts sales, Honeywell created a blockchain-based marketplace, GoDirect Trade, that is a modern shopping site that gives buyers easy access to the information and parts they needed and, importantly, removed uncertainty from the transactions.

Thanks to the blockchain records, buyers can now view vital data on many parts, such as:

  • The entire lifecycle of a part
  • The number of hours it was in service
  • Any and all repairs made and by who, when and where
  • All previous owners of the part

In selecting the blockchain framework to power GoDirect Trade, Honeywell had a number of criteria, including low latency, high throughput, and fast send rates. Hyperledger Fabric provided all that, along with privacy controls such as channels that give a granular ability to manage data. 

Today, shopping on the platform feels like using a typical consumer e-commerce site with photos, detailed product information, and a simple checkout. The average checkout screen only takes two clicks. All these were groundbreaking innovations for aviation parts.   

A month after GoDirect Trade went live with little fanfare, the marketplace had registered more than 300 buyers and processed nearly a quarter million dollars in online transactions. Within 10 weeks, sales soared past $1 million.

Hyperledger has captured the details behind the conception and development of the Hyperledger Fabric-powered GoDirect Trade, its success to date and future plans for the platform. Read the full case study here.

Nov 07
Love0

Best Practices and Lessons Learned from Hyperledger Besu Establishing a Maintainer Process

By Blog, Hyperledger Besu

As an open source project, the Hyperledger Besu team is continuing to focus on building our community. One reason we submitted Hyperledger Besu to Hyperledger was to improve the project’s open source governance using Hyperledger’s best practices and recommendations. The Linux Foundation and Hyperledger have been leaders in establishing open source governance processes for years. Hyperledger uses best practices across its projects, including open communication, tool consistencies, and cross-project technical leadership. The Hyperledger Besu team wanted to take these open source governance learnings a step further to create a process for managing its maintainers. 

Why Maintainer Governance is Important

Maintainers of open source projects are the leaders and direction-setters for the projects. They are oftentimes the ones contributing the most code to the project, talking to the community on chat channels, and dedicating time to other community activities, such as working groups or writing documentation. We wanted our process around maintainer governance to reflect the significance of the role within the project. The Besu team researched how other projects and open source foundations performed the maintainer governance. 

We found the following examples from other organizations to help inform our decision:

The Apache Foundation: The Apache Foundation has Project Management Committee (PMC) Members, which is their alternative for maintainers. PMC Members are elected due to their commitment to the codebase. The PMC has control over the codebase and are the ones who vote on major releases.  

OpenJDK: OpenJDK has a more formal process for adding maintainers, including taking formal nominations for the new maintainer. They hold a one-week nomination period, select a candidate amongst the nominees, and then use a Lazy Consensus vote to vote on the nominee.

Other Hyperledger projects: Currently the Hyperledger projects have different approaches for managing their maintainers. Hyperledger Fabric requires a majority vote of maintainers to add a new maintainer, for example. Hyperledger Indy encourages maintainers to be highly collaborative with other contributors and maintainers.

The Besu Team’s Decision

The Besu team investigated these proven practices with the aim of determining the best option for managing the project’s maintainers. We wanted the process for adding and maintaining maintainers to be as objective and transparent as possible. With this in mind, the team decided to model its maintainer process most closely after the OpenJDK foundation with some additions. 

A few key tenants of Besu’s management maintainers include:

  • A proposed maintainer must have 5 significant changes committed to the codebase
  • A proposed maintainer must be sponsored by a current maintainer
  • A proposed maintainer can be vetoed by a current maintainer but a public explanation is required when such vote occurs. 
  • There is a two week window for voting on a proposed maintainer. Voting can end early if an absolute majority is reached. 
  • A current maintainer can also be removed if warranted. The Hyperledger Code of Conduct can be found here.

These requirements help provide clear and direct expectations for the community on how to become a maintainer. We wanted members of the community to know exactly the steps required if becoming a maintainer interested them. We also tried to make the process be conducted in an open and community-friendly manner. It is important to us to make our project approachable with anyone feeling welcome and encouraged to try it out.

Contribute to Hyperledger Besu Now!

It is easy to begin your journey using and contributing to Hyperledger Besu. Check out these resources to help you get started:

Nov 05
Love0

Hyperledger Certifications Give Experts A Professional Edge

By Blog, Hyperledger Fabric

Hyperledger Certifications give experts a professional edge by providing globally recognized evidence of skills mastery, demonstrating ability within a specific topic. 

Hyperledger announced the Certified Hyperledger Fabric Administrator (CHFA) designation earlier this year. This certification is earned by professionals who can effectively build a secure Hyperledger Fabric network for commercial deployment, including the ability to install, configure, operate, manage and troubleshoot the nodes of thatnetwork1.

Hyperledger expanded the available certifications with the recently announced Hyperledger Certified Service Provider (HCSP) designation for companies that meet the following criteria: 

  1. Be a member of Hyperledger, 
  2. Have a business model to support enterprise end users, including putting engineers at customer sites, and
  3. Have three or more engineers who have passed the Certified Hyperledger Fabric Administrator (CHFA) exam.

As an active member of Hyperledger, contributing to the quarterly releases and participating in conferences around the world, Chainyard has the first requirement covered. Additionally, Chainyard’s business model, covering the second requirement, is to service enterprises, startups and associations with their blockchain needs, whether they be advisory, engineering, operational or governance in nature. 

Regarding the third, I am proud to say our first three engineers who obtained the CHFA designation are Ratnakar Asara, Surya Lanka and Ramesh Thoomu. All three were motivated to get the designation to validate their expertise and contribute to the company’s goal of obtaining the HCSP designation. 

Obtaining this designation is important to individuals both to affirm what they know and for their personal development and growth. Here is what our first three engineers to obtain the HCFA designation had to say. 

Achieving Certified Hyperledger Fabric Administrator (CHFA) is a big milestone in my career and demonstrates my skills, knowledge and competencies to build a secure Hyperledger Fabric network for commercial deployment including the ability to install, configure, operate, manage, and troubleshoot the nodes on that network. 

Working in multiple blockchain projects through Chainyard gave me opportunity in exploring Hyperledger Fabric in depth and boosted my confidence in taking this exam. 

– Ratnakar Asara 

CHFA is highly recommended because it helps one to understand the core Hyperledger Fabric network fundamentals with emphasis on building Hyperledger Fabric network, operations and maintenance. It also helps organizations to build Hyperledger Fabric blockchain skill sets for its employees. 

Phenomenal efforts have been put forward by the Hyperledger team in designing the content of CHFA. Thanks to the Linux Foundation. 

– Ramesh Thoomu 

“I have been working with Hyperledger Fabric for over two years. When I heard about the opportunity to become Certified Hyperledger Fabric Administrator, I made up mind to do it. I am grateful to Chainyard for their trust and encouragement to become Certified Hyperledger Fabric Administrator.” 

– Surya Lanka 

For our company, the designation separates us from the competition and provides an objective affirmation by a respected organization, the Linux Foundation, of our capabilities with Hyperledger Fabric. 

Our team has worked on many Hyperledger Fabric projects running in multiple data centers and public clouds on projects across many domains. The experience the team has obtained over the past four years is tremendous and enabled Ratnakar, Ramesh and Surya to pass the exam. Their dedication to their craft, careers and our clients, helping them to solve many problems, allowed them to pass this exam and validate their expertise with Hyperledger Fabric. 

We are happy to say we have additional engineers in the pipeline who have committed to work towards this designation. We work closely on our client projects, leveraging each other’s strengths, to deliver the best work. This collaboration will continue into the classroom as our expert level engineers have promised to hold extra whiteboard coaching sessions to help others in the company pass the HCFA exam. We look forward to having more engineers achieve this milestone. 

As a company, we see the Hyperledger Certified Service Provider designation as a way to help better promote our company services and grow our business. Having the designation validates what we say to our clients, giving them greater confidence in our team, whether it be during pre-sales, while developing a solution or when resolving an operational issue. 

Chainyard has been active with Hyperledger for four years and proud to have the HCSP designation to reinforce our commitment to the ecosystem.

1. Certified Hyperledger Fabric Administrator (CHFA) requirements

Nov 01
Love0

Announcing Hyperledger Quilt v1.0: Interledger for the Java platform

By Blog, Hyperledger Quilt

Today, I’m thrilled to announce Hyperledger Quilt v1.0, a Java implementation of the Interledger protocol that enables payments across any payment network. 

Much like the Internet did for information, Interledger provides open protocols and standards to enable payments interoperability — across any currency, fiat or crypto — with no single company or organization controlling the Interledger. Instead, by specifying a common set of protocols to follow, the Interledger will consist of a variety of entities and institutions who can decide which other Interledger networks to connect to.

An Open Collaboration for Java Developers

Because no single entity will own the Interledger, it makes sense for Interledger software implementations to be free and open-source. To this end, Quilt is hosted in the Hyperledger community, which provides a strong governance structure to help the Quilt implementation mature, and also has a rich set of business blockchain technologies and partners that will benefit immensely from a payments interoperability layer.

Hyperledger Quilt and Interledger have major developer backing from a variety of organizations, most importantly Xpring. 

At Xpring, we’re creating an open platform for developers to integrate money into their apps. 

Central to this vision is Interledger, and we’re investing heavily in tools and services (like an Interledger Testnet and more) to enable anyone to also build payment systems using Interledger technologies. Xpring’s platform is built to foster innovation in blockchain to interoperate “all the money” with the launch of Quilt v1.0 – a Java implementation of Interledger.

Which brings us back to Quilt, and its foundation on Java. 

While it’s just one programming language in the Interledger ecosystem, Java is an immensely important one. There are millions of Java developers around the world, with billions of devices running Java software, largely led by Android deployments. With this in mind, Quilt is vital because it provides Java developers with easy-to-use libraries for sending and receiving Interledger payments.

With the 1.0 release of Hyperledger Quilt, the Java ecosystem now has a support for nearly all Intereldger primitives, including streaming payments.

In the rest of this post, I want to explain some of these core primitives and features, and walk you through how to send an Interledger payment from a Java application using Quilt. So let’s get started!

Tutorial: How to Send an Interledger Payment using Quilt

First, let’s talk about identity. Every Interledger sender will need to know who to pay, and for that we use the Payment Pointer: a standardized identifier for payment accounts. Because payment pointers are made up of string characters, you don’t need to fully understand everything about them in order to use them. For this example, we’ll simply be making a payment to this Payment Pointer: 

`$rs3.xpring.dev/accounts/user_usio37ti/spsp` 

The above payment pointer represents an account on the Xpring testnet, and indicates the user `user_usio37ti` at the Connector hosted at https://rs3.xpring.dev.

Now that we know who to pay, we need to get an account that will represent us on the Interledger. To do this, we can create a test account by using the Xpring Interledger testnet here.

Once you have your account credentials, you’ll be able to easily send a payment using something like the following code snippets.

To get started with our payment, we need to create a `Link` using Quilt. Links allow two peers to communicate with each other. In this instance, you communicate to your Interledger service provider (think of this like your ISP) using a Link, and this gives you access to the broader Interledger. 

For this example, we use HTTP for actual network communication, and construct a new Link of type `IlpOverHttpLink`:

```
Link link = new IlpOverHttpLink(
 // … actual dependencies here.
)
```

Next, we want to make an Interledger payment using STREAM, which is a packetized payment protocol inspired by the QUIC Internet Transport Protocol. STREAM operates on top of core Interledger protocols by allowing a sender and receiver to coordinate a payment over any arbitrary Interledger topology. 

Similar to the way the Internet packetizes data, STREAM splits up payments into packets to maximize network liquidity and throughput. This allows Interledger to support a variety of use-cases, including micro-payments as well as large-value payments, machine-payments, non-custodial wallets, retail and ecommerce payments, and more.

In code, we can create a `StreamSender` that uses our `Link`, like this:

```
StreamSender simpleStreamSender = new SimpleStreamSender(link);
```

Finally, to send our test payment, the following line of Java can be used:

``` 
simpleStreamSender.sendMoney(
  SHARED_SECRET, SENDER_ADDRESS, RECEIVER_ADDRESS, UnsignedLong.valueOf(1000)
);
```

The above command instructs the StreamSender to send `1000` units across the Interledger to the receiver identified by `RECEIVER_ADDRESS`. Note that because the immediate peer of this sender is part of the Xpring testnet, these units are actually XRP milli-Drops (a Drop is a millionth of an XRP). Thus, while 1000 units will be sent by this payment, the payment will actually equate to only 1 Drop of XRP.

Quilt for Enterprise 

As you can see above, sending payments over Interledger is pretty simple, although the code snippets in this post are truncated for illustration purposes. To see the actual code behind these examples, navigate over to the Hyperledger Quilt Examples on Github.

All of us at Hyperledger and Xpring are incredibly excited about the new platform we’re building on top of Interledger. It will be fun to see what gets built on top of Quilt, especially for enterprise DLT use-cases like connecting currently disconnected Fabric networks together using Interledger.

Further Reading

To learn more about Hyperledger Quilt, you can read more at hyperledger.org. To integrate Quilt into your project, learn more in the project README or find release artifacts here.

To get more involved in the Interledger community, find us on Slack or in the Interledger forum.

The examples in this post are powered by the following Interledger Protocols, each of which is implemented in Hyperledger Quilt:

  • Interledger Addresses: a hierarchical identifier for Interledger network nodes that enables efficient routing of payment packets.
  • Payment Pointers: a standardized identifier for end-user payment accounts.
  • ILPv4: The lowest-layer Interledger protocol that enables packets to multi-hop from peer to peer across the Interledger.
  • ILP-over-HTTP: An HTTP protocol that allows two peers to transmit ILPv4 packets to each other using HTTP.
  • SPSP: Simple Payment Setup Protocol, used to allow a sender and receiver to negotiate the security parameters of an Interledger payment.
  • STREAM: A protocol for reliably sending money and data over ILPv4.

About Hyperledger

Hyperledger is an open source collaborative effort created to advance cross-industry blockchain technologies. It is a global collaboration, hosted by The Linux Foundation, including leaders in finance, banking, Internet of Things, supply chains, manufacturing and technology.

About Xpring

Xpring is creating an open platform for money to make it easy for developers to integrate payments into their applications. The Xpring Platform builds upon open-source core technologies like XRP, Web Monetization, and Interledger to allow for sending and receiving real time payments in any currency. Learn more at https://xpring.io. Follow @xpringDev

About Interledger

Interledger is an open protocol suite for sending payments across different ledgers. The open architecture and minimal protocol enable interoperability for any value transfer system. Learn more at https://interledger.org.

Oct 31
Love0

Announcing Sawtooth PBFT 1.0

By Blog, Hyperledger Sawtooth

The Sawtooth community is excited to announce the official release of Sawtooth PBFT 1.0 along with the Hyperledger Sawtooth 1.2 release. PBFT 1.0 is the result of substantial engineering effort from Bitwise IO and Cargill to provide a fast and practical consensus algorithm for consortium-style Sawtooth networks.

An earlier blog post, Introduction to Sawtooth PBFT, presented the details of the consensus algorithm. The next post, Sawtooth PBFT, Part 2: Extensions and Changes, described the enhancements that made the algorithm more efficient and easier to implement for Sawtooth. Now, we’d like to describe the advantages of Sawtooth PBFT and give practical tips for how and when to use PBFT consensus.

What Makes PBFT Different?

Those familiar with Sawtooth already know about the Proof of Elapsed Time (PoET) consensus algorithm, a lottery-style (Nakamoto) algorithm that is designed for large, open-enrollment blockchain networks. Until now, PoET was the only production-ready consensus option for Sawtooth. While PoET is useful for certain kinds of networks, it isn’t a universal solution. In particular, PoET is not well suited for smaller networks because of its slower performance.

To make Sawtooth a more versatile blockchain platform, we introduced the dynamic consensus interface in Sawtooth 1.1, which provides a new consensus API that simplifies the process of adding new consensus algorithms. We started with Raft, a simple leader-based consensus algorithm designed for small networks. Raft provided a consensus type that we didn’t have with PoET, but because Raft isn’t Byzantine fault tolerant (BFT), it wasn’t a complete solution.

This is where Sawtooth PBFT comes in. PBFT has properties that make it well suited for small networks — it’s leader-based, non-forking, and fast. It also provides the safety and liveness guarantees that are necessary for operating a blockchain network with adversarial trust. This makes PBFT an excellent option for most consortium-style networks. Consortium networks are small (typically 5-20 nodes), have controlled membership (only administrators can add and remove nodes), and typically require finality (non-forking behavior). Once a block is committed, it is committed forever, which eliminates any uncertainty about the permanence of state.

How Well Does PBFT Work?

Sawtooth PBFT works very well! We’ve tested it extensively for safety, reliability, and performance. The code includes a large number of unit tests that validate PBFT’s functionality, and we’ve run a number of long-running PBFT networks to work out the kinks.

How does PBFT Perform?

Part of the extensive testing of PBFT was determining how well it performs. A full Sawtooth network consisting of 10 “m5.large” AWS instances running with PBFT consensus performed 2.5x faster than the same network running with PoET consensus.

Exact results may vary depending on factors like system resources and network size, but the big picture is pretty clear: PBFT can provide a big performance boost compared to PoET.

When Should I Use PBFT?

The short answer is that PBFT should be considered the first choice for small to medium Sawtooth networks that do not require open enrollment. If your use case requires a large network (more than 20 nodes, for instance) or open enrollment, PoET may be a better choice because it is designed to perform well with many nodes and is less strict about membership in the network. But, in general, we recommend using PBFT because of its finality and performance advantages for most networks.

How Do I Use PBFT?

Sawtooth PBFT is easy to configure and use. We designed Sawtooth’s dynamic consensus interface to make choosing consensus simple. The Sawtooth 1.2 documentation includes instructions for setting up a Sawtooth network with PBFT using Docker and Kubernetes, which are designed for application development environments and Proof of Concept evaluations. For production networks and do-it-yourself developers, there’s also a procedure for setting up a Sawtooth network on Ubuntu.

See For Yourself

Sawtooth PBFT is an exciting new addition to the Hyperledger Sawtooth ecosystem. If you’d like to learn more:

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, working in a variety of areas including consensus, Hyperledger Sawtooth, and Hyperledger Transact.

Oct 22
Love0

Hyperledger Grid and GS1 Standards: Harmonizing Static and Dynamic Data

By Blog, Hyperledger Grid

Supply chain professionals are all too familiar with the persistent challenges that plague the industry–a lack of inventory visibility, not having complete or trustworthy data to share with partners, or not enough business process consistency are a few issues that come to mind. However, somewhat ironically, it often takes industries joining together to collaborate to solve these issues that ultimately helps companies enjoy longevity and stand out from their competition.

It’s this “collaborate to compete” concept that has inspired so much discussion around what blockchain can do to help improve the supply chain. With a long history of facilitating collaboration to adopt new technologies and business processes, GS1 US has applied this open community spirit to our work on Hyperledger Grid, a collaboration with Cargill, Target, Intel and Bitwise IO. This project builds on Target’s earlier proof of concept based on the open source solution ConsenSource that was focused on certifying suppliers for its private label paper products. Experiencing success in this test, the retailer branched out to explore how Hyperledger Grid could be applied for better food traceability with supplier, Cargill.

For the past several months, the Hyperledger Grid team has investigated the role of GS1 Standards in blockchain development. We’ve discussed how to help create the ideal foundation for supply chain-based blockchain applications to flourish. The partners understand the need to standardize static data, such as a product’s Global Trade Item Number (GTIN) and core attributes, as well as more dynamic details like time, location and temperature readings that are important for transaction-based communications, such as procurement and track and trace. 

All of this is reflective of this overall nascent stage of blockchain’s life cycle where supply chain partners are still agreeing on what is “the right data” to share on a blockchain. Regardless of how they are piloting blockchain, many companies are finding that this is the time to say “enough is enough” and end the churning of poor data quality that has particularly plagued supply chain for many years. 

Several GS1 Standards provide consistency and structure to data transactions on a blockchain, increasing the likelihood that the intended outcome will be achieved: 

GTIN – This product identifier plays a critical role in global commerce, as it helps businesses manage items on both the physical and digital shelf. Unique like your own fingerprint, a GTIN is composed of numbers that identify the company making a product and numbers that identify the product. If every item is uniquely identified with its own GTIN, it retains an identity regardless of where it is in the supply chain. 

This number is what is encoded into a UPC and scanned at checkout, but is mightier than this function. Identification that is persistent beyond the four walls of the company is key for a blockchain implementation, given the technology’s immutability. A universal data language that starts with product identification can ensure that the right data is stored and communicated further down the chain. 

Global Location Numbers (GLN) –  Similar to GTINs, these are numbers that uniquely identify organizations and locations in the supply chain. GLNs give companies the flexibility to identify any type or level of location required for supply chain visibility. They can identify a warehouse, a retailer, a hospital, even something as specific as a store shelf. Or, they can identify a company’s legal or functional entities as they relate to a particular business transaction, for example as buyer, seller, or carrier. 

So many blockchain use cases today revolve around supply chain visibility, with specific focus on locations and origins. For example, Nestle teamed with Carrefour to put traceability directly into the hands of consumers using the IBM Food Trust blockchain platform. Carrefour shoppers can track Mouseline instant mashed potatoes from Nestle’s factory to Carrefour’s stores by scanning a QR code on the packaging with a smartphone. In addition to providing extended product details, such as the product’s production date and quality control parameters, it also reveals the locations of warehouses and the farms that supply the potatoes. Without standardized location identification, such a level of transparency would not be possible. 

GS1 barcodes – For data to be shared among trading partners (with or without a blockchain), it must be captured. More trading partners, particularly in the food industry, are leveraging the GS1-128 barcode to capture dynamic product information and serialized logistics data, such as expiration date and batch/lot numbers. Using these barcode labels, companies enable the automatic recording of product-specific information whenever a barcode is scanned, for a more real-time view of where products have been and where they are going. 

Electronic Product Code Information Services (EPCIS) – EPCIS is like a standardized application program interface (API). EPCIS acts in a similar way to capture and share information about the movement and status – the what, where, when and why – of products, logistics units and other assets in the supply chain. EPCIS simplifies the capture and description of physical events, allowing companies to more effectively rely on a single version of the truth about supply chain and logistics events. 

EPCIS is increasingly deployed in sectors such as fresh foods, healthcare, and logistics to improve efficiency. It is versatile, in that it can be used with a number of different data carriers, including GS1 barcodes and EPC-enabled radio frequency identification (RFID). Unlike “batch oriented” data transmission mechanisms, EPCIS is more suitable for blockchain because it more efficiently documents the potentially massive amounts of event-based data. 

These concepts from the GS1 System are being incorporated into Hyperledger Grid from the ground up. Adopting standards means putting structure around both static and dynamic data.  Without a common platform to share data, blockchain applications may fail to deliver on promises of consistent efficiency and visibility. GS1 Standards have an inherent credibility, neutrality and interoperability to help make data usable for blockchain today and scale for tomorrow. 

Cover image: Standards by Nick Youngson CC BY-SA 3.0 Alpha Stock Images