Our current approach to decentralized value creation is fatally broken. The notion that all decentralized software should run on one of the few humongous shared networks is creating misaligned incentives and poor for users and developers alike. The base economic layer of such networks is designed for value capture and inserts itself into user experience .
Questions of scalability of transaction throughput arise as the result of this faulty premise, not from architectural clarity. A whole class of crypto-billionaires is . We worry that this is what crypto has become—a game of the rich and for the rich, just another turn on the road for global consolidation of economic power. And, speaking of power, (For Ethereum this number is about 70).
We are building in an attempt to address these problems. We believe that a truly democratic decentralized ecosystem should be comprised of a large number of small decentralized networks, each running its own application, in its own unique way, making its own choices with respect to economics, consensus mechanism, governance process, level of decentralization, fundraising model, user experience, and community engagement.
ADAPT is a software SDK for developing and launching decentralized networks. It is being designed as a tool for building decentralized networks and taking them through a succession of upgrades and changes to the consensus and economic models commensurate with their size at each stage. ADAPT can be used to build single-application networks as well as shared ecosystems that run multiple applications, if the designers so choose. It can also be used to create private data servers as part of non-blockchain networks.
To counteract the broken incentives of large networks, ADAPT does not attempt to create a shared economic layer. Instead its initial stages will be funded by donation (but you will get a cool Ethereum non-fungible asset as a thank you). At the later stages it our hope that early applications that want to run on ADAPT will choose to contribute funds to its development.
This approach means we will certainly not be overfunded like other decentralized platforms out there. But does it mean we can’t compete at all? ADAPT is first and foremost a social experiment. We want to know whether decentralized software can compete on merits, or whether an overbloated ecosystem fund is all it takes to destroy all competition. Frankly, if it is the latter, I don’t think this space has any hope of becoming useful to anyone, and will forever remain a self-fulfilling game for the elite few.
The rest of this posts addresses some of ADAPT’s architectural choices and answers some questions people asked us so far.
Why a new programming language?
ADAPT’s programming language, MUFL, offers an original approach to database programming — the concept of mutable functions. This plus the of the language ensures that everything you can do in MUFL can be done with just a few simple primitives. It literally takes an hour to understand how the language works and a few days to deepen and refine your command of it.
What’s more, MUFL acts as a glue language that can operate on any natively-implemented data structure that exposes itself to the language via an API interface of less than a dozen methods. Consequently, it is very easy to extend the language, while keeping it efficient and simple.
OK, but why, you ask. To answer this question it may be necessary to demonstrate the drawbacks of existing approaches to decentralized programming. Yet, we do not want to speak badly of some really respectable efforts out there, including Ethereum’s Solidity, Hyperledger’s JavaScript, Kadena’s Pact, and many others. Solidity, for one, has introduced thousands of people to smart contract development and will always stand out as the first successful attempt at programming in this new and novel execution environment.
Yet, we would like to offer an alternative to these approaches in the form of MUFL. We want to give data mutation under security constraints a new form and shape, so as to better enable developers to experiment with the novelty that decentralized networks are. Consequently, we don’t want our language to assume that tokens are first-class objects. Rather, the design of MUFL proposes a programming model that can implement both tokens and many other decentralization primitives, and let’s the developer choose their form, functionality, and features.
Decentralization technology is just beginning to discover the power and breadth of this design space. Transferrable scarce digital assets are just a tip of the iceberg in terms of what these systems can do. Ledgers with detailed history, accounting networks, reputation systems, and curation markets are novel and unique idioms of decentralized programming, no less important than tokens. We believe that programming data mutations under constraints should be naturally generic, while allowing to implement these structures without friction. For that you have to remove the assumption that smart contract programming is necessarily about economics, value, or asset transfer. This is what MUFL is trying to be — a generic language for programming under security constraints.
Our advisors correctly point out that bringing a new programming language to life is a long and arduous process. Go took 5 years to build out the tools and libraries it needed to truly enter the mainstream. Java in the 90s took even longer. Why do we feel that our approach warrants such an effort?
New use cases warrant new approaches, and it usually takes time to find the approach that works. Java came to market when browser programming became a thing. Similarly, Go became the tool for highly networked cloud applications. Solidity pioneered decentralized programming, but it was the first such attempt, and so lacks generality. With MUFL we are looking to build on that experience, while introducing a general programming model in a decentralized context. To us, this warrants a new language and all the difficulty that comes with this choice.
What about network security?
This is the second most frequent question we hear. It mostly comes from people who believe that proof-of-work consensus is the only secure consensus model, and correctly point out that its security increases with network size and economic value. To these people it sounds strange that anyone would propose a model where each dApp uses its own network.
Yet, this thinking is an absolute fallacy, akin to saying that telephony over radio waves can never work because the radio bandwidth is not sufficient to carry all the phone calls. It simply outright disregards advancement and experimentation, rather focusing on past accomplishments as the only viable way to do things. This is the thinking space exploration employed until SpaceX, promoting fear of trying anything new and wasting billions of dollars on using outdated technology.
Yes, despite proof-of-work being a cutting-edge advance five years ago, it is entirely clear that it will be outdated very soon. Delegated proof-of-stake models are perfectly able to sustain network security independent of size. Additionally, smaller applications require less security by definition. Some may do quite well by running BFT consensus between a group of hand-picked validators. Other ideas for consensus algorithms are emerging as well.
We aim to reduce economic and ideological interdependence between decentralized applications. To us, this is going to lead to a net increase in reliability, even accounting for some additional security concerns. Security is not just a matter of how well protected or final your transactions are. Equally important is usability and clarity of user experience. Even though there is little statistics, I am sure that to date users lost more cryptocurrency due to human error than to hacks, and we have heard of almost no compromises of the consensus layer despite its .
By allowing dApps to design their economic process from the very bottom of the stack, we enable unprecedented experimentation with security models, hoping that the right model will emerge not from a small group endowed with vast resources, but from a large group of people who don’t need much resources in the first place. By reducing the expense of building unique decentralized networks, we bring blockchain to your garage, similar to what component-based radio did in the 30s and PC did in the 80s.
Conclusion
Decentralized thinking opens up infinite possibilities for social and economic innovation. Today, however, such innovation lies at the mercy of the ecosystem creator, a brave individual, who is not afraid to undertake a huge effort with an equally large risk of failure. Solid technological thinking is but half of the work. The rest is marketing, community development, investment activity, management, and so on. In other words, bringing a blockchain ecosystem to life is an activity with a very high barrier to entry.
Those who build decentralized applications are faced with the choice of the network to use. There aren’t many to choose from, and they all have pluses and minuses. Some minuses are across-the-board universal. I am talking about the fact that any ecosystem founder would necessarily be thinking about the way they are going to capture value from their efforts. Platform monetization is fine, because significant efforts deserve significant rewards. But, unfortunately, it not only captures value, but also diverts significant attention and effort, and diminishes user experience.
Most importantly, as clever as they are, the founders of a large ecosystem simply cannot predict the kinds of problems their network will need to solve in the future. By the time those problems become apparent, the ecosystem is already large, and cannot be easily upgraded to provide a solution. Every decentralized network today is a kind of a trap: you can join it, but down the road when new problems arise, you cannot expect the network to solve them fast enough. These systems are oversized, which makes them anti-agile, and, consequently, fragile. You end up committed to an environment which is destined to deteriorate quicker than you can transition out of it.
ADAPT allows you to launch your own network for your own purpose. The agility of such a network is predicated on your choices, not on choices made by someone else. Decentralized systems will always suffer from the agility problem — this is the natural outcome of their . But by making applications independent from each other, we at least remove impediments to agility that are unnecessary.
We welcome your feedback and support. ADAPT will be an underfunded project for the entire first stage of development, so contributions of any form are welcome. For updates, follow @adaptkit on twitter and periodically check .
was originally published in on Medium, where people are continuing the conversation by highlighting and responding to this story.