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

現在の 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 が独自のフルスタック プラットフォームによって実現される新しい種類のトランザクション設計で、まさにそれをどのように実現するかについて説明します。