現在の Web3 と DeFi は、主流のユーザーにとっては準備ができていません。暗号通貨の専門家でない人にとって、それはあまりにも混乱し、リスクがあり、費用がかかるものです。 明らかに修正が必要な点がいくつかあります。 そして、アカウントを安全にバックアップするために長いシードフレーズを管理するというクレイジーな要件もあります。しかし、あまり注目されていないもう 1 つの大きな障壁があります。 。 恐ろしい開発者エクスペリエンス トランザクションには意味がなく、ユーザーや開発者がこの非常に新しいテクノロジーを自信を持って使用するために必要な制御が与えられません 問題はウォレット UI の 1 つだけではありません。実際、これは主に L-1 プラットフォーム自体のアーキテクチャに問題があります。今日のトランザクションは、日々やり取りする開発者やユーザーのニーズや期待によって定義されるのではなく、テクノロジーの前提によって制限される形で定義されています。どのウォレットもこれらの制限を回避することはできません。 だからこそ、Radix はトランザクションの概念をゼロから再定義する必要がありました。 。 完全なテクノロジースタック その結果は、Radixの最も強力な利点の1つであり、安全でないウォレットのユーザーエクスペリエンス、困難なdAppの相互運用性、サンドイッチ取引、委任された手数料の支払いの不可能性など、驚くほど広範囲の重要なDeFiの問題を修正します。また、Radix Wallet は次のように、完全にトラストレスでユーザーにトランザクションを提示できます。  しかし、Radix のソリューションに入る前に、今日のトランザクションがなぜこれほど徹底的な見直しを必要としているのかについて話しましょう。 トランザクションには何が含まれますか? トランザクションの問題がどれほど深刻であるかを理解するには、 について話す必要があります。 ブロックチェーン トランザクションが実際に何であるか 今日のスマート コントラクト ブロックチェーン上のトランザクションの内容は、テクノロジーによって大きく左右されます。ほとんどのスマート コントラクト ネットワークでは、dApp ロジックだけでなく、 スマート コントラクトです。 。このモデルの制約内では、トランザクションが として定義されることは驚くべきことではありません。 すべてが 資産そのものの定義 スマート コントラクトの呼び出し これは、これらのネットワークでは、トランザクションの主要部分は基本的に、単一のスマート コントラクトに送信されるメッセージであり、何をすべきかを指示するために必要なデータがすべて含まれていることを意味します。 スマート コントラクトがそのメッセージを受信すると、自身の内部データに何らかの変更を加える可能性があり、舞台裏で スマート コントラクト (ERC-20 トークン スマート コントラクトなど) を呼び出し、 内部データに何らかの変更を加える可能性があります。 他の その そのトランザクションの結果として起こるあらゆることは、スマート コントラクトへの 1 つのメッセージによって開始される必要があります。 トランザクションをネットワークに送信するには、もう少し時間がかかります。スマート コントラクトの呼び出しは、「呼び出し元」としての 1 つのアカウントの秘密キーによって署名され、その呼び出し元は、ネットワーク料金 (または「ガス」) としてそのアカウントからいくら使うかをネットワークに伝えます。 一般的に言えば、トランザクションに含まれるのは、 。 スマート コントラクトへのメッセージ、ユーザーのウォレットからの署名、および支払うネットワーク料金の仕様だけです だから問題は何ですか？  「トランザクション」を定義するこの方法は、技術的に言えば機能しますが、ユーザーが署名する方法で物事が記述されていないため、多くの点で改善の余地があります。ユーザーとして、私は DEX を介してトークンを交換したり、NFT を購入したり、ローンを借りたりするトランザクションを実行しようとしているかもしれませんが、私が署名しているのは常に、スマート コントラクトのブラック ボックスへの 1 つのメッセージです。希望は私が期待していることをしてくれるでしょう。 この「ブラックボックスへのメッセージ」トランザクション設計は、今日の暗号通貨では当然のことと考えられているいくつかの重大な欠点を生み出します。 。ウォレットは、特定のスマート コントラクトが呼び出されていることだけを知っています。すべてのトランザクション結果は、内部スマート コントラクト ロジックによってコミットされた内部変更であり、事前に知ることは事実上不可能です。実際、多くのチェーンでは、ユーザーはスマート コントラクト呼び出しのハッシュに署名するため、さらにわかりにくくなります。 ウォレット ユーザー (およびウォレット ソフトウェア) は、トランザクションの実際の結果を知ることができません 。 DEX の例を挙げると、ユーザーにスリッページ保護を提供する唯一の方法は、DEX スマート コントラクトが内部ロジックの一部としてそれを提供する (そしてユーザーがその実装を信頼する) ことです。 ユーザーは「サンドイッチ取引」やスリッページから身を守ることはできません 。ユーザーがスマート コントラクトに対して自分自身を認証する唯一の方法は、単一のアカウント キーの署名を介することです。さらに複雑な場合は、(ご想像のとおり) 別のスマート コントラクトをデプロイすることを意味します。 認可パターンは非常に単純です 。トランザクションには単一のエントリ ポイントが必要で、その後、他のスマート コントラクトを複数回呼び出すことができます。これは、構成を実現するには事前の計画が必要であり、手間がかかり、厳格であることを意味します。 複数のスマート コントラクトを一緒に構成することは、別のスマート コントラクトを展開することを意味します   。単一署名者の発信者パターンは、そのユーザー アカウントのみが料金を支払うことができることを意味します。 dApp は、ユーザーに代わってネットワーク料金を支払うことはできません 基本的なトランザクション モデルのこれらの欠点を回避することで、その深刻度を軽減しようとするさまざまな提案があります。たとえば、ERC-4337 の「アカウントの抽象化」により、(とりわけ) 委任された料金支払いの形式が可能になりますが、 。 重大なシステムの複雑さとリスクを犠牲にして ただし、どのような回避策が追加され 。 ても、プラットフォーム テクノロジが制限でなければ、トランザクションがユーザーや開発者が望むように機能しないという問題は残ります 上記の問題を解決するには、トランザクションの概念を再定義して、トランザクションがより強力かつ柔軟になるようにする必要があります。開発者には、より複雑なインタラクションを直接定義するためのより多くの権限を与える必要があり、ブラックボックスのスマート コントラクト ロジックを信頼するのではなく、署名時にユーザーが自分にとって重要なことを制御できるようにする必要があります。 次回のブログでは、Radix が独自のフルスタック プラットフォームによって実現される新しい種類のトランザクション設計で、まさにそれをどのように実現するかについて説明します。 でも公開されています。 ここ

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Buy XRD with card or bank transfer via Switchere.

このオーディオは、ストーリーの元の言語で制作されています。

長すぎる; 読むには

Download free Tech Leaders Productivity Report!

今日の暗号通貨取引の問題

About Author

コメント

ラベル

この記事は

Related Stories

ワークフローを10倍に向上させる方法: 必須アプリ17選

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

Telegram: クリプト島と本土を結ぶ橋

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

ワークフローを10倍に向上させる方法: 必須アプリ17選

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

Telegram: クリプト島と本土を結ぶ橋

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps