Category

Blog

[VIDEO] Hyperledger Interviews Hitachi’s Head of the Financial Innovation Center, Toshiya Cho

By Blog

We recently sat down with Toshiya Cho of Hitachi Limited. Toshiya is part of the financial business unit of Hitachi Limited – IT Business. He’s involved in Hyperledger as Head of the Financial Innovation Center, and is spending a ton of time working with the project.

Hitachi Limited believes blockchain will lead to the realization of a so-called Society 5.0 where there is interconnectivity among various industries. Blockchain technologies, especially the smart contract functionality, will provide the capability to deal with the interconnectivity among these various industries. There are a lot of possibilities to change the world with blockchain technologies, according to Toshiya.

Watch the full video below:

Developer Showcase Series: Jordan Jennings, Senior Software Engineer, Skuchain

By Blog

Next up in our Developer Showcase Series is Jordan Jennings, a Senior Software Engineer at Skuchain. This blog series highlights the work and motivations of developers, users and researchers collaborating on Hyperledger’s incubated frameworks and modules. Here’s what Jordan had to say about working on blockchain and Hyperledger:

Jordan Jennings, Senior Software Engineer at Skuchain

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

There is a huge expanse of applications to be explored in the realm of distributed trust-less databases via blockchain technology. If you are looking for problems to solve in the space then the places of greatest value are those where the risk of data manipulation are the highest and fingerprintability is most valuable. Measurements, signals or data which come signed straight from the hashed source and placed into an immutable ledger decrease the risks of fraud and increase the visibility to privileged parties. The chain of trust from client to ledger itself has many challenges aside from product development, and the products themselves must be such that lend themselves to the value of providing immutable proof of previous events from trusted client devices.

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?

Joining Skuchain and diving into the ecosystem was a no brainer. While I did not have any domain specific knowledge, I was only a software engineering background (specifically in video software at Cisco Systems). I recognized the potential for blockchain technology to completely change entire industries. At Skuchain, the industry of focus is the supply chain, and the innovation we are bringing to old antiquated processes has enormous value for customers. The pitch given to me when interviewing was filled with the potential to make a mark on this industry in ways that others have yet to accomplish, treading new ground in a multi-trillion dollar industry. As someone who is passionate about exploring what can be done with new software technologies joining a startup in this space was a perfect fit.

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

The role of Hyperledger in the underlying tech of our application is immense. Stability, and well documented APIs are of the greatest importance for usability and confidence in deploying on premise installations of Skuchain applications. Thus far, Hyperledger hasg proven itself in our tests. I am expecting that an unwavering focus on bullet proof releases will make it the continued choice of Skuchain and my personal recommendation for enterprise blockchain applications.

Well designed and documented APIs will also prove extremely useful for startups looking to maintain high velocity when shipping releases of their products.Ease of use for developers is one of the most important aspects when considering the adoption of new technologies. It enables software ecosystems to quickly form around platforms which in turn can help startups to find product market fit under tight resources and limited time. Thus the importance of these two continuous goals for Hyperledger cannot be understated.

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

The promises of blockchain technologies require work outside of the software, this type of work comes in the form of education, legal and community building around software. Today much of what can be done is not understood from both the technical and legal standpoint. This incurs a risk of the unknown when venturing into products where users may not understand the huge value proposition or courts may not recognize the mathematical properties which bind an agreement between two parties.

A path must be forged to reach these powerful use cases of blockchain, production systems must be shipped and used by customers to increase tangibility, battles won in courts, it must be done carefully to avoid over promise and under delivery, which has the possibility of creating an AI winter scenario for blockchain technologies. Removing these problems in the blockchain space will break barriers to things we cannot imagine doing with the technology today.

Get to Know Hyperledger’s New Community Architect

By Blog

The Hyperledger team continues to grow, and we’re excited to announce that we’ve recently added Tracy Kuhrt as a Community Architect.

Tracy has had a varied career working in automotive manufacturing, pharmaceutical, microelectronics, and e-commerce industries. Prior to The Linux Foundation, Tracy was a Principal Member of Technical Staff at PayPal on the Strategic Architecture team. Tracy has also developed compilers, assemblers, and linkers for 8- and 16-bit micro-controllers at Microchip Technologies using open source software.

Now let’s get into some questions to better understand what Tracy will be working on and her aspirations for Hyperledger.

What got you interested in working on Hyperledger and blockchain?

Tracy Kuhrt, Hyperledger’s Community Architect

I became interested in blockchain when Open Blockchain (what is now Hyperledger Fabric) was announced. I put together a proof of concept — getting my hands dirty is one of the best ways that I know to learn something new. Since that time I have been following the blockchain ecosystem and teaching others about blockchain and its uses.

Blockchain captured my interest because of the number of technologies that it brings together. This speaks to the technologist in me. Hyperledger also captured my interest because of the communities that it is bringing together to develop these technologies in an open, collaborative, and transparent nature. This speaks to the way that I work best with others.

When the opportunity to work for The Linux Foundation on this disruptive and foundational technology presented itself, I knew that this was the right spot for me.

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

As a Community Architect, there are two parts to my role — community and architecture.  Brian describes the community portion as “reducing all barriers to participation and collaboration inside and across all projects at Hyperledger”.  Architecture involves assisting with “technical conversations across projects, driving a holistic overarching architecture that makes sense to developers and the broader user community”.  With that in mind, my initial goals will be to meet the people within the community and to better understand the architecture of all projects that fall under the Hyperledger umbrella.

Next, I want to focus on reducing the barrier to entry for people who are interested in participating in the Hyperledger community.  Most people will progress through a standard set of steps.  The first step will be a need to understand the different projects to determine which is right for their use. After a person chooses the project(s) to work with, it must be easy to set up a development environment, create their first blockchain application, and deploy a blockchain network. The next phase of a person’s involvement would include reporting and/or fixing bugs that are found while working through a use case.

Each of these steps requires good documentation and training material to help jumpstart the process of involvement within the community.  A level of consistency across the projects will make it easy for our community members to contribute and move easily between the different projects.

What is most important in building Hyperledger’s community and what should be the focus for the next year?

As the Hyperledger community grows, our focus must be to continue to create an inclusive, diverse, and welcoming environment, where software development is done in an open and transparent fashion.  We need to ensure that people can quickly come up-to-speed on the work that we are doing across the different Hyperledger communities, including architecture and design discussions, code, and bugs. The contribution process must be easy to understand and follow. These items will help to make this a reality:

  • Creating a single entry point for all things Hyperledger.
  • Holding our discussions on open mailing lists to allow for a greater contribution and diversity of thought.
  • Answering questions posed on our chat channels to help others continue their exploration and learning.
  • Utilizing our shared bug tracking database to log open issues and new features while using a consistent method for tagging “first timer” or “starter” bugs.
  • Documenting our processes and systems using the Hyperledger wiki so that they are easy to find and understand, as well as, being up-to-date.

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

Blockchain will be used to solve a multitude of problems across different industries; however, there is one use case that really peaked my interest — taking back control of data about me. One of the initial articles I read about blockchain was how blockchains would allow me to take back control of the data about me even to the extent of allowing me, instead of big corporations, to monetize this data. I hope that someone will utilize blockchains to ensure that my data remains private and is only shared with the people or organizations that I choose. In addition, I will be able to see who has access to my data and be able to revoke access to people or organizations that no longer require this information. I look forward to seeing how Hyperledger Indy will contribute to making this use case possible.

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

In five years, blockchain and the technologies surrounding blockchain will have matured. We will begin to see a transformation to decentralized business models and solutions. Hyperledger and its communities will have been pioneers for making this future a reality. Related to my work as a community architect, Hyperledger will have a strong and diverse community of contributors and a modular architecture that allows people to choose the best pieces to meet the requirements of their particular use case.

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

If you are in your comfort zone, you are not in your learning zone. Change is hard, and it is easy to get stuck in a space where you are comfortable. When that happens, the one thing that stops is learning. Challenge yourself by trying something new. It will definitely be uncomfortable. You may feel foolish, and you may fail. What fun is doing the same thing all the time?

What do you enjoy doing outside of work? Hobbies?

Outside of work, I have some eclectic hobbies — playing pinball, travelling, raising chickens, and watching the Phoenix Mercury.

Meet Hyperledger Composer

By Blog, Hyperledger Composer

Today, we’re proud to announce that Hyperledger Composer has been accepted into incubation by the Technical Steering Committee. Composer is a collaboration tool for building “blockchain business networks,” accelerating the development of smart contracts and their deployment across a distributed ledger.

All work done on Composer to date has been done on top of Hyperledger Fabric. However, Composer has been designed so that it can be ported to run on other distributed ledger technologies, such as Hyperledger Iroha or Hyperledger Sawtooth.

Why?

All “blockchain business networks” share certain elements  – namely assets, participants, identities, transactions, and registries. With existing blockchain or distributed ledger technologies, it can be difficult for organizations to take a blockchain business use case and map these concepts into running code. In the same way that the software world was accelerated by the arrival of software modelling tools, the primary goal of the Composer project is to accelerate the development of business networks built on blockchain technology.

Technical details of Composer

The main components are:

  • The modelling language; simple but expressive business-centric (the language features keywords such as asset and participant) language that allows non-developers and developers to model their business network. The modelling language also supports modelling of relationships and data validation rules.
  • The ability to encode business logic as transaction processor functions that are written in standard JavaScript. We chose JavaScript because it is a modern, rapidly evolving programming language that is used by millions of developers around the world, as well as giving us the ability to run the code anywhere that supports standard JavaScript.
  • Declarative access control using access control lists, that allows developers to describe what resources can be accessed by which participants. Access control is automatically enforced by the runtime.
  • Client and administrative APIs, as well as a “composer” CLI application that allows developers and operators to deploy and interact with business networks from Node.js applications or automation scripts.
  • A web based “playground” that allows new and experienced users to learn the language, model their business network, and test that network from the comfort of their web browser. The playground can work in both “disconnected” mode, using a simulated network, and when connected to real running network.
  • REST API support and integration capabilities; a LoopBack connector for business networks has been developed that exposes a running network as a REST API which can easily be consumed by client applications.
  • Syntax highlighting support for two popular open-source editors, Atom and VS Code, with future plans about how we could include testing/debugging capabilities.
  • Application generation using the Yeoman framework; client application developers can quickly generate a skeleton Angular 2 or CLI application to use as a starting point, allowing them to focus on UI/UX rather than business network interactions.

Who will work on Composer?

The initial maintainer community is comprised of Simon Stone, Daniel Selman and Kathryn Harrison of IBM, and Cong Tang and others from Oxchains. Of course everyone is encouraged to get involved, we want to see the contributor and maintainer community grow. There is a bi-weekly Hyperledger Composer community call. Please join the mailing list https://lists.hyperledger.org/mailman/listinfo/hyperledger-composer to receive notifications about Composer.

Getting started

Documentation for Composer, including a tutorial for first time users, is available from the public website: https://hyperledger.github.io/composer/

Composer is currently hosted under the Hyperledger organization on GitHub: https://github.com/hyperledger?q=composer. All of our work, both planned and in-progress, is managed using GitHub issues: https://github.com/hyperledger/composer/issues

The current list of repositories is:

  • composer – the majority of the code (including APIs, runtime, and UI)
  • composer-sample-networks – a collection of sample business network definitions
  • composer-sample-applications – a collection of sample applications
  • composer-sample-models – a collection of sample model files
  • composer-atom-plugin the plugin for the Atom editor
  • composer-vscode-plugin – the plugin for the VS Code editor
  • composer-tools – additional tools that are not part of the Composer “core”

The project was initially called “Fabric Composer”, and was renamed to simply “Composer” so as to encourage the other DLT framework efforts at Hyperledger to take a look and consider helping us implement support for them. However you will likely still see the terms “Fabric Composer” used in the documentation and source code until we get around to cleaning that up.

The majority of the Composer source code is JavaScript, and can be built and tested using the standard npm toolchain (“npm install” and “npm test”). We have aimed to use standard JavaScript tools as part of our development process: npm, Mocha (test driver), Chai (test assertions), Sinon (mocks), Istanbul (code coverage), etc.

What’s next?

By working with the community, we would like to continue to develop Composer to be a powerful and complete development framework that allows users to easily and rapidly build blockchain business networks.

Future work that the community is currently considering includes:

  • First class support for events; being able to model the structure of events, being able to publish events from a blockchain and allowing client applications to subscribe to and receive those events.
  • Links between multiple running business networks; for example, allowing one network to reference assets that are stored in another network.
  • Complex and historical query support, to allow powerful queries over assets, participants, and transactions and the relationships between those resources that have been recorded.
  • Investigate adding support for Iroha and Sawtooth Lake. Composer already includes a pluggable adapter layer that makes this possible. The majority of the Composer codebase is runtime agnostic. The runtime specific code is restricted to the connector implementations (client to blockchain) and the runtime container implementations (blockchain to common runtime).
  • Automatic, formal verification of Composer business logic. The smart contracts generated by Composer would be analyzed against the user-specified requirements written in the modelling language. The verification tool would output a statement that the smart contract is correct, or it would output a counterexample, explaining some way in which the smart contract does not meet its specification.

For those interested in additional information about Composer or any of the other frameworks or modules under Hyperledger, please reach out to: info@hyperledger.org. As always, we encourage developers to join our efforts via GitHub, Rocket.Chat the wiki or the mailing lists. You can also follow Hyperledger on Twitter.

Hyperledger Welcomes Project Indy

By Blog, Hyperledger Indy

Guest post: Phillip J. Windley, Ph.D., Chair, Sovrin Foundation

We’re excited to announce Indy, a new Hyperledger project for supporting independent identity on distributed ledgers. Indy provides tools, libraries, and reusable components for providing digital identities rooted on blockchains or other distributed ledgers so that they are interoperable across administrative domains, applications, and any other silo.

Why Indy?

Internet identity is broken. There are too many anti-patterns and too many privacy breaches. Too many legitimate business cases are poorly served by current solutions. Many have proposed distributed ledger technology as a solution, however building decentralized identity on top of distributed ledgers that were designed to support something else (cryptocurrency or smart contracts, for example) leads to compromises and short-cuts. Indy provides Hyperledger projects and other distributed ledger systems with a first-class decentralized identity system.

Indy’s Features

The most important feature of a decentralized identity system is trust. As I wrote in A Universal Trust Framework, Indy “provides accessible provenance for trust transactions. Provenance is the foundation of accountability through recourse.” Not only can Indy support user-controlled exchange of verifiable claims about an identifier, it also has a rock-solid revocation model for cases where those claims are no longer true. Verifiable claims are a key component of Indy’s ability to serve as a universal platform for exchanging trustworthy claims about identifiers.

Another vital feature of decentralized identity—especially for a public ledger—is privacy. Privacy by Design is baked deep into Indy architecture as reflected by three fundamental features:

  • First, identifiers on Indy are pairwise unique and pseudonymous by default to prevent correlation. Indy is the first Distributed Ledger Technology  to be designed around Decentralized Identifiers (DIDs) as the primary keys on the ledger. DIDs are a new type of digital identifier that were invented to enable long-term digital identities that don’t require centralized registry services. DIDs can be verified using cryptography, enabling a digital “web of trust.” DIDs on the ledger point to DID Descriptor Objects (DDOs), signed JSON objects that can contain public keys and service endpoints for a given identifier. DIDs are a critical component of Indy’s pairwise identifier architecture.
  • Second, personal data is never written to the ledger. Rather all private data is exchanged over peer-to-peer encrypted connections between off-ledger agents. The ledger is only used for anchoring rather than publishing encrypted data.
  • Third, Indy has built-in support for zero-knowledge proofs (ZKP) to avoid unnecessary disclosure of identity attributes—privacy preserving technology that has been long pursued by IBM Research (Idemix) and Microsoft (UProve), but which a public ledger for decentralized identity now makes possible at scale.

Indy is all about giving identity owners independent control of their personal data and relationships. Indy is built so that the owner of the identity is structurally part of transactions made about that identity. Pairwise identifiers not only prevent correlation, but they stop third parties from transacting without the identity owner taking part since the identity owner is the only place pairwise identifiers can be correlated.

Indy is based on open standards so that it can interoperate with other distributed ledgers. These start, of course, with public-key cryptography standards. Other important standards cover things like the format of the identifiers, what they point to, and how agents exchange verifiable claims. Indy also supports a system of attribute and claim schemas that are written to the ledger for dynamic discovery of previously unseen claim types. Relying parties can make their own entitlement decisions based on schemas with publicly known identifiers.

The result is a new way of doing systems integration on the Internet that is much less costly while also being more trustworthy. As I wrote in When People Can Share Verifiable Attributes, Everything Changes, owner-provided attributes are a powerful driver that will push decentralized identity systems well beyond the current uses of federation and social login. Organizations can reduce, or even eliminate, costly manual verification processes and API integrations, and instead trust the identity claims presented to them, precisely because these claims can be verified. People and organizations become the source of what’s true about them.

Indy Shares the Internet’s Virtues

As I wrote in An Internet for Identity, Indy shares three important virtues with the Internet: No one owns it. Everyone can use it. Anyone can improve it. Launching Indy as a Hyperledger Project is a critical component of allowing anyone to improve how Indy works.

These virtues are supported by Indy’s permissioned-validation ledger model and open-source code base. This has important consequences for scale and cost. But unlike other permissioned ledgers like R3’s Corda (http://www.r3cev.com/blog/2016/4/4/introducing-r3-corda-a-distributed-ledger-designed-for-financial-services) , CULedger (http://www.culedger.com/), or SecureKey (http://securekey.com/press-releases/ibm-securekey-technologies-deliver-blockchain-based-digital-identity-network-consumers/), Indy is designed for global public access. Even though Indy is permissioned, anyone can access Indy’s features.

Validation is performed by a set of validator nodes running a modified, redundant Byzantine fault tolerant protocol called Plenum that is part of the Indy project. Plenum allows for the group of servers run by the validators to come to collective agreement about the validity and order of events.

This diagram shows how these different dimensions of validation and access play across different distributed ledger systems.

What is the Relationship of Indy and Sovrin?

The Indy code base is being contributed to the Hyperledger Project by the Sovrin Foundation. Established in September 2016, the Sovrin Foundation is an international non-profit foundation created to govern a global public utility for decentralized identity. The trustees of the Sovrin Foundation believe the public, permissioned quadrant above is the only one that can achieve both high trust and global adoption for a decentralized identity system.

The Sovrin Foundation developed the Sovrin Trust Framework to govern how trusted institutions, called stewards, will operate validator nodes of the Sovrin Network. All stewards will run an instance of Project Indy. However the Sovrin Network is only one network designed to run Indy; any number of other networks may be created to run their own instances.

How Will Hyperledger Enhance Indy?

The Indy code base, originally developed by Evernym, was donated to the Sovrin Foundation to establish a strong open source foundation for the Sovrin Network. The Sovrin Foundation has been building a global community of developers who are passionate about Independent Identity and the economic and social benefits it brings to both individuals and enterprises.

Now the contribution of Indy to Hyperledger takes the next step in that process, opening up Project Indy to the entire Hyperledger family of developers. Our hope is to attract even more developers who want to unleash the transformative power of digital identity that is truly decentralized, self-sovereign, and independent of any silo. We would also like to explore direct synergies with the identity management goals and requirements of the other Hyperledger projects.

Learn More about Indy

To learn more or contribute to the Indy project:

And for those who want to learn more about the Sovrin Foundation:

For those interested in additional information about Indy or any of the other technical projects under Hyperledger, please reach out to: info@hyperledger.org. You can also plug into the Hyperledger community at github, Rocket.Chat the wiki or our mailing list.

 

[VIDEO] Hyperledger Interviews Amber Baldet, JP Morgan

By Blog, Finance

We recently sat down with Amber Baldet, blockchain program lead at JP Morgan. JP Morgan is one of the Premier founding members of Hyperledger.

JP Morgan is a big supporter of open source software and was thrilled to see a community coming together around open source standard setting for blockchain and DLT. Last year, they announced work on Quorum, a privacy preserving version of Ethereum via Hyperledger’s TSC.

JP Morgan is currently exploring blockchain to discover ways of doing more complex asset transfer, while maintaining security and understanding the concept of value. Amber looks forward to seeing how their work on Quorum can be additive to the overall Hyperledger community. According to her, Blockchain tech is transformative to the financial services industry and as the largest investment bank in the world, JP Morgan is committed to shaping the future of the technology.

Watch the full interview below:

Hyperledger’s Monthly Technical Update

By Blog, Hyperledger Burrow, Hyperledger Cello, Hyperledger Composer, Hyperledger Explorer, Hyperledger Fabric, Hyperledger Iroha, Hyperledger Sawtooth

As our incubated projects continue to mature, we’d like to update the community monthly on the progress we make. Below are updates on Blockchain Explorer, Fabric, Cello, Iroha and Sawtooth Lake during April. An update on Burrow will be included in May’s blog.

Hyperledger Blockchain Explorer

  • We are actively working towards implementing Explorer as per the architecture document. We are planning to make the initial release compatible with Hyperledger Fabric v1.0.

Hyperledger Fabric

  • The v1.0.0-alpha release was published just prior to the previous Governing Board meeting. The past month has been focused on planning out the end-game for the v1.0 release – including deciding how we will manage the process, and what remaining feature work must be included
  • We have also been working on cleaning up JIRA, so that we can focus on a truly JIRA-centric process of managing releases going forward to close out v1.0 and beyond
  • There have been improvements made to the bootstrap process to enable deployment on Windows and in documenting some sample applications.

Hyperledger Cello

  • Fixed the build-up problem on MacOS, now we support both linux and MacOS to run Hyperledger Cello
  • Add host operation fill up/clean/reset supported in dashboard with react theme
  • New sub-project Cello-analytics was started to help maintain those operational/analytics tools
  • Intern candidates on Hyperledger Cello are under review to select
  • Updated the design and contribution documentation
  • Connected with Cloudsoft to have a online demo to make decision to collaborate on the project

Hyperledger Iroha

Hyperledger Sawtooth

  • Hyperledger Sawtooth is on track to release v1.0 mid-summer.
  • Supply Chain demo added to Hyperledger YouTube channel
  • Recommended version and default docs upgraded to 0.8. 0.7 is now considered legacy. Once 0.8 is feature-complete and passing various quality criteria it will be promoted to 1.0.
    • Proof of Elapsed Time (PoET) migrated to 0.8 architecture.
    • Validator Registry migrated to 0.8
    • Added trusted validator signup on genesis tool
    • Created deb-only docker images for all components
    • Migrated load generator from 0.7/stable to 0.8/master
    • Implemented ZMQ ‘Ironhouse’ security on interconnect
    • Added support for parallel scheduler to context manager
    • Added several REST API features
    • Completed the Completer which aids peering by accounting for locally missing blocks and batches
    • Completed a number of CLI tools which benefit on-chain settings
    • Gossip improvements

That’s it for the updates! We encourage developers to join our efforts on these projects. You can plug into the Hyperledger community at github, Rocket.Chat the wiki or our mailing list. You can also follow Hyperledger on Twitter or email us with any questions: info@hyperledger.org.

Happy coding!

Regulators and Industry Groups Continue Blockchain Efforts

By Blog

Guest post: Matthew Comstock, Shareholder, Murphy & McGonigle, P.C.

Regulators and industry groups continue their efforts to understand blockchain technology and its implications for the securities, futures and related financial sectors. Importantly, regulators and industry groups have not yet advocated for or against any particular type of blockchain technology. Rather, efforts have largely centered on defining what, in the view of those regulators and industry groups, blockchain technology is, how it may be used in the financial services industry, and what the regulatory implications are for its use.

The various financial industry regulators and industry groups have not coalesced around a single definition of blockchain technology. Their definitions, however, typically describe blockchain as a technology that involves a type of distributed-ledger technology that includes a decentralized, public or private peer-to-peer network that records transactions that occur through the network in shared digital ledger.   

The U.S. Securities and Exchange Commission (SEC), the primary federal regulator for the securities industry, appears to have begun formal work on blockchain-related matters with the establishment of the Digital Currency Working Group, which started around 2013. Since that time, the SEC has been asked to clarify whether digital currencies are securities; approved a registration statement to become effective that permitted a company to sell digital securities to the public; and held a FinTech Forum in the fall of 2016, which included a panel on blockchain technology (panelists included members of Hyperledger). In March of this year, the SEC issued two separate controversial blockchain-related orders. It disapproved proposed changes to the rules of two securities exchanges that would have permitted the Winklevoss Bitcoin Trust to trade on one exchange, and the Solid X Bitcoin Trust to trade on another. Each trust would have traded as an exchange traded product, with bitcoin as its the underlying asset. In disapproving the proposed rule changes, the SEC essentially took the position that lack of regulation surrounding bitcoin markets made bitcoin, and thus the trusts, susceptible to fraud and manipulation.

The Financial Industry Regulatory Authority, Inc. (FINRA), which oversees securities brokerage firms (subject to the ultimate supervision of the SEC), recently issued a report (the “FINRA Report”) on blockchain technology. The FINRA Report (1) described blockchain technology; (2) discussed potential applications of blockchain technology to the securities industry (e.g., issuing and trading public company stock on a blockchain-based platform, and centralizing customer identity management functions); (3) identified potential impacts on the securities industry, such as increased transparency (e.g., by maintaining a database containing the complete histories of securities transactions, and altering or eliminating the roles of financial intermediaries); and (4) addressed implementation considerations, such as governance (e.g., “trustless” network open to the public with no single party responsible for the proper operation of the system, versus a private network with parties known and trusted, and transaction validation (consensus-based versus single-node verifier).

Finally, the FINRA Report discussed certain regulatory implications arising out of securities brokerage firms’ use of blockchain technology, particularly with respect to financial responsibility requirements. For example, FINRA raised an issue as to how brokerage firms could meet their regulatory obligations to take custody of “cryptosecurities” held on a blockchain network on behalf of customers. Moreover, FINRA asked whether cryptosecurities held by a brokerage firm would have a “ready market,” i.e., a liquid market, so that firms’ holdings of such securities would be allowable (liquid) regulatory capital. The FINRA Report also noted the brokerage firm records that are maintained electronically must be kept in a non-rewriteable, non-erasable format (also referred to as “write once, read many” or “WORM”). Although blockchain is arguably a superior recordkeeping technology, FINRA nevertheless asked whether a brokerage firm records maintained on a blockchain network would meet the SEC’s WORM requirement.

An organization that primarily represents brokerage firms and asset managers, the Securities Industry Financial Markets Association (typically called “SIFMA”), is in the process of drafting a comprehensive response to the FINRA Report. SIFMA members have indicated that SIFMA’s response will advocate that any guidance regulators provide, or principles that regulators formulate with respect to blockchain, be technologically neutral.   

The International Organization of Securities Commissions (“IOSCO”) recently issued the “IOSCO Research Report on Financial Technologies (Fintech)” that included a discussion of distributed ledger technology.  IOSCO noted that blockchain is one subset of distributed ledger technology, distinguished between permissioned and permissionless systems, described proof-of-work and proof-of-stake consensus algorithms, and emphasized the role tokenization and smart contracts are likely to play in applying distributed ledger technology to the financial services industry. The IOSCO report also identified potential application of distributed ledger technology to the financial services industry in areas such corporate recordkeeping; trading and settling transactions in certain types of financial instruments; ensuring that certain regulatory requirements are met (e.g., compliance with anti-money laundering rules); creating individual IDs to be used in financial transactions; and improving the speed, efficiency and security of financial transactions, among other things.  

The U.S. Commodity Futures Trading Commission (CFTC), the federal agency tasked with overseeing futures intermediaries, among other things, recently proposed to modernize the CFTC’s recordkeeping rules for such intermediaries.  The proposed rules are intended to be technology neutral, and would take a principles-based approach to recordkeeping. Among other things, futures intermediaries would be required to maintain security, signature, chain of custody elements and data as necessary to ensure the authenticity of the information contained in regulatory records.

The efforts described above built upon, among other things, earlier white papers from The Depository Trust & Clearing Corporation and the Board of Governors of the Federal Reserve System.  Expect regulators and industry groups to continue their efforts around blockchain technology.

[VIDEO] Hyperledger Interviews Hanna Zubko, IntellectEU

By Blog

We recently sat down with Hanna Zubko, Co-founder and VP of business development at IntellectEU. IntellectEU is a general member of Hyperledger.

IntellectEU plans to continue to build out several blockchain proof of concepts in 2017 but they are also looking to expand their footprint into other various industry verticals. Hanna explains that it is important to their stakeholders to be able to build a solution using blockchain technology that is enterprise ready and scalable.

Hanna believes a key benefit of joining Hyperledger is the community. She encourages any institution that is experimenting or interested in building blockchain solutions to join. With Hyperledger, IntellectEU can harness the benefits of this new technology and is at the bleeding edge of blockchain.
Watch the full video below!

Meet Hyperledger’s New Security Maven!

By Blog

We’re thrilled to announce that the Hyperledger team is growing! We’ve recently added David Huseby as the Security Maven.

David brings more than 20 years of experience working with and on open source projects in industries including aerospace, video games, and web, both server and client side. For the last decade he has focused on privacy enhancing technology, user anonymity and anti-surveillance. Most recently he was a senior platform security engineer at Mozilla where he focused on web privacy and led the project to merge Tor Browser hardening into Firefox.

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

What got you interested in working on Hyperledger and blockchain?

I am a long-time Bitcoin user and enthusiastI mined my first Bitcoins when they were worth just $4.00 USD. The blockchain technology in Bitcoin has always fascinated me and like everybody else I immediately saw its potential for solving persistent problems in a variety of other industries. Working on blockchain technology has been on my to-do list for years. I was attracted to the Hyperledger project because of its solid community leadership and the integrity of The Linux Foundation. When I was given the opportunity to work on all-things-security and all-things-blockchain at The Linux Foundation, I could not refuse. I am very excited to be joining the team.

David Huseby, Hyperledger’s Security Maven

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

I’d like to work with the community to maintain and grow the trust in our projects. Taking inspiration from other successful open source projects, I’d like us to document a set of software development and deployment best practices that all of the Hyperledger projects follow consistently. Projects like the Linux kernel, the Bitcoin core, and the Tor project have pioneered great standards for managing change and integrity during software development and deploymentwe would do well to emulate them.

I also want to partner with our project teams to build a security vulnerability reporting system that minimizes the friction of reporting security vulnerabilities responsibly.  In addition to the reporting system, I would like to organize and coach a security triage team for driving issues from reporting all the way through resolution and disclosure.

It is also important that we get out ahead of any security related regulatory issues in markets like finance and healthcare.  I’d like to work with our member partners to plan for and minimize the roadblocks for Hyperledger projects moving into regulated industries (i.e. being prepared for audits and code escrow, etc).

In addition to the above projects, I am taking a special focus on the identity problem. I plan to learn all I can about any future projects that fall under Hyperledger regarding personal identity and personal data management with blockchains. Having a good answer to the identity problem is one key element to the success of many of the Hyperledger projects.

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

Blockchain technology is being applied to systems where lapses in security can result in serious consequences. I think our greatest challenge is to nurture and grow the great software engineering culture that already exists in all of the Hyperledger projects.  Security is ultimately a human problem and having good engineering culture naturally leads to consistent application of best practices. In the next year I hope to partner with the community to bring best practices such as signed commits, merges, and releases, dependency tracking, sign off accountability, and responsible disclosure of vulnerabilities to all of the Hyperledger projects. That is how we will maintain the trust of our partners and the broader community that relies on the technology we create.

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

I hope that we can solve the identity problem in such a way as to maximize the privacy and sovereignty of everyday people. So much of the computerized world is dedicated to tracking people and monetizing that information. I hope blockchains give me back control over my private self while also lowering the friction of proving that “I am me” to the myriad of balkanized systems. The last time I checked, my password manager had account credentials for over 200 different separate services that I use. Why can’t there be just one cryptographic proof for “this is me”?  And why can’t I be asked to approve what data gets shared? I truly hope we solve this problem, or at least find a good enough solution for most people.

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

In five years I hope Hyperledger is universally respected for having nurtured cooperation and leveraged technical and industry expertise to bring blockchains to market and to make tangible improvements in many different industries. I half-joke that if Apache helped make the Web, maybe Hyperledger can help make the Web easy.  Having a universal identity solution, cryptographically secure ways to share data, and auditable access to digital records would go a long way in making the Web easier for everybody. Hyperledger and The Linux Foundation is the natural place for that level of Internet-wide cooperation and in five years, I hope we will have succeeded.

What’s one thing you wish people understood about security?

I wish people understood that security is mostly a people problem. We’ve all heard stories of bad passwords being the weak link in an otherwise secure system. Having good security is like having good hygiene. It takes diligence and constant attention and strong passwords.

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

I always live by these two pieces of advice:

  1. If something is worth doing, it is worth doing right. (Thanks D). To me, this means that I should be picky in what I commit to so that when I commit, I am all in.
  2. Always have your passport. (Thanks A). Living by the first piece of advice is intense and this second piece of advice means I never miss a chance to stop and have fun. Sometimes the right answer is to get on the next plane to somewhere, anywhere, and go have fun.

What do you like to do in your spare time?

I live in Las Vegas so what don’t I do in my spare time?  Seriously though, I enjoy spending time with my friends at the Synshop Hackerspace. I am an occasional guest on the Greynoise podcast that is recorded at the Synshop every Friday evening. I also enjoy exploring the south western states, going on hikes, camping, and getting outside in general.  A few months ago I decided to start corresponding with friends through handwritten letters and because if something is worth doing, it is worth doing right, I started teaching myself Spencerian calligraphy to up my power level. I think my favorite thing to do is make new friends, so please, if you see me at a conference or a meetup somewhere, don’t hesitate to come say “hi”; we might become pen pals.