Sometimes one can hear at conferences or read online that philosophy is needed in the blockchain space. Most of the time, this is a well-meaning suggestion from people deeply appreciative of the multifaceted (and at times very peculiar) nature of blockchain engineering and research. I have some reservations about whether this suggestion should be presented in such a strong modality. After all, this is a very open question if the blockchain field needs philosophy. In fact, many philosophers themselves, from time to time, express doubts about whether anyone really needs philosophy. At the same time, it feels somewhat disheartening to just ignore these well-meaning suggestions. Perhaps we can ask a different question: 'Can philosophy be useful (maybe even a bit) when we build, design, and use blockchain-based applications?'. And intuitively, it seems that it just might be.
To untangle these intuitions into more specific suggestions, we can try to identify some parallels between classes of problems or areas of interest common to blockchain and philosophy people. Well, for one, both of these fields are deeply permissionless both in spirit and nature. Sure, we have a venerable tradition of academic research relevant to both of these fields, with associated formal and institutional frameworks. And yet there is no single entity or institution in the world with the definite central authority to certify something as 'true blockchain' or 'true philosophy'.
What we call philosophy historically is a product of consensus between validating parties. Anyone can create their own philosophy, and if enough people are incentivized to maintain and participate, it will achieve liveness and decent adoption. Now the downside of that is, of course, an abundance of completely inconsistent and unworkable philosophies that nevertheless found a significant amount of confused participants throughout history. I will leave it to the reader to find parallels with the blockchain world, but there are plenty. Yet, this permissionless spirit is also a source of endless creativity and ingenuity. Not unlike impactful philosophers of the past, blockchain engineers keep inventing and re-inventing conceptual worlds, designing new (sometimes so questionable they would make Plato proud) models of society, and with immense persistence try to solve problems judged to be unsolvable or unimportant by others.
Thus, it is no surprise that many engineers, researchers, and inventors in blockchain space find themselves dabbling with issues that many philosophers have dealt with (with varying degrees of success).
One of those problems familiar to philosophers as well can be labelled as ‘Levels of Abstraction’. Coders, engineers, and computer scientists love levels of abstraction and layers. To borrow an expression from one of the lecturers from the introductory class to CS students: "We have to use layers; otherwise, our puny human brain would not be able to handle the complexity." Indeed, separating the system under question into different layers is quite a convenient way to grasp different components, functions, or problems in a more meaningful and focused way. OSI and TCP/IP models are well-known examples of conceptual models used to address complexity.
Layering models are no less popular in the context of a blockchain system. At the moment of the writing of this blog, arguments on 'layer three' scalability solutions sound practically mainstream. It is common also to hear expressions like 'this is a governance layer problem' or 'this is a social layer problem.' So it is safe to say that layer thinking is also quite popular in the blockchain space. What is less clear is whether such thinking does help to address complexity or creates more of it. The problem here is that decentralized systems like actual blockchains (some insist on calling them 'permissionless blockchains' for whatever reason) generate emergent properties and emerging complexity. Even a seemingly simple idea of DAO (we just collaborate online) is a compound complexity on top of a DeFi complexity, on top of a Smart contract complexity, on top of a consensus protocol complexity, on top of network complexity. This also means that with the increase of scale and application, a layering model which once was useful becomes either reductionist or naive or both.
Case in point: the standard practice in blockchain engineering to dump down all non-technical aspects into one 'social layer'. This may sound like a convenient way to deal with everything that is: a) not important right now; b) other people's problem; c) will resolve itself after the bull market resumes. However, one could argue that maybe we should try to avoid such reductionist models. Not just as an exercise in intellectual honesty but also from a purely pragmatic perspective. Simplification tend to ignore implicit assumptions swiping them under the rug of ‘social layer’, which leads to piles of hidden complexity. For example, attempts to address Sybil attacks at the application layer just incentivise the creation of novel and ingenious tools to deprive DAPPs users’ of the little privacy they have, instead of achieving the stated goal. Because of course, the generation of fake identities is just pushed to different layers.
What can we do to avoid simplification? Well, we could use a more rational approach to the modelling of systems. For instance, we could try to consider different levels of abstraction for a blockchain system not as a technical system with one blob of ‘social layer’ but rather as a non-trivial socio-technical system. This means that the functioning of each layer and system as a whole critically depends on the specific behavior of human participants at each layer. If we use traditional layering, say borrowed from networking, this gives us only a partial picture. But if we want to analyze blockchain as a socio-technical system, we may need to consider the influence of the 'socio' part on different layers and how these layers are related in terms of mutual influence and dependency. For instance, we can consider different social layers distinguished by norms that define the roles and behaviour of human participants of a system at various levels of abstraction. In other words, what do we want different people to do so that our blockchain works:
Meta-rules (rules for the EIP proposals and acceptance), rules for the development of codebase, rules for the acceptance of pull requests, and the infamous ‘loose social consensus');
Rules creation (Developer meetups, forums, etc.), actual EIPs, implementations, actual pull requests;
Application of rules (Miners), validators;
Following the rules (Clients, smart contracts).
This type of layering can be a helpful approach to highlight dependencies regarding different participants. For instance, it could be argued that the whole epic saga of Miner Extractable Value (MEV), is the result of a complete detachment between rules and incentives at different layers. The issue of arbitrary transaction ordering in cryptocurrency protocols was simply not that significant given the absence of serious incentives to do so. Thus, these protocols do not bother themselves with explicit rules on mempool accountability or enforcement of a particular transaction ordering. However, once we add smart contracts and DAPPs on top of it creating new economic incentives for miners at mempool level, we get dark forest and Jaredfromsubway.eth. This is of course not an argument to create permissoned DAPP store, just an observation that unexamined interaction of norms and incentives at different layers lead to funny outcomes. We are witnessing it now with restaking, happening all over again, and it will happen many more times in the future. But to talk about these and other issues in a meaningful and fruitful way we need good analytical approaches and other tools, which brings us to the next topic, namely proper conceptual frameworks.
Many square meters of doodles on a whiteboard written non-stop for a few days, is what it takes to come up with just one reasonably clear model of a decentralized system. Describing it coherently and clearly to other people is yet another task. This task is often complicated by the fact that despite reasonable maturity of distributed systems research in academia and in industry there is actually very little agreement on proper terminology. To bring up one notorious example already creeping in in this paragraph: is it distributed? Is it decentralized? Which one is which? Many computer scientists and industry developers will disagree on these terms. Well, philosophy is all about conceptual disagreements and complex mental abstractions, and sure not all of them always make sense. Still, a good deal of philosophy can be used to build reasonably coherent and meaningful conceptual models.
One issue which could benefit from conceptual analysis is an overabundance of interdisciplinary terminology in the blockchain space. As blockchains are not-trivial socio-technical systems, little surprise that concepts from humanities and engineering are often mixed together and conflated. The word 'trust' is easily one of the most infamous examples of that. In itself, it is not a problem if people want to talk about different aspects of such a rich phenomenon. But it may become a problem when we start arguing about different things as if this is one thing. Not to mention freshly-baked blockchain critics appearing each year with the same argument: 'But no, you still have to trust developers, no Blockchain is not trustless. Check and mate blockchain people!' The latter argument is, of course, harmless and irrelevant as it fails to grasp the specific meaning of 'trust' here. I mean, one can criticize gossip protocol designers because their solutions fail to spread interesting and fresh gossip about (INSERT SOME CELEBRITY NAME). Not that anyone will care about people trying to make such criticism. Still, generally speaking, it is helpful to strive for conceptual clarity when engineering complex systems.
One way to look at this problem through the prism of conceptual analysis is to consider 'trust' as a peculiar example of so-called conceptual slippage. This happens when the concept is borrowed from a different field (social studies/game theory) and stuffed with a different meaning (in P2P) or reduced to a very specific meaning (in security). Not just fields, even subfields in computer science also tend to have different conceptions of ‘trust’. And when the field (distributed systems) expands to incorporate new contexts (blockchains with human participants), we still keep applying modified/reduced concepts in a broader context with often confusing results. This means that we need to enrich the concept again to make it appropriate for this extended context.
But of course, there are many more cases that could benefit from closer scrutiny. 'Consensus' is yet another concept that seems to bring a lot of confusion between technical and social interpretations, not only for outsiders but also for some blockchain projects. In other words, when project developers tend to forget that having a running consensus protocol does not automatically address all the issues that require social consensus. This is an honest mistake since we still do not completely understand the complexity of layers for blockchain systems.
And then, of course, there is plenty of overlap and mixture between different terminology. Going back to the ‘decentralized’ and ‘distributed’ distinction. Many computer scientists prefer to distinguish between ‘centralized distributed’ systems (cloud) and ‘decentralized distributed’ systems (P2P); industry developers sometimes use distributed in the sense of 'super decentralized’. This is completely understandable, given that the concept of ‘decentralization’ is not only open to various interpretations in different contexts, but also a fine example of what is called in philosophy an essentially contested concept. This happens when people have a vested interest in insisting on a particular definition, maybe because it fits the system they are building, maybe because this is how it is defined by their peers, or for any other reasons. Some of these issues can be properly addressed with some help from a good old conceptual analysis and a dash of scepticism, which is coincidentally the third point of this blog post.
Philosophy is very good as skepticism: “Do we really know things as they are, are we brains in a vat? What if zoo authorities painted all horses at the local zoo into zebras.”
And yes, this is a real citation from a respectable philosopher and not a twitter conspiracy theory account. Most strange sceptical arguments are cherished by philosophers as necessary tools of trade. The inevitable consequence of an ever-present skepticism is that philosophers (at least those that are honest with themselves) tend to simultaneously entertain strong beliefs in the correctness of their arguments with constant doubts about the coherence and soundness of these mental constructions.
Would such skepticism do any good in the blockchain space? There is a lot of circumstantial evidence that it would indeed. It certainly does not hurt to maintain a constant healthy dose of skepticism while engaging in blockchain experimentation, and we are not only talking about 'farm yields' that sound too good to be true, or 'supercycle' promises. Engineering and system modelling for blockchain solutions also can benefit from a healthy dose of skepticism. For one, there are a lot of hidden assumptions in blockchain engineering that we tend to ignore or accept uncritically. It is safe to say that a good deal of assumptions on economic incentives or tokenomics falls in the category of blind faith or vague assumptions. Can your algorithmic coin maintain the peg? MEV is not a big deal… the list goes on. Does this mean that we should not try new things? No, of course not, but the point is that it would be helpful to be honest with our assumptions, and try to distinguish between designs and system components that we understand relatively well and those parts that we do not understand yet.
Another cool part about skepticism is that it can help to distinguish between relevant and irrelevant critical arguments and highlight constructive criticism. For instance, in order to evaluate these arguments, we can consider whether these arguments are using a valid conceptual framework and level of abstraction that corresponds to the subject of criticism. E.g., saying that smart contracts do not have the same qualities as legal contracts and thus should be done differently is not a relevant or constructive criticism. On the other hand, saying that smart contract development driven primarily by gas-optimization strategies does not align well with good software engineering practices is a constructive criticism.
Finally, healthy skepticism is a must-have in a space dominated by information asymmetries, between founders and VCs, between developers and users, between crypto exchanges and investors… the list goes on. In other words, it means that the distribution of expert and accurate knowledge is very, very, very uneven in blockchain space. One can say that blockchain space is not just characterized, but defined by the information asymmetries both of intentional and unintentional nature. These asymmetries are unfortunately incentivized because information advantage is often easily monetizable in this space. Then, there are also objective asymmetries rooted in the complexity of blockchain systems that require some very particular expert knowledge like cryptography of distributed systems engineering. And, of course, the constantly increasing number of new projects and more specialized solutions makes it quite challenging to navigate the space for anybody, including blockchain researchers. Here again, correct terminology and correct level of abstraction can do wonders. Not to mention a good habit of verifying as much as possible in a true spirit of healthy skepticism, which is one of the original values of blockchain space if you think about it.
So after all, maybe some amount of philosophy could be useful in blockchain research and engineering as well. Inspired by this thought, this blog will keep presenting and elaborating on some of these and other intuitions on blockchains and philosophy. All presented thoughts are superficial conjectures at best, and you should not expect profound insights from these posts. However, the blog's authors hope that the blockchain research and development field is still at that level of maturity when naive ideas can be valuable; after all, "we are still early”™.