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 

Greymass Website

Greymass on Twitter

Greymass Telegram

eos-voter wallet

Light History Node explainer