The impact of recent EOS proposals on the long term utility
Article credited to Dexaran and provided by EOS GO
I'd like to provide my insights on the recent EOS updates:
-
Blockchain Governance Proposal by Dan Larimer.
-
RAM mechanics.
However, before I describe the value of the above proposals, I want readers to understand what we should keep in mind when evaluating EOS and the direction of where things are going.
The reason for EOS to exist
EOSIO was originally designed to be a DApp development platform. I recommend reading this article for better understanding of what DApp is supposed to be, where it came from and what benefits it should have.
I would like to provide a quote from the definition of Software development:
Software can be developed for a variety of purposes, the three most common being to meet specific needs of a specific client/business (the case with custom software), to meet a perceived need of some set of potential users (the case with commercial and open source software), or for personal use (e.g. a scientist may write software to automate a mundane task.
This also applies to Decentralized Applications.
Decentralized applications appeared and became popular in the crypto industry, because they have a number of advantages compared to existing approaches for developing client-server applications. Obviously, there is no need for a platform that does not have any advantages over alternatives, so the utilization of DApp development platforms (such as EOS) depends on how much advantages the development of DApps on this platform has over alternative software development approaches.
We should keep in mind that not every application that is deployed on EOS is a DApp. It is also described at this article of EarnBet and their 30 days notice:
All decentralised apps have had a string of outages over the past month, and for the less fortunate ones, zero transactions on their platform during this period. DApps that have not had outages are not dApps at all, but rather, centralized applications masquerading as “d”Apps with a Scatter login.
Decentralized application must work fully on chain without any interference of off-chain services and servers. Otherwise this off-chain services and servers become the fault point of this application system and negate any advantages of decentralization thus turning the EOS application into a traditional centralized client-server application masquerading as “d”App.
It should be noted that the main goal of EOSIO is to run the developed applications and ensure 100% uptime as well as public accessibility. Thus the main utility of EOS is its ability to serve as a distribution platform for the developed decentralized applications.
Advantages of Decentralized Applications and the potential utility of EOS
To get to know the development process and the capabilities of EOS smart contracts, I previously developed a prototype of the game and launched a contract on EOS mainnet. I have already highlighted a number of issues that I experienced during the development process. You can read the article about this here.
1. Decentralized Applications are censorship-resistant.
If you run your application on a dedicated server then some party can violate the operability of the application by shutting down the server. However this is not the case for EOS smart-contracts since the contract can not be accessed by anyone who does not have a private key that has a permission to modify the code of the contract. This would be an advantage of EOS but it turns out that most of kinds of decentralized application can not run on EOS without a help of off-chain servers. In this case the advantage of "censorship-resistence" is negated by the fact that the off-chain helper server becomes a fault point of this system once again.
Censorship resistance of smart-contracts can be an advantage of EOS as a development platform but only the simplest applications are truly censorship-resistant and capable of working solely with the help of EOS platform without any third party interference.
Real example of censorship and centralized fault point: Scatter nodes and half of EOS Block Producer API nodes are blocked in Russia. I do not know if this is the Russian government, my Internet provider or the developer of the hardware used by my Internet provider responsible for blocking the nodes. The fact is that the nodes are blocked and a mere user can not access DApps without setting up VPN or changing the background node of Scatter. Fortunately EOS has relatively large number of API nodes and not all of them are blocked yet. However the same method of censoring can be applied to violate the operability of any DApp that uses a centralized server so EOS can not solve a problem of censorship resistence for any DApp that requires an off-chain server to run.
2. EOS as a distribution platform.
Distribution of the developed software is another important point to consider. After the application is developed it must be delivered to the end users (it it is not a "personal use application").
In traditional client-server application system the developer must worry about maintaining an online server and making sure that the server is operating properly. This creates additional overhead for the developer of the application if the server must hold some critical data or operate with funds. The developer of the application must take all the security measures into account to make sure that server provider can not steal the funds or manipulate the operability of the application for his personal goals.
EOS can significantly improve the application development process by serving as a publicly available distribution platform with guaranteed 100% uptime. EOS could eliminate the need of trust between the developer of the application and server providers as EOS can act as an agnostic distribution ledger.
All this advantages are also negated by the fact that most application still rely on a centralized server to run on EOS.
3. Built-in monetization.
This is the brightest unarguable advantage of EOS as a development platform nowadays.
Blockchain and cryptocurrencies allow for much easier methods of monetizing your applications than anything else. In addition most of ICOs in 2016-2017 raised more funds that they actually needed for the implementation of what they proposed thus blockchain industry is ideally suitable for fundraising so is EOS.
4. Decentralized applications are trustless myth.
This is not actually true.
As a security engineer and smart-contract auditor I can say that there is always the need of trust: (1) in case of centralized applications controlled by the developer a user trusts that the developer will not manipulate the application to violate user on purpose. (2) In case of decentralized applications and smart-contracts a user trusts that the developer of the contract did not make any mistakes during the development process that could violate user.
Smart-contracts can not completely solve the issue of trust. The only issue that smart-contracts CAN solve is the issue of transparency. In case of centralized applications an owner of the application can violate some users rights but it will be impossible to prove this. In case of smart-contracts each action is transparently available in the blockchain, every transaction is recorded and there is no way to violate someone silently.
EOS can definitely solve the issue of transparency for application developers and users.
Resource Allocation Model
The proposed resource allocation model update assumes the removal of the permanent right to "own" a pro-rata share of CPU by staking EOS.
The current resource staking and REX renting model gave EOS great utility. The proposed resource allocation model update will strongly shitf the utility in favor of for-profit applications only.
Let's get back to the main types of the software by development purposes:
-
custom software (intended to fit specific needs of a customer)
-
open source/ commercial software (intended to meet a perceived need of some set of potential users)
-
personal use software
The new resource model will require software developer to constantly pay for his application to run on EOS blockchain which greatly limits the utility of EOS as a platform for the development of personal software (such as a single-player game, continuous computation node or process modeling software deployed on a public ledger for the sake of transparent distribution and public availability) or distribution of non-profit software.
If the main goal of the EOS was to serve as a blockchain for commercial use, and not just a platform for developing various applications as it was at the launch stage, then this step could be considered appropriate. However the recent notice form EarnBET emphasizes that EOS is still experiencing problems when used in commercial applications:
During its year-long ICO, EOS billed itself as “EOS: The Blockchain for Commercial Scale.” A corporation or enterprise will not build on a blockchain where their application can be taken off the network at any moment by a seemingly valueless resource mining scheme.
Personally I've seen various use cases for EOS as a platform for the development and distribution of personal/custom software due to the public auditability and transparency of smart-contracts as well as the elimination of trust between a software developer and a server provider. Restricting this use cases will lead to the loss of utility for EOS as a platform in my opinion.
An example of distribution platform: github
Github is usable for very wide variety of tasks. Its main ustility is to serve as a version control system and ensure teamwork as well as public representation of the developed source codes. Github is also used for wide variety of activities such as organization of business processes, hosting articles, hosting single-page applications and websites. It is possible to develop a single-player game in JS and host it at github repo so that users can play it directly from the source codes (example github clumsy bird game).
ONLY_BILL_FIRST_AUTHORIZER implementation
I strongly recommend reading the EOSIO system design considerations when covering user resource costs article to understand the implementation details of this EOS feature.
The most important thing to note is that it is necessary for an application to co-sign a transaction that the application will be paying for. This can not be done from the smart-contract and this requires a private key that have a permission to perform this action on behalf of the app.
The current implementation of ONLY_BILL_FIRST_AUTHORIZER introduces the following problems:
-
It is almost impossible to use in truly decentralized applications that do not take out part of the logic into off-chain services.
-
It introduces a number of security concerns.
The presence of a server that plays an important role in the application workflow is unacceptable for DApps
Aaron Cox in his article suggests using the following approach to utilizing the ONLY_BILL_FIRST_AUTHORIZER function:
3. Application creates, user signs first, then to a service layer...
The third scenario solves the apparent problems of the first two approaches by taking the original process and adding a third component into the mix.
This new component is a "Service Layer", running and secured on a server as a backend service invisible to the end user. While this model adds complexity to the overall architectural design of an EOSIO-based application, it allows for signatures to be created in a secure, non-distributed environment, completely outside of the application.
As it was stated earlier decentralized application must work fully on chain without any interference of off-chain services and servers. Otherwise these are not "decentralized" applications but only a traditional centralized client-server application masquerading as “d”App.
Security concerns of using ONLY_BILL_FIRST_AUTHORIZER
The suggested way of making applications pay for the users resources requires a "service layer" or some server to operate with the keys that will be used to co-sign a transaction that application is going to pay for.
The requirement of storing the private key at some server is a security concern. The need of trust between the owner of a key and a server provider is a serious problem because no one can guarantee that server providers will always act as they should. There is a human factor and a possibility of some illegal activity involving social engineering that can result in the private keys being accessed by some parties that have influenced the server provider.
This can result in private keys and funds (in case the private key has a permission to send transactions from the account of "d"App) being stolen.
We have real examples of how the human factor can result in thefts: Classic Ether Wallet hijack resulted in $300,000 theft.
Application developers must:
-
Properly set up permissions of their DApp account and private keys that they are going to use.
-
Never expose the private keys that have permission to send funds to any third party services/servers.
However, in case of off-chain services it is impossible for the user of a "d"App to verify what the application is doing in off-chain. Offchain services have zero transparency, auditability and verifiability. For a customer of "d"App this creates a need to trust that the application developer has properly managed the keys and funds can not be stolen in case a server provider will decide to perform some illegal actions. This is a security concern as well.
While it is possible to deal with this implementation of ONLY_BILL_FIRST_AUTHORIZER properly, it still has a lot of concerns.
What is required to make DApp capable of paying for user's resources
It is necessary to implement a feature that will allow smart-contracts to determine if the account at which the contract is deployed wants to pay for the resources required to perform an action.
It is necessary to give applications the ability to pay for user resources through the internal logic of a smart-contract without a requirement of any third party service layers.
Blockchain Governance Proposal
I propose the creation of 6 staking pools: 3 month, 6 month, 12 month, 2 year, 5 year, and 10 year. In a network with a token supply of 1B, each pool will receive 5M tokens per year on a minute by minute basis (assuming network is operating at 100% reliability). Users can buy into the pool to receive their pro-rata share of that pools income. A user’s vote-weight is based upon the sum of their percentage ownership of each pool. This represents a 3% annual inflation paid to the different staking pools.
This is a very reasonable proposal and I believe that this is an important step in right direction towards improving the EOS governance system.
The initial EOS governance system did not take into account that not every user (or the account that owns EOS) will have a will to participate in decision making. Granting equal voting rights to everyone, regardless of how interested the holder of EOS tokens is in decision making, leads to the fact that the voting power that was granted to those who had no incentives to participate in decision making acted carelessly or their voting powers were leaked by parties that were interested in voting.
The problem of tokenized governance system is that an owner of tokens must explicitly express his willing to participate in decision makin to grant his voting power. Otherwise he should have no voting power regardless of how much tokens he owns.
A good example is how traders behave. Traders and long term investors have a large quantity of EOS in total. However everything they want is a good deal that will bring them huge gains. They are not interested in technology and what it will turn into once they close their trade. They tend to watch charts and this is a full time job for some of them. They own multiple assets - and EOS is just a part of their portfolio. It is impossible to dive deeper into every asset that you are buying to sell a week later, so there is no chance that this group of EOS holders will participate in decision making or even have a desire to do so.
As the result, they tend to store their EOS at exchanges and they don't care about what exchanges do with it under the hood. Some exchanges have EOS block producers and they are interested in exploiting their customers funds to vote for themselves and make some money in short term. The fact that their customers don't care about this allows the exchanges to do so in theory.
However, I have some doubts about the details of the described proposal.
First of all, it states that all six staking pools will have the same amount of funding (5M/year). However it can happen that there will be not enough incentives for users to engage in long-locking pools. The risks of locking your funds (i.e. EOS) at pools that will freeze funds for 5 or 10 years are much larger than the risks of locking EOS in a staking pool for 3 months. However the allocated budgets are the same. It may be worth to allocate the budget proportional to the risks (i.e. to the locking time) so that the financial incentives would be balanced with the associated risks.
I'd like to provide a quote from the "Expected Outcome" section of the governance proposal:
Expected outcome
Exchanges would be unable to vote with user tokens because most of the control is tied up in long-term staking contracts.
It should be noted that this assumption is not necessary applicable to the current situation in reality. Exchanges can still vote with their users funds but they will need to keep a separate part of liquid balance that will be used to process withdrawals.
Exchanges can rely on an assumption that users will not request withdrawals of all their funds at once. With that being said, Exchanges can lock for voting a significant part of their total balance (say 50%) and still participate in voting.
It is really unlikely that all users will start requesting withdrawals and drain the whole "liquid budget" of a large exchange. Even if this will happen the exchange can use its funds to purchase the insufficient funds to process the withdrawals because the exchange will still get these funds back once the "voting lock period" will end.
RAM mechanics
The main problems of RAM in EOS are:
-
A user loses control over his RAM once it is used by a third party smart-contract.
-
RAM holders are incentivised to participate in decision making but they have no voting weight/rights unlike EOS holders.
-
RAM speculations.
RAM management issues.
In EOS it is possible for a contract to (1) pay for user's data or (2) require a user to allocate some RAM for the data used by the contract. For example a token contract may require a user to allocate some RAM to store his balance variable.
At the other hand, once a user has confirmed that he is allocating RAM for the contract then he is no longer in control of "his" RAM.
Even despite the fact that the RAM belongs to the user, only a contract may free it up. A user must trust that the contract developer has implemented a function to clear up the RAM. An irresponsible developer or a malicious person can implement a contract so that it will consume RAM without any possibility for user to recover it.
We should take the recent RUTM hype into account. It is possible for a contract developer to implement it so that users will not have the ability to clear their RAM once it is used by a contract. It is also possible to poison the whole ecosystem by implementing a contract that will be consuming large quantities of users RAM and then mess the contract so that it will no longer give the RAM back. In this case a malitious person can subtract the amount of RAM consumed by his contract from the total RAM supply of EOS ecosystem permanently.
RAM and EOS governance.
When we talk about a management system, we often overlook one important thing - those who hold RAM do not have voting weight for now, but they are at the same time the parties which are incentivised to make decisions that will improve the utility of EOS. Huge RAM holders are mostly DApps and users who utilize EOS as a development platform. These have much more incentives to improve the EOS ecosystem than many EOS holders that expect financial gains from EOS price moves.
This was also highlighted in the Decentralizing in Spite of Pareto Principle article. This is a very important thing that definitely needs to be addressed to ensure fair voting distribution.
Speculations on RAM
RAM price is determined by market in EOS. However the crypto markets are prone to speculations and pump&dump activity. RAM is not an exception. However RAM pump&dumps are not desirable for the EOS ecosystem because it may affect the utility of the platform and unnaturally increase the cost of DApps.
There is a 0.5% fee on RAM purchasing but this is not enough to prevent the speculations as the reality shows.
The recent RUTM activity allows me to perform a demonstrative buy and sell 25 minutes later with 2% of profit (which is enough for day traders to engage). The RUTM RAM pump goes further and the price is surging as a result of the process that is definitely not a natural demand.
If the goal is to make it harder to speculate on RAM pricing then 0.5% fee is not enough to accomplish this goal.
To stay up to date on all the EOSIO news for next week, don't forget to subscribe to our Telegram channels, follow us on Twitter and bookmark our website!
EOS GO is funded by EOS ASIA and powered by YOU. Join the community and begin contributing to the movement by adding eos go to your name and joining the EOS GO telegram group.