Q & A on Q (Part 2)

A while ago I wrote a blog post Q&A on Q (Part 1). As the title suggests, I promised to publish a second part, answering questions that I did not cover in Part 1. It’s taken a while, but finally — here it is.

As a reminder, the questions covered are of the type that I am typically asked by people who have already had a first intro to Q and are interested in learning more. If you are new to the Q Protocol, I recommend to check out other resources first: browsing the website and checking out the White Paper is a good way to start.

With that out of the way, here we go:

1) Is the Q community against “code-is-law”?

No.

In fact, I would argue it is the opposite: We love the concept of code-is-law — we are just using it as (we believe) it was originally intended. In a way, we hope to bring about a renaissance of the concept of code-is-law, but in a richer, more nuanced and ultimately more useful way compared to how the term is currently used in the crypto community.

How so? Let me explain. First, a brief history lesson: The term “code is law” was coined by Harvard professor Lawrence Lessig in his book Code and Other Laws of Cyberspace. Surprisingly to some, this book was first published in 1999 — long before cryptocurrencies, blockchains and smart contract platforms even existed.

What Lessig described with the term code-is-law is that in specific circumstances, computer code can functionally have similar effects as the law: Both the law and computer code can be tools to regulate behaviour and enforce rules. In this sense, code can complement or even replace law. In short: “code is law”.

What is important to note is that the statement that “code is law” in itself is a positive one, not a normative one: it describes a fact rather than an opinion of whether this is good or not. Whether or not code should replace law, and if so, in which circumstances and how, is another question. If anything, Lessig was critical of the potential consequences of the internet becoming an “unregulable”, lawless place. In a 2000 Harvard Magazine article, Lessig wrote that “no thought is more dangerous to the future of liberty in cyberspace than this faith in freedom guaranteed by the code”.

When blockchain came about a decade later, the crypto community happily co-opted the term code-is-law. Understandably, since it seemed to perfectly encapsulate the value proposition of cryptocurrencies like Bitcoin and smart contract platforms like Ethereum: the functionality that they provide is enshrined in code, and execution of the code is guaranteed by the cryptoeconomic principles that make the underlying blockchains immune to manipulation or censorship. Therefore, we do not need a legal system to enforce transactions — we now have blockchains to to that.

So far, so good. But what happened fairly quickly was that the term code-is-law was (ab)used beyond its original intention. Rather than positively describing the objective characteristics and functionality of code, it was turned into a normative statement: Code should be law. With legal systems being prone to manipulation by the humans that run it, blockchain-based code was seen as the superior solution to regulate behaviour. Code-is-law thus became a rallying cry for many within the crypto community that were looking to replace law with code not only in some, but in pretty much all areas of life.

While this extreme view might have been well-intentioned, reflecting the cypherpunk spirit of the crypto community, it is also fairly naive. Anyone with a basic understanding of law, economics or computer science should easily understand that not all human interaction can — or should — be regulated by code alone. Recently, Lessig himself called out this “really embarrassing inversion of my slogan”.

Let’s take economics (the discipline I am most qualified to talk about): The theory of incomplete contracts describes that not all future states of the world can be known, and therefore legal contracts tend to be “incomplete” — the gap being filled by the interpretation of courts of law when necessary. This, of course, also means that most contracts cannot be represented by code alone, since this would require knowledge of all future states of the world that are relevant to the respective contract (and by the way: no, AI does not solve this). The challenge is thus to figure out which types of contracts — or which parts thereof — can be represented by code. Where this is the case, code tends to do a better job than the law, since it is transparent and deterministic. In these circumstances, rule enforcement via code is cheaper, faster and less prone to error. But where this is not the case, we still need legal frameworks and infrastructure to fill the gap.

A nuanced approach will take the best of both worlds: It is not code OR law, it is code AND law. By optimizing the interplay between the two based on their respective strengths and weaknesses, we have a shot at achieving the the best results for the humans that use code-based infrastructure.

2) Aren’t root nodes effectively controlling the system?

No. While root nodes are an integral part of the Q Protocol and are critical for the enforcement of protocol rules, they certainly do not control it. This is true both in relation to the Q Protocol itself as well as to other applications or DAOs that use Q’s governance opt-in features.

Here is some background information to better understand the role of root nodes:

• The role of root nodes, including their rights and obligations, is defined in the Q Constitution. They do not have any formal powers beyond those that are given to them in the Q Constitution.
• Root nodes are not involved in block production. Therefore, they cannot actively alter or censor the state of the Q Blockchain.
• All changes to the Q Protocol are effected via constitution changes. Root nodes can veto such changes on the basis that they do not comply with the Q Constitution, but not on any other grounds. They are strictly bound by the Q Constitution and have a clearly defined scope of discretion within which they make decisions.
• Root nodes are free to participate in discussions and propose constitution changes. However, as there is no concept of “rough social consensus” in Q, their role in such discussions is not different from that of any other Q token holder.
• For other dApps, DAOs or protocols that integrate into the Q governance framework and use Q’s opt-in governance features, root nodes’ roles and responsibilities are just as clearly defined, and are always based on an active opt-in of the respective dApp, DAO or protocol.

In essence, the rules of Q are clear in that root nodes have a specific function that is critical for the system but does not result in them controlling it. Their role is largely passive, guaranteeing the integrity of agreed-upon rules.

But how can we be sure that this will be the case and root nodes do not abuse their powers? Well, there are a number of checks and balances to keep root nodes in check:

• The selection criteria for root nodes ensure that there is no dominant root node sub-group that is likely to collude to corrupt the system. Root nodes need to be from different verticals, making sure there no specific interest group dominates the root node panel, and from different jurisdictions, making sure that legal capture in a specific jurisdiction does not impact the integrity of the root node panel overall.
• Root nodes are known by their real-world identity, meaning that there is a reputational damage if they compromise on their integrity.
• Root nodes need to put up stake which can be slashed in case of misbehaviour.
• Root nodes’ liability is not limited to their stake. Combined with the fact that they are publicly known, this results in a very strong incentive to comply with the agreed-upon rules of the Q Constitution.
• Root nodes are rewarded via fixed token rewards for their service. They cannot increase rewards by adding stake or delegations, which supports their independence by making them immune to the type of “popularity contests” that are often seen in delegate systems.
• Root nodes are subject to Q’s dispute resolution mechanism, meaning that any token holder can bring a claim against a root node if they think that the root node is in non-compliance with the rules.
• Root nodes can be replaced by token holder vote. If they are voted out, root nodes lose their valuable slot in the root node panel. This is a strong incentive against misbehvaiour. And since they identity is known, they cannot just re-enter the panel under a different name or address.

So if root nodes do not control the Q Protocol, is the Q Protocol’s functioning dependent on them? I would say yes, at least for the protocol’s core functionality, which is to provide shared governance security — both for the core protocol itself and for other dApps, DAOs and protocols.

On the other hand, even without root nodes the Q Protocol would still provide the same functionality as other Layer 1 blockchains. As the comedian Mitch Hedberg postulated in one of his two-liner jokes, “an escalator can never break — it can just become stairs”. Similarly, for Q in the case of a malfunctioning of root nodes, we could postulate the “Q can never break — it can just become a Layer 1 blockchain”.

3) Why is Q built as a Layer 1 blockchain? Why not as an application on Ethereum? Why not as a Layer 2? Why not as a centralized company?

This question touches on one of the fundamental design choices of Q and probably warrants a more in-depth discussion than can be provided in a short blog post. I will therefore only give a brief overview of my thoughts on the topic here.

First, let me say that this is a question to which the answer might change over time. For example: when we started working on Q, roll-ups, or more generically Layer 2s, did not yet exist. Today they do, although they still have what people euphemistically call “training wheels”. In my personal view, L2s are therefore not yet ready for prime time, and I think it would be irresponsible to deploy security-critical infrastructure such as Q on a system that is ultimately controlled by a multisig or has other known single points of failure. However, we can expect L2s — and more generally the whole modular blockchain stack — to evolve. Therefore, the answer to the question “what’s the best technical basis for Q” might well be different a few years down the road.

The nice thing about Q is, however, that whatever technological developments materialize from here on, the protocol’s governance framework allows for a structured and orderly process to adopt the latest technology. I would expect the Q community to take a “smart follower” approach for many infrastructure decisions, meaning that new and better technology can be adopted when it is sufficiently mature, while allowing the Q community to focus on what Q does best: provide shared governance security.

With all that said, there are good arguments as to why a Layer 1 is — at least as of today — the appropriate design choice for Q. For me, it comes down to two main aspects: Economic security and sovereignty.

Economic security relates to the most basic cryptoeconomic principle that the cost to corrupt the system should exceed the reward of corrupting the system. We therefore need an economic value of Q that exceeds that of individual dApps built on top of it.

Economic security is much easier to bootstrap for Layer 1 blockchain than for an application, since the Layer 1 has a value in and of itself as an infrastructure layer, even if there is (yet) only limited value protected by the Layer 1. In a steady state, where there is lots of value protected by it, an application might provide a level of security that comes close; but the bootstrapping of this security is hard. The first few applications using governance security provided by another app would be inherently insecure, since they would suffer form the same security deficiency as protocols controlled by their governance tokens today.

Bootstrapping the required economic security might be possible via a Layer 2, but this is highly uncertain due to the lack of an established underlying economic model of L2s. Today we observe sky-high valuations of L2s, but those are still largely speculative. I would personally be reluctant to base security-critical infrastructure on a design with unproven or even unsound economics.

In theory, a traditional company could provide sufficient economic security in a steady state. Practically, though, it takes years for company shares to not only accrue value but also be fungible and sufficiently liquid for economic security to even be relevant, so this is not an option.

The Layer 1 option, on the other hand, provides economic security from Day 1. The economic design of Q is based on a virtuous circle where governance fees capture part of the value created by its integrated applications, which in turn strengthens the security of the Layer 1 blockchain, which in turn provides stronger security guarantees compared to other Layer 1 blockchains with similar levels of economic activity.

Independent of economic security, though, none of the alternatives solve the sovereignty problem.

Sovereignty in the context of providing governance security means that the system should be secure in and of itself and not rely on the security of another system. This is the case for a Layer 1 blockchain, which is a self-sufficient and self-sovereign system. If Ethereum (or any other L1) broke down tomorrow, Q itself would be unaffected. The same cannot be said of applications or of Layer 2 solutions, which anchor transaction security on Ethereum’s mainnet. If Q were a dApp on Ethereum, or a Layer 2 on Ethereum, the ultimate authority whether or not a transaction would be accepted — and this critically includes governance transactions — would not lie with Q, but with Ethereum. If Ethereum validators decided to censor Q transactions in this scenario, Q stakeholders could do little about it.

Now I know that such statements may ruffle some feathers with “Ethereum maxis” who think of Ethereum as perfectly neutral. While I think that Ethereum is without a doubt the “most neutral” of the large smart contract platforms, I also think that the Ethereum community is still in the discovery phase of what exactly base layer neutrality means. Let me give you three data points: (1) discussions around OFAC sanctions, which are still ongoing and somewhat unresolved — this showed that it is far from clear how Ethereum validators will position themselves if push comes to shove; (2) policy discussions around MEV, which is at its most basic level censorship on very short time scales — also here there is no agreement as to what exactly the problem is, and how it should be addressed; (3) the current discourse focusing on the role and “alignment” of Ethereum’s “social layer” (a.k.a. “people”) — this would not make any sense if there were complete clarity of what base layer neutrality actually meant.

Don’t get me wrong — this is not a criticism of Ethereum. Those are tough questions and I think that the Ethereum community, of which I consider myself to be a part of, does a good job in advancing these discussions. But for Q, the focus is clear: protection of its constitution under all circumstances. This goal is the driver behind many design choices, including the build-out as a Layer 1.

Lastly: Needless to say that a corporation as the basis for Q would ultimately not be sovereign but rely on the support of the relevant jurisdiction in which it is based. Again, the only solution that currently provides full sovereignty is a Layer 1 blockchain.

While those are the two most critical aspects, there are more — e.g. the state of existing infrastructure, tooling and UX associated with a specific technical implementation.

As with all design choices, there are trade-offs. For the current implementation of Q, those were taken with the goal in mind to create the best platform to provide shared governance security, even if this comes at the expense of convenience and cost.

Again: with ongoing technological developments, the optimal choice might look different in the future. What I would personally strongly oppose, however, is to make fundamental design choices dependent on “fashion” or hype around certain narratives. We all know that those short-term trends come and go, and if we want to build infrastructure for generations to come, we should not divert from first-principles thinking.

4) If root nodes’ identities are known, aren’t they more easily corrupted?

In the interest of providing a balanced discussion, I think it is fair to say that there are pros and cons do the requirement of revealing root nodes’ identities.

The argument against it is simple: Knowing who root nodes are makes it easy to contact them, which in turn makes it easier to corrupt them. Note that corruption can take on a number of forms on a very wide spectrum — from exercising soft power in a subtle yet inappropriate way to outright payment-for-votes or even extortion.

However, I would argue that in crypto, knowing the identity of someone is not a prerequisite for corrupting that person or entity. Online and on-chain, it is easy to get in touch with someone if you want to, make payments and monitor desired behaviour. In fact, there even are bribing protocols that facilitate such transactions. So while anonymity might avoid some types of overreach (e.g. from state actors), it does not per se protect against corruption.

The case for requiring root nodes to disclose their identity rests on the premise that they have a reputation which is of value to them. Any form of misbehaviour or corruption — if it becomes known — would seriously damage this reputation, thus providing a strong incentive for root nodes to stay honest. One of the key tenets of the dual-node infrastructure of Q is that both tiers of nodes (validator nodes and root nodes) have very different functions and are motivated differently. The respective rewards and incentives should reflect the motivational structure of each node layer. With root nodes’ motivation being not solely financial, the reputational aspect becomes relevant, and this aspect is strengthened by their identities being public.

Furthermore, known identities protect against sybils, which would severely undermine the purpose of the root node panel. Without sybil protection, it would be possible for a small number of root nodes (or even a single root node) to gain a majority in the root node panel, which would render the security guarantees which root nodes provide ineffective.

Finally, root nodes’ identity needs to be known to ensure that they are legal residents in a jurisdiction that enforces arbitral awards according to Q’s dispute resolution mechanism.

5) Don’t you think nation states would oppose a system that is in competition with local legal systems?

Generally speaking: no. In fact, many nation states encourage their citizens to rely on private agreements as much as possible, and to solve potential disputes privately, i.e. without resorting to the local judicial system. This has the great benefit that costs are borne by the contracting parties and not by the tax payer, which is the case (at least partially) if things are handled by the local courts. Legal infrastructure costs for the state can thus be contained, reducing tax payers’ burden and limiting bureaucratic overhead.

Interestingly, even nation states themselves increasingly rely on non-nation-state-based legal infrastructure. This is true both for treaties between nation states as well as contracts between nations and private enterprises. The “opting out” of local legal systems is an established practice where parties meet at eye-level and want to customize their contractual relationship. There are multiple benefits, including reduced cost, increased transparency, the option to preserve confidentiality and faster turnaround times of disputed cases. Furthermore, it provides parties with a “neutral ground” on which to meet, since typically no party wants to submit to the other party’s jurisdiction.

But there are also limitations to the general statement that nation states support the “opting out” of local legal systems.

For starters, this is typically possible only for agreements under private law. There are other areas of law where “opting out” is not possible. Examples include criminal law, tax law or consumer protection law. The details may vary between jurisdictions, but generally an opt-out works only for the legal areas that are covered by the respective jurisdiction’s “freedom of contract” rules.

Also, my analysis is written from the perspective of democratic and (relatively) free and open societies. Every nation state is different and there are nuances depending on which jurisdiction you look at. On the extreme end of the spectrum, autocratic or dictatorial regimes may not view alternative systems enabling private contracts as favourably as I have described above.

Lastly, it is worth mentioning that the border between what nation states define as their exclusive domains is constantly in flux and subject to a much broader societal discourse. An example that gained some publicity a few years ago was the proposed Transatlantic Trade and Investment Partnership (TTIP) discussed between the EU and the United States, which included a clause that effectively resulted in an “opt-out” of local law for in instances (the investor-state dispute settlement system). This was widely criticized because it was seen as bypassing not only local courts, but the democratic process as a whole in areas that some observers felt should be within the sovereignty of the nation state.

With ongoing dynamic and sometimes conflicting developments, such as globalization, the counter-trend towards localism or nationalism, and the emergence of new technology (such as blockchain, of course), I expect that discourse around the extent of sovereignty of nation states will gain relevance in the coming years or even decades. Wherever sovereignties overlap, you can expect discussion and sometimes conflict that will need to be negotiated on a broad societal level.

6) Isn’t a system whereby root nodes can veto decisions effectively the same as the multisig setups we know from other projects?

No. There are several differences which are material and which make Q’s governance architecture with its root node structure much more robust and censorship-resistant than even the most sophisticated multisig setup:

• Q root nodes exhibit a high degree of diversity, which is to ensure that there is no single attack vector via which root nodes could be compromised or corrupted, e.g. by being in a specific jurisdiction or by having similar particular interests because they belong to a certain industry vertical. This is typically not the case in multisig setups, where in the worst case, it is not even clear whether key holders are distinct persons and even in the best case, key holders are typically part of a relatively homogeneous group and often predominantly located in a specific jurisdiction.
• To make it concrete: Today, the root node panel comprises 26 parties from 13 different juridsictions and many different vertically, including infrastructure operators, lawyers, academics, corporates, DAOs and NGOs.
• Root nodes themselves are subject to Q’s dispute resolution mechanism, making it possible for any Q token holder to submit claims against root nodes in case of misbehaviour.
• Root nodes have to put up stake, which is subject to slashing in case of misbehaviour. However, the liability of root nodes is not limited to their staked Q, so there is even a possibility of executing claims into root nodes’ off-chain assets if their staked Q are not sufficient to cover claims.
• Slashing proposals can be initiated by any Q token holder, but on top of that, root nodes are also obliged to monitor each other and propose slashing of stake in case of misbehaviour.
• Root nodes’ real-life identity is known, and therefore there is the threat of reputational damage with a corresponding loss of future earnings potential in case of misbehaviour. Since their role as root node on Q typically represents only a small part of their total income streams, risking reputational damage which would negatively affect all their income streams would be a strategy with a negative expected value. In essence, the structural setup of root nodes ensures that they are independent and are highly unlikely to benefit from malicious behaviour.
• Root node permissions are tied to a specific natural or legal person, not to a wallet address. There is a vetting process with a dedicated expert panel checking on the information provided by root nodes.
• Root Nodes can be voted out by Q token holders, which have a very strong vested interest in keeping the Q Protocol compliant with its own rules. Through its concept of “shared governance security”, it also prevents a faction of a specific protocol or application on Q to gain dominance and influence the root node panel unduly through voting in or out friendly candidates.
• Lastly, and maybe most importantly, everything on Q happens “in-protocol” and is transparent and visible to the outside world. This is not the case with an admin key / multisig setup, where the “in-protocol” part ends with the address of the multisig holders. For everything else, protocol participants need to rely on information that is external to the protocol, i.e. real-life data of multisig holders or contracts regulating their behaviour. So even if a multisig setup tried to mimic all of Q’s features as described above, it would be practically impossible for protocol stakeholders to verify this. While a lot of things can be regulated in this way in principle, e.g. by way of drawing up legal paperwork defining certain obligations of multisig holders, those elements cannot be enforced in-protocol and are thus reliant on external trust systems. In contrast, the Q governance architecture aims to minimize trust assumptions needed and anchor all trust assumptions firmly within the Q Protocol.

7) Is a system like Q which requires human input scaleable?

In short: yes — but over longer time scales than systems that do not require continuous human input.

I am often faced with skepticism since Q requires human input, and scaling the protocol means that it will need more such human input. This is obviously different from purely technical systems that — once live — operate up to their scale limit with only a limited amount of human input. While this observation is correct in the short term, the situation is reversed over longer time scales. Systems like Q can in principle be scaled indefinitely, whereas technical systems hit technical scale limits at some point. So the question of scalability cannot be answered without taking into account time scales.

One thing that is important to to point out, and often not well understood, is that many — if not most — crypto protocols today already require a lot of human input and do so in a way that does not scale at all. As an example: Major protocols like Lido or MakerDAO each have annual “payroll” costs in the double-digit millions. The crazy part: A major part of this is for overhead activities that are duplicated across protocols. This is a highly inefficient way to organize human labour and flies in the face of the idea of building scaleable systems.

With Q’s concept of shared governance security, some of the human input related to governance activities can be shared, meaning that Q supports the scaling of existing crypto protocols in the very short-term.

As an analogy, think of existing governance systems in the traditional financial world. Bundling and sharing governance-related activities greatly reduces overhead while increasing security. Some activities such as standard setting (e.g. for accounting data, reference rates, life insurance mortality tables) scale indefinitely, meaning that if provided once with a sound governance behind it, they can be used by an indefinite number of users at no additional costs. Other activities such as dispute resolution or auditing services do require more input with more activity or users, but at a decreasing rate, resulting in significant economies of scale.

I expect the same to be true for Q, where for example certain expert panels can provide data that is relevant for a multitude of protocols, whereas for example the dispute resolution process will always require more input with an increasing number of users, although will still benefit from scale.

How scaling looks like in detail for Q is still unknown, but already today there are many ideas. Specifically, I believe that the concept of expert panels as it stands today is still in an early phase and can be adapted to scale. But also new governance mechanics that apply a variety of disciplines such as cryptoeconomics, game theory and social choice theory can support scaling. It is still early days and I am looking forward to seeing ideas being brought forward by the Q community.

— — —

Closing remarks

As with the first Q & A post, I am looking forward to feedback and discussion. And while I am not promising a third part this time, I do promise to engage with and support people and ideas that have the potential to advance the Q Protocol. So please reach out. Onwards!

A big thank you to Alice Zhang, Rashmi Abbigeri, Gerrit Brügge and Nicolas Biagosch for input to and review of this article!