Original author: @hosseeb
Original compilation: TechFlow
TechFlow note: On the occasion of the 5th anniversary of Solana's founding, @hosseeb, a partner at Dragonfly Capital, released a tweet today, reflecting on how he missed the opportunity to participate in Solana's seed round at $0.04 per token in 2018, missing out on over 3,250x returns. He also attached the original investment memo as a memento. In addition, we have excerpted the discussion between Solana co-founder Toly and Hosseeb under this tweet.
The original text is as follows:
In early 2018, I turned down the opportunity to invest in the @solana seed round at $0.04.
At today's prices, that would have been a 3,250x return.
Solana was one of the first projects I evaluated as a junior VC. Back then, I was adorably naive and confident, writing memos for every investment I passed on.
Rereading this memo is pure "peak junior VC cringe". We were all obsessed with finding the "Ethereum killer", researching consensus protocols, and what technology would replace the EVM/eWASM.
So here is the completely unedited original memo - the worst investment MISS of my career.
Happy birthday, Solana! 🎂
Memo content
1. After reading the whitepaper, my notes are as follows:
Their key innovation is Proof of History (PoH). Essentially this is a verifiable delay function, using continuous hashing, similar to sequential Proof of Work. In other words, they elect a time keeper who constantly iterates a hash on some value and publishes all the intermediate hashes. Since this process must be executed serially on a single core and cannot be parallelized, nodes should be able to predict the time elapsed between consecutive hashes (presumably based on their understanding of the hardware performance?).
The PoH nodes also mix in any current state (e.g. transactions to be committed) into these hashes. This allows them to create a tamper-evident history of events with reliable timestamps.
If the PoH node fails or cannot guarantee liveness, they propose a scheme where multiple PoH nodes periodically mix their state.
A set of validator nodes will replay and verify the operations of the PoH node (the verification process can be made more efficient through a MapReduce architecture). These validators reach consensus using PoS, similar to Casper. If they detect Byzantine or malicious behavior from the PoH node, they can elect a new PoH node.
It looks like they will develop payment and smart contract functionality.
They claim 710,000 TPS and have achieved 35,000 TPS on a single node testnet.
2. My thoughts:
Their numbers are complete bullshit. 710,000 TPS is laughable; even Google's search volume is less than 100,000 TPS. This data point being prominently displayed on their website makes me very wary.
I take back my earlier praise of the whitepaper. The high-level content is decent, but the technical details are very lacking and vague. As a description of a consensus protocol, the rigor is disappointing.
The team is primarily composed of low-level engineers from Qualcomm. The CEO and CTO have mainly worked on operating systems, embedded systems, GPU optimization, and compilers. Their background in distributed systems and cryptography is clearly lacking, which is evident in the paper. Their handling of the Byzantine fault tolerance problem is poor. Reminds me of the Raiblocks/Nano whitepaper (also written by low-level engineers).
And content like this in the whitepaper raises red flags for me:
[Solana whitepaper excerpt, Section 5.12]
"PoH allows network validators to observe past events and their timestamps with a degree of certainty. As the PoH generator produces the message stream, all validators must submit their signatures on the state within 500 ms. This value can be further reduced based on network conditions. Since each validation is input into the stream, everyone on the network can verify that all validators submitted their votes within the specified timeout, without directly observing the voting process."
This is not a consensus protocol. Assuming a 500 ms message delivery constraint as consensus is highly problematic, and does not meaningfully implement Byzantine fault tolerance. Moreover, how do they measure 500 ms? Given that they will be estimating time passage based on the number of iterated hashes, how will other nodes in the system agree on 500 ms? And how will they address clock drift over time due to hardware improvements, failures, or noise? Time issues in distributed systems are very hard, and I don't think they appreciate how difficult it is.
Also, who cares about time? Is this a big problem in the blockchain space? Are people unsatisfied with 15 sec/1 sec (e.g. DFINITY) block times? I don't think this is an issue, and the complexity and messiness they introduce into the protocol doesn't seem to bring much value.
They have a section specifically discussing attacks and incentive misalignment problems. Their responses to attacks are completely unconvincing, and again lack rigor or detailed explanation.
They have an entire chapter discussing Proof of Replication, just like Filecoin. What? Tell me about your consensus protocol and how you'll implement transactions and accounts, what features your blockchain will have. I don't care about data storage proofs.
There's also a large section starting to describe smart contracts, but only saying they'll use LLVM as a backend to support multiple platforms. Nothing else.
Lots of content about GPUs and parallelization. This betrays a strange focus - if they need to implement a BFT consensus protocol and a viable smart contract platform, they shouldn't be so obsessed with the parallel processing of their data packet formats. I recall their demos were also like this - spending most of the time discussing these node processing optimizations, with barely any time spent actually describing their consensus protocol.
Conclusion: I absolutely will not invest in this project
Interestingly, 5 years later, when Haseeb @hosseeb tweeted to wish Solana a happy birthday and joked about how his younger self had missed out on a huge opportunity, Solana co-founder Toly @aeyakovenko replied in the tweet that "All your concerns at the time were indeed valid. Essentially, it was a bet - a bet that we could solve all those problems while maintaining the underlying advantages that other teams didn't have."
Haseeb then replied to Toly, "I think that's the lesson here. Your obsession with low-level optimizations and unique attack angles, which other teams lacked, is what mattered most. Doubling down on your strengths and mitigating your weaknesses is key. I completely failed to appreciate that at the time."
