Since its inception, EOS has come under criticism. Most often, this is directed at the network’s dependence on small groups, which critics believe make EOS too centralized. For example, the EOS token supply is dominated by whales, with 69% of all tokens owned by just 100 addresses.
Under the EOS DPoS consensus model, there are just 21 block producers (BPs) responsible for running the network. However, many people don’t realize that out of those 21 block producers; only five are currently running full history nodes. These nodes are the only ones which allow dApp developers to query the entire history of the EOS blockchain.
The remaining BPs are running nodes with only a partial history of the blockchain. While partial history is sufficient for around 80% of EOS transactions, the other 20% require a full history query.
EOS is many, many times faster than other blockchains like Bitcoin or Ethereum, running at thousands of transactions per second, in contrast to five or six. This high throughput means that EOS has already processed many more transactions over its lifetime, which at less than one year is considerably shorter than either Bitcoin or Ethereum.
Therefore, due to many more transactions taking place, the EOS blockchain is much more memory intensive than Bitcoin or Ethereum. It requires EOS full history nodes to process several terabytes of data at a time, compared with Bitcoin which was still under 200 GB at the start of 2019.
For a BP to run a full history node, they have to pay for the computing resources needed to process this volume of data. As EOS continually handles new transactions, the problem will only get worse as the blockchain grows in size.
Furthermore, EOS introduced a change to the history plugin in November 2018. According to block producer EOS42, this change doubled the RAM needed to operate the plugin. Costs of running a full history node climbed up to around $30k, leading to the current situation where there are now just five full history nodes.
Block producer Cypherglass explained in a video how the EOS network could continue to operate without these nodes. A full history node only provides an access layer dApp developers to query the full history – it’s not physically holding one of the only copies of the full history. However, as things stand today, dApps currently running on EOS use only these five nodes as a means of querying the full blockchain history.
These nodes get no extra compensation or other incentives for continuing to operate the history plugin. If only one of them drops out, then the risk becomes even more significant. With the same workload split between just four full history nodes, the costs will rise even higher. Therefore, the EOS community needs to find a way to alleviate the pressure on these five nodes.
The good news is that solutions are already starting to emerge. One is LiquidApps, which has now launched its DAPP Network, offering tools and utilities designed to attract dApp developers to the EOS network.
One of the first use cases of the DAPP Network is vRAM. Whereas a BP needs actual RAM to run its node, EOS operates on its own version of RAM. A dApp developer wanting to launch on the EOS network must buy EOS RAM – or state storage – up front. The price of EOS RAM is determined by supply and demand, and the cost for developers can be prohibitively high.
LiquidApps vRAM is compatible with EOS RAM and sourced from a decentralized network of DAPP Service Providers (DSPs). A DSP can be any entity or individual, as long as they meet the minimum requirements for becoming an EOS BP.
Once they’re set up on the DAPP Network, a DSP can package up vRAM as they wish, and sell it to EOS dApp developers for DAPP tokens. However, the DSP role could do much more than that. An existing full history node could become a DSP on the DAPP Network, offering dApp developers the ability to query the full history of the EOS blockchain as part of its service packages.
The DAPP token provides an economic incentive to run the full history node, as the DSP could request staked DAPP tokens for any developer using the full history feature. The financial incentive could also attract other entities to becoming DSP’s offering the full history service, hence reducing the burden on the few. This would increase redundancy, leveraging the benefits of decentralization.
Developers are also working on other solutions. For example, EOS Canada, one of the five BPs currently running a full history node, offers the DFuse service. DFuse is a closed source solution but provides developers the service option to plug into a full history service on an as-needed basis.
Block.One, the company behind EOS, is developing another fix called the MongoDB plugin. However, this has some limitations compared to the history plugin. It doesn’t allow external users to query the blockchain, and there have been issues with various updates.
EOS developers are also working on various other solutions to the full history problem. However, the LiquidApps solution has unique potential. The promise of economic incentives for becoming a full history DSP plays to the reasons for becoming a block producer in the first place. Offering full history queries as a service could soon be a profitable enterprise, which would be a game-changer for the full history problem.
