Subscribe to 0xtomo
0xtomoTenderly + Vercel + Foundry + monorepoでのEthereum開発が楽すぎる話
0xtomoEIP-7702凄すぎ説
こんにちは。この記事は以下の続きのような感じです。 https://mirror.xyz/0xtomo.eth/uMrMMzPFbK2gEkusMNZ66qQQbQr9LjCNWeBd2U5tnBM 前の記事で、EIP-7702はブロックチェーン玄人にとっては有力なオプションで、既存または新規のEOAに code をセットしてAccount Abstractionを含むコントラクトウォレット(e.g. smart account)のメリットを享受するといい、しかしブロックチェーンにもセキュリティにも疎い初心者ユーザには使いづらいのではないか? 引用すると実際にこのユーザ群にとって良い選択肢である一方で、無知なユーザに必要以上の権限委譲をさせてしまう危険性を孕んでいると感じました。ウォレットやdAppの提供者は、ユーザのEOAに「この code をセットしませんか」と促すことができます。その code はユーザが理解していない副作用を持つかもしれません。また、セットできる code は一つなので、ウォレット提供者はともかくdAppがそれをセットするのは、他のdAppも違う code...
<100 subscribers
0xtomoTenderly + Vercel + Foundry + monorepoでのEthereum開発が楽すぎる話
0xtomoEIP-7702凄すぎ説
こんにちは。この記事は以下の続きのような感じです。 https://mirror.xyz/0xtomo.eth/uMrMMzPFbK2gEkusMNZ66qQQbQr9LjCNWeBd2U5tnBM 前の記事で、EIP-7702はブロックチェーン玄人にとっては有力なオプションで、既存または新規のEOAに code をセットしてAccount Abstractionを含むコントラクトウォレット(e.g. smart account)のメリットを享受するといい、しかしブロックチェーンにもセキュリティにも疎い初心者ユーザには使いづらいのではないか? 引用すると実際にこのユーザ群にとって良い選択肢である一方で、無知なユーザに必要以上の権限委譲をさせてしまう危険性を孕んでいると感じました。ウォレットやdAppの提供者は、ユーザのEOAに「この code をセットしませんか」と促すことができます。その code はユーザが理解していない副作用を持つかもしれません。また、セットできる code は一つなので、ウォレット提供者はともかくdAppがそれをセットするのは、他のdAppも違う code...
Share Dialog
Share Dialog
ウォレットやトランザクションについて考えることが職業柄多く、最近特に発展してきたなと思うのでまとめておきます。内容の一部はEthereum界隈の人全般向け、一部はその中でもエンジニア向けになっています。最近推しのウォレット、ウォレット関連のEIP、玄人や素人は何をつかうべきなのか? みたいな章構成です。
Crypto、特にEthereum界隈に2018年ぐらいからいる。はじめて参加したDevconは大阪。Bitcoinを持ち始めたのは2017年1月
Startbahnという会社のCTOをやっており、5年ほど前からマスに向けたweb3サービスを提供している
そこそこ色んなdAppsを触ってきましたがDeFiをめちゃくちゃやる方ではない
使ってきたEthereumウォレットは
MetaMask
Brave Wallet
Phantom
Bitget Wallet
Binance Wallet
とCrypto分かる人の中ではおそらく極めて普通。開発しているプロダクト内では、Crypto全然分からない人向けにはWeb3Auth(旧Torus)を用いて、EmailやGoogleログインなどで秘密鍵を取得し認証する仕組みを採用してきました。余談ですが、弊社プロダクトの2020年リリース当時、
一般の人が使えて
GoogleなどのOAuth認証を含む
Custodialではなく(鍵全体に対するアクセスをサービス提供者が持たない)
dAppsにConnect Walletできる(e.g. 決まったトランザクションだけではなく任意のメッセージに署名できる)
ウォレットに選択肢は殆どありませんでした。今ではPrivyなどの採用を多く見かけますね。
ここから本題に入っていきますが、最近推しのウォレットができました。2024年秋のDevcon Bangkokの前から目をつけていて中の人とも話して気にはなっていたAmbire Walletです。モバイルアプリも提供されていますが、今v1からv2への移行期ということで、先にv2が採用されているChrome Extentionだけを今は利用しています。もし招待コードが必要でしたら、 cb81584f8cc8 を利用していただけたら幸いです。
Account Abstraction(ERC-4337)ウォレットでのTXが非常に見やすいです。
ERC-20トークンである $USDC のApprovalと, $WALLET とのSwapが一つのトランザクション内で行われたことがよく分かります。
Gas Tankという機能を使って、一つのチェーンに $USDC などをガス代用にdepositしておくことで、このウォレットからの(基本的に)あらゆるチェーンでのあらゆるトランザクションの手数料をそこから支払うこともできます。 Particleが少し前からGas Abstractionと言っていましたが、一般的な機能になってきましたね、素晴らしい。
ちなみに、このウォレットのインタフェース上でのSwapは現時点で0.25%の手数料が取られます。僕はこのウォレットを推しますが、利用は自己責任でお願いいたします🙏
このウォレットを使ってdApps、例としてNFTマーケットプレイスであるMagic EdenにConnectしてみましょう。
普通のEthereumウォレット(EOA, Externally Owned Address)と同様に決まった書式のメッセージに署名を求められます。ウォレットアイコンの左上にある SA はERC-4337を利用した Smart Account を意味します。
また、既にEtherScan(や同系列のBaseScanなど)も既にこれらのトランザクションを非常に上手く表示する機能を搭載してくれています。是非Ambireで一つトランザクションを実行してexplorerで確認してみてください。
関連するEIP/ERCについても考えていきましょう。
ERC-4337は、Account Abstractionを利用したウォレットインタフェースの中で、おそらく一番利用されているものです。ユーザは生のトランザクションではなく、UserOperation というオブジェクトに署名をして、 Bundler という役割を行っている相手(ノード)にそれを投げます。この一つの UserOperation は複数のコントラクト実行、例えば上の例で言うと
$USDCコントラクトの Approve をするための関数
DEXコントラクトのSwap用の関数
の実行を含んでいて、これらはEOAの世界では2つのトランザクションに別々に署名が必要でガス代も多めにかかっていたところが、1つになっています。
ERC-1271は、どうコントラクトウォレットの署名を検証するのかを規定しています。おそらく上でSwapのトランザクションにおいても、Magic EdenへのConnectにおいても、該当ウォレットのisValidSignature関数を実行することで認証しています。これはEOAにおける、dAppsバックエンドがsecp256k1 ECDSA署名から ecrecover アルゴリズムを利用して署名元のEthereumアドレスを復元し、署名したと言っているアドレスと一致するかを検証することで認証していたものなどを代替するものです。
ERC-6492はそれを補完するものです。Contract Walletを含むコントラクトのデプロイにはコストがかかるため、オンチェーンでそのウォレットがトランザクションを実行するまではデプロイを控えたい。しかしERC-1271は既にそのネットワークにデプロイされているコントラクトに対してしか実行できないという弱点を、そのデプロイや検証のバイトコードをオフチェーンでも実行する仕組みを提供することで補完しています。結構前ですが、それを使った認証を実装したコードも書いてみた( web server contracts がそれぞれフロントエンド, バックエンド, コントラクトに対応しています)ので気になる方は参照してみてください。
EIP-7702は、比較的新しいもので、今ちょうどEthereum L1ではテストネットにはリリース済み、メインネットには近々リリースされるPectra(execution layerへのPragueリリースとconsensus layerへのElectraリリースの総称)に含まれています。他のEVM L1やL2も対応を複数発表しています。表題は Smarter EOA で、ERC-4337を代表としたAccount Abstractionを含むContract Walletの考えは素晴らしく、また長期的には全面的に採用されていくべきもの。しかし現在ユーザはEOAに慣れきっているため、橋渡しをしていく意味で短中期的にユーザはあくまでEOAを使っているがContract Walletの機能を享受できるようにしよう、というものです。技術的な詳細はこの動画が分かりやすいです。こちらについてもHello World的なコードを書いてみたので気になる方はどうぞ。かいつまんで言うと、Pectra以降、各EOAにはコード( code )をセットすることができるようになり、Contract Walletをアドレスや鍵を変えずに利用することができます。セットできるコードは1つです。以下はEIP-7702を享受している、つまり code がセットされているEOAが、トランザクションのFromにもToにも使われうることを示します。前者は今まで通りそのEOAの鍵を利用してトランザクションを発行した場合、後者は code を他のEthereum Address(EOAかもしれないしコントラクトかもしれない)が実行した場合です。EIP-7702以前は、(ネイティブ通貨(e.g. $ETH )のtransferを除き)EOAは常に署名をする側、つまりFromでしかあり得ませんでした。
(Explorerはローカルで動作するOtterscanを利用しています👏)
上の例で、Block 5の時点で既に0x709… は 0xf39… に一定の権限を付与されているため、その権限に基づきトランザクションを実行しています。 0xf39… がERC-4337のウォレットで、 0x709… が UserOperation に署名するEOAという図式を代替したと言っていいでしょう。一方で、 0xf39… の秘密鍵は依然としてフルの権限を持っているため、Block 6において別のトランザクションを実行しています。これが、このEIPがEOAとContract Walletの世界の橋渡しをする Smarter EOA の中身です。
さて、では我々Crypto慣れている勢と、Crypto何も分からない勢はどのウォレットを使うべきなのでしょうか。
比較的簡単なのは前者です。既にMetaMaskに代表されるEOAウォレットを使って色んなアプリを利用しているでしょうから、徐々にAmbireやParticleなどのERC-4337対応のウォレットに移行していけばいいでしょう。上でMagic EdenへのConnectを紹介しましたが、本記事執筆時点でAmbire Walletを利用した、Ledgerデバイスで署名するERC-4337アカウントではMagic Eden, Uniswap, OpenSeaにはConnectできましたが、記事が書かれているMirrorにはConnectできませんでした。初期に比べて格段にサポートが良くなっていて、実用し始めるには十分と思いますが、まだ全てのアプリで使う準備ができているとは言えないでしょう。また、既に利用しているEOAのトランザクション履歴を大事にしたい場合には、そのEOAに好きな code をセットして、EIP-7702ウォレットとして利用していくのも有力な選択肢と言えます。
後者については個人的にはいまだに凄く良い解がありません。EIP-7702の開発者はこのユーザ群のbootstrapを一つの目的として掲げています。実際にこのユーザ群にとって良い選択肢である一方で、無知なユーザに必要以上の権限委譲をさせてしまう危険性を孕んでいると感じました。ウォレットやdAppの提供者は、ユーザのEOAに「この code をセットしませんか」と促すことができます。その code はユーザが理解していない副作用を持つかもしれません。また、セットできる code は一つなので、ウォレット提供者はともかくdAppがそれをセットするのは、他のdAppも違う code をセットさせたいのではないか? その code にユーザが乗り換えようとしたとき、最初の code とデータに互換性はあるのか? などを考えると、対象ユーザ群のリテラシが低いことを認識しているからこそ気が引けます。これらの理由から、このEIPを利用した素晴らしいユースケースは出てくることが期待できる反面、良からぬ事故が起きてしまうことも想定されるし、dapp開発者として利用することを躊躇してしまう場面もあります。結局のところ、よりTrustfulだがメールが使えれば使えるPrivyのような選択肢のほうが期待値的に良いUXを与えるのが現状という気がします。
以上です。お読みくださりありがとうございました。質問があればいつでもTwitterなどでくださればと思います。また、より詳しい方や似た悩みをお持ちの人がいれば是非話させてください！
ウォレットやトランザクションについて考えることが職業柄多く、最近特に発展してきたなと思うのでまとめておきます。内容の一部はEthereum界隈の人全般向け、一部はその中でもエンジニア向けになっています。最近推しのウォレット、ウォレット関連のEIP、玄人や素人は何をつかうべきなのか? みたいな章構成です。
Crypto、特にEthereum界隈に2018年ぐらいからいる。はじめて参加したDevconは大阪。Bitcoinを持ち始めたのは2017年1月
Startbahnという会社のCTOをやっており、5年ほど前からマスに向けたweb3サービスを提供している
そこそこ色んなdAppsを触ってきましたがDeFiをめちゃくちゃやる方ではない
使ってきたEthereumウォレットは
MetaMask
Brave Wallet
Phantom
Bitget Wallet
Binance Wallet
とCrypto分かる人の中ではおそらく極めて普通。開発しているプロダクト内では、Crypto全然分からない人向けにはWeb3Auth(旧Torus)を用いて、EmailやGoogleログインなどで秘密鍵を取得し認証する仕組みを採用してきました。余談ですが、弊社プロダクトの2020年リリース当時、
一般の人が使えて
GoogleなどのOAuth認証を含む
Custodialではなく(鍵全体に対するアクセスをサービス提供者が持たない)
dAppsにConnect Walletできる(e.g. 決まったトランザクションだけではなく任意のメッセージに署名できる)
ウォレットに選択肢は殆どありませんでした。今ではPrivyなどの採用を多く見かけますね。
ここから本題に入っていきますが、最近推しのウォレットができました。2024年秋のDevcon Bangkokの前から目をつけていて中の人とも話して気にはなっていたAmbire Walletです。モバイルアプリも提供されていますが、今v1からv2への移行期ということで、先にv2が採用されているChrome Extentionだけを今は利用しています。もし招待コードが必要でしたら、 cb81584f8cc8 を利用していただけたら幸いです。
Account Abstraction(ERC-4337)ウォレットでのTXが非常に見やすいです。
ERC-20トークンである $USDC のApprovalと, $WALLET とのSwapが一つのトランザクション内で行われたことがよく分かります。
Gas Tankという機能を使って、一つのチェーンに $USDC などをガス代用にdepositしておくことで、このウォレットからの(基本的に)あらゆるチェーンでのあらゆるトランザクションの手数料をそこから支払うこともできます。 Particleが少し前からGas Abstractionと言っていましたが、一般的な機能になってきましたね、素晴らしい。
ちなみに、このウォレットのインタフェース上でのSwapは現時点で0.25%の手数料が取られます。僕はこのウォレットを推しますが、利用は自己責任でお願いいたします🙏
このウォレットを使ってdApps、例としてNFTマーケットプレイスであるMagic EdenにConnectしてみましょう。
普通のEthereumウォレット(EOA, Externally Owned Address)と同様に決まった書式のメッセージに署名を求められます。ウォレットアイコンの左上にある SA はERC-4337を利用した Smart Account を意味します。
また、既にEtherScan(や同系列のBaseScanなど)も既にこれらのトランザクションを非常に上手く表示する機能を搭載してくれています。是非Ambireで一つトランザクションを実行してexplorerで確認してみてください。
関連するEIP/ERCについても考えていきましょう。
ERC-4337は、Account Abstractionを利用したウォレットインタフェースの中で、おそらく一番利用されているものです。ユーザは生のトランザクションではなく、UserOperation というオブジェクトに署名をして、 Bundler という役割を行っている相手(ノード)にそれを投げます。この一つの UserOperation は複数のコントラクト実行、例えば上の例で言うと
$USDCコントラクトの Approve をするための関数
DEXコントラクトのSwap用の関数
の実行を含んでいて、これらはEOAの世界では2つのトランザクションに別々に署名が必要でガス代も多めにかかっていたところが、1つになっています。
ERC-1271は、どうコントラクトウォレットの署名を検証するのかを規定しています。おそらく上でSwapのトランザクションにおいても、Magic EdenへのConnectにおいても、該当ウォレットのisValidSignature関数を実行することで認証しています。これはEOAにおける、dAppsバックエンドがsecp256k1 ECDSA署名から ecrecover アルゴリズムを利用して署名元のEthereumアドレスを復元し、署名したと言っているアドレスと一致するかを検証することで認証していたものなどを代替するものです。
ERC-6492はそれを補完するものです。Contract Walletを含むコントラクトのデプロイにはコストがかかるため、オンチェーンでそのウォレットがトランザクションを実行するまではデプロイを控えたい。しかしERC-1271は既にそのネットワークにデプロイされているコントラクトに対してしか実行できないという弱点を、そのデプロイや検証のバイトコードをオフチェーンでも実行する仕組みを提供することで補完しています。結構前ですが、それを使った認証を実装したコードも書いてみた( web server contracts がそれぞれフロントエンド, バックエンド, コントラクトに対応しています)ので気になる方は参照してみてください。
EIP-7702は、比較的新しいもので、今ちょうどEthereum L1ではテストネットにはリリース済み、メインネットには近々リリースされるPectra(execution layerへのPragueリリースとconsensus layerへのElectraリリースの総称)に含まれています。他のEVM L1やL2も対応を複数発表しています。表題は Smarter EOA で、ERC-4337を代表としたAccount Abstractionを含むContract Walletの考えは素晴らしく、また長期的には全面的に採用されていくべきもの。しかし現在ユーザはEOAに慣れきっているため、橋渡しをしていく意味で短中期的にユーザはあくまでEOAを使っているがContract Walletの機能を享受できるようにしよう、というものです。技術的な詳細はこの動画が分かりやすいです。こちらについてもHello World的なコードを書いてみたので気になる方はどうぞ。かいつまんで言うと、Pectra以降、各EOAにはコード( code )をセットすることができるようになり、Contract Walletをアドレスや鍵を変えずに利用することができます。セットできるコードは1つです。以下はEIP-7702を享受している、つまり code がセットされているEOAが、トランザクションのFromにもToにも使われうることを示します。前者は今まで通りそのEOAの鍵を利用してトランザクションを発行した場合、後者は code を他のEthereum Address(EOAかもしれないしコントラクトかもしれない)が実行した場合です。EIP-7702以前は、(ネイティブ通貨(e.g. $ETH )のtransferを除き)EOAは常に署名をする側、つまりFromでしかあり得ませんでした。
(Explorerはローカルで動作するOtterscanを利用しています👏)
上の例で、Block 5の時点で既に0x709… は 0xf39… に一定の権限を付与されているため、その権限に基づきトランザクションを実行しています。 0xf39… がERC-4337のウォレットで、 0x709… が UserOperation に署名するEOAという図式を代替したと言っていいでしょう。一方で、 0xf39… の秘密鍵は依然としてフルの権限を持っているため、Block 6において別のトランザクションを実行しています。これが、このEIPがEOAとContract Walletの世界の橋渡しをする Smarter EOA の中身です。
さて、では我々Crypto慣れている勢と、Crypto何も分からない勢はどのウォレットを使うべきなのでしょうか。
比較的簡単なのは前者です。既にMetaMaskに代表されるEOAウォレットを使って色んなアプリを利用しているでしょうから、徐々にAmbireやParticleなどのERC-4337対応のウォレットに移行していけばいいでしょう。上でMagic EdenへのConnectを紹介しましたが、本記事執筆時点でAmbire Walletを利用した、Ledgerデバイスで署名するERC-4337アカウントではMagic Eden, Uniswap, OpenSeaにはConnectできましたが、記事が書かれているMirrorにはConnectできませんでした。初期に比べて格段にサポートが良くなっていて、実用し始めるには十分と思いますが、まだ全てのアプリで使う準備ができているとは言えないでしょう。また、既に利用しているEOAのトランザクション履歴を大事にしたい場合には、そのEOAに好きな code をセットして、EIP-7702ウォレットとして利用していくのも有力な選択肢と言えます。
後者については個人的にはいまだに凄く良い解がありません。EIP-7702の開発者はこのユーザ群のbootstrapを一つの目的として掲げています。実際にこのユーザ群にとって良い選択肢である一方で、無知なユーザに必要以上の権限委譲をさせてしまう危険性を孕んでいると感じました。ウォレットやdAppの提供者は、ユーザのEOAに「この code をセットしませんか」と促すことができます。その code はユーザが理解していない副作用を持つかもしれません。また、セットできる code は一つなので、ウォレット提供者はともかくdAppがそれをセットするのは、他のdAppも違う code をセットさせたいのではないか? その code にユーザが乗り換えようとしたとき、最初の code とデータに互換性はあるのか? などを考えると、対象ユーザ群のリテラシが低いことを認識しているからこそ気が引けます。これらの理由から、このEIPを利用した素晴らしいユースケースは出てくることが期待できる反面、良からぬ事故が起きてしまうことも想定されるし、dapp開発者として利用することを躊躇してしまう場面もあります。結局のところ、よりTrustfulだがメールが使えれば使えるPrivyのような選択肢のほうが期待値的に良いUXを与えるのが現状という気がします。
以上です。お読みくださりありがとうございました。質問があればいつでもTwitterなどでくださればと思います。また、より詳しい方や似た悩みをお持ちの人がいれば是非話させてください！
No comments yet