Two Kinds of Decentralisation
In the crypto-asset ecosystem, decentralisation is perceived as both a virtue and a primary reason that many of these assets are considered valuable. When considering decentralisation, however, the discussion is typically limited to a single means of achieving the desired goal of distributed control among several actors. In what follows, two different kinds of decentralisation will be highlighted, with each of their respective trade-offs discussed. A brief discussion of the solidity programming language as a convention will also be provided.
Decentralisation
Before highlighting how a crypto-asset, or set of assets, can be decentralised via two distinct mechanisms it will prove useful to first clarify what is meant by the term “decentralisation” in this context.¹ Gencer et al. succinctly describe decentralisation as ‘a property regarding the fragmentation of control over the protocol’ (2018, p. 1). In line with this, Walch highlights how a desired feature of a blockchain is that there ‘is not a single central party keeping the record, that means that no single party has responsibility for it, and thus no single party is accountable for it’ (2019, p. 6). Decentralisation, therefore, and as opposed to centralisation, identifies the degree of distribution of control over an asset; the more decentralised something is, the less influence any given individual has over it.
Notice how this definition places decentralisation and centralisation on a spectrum, rather than being a sharp dichotomy (Walch, 2019, p. 14). Some blockchains can reasonably be considered more decentralised than others, even if they are both appropriately described as decentralised. Consider, for instance, two blockchains, A and B. Suppose that A has 1,000 nodes that collectively define and enforce the protocol rules, while B has 10,000; both can reasonably be described as decentralised, although B is also more decentralised than A.
Additionally, it is important to recognise the function that decentralisation fulfils for a crypto-asset. Crypto-asset are ‘decentralised to survive attempts at censorship, manipulation, or shutdown’ (Qureshi, 2020). Decentralisation is a means to an end, not the end itself. If a crypto-asset could achieve these properties without being decentralised, that would almost certainly be preferable due to the costs and inefficiencies incurred with decentralisation. Not only is it notoriously difficult to coordinate large groups in order to achieve the provision of a collective good (Olson, 1965, p. 48), but the technical constraints necessarily imposed in order to achieve decentralisation limit the utility of the underlying network. As an example, excluding secondary and tertiary scaling layers, the Bitcoin network can only facilitate seven transactions per second (Pritzker, 2019, p. 92). A centralised database that stores a token with a fixed supply of 21 million coins could facilitate orders of magnitude more transactions per second than this. Of course, this database would not be trust-less or censorship resistant at all.
There exists, therefore, a design trade-off between decentralisation and utility for crypto-assets. If a crypto-asset is designed such that decentralisation is maximised, the utility of the protocol is undermined (e.g. transaction throughput and/or the possibility of upgrading). Conversely, if utility is maximised, the degree of decentralisation is often undermined and, as a result, the protocol will not have the properties of trustlessness and censorship resistance that motivated its construction to begin with.² Designers, therefore, are motivated to achieve a “minimum viable level of decentralisation” in order to attain the desirable properties that decentralisation confers without unnecessarily limiting the utility of the protocol (Backus, 2018).³ As Backus articulates when recounting the history of peer-to-peer file transfer services like Napster and BitTorrent, ‘beyond staying alive, decentralisation is a weakness not a strength’ (Backus, 2018).
Interestingly, as Walch highlights, this dynamic also creates an incentive for key stakeholders to overstate the degree of decentralisation that their protocol has, thereby creating a “veil of decentralisation” (Walch, 2019, p. 29). The reason being that ‘if one believes that no particular people are doing things of consequence, and power is diffuse, then there is effectively no human agency within the system to hold accountable for anything. If you can’t see people doing things that are “a key determining factor in the enterprise,” then how could you hold anyone accountable for illegal actions taken or facilitated by the system, or for failures of the system?’ (Walch, 2019, pp. 28–9). When taken together, designers and users of a crypto-asset are motivated to achieve a minimum viable level of decentralisation, while simultaneously overstating the degree of decentralisation that has been attained in order to shield key stakeholders from any form of intervention or regulatory oversight. One could argue that this is precisely what is being observed in the crypto-asset ecosystem presently.
Multiple Realisability
Up until this juncture the discussion of decentralisation has been limited to each crypto-asset as being an isolated structure (e.g. how decentralised is Bitcoin when compared with Ethereum?). Such a framework is certainly valuable and coherent, however, it obscures another mode of decentralisation that crypto-assets can employ, this being platform, or codebase, decentralisation. In order to see this it is important to recognise the innovation that was introduced with the Ethereum network.
Breifly, Ethereum was the first ‘blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats and state transition functions’ (Buterin, 2014, p. 13). This Turing complete codebase is described as the Ethereum Virtual Machine (EVM), and it allows developers to build novel structures and applications on top of the Ethereum network (Dhillon et al., 2021, p. 37; Kim et al., 2021; Zetzsche et al., 2020). Ideologically, the purpose of the Ethereum network, and more specifically the EVM, is to fulfil the function of a decentralised “world computer,” which is open, deterministic, and permissionless (Dhillon et al., 2021, p. 48).
As already mentioned, decentralisation is very inefficient and even though several technical design decisions have been implemented in order to increase decentralisation of the Ethereum network (e.g. an account-based model, 15 second block times, etc.), the maximum throughput of the network in its current instantiation, which is approximately 15 transactions per second (Schäffer et al., 2019, p. 103), has clearly been reached. This is evidenced by soaring transaction costs; at the time of writing the average transaction fee to send an ERC20 token⁴ is approximately $100 AUD. Not only does this severely undermine the utility of the Ethereum network due to the fact that low-value transactions are uneconomical (because the cost to transact exceeds the value transacted), but it also effectively excludes individuals with limited funds from participating. To further highlight this, Wang et al. write, ‘sending one-megabyte application data to Ethereum costs 17.5 Ether or more than $25,000 USD (at the exchange rate as of Jan. 2021), which is much more expensive than alternative centralized solutions (e.g. cloud services) and has scared away customers’ (2021, p. 566). In fairness, the Ethereum core developers seem to be aware of this limitation, and progress is being made to transition the Ethereum network to a sharded proof of stake blockchain in order to increase transaction throughput (Dhillon et al., 2021, p. 61).
Concurrently, however, several rival platform blockchains have been built using the same EVM architecture and programming language (Solidity) present in Ethereum while often compromising decentralisation in order to increase transaction throughput in various ways. Perhaps the best example of this is the Binance Smart Chain, which is an explicitly centralised and corporate blockchain. Binance, the international crypto-currency exchange, built this protocol and integrated it into their website in order to easily on-board users into their blockchain environment. Importantly, the ‘Binance Smart Chain relies on a system of 21 validators with Proof of Staked Authority (PoSA) consensus that can support short block time and lower fees’ (Binance, 2021). A full treatment of this hybrid consensus mechanism will not be provided presently, except to say that the limited number of validators for the Binance Smart Chain have been explicitly selected by Binance, the company.
Unlike with Bitcoin or Ethereum, where any individual can contribute to the decentralisation of the network by running their own node, only those validators selected by Binance are able to secure the network. As Joshi writes, a ‘[Proof of Authority] consensus model relinquishes some degree of decentralization because of its mechanism to reach a consensus using validatory nodes, thus we can conclude [Proof of Authority] sacrifices decentralization in order to achieve high throughput and scalability’ (2021, p. 4). The Binance Smart Chain, therefore, is far more centralised than either Bitcoin or Ethereum, meaning that transactions occurring on this blockchain are liable to censorship by the consortium of authorised validators (Joshi, 2021, p. 4). It might be argued that the Binance Smart Chain has nonetheless reached the minimum level of decentralisation needed in order to attain the desirable properties listed above. Moreover, even if this is not the case, Binance, the company, has a clear incentive to refrain from censorship because doing so would highlight the lack of decentralisation to users, thereby encouraging them to migrate their funds to alternative blockchains. It seems likely, however, that if a significant level of political and/or economic pressure is placed on Binance, censorship and perhaps even seizure of funds will occur.
All of this is beside the point, however, the key aspect of the Binance Smart Chain worth emphasising, and one of the primary reasons for its success, is that it integrated a version of the EVM into its blockchain (Binance, 2021). This is significant because it means that any smart contracts, distributed applications, or assets that exist on Ethereum are easily transferable to, or copied on, the Binance Smart Chain. Furthermore, third-party applications like wallets and blockchain explorers are seamlessly modifiable in order to be used on the Binance Smart Chain (Binance, 2021).
Ammori summarises this nicely when he writes that ‘the permissionless nature of Ethereum-based applications — with the ability to freely and seamlessly “fork” (or copy and adapt) codebases — collapses barriers to entry for entrepreneurs down to zero. End consumers are the primary beneficiaries of this innovative environment: Because all applications share the same database (the Ethereum blockchain), moving capital between platforms is trivial. This forces projects to ruthlessly compete on fees and user experience’ (Ammori, 2021). The only aspect of this that Ammori misses, however, is that it is not the Ethereum blockchain, per se, that is the shared standard which facilitates the ruthless capitalistic competition that benefits users so much as it is the EVM standard that exists across multiple blockchains.
To see this, notice that the Binance Smart Chain is not the only EVM compatible blockchain that has gained prominence in light of the cost-prohibitive fees present on Ethereum. Other examples include Avalanche, Polygon, Tron, Fantom, xDai, Near, and Harmony One. Put simply, the EVM is multiply realisable. Arguably, and without dwelling on the minutia attendant with any given blockchain, all of these alternative base-layer platforms sacrifice decentralisation in some way in order to increase transaction throughput and decrease transaction fees for users. Moreover, several applications that originated on Ethereum, such as SushiSwap and Curve, have expanded, or are in the process of expanding, their operations to several other EVM compatible blockchains listed above. As Ammori highlighted above, this ultimately benefits the users of these applications who can now use these services without incurring the high transaction costs associated with the Ethereum blockchain.
Notice how this represents a different kind of decentralisation; rather than the base-layer blockchain being decentralised, as is the case with Bitcoin, the programming language and virtual machine on which applications and services function is decentralised across several rival blockchains. Each individual blockchain, like the Binance Smart Chain, may or may not achieve a minimum level of decentralisation needed to resist third-party intervention. The EVM ecosystem as a whole, however, can be thought to achieve a kind of decentralisation as the number of rival blockchains that share the same virtual machine increases. No one set of centralised developers control the entirety of the EVM ecosystem. In the event that one instantiation of the EVM ecosystem is shut down, for whatever reason, developers and users can simply migrate to another instance of the EVM and continue operations. Certainly, such an event would be devastating for the users involved due to the fact that it would likely result in the permanent loss of funds, however, the EVM environment as a whole would survive.⁵ Henceforth, this form of decentralisation will be referred to as “virtual machine decentralisation,” in contrast to the kind of “blockchain decentralisation” achieved by the distributed network of Bitcoin nodes.
Solidity as a Convention
Before highlighting the various trade-offs associated with each form of decentralisation, it is worth recognising the incentives that exist for developers given the relative dominance of the EVM standard. To see this, notice how the solidity programming language can be thought of as a convention, in the game theoretic sense, when contrasted against alternative programming languages. A rigorous definition of a convention will not be provided presently, although the interested reader can consult a prior article that examines this form of collective behaviour in greater detail.
To help see why the solidity programming language is a convention, consider a lone developer, Scott, who wishes to build an application on the Ethereum network. Scott, when beginning the project, is immediately faced with the choice of which programming language to use. Solidity is not the only programming language that the EVM can interpret; alternatives include Vyper and Flint, among several others (Hirai, 2021). Scott, however, has strong rational incentive to use solidity over these alternatives, even if these alternatives are “better” in some sense, due to the fact that solidity is the dominant standard used to develop applications on Ethereum. Not only does almost everyone use solidity to develop applications on Ethereum, but it is also expected that new applications will be built using solidity (Arias, 2019, p. 1). It is both common knowledge and widely anticipated that applications built on Ethereum will be constructed using the solidity programming language. In the event that Scott reaches out to other developers for assistance or an independent audit, those developers will anticipate that Scott’s application is written in solidity, and will likely be surprised if they discover that this isn’t the case. Every developer building applications on Ethereum is in a similar situation to Scott, and as a result, every developer has a rational incentive to conform to the convention of using the solidity programming language if they wish to develop applications for the EVM.
Notice how there is nothing special about solidity, in fact many critics suggest that, all things considered, solidity is a poorly considered programming language with several counter-intuitive features that make building applications more difficult than might otherwise be the case (Amiet, 2021). The Nash equilibrium for using the solidity programming language exists, not because solidity is the best or only programming language, but because almost everyone uses it, almost everyone expects everyone else to use it, and as a result, these actions and expectations create a rational incentive for almost everyone to continue to use it. As Lewis highlights, a convention is a situation where ‘each [person] wants to conform conditionally upon the conformity [of] others, conforming action produces expectation of conforming action and expectation of conforming action produces conforming action’ (Lewis, 1969, p. 42). Thus, in much the same way that verbal languages (e.g. English, Spanish, Mandarin, etc.) are conventions, so too are programming languages, and in particular, adopting the solidity programming language can be thought of as a convention when building applications for the EVM.
The EVM standard, however, does not appear to be a convention in the same way that the solidity programming language used to develop on it is. There are two reasons for this. Firstly, there are several significant platform blockchains that do not adopt the EVM standard (e.g. Solana and Stacks), which violates the first condition for a convention to exist (universal, or near universal, conformity). Secondly, those building EVM compatible blockchains do not appear to expect others to do likewise, which violates the second condition.
Despite this, there is a strong incentive for blockchain designers to adopt the EVM standard, although not due to the conditional expectations of others, which is what is required for a convention to exist. In order to recognise this incentive, notice the immediate advantages that blockchain designers open themselves up to if they adopt the EVM standard for their blockchain. Rather than creating an entirely new standard which developers must first learn to master, by adopting the EVM standard pre-existing applications can easily be copied to the new blockchain, and developers can easily be coaxed over to build on the new environment with monetary incentives.
Not only does this further entrench the EVM standard, but it further contributes to the decentralisation of the EVM ecosystem. This is not to suggest that rival Turing complete blockchains will not exist, or even that they will not succeed. Once more, blockchains like Solana and Stacks do not adopt the EVM standard and both are gaining rapid adoption by users. Both blockchains, however, face a persistent dis-advantage due to the lack of easy interoperability of assets and code structures. Any solidity developer who is familiar with the EVM standard will struggle to build on a non-EVM alternative, which poses a barrier to entry for them, and one which ultimately undermines the long-term success of the non-EVM blockchains.
Blockchain Vs. Virtual Machine Decentralisation: Trade-Offs and Incentives
Returning to the two ways in which decentralisation can be achieved, and in light of the fact that decentralisation is useful only insofar as it confers the properties of trustlessness and permissionlessness, the trade-offs associated with each method can now be evaluated. Particular focus will be paid to how well suited each form of decentralisation is at achieving these desired goals, along with the incentives and efficiency trade-offs attendant with both.
Beginning, briefly, with blockchain decentralisation like that achieved with Bitcoin. As was mentioned above, blockchain decentralisation is achieved when no single entity, or small consortium of entities, has control over the network and protocol rules of a blockchain. The benefits of blockchain decentralisation are, as already mentioned, that the protocol can achieve a high degree of censorship resistance, permissionlessness, and trustlessness. In contrast, and as also highlighted above, the limitations of blockchain decentralisation are that the network is highly inefficient, has very low transaction throughput when compared with centralised counterparts, and is notoriously difficult to upgrade. There is almost no incentive to change or successively iterate on a well-functioning decentralised blockchain like Bitcoin.
Conversely, virtual machine decentralisation presents a different set of design trade-offs. Because a decentralised platform and coding standard like the EVM and solidity programming language is multiply realisable, each instantiation can be thought to be in competition with the set of alternative instantiations. The reason for this is that each instantiation is trying to distinguish itself from its counterparts in order to attract users, developers, and monetary capital. Each instantiation, therefore, is incentivised to innovate in novel ways and to develop beneficial features that rival instantiations have not yet offered, or are not able to offer. This is precisely what is being observed presently. As an example, both Avalanche and Harmony One have deployed a kind of sharding technology (in essence creating multiple concurrent sub-blockchains that are interoperable) which is also planned for an upcoming Ethereum upgrade. This has allowed both rival EVM blockchains to boast far higher transaction throughputs than Ethereum, and as a result, users have a strong incentive to use these alternatives in order to incur lower transaction fees. Ethereum developers, in turn, have a strong motivation to innovate and implement the sharded upgrade that has been in development for years. Additionally, second-layer scaling solutions such as Arbitrum and Optimism, which are, in a sense, also centralised EVM platforms, have arisen and have been adopted by users.⁶
There are only two reasons why a user would be motivated to incur the high transaction fees on one EVM chain, such as Ethereum, while avoiding cheaper alternatives. Firstly, an asset or service may only exist on one blockchain, meaning that if a user wants to use the service in question their only option is to incur the high fees associated with the blockchain on which it exists. Such a scenario is unlikely to persist for long, however, due to the ease at which code can be copied and deployed on rival EVM chains. Secondly, a user may have concerns regarding the degree of decentralisation that an alternative EVM blockchain has achieved. As a result, this individual may be willing to pay the higher transaction fees in order to have the assurances of permissionlessness, trustlessness, and censorship resistance associated with the more decentralised instantiation of the EVM. This appears to be a more robust reason why transaction fees can be expected to remain high on some EVM chains despite the fact that there are cheaper alternatives available. Even in this scenario, however, there remains an incentive to use the cheaper EVM blockchains to avoid high fees if several transactions are going to occur, but to keep one’s assets on the more expensive and decentralised EVM chain. Thus, all of this competition and innovation not only drives down the fees to transact across the virtual machine landscape, but it also instils an incentive for constant improvement and development, all of which ultimately benefits users.
There are, however, several drawbacks that can be associated with virtual machine decentralisation. Firstly, each instantiation of the virtual machine is incentivised to be as centralised as possible in order to maximise transaction throughput and upgradability. This may lead some instantiations to become so centralised that they can be shut down entirely by financially repressive regimes, or sabotaged by malicious actors. This incentive across the EVM landscape undermines the core properties gained by decentralisation.
Secondly, while the assets that exist on one instantiation of the virtual machine are interoperable and usable on another, because they have been designed with the shared standard, they must first be bridged, and in some cases “wrapped,” before this can occur. This creates a barrier to interoperability and transposability between each instantiation of the platform. Moreover, it may introduce trust assumptions when using these services, thereby undermining one of the key reasons to strive for decentralisation in the first place. Caldarelli, for instance, writes that ‘similar to how oracles reintroduce trust, and [a] single point of failure, the issuance of wrapped tokens involves third parties whose characteristics need to be considered when evaluating the advantages of “crossing-chains”’ (2021, p. 1).
Thirdly, the existence of multiple rival blockchains, and single applications that span these blockchains, can result in liquidity fragmentation for assets across the various networks (Anonymous, 2021). In particular, one asset might be highly liquid on one blockchain, but be relatively illiquid on another. This is not an insurmountable concern, especially if it is relatively easy to bridge between the various blockchains, but it does represent one form of inefficiency for the entire decentralised virtual machine ecosystem.
Fourthly and finally, the strong motivation to iterate and change may lead to counter-productive design changes to the protocol rules of the blockchains. As an example, the recent decision by the Ethereum developers to make ether, the base-layer asset of Ethereum, more scarce appears to be a very poorly considered long-term decision (Chalopin and Trehan, 2021). To see this, recall that Ethereum is in a competition with rival EVM blockchains for the lowest fees possible. As a result it does not appear wise to make the base-layer asset more valuable by making it scarcer. It seems uncontroversial that increasing the cost of transacting on Ethereum will only undermine the utility of the network, and will motivate users to abandon the blockchain for cheaper EVM alternatives, like those listed above.⁷ Thus, this appears to be an instance where a counter-productive design decision has been made that will ultimately undermine the long-term success of one EVM instantiation relative to its peers. Keep in mind, however, that this is just one example, and it may ultimately become clear that this design decision represented, all things considered, a beneficial change to the protocol rules of Ethereum. The larger point still remains, however, which is that the motivation to constantly innovate will result in some design decisions that will not be beneficial to users, and may even undermine the desired properties of decentralisation.
The design and incentive trade-offs for each form of decentralisation are summarised in the table below.
Concluding Remarks
It seems clear, therefore, that blockchain decentralisation achieves the desired properties of censorship resistance, permissionlessness, and trustlessness to a higher degree than virtual machine decentralisation. This should not be taken to mean that blockchain decentralisation is more desirable in all circumstances when compared with virtual machine decentralisation; each method provides different trade-offs and each are better equipped to achieve different goals. In order to construct a non-sovereign money that can resist nation state intervention, blockchain decentralisation is clearly the preferable design choice. Instances of the decentralised virtual machine are liable to censorship by repressive nation states, and the ability to innovate is not desirable if the goal is a trustless form of digital money. If, however, a computing layer facilitating a new set of financial services is desired, then virtual machine decentralisation is the preferable choice in that instance. The ruthless capitalistic competition and high degree of innovation attendant with virtual machine decentralisation are well suited for this end. Moreover, the ability for governments to intervene could also be viewed positively, because it allows for regulations and oversight to exist in this burgeoning environment. Thus, because each form of decentralisation has a different set of design and incentive trade-offs associated with it, each form of decentralisation is better able to achieve different goals.
[1]: As several authors highlight, this term is used in a variety of ways (Schneider, 2019, p. 2; Walch, 2019, p. 12).
[2]: This tension between the utility, robustness, and trustlessness of a blockchain has elsewhere been described as the “blockchain trilemma” (Im, 2018).
[3]: This notion has also been referred to as “semi-decentralisation” (Chen et al., 2021, p. 1305).
[4]: This is a common token format for EVM compatible blockchains (Somin et al., 2020, p. 1).
[5]: This approach to censorship resistance resembles the tactic employed by The Pirate Bay. Very briefly, The Pirate Bay is peer-to-peer file sharing site that uses many different website domain addresses to remain in operation. While any given domain may be shut down, each is simply replaced with another that achieves the same purpose, thereby ensuring that the website and service remains in operation (Anonymous, 2016).
[6]: Some proponents of Ethereum envision a future where this kind of multiple realisability of different EVM platforms described above occurs at the secondary and tertiary scaling layers of Ethereum. This notion has been referred to as a modular blockchain system (Hoffman, 2021). Certainly, this seems possible, although it does not undermine the argument being presented here. The issue is simply where the multiple realisability and competition between EVM instantiations occurs, not whether it is, and will continue to, occur.
[7]: It may be retorted that there is an important distinction to be drawn between the value of the asset and the cost to transact on the network. Certainly, it is possible that the cost to transact can decrease despite the value of the base-layer asset increasing. However, given that the cost to transact is denominated in the base-layer asset, because this is what must be paid to miners/validators in order to have one’s transaction included in an upcoming block, ceteras paribus, as the base-layer asset increases in value, so too does the cost to transact.
References:
Amiet, N., 2021. Blockchain Vulnerabilities in Practice. Digital Threats: Research and Practice 2, 1–7.
Ammori, M., 2021. Decentralized Finance: What It Is, Why It Matters [WWW Document]. Future. URL https://future.a16z.com/cryptos-fourth-wave-defi-poised-for-breakthrough/ (accessed 10.22.21).
Anonymous, 2021. Multi-chain Ethereum Expansion: Compatible with EVM and become the standard configuration of high-performance public chain • Blockcast.cc- News on Blockchain, DLT, Cryptocurrency. Blockcast.cc- News on Blockchain, DLT, Cryptocurrency. URL https://blockcast.cc/news/multi-chain-ethereum-expansion-compatible-with-evm-and-become-the-standard-configuration-of-high-performance-public-chain/ (accessed 10.25.21).
Anonymous, 2016. The Pirate Bay lost all its old Hydra heads, here are the new ones. TechWorm. URL https://www.techworm.net/2016/01/pirate-bay-lost-old-hydra-heads-new-ones.html (accessed 10.25.21).
Arias, E.J.G., 2019. Towards Principled Compilation of Ethereum Smart Contracts (SoK), in: 2019 10th IFIP International Conference on New Technologies, Mobility and Security (NTMS). IEEE, pp. 1–5.
Backus, J., 2018. Resistant protocols: How decentralization evolves [WWW Document]. Medium. URL https://medium.com/@jbackus/resistant-protocols-how-decentralization-evolves-2f9538832ada (accessed 10.15.21).
Binance, 2021. Binance Chain Docs [WWW Document]. URL https://docs.binance.org/ (accessed 10.21.21).
Buterin, V., 2014. A next-generation smart contract and decentralized application platform. white paper 3.
Caldarelli, G., 2021. Wrapping trust for interoperability. A study of wrapped tokens. arXiv preprint arXiv:2109.06847.
Chalopin, J., Trehan, R., 2021. Ethereum’s Deflationary Changes and ETH Price Prediction [WWW Document]. Deltec Bank & Trust. URL https://www.deltecbank.com/2021/08/25/ethereums-deflationary-changes-and-eth-price-prediction/?locale=en (accessed 10.25.21).
Chen, Y., Pereira, I., Patel, P.C., 2021. Decentralized governance of digital platforms. Journal of Management 47, 1305–1337.
Dhillon, V. (Research fellow), Metcalf, D., Hooper, M. (CEO of M.T., 2021. Blockchain enabled applications : understand the blockchain ecosystem and how to make it work for you, 2nd ed. ed, Springer English/International eBooks 2021 — Full Set. Apress.
Gencer, A.E., Basu, S., Eyal, I., Van Renesse, R., Sirer, E.G., 2018. Decentralization in bitcoin and ethereum networks, in: International Conference on Financial Cryptography and Data Security. Springer, pp. 439–457.
Hirai, Y., 2021. Awesome Ethereum Virtual Machine.
Hoffman, D., 2021. Ultra Scalable Ethereum [WWW Document]. URL https://newsletter.banklesshq.com/p/ultra-scalable-ethereum (accessed 11.2.21).
Im, D.K.D., 2018. The blockchain trilemma.
Joshi, S., 2021. Feasibility of Proof of Authority as a Consensus Protocol Model. arXiv preprint arXiv:2109.02480.
Kim, H., Kim, M.-S., Kwon, H.-J., 2021. Capability and Limitations of De-Fi (Decentralized Finance). The Journal of Society for e-Business Studies 26, 143–155.
Lewis, D., 1969. Convention: A Philosophical Study. Harvard University Press, Cambridge, Massachusetts.
Nash, J.F., 1950a. Equilibrium points in n-person games. Proceedings of the national academy of sciences 36, 48–49.
Nash, J.F., 1950b. The bargaining problem. Econometrica: Journal of the Econometric Society 155–162.
Olson, M., 1965. The Logic of Collective Action. Harvard University Press, Cambridge, Massachusetts.
Pritzker, Y., 2019. Inventing Bitcoin. Amazon Digital Services LLC — KDP Print US.
Qureshi, H., 2020. Why Decentralization Isn’t as Important as You Think [WWW Document]. haseeb qureshi. URL https://haseebq.com/why-decentralization-isnt-as-important-as-you-think/ (accessed 5.27.21).
Schäffer, M., Di Angelo, M., Salzer, G., 2019. Performance and scalability of private Ethereum blockchains, in: International Conference on Business Process Management. Springer, pp. 103–118.
Schneider, N., 2019. Decentralization: an incomplete ambition. Journal of cultural economy 12, 265–285.
Somin, S., Gordon, G., Pentland, A., Shmueli, E., Altshuler, Y., 2020. Erc20 transactions over ethereum blockchain: Network analysis and predictions. arXiv preprint arXiv:2004.08201.
Walch, A., 2019. Deconstructing’Decentralization’: Exploring the Core Claim of Crypto Systems. Crypto Assets: Legal and Monetary Perspectives (OUP, Forthcoming).
Wang, Y., Zhang, Q., Li, K., Tang, Y., Chen, J., Luo, X., Chen, T., 2021. iBatch: saving Ethereum fees via secure and cost-effective batching of smart-contract invocations, in: Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. pp. 566–577.
Zetzsche, D.A., Arner, D.W., Buckley, R.P., 2020. Decentralized finance. Journal of Financial Regulation 6, 172–203.
