Category

Hyperledger Fabric

Dec 03
0

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.

Nov 30
0

Six 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 six 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 personal information control

Hu-manity.co is a New Jersey-based startup, whose mission is to ensure that every person on Earth has the full legal right to their own personal data as protected property. To do this, the group built its mobile #My31 app, which works with “intelligent contracts” where that personal data can be protected and seen as personal property using its Human Data Consent and Authorization Blockchain (HD-CAB). The idea is to create an environment where humans, their data and corporations can co-exist through blockchain-backed explicit consent and authorization to use such data, giving individuals more privacy and greater control over their own information. The Hu-manity.co effort partners with the Sovrin Network, which is an identity network that uses Hyperledger Indy technology to bring it all together. Data isn’t stored in the app, but the app is designed to give users control over their data by using the app. Users can download the #My31 app for Android or iOS.

3. 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.

4. 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.

5. 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.

6. 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.

 

Nov 28
0

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.

 

Nov 16
0

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.

Nov 15
0

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.

 

Oct 26
0

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

Sep 25
0

Developer Showcase Series: Joshua Smith, MonetaGo

By | Blog, Hyperledger Fabric

We return back to our Developer Showcase blog. This series serves to highlight the work and motivations of developers, users and researchers collaborating on Hyperledger’s projects. Next up is Joshua Smith from MonetaGo. Let’s see what he has to say!

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

Be willing to ask questions, keep an open mind, and stay humble.  Blockchain is bleeding edge technology, there are difficult problems that many people are trying to solve in different ways. There is no gold standard or best practice guide to follow, the whole community is figuring it out as we go along. There are so many different blockchain implementations; do some research, pick one, and dive in.

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

Before becoming a software engineer I was a physicist. After leaving academia, I was focused on finding another career path that would allow me to be a part of a community dedicated to solving complex problems. I was familiar with public, permissionless blockchain implementations before formally entering the field and learned a lot about Hyperledger and its projects while preparing for my interview with MonetaGo. I felt pretty confident that getting into blockchain would be fun. A year and a half later and I’m still having a really great time solving tough problems with my team and the broader Hyperledger community.

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

For the past year we’ve worked towards launching a production blockchain network for a group of exchanges in India seeking to mitigate fraud in the process of invoice factoring. I spent a long time writing chaincode, working with the node sdk, and customizing channel settings to make sure our solution met the necessary standards to go into production. We hit our go live milestone at the end of March 2018, making us the first production enterprise blockchain solution in India. Now most of my focus is on scaling our architecture to support our growing user base.

I’ve worked with Hyperledger Fabric since version 0.6.5 and I’m really happy with how the project has evolved. I really appreciate the transparency maintainers have with regards to project direction and priorities. As the community has grown over time I’ve found members to be consistently helpful and friendly in both hackfests and rocket chat. There’s a great wealth of knowledge available if you know the right questions to ask.

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

The passing of GDPR and some US states looking to adopt similar privacy rules is going to make data privacy of huge importance. Although it’s currently possible to implement your own privacy solutions, I think Hyperledger projects will need to include guarantees out of the box for widespread adoption as production solutions.

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

The biggest difference between expert and novice problem solvers is the time it takes to begin. Experts take a much longer time to ensure they understand the bounds of a problem before starting to implement a solution and end up saving time by doing it right the first time.

What technology could you not live without?

Definitely my phone, I use it for so many different things throughout the day it may as well be a part of me.

Sep 14
0

Hyperledger 2018 Summer Mentors Recap

By | Blog, Hyperledger Cello, Hyperledger Fabric, Hyperledger Iroha

Our interns did some great work on some very meaningful projects this summer. We’ve shared details of their work here. Of course, the program wouldn’t work without the time, effort and input our mentors provided. Many of them went the extra mile and provided their take on lessons learned, what they gained by being a mentor and advice for future interns as well. Here is some of the wisdom they shared:

Baohua Yang, Principal Architect, Oracle Blockchain (Project: Design Effective Operational Platform for Blockchain Management)

Lessons learned:

The intern’s self-motivation is important as is his/her interests with open-source projects.

What you got out of being a mentor:

I was very glad to help new person to get involved into the open-source world.

Advice for those interested in interning in the future:

Knowledge or skill is not the most important thing to learn as an intern. The Hyperledger internship is a great opportunity to help you learn open culture and principles to participant a teamwork.

Dave Huseby, Security Maven, Hyperledger, The Linux Foundation (Project: Simulating Hyperledger Networks with Shadow)

Lessons learned:

The primary lesson I learned is to choose the right size for an intern project. I was ambitious in what I asked my intern to do. It turns out that blockchains are complicated pieces of software and getting them to run under a simulator is difficult. That said, the reduced scope we agreed upon mid-summer was met and we did advance this effort.  I’m hoping that an intern next summer will pick up where my intern left off.

What you got out of being a mentor:

It was interesting to see our community through the eyes of a newcomer.  I got involved with open source communities so long ago that I forgot what it was like to be new.  I had forgotten all of the mental shifts (e.g., don’t ask for permission, just do) and leaps of faith (e.g., here’s my code, please be nice) that a developer has to make to be a successful contributor to an open source project. It takes real courage to contribute code and fully participate in a community where you know nobody. I really enjoyed encouraging Martin when things got tough. More importantly, the best thing I got from being a mentor was a new friend.  Martin is a really good person.

Advice for those interested in interning in the future

Be prepared to work hard. Working remotely is difficult and not a normal way of working. It takes a great deal of self-discipline, and as I said above, it takes real courage to submit code to people you don’t know and be judged by your contribution.  Be prepared to learn. With the right attitude, an intern can get some real rubber-meets-the-road experience. There’s a big difference between a recent computer science graduate and a work-a-day programmer. An internship working on open source software can go along way towards making you a work-a-day programmer.

Jay Guo Software Engineer, IBM (Project: Extended Support for EVM and and Tooling in Hyperledger Fabric)

Lessons learned:

We should set realistic goals for interns, and we should give them enough time to climb the learning curve.

What you got out of being a mentor:

Mentoring requires more than technical skills. I learned a great deal of project management, communication and presentation skills

Advice for those interested in interning in the future:

  • Remote internship is hard and timezone difference makes it even harder. Both mentors and applicants should take this into consideration. Being located in the same city would make life much easier.
  • Communication is a key part of internship. Interns should proactively seek help from mentors, and this is a quality that mentors should pay attention to when interviewing candidates.

Swetha Repakula, Open Source Developer, IBM Digital Business Group (Project: Extended Support for EVM and and Tooling in Hyperledger Fabric)

Lessons learned:

  • Most of my lessons comes from the fact that this was a remote internship. I underestimated the difficulty that comes from both not being able to work together in person as well as being able to finding a reasonable time for everyone involved to be able to speak. Because of this, I think projects that are suggested for this program either have to be very structured and scoped or the project needs to be isolated enough that the intern is able to make progress without other people. The solution to this we found was scheduling regular calls and asking for daily reports on progress to make she was on track.
  • Another thing I learned was making sure our intern felt comfortable asking questions and not feeling like she was alone. Creating that environment was our number one goal because interns shouldn’t feel like they are expected to do everything by themselves. We found that explaining our expectations to her and constantly encouraging her to ask us questions was the best solution to this.
  • My final takeaway was setting realistic goals for the internship. Goals can refer to the actual progress of the project, but I viewed the internship successful if our intern was able to end the program with a skill set she could apply to whatever she planned to do next. Of course our intern produced results, but what I was most proud of was when she understood concepts such as test-driven development or breaking down a project into smaller achievable tasks. Those are the skills that will make her a good developer and, in the end, the goal of this program is to enrich our interns, not necessarily just got some work done for our projects.

What you got out of being a mentor:

  • I have always enjoyed sharing knowledge, and this program gave me the opportunity to do that. My proudest moment easily was when my intern spoke about how the things we taught her during the internship directly applied to her current classes. As I mentioned above, our first goal was to make sure our intern learned enough that she could apply it to the rest of her career.
  • I found though that mentoring someone was not just about teaching but required some managerial skills. That would involve making sure my schedule allowed enough time for me to be available to guide my intern, ensuring she was making enough progress at the correct pace and helping her get the resources she needed to complete her work. This is was a very new experience from me.

Advice for those interested in interning in the future:

  • I recommend that those who wish to intern in the future be honest, whether that is about their skill set, their availability, or their professional interests. Our intern was clear about what she understood or didn’t understand and that really helped make sure the limited time we had was focused on what she was stuck on.
  • Be proud of your current accomplishments. As mentors we aren’t expecting you to necessarily have experience in the topics we are working on. What I look for is someone who is driven and passionate about the work they do. So be able to talk about those accomplishments, regardless of whether it is a class assignment or a huge project you have worked on.
  • Communication is key for anything you work on. Focus on being to explain your ideas clearly as well as relaying what you have done in the past. And, lastly, come with your ideas and questions.

Sheehan Anderson, Vice President/Director of Architecture, State Street (Project: Hyperledger Fabric Chrome Extension)

Lessons learned:

Working remotely brings unique challenges, especially when starting a new project. There were several of steps we took that worked really well throughout the internship.

  1. Have a plan laid out on day one that covers the length of the internship. Understand what parts of the project should be functioning by the end of each week as 12 weeks will go by really quickly. You don’t want to be spending time deciding what to do at the start of each week.
  2. Communication is important. Have regular video conference calls to demo what has been built, discuss any blockers, make sure that next steps are understood, and just to get to know each other. Be available on Rocket.Chat (chat.hyperledger.org) so you can answer questions. Also, encourage your intern to reach out in the various channels when they have a question. It’s a great way to meet other Hyperledger developers.
  3. Be flexible. Chances are that your 12 week plan will encounter at least some roadblocks. Be quick to remove or alter features if they are taking longer than expected to build.

What you got out of being a mentor:

Hyperledger Fabric is no longer a new project. I started as one of the original developers and now spend most of my time writing applications that run on the Hyperledger Fabric platform. I’m surrounded by people with similar experience. Having a chance to work with someone who is both new to Hyperledger and early in their software engineering career brings new perspectives that are important. A risk of working on the same thing for too long is that you get used to the way things are and don’t stop and question why something is done in a particular way and if there may be a new or better alternative. Being a mentor requires you to both be able to explain the existing architecture and answer those “why” questions that you may have ignored otherwise.

Advice for those interested in interning in the future:

The interns that really stood out during the interview process had built projects utilizing existing open source projects. This showed that they had curiosity, determination, and the ability to self-learn and get unstuck when faced with an obstacle. Sometimes contributing to existing open source projects can seem daunting or have a very steep learning curve. Creating your own small project that makes use of an existing open source project can be a great introduction to various open source communities and will also show that you have the skills needed to succeed in a program like the Hyperledger internship.

Salman A. Baset, IBM (Project – Running Solidity Smart Contracts on Hyperledger Fabric or Vice Versa)

1) Lessons learned:

To have a successful internship outcome, a project needs to be crisply defined, have an intern who possesses the necessary background and is excited to learn, and have periodic sync ups with the intern. I was fortunate to have an intern who had background in compilers and was excited to learn both Ethereum and Hyperledger Fabric in order to translate Solidity smart contracts into Javascript for Fabric. We leveraged Zoom and Hyperledger Rocket chat for communication.

The key takeaway from the project is that it is possible to write smart contracts for one platform that run in another without making changes to the core platform. Perhaps, a bigger lesson is that there is a need to write smart contracts in a language that can be run on any target platform (similar to Java). Hopefully, next year, we can have a project to develop a smart language that targets multiple blockchain platforms within Hyperledger.

The project is available as open source with Apache 2.0 license and will soon be converted to a Hyperledger Lab. The source code is available here:

https://github.com/AhmadZafarITU/SolidityToJavascriptTranslatorCode

What you got out of being a mentor:

I had the satisfaction of supervising a hardworking intern who was able to create running code for the seemingly difficult idea of running Solidity contracts on Fabric. My hope is that the project does not end with the culmination of the internship and sparks interest among other members of the community.

Advice for those interested in interning in the future:

Asking questions to your mentor and seeking solutions on your own from members of community is very important.

We would also like to recognize the mentors for all the time, effort and input they provided! As always, you can keep up with what’s new with Hyperledger on Twitter or email us with any questions: info@hyperledger.org.

Sep 13
0

Hyperledger 2018 Summer Interns Recap

By | Blog, Hyperledger Burrow, Hyperledger Cello, Hyperledger Fabric, Hyperledger Iroha

It’s suddenly September and so it’s time to check in on our Hyperledger summer interns and mentors. Read on for more about five of the projects our interns tackled. We asked the interns about their summer with Hyperledger.

Here, their own words, are the goals, successes and lessons learned from each intern:

Ahmad Zafar (Project: Running Solidity Smart Contracts on Hyperledger Fabric or Vice Versa)

Project goals:

I was working on Running Solidity Smart Contracts on Hyperledger Fabric Project. The Solidity smart contracts are easy to write and are widely used by developers. The aim of this project was to help the developers to translate the publicly available Solidity smart contracts into readable and, hopefully, functionally equivalent Hyperledger Fabric contracts without writing the contracts from scratch. For Hyperledger Fabric, we chose Javascript language. Our goal was to translate 70-80% of the Solidity grammar/programs correctly into fabric smart contracts that are also human readable to make them easy to understand and change.

Successes:

I have successfully translated approximately 65-70% of solidity code to javascript code for Fabric smart contracts. Examples of language features include types, expressions, functions, events, function modifiers, structs, and single inheritance. Since Ethereum is a public blockchain with notions of Ether (Cryptocurrency) and Ether transfer, I had to provide functional equivalence in terms of Ether transfer on Fabric – (we ignore gas for now).

I have also translated 15 Solidity smart contracts examples to javascript code. These contract have been taken from different places. Some are from solidity documentation, and some are from github repositories, including the ERC20 token format which is used to create ICOs. These contracts were chosen with my mentor to cover a large number of Solidity features.

My translator will work on other contracts as well if the contract has 65-70% of the common components. My translated code and all examples that I have tested are placed on my github repository along with all the other content related to my project, including which components we have covered, how you can run this tool and results of my translated code.

Lessons learned:

For developing a translator from Solidity to Fabric, one has to have knowledge of compilers and has to learn both Solidity and chain code and both frameworks for testing code. Before starting this internship, I worked on compiler construction in my university project. The scope of that project was not big but making a translator for complete language was a massive task for me. Successfully completing that project boosted my skills in writing translator tools for different things. However, before starting this project, I had little knowledge about Ethereum and Hyperledger Fabric smart contracts. After this project, I have become skillful enough in writing both Ethereum and Fabric smart contracts. Other than languages, I have learned how to run contracts on both frameworks and their architecture. In short, I learned many things related to Ethereum and Hyperledger Fabric. This project will help me a lot to start development in blockchain, especially in Fabric and hopefully other Hyperledger frameworks.

A V Lakshmy (Project: Extended Support for EVM and and Tooling in Hyperledger Fabric)

Project goals:

My project involved the integration of Ethereum events into Hyperledger Fabric. The two key goals of the project were:

  • Implementation of event-related interfaces from Hyperledger Burrow to work with the event framework in Hyperledger Fabric
  • Modification of the JSON-RPC API functions in the fabproxy module to deal with events

Successes:

  • In the initial few weeks of my internship, I wrote some simple test cases for the chaincode evmscc.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 and modified the API functions in the fabproxy module. These pieces are still under review and will hopefully be merged before the September release.
  • This was my first experience with open-source development and in the exciting field of blockchain. I am thrilled that my work will eventually be included in the source code of a vast project like Fabric!

Lessons learned:

  • I got to study a new programming language, Golang.
  • I learned about Ethereum and Fabric and how to interact with these blockchain frameworks.
  • I got an exposure to version control systems like Git.
  • I grasped good software engineering principles, such as test-driven development.

I am very grateful to my mentors, Swetha Mam and Jay Sir , for patiently guiding me through this project. All in all, this project was an incredible learning experience for me!

Daniel McSheehy (Project: Hyperledger Fabric Chrome Extension)

Project goals:

The goals of my project was to build a Chrome extension that can connect to a Hyperledger Fabric network and provide an easy to use api for websites to send transactions.

Successes:

The Chrome Extension is operational. Through a simple api, a website can easily prompt the chrome extension to send transactions and query the ledger. The extension also requires confirmations from the user, preventing a website maliciously sending transactions.

Lessons learned:

Sometimes the “right” way to do something doesn’t work, so I had to come up with alternative solutions to get things working. Because my project is intended to make things easy for users, I also learned the importance of reaching out to others and receiving feedback.

Martin Martinez (Project: Simulating Hyperledger Networks with Shadow)

Project goals:

We had two key goals for the project:

  • Analyzing the current Shadow tool characteristics to find compatibility with Hyperledger networks.
  • Testing the Shadow tool with platforms such a Hyperledger Sawtooth, Hyperledger Fabric and Hyperledger Iroha.

Successes:

We successfully identified that Hyperledger Iroha is the most suited candidate to use the Shadow network simulation tool.

Lessons learned:

I learn more about the complexity and benefits of working in an open source community. Also, I feel grateful for the support of my mentor as well as the Hyperledger community members that I contacted through different channels such a Hyperledger chat.

Shuo Wang (Project: Design Effective Operational Platform for Blockchain Management)

Project goals:

My internship project focused on supporting dynamic blockchain configuration and integrating Fabric-CA module into Hyperledger Cello to make it more suitable for production environment. For beginners or in the testing environment, we often use an offline tool to generate all the cryptographic configuration artifacts statically. However, it is a centralized and unsafe way for a single user to generate all users’ identities in a real application scenario.

Successes:

I adopted Fabric-CA module and made the generation of cryptographic artifacts dynamic, automatic and decentralized. After users login into an operator dashboard, they could easily connect to a worker node and create the blockchain on it with quite simple configuration of the network type, size and roles in the blockchain. All the orderer nodes and peer nodes will register and enroll their identities from the CA server. Then users could login into a User-Dashboard to install and run chaincode in the blockchain with a newly generated user identity from the CA server.

I will continue to work in Hyperledger Cello Project after internship, and I plan to make the process of Cello workflow more dynamic so that each organization in the blockchain network could change their own settings more freely.

Currently, I am doing my master thesis at the Southern University of California and Tsinghua University. My research is focused on the blockchain consensus. Therefore， I am quite interested in seeing the Byzantine-fault-tolerant consensus used in the future version of Hyperledger Fabric.

Lessons learned:

During the internship, I enjoyed the culture of open source and learned some great tools for open source project development. The most important lesson I learned is to be timely in following up and keep in close touch with mentors and colleagues because people work collaboratively from all over the world. I really appreciate my mentor, Dr. Baohua Yang, and his kind help and guidance. He gave me many practical suggestions and shared deep insight of blockchain industry with me.

As a bonus, we asked for the intern’s take on what they’d like to see Hyperledger do in the future. Here are a couple of our favorite answers:

“I hope Hyperledger offers or organizes hackathons at universities. I think that it could be a great way to get students involved in blockchain and expose them to open source communities. I’m always amazed at the ideas people come up with at hackathons, and think that there could be projects and use cases that have never been thought of.” – Daniel McSheehy

“I hope that Hyperledger continues to give such amazing internship opportunities to students!” – A V Lakshmy

We would like to thank these interns for all their hard work and success. We would also like to recognize the mentors for all the time, effort and input they provided. Many of them went the extra mile and provided some their take on lessons learned, what they gained by being a mentor and advice for future interns as well. We will be posting their reactions and experiences with the program in another blog tomorrow – stay tuned! As always, you can keep up with what’s new with Hyperledger on Twitter or email us with any questions: info@hyperledger.org.