今日はアカウント抽象化についてお話します!🥳 最後から始めましょう:UX、UX、UX。 アカウントの抽象化は、優れたUXの鍵です。 私たちは、可能な限り最高のUXのためにユーザーに最大限の努力を払う義務があります。 最高のUXには、適切なインフラストラクチャが必要です。 「適切なインフラストラクチャ」とは、アプリ/ウォレットの UX をカスタマイズおよび最適化できるインフラストラクチャを意味します。 つまり、AA は、平均的な暗号 UX である有名な不格好で面倒なエクスペリエンスに対するソリューションです。しかし、このソリューションが何をするかを理解する前に、問題を理解する必要があります。 不格好なUX イーサリアム、EVM チェーン、およびその後のほぼすべてのチェーンには、ユーザー アカウントとスマート コントラクトの 2 種類のアカウントがあります。 ユーザーアカウント(別名EOA): - 実行できる特定のアクションのセットを用意する: 支払いを行うか、スマート コントラクトをトリガーしてコード (およびさらにいくつかのこと) を実行できます。 - ユーザーは、アカウントが発行するすべての取引ごとに秘密鍵で署名する必要があります。 - 署名ロジックをカスタマイズすることはできません。これらのアカウントに対してカスタマイズされた回復メカニズムを使用することはできません。 スマートコントラクトは、コード(アプリといえば)を実行するアカウントです。 - (ユーザーアカウントまたは別のスマートコントラクトによって)トリガーされると、実行するように設計されたアクションを実行します。 - 他のスマートコントラクトをトリガーすることはできますが、それ自体をトリガーすることはできません。別のスマートコントラクトをトリガーするスマートコントラクトがある場合でも、最初のトランザクションをトリガーするユーザーアカウントが必要です。 したがって、スマートコントラクトをトリガーするにはユーザーアカウントが必要であり、その動作や操作ロジックには柔軟性が欠けています。この柔軟性の欠如により、アプリが構築でき、ユーザーが持つことができる UX が制限されています。 アカウント抽象化 アカウント抽象化とは、ユーザーアカウントもスマートコントラクト(EOAではない)であることを意味します。EOAが持つ特定のロジックに制限されないということは、ユーザーのために作成できる動作/ロジックにも制限されないことを意味します。UXの制限を抽象化することができます。 次に、ウォレットの優れた UX の部分にたどり着きます さて、ユーザー アカウント (ウォレット) はスマート コントラクトになりました (スマート ウォレットと呼ぶことができます)。 これにより、ウォレット管理に関して UX の創造性に多くの余地が開かれます。 *例えば*： - スマートフォンの生体認証と暗号化を使用して支払いを承認しますか?はい。 - マルチシグのスマートウォレットをお持ちですか?はい。 - 毎月の支払いを承認し、アクティビティがない場合(またはキーを紛失した場合)に自動的に他の人に資金を送金するデッドマンスイッチを設定しますか?繰り返しに聞こえる危険を冒してでも、そうです。 - 複数のコントラクトへの複数の呼び出しをバッチ処理し、1つのトランザクションとして送信しますか?はい。 - EOAができないMoooarのこと?はい。 これは技術的なことのように聞こえますが、ユーザーを暗号通貨から遠ざける暗号的なエクスペリエンスを取り除く、スムーズなカスタムメイドのフローにコンパイルされます。 私の隣人、あなたの叔母、そして職場の友人をオンボーディングしたい場合、暗号UXが非暗号アプリと競合することが重要です。 アカウント抽象化は非常に重要な要素であるため、Starknet は AA を設計に組み込んで構築されました (これをネイティブ アカウント抽象化と呼びます)。 Paymaster と Native Account Abstraction の 2 つのトピックも説明する価値がありますが、このツイートはすでにかなり長いです。したがって、Paymaster と *ネイティブ* アカウント抽象化は (多かれ少なかれ) 明日を待つことになります。 この説明により、AA がなぜそうなのか🗝️が明確になることを願っています。

🚨 Starknet のガス UX が変更されました。絶えず。🚨 Starknet Paymaster のご紹介 - ガス料金を抽象化するためのオープンソースで本番環境に対応した開発者ファーストの方法です。 → スポンサー取引 → ガスのトークンを受け入れる → 自分で実行する 話しましょう 👇