À l’occasion du cinquième anniversaire de Solana, Hosseeb, associé chez Dragonfly Capital, a publié un tweet aujourd’hui rappelant comment il a raté un tour de table de 0,04 $ de Solana en 2018 et a manqué plus de 1 000 fois les gains. Dans le même temps, le mémorandum d’investissement original est joint pour exprimer la nostalgie. Nous avons également extrait la discussion entre les co-créateurs de Solana, Toly et Hosseeb, sous ce tweet.
Voici les détails du texte original :
J'ai refusé l'opportunité de participer à l'investissement en seed round de Solana à 0,04 $ au début de 2018.
Au prix actuel, cela équivaut à avoir déjà manqué un retour de 3250 fois.
Solana est l'un des premiers projets que j'ai évalués en tant que VC junior. À cette époque, j'étais encore très mignon, naïf et confiant, et j'écrivais des mémos pour chaque projet dont je renonçais à l'investissement.
Relire ce mémo maintenant est tout simplement "un moment gênant pour les VC débutants" (peak junior VC cringe). À l'époque, nous étions tous obsédés par la recherche du "tueur d'Ethereum", l'étude des protocoles de consensus, et quelle technologie pourrait remplacer l'EVM / eWASM.
Donc, voici le texte original du mémo complètement non édité — — le pire investissement de ma carrière.
Joyeux anniversaire, Solana !
Contenu du mémo
Après avoir lu le livre blanc, mes notes sont les suivantes :
Leur innovation majeure est la preuve historique (PoH). Essentiellement, il s'agit d'une fonction de délai temporel vérifiable, utilisant des opérations de hachage continues, similaire à une preuve de travail séquentielle. En d'autres termes, un mainteneur de temps est sélectionné, et ce mainteneur effectue constamment des opérations de hachage itératives sur une certaine valeur et publie tous les hachages intermédiaires. Étant donné que ce processus doit être exécuté de manière séquentielle sur un seul cœur et ne peut pas être parallélisé, les nœuds devraient être en mesure de prédire la quantité de temps écoulé entre les hachages consécutifs (probablement basé sur leur compréhension des performances du matériel ?).
Le nœud PoH se mélange également dans n’importe quel état actuel, tel qu’une transaction à soumettre, dans ces hachages. Cela vous permet de créer un historique des événements qui peut être horodaté de manière fiable.
Si un nœud PoH rencontre des problèmes ou ne peut garantir sa disponibilité en ligne, ils ont proposé un plan permettant à plusieurs nœuds PoH de mélanger régulièrement leurs états.
Un ensemble de nœuds validateurs reproduira et validera les opérations des nœuds PoH (le processus de validation peut être parallélisé de manière plus efficace grâce à une architecture MapReduce). Ces validateurs atteignent un consensus via un protocole similaire à Casper utilisant PoS. Si un nœud PoH rencontre un problème byzantin ou un comportement inapproprié, 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 :
Leur chiffre est complètement absurde. 71 000 TPS est tout simplement risible ; même le nombre de recherches par seconde de Google n'atteint pas 100 000. Cette donnée est placée à l'endroit le plus visible de leur site, ce qui me rend très méfiant.
Retirer l'évaluation précédente selon laquelle le livre blanc était bien écrit. 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 est décevante.
L'équipe est principalement composée d'ingénieurs de base de Qualcomm. Le CEO et le CTO se concentrent principalement sur les systèmes d'exploitation, les systèmes embarqués, l'optimisation des GPU et les compilateurs. Leur expérience en systèmes distribués et en cryptographie semble clairement insuffisante, ce qui est évident dans le document. Leur gestion des problèmes de tolérance aux pannes byzantines est médiocre. Cela me rappelle le livre blanc de Raiblocks/Nano (qui sont également des ingénieurs de base).
Et un contenu comme celui-ci dans le livre blanc me fait douter :
[Document blanc Solana, Section 5.12]
« 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 de PoH produit un flux de messages, tous les validateurs doivent soumettre leur signature sur l'état dans les 500 ms. Ce chiffre peut être réduit davantage en fonction des conditions du réseau. Étant donné que chaque validation est intégrée dans le flux, chacun dans le réseau peut vérifier si tous les validateurs ont soumis leur vote dans le délai imparti, sans avoir besoin d'observer directement le processus de vote. »
Ce n'est pas un protocole de consensus. Supposer que limiter à 500 ms dans la messagerie est un consensus est assez problématique, et il n'y a pas de mise en œuvre significative de la tolérance aux pannes byzantines. De plus, comment mesurent-ils les 500 ms ? Étant donné qu'ils estimeront le temps écoulé en fonction du nombre d'itérations de hachage exécutées, comment les autres nœuds du système parviennent-ils à un consensus sur l'écoulement de 500 ms ? En outre, comment vont-ils résoudre les écarts de vitesse d'horloge au fil du temps dus à des améliorations matérielles, des pannes matérielles ou des bruits ? Les problèmes de temps dans les systèmes distribués sont très complexes, et je pense qu'ils ne réalisent pas à quel point cela est difficile.
De plus, qui se soucie du temps ? Est-ce un grand 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 des choses comme DFINITY) ? Je ne pense pas que ce soit un problème, la complexité et le chaos qu'ils introduisent dans le protocole semblent ne pas apporter beaucoup de valeur.
Ils ont une section dédiée à la discussion des problèmes d'attaque et d'incitation désalignés. Leur réponse aux attaques est totalement peu convaincante et manque également de rigueur ou de détails.
Ils ont tout un chapitre consacré à la preuve de réplication, tout comme Filecoin. Que se passe-t-il ? Dites-moi votre protocole de consensus et comment vous réalisez des transactions et des comptes, quelles caractéristiques aura votre blockchain. Je ne me soucie pas de la preuve de stockage de données.
Il y a encore une longue section qui commence à décrire les contrats intelligents, mais elle ne dit que qu'ils utiliseront LLVM comme backend pour supporter plusieurs plateformes. Mais à part cela, rien d'autre n'est mentionné.
Beaucoup de contenu sur les GPU et la parallélisation. Cela révèle une étrange concentration - s'ils ont besoin de mettre en œuvre un protocole de consensus BFT et une plateforme de contrats intelligents disponible, ils ne devraient pas être obsédés par le traitement parallèle de leur format de paquet. Je me souviens qu'ils en ont également discuté dans la présentation que j'ai vue - ils ont passé la majeure partie de leur temps à discuter de l'optimisation du traitement par ces nœuds, et presque pas de temps à décrire réellement leur protocole de consensus.
Conclusion : Je ne vais absolument pas investir dans ce projet.
Il est intéressant de noter qu'après 5 ans, lorsque Haseeb a tweeté pour féliciter Solana d'avoir réussi à se faire une place dans le monde de la cryptographie et s'est moqué de son ancien moi immature qui a raté une grande opportunité, Toly, co-fondateur de Solana, a répondu à ce tweet : "Toutes tes préoccupations à l'époque étaient effectivement raisonnables. En essence, c'est un pari — parier sur notre capacité à résoudre tous ces problèmes tout en maintenant un avantage fondamental que les autres équipes n'ont pas."
Haseeb répondit alors à Toly : « Je pense que c’est la leçon. Votre dévouement à l’optimisation de bas niveau et aux angles d’attaque uniques est quelque chose qu’aucune autre équipe n’a. Ce genre de maximisation des forces et d’éviter les faiblesses est la chose la plus importante. Je ne m’en rendais pas compte du tout. ”
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.
2 J'aime
Récompense
2
1
Partager
Commentaire
0/400
LifeChangerCrypto
· 03-24 23:49
nous attendons le grand bull run dans le marché des cryptomonnaiesBull Run 🐂
Dragonfly Partenaire : Comment ai-je raté le tour de semence de 0,04 dollar SOL ? La pire décision de ma vie
Auteur | Hosseeb
Compilation | Deep Tide TechFlow
À l’occasion du cinquième anniversaire de Solana, Hosseeb, associé chez Dragonfly Capital, a publié un tweet aujourd’hui rappelant comment il a raté un tour de table de 0,04 $ de Solana en 2018 et a manqué plus de 1 000 fois les gains. Dans le même temps, le mémorandum d’investissement original est joint pour exprimer la nostalgie. Nous avons également extrait la discussion entre les co-créateurs de Solana, Toly et Hosseeb, sous ce tweet.
Voici les détails du texte original :
J'ai refusé l'opportunité de participer à l'investissement en seed round de Solana à 0,04 $ au début de 2018.
Au prix actuel, cela équivaut à avoir déjà manqué un retour de 3250 fois.
Solana est l'un des premiers projets que j'ai évalués en tant que VC junior. À cette époque, j'étais encore très mignon, naïf et confiant, et j'écrivais des mémos pour chaque projet dont je renonçais à l'investissement.
Relire ce mémo maintenant est tout simplement "un moment gênant pour les VC débutants" (peak junior VC cringe). À l'époque, nous étions tous obsédés par la recherche du "tueur d'Ethereum", l'étude des protocoles de consensus, et quelle technologie pourrait remplacer l'EVM / eWASM.
Donc, voici le texte original du mémo complètement non édité — — le pire investissement de ma carrière.
Joyeux anniversaire, Solana !
Contenu du mémo
Leur innovation majeure est la preuve historique (PoH). Essentiellement, il s'agit d'une fonction de délai temporel vérifiable, utilisant des opérations de hachage continues, similaire à une preuve de travail séquentielle. En d'autres termes, un mainteneur de temps est sélectionné, et ce mainteneur effectue constamment des opérations de hachage itératives sur une certaine valeur et publie tous les hachages intermédiaires. Étant donné que ce processus doit être exécuté de manière séquentielle sur un seul cœur et ne peut pas être parallélisé, les nœuds devraient être en mesure de prédire la quantité de temps écoulé entre les hachages consécutifs (probablement basé sur leur compréhension des performances du matériel ?).
Le nœud PoH se mélange également dans n’importe quel état actuel, tel qu’une transaction à soumettre, dans ces hachages. Cela vous permet de créer un historique des événements qui peut être horodaté de manière fiable.
Si un nœud PoH rencontre des problèmes ou ne peut garantir sa disponibilité en ligne, ils ont proposé un plan permettant à plusieurs nœuds PoH de mélanger régulièrement leurs états.
Un ensemble de nœuds validateurs reproduira et validera les opérations des nœuds PoH (le processus de validation peut être parallélisé de manière plus efficace grâce à une architecture MapReduce). Ces validateurs atteignent un consensus via un protocole similaire à Casper utilisant PoS. Si un nœud PoH rencontre un problème byzantin ou un comportement inapproprié, 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.
Leur chiffre est complètement absurde. 71 000 TPS est tout simplement risible ; même le nombre de recherches par seconde de Google n'atteint pas 100 000. Cette donnée est placée à l'endroit le plus visible de leur site, ce qui me rend très méfiant.
Retirer l'évaluation précédente selon laquelle le livre blanc était bien écrit. 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 est décevante.
L'équipe est principalement composée d'ingénieurs de base de Qualcomm. Le CEO et le CTO se concentrent principalement sur les systèmes d'exploitation, les systèmes embarqués, l'optimisation des GPU et les compilateurs. Leur expérience en systèmes distribués et en cryptographie semble clairement insuffisante, ce qui est évident dans le document. Leur gestion des problèmes de tolérance aux pannes byzantines est médiocre. Cela me rappelle le livre blanc de Raiblocks/Nano (qui sont également des ingénieurs de base).
Et un contenu comme celui-ci dans le livre blanc me fait douter :
[Document blanc Solana, Section 5.12]
« 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 de PoH produit un flux de messages, tous les validateurs doivent soumettre leur signature sur l'état dans les 500 ms. Ce chiffre peut être réduit davantage en fonction des conditions du réseau. Étant donné que chaque validation est intégrée dans le flux, chacun dans le réseau peut vérifier si tous les validateurs ont soumis leur vote dans le délai imparti, sans avoir besoin d'observer directement le processus de vote. »
Ce n'est pas un protocole de consensus. Supposer que limiter à 500 ms dans la messagerie est un consensus est assez problématique, et il n'y a pas de mise en œuvre significative de la tolérance aux pannes byzantines. De plus, comment mesurent-ils les 500 ms ? Étant donné qu'ils estimeront le temps écoulé en fonction du nombre d'itérations de hachage exécutées, comment les autres nœuds du système parviennent-ils à un consensus sur l'écoulement de 500 ms ? En outre, comment vont-ils résoudre les écarts de vitesse d'horloge au fil du temps dus à des améliorations matérielles, des pannes matérielles ou des bruits ? Les problèmes de temps dans les systèmes distribués sont très complexes, et je pense qu'ils ne réalisent pas à quel point cela est difficile.
De plus, qui se soucie du temps ? Est-ce un grand 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 des choses comme DFINITY) ? Je ne pense pas que ce soit un problème, la complexité et le chaos qu'ils introduisent dans le protocole semblent ne pas apporter beaucoup de valeur.
Ils ont une section dédiée à la discussion des problèmes d'attaque et d'incitation désalignés. Leur réponse aux attaques est totalement peu convaincante et manque également de rigueur ou de détails.
Ils ont tout un chapitre consacré à la preuve de réplication, tout comme Filecoin. Que se passe-t-il ? Dites-moi votre protocole de consensus et comment vous réalisez des transactions et des comptes, quelles caractéristiques aura votre blockchain. Je ne me soucie pas de la preuve de stockage de données.
Il y a encore une longue section qui commence à décrire les contrats intelligents, mais elle ne dit que qu'ils utiliseront LLVM comme backend pour supporter plusieurs plateformes. Mais à part cela, rien d'autre n'est mentionné.
Beaucoup de contenu sur les GPU et la parallélisation. Cela révèle une étrange concentration - s'ils ont besoin de mettre en œuvre un protocole de consensus BFT et une plateforme de contrats intelligents disponible, ils ne devraient pas être obsédés par le traitement parallèle de leur format de paquet. Je me souviens qu'ils en ont également discuté dans la présentation que j'ai vue - ils ont passé la majeure partie de leur temps à discuter de l'optimisation du traitement par ces nœuds, et presque pas de temps à décrire réellement leur protocole de consensus.
Conclusion : Je ne vais absolument pas investir dans ce projet.
Il est intéressant de noter qu'après 5 ans, lorsque Haseeb a tweeté pour féliciter Solana d'avoir réussi à se faire une place dans le monde de la cryptographie et s'est moqué de son ancien moi immature qui a raté une grande opportunité, Toly, co-fondateur de Solana, a répondu à ce tweet : "Toutes tes préoccupations à l'époque étaient effectivement raisonnables. En essence, c'est un pari — parier sur notre capacité à résoudre tous ces problèmes tout en maintenant un avantage fondamental que les autres équipes n'ont pas."
Haseeb répondit alors à Toly : « Je pense que c’est la leçon. Votre dévouement à l’optimisation de bas niveau et aux angles d’attaque uniques est quelque chose qu’aucune autre équipe n’a. Ce genre de maximisation des forces et d’éviter les faiblesses est la chose la plus importante. Je ne m’en rendais pas compte du tout. ”