Developer Showcase Series: Judy Priest, Engineer, Cisco

By Blog

The Hyperledger community is comprised of developers and technical leaders from around the globe who are working together to change the world with blockchain technologies. This new blog series highlights the work and motivations of developers, users and researchers collaborating on Hyperledger’s incubated projects to build blockchain frameworks and platforms in an open and collaborative manner. Below is our first interview with Judy Priest who is an engineer at Cisco working on blockchain.

Let’s get to it…

Give a bit of background on what you’re working on and what made you want to get into blockchain?

Judy Priest, Engineer, Cisco

When I first started getting into blockchain, 99% of the published content was around Bitcoin, and 95% of the use cases involved some type of cryptocurrency. As a technologist, I had an appreciation for blockchain as a technology, but I didn’t have much interest in the typical financial transaction use cases.  However, I was fascinated by several of the other novel use cases that blockchain could enable.

Cisco is a long time member of The Linux Foundation and highly vested in the open source community. I attended the very first Hyperledger Project meeting, and we talked about the importance of creating an enterprise class solution based on blockchain that could span across multiple industries. We talked about the different use cases across supply chain, Internet of Things (IoT), healthcare, identity, and tracking and trading of digital and physical assets. These are all areas where Cisco is driving our digitization strategy, and markets that are important to our customers, partners, and suppliers. The dots were starting to connect on the revolutionary and truly disruptive potential of blockchain to transform businesses.

Can you sum up your experience with Hyperledger, thus far?

With any nascent technology, the global experts are rarely all inside one single company or university. Being a member of Hyperledger has given me access to an amazing intellectual collective, brought together in a genuinely collaborative community and cooperative development environment. If you look at blockchain long enough, you’ll soon realize that there isn’t a one-size-fits-all solution for all those different markets and applications. We came in with different ideas and eventually got to the point of defining frameworks for modular, configurable, and composable architectures, based on specific use cases that defined those particular requirements.

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

In the next year, I’d like to see this become more plug and play. Hyperledger can do the heavy lifting (e.g., code quality, documentation) so new developers can take the various components and spend less time debugging the codebase, and spend more time customizing a unique blockchain for their needs.

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

My advice for anyone interested in getting started working on blockchain – start with your business use case. If you don’t start there, you should expect a lot of mental spirals. As many experienced technologists will tell you, you need to fall in love with the problem you are solving, not the technology or the particular “hammer” you have available. If there is no pain point and a simpler solution already exists or is sufficient, then you should question whether a blockchain adds value. For many problems blockchain is not the right answer, but for some problems it is a transformative solution.

Gain your domain expertise early, dive into the codebase and start looking at what transaction layer requirements you have for your application. What security features, policy management, and infrastructure is required to support it?

When a technology has such wide cross-industry impact, it’s not a question of `if’ but a matter of “when” and “where”. As the poet Ovid said, “If you are not ready today, you will be even less so tomorrow.”

Are you building something cool on top of Hyperledger? Tell us about it – we’d love to feature your work. You can email, if so. You can also plug into the Hyperledger Community at github, Rocket.Chat, the wiki or our mailing list.

Recap: Dutch Blockchain Hackathon

By Blog

Guest post: Chris Ferris, Head of Hyperledger Technical Steering Committee 

I had a really great time this past weekend at the Dutch Blockchain Hackathon. I had been invited to serve as a “super accelerator”, a judging role I’ll explain in a bit.

This event was billed as the worlds largest blockchain hackathon to date. It was certainly impressive in its size! There were 55 teams of 5-6 participants competing in 5 solution domain tracks (Identity, Pensions, Energy, Reinventing Government, and Entrepreneurship and Trade). Microsoft and IBM were the Technology Sponsors of the event. Interestingly, the teams were roughly evenly divided between use of Ethereum and Hyperledger Fabric in their hacks. One team even tried to use Fabric v1.0 level code however, the nature of their hack involved a function still missing from the Node.js SDK, so they reverted to the Fabric v0.6 stable release.

One of the key themes of the event was that it was intended to “accelerate” winning teams through the next stages of realizing their vision – this is where the role of “super accelerator” came in. As a “super accelerator” we were to help the winning teams with connections, insights and guidance as they sought to continue development of their solution. I had offered to help any of the teams in establishing open source governance and community building insights for their projects, and for the winning teams using Hyperledger projects, any technical expertise and guidance.

The winning teams in the Identity and Entrepreneur track both used Hyperledger Fabric in their solutions. The Identity track winning team had a very novel approach to identity rehabilitation for refugees. The Entrepreneur track focused their winning solution on a uniquely Dutch problem pertaining to freelance contractors tax and pension allocation that is mandated by a new law.

Of course, there were plenty of great ideas being implemented by non-winning teams. Lots of world-changing ideas around green energy, identity and reinventing government. The energy and excitement at the event was inspiring. I’ll leave you with a taste in a video clip assembled by the organizers.



Given the excitement, innovation and energy at this event, I a really looking forward to the Hyperleger Hackathon in Shanghai next month!

Hyperledger Meetups – Get Involved in 2017!

By Blog

The Hyperledger meetup scene continues to thrive in 2017. We now have 9,134 members across 38 different meetup groups all around the world! We have our amazing community to thank for this growth.

Most recently, we hosted a meetup in Seoul, South Korea. 50 people attended from financial institutions like Mirae Asset and Shinyoung Securities, universities including Korea, Yonsei, and Hongik, as well as Hyperledger members like Coinplug, Samsung SDS and Koscom. There were also a few startups in attendance. The content was introductory and focused on Hyperledger Fabric. We’re now planning a meetup in Seoul on February 23 that will cover more general blockchain information, key players, as well as additional information on how Hyperledger fits into the market.

On January 17 we held our second Hyperledger Hong Kong meetup. Around 50 people attended, from financial institutions such as HSBC, Bloomberg and Standard Chartered Bank, to consultants including Ernst & Young and Deloitte, and Fintechs like ANX International.

Attendees were updated on exciting developments and activities in Hyperledger in Asia Pacific and Greater China, by Hyperledger Asia Pacific VP, Julian Gordon, and for Hong Kong by IBM’s Solution Industry Executive, Daniel Leung. John Wolpert, IBM’s Blockchain Offerings Director, led an in-depth discussion and Q&A on Hyperledger Fabric. The meetup was organized by Jen Advisors and held at Infiniti Lab.

We also hosted a Hyperledger meetup in Shenzhen, China on January 7. The meetup was organized by IPA (Investment and Promotion Administration, Futian District), FISCO (Financial Blockchain Shenzhen Consortium), Energy Blockchain Labs, IBM and Huawei. More than 250 attendees from 40+ different organizations came to sit in on both morning and afternoon sessions that covered the basics of blockchain technology, its application in financial services and technical discussions on Hyperledger.

Finally, there is a Hyperledger Hackathon planned for March 10 & 11th in Shanghai. It will include an overview on Hyperledger, chaincode development, and blockchain use case discussion.

Are you thinking of starting a Hyperledger meetup?  We strongly encourage and support the community in starting their own events, but there are a few things that should be considered beforehand. Please visit our Wiki to learn more first:

If you have any other questions about starting a meetup or the process, please email

Happy meeting!

Happy Birthday, Hyperledger!

By Blog
Last February, The Linux Foundation announced 30 founding members and six of those proposed contributions of code to advance blockchain technology under Hyperledger. Fast forward to today, Hyperledger is now the fastest growing project ever hosted by The Linux Foundation. More than 110 member companies that span numerous industries make up the project and support five incubated open source projects. Hyperledger membership is truly global with 39% in APAC (25% in China), 20% in EMEA and 41% spread across North America. Below is an overview highlighting the important achievements in Hyperledger’s first year. Read More

Event Recap: Blockchain Masterminds Unite at Hyperledger Hackfest

By Blog

Guest post: Hanna Zubko, IntellectEU

Last week, Blockchain masterminds gathered for three events in the Bay Area:  Blockchain Protocol Analysis & Security Engineering Conference, CoinDesk’s Construct Conference, and Hyperledger’s Hackfest. All the events demonstrated that blockchain technology is becoming more mature and forming an emerging industry of startups and enterprise players.

On January 29-30, Stanford University hosted a deeply scientific conference on the security and systemic risks in blockchain protocols through the use of formal methods, empirical analysis, and risk models. Brilliant presentations on modern trends in consensus algorithms and communication protocols ensued open conversations among cryptographers representing various distributed ledgers. The conference succeeded to foster multidisciplinary collaboration among practitioners and researchers. Among the participants, companies presenting various efforts built on top of Hyperledger’s technology included HACERA, Skuchain, and IntellectEU. HACERA was presented at the second part of the talk  “Permissioning Your Blockchain: How to Overlay Hyperledger Fabric with a Fully Workable System Tapestry” at the event.

After an unusually warm weekend in San Francisco, a group of 350 technical blockchain experts headed to the Innovation Hangar. At the invite-only CoinDesk’s Construct Conference, participants heard the latest updates from CTOs of leading Blockchain initiatives, saw live product demos, and were able to install environments for protocols and projects that were new to some.

Hyperledger frameworks including Fabric, Sawtooth Lake, and Iroha had dedicated sessions presented by Chris Ferris, Mic Bowman and Makoto Takemiya, respectively. Brian Behlendorf, Executive Director of Hyperledger, delivered an update on the “Modular Umbrella Approach,” which included new efforts like Cello, and existing projects like Chaintool and Blockchain Explorer. Everyone that was interested in Hyperledger Fabric could witness a trading marbles demo in a separate dedicated pavilion.

While those events were a real treat for all Blockchain professionals, the Hyperledger Hackfest was the cherry-on-top. It gathered 80 Hyperledger enthusiasts and core developers at the Presidio on February 1-2. Both days were filled with project activities, updates, and work group meetings on coding and support. During the Hackfest, Iroha and IBM even announced their collaboration. The Hackfest featured two working groups: Architecture WG and Identity WG. The highlight had to be a presentation that introduced an application framework designed to simplify and expedite the creation of Hyperledger blockchain applications with additional business logic on top often referred to as “smart contracts” – Fabric Composer.

The consensus for all the three events is that Blockchain is here to stay. While 2016 was named the year of Proof of Concept, 2017 promises to be a year of Pilot. The Blockchain ecosystem across companies and industries unites efforts to address scalability and privacy challenges. It is acclaimed that the Hyperledger community plays a notable role in this game.

If you’re interested in blockchain, plug into the Hyperledger Community at github, Rocket.Chat the wiki or our mailing list. You can also follow Hyperledger on Twitter or email us with any questions:


Hyperledger Says Hello to Cello

By Blog

Today, we’re excited to welcome a new project to Hyperledger, Cello. Cello is a toolkit for deploying a Blockchain-as-a-Service, that reduces the effort required for creating, managing, and terminating blockchains. Hyperledger serves as an “umbrella” for software developer communities building open source blockchain and related technologies, and as such, Cello joins many other efforts including Fabric, Sawtooth Lake, Blockchain Explorer, and Iroha.

What is Cello?

Cello aims to bring the on-demand “as-a-service” deployment model to the blockchain ecosystem, to provide a multi-tenant chain service efficiently and automatically, on top of various infrastructure, e.g., baremetal, virtual machine, and more container platforms.

With Cello, operators can create and manage multiple blockchains in a pool through a dashboard, at the same time users (typically the chaincode developers) can obtain blockchains instantly with a single request, as illustrated in the figure below.

Cello will plan to support existing and further Hyperledger blockchain platforms including Fabric, Sawtooth Lake, Iroha, and more. We have been evaluating Cello for several environments, e.g., Cello in a POWER-based Cloud has supported thousands of chains for nearly a year.
“Cello will definitely welcome potential collaborations with other important projects, to achieve another open-source success”, said by the initial project proposer, Baohua Yang.

Why Cello?

The Hyperledger community and by extension, The Linux Foundation, has initialized several projects (e.g., Fabric, Sawtooth Lake and Iroha) for the Decentralized Ledger Technology (DLT) ecosystems. Those projects provide various ledger implementations targeting performance, stability, permissions, scalability, etc. Cello hopes to help build the community by providing the blockchain service functionality and attracting more contributors to Hyperledger.

Today, to boot a chain, developers need to adopt the installation scripts, e.g., docker-compose scripts in Fabric. If multiple tenants requires to obtain separate chains at the same time, they have to modify the scripts carefully and create these chains manually. This procedure is time consuming, and even worse, leads to possible misconfigurations.

Take Hyperledger Fabric, for example, currently, the solution to create a Hyperledger Fabric chain includes:

  • Manual installation of each peer node on different servers. This requires much effort and is error prone.
  • Setup scripts (e.g., Docker-Compose) to start a fabric network. This requires a specific server configuration, which makes it hard to share resources and dynamically create multiple chains.

Cello solves these problems in a different way, by maintaining a pool of chains automatically. Users will get chains with various configurations instantly, while operators can dynamically scale the physical resources through a dashboard.

The Hyperledger community now has projects of SDK, blockchain-explorer and chaintool. Cello is a great complement. For example, Cello can boot a blockchain with blockchain-explorer as the dashboard, with SDK and chaintool as the interface to operate chaincode.

Cello’s Architecture

Cello leverages the Docker APIs to manage the blockchain clusters in remote hosts, including physical servers and virtual machines. Hence Cello can be easily deployed to Cloud environments that provide virtual machines on demand.

The design architecture is as follows:

  • Orchestration Engine: Core to handle resource management and workload scheduling, which is mainly implemented in Python;
  • Dashboard: Operational interface, implemented with JavaScript;
  • Restful Server: Operational interface, which is implemented with Python;
  • Drivers: Currently we utilize Docker API lib, to support native host and Swarm cluster The driver layer is designed to be pluggable to support more types in future;
  • Tools: We have also designed several tools to handle tasks like monitoring and logging, which are mainly implemented in Golang. However, the framework is pluggable, hence we can also integrate existing open-source tools.


Who will work on Cello?

Currently, Baohua Yang and Haitao Yue from IBM Research are committed part-time to developing and maintaining the project. There are also sponsors from Soramitsu, Huawei and Intel.

Learn more about Cello

Cello is hosted at github. We will follow the Hyperledger community’s guide, all information is open at the wikipage at Please connect up directly with the Cello team.  Their contact details can be found at those interested in other technical projects under Hyperledger, please reach out to: 


Help Shape The Future of Blockchain – Join the Hyperledger Team!

By Blog

Huge thanks to all our members and the community for their support in 2016. It has been a real pleasure for all of us to be behind something so great.

Hyperledger is moving full steam ahead in 2017! As the number of different projects, different members, and public interest in Hyperledger has grown, so too has our concept of who we are and how we support the community. Given that, the Linux Foundation is looking to fill new roles on the Hyperledger team: a Director of Ecosystem Development, a Security Maven, and two Community Architects to help Hyperledger drive open blockchain standards and technologies in the coming year.

The Community Architects will be technical, and expected to write code from time to time, but their primary role is to remove all barriers for other developers to understand, get productive, and start collaborating. They will also assist technical conversations across projects, drive a holistic overarching architecture that makes sense to developers and the broader user community, and drive successful adoption of open source development practices across Hyperledger.

The Security Maven will ensure the Hyperledger community implements the best practices of secure software development, from reporting processes to code scanning to building a common security model. Finally, the Director of Ecosystem Development will help us coordinate all the non-development-related engagement with our members and the broader business community.

If you’re interested in any of the positions mentioned, please apply directly here:
Here’s to a great year!

Hyperledger Announces Technical Working Group China

By Blog


Hyperledger membership has been growing quickly in China over the past year. To date, more than 25% of Hyperledger members are from mainland China. In order to foster a strong relationship between the Hyperledger global community and the China local technical teams, today, Hyperledger is announcing a Technical Working Group China (TWG China). TWG China was officially approved by the Hyperledger TSC on December 1, 2016.

The TWG China is a bridge between the global Hyperledger community, the emerging technical users and contributors in China and the greater region, including Hong Kong and Taiwan. TWG China is now led by key contributors from China, who actively contribute to the Hyperledger Technical Community and build the consortium ecosystem. Currently, three members are appointed by Hyperledger TSC as chairpersons of the working group, including Baohua Yang from IBM, Dong Cai from Wanda and Ruifeng Hu from Huawei.

The mission for TWG China is to help grow the Hyperledger developer community in China by responding to new user questions, as well as help with first-level triage of community-reported bugs or other issues. TWG China will also:

  1. Help grow the Hyperledger technical team, embrace more members and encourage technical contribution to Hyperledger community from the greater China region.
  2. Help demonstrate to new developers how to contribute,e.g., report bugs or file pull requests, and point motivated developers towards the Hyperledger roadmaps and development initiatives.
  3. Expose new users to the broad range of projects at Hyperledger.
  4. Regularly organize meetups, Hackathons, trainings and related activities for the membership and technical fans to communicate and exchange innovative ideas with each other.

Individual contribution and firm membership are warmly welcomed. As an open team, TWG China encourages others from the community to join the team, help build the local technical scene, and promote Hyperledger with more adoptions and scenarios. If you’re interested in joining please email You can also visit: for additional information.



在过去的一年中,Hyperledger 中国成员增长迅速。目前,25%以上的Hyperledger 成员来自中国大陆地区。为了培养Hyperledger 全球社区与中国当地技术团队之间的紧密联系,今天,Hyperledger 宣布成立中国技术工作组(TWG China)。该工作组由 Hyperledger 技术委员会于2016121日正式批准。

中国技术工作组是连接 Hyperledger 全球社区和大中华地区(包括港台)新兴技术用户和贡献者的桥梁。中国技术工作组的具体工作由数位来自中国的核心贡献者领导展开,他们作为 Hyperledger 技术社区的活跃贡献者,帮助建设了整个联盟的生态系统。目前工作组的三位执行主席由 Hyperledger 技术委员会任命,他们是杨保华(IBM)、蔡栋(万达)以及胡瑞丰(华为)。

中国技术工作组的使命是发展壮大中国的 Hyperledger 开发者社区,包括新用户答疑以及归类处理社区反馈的 bug 和其他问题。另外,中国技术工作组的具体工作还包括:

帮助扩展 Hyperledger 技术团队,吸引更多成员加入,鼓励更多来自大中华地区的对 Hyperledger 社区的技术贡献。

向新开发者演示如何进行贡献,包括报告问题、提交代码等,帮助有意向的开发者向 Hyperledger 的技术路线图和开发设计理念靠拢。

Hyperledger 旗下的多个子项目带来更多的新用户。


我们诚挚欢迎独立贡献者和公司成员的加入。作为一个开放的团队,中国技术工作组鼓励社区的其他成员的加入,一起建设本地化的技术氛围,让Hyperledger 获得更多可能的应用和场景。如果您有兴趣加入,请发送邮件到 。您也可以访问了解更多信息。

Meet Sawtooth Lake

By Blog, Hyperledger Sawtooth

By Dan Middleton, Sawtooth Lake Maintainer*

When I was asked to post about Sawtooth Lake, an obvious topic was “What is Sawtooth?”  Well, Sawtooth Lake is a distributed ledger with novel consensus and transaction handling, incubated under the Hyperledger umbrella.

But maybe a more interesting question is “Why is Sawtooth?”  Given the profusion of bitcoin forks and other blockchains why create another system?  In a nutshell, there are usages that shouldn’t be contorted on top of a currency or on top of a centralized database – even if it’s replicated.

1-mrhyperledger-300x94 Originally, Sawtooth Lake was designed to explore scalability, security, and privacy questions prompted by the original distributed ledgers. That mandated a certain modularity that was lacking at the time. Starting from scratch allowed us to employ lessons from those pioneering systems and branch into usages that the original currency ledgers weren’t intended to address. PoET, the new consensus hits scalability, while Transaction Families, our contract logic, narrow the attack surface for contracts while simultaneously broadening the functionality. We also have a keen interest in trusted execution environments and what role that can play in private transactions.

In branching into new business cases, we felt it was important that the system preserve certain tenants of a distributed ledger. That is, in an enterprise deployment, the concept of a distributed ledger shouldn’t collapse into a replicated database. Enterprise participants need autonomy and they have the right to run their own nodes. The set of participants will also be dynamic and the system – particularly consensus – must accommodate that volatility. It is not clear, for example, whether an O(n2) protocol with fixed membership like PBFT can support the scale or volatility of a distributed ledger at production levels. Finally, we observed that, “public” and “private” define a spectrum of authorization policies – not a binary option for a distributed ledger.

Since open sourcing earlier this year, we’ve learned a lot from industry trials. Sawtooth Lake’s pluggable Transaction Families have enabled its use in exploratory projects across several industries, including recent public announcements of a global deployment in finance and as the reference platform for a music industry initiative. Likewise pluggable consensus allows Sawtooth Lake to be used in small tightly held networks or large broadly open networks. If there’s a sweet spot for Sawtooth Lake, though, it’s the Consortium Ledger.


Before getting into the novelties of Sawtooth lake, it’s worth motivating the problem space.  There are plenty of replicated databases.  We want to build a truly distributed ledger.  The business models in this space involve tens to hundreds of business entities.  That puts some unique demands on the underlying distributed system.

2-pluribus-300x113 Consortiums fit the bill for Distributed Ledger Technology (DLT) as a collection of related, but not fully trusting organizations, that can benefit from a shared view of data. One of the promises of DLT is that it creates win-win opportunities for organizations to open up silos. Eliminating intermediaries is an often cited benefit, but to me, DLT isn’t just about efficiencies, it’s about unlocking new ways to grow.

Consider a motivating example from supply chain, let’s say you want your product to use only ethically sourced minerals, but your company is several steps removed from mining the raw materials, refining them, etc. A shared ledger recording each transfer from materials harvesting to product assembly would let you trace the provenance and gain confidence that the end product is ethically sourced. To work well, that shared database needs input from a variety of companies. Without a shared ledger, it’s more difficult for any of the suppliers or retailers to advertise and capture the value of the ethical sourcing. While it might be possible to accomplish that with a single, centralized database managed by a governing entity, a DLT offers better and perhaps necessary features.

In too simple of an example, the supply chain has a single chain of relationships or perhaps a radial network with a center – which, importantly, could be served by a traditional, centralized database.

3-supplychain-768x174Overly Simplistic Supply Chain.

A real ecosystem, however, has a web of relationships. By looking at only one node in that network, its direct connections form a natural group that suggests it could be supported with a centralized database. But by observing that each of these nodes has a nexus of relationships – it’s own centrality – it’s clear there’s no single, central database that makes sense. Consider also the kinds of data that are relevant and not relevant to each peer.

ecosystem_comparisonA DLT is ideal for this kind of scenario where relationships and dependencies are many and varied.

We believe that a truly distributed ledger should provide autonomy to each participant, and that participants should be allowed to run their own nodes. A consortium may develop rules for authorizing participants, but centralizing the nodes and the control defeats the purpose of distribution and fails to satisfy the actual requirements of the participants.

Realistically, participating companies will be dynamic, entering and leaving the system as their business dictate. This mandates a truly distributed system, not just a replicated database.


Realizing this distributed ledger vision requires technology choices that satisfy requirements for autonomy and dynamic membership. In DLT the choice of consensus has a dramatic effect on the system as a whole. Sawtooth employs an experimental consensus algorithm we call Proof of Elapsed Time, or PoET. It’s a form of random leader election, wherein each validator node waits a random amount of time before trying to claim a block. In other random leader election algorithms like Proof of Work, that randomness is enforced by searching for partial hash collisions. PoET replaces that work with trusted computing.

6-nantucket-300x96The benefit of this is a more economical and greener algorithm (as compared to ASIC mining rigs). Rather than chips churning on hash functions, the trusted computing functions allow each node to get on with other work until its timer expires, putting computing cycles into useful operations without wasted electricity. PoET is a return to the Satoshi intent of “one-CPU-one-vote”.

In its original form PoET exists near the unpermissioned end of the policy spectrum. Any host that can provide certain cryptographic proofs about the correctness of its execution can publish a block. The sawtooth-core maintainers have begun adding scaffolding to support the more direct authorization models that consortia may require. The first policies in this new framework include basic requirements of a validator such that it is running the correct version of the consensus algorithm and that it has a verifiably unique identity on the network (an anti-sybil feature of PoET). The network itself validates authorization of each node as it joins the system. Once validated, those nodes and their authorization data are committed to a table on the ledger, called the Validator Registry. Building on these new features, participants in a network can define arbitrarily elaborate (or simple) authorization policies. This authorization framework then lets the underlying PoET consensus algorithm be utilized across a wide swath of the public to private ledger spectrum.

Family Ties

Transaction Families are unique to Sawtooth Lake. Transaction logic is, of course, another area of intense exploration in DLT development. This logic is akin to the stored procedures your grandmother may have written for her old-fashioned steam-powered database. The two most pressing questions about this so called “smart contract” layer are (1) where is the proper architectural divide in data control logic versus application logic, and (2) how expressive should that layer be?opscode_head

With regard to expressiveness, Bitcoin started with too much power and has pared back over its evolution. Ethereum sought to provide more expressiveness but control it with economics. In both cases the appropriate divide between application logic and data control logic has been unclear and the allowed ledger operations have been exploited.

8-contrast-smartcontract-txnfamilies_conjoined-768x453Transaction Families create a smaller surface tailored for each domain.

Sawtooth Lake’s Transaction Family architecture is meant to address the questions of architectural boundaries and transaction expressiveness. Rather than trying to create a new language or define the perfect set of opcodes for all domains, Transaction Families decompose the logic problem by domain. If we tease apart the logic layer into two layers we get a set of rules for a domain and a composition layer for creating versatile transactions within that domain.

Transaction families are at once more powerful and more restrictive than other approaches of logic. Transaction Family code is deployed natively within the validator. That embedded validator code defines a data model and a set of updates associated with the model. The DApps (Distributed apps) author can then compose new transaction logic out of the available update methods. We intend that this be a more secure approach than providing all logic for all domains as a single interface to the ledger. Transaction families more tightly bound the code that must be vetted allowing for more tractable analysis. Consider if you will, how the complexity of the DAO code led to this summer’s Ethereum problems.


Sawtooth deployed with two transaction families: Trading and Authorization

Returning again to the consortium ledger, the consortium can define the extent of flexibility on the data model for the domain they participate in. Take for instance some recent work where Sawtooth Lake was used to prototype a bond and settlement market. For this prototype, a transaction family was created specifically to execute only the required bond settlement operations, eliminating the possibility of executing, unallowed, unnecessary, and illegal operations. The consortium can vet and approve a family before it is deployed to the network. The consortium participants can then still differentiate and establish competitive contracts with reduced risk that unwanted operations ensue.

Similarly domains often have services important to that domain which might be inappropriate or unnecessary in others. Again, in the case of bonds, a time service is important to address payment terms for maturity. The granularity of that time is probably coarser than a supply chain  domain focused on delivery of perishable goods like fish, or where the time source for that perishable good is provided by some external authority.

Finally there is a lot of energy surrounding private transactions. The Sawtooth-Core team is experimenting with private transactions using all the tools available including pure cryptographic techniques such as NIZK as well as trusted computing like Intel® SGX. This is an ill-defined space right now. It’s common to hear explicitly contradictory requirements like, the desire to discover assets on the ledger and settle the transfer of assets between parties while at the same time not listing the assets or parties on the ledger. Proposed solutions include recording only opaque identifiers for transactions but not the transactions or the assets themselves. A database that only has transaction IDs but no transactions or assets probably loses a lot of value. However, it’s possible that more interesting solutions exist using computationally expensive means like zero-knowledge relations or using trusted hardware with private enclaves.

Until next time…

I hope this has been an informative look into Sawtooth Lake. We are making a number of significant improvements at the time of this writing from our persistence mechanism up through transaction family API. Next time I’ll bring an update on those activities. Meanwhile you can find the work in progress in our github repo and docs. We are active on slack and there’s always someone around to help ramp a new contributor.


* Dan Middleton is an employee of IntelⓇ Corporation. The views expressed here are in the context of his role as an open source maintainer of Sawtooth Lake and do not necessarily represent those of IntelⓇ Corporation.

Hyperledger Welcomes Iroha

By Blog, Hyperledger Iroha


We’re pleased to announce that the distributed ledger project, Iroha, has been accepted into incubation status under Hyperledger. Originally developed by Hyperledger member company, Soramitsu, Iroha was inspired by the Fabric architecture and aims to provide a development environment where C++, web, and mobile application developers can contribute to the Hyperledger Project.

What is Iroha?

Iroha seeks to complement Fabric, Sawtooth Lake, and other potential projects, by creating reusable components in C++ that can be called from languages such as Go. In this way, Iroha is additive to existing projects and the long term goal is to realize a robust library of reusable components that can be selected and used freely by those running distributed ledgers on Hyperledger technology.

“Iroha allows even more developers to interact with Hyperledger to build infrastructural projects and applications requiring distributed ledger technology,” said Brian Behlendorf, Executive Director of Hyperledger. “It is encouraging to see member companies actively contributing to a diverse and sustainable open source blockchain ecosystem built on cooperation.”

The design and architecture of Iroha is greatly inspired by Fabric, in that blockchain and chaincode services form the overall architecture. Where possible, APIs were made to be similar to Fabric and, rather than competing with Fabric, the goals of Iroha are to:

  1. Provide an environment for C++ developers to contribute to Hyperledger
  2. Provide infrastructure for mobile and web application support
  3. Provide a framework to experiment with new APIs and consensus algorithms that could potentially be incorporated into Fabric in the future.

Why Iroha?

Currently, the Hyperledger Project lacks an infrastructure project written in C++, thus limiting the potential developers who can contribute. Also, there is not currently a strong focus on user interaction or mobile applications, though both are necessary for the realization of the widespread use of distributed ledger technology. Iroha aims to rectify both of these points, bringing in more developers while providing libraries for mobile user interface development.

Iroha is a distributed ledger project that was designed to be simple and easy to incorporate into infrastructural projects requiring distributed ledger technology. Iroha features:

  1. Simple construction
  2. Modern, domain-driven C++ design
  3. Emphasis on mobile application development
  4. New, chain-based Byzantine fault tolerant consensus algorithm, called Sumeragi

Although turing complete smart contracts are available via chaincode in Java (running a sandboxed JVM), users do not need to write chaincode in order to define digital assets in Iroha. Common use cases, such as deploying new currencies and sending text messages, are available as part of the core framework. Iroha is composed of the following:

  • Iroha core
  • Iroha Native iOS Library
  • Iroha JavaScript Library
  • Iroha Native Android Library

Iroha core provides the distributed ledger infrastructure comprising the data membership services, consensus algorithm, peer-to-peer network transmission, data validation, and chaincode infrastructure. The iOS, Android, and JavaScript libraries provide convenience functions for performing common operations, such as digitally signing transactions. Future work will expand these common functions to interoperate with the Fabric ledger.

Who will work on Iroha?

Soramitsu has committed several full time engineers to the project. Makoto Takemiya of Soramitsu is the initial project maintainer, along with six other engineers at Soramitsu. Besides Soramitsu, the co-sponsors of the proposal and other Hyperledger members are considering committing resources to work on Iroha including Toshiya Cho of Hitachi, Takahiro Inaba of NTT Data, and Mark Smargon of Colu.

Soramitsu is also doing collaborative research with The University of Tokyo, The University of Aizu, and Center for Global Communications (GLOCOM, below) of International University of Japan. From the University of Tokyo, Hideyuki Tanaka will consider economics use cases with Iroha. From The University of Aizu, Yasushi Fujii will explore business use cases with Iroha. From GLOCOM, Soichiro Takagi will consider economics and scientific research using Iroha.

“We’re pleased that Iroha has been accepted for incubation into  Hyperledger,” said Makoto Takemiya at Soramitsu. “By creating C++, mobile, and web development environments for Hyperledger, new developers can join the project and help contribute not only to Iroha, but to other sub projects, such as Fabric and Sawtooth Lake.”

Learn more about Iroha

Working with community members and use case partners, we would like to continue to improve upon Iroha and have it reach and active project stage in the future. The end goal is to realize a suite of components that can be freely interoperable with other Hyperledger projects.

The following repositories on github have been created to manage Iroha resources:


You can learn more about Iroha in this whitepaper or other incubation projects under Hyperledger here. Iroha documentation can be found at For those interested in additional information, please reach out to: