DUSKでも結局同じところに戻ってきてしまいます:
面白いのは、プライバシーという“物語”そのものではありません。
開発者向けドキュメントを開いて、「よし…実際にどうやってこれを作るの?」と聞いたときに起きることです。
選択肢は2つ。
DuskEVMは、いちばん安心できる道です。
Solidity、Foundry、Hardhat、ethers、viem――すでに多くのEthereum開発者が知っているツールです。
そして、もうひとつがDuskVM。
Rust、WASM、そして、チェーンとやり取りするためのよりネイティブな手段です。
この2つ目のルートは、まるで別物に感じられます。
プライバシーのラベルを貼った、馴染みのあるEVMに“デプロイする”だけではない。
DUSK自体の仕組みを学んでいくんです。
それが大事です。
W3sperは、アプリがRuskノードと通信し、チェーンデータを問い合わせ、アカウントの状態を扱い、コントラクトと連携し、WASMデータドライバで処理できるようにします。
Dusk Connectは、開発者を特定のウォレットに縛り付けずにウォレットを扱えます。
そして、抽象化が十分でなくなったら、さらに下に降りられます。
GraphQL。
Node API。
より生のトランザクションやコントラクトのフロー。
たいてい、それは良い兆候です。
なぜなら、どんな真剣な開発者も、最終的には“便利なラッパー”の限界にいつか当たるから。
コントラクトのライブラリも気になりました: アクセス制御、停止可能性(pausability)、リエントラント防止、タイムロック、リプレイ防護。
退屈な話。
でも、実際に必要になったときには。
それが、DUSKの開発者スタックについて私が好きなところです。
外から見て簡単そうに見えるためだけに作られている感じがしません。
“機械を理解したい”人のための、より深い層があります。
そして、たぶんここにある静かな賭けはこうです:
このスタックを理解できるだけの時間をかけて残る開発者は、他ではうまく表現しにくいものを作ってしまうかもしれない。
最高の開発者向け機能って、チュートリアルが役に立たなくなってから初めて気づくものだったりします。
#dusk $DUSK @Dusk
面白いのは、プライバシーという“物語”そのものではありません。
開発者向けドキュメントを開いて、「よし…実際にどうやってこれを作るの?」と聞いたときに起きることです。
選択肢は2つ。
DuskEVMは、いちばん安心できる道です。
Solidity、Foundry、Hardhat、ethers、viem――すでに多くのEthereum開発者が知っているツールです。
そして、もうひとつがDuskVM。
Rust、WASM、そして、チェーンとやり取りするためのよりネイティブな手段です。
この2つ目のルートは、まるで別物に感じられます。
プライバシーのラベルを貼った、馴染みのあるEVMに“デプロイする”だけではない。
DUSK自体の仕組みを学んでいくんです。
それが大事です。
W3sperは、アプリがRuskノードと通信し、チェーンデータを問い合わせ、アカウントの状態を扱い、コントラクトと連携し、WASMデータドライバで処理できるようにします。
Dusk Connectは、開発者を特定のウォレットに縛り付けずにウォレットを扱えます。
そして、抽象化が十分でなくなったら、さらに下に降りられます。
GraphQL。
Node API。
より生のトランザクションやコントラクトのフロー。
たいてい、それは良い兆候です。
なぜなら、どんな真剣な開発者も、最終的には“便利なラッパー”の限界にいつか当たるから。
コントラクトのライブラリも気になりました: アクセス制御、停止可能性(pausability)、リエントラント防止、タイムロック、リプレイ防護。
退屈な話。
でも、実際に必要になったときには。
それが、DUSKの開発者スタックについて私が好きなところです。
外から見て簡単そうに見えるためだけに作られている感じがしません。
“機械を理解したい”人のための、より深い層があります。
そして、たぶんここにある静かな賭けはこうです:
このスタックを理解できるだけの時間をかけて残る開発者は、他ではうまく表現しにくいものを作ってしまうかもしれない。
最高の開発者向け機能って、チュートリアルが役に立たなくなってから初めて気づくものだったりします。
#dusk $DUSK @Dusk
