dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_1167
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_1167 [2020/11/13 02:21] nick ↷ Links adapted because of a move operation |
dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_1167 [2021/08/06 14:04] (current) murphy |
||
|---|---|---|---|
| Line 17: | Line 17: | ||
| === Simple Summary === | === Simple Summary === | ||
| - | : //To simply and cheaply clone contract functionality in an immutable way, this standard specifies a minimal bytecode implementation that delegates all calls to a known, fixed address.// | + | : //To simply and cheaply clone contract functionality in an [[dido:public:ra:xapend:xapend.a_glossary:i:immutable|immutable]] way, this standard specifies a minimal bytecode implementation that delegates all calls to a known, fixed address.// |
| === Abstract === | === Abstract === | ||
| - | : //By standardizing on a known minimal bytecode redirect implementation, this standard allows users and third party tools (e.g. Etherscan) to (a) simply discover that a contract will always redirect in a known manner and (b) depend on the behavior of the code at the destination contract as the behavior of the redirecting contract. Specifically, tooling can interrogate the bytecode at a redirecting address to determine the location of the code that will run - and can depend on representations about that code (verified source, third-party audits, etc). This implementation forwards all calls and 100% of the gas to the implementation contract and then relays the return value back to the caller. In the case where the implementation reverts, the revert is passed back along with the payload data (for revert with message).// | + | : //By standardizing on a known minimal bytecode redirect implementation, this standard allows users and third party tools (e.g. Etherscan) to (a) simply discover that a contract will always redirect in a known manner and (b) depend on the behavior of the code at the destination contract as the behavior of the redirecting contract. Specifically, tooling can interrogate the bytecode at a redirecting address to determine the location of the code that will run - and can depend on representations about that code (verified source, third-party audits, etc). This implementation forwards all calls and 100% of the [[dido:public:ra:xapend:xapend.a_glossary:g:gas|gas]] to the implementation contract and then relays the return value back to the caller. In the case where the implementation reverts, the revert is passed back along with the payload data (for revert with message).// |
| === Motivation === | === Motivation === | ||
| : //This standard supports use-cases wherein it is desirable to clone exact contract functionality with a minimum of side effects (e.g. memory slot stomping) and with low gas cost deployment of duplicate proxies.// | : //This standard supports use-cases wherein it is desirable to clone exact contract functionality with a minimum of side effects (e.g. memory slot stomping) and with low gas cost deployment of duplicate proxies.// | ||
dido/public/ra/xapend/xapend.b_stds/defact/ethereum/eip/erc_1167.1605252092.txt.gz · Last modified: 2020/11/13 02:21 by nick
