说到fil，我基本都是摇头。没办法，糟糕的市场表现确实伤了很多人的心，但真的是一个无可奈何的阿斗吗？
看完fil的整个奋斗史，你会有所作为。
第1部分：被迫做公链。Beard其实一开始只想做以太链的dapp存储应用，无奈等到Ether 2.0到来，花儿都没了。现在以太网链的性能根本不达标，只能自己动手。
Part 2: Juan是V神的脑残粉，要做以太一样的去中心化公链。于是，饱受诟病的低速fil公链诞生了。
第三部分：问题来了。由于低速tps和容量限制，肯定无法在链上实时匹配数据。好吧，那就改成线下相亲吧。下行匹配不需要上行验证，所以有一个很明显的bug:一些节点互相传输大量数据，也就是欺骗了系统的计算能力，然后就会混乱。
第四部：卷骚行动又来了！既然这个bug封不了，那就公开给大家用吧。拜托，大家都是公平利用漏洞，为自己封装数据。好家伙，现在填满网络存储器都是垃圾数据。你知道是怎么回事。
第五部分：但是，问题又来了！都是封装自己的数据，甚至懒的连数据都不打包。链上来检查的时候，我会临时生成数据来处理。怎么修？胡子肯定是不允许的。于是他突发奇想，通过十几个通道对封装的数据进行加密。彻底切断你临时抱佛脚的可能性。
第六部：好吧，俗话说，伤敌八百。还有一个问题！凭空给数据加十几个密码锁，读的时候要慢慢解锁。于是就产生了一个严重的后果：数据读取慢，甚至无法读取！这直接把路堵死了。
在山的尽头，没有出路，但有另一个村庄！
就在我们苦苦寻找出路的时候，一个亮瞎的创新CDN搜索节点出现了。如果说存储节点是总统，那么检索节点就是贴心秘书。每个存储节点周围都有大量的检索节点。检索节点负责对读取频率高的热点数据进行缓存和备份，以便即时读取。最近怎么样？有了贴心秘书的样子，做事真的事半功倍。解决了热数据读取的问题。
回顾六部，胡安为了填补漏洞，不断完善自己的补丁。你会发现做行业先锋有多难：没有经验，你得自己攻克技术难题，你得自己出去闯。
当热数据瞬间读取，加上FVM，应用爆炸还会远吗？