Le fondateur d’Ethereum, V God, a proposé de remplacer « RISC-V » par Ethereum dans la couche d’exécution pour remplacer l’ancien EVM, ce qui a rendu certains développeurs méfiants, et en 2016, le développeur d’Ethereum, OG, a estimé que cela rendrait l’écosystème Ethereum confronté à une redistribution et serait très hostile aux petits projets d’investissement. (Synopsis : Les frais de gestion d’Ethereum ont atteint leur plus bas niveau en cinq ans, et la communauté a déclenché la « théorie du poison L2 » : il n’y a pas de voitures sur la route, et V God est toujours en train de rire et de construire des autoroutes) (Supplément de contexte : Démantèlement de l’ambition stratégique de Vitalik de reconstruire la couche exécutive d’Ethereum avec « RISC-V au lieu d’EVM ») La récente proposition « RISC-V » du fondateur d’Ethereum, V God, a attiré l’attention de la communauté crypto et a suscité un débat parmi les développeurs de l’écosystème principal, et pour la plupart des utilisateurs, la plupart d’entre eux ne peuvent pas comprendre RISC-V Comment réformer Ethereum, et quel genre de progrès la proposition de V-God peut-elle apporter à Ethereum ? Afin de répondre à cette question, nous avons interviewé un vieux « dragon anti-échelle » OG qui développe l’écologie de base d’Ethereum depuis 2016, et il répondra au processus détaillé de révision de « RISC-V » et aux effets négatifs à court terme qui pourraient survenir à l’avenir, rappelant à tous les investisseurs d’Ethereum de prêter une attention particulière au suivi de cette proposition. Comment réorganiser la situation RISC-V Ethereum est différent des autres chaînes PoS en ce sens que le client Ethereum est composé de deux parties, la « couche de consensus » et la « couche d’exécution », et la couche de consensus est responsable de l’empaquetage du vote de mise, et la couche d’exécution est responsable du traitement des transactions, de sorte que le code qui exécute le contrat intelligent est en fait un client de couche d’exécution exécuté par l’ordinateur du nœud, qui exécute le code en saisissant la diffusion de la transaction et écrit les résultats du vote via la « couche de consensus » sur le grand livre public. La seule façon de mettre à niveau l’environnement EVM actuel vers RISC-V est de mettre à jour le « client de couche d’exécution » du client de nœud, qui n’est qu’un fork au niveau logiciel, contrairement au hard fork habituel dans le passé pour modifier le bloc Ethereum et la révision de nœud correspondante. Selon la description du contenu de l’article de V God, idéalement, si tous les clients noeuds ont des exécuteurs RISC-V, alors le fonctionnement du protocole pour la nouvelle version et le fonctionnement de la preuve zk peuvent atteindre près de 100 fois l’efficacité théorique, mais il faut savoir que cela est calculé sur le contrat intelligent pour la version RISC-V et le client RISC-V, par rapport au format de contrat intelligent EVM exécuté sur le client EVM. Ce qui est spécial dans la proposition de RISC-V cette fois-ci, c’est qu’il est directement remanié sur le client de la couche exécutive et n’utilisera pas la partie hard fork, ce que je n’aime pas beaucoup, mais on peut voir qu’Ethereum se dirige dans une nouvelle direction, ce qui peut être un avantage à double tranchant, et ce niveau de changement dans le passé, Ethereum peut choisir d’être mis en œuvre avec un hard fork, car cela peut être une approche plus sûre. Correspondance entre la situation actuelle et l’ancien contrat Après avoir compris les performances de la théorie, regardons quelle est la situation actuelle, la situation actuelle est que toute l’écologie d’Ethereum et toutes les pratiques EIP sont exécutées avec succès via des contrats intelligents EVM et des clients EVM, si, comme V Dieu l’a dit, RISC-V aura un transpilateur EVM, alors la situation future réelle peut être divisée en les situations suivantes Les contrats intelligents EVM s’exécutent sur le client EVM (l’ancien EIP est entièrement compatible, mais le nouveau EIP doit correspondre à deux versions) Le contrat intelligent EVM s’exécute sur le client RISC-V via le transpilateur EVM de RISC-V (l’ancien et le nouveau EIP doivent passer par de nombreux tests et débogages pour être résolus) Le contrat intelligent RISC-V s’exécute sur le client RISC-V (l’ancien EIP sera tous retesté, mais le nouveau EIP devrait être parfaitement compatible) En résumé, compte tenu de la performance théorique de l’efficacité opérationnelle du futur contrat intelligent de 100 fois, seul le troisième état est applicable, et pour le second cas, En particulier, il s’appuie sur l’optimisation du transpilateur par l’équipe principale d’Ethereum, ainsi que sur toutes les mises à niveau EIP et les contrats intelligents dans le passé, ce qui signifie qu’Ethereum doit payer un prix d’optimisation très élevé afin d’obtenir une amélioration théorique des performances, et il n’est pas certain que l’optimisation de l’efficacité de l’ancien code EVM par traduction sur RISC-V soit définitivement supérieure à celle de l’environnement EVM natif. En fait, V God a dit ceci, je suppose qu’il doit y avoir beaucoup de développeurs de base qui se sentent très désespérés, dans le passé sur le développement EVM, de résoudre chaque implémentation et test EIP, la charge de travail est déjà très importante, car Ethereum est une communauté qui aime tester des réponses ouvertes dans un environnement très ouvert. Mais maintenant, quand il devient un environnement RISC-V, je pense juste à la période de test de transformation, qui est un très casse-tête, le problème principal est que vous ne pourrez peut-être pas exécuter plus de 1 ~ 5 fois plus efficace que l’environnement d’origine pendant la période de test, donc je suppose que cette période de test continuera à être prolongée plusieurs fois, tout comme Ethereum Merge dans le passé, de sorte qu’il y a un manque de résultats concrets au stade précoce, et il est difficile d’attirer des écosystèmes externes à déployer sur le testnet et à soumettre des commentaires. Tout ce que je peux dire, c’est que V God a de grandes ambitions, mais je ne pense pas que la mise en œuvre soit très optimiste, du moins je pense que plus de la moitié des développeurs principaux ne seront peut-être pas très heureux, s’ils sont déterminés à passer à RISC-V, V God et la Fondation Ethereum doivent consacrer beaucoup d’efforts à encourager l’équipe de développeurs de base et l’écologie. Le problème de la correspondance écologique avec RISC-V Le dragon a mentionné que le plus gros problème de la proposition RISC-V peut provenir du soutien et de la correspondance du projet privé écologie, dans l’écosystème open source existant, les composants qui peuvent être utilisés sont très limités, de sorte que le slogan de la traduction d’EVM à RISC-V proposé par V Dieu peut avoir beaucoup de doutes et de problèmes à court terme. Par exemple, l’écosystème existant d’Ethereum, tel que les projets EVM et les contrats qui n’ont aucun problème, sous la prémisse de la traduction EVM vers RISC-V, il peut y avoir un manque d’état ou une fin d’opérations dans le processus d’exécution du contrat au niveau de la couche d’exécution, ce qui signifie que même les anciens projets EVM qui n’ont eu aucun problème dans le passé, dans le cas de l’utilisation de la traduction EVM vers RISC-V, il peut y avoir des jetons qui ne peuvent pas être proposés, ou accidentellement brûlés ou verrouillés. Un tel exemple est très susceptible de rendre l’équipe du projet écologique, dans certains cas, réticente à ouvrir les utilisateurs à l’utilisation du transpiler EVM vers RISC-V pour exécuter des contrats intelligents EVM hérités ; De plus, afin d’éviter les risques associés et de suivre la nouvelle technologie d’Ethereum, la meilleure façon pour l’écosystème du projet est d’écrire une nouvelle version RISC-V du contrat pour tous les contrats intelligents, et la connexion entre l’ancien contrat et le nouveau contrat est résolue par le biais d’un pontage d’actifs. En fait, la façon de s’engager dans la compatibilité est très facile à emballer, mais si la fondation est prête à disperser de l’argent pour obtenir la solution générale, alors elle peut résoudre 99% des problèmes de compatibilité, mais le problème réside dans le 1% restant et la confiance de sécurité des développeurs écologiques. Maintenant, vous demandez aux développeurs du projet Ethereum, je suppose que je ne serai pas si confiant dans la partie de la traduction EVM RISC-V, les grandes entreprises technologiques du capital veulent appartenir à leurs propres systèmes ou puces personnalisés du début à la fin, ils ne choisiront pas nécessairement RISC-V, car bien que cette architecture soit open source, par rapport aux architectures grand public telles que ARM et X86, le support écologique RISC-V est très limité, et il n’y a pas de développement connexe de la blockchain, ce qui signifie qu’Ethereum doit ouvrir un monde à mains nues. Si vous êtes à l’examen...
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.
Ethereum "changer RISC-V" fait fuir les développeurs ? Avertissement OG : l'écosystème ETH sera redistribué, les petits projets quitteront Solana
Le fondateur d’Ethereum, V God, a proposé de remplacer « RISC-V » par Ethereum dans la couche d’exécution pour remplacer l’ancien EVM, ce qui a rendu certains développeurs méfiants, et en 2016, le développeur d’Ethereum, OG, a estimé que cela rendrait l’écosystème Ethereum confronté à une redistribution et serait très hostile aux petits projets d’investissement. (Synopsis : Les frais de gestion d’Ethereum ont atteint leur plus bas niveau en cinq ans, et la communauté a déclenché la « théorie du poison L2 » : il n’y a pas de voitures sur la route, et V God est toujours en train de rire et de construire des autoroutes) (Supplément de contexte : Démantèlement de l’ambition stratégique de Vitalik de reconstruire la couche exécutive d’Ethereum avec « RISC-V au lieu d’EVM ») La récente proposition « RISC-V » du fondateur d’Ethereum, V God, a attiré l’attention de la communauté crypto et a suscité un débat parmi les développeurs de l’écosystème principal, et pour la plupart des utilisateurs, la plupart d’entre eux ne peuvent pas comprendre RISC-V Comment réformer Ethereum, et quel genre de progrès la proposition de V-God peut-elle apporter à Ethereum ? Afin de répondre à cette question, nous avons interviewé un vieux « dragon anti-échelle » OG qui développe l’écologie de base d’Ethereum depuis 2016, et il répondra au processus détaillé de révision de « RISC-V » et aux effets négatifs à court terme qui pourraient survenir à l’avenir, rappelant à tous les investisseurs d’Ethereum de prêter une attention particulière au suivi de cette proposition. Comment réorganiser la situation RISC-V Ethereum est différent des autres chaînes PoS en ce sens que le client Ethereum est composé de deux parties, la « couche de consensus » et la « couche d’exécution », et la couche de consensus est responsable de l’empaquetage du vote de mise, et la couche d’exécution est responsable du traitement des transactions, de sorte que le code qui exécute le contrat intelligent est en fait un client de couche d’exécution exécuté par l’ordinateur du nœud, qui exécute le code en saisissant la diffusion de la transaction et écrit les résultats du vote via la « couche de consensus » sur le grand livre public. La seule façon de mettre à niveau l’environnement EVM actuel vers RISC-V est de mettre à jour le « client de couche d’exécution » du client de nœud, qui n’est qu’un fork au niveau logiciel, contrairement au hard fork habituel dans le passé pour modifier le bloc Ethereum et la révision de nœud correspondante. Selon la description du contenu de l’article de V God, idéalement, si tous les clients noeuds ont des exécuteurs RISC-V, alors le fonctionnement du protocole pour la nouvelle version et le fonctionnement de la preuve zk peuvent atteindre près de 100 fois l’efficacité théorique, mais il faut savoir que cela est calculé sur le contrat intelligent pour la version RISC-V et le client RISC-V, par rapport au format de contrat intelligent EVM exécuté sur le client EVM. Ce qui est spécial dans la proposition de RISC-V cette fois-ci, c’est qu’il est directement remanié sur le client de la couche exécutive et n’utilisera pas la partie hard fork, ce que je n’aime pas beaucoup, mais on peut voir qu’Ethereum se dirige dans une nouvelle direction, ce qui peut être un avantage à double tranchant, et ce niveau de changement dans le passé, Ethereum peut choisir d’être mis en œuvre avec un hard fork, car cela peut être une approche plus sûre. Correspondance entre la situation actuelle et l’ancien contrat Après avoir compris les performances de la théorie, regardons quelle est la situation actuelle, la situation actuelle est que toute l’écologie d’Ethereum et toutes les pratiques EIP sont exécutées avec succès via des contrats intelligents EVM et des clients EVM, si, comme V Dieu l’a dit, RISC-V aura un transpilateur EVM, alors la situation future réelle peut être divisée en les situations suivantes Les contrats intelligents EVM s’exécutent sur le client EVM (l’ancien EIP est entièrement compatible, mais le nouveau EIP doit correspondre à deux versions) Le contrat intelligent EVM s’exécute sur le client RISC-V via le transpilateur EVM de RISC-V (l’ancien et le nouveau EIP doivent passer par de nombreux tests et débogages pour être résolus) Le contrat intelligent RISC-V s’exécute sur le client RISC-V (l’ancien EIP sera tous retesté, mais le nouveau EIP devrait être parfaitement compatible) En résumé, compte tenu de la performance théorique de l’efficacité opérationnelle du futur contrat intelligent de 100 fois, seul le troisième état est applicable, et pour le second cas, En particulier, il s’appuie sur l’optimisation du transpilateur par l’équipe principale d’Ethereum, ainsi que sur toutes les mises à niveau EIP et les contrats intelligents dans le passé, ce qui signifie qu’Ethereum doit payer un prix d’optimisation très élevé afin d’obtenir une amélioration théorique des performances, et il n’est pas certain que l’optimisation de l’efficacité de l’ancien code EVM par traduction sur RISC-V soit définitivement supérieure à celle de l’environnement EVM natif. En fait, V God a dit ceci, je suppose qu’il doit y avoir beaucoup de développeurs de base qui se sentent très désespérés, dans le passé sur le développement EVM, de résoudre chaque implémentation et test EIP, la charge de travail est déjà très importante, car Ethereum est une communauté qui aime tester des réponses ouvertes dans un environnement très ouvert. Mais maintenant, quand il devient un environnement RISC-V, je pense juste à la période de test de transformation, qui est un très casse-tête, le problème principal est que vous ne pourrez peut-être pas exécuter plus de 1 ~ 5 fois plus efficace que l’environnement d’origine pendant la période de test, donc je suppose que cette période de test continuera à être prolongée plusieurs fois, tout comme Ethereum Merge dans le passé, de sorte qu’il y a un manque de résultats concrets au stade précoce, et il est difficile d’attirer des écosystèmes externes à déployer sur le testnet et à soumettre des commentaires. Tout ce que je peux dire, c’est que V God a de grandes ambitions, mais je ne pense pas que la mise en œuvre soit très optimiste, du moins je pense que plus de la moitié des développeurs principaux ne seront peut-être pas très heureux, s’ils sont déterminés à passer à RISC-V, V God et la Fondation Ethereum doivent consacrer beaucoup d’efforts à encourager l’équipe de développeurs de base et l’écologie. Le problème de la correspondance écologique avec RISC-V Le dragon a mentionné que le plus gros problème de la proposition RISC-V peut provenir du soutien et de la correspondance du projet privé écologie, dans l’écosystème open source existant, les composants qui peuvent être utilisés sont très limités, de sorte que le slogan de la traduction d’EVM à RISC-V proposé par V Dieu peut avoir beaucoup de doutes et de problèmes à court terme. Par exemple, l’écosystème existant d’Ethereum, tel que les projets EVM et les contrats qui n’ont aucun problème, sous la prémisse de la traduction EVM vers RISC-V, il peut y avoir un manque d’état ou une fin d’opérations dans le processus d’exécution du contrat au niveau de la couche d’exécution, ce qui signifie que même les anciens projets EVM qui n’ont eu aucun problème dans le passé, dans le cas de l’utilisation de la traduction EVM vers RISC-V, il peut y avoir des jetons qui ne peuvent pas être proposés, ou accidentellement brûlés ou verrouillés. Un tel exemple est très susceptible de rendre l’équipe du projet écologique, dans certains cas, réticente à ouvrir les utilisateurs à l’utilisation du transpiler EVM vers RISC-V pour exécuter des contrats intelligents EVM hérités ; De plus, afin d’éviter les risques associés et de suivre la nouvelle technologie d’Ethereum, la meilleure façon pour l’écosystème du projet est d’écrire une nouvelle version RISC-V du contrat pour tous les contrats intelligents, et la connexion entre l’ancien contrat et le nouveau contrat est résolue par le biais d’un pontage d’actifs. En fait, la façon de s’engager dans la compatibilité est très facile à emballer, mais si la fondation est prête à disperser de l’argent pour obtenir la solution générale, alors elle peut résoudre 99% des problèmes de compatibilité, mais le problème réside dans le 1% restant et la confiance de sécurité des développeurs écologiques. Maintenant, vous demandez aux développeurs du projet Ethereum, je suppose que je ne serai pas si confiant dans la partie de la traduction EVM RISC-V, les grandes entreprises technologiques du capital veulent appartenir à leurs propres systèmes ou puces personnalisés du début à la fin, ils ne choisiront pas nécessairement RISC-V, car bien que cette architecture soit open source, par rapport aux architectures grand public telles que ARM et X86, le support écologique RISC-V est très limité, et il n’y a pas de développement connexe de la blockchain, ce qui signifie qu’Ethereum doit ouvrir un monde à mains nues. Si vous êtes à l’examen...