Monday, March 6, 2017

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,


Tuesday, February 28, 2017

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,

Saturday, February 25, 2017

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,