Dragonfly合伙人：错过Solana种子轮，我是如何与3250倍收益失之交臂的？

正值 Solana 诞生五周年之际， Dragonfly Capital 的合伙人@hosseeb今日发布一篇推文，回顾他在 2018 年是如何错过以 0.04 美元单价参与 Solana 种子轮投资，并错失千倍以上收益的。同时附上当初的投资备忘录以表怀念。此外我们还节选了 Solana 联创 Toly 与 Hosseeb 在此条推文下的讨论。

以下是原文详情：

我在 2018 年初拒绝了以 0.04 美元参与Solana种子轮投资的机会。

按照现在的价格，相当于已经错失 3250 倍的回报。

Solana 是我作为初级 VC 时评估的第一批项目之一。那时候我还很可爱地天真和自信，会为每个放弃投资的项目都写备忘录。

现在重读这份备忘录简直是"初级 VC 的尴尬现场"（peak junior VC cringe）。当时我们都沉迷于寻找“以太坊杀手”、研究共识协议，以及什么技术会取代 EVM / eWASM。

所以，这就是完全未经编辑的备忘录原文 —— 我职业生涯中最糟糕的投资 MISS。

生日快乐，Solana！🎂

备忘录内容

1. 阅读完白皮书后，我的速记如下：

• 他们的重大创新是历史证明（PoH）。本质上这是一个可验证的时间延迟函数，采用连续哈希运算，类似于顺序工作量证明。换句话说，选出一个时间维护者，该维护者不断地对某个值进行迭代哈希运算，并公布所有中间哈希值。由于这个过程必须在单个核心上串行执行，无法并行化，节点应该能够预测连续哈希之间经过的时间量（大概是基于他们对硬件性能的了解？）。
• PoH 节点还会将任何当前状态（例如要提交的交易）混入这些哈希中。这样便可以创建可以可靠地加盖时间戳的事件历史记录。
• 如果 PoH 节点出现问题或无法保证在线，他们提出了一种方案，让多个 PoH 节点定期相互混合状态。
• 一组验证者节点会重放并验证 PoH 节点的操作（验证过程可以通过 MapReduce 架构实现更高效的并行化）。这些验证者通过类似 Casper 的协议使用 PoS 达成共识。如果发现 PoH 节点出现拜占庭问题或行为不当，验证者节点可以选举新的 PoH 节点取而代之。
• 看起来他们将开发支付和智能合约功能。
• 他们声称可达到 71 万 TPS，并在单节点测试网络上实现了 3.5 万 TPS。

1. 我的想法：

• 他们的数字完全是扯淡。71 万 TPS 简直可笑；连谷歌每秒的搜索量都不到 10 万。这个数据被放在他们网站最显眼的位置，让我非常警惕。
• 收回之前说白皮书写得好的评价。高层次的内容不错，但技术细节非常缺乏且模糊。作为一个共识协议的描述，严谨性令人失望。
• 团队主要由高通的底层工程师组成。CEO 和 CTO 主要从事操作系统、嵌入式系统、GPU 优化和编译器方面的工作。他们在分布式系统和密码学方面的背景明显不够强，这一点在论文中表现得很明显。对拜占庭容错问题的处理很差。让我想起了 Raiblocks/Nano 的白皮书（他们也是底层工程师）。
• 并且白皮书中这样的内容让我产生疑虑：

[Solana 白皮书原文，第 5.12 节 ]

"PoH 允许网络验证者以某种程度的确定性观察过去发生的事件及其时间。当 PoH 生成器产生消息流时，所有验证者需要在 500ms 内提交他们对状态的签名。这个数值可以根据网络条件进一步降低。由于每个验证都被输入到流中，网络中的每个人都可以验证所有验证者是否在规定超时时间内提交了他们的投票，而无需直接观察投票过程。"

• 这不是一个共识协议。假设在消息传递上将 500ms 限制为共识是相当成问题的，并且没有有意义地实现拜占庭容错。况且他们如何测量 500ms？考虑到他们将基于执行的迭代哈希数量来估计时间流逝，系统中的其他节点如何就 500ms 的经过达成共识？此外，他们将如何解决由于硬件改进、硬件故障或噪声导致的时钟速度随时间推移产生的偏差？分布式系统中的时间问题非常复杂，我认为他们没有意识到它有多难。
• 再说了，谁在乎时间？这是区块链领域的一个大问题吗？人们对 15 秒/1 秒（比如 DFINITY之类的东西）的区块时间粒度不够满意吗？我认为这不算什么问题，他们在协议中引入的复杂性和混乱似乎并没有带来太多价值。
• 他们有一个部分专门讨论攻击和激励不对齐问题。他们对攻击的回应完全无法令人信服，而且同样缺乏严谨性或细节说明。
• 他们有整整一个章节讨论复制证明，就像 Filecoin 那样。搞什么？告诉我你的共识协议和如何实现交易、账户，你的区块链会有什么特性。我不关心数据存储证明。
• 还有一大段开始描述智能合约，但只是说他们将使用 LLVM 作为后端以支持多个平台。但除此之外什么也没提。
• 大量关于 GPU 和并行化的内容。这暴露出一种奇怪的专注感 —— 如果他们需要实现 BFT 共识协议和可用的智能合约平台，就不应该沉迷于他们数据包格式的并行处理。我记得他们在我看过的演示中也是这样 —— 花了大部分时间讨论如何使用这些节点处理优化，而几乎没有时间实际描述他们的共识协议。

结论：我绝对不会投这个项目

有趣的是，时隔 5 年后，当 Haseeb@hosseeb发推祝福 Solana 已经成功在加密拥有一席之地，并调侃当初稚嫩的自己如何错失大机会时，Solana 联创 Toly@aeyakovenko在这篇推文下回复：“你当初所有的担忧确实都是合理的。本质上这是一个赌注 —— 赌我们能否在保持其他团队所不具备的底层优势的同时，把这些问题都解决掉。”

而后 Haseeb 回复 Toly：“我想这就是其中的教训。你们对底层优化和独特攻击角度的执着，是其他团队所不具备的。这种发挥到极致的的扬长避短才是最重要的。当时的我完全没有意识到这一点。”