Add ERC: PDAs (Programmatically Derived Addresses) #890
+106
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
File
|
bomanaps
reviewed
Feb 27, 2025
Comment on lines
+30
to
+34
| ```solidity | ||
| function derivePDA(address baseContract, bytes32[] memory seeds) public pure returns (address) { | ||
| bytes32 hash = keccak256(abi.encodePacked(baseContract, seeds)); | ||
| return address(uint160(uint256(hash))); | ||
| } |
There was a problem hiding this comment.
I have some concerns/questions about this since there is no Discussions link to EthMagicians.
This function derives an Ethereum address by truncating a 32-byte Keccak-256 hash to 20 bytes?. If so, this is not the standard method for deriving Ethereum addresses. Usually , an Ethereum address is obtained by taking the last 20 bytes of the Keccak-256 hash of the public key.
Solidity's abi.encodePacked performs tight packing, this makes variable-length arrays like seeds might not be properly hashed as intended.
No Error Handling or validation for invalid inputs.
SamWilsn
requested changes
Apr 24, 2025
| --- | ||
| EIP: 7879 | ||
| Title: Program-Derived Addresses (PDAs) | ||
| Author: John Crunch, @JohnCrunch |
There was a problem hiding this comment.
Suggested change
| Author: John Crunch, @JohnCrunch | |
| author: John Crunch (@JohnCrunch) |
| --- | ||
|
|
||
| ## Abstract | ||
| This Ethereum Improvement Proposal (EIP) introduces Program-Derived Addresses (PDAs) as a mechanism to generate deterministic, contract-derived addresses without private keys. Inspired by Solana’s PDA architecture, this standard enables smart contracts to create verifiable and immutable addresses using predefined seeds and cryptographic operations. PDAs provide stateless, permissionless interactions with smart contracts while ensuring security and uniqueness. |
There was a problem hiding this comment.
Suggested change
| This Ethereum Improvement Proposal (EIP) introduces Program-Derived Addresses (PDAs) as a mechanism to generate deterministic, contract-derived addresses without private keys. Inspired by Solana’s PDA architecture, this standard enables smart contracts to create verifiable and immutable addresses using predefined seeds and cryptographic operations. PDAs provide stateless, permissionless interactions with smart contracts while ensuring security and uniqueness. | |
| Program-Derived Addresses (PDAs) are deterministic, contract-derived addresses without private keys. Inspired by Solana’s PDA architecture, this standard enables smart contracts to create verifiable and immutable addresses using predefined seeds and cryptographic operations. PDAs provide stateless, permissionless interactions with smart contracts while ensuring security and uniqueness. |
| --- | ||
|
|
||
| ## Abstract | ||
| This Ethereum Improvement Proposal (EIP) introduces Program-Derived Addresses (PDAs) as a mechanism to generate deterministic, contract-derived addresses without private keys. Inspired by Solana’s PDA architecture, this standard enables smart contracts to create verifiable and immutable addresses using predefined seeds and cryptographic operations. PDAs provide stateless, permissionless interactions with smart contracts while ensuring security and uniqueness. |
There was a problem hiding this comment.
Your abstract is decent, but it's missing a high-level (but still technical) overview of how the proposal accomplishes its goals. You should sketch out what the derivation mechanism is, at least briefly.
Comment on lines
+39
to
+67
| ### Key Properties | ||
| - **No Private Key Association**: The PDA does not have a corresponding private key, making it non-custodial and non-signable. | ||
| - **Verifiable On-Chain**: Any contract can recompute a PDA and validate its authenticity. | ||
| - **Prevents Collisions**: By incorporating the contract’s address, PDAs remain unique to the originating smart contract. | ||
|
|
||
| ### Use Cases | ||
| #### 1. Stateless Account Abstraction | ||
| PDAs allow contracts to operate permissionlessly on derived accounts, facilitating multi-user, multi-session access without requiring new wallet generation. | ||
|
|
||
| #### 2. Gasless Meta-Transactions | ||
| Users can interact with PDAs without directly owning them, enabling sponsored transactions where a relayer signs and pays gas on their behalf. | ||
|
|
||
| #### 3. Trustless Escrow & Sub-Accounts | ||
| Protocols can create predictable, verifiable addresses for escrow, lending, and financial primitives without requiring independent contract deployments. | ||
|
|
||
| #### 4. Off-Chain State Commitments | ||
| PDAs provide a deterministic address for off-chain data commitments, ensuring verifiability while reducing on-chain storage costs. | ||
|
|
||
| #### 5. Efficient Multi-Party Control Without Gas Costs | ||
| Ethereum’s multisig wallets require explicit transactions to modify ownership structures, incurring gas fees. PDAs enable multi-party control without the need for continuous storage updates, as authority can be derived programmatically. | ||
|
|
||
| #### 6. On-Chain Order Books and Marketplaces | ||
| Ethereum’s on-chain order books require storage mappings, making them expensive in gas costs. PDAs allow orders to be stored in derived addresses without bloating contract storage, similar to Solana’s Serum order book model. | ||
|
|
||
| #### 7. Dynamic On-Chain Games | ||
| PDAs can facilitate player state storage in decentralized games, reducing reliance on smart contract storage while maintaining programmatic access to game states. | ||
|
|
||
| #### 8. Precomputed Addresses for DeFi and Oracles | ||
| Lending protocols, AMMs, and on-chain oracles can generate deterministic PDAs for vaults, price feeds, and liquidity pools without requiring separate contract deployments, improving gas efficiency. |
There was a problem hiding this comment.
Use cases belong in Motivation. The Rationale section is for explaining choices made within the document itself.
|
The commit e642451 (as a parent of 06ede5b) contains errors. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a draft ERC proposing Programmatically Derived Addresses (PDAs).
Summary
This ERC introduces a mechanism for generating deterministic, contract-derived addresses without private keys. PDAs enable permissionless, stateless interactions with smart contracts while ensuring security and uniqueness.
Requesting review from ERC editors. Thanks!