Category

Hyperledger Fabric

Hyperledger Global Forum: Takeaways from a local blockchain professional

By | Blog, Hyperledger Fabric

I’m very curious and I love to meet people from all over the world. I’m fascinated by new technologies, learning what can be done, seeing what has been done and realizing the potential.

Meeting like-minded, open people is the favorite way my team at 4eyes and I satisfy our curiosity. Learning from each other, sharing experiences and discussing problems and questions is the best way to achieve this.

Tangible results are sometimes difficult to see in software frameworks, and perhaps more so within the DLT/Blockchain space. However, they are very important to understanding the technology and its potential. So looking at projects in various stages from prototype to production is immensely helpful for us and, eventually, for our customers and partners.

With that in mind, we were excited to hear that the global Hyperledger community was getting together in Basel, about 15 minutes from our offices! While I already got an in-person impression of the Hyperledger Community at the Hackfest in Amsterdam and in my activities within the Special Interest Groups for the public sector, it was wonderful to have the whole Hyperledger Community as a guest in my hometown.

I’ve been to dozens of blockchain-related events this year with the Hyperledger Global Forum serving as the grand finale. In my opinion, it was by far the best experience as Hyperledger is the most inclusive, down-to-earth and also self-critical blockchain community. I remember Brian Behlendorf reminding people in a working group call of the importance of honest and transparent communication about Hyperledger as it’s crucial for the credibility and future development of Hyperledger. This spirit permeated the whole conference. While we know that Hyperledger has great frameworks and tools for a broad variety of real-life applications, as open-minded professionals we all realize that there is no one-size-fits-all holy grail kind of solution. This mindset leads to very constructive discussions about the different ways of solving a task.

To satisfy my curiosity, I attended a variety of workshops, especially for those Hyperledger frameworks that were still new to me. So, for example, I experienced Indy hands on in John Jordan’s workshop and learned to bring natural language legal contracts into the blockchain using Accord from Dan Selman. As sharing is a essential part of the learning experience, Waleed El Sayed and I talked about our experience developing blockchain-based projects using Fabric and Composer, which led to very interesting discussions with the audience and also during the rest of the conference. Apart from the inspiring keynotes ranging from consensus and application of blockchain in various industries to philosophy of trust, Global Forum was an opportunity to talk to the broad variety of companies showcasing their products and services.

In terms of my developer skills, the time I spent talking to Caroline Church, IBM’s Lead for Blockchain Tooling, was probably the most impactful. At Accenture’s Hack-For-Good hackathon towards the end of the Forum, Caroline showed us the new way of coding chaincode in Fabric 1.4 and, even more important, the Visual Code extension she created that allows for easy testing and debugging of chaincode. This is a huge step forward in terms of developing chaincode in Fabric. Caroline’s tools will immediately help my team and me and will increase 4eyes’ efficiency dramatically.

From my point of view as a consultant, I learned a lot from the presented use cases, such as the very interesting talk from Marco Alarcon and Andrés Falcone about the Short Sales Lending solution they’ve created at the Santiago Stock Exchange. I was also very impressed by David Berger’s very pragmatic solution to facilitating proof of existence for the legal industry.

As I love to spend time with people all over the world, I skipped one or the other presentation in favor for a in-depth conversations ranging from technical to conceptual during the forum and fun to philosophy during the delegates party at the fantastic Pantheon. This way I met amazing people from all over the world: Japan, France, USA, South Korea, Chile, Saudi Arabia, Canada, Switzerland, Russia, China and many more.

My experiences at the Hyperledger Global Forum helped me to assess the possibilities and the maturity of the framework and tools and inspired many new ideas, which in turn will help my team and me to provide better guidance and consultancy for clients and partners.

We are looking forward to the next opportunities to learn and share at upcoming Hyperledger events such as the Hackfest.

The whole 4eyes team and I would love to welcome the Hyperledger family back in Basel in 2019!

Links

Developer showcase series: John Greenhow, Peloton Blockchain

By | Blog, Developer Showcase, Hyperledger Composer, Hyperledger Fabric

Back to our Developer Showcase Series to learn what developers in the real world are doing with Hyperledger technologies. Next up is John Greenhow of Peloton Blockchain.

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

To anyone that wants to get started working on blockchain, my advice is to just start. As we set out, our team had to go through a headspace change similar to moving from assembly to object-oriented.

We picked a platform, picked a simple goal and ran through the installation and a test. More than once if necessary (I installed and setup Fabric twice). As soon as you physically can, look at the files on disk or in the database to see how they change – it will demystify things much more quickly.

We started off with Hyperledger Composer. This was a fantastic way in for us. It allowed us to model the business network we had envisioned and to write and test the necessary logic very quickly, all while going back to check bytes-on-disk to see how things worked under the hood.

My other piece of advice starts with an old saying, “when you’re holding a hammer, everything looks like a nail”. There will be use cases out there to which blockchain is not well suited as a solution, and that’s OK.  Spend time looking thinking about eco-systems and business networks and where the cost of a decentralized solution is really going to make a difference to everyone in the network.  It will pay off in the long run.

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?

Peloton Blockchain has developed software and a network for the tokenisation, issuance, discovery, listing, secondary trading and redemption of financial instruments and non-financial assets – in a way that is compliant with regulatory jurisdictions around the world.   

We can offer efficiencies in primary markets, new distribution channels for issuers and a whole new class of products for exchanges. We have 1 patent pending with 2 further patents in the pipe. Exciting times!

We’ve developed 3 products:

  • Issuer/Arranger System – this SaaS supports the tokenisation of products and publishing of new tokens or securities to a blockchain network; no development or scripting is required for new securities.
  • Blockchain Network – based on Hyperledger Fabric, this is a private, secure and scalable network designed to provide unparalleled breadth of distribution to issuers and lead arrangers; chain-code manages compliance and the full security lifecycle – we’ve built RESTful APIs to facilitate connectivity into crypto-exchanges and secure “nodes” for deployment.
  • Exchange System – an exchange trading platform designed for primary and secondary market trading of tokens and securities; we don’t (and won’t!) run a market ourselves, but we do provide the software and expertise if it’s needed to setup secondary markets.

Blockchain in general, and specifically Hyperledger Fabric, provided the best platform upon which we could build. The ability to deploy software to many different organizations and yet retain a trusted view of a ledger of security transactions and ownership opens a utopian vision for many in the capital markets. Blockchain is simply the perfect tool for this job.

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

We initially started on Composer and then moved to Fabric as we moved towards a production deployment model. We were sorry to leave Composer behind as it has so many great features – the modeling language and API generation chief among them.

Moving to Fabric involved a re-write into Golang, and we were really surprised by just how much code was needed to port what had been a fairly small project in Composer. I don’t say this to denigrate Fabric but to accentuate the power of Composer.

Our focus now is building out a production network. As well as deploying nodes to participating market operators, issuers and arrangers, we are hosting several nodes around the world to form a reliable back-bone to the network. To do this, we’ve utilized the AWS Elastic Kubernetes Service (EKS) and this has been a powerful tool in ensuring scalability.

We’re also looking ahead to production operations, and building web services and management consoles to automate and coordinate everything from upgrades to onboarding new network participants.

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

There are several routes available by which Hyperledger can continue to lower barriers to entry for new teams and projects. These include:

  1. A move to commoditization – installation, configuration and operation of databases, message buses, caches and many other complex software packages is out-of-the-box today. Experience in the field will contribute to incremental releases that continually shorten the time taken to be productive.
  2. Best of breed flagship – rolling together the (stable) killer features of different Hyperledger projects into a commodity enterprise project could reduce the risk stemming from dependency upon a single project and provide a single point of entry into the Hyperledger world for teams focused on solutions rather than platform evaluation. An example might include Fabric support for Composer models (or perhaps better, Composer cross-compilation to Fabric-ready Golang) packaged with Cello features pre-configured for particular use-cases.

Ongoing community out-reach, profile pieces and education remain invaluable and the more the better!

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

What really fascinates me about blockchain is that it rarely seems to be the most efficient or low-cost solution available. I’ve had endless conversations with technologists who see a simple, centralized solution as faster…easier…cheaper!

From the perspective of a single organization, this is true. Where the technology comes into its own is in making whole eco-systems of organizations more effective. Blockchain isn’t growing the one slice, it’s growing the whole damn pie.

How successful blockchain projects (in terms of adoption) are seems to depend on the benefits brought to all participants, rather than to a central orchestrator. To the central orchestrator, data is the new oil. Is that still the case if everyone has a copy of that data?

Seen through this filter, there is an implication of more broadly available efficiencies to many industries. This can only be good for economic growth in both developed and high potential markets.

Our project at Peloton Blockchain focuses directly on this, building highly connected networks of issuers, arrangers and exchanges to the benefit of all.

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

Ultimately blockchain is an application infrastructure layer, much like an RDBMS or messaging bus.

While there is (quite rightly) a lot of research and energy going into blockchain today, the hope is that the layer will become commoditized and that the focus will shift to the solutions that this enables for business networks.

Hyperledger already has projects that are well on the way to making this a reality and we’re really excited to see this continue.

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

Test your code!

Introducing Hyperledger Fabric 1.4 LTS!

By | Blog, Hyperledger Fabric

The pace of blockchain development and deployment is accelerating. Fortunately, so too is the scale and maturity of the community and technology at the core of Hyperledger Fabric. With an eye towards the growing rollout of production Fabric networks, we are pleased to introduce Fabric v1.4 LTS, our first long term support release.

The Fabric developers have been working with network operators and application developers to deliver v1.4 with a focus on production operations and developer ease of use. Key new production-focused features of Fabric fall into four key buckets:

  • Serviceability and Operations: As more Hyperledger Fabric networks get deployed and enter a production state, serviceability and operational aspects are critical. Fabric v1.4 takes a giant leap forward with logging improvements, health checks, and operational metrics. Along with a focus on stability and fixes, Fabric v1.4 is the recommended release for production operations. Future fixes will be delivered on the v1.4.x stream, while new features are being developed in the v2.0 stream.
  • Improved programming model for developing applications: Writing decentralized applications has just gotten easier. Programming model improvements in the Node.js SDK and Node.js chaincode makes the development of decentralized applications more intuitive, allowing you to focus on your application logic. The existing npm packages are still available for use, while the new npm packages provide a layer of abstraction to improve developer productivity and ease of use. We have also provided a comprehensive business scenario and tutorial to get you started with the new developer experience.
  • Enhanced data privacy: Data and transaction confidentiality has been a key driver for Fabric development since v1.2. With this new release, we have added two new enhancements: 1) peers for organizations that are added to private data collections can now retrieve the private data for prior transactions to which they now are entitled, and 2) automatically enforce access control within chaincode based on the client organization collection membership without having to write specific chaincode logic.
  • Hand-on tutorials: Commercially focused training to help developers move up the Fabric learning curve quickly and efficiently to speed adoption and deployment.

Complete details of the new features can be found in the What’s New documentation and release notes.

Hyperledger Fabric’s First Long Term Support Release.

As noted, Hyperledger Fabric v1.4 LTS marks our first long term support release. This is a critically important development for those beginning to deploy Hyperledger Fabric solutions into production and is a reflection of the confidence that the Fabric maintainers have in this latest release.

Our policy to date has been to provide bug fix (patch) releases for our most recent major or minor release until the next major or minor release has been published. We plan to continue this policy for subsequent releases. However, for Hyperledger Fabric v1.4 LTS, the Fabric maintainers are pledging to provide bug fixes for a period of one year from the date of release (Jan 10). This will likely result in a series of patch releases (v1.4.1, v1.4.2, …), where multiple fixes are bundled into a patch release.

If you are running with Hyperledger Fabric v1.4 LTS, you can be assured that you will be able to safely upgrade to any of the subsequent patch releases. In the advent that there is need of some upgrade process to remedy a defect, we will provide that process with the patch release.

If you’d like to join the community or learn more, you can find more information here:

Chat: #Fabric in Hyperledger Chat

Docs: Fabric 1.4 Documentation

Code: Fabric Github

Issues & Roadmap: Fabric JIRA

Website: Hyperledger Fabric Homepage

Thanks for reading about our newest Fabric release. We encourage developers to try these new features out and give us feedback!

Developer showcase series: Arielle Telesmanic, Scroll

By | Blog, Developer Showcase, Hyperledger Composer, Hyperledger Fabric

Back to our Developer Showcase Series to learn what developers in the real world are doing with Hyperledger technologies. Next up is Arielle Telesmanic of Scroll.

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

Blockchain is quite different from its centralized information system’s counterparts. It is very important to understand the fundamentals of Blockchain Technology and design a Blockchain ecosystem that is both cost effective and efficient to provide the favorable conditions needed to support industry migration or a public user base depending on intended use. Before getting to carried away at the drawing board learn about smart contracts, consensus models, blockchain states and the nature of the peer to peer distribution of data within a blockchain system. Ask yourself, “Can this scale? Is this a better alternative to traditional systems? What information do I need to record and how is this information being distilled to the right participants?

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?

Currently, I am working on the logistics and system design of three blockchain projects focused on ensuring data integrity in supply chains and streamlining data recovery in the advent of a data breach or leak. To complement the data recovery project, we are also developing a main net to strengthen the modularity and ease of use in migrating to a Blockchain. Our efforts include optimizing transaction speeds, side chain communication and a method to promote efficient change-management.

My interest in blockchain peaked as I noticed the advancements in quantum computing have been Signiant. Quantum computing’s ability to decrypt cryptosystems used in industry is concerning and there needs to be more development on quantum-resistant encryption and data verification/handling.

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

Currently, we are working with Hyperledger Fabric and Composer. Hyperledger’s framework uses chaincode which allows us to work with different states of the blockchain per transactions triggers by different applications. Out of the box, Hyperledger has promise in aiding the permissioned access to states of the ledger which is not typically supported in traditional Blockchain solutions. More information to follow on our integration efforts and contribution to the Hyperledger framework on Https://scroll.network

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?

Although Blockchain technology originated as a fintech solution, I am more interested in identity management and data quality assurance use cases (specifically data validity). The world is data-driven. Whether data is used to report manufacturing defects, drive patient care plans or execute a transaction that involves Personally Identifiable Information, it is of utmost importance that data is accurate.

All Are Welcome Here

By | Blog, Hyperledger Burrow, Hyperledger Fabric, Hyperledger Indy, Hyperledger Iroha, Hyperledger Sawtooth

A Minneapolis coffee shop that has fueled or at least caffeinated a lot of Hyperledger commits.

One of the first things people learn when coming to Hyperledger is that Hyperledger isn’t, like it’s name may imply, a ledger. It is a collection of blockchain technology projects. When we started out it was clear almost immediately that a single project could not satisfy the broad range of uses nor explore enough creative and useful approaches to fit those needs. Having a portfolio of projects, though, enables us to have the variety of ideas and contributors to become a strong open source community. Back in January of 2016 Sawtooth and Fabric were both on the horizon followed shortly by Iroha, but we wouldn’t have predicted that we would have Hyperledger Burrow and Hyperledger Indy – two projects that bear no resemblance to each other. Burrow is a permissioned Ethereum-based platform and Indy is a distributed identity ledger. Burrow is written in Go, and Indy was created in Python and is porting to Rust.

Both of these platforms are interesting in their own rights, but Hyperledger is even more interesting for the combination of these projects with the others. Both Sawtooth and Fabric have already integrated with Burrow’s EVM. Now Hyperledger has a set of offerings that can simultaneously satisfy diverse requirements for smart contract language, permissioning, and consensus. Likewise Sawtooth and Indy have been working together at our last several hackfests. The results of that may unlock new use cases and deployment architectures for distributed identity. So it’s not that our multiplicity of projects has given us strength through numbers, but rather strength through diversity.

Hyperledger Hackfest – December 2017 at The Underground Lisboa

The hackfests that we mentioned are one of the rare times that we get together face to face. Most of our collaboration is over mail list, chat, and pull-requests. When we do get together though it’s always in a new city with new faces. One of our most recent projects was hatched inside one of those buses. It wasn’t the most ergonomic meeting I’ve ever had but there was room for everyone on that bus.

Hyperledger Hackfest in Chicago

Our hackfest in Chicago was in a lot more conventional surroundings (still a very cool shared creative space .. lots of lab equipment and benches out of view on the other side of the wall to the right). Looking back at this photo is fun for me. I can see a lot of separate conversations happening at each table… people sharing different ideas, helping ramp new contributors, working on advancing new concepts with existing contributors. I can see a lot of similarity but also a little variety. It’s a busy room but there’s still open chairs and room for more variety.

Our next hackfest won’t be until March 2019 (Hyperledger is hosting Hyperledger Global Forum in December in Basel though). The March hackfest will be somewhere in Asia – location to be settled soon. The dates and locations of the other 2019 hackfests aren’t set yet. I don’t know where they will be specifically, but I do know that there will be a seat available and you will be welcome there.

These face to face meetings really are more the exception than the rule at Hyperledger. There are now more than 780 contributors spread all across the globe. 165 of those were just in the last few months. That means that every day we have a new person contributing to Hyperledger. Most of our engagement is through the development process. People contribute bug fixes, write new documentation, develop new features, file bugs, etc. If you’ve never contributed open source code before getting started might be intimidating. We don’t want it to be, though. There are a number of resources to help you get started. You can watch this quick video from Community Architect, Tracy Kuhrt. There’s documentation for each project, mail lists, a chat server, working groups, and some of the projects even host weekly phone calls to help new developers get engaged. Everyone in Hyperledger abides by a Code of Conduct so you can feel comfortable knowing that when you join any of those forums you will be treated respectfully. Anyone who wants to get involved can regardless of “physical appearance, race, ethnic origin, genetic differences, national or social origin, name, religion, gender, sexual orientation, family or health situation, pregnancy, disability, age, education, wealth, domicile, political view, morals, employment, or union activity.” We know that to get the best ideas, best code, best user experience we need your involvement. Please come join our community.

Image created by https://allarewelcomehere.us/ for Hyperledger

As always, you can keep up with what’s new with Hyperledger on Twitter or email us with any questions: info@hyperledger.org.

Five Hyperledger Blockchain Projects Now in Production

By | Blog, Hyperledger Fabric, Hyperledger Indy

IT leaders have been hearing a lot about blockchain and its potential in the enterprise for the last few years, but until now they may not have heard much about how it is actually being used today for real-world business processes inside and between enterprises. So, we compiled this list of five intriguing, Hyperledger blockchain initiatives that are in production today across a wide range of industries, including food supply, fine art, insurance, aviation and accounting.

  1. Food source tracking using blockchain

Ensuring the safety and quality of a vast portion of the nation’s food supply is a huge undertaking, especially since incidents have occurred over the last several decades in which consumers have become sickened or died after eating tainted foods. IBM Food Trust is powered by Hyperledger Fabric to create unprecedented visibility and accountability in the food supply chain. It is the only network of its kind, connecting growers, processors, distributors, and retailers through a permissioned, permanent and shared record of food system data.

The IBM Food Trust network represents the continuation of more than a year of pilot tests with major retailers and food suppliers, including Golden State Foods, McCormick and Co., Nestlé, Tyson Foods and Wal-Mart Stores Inc. These companies formed a consortium in collaboration with IBM to use its food safety blockchain in order to protect consumers and enhance trust the food supply.

The solution provides authorized users with immediate access to actionable food supply chain data, from farm to store and ultimately the consumer. The complete history and current location of any individual food item, as well as accompanying information such as certifications, test data and temperature data, are readily available in seconds once uploaded onto the blockchain. Learn more here.

2. Blockchain for the airline industry

To help airlines improve passenger ticketing processes, NIIT Technologies developed its new Chain-m blockchain application using Hyperledger Fabric that can report on a wide range of critical information, from the number of tickets sold to fare amounts, commissions, taxes collected and more. Using a web-based interface, Chain-m adds transparency to ticketing processes, which is expected to help improve record-keeping, save money and improve security and agility in a complex business.

3. Follow the trail of Cambio Coffee with blockchain

Direct trade organic coffee seller Cambio Coffee provides a clear, traceable supply chain path for its products–from harvesting to roasting, packaging, and shipping–so customers could learn the exact details of what they are buying and drinking. To do that, the company began adding QR scan codes from ScanTrust to its coffee packaging, which when scanned records those details onto a Hyperledger Sawtooth blockchain network. Tying the QR codes together with the blockchain data lets coffee buyers scan the codes to see exactly where their coffee originated and how it arrived to their local store and into their grocery carts. The idea, according to Cambio Coffee, was to give its customers trust in its products and to provide transparency and traceability throughout their journey to customers. Watch the webinar here to learn more.

4. Blockchain for better enterprise operations management

China’s largest retailer, JD.com, offers its own JD Blockchain Open Platform to help enterprise customers streamline a wide range of operational procedures by creating, hosting and using their own blockchain applications. The platform uses Hyperledger Fabric and is an expansion of the company’s Retail-as-a-Service strategy, which offers some of its own internal initiatives to other companies as a service. The China Pacific Insurance Company is using the platform to deploy a traceable system for e-invoices, which are official receipts required in China for business. The system strengthens the security governance of e-invoices by applying unique blockchain IDs to each document, increasing efficiency and streamlining the accounting process, according to the company.

The platform allows users to create and update smart contracts on public and private enterprise clouds, while also enabling companies to streamline operational procedures such as tracking and tracing the movement of goods, charity donations, authenticity certification, property assessment, transaction settlements, digital copyrights and more.

5. Blockchain for insurance compliance data

Insurance companies are required to regularly report a significant amount of regulatory data that is subject to a wide range of compliance requirements and must be shared securely with regulators. The American Association of Insurance Services, a not-for-profit insurance advisory organization, has developed openIDL (open Insurance Data Link), which is designed to automate insurance regulatory reporting. Built on IBM Blockchain thus powered by Hyperledger Fabric, openIDL can help streamline regulatory and compliance requirements while improving efficiency and accuracy for both insurers and state insurance departments. The openIDL is the first open blockchain platform focused on the collection and sharing of statistical data between insurance carriers and regulators, according to the group. Using this blockchain network, insurers can contribute data directly onto the secure platform, which satisfies state regulatory requirements, while historical and current data is stored on an immutable blockchain ledger. Regulators are then provided permissioned access to view only the information they need to see for compliance purposes.

If you’re interested in learning about other ways Hyperledger technologies are used today to solve interesting problems, you can read through our case studies and/or visit the Blockchain Showcase.

Conducting Data with Concerto and Hyperledger Fabric

By | Blog, Hyperledger Composer, Hyperledger Fabric

 

Guest post: Dan Selman, Maintainer Hyperledger Composer, Accord Project Cicero, CTO Clause Inc.

 

Is the business logic in your blockchain chaincode hard to find because it is buried in code that is doing JSON serialization and data validation? Are you developing REST APIs by hand for your domain model? The good news is that there is now a better way!

In this article for developers and blockchain solution architects, I introduce the Concerto npm module and show you how you can use it from Hyperledger Fabric v1.3 Node.js chaincode.

Concerto is a lightweight, 100% JavaScript schema language and runtime. It works in both a Node.js process or in your browser. The browserified version of Concerto is ±280 KB and the maintainers are working to make it even smaller.

Concerto has recently been modularized and moved out of Hyperledger Composer into the composer-concerto npm module, so you can use it in your Node.js applications,  Fabric Node.js chaincode or even in your web browser!

Things you can do using Concerto:

  • Define an object-oriented model using a domain-specific language that is much easier to read and write than JSON/XML Schema, XMI or equivalents. The metamodel gives you “just enough” expressivity to capture real-world business models, while remaining easy to map to most runtime environments.
  • Optionally edit your models using a powerful VS Code add-on with syntax highlighting and validation
  • Create runtime instances of your model
  • Serialize your instances to JSON
  • Deserialize (and optionally validate) instances from JSON
  • Introspect the model using a powerful set of APIs
  • Convert the model to other formats including JSON Schema, XML Schema, Java, Go, Typescript, Loopback, PlantUML…
  • Generate dynamic web-forms from your data model and bind them to JSON data
  • Import models from URLs
  • Publish your reusable models to any website, including the Accord Project Open Source model repository, hosted at: https://models.accordproject.org

Sidebar: Why Use Models?

All software applications have a data or domain model.

Models are required to create generic tools because you need to reason about the structure of user-defined domain models. As soon as you want to implement something like an Object-Relational-Mapper or REST API browser or web-form generator, you need a data model.

The data model for your application can either be implicit (duck typing…) or explicit. If it is explicit, it can be expressed using a wide range of technology including XML Schema, JSON Schema, protobufs, NoSQL design documents, Loopback schema, Java classes, Go structs, RDBMS tables, ad-hoc JSON or YAML documents…the list is almost endless.

These different model representations make different trade-offs with respect to:

  • Integration with computation
  • Optimization of serialization/wire format
  • Cross-platform usage
  • Industry acceptance
  • Human readability and editability
  • Expressiveness of the metamodel
  • Composability and reuse

If developers define models as part of application development, they tend to favour creating Java classes, Go structs, Typescript or similar, because they want to express the model in a language they are familiar with and that integrates closely with the type-system used for computation. The major downside with this approach is that it is almost impossible to then share and reuse these models outside of a single application. It also doesn’t integrate well with modern application development, where we may use different technology across the web, mobile, middle and backend tiers of an application. Out of sync models (or model mapping) is a huge source of anguish and bugs.

When industry-standard bodies define models, they tend to favour representations that are more cross-platform and less tied to computation, such as publishing XML Schemas. Developers tend not to like using these models because the mapping from things like XML Schema to Java classes or Go structs for use at runtime is lossy/messy/complex.

Concerto solves many of these problems by providing an Object-Oriented schema language that allows models to be moved outside of applications while mapping quite naturally to most common programming languages. We like to think of it as a “goldilocks” approach to modeling, “just enough” to cover most business use cases, with a natural mapping to most common programming languages, and with a JSON serialization.

An example

I’ve published a detailed code sample for Node.js chaincode and a HLF v1.3 client so you can start to experiment with using Concerto in HLF v1.3 Node.js chaincode: https://github.com/clauseHQ/fabric-samples/blob/master/concerto/README.md

The sample shows you how to deploy Concerto models to the blockchain and then use the models to validate instances and to serialize them to JSON for long-lived persistence.

Editing a Concerto model using the Concerto Form Generator

 

The sample defines a simple Concerto domain model for an employee, which is deployed to the blockchain.
Here is the definition of the Concerto model:

namespace io.clause

enum Gender {

  o MALE

  o FEMALE

  o OTHER

}

asset Employee identified by email {

  o String email

  o String firstName

  o String lastName

  o String middleName optional

  o Gender gender

  o DateTime startDate

  o DateTime terminationDate optional

}

The sample then uses the model to validate instances and to serialize them to JSON for long-lived persistence on the blockchain.

A React form, dynamically generated from the Concerto model

First the client creates a valid instance of an employee, and the chaincode validates it and stores it on the blockchain:

{ 

$class : 'io.clause.Employee',

email : 'bob@clause.io',

firstName: 'Bob',

lastName: 'Concerto',

gender: 'MALE',

startDate : Date.now()

}

When the client attempts to create an instance that is missing the required firstName field:

{

$class : 'io.clause.Employee',

email : 'bob@clause.io',

lastName: 'Concerto',

gender: 'MALE',

startDate : Date.now()

}

The instance fails validation, and the chaincode refuses to create the instance:

ValidationException: Instance io.clause.Employee#bob@clause.io missing required field firstName

What’s next?

We’ve just scratched the surface of what you can do with Concerto. The metamodel is flexible enough to capture almost any business domain model.

Here are some ideas for what to do next:

  • Generate Java, Go, XML Schema or Typescript code from your Concerto models, ensuring that other parts of your application infrastructure are all in sync with your canonical Concerto model. For any Open Source models that have been published to https://models.accordproject.org you can download these directly from the webpage.
  • Embed the Concerto Form Generator into your web application to dynamically generate web forms based on Concerto models.
  • Generate a Loopback schema from your Concerto model, and then use the Loopback framework to expose your modelled assets as a REST API.
  • Import types from the Open Source Accord Project Model Repository into your models: https://models.accordproject.org or publish your models to the Model Repository, or to any HTTP(S) site for import and reuse by others.
  • You can even write Accord Project legal contracts and type-safe Ergo logic over the types you’ve modelled. That’s an article for another day, however!

Get Involved!

If you are using Concerto already or would like to get involved with improving it further, please don’t hesitate to get in touch. In the true spirit of Open Source we welcome all contributions.

 

The journey to becoming a Hyperledger contributor

By | Blog, Hyperledger Burrow, Hyperledger Fabric

Guest Post: Av Lakshmy

I am an undergraduate student in the Department of Computer Science and Engineering at the Indian Institute of Technology Madras (IIT Madras), India. This summer, I had a wonderful opportunity to intern at Hyperledger. I worked on a module related to the integration of Burrow EVM into Hyperledger Fabric, specifically integrating Ethereum events into Fabric, under my mentors, Swetha Mam and Jay Sir.

Before this internship, I had very little knowledge of blockchains. Moreover, this was my first experience with open-source development. But, over the course of the internship, I have learnt a lot! Let me share with you my journey over the past few months: how I learnt about blockchain frameworks, became familiar with the Hyperledger development process, and submitted my first patch using Git. I would also like to share some of the key lessons I learnt along the way.

Most people who are new to open source development may find it a bit difficult to get started, since there are no clearly-defined instructions or hard deadlines. Indeed, open source development is more self-driven but is a joy once we get used to it! Let me outline the steps involved in contributing to open source code, especially for Hyperledger projects.

The first and most important step in open source development is identifying the area where we want to contribute. Fortunately for me, this was taken care of by my mentors. This is the first lesson I learnt. Like many other endeavours in life, once we have a mentor, things become much easier. Of course, as we understand the project more and more, we can ourselves develop a better idea of where we can contribute.

Prior knowledge of the programming language involved in the project is desirable but not essential. We can always learn the language while writing the code. This brings us to another important lesson I learnt. Lack of proficiency in the language being used should not be a mental block while volunteering for an open source project. Most of the Fabric code is in Golang, which I had never worked with so I had some apprehensions. But, within a few days, my confidence increased, and by the time I finished the internship, I had become reasonably proficient in Golang.

Another lesson I learnt is that, besides the specific module on which we are working, we must also have a broad awareness of related modules, so that we have a holistic understanding of the project. For this, we must go through the documentation on the project, and do some background reading. I spent the first three weeks of the 12-week internship just studying about blockchains, and the three main platforms involved in my project, namely Hyperledger Fabric, Hyperledger Burrow and Ethereum.

The next lesson I learnt is that, we have to carefully set up our development environment to ensure that all the versions of the different softwares and tools downloaded are compatible. Otherwise, we may face problems later on. This is the phase where we may have a lot of questions and doubts, since the environment on each developer’s machine will be different. The documentation usually does not have the answers to all these questions. Online discussion forums can come in handy here; we can learn from others who have also faced similar issues. Posting doubts on the Hyperledger mailing lists, or in the Rocket Chat channels also helps. In my case, my mentors were very patient and helpful, and they clarified almost all my doubts.

The next step is to delve deep into the specific module we will be working on. We can’t rely on the documentation to guide us here. This is where my mentors gave me an important insight. The best place to understand more about the project is by going through the source code itself. I learnt the importance of going through the source code of vast projects like Fabric and Burrow in a systematic way. I learnt how to track the code flow, starting from an entry point, and tracing the flow of data through several function calls, until the exit point. This gave me a better picture of what is already in place, and where exactly I would have to add my code.

The internship also taught me the importance of test-driven development. The conventional way of software development is to write the code and then test it. But, while implementing large complex software projects, which should work in various scenarios, this method is not recommended. A better method is test-driven development (TDD), where we start with test cases and incrementally build the actual code. As we keep building the code, we can keep adding more complicated test cases to check how well the code works. The rationale behind TDD is that, if a particular test case doesn’t pass, we will know exactly where our code went wrong. This is a much more reliable and convenient way of improving the code. TDD is ideal for open source development where many people are involved. TDD makes it easy for the next contributor to pick up from where we have left because the test cases already being used will indicate the scenarios that have already been dealt with. In my case, we made use of Go testing frameworks like Ginkgo and Gomega to write our test-suites.

The essence of an open source project is the coordination and synchronization of many contributors,working on the code simultaneously. This is where a powerful version control tool like Git comes into the picture.  Once I had written some code for my project, it was time for me to push up a patch. For this, I became familiar with the process of pushing up a Git commit, thereby submitting the code for review. The process of review is iterative and continues till the reviewers find the code good enough to be merged into the repository.

Looking back, my internship project of integrating Ethereum events into Fabric was a rewarding and enriching experience! In the first few weeks, I wrote some simple test cases (using TDD) for the main piece of the project, the chaincode evmcc.go. When my patch passed through the review process and finally got merged into the repository, I was elated! I also wrote code for an event manager module to be integrated with the evmcc.go chaincode. These pieces are still under review and will hopefully be merged soon. I am thrilled that my work will eventually be included in the source code of a prestigious project like Fabric!

I hope this article will motivate people to start contributing to open source projects in general, and Hyperledger in particular.

How to deploy Hyperledger Fabric on Kubernetes Part II

By | Blog, Hyperledger Fabric

We recently hosted a webinar about deploying Hyperledger Fabric on Kubernetes. It was taught by Alejandro (Sasha) Vicente Grabovetsky and Nicola Paoli from AID:Tech.

The webinar contained a detailed, step-by-step instruction showing exactly how to deploy Hyperledger Fabric on Kubernetes. For those who prefer reading to watching, we have prepared a condensed transcript with screenshots that will take you through the process that has been adapted to recent updates in the Helm charts for the Orderers and Peers.

Are you ready? Let’s dive in!

What we will build

  • Fabric CA

First, we will deploy a Fabric Certificate Authority (CA) serviced by a PostgreSQL database for managing identities.

  • Fabric Orderer

Then, we will deploy an ordering service of several Fabric ordering nodes communicating and establishing consensus over an Apache Kafka cluster. The Fabric Ordering service provides consensus for development (solo) and production (Kafka) networks.

  • Fabric Peer

Finally, we will deploy several Peers and connect them with a channel. We will bind them to a CouchDB database.

What you’ll need

You will need 3 things to get started:

  1. A running Kubernetes cluster.

You can get a free managed cluster from most cloud providers; many give generous free credits.

  1. A domain name for your cluster.

Just get a free or cheap one.

  1. The repository prepared for this webinar.

Download it at https://github.com/aidtechnology/lf-k8s-hlf-webinar.

Once you have a cluster, install an Ingress controller. In this case, we use NGINX.

You’ll also install a certificate manager, which will renew the Tiller certificates to access your sub-domains by using a service called Let’s Encrypt.

DEPLOYING HYPERLEDGER FABRIC ON K8S

Let’s get the party started!

The deployment has three key parts:

  • Fabric CA

Fabric Certificate Authority registration & enrolls identities

  • Fabric Orderer

Fabric Ordering service provides consensus for development (solo) and production (Kafka) networks.

  • Fabric Peer

Fabric Peer maintains the blockchain by communicating with the Ordering service.

Let’s go through these one by one.

  • Fabric CA

To install Fabric CA, you’ll need to follow these steps:

  • Install Fabric CA Helm Chart
  • Generate Fabric CA Identity
  • Obtain Crypto Material
  • Save Crypto Material to K8S
  • Generate Genesis and Channel

Let us go through them one by one.

  • Install Fabric CA Helm Chart

Let’s install the actual Fabric CA Chart. We can run the command Kubectl get pods to get the actual Pod running the CA. And then, run kubectl logs, to check if the CA server has started running.

helm install stable/hlf-ca -n ca –namespace blockchain -f./helm_values/ca_values.yaml

CA_POD=$(kubectl get pods -n blockchain -l “app=hlfca,release=ca” -ojsonpath=”{.items[0].metadata.name}”)

kubectl logs -n blockchain $CA_POD | grep ‘Listening on’

The values file for the CA is rather more involved.

First, we define the image tag where we use Fabric 1.2. We also implement an Ingress. This is basically a way for you to access the Certificate Authority from outside the Kubernetes cluster. In the webinar, they used a test domain that they owned to enable access to the CA.

We again implement persistence to store the certificates permanently, so we don’t lose them if the POD restarts. We also specify a name for our Certificate Authority, which in this case is CA, and also specify the PostgreSQL dependency, so that our CA chart knows to create the database chart.

Then, we define some configuration, such as the Hyperledger tools version we use, which customizes one of the config maps in the chart. A config map is a Kubernetes abstraction that stores some values that are made available to the POD.

Importantly, we also specify the Certificate Signing request and an affiliation list, which in this case, is empty.

And finally, we again add a Pod affinity. In this case, we make sure that our Fabric CA server gets deployed to the same Kubernetes machine as our PostgreSQL server.


 

  • Generate Fabric CA Identity

Once our CA is running, we will need to enroll the identity of the Fabric CA itself. For the first command, we use kubectl exec to check if a certificate exists in the Fabric CA membership service provider folder.

If it does not, we will run the Fabric CA client enroll command inside the CA, pointing to the Ingress of the CA. Then, we can run Kubectl get ingress on our own machine to obtain the Ingress connected to the Fabric CA service. So, this will essentially be the domain name that we spoke about.

Once you have that set up, you should be able to use the curl command to get the CA info. Bear in mind that this depends on the Certificate Manager setting up the TLS correctly, so you might need to wait for a little while before this works.

kubectl exec -n blockchain $CA_POD — cat/var/hyperledger/fabric-ca/msp/signcerts/cert.pem

kubectl exec -n blockchain $CA_POD — bash -c ‘fabric-ca-client

enroll -d -uhttp://$CA_ADMIN:$CA_PASSWORD@$SERVICE_DNS:7054′

CA_INGRESS=$(kubectl get ingress -n blockchain -l “app=hlfca,release=ca” -ojsonpath=”{.items[0].spec.rules[0].host}”)

curl https://$CA_INGRESS/cainfo

  • Obtain Crypto Material

Now that your CA is installed and set up, you can give the certificate or the CA server to your own machine, by using the Fabric CA Client binary. If you’re using a Mac, you can for example use Homebrew to install it.

Then, you can use Kubectl exec to execute the register command inside the Fabric CA, to register the organization we will use to host the Orderers and the Peers.

Once we have registered the identity, we can use the Fabric CA client again and actually enroll the identity and get our private key and our certificate. We’ll copy the certificate from signcerts also into the admincerts folder, since this identity is the admin.

FABRIC_CA_CLIENT_HOME=./config fabric-ca-client getcacert -uhttp://$CA_INGRESS -M ./AidTechMSP

kubectl exec -n blockchain $CA_POD fabric-ca-client register –id.name org-admin –id.secret OrgAdm1nPW –id.attrs ‘admin=true:ecert’

FABRIC_CA_CLIENT_HOME=./config fabric-ca-client enroll -uhttp://org-admin:OrgAdm1nPW@$CA_INGRESS -M ./AidTechMSP

mkdir -p ./config/AidTechMSP/admincerts

cp ./config/AidTechMSP/signcerts/* ./config/AidTechMSP/admincerts

  • Save Crypto Material to K8S

Notice that when speaking with configure CA, we need to specify the lets encrypt authority’s certificate for the TLS connection, because the Fabric CA client will check that the certificate corresponds to the one it sees when connecting to the CA server. So, since our apps will use the certificate and the key, we need to use a kubectl create secret generic to add this file to the Kubernetes service as secret:

ORG_CERT=$(ls ./config/AidTechMSP/admincerts/cert.pem)

kubectl create secret generic -n blockchain hlf–org-admincert–from-file=cert.pem=$ORG_CERT

ORG_KEY=$(ls ./config/AidTechMSP/keystore/*_sk)

kubectl create secret generic -n blockchain hlf–org-adminkey–from-file=key.pem=$ORG_KEY

CA_CERT =$(ls ./config/AidTechMSP/cacert/*.pem)

kubectl create secret generic -n blockchain hlf–ca-cert–from-file=cert.pem=$CA_CERT

  • Generate Genesis and Channel

Now we can run the config X Gen2. We use it twice, in the two profiles we defined to produce a genesis block for the orderers and the chain of transactions for the peers. So we have these two Kubernetes secrets to store them on our cluster. These secrets will act like the config maps that we defined before: they will act as obstructions that will hold values. But they will encrypt them at the same time and hold them in a secure manner.

cd ./config

configtxgen -profile OrdererGenesis -outputBlock ./genesis.block

configtxgen -profile MyChannel -channelID mychannel -outputCreateChannelTx ./mychannel.tx

kubectl create secret generic -n blockchain hlf–genesis –fromfile=genesis.block

kubectl create secret generic -n blockchain hlf–channel –fromfile=mychannel.tx

  • Fabric Orderer

Now that we have a functioning Fabric CA, we can get to the Orderer. We will need to follow three steps to get this running.

  • Install Kafka Helm Chart
  • Setup Orderer Identity
  • Save Orderer crypto-material to Kubernetes
  • Install Fabric Orderer Helm Chart

Let’s go through them one by one:

  • Install Kafka Helm Chart

First, we need to install the Kafka cluster itself, which is made easy with an incubator chart available:

helm install incubator/kafka -n kafka-hlf –namespace blockchain -f ./helm_values/kafkahlf_values.yaml

Note that you need some very specific configuration to make this work correctly.

First, we need to ensure we have at least four replicas of Kafka, in order to make it properly crash-tolerant. This means that your Kubernetes cluster must be composed of at least four machines. We also specify, again, the image and the tag that we want to use. In this case, we use the confluentinc.cv.kafka image and the tag 4.112. And we also add role-based access control to our Kubernetes cluster.

Again, we have anti-affinities to make sure that the Kafka pods actually end up on different Kubernetes machines, because otherwise, several of your Kafka pods could end up on one machine, and then one single machine crashing could actually get your network down.

And here is the most important part. The configuration overrides section contains several options that are necessary to work with Fabric. All these options are necessary but the most important one is the last one, called log.retention.ms which specifies that we never want to forget a record, because by default, Kafka will forget records after typically around two weeks. This is a common mistake.

 

  • Set up Orderer Identity

Now, we can set up the Orderer Identity. We first use kubectl exec to connect to the fabric-ca and register the identity of the order with a CA. We then enroll the Orderer and obtain the cryptographic materials, which will identify the orderer. In this case, we specify a dummy password “ord${NUM}_pw”, but in a real deployment you should use a complex (e.g. alphanumeric of length at least 12) string instead.

Here we work with the first orderer, if you want to install the second one, just change the initial export to set the NUM to 2.

export NUM=1

kubectl exec $CA_POD -n blockchain  — fabric-ca-client register –id.name ord${NUM} –id.secret ord${NUM}_pw –id.type orderer

FABRIC_CA_CLIENT_HOME=./config fabric-ca-client enroll -d -u https://ord${NUM}:ord${NUM}_pw@$CA_INGRESS -M ord${NUM}_MSP

  • Save Orderer crypto-material to Kubernetes

Having created the crypto-material for the Orderer, we can save it to Kubernetes, so that we can utilise it when we launch the appropriate Helm chart. Below we show how to save the certificate and key of the Orderer.

NODE_CERT=$(ls ./config/ord_${NUM}_MSP/signcerts/*.pem)

kubectl create secret generic -n blockchain hlf–ord${NUM}-idcert –from-file=cert.pem=$NODE_CERT

NODE_KEY=$(ls ./config/ord_${NUM}_MSP/keystore/*_sk)

kubectl create secret generic -n blockchain hlf–ord${NUM}-idkey –from-file=key.pem=$NODE_KEY

  • Install Fabric Orderer Helm Chart

Now we can install the actual orderers and check that they have been correctly initialised.helm install stable/hlf-ord -n ord${NUM} –namespace blockchain -f./helm_values/ord${NUM}_values.yaml

ORD_POD=$(kubectl get pods -n blockchain -l “app=hlf-ord,release=ord${NUM}” -o jsonpath=”{.items[0].metadata.name}”)

kubectl logs -n blockchain $ORD_POD | grep ‘completeInitialization’

We also specified the consensus type, Kafka, and the ID of the organization membership service provider (in our case, it’s AidTechMSP). Finally, we specify a set of secrets that we will need to correctly connect to the Certificate of Authority, such as the caServerTls secret, the genesis block secret which in this case is called hlf–genesis, and the admin certificate for the organization.

We can then get the orderer Pod using kubectrl get pods and check that the order has started by running kubectl logs and filtering for the string completeInitialization. And that’s it, you have a basic ordering service, using Kafka.

 

  • Fabric Peer

It is finally time to install Fabric Peer, which maintains the blockchain ledger. It involves several steps, most of which should look familiar by now:

  • Install CouchDB Helm Chart
  • Set up Peer Identity
  • Save Peer crypto-material to Kubernetes
  • Install Fabric Peer Helm Chart
  • Create Channel
  • Fetch and Join Channel

Let us go through them one by one.

  • Install CouchDB Helm Chart

The first step is to install the CouchDB database. It is similar to installing the PostgreSQL chart. Once you’ve deployed it, use the Kubernetes logs to check if it is running.

The values file in this case is really simple. It specifies the version of the Hyperledger carsDB, which in this case is 0.4.10. We also again specify a persistence, so that the couchDB database holds the data and an anti-affinity so that couchDB pods are deployed on different Kubernetes machines.

  • Set up Peer Identity

To set up the peer identity we get the CA_PASSWORD, which again is a one-time password generated automatically by the chart, and we register the peer with the certificate authority just like we did with the orderer, we just specify a different ID type, in this case we specify a peer. Again, the peer will periodically try to enroll with the CA until it succeeds. Once it does you will see the strings start to appear in the logs.

kubectl exec $CA_POD -n blockchain  — fabric-ca-client register –id.name peer${NUM} –id.secret peer${NUM}_pw –id.type peer

FABRIC_CA_CLIENT_HOME=./config fabric-ca-client enroll -d -u https://peer${NUM}:peer${NUM}_pw@$CA_INGRESS -M peer${NUM}_MSP

  • Save Peer crypto-material to Kubernetes

Just as with the Orderer, we save the crypto-material for the Pee to Kubernetes. Again, we save the certificate and key of the Peer.

NODE_CERT=$(ls ./config/peer_${NUM}_MSP/signcerts/*.pem)

kubectl create secret generic -n blockchain hlf–peer${NUM}-idcert –from-file=cert.pem=$NODE_CERT

NODE_KEY=$(ls ./config/peer_${NUM}_MSP/keystore/*_sk)

kubectl create secret generic -n blockchain hlf–peer${NUM}-idkey –from-file=key.pem=$NODE_KEY

  • Install Fabric Peer Helm Chart

Now let’s install the Fabric Peer Helm Chart.

helm install stable/hlf-peer -n peer${NUM} –namespace blockchain -f ./helm_values/peer${NUM}_values.yaml

PEER_POD=$(kubectl get pods -n blockchain -l “app=hlf-peer,release=peer${NUM}” -o jsonpath=”{.items[0].metadata.name}”)

kubectl logs -n blockchain $PEER_POD | grep ‘Starting peer

The values file looks very similar to the orderer values, since it mentions the ‘fabric-ca’ address and the peer username on the certificate authority. It also specifies that we are using CouchDB and the name of the CouchDB Helm deployment. Again, we note the secrets that we need such as the ca-TLS secret which we need to communicate securely, the channel secret specifying the channel transaction that will allow the peer to create and join channels, and the organization admin certificate key which is also necessary to join the channel to ask permission to network.

 

  • Create Channel

Once the first peer has been created, you can create the channel. For this, you will need to specify the address of the orderer, the name of the channel, and the location of the channeled transaction.

kubectl exec -n blockchain $PEER_POD peer channel create -o ord1-hlford.

blockchain.svc.cluster.local:7050 -c mychannel -f/hl_config/channel/mychannel.tx

  • Fetch and Join Channel

Once the channel is created, you will need to fetch it and join it on every peer that you create. You can do this by running the peer channel fetch config command inside the Peer. And then run the peer channel join inside each peer container as well. Once all of that is done, you can run peer channel list to check that the peer has indeed joined the channel.

kubectl exec -n blockchain $PEER_POD peer channel fetch

config /var/hyperledger/mychannel.block -c mychannel -o ord1-hlford.blockchain.svc.cluster.local:7050

kubectl exec -n blockchain $PEER_POD — bash -c

CORE_PEER_MSPCONFIGPATH=$ADMIN_MSP_PATH

peer channel join -b /var/hyperledger/mychannel.block

kubectl exec -n blockchain $PEER_POD peer channel list

And that’s it! If you followed along with all the steps, you should have successfully deployed Hyperledger Fabric on Kubernetes!

Watch the replay of the webinar here, or download slides and other resources on the same page. You can also head straight to the Github repository set up for the webinar.

 

Hyperledger Fabric Now Supports Ethereum

By | Blog, Hyperledger Fabric

Guest post: Swetha Repakula of IBM 

At this point, there are few that haven’t heard the word blockchain. Despite all the buzz and hype around the technology, the learning curve is steep. When we meet people new to the technology, we like to break down blockchain into four main parts:

  1. The ledger technology: How is the data stored? Data could be many things such as the transaction log, or just the current state of the world. Each node could use its own database, and the database need not be the same across all the nodes in the network.
  2. The consensus mechanism: How are all the participants coming to agreement about the block ordering and current state?
  3. Membership Services: How is identity managed and who is allowed into the network?
  4. Smart Contract Runtime or Application: What smart contracts can I deploy or what kind of application is this?

We believe most blockchain technologies can be separated into four parts and that developers/consumers should have the ability to choose at each of those levels. Take Hyperledger Fabric for example:

  1. The Ledger Technology: The actual blockchain, or transaction log, is stored in the file system of the peer using merkle hashes while the current state of the world is stored separately in a database for quick lookup.
  2. The Consensus Mechanism: The combined effect of the endorsement model and the ordering service achieve consensus in the network.
  3. Membership Services: Fabric has the concept of Membership Service Providers (MSP) which manages the concept of identity by issuing certificates,  validating them and authenticating users. The MSP is a core part of permissioning in Fabric.
  4. Smart Contract Runtime: Fabric mainly supports smart contracts that are written in Go or Node.js.

In the spirit of expanding choices, Hyperledger Fabric now supports Ethereum Virtual Machine (EVM) bytecode smart contracts. Contracts can now be written in languages such as Solidity or Vyper. Along with introducing a new smart contract runtime, Fabric also has a corresponding web3 provider which can be used to develop decentralized applications (DApps) using web3.js. This new feature comes as part of the 1.3 release and is motivated with the goal to enable developers to be able to migrate or create DApps for a permissioned platform.

Smart Contract Runtimes

Before diving into the details of the EVM integration, let’s expand on the concept of a smart contract runtime. In general the runtime refers to what are the languages that are supported by a specific platform. But there are many other considerations that should be weighed in. Due to the nature of blockchain, these runtimes have to be evaluated in a distributed nature. Since many nodes, if not all of them, have to run and store these contracts, the network has to be mindful of the runtimes being supported. Languages affect how computationally intensive an arbitrary contract can be as well as the deterministic nature of them. Though neither is necessarily a limitation, they can place an unfair burden on the contract developer. Another important factor is what languages the contract developers themselves are experienced in. With the emergence of blockchain, there has been an increase in developers that do not have technical backgrounds, so picking up new languages is not always a practical solution. The implications of smart contract runtimes make choosing a blockchain network even more difficult. Through the introduction of an EVM, we hope to make sure that Solidity smart contracts and permissioned networks are not mutually exclusive.

Implementation

As part of integrating an EVM, we wanted to recreate some of the developer experience of Ethereum. Therefore the integration can be broken into two key pieces, an EVM user chaincode, and a web3 provider Fab3.

User Chaincode

The EVM user chaincode is a wrapper around the Hyperledger Burrow EVM. We have also added functionality to enable queries about accounts and contract code. Below are a couple of the key design decisions made as part of the integration.

Accounts

Ethereum has two types of accounts, a Externally Owned Account (EOA) and Contract accounts. EOAs essentially are an address that is generated from a user’s public key and a balance of ether. As part of this work, Fabric was not introducing ether or any other tokens so EOAs are not explicitly stored. However a user account address is generated on the fly from a user’s public key.

Contract accounts contain the runtime EVM bytecode for a contract. Following Ethereum, the EVM chaincode will be storing these types of accounts on the chain. Smart contract deployment through the EVM will not need a manual step of installing a smart contract like in the Fabric workflow.

Gas

Every instruction in the EVM requires a certain amount of gas. For every transaction that is run through the EVM, enough gas must be provided to ensure completion. This makes sure “miners” don’t risk DoS caused by infinite loop, and waste computational resources Essentially if enough gas is not provided for a certain transaction, it will exit before finishing. In its current iteration, the EVM chaincode provides a large hardcoded amount of gas per transaction.

Fab3

Another key piece we adopted from the Ethereum ecosystem is the Ethereum JSON RPC API. The API defines a systematic way clients can interact with the Ethereum network. However, due to the differences of Ethereum and Fabric, Fab3 does not completely implement the API. It does support enough instructions to allow for DApps written using the web3.js library.

Try out the new feature by following this tutorial.

Future Plans

Our next goals include enabling smart contract events, and expanding the Fab3 support so that clients such as Remix and Truffle can be used to interact with Fabric. We are also looking for other aspects of the Ethereum ecosystem that can be adopted. This new feature is also a topic of one of the workshops at Hyperledger Global Forum in Basel, Switzerland this December. Come join us and bring your EVM smart contracts and DApps to play with.

We encourage developers to try the feature out and give us feedback! To get started with using Hyperledger Fabric and EVM, you can download the 1.3 code today: https://www.hyperledger.org/projects/fabric