We sat down with
Aaron Cox and
Scott Sallinen from
Greymass, one of the strongest infrastructure-focused block producer teams in the EOS community. They are known to many users for their
eos-voter desktop wallet, but they also do a ton of behind-the-scenes work on core infrastructure for the network. It’s work that often goes unnoticed, but it is absolutely critical for the healthy functioning of both the EOS blockchain and the dApps built on top of it.
Recently, many people have begun talking about the size of EOS’s full history API nodes and the storage requirements for these nodes. We
discussed this issue in our most recent newsletter, but we wanted to speak with experts on the subject. Team Greymass knows these issues better than almost anyone, and we dove into the top in-depth. We also covered a number of other interesting topics, including:
- Scott and Aaron’s background in Steem and other DPOS chains
- The infamous Whiteblock report on EOS
- Academia and the blockchain industry
- The issues around full history API nodes on EOS
- Consensus nodes vs. history nodes
- Why full history nodes matter
- The importance of having API standards
- Storage requirements for derived history
- The reasons why full history is so large
- CPU vs. NET on EOS and how each contribute to storage requirements
- Full history API access as a BP service vs. a paid service
- How APIs affect the decentralization of dApps
- Greymass’s Light History solution
- Other solutions on the horizon
- New tools and products Greymass is working on
Links
