Each layer 1 (L1) blockchain presents an ecosystem, which is available for us to use as a substrate to build our projects. In that sense, each blockchain network (such as Ethereum or Solana) is like a programming language, which offers a bunch of features (such as functional programming primitives, or recursion). And it’s up to a developer who is building a project to decide which ecosystem to pick for their application.
This analogy to programming languages becomes more interesting when you factor in the fact that each L1 ecosystem is potentially a lot “richer” than a programming language: other than offering you features, it also comes with it’s own token or currency, and the value of the currency represents the value of the ecosystem in the eyes of its users. (It also comes with a built-in runtime environment and a shared database capturing a “state of the world” that everyone agrees upon.)
Imagine that in the year 2000, if the dominant programming languages of that time acted in this way. They would all have their own native tokens. There would be Fortran, with its coin (FORT). It was the OG coin: it had been around for a long time, but wasn’t being used all that much anymore. It’s value was way low, but there were a bunch of old-timey developers who were HODLing FORT because they were sure it was going to come back. Then there was Cobol, with its coin (BOL). The ecosystem was cumbersome to use, but BOL had a massive treasury which was largely being held by banks and other financial institutions, where Cobol was in heavy use. And then there was java, and java’s currency (JCOIN) was valued the highest, because it was the dominant ecosystem of the time, and most of the software development community expected it to perform the best in the future. To take the analogy one step further, java (and the other languages) would be offering their native currency to the developers of important projects who chose java: “Pick java for your web socket development, and get some JCOIN!” And then the web socket developers could launch their own coin in that ecosystem. And then they would offer their own coins to the people who used those projects. “Are you using our web socket software? Great! We will airdrop you some SOCKCOIN!”
Layers of network effects
These kinds of incentives create interesting confluences of network effects:
- Supercycles for investors. People keep buying JCOIN because they see developers flocking to java, and they think other people will buy JCOIN, thereby inflating the price of JCOIN even more.
- Supernetwork effects for developers. You keep using java even though it’s clear that java is a perverse, repugnant language that’s not right for your project, because JCOIN price is going up, and you’re earning more of it all the time. The competitor (python) is an elegant language, with a great syntax and rich libraries, but the price of PYCOIN is very low, it’s not clear where it’s going. So you stick to java as your ecosystem, thereby continuing to drive up the price of JCOIN.
But this also creates increased volatility for ecosystem choices:
- False greener pastures. You’re happy with your choice of python ecosystem for your project, but PYCOIN isn’t doing too well, and you don’t want to miss the rising tide of JCOIN, even though you know it’s the wrong ecosystem choice for your project.
- Market coupling. Something (non-programmatic, maybe market driven) causes the price of JCOIN to crash, and now you want to switch your entire project to another ecosystem because you want to ride the wave of some other ecosystem coin. Or maybe you still don’t want to switch ecosystems because you want to catch THIS bull run of JCOIN as it recovers.
What do we do?
We want to build a new project (say, a file server), and need to choose an ecosystem.
Approach 1: Make projects portable
Projects should be able to switch ecosystems with minimal effort. To do this, several things must be true:
- As much as possible, the ecosystem layer must be abstracted away from the core project functionality.
- There needs to be a middleware that allows a project to switch between different ecosystems.
This also prepares us for approach 2…
Approach 2: Make projects inherently multi-platform
Our file server is available on multiple platforms: you (the user) can deploy our file server on java (and earn JCOIN or our FileServerJCOIN), or you can deploy our file server on python (and earn PYCOIN or PythonFileServerCoin).
Of course, this is easier said than done. Java is an object oriented language, where every primitive is a factory, and compiles to a bytecode that runs on a jvm, whereas python is an interpreted language which need not be object oriented, support functional concepts and is not compiled at all. It will not be easy (or sometimes even possible) to make multi-platform versions of projects.
For either approach mentioned above, the project team must have developers who are familiar with multiple ecosystems, their pluses and minuses, and be able to guide transitions.