Update EIP-8141: Fix some issues with EIP-8141

[derekchiang]

• Remove several references to how APPROVE requires CALLER == frame.target which doesn't make sense since a typical VERIFY frame will have CALLER == ENTRY_POINT and frame.target == tx.sender, as seen from the examples. I believe the real intention is that APPROVE should be called by frame.target (or more precisely ADDRESS == frame.target), so I updated the language accordingly.

• Restrict APPROVE to VERIFY frames. I believe this is the intention since APPROVE cannot be called from SENDER frames and it's not clear why it should ever be called from a DEFAULT frame since DEFAULT frames can modify state.

• Clarify that frame reverts don't affect subsequent frames.

• Fix some minor typos.

[eth-bot]

File EIPS/eip-8141.md

Requires 1 more reviewers from @drortirosh, @fjl, @forshtat, @lightclient, @shahafn, @vbuterin, @yoavw

[lightclient]

Thanks for this! Definitely a mistake by me when I was refactoring approve. I definitely meant it to be ADDRESS == frame.target like you wrote.

I would like to remove the restriction on calling approve only in "verify" frames though. Builders may want to have stateful frames approve a transaction - those just wouldn't propagate through the public txpool.

[derekchiang]

Thanks for this! Definitely a mistake by me when I was refactoring approve. I definitely meant it to be ADDRESS == frame.target like you wrote.

I would like to remove the restriction on calling approve only in "verify" frames though. Builders may want to have stateful frames approve a transaction - those just wouldn't propagate through the public txpool.

Understood -- removed the restriction just now.

[nlordell]

While you're here - was the TXPARAM meant to jump from 0x09 to 0x10 and skip 0x0[a-f], or was it just a decimal/hex typo (was mentioned by someone else in a Telegram group)?