> The centralization of apis (infura, opensea and ethscan used by metamask) is the biggest problem. I could be wrong, but I don't think we've seen that fast consolidation in other early tech. I remember in the late 90s there were a number of search engines but no one really owned the space. Only 20 years later did Google emerge as the winner and is (IMO) by far the best in terms of relevant results. But that didn't happen overnight, and there wasn't a search engine dominating 90% of the market within a few years of the beginning of mainstream acceptance.
> How hard is it to create a competitor to infura? MetaMask should be incentivized to do this as they're core offering is controlled by one party.
> [edit] Never mind, metamask and infura are owned by the same company (ConsenSys). It's even worse than it appears...
Currently working in the space (graduated from doing systems-level . My hot take is what is considered a "full node" can potentially use significantly less resources. The base word size is 256-bit (size of SHA256), most is either 1s or 0s, the entire raw Ethereum blockchain is roughly 350 GiB uncompressed, probably can be much better with zstd compression on multi-core. Let's just quietly ignore that most is not using an assembly-level optimized implentations of uint256 arithmetic operations. Also all the current clients (a) afaik run transactions single-threaded, and (b) no on-disk compression, (c) at best use mmap relying on OS level paging even though you're going to have 32-byte random reads invalidating entire 4K or 16K pages out of ~3TiB of read/write space. I'm more than certain execution can be ran speculatively using STM (software transaction memory). I seriously doubt that most Ethereum transactions within a single block have that much r/w contention if you were to execute them in arbitrary order in parallel. Basically application level speculative execution (except you know the ending hash ahead of time, so you know of the ending state is valid or not). Anyhow...
What is your point? Sounds to me you're just regurgitating technical mambo jambo that doesn't realy have any relation whatsoever to any of the points quoted!
Are you trying to say that by optimizing a node's software, people will be able to run a full node on their devices?? That's patently false currently, even more if the technology actually goes viral one day (small system-level optimisations simply won't scale to compensate for the fast increase in the blockchain size).
> How hard is it to create a competitor to infura? MetaMask should be incentivized to do this as they're core offering is controlled by one party.
> [edit] Never mind, metamask and infura are owned by the same company (ConsenSys). It's even worse than it appears...
Currently working in the space (graduated from doing systems-level . My hot take is what is considered a "full node" can potentially use significantly less resources. The base word size is 256-bit (size of SHA256), most is either 1s or 0s, the entire raw Ethereum blockchain is roughly 350 GiB uncompressed, probably can be much better with zstd compression on multi-core. Let's just quietly ignore that most is not using an assembly-level optimized implentations of uint256 arithmetic operations. Also all the current clients (a) afaik run transactions single-threaded, and (b) no on-disk compression, (c) at best use mmap relying on OS level paging even though you're going to have 32-byte random reads invalidating entire 4K or 16K pages out of ~3TiB of read/write space. I'm more than certain execution can be ran speculatively using STM (software transaction memory). I seriously doubt that most Ethereum transactions within a single block have that much r/w contention if you were to execute them in arbitrary order in parallel. Basically application level speculative execution (except you know the ending hash ahead of time, so you know of the ending state is valid or not). Anyhow...