现在Eos的wasm智能合约代码以JIT方式加载代码的速度是30ms，意味着单线程情况下每秒的最低速度为30TPS。
现在Eos采取的做法是采用cache的方式来加快代码的执行速度。也就是说，在第一次执行智能合约的代码时，会cache编译过后的代码，下次再调用智能合约时就可以省掉这30ms的编译时间。
现在假设其中一个producer中途挂掉了，那么它再次启动重新加入后，因为cache已经清空，这时，最开始，在单线程的情况下，它产生块也就只有30TPS的速度了。
为了解决这个问题，producer必须在启动的时候重新加载所有的智能合约。这时，producer的重新启动速度就会随着部署的智能合约越来越多而越来越慢。并且由于编译wasm不支持多线程，也就意味着不能通过多线程来加速。
假如有100万个wasm智能合约，加载wasm代码最少也要30ms，那么总的加载时间就是 1e6*30/1000/60/60，即8个多小时，这显然是太长了。
不仅仅如此，这个缺陷甚至可能被恶意利用。大家都知道Eos的ts是不收费的，带宽和存储空间是按锁定的Eos的来分配的。那么这个带宽和存储空间的分配就必须小心的考虑了，不单单是要考虑存储数据要占用多少存储空间，而且要对数据是否是智能合约代码进行判断，因为编译智能合约的代码要占用额外的内存。如果设计不当，那么攻击者就可能在链上创建大量的智能合约而成本却很低，从而使链上充斥着大量无用的智能合约，从而使ts的处理速度降低并且占用大量的内存和存储空间，甚至使整个系统瘫痪。
另外，cache wasm代码的内存也肯定会消耗得越来越多，如果加载wasm所需的总内存不够了要怎么处理，现在eos还没有看到具体的处理逻辑。并且未来要实现也应该是采用类似于虚拟内存的技术，也就是将一段时间不使用的编译后的wasm代码从内存中删除，以腾出空间来保存需要使用的编译后的wasm代码。然而就像虚拟内存的缺陷一样，虽然这可以解决wasm代码无法加载的问题，但是如果处理不好必然会造成性能的大幅下降。
当然，在主链刚开始上线时这肯定不是问题，而且eos的团队也应该有足够的时间来解决这个问题。
