The Resource Economy by Remme Protocol
With Remme Protocol moving to EOSIO ecosystem, we wanted to discuss the nature of the changes the Protocol is experiencing. Our previous post explained the modifications to consensus and governance. Now, it’s time for us to dive into resource management.
Because all blockchains are resource constrained, they require a system to prevent abuse. With a blockchain that uses Remme Protocol software, there are three broad classes of resources that are consumed by users:
1. Bandwidth and Log Storage (NET)
2. Computation and Computational Backlog (CPU)
3. State Storage (RAM)
Bandwidth and computation have two components: instantaneous usage, and long-term usage. A blockchain maintains a log of all actions and this log is ultimately stored and downloaded by all full nodes. With the log of actions, it is possible to reconstruct the state of all applications.
The computational debt consists of calculations that must be performed to regenerate state from the action log. If the computational debt grows too large then it becomes necessary to take snapshots of the blockchain’s state and discard the blockchain’s history. If computational debt grows too quickly then it may take six months to replay one year’s worth of transactions. It is critical, therefore, that the computational debt is carefully managed.
Blockchain state storage is information that is accessible from application logic. It includes information such as digital keys, revocation status, and account balances. If the state is never read by the application, then it should not be stored. For example, identity scans and home address are not read by application logic, so they should not be stored in the blockchain’s state. Meanwhile, the existence of a document, the number of BP votes, and other properties do get stored as part of the blockchain’s state.
Adopting the Remme Protocol software on a launched blockchain (e.g. REMChain) means bandwidth and computational capacity are allocated on a fractional reserve basis because they are transient (unused capacity cannot be saved for future use).
Compared to the EOS blockchain, Remme Protocol software offers a simplified resource management experience.
There are two classes of smart contracts: System Contracts (invoked, managed and operated by the majority of Active BPs) and User Smart Contracts (deployed and used by regular accounts). Due to the major focus on PKI(d) use cases, we assume that most of the core PKI(d) services within the network are provided by the Block Producers based on the system smart contracts and only a small portion of services by the community dApps on top of the core ones. To address this, Remme Protocol allocates the available supply of all three resources (RAM, CPU, NET) simultaneously and proportionally to the number of tokens held in a three-day-minimum staking contract.
For example, by staking 1% of total token supply, an account gets the potential to utilize 1% of all resources (either by running its own dApp or using someone else’s dApp).
In contrast to the user smart contracts, the system contracts provide various PKI(d) services based on a subscription or per use model. For example, a user would pay a certain flat fee to store a device’s public key and its revocation status for a period of one year. After the period ends, the key transits into an expired state and the system contract frees up the RAM resources.
Remme Protocol has a flat fee to create an account. A new account gets created with the minimum required allocation of CPU, NET and RAM resources that allows users to store the account data in the state and perform about 3–5 average transactions per day at no additional cost. The goal is to let the vast majority (up to 95%) of users transact for free (assuming a regular user would not need more than five transactions a day).
Remme will develop a monitoring tool that will give visibility to users, detailing their account resource usage and quotas.
In removing the hassle of resource management and simplifying the user experience, we believe that REMChain will become very friendly and intuitive for newcomers who are not familiar with blockchain technology and its peculiarities. With this approach, we expect most users to access various high-level applications without even noticing the blockchain behind that powers them. We expect most of these users to be onboarded (and sponsored with a new account if needed) by businesses or dApps that benefit from improved security or other PKI(d) use cases.
Check out our Github repository to find out more about the Protocol’s potential and stay tuned for further updates on the modifications associated with moving to EOSIO.
