如何根据代码辨别基金？
我一般通过两个渠道，一个是由源码看到注释，看是不是自己关心的基金的源码；另一个是搜一下该基金代码或者名字，看看有没有什么有意思的博客提到它。 比如这次调研的BTCJ，我在github上看到了它的源码，然后看了一下commit历史，发现了一个有趣的issue： 这个issue大概意思是，作者在单机测试的时候，BTCJ比比特币本身要快，但是在多机测试的时候，BTCJ反而没有比特币快，因此他怀疑BTCJ的性能问题，并且把这个问题提交到了bitcoin core的issue里面去了（不知道这个issue现在是什么状态）。
通过阅读这一篇 issue 我获得了两条信息： 一个就是BTCJ在单机测试的时候很快，多机测试的时候很慢，由此可以判断 BTCJ 是 基于比特币核心源代码修改的 。
另外一个就是BTCJ的作者说了一堆理由证明为什么他的交易方案比比特币自己的交易方案更快。其中有一条理由是BTCJ不用维护一个全量的map，因为所有的交易历史都记录在一个由随机数产生的hash池里，由此可以在查找交易的时候减少一些工作量。 看到这里我就明白了，之所以BTCJ的单机测试比比特币快，是因为BTCJ做了代码优化，而多机测试的时候比比特币慢，是因为不同机器上存在hash池的不同初始化种子，导致最终hash池的内容并不一致，所以找到最佳的hash池就变成了一个非常耗时的工作。
另外，从这篇issue里我还发现了BTCJ的一个缺点，就是它对每个交易的查询都是基于整数的，也就是它不能像比特币一样精确地查询某个区块里面的某个交易的输入和输出数量。 再比如上次调研的EAC，这个基金是在以太坊上面做的DApp，所以我先搜索以太坊上的相关源码，果然找到了EAC的智能合约地址以及文档： 接着我在一个分析以太坊性能的网站上，看到这个网站上的高手分析了EAC的智能合约，并且对比了它与比特币的智能合约所消耗的gas： 从图中可以看到，当 transaction数量比较少的时候，EAC要比比特币快很多；但是随着 transaction数量的增加，EAC的性能劣势明显。这说明 EAC 在小交易量的情况下，通过效率更高的方式实现了验证和记账的功能，而在 大交易量的情况下，由于无法避免的冗余计算和重复计算导致了性能的下降。