Simply

ERC827とは

1/24(水)にOpenZeppelin v1.6.0がリリースされました!
このリリースの中には仮想猫でお馴染み「ERC721」だけでなく、「ERC827」というトークン仕様も含まれています。
というわけで今回は「ERC827」について説明します。

※ OpenZeppelinとは、セキュアなスマートコントラクト開発をサポートしてくれる Solidity 製ライブラリです。

ERC827とは?

EIPにある説明の最初に作成日が書かれていないので正確な提案日時は不明ですが、issue 自体の作成は今から19日前なので1/11(木)に出された改善案のようです。

ERC20の抱える課題

例として、ERC20トークン「SIM」を管理する「SIMコントラクト」があり、AさんがBさんに10SIM送る場合、以下2つのトランザクションが発行されます。

  1. AさんがSIMコントラクトに対して「Bさんに10SIMの転送を許可する(approve)」トランザクションを発行
  2. BさんがSIMコントラクトに対して「AさんからBさんに10SIM転送する(transferFrom)」トランザクションを発行

Ethereum 大元の通貨 ether は1つのトランザクションで通貨送れるのに、ERC20トークンを送るためには2つトランザクション必要なのっておかしくない?というのが「ERC827」提案の源泉みたいです。
トランザクションが多いとその分ガスが多く使われる、かつネットワークに負荷をかけるので、当然と言えば当然の疑問です。

ERC827のメリット

では、この課題をどう解決しているのか。
「ERC827」では「トランザクションの中で最初の処理とは別の処理を、別のユーザーとして呼び出す」設計を実現し、1つのトランザクション内で「ERC20」での approve / transfer を呼び出せるようになっています。
上記の例で言うと、

  1. Aさんが『AさんからBさんに10SIM転送』する処理の呼び出しをバイトコードに変換
  2. AさんがSIMコントラクトに対して「Bさんに10SIMの転送を許可し、上記バイトコードを共に投げる(ERC827 transfer)」トランザクションを発行
  3. SIMコントラクト内で「Bさんがバイトコードを実行」する、すなわちBさんが「AさんからBさんに10SIM転送」する

そうする事でガスを節約できるだけでなく、「ERC20」が抱えている「送り主の意図しない量のトークンを相手に送ってしまう」というAPIレベルでの脆弱性の解決も期待できます。

ERC827のデメリット

与えられたバイトコードの内容を検証する仕組みが無いため、例えば「AさんからBさんに手持ち全てのトークンを送る」をバイトコードにして実行されてしまうと、トークンが盗まれる恐れがあります。
また、AさんBさんでは無くトークンオーナーを指定する事も出来てしまうので、オーナー所有のトークンすら盗まれる可能性があります。
このあたりのセキュリティリスクは既にEIPコメントにて指摘されており、今後の議論によっては新しいEIPが作られるかもしれません。

まとめ

「ERC20」改善の決定版!みたいな仕様が中々決まりませんが、今後もEIPをチェックして次のトークン仕様がどうなるのか、追っていこうと思います!

 

Follow us

Don't be shy, get in touch. We love meeting interesting people and making new friends.