#dusk $DUSK @Dusk 最初、私はEVM互換性をチェックボックスのように扱っていました。
あるチェーンがSolidityに対応していれば、開発者は来てくれる。簡単ですよね?
でも、DuskEVMをもう少し詳しく見てみると、その前提は少し浅すぎる気がしてきました。
本当に重要なのは、開発者が移行したあとに何を持ち続けられるかです。
DuskEVMなら、Solidityと馴染みのあるEVMツールを使って、EVM同等の環境で開発できます。つまり、これは単に別の実行環境を追加する話ではありません。開発者がすでに知っていることと、Duskが作っているものとの距離を縮めることが目的なのです。
その点に私は惹かれました。
開発者にまったく新しいスタックを学ばせるのは一つの話です。しかし、馴染みのスマートコントラクトのワークフローを、別のブロックチェーン・アーキテクチャへ持ち込めるようにするのは、別の話です。
そしてDuskDSもあります。
DuskEVMが実行を担当し、DuskDSがその下で決済とデータ可用性の基盤を提供します。さらにDuskVMという別の実行経路もあり、Rust/WASMのコントラクトをDusk L1上で直接動かします。
そこで私は考え始めました:
異なる実行環境が同じ決済基盤に依存できるのなら、全体のアーキテクチャはより柔軟になるのでしょうか?
たぶん。
でも、EVM互換性だけでは何も証明できないと思います。
本当の試金石は、開発者が到着したあとに何が起きるかです。実際に作るのか? ツールは使い心地が十分なのか? 実行と決済が分離されることで、アプリケーションは恩恵を受けるのか?
私は今、まさにそれを見ていきたいと思っています。
新興のLayer 1にとって、Solidityをサポートするだけで開発者を惹きつけるのに十分なのでしょうか。それとも、本格的に人々が作り始めたところからが本当の試験ではないでしょうか?
@Dusk $DUSK
#Dusk #DuskEVM
あるチェーンがSolidityに対応していれば、開発者は来てくれる。簡単ですよね?
でも、DuskEVMをもう少し詳しく見てみると、その前提は少し浅すぎる気がしてきました。
本当に重要なのは、開発者が移行したあとに何を持ち続けられるかです。
DuskEVMなら、Solidityと馴染みのあるEVMツールを使って、EVM同等の環境で開発できます。つまり、これは単に別の実行環境を追加する話ではありません。開発者がすでに知っていることと、Duskが作っているものとの距離を縮めることが目的なのです。
その点に私は惹かれました。
開発者にまったく新しいスタックを学ばせるのは一つの話です。しかし、馴染みのスマートコントラクトのワークフローを、別のブロックチェーン・アーキテクチャへ持ち込めるようにするのは、別の話です。
そしてDuskDSもあります。
DuskEVMが実行を担当し、DuskDSがその下で決済とデータ可用性の基盤を提供します。さらにDuskVMという別の実行経路もあり、Rust/WASMのコントラクトをDusk L1上で直接動かします。
そこで私は考え始めました:
異なる実行環境が同じ決済基盤に依存できるのなら、全体のアーキテクチャはより柔軟になるのでしょうか?
たぶん。
でも、EVM互換性だけでは何も証明できないと思います。
本当の試金石は、開発者が到着したあとに何が起きるかです。実際に作るのか? ツールは使い心地が十分なのか? 実行と決済が分離されることで、アプリケーションは恩恵を受けるのか?
私は今、まさにそれを見ていきたいと思っています。
新興のLayer 1にとって、Solidityをサポートするだけで開発者を惹きつけるのに十分なのでしょうか。それとも、本格的に人々が作り始めたところからが本当の試験ではないでしょうか?
@Dusk $DUSK
#Dusk #DuskEVM
