Blog

In many of the discussions that I have had regarding blockchain, business models are a frequent topic. Why use a new technology like blockchain instead of an existing, well understood, proven, cost effective technology? What makes blockchain radically different?

To answer, let’s start with a simple history of the evolution of communication, the evolution of how one person shared a concept with another person. What was visual (point at it), became verbal (speak and hear), became written (write and read), and then became an electronic transmission. Telegraph became radio became television. Each approach was essentially the same: describe something in enough detail such that the listener could create the same picture in their mind or on their device.

In these approaches, the sender strives for enough detail that the listener can create an identical view. Complete accuracy is difficult. Differences are basically guaranteed, especially if changes occur to the picture by either party. Reconciliations attempt to repair the differences. Doubts gather whether the sender and receiver are staying on the same page. In some cases, the cost of reconciliation is so high that it is simply ignored and differences accumulate.

Some mitigations have arisen. The simplistic sending of a flat file, as a description of the object, has moved to the use of APIs. Systems now agree to the verbs used with an object and to use the verbs to communicate actions about the object. These verbs make up an API. With such, two or more systems can communicate aboutan object without actually exchanging the object. Color the car red, Credit the account $500.

Blockchain technology adds a new approach to our toolkits. Blockchain technology enables the sender and receiver to always interact with the same object, the same noun. The local copy of the object is complete and synchronized across each participant of the blockchain network. No explicit interpretation or reconciliation needed. We now have a new tool, a new ability to share the noun, a single noun. The historic approaches of trying to describe, create, and work through verbs are not limiters any more.

By sharing the noun, blockchains create opportunities for new paradigms where all participants see the same object and every change to the object. The verbs do not need to be agreed upon. This freedom to interact with the noun, a shared object, without agreement as to how, is a very different and new approach.

How do we think about existing business models in a model of sharing the noun? Submitting a medical claim becomes simply placing it on the blockchain. After that, all participants can edit, approve, pay, reject, bundle, and take any action they want on the claim. Imagine six companies, sharing a blockchain. Each has connected their systems to the blockchain to take action as changes are seen on the chain, and to submit theirown changes to the chain. Everyone on the network can work simultaneously. As every participant sees every change on the claim, taking action on edits becomes easy and automatic.

This model of sharing a noun is unlike any business process today. No longer restricted by previous modes of communication, we can each see the same noun and operate on it together. We have an opportunity to move from linear, assembly-line workflows to constant and simultaneous interaction. This is an exciting opportunity and to explore it, we must begin using blockchains in our production processes. We should not seek the “killer app.” Instead, we should create a thousand new opportunities for new interactions, value creation, and niches in our ecosystems. As these opportunities succeed and some fail, we will learn. Let’s begin exploring the uncharted areas of our maps.

Jumping back to our Developer Showcase blog series, which serves to highlight the work and motivations of developers, users and researchers collaborating on Hyperledger’s incubated projects. Next up is Todd Cooper and James Sloan from NuArca. Let’s see what they have to say!

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

Dive right in. The pace of change is so fast in this space that getting caught up can be a relatively quick process. I think the term ‘blockchain’ still covers a lot of ground so it makes sense to narrow your focus a bit. If you are interested in cryptocurrencies then dive into Bitcoin, Ethereum and token sales in that order. Go out and set up a wallet and buy a small amount of bitcoin just for the experience. Then look it up on a bitcoin explorer to see the history of the transactions.

To start to get familiar with the underlying code the open source community is great in terms of being open to participation and providing resources for learning. Start by downloading Hyperledger Fabric, writing your own Smart Contract and setting up a network of Docker nodes or develop your own token on Ethereum’s test network in Solidity. If you are looking to familiarize yourself with the innovation in this space, every ICO is publishing a new whitepaper exploring new concepts in blockchain and while the quality may vary, you can get a sense of what is happening.

Finally, there are lots of networks out there on Slack, Twitter, Telegram and Meetups that are occurring all around the world. Start talking to other people to find out what they are doing.

James Sloan, EVP Product Management, NuArca

Todd Cooper, CEO and Co-founder, NuArca

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?

NuArca is working with AST (American Stock and Transfer) to deliver a blockchain and machine learning enabled proxy voting solution. AST is one of the largest proxy voting solutions in the market, and the NuArca built system will be used by thousands of corporations and funds to define, manage, and record their proxy vote issuances and annual shareholder voting. This solution will facilitate greater transparency and confidence in data handling, allowing issuers to make more informed decisions and strategy adjustments. It will also allow AST’s proxy solicitation experts to access advanced predictive analytics to guide complex proxy solicitations.

What project in Hyperledger are you working on? Any new developments to share? Can you sum up your experience with Hyperledger?

Our primary focus at this time is on deploying the Proxy voting solution using Hyperledger Fabric. We will be live by end of September with more than 2 million unique voters representing over 1 trillion shares. This first project stage is focused on parallel record keeping with existing proxy systems. When all goes well, the Fabric based system NuArca built will become the system of record for proxy voting. By Q2 2019, ~40% of all fund proxy voting will be using this system.

To date, Hyperledger has been great, but does require full time tracking of changes in both technology incorporation as well as deployment. It is new enough that this is completely understandable, but anyone getting involved should know that they are working in a fast moving and dynamic system in which time must be invested to understand and leverage.

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

Scalability and effectively getting the news out on the good enterprise class solutions that are starting to come out using Hyperledger. Much of the tech industry press and financial services press are focused on coins and tokens. Meanwhile, Hyperledger solutions are proving themselves scalable and practical. The Hyperledger community can do a better job of helping to make that knowledge resonate in the market.

From a specific technology gap standpoint, we are particularly looking to have support of Hyperledger on Red Hat rather than Debian as that is the OS of choice for much of the financial services industry. We anticipate needing ongoing improvements to performance and scalability as we grow the solution.

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?

In general, it is the practical use of the technology available today that is most interesting. Hyperledger is not a pie in the sky visage that may come into its own 5 – 10 years down the road. It is here today and can better solve specific types of problems better than yesterday’s technology base.

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

Confidence and accuracy in electoral voting.

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

Providing a backbone for strong, private blockchains to various industries that are being used to solve various business challenges. An accepted standard similar to Linux.

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

At some point in every project, it is time to shoot the developer and ship the software. Knowing where that point of time is requires decades of experience, and makes all the difference in the world.

What technology could you not live without?

Cloud service models. The convenience and cross platform synchronization is making a truly mobile life possible. One reason blockchain is needed is to ensure the ongoing security, privacy, and resiliency of these models that are increasingly pulling us towards full reliance on external and potentially vulnerable information management models.

As an open source project that is part of the Linux Foundation, Hyperledger takes on a great deal of responsibility to deliver software using a process that is transparent, proactive, and uses the best security practices. This blog post is about the release process for Hyperledger projects reaching the version 1.0 milestone. It is the first in a series focused on the Hyperledger security regime. The next post in this series will focus on everything we do to make good on the promise of open source software being more secure.

When Hyperledger Fabric 1.0 was released on July 11th, 2017 several administrative initiatives were under way. The first of these was an audit of the source code to determine the open source licenses the software was under. Hyperledger uses the Apache 2.0 License for all of its original software and strives to only depend on other code licensed under the same or equally compatible licenses.

The second initiative was a cryptography export audit conducted by the Software Freedom Law Center. Despite a victory in the “crypto wars,” since blockchains require heavily on the latest cryptography, we still have a reporting requirement for all cryptography that we include in our software.

The third initiative was an outside security audit. The Hyperledger team contracted an outside firm named Nettitude to do an independent audit of the Fabric source code. The purpose was to get confirmation of the soundness of the software and to establish a baseline for its security. The team at Nettitude did a great job going through the source code and attempting penetration tests and running fuzzing processes against Fabric.

“Nettitude is delighted to have had the opportunity to work with The Linux Foundation to assess the security of their Hyperledger Fabric blockchain software. This was an exciting and timely piece of work, in a field which Nettitude had already identified as one of our security research priorities.”

The end results of the audit showed only a couple medium grade security issues that have since been mitigated. One issue was a general lack of comments in the code that documented the expected behavior of the code. This is an important detail because programmers can look at the code and figure out what it does, but bugs lurk in the difference between what the original programmer intended and what the code actually does. Having thorough comments in the code helps reduce the risk of a security regression occurring during future software maintenance work.

The other issue was focused on the general security of the Docker container used to execute chain code. The principle of least authority dictates that the Docker container should be restricted and isolated as much as possible. Today, we are finally publishing the Hyperledger Fabric 1.0 security audit report. We have published the technical report and the management report documents.

This process will be applied to all of the other Hyperledger projects as they reach the 1.0 milestone.. The next project to go through it is Hyperledger Sawtooth. The license, crypto, and security audits for Sawtooth have already been completed and readers should expect its 1.0 release in the very near future. Stay tuned for the follow up with the Sawtooth security audit report.If you would like to help us make great software, the Hyperledger community has organized meetups and hackfests all over the world. If you find a security issue please report it to security@hyperledger.org. You can find an upcoming event near you by visiting our events page here: https://hyperledger.org/events. We’ll also be talking at RSA this year in April in San Francisco. Director of Ecosystem, Marta Pierkarska and I will present “Blockchain-the new black. What about enterprise security?” We hope to see you there!

We’re back to our Developer Showcase blog series, which serves to highlight the work and motivations of developers, users and researchers collaborating on Hyperledger’s incubated projects. Next up is Rohit Aneja from Bristlecone Labs. Let’s see what he has to say!

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

One needs to be open minded – It is very new technology and many are interested in it due to its popularity. Many don’t know what it does. Also, there are many platforms claiming to be blockchain frameworks, but real frameworks that offer end to end blockchain needs ranging from membership service to smart contracts are rare, so developer needs to be well versed with knowledge and open minded for selecting a technology and implementing it.

Platform – Permissionless or permissioned – It is very important to identify which type of network is suitable for your needs. Like enterprise level networks where each member has some role and is known can leverage a permissioned network, also known as a private network.

Identify use case and problem solution – Identifying use case and finding a value prop for each participant on network is significant before making a solution. It may work for one party, but since the network needs participation from all members who are required on network, it is important to have use case which serve purpose to everyone.

Give back – contribute to open source – This is very important for every developer, consuming open source platforms or making solutions around it. Open source platforms rely on contributions and an active community. Answering questions, being active on forums is a must if you really want to explore, learn and master a framework.

Rohit Aneja, blockchain engineer, Bristlecone Labs

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?

At my organisation, Bristlecone Labs, I work as a blockchain engineer and prosper innovative solutions to serve supply chain specific use-cases. We have developed IOE + Blockchain solution based on Hyperledger Fabric 0.6 while 1.0 was still in its alpha phase. The solution is aimed at logging real time sensors data in its immutable ledgers and executing smart contracts on sensor data.

One of the use cases being smart contracts which execute on every sensor reading and checks if sensor crossed specific threshold, which may mean perishables are exposed to unsuitable conditions and have spoiled due to this. The system can help not only record such breach of contracts in immutable ledgers but can also identify responsible shipper and take corrective actions in real time. There is avoidance of any conflict with system in place and real time sensory data, optimisation and efficiency can be achieved by identifying rough routes and avoiding them, by having shock detecting sensors on shipping trucks transporting delicate or fragile shipments.

As blockchain is key to achieving the above scenarios where distributed participants can agree upon consensus, and benefit on big picture out of this system.

As there is a high interest from various big players as well as small players, plus the nature of blockchain platforms (being distributed, open source) also makes it available to everyone, by everyone, there is no “single owner” of these platforms and this technology but all of us working on blockchain are. This is one important fact which motivated me to jump into blockchain engineering and learn, contribute and innovate passionately for the better of the world.

What project in Hyperledger are you working on? Any new developments to share? Can you sum up your experience with Hyperledger?

Currently, I am developing a business network on Hyperledger Composer, although it’s in early stage of its development, it will be mostly a network of networks that will have suppliers identify an optimised supply path as well as have competitive advantage for being on a network than suppliers playing alone.

Hyperledger has been constantly evolving and has a very active community. Availability of production ready system that has high security and scalability in such early stages of blockchain technology is a bliss for developers. Availability of high quality documents and tutorials makes it easy for developers to jump into complex world of blockchain. As I started my Blockchain journey with Hyperlegder, after making some solutions, I have never felt short changed of features and possibilities that the framework offers. Having an active community with regular meetups and weekly updates keeps us flowing with recent changes and recommended coding guidelines.

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

I think, tools that make achieving end to end solutions faster and easier will definitely attract lots of audience and developers around the globe. Blockchain can be a complex topic for people from different backgrounds and giving tools for rapid development like Hyperledger Composer is a great value prop for people to adopt a simple and fast solution.

Keeping focus in improving such tools will really drive a large base towards Hyperledger framework. It is incredible what Hyperledger is doing and especially keeping it open source and public driven complements technology like blockchain, which at a core is – “there is no central authority.” Offering a framework which is contributed by the developer community around the globe, there is no way it can go wrong with great mediators and helpful, passionate organisers.

Blockchain is really going to have a big impact on how things function as of now (hence disruptive), and when business realizes true potentials of it, that’s when early adopters are going to really benefit.

We’re thrilled to announce that the Hyperledger team is continuing to grow in 2018. Please join us in welcoming David Boswell as the Director of Ecosystem!

David is a community expert who has worked with Mozilla, Open Networking Foundation, NASA, Sun Microsystems, Nokia and more on their community strategies. Through these past experiences, he has expertise with both launching a new community as well as scaling existing communities.

Now let’s get into some questions to better understand David’s role, what he will be working on and his own aspirations for Hyperledger.

What got you interested in working on Hyperledger and blockchain?

I was fascinated by the ability of blockchain technology to build trust and accountability. In our world today there is a great need for building more trust and accountability so this feels like a very important effort to become a part of.

David Boswell, Director of Developer Ecosystems

What are your main goals now that you’re part of the Hyperledger team?

One of my main goals is to bring in my experience of what has worked (and not worked) in other open source communities. When I got involved in an open source project for the first time in the late 1990s there was a lot of trial and error since no one knew what was going to be successful. We’re really lucky now that there is a long history of building successful open source projects we can leverage and I want to take best practices and good ideas from other communities and apply them to the needs of the Hyperledger project.

What do you think is most important for Hyperledger to focus on in the next year in terms of developer traction and community growth?

Scaling a community is a big challenge and I want to make sure that the excitement and enthusiasm around Hyperledger is translated into a growing community that continues to work well for everyone. A major challenge with growth is that processes and dynamics that worked well when the community was smaller can break down as the size of that community grows. It can be hard to realize when it is time to change something that has worked well in the past or when to introduce new things to keep a community running well. I saw this first hand as Mozilla went from a small project to a very large global community and I’m excited to share what I’ve learned about how to scale in an effective way.

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

A friend of mine who worked with volunteers at the Red Cross told me that the best way she knew to get people to participate was to ask for their help. I’ve found this to be extremely powerful advice for open source communities. There is a tendency to think that people will have ‘an itch to scratch’ and will show up and start working on things that they’re interested in. That is true at times, but there are also many times when people want to help but don’t know what to work on and letting them know where we need help and asking for their support can greatly increase the amount of participation within a community.

What do you like to do in your spare time?

After seeing the total solar eclipse in Wyoming last summer, I’ve become fascinated with those and am figuring out when to see another. I might have to wait a few years for the next opportunity though, so in the meantime I enjoy reading, hiking, diving, seeing live music and exploring the interesting things that the Bay Area offers.

We return to our Developer Showcase blog series, which serves to highlight the work and motivations of developers, users and researchers collaborating on Hyperledger’s incubated projects. Next up is Hrishikesh Nashikkar, blockchain lead at Broadridge. Let’s see what he has to say!

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

Blockchain is emerging as a huge collaborative innovation that has powered a paradigm shift from centralized applications to decentralized/distributed applications.

Firstly, the important aspect is a change in the development mindset. As we move applications from centralized to decentralized/distributed world, the development mindset needs to be changed as well. The solution to a problem may work perfectly in the centralized world, but may not work or even be suitable in the distributed world. For example, the matching logic in the current world business workflows will not be necessary and it can be completely re-designed in the distributed world by multi-party approval process where one party submits a transaction and other party approves/rejects, another example is, the existing data models will no longer be viable as we build granular data privacy requirements and require new data models.

Second, the technology is certainly not fully matured and still has several complex unsolved problems such as scalability, data archival and interoperability which need to be solved for before it can be productionized. Technologists should grab this opportunity to solve the problems and this brings with it immense learning, experience and a chance to innovate.

Third, we are seeing the technology rapidly evolving in both public and private blockchain space. As a developer, one should be open to both public or private blockchain implementations, both have subtle differences but it’s always helpful to be cognizant of pros and cons, design patterns, and application while implementing the use case.

Two years back, I started my journey with Hyperledger Fabric at Broadridge and we’ve always been at the forefront of experimenting with the latest version and testing Fabric for real-world use cases in the financial services. We believe some of the specific privacy, asset modeling requirements in the financial services are very critical to productionize the solution and we as technologists continue to provide the feedback or suggestions to the Fabric community. With this emerging technology, it is very important to share learning and best practices that mutually benefits the development community.

Hrishikesh Nashikkar, Blockchain Lead, Broadridge

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 currently working in Broadridge Blockchain Centre of Excellence and leading our efforts on Hyperledger Fabric and post-trade blockchain based projects.

Broadridge is the global fintech leader and plays a crucial role at the center of the financial services industry. We have been driving innovation and adoption of new technologies like Machine learning, Blockchain, Robotic Process Automation to solve real-world problems. Blockchain is one of the key technologies in our innovation strategy. We believe, Blockchain offers a high level of transparency, auditability, data privacy and security and this will certainly bring significant value-add, cost-saving and operational efficiency to our clients.

Given my background of a developer and subsequent exposure to the financial markets as a Business Analyst, Blockchain seemed like the next best choice for me as a career, as I can combine both of my skills to deliver next-gen solutions in the financial markets.

What project in Hyperledger are you working on? Any new developments to share? Can you sum up your experience with Hyperledger?

We at Broadridge have been extensively using Hyperledger Fabric for our internal POCs/Pilots since its initial versions.

Recently, Broadridge announced the successful completion of a pilot with Natixis and Societe Generale which leverages blockchain technology to enhance the operational efficiency, reduce risks and auditability of bilateral repurchase, or repo, agreements. The Bilateral Repo solution is for Broker-dealers and Buy-side firms that automate end-to-end processes, streamlines the repo agreement and confirmation processes, offers a faster and more accurate collateral substitution, valuation process and other mid-life events, while eliminating time-consuming manual interventions, and reduces counterparty risk while increasing auditability.

We have utilized Hyperledger Fabric v1.0 to facilitate private/permissioned network between Broadridge and its partners in the pilot. Overall, my experience is – Fabric has performed reasonably well with our pilot requirements during the testing, despite showing few pain points of an emerging technology. The development community has been very supportive and quickly helped us on the critical issues.

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

I think blockchain is rapidly evolving through enterprise, open-sourced or consortiums based developments. Many blockchain frameworks are available in different flavors, sizes and complexity levels. One of the key requirements is interoperability between different platforms. Various blockchain based application development projects or initiatives are being developed in silos. We see mixed opinions on the different blockchain frameworks and it is difficult to pinpoint the winner at the moment. It’s quite apparent, we’ll witness different blockchain frameworks being used in the industry.

This leads to few important questions. How will different blockchain frameworks co-exist and integrate with different standards of networking, data privacy and security, identity or crypto specifications, assets, smart contracts? Another critical question is – how do we manage interoperability between different legacy systems and new blockchain platforms with complex business logic and data storage? These questions become increasingly important when we set our path to productionize the use case and network with multiple participants with their own choice of blockchain technology.

Obviously, some of these questions are being brainstormed or addressed to a certain extent. But, secure, robust operational designs and common standards need to be incorporated to build the strong ecosystem for the future.

I believe, Hyperledger is playing an important role as a technology incubator in the industry and has multiple cross-industry blockchain projects under its umbrella. Hyperledger is the best platform to start addressing some of these problems and build common standards across different blockchain frameworks.

Today, we are pleased to announce Hyperledger Sawtooth 1.0 is now available! This is a major milestone for the Hyperledger community, as it marks the second blockchain framework that has reached production ready status. This Hyperledger Sawtooth 1.0 release is the culmination of work from several companies intent on creating a distributed ledger designed for the enterprise.

Stretching back to at least 2014, the journey began with a research project code-named Sawtooth Lake inside Intel Labs. Its purpose was to explore the security and scalability questions arising from the adoption of Bitcoin and understand the requirements to move blockchain technology into enterprise. By 2016 research had produced Proof of Elapsed Time (PoET), to provide a green and performant alternative consensus to Proof of Work, and Transaction Families, an approach to building safe smart contracts. In the same year, Hyperledger was getting underway and Intel contributed Sawtooth Lake to Hyperledger as an incubated project. From incubation the community rapidly grew with code contributors from diverse companies and individuals and winning an ‘Open Source Rookie of the Year’ award. In May of the following year, Sawtooth dropped the “Lake” and graduated from incubation to “active” status within Hyperledger – a recognition of the maturity of its open source process and community.

We would not have the rich features or deployment maturity today without the collaboration and contributions from these organizations (alphabetically): Active Ticketing, Amazon Web Services, Bitwise.io, Cloudsoft, Context Labs, Dot BC Media, Ericsson, Hacera, Huawei, IBM, Intel, Microsoft Azure, Monax, Open Music Initiative, PokitDok, R3, T-Mobile, Wind River, and several independent engineers.

Throughout this time, we’ve maintained our focus on making smart contracts safe and bringing blockchain to the enterprise without cutting the benefits of blockchain that inspired interest to begin with. While maintaining that focus, we’ve not rested on PoET and Transaction Families. With the launch of Sawtooth 1.0 we introduce several new enterprise features:

On-chain governance – Utilize smart contracts to vote on blockchain configuration settings such as the allowed participants and smart contracts.

Support for Ethereum – Run solidity smart contracts and integrate with Ethereum tooling.

Dynamic consensus – Upgrade or swap the blockchain consensus protocol on the fly as your network grows, enabling the integration of more scalable algorithms as they are available.

Projects over the last 2 years with various consortia, startups, and established companies guided this set of features. For example, we found that it was difficult and error-prone to have manual configuration files on each system deployed at n different companies. If a configuration setting is required to be the same across the network, that seemed a lot like needing shared state agreement, which is after all the goal of a blockchain. Subsequently we added “On-Chain Governance” as a first class feature of Sawtooth. This also satisfies auditability goals that are driving many companies’ interest in blockchain.

When it comes to business logic, we learned how to manage and isolateapplications on the blockchain. The resulting design enables parallel execution for better performance. It also enforces complete separation between the core blockchain and the apps, such that you can write the app in just about any language. In fact, that worked so well, that we were able to bring Hyperledger Burrow’s EVM on board as an application we call Seth (a play on words for Sawtooth and Ethereum).

A little more on the decision to prioritize the Seth / Ethereum contract compatibility – We found that a lot of companies had been experimenting with Ethereum but wanted the enterprise features offered in Hyperledger Sawtooth. Seth turned out to be an easy way to enable those companies to bring across their existing business logic and pick up new features like Permissioning and Un-pluggable Consensus.

Sawtooth Integration Testnet Console

For those close to Sawtooth, a lot of this is old news. Many of these features have been in test networks for three to six months by this point. During that period we’ve been focused on stability and performance. The engineering you won’t see are automated integration test networks we’ve built to run each release candidate build through a rigorous 7-day, multi-node test. This is in addition to the existing continuous integration testing we’ve had in place for years.

Where will Hyperledger Sawtooth focus its efforts in 2018? Well, we are already in motion on more work in performance and new work in privacy. To the former, we are looking at both consensus and core implementation. We’d like to add another consensus option for those planning to run small networks. Within the core, we are looking at replacing targeted python modules with optimized components in languages like Rust. On the privacy front, we have contributors investigating both trusted execution and zero-knowledge cryptographic approaches. We look forward to our enterprise users contributing back pilot implementations in these spaces as well.

We get feedback that application development is easier in Hyperledger Sawtooth than other platforms. Nonetheless, we’ll be making some changes to make it even easier. In a related vein, we’ve had great collaboration with Hyperledger Burrow, and we want to expand that collaboration to other Hyperledger projects including Fabric, Indy, and Composer.

Today, we’re excited to announce that the Technical Steering Committee (TSC) has voted to approve the launch of Hyperledger Labs! Hyperledger Labs aims to provide a channel suitable for innovation and testing of ideas where work can easily be started without the creation of a formal Hyperledger project. It will allow teams to experiment with new frameworks and new modules without the promise of stable code or MVP.

We believe Hyperledger Labs supports the main goal behind Hyperledger to help build communities by gathering people sharing a common interest in developing blockchain related software.

Why Hyperledger Labs?

Currently, the project lifecycle at Hyperledger requires projects to be started in Incubation and graduate to Active projects. However the only way to currently do this is to submit a project proposal and launch a formal project in Incubation. This is a relatively heavy process that requires a level of endorsement by Hyperledger that is not suitable for cases where projects are immature from a code-complete, production-quality, or community building perspective, or experimental.

Hyperledger Labs lowers the pressure on the TSC to start new projects and allow for work to be done within a legal framework that eases transition to a project in Incubation in cases where this ends up being the chosen path for the Labs.

What can be in Labs?

Examples of possible Labs include: projects too early for TSC approval as an incubator because there’s not a lot of code; demos; documentation examples; sample code from hackathons, research projects, etc.

There is no guarantee that a Lab will become an incubated or fully-fledged project at Hyperledger. If at any point a Lab wants to enter Incubation and become a formal project, a project proposal will need to be submitted for TSC consideration.

How will Labs work?

Hyperledger Labs is not directly controlled by the TSC. Labs are proposed and run by the community. They can be created by a simple request (done by submitting a Pull Request) to the Labs Stewards.

Labs Stewards act in oversight to ensure legal compliance, etc., and will produce a quarterly hyperledger-labs-wide “project” report to the TSC. To help the community understand the status of the different Labs, Stewards will also be responsible for curating the set of Labs, moving to an archives space those that become dormant or unresponsive for an extended period (6+ months), or are explicitly deemed by the committers to be deprecated/obsoleted. In case of issue with the Labs Stewards, requesters and/or committers can appeal to the TSC for arbitration.

The Labs Stewards will consist of the Hyperledger Community Architect(s), who are staff members of The Linux Foundation, and subsequently any volunteer from the community approved by the TSC. The initial list of Lab Stewards is:

Arnaud Le Hors

Vipin Bharathan

Bas van Oostveen

Tracy Kuhrt

Get involved!

We hope that Hyperledger Labs encourages more developers to get involved and experiment in the community. The following communication channels have been set up for Hyperledger Labs:

As always, we encourage developers to join our efforts via github, Rocket.Chat, the wiki or the mailing lists. You can also follow Hyperledger on Twitter or email us with any questions: info@hyperledger.org.

We return to our Developer Showcase blog series, which serves to highlight the work and motivations of developers, users and researchers collaborating on Hyperledger’s incubated projects. Next up is George Theofilis, CTO of Synaphea. Let’s see what he has to say!

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

Get your theoretical background fortified, and start reading, now! Knowing it works is only half the skill, if you can’t explain how and why it works. This might force you to at least dab in economics or legal studies a bit, but it sure is worth your while.

Theoretical background is of major importance and so is market knowledge in order for a development team to quickly grasp the value of the solution they build.

A relatively novice programmer wishing to build a blockchain application with Hyperledger should definitely possess an adequate basic understanding of Docker as well as some fluency in the Go programming language.

George Theofilis, CTO of Synaphea

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?

For me it started with academic curiosity during my years in the university. From there it grew into something more very quickly, supported by the hype of the bitcoin community. What my startup and I are working on right now is a wide array of tools for smart-contract management – which began as ways to make our daily lives easier – and an aggregation system for easy deployment for smart-contracts over many blockchain implementations and networks, both public and privately owned.

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

I think blockchain technology would help us to further the digitization of the public sector. Thus making public management more transparent and efficient. One such application of blockchain would be digital IDs or an application that would issue needed credentials in an automated way.

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

Every day try to learn a new thing and to push yourself to your limits, is the only way to mastering computer programming.

What technology could you not live without?

On a matter of lifestyle I think it’s the internet. It became synonymous with the western way of life. But on a more pragmatic approach it would definitely be electricity. Humanity depends much on electric current for its survival.

Hyperledger Sawtoothis an enterprise blockchain platform for building distributed ledger applications and networks. Sawtooth simplifies blockchain application development by separating the core system from the application domain. Application developers can specify the business rules appropriate for their application, using the language of their choice, without needing to know the underlying design of the core system.

In this blog post though, we wanted to get past the “Hello World” content and talk about some of that underlying design to allow advanced developers to extract more performance. (TLDR: Read this design doc). Sawtooth relies on a merkle radix data structure as the underlying data store. This differs from Hyperledger Fabric, but is common with some other blockchain implementations.

If you are just getting started with Sawtooth you really don’t need to understand any of this, but if you are interested in digging deeper or are working on an intensive blockchain application there’s some design considerations to think through on your data model.

Let’s say we have some resources we plan to store as UTF-8 encoded JSON strings. You can use any byte encoding you like, and there are better options than JSON, but this will give us something familiar and human readable as an example. Our resources are going to have a pretty simple structure, just a unique id, a description, and an array of numbers:

So now we have to decide how to store this data on the merkle radix tree. Sawtooth addresses are made up of 35-bytes, typically represented as 70 hexadecimal characters. The first six characters are the namespace for our transaction family, but the final 64 characters we can use however we like. Let’s go through three possible setups we could choose:

All of our data is stored at a single address.

Each resource is stored its own address.

Each resource is stored over multiple addresses.

One Address For Everything

This is an absurd design only appropriate for the most rudimentary hello world examples. But why is it absurd? Exploring that should provide some useful insights. Let’s say we just take all of our data, and throw it in one JSON object indexed by the resource ids:

(Note that the space after the namespace in the addresses above are just for illustration purposes. Sawtooth addresses do not have spaces.)

From a certain perspective this may be attractive for its simplicity. You don't need to think about addressing at all! You just always read/write from the one address and pull up whatever JSON is there. There are unfortunately two big downsides to this approach:

First, you now need to read/write a lot of data anytime you want to make a modification. Anytime anything changes, you will be parsing a huge JSON string, updating some small part of the resulting data, then re-encoding it as JSON and writing it back to the merkle tree. With any number of resources this will quickly become a huge performance bottleneck.

Second, you will have hamstrung one of Sawtooth's greatest strengths: parallelism. Sawtooth validators are capable of simultaneously validating multiple transactions, but if those transactions are trying to write to the same address, they cannot be executed in parallel, and must be validated sequentially. So with all of our data in a single address we guarantee validators will only ever work on one transaction at a time.

One Address per Resource

This approach is a little more sensible and still fairly simple. While you don't get to ignore addressing completely, all you really need to do is to find a way to turn each resource's unique identifier into 64 hex characters. A common method is to just take the first 64 characters of a hash. Here's how we would store our example resource above if we took the SHA-512 hash of the “id” field:

This is likely the approach you'll see in many applications. It is easy to reason about, and as long as each resource is not too large, or updated too frequently, performance should be reasonable. But what if we do have large or frequently updated resources? Could we split this up further?

One Resource over Multiple Addresses

64 hex characters provides us with trillions and trillions of potential addresses. There is no reason not to get as fine-grained as we like with them. For example we could use the first 60 characters for a hash of the identifier, and then use the remaining 4 characters for a hash of each property name:

This is also a pretty absurd example. In order to reconstruct the resource later we have to spell out the property name and include the resource id repeatedly. Overall we are storing a lot more data, but we have minimized the amount of data we need read/write in each update. Also, while our validator can now do some fancy tricks like updating the "description" at the same time it updates the "number", that probably isn't important with our tiny little array of three numbers.

But what if we had thousands of numbers that changed frequently? We could instead use those last address characters as array indexes. Something like this:

So now we are using 56 characters for the id hash, and reserving the last eight for pieces of the resource, which gives us room for a few billion pieces. All of the basic resource info is at 00000000, while any remaining addresses each store a single number.

This is starting to get pretty complex, and reconstructing this resource later will be a pain, but adding a new numbers has become extremely simple. Imagine the array was 10,000 items long. In any of the previous designs we would have had to parse that entire gigantic string and then re-encode it, just to add one item. With this design, we just add a new entry to the next index. Also, the validator can be highly parallelized now. Adding new numbers, updating the description, and changing existing numbers can all happen at the same time.

Conclusion

There is no one correct answer or strategy when it comes to structuring your data model. You'll need to decide for yourself what is appropriate based on your developer and application needs. In Sawtooth Supply Chain, we have "Record" resources with multiple arrays of telemetry data that could be updated on a second by second basis, and might stretch to millions of entries. So Records are highly split up in a manner similar to the numbers example above. Logically we are just pushing to an array, but in practice we needed to break that into different buckets. For a full discussion of this pattern take a look at the supply chain doc on the subject.

Zac Delventhal is senior software engineer at Bitwise IO, and a maintainer on Hyperledger Sawtooth. When bored, he can be found giving overly long explanations about Hyperledger concepts in blog posts or on RocketChat.