A Crypto on the Edge of Forever

Now that the dust has settled from more than twenty countries of travel, dozens of conferences, major events and community meet and greets this year, I’ve finally had the time to reflect on the progress of the Cardano project as well as some of the lessons I’ve learned. It’s honestly been the most challenging year of my life filled with drama, stress, death and some unbelievably cruel people.

It’s also been one of the most rewarding and joyful having the chance to meet thousands of passionate and kind fans, technologists and scientists- I can see the inspiration that Charles Dickens had when he said it was the best of times and the worst of times.

The reality is that the internet and in particular the cryptocurrency space can be a really toxic place if you allow it to get to you. There were times after reading some blog post or comment on reddit that I seriously questioned if this effort was worth it. I can understand why Mike Hearn left Bitcoin.

But I’ve never been here for the short term, it’s always been the dream of finding a way to get financial services to the three billion people who don’t have them using technology that was only a dream a generation ago. And I think we are making great progress there.

In January of 2017, Cardano was still mostly in a very early alpha stage. We had tremendous engineering difficulty getting Haskell, our devops and the new protocols such as Ouroboros and Scrape to play nicely together. Rather it was a constant learning curve of how to tame the three headed dragon of research, decentralized teams and exotic programming languages while managing the expectations of a huge community.

As an aside, Cardano has one of the fastest growing and most intelligent fanbases. We actively invited people who care about formal methods, peer review and functional programming to come see what we are working on. These people aren’t swayed by jargon or flashing marketing. They were born with bullshit detectors in their cribs

I’ve gained significant strength and a much needed boost in morale from interacting with our community. For example, one member asked about how we were verifying the proofs in the Ouroboros paper and I posted a link to Kawin’s Isabelle repo. Most would simply say that’s nice and move on. This member took the time to read the code and mentioned we have a long way to go with specific examples.

For most people, Isabelle is a name followed by a lake in Minnesota. For our community, some can actually read the code and comment on it. That’s a rare gift and it’s the privilege of a lifetime to be in this kind of environment (we ending up hiring the person who commented on the code).

Moving through the months, Cardano moved from the lab to a series of testnets to eventually being released in September. Dealing with these transitions gave us a newfound appreciation for just how many different computer and network configurations exist. I can almost feel a windows force ghost whispering “I told you so” in a smug voice.

We designed the Byron (the September release of Cardano) to be the minimum viable product necessary to test the concepts Cardano is built upon. We wanted to run Ouroboros in a production setting to see epochs function properly. We wanted extensive logging of both the edge nodes and relays to see how our network is being used. We wanted to have third parties play with our APIs and tell us where we screwed up (boy did they ever!). We wanted to test the update system a few times.

Overall, the experiment has been a tremendous success. There are several thousand edge nodes concurrently connected to the network. There are several exchanges and other third parties using our software in the harshest possible way. There is a wealth of data flowing in that is giving us a much better sense of what we need to do to make Cardano better.

Since launch, we’ve already pushed three updates to the network without incident. We’ve started a very rapid redesign of our middleware and its associated APIs to make it easier for third parties to integrate. We’ve started a series of systematic improvements to our network stack that will be finished with the Shelley release that should dramatically improve things.

However, what excites me most about 2018 is that Cardano is starting to open up to the world. Delegation and staking will be rolled out all throughout Q1 and Q2 in coordination with the community. Soon we’ll have a testnet running IELE allowing developers to play around with our smart contract model for the first time. And we’ll be deploying our first verified protocol with Praos thereby engaging the formal methods community.

Constantly living in the moment, one tends to eschew Cardano’s vast scope in exchange for the problem of the week. But looking at our ever growing whiteboard series demonstrates how many brilliant people wake up every morning thinking about how to solve the problems of scalability, interoperability and sustainability. These aren’t just hypothetical lectures. They are backed by papers, funding and developers working full time.

Then there are the new things. Professor Rosu’s and Runtime Verification’s work on K and semantics based compilation isn’t just really smart competitive differentiation, it’s literally moving the chains of the entire field of programming language theory. The Cardano project is creating a financial incentive to have correct by construction infrastructure from virtual machines to compilers. Our success means you don’t have to hand write this code ever again- not just in a cryptocurrency context; in a general context.

Our research efforts at Tokyo Tech under Professors Mario Larangeira and Bernardo David with multiparty computation is rapidly bringing these protocols into practical use. Kaleidoscope and Royale are case studies on how to achieve everything that Ethereum does off chain, in a low latency setting, privately and at a scale of millions of concurrent users each in their own domain. Further abstractions will push this work into more useful domains like decentralized exchange. And eventually DApp developers will be able to integrate these protocols into their code via libraries.

Professor Bingsheng Zhang’s research on treasuries and voting is groundbreaking. It’s giving our project the ability to have a discussion about how should changes to cryptocurrencies be proposed, debated, approved and funded. What’s most special here is the interdisciplinary nature of the effort that can draw from political science, game theory, sociology, open source software governance and computer science. There is something for everybody.    

Moving into 2018, we are going to open this discussion up by both engaging the community directly and by holding a conference in Switzerland. More details will be published later, but the basic idea is that this area isn’t a Cardano problem. It’s a cryptocurrency problem. And there are many great projects from Dash to Pivx who are trying to solve it in a novel way. We ought to talk to each other.

I could continue enumerate our research efforts (there’s a lot more to write), but I think the point has been made. Cardano isn’t a cryptocurrency as much as it is a movement of minds who are frustrated with the way technology works in practice.

The functional programming community has had for decades great solutions to many of the problems plaguing modern developers, but they have been historically ignored. Our RINA guys if given a chance could build a much better and more fair internet. Layering protocol development with formal methods extracts a much cleaner and more meaningful design process where ambiguity and hand waving is slain.

What Cardano has given us is a chance to answer if only the world worked this way with why not? We have the freedom to dream again and the freedom to try new things without asking permission. I even have a chance to work with my heroes like Phil Wadler. 2018 is going to be one hell of a year.

Thanks for reading

[{Axiom}]

Phil Wadler and Me hanging out at Edinburgh

My Thoughts on the Tezos Issue

As a long time forum lurker in the Tezos community and having read the Goodman whitepaper back in 2015, I’ve always admired and respected what the project is attempting to achieve. It’s a nice blend of governance, formal methods and functional programming. Given that Arthur is French, I can forgive the obvious mistake of using Ocaml instead of Haskell (yes I’m biased), but I’ve been a bit puzzled by the crisis that has befallen the project.

First a brief summary of my understanding of Tezos. It’s a cryptocurrency that is seeking to define itself in terms of three subprotocols say <Network, Transaction, Consensus>(0) and then describe these subprotocols in a machine understandable format. Then they introduce an on-blockchain voting mechanism V that allows holders of Tezos tokens to propose a new <Network, Transaction, Consensus>(k) to fork the ledger. Should it pass this becomes the new Tezos.

It’s an elegant idea and one that promotes discussion on two axises. First, the notion of formal specification of a cryptocurrency. There have been numerous attempts to do this academically as a whole via IC3 or in part via Bartoletti et. al’s work, but building a system around it is both ontologically really interesting as well as practical for cross comparisons. IOHK has pursued less ambitious work via collaborating with Alex Chepurnoy on Scorex.

Second, there is the idea of creating an ideal voting system that is both secure and fair as well as incentivized enough to expect reasonable participation of the eligible voters. Here we are confronted with who are actually eligible and what is reasonable. Who and how people get to vote are more important than what is being voted on.

As fun as it is to discuss the technology or ideas, the vogue topic is a governance crisis at Tezos. They apparently opted to have a fairly strange structure where capital pools in one place and is precommitted to buy IP from another place to benefit some group. Semantics and other vagaries aside, a fight in the heavens and some bad press have spilled out into the public domain yielding threats of lawsuits and some small class action lawsuits.

It’s somewhat ironic- in a dark Irish way- that the venture focusing most on governance is running into a governance crisis, but the good news is that it’s actually completely solvable. It appears the structures chosen were designed for the following reasons:

1. Ensure insiders get fair compensation for their early work and risk taking
2. Minimize regulatory risk
3. Protect project capital in a safe jurisdiction
4. Provide project oversight that is independent of the will of a single group      

Well as people aren’t getting along it seems that the structures are deadlocked. Trying to fire people isn’t going to make things any better. Furthermore, the longer the fight goes on the more angry (i.e. more tortuous) the Tezos buyers will be. Calls for refunds will convert into class action participants. A rush to deliver Tezos to market as a bastardized product won’t likely solve the problem. Nor will hiding behind purchasing agreements that claim everything is a donation, we have no relationship with you and expect nothing. People wouldn’t threaten to sue if there wasn’t some intention at the end of the rainbow.

So to clean up the mess here’s what I would do if I was the arbitrator. First, there is a loss of faith and trust in the Tezos Foundation. Whether this is fair or unfair is completely irrelevant. Funds from the Foundation and its assigns need to be transferred to an independent trust subject to an audit that covers both accounting and conduct. The audit report must be made public alongside all contractual obligations of Tezos Foundation with third parties and employment agreements.

Next, in terms of the IP transfer. The sale of software isn’t a bright idea. Transfer pricing considerations aside, there is software and there is specification. Tezos is a concept that can be formalized on paper in a machine understandable way. Then there is the software that actually runs the concept. Arthur and company should write formal specs and sell the specs to the Foundation.

Then the Foundation can submit a request for bids from software development firms to build Tezos from this spec and accept the best three bids. There is well more than enough capital in the foundation to diversify the development and it de-risks the project from over-reliance on a single vendor. A third party could be retained such as the Gallium team at Inria to select the top three. They are some of the most qualified in the world for such a task.

The best part of this process is that the community can have a lot of input about their expectations in terms of communication, accountability and transparency of the development process. With ETC, we have made it a point to always broadcast our development standups on a weekly basis on youtube via hangouts. With Cardano we have monthly counters and weekly reports. These metrics could be built into contracts.

Finally, there is the issue of liquidity. Tezos buyers are trading futures at the moment. I’d recommend issuing an ERC20 token that will be an airdrop target and getting it listed on as many exchanges as possible. This will provide liquidity for those who have lost faith and allow new actors to enter the ecosystem through the secondary market. It also reduces pressure considerably to deliver a product for the sake of delivering one thus a more natural process can take place.

As a parting note, there has been a lot of tough press about the project. I’ve personally gotten some and I understand how hard and frustrating it can be. But also understand that the investigative journalists didn’t raise a quarter billion dollars. Tezos did. They also didn’t start the board fight.

So it would be good to hold a media roundtable with Johann and the rest of the foundation board as well as the other relevant parties and let the media ask their questions. Silence and obfuscation are only going to promote deeper inquiry and more aggressive stories.

At the end of the day what is driving the stories is a concern that people who bought the token are being defrauded or treated unfairly in some way. The only way to clean this up is to explain why they are not. Hiding solves nothing.        

I doubt my opinion matters much, but thanks for reading and I hope it all gets resolved.

[{Axiom}]

Some Thoughts Towards an Ontology for Smart Contracts

The concept of smart contracts has grown considerably since the birth of Ethereum. We've seen an explosion of interdisciplinary research and experimentation bundling legal, social, economic, cryptographic and even philosophical concerns into a rather strange milieu of tokenized intellect. Yet despite this digital cambrian explosion of thought, there seems to be a lack of a unified Ontology for smart contracts.

What exactly is an Ontology? Eschewing the philosophical sense of the word, an Ontology is simply a framework for connecting concepts or groups alongside their properties to the relationships between them. It's a fundamental word that generally is the attempt at bedrock for a topic. For example, it's meaningful to discuss the Ontology of democracy or the Ontology of mathematics.

Why exactly would one want to develop an Ontology for smart contracts? What is gained from this exercise? Is it mostly an academic exercise or is there a prescriptive value to it? I suppose there are more questions to glean, but let's take a stab at the why.

Smart contracts are essentially two concepts mashed together. One is the notion of software. Cold, austere code that does as it is written and executes for the world to see. The other is the idea of an agreement between parties. Both have semantical demands that humans have traditionally had issues with and both have connections to worlds beyond the scope in which the contract lives in.

Much of the focus of our current platforms such as Ethereum is on performance or security, yet abstracting to a more Ontological viewpoint, one ought to ask about semantics and scope.

From a semantical perspective, we are trying to establish what the authors and users of smart contracts believe to be the purpose of the contract. Here we have consent, potential for non est factum style circumstances, a hierarchy of enforceability and other factors that have challenged contract law. What about cultural and linguistic barriers? Ambiguity is also king in this land.

Where normal contracts tend to pragmatically bind to a particular jurisdiction and set of interpretations with the escape hatch of arbitration or courts to parse purposeful ambiguity, decentralized machines have no such luxury. For better or worse, there is a pipeline with smart contracts that amplify the semantical gap and then encapsulate the extracted consensus into code that again suffers from it's own gap (Loi Luu demonstrated this recently using Oyente).        

Then these structures presume dominion over something of value. Whether this dominion be data, tokens or markers that represent real life commitments or things such as deeds or titles. For the last category, like software giving recommendations to act on something in physical world, the program can tell one what to do, but someone has to do it.

So we have an object that combines software and agreements together that has a deep semantic and scope concern, but one could add more dimensions. There is the question of establishing facts and events. The relationship with time. The levels of interpretation for any given agreement. Should everything be strictly speaking parsed by machines? Is there room for human judgement in this model (see Szabo wet and dry code and this presentation)?

One could make a fair argument that one of the core pieces of complexity behind protocols like Ethereum is that it actually isn't just flirting with self-enforcing smart contracts. There are inherited notions from the Bitcoin ecosystem such as maximizing decentralization, maintaining a certain level of privacy, the use of a blockchain to order facts and events. Let's not even explore the native unit of account.

These concepts and utilities are fascinating, but contaminate attempts at a reasonable Ontology that could be constructive. A less opinionated effort has come from the Fintech world with both Clack's work on Smart Contract Templates and Brammertz work on Project ACTUS. Here we don't need immutability or blockchains. The execution environment doesn't matter as much. It's more about consensus on intent and evaluation to optimize processes.

What about the relationship of smart contracts with other smart contracts? In the cryptocurrency space, we tend to be blockchain focused, yet this concept actually obfuscates that there are three data domains in a system that uses smart contracts.

The blockchain accounts for facts, events and value. There is a graph of smart contracts in relation to each other. Then there is a social graph of nodes or things that can interact with smart contracts. These are all incredibly different actors. Adding relays into the mix, one could even discuss the internet of smart contract systems.

Perhaps where an Ontology could be most useful is on this last point. There seems to be economic value in marrying code to law for at least the purpose of standardization and efficiency, yet the hundreds of implicit assumptions and conditions upon which these systems are built need to be modelled explicitly for interoperability.

For example, if one takes a smart contract hosted on Rootstock and then via a relay communicates with a contract hosted on Ethereum and then connects to a data feed from a service like Bloomberg, then what's the trust model? What assumptions has one made about the enforceability of this agreement, the actors who can influence it and the risk to the value contained? Like using dozens of software libraries with different license, one is creating a digital mess.

To wrap up some of my brief thoughts, I think we need to do the following. First, decouple smart contracts conceptually from blockchains and their associated principles. Second, come to grips with the semantic gap and also scope of enforcement. Third, model the relationships of smart contracts with each other, the actors who use them and related system. Fourth, extract some patterns, standards and common use practices from already deployed contracts to see what we can infer. Finally, come up with better ways of making assumptions explicit.

The benefits of this approach seem to be making preparations for sorting out how one will design systems that host smart contracts and how such systems will relate to each other. There seems to be a profound lack of metadata for smart contracts floating around. Perhaps an Ontology could provide a coherent way of labeling things?

Thanks for Reading,
Charles


   

Some Thoughts on Lisk

Lisk has been a fairly controversial and frustrating cryptocurrency project since its inception. I wasn't involved in the Crypti community nor had met Max and Oliver prior to signing on as an advisor shortly after they had just finished their crowdsale. It was a hard decision to join and I feel that I need to elaborate a bit more on it to provide some context and more accurately explain my involvement

First, I mostly ignore other altcoins unless they have some unique piece of technology they they bring to the ecosystem. For example, IOHK recently published a comprehensive report on Dash and we later followed it up with another report containing a series of improvements. I think Tezos has its heart in the right place and just needs some TLC to make a serious impact on the space. Monero has started a great privacy conversation.

With respect to Lisk, it had all the right marketing jargon in its beginning- blockchain apps, sidechains, javascript, etc. But I honestly couldn't grok what the platform offered to developers and why it was unique and interesting to the space. Furthermore, the technology seemed to be a rehash of older ideas that have failed in the space such as the original DPoS and Crypti.

Hence, I initially completely ignored the project and happily went on my way to other things. Then a friend of mine participated in the crowdsale with a six figure amount. He asked me to try to be an advisor and help the project along. I generally reject these requests, but he is a good friend and thus I figured I'd meet Max and Oliver to see their vision.

I sent over a list of due diligence questions alongside some technical and roadmap questions. The answers were sufficient to warrant a meeting. Upon some discussions with Max, I realized that Lisk could actually serve a valuable place in the community.

Microsoft has been pushing a Blockchain as a Service platform. It seemed like Lisk could serve as a decentralized version of this idea by creating a marketplace for developers to consume blockchain related services for their applications where and when needed from immutable storage to oracle services. All these services could be priced in Lisk. I discussed this in more detail here.

Ok, so we have a decentralized version of something that Microsoft is doing and it's a marketplace. Sounds like a decent experiment to run. If anything, we could explore improving DPoS, sidechains and a lot of incentive schemes with the funds. Also, building a cryptocurrency in javascript is a really interesting pedagogical project.

Thus, we hammered out a deal for me to come onboard as a non-fiduciary advisor to Lisk alongside a lawyer friend of mine Steven Nerayoff. To be extremely clear what this relationship meant:

1. I never had control over the funds lisk raised at any time 
2. I never had control over management of the project nor HR decisions 
3. I never had control over project governance, the roadmap or direction

I was hired to be exactly what my title denoted- an advisor. That meant to me that I would provide advice to Lisk's management when asked about any topic I felt comfortable discussing and also be available for meetings. As an advisor, I shared several concerns about the project from the very beginning. 

First, I recognized that they raised funds without an operating entity. I requested that they form a not for profit and aggregate the funds held their trust to it. Their original strategy was to accomplish this task from a German structure. I have no experience in German law and thus recommended a Swiss Foundation. Eventually the Swiss option was followed after many months of spinning in circles on a German ggmbh. 

Second, I requested an immediate increase in staffing. To facilitate the advice, I recommended several recruitment options from outsourcing some development components to a trusted Ukrainian shop to directly recruiting using some talent scouts that I've worked with in the past. 

The lack of a legal entity and lack of access to funds seems to have greatly slowed this process. I still cannot understand why they don't have more developers. For example, IOHK hired seven full time scala developers in three months time for ETC. 

Third, I requested that they get a security audit of the existing source and protocols. As it was inherited and written in a very dangerous language (javascript), I speculate that is a high probability there exists at least one ticking time bomb in the github repo. To the best of my understanding an audit hasn't been done. I could be wrong.

Fourth, I requested that a whitepaper and roadmap be drafted with explicitly clear goals and a solid value proposition for the project to focus on. Blockchain apps and javascript is not a business strategy. Lisk does not support smart contracts and to the best of my understanding does not currently offer app developers any reasonable support for their applications. 

The decentralized Microsoft play stated above is one example of a conceptual direction they could take and I believe there exist sufficient whitepapers and tech out there to make a push for it. I am uncertain exactly what Lisk is trying to do and honestly it hasn't been well communicated to me. 

As Lisk isn't my project and I just advise, it's perfectly ok for me to disagree with things or to say that I can't divine the reason for XYZ. It's Max and Oliver's project and they were entrusted with over ten million dollars. I'm just the guy in the back. However, what has deeply frustrated me throughout this process is the lack of communication and strategic execution.

I've always been just an email or skype message away and I have one of the deepest networks in the cryptocurrency space. My value as an advisor was to share that network at any time. It really wasn't used. For example, I was totally willing to help vet and hire candidates. This was never asked. I was totally willing to help get security auditing setup or assist in planning out a whitepaper. Again never asked.

Hence, I- like many in the Lisk community- was left on the outside looking on in hoping for progress. In the meantime, some in the Ethereum community blamed me for the failures of Lisk. I recall one post on reddit entitled Charles Hoskinson's CV and then posting a price chart of Lisk. It was hurtful, unfair and exactly what one expects from the cruel internet.

If there was a point to taking the criticism, I'd be willing to brush it off. But not being utilized, I can't honestly understand why it's necessary or fair. I've always wanted to see young entrepreneurs in this space succeed and I have spent hundreds of uncompensated hours answering emails and skype calls from dozens of projects providing advice. In fact, my entry point in the cryptocurrency space was through a free MooC Brian Goss and I created on Bitcoin.

While I really want to see Max and Oliver succeed and for Lisk to become a prominent project with real utility and good technology, I'm not sure I'm the best fit to advise them on how to get there for whatever reasons. Therefore, I'm officially resigning as an advisor.

This doesn't mean that I think Max and Oliver are bad people or that Lisk will fail. It just means that my role wasn't being utilized and thus I'd like to move on to not waste anyone's time or resources.

As a final point, I honestly do hope that the Lisk Foundation funds an independent team to develop a parallel client. I think competition would do the project a lot of good. I also hope they draft a whitepaper clearly outlining the goals and value proposition of Lisk.

If there is any technology in IOHK's portfolio that's useful to Lisk, they are of course welcome to use it (everything we have is open source). I'm also always willing to answer an email if it should come across my inbox.

Thanks for reading,
Charles

Some Thoughts on ETC

As the past few weeks in ETC land have been filled with a bit of drama and uncertainty that is bubbling into the public domain, I've decided to collect my thoughts into a single document. First, it's always a rude awakening being reminded how much FUD, trolling and in some cases genuine hate the internet brings out in people. I suppose it's a toxic blend of anonymity and lack of social pressure to behave like reasonable human beings.

This said, I've seen a lot of good people step up over the last few days in particular with good arguments, support or at least constructive criticism. Such things give me hope. And I continue to hope that we can be civil as a community despite the idiocy of a few bad actors.

Now on to my points. There are three that I'd like to discuss. First, the ECIP 1017 monetary policy proposal. Second, IOHK's treasury proposal and future roadmaps. Third, a broader point on community management and governance.

With respect to ECIP 1017, I think Snaproll has done a great job producing something fair and timely for our community. I'm in full support of it and I'd like to see it approved and implemented. My reservations actually don't come from a desire to install a hook for a treasury, but this of course would be nice, but rather a lack of process for communicating with all the major stakeholders.

ETC isn't just Slack or Reddit. There are other communities that are directly responsible for the success of the project that either cannot or will not use our standard communication mediums. Second, they, in some cases, do not speak English. My primary reservation is that we cannot change the social contract of ETC without their consent or we have every right to expect a surprise fork just like the EF endured.

IOHK has been proactively trying to broadcast the need for a MP discussion in places like China and we've even sent Carlo there in person. I'd love to see both Snaproll and Elaine enter this market as well for several face to face meetings. Yes this process takes time, but it can and should be expedited.

In reality, if conversations began now, then unless there is strong opposition to ECIP 1017, I think we can get final approval in mid-March and then it's a settled matter. Things could go wrong, but as with Die Hard, I've been amazed at our ability to pull together when absolutely necessary.

Second, IOHK has recently released a treasury proposal. I would like to apologize for it's poor and confusing release to the general public. We intended on a soft discussion that would gradually solidify over time. It was not meant to be a papal bull encased in immutable canon law once given.

I want the community to understand a few points. First, we are all paying an inflation tax at the moment to miners. This tax is in the form of coinbase awards and it's a standard notion as we consider it for a common good. It's clear to those in the game theory business and those who understand that mining alone isn't sufficient to maintain a healthy network that we need to have a serious discussion about other incentivized behaviors.

People need to store the blockchain for the system to work. People need to relay data upon request. There needs to be bootstrap nodes. There needs to be developers maintaining the protocol. There is community management and marketing. There are DApp developers who need capital to deploy contracts on our network.

If the protocol cannot make financial accommodations for these actors, then we face either the unpredictability of volunteerism, which has never historically scaled (Here's a great article providing an elucidating example) or we endure the soft federation of patrons buying influence through subsidies. The latter is more likely and inevitable.

My purpose in bringing up the treasury discussion is to make sure we in the future social contract of ETC understand the need to diversify incentives beyond mining. A treasury gives the stakeholders of the system a much larger role and provides the competitive advantage of guaranteed capital for long term projects. More abstractly, let's try to cut the inflation pie into more than a single piece for a single group.

My second point is that I do not believe that it is wise or sane to implement a treasury system with a smart contract. It will take likely 6-12 months of research and development to build a proper peer reviewed and tested treasury system (something the DAO never did) and we will likely have to introduce new cryptographic primitives, data structures and other pieces of complexity to implement this system. The earliest it can be safely done would be Q1 of 2018.

Utilizing a smart contract for a global system would make it bloated, force development in a sub-optimal language solidity and greatly restrict our flexibility. It makes no more sense to me to embed a treasury's mechanics into a smart contract than to embed our consensus algorithm into one.

Third, I would like to remind everyone that one of the reasons the hard fork occurred is that the core entity pushing it has absolutely no accountability to the stakeholders of Ethereum. The EF cannot be defunded or compelled to behave in a certain way from the holders of Ether. It's effectively like a supreme court justice in power for life without fear or recourse for actions beyond brand damage.

Decentralizing the capital available to the ecosystem and making it flow in stages with contingencies and revokeability would completely change the social dynamic. An entity like the EF would be forced to ask have they really achieved proper consent from the community for an action. Lack of consent wouldn't breed anger, it would remove capital.

This mechanism is an extremely powerful governance tool and ought to be explored. ETC was founded with the goal of minimizing centralization and strongmen pushing us into bad directions.

My last point, with respect to the treasury, is that we should dream big with ETC. The reality is that smart contract competition is going to get extremely tough in 2017. Tezos is launching with smart contracts. Rootstock will be a player in the second half of this year. Ethereum continues to evolve rapidly. There will also be many more.

If ETC wants to stay relevant and survive, then we cannot be the litecoin of smart contracts. We need to seriously differentiate ourselves from Ethereum and the rest in class. This means we need to get used to discussions about new consensus algorithms, better and more secure smart contracts, decentralized funding and other topics. The advantage is that we have the total freedom to pursue any path, but we need to pick one.

To me, the worst thing we could do is be overly conservative. I cannot understand how just being Ethereum that stuck to mining will make us competitive at all. Rootstock will have far more hash power, the stability of the Bitcoin network and one of the top InfoSec minds in the world behind their client (which is also five times faster than the original EthereumJ client they forked and modified).

I've had a chance to read so many great papers that provide a lot of cool insight into how we can do something special. For example, here's one on adding concurrency to smart contracts jointly published out of Yale and Brown. Loi lou and his co-authors published a wonderful set of recommendations for smarter smart contracts here. There are dozens more.

IOHK has two research centers and soon more. We have some of the best cryptographers and PLT folks in the world working with us on a daily basis. We are willing to put in the legwork to build out an extremely competitive roadmap for ETC to be a best in class protocol, but we can't and won't invest the time and effort for this work if the community simply wants to litecoin.

In any event, we'll continue developing and release the Grothendieck client without any divergent code from the Geth and Parity clients maintained for ETC. Whether we continue supporting this client through 2018 and beyond will be totally dependent on the roadmap ETC settles on.

Now on to my final topic, community management and governance. When ETC first began, I quickly hired two people. Christian Seberino and Carlo Vicari. They serve totally different, yet complimentary roles. Christian is subsidized to write at least one article a week on a blockchain topic related to ETC. We have no editorial control over his work nor have ever asked him to support a particular idea.

I realized that as our roadmap evolves, it's going to be important to have several people in an objective explainer role similar to Andreas for Bitcoin. Our relationship with Christian is to bootstrap the development of these characteristics in the community.

Carlo is a traditional community manager. He's responsible for accurately broadcasting news and events, creating more positive interactions between community members and also dealing with crisis control when bad events happen like unexpected bugs, security flaws or hacks. We have limited oversight over Carlo and he mostly operates autonomously. The exception is usually when I ask him to travel to places like England, Japan or China to talk to a particular group like the London MP event for example.

It's important to understand that while I pay Christian and Carlo, they ultimately work for you. They are resources for the community and exactly the type of roles that a treasury could eventually cover.

The last thing I'll mention is the core/reference client issue I've had with the Geth team. It's extremely distasteful to me that some members of this community have decided to view the formalization of this team to mean the IOHK is somehow on the peripheral of core development or is less important to the community than Splix or Elaine.

Let me be blunt. Taking someone else's code, making some modifications does not make you a core developer of a project. No one has nor should have a mandate to be in charge of the reference client for ETC. As the weekly Grothendieck stand-ups should make very clear to the general public, Ethereum is an extremely complex protocol.

While I have tremendous respect for the work the ETC devs have been able to accomplish, it's necessary to point out that it took Jeff, Vitalik and Gavin nearly two years to launch the Frontier client with the aid of dozens of contributors and much security auditing. Even still, they got a lot wrong that had to be fixed over another year.

No one in our community has publicly demonstrated an equal level of competency as the EF's core developers. This observation is not an insult or an attack on intelligence. It's a merit based fact.

In my view, the only way to demonstrate competency is to build a client from scratch or spend many months of heavy refactoring of the original source base. Perhaps this view is misguided, but it's the one we adopted at IOHK. We could have hired Go or Rust developers and contributed to the currently used clients, but I felt it would eventually lead to a disaster where a lack of experience led to a bad update.

This view means that Grothendieck has not been able to participate in the recent two hard forks or contribute code yet to the clients currently in use. Some have inferred from this lack of contribution that we are thus worthless to the effort or do not deserve to be considered core developers. It's hurtful and counterproductive to the community.

Seven full time Scala developers each with a decade or more of development experience is not a cheap proposition. IOHK made this commitment and will see it through. I personally spent many hours- usually late at night- reviewing resumes of candidates for the Grothendieck team. I didn't have the time for it, but I found it because I really do care about this project.

My point here is that there is no core client or core developers. Anyone who claims this mandate or infers or implies it is trying to centralize the project. I am directly asking the geth team to stop using core or reference when discussing their efforts. I am also directly asking the community to reject any attempt to establish a reference client.

There is a formal specification for Ethereum. It's Gavin's yellow paper. We will work to improve it and also add more detail and content. But to assert there is a reference client, in my view will lead to a small group of people having near totally control over the roadmap and direction of the project.

Thanks for reading,
Charles