Un partenaire de Dragonfly raconte comment il a manqué l'opportunité d'investir dans la série pré-amorçage de Solana
TechFlow SélectionTechFlow Sélection
Un partenaire de Dragonfly raconte comment il a manqué l'opportunité d'investir dans la série pré-amorçage de Solana
A manqué un rendement de 3250 fois, l'un des mémorandums d'investissement les plus coûteux de l'histoire de la cryptomonnaie.
Dédié à des analyses Web3 approfondiesAuteur original : @hosseeb
Traduction : TechFlow
TechFlow : À l'occasion du cinquième anniversaire de Solana, Hosseeb, associé chez Dragonfly Capital, a publié aujourd'hui un fil sur X où il revient sur son refus en 2018 d'investir au tour de financement initial à 0,04 dollar par jeton, manquant ainsi un rendement multiplié par plus de mille. Il partage également le mémorandum d'investissement d'époque par nostalgie. Nous avons également sélectionné une partie de l'échange entre Toly, cofondateur de Solana, et Hosseeb sous ce tweet.
Voici le texte intégral original :
J'ai refusé en 2018 l'opportunité d'investir lors du tour initial de @solana à 0,04 dollar.
Au cours actuel, cela équivaut à rater un retour sur investissement de 3 250 fois.
Solana a été l'un des tout premiers projets que j'ai évalués en tant que jeune capital-risqueur. À l'époque, j'étais naïf et confiant, au point de rédiger un mémorandum pour chaque projet que je choisissais de ne pas financer.
Relire ce document aujourd'hui est purement et simplement « l’archétype du malaise du jeune VC » (peak junior VC cringe). Nous étions alors obsédés par la recherche du « tueur d’Ethereum », l’analyse des protocoles de consensus, et par savoir quelle technologie remplacerait l’EVM / eWASM.
Voici donc le mémorandum dans sa version originale, non modifiée — mon plus grand raté d’investissement à ce jour.
Bon anniversaire, Solana ! 🎂
Contenu du mémorandum
-
Notes rapides après lecture du livre blanc :
-
Leur innovation majeure est la Preuve d’Historique (Proof of History, PoH). Il s'agit essentiellement d'une fonction vérifiable de délai temporel, basée sur des hachages successifs, similaire à un travail séquentiel de type preuve de travail. Autrement dit, un gardien du temps effectue continuellement des itérations de hachage sur une certaine valeur et publie tous les hachages intermédiaires. Ce processus devant s’exécuter en série sur un seul cœur, sans possibilité de parallélisation, les nœuds devraient être capables d’estimer avec précision le temps écoulé entre deux hachages successifs (probablement en fonction de leurs connaissances sur les performances matérielles ?).
-
Les nœuds PoH intègrent également tout état courant (par exemple, les transactions à valider) dans ces chaînes de hachage. Cela permet de créer un historique fiable des événements horodatés.
-
En cas de panne ou d’indisponibilité du nœud PoH, ils proposent un mécanisme où plusieurs nœuds PoH fusionnent régulièrement leurs états entre eux.
-
Un ensemble de nœuds validateurs rejoue et vérifie les opérations du nœud PoH (le processus de vérification pouvant être parallélisé efficacement via une architecture de type MapReduce). Ces validateurs atteignent un consensus selon un protocole similaire à Casper utilisant la preuve d’enjeu (PoS). Si un nœud PoH présente un comportement byzantin ou fautif, les validateurs peuvent élire un nouveau nœud PoH pour le remplacer.
-
Ils prévoient apparemment de développer des fonctionnalités de paiement et de contrats intelligents.
-
Ils affirment pouvoir atteindre 710 000 TPS, et ont déjà réalisé 35 000 TPS sur leur réseau test mono-nœud.
-
Mes impressions :
-
Leurs chiffres sont totalement fantaisistes. 710 000 TPS, c’est ridicule ; Google effectue moins de 100 000 recherches par seconde. Le fait qu’ils mettent ce chiffre en avant sur leur site me paraît très suspect.
-
Je retire ce que j’ai dit sur la qualité du livre blanc. Le niveau général est bon, mais les détails techniques sont extrêmement vagues et manquent de rigueur. En tant que description d’un protocole de consensus, c’est profondément insatisfaisant.
-
L’équipe est principalement composée d’ingénieurs bas niveau venant de Qualcomm. Le PDG et le directeur technique ont travaillé sur les systèmes d’exploitation, les systèmes embarqués, l’optimisation GPU et les compilateurs. Leurs compétences en systèmes distribués et en cryptographie sont manifestement limitées, ce qui se reflète clairement dans le document. Le traitement de la tolérance aux fautes byzantines est particulièrement mauvais. Cela me rappelle le livre blanc de Raiblocks/Nano (eux aussi des ingénieurs bas niveau).
-
Certains passages du livre blanc suscitent en moi des doutes sérieux :
[Extrait du livre blanc de Solana, section 5.12]
« La PoH permet aux validateurs du réseau d’observer avec un certain degré de certitude les événements passés et leur chronologie. Lorsque le générateur PoH produit un flux de messages, tous les validateurs doivent soumettre la signature de leur état dans un délai de 500 ms. Cette valeur peut être réduite davantage selon les conditions du réseau. Comme chaque validation est intégrée au flux, tous les participants du réseau peuvent vérifier que chaque validateur a bien soumis son vote dans le délai imparti, sans avoir besoin d’observer directement le processus de vote. »
-
Ceci n’est pas un protocole de consensus. Supposer que la limite de 500 ms dans la transmission des messages puisse servir de base au consensus soulève de graves problèmes, et ne réalise pas une tolérance byzantine significative. De plus, comment mesurent-ils ces 500 ms ? Puisqu’ils estiment le temps écoulé en fonction du nombre d’itérations de hachage exécutées, comment les autres nœuds du système peuvent-ils s’accorder sur le passage de 500 ms ? Comment gèrent-ils les variations de vitesse d’horloge dues à l’amélioration matérielle, aux pannes ou au bruit ? La gestion du temps dans les systèmes distribués est extrêmement complexe, et je pense qu’ils n’ont aucune idée de la difficulté du problème.
-
Et puis, franchement, qui s’en soucie ? Est-ce vraiment un problème majeur dans le domaine des blockchains ? Les gens sont-ils insatisfaits de blocs toutes les 15 secondes ou 1 seconde (comme DFINITY par exemple) ? Je ne pense pas que ce soit un vrai problème, et la complexité et le désordre introduits dans le protocole ne semblent apporter aucune valeur ajoutée significative.
-
Ils consacrent une section entière aux attaques et aux désalignements d’incitations. Leurs réponses aux scénarios d’attaque sont totalement peu convaincantes, tout comme elles manquent de rigueur ou de détails.
-
Ils ont même un chapitre entier sur la preuve de duplication, à la manière de Filecoin. Mais de quoi parlent-ils ? Dites-moi plutôt comment fonctionne votre protocole de consensus, comment vous gérez les transactions et les comptes, quelles seront les caractéristiques de votre blockchain. Je me moque de la preuve de stockage de données.
-
Il y a ensuite un long passage sur les contrats intelligents, où ils expliquent simplement qu’ils utiliseront LLVM comme backend pour supporter plusieurs plateformes. Et c’est tout.
-
Ils abordent longuement les GPU et la parallélisation. Cela trahit une obsession étrange : s’ils doivent mettre en œuvre un protocole de consensus BFT et une plateforme de contrats intelligents fonctionnelle, ils ne devraient pas s’obnubiler sur la parallélisation de leur format de paquets. Je me souviens que leur présentation était exactement la même : ils passaient la majorité du temps à parler d’optimisations de traitement sur les nœuds, et presque aucun à décrire réellement leur protocole de consensus.
Conclusion : Je n’investirai absolument pas dans ce projet.
Cinq ans plus tard, quand Haseeb @hosseeb, en postant ses félicitations à Solana pour sa place désormais établie dans l’écosystème crypto, plaisante sur sa propre jeunesse et l’opportunité manquée, Toly, cofondateur de Solana @aeyakovenko, répond sous ce tweet : « Toutes tes inquiétudes étaient fondées à l’époque. C’était fondamentalement un pari : celui de réussir à résoudre tous ces problèmes tout en conservant un avantage technologique bas niveau que les autres équipes ne possédaient pas. »
Haseeb lui répond alors : « Je crois que c’est là toute la leçon. Votre obsession pour les optimisations bas niveau et votre angle d’attaque unique, que d’autres équipes ne partageaient pas, était cruciale. Cette capacité à exploiter pleinement vos forces tout en contournant les faiblesses était ce qui comptait le plus. À l’époque, je n’en avais absolument pas conscience. »
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@dragonfly_xyz
