ニュース暗号資産開発者が指摘するWeb3の使いやすさと普及に必要な主要改善点

開発者が指摘するWeb3の使いやすさと普及に必要な主要改善点

著者: Blocktelegraph·

重要ポイント

  • •アプリケーションやウォレットは、取引承認前に権限、リスクにさらされる資産、取り消し可能性を平易な言葉で説明することで、ユーザーリスクを軽減できる可能性がある。
  • •開発者は、チームやユーザーがアプリケーションレベルで低レベルのブロックチェーンインフラを管理しなくて済むよう、より高い抽象化レイヤーを求めている。
  • •ステーブルトークンでの支払い、またはアプリケーションによる費用負担を含む予測可能で上限のある手数料モデルは、ユーザーや企業がWeb3利用を計画しやすくする可能性がある。
  • •クロスチェーンのメッセージ、資産、アカウントモデルに関するオープン標準は、ブリッジ障害を減らし、相互運用性を高める方法と見なされている。
  • •デフォルトのプライバシーツール、後方互換性のあるアップグレード、より速いファイナリティは、より安全で使いやすいWeb3システムに向けた技術的優先事項として挙げられている。
開発者が指摘するWeb3の使いやすさと普及に必要な主要改善点

Web3開発は、普及を遅らせ、実装を難しくする持続的な障害に直面し続けている。この分野で活動する開発者や実務者は、より明確な取引リスクの開示、抽象化レイヤーの高度化、顧客ニーズへのより強い注力、予測可能な手数料、より速いファイナリティ、クロスチェーン標準、デフォルトのプライバシー、より安全なアップグレード手順など、技術とユーザー体験の改善が必要な複数の領域を挙げている。

これらの提言は、ユーザーや企業がウォレット、ブリッジ、ガス手数料、暗号技術上の処理、コンセンサスメカニズム、ブロックチェーンインフラの複雑さをすべて理解しなくてもWeb3を使いやすくすることに重点を置いている。この点が重要なのは、多くのWeb3システムが、ユーザーが日常的な操作を完了しようとしているまさにその瞬間に、取り消し不能または技術的に複雑な判断を求めているためだ。

平易な取引コンテキストでリスクを明確化する

提案されている変更の1つは、ユーザーにリスクを説明する際のデフォルトの開発者体験を改善することだ。Web3チームはウォレット、ブリッジ、インセンティブ、プロトコルの仕組みに多くの注意を向ける一方で、一般的なユーザーはいまだに分かりにくいプロンプトに直面し、どの操作が安全なのかを判断しなければならない。

重要な改善策は、アプリケーションやウォレットに、人間が理解しやすい取引コンテキストを直接組み込むことだ。「approve」や「sign」だけを表示するのではなく、どの権限が付与されるのか、どの資産がリスクにさらされるのか、その操作は取り消せるのか、なぜアプリケーションがそれを求めているのかを、平易な言葉で説明できるようにする。

この種の明確さは日常的なものに見えるかもしれないが、その日常的な明確さこそがこの分野に必要だという主張である。ChainClarityでは、暗号資産関連のホワイトペーパーを平易な英語に翻訳する業務を通じて、業界全体に同様の問題があることが浮き彫りになっている。技術に詳しいユーザーはシステムを理解し、一般ユーザーはマーケティングを理解するが、その間に危険な隔たりが存在している。

Web3がより広範に普及するには、理解を任意のものとして扱うことはできない。自分が行っている操作を理解しているユーザーは、詐欺に遭う可能性が低く、悪い体験をカテゴリー全体のせいにする可能性も低く、再び利用する可能性が高い。

Web3の抽象化レイヤーを引き上げる

別の提案は、バックエンドにおける暗号技術上の処理の複雑さを、フロントエンドのユーザー体験から切り離す標準的な抽象化レイヤーを整備することだ。Web3はしばしばインターネットの第3の進化形と説明されるが、その開発環境では、多くのチームが依然としてアプリケーション層で低レベルのインフラ課題を管理する必要がある。

開発者は、ウォレット統合、ガス手数料、ノード同期、その他インフラエンジニアリングに近い技術的課題に頻繁に対応しなければならない。多くのプロジェクトのアーキテクチャにおいて、問題は必ずしもブロックチェーン技術そのものの失敗ではない。むしろ、ブロックチェーン台帳と従来型の企業ソフトウェアとの接続が脆弱すぎる点にある。

比較対象となるのは、業界がかつて生のサーバー管理からクラウドベースのホスティングプラットフォームの利用へ移行した過程だ。Web3インフラも同様の成熟度に達する必要がある。分散システムのユーザーが、ログインや資産の検証のためだけに取引がどのように実行されるかを理解しなければならないのであれば、そのユーザー体験はすでに失敗している。

分散型バックエンドが、クラウドデータベースAPIと同じようにエンドユーザーから見て不透明な存在になるまでは、企業による採用は構造的な解決策の反映ではなく、実験的なものにとどまる可能性がある。目標は、企業が基盤インフラの管理責任を追加で負うことなく、調整に関する課題を解決できるようにすることだ。

顧客ニーズから始める

一部の開発者は、多くのWeb3プロジェクトがいまだに「どのブロックチェーンを使うべきか」という誤った問いから始まっていると指摘する。Zibtekでは、チームがそうした議論に参加してきたが、それは多くの場合、出発点として適切ではないと分かっている。

より優れたプロジェクトは、全員が理解している顧客の課題から始まった。その課題が明確になれば、技術選択の議論ははるかに小さなものになる。フレームワーク、チェーン、ウォレット統合に早い段階で注力しすぎるチームは、実際の顧客フィードバックを集めるのに十分なものを作る前に、何週間も失う可能性がある。

その遅れは高くつき、製品を前進させない。最も速く進展したチームは、必ずしも最新技術を使っていたチームではなかった。早い段階で動作するソフトウェアをユーザーの前に出し、そのフィードバックによって次の判断を形作ったチームだった。

手数料を予測可能かつ上限付きにする

不確実なガスコストは、計画と利用の双方を難しくする。上限があり予測可能な手数料モデルは、アプリケーションとユーザーの双方に明確な限度を設定する。価格急騰を平準化する基本手数料に、スポンサー負担モデルやサブスクリプションを組み合わせることで、コストの安定に役立つ可能性がある。

手数料をステーブルトークンで支払えるようにしたり、アプリケーション自体が負担したりできれば、取引の流れはより単純で理解しやすくなる。ウォレット内で価格を明確に表示することも、信頼の構築と想定外の高額感の軽減に役立つ。企業にとっても、予測可能な取引コストは運用費のモデル化を容易にし、突然の手数料がユーザー体験を損なう顧客向け製品を支えやすくする。

開発者は、コストを安定的で予測可能かつ上限付きにする手数料ルールとツールを求めている。

ほぼ即時のファイナリティを確保する

遅い、または弱いファイナリティは、金融取引のリスクを高める可能性がある。改善されたコンセンサスメカニズムと共有シーケンサーは、多くのバリデーターがチェーンを確認し続けながら、より速い承認を可能にする可能性がある。不正証明とライトクライアントは、中央の管理者に依存せずに無効なブロックを特定するのに役立つ。

シングルスロットまたはほぼ即時のファイナリティには、強力なスラッシング規則と再編成に関する明確な制限も組み合わせるべきだ。研究は、遅延やロールバックを引き起こす可能性のあるMEV関連の挙動にも対処する必要がある。より広い目的は、権力の分散を維持しながら速度を高める設計を支えることだ。

オープン標準でチェーンを統合する

Web3には、チェーン同士が通信し連携するための共通の方法も必要だ。メッセージ、資産、アカウントモデルに関する普遍的な標準は、ブリッジに関連するハッキングや障害を減らす可能性がある。共有されたセキュリティルールと明確な障害領域は、チェーン間の移動をより安全にする。

SDK、テストスイート、ファザーなどのツールは、アプリケーションがより迅速にローンチできるよう、標準とともに提供されるべきだ。ユーザーにとっては、分断された個別のサイロ環境ではなく、より滑らかな体験につながる。開発者は、オープンなクロスチェーン標準の策定と採用を業界に促している。

デフォルトで使いやすいプライバシーを実現する

パブリックブロックチェーンは、ユーザーデータを大量に露出させる。組み込みのゼロ知識ツールは、必要なルールが守られたことを証明しながら、取引額や関連性を隠すことができる。選択的開示キーにより、ユーザーはすべての詳細を明かすことなく、監査人に特定の事実を示すことができる。

プライベートなスマートコントラクトには、シンプルなウォレット、スマートフォン上での高速な証明、安全な復旧手段も必要だ。デフォルトのプライバシーは、データスクレイピングを抑制し、通常の利用を保護するのに役立つ。アプリケーション全体で使いやすくデフォルトで有効なプライバシーを構築するチームへの支持が広がっている。

安全で後方互換性のあるアップグレードを確立する

アップグレードは、アプリケーションを壊し、コミュニティを分断する可能性がある。より強固なガバナンスとアップグレードプロセスは、新しいバージョンを導入しながら既存のコントラクトを保護すべきだ。バージョン管理されたコード、機能フラグ、オプトイン方式のモジュールにより、アプリケーションはそれぞれのペースで移行できる。

明確な社会的ルール、監査、チェックを伴う緊急停止措置は、まれな危機への対応に役立つ。公開テスト実行と形式的証明は、メインネットへの展開前にエラーを特定できる。開発者は、安全で後方互換性のある変更を確立し採用しやすくする枠組みを求めている。