EIP86
概要
2017.02.20 に Vitalik が提案したが、採用には至っていない
目的:トランザクション検証処理をプロトコルから切り離し、account security abstraction を実現すること
Implements a set of changes that serve the combined purpose of “abstracting out” signature verification and nonce checking, allowing users to create “account contracts” that perform any desired signature/nonce checks instead of using the mechanism that is currently hard-coded into transaction processing.
The goal of these changes is to set the stage for abstraction of account security. Instead of having an in-protocol mechanism where ECDSA and the default nonce scheme are enshrined as the only “standard” way to secure an account, we take initial steps toward a model where in the long term all accounts are contracts, contracts can pay for gas, and users are free to define their own security model.
m0t0k1ch1.icon トランザクション検証処理の担い手をプロトコルからコントラクトに変えようという話
詳細
新しいトランザクション形式の導入
トランザクションの電子署名が (CHAIN_ID, 0, 0)(すなわち、r = s = 0 v = CHAIN_ID)の場合、それを許容し、送信者アドレスに NULL_SENDER(2**160 - 1)を設定する
上記形式のトランザクションは gas_price = 0 nonce = 0 value = 0 でなければならない
NULL_SENDER の nonce をインクリメントしてはならない
CREATE2(0xfb)という新しい opcode の導入
m0t0k1ch1.icon 新しいトランザクション形式では常に nonce = 0 となってしまうため、nonce に依存しないアドレス決定ロジックが必要となる
value salt mem_start mem_size を引数とする
これによって生成されるコントラクトのアドレスは sha3(sender + salt + sha3(init_code)) となる
salt は 32 byte でなければならない
あらゆるコントラクト生成処理は、生成しようとするコントラクトのアドレスが既に存在し、コードもしくは nonce が空でない場合、初期化コードが gas を使い果たした場合と同様に失敗し、0 を返す
アドレスのコードと nonce は空だが balance が空でない場合、コントラクト生成は成功しうる
---.icon
m0t0k1ch1.icon Vitalik はこの頃から account "security" abstraction を見てたんだなあ
m0t0k1ch1.icon 彼が social recovery 推してるのもこの文脈に乗る
m0t0k1ch1.icon スジ通ってんねえ