I am with my tribe at DEVCON3

I have just landed in beautiful Cancun, Mexico, for the DEVCON3 conference which starts on Wednesday.


DEVCON is the crowd jewel of the Ethereum community, where developers, business people and enthusiasts of all stripes gather in one place to hear the latest news about this fantastic platform which we are building together.  Right from the mouths of the developers who are at doing that every day.

Unlike many other blockchain events, DEVCON is always about the technology and the people – never about money.   It is a developer conference, with many deeply technical sessions.  It is a delight.

These are my people.   I will be with my tribe this week.   I can’t wait.

Bob’s Next Adventure


My active Ethereum journey has been underway for well over two years now, starting in the months leading up to Frontier launch in July 2015 when the mainnet went live.   I had been lucky enough to meet Vitalik even earlier than that, back in 2014, when my friend David Lowy hosted a dinner for Vitalik and various interested Vancouver locals as he was in town for the day.


Left-to-right: Manie Eager (Chairman, Blockchain Association of Canada), Alex Alexandrov (CEO, CoinPayments), MaRi Eager (Co-Founder, Digital Futures), Lauren Richer, Vitalik Buterin, Ward Stirrat (CMO, Coinpayments), Bob Summerwill, David Lowy.

David was one of the first customers at the world’s first Bitcoin ATM, right here in Vancouver in October 2013, and was heavily involved in Bitcoin for many years before that.  His first Bitcoin trades were at 5 cents.  in 2010 he sought out and acquired the domain name Bitcoin.com, later selling it for a substantial profit.

David has been quiet for the last few years, but will soon be launching a very exciting project which has been in gestation for many years.   Keep your eyes on this man.  He is the reason that I am in this space, and I was very lucky to meet and become friends with him when I did!   He is a visionary.


By 2015 I was living in Toronto and took advantage of their great crypto Meetup scene.   Techno Crypto with Jeff Coleman at Decentral, Ethereum Toronto Meetup with Paul Paschos, DEC_TECH at the Mars Discovery Centre with Anthony Di Iorio.

This photo was from a special session of the Ethereum Toronto meetup just prior to the Frontier launch, showing some other familiar faces 🙂


Left-to-right:  Paul Paschos, Ethan Wilding (Co-Founder, L4 Ventures), Vitalik Buterin, Nick Dodson (ConsenSys, GovernX), William Mougayar (many hats) Michael Perklin (CISO, ShapeShift)

I started doublethink.co and hired Anthony Cros to start working on cpp-ethereum-cross while my days were full at TD Securities.

Later that year on my return to Vancouver, I was able to get hands-on with that project, seeking to get an Ethereum light client working on a Gear S2 smartwatch.   That work morphed into helping out the cpp-ethereum project which morphed into a part-time job on Christian Reitwiessner’s team, which then morphed into a full-time role.  On we went through Homestead, major build system and DevOps work and the repository restoration of cpp-ethereum-1.3.0 (“Homecoming”), the DAO fork, the failed Apache 2.0 relicensing attempt and on to the amazing DEVCON2 conference in Shanghai.

I had real hope there with the arrival of Brian Behlendorf as Executive Director at Hyperledger (who I met at OSCON in Austin that April) that we could forge a shared future which could see both public-chain and private/consortium chain systems built on top of a common kernel, a la Linux, and bring all these communities together.  Alas, it was not to be.


With Ethereum/Hyperledger grand unification off the table, I was delighted to have the opportunity to work towards the goal of Ethereum Everywhere again as Joe Lubin hired me to work to help form the Enterprise Ethereum Alliance at ConsenSys.  The EEA launched earlier this year in New York and is now the largest blockchain consortium in the world with over 200 member companies.

The photo below was taken at the JP Morgan offices in Brooklyn during our second round of face-to-face meetings in the run-up to the EEA launch, with Shahan talking Vitalik through our technical vision.


Left-to-right:  Bob Summerwill, Kirk Dameron (ConsenSys), Shahan Khatchadourian (ConsenSys), Joseph Chow (ConsenSys), Vitalik Buterin, Amber Baldet (JP Morgan).

Joe is one of the most inspirational and enlightened leaders who I have ever met, and ConsenSys is one of the most unique places that I have ever had the pleasure of working at.   This is going to be a world-renowned company in the very near future.  It is already getting there and can now hire the cream of the crop.

Gather smart people.   Empower them.  Go!  Just magic.


[From Can Ethereum Restore Online Freedom & Transform the Internet?]

After a year of mainly organizational work at the EEA, it is time for a new challenge – back in a hands-on development role.   In all of this time within the Ethereum ecosystem, I have never built a decentralized application at really large scale.   It is time for me to do just that at Sweetbridge.   Their ambitious and transformational goals have inspired me.  I could not resist the challenge!   I will be joining their protocol team as Principal Developer.

Sweetbridge is also building an alliance to work towards a liquid supply chain on blockchain technology.   Scott Nelson, their fantastic CEO, can explain The Vision much better than I, but the starting point is solving structural inequalities related to access to capital within global supply chains, which form two-thirds of the world economy or $54 trillion in annual trade

Screen Shot 2017-10-18 at 2.42.03 PM

What’s really unique and special about Sweetbridge and what attracted me to them is their team and it’s depth of invaluable industry experience (many 20-30 year veterans). Scott had the vision to build this platform for more than a decade, recognizing the blockchain is the technical innovation that unlocks the potential to turn this dream into a reality.

These are good people.   How many companies have you seen who lead off with a series of Medium posts on their Core Beliefs?   This is just fabulous to see.


One of the primary advisors to Sweetbridge is Vinay Gupta, an Ethereum community and cypherpunk old-timer and hugely prescient thinker who I have been following and engaging with for several years, but still never met in person.    I really look forward to collaborating with Vinay more closely as part of my work at Sweetbridge.

Block off some time to watch this awesome video where Scott and Vinay deconstruct the problem-space:
The Ultimate Gupta vs. Nelson Blockchain + Supply Chain Throwdown.


In addition to my work at Sweetbridge, I will also be advising Frontier Foundry, who are based right here in my home town of Vancouver.   They also have a great leader in the form of Boris Mann, whom I have known since 2015.  Our paths crossed in a wearables/blockchain context.    Boris has been involved in the startup scene, angel investing, advising, open source ecosystem building and more for many, many years and is now bringing those talents to bear full-time in the blockchain world.  Frontier is building a global investment platform for blockchain based capital pools.  Check them out!

I am also getting more involved in the Vancouver crypto-business community, which is growing in leaps and bounds in 2017.   We had the ADI Summit in September which I spoke at, and have had the inaugural meetings of Blockchain for Product Developers and BC Blockchain Forum meetups in the past couple of weeks.   We have Blockchain @ UBC, and we have active discussions ongoing with the BC regulators.   It is all great to see, and Frontier are primary drivers of this change.


Boris Mann (Frontier Foundry)

So that’s what I will be up to next.   It should be a lot of fun.    I wish all my former colleagues at ConsenSys and the EEA the best of luck for the future as we continue to build this new ecosystem together.   As Joe recently said at ETHWaterloo, we are still in the “first minute”, and have years of collaboration and building ahead of us.   Our paths will cross many times again in the future.

For anybody thinking, “You have a lot of photos of people in this article, Bob,” well, yes, I do.  Because it is always about the people.   They are what make the technology work.

I hope to be face-to-face with many of the fabulous people in this community very soon.  See you in Cancun for DEVCON3.

Cancun Strand Luftbild

What’s been happening in the EEA?

I’ve had a number of people asking me recently what has been happening on the technical side of things within the EEA over the last month or so.   The answer to that question is “lots”, but it has mostly been churning under the surface.

[Churning Water by Indi Samarajiva]

The mundane reality of setting up a new organization on the scale of the EEA is that you need a lot of structure, defined operational processes, rules and bureaucracy.   Without that you have lots of talk and nothing much being achieved.

There is also plenty of administrative work to be done, which Virtual, Inc. have recently come on board to help with.   We don’t have an Executive Director.   We don’t have any permanent staff (yet).

In retrospect, our initial efforts at a Technical Working Group were pretty ineffective, so we’ve taken a step back and looked at the broader goals of the EEA.   What are we trying to achieve as an organization?   How are we going to tackle that?  What is a Committee?   What is a Working Group?   How can we decompose the problem space?  What is a rational scope for each of these groups to consider?    Where and how can EEA members best get involved?   How do we avoid stepping on each others toes?   What should happen inside EEA and what is best left to the members outside of the EEA?

We didn’t have good answers on some of these matters.   We’re getting to much better answers now, I think, between the board, Virtual, the governance committee, Alex Batlin and myself.   These new documents are still under review, but should be in a state to be shared with the membership very soon.   They should give us a solid basis on which to proceed, and if they still aren’t feeling quite right then they can be revised further.

The break in momentum for the last few weeks has been quite painful, but was very necessary, I think.   The EEA was brought to life in record time, and the level of interest has been astonishing.   Going from nothing to having a 100+ company organization within a few months is really hard.

The aim of this downtime and seeming inaction has been to ensure that we have the structure in place such that all EEA members can get involved and productive moving forward.   If you have felt unsure, or excluded, or confused by the EEA to this point, I would like to extend my apologies to you.   I will try to blog regularly from this point onwards.

The Technical Steering Committee should be rebooted within a week or two.   We should also have more Working Groups in an active state, and have clear processes for our members to get involved and help driving this cruise-liner towards our mutual goals.

The Technical Mailing List is the best way to communicate between ourselves.    I would still encourage members to introduce themselves and their interests there.   Even in the absence of organizational clarity, please don’t stop talking!

The following technical working groups exist in an early form and will soon be relaunched with clear charters and defined goals:

  • Consensus Algorithms WG
  • Identity WG
  • geth and Quorum WG
  • Python Client WG
  • Integration and Tools WG

We have also identified that we will need to launch working groups on at least the following additional topics:

  • Data Privacy WG
  • Access Controls WG
  • Documentation and Specifications WG

There are plenty of other working group proposals floating around too – though many of them related to specific industry verticals or problem spaces, so I won’t list them all here.

I am always happy to talk to anybody, so if you are an EEA member (or EEA prospective member) with questions, please feel free to contact me at bob@summerwill.net, or https://twitter.com/bobsummerwill or https://linkedin.com/in/bobsummerwill.

Here are links to our Confluence site and to the main website.

EEA Technical Working Groups Need YOU!


The Enterprise Ethereum Alliance (EEA) has a number of technical working groups (WGs) already in motion:

Self-organizing working groups are intended as the primary mechanism for members to contribute to the EEA.    There were 30 member companies at launch, and it appears likely that number will grow rapidly in the coming months.   It is impractical for every company to be represented on the primary committees without those bodies becoming unwieldy and ineffective.

HOWEVER, there are numerous topics where coordination within working groups would be very beneficial, and much of this work can happen in parallel.  This breadth of effort should allow us to take advantage of the scale of talent and resourcing available across our collective membership without getting bottlenecked.

If you haven’t got involved in any of the working groups yet, the best place to start is by joining the Technical Mailing List, which is acting as the “lobby” for the working groups.

Please introduce yourself and share your interests.   Better yet, offer to create and lead new working groups where you see a need.    We don’t have heavyweight process.   The most important thing is for the conversation to get started.   There is a suggested template to help clarify scope.  There are Confluence pages for each group here.    You do not need anybody’s permission to create a new sub-group.

The intention of the EEA is not to dictate any kind of top-down structure, but for members to self-organize around their key requirements and needs, and for those groups to make concrete proposals which then filter upwards to define our standards and best practices.    With that caveat in mind, here are some possible Working Group ideas which have been raised in the past and might make sense:

  • Benchmarking
  • Testing
  • Architecture
  • Security
  • Cryptography
  • IoT
  • Best practices
  • Interoperability
  • Requirements and use-cases
  • [Bring your own suggestions]

So please do jump in and help!   Many thanks.

New Granville Island Office


I had been working from a coffee shop every day for the best part of the year.   That was just fine in most respects, but it has meant that I never completed the setup of my hardware test farm for cpp-ethereum-cross.   It was time for me to look at rented desk space again.

I found a real beauty of a spot which was newly available on Granville Island, right by the water, in a converted houseboat, by The Profile.    I am already finding lots of common interests with my coworkers.   There is an old TV, and my Atari 2600 and Commodore 64 are definitely going to get hooked up 🙂





C++ re-licensing plan


This is a proposal to re-license the C++ implementation of the Ethereum client runtime (cpp-ethereum) from the copyleft GPLv3 license to the permissive Apache 2.0 license, to enable Ethereum to be used as broadly as possible.

NB:  If you would like to discuss this plan, please let’s all do so on cpp-ethereum Gitter channel.   Thanks!

Moving to permissive licensing has been the “plan of record” for a year or so, which we are belatedly executing on.   Gavin Wood actually started the process of relicensing to MIT last year, but it was never completed.    So we’re going through the process again now.

There is another long-form article talking about the rationale for the change and the history leading up to this proposed change of licensing, so I won’t duplicate that content here.

This post talks through the expected operational steps for making this change.   These steps aren’t entirely sequential, and we will be doing overlapping steps in parallel wherever we can, to try to get through the tedious process as quickly as we can.

Ultimately the contributors to the C++ codebase will make the decision on whether or not we relicense, and there is no intention from the Ethereum Foundation to “force” the process.



Steps to be followed

  • Creation of a Github issue to start the ball rolling                       [started May 25th]
  • Start to gather contributor details (Piratepad, then Wiki)         [completed July 7th]
  • Mention in the last few releases that we are contacting contributors  [May, June, July]
  • Ad-hoc conversations with contributors on the issue, Gitter, email   [Ongoing]
  • Talk to an IP lawyer to verify what we need to do, in rough strokes   [June 22nd]
  • Publicize “the plan” and work through any disagreements      [July 12th onwards]
  • Distribute paperwork to all contributors     [August 18th to August 24th]
  • Complete the process and change the license
  • Announce that change to the world



What is the paperwork?

Everybody who has contributed to the code in question (see below) will be sent a letter, probably both as a PDF and physically, which essentially attests to the fact that they were the author of that code, and giving their approval for that contribution to be used under the Apache 2.0 license.

Future contributors will be required to make a similar declaration.    The one page document just ensures that there is no ambiguity for any party in the case of future disagreement or legal action.

Here is a template for the paperwork, which is legal boilerplate from the Linux Foundation adjusted to our project.

This is not final paperwork.   Discussion ongoing.


Content to be relicensed

The following repositories are in the process of being reorganized into a restored cpp-ethereum repository, which will be relicensed as Apache 2.0:

That will include the following applications:

  • Ethereum VM:
    • eth
    • ethvm
  • Unit-testing:
    • testeth
    • testweb3
    • testweb3core
  • Support tools:
    • bench
    • ethkey
    • ethminer
    • rlp

The following standalone repositories will also be relicensed to Apache 2.0:

The following repositories, containing the Solidity compiler and the deprecated C++ GUI applications will remain under GPLv3:

The following repository, containing the new “Remix” debugging components will remain under MIT, though we might want to consider whether that should be Apache 2.0 as well?

Ethereum Everywhere

“The Ethereum Foundation’s mission is to promote and support research, development and education to bring decentralized protocols and tools to the world that empower developers to produce next generation decentralized applications (dapps), and together build a more globally accessible, more free and more trustworthy Internet.”
From https://ethereum.org/foundation


TL;DR – What are you proposing?

I am proposing to the contributors that the C++ Ethereum client runtime (cpp-ethereum) be re-licensed from the copyleft GPLv3 license to the more permissive Apache 2.0 license, to enable Ethereum software to be used as broadly as possible (a long-standing plan).   This proposal only addresses the C++ client runtime and does not include Solidity or Mix (the C++ tools).

There is another blog post detailing the likely operational steps in that process.   This document seeks to explain why I am making that proposal.


What is Ethereum?

When we think about Ethereum, we usually think about public chain, and more specifically we think about the public chain (the “mainnet”).    That is quite natural within the frame of reference of Ethereum purely as a cryptocurrency, but it is a limited view of the possibilities which this new decentralized computing platform offers.

Ethereum is much more than “a better cryptocurrency”.   Ether is the fuel for the engine, but it is the Ethereum engine itself which opens up these new possibilities.  The fuel is just a means to an end.

We have the opportunity to build a set of technologies in the next few years which could have similar societal impact as when the Internet, the World Wide Web and open source languages, databases, etc. became available.  We are building a decentralized computing platform which every individual on Earth should benefit from.

These technologies need to reach into every nook and cranny of our computing fabric: big and small, public and private, independent and corporate; smartwatches to mainframes.

This is a large and ambitious undertaking that is addictive and all-consuming for many of us.  Diversity of viewpoints, a broad spectrum of use-cases to mature the base technology, and an open and inclusive attitude and environment of collaboration will help us achieve our shared goals.


Why do private and consortium chains matter?


“It is important to note that while the original Ethereum blockchain is a public blockchain, the Ethereum state transition rules (i.e. the part of the protocol that deals with processing transactions, executing contract code, etc.) can be separated from the Ethereum public blockchain consensus algorithm (i.e. proof of work), and it is entirely possible to create private (run by one node controlled by one company) or consortium (run by a pre- specified set of nodes) blockchains that run the Ethereum code.”

“Ethereum technology itself is thus arguably agnostic between whether it’s applied in a public, consortium or private model, and it is our goal to maximally aim for interoperability between various instantiations of Ethereum – i.e. one should be able to take contracts and applications that are written for public chain Ethereum and port them to private chain Ethereum and vice versa.”

Vitalik Buterin, Ethereum Platform Review paper


Many individuals and companies, large and small, see that opportunity the Ethereum platform has to offer, and are equally supportive of and inspired by the technical vision, even if their business goals vary dramatically. Public chains and private or consortium chains will likely end up having a lot more in common than meets the eye.

We have a working example of a permissioned Ethereum chain in the form of HydraChain, which was demonstrated at Ethereum DEVCON1 last November (2015):

Consortium chains can provide certain benefits beyond the general purpose public chain because they are special-purpose, such as:

  • They can choose to have 1 second block-times.
  • They might not need to do any node-discovery because the nodes are fixed.
  • They can have incredible throughput (e.g. JP Morgan’s Juno boasts 2,000 txns/sec).
  • They can modify consensus rules for performance (i.e. using PBFT).
  • They can be a testbed for experimentation and innovation, because there will often be much smaller groups of stakeholders.

The interest in Ethereum can be seen in the ever-growing volume of news stories about blockchain and decentralized ledger technologies in general, but in particular, the interest in the Ethereum platform emanating from  major technology companies has escalated rapidly and noticeably since the last Ethereum developer conference, DEVCON1, which was held in London in November 2015.

The Ethereum platform is unique in the crypto space in  that a significant number of  large publicly owned corporations are either already using it, have experimented with it, or are exploring how it may be used in or integrated with their current systems.

The author believes providing a permissive licensing will facilitate moving towards the dream of mass adoption of the Ethereum platform.

Some articles from Vitalik Buterin on private and consortium blockchains:


Why permissive licensing over copyleft?

Software licensing is obviously somewhat of a religious matter, but there are practical reasons to favor permissive licenses for low-level components like Ethereum.

Beyond incompatibility between the GPL and corporate business models there are practical ways in which the GPL reduces Ethereum’s reach.   The author was witness to these restrictions in his “past life” as a video games developer.

Worst of all are the games consoles.   Code for PlayStation and XBOX usually has to be closed-source, because developers must sign NDAs (non-disclosure agreements) to be allowed access to the SDKs and they cannot redistribute those SDKs or any information about the platform APIs.   That is commonly interpreted to include any code using those APIs.    Some embedded platforms are similarly locked down.

While we could argue until the cows come home about the ethics of even using such systems, they are a reality, and making Ethereum available on them has value.

The Apple stores – App Store for iOS and Mac Store for macOS – are incompatible with the GPL, and the same is likely true of the Windows Store.    The Terms of Service are applying additional constraints which are incompatible with the GPL.

The only “workaround” which I have seen for this incompatibility is for there to be a single copyright owner for the software, such that they can dual license it as GPL and commercial, and for the commercial version of the software to be used in the App Store.   That is the approach which Mono used for nearly a decade, which means that developers wanting to use C# on iOS had to pay for a commercial license for Mono for all that time.

Open Whisper Systems recently added an exception to the GPLv3 license for their libsignal-protocol-c library, which permits people to incorporate that library into applications distributed through the App Store under Mozilla Public License 2.0, providing that the licensees are otherwise in compliance with the GPL.   That exception looks similar to dual-licensing, but seemingly only applies for iOS.

That dual GPL/commercial licensing approach is a sensible approach for open-source friendly companies to take, which balances their desire to make the code available for public good while also generating revenue to keep them alive from those end-users who want or need to use the code in a context which is not GPL-compatible.

Dual licensing is the approach which Mono took, which Qt have recently switched to and which Ethcore are following with Parity.   That dual licensing approach doesn’t work well for a Foundation, though, which is explicitly non-profit.

The choice of GPL for a Foundation just reduces the contexts in which the code can be used, because offering a commercial license is not really possible.    Commercial licensing would be incompatible with the non-profit mission of the Ethereum Foundation.

More importantly, though, the Foundation does not own the code to be able to offer the code under a commercial license, because the Foundation has intentionally not required copyright assignment from the contributors.

What licenses does the Ethereum Foundation use?

At the moment we have a bit of a mixed bag.    This proposal is only considering the C++ codebase, but it might make sense to look at licensing for the codebases as a whole.

  • go-ethereum – GPLv3 and LGPLv3
  • cpp-ethereum – GPLv3
  • pyethereum/pyethapp – MIT
  • ethereumjs-lib – MPL 2.0 and MIT
  • remix – MIT
  • web3.js – LGPLv3


Why Apache 2.0?

There are numerous permissive software licenses which are OSI approved, with a much shorter list of popular ones (really boiling down to MIT, BSD and Apache).   Why are we favoring Apache 2.0 for the C++ codebase, where we had previously favored MIT?



See License compatibility from Wikipedia.

It essentially boils down to compatibility with GPLv3 in combination with protection from future software patent claims, which is obviously hugely important to Ethereum.

Apache 2.0 is the Free Software Foundation’s own recommendation for permissive licences for that very reason:

“This is a free software license, compatible with version 3 of the GNU GPL.”

“Please note that this license is not compatible with GPL version 2, because it has some requirements that are not in that GPL version. These include certain patent termination and indemnification provisions. The patent termination provision is a good thing, which is why we recommend the Apache 2.0 license for substantial programs over other lax permissive licenses.”

Various Licenses and Comments about them, Free Software Foundation


About the Ethereum C++ client

The Ethereum C++ project has spent the last few months rebooting under the leadership of Christian Reitwießner, who is probably best known as the lead developer on Solidity, but also leads work on Mix, Remix and on the C++ client.


A number of the original C++ development team departed last year, with Christian, Yann Levreau, Liana Husikyan and Dimitry Khoklov staying on.  Bob Summerwill and Greg Colvin were added to the team in February, and Paweł Bylica rejoined the Foundation in March.

Christian has blogged about our progress in FebruaryMay and July.

We are on the verge of finally decoupling Solidity, (Re)Mix and Eth, so that we have three entirely independent projects – one runtime, two tooling.

That architectural decoupling is a dual-edged sword, because that tight coupling did a lot to keep the eth client alive.    We needed Solidity and Mix, so development on eth had to continue too.   All of the projects were interrelated.

Following this refactoring, it is getting much harder to justify any significant level of spending from the Foundation for ongoing eth development.   We already have geth.   Parity is becoming more popular.   There are 8 clients in total.    In the early days, having the Foundation funding multiple clients was crucial for maturing the protocol.   With 4 clients developed outside of the Foundation, it is harder to argue for this spending anymore.

So what unique value does a C++ client bring to the table to justify ongoing spending, whether from the Foundation or from other community actors?

The author’s own interest in the C++ client was on the basis of resource-constrained devices and portability, potential for the best raw performance, and a possibility that such a profile might also be a good fit for data centers.    Those are interesting stories, but not entirely compelling.   Parity has a very similar “profile”.

With this huge growth in interest in Ethereum for private and consortium chain scenarios though, we have a fantastic new potential “niche” for the C++ client, which is Enterprise applications.

That wouldn’t mean that the C++ client wouldn’t support public chain scenarios.    It would mean that we put an additional focus on modularity in the C++ client, so that it can start to span all of these categories in a way which has not been a primary focus to this point.   And it would mean that additional resources could come to bear on this work, outside of purely being funded by the Ethereum Foundation.


Why is the Ethereum C++ client a good fit for Enterprise?

Development efforts within large enterprises usually quite conservative in their development language choices.   They need systems to run for many years, and favor long-term-service platforms and well known and mature development tools.    That often ends up meaning Java or C++ on Linux.

Newer languages like Go and Rust are less appealing in many corporate environments, because their developers have little to no experience with those languages, where they have Java and C++ experience to spare.

In addition, the C++ codebase benefited from a fairly significant refactoring last year which started to decouple the consensus mechanism.    This was prototyped as a Proof of Authority (POA) alternative to Proof of Work (POW) in the (now retired) Fluidity client.

There has been huge interest in Ethereum integration within the Hyperledger consortium following Vitalik’s presentation to their Technical Steering Committee in April 2016.   Hyperledger is a project under the Linux Foundation bringing together many member companies collaborating to build common blockchain and ledger solutions.

Outside of Hyperledger there are other companies who have already made their technology decision and chosen Ethereum as their base technology.   Rubix by Deloitte, for example, have been building on the C++ codebase for several months and there are a number of other companies also favoring the C++ codebase.

With permissive licensing, work in any of these “C++ buckets” could proceed in parallel with existing Ethereum Foundation-centered work.   We can collaborate where we have commonality and diverge where we need to.

Permissive licensing enables permissionless innovation.



Corporations don’t love you or hate you

Screen Shot 2016-06-26 at 10.51.00 PM

Technology companies are now the largest corporations in the world by market cap.

Apple, Alphabet/Google, Microsoft and Amazon are literally #1, #2, #3 and #4 for the first quarter of 2016.   Ahead of oil companies.   Ahead of banks.   Ahead of every other industry.

Most software developers are working for large corporations.   Those corporations need tools to build their businesses.  Open source tools resourced by large corporations are now the norm.   There is a world of difference between the current day and the hostile landscape which Richard Stallman was facing in the mid-80s.

  • Apple are obviously a money-making machine, but they also finance LLVM/Clang.
  • Google do not have your best interests at heart, but that doesn’t mean that Go is evil.
  • Facebook, mixed in with their people farming, have brought us React.
  • Microsoft are night-and-day different from the Ballmer horror days.


Corporations will build blockchain technology irrespective of what we do.   It is already happening.

Just as both Intranets and the Internet have a role to play, so do public and private/consortium chains.    Maximalist thinking is not particularly helpful here.

The real world never works in black-and-white, and demonizing people with similar but not identical goals is self-defeating.

The author would rather have those corporations building Ethereum-based blockchain technology than have them building something completely incompatible purely because of the barrier of copyleft licensing which we have long planned to remove anyway.

Having  these corporations within a shared “big tent” rather than in rival camps gives us maximal synergy, and taps the vast resources of those corporations to contribute to our goals, rather than letting them build rival ecosystems with zero synergy.

Proceed with caution, but please let’s proceed!




Appendix A – History of cpp-ethereum licensing

Appendix B – A selection of Enterprise blockchain articles and events