Gate.io note: On the occasion of the 5th anniversary of Solana's birth, Hosseeb, a partner at Dragonfly Capital, released a tweet today, reviewing how he missed the opportunity to participate in Solana's seed round investment at a price of 0.04 USD in 2018, missing out on over a thousand times the return. At the same time, the original investment memorandum is attached for remembrance. In addition, we have excerpted the discussion between Solana's co-founder Toly and Hosseeb in the comments of this tweet.
Voici les détails du texte original :
J'ai refusé l'opportunité de participer au tour de financement initial de @solana à 0.04 $ en 2018.
Au prix actuel, cela équivaut à avoir manqué un retour sur investissement de 3250 fois.
Solana est l'un des premiers projets que j'ai évalués en tant que VC junior. À l'époque, j'étais encore naïf et confiant, et j'écrivais des mémos pour chaque projet auquel je renonçais.
Relire maintenant cette note de service, c'est vraiment le "pic de la gêne des VC juniors". Nous étions alors tous obsédés par la recherche du "tueur d'Ethereum", l'étude des protocoles de consensus, et quelle technologie remplacerait l'EVM / eWASM.
Donc, voici le texte intégral non édité du mémo - le pire investissement de ma carrière professionnelle, MISS.
Joyeux anniversaire, Solana！🎂
Contenu du mémo
Après avoir lu le livre blanc, voici ce que j'ai noté :
Leur innovation majeure est historiquement prouvée (PoH). Fondamentalement, il s'agit d'une fonction de retard de temps vérifiable, utilisant des opérations de hachage continues, similaire à une preuve de travail séquentielle. En d'autres termes, un gardien du temps est choisi, qui itère continuellement une valeur à travers des opérations de hachage et publie toutes les valeurs de hachage intermédiaires. Comme ce processus doit être exécuté en série sur un seul cœur, sans possibilité de parallélisation, les nœuds devraient être capables de prédire le temps écoulé entre les hachages continus (probablement en fonction de leur compréhension des performances matérielles ?).
Le nœud PoH mélange également tout état actuel (par exemple, les transactions à soumettre) dans ces hachages. Cela permet de créer un historique d'événements avec horodatage fiable.
Si un nœud PoH rencontre des problèmes ou ne peut pas garantir une disponibilité en ligne, ils ont proposé un plan pour mélanger régulièrement les états de plusieurs nœuds PoH.
Un groupe de nœuds validateurs rejouera et validera les opérations du nœud PoH (le processus de validation peut être plus efficacement parallélisé en utilisant l'architecture MapReduce). Ces validateurs parviennent à un consensus en utilisant un protocole similaire à Casper avec PoS. En cas de problème byzantin ou de comportement inapproprié du nœud PoH, les nœuds validateurs peuvent élire un nouveau nœud PoH pour le remplacer.
Il semble qu'ils vont développer des fonctionnalités de paiement et de contrats intelligents.
Ils prétendent atteindre 710 000 TPS et ont réalisé 35 000 TPS sur un réseau de test à nœud unique.
Mon idée :
Leurs chiffres sont complètement ridicules. 71 万 TPS est tout simplement risible ; même le volume de recherche par seconde de Google est inférieur à 10 万. Ces données sont placées à un endroit très visible sur leur site Web, ce qui me rend très méfiant.
Retirez les éloges précédents sur la qualité de l'écriture du livre blanc. Le contenu de haut niveau est bon, mais les détails techniques sont très insuffisants et flous. En tant que description d'un protocole de consensus, la rigueur laisse à désirer.
L'équipe est principalement composée d'ingénieurs de base de Qualcomm. Le PDG et le CTO se concentrent principalement sur le système d'exploitation, les systèmes embarqués, l'optimisation du GPU et les compilateurs. Leur expérience dans les systèmes distribués et la cryptographie est clairement insuffisante, ce qui est très évident dans le document. Ils traitent très mal le problème de tolérance aux fautes byzantines. Cela me rappelle le livre blanc de Raiblocks/Nano (eux aussi des ingénieurs de base).
Et le contenu de ce livre blanc me fait douter :
[Solana livre blanc, section 5.12 ]
"PoH permet aux validateurs du réseau d'observer avec une certaine certitude les événements passés et leur heure. Lorsque le générateur de PoH produit un flux de messages, tous les validateurs doivent soumettre leur signature d'état dans les 500ms. Cette valeur peut être réduite davantage en fonction des conditions réseau. Comme chaque validation est entrée dans le flux, tout le monde dans le réseau peut vérifier si tous les validateurs ont soumis leur vote dans le délai imparti sans avoir à observer directement le processus de vote."
Ce n'est pas un protocole de consensus. Supposer que limiter à 500ms la communication des messages pour parvenir à un consensus est problématique et ne permet pas une mise en œuvre significative de la tolérance aux fautes byzantines. De plus, comment mesurent-ils les 500ms ? Comment les autres nœuds du système peuvent-ils parvenir à un consensus sur le passage de 500ms, étant donné qu'ils estiment le temps écoulé en fonction du nombre d'itérations de hachage effectuées ? De plus, comment vont-ils résoudre les écarts de vitesse d'horloge dus aux améliorations matérielles, aux défaillances matérielles ou au bruit, qui se produisent au fil du temps ? Les problèmes de synchronisation du temps dans les systèmes distribués sont extrêmement complexes, et je pense qu'ils ne réalisent pas à quel point cela est difficile.
En outre, qui se soucie du temps? Est-ce un gros problème dans le domaine de la blockchain? Les gens ne sont-ils pas satisfaits de la granularité du temps de bloc de 15 secondes / 1 seconde (comme DFINITY)? Je ne pense pas que ce soit un problème, l'introduction de complexité et de confusion dans le protocole ne semble pas apporter beaucoup de valeur.
Ils ont une section dédiée à discuter spécifiquement des problèmes d'attaques et d'incitations qui ne sont pas alignés. Leur réponse aux attaques est totalement peu convaincante et manque également de rigueur ou de détails explicatifs.
Ils consacrent un chapitre entier à discuter de la preuve de réplication, comme Filecoin. Quoi ? Dites-moi quel est votre protocole de consensus et comment vous réalisez les transactions, les comptes. Quelles caractéristiques votre blockchain aura-t-elle. Je ne me soucie pas de la preuve de stockage des données.
Il y a encore un long paragraphe qui commence à décrire les contrats intelligents, mais il ne mentionne que l'utilisation de LLVM comme backend pour prendre en charge plusieurs plates-formes. Mais à part cela, rien d'autre n'est mentionné.
Beaucoup de contenu sur les GPU et la parallélisation. Cela expose un sentiment étrange de concentration - s'ils ont besoin de mettre en œuvre un protocole de consensus BFT et une plateforme de contrat intelligent utilisable, ils ne devraient pas être obsédés par le traitement parallèle de leurs formats de paquets. Je me souviens que c'était aussi le cas dans la démo que j'ai vue - la plupart du temps était consacré à discuter de l'optimisation de l'utilisation de ces nœuds, et il n'y avait presque pas de temps pour décrire réellement leur protocole de consensus.
Conclusion: Je ne vais absolument pas investir dans ce projet
Il est intéressant de noter que, cinq ans plus tard, lorsque Haseeb @hosseeb a tweeté ses vœux de réussite à Solana dans le monde de la cryptographie et s'est moqué de lui-même en regrettant d'avoir raté une grande opportunité, Toly, co-fondateur de Solana, a répondu à ce tweet en disant : "Toutes tes inquiétudes à l'époque étaient en effet légitimes. Fondamentalement, il s'agissait d'un pari - parier que nous pourrions conserver un avantage fondamental que d'autres équipes n'avaient pas, tout en résolvant ces problèmes."
Ensuite, Haseeb répondit à Toly : "Je pense que c'est la leçon à tirer. Votre persistance dans l'optimisation de base et dans des angles d'attaque uniques est ce que les autres équipes n'ont pas. C'est cette exploitation maximale des forces et faiblesses qui est la plus importante. À l'époque, je n'en avais aucune conscience."
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Dragonfly partenaire : comment ai-je manqué l'opportunité d'investir dans la phase de démarrage de Solana ?
Auteur original: @hosseeb
Compilation: Deep Tide TechFlow
Gate.io note: On the occasion of the 5th anniversary of Solana's birth, Hosseeb, a partner at Dragonfly Capital, released a tweet today, reviewing how he missed the opportunity to participate in Solana's seed round investment at a price of 0.04 USD in 2018, missing out on over a thousand times the return. At the same time, the original investment memorandum is attached for remembrance. In addition, we have excerpted the discussion between Solana's co-founder Toly and Hosseeb in the comments of this tweet.
Voici les détails du texte original :
J'ai refusé l'opportunité de participer au tour de financement initial de @solana à 0.04 $ en 2018.
Au prix actuel, cela équivaut à avoir manqué un retour sur investissement de 3250 fois.
Solana est l'un des premiers projets que j'ai évalués en tant que VC junior. À l'époque, j'étais encore naïf et confiant, et j'écrivais des mémos pour chaque projet auquel je renonçais.
Relire maintenant cette note de service, c'est vraiment le "pic de la gêne des VC juniors". Nous étions alors tous obsédés par la recherche du "tueur d'Ethereum", l'étude des protocoles de consensus, et quelle technologie remplacerait l'EVM / eWASM.
Donc, voici le texte intégral non édité du mémo - le pire investissement de ma carrière professionnelle, MISS.
Joyeux anniversaire, Solana！🎂
Contenu du mémo
Après avoir lu le livre blanc, voici ce que j'ai noté :
Leur innovation majeure est historiquement prouvée (PoH). Fondamentalement, il s'agit d'une fonction de retard de temps vérifiable, utilisant des opérations de hachage continues, similaire à une preuve de travail séquentielle. En d'autres termes, un gardien du temps est choisi, qui itère continuellement une valeur à travers des opérations de hachage et publie toutes les valeurs de hachage intermédiaires. Comme ce processus doit être exécuté en série sur un seul cœur, sans possibilité de parallélisation, les nœuds devraient être capables de prédire le temps écoulé entre les hachages continus (probablement en fonction de leur compréhension des performances matérielles ?).
Le nœud PoH mélange également tout état actuel (par exemple, les transactions à soumettre) dans ces hachages. Cela permet de créer un historique d'événements avec horodatage fiable.
Si un nœud PoH rencontre des problèmes ou ne peut pas garantir une disponibilité en ligne, ils ont proposé un plan pour mélanger régulièrement les états de plusieurs nœuds PoH.
Un groupe de nœuds validateurs rejouera et validera les opérations du nœud PoH (le processus de validation peut être plus efficacement parallélisé en utilisant l'architecture MapReduce). Ces validateurs parviennent à un consensus en utilisant un protocole similaire à Casper avec PoS. En cas de problème byzantin ou de comportement inapproprié du nœud PoH, les nœuds validateurs peuvent élire un nouveau nœud PoH pour le remplacer.
Il semble qu'ils vont développer des fonctionnalités de paiement et de contrats intelligents.
Ils prétendent atteindre 710 000 TPS et ont réalisé 35 000 TPS sur un réseau de test à nœud unique.
Mon idée :
Leurs chiffres sont complètement ridicules. 71 万 TPS est tout simplement risible ; même le volume de recherche par seconde de Google est inférieur à 10 万. Ces données sont placées à un endroit très visible sur leur site Web, ce qui me rend très méfiant.
Retirez les éloges précédents sur la qualité de l'écriture du livre blanc. Le contenu de haut niveau est bon, mais les détails techniques sont très insuffisants et flous. En tant que description d'un protocole de consensus, la rigueur laisse à désirer.
L'équipe est principalement composée d'ingénieurs de base de Qualcomm. Le PDG et le CTO se concentrent principalement sur le système d'exploitation, les systèmes embarqués, l'optimisation du GPU et les compilateurs. Leur expérience dans les systèmes distribués et la cryptographie est clairement insuffisante, ce qui est très évident dans le document. Ils traitent très mal le problème de tolérance aux fautes byzantines. Cela me rappelle le livre blanc de Raiblocks/Nano (eux aussi des ingénieurs de base).
Et le contenu de ce livre blanc me fait douter :
[Solana livre blanc, section 5.12 ]
"PoH permet aux validateurs du réseau d'observer avec une certaine certitude les événements passés et leur heure. Lorsque le générateur de PoH produit un flux de messages, tous les validateurs doivent soumettre leur signature d'état dans les 500ms. Cette valeur peut être réduite davantage en fonction des conditions réseau. Comme chaque validation est entrée dans le flux, tout le monde dans le réseau peut vérifier si tous les validateurs ont soumis leur vote dans le délai imparti sans avoir à observer directement le processus de vote."
Ce n'est pas un protocole de consensus. Supposer que limiter à 500ms la communication des messages pour parvenir à un consensus est problématique et ne permet pas une mise en œuvre significative de la tolérance aux fautes byzantines. De plus, comment mesurent-ils les 500ms ? Comment les autres nœuds du système peuvent-ils parvenir à un consensus sur le passage de 500ms, étant donné qu'ils estiment le temps écoulé en fonction du nombre d'itérations de hachage effectuées ? De plus, comment vont-ils résoudre les écarts de vitesse d'horloge dus aux améliorations matérielles, aux défaillances matérielles ou au bruit, qui se produisent au fil du temps ? Les problèmes de synchronisation du temps dans les systèmes distribués sont extrêmement complexes, et je pense qu'ils ne réalisent pas à quel point cela est difficile.
En outre, qui se soucie du temps? Est-ce un gros problème dans le domaine de la blockchain? Les gens ne sont-ils pas satisfaits de la granularité du temps de bloc de 15 secondes / 1 seconde (comme DFINITY)? Je ne pense pas que ce soit un problème, l'introduction de complexité et de confusion dans le protocole ne semble pas apporter beaucoup de valeur.
Ils ont une section dédiée à discuter spécifiquement des problèmes d'attaques et d'incitations qui ne sont pas alignés. Leur réponse aux attaques est totalement peu convaincante et manque également de rigueur ou de détails explicatifs.
Ils consacrent un chapitre entier à discuter de la preuve de réplication, comme Filecoin. Quoi ? Dites-moi quel est votre protocole de consensus et comment vous réalisez les transactions, les comptes. Quelles caractéristiques votre blockchain aura-t-elle. Je ne me soucie pas de la preuve de stockage des données.
Il y a encore un long paragraphe qui commence à décrire les contrats intelligents, mais il ne mentionne que l'utilisation de LLVM comme backend pour prendre en charge plusieurs plates-formes. Mais à part cela, rien d'autre n'est mentionné.
Beaucoup de contenu sur les GPU et la parallélisation. Cela expose un sentiment étrange de concentration - s'ils ont besoin de mettre en œuvre un protocole de consensus BFT et une plateforme de contrat intelligent utilisable, ils ne devraient pas être obsédés par le traitement parallèle de leurs formats de paquets. Je me souviens que c'était aussi le cas dans la démo que j'ai vue - la plupart du temps était consacré à discuter de l'optimisation de l'utilisation de ces nœuds, et il n'y avait presque pas de temps pour décrire réellement leur protocole de consensus.
Conclusion: Je ne vais absolument pas investir dans ce projet
Il est intéressant de noter que, cinq ans plus tard, lorsque Haseeb @hosseeb a tweeté ses vœux de réussite à Solana dans le monde de la cryptographie et s'est moqué de lui-même en regrettant d'avoir raté une grande opportunité, Toly, co-fondateur de Solana, a répondu à ce tweet en disant : "Toutes tes inquiétudes à l'époque étaient en effet légitimes. Fondamentalement, il s'agissait d'un pari - parier que nous pourrions conserver un avantage fondamental que d'autres équipes n'avaient pas, tout en résolvant ces problèmes."
Ensuite, Haseeb répondit à Toly : "Je pense que c'est la leçon à tirer. Votre persistance dans l'optimisation de base et dans des angles d'attaque uniques est ce que les autres équipes n'ont pas. C'est cette exploitation maximale des forces et faiblesses qui est la plus importante. À l'époque, je n'en avais aucune conscience."