EOS Governance:
Approaching Immutable dApp Architecture
The EOSIO technology and the EOS network have been massively successful so far despite limited time spent in production. We have outpaced many competitors in throughput, daily active users, and rate of growth. We have rapidly improved and iterated since launch. This should be celebrated.
The following proposal is meant to be a thought-starter. We believe that a recalibration event should occur regarding where we focus our efforts as they pertain to EOS governance. This software provides ample opportunity to disrupt and displace legacy systems by repositioning the value-creator as the focal point. To this purpose, we believe the community should reposition the developer, the value creator, back to the center of the conversation within EOS.
The Position
Good EOS governance means an efficient decision-making framework that reduces the need for trust between parties and accelerates growth.
The following is a quote from a member of the EOS telegram community.
…We are debating with [dApp] about dropping or maybe delaying our EOS roadmap — and we’ve been very pro EOS since day 1 but it feels lonely as a dapp Developer in EOS to be honest — all we talk about is BPs, constitutions, RAM, etc. [While] we’re here busting our butts bringing EOS to the masses — alone
The discussion surrounding governance so far has left out the developers.
Let’s pivot.
The Current State
Ethereum smart contracts are immutable by default. Despite this, developers have gone to great lengths to find ways to circumvent their immutable status. The reason for this should be obvious, software development is not a static thing, it is ongoing. In contrast, EOSIO embraces the needs for a degree of mutability and this is ok. The EOSIO software is being updated on weekly basis so remaining stagnant as a developer is simply not an option. But this mutable state, especially for sensitive contracts such as the ones that govern dApp tokens, cannot remain this way indefinitely. Mutability and immutable need to be seen as a spectrum that exists within the development cycle. Throughout this cycle, the developer should seek to increase security and decrease the need for trust by either achieving total immutability or asymptotically approaching it.
A Solution
The way we accomplish this is by taking advantage of the extremely robust permissions system on EOS. Here is the description of “Permissions” written by Block.One in their developer portal.
The below examples are authorities for a fictional account named @multisig. In this scenario, two users are authoritized to both the owner and active permissions of a fictional @multisig account, with three users permissioned to a custom publish permission with varying weight.
In this scenario, a weight threshold of 2 is required to make changes to the owner permission level, which means that because all parties have a weight of 1, all users are required to sign the transaction for it to be fully authorized.
To send a transaction which requires the active authority, the threshold is set to 1. This implies that only 1 signature is required authorize a action from the active authority of the account.
There’s also a third custom named permission called publish. For the sake of this example, the publish permission is used to publish posts to the @multisig’s blog using a theoretical blog dApp. The publish permission has a threshold of 2, @bob and @stacy both have a weight of 2, and a public key has a weight of 1. This implies that both @bob and @stacy can publish without an additional signature, whereas the public key requires an additional signature in order for a action under the public permission to be authorized.
Thus the above permissions table implies that @bob and @stacy, as owners of the account, have elevated priviledges similar to a moderator or editor. While this primitive example has limitations particularly with scalability and is not necessarily a good design, it does adequately demonstrate the flexible nature of the EOSIO permissions system.
Also, notice in the above table, permissions are set using both an account name and a key. At first glance this may seem trivial, however it does suggest some added dimensions of flexibility.
Observations
@bob and @stacy can be explicitly identified as the owners of this account
The public key cannot push a action under publish authority without an additional signature from @bob or @stacy
@bob and @stacy can push a action under publish authority without any additional signatures.
By properly utilizing this permissions system, a developer can share the authority to update his or her smart contract code with one or more parties, removing a point of central failure and decreasing the need for users to trust a single developer or team of developers.
Michael Fletcher, a lead developer at EOS42 and the Chintai Team token leasing platform, comments on the permissions structure of Chintai, which requires 6 of 11 Block Producer sponsors to sign a multi-sig transaction to make any update to the code whatsoever. It cannot be updated otherwise.
Block Producers<>dApp Developers
Block Producers can update various parts of the EOS blockchain when 15/21, or ⅔ +1 Block Producers, each sign a transaction to access the active permission of the eosio.prods account. Once 15/21 have signed, eosio.prods can authorize actions that normal accounts cannot. Within the eosio.prods account there exist three important permissions that are vital to this proposal.
- active,
- prods.major
- prods.minor
Each permission within eosio.prods: active, prods.major, and prods.minor requires 15, 11, and 8 Block Producers to access, respectively. This can also be viewed as ⅔ +1, ½ +1, and ⅓ + 1.
What we have is a very elegant stepped system that, when leveraged, can be used to decentralize the authority to update sensitive smart contracts of decentralized applications with Block Producers, who are trusted and accountable entities within the EOS ecosystem. Basically, by utilizing the available features of EOSIO we can create a structure of governance that reduces the need for trust and increases the security of dApps that build on EOS. This relationship of distributed authority is not limited to just eosio.prods permissions but can also be between any developer and third party. This is a competitively differentiating feature for EOS.
What Could This Look Like?
There are many certification standards across many industries today. For example, SSL certificates certify who you are, SOC and PCI compliance each certify the security of your processes, and ISO certifies quality standards across industries. Most of these are then broken up into tiers depending on the rigor of the certification performed. While the unbridled flexibility that EOS offers its developers is great, the average user does not possess the necessary tools to evaluate the security, safety, nor developer identity for any dApp with which they interact.
Just like levels or types of certification, there could be a standard certification indicating at least the degree of immutability for dApps. Depending on the threshold of difficulty that must be met in order to change a smart-contract code a different physical badge could be issued. It can be displayed through the wallet or dApp explorer which the user utilizes to access these dApps, or directly on the UI of the dApp itself.
The Tasks Ahead
During the week 10 December 2018 a security vulnerability was responsibly disclosed and a patch was developed, released, and deployed on the EOS mainnet by all Block Producers. This patch, while undoubtedly necessary, caused problems for many dApp developers and their smart contracts. What if these dApps were sharing permissions to update their code with Block Producers? We are presented with a series of logistics challenges.
- How would dApps have been notified and Block Producers been notified by dApps?
- How would dApps submit the update information to Block Producers for them to verify?
- Is there a fee involved?
- Is there a portal for communication or some other process?
- Should a service level agreement exist between Block Producers and dApps that share permission structures?
These are the important questions, the answers to which represent what the foundations of what EOS governance should have looked like from the beginning.
Conclusion
The service-level relationship between Block Producers and dApp developers is pivotal to the foundational governance framework of the EOS Mainnet Blockchain. Moving toward immutable architecture for sensitive smart contracts helps create a framework for growth by increasing security and decreasing the need for trust between parties. dApp developers should be thinking about how to approach immutability of their sensitive smart contracts, especially those that govern their token and by doing so they can differentiate themselves from their less secure competitors. Block Producers should begin to devise a process by which they can adequately support developers with this approach. Constructing this framework is the responsibility of the entire EOS community. Developing the workflows, processes, and rules of engagement surrounding how we move forward are pivotal. EOS New York is not prescribing exactly how this process should take shape. We are, however, calling on the community to recognize the importance of this initiative and to refocus our energy away from the distractions that have sucked the air out of the room. Let’s place the developer back into the center of the conversation. How we as a community address this will directly impact the growth and governance of the EOS mainnet and EOSIO.
Join the conversation: https://t.me/immutablearchitecture
Thank you to EOS Cafe Block and eosDAC for being a part of the development of these ideas.
