The Conceptual Blockchain

By Allen Farrington on ALTCOIN MAGAZINE

“Money makes people mad. There is the idea of cryptocurrency and blockchain and this new idea of distributed trust in the Internet and then there is the very fundamental application of that technology which is a new kind of money. I think most people are unable to look objectively and dispassionately at the mechanics of how it works without getting pre-emptively upset: just angry. How dare the nerds come up with some new form of money! There has got to be something wrong with this! I will now attempt to find something wrong with this because obviously it violates the laws of nature and governments and whatever … And by the way, I’m not just talking about regular people, I’m talking about bank CEOs, who are just furious. You bring up Bitcoin and they get really upset, and I’m like, ‘did you get upset about your new toaster? It’s just a technology!’ “

Marc Andreessen, on the Tim Ferriss podcast

Photo by Clint Adair, via Unsplash

I am not going to address blockchain at a technical level. Sorry about that. There will be no talk of hashes, public/private key pairs, mining and the like, except where I absolutely can’t avoid it, assume you know what these mean anyway, and tell you to go learn if you don’t. I want to try to answer ‘what is a blockchain?’ at a conceptual level.

Heinz Pagels had an interesting idea in the philosophy of science that proposed a ‘causal decoupling’ of some physical processes from any requirement for further reductionist explanation. Very roughly, in many areas of science, absolutist reductionism may be logically and factually correct but unhelpful for understanding and hence for further discovery. Some concepts may be usefully primitive to a domain despite also having some deeper explanation, in theory in some other domain altogether. You can do genetics without microbiology, for example, or politics without neuroscience, or real analysis without set theory. This post could be thought of as an attempt to explore some ‘conceptual primitives’ of blockchain.

That said, just because you can do such things doesn’t mean you always should. Some facts about real analysis can only be appreciated by beginning with set theory. Blockchains are an engineering construct — arguably much simpler than nonstandard constructions of the real numbers, but also more ignorantly despised, but such is life — and the best way to understand an engineering blueprint is frankly to get your hands dirty trying to build to it. In which case you will have to understand hashes, public/private key pairs, mining, and all that jazz. If you are struggling with where to start, I highly recommend here. If not, or you don’t want to anyway, or you already have, let us proceed in Pagelsian fashion with some conceptual primitives.

I think the best way to understand blockchains nontechnically is as definitively novel combinations of three more basic concepts: a new kind of computer, a free and open source software project and community, and a decentralised corporation. Once this introductory waffle is out of the way — soon, I promise — this post is a detailed exploration of this definition.

Before getting started, I will comment briefly on the introductory quote from Marc Andreessen, professional baller. I included it partly because it is funny, but mainly because I think it does a good job of setting the desired tone for the discussion. I have tried to be as clear and precise as possible by what I mean by various terms, and to view the overall problem as abstractly as is still helpful (and understandable). This is precisely because of how easy it can be to address the question — what is a blockchain? — in an unhelpfully ideological manner, and equally from almost any ideological starting point. I have done my best to avoid this and to try to produce a thoughtful analysis of the capabilities of the technology. This functions as something of a disclaimer, however — I can’t imagine anybody would be motivated to go as in-depth on a technical level without ideological inspiration, at least in part. So, I readily admit to ideological motivations in the background, and apologise if, despite my best efforts, it has perverted this analysis at any point. In any case, I have done my best, and encourage the reader to do theirs too, to treat the topic like a toaster.

A New Kind of Computer

photo by Thaovy, via Pixabay

By ‘computer’ I do not mean a physical machine — an abacus, a calculator, a laptop, a web server in a datacentre, etc. — I mean an abstraction of computing along the following lines: a process that receives input data, stores and manipulates the data, and returns some output data. The previous examples are all physical instantiations of an abstract computer, and so the distinction may seem cute, but it is required in our case as blockchains are arguably the least ‘physical’ computers ever designed, insofar as the physical machinery running the computations are so widely distributed, and so constantly changing, that it is at best extremely unclear to refer to the totality of physical components involved — and at worst completely nonsensical.

In this section, I will describe why I think it is sensible to treat blockchains as a new kind of computer. However, I think a bit of sign-posting is in order as this is likely the densest and most abstract section of the entire post. Firstly, I compare blockchains to more widely understood abstractions of computers by considering what data constitutes the inputs, memory, and outputs, and what manipulations of the data are being carried out. Having answered this as, effectively, ‘making data scarce’, I compare the utility of such a computer to existing institutions that attempt to accomplish the same ends of artificial scarcity of data. I also compare it to the consideration of software companies as fitting the original abstraction of a computer, with the apparatus of a ‘corporation’ then built around it.

So, what input data is taken, how is it manipulated, and what is the output? In the loosest form possible, a blockchain is a data structure that is universally accessible and readable. Although there may be many nested data types, at the highest level the types are called ‘blocks’, which exist as an ordered list. There is a conference of some or other kind of ‘ownership’ of the data types within blocks, such that although everybody can see the data, part of what they can see is specifically who can alter the data they ‘own’. The blockchain is only writable by appending a new block to the end of the list. Adding this block happens only by blindly contributing computing power with a reward being assured only probabilistically. This block contains the same data types, newly formatted to represent the changes made by the owners of the data in the real-world time since the last block was added. There will also be a default additional change which is intended to be desirable, which serves as an incentive to those lending their (physical) computing power to the process. No previous blocks are altered, nor can they be, and only valid alterations are admitted to this block.

As promised, at this point it is impossible not to invoke cryptography, but we needn’t go into why. Interested readers can find plenty of helpful material online on SHA256 and RSA public/private key pairs. The relevant point here is that ‘can’t alter past blocks’ and ‘can’t submit invalid transactions’ are not matters of convention or law, but are mathematical near-certainties.

The overall data structure of the blockchain can be thought of as a ‘ledger’ recording every valid editing of the data types in its history. Finally, it is a ‘computer’ in the sense that it is constantly running to add valid alterations (the inputs), and broadcasting back the up-to-date top-level data structure to all involved in running it (the outputs).

Bitcoin is often cited as the prototypical blockchain, and although this is true for obvious historical reasons, it is worth considering why it is arguably conceptually prototypical also: the data structures in Bitcoin reflect ‘balances’ of a native and invented unit, and the alterations are transfers of this unit from its ‘owners’ to others. The default additional alteration is to add units to the balance of the accounts of those lending computing power. This is about as simple as possible, because even though we have an apparatus of nested data structures, etc., the sole function they serve is to change a list of name and number pairs; the names (pseudonymously) identify the users and the numbers mean nothing beyond themselves.

We might wonder what the point of all this is. What is so special about such a contrived ‘data structure’? Isn’t an excel file a data structure? The answer is that it is the first and only known way to electronically transfer data without an intermediary in such a way that the sender loses access to it after it is sent. It is the only known way to make data scarce.

So, for example, if I email you, this could be construed as me sending you text data. But I can send you the same email again, so I am not constrained in any way. To give a more economically relevant example, I could claim to sell you my credit card, such that you give me cash and I email you its details. However, clearly, I still have the details (assume I forget them, so I mean in my ‘sent folder’) so this sale is very dubious from your point of view. But don’t credit card companies perform the role I describe above, of facilitating the electronic transfer of data in such a way that access is lost after it is sent? After all, if you have a $1k credit card limit and you spend $700, then try to spend $500 again, it will fail, and you will eventually have to pay back the original $700.

No, this is not really what is happening at all. In fact, the credit card company is keeping a list of name and number pairs that it adjusts for everybody on their behalf. I can’t access what is supposedly mine on the list, and neither can you. The credit card company accesses everybody’s and maintains the illusion of everybody having access to their own by facilitating everybody’s valid requests. Blockchains strip the illusion from this process, making it possible for owners to directly spend what they have, impossible to spend what they don’t have, and unable to do anything to accounts that are not their own. They could be thought of as moving from mimicking data scarcity via a trusted central party to enforcing it via the cryptographic characteristics of the data structure. I think the expressions are overly rhetorical, but blockchains are often described as ‘automating trust’ or ‘distributing trust’, given they replace the role of the credit card company in this example, which held the activity together on the basis of being trusted to act honestly in updating the list of name and number pairs.

I set out to give the broader definition above, rather than describing more precisely how Bitcoin specifically works, because any aspect of this blueprint could be made more complex. I don’t want to go too far into it here as the possibilities are endless, but I think there are three good starting points: firstly, notice I said above that in Bitcoin, the numbers mean nothing beyond themselves. However, there is no reason for the meaning of the data to need be inferred by the users; the data could itself be functional code, and the process of updating the chain could include, in part, both running and altering this code. If architected properly, the blockchain could become more than a ‘computer’ capable solely of computing alterations to a list of name and number pairs, but could actually become a fully general computer — admittedly with severe trade-offs that may or may not be worth it, to whit see point number three below. Secondly, in thinking why this peculiar computational design might be effective, we ought to think of where scarcity exists or ought to exist, where there would otherwise be friction or even impossibility in its transfer, and whether that scarcity can be reflected adequately in a definable data structure. In any such case, the convention is to call the balances that mediate the adjustments to the data structures, ‘tokens’. If you hold tokens, you have the exclusive ability to submit an adjustment to the data structure of some prescribed amount.

Thirdly, and where I think many vague ideas around the economic utility of blockchain fall down, there needs to be some compelling reason why a trusted third party cannot possibly provide this service; not ‘cannot provide it all that well’, but ‘cannot provide it at all, even in theory’. This slips into the mildly technical, but nonetheless is important to fully appreciate this conceptual primitive: by the standard of any ‘normal’ computing, blockchains are obscenely redundant. They are often called ‘inefficient’, although I dispute that this is a valid criticism in general, rather than in specific circumstances in which a blockchain is pointlessly being employed even though a normal, centralised computer could just as easily be used. For reasons we needn’t explore here, the redundancy is a feature, not a bug. It provides the security that replaces trust in a guarantor of the integrity of the ledger with trust in the incentives of the system, and in the cryptography that frames the incentive structure. This is the essence of the third point: there really has to be some reason why the desired computation cannot be run centrally.

A blockchain, then, is an abstract computer that takes valid adjustments to the owners’ data structures as input and gives back the updated data structure as output. This adjustment is one ‘computation’, but the majority of the computational expense is highly redundant, yet incentivised in such a way to provide security by ensuring precisely that all and only valid transactions are accepted.

It is obviously possible to do all of this without balances mediating transfers; by simply not having such a data type within the structure. However, it is not clear to me how specifically the incentives could be made to work without it. Remember that the only reason people lend their physical computing power is in the hope of a default adjustment to the data structure being made in their favour. If this is not topping up a balance, then what is it? I am not aware of any real-world examples, nor could I think of one that would make sense. But that doesn’t mean somebody couldn’t discover one any day now! Gavin Wood seems to have had ideas for some time now, so perhaps Polkdaot is worth keeping an eye on?

Less the security via redundancy, many software companies clearly fulfil a similar role in that they offer customers instances of an abstract computer and charge for it. Take Salesforce, for example. Although we see fancy GUIs and layers of security and payment, and find it difficult not to be distracted by the flashiness of the corporation, its employees, its equity, and so on, what is really happening at its core is that the customer submits her data, Salesforce runs its proprietary computer on it, and the customer receives the output. As Salesforce is trusted, there is no redundancy to provide security, although Salesforce will accept much smaller expenses to ensure security and remain trusted. Since the computation is still expensive to produce and valuable to consume, Salesforce charges the customer, and hence we have not just a computer but a company.

Investing in such a company is, in a sense, betting on the value of this proprietary computer. But since the company has cash expenses to run the computer and cash revenues charging for access, it can exist as a regular corporation with equity, debt, and derivative instruments we can invest in. In holding a token, you have a right to some quantum of the throughput of the computer (loosely defined). This explains why the instrument may be both valuable and yet have no cash flows linked to it. In some sense, this process is actually cleaner than a company built around an abstract computer: rather than the customer paying for the right to access the computer at a price determined by the company that owns it, the customer simply buys the computations with a native currency: the token: the balance mediating transfers of made scarce data on a new kind of computer.

Free and Open Source Software Projects and Communities

photo by Leo Furiolo, via Unsplash

Thinking of (specifically) software companies as abstract computers provides a natural segue. We can marginally extend the scope of the discussion by thinking of any ‘computer’ as additionally being a software project in that the computer doesn’t just exist, floating in the ether: it was built by actual people (Ethereum has really ruined that expression, by the way) These people had goals and incentives given they likely worked for a company and possibly had a stake in the company’s equity. This is one common model for organising a software project and, ultimately, building an abstract computer. But blockchains do not follow this model. By necessity of their design they are free and open source projects, built by communities whose goals and incentives differ dramatically to that of a company’s workforce and must be given careful consideration to fully appreciate what blockchains really are.

What are these differences? Here I am heavily indebted to The Cathedral and the Bazaar by Eric Raymond for a social and anthropological account, Hackers by Stephen Levy for a historical account (25th anniversary edition specifically), and Free Software: Free Society by Richard Stallman, for a political and philosophical account. The gist is that the production of open source software is best described anthropologically as a ‘gift culture’ rather than an ‘exchange culture’. Most commercial activity in Western society operates as an exchange culture, in which, “allocation of scarce goods is done in a decentralised way through trade and voluntary cooperation.” And, “in an exchange economy, social status is primarily determined by having control of things (not necessarily material things) to use or trade.” On the other hand, “gift cultures are adaptations not to scarcity but to abundance … Abundance makes exchange relationships an almost pointless game. In gift cultures, social status is determined not by what you control but by what you give away … For examined this way, it is quite clear that the society of open-source hackers is in fact a gift culture. Within it, there is no serious shortage of the ‘survival necessities’ — disk space, network bandwidth, computing power. Software is freely shared. This abundance creates a situation in which the only available measure of competitive success is reputation among one’s peers.

That said, I don’t want to spend any more time theorising, as I believe that it is interesting but for our purposes is moot. Observing the world of software, even proprietary corporate software, demonstrates that open source has clearly won. We need not agree with any particular theory as to why it is effective as a method of software development, but we must agree that it is simply is effective.

Let us take Facebook as an example. In some respects, Facebook is the antithesis of free and open source code: the application software is very much proprietary as far as the users, advertisers, and API utilisers are concerned, and moreover is a closely guarded secret. The corporation built around this proprietary software is one of the most valuable and innately profitable in history. But how much is really proprietary? Facebook’s codebase is primarily built on what is called a ‘LAMP’ stack, meaning the service uses a Linux kernel in an Apache web server environment, reading from and writing to a MySQL database, to run applications written in the programming language PHP. Linux, the operating system kernel, is probably the most famous open source project out there. Apache too is open source, and powers an estimated 35% of the web’s top one million sites, as are MySQL and PHP, whose general usage is more difficult to measure as they have purposes beyond facilitating websites. Now Facebook admittedly doesn’t use any of these ‘straight out of the box’ and has actually done some highly praised work optimising each for their own, obviously specific, needs and releasing back to the community. Interested readers should look up Thrift, Cassandra, React, and Hive, which all originated within Facebook to solve unique technical problems, but which were later open-sourced.

I am by no means picking on Facebook here (I pick on Facebook here, instead) None of this is secret or embarrassing, and almost any large proprietary software company will be in a similar position. Nor am I downplaying the engineering marvel that Facebook constitutes. I am just claiming that the incredible amount Facebook has achieved could not even begin to be imagined without a free and open source backbone. This is arguably the essential feature of the software engineering labour market; engineers will specialise in a few programming languages and have some familiarity, but not necessarily expertise, with a variety of open source tools. The effect is that any software company whatsoever, from a one-person start-up to a Facebook-like mega cap can set out to efficiently build something proprietary on top of a free and open source foundation, since, i) there is no legal impediment to doing so, and, ii) there is a large pool of labour with the skillset to immediately begin working with this capital. That this is so frictionless, and that the proprietary software is potentially so valuable to the corporation developing it, is incidentally why there is arguably no need for unionisation in the software engineering profession, at least at the mid to high end (please note I mean this as an economic observation, not a political statement. I am not a professional software engineer, have no opinions on the matter, and am not trying to trigger anybody here) Since the capital created is (almost) literally the direct product of the employees’ minds, the employees have far more individual bargaining power to extract beneficial terms. Hence, none of the traditional benefits of unionisation have much sway: the positions are well paid to begin with, the corporate culture is such that equity rewards are expected in addition, all work expands the employee’s skillset in an entirely generalizable way such that they become more valuable to all potential employers, and so on and so forth.

As a brief aside, for a fascinating take on how this all developed, see this Tom Wolfe profile of Robert Noyce, founder of Fairchild and Intel and nicknamed ‘The Mayor of Silicon Valley’. Being Wolfe, it is exceptionally witty and engaging, and well worth the read even if you have no particular interest in Noyce.

I will return to software momentarily, but in case this argument seems alien to any readers, I will point out that software lends itself to this argument most naturally, but by no means exclusively. Examples of exactly this kind of fundamentally new economic behaviour include: remixes in art and music, crowdfunding in finance, WordPress, Blogger, and Medium in social publishing, arXiv in academic publishing, The Gutenberg Project in archiving, SETI in computing infrastructure, the mesh networking that enables Wi-Fi in radio engineering, Internet nodes in electrical engineering, but most readily of all: Wikipedia in reference and information services. I won’t belabour why or how Wikipedia ‘works’ as an organisation; I chose Wikipedia because I assume everybody knows. But I will briefly stress that this is not some bizarre and inexplicable exception to established microeconomic norms: it is open source writing as opposed to something as technically esoteric as software engineering. There are admittedly limited examples where this kind of social organisation is feasible, but where it is, it produces outcomes far superior to any other known method. But as I pretentiously explore here, the Internet is forcing this model, inch by inch, on practically everything. Anyway …

Free and open source is without a doubt the most effective way to create many kinds of software, from the point of view of social organisation. Arguably the main exceptions rely on some corporation wanting and being able to keep the software proprietary throughout its development, rather than this leading to higher quality code; corporate customers need somebody to sue if it fails, for example; or the product itself has network effects that can be profitably taxed in order to fund ongoing development at a quality commensurate with free and open source, while the network effects prevent a viable free or open source competitor; or the software is only for internal use and its working necessarily betrays sensitive business information, etc. What is notable to almost probably every single instance of such an exception is that the solution will likely be built on top of an open source backbone anyway. And why wouldn’t it? Nobody wants to reinvent the wheel, especially when there are free and infinitely reproducible wheels lying around all over the place. It might even transpire that open source software hardly needs to be modified at all for some business application, but it is still desirable to have a corporate counterpart with technical expertise that doesn’t exist within the customer’s workforce. Red Hat was founded on exactly this basis and was a very successful business until being acquired recently by IBM.

Red Hat is a good analogy for another reason too, which involves considering what kind of software Linux is: it is a platform. It does nothing on its own: it is infrastructure for others to build applications on top of. This creates a kind of unusual network effect in a very roundabout way because a huge network of people is creating the platform, meaning it is better as a platform for the equally huge network of people to build applications on top of it. The better the applications, the more validation for the platform. It could also be described as helpfully ‘antifragile’ in the sense that the exploitation of weaknesses improves it: if an engineer finds some flaw or gap in the platform that means some desired application won’t work, the incredible utility of the rest of the platform encourages the engineer to just provide the fix on their own, which in turns benefits everybody.

This overall thesis is a good starting point as to why AWS might very reasonably be considered the best business of all time. Not only is it growing at 46% p.a. on $27bn of highly profitable revenue, and not only is this conceivably unbounded because the ‘addressable market’ is determined entirely by what people think to do with this infrastructure (and no, ‘corporate IT spend’ does not cover it. Netflix, Spotify, Airbnb, Snap, Salesforce, Adobe, Workday, and countless more are all operationally infeasible without cloud computing. Many more have not been invented yet) but it is largely antifragile in the same way as Linux. It is so profoundly useful as infrastructure that customers who want an additional feature just ask for it and will very likely get it. It is not worth their while to build it on their own when AWS will do it for them, and it is worth AWS’s while because it will conceivably be useful for all customers, real and potential, and further deepen the moat. Blockchains have this same property, if they become sufficiently widely used. If some flaw or new feature is desired, the users can either ask for it or just build it themselves, as the blockchain is by definition also a free and open source project. If it is useful, safe, and true to the community’s notion of the blockchain’s purpose, then the network will likely accept the change as they will be useful for everybody.

There are obviously differences between AWS and blockchains. I will pick up on some in the next section, but a nice way to tie many of the claims in this section together is that unlike Linux which has no owners, and unlike AWS, owned by Amazon and ultimately by its shareholders, in a blockchain, we combine ideal elements of both. Anybody can access, run, and even hack, the software, but the outputs of the software can now be owned. There are various caveats required here to the effect that, no, what you really have is the right to participate in the network, not the network itself. But as with many points in drawing analogies between blockchain and regular software, this is true in fact if defined loosely enough, and in spirit regardless. The cliché at this point is to say something like: imagine if you could have had a security linked to instances of the Linux kernel, or data packets sent via HTTP, or public-private key pairs generated by SSL (now TSL) — and imagine in addition, how this economic incentive could have accelerated even better and faster development of these projects!

I must admit to having a far more conservative take. Even aside from my extreme scepticism that these analogies make any economic sense, I think a far better interpretation is to return to my digression into the intricacies of the high end of the software engineering labour market several paragraphs up. Equity grants are already commonplace here. The idea can arguably be generalised beyond specifically corporate grants to employees by observing that there is an ever-present latent threat that employees will simply leave to start their own business around whatever idea they have had and get 100% of the equity. We see this all the time with software founder-CEOs having been trade-educated and made a living at a more established corporation before striking out with their brilliant idea. I think this is a better starting point than: imagine if X had a security linked to it! What we ought to appreciate is rather that the friction of corporate mediation of value between labour and capital has been removed. For software projects that lend themselves to blockchains (an extremely important caveat that many forget, or fail to understand to begin with) capital can be staked and traded with no minimum value, and hence can serve as a motivating factor to labour that is similar to existing norms of corporate culture. While this idea is obviously not new given my deliberate choices of presentation to make this point clear, there is still reason for excitement in that the ‘market’ for doing so, if we want to call it that, is potentially greatly expanded by removing this legal friction. This friction alone arguably isn’t necessarily severe, but the consequences of removing it is that this particular space can now access the social/anthropological benefits of free and open source communities.

Decentralised Corporations

photo by rihaij, via Pixabay

Linux fits the combination of the first two categories. It was, and still is to some extent, the archetypal open source project and community, and it is a blueprint to an operating system kernel, which was a ‘new way’ of directing physical machinery to input, manipulate, and output data. And yet, nobody invested in this. There was no financial instrument indexed to the number of Linux kernels installed, nor is it clear how such a thing could have existed, except as an extremely ill-advised bet. Lots of people made huge amounts of money by using it, as mentioned for Facebook and Red Hat, but nobody made money by in any way owning it itself.

The starting point in prying out the difference is something I sneakily slipped into the above paragraph. Did you notice? I said Linux is a ‘blueprint for a computer’, and later that ‘Linux kernels are installed’. This mildly technical language means something like, anybody can find the Linux code and run it on their own hardware, thereby spinning up their own computer running as per a Linux distribution of their choosing, for free. Linux isn’t so much a computer as an idea for a computer, infinitely reproducible by law, and free and open by design. Salesforce is valuable precisely because it is the only one running its own computer. Its computer is (presumably, to some degree) protected by patent and trade secret law, and besides is not directly observable by the customer. She knows only the interface to turn her input data into output data, not how any of this is happening.

Blockchains are not like this. Although they are necessarily free and open source, there is only one version of each. The sense in which it is a ‘computer’ rather than just ‘code’ relies on this. It is huge numbers of different people running the same code at the same time, having their inputs mediated by this code, that powers the computations on the data in the first place. This might make more sense of why I stressed above, perhaps awkwardly, that a blockchain is a purely abstract computer and that considering it as having any discrete physical counterpart is highly confused. Given this demarcation, I think it makes sense to think of a blockchain as itself being a corporation.

This might seem like it requires yet more abstraction about what a corporation really is, but I think the claim is a straightforward one. First of all, clearly, I do not mean this legally. Blockchains are obviously not ‘incorporated’. However, they very obviously are associations of individuals with articulated purposes and charters, interpretable as discrete units which perform real and observable actions by the combined input of the members. That seems like a decent definition of a ‘corporation’ to me. If anything, it seems to make sense to observe that various legal systems started with this social idea and gave it a legal representation, primarily to reduce commercial friction.

The connection is closer than we might think at first: blockchains have governance structures for altering their code (charter) which could potentially depend on voting systems derived from the number of tokens held, or share of computing power contributed. Equally they could depend on something else entirely, but this option is intriguing in its obvious analogy to equity. In whichever sense we adopt, they can even be reasonably thought of as having ‘owners’. This again has further interesting legal implications which I won’t go into here (actually I can’t anyway because I’m not nearly educated enough — please comment or tweet at me to correct this) but to return to the sense in which they are also ‘computers’, this situation is clearly very different to any previous free or open source project. Nobody owns Linux. Software projects (‘computers’) that are owned are by definition not free and struggle to be meaningfully open-source. It isn’t clear to me what this would even mean: perhaps that community members can freely access and hack the code, but only to re-submit it to the ‘owner’ under legal penalty of using it in any other way? This sounds an awful lot like being an employee, and it doesn’t seem like considering the software to be a ‘corporation’ is in any way helpful. But it makes perfect sense to think of blockchains as corporations of single computers, moreover ones that are decentralised to a degree never previously possible given the best way to think of them is as having no physical counterpart.

For a slightly tangential discussion of ‘owning software’ see the short essay, Why Software Should Not Have Owners, by Richard Stallman, initiator of the GNU project, in the collection, Free Software: Free Society, already cited. The ‘Economics’ final section of this essay presciently anticipates the variety of ways software companies came to interact with open source from the late 90s onwards. Stallman also makes the brilliant move of eschewing traditional concepts of law and economics that are flatly out of place in this context, instead analysing incentive structures from first principles. This approach is highly recommended for thinking about blockchain also.

As mentioned in the previous section, AWS can also be thought of as an ‘abstract computer’, and in fact one with platform and network related qualities that seem quite similar to that of a blockchain. However, clearly, AWS is a centralised corporation, and not a decentralised one. This might seem cute and philosophical, but it has practical implications: AWS is designed to be profitable. It therefore cannot be free or open source, although it can mimic many desirable (arguably social) properties of free and open source projects, as discussed. Blockchains can only be free and open source (real ones, I mean. Public ones. None of this ‘enterprise blockchain’ nonsense) I don’t want to push the analogy too far, but this means something like: they are as if AWS were a cooperative. They are ‘owned’ by their community, and hence are run not for profit, but for the appreciation of the equity value of the communally owned, decentralised corporation.

Conclusion

None of this is to detract from more technical explanations, to whose expositors I owe a great deal. I mentioned most of my sources for brushing up on free and open source, but I should add Yochai Benkler’s truly brilliant, The Wealth of Networks, specifically for the paragraph stepping outside of software, but more generally because the book is utterly authoritative on what Benkler calls ‘social production’ — a mode of economic activity that is spreading due to the Internet. I would suggest the book is required reading for understanding the economics of open source at the very least, but also any creative activity that is natively online — blockchain is obviously both.

I should also give a tip of the hat to Chris Dixon and Fred Wilson, whose commentary over the years led me to formulate my (really barely original) understanding as outlined in the first section on a new kind of computer. Sorry I can’t provide specific links as I honestly don’t even remember. They have both written and spoken so much that DuckDuckGo (not Google) is your friend here. I entirely welcome tweets or comments here — as much for other readers as to jog my own memory.

Not to beat a dead horse, but to really pry apart this conceptual primitive, you have to just build one. Some of the (possibly nonsensical) insights I developed late in the day of getting this post down on paper came from firing through this Udemy course (same link as above). To borrow a truly noble sentiment from Naval Ravikant, “If you can’t code, write books and blogs, record videos and podcasts”. I would go further; you can code. Trust me. Just do it. I first did it badly when I was 22 and then slightly less badly when I was 27. You can also write books and blogs and make videos and records podcasts. Be the change you want to see in the world! Make this timeline the best one! Do or do not, there is no try!

Okay that’s enough.

Finally, for the section on decentralised corporations, I will tip my hat to

Vitalik Buterin’s now (in)famous essay Bootstrapping A Decentralised Autonomous Organisation for the inspiration for part 3, as well as to Olaf Carlson-Wee’s appearance on Patrick O’Shaughnessy’s podcast, The Investor’s Field Guide, who expanded on this idea in fascinating detail. I’m sure others have contributed to this line of thought too, and I’m sure they helped me and I forgot. Apologies, and again please comment or tweet with good sources.

All these thanks and attributions point to an obvious, possibly self-defeating, conclusion. There is far more to grasp on blockchain than a few conceptual primitives. But you can’t start everything with set theory (if only you could), and so were we to want some, I suggest the following: the best way to understand blockchains is as definitively novel combinations of three more basic concepts: a new kind of computer, a free and open source software project and community, and a decentralised corporation.

Additional thanks to the many wonderful people who helped me edit this particular post: Nic Carter, Arianna Simpson, Larry Sukernik, Angie Dalton, and Yassine Elmandjra in particular, but many more who know who they are.

follow me on Twitter @allenf32


Follow us on Twitter, InvestFeed, Facebook, Instagram, LinkedIn, and join our Discord and Telegram.

Read about our upcoming Altcoin Magazine Mastermind Event here.