先日、Dusk Connect SDK のメモを読み返していたら、ひとつ気になって仕方ないことがありました。実際のスローダウンはほとんどの場合、コアプロトコルの中には収まりません。問題は、良いアイデアと「実際に動くもの」の間にある、あの静かなギャップに潜んでいます。
SDK は、ウォレット接続やトランザクション処理をあらゆるチームの手から取り上げて、ひとつの場所に集約するはずです。多くの人はそれを、単なる便利さだと捉えます。でも私は違います。カスタム版は結局、それぞれが小さなバグを抱え、別々の権限プロンプトになり、そして特に「シールドされた経路」と「公開経路」の両方が正しく動く必要があるとき、些細に見えて重要なセキュリティの隙間が生まれがちです。共有 SDK は、ひとりで作ってしまったときに多くのチームがミスしやすい部分を処理することで、その露出面を減らすべきです。
だから本当の問いは、SDK が存在するかどうかではありません。それが実際に取り除く、脆いパーツがどれだけあるのか――接続フロー、サイニング、権限の一貫性、そしてパブリックとプライベートの分割です。そこがきれいに保たれていれば、新しいアプリが壊れる余地は小さくなります。もし中途半端に残っていれば、結局チームは難しい部分を自分たちで書くことになります。
私はまだ、それがさまざまな種類のアプリでどれほど安定して機能するのか分かっていません。単純な送金はそのひとつです。混在したプライバシーを含む、より長い組織的なフローは別です。きちんとしたローンチ後の記事なら完成して見えることもある。ですが、本当に独立して使ってみると、偽物にしにくい部分があります。
私の静かな疑いはこれです。コアの外のチームが、実際にもっと多くのものをそれで出してくるまでは、私たちは「導入されたか」よりも「発表されたか」を測ってしまっている、ということ。
#dusk $DUSK @Dusk
Dusk Connect のような SDK にとって、もっとも重要なのは何ですか?
SDK は、ウォレット接続やトランザクション処理をあらゆるチームの手から取り上げて、ひとつの場所に集約するはずです。多くの人はそれを、単なる便利さだと捉えます。でも私は違います。カスタム版は結局、それぞれが小さなバグを抱え、別々の権限プロンプトになり、そして特に「シールドされた経路」と「公開経路」の両方が正しく動く必要があるとき、些細に見えて重要なセキュリティの隙間が生まれがちです。共有 SDK は、ひとりで作ってしまったときに多くのチームがミスしやすい部分を処理することで、その露出面を減らすべきです。
だから本当の問いは、SDK が存在するかどうかではありません。それが実際に取り除く、脆いパーツがどれだけあるのか――接続フロー、サイニング、権限の一貫性、そしてパブリックとプライベートの分割です。そこがきれいに保たれていれば、新しいアプリが壊れる余地は小さくなります。もし中途半端に残っていれば、結局チームは難しい部分を自分たちで書くことになります。
私はまだ、それがさまざまな種類のアプリでどれほど安定して機能するのか分かっていません。単純な送金はそのひとつです。混在したプライバシーを含む、より長い組織的なフローは別です。きちんとしたローンチ後の記事なら完成して見えることもある。ですが、本当に独立して使ってみると、偽物にしにくい部分があります。
私の静かな疑いはこれです。コアの外のチームが、実際にもっと多くのものをそれで出してくるまでは、私たちは「導入されたか」よりも「発表されたか」を測ってしまっている、ということ。
#dusk $DUSK @Dusk
Dusk Connect のような SDK にとって、もっとも重要なのは何ですか?
Easy integration
100%
Security consistency
0%
Privacy handling
0%
Real developer adoption
0%
1 投票 • 投票は終了しました