Vitalik Buterin Stresses an Important Problem in Ethereum That Has Not Yet Seen Enough Love

In a series of tweets shared a few hours ago, the Ethereum (ETH) co-founder, Vitalik Buterin, stressed an important problem in Ethereum that has not received enough love as expected.

According to Buterin, the major problem is the decentralized marketplaces where historical information about logs, transactions, and others can be provided.

Vitalik Buterin tweeted, “One important problem in ethereum that has not yet seen enough love is decentralized marketplaces for providing historical information (logs, txs… basically anything other than current state).”

One important problem in ethereum that has not yet seen enough love is decentralized marketplaces for providing historical information (logs, txs… basically anything other than current state).

— vitalik.eth (@VitalikButerin) August 2, 2020

Buterin further elaborated on the information attached to logs, which are also applicable in terms of transactions.

He wrote:

“One example is logs: 1. Client sends message “I want all historical logs for topic X” 2. Provider replies back with logs + Merkle proofs 3. Client re-broadcasts provider’s response; if the provider missed a log their deposit can get slashed. This could be done for txs too…

“Payment could be done through state channels: clients would randomly choose a provider, open a channel with them, and pay through the channel for each request. If a provider fails to respond quickly, the client can just switch to another provider.

“The important thing is that this could+should be fully decentralized neutral architecture, and being a provider should be permissionless.

“This has two key benefits to ethereum: 1. Clients could stop storing history themselves, and only store state (~5x storage size decrease) 2. Dapps could get more gas-efficient (many dapps are suboptimal gas-wise today because they put things in storage to read them more easily).

“Additionally, notice that in eth2 when the network is sharded, infrastructures of this kind basically become mandatory if we want to avoid dapp UIs all relying on centralized providers.

“There’s certainly quite a few people who have thought about such things, even implemented prototypes, etc, but this seems like an important area where we’d benefit substantially from ~5x more effort being put into it.”