Part III

All Hail the Bees! - cross-pollination, mechanisms, and metamorphoses for a wild growth of DAC economy

Decentralization is hard. Otherwise we would have long been living in a decentralized economy already, considering all the benefits it begets[3] (trustless consensus, permissionless network, censorship resistance – socioeconomically these characteristics indicate a secure, fair and just system). From previous discussion (in Part I and Part II) we get the hint that, to sustain a decentralized system, you need: (a) space (scale-up); (b) complexity (through entropy defying non-trivial liveness[18]). Also, space is not merely size but dimensionality and being able to scale up to more dimensions is the basis for achieving non-trivial complexity, which is the goal of DAC economy. Space and complexity – these are the foundations (“whys”) of DAC economy.

In this part of the discussion (Part III), we are going to explore the ways (“hows”) of DAC economy – which we call mechanisms. Since these are very early days of decentralized economy, we are not here to talk about the nitty-gritties of algorithms on the ground, but design principles and rationales behind the scenes – sort of like another layer of whys behind the hows.

In the traditional world, you have natural stages for things to happen and people to interact with – villages, towns, cities, control rooms, datacenters. There the sense of a system takes the form of centralized rules – such as traditions, doctrines, laws, commands, kill-switches – to regulate or govern what people can do (or must-do), which is the essence of centralized power. In a decentralized blockchain system, the sense of rules are quite different though. Decentralized rules do not regulate or dictate what people can do, but rather incentivize people to do their (decentralized rules’) bidding. There are no overarching rules hanging above everything in a decentralized system. Once the system is started you can’t even shut it down, like what you can do in a centralized datacenter. In a decentralized system, the only entity that matters is the networked peer (node) and those peers or nodes have complete freedom to act as their own agents. The traditional sense of rules – regulation and dictation – don’t quite apply in a decentralized blockchain system. You have to design what is called mechanism to lure network nodes to do any bidding or to punish them to not do bad things. Mechanisms are not coercive – their outcomes are probabilistic in nature and their design very tricky.

Traditional economics tried to gauge the behavior of people in a society or economy by using game-theoretic analysis. The results are post factum, but are used to devise policies

_________________________________________________19_________________________________________________

anyways. We pointed out in Part II[10] of our discussion that there is often a disconnect between micro level economics and macro level policies. Most often game-theoretic analysis can yield interesting revelation in simple case studies at the micro level but many of its idealistic assumptions made it unfit to apply the reasoning process directly to large scale behaviors – much like what we encountered in the physical world – such as using heat engines directly to explain the phenomenon of life. The reason is because there are just too many factors in human behaviors at many levels that simpler analytic models just choked. Nevertheless, in decentralized blockchain systems, micro-level mechanism design has a direct causal link to macro level behaviors[11] (on the blockchain mechanism is policy) – making it a good experiment lab in testing mechanism designs from game-theoretic methods.

That being said, mechanism design in decentralized blockchain system is still not a trivial task to accomplish. Game-theoretic analysis in traditional economics usually seeks weak explanatory result so it assumes rational behavior of players in a system. On the contrary, a decentralized network system must assume Byzantine (random) behaviors of network peers⁴⁸ (nodes). Thus there exists a dilemma – how do you design a secure mechanism for a Byzantine blockchain network using rational economic mechanism design premises, e.g., assuming that rational participants in the blockchain network won’t deviate far from adversarial strategic equilibriums (such as Nash equilibrium⁴⁹)? Of course, in the blockchain community there exist always Vitalik’s⁵⁰ blockchain trilemma⁵¹. Blockchain mechanism design is far from a solved problem.

It’s been over a decade since Bitcoin and a slew of other blockchain systems have been deployed into the wild. Despite a plethora of successful attacks, the public largely accepted that blockchains held the line and became a viable financial asset class. Yet developers know better. Only a few projects afforded to design rigorous blockchain systems of value that can withstand the test of attacks and market acceptance. Many lesser curated blockchain projects unfortunately (or intentionally) just slipped into dustbins of pump and dump schemes. This situation is not unlike what happened in early days of software development – better software engineering methodology and tools are needed to tackle design problems – e.g., OOP52 – so quality can become manageable even for smaller developer teams, teams with focus on business not cryptography or algorithmic game theory. Metis project bid DAC economy not merely a prospect but also a methodology with tools to tackle the blockchain mechanism design challenges.

We shall encounter strange and exciting specimen in our DAC garden (“economy”). As DAC gardeners (“developers”) our task is to curate and nurture even crazier specimens – we can borrow a page from software engineering to tame mechanism design – composing meta patterns through cross-pollination, metamorphoses, and let loose the bees.

_______________________________

⁴⁸ Byzantine Consensus with Unknown Participants.

⁴⁹ Nash equilibrium.

⁵⁰ Vitalk Buterin, Ethereum co-founder.

⁵¹ See Solving the blockchain trilemma, and Blockchain trilemma solved?

⁵² Object-oriented programming.

_________________________________________________20_________________________________________________