イーサリアムの創設者であるVゴッドは、過去のEVMを置き換えるために実行層で「RISC-V」をイーサリアムに置き換えることを提案し、一部の開発者が疑念を抱かせ、2016年にイーサリアム開発者のOGは、これによりイーサリアムのエコシステムが再分配に直面し、小規模な資本プロジェクトにとって非常に不親切になると考えました。 (あらすじ:イーサリアムの手数料は5年ぶりの安値を記録し、コミュニティは「L2毒説」を唱えました:道路には車はなく、V神はまだ笑って高速道路を建設しています) (背景補足:イーサリアムのエグゼクティブレイヤーを「EVMの代わりにRISC-V」で再構築するというヴィタリックの戦略的野心を解体する) イーサリアムの創設者であるV God氏の最近の「RISC-V」提案は、暗号コミュニティの注目を集め、コアエコシステム開発者の間で議論を巻き起こしましたが、ほとんどのユーザーにとって、ほとんどのユーザーはRISC-Vを理解できません イーサリアムをどう改革するか、そしてV-Godの提案はイーサリアムにどのような進歩をもたらすことができるのか? この疑問に答えるために、2016年からイーサリアムのコアエコロジーを発展させてきた老OGの「アンチスケールドラゴン」にインタビューし、「RISC-V」改訂の詳細なプロセスと今後起こりうる短期的な悪影響に回答し、イーサリアム投資家の皆様にこの提案のフォローアップに細心の注意を払うよう注意喚起します。 RISC-Vの状況を刷新する方法 イーサリアムは他のPoSチェーンとは異なり、イーサリアムクライアントは「コンセンサスレイヤー」と「実行レイヤー」の2つの部分で構成されており、コンセンサスレイヤーはステーク投票のパッケージ化を担当し、実行レイヤーはトランザクションの処理を担当するため、スマートコントラクトを実行するコードは、実際にはノードコンピューターによって実行される実行レイヤークライアントであり、トランザクションブロードキャストを取得してコードを実行し、「コンセンサスレイヤー」を介して投票結果を公開台帳に書き込みます。 現在のEVM環境をRISC-Vにアップグレードする唯一の方法は、過去の通常のハードフォークとは異なり、ソフトウェアレベルのフォークであるノードクライアントの「実行層クライアント」を更新して、イーサリアムブロックと対応するノードリビジョンを変更することです。 V Godの論文の内容説明によると、理想的には、すべてのノードクライアントがRISC-V Executorを持っている場合、新しいバージョンのプロトコルの動作とzk証明の動作は理論上の100倍近くの効率を達成できますが、これはEVMクライアントで実行されるEVMスマートコントラクト形式に対して、RISC-VバージョンとRISC-Vクライアントのスマートコントラクトで計算されることを知っておく必要があります。 今回のRISC-Vの提案で特別なのは、エグゼクティブレイヤーのクライアントを直接刷新し、ハードフォークの部分を使わないという点で、私はあまり好きではありませんが、イーサリアムが新しい方向に進んでいることが分かり、それは諸刃の刃であり、過去のこのレベルの変化は、イーサリアムの方が安全なアプローチかもしれないので、ハードフォークで実装することを選択するかもしれません。 現在の状況と古い契約の対応 理論のパフォーマンスを理解した後、現在の状況を見てみましょう、現在の状況は、イーサリアムのエコロジーとすべてのEIPプラクティスがEVMスマートコントラクトとEVMクライアントを通じて正常に実行されているということです。 V GodがRISC-VにEVMトランスパイラを持つと言ったように、実際の将来の状況は、次の状況に分けることができます EVMスマートコントラクトはEVMクライアント上で実行されます(古いEIPは完全に互換性がありますが、新しいEIPは2つのバージョンに対応する必要があります) EVMスマートコントラクトは、RISC-VのEVMトランスパイラを介してRISC-Vクライアント上で実行されます(新旧のEIPは、解決するために多くのテストとデバッグを経る必要があります) RISC-VスマートコントラクトはRISC-Vクライアント上で実行されます(古いEIPはすべて再テストされますが、新しいEIPは完全に互換性があるはずです) 要約すると、将来のスマートコントラクトの運用効率の理論上のパフォーマンスを100倍にすると、3番目の状態のみが適用され、2番目のケースでは、 特に、イーサリアムのコアチームによるトランスパイラの最適化や、過去のすべてのEIPアップグレードやスマートコントラクトに依存しているため、イーサリアムは理論的なパフォーマンス向上を達成するために非常に大きな最適化価格を支払う必要があり、RISC-Vでの変換による古いEVMコードの効率最適化がネイティブEVM環境の効率最適化よりも確実に優れているかどうかは不確かです。 実際、V神はこれを言いました、私は多くのコア開発者が非常に必死に感じているに違いないと思います、過去にEVM開発で、各EIPの実装とテストを解決するために、ワークロードはすでに非常に大きいです、なぜならイーサリアムは非常にオープンな環境でオープンな答えをテストするのが好きなコミュニティだからです。 しかし、今、RISC-V環境になると、変換のテスト期間について考えるだけで、非常に頭痛の種であり、核心的な問題は、テスト期間中に元の環境よりも1~5倍以上効率的に実行できない可能性があることであり、このテスト期間は、過去のEthereum Mergeのように何度も延長され続けるため、初期段階では具体的な結果が不足しており、テストネットにデプロイしてフィードバックを提出する外部エコシステムを誘致することが難しいと思います。 Vゴッドは大きな野心を持っているとしか言えませんが、実装はあまり楽観的ではないと思います、少なくともコア開発者の半分以上はあまり幸せではないかもしれないと思います、彼らがRISC-Vに変わることを決意した場合、V Godとイーサリアム財団はコア開発者チームとエコロジーを奨励するために多くの努力を費やす必要があります。 RISC-Vへの生態学的対応の問題ドラゴンは、RISC-V提案の最大の問題は、既存のオープンソースエコシステムでは、使用できるコンポーネントが非常に限られているため、V Godによって提案されたEVMからRISC-Vへの変換のスローガンは、短期的には多くの疑問と問題を抱えている可能性があると述べました。 例えば、問題のないEVMプロジェクトやコントラクトなど、イーサリアムの既存のエコシステムでは、EVMからRISC-Vへの変換を前提に、実行レイヤーでコントラクトを履行する過程で状態が欠如していたり、運用が終了していたりする可能性があり、つまり、過去に問題がなかった古いEVMプロジェクトでも、EVMからRISC-Vへの変換を利用した場合、提案できないトークンがあったり、誤ってバーンしたりロックされたりする可能性があります。 このような例では、エコロジカル・プロジェクト・チームは、場合によっては、EVMからRISC-Vへのトランスパイラを使用してレガシーEVMスマートコントラクトを実行するためにユーザーを開放することを望まなくなる可能性が非常に高いです。 さらに、関連するリスクを回避し、イーサリアムの新しいテクノロジーをフォローアップするために、プロジェクトエコシステムにとって最善の方法は、すべてのスマートコントラクトに対して新しいRISC-Vバージョンのコントラクトを作成することであり、古いコントラクトと新しいコントラクトの間の接続はアセットブリッジングによって解決されます。 実際、互換性に取り組む方法は非常に簡単にパッケージ化できますが、財団が一般的な解決策を得るためにお金をばら撒くことをいとわない場合、互換性の問題の99%は解決するかもしれませんが、問題は残りの1%とエコロジカル開発者のセキュリティ信頼にあります。 今、あなたはイーサリアムのプロジェクト開発者に尋ねます、私はEVM翻訳RISC-Vの部分にそれほど自信がないと思います、大資本のテクノロジー企業は最初から最後まで独自のカスタムシステムまたはチップに属したいと思っています、彼らは必ずしもRISC-Vを選択しません、なぜならこのアーキテクチャはオープンソースですが、ARMやX86などの主流のアーキテクチャと比較して、RISC-Vの生態学的サポートは非常に限られており、ブロックチェーンの関連する開発はないため、イーサリアムは素手で世界を開拓しなければならないことを意味します。 試験中の場合...
223k 投稿
188k 投稿
141k 投稿
79k 投稿
66k 投稿
62k 投稿
60k 投稿
57k 投稿
52k 投稿
51k 投稿
イーサリアム「改 RISC-V」が開発者を驚かせる？OGの警告：ETHエコシステムが再分配され、小規模プロジェクトがソラナに移行する可能性がある。
イーサリアムの創設者であるVゴッドは、過去のEVMを置き換えるために実行層で「RISC-V」をイーサリアムに置き換えることを提案し、一部の開発者が疑念を抱かせ、2016年にイーサリアム開発者のOGは、これによりイーサリアムのエコシステムが再分配に直面し、小規模な資本プロジェクトにとって非常に不親切になると考えました。 (あらすじ:イーサリアムの手数料は5年ぶりの安値を記録し、コミュニティは「L2毒説」を唱えました:道路には車はなく、V神はまだ笑って高速道路を建設しています) (背景補足:イーサリアムのエグゼクティブレイヤーを「EVMの代わりにRISC-V」で再構築するというヴィタリックの戦略的野心を解体する) イーサリアムの創設者であるV God氏の最近の「RISC-V」提案は、暗号コミュニティの注目を集め、コアエコシステム開発者の間で議論を巻き起こしましたが、ほとんどのユーザーにとって、ほとんどのユーザーはRISC-Vを理解できません イーサリアムをどう改革するか、そしてV-Godの提案はイーサリアムにどのような進歩をもたらすことができるのか? この疑問に答えるために、2016年からイーサリアムのコアエコロジーを発展させてきた老OGの「アンチスケールドラゴン」にインタビューし、「RISC-V」改訂の詳細なプロセスと今後起こりうる短期的な悪影響に回答し、イーサリアム投資家の皆様にこの提案のフォローアップに細心の注意を払うよう注意喚起します。 RISC-Vの状況を刷新する方法 イーサリアムは他のPoSチェーンとは異なり、イーサリアムクライアントは「コンセンサスレイヤー」と「実行レイヤー」の2つの部分で構成されており、コンセンサスレイヤーはステーク投票のパッケージ化を担当し、実行レイヤーはトランザクションの処理を担当するため、スマートコントラクトを実行するコードは、実際にはノードコンピューターによって実行される実行レイヤークライアントであり、トランザクションブロードキャストを取得してコードを実行し、「コンセンサスレイヤー」を介して投票結果を公開台帳に書き込みます。 現在のEVM環境をRISC-Vにアップグレードする唯一の方法は、過去の通常のハードフォークとは異なり、ソフトウェアレベルのフォークであるノードクライアントの「実行層クライアント」を更新して、イーサリアムブロックと対応するノードリビジョンを変更することです。 V Godの論文の内容説明によると、理想的には、すべてのノードクライアントがRISC-V Executorを持っている場合、新しいバージョンのプロトコルの動作とzk証明の動作は理論上の100倍近くの効率を達成できますが、これはEVMクライアントで実行されるEVMスマートコントラクト形式に対して、RISC-VバージョンとRISC-Vクライアントのスマートコントラクトで計算されることを知っておく必要があります。 今回のRISC-Vの提案で特別なのは、エグゼクティブレイヤーのクライアントを直接刷新し、ハードフォークの部分を使わないという点で、私はあまり好きではありませんが、イーサリアムが新しい方向に進んでいることが分かり、それは諸刃の刃であり、過去のこのレベルの変化は、イーサリアムの方が安全なアプローチかもしれないので、ハードフォークで実装することを選択するかもしれません。 現在の状況と古い契約の対応 理論のパフォーマンスを理解した後、現在の状況を見てみましょう、現在の状況は、イーサリアムのエコロジーとすべてのEIPプラクティスがEVMスマートコントラクトとEVMクライアントを通じて正常に実行されているということです。 V GodがRISC-VにEVMトランスパイラを持つと言ったように、実際の将来の状況は、次の状況に分けることができます EVMスマートコントラクトはEVMクライアント上で実行されます(古いEIPは完全に互換性がありますが、新しいEIPは2つのバージョンに対応する必要があります) EVMスマートコントラクトは、RISC-VのEVMトランスパイラを介してRISC-Vクライアント上で実行されます(新旧のEIPは、解決するために多くのテストとデバッグを経る必要があります) RISC-VスマートコントラクトはRISC-Vクライアント上で実行されます(古いEIPはすべて再テストされますが、新しいEIPは完全に互換性があるはずです) 要約すると、将来のスマートコントラクトの運用効率の理論上のパフォーマンスを100倍にすると、3番目の状態のみが適用され、2番目のケースでは、 特に、イーサリアムのコアチームによるトランスパイラの最適化や、過去のすべてのEIPアップグレードやスマートコントラクトに依存しているため、イーサリアムは理論的なパフォーマンス向上を達成するために非常に大きな最適化価格を支払う必要があり、RISC-Vでの変換による古いEVMコードの効率最適化がネイティブEVM環境の効率最適化よりも確実に優れているかどうかは不確かです。 実際、V神はこれを言いました、私は多くのコア開発者が非常に必死に感じているに違いないと思います、過去にEVM開発で、各EIPの実装とテストを解決するために、ワークロードはすでに非常に大きいです、なぜならイーサリアムは非常にオープンな環境でオープンな答えをテストするのが好きなコミュニティだからです。 しかし、今、RISC-V環境になると、変換のテスト期間について考えるだけで、非常に頭痛の種であり、核心的な問題は、テスト期間中に元の環境よりも1~5倍以上効率的に実行できない可能性があることであり、このテスト期間は、過去のEthereum Mergeのように何度も延長され続けるため、初期段階では具体的な結果が不足しており、テストネットにデプロイしてフィードバックを提出する外部エコシステムを誘致することが難しいと思います。 Vゴッドは大きな野心を持っているとしか言えませんが、実装はあまり楽観的ではないと思います、少なくともコア開発者の半分以上はあまり幸せではないかもしれないと思います、彼らがRISC-Vに変わることを決意した場合、V Godとイーサリアム財団はコア開発者チームとエコロジーを奨励するために多くの努力を費やす必要があります。 RISC-Vへの生態学的対応の問題ドラゴンは、RISC-V提案の最大の問題は、既存のオープンソースエコシステムでは、使用できるコンポーネントが非常に限られているため、V Godによって提案されたEVMからRISC-Vへの変換のスローガンは、短期的には多くの疑問と問題を抱えている可能性があると述べました。 例えば、問題のないEVMプロジェクトやコントラクトなど、イーサリアムの既存のエコシステムでは、EVMからRISC-Vへの変換を前提に、実行レイヤーでコントラクトを履行する過程で状態が欠如していたり、運用が終了していたりする可能性があり、つまり、過去に問題がなかった古いEVMプロジェクトでも、EVMからRISC-Vへの変換を利用した場合、提案できないトークンがあったり、誤ってバーンしたりロックされたりする可能性があります。 このような例では、エコロジカル・プロジェクト・チームは、場合によっては、EVMからRISC-Vへのトランスパイラを使用してレガシーEVMスマートコントラクトを実行するためにユーザーを開放することを望まなくなる可能性が非常に高いです。 さらに、関連するリスクを回避し、イーサリアムの新しいテクノロジーをフォローアップするために、プロジェクトエコシステムにとって最善の方法は、すべてのスマートコントラクトに対して新しいRISC-Vバージョンのコントラクトを作成することであり、古いコントラクトと新しいコントラクトの間の接続はアセットブリッジングによって解決されます。 実際、互換性に取り組む方法は非常に簡単にパッケージ化できますが、財団が一般的な解決策を得るためにお金をばら撒くことをいとわない場合、互換性の問題の99%は解決するかもしれませんが、問題は残りの1%とエコロジカル開発者のセキュリティ信頼にあります。 今、あなたはイーサリアムのプロジェクト開発者に尋ねます、私はEVM翻訳RISC-Vの部分にそれほど自信がないと思います、大資本のテクノロジー企業は最初から最後まで独自のカスタムシステムまたはチップに属したいと思っています、彼らは必ずしもRISC-Vを選択しません、なぜならこのアーキテクチャはオープンソースですが、ARMやX86などの主流のアーキテクチャと比較して、RISC-Vの生態学的サポートは非常に限られており、ブロックチェーンの関連する開発はないため、イーサリアムは素手で世界を開拓しなければならないことを意味します。 試験中の場合...