Executive Director, ETC Cooperative | CTO and Co-Founder Varro Technologies | Community – Ethereum, Hyperledger, CryptoChicks
Recovered 🙂
My first paid programming work, from my work experience at Penrhyn Quarry. Made for an open day and they gave me 50 quid after the fact.
I bought a USB 3.5″ disk drive to attach to me Mac, and the disk just worked, and the emulator just worked too:
Here is the Pascal source code:
And a video of the game being played (though sadly with no audio – you will have to imagine that!)
There have been rumblings for years about the BSV project’s plans related to “court orders”.
The Bitcoin (BSV) Association dropped a bombshell on 5th October 2022, announcing their Digital Asset Recovery Process and releasing the Blacklist Manager. This is the closest that we have seen to on-chain censorship for any blockchain, and the censorship is just the first step. The second step is reassignment of assets to other owners with no private keys required.
Further details are provided in the Blacklist Manager Technical Manual.
Here is the explainer video:
The Blacklist Manager is described as “A required add-on to the Bitcoin SV node software to ensure that miners comply with court orders”.
Furthermore, “A miner who does not install Blacklist Manager risks being out of consensus with other nodes on frozen UTXOs. This could lead to their blocks being orphaned by the rest of the network if they are spending these frozen UTXOs.”
What is the context?
Craig Wright has been claiming for years that Bitcoin can be moved without private keys and that developers have a fiduciary duty to reassign stolen coins if they are ordered to do by courts. The developers have the power to do that, he argues, and so they must do so. Until this software was released it was unclear how such an out-of-left-field assertion was even possible.
It seems likely that these “court order” moves within the BSV ecosystem are directly related to Craig Wright’s claim that 110,000K bitcoins were stolen from him on or around 5th February 2020 in the notorious “Pineapple Hack”. He wants those coins to be recognized as his property and for them to be reassigned to him.
(Incidentally – he claims ownership of the infamous “1Feex” address which received funds from the Mt Gox hack in 2011. So the funds his claims were stolen from him were themselves previously stolen goods. What about the property rights of their original owners?)
Such reassignment obviously requires changes to the BSV software, because blockchain transactions always require private keys to move funds. These releases from the Bitcoin (BSV) Association and nChain appear to be the changes to support such actions.
Some history on this saga:
How is this tooling supposed to work?
Here are the stages in the workflow, with Step 4 being where the miners “choose” to prioritize orders from the Blacklist over the existing “longest chain” Nakamoto Consensus which has been the consensus mechanism for Bitcoin since the very first mined block. The Blacklist Manager is in control of which transactions miners can or cannot mine.
In the final phase of the Digital Asset Recovery Process (not yet implemented it seems, but explained in the video), the miners would also receive orders from the Notary to reassign assets and the miners would follow their orders on that as well as on the freezes.
It is unclear exactly how that asset reassignment would work, but conversations on Twitter point to that likely being either forcing of an invalid transaction by the miners or by addition of a new transaction type which could transfer funds with no need for private keys. Both of these options would constitute a soft fork or hard fork and would be a change of consensus.
How would forcing an invalid transaction work? Wouldn’t the other full nodes reject it? No. There are very few full nodes in BSV except those run by the miners, because they are too expensive to run. The only exception are a small number of infrastructure providers, but many of those will hit the same kind of scale issues which Blockchair hit causing their nodes to crash. In the explanation of that event, they explained:"But the reality is that 99.99% or so of Bitcoin SV transactions are junk, so despite being the biggest Bitcoin-like blockchain with most transactions, Bitcoin SV constitutes only 0.3% of our visitor numbers and there are very few API clients using Bitcoin SV (0.2% of all API requests most of which are free API calls for the stats). Unfortunately, this doesn't cover all these costs. So that's why we can't run more than 2 nodes, and even these two nodes will get stuck at some point because we'll go bankrupt buying all these disks to store the junk data. But we're trying our best :)"
It is somewhat unclear from the Blacklist Manager Technical Manual whether miners can connect to multiple Notaries in parallel or only to a single notary.
Assuming a multiple-notary scenario it would be impossible for miners would stay in consensus unless they were all following the exact same list of notaries. All the miners must move in lockstep to avoid orphaning.
Lockstep, why?
Here is an example of the lockstep issue, first tweeted shortly after the initial release of this article.
Court orders might be mutual incompatible between countries too, meaning that some legal orders must be ignored. A simple example here would be enforcement of sanctions, as highlighted by the recent Tornado Cash OFAC situation. If there was a Notary for OFAC enforcement for the US issuing digital court orders for sanctions against Russia and a Notary in Russian issuing digital court orders for sanctions against the USA, how does that resolve? Are we going to end up with USA-chain? BSV not usable in China?
As part of the Blacklist Manager Technical Manual there is a glossary which includes their definition of “Legal Terms” which is, frankly, incredible. This is either terribly sloppy work or is willfully broad, leaving huge grey zones as to what is or is not acceptable to be enforced for freezes or asset reassignments.
Could the Tulip Trust Ltd’s legal notice be interpreted as a “Court Order?” Yes.
Could a meeting of a bunch of lawyers employed by TTL be interpreted as a “Law Court?” Yes.
The miners will do what they are told
Everyone who runs the BSV Node software is doing so under the licensing agreement which accompanies the source code and binary releases of that software.
The licensing for that software changed from an open source license to a proprietary license on 2nd May 2019, when the MIT license put in place by Satoshi in the very first release of the Bitcoin source code had a raft of restrictions added to it which mean it no longer meets the Open Source Definition as maintained by the Open Source Initiative non-profit, failing on nearly every point, with the exception of the source code being available.
Here is the key line – https://github.com/bitcoin-sv/bitcoin-sv/blob/master/LICENSE#L20
——————2 - The Software, and any software that is derived from the Software or parts thereof, can only be used on the Bitcoin SV blockchains. The Bitcoin SV blockchains are defined, for purposes of this license, as the Bitcoin blockchain containing block height #556767 with the hash "000000000000000001d956714215d96ffc00e0afda4cd0a96c96f8d802b1662b" and that contains the longest persistent chain of blocks accepted by this Software and which are valid under the rules set forth in the Bitcoin white paper (S. Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, posted online October 2008) and the latest version of this Software available in this repository or another repository designated by Bitcoin Association, as well as the test blockchains that contain the longest persistent chains of blocks accepted by this Software and which are valid under the rules set forth in the Bitcoin whitepaper (S. Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, posted online October 2008) and the latest version of this Software available in this repository, or another repository designated by Bitcoin Association
——————
You can only use the software on the BSV fork of the Bitcoin blockchain and you are also compelled to run the latest version of the software. There are no alternative implementations of the BSV client software, so you are taking whatever changes the maintainers want to make and there is nothing you can do about it. Those changes can include major changes to functionality (like the Blacklist Manager).
The freezing code was added to BSVNode in the 1.0.9 version released in October 2021 so will already be being used by all node operators.
OPINION – Why do this? What is the endgame?
So this is all pretty undesirable in the opinion of the author, but what is the big deal? If the only outcome is that the BSV community is so compliant that it allows Craig Wright to reassign Mt Gox coins to himself which he claims were stolen then what is the harm? It it just further proof of cult-like behaviour which won’t surprise anybody outside of that bubble. Right? Wrong.
Tulip Trust Ltd issued legal notice to BTC and BCH developers too at the same time, and will no doubt use a “successful” implementation on BSV to prove that this is possible and that BTC and BCH developers are willfully obstructing legal due process and “law and order” if they do not do the same. Even beyond Bitcoin-family chains, any such precedence puts all blockchain projects and their developers at legal risk
The cover story is of BSV being a “legally friendly” blockchain which protects victims of crime. The reality is a horrific backdoor in the protocol which presents terrible danger of abuse to end-users and goes against the whole “immutable ledger” basis of blockchain.
It is obviously important for blockchain projects to comply to legal requirements in the jurisdictions which they operate, but tools for these purposes are better implemented at a higher level in the stack – not by dangerous intervention on the ledger itself. That approach introduces a subjective mechanism into a system which is very intentionally objective and tamper-resistant.
Law enforcement already have incredible tools to do their job, in the form of an immutable ledger and powerful chain-analysis tools.
The playbook here is very similar to the backdoors proposed in encryption in the 1990s onwards. Backdoors to encryption were largely beaten off because of the risks which they represented to all participants.
In the author’s opinion the same fight is required to halt “solutions” which seek to censor or blacklist transactions on blockchains, let alone to reassign coin ownership.
These blockchain backdoors can and will be abused and are ultimately not in the public interest.
“ASIC resistance” is a myth. The author rejects that myth as do many other individuals within the ETC ecosystem.
This position statement seeks to foster confidence that decisions around ETC mining are not being guided by an easily disprovable myth, but by the application of science, measurement and facts – not subjective personal beliefs.
The Ethereum Classic project “inherited” both philosophy and implementation decisions from the Ethereum project which are in conflict with the “Immutable, Decentralized, Unstoppable” philosophy and ethos of ETC.
The first break which ETC made against such inheritance was with Monetary Policy, where the lack of a fixed cap on supply in Ethereum, while not problematic for the ETH2 (“World Computer”) project, was a huge problem for ETC (“Bitcoin with state and smart contracts”). That project needs a “hard money” basis.
ECIP 1017: Monetary Policy and Final Modification to the Ethereum Classic Emission Schedule
Getting to human consensus on the Monetary Policy change was hard, because the change was in conflict with Immutability doctrine. Changing consensus rules in any way is very problematic to some people.
Monetary policy was seen as something where there was very broad consensus that the inherited lack of monetary policy was a major problem for ETC. Breaking immutability in that way so that immutability could be preserved with respect to monetary policy on a multi-decade basis moving forward was seen as a worthwhile tradeoff.
“ASIC resistance” is another instance of a “bad inheritance” which could be fixed so that ETC ecosystem participants can have multi-decade certainty around mining as well as monetary policy.
Ethash Design Rationale by Vitalik Buterin, Chief Scientist, Ethereum Foundation, 10th February 2015.
ASIC Resistance is Nothing but a Blockchain Buzzword by StopAndDecrypt, 8th June 2018.
The Prognosis on ProgPOW, with Kristy Minehan on BlockChannel, 10th April 2019.
“She stated that ASIC resistance was, indeed, a ‘myth’ and a ‘fallacy’, adding that Proof-of-Work required “some form of ASIC to do the work. Text summary of the interview above by coinbarters.com.
The ETC Summit 2019 mining panel in Vancouver, Canada, 4th Oct 2019, covered this very well.
“Is ASIC resistance a myth? Aren’t GPUs ASICs too?”
– Bob Summerwill, Executive Director, ETC Cooperative
“An important thing to clarify here is when you say “ASIC resistance”, those people who are for “ASIC resistance” are not against something called ASIC. They are against something which is a custom hardware which is more efficient to the hardware available to the masses, or general hardware. So, I do believe ASIC resistance in that way is futile, because there will be some custom hardware always. If you have a coin which is worth mining then somebody will find a more efficient way of mining it, whether it is ASICs or some other way, which gives them equal advantage that ASIC cannot. For example, maybe I live in a country where I have good connection to the government and can get almost free electicity. Now, I am maybe 1000x more efficient than someone, without buying any ASICs. If you are against ASICs in that way, you are just against competition”
– Nishant Sharma, Head of International PR and Community Relations, Bitmain.
“I think ASIC resistance is more of a philosophy than a practical approach you can implement. If you look at things: GPUs are ASICs. CPUs are ASICs and the blockchain processes we make are ASICs. Fundamentally the philosophy behind “ASIC resistance” has been to make things products memory hard. And so, what you end up doing, is you are buying GPUs primarily to be “ASIC resistant”. You pay a lot for memory and inherently the hash rate is a lot slower. Philosophies around “ASIC resistance” are that it is widely available. You can go to AMD or NVIDIA to buy those products. But fundamentally it is not a good mining solution. You can see that in today’s world and very shortly that GPUs are not profitable and we see that as technology moves along the GPUs will be dwarfed by ASICs.”
– Henry Quan, CEO, ePIC Blockchain Technologies.
UPDATE – We have a room assigned! H.3244 on Sunday 2nd February between 14.30 and 15.30. That is upstairs in the H building which has the info centre, T-shirts and some of the rooms for the talks. Look for the BoF signs pointing in the right way.
Greetings!
I am proposing a blockchain “Birds of a Feather” session at FOSDEM 2020.
Who is with me?
There was a similar session at FOSDEM 2018, and while I missed FOSDEM 2019, I understand that one was held there too.
FOSDEM is a unique “neutral ground” from the horrors of blockchain tribalism. I have spent a lot of time in the last two years working to build bridges between different factions of the blockchain ecosystem, particularly within Ethereum, but also across the whole space.
We all have so more more in common than we have differences, especially when it comes to the “foot soldiers” who are actually working on blockchain technology rather than the products or “coins” which incorporate that technology.
Please join this Telegram group for updates.
When we have a room/time I will update this blog post and tweet that out too.
Best wishes,
Bob Summerwill
UPDATE – We have a room assigned! H.3244 on Sunday 2nd February between 11.30 and 12.30. That is upstairs in the H building which has the info centre, T-shirts and some of the rooms for the talks. Look for the BoF signs pointing in the right way.
Bonus: Stay in your seat for Pinephone Porters from 12.30 to 13.30 and for PineTime from 13.30 to 14.30. Then from 15.00 to 15.50 Regaining control of your smartphone with postmarketOS and Maemo Leste in Janson.
Bonus: Sailfish/Mer BoF session 1st Saturday (today) at 15.00 to 14.00 also in room H.3244 booked by Nokius!
I reached out to Nicole Faerber, the CTO of Purism, a week or so back to ask whether there was a Birds of a Feather session organized at FOSDEM 2020 around the Purism Librem 5 device, and she said no, so I volunteered to organize one.
As per the Purism website,“The Librem 5 represents the opportunity for you to take back control and protect your private information, your digital life through free and open source software, open governance, and transparency. The Librem 5 is a phone built on PureOS, a fully free, ethical and open-source operating system that is not based on Android or iOS (learn more about why this is important).”
Devices are being shipped to developers and the multi-year process from conception to first release is coming to a climax.
There will be various Purism people at FOSDEM, who can give us an update on the State of The Union, demonstrate actual devices and take part in some Q&A.
We won’t have an assigned room until I get to the campus and can book one. When that happens I will update this blog post accordingly.
Please join this Telegram group for updates.
Best wishes!
Bob Summerwill, Mobile Linux Fan.
I have just submitted a pull request to the Ethereum Classic Github repository proposing the following protocol change:
“Hard cap on the gaslimit for the ETC mainnet as an in-protocol consensus rule”
There is not an ECIP number assisted yet. That is a task for the ECIP editors.
I welcome discussion on the proposal and suggested changes through the ECIP process as defined by ECIP-1000.
A proposal to place a hard cap on the gaslimit for the ETC mainnet as an in-protocol consensus rule. From the block that this ECIP was activated, gaslimit would follow a curve defined in this proposal rather than being subject to miner voting.
There is nothing more important to the ETC network than security and decentralization. Both of those desired characteristics have already been heavily compromised in ETC because of the malincentives which ETC inherited from ETH in the form of the miner gaslimit voting mechanism.
The gaslimit has been raised for the ETH mainnet first to 8M and then to 10M gas, despite it being obvious that the client implementations cannot adequately cope with the state trie growth that such a high gaslimit has created. ETH has been “overclocked” and smoke is coming out of the engine. This long crisis was one of the primary motivations for the ETH 1.x initiative which started around DEVCON4 in Prague in October 2018. The crisis on ETH is still ongoing and still unresolved and is affecting ETC too as well now.
The miner gaslimit voting is one-sided. There are no checks-and-balances. There is no voice for the end-users who care about the long-term health of the network. There is only a single “control knob” and the miners have control of that “control knob”. They are incentivized to vote the limit up to infinity, because fees rise if they do so. Like over use of credit cards, the bill comes much later as a consequence of growth of the state trie which makes it harder and harder to run a full node. For Ethash miners with GPUs or FPGAs there is little consequence for them “killing the host”. They can just exit and go and mine some other coin if ETH or ETC become completely centralized and unusable because of state bloat.
This malincentive has played out for ETH such that the ETH state tie is now so large that full-sync-from-genesis is completely impractical and the disk usage is off the charts for full nodes, let alone for archival nodes. Fully validating syncs for ETH nodes are now a multi-month process.
Here is a recent example from Jeff Garzik on 15th January 2020 (it took him nearly 2 months):
https://twitter.com/jgarzik/status/1217488290900848640
ETH is completely reliant on Infura now and it is well known how serious a problem that dependency on a single centralized and proprietary service provider is.
Anthony Lusardi proposed an appeal to the ETC miners to voluntarily vote the gaslimit down to 1M in March – (ECIP-1047) but that appeal has never happened, though might soon. A voluntary solution would be a step in the right direction in terms of the effects, but it does not solve the root issue which is the malincentive of the miner vote.
A protocol change to set a hard-cap would resolve the unsustainability issue for ETC and bring the protocol into alignment with ETC philosophy, rejecting this bad inheritance from ETH and back in line with Bitcoin’s sustainable approach.Unlike BTC however, we would define a long-term growth curve to reflect the constantly improving hardware – even with the same protocol and same client implementations.
At block number ACTIVATION_BLOCK on ETC mainnet, switch the gas-limit calculation to be one of the following two options:
There is certainly a concern that some smart contracts which used to work will cease to work (until some future point where the raising gaslimit makes them viable again) and we need to quantify this risk.
There is a concern that it will not be possible to migrate ETH smart contracts to ETC because of the lower gaslimit. Straw polls on Twitter seem to indicated that 1M or 2M is adequate for most smart contracts out there for their heaviest transactions with the sole exception of transactions for contract deployment, which can hit 4M or more. In that case we have no answer yet other than spliting contracts up into multiple libraries.
It looks like some kind of “Webpack for Solidity” would be workable, where we could add opcodes to deploy chunks of bytecode across several transactions, with new opcodes for START_DEPLOY, DEPLOY_CHUNK and END_DEPLOY or similar which could be used transparency internal to the development framework (Truffle, Embark, Brownie, etc) and compiler (SOLC, SOLL, Vyper, etc) to generate different bytecode depending on the gaslimit of the target chain. This is just an idea for the time being and needs its own new ECIP too.
Aragon is probably the perfect guinea pig for addressing these concerns because they have large smart contracts and have just recently been the victim of backwards-compatibility breaks in ETH as part of the Istanbul HF. If we can provide a great story for ETH to ETC migration with well engineered changes spanning frameworks, compiler and runtime then that will be a delightful win-win for all parties.
As Jorge said, while breaking smart contracts up is the right thing to do, it should not be REQUIRED. To require changes to existing script is a break in the implicit social contract:
There is no implementation of this proposal yet because we are missing the specific details of the future gaslimit curve. That could either be linear growth or Moore’s Law style exponential growth.
The ETC Cooperative will fund implementations of this ECIP for Hyperledger Besu, Parity-Ethereum and MultiGeth, including testnets and audits as required.
This work is licensed under the [Apache License, Version 2.0. The author, Bob Summerwill, attests to his sole authorship of this work, and that he is able to contribute this work to the ECIP process under the Apache 2.0 licence. He further attests that he neither holds nor is aware of any patents, trademarks, copyright issues or other IP hinderances associated with this work.
[View of Stanley Park and Grouse Mountain from Dunbar, Photo by Bob Summerwill]
NOTE – I am not actively seeking work, but I am always open to opportunities. There are numerous ways to contact me if you think there is some interesting possibility for collaboration, but please DO READ THIS POST FIRST. That will save both of us from wasting our time in discussing an opportunity which does not meet my basic requirements (ie. anything which requires me to relocate from Vancouver).
This is a follow-up to my Bob Summerwill for Headhunters (2017) article which was written in December 2017. Not a great deal has changed in the meantime for my requirements and what I have to offer, but I felt it was time for a refresh anyway.
Since November 2017 I have maintained a full Conflict of Interests statement which enumerates the many roles and professional relationships which I have, whether financially compensated and otherwise and my cryptocurrency holdings.
During 2019 I also added my CRA (Canada Revenue Agency) personal tax filings and a list of individuals whose work I sponsor (all Github Sponsorships at the time of writing, but with Gitcoin donations likely to be added to the mix soon). I also moved from a list of organizations which I recommend and endorse to a (very long) list of individuals who I trust and a much shorter list of individuals who I do not trust and who have hurt me or hurt the projects I am involved with. I still have a bunch of hyperlinks and details to add to that list to make it more useful.
My Resume page is out of date, but my LinkedIn profile is very up-to-date. The About page on this website is always up-to-date as well.
We just had an ETC Devs / Miners / Community call to talk about options to manage rampant chain bloat we are seeing on the ETC mainnet which is being caused by GasToken, with most blocks being filled with garbage, adding gigabytes to the state every day. This will compromise decentralization in short order and is an existential threat to the health of the network.
Here is a copy of the recording of the call. Thanks to a.s. for that.
My suggested ACTIONS ITEMS:
Future discussion is best done on Github issues within the ECIP process, for global visibility and permanent papertrail on the decision-making process.
Thanks to Zac Mitton for setting up and hosting the meeting.
First published on Coindesk on 26th December 2019 as The Ethereum Community is No Longer Fighting with Itself. This is my original draft.
This post is part of CoinDesk’s 2019 Year in Review, a collection of 100 op-eds, interviews and takes on the state of blockchain and the world. Bob Summerwill is Executive Director of the ETC Cooperative.
2016 and 2017 were divisive years for the Ethereum ecosystem.
In January 2016 the former CTO of the Ethereum Project, Gavin Wood, spun off the former ETHDEV C++ team to found Ethcore – later renamed as Parity Technologies. There has been an ongoing love-hate relationship between Parity and the rest of the Ethereum community ever since. This continues to the present day with their controversial proposal to move the Parity-Ethereum project into a DAO.
In July 2016 we had world class drama when The DAO was drained of funds. After a month of the most intense debate, the ecosystem was cleaved into two with The DAO Fork. The “World Computer” majority accepted the fork which returned funds. That fork retained the ETH “ticker” and the Ethereum trademark while the “Code is Law” crew showed the world that minority chains can survive by supporting the unforked chain and bringing Ethereum Classic to life.
In October 2016, Parity Technologies blocked relicensing of cpp-ethereum to Apache 2.0 at the eleventh hour because it would have affected their commercial interests. They also feared that having IBM’s “nose under the tent” could have led to a chain split. That relicensing looked very likely to result in a huge swing towards Ethereum within the Hyperledger consortium which had been formed a little under a year before. Not to be.
Blocking the relicensing led indirectly to the creation of the EEA which emerged as a “Plan B” as the relicensing floundered. No grand alliance between Ethereum and Hyperledger was possible at that stage, but there were sufficient enterprises using Ethereum for more formal collaboration to be worthwhile.
So February 2017 saw the founding of the Enterprise Ethereum Alliance (EEA), including household names like Microsoft, Intel, JP Morgan, BNY Mellon and CME Group. The members were primarily focused on private and consortium chain scenarios. The birth of the EEA was a very tense affair, with serious worries that the Ethereum Foundation would flat out denounce the EEA. Vitalik Buterin was privately supportive, but did not attend the launch event in personal. Instead he sent in a pre-recorded video which made no mention of the EEA but spoke in generalities about business uses of Ethereum. The EF itself made no formal statement. The tension was palpable in those early months.
Was the EEA an attempt at corporate capture of Ethereum? Was the EEA just a front for ConsenSys (who were contributing most of the resources during that launch period and early stages of operation)? Parity were also notably absent, and indeed have never joined the EEA. Were the EEA and Hyperledger rivals? Was this just a proxy battle between Microsoft (a major backer of Ethereum) and IBM (the primary mover within Hyperledger?)
None of these fears were true. They were all the result of zero sum thinking.
As Jeremy Miller said at the EEA Launch event, there was a no reason why a suitably modular Ethereum codebase should not meet all of these use-cases – public and private, permissioned or permissionless. An analogy could be drawn with Internet and Intranets. Both have their uses. Deployment choices would just be configuration settings on common codebases.
That is just how things have played out.
In February 2017, Monax (a founding EEA member) joined Hyperledger and contributed the first Ethereum Virtual Machine – Burrow (previously known as ErisDB). That codebase had only ever run as a permissioned chain using Tendermint, never on the Ethereum mainnet. It was integrated into Hyperledger Sawtooth (as Seth), and then into Hyperledger Fabric. EVM-in-Fabric was the primary display at the IBM booth at Consensus in May 2018.
In January 2018 I wrote a tweetstorm which become the “Call for an End To Tribalism in Ethereum” keynote at the Ethereum Community Conference in Paris in March 2018. Kent Barton continued that theme with “Divided We Fail: The Irrational Insanity of Crypto Tribalism” in April 2018.
That Paris conference also saw the launch of the Ethereum Magicians led by my former colleagues Jamie Pitts and Greg Colvin. That group of individuals sought to mature the governance around the Ethereum protocol improvement process.
In October 2018, EEA and Hyperledger announced that they were becoming associate members of each others organizations, and would be collaborating on common projects. In April 2019 the Token Taxonomy Initiative was launched, with Microsoft and IBM working together. In June 2019, Microsoft finally joined Hyperledger. Now we just need IBM to join the EEA (hint, hint)!
Tensions between the Ethereum Foundation and the EEA thawed in 2019, with Aya Miyaguchi, the Executive Director of the EF joining the Board of the EEA in August 2019, and the Mainnet Initiative being announced as a collaboration between the EF and the EEA.
In August 2019, ConsenSys announced that they would be joining Hyperledger as a Premier Member, with Joe Lubin joining the Governing Board. They announced that they would be contributing their Enterprise Ethereum client Pantheon (now renamed as Besu).
Three years after the failure of cpp-ethereum relicensing, we finally had a fully-fledged ETH mainnet client as part of Hyperledger. Besu was written in a mainstream enterprise language – Java, had permissive Apache 2.0 licensing and had mature governance under the Linux Foundation. It was built by a large team of world class software engineers, building to the specifications which the EEA had matured since 2017.
ETC Cooperative funded ETC support and that work was completed by ChainSafe in December 2019. There has been a period of growing collaboration between the ETC ecosystem and the ETH ecosystem in late 2018 and throughout 2019, after several years or hurt feelings and bitterness after “a bad divorce”. Virgil Griffith was key to that detente and has been an excellent friend to ETC.
As my good friend John Wolpert said so well in his seminal “Bring on the Stateful Internet” blog post in August 2018:
“I wish we could take all the good work out there — the patterns each team in the blockchain space has explored for the past several years — and lop off all the brands, the flags, the preciousness we all get when looking at our own babies. We would see it all as a bag full of Legos, a set of potential standards converging on what we really need in order to build awesome new applications that transcend the limitations and troubling central control issues of client/server.”
The artificial boundary we have put in place in our minds between “public chains” and “private chains” is fading rapidly. All our different technologies, whether we call them blockchains, or DLTs, or distributed databases, should be interoperable.
One chain to rule them all is Maximalist nonsense. Out future evidently has multiple chains. L1s and L2s. State channels, Rollups, Plasma, Lightning, Counterfactual instantiation, L2 privacy solutions, Off Chain Compute, every type of consensus under the sun. Integration with legacy systems is critically important too. Blockchain is not a silver bullet.
At the close of 2019, we are in a completely different place than we were during the high drama of 2016. Former rivals (both within Ethereum and across the broader enterprise blockchain ecosystem) are pulling together in a way which is a delightful contrast to the fractured and tribal landscape of the near past. Collaboration is proving the winning strategy over cut-throat competition. This trend will only accelerate into 2020.
Maturity of governance is also finally being seen as the critical foundation for collaboration which it truly is. The whole ecosystem is finally growing up.
“We have the opportunity to build a set of technologies in the next few years which could have similar societal impacts as the Internet, the World Wide Web and open source languages, relational databases, etc. 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.”
In 2020 that dream is ever closer to becoming a reality. It is a sheer delight to have had such a front-row seat to this revolution. Bring it on!
Bob's Blog 