1:4 Good Architecture
As fascinating as the consensus layer of the distributed ledger system can be, consensus is only a small fraction of a much larger system architecture distributed ledgers need to deliver on their lofty promises.
Architecture in computer science has a surprising amount in common with architecture in the physical world.. as all buildings (or pick your complex systems metaphor: human body, ant colony, etc.) consist of networks of interconnected sub systems that must selectively interact for the larger system to survive.
In this oversimplified model, we'll say buildings engage with four primary systems:
The public infrastructure such as the sewer system and electrical grid so the building can connect with the outside world.
The load bearing foundation upon which everything in the building is stored.
The "smart" systems of the building including electrical, climate control, & security sub systems that perform some type of useful logic.
The user interface of the building which occupants interact with including the light switches, thermostats, and furniture.
In computer science, architecture works largely the same way. The “stack” (complete list of protocols and languages used to construct a software product) that developers use to build more complex services can be viewed in a similar light as a series of sub systems working in harmony to achieve more useful behavior than any single sub system can deliver individually. Think GPS + front end interface + back end logistics + information piping + information storage systems interacting together every time a user requests a rideshare.
The public infrastructure is a series of interconnected protocols called "the internet" that allows for communication between servers (individual or clusters of computers). Regardless of the server hardware chosen (Intel or AMD does not matter), database languages, operating systems, etc. along long as each server can agree on basic packet switching standards, communication between any two machines globally is possible in nanoseconds.
If we view a building as an "application" (or a unified assembly of digital code parts designed to accomplish some task) the foundation of the application consists database layers where all information created within the application is ultimately stored. Within this database layer, distributed ledgers add an additional layer of complexity with a shared integrity engine to share data between many distributed databases that traditional centralized databases do not have.
Sitting on top of the database storage layers are the intelligence layers, which in distributed ledger speak are colloquially known as "smart contracts". In chapter 1 we defined as the programmatic logic that allows users to sell Beanie Babies, replace Facebook, etc in the same manner a building uses thermostat data to regulate it’s temperate (if temperate >= too hot -> then trigger air conditioner to start). Once some piece of programmatic logic happens, (If user clicks like -> then display like to other users) a record of this event can be stored somewhere so it can be queried later.
The interface layers then sit on top of both the database and smart logic which gives lay users the ability to interact with the system without needing to program anything. Interfaces can be as simple as a command line terminal, all the way to swiping right on Tinder. End users tend to think in terms of what they can see and directly interact with, but as we now know there is a massive iceberg sitting beneath each user interface. When you flush a toilet (a user interface of sorts), your waste does not magically disappear, but is handled by a ballet of interconnected water treatment sub systems.
As we live in the future, even sanitation systems generate enormous amount of digitizable data on water quality, flow rates, quantity of chemicals used, and even new species of bacteria and other organic life present in the waste. Even if there is no convenient interface to look at and analyze this data yet, it does exist and needs to be stored securely somewhere.
Physical & Digital Architecture
These four basic levels of any complex system (be it building or application), must be able to selectively interact with each other for the system to function. In other words, we need semi-permeable membranes that can decide when to open themselves up, and when to close themselves off from the outside world.
For our building to function properly, we need to somehow separate the structure from the outside world to protect it from the ravages of entropy, yet also allow for selective access of electricity, fresh air, water, and of people into the structure.
This is why we invented keys. Not only can we have keys to the main door, but within the structure we can have keys to protect the critical sub systems that only credentialed maintenance workers have access to. A rough sketch of how a building fits inside a larger system looks something like this:
Where each system is protected from the others by a series of keys that selectively guard access to keep each individual sub system secure.
Cities represents the protocol layers that allow buildings to communicate with other buildings via plumbing, electrical lines, and roads just as applications can communicate with each other over the open internet to send mortgage applications, Pokemon loot, or denial-of-service attacks across a digital city.
Bridges between cities represent technologies like atomic swaps and other cross chain systems that allow different protocols to interact with each other. In the DLT world, an Ethereum smart contract can communicate with a Ripple or Stellar cross border payment in the same manner your centralized bank credit card can communicate with a centralized eCommerce store, even if they are both running on completely separate systems by utilizing bridging technologies.
Buildings represent the database layer where information is stored, and defines the boundaries of what exists inside the building, and what exists outside. This is the bedrock of the DLT where the actual data itself is contained in either discrete blocks, or in a hashed web of transaction data.
This contrasts with the centralized world, where data is stored in a repository where a single entity has asymmetric read/write/modify/delete access over others using the system from an information disadvantaged position. Think of a single bank vault where friction is very high to access highly concentrated value, versus a hotel where key access can be more fluidly given between users, and each room safe needs to be compromised individually rather than a single vulnerable mega safe.
Plumbing represents some kind of logic that provides functionality to the building by performing useful work. In the physical world, this useful work can be transporting gas or water throughout the building via pipes, or people via elevators. In the digital world, “plumbing” can represent any useful manipulation of 1s and 0s from legal logic to define property ownership, to pattern recognition logic that spots deepfakes too advanced for the human eye to discern.
Flushing the toilet sits at the pinnacle of architectural design as one of the few systems end users directly interact with. Flushing, like swiping an App, is the physical manifestation of all deeper layers of the system. End users of building typically do not interact with the rebar inside concrete For DLT to become truly competitive with centralized systems, interface design must be just as seamless for end users to work with as the best centralized applications of today. If flushing required root access and 50 lines of terminal bash code, it would take much longer for basic sanitation to reach a critical mass of people.
As we can see, digital architecture is quite similar to physical architecture. The same human brains that have constructed great works of physical engineering for millennia have in recent decades turned to constructing digital monuments. Balancing efficiency, economy, usability, durability, and many other key attributes for both types of systems remains an immense challenge many spend lifetimes trying to improve a minute part of. While hidden to all but a small group of experts, the architectural choices made in the depths of each sub system add up to large consequences for end users. Make the fire escapes too narrow and people will die. Forget to double check for concurrency bugs and watch as hundreds of millions of dollars vanish in a flash.
Mathematics, Inc: The Art of Buying Cities
Well run cities attract businesses, which in turn attracts talent, which drives the entire local economy. In the quest to attract the best people, cities are most concerned with creating fertile ground in which newcomers feel welcome. Both physical cities and digital cities accomplish this by tweaking regulatory knobs such as:
Tax rates: How much rent is extracted use use the roads, plumbing, etc.?
In a DLT system tax rates = network transaction fees, or the cost incurred each time a record on the application is sent to the protocol for validation and storage. Viewed more abstractly, tax rates can also be levied on applications within the protocol such as an Uber/Lyft-like ride sharing app. The “tax” paid to shareholders and employees comes out of the service fee they charge to drivers and passengers in the system. Of course, part of this tax is also paid to the lower level protocol that facilitates the IT infrastructure.
Building codes: What rules do developers need to follow when creating new structures?
The programming languages used and other pieces of the development stack such as the compilers and API queries determine the ways smart contract programs are constructed and executed on the network. The most important part of building codes is SAFETY (eg we don’t want things like poor locks on our doors to open up liability when there is a break in)
Development constraints: How much land is available to build on, and how much does extra does it cost to scale to larger developments?
Development constraints = Network bandwidth and storage needed to run applications at scale. If the bedrock the city is built on is too deep and developers choose to develop on shaky ground, the applications they create can potentially topple when what they depend on to perform lower level computations fails.
Bridges: How easy is it to travel to other cities?
Bridges = programmatic tools in the protocol layer that allow data (tokens, metedata, etc.) from other platforms to be exchanged for data on the native platform. Bridges have the very difficult job of properly translating data from one system to another. If you send your Bitcoin to the Ethereum network and receive one Bitcoin equivalent token, how do you know you can send it back?
Governance: How stable is the governance structure, and what is the process to change the rules?
Governance = The rules of consensus outlined in the previous chapter, and methods for voting in new network parameters. More importantly, good governance determines if people trust the system or not. If users think a hard fork is just around the corner and the project will be abandoned, the value of the project sinks.
When you purchase a cryptographic token representing a portion of the base level protocol, in effect you are purchasing ownership in the collective rules that govern how a digital city operates. Let's unpack this idea by trying and answer the question: Where is amazon moving its headquarters?
Properties of Good Cities
If you knew the answer to this question, you could make a considerable fortune speculating on the price of land. The same is true when buying platform level distributed ledger tokens. The "bet", in simple terms is which ecosystem is going to attract the most talent, development, and adoption.
The winning city will most likely need:
Low tax rates: The cost for performing transactions on the network is very low and does not inhibit the ability to effectively do business.
Flexible building codes: programming languages and toolsets that allow programmers to build applications of any complexity, and make development easier and more intuitive. Instead of needed to reinvent the wheel each time, APIs are available that show how to easily perform pre-written functions such as sending payments, collateralizing assets, etc.
Low development constraints: If the application is successful, the protocol needs to support massive scalability in the quantity of data stored on the protocol as well as the speed at which new information can be stored and retrieved.
Good bridges: that allow the protocol to talk to other protocols, etc.
Good governance: Trust in the people and mathematical logic maintaining order in the system with proper game theoretic incentives to keep bad actors out.
While these characteristics can create the fertile ground development, only developers creating useful applications will encourage end users to move to the platform, which in turn will spur more applications to move there.
This classic chicken and egg problem is called a "Network Effect" which was turned into simple mathematical logic in the 1950s called "Metcalfe's Law". This law states the value of any network is the square of the number of active users.
While not always exactly an exponent of 2, the basic phenomena of networks becoming exponentially more powerful with the adoption of new users is borne out in all modern networks. It makes logical sense that having 50 telephones in a small town versus 10 telephones in a small town would allow for exponentially more network interconnections between users. As we will discuss further in Part II, developers have more incentives to build on open DLT protocols over closed FAANG systems, in part due to the history of centralized platforms aggregating the majority of valued created for themselves.
The next chapter will further expand on this point by drawing a larger boundary around what is considered system architecture. Rather than view the technical development stack as separate from larger society level stack, we need to understand the motivations of each different type of user interacting within a larger cohesive system.