Addressing EOS Token Smart Contracts and a Proposal for Core Development Funding on EOS
Further Decentralizing Tokenized Assets Through eosio.token, & Establishing A Commons Development Program Funded by Voluntary Blockchain Economic Activity
Abstract:
An EOS-based decentralized application (dApp) may be operating on a blockchain but may also have centralized owner permission control over the token smart contract. A single key pair owner permission governing a token smart contract introduces security risks and attack vectors against the dApp the token contract supports. In order to reduce this threat, we propose that dApps have the ability to deploy their token through eosio.token, the system contract that issued the EOS token, and that can only be affected by 15/21 token-holder elected Block Producers. With efforts in education and additional UI elements, users can understand the difference between premium dApp tokens and dApp tokens that they must trust. Furthermore, similar to EOS short-names, a bidding system should be created within eosio.token to access this premium feature which can be marketed back to a dApp’s users. The tokens contributed to eosio.token for this access can be allocated toward EOS core development projects, similar to EOS42’s EOS Voter Bounties, through the eosio.forum referendum system and confirmed by 15/21 token-holder elected Block Producers.
This is a two-part primer on what we consider two very important issues; (1) the decentralization of tokenized assets created and issued on EOS, and (2) the need to establish a pool of resources meant for the open-source development of solutions that improve core EOS function (and ensuring these funds originate from voluntary activity, not inflation). We hope that this will spark conversation about this important expectation of governance and where we should move as a community.
Part 1: Breaking Down Decentralization in a dApp
A purpose of decentralization is to eliminate single points of control or failure within a system and to distribute control of the system across its participants.
Decentralization is an extremely difficult thing to quantify. What is decentralized enough? A very interesting take on how to begin to measure decentralization was done by By Balaji S. Srinivasan and Leland Lee. In their proposal, dubbed the minimum Nakamoto coefficient, they break down a system (blockchain) into subsystems and utilize Lorenz curves and Gini coefficients to plot actors or points of control within such subsystem in order to identify what percentage of actors or points would need to be compromised to control at least N% of that subsystem.
In a system as complicated as EOS, there are many subsystems to analyze if we are to try to attempt to quantify the decentralization of EOS overall (Block Producers, token distribution, Smart Contracts, Validating Nodes, Exchanges, System Contracts, Codebase, etc.).
With regard to dApps, EOS New York previously published the idea that asymptotic immutability, or the persistent effort to decentralize as much as possible over time without ever achieving total immutability (so applications can be easily updated and improved over time), is a beneficial direction for EOS to take. So, to what degree should an application on EOS be decentralized? Of course, existing on a blockchain is a tremendously helpful start. But at how many other points does a dApp rely on a central point or actor for its continued functioning? Is there a single API service it relies on? Is the front-end hosted on a centralized service? Even more basic and important, what are the permissions of the smart contracts that comprise the dApp? The answer lies somewhere in “exactly to the degree to which the developer and the users mutually accept”. But, discussion surrounding to what degree a system is decentralized, and the understanding of what can be appropriately decentralized within each subsystem, is not being discussed as much we would like within the EOSIO space. We’d like to focus on a particular aspect of the smart-contract subsystem, the token smart contract’s permission structure.
One Private Key
Of the top ten tokens by market cap on EOS at the time of this writing (per www.bloks.io) all but two tokens have a single owner key. We should not assume maliciousness on behalf of the most popular dApps on EOS, a single owner key for the token smart contract means that, in theory, the developer could unilaterally apply fees to transfers of their token, install a redirect for all future transfers of the token to an account of their choice, freeze transfers altogether, or issue new tokens to a party of their choosing.
In the case that a user has not assumed possession of the token in their own RAM pool, the token can be recalled entirely. In our opinion, it is not necessary that changes of this nature should be possible, save past the initial token distribution.
This is a perfect space for services to enter and establish themselves as trusted entities that can abstract away access to these critical functions away from any single party. But, while the community waits patiently for this new market to emerge, there lies an elegant solution available to us right now.
The eosio.token System Contract
eosio.token is the system contract that created the EOS token. At the time of the EOS blockchain launch, it issued EOS tokens to eosio, the account which then created every account on the EOS blockchain, and transferred the correct EOS token balance to each newly created account per the snapshot created at the end of the Block.One token generation event. The eosio.token contract is maintained by the eosio@active permission, which can be adjusted by 15/21 token-holder elected Block Producers.
Prior to launch, one idea among the launch participants was that future dApp tokens would be created and issued under eosio.token, which is capable of doing this. But this would require that 15/21 token-holder elected Block Producers would be responsible for creating and issuing any new tokens. Fearing a bottleneck, this idea was dismissed. At the time, this may have been the correct decision. But the ultimate result has been the creation of tokens that are unilaterally controlled by single key pairs. While we have the chance, we can correct this behavior to mitigate security risks and further decentralize control of tokens.
We are proposing that we reopen this idea and provide a structured and scalable system that allows for dApp developers to deploy tokens under the eosio.token system contract and essentially abstract trust away from one key pair to at least 15 out of 21 Block Producers which are elected by the stake-weighted vote of token-holders. This means that a dApp token specifically would be as secure as the EOS token.
Creating and issuing a token under eosio.token is a premium and differentiating feature for dApp projects. Essentially, the claim can be made by the developer,
“… the integrity of our token is maintained at a level equal to the threshold equal to EOS token itself”.
It should also be noted that the token ticker, or the capital letters that represent a token, cannot be repeated. The token smart contract no longer needs to be managed by the developer as well. Block Producers, as part of their core function, maintain the EOS system contracts which are shared across all nodes. The eosio.token contract is one of these system contracts so a workflow for its management and upgrades are already in place. It will be managed by Block Producers in the same way that all system smart contracts are. Finally, it separates business logic smart contracts from the token contract, a security best practice.
Part 2: Establish a Commons Development Program Funded by Voluntary Economic Activity On-Chain
EOS allows for the creation of human-readable names that are 12 characters long (limited to a-z, 1–5) to serve as “accounts”. These human-readable names are much easier to type in an address field when sending tokens instead of a 50+ random character string. EOS also allows for the creation of premium short-names. To obtain the ability to create a premium short-name one must submit a bid to eosio.names and be the highest bidder on all short names for that day. For example, the short name com was purchased for the equivalent of $1,245,000 on July 6th, 2018. The owner of this account can now create any name followed by `.com`, an attractive feature. Read more about the premium name function for EOS here.
We further propose that a similar bidding system is established in front of eosio.token, which would allow for dApps to bid on these premium token names.
Allocating eosio.token Funds
Block.One continues to improve EOSIO at their leisure but it may not always be so. The EOS community will, at some point, need to begin to hedge against the very unlikely event that Block.One will not be a significant contributor to EOSIO, or, that the needs of the EOS blockchain will diverge from the direction of Block.One-maintained EOSIO development. In short, core development will be needed and without a means to fund a reliable and accountable workflow to produce these core code developments, the EOS community may find itself in a bind. Such is the Tragedy of the Commons.
Finally, we propose that the EOS tokens that are contributed to eosio.token as the winning bid for a premium token name are used for core development work for the EOS blockchain. Proposals for work will be submitted via the eosio.forum referendum system and those that receive 15/21 token-holder elected Block Producer approval, the same threshold by which we maintain the EOS blockchain, will be funded in accordance with the proposal made.
EOS42 has already done excellent work motivating expert members of the community with the EOS Voter Bounties (EVB) to develop needed solutions to various obstacles. This would merely bolster this effort already underway as well as open the market to all EOS experts, not just those representing a Block Producer candidate.
An attractive difference between this proposal is that it funds open-source development for EOS through entirely voluntary means and imposes no additional inflation on the network. In fact, the rate of open-source development that can be afforded by such a mechanism is exactly correlative with the rate of certain economic health identifiers of the blockchain itself, namely new premium token creation i.e. dApp development.
Next Steps
EOS New York is always interested in the opinions of the community and we hope that this post spurs discussion. EOS New York will begin development following positive reinforcement of this idea from within the EOS community. Want to voice your opinion? Vote on the referendum we proposed alongside this post, “Should EOS establish a voluntary, non-inflationary, commons fund for EOS core development through a bidding system built on top of eosio.token smart contract?” Also, be sure to visit the official EOS New York telegram and let us know what you think!
Thank you to eosDAC, and EOS Nation for contributing to the editing of this document.
