Category

网志

Developer Showcase Series: Jonas Snellinckx, TheLedger

By | Blog

This blog series serves to highlight the work and motivations of developers, users and researchers collaborating on Hyperledger’s projects. Next up is Jonas Snellinckx from TheLedger. Let’s see what he has to say!

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

Blockchain isn’t like any other technology, it isn’t well researched, and it sure isn’t well documented. But let this not scare you. You are a pioneer in the era of a new internet.

Whether you have a computer science background or not, blockchain is a technology you want to get started with. I would not recommend focusing all your resources on one technology. Everything is still early, and there are so many good concepts and technologies out there. Just wait and follow the market. New technologies will arise, so there’s no reason to get tunnel vision and use one technology for all. This is not Java.

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

I’m currently working at TheLedger developing prototypes on mostly Hyperledger Fabric, but also BigchainDB. We are a consultancy firm, mostly doing prototypes, which means I’m fortunate enough to cycle through projects and learn new things at a quick pace. I have worked on numerous prototypes from KYC to competencies on the blockchain to a hackathon solution for diamond invoice financing to even a self-conscious house. You can learn all about our adventures and other Hyperledger Fabric related posts here: https://medium.com/wearetheledger.

I’m also maintainer of some boilerplates and tools for the Hyperledger Fabric network. You can find all our tools on https://github.com/wearetheledger , we have a bunch. We created a network boilerplate, backend boilerplate using nestjs and typescript, node utils to write nodejs chaincode at lightning speed and a mockstub to test nodejs chaincode. We vastly improved our workflow by using these tools, so I highly recommend looking at these.

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

I think Hyperledger Indy is a big one, I think self-sovereign identity will be more important in the future. Just overall making the projects more mature and listening to the needs of the community. I think Fabric is doing this pretty well already.

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?

We recently talked about this at the office. Hyperledger Indy and Self-Sovereign Identity will be a big part once we get to integrate this with Hyperledger Fabric. There’s still some work to this, but this has so much potential. Blockchain is one thing, but SSI will have a whole other meaning to the ecosystem. This will also help some GDPR related issues.

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

I think I’m not the only developer who’s lazy. At school they told us a developer should be like this. This is why it frustrates me one has to do so much duplicate work to submit forms to difference instances for example. I just hope we get rid of this all this duplicate paperwork and do something useful with this saved time.

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

I don’t think we can even imagine the impact of blockchain in 5 years. There’s so many awesome ideas, and most of them are currently only in their concept phase. We’ll have to wait until things mature.

 

Growing the Enterprise Blockchain Ecosystem Through Open Standards and Open Source Code

By | 网志

By Brian Behlendorf, Executive Director of Hyperledger at the Linux Foundation

and Ron Resnick, Executive Director of the Enterprise Ethereum Alliance

The Enterprise Ethereum Alliance and Hyperledger today announce that we are formally joining each other’s organizations as Associate Members. This will enable more active and mutual cross-community collaboration through event participation, connecting with other members, and finding ways for our respective efforts to be complementary and compatible. The collaboration between our organizations will further accelerate adoption of blockchain technologies for business.

The Enterprise Ethereum Alliance sponsors the development of specifications and standards for enterprise blockchain networks, with a focus on those aligned with the broader Ethereum ecosystem. Hyperledger fosters the development of open source software for establishing, managing, and connecting enterprise blockchain networks. Thus, our two organizations have similar objectives, with highly complementary approaches to achieving them.

Our two organizations have similar objectives, such as broadening and strengthening the community around and the adoption of enterprise blockchain technologies. What we hope to get across to the public is that anyone who ever put a “versus” between EEA and Hyperledger got it wrong; it’s now conclusively “EEA AND Hyperledger.”

This relationship will enable Hyperledger developers to write code that conforms to the EEA specification and certify them through EEA certification testing programs expected to launch in the second half of 2019. As members of each other’s organizations, both communities will be able to collaborate across tens of Special Interest Groups, Working Groups, meetups and conferences globally, across hundreds of thousands of developers in both communities.

EEA community members working on specifications and standards can turn to Hyperledger to collaborate on software implementations of those standards. Those could be done as lightweight efforts in Hyperledger Labs, or proposed as top-level projects to the Technical Steering Committee for approval to join the other 10 Hyperledger projects. Our cross-cutting working groups on identity, architecture, performance/scalability could also be leveraged. Both organizations host Meetups and events around the globe, adding to the opportunities for collaboration.

There is already work underway that shows our alignment. In 2017, Hyperledger launched the Hyperledger Burrow project, an Apache-licensed implementation of the Ethereum Virtual Machine (EVM) bytecode interpreter. Earlier this year, Hyperledger Sawtooth added support for the EVM as a transaction processor, bringing smart contracts developed for the Ethereum mainnet over to Sawtooth-based networks. That effort, dubbed “Seth,” is now in active use, and the developers anticipate submitting it for conformance testing to the EEA Spec 1.0 as soon as possible. Likewise, support for the EVM is now available in Hyperledger Fabric.

As a further example, there is currently a working group on Trusted Execution Environments in EEA, and a prototype implementation of those proposed standards, called “Private Data Objects,” being built as a lab at Hyperledger. Hyperledger Labs provide a channel for innovation and testing of ideas to experiment with new frameworks and modules before achieving MVP or stable code.

This concept of simultaneously developing community-driven open standards and production-quality open source reference implementations is a best practice of Internet-scale software development work. Previous examples include the IETF and Apache working on HTTP, and ECMA and Mozilla working on JavaScript.

Down the road, we hope this mutually beneficial relationship will encourage Ethereum developers to consider submitting their enterprise projects to Hyperledger and Hyperledger project maintainers to consider taking de-facto interfaces appropriate for standardization to the appropriate EEA working groups. This relationship will also enable Hyperledger developers to write code that conforms to the EEA specification and certify them through EEA certification testing programs expected to launch in the second half of 2019.

Both organizations will continue to work with other standards bodies, and other open source communities. By working together, the Enterprise Ethereum Alliance and Hyperledger will bring substantial benefits to developers and enterprises, and accelerate the adoption of enterprise blockchain technologies.

 

Thanks,

Brian & Ron

 

Developer Showcase Series: Joshua Smith, MonetaGo

By | 网志, 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.

Hyperledger Bug Bounty Update

By | 网志

By Dave Huseby — Hyperledger Security Maven

In October of 2017, the Hyperledger community launched our first bug bounty program through a partnership with HackerOne. This is in addition to the independent security audits we have initiated to vet our software. Now that the first year of the program is coming to a close, it is time for an update on the impact it has made so far.

We’ve found that increasing our bug bounty payouts has attracted more interest among analysts, and we’ll make even more changes in 2019 to boost bug reporting.

At the launch of the program, only Hyperledger Fabric was in a position to be included. Initially, the bug bounty program was kept private and only open to people in HackerOne’s pool of vetted security analysts because of the relatively new nature of the Fabric code base. By limiting the pool of analysts, we were hoping to better control the number of security bugs coming in.

HackerOne sent invitations to 174 analysts in their pool. Of those 174, only 72 accepted the invitation and joined our program. We were excited to finally have outside people trying to break our software. Unfortunately, at the end of the first six months of the program, we were not where we wanted to be.

To better understand why we are seeing a general lack of interest, HackerOne surveyed the analysts invited to the program to ask why they were not participating in the bug bounty. The results are listed in Table 1.

Specialization 26
Uninteresting 17
Competitiveness 11
Small Scope 10
Onerous Setup 9
Skills Mismatch 7
Clarity 6
Unresponsive 6
Hardened 5
Objection 5
Unattractive 4
Access Criteria 2
Aggressive Policy 2
Low Payouts 2
Small Scope 2
Unclear Payout Structure 1
Total 115

Table 1 — HackerOne Survey Results

We know that blockchain platforms are novel and different from what the HackerOne analysts are used to working with, but we had hoped that it wouldn’t matter. From the survey results, it appears that most analysts weren’t interested because of the high degree of specialization needed to mount effective attacks against the software. To offset the specialization required, we decided to increase our bounty payouts to move out of the “uninteresting” category.

The bug bounty program opened to the public this past April with increased bounty amounts. Immediately we had more interest, however we received a flood of bug reports from people who didn’t take the time to read our program rules and weren’t aware that we are an open source organization. However, we did receive three bugs worth paying attention to. Two were configuration issues with our infrastructure and one was a bug in Fabric. All were fixed and small bounties were paid.

Our bounty award levels are right near the industry median, but based on the required levels of specialization needed to effectively attack our networks, we may need to raise our bounty payouts even further  to increase the level of interest. Table 2 lists our current payouts.

Critical $2000
High $1500
Medium $500
Low $200

Table 2 — Current Bounty Payment Schedule

Moving into 2019, we will reassess the efficacy of our bug bounty program and change our direction. One obvious thing is that we’re not getting the level of interest we had hoped for. Either Hyperledger Fabric has airtight security or we’re not doing enough to interest analysts and hackers. If I had to bet, my money would be on the latter. We’re exploring a number of ideas, from more marketing, using the available bounty budget better through limited time bonuses and offering other incentives like all-expenses-paid trips to Hyperledger events for anybody who reports a critical bug. The discussion is taking place on our Technical Security Mailing list right now: here and here.

Overall, we need to have a well-rounded security process that follows all of the best practices. We have a robust and public bug tracking system and development discussions. All of the teams have rules around code reviews, and they do a good job of managing risk when carving new releases. Over the past year, we have conducted outside security audits of Hyperledger Fabric, Sawtooth, Iroha, Composer, and Indy is underway. The bug bounty is underway and we’re discussing expanding it to include Hyperledger Sawtooth, Iroha and Indy. The idea of running test nets is also being considered.

You can stay connected and participate in that discussion to help us make even more effective use of our security resources in 2019. And as always, you can keep up with what’s new with Hyperledger on Twitter or email us with any questions: info@hyperledger.org.

Bitagora: A Decentralized Voting Platform Built on Hyperledger Sawtooth

By | 网志, Hyperledger Sawtooth

Guest post: Ignasi Ribó (@seliestel)

On October 1 2017, Catalan citizens were called to the polls to decide whether they wanted to become an independent Republic or remain a region of Spain. This self-determination referendum had been promoted by the Catalan regional government with the support of civic organizations and a large part of the Catalan population. But there was one problem: the Spanish government was staunchly opposed to its celebration. As the day of the referendum approached, Spanish police and public prosecutors increased their repressive actions against Catalan citizens and institutions, including the seizure of websites, print houses, postal mail, and any other means by which the referendum could be carried out.

In spite of the repression, citizens occupied the polling stations days before the referendum in order to prevent the police from shutting them down. During October 1st, in an exemplary show of self-organization and resilience, thousands of people kept the polling stations open, defending ballot boxes with their bodies as policemen armed with riot gear tried to seize them by force. Hundreds were injured by the batons and rubber balls indiscriminately used by the police against peaceful voters. In spite of coordinated DDoS attacks throughout the day, anonymous citizens managed to sustain the computer systems used for voter registration. At the end, more than 2 million people were able to cast their ballot. But police brutality and the repressive actions of the Spanish state seriously disrupted the polling and managed to put into question the final results.

Inspired by these dramatic events, I began at the end of November 2017 to develop a blockchain application that would allow any concerned group of citizens to organize a referendum and deliver accurate and auditable results without having to rely on a central authority. The project aimed to strengthen grassroots democracy around the world and give people the ability to exercise their right to vote on any question they deemed relevant, whether central institutions and authorities approved the vote or not.

My interest in decentralized, direct democracy was not new. In my book Habitat: The Ecopolitical Nation I had already argued for the need to extend it as much as possible in order to achieve more sustainable and resilient commonwealths. But now I felt it was the time to work on a practical tool that could help to bring this ideal closer to reality.

Developing Bitagora

The first thing I needed to do was to devise a system for voter registration that would guarantee the anonymity of voters while ensuring that everyone casting a ballot was authorized to do so and that no one would be able to vote more than once in the same election. Centralized voting systems solve this problem by using official censuses and polling stations. For obvious reasons, a decentralized system could not rely on this machinery.

Fortunately, modern public-key cryptography offers the necessary tools to build systems that provide both anonymity and verifiability without relying on a central authority. In the Bitagora implementation, voters submit their identification to a fully automatic Certifier script that checks the validity of the information according to the requirements set by the promoters of the poll. If the identification is valid, the Certifier script generates a private key that is deterministically derived from the voter identification using a hashing function that would prevent an attacker from recovering the identification information of the voter even if he got hold of the private key. The Certifier also generates a token that includes the public key derived from the voter private key using the elliptic curve secp256k1 protocol, the same cryptographic cypher underlying Bitcoin. The Certifier signs this token with its own private key and sends the signature and the voter key back to the voter. With this key, the voter can then cast a ballot in the poll.

Enter Hyperledger Sawtooth

Once I had set up the registration system and a user interface (both mobile and web) that voters could use to register and cast their ballots, I still needed to develop the core functionality of the decentralized network of validators that had to sustain the trustless voting system (i.e., a blockchain).

One very attractive possibility was to build the voting system as a DApp running on the Ethereum Virtual Machine. But that would have required voters to interact with the network using a cryptocurrency. Without owning some amount of Ether, or some other fungible token, voters would not be able to pay for the transaction costs involved in executing the Bitagora smart contract. This didn’t look like a scalable, or even fair way of setting up a voting system that could be used by a large number of voters in a real election.

So I quickly discarded relying on any existing blockchain and opted instead for building my system using a private blockchain that would be sustained by volunteers and be completely free for voters. After reviewing several of the frameworks currently available to build such a system, I chose Hyperledger Sawtooth.

Unlike other frameworks, Hyperledger Sawtooth was meticulously documented, with exhaustive explanations and a wide range of examples and applications that worked right away without a flaw. It also provided a complete SDK in Javascript, the language I was already using to code my system. Moreover, the different modules were packaged in Docker containers, which greatly facilitated the installation and fit perfectly well in my strategy to make the Bitagora validator software easily deployable by a large number of nodes in various operating systems without having to go through messy installations.

As I started to work on developing the validator software using the Hyperledger Sawtooth framework, I also found that there was a very active community of engineers and developers exchanging information, ideas and support on the Hyperledger chat. Whenever I had a question I could not solve on my own, I would post it there and quickly receive valuable suggestions and advice from the Sawtooth team or from developers working on other projects. On some occasions, this chat was a lifesaver!

An open project

At the beginning of August, after months of development, I finally distributed the code of the different Bitagora modules through Github under an Apache 2 license. With the help of the Catalan Pirate Party, I had previously conducted several tests and the system performed really well, thanks in particular to the robust consensus mechanism employed by the Hyperledger Sawtooth network layer. The platform is now ready for anyone to set up and use in all sorts of elections.

Since I am not a professional developer, I don’t have the time or resources to sustain this project on my own beyond its current state. But I would be happy to work with other people interested in expanding and improving Bitagora in order to turn it into a fully functional and open-source tool that can enhance direct democracy and empower voters around the world.

If you’re interested in learning more about the project, you can do so at https://bitagora.cc. You can also help contribute code by visiting: https://github.com/bitagora/bitagora-core

Hyperledger 2018 Summer Mentors Recap

By | 网志, 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.

Hyperledger 2018 Summer Interns Recap

By | 网志, 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.

Privacy By Design in Hyperledger Indy

By | 网志, Hyperledger Indy

The Scope and Limits of Indy’s Privacy Tech

Guest post: Daniel Hardman, Evernym

Privacy is a hot topic in blockchain circles–and across the entire digital landscape. GDPR, ePrivacy, and similar regulatory regimes have the world thinking hard and smart. Modern systems must bake privacy into their DNA; it can’t be bolted on after-the-fact. I’ve written elsewhere about why this is true, and how it must be done–and I’ve spent the last couple years helping Hyperledger Indy embody all the privacy goodness I know. I’m encouraged to hear a swelling chorus of blockchain practitioners opine that certain things must NOT go on a blockchain.

Perhaps you have heard a claim that Indy “solves” privacy. Or perhaps you’ve seen skeptics roll their eyes, muttering about how we’re all going to be correlated by the surveillance state, no matter what we do.

The truth is that both of these perspectives distort reality. Indy does offer some wonderful features to aid privacy, and these features matter! But institutions are certainly going to know some things about us, no matter what Indy does. Indy can minimize this in exciting ways. Nonetheless, what privacy we have, now or in the future, will emerge from a combination of technology, social and legal constructs, market forces, and human behavior; it can’t be trivialized as a tech problem.

What “Privacy Tech” Are We Talking About?

Today, Hyperledger Indy’s approach to privacy includes elliptic curve cryptography, pairwise DIDs, semi-trusted agents, agent-to-agent communication using techniques such as libsodium’s sealed box and authenticated encryption, zero-knowledge proofs, a separation between credentials and proofs, privacy-preserving credential revocation features, an affinity for data and key storage at the edge, and a carefully constructed wallet interface that manages personal secrets with industry best practices. In addition, privacy-preserving agent (device) revocation has been demonstrated as a proof of concept.

Indy’s roadmap includes additional privacy-enhancing features such as a user-friendly SSI tool (mobile app) with smart and safe defaults, microledgers, sophisticated policy and/or AI for agents, mix networks for transaction submitting and agent routing, and so forth.

Some of these technologies exist in other identity technologies, but Indy combines more of them, in far more powerful ways, than any similar technology I know.

What All This Tech Does NOT Deliver

Except for people who live in remote, technology-scarce  places, all of us are constantly observed and recorded. Google maps may have a picture of our front door; cell phone towers track the location of our mobile devices; credit card companies see what we spend; closed-circuit cameras watch us on the road or subway.

In such an environment, much will be known about us, even if we use Indy to prove things in zero knowledge. And, if we choose to use Indy to disclose something identifying–our email or phone number or name+birthdate, for example–then the disclosing interaction is correlatable to a much bigger digital footprint, no matter what fancy math did the proving. Even less perfect correlators like first name + fuzzy place + fuzzy time may correlate us, given sufficient context.

It might be tempting to say, then, that there’s no point to Indy’s elaborate privacy posture. But there is more to the story.

What Hyperledger Indy Privacy DOES Deliver

Hyperledger Indy allows you to construct interactions where the degree of disclosure is explicit and minimal–much smaller than what was previously possible. Nothing about the mechanics of connecting, talking, or proving in Indy is leaky with respect to privacy; vulnerabilities that emerge must come from the broader context. No other technology takes this minimization as far as Indy does, and no other technology separates interactions from one another as carefully. If privacy problems are like a biohazard, Indy is the world’s most vocal champion of wearing gloves and using a sharps container for needles–and it provides the world’s best latex and disinfectants.

Of course, this does not give perfect protection. Like a needle stick, mistakes can ruin Indy’s carefully sanitized interactions, and contamination is always a possibility. In 2017, the layouts of US army bases in some of the most dangerous locations in the world were compromised because soldiers had been using the Strava running app to track where they exercised (https://wapo.st/2J6DQqU). If this can happen when stakes are so high, and when the organization is as careful as a sophisticated army, then similar fiascos will undoubtedly occur, both with and without Indy technology, for the foreseeable future. These are serious problems that are not to be underestimated.

Despite the imperfect guarantees, doctors consider it worthwhile–even vital–to wear gloves. And despite risk, Indy’s privacy tech can deliver real value, if we are careful about constraining behavior and understanding use cases. Any interaction that does not leak is a tiny bit of personal, private space–and chaining such interactions together can accrue significant benefits. Indy makes it possible to prequalify for a loan at a thousand banks, in a way that proves credit worthiness, income, and citizenship, without forfeiting privacy. Used correctly, it can insulate cautious whistleblowers; it can enable secure, private voting; it can make online dating safer. Many other use cases exist. In each situation, we must carefully assess privacy beyond the narrow context of Indy’s proving mechanics. Gloves are less helpful when a disease vector is airborne; the government still needs to know who you are when you pay your taxes.

Intentions And Incentives

Besides discussing what protections Hyperledger Indy offers on the technical level, and what ways there might be to defeat such protections, we can also make an argument that architectures, algorithms, data models, and cryptography always carry a certain “intention” towards the parties we interact with. In our case, this intention is to maintain the individual’s privacy, sovereignty, etc. Whether or not the technology can strictly enforce this intention, or to what extent, is an important question, but not the only argument for building it in a certain way.

If we use pairwise DIDs and zero-knowledge proofs, the message is clearly “don’t try to correlate me,” even if you could find a way to do it if you try hard enough. An HTTP Do-Not-Track header says “do not track me,” but it doesn’t offer any actual protection from tracking. The VRM community has been talking about user-defined terms for a long time. In a relationship, you can express “don’t use my data for advertising,” or “delete my data after 14 days,” or “use my data for research, but not commercially.”

Simply expressing these intentions in code and architecture has value by itself. It bears a message that privacy and sovereignty “should be honored,” even if it cannot always be guaranteed technically that it will be. Over time, we expect that through regulation, trust frameworks, reputation, and similar mechanisms, not honoring such intentions will be discouraged. Of course we must always communicate clearly the limits of intentions and guarantees, lest we create a false sense of security that can lead to severe consequences.

One of the main reasons for the growth of Internet’s re-decentralization movement (Diaspora, Bitcoin, etc.) was not only to achieve more privacy and independence, but also to build architectures that better mirror the way we want society to work in the real world (not client/service aka. master/slave). At the same time, the point of view that “technology is neutral” is getting less prevalent, being more and more replaced by an assumption that “technology has built-in values.” From this perspective, privacy tech is valuable not only as a technical defensive mechanism, but also to make a point, to convey an intention.

Importantly, Indy’s technology also enables the transformation of privacy incentives. Companies that once stored PII can now store an opaque identifier for a customer, and contact the customer’s agent to learn more–then throw away the data after they use it. This has the potential to eliminate many centralized data troves as hacking targets, and it empowers people instead of impersonal and conflicted corporate guardians. Indy also provides meaningful advances in the world’s answers to privacy regimes like GDPR. We believe that in the future, social, software, and legal constructs will evolve to take advantage of the privacy features offered by Hyperledger Indy, and that this will lead to ever more creative types of business models and digital interactions not possible before.

 

Hyperledger Fabric & Sawtooth Certification Exams Coming Soon!

By | 网志, Hyperledger Fabric, Hyperledger Sawtooth

We strongly believe in helping organizations and developers overcome obstacles to blockchain adoption by investing in training and certification courses for Hyperledger. That’s why we’re thrilled to announce that Certified Hyperledger Fabric Administrator and Certified Hyperledger Sawtooth Administrator exams will be released later this year!

Below is more information on the certification exams:

Certified Hyperledger Fabric Administrator

The Certified Hyperledger Fabric Administrator (CHFA) can effectively build a secure Hyperledger Fabric network for commercial deployment. To pass the exam, professionals must demonstrate the ability to install, configure, operate, manage, and troubleshoot the nodes on that network. Completion of LFD271 may help serve as preparation for the CHFA exam, but is not required.

Exam sections will include:

  • Application Lifecycle Management
  • Installing and Configuring the Network
  • Diagnostics and Troubleshooting
  • Membership Service Provision
  • Network Maintenance and Operations

View the full list of domains and competencies for CHFA.

Certified Hyperledger Sawtooth Administrator

The Certified Hyperledger Sawtooth Administrator (CHSA) can effectively build a secure Hyperledger Sawtooth network for commercial deployment. To pass the exam, professionals must demonstrate the ability to install, configure, operate, manage, and troubleshoot the nodes on that network.

Exam sections will include:

  • Installation
  • Configuration
  • Permissioning, Identity Management & Security
  • Lifecycle
  • Troubleshooting

View the full list of domains and competencies for CHSA.

The certification exams were made possible thanks to generous help from the community. Specifically, we’d like to call out and thank the participating individuals for the time they contributed to shape the content for these certifications:

Hyperledger Fabric

  • David Gorman, IBM
  • Dinesh Kumar, Oracle
  • Ernesto Lee, Blockchain Training Alliance
  • Greg Skerry, Altoros
  • Manu Varghese, Greenstream Technology
  • Yaoguo Jiang, Huawei
  • Naresh Thumma and Bhasker Nallapothula, Biarca
  • Ry Jones, Hyperledger,
  • Liz Kline, The Linux Foundation
  • Clyde Seepersad, The Linux Foundation
  • Toki Winter, The Linux Foundation

Hyperledger Sawtooth

  • Dan Middleton, Intel
  • Tom Barnes, Intel
  • Richard Berg, Bitwise IO
  • Ryan Beck-Buysse, Bitwise IO
  • Val Reid, PokitDok
  • Anthony Adkins, PokitDok
  • Gregory Skerry, Altoros
  • Neeraj Srivastava, DLT Labs
  • Jovan Maric, DLT Labs
  • Chris Spanton, T-Mobile
  • Ernesto Lee, Blockchain Training Alliance
  • Tracy Kuhrt, Hyperledger
  • Ry Jones, Hyperledger
  • Wallace Judd, Authentic Testing
  • Toki Winter, The Linux Foundation
  • Liz Kline, The Linux Foundation

Both the CHFA and CHSA exams will be available to take before the end of the year. As with all Linux Foundation certification exams, the exams are completed remotely from virtually any location with a stable internet connection and webcam. Those who fail to pass the exam on their first attempt can retake the exam one additional time at no cost.

But the certifications are not the only thing to be excited about – you can now enroll in a new LFD271 – Hyperledger Fabric Fundamentals training course, which was also announced by The Linux Foundation today. LFD271 is designed for developers. They will learn how business logic is implemented in Hyperledger Fabric through chaincode (Hyperledger Fabric’s smart contracts) and review the various transaction types used to read from and write to the distributed ledger.

The LFD271 course instructor, Jonathan Levi is the founder of HACERA, and one of the early contributors to Hyperledger Fabric. He helped shape the Membership Services (the permissioning layer of Hyperledger Fabric) and was the official release manager of Hyperledger Fabric 1.0. He has built several large-scale mission critical systems that had to be highly available, secure and fault-tolerant.

Be on the lookout for these certifications as well as a beta tester program where we will invite members of the community to take the exams. If someone completes the beta exam with a passing grade, they will become one of the first Certified Hyperledger Fabric or Sawtooth Administrators upon launch of the program.

We hope you join us in contributing to Hyperledger projects. As always, you can keep up with what’s new with Hyperledger on Twitter or email us with any questions: info@hyperledger.org.

Developer Showcase Series: Ian Costanzo, Anon Solutions Inc

By | 网志, Developer Showcase, Hyperledger Composer, Hyperledger Fabric, Hyperledger Indy

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 Ian Costanzo from Anon Solutions Inc. Let’s dig in!

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

Learn the fundamentals, and then get involved in an interesting open source project.

Working with Bitcoin is one of the best ways to learn the fundamentals of blockchain. The original white paper lays the groundwork in a clear and concise way, and there is a significant amount of documentation and examples available. Once you have a good understanding of the basic cryptography, merkle trees, proof of work, etc, it is much easier to work with more complex frameworks, which tend to layer on additional functionality (and complexity).

Then find an open source project and get involved. No matter what your interest there is probably a existing project in with a need for contributions in a number of areas. Documentation, introductory tutorials and testing are common needs. I’ve been involved in a few projects, and I’ve found there is always enthusiastic support (via slack, rocketchat, telegram, etc.) for new participants.

Also check for local meetups – I’m fortunate that in Vancouver there are a lot of blockchain enthusiasts, many meetups, and I’ve met quite a few interesting characters.

Give a bit of background on what you’re working on, and let us know what was it that made you want to get into blockchain?

I’m working with the BC Government on their Verifiable Organizations Network (VON) project (https://github.com/bcgov/von) using Hyperledger Indy.  I got involved in a roundabout kind of way.

Originally I was working with a homeless shelter in Calgary (https://www.calgarydropin.ca/) – they had recently implemented a new CRM and were looking at ways they could improve service to their clients by (securely) collaborating with other service providers. Their primary concerns were security of personal information, and respect for the sovereignty of individuals to control their own information, where possible. I did a survey of the technology space, and found that the Sovrin network (and Hyperledger Indy) was a clear fit for their requirement. I was lucky enough to get in touch with the BC group who were working with the same technology, and then fortunate to be able to participate in their project.

I’m interested in how blockchain can be used to help protect our personal information, and give us more autonomy and control over how our information is shared and used.

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

I’m working with Hyperledger Indy, with the BC Government. My role has been to scale up the solution to handle enterprise requirements, including large data volumes and transaction throughputs.  It’s been a fascinating experience, because I get to work with a lot of very smart people in the BC Government, as well as at Sovrin, Evernym and the whole Indy community.  The technology is new, which is interesting, but we’re also exploring new ways in how the technology is being applied, which creates lots of challenges and opportunities.

Specifically I’ve been working on an Enterprise Wallet for the central credential “holder.” I’ve updated the wallet to support multiple identities and millions of credentials, and to run in an enterprise micro-services deployment. I’m excited for the next round of SDK wallet development, which is going to introduce wallet meta-data, native encryption and improved search capabilities, which are all going to support functionality the team is planning to add in the coming months.

I’d also like to mention that the BC team is working in partnership with the governments of Ontario and Canada. In Victoria we work out of the government’s “Innovation Center”, which is focussed on public/private partnerships and support for the open source community. All the work we are doing is open source, available for use, and we welcome new collaborators.

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

Ease of use for new developers, as well as scalability. Ease of use is something that Ethereum (for example) has done a very good job with. Solidity is pretty simple to learn, and you can write very sophisticated blockchain applications without having to get too deep into the weeds. This is why Ethereum is one of the most widely used blockchain platforms. The downside of Ethereum is scalability (Crypto Kitties almost brought down the whole network) but that is something they are putting some resources into.

I’ve worked with Hyperledger Fabric and Hyperledger Indy, and I think anyone will agree that these are very complex technologies!  In order to get more widespread adoption documentation, training and tooling are critical. Their strength is that they are more specialized networks, however they come with a very steep learning curve, and this is something that needs to be addressed.

For Hyperledger Fabric, the introduction of Composer for application development was a huge step forward. Hyperledger Indy (what I am mostly working with now) could use similar tooling. There is work in progress on documentation and developer tools, but the more focus in this area the better!

As a private network, Hyperledger Fabric may not suffer from the same scalability concerns as public networks, but Indy supports a public network (Sovrin) so scalability is definitely a concern.

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

I like to think that blockchain can be used for the benefit of humanity, rather than just providing a living for those of us fortunate enough to be working with the technology.

Self sovereign identity has a lot of potential, putting information under the control of the individual rather than large corporations, allowing us to (selectively) share with our friends and colleagues, without having to worry about our information being mined and mis-used.  Also being able to benefit disadvantaged populations, like refugees and the homeless.

Privacy is another potential benefit of blockchain, having the ability to secure personal information, as well as being able to communicate and transact anonymously.

I’ve seen a lot of other really interesting applications proposed or prototyped, like using cryptocurrency to distribute aid directly to recipients (reducing the risk of graft), or using blockchain to track ethically captured tuna. I’m excited (and hopeful) for the future of this technology.

What technology could you not live without?

I resisted getting a smartphone for a long time, because I have a bit of a technology addiction. (I also don’t own a TV because I would just end up watching it all the time.) Now I have an Android phone, and I’m in constant communication. I always know the answer to every question (thanks Google) and where to go for lunch or the best route to get to the ferry. When I get involved in an interesting technology (like blockchain!) I become a bit of a workaholic and spend far too much time on the computer.

So the best technology for me is sometimes no technology at all. Leave the phone behind and go for a walk, to clear my mind. Sit down with a pen and paper to solve some problems, rather than try to work it out at the computer (This forces me to do some actual programming for a change, rather than just cut and pasting from StackExchange.) Read the newspaper rather than my news feed online.

Until the nervous twitching starts and I have to reach for my phone!