ERCs
ERCs copied to clipboard
ethereum
Add ERC: Puppet Proxy Contract
Here's the puppet proxy contract EIP.
I'm aware that there's a strict numbering convention for the EIPs, but if it's bypassable, it would be great if this EIP got number 1133. It would place the puppet proxy mentally close to ERC-1167, the clone proxy, which is a similar concept.
I'm aware that there's a strict numbering convention for the EIPs, but if it's bypassable, it would be great if this EIP got number 1133. It would place the puppet proxy mentally close to ERC-1167, the clone proxy, which is a similar concept.
EIP/RIP/ERC numbers are assigned incrementally.
From: https://eips.ethereum.org/EIPS/eip-1
Once the EIP is ready for the repository, the EIP editor will:
Assign an EIP number (generally incremental; editors can reassign if number sniping is suspected)
Hi @mattstam, thanks for the feedback! There's the "motivation" section, do the usage examples need more thorough explanation? The alternative approaches are described in the "rationale" section, they are separated to follow the template ERC structure.
I mean expand on this:
each user of a protocol can get their own address where assets can be sent and stored.
Who is the deployer of these accounts, the protocol or the users? What types of protocols would want this behavior?
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hi @SamWilsn, thanks for the review and the forum discussion!
ERCs shine when multiple independent implementations need to interoperate without communicating beforehand. ERC-20 is a great example
This proposal seems like it would be a better fit for a library (with associated documentation), or for a smart contract wallet implementation.
Examples of ERCs very similar to this one are 1167, 3448 and 7511. This ERC and all 3 other proxies are standardized by specifying the exact bytecodes of their init codes, with their interfaces and usage emerging from these bytecodes. None of these ERCs define how these raw bytecodes are handled in practice, it's up to the designers of tools and libraries. For example searching on GitHub for the ERC-1167 init code yields over 17K results, and each of them is a different tool, library or a piece of ad-hoc code for handling the proxies. Such proliferation is possible because the standard enforces only the raw bytecode giving a lot of elasticity, anybody can easily write their own library using the preferred language and framework. If they only agree to use the same bytecode, they can derive each others' CREATE2 addresses, they know how to deploy the proxies and how to use them.
please explain (in the document itself) who the parties are that need to coordinate on this topic, and why you need a particular implementation instead of just an interface.
This is touched on in the "motivation" section:
Because the bytecode is not compiled, it can be reliably deployed under a predictable CREATE2 address regardless of the compiler version.
There's a scenario described that is only feasible because the bytecode is standardized and known by the actor sending the funds. It would be much harder to work with if the puppet bytecode wasn't fixed because depending on the compilation process it would generate a different CREATE2 address derived from a different input:
If the puppet is deployed under a predictable address, e.g. by using the user's address as the CREATE2 salt, the puppet may not even need to be deployed before funds are sent to its address.
There's another scenario which is practical only because the users can rely on the fixed bytecode resulting in a predictable CREATE2 address:
It can be also used as a full replacement of the CREATE3 factory by using a puppet deployed using CREATE2 to deploy arbitrary code using plain CREATE.
Is this described clearly and deeply enough or does it need more explanation?
This is touched on in the "motivation" section: [...]
It's clear why you've chosen bytecode over solidity. The document does a good job of explaining that. What's missing is why you need deterministic addresses, and why a third party (who isn't the puppeteer) would care what the address ends up being.
Essentially you need to make the case for why you can't just specify an interface and you need to specify an implementation.
I think you could get away with rewording this chunk and putting it in the document:
Such proliferation is possible because the standard enforces only the raw bytecode giving a lot of elasticity, anybody can easily write their own library using the preferred language and framework. If they only agree to use the same bytecode, they can derive each others' CREATE2 addresses, they know how to deploy the proxies and how to use them.
I pushed explicit interoperability motivation for standardizing the exact creation code. @SamWilsn is this good and does it provide the necessary information?
The commit 4af286a23587daecf820065dde348a445644a196 (as a parent of 56acd2f16c54b04ca5ec144d5c3a6ef04993c5a7) contains errors. Please inspect the Run Summary for details.
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.