-
Notifications
You must be signed in to change notification settings - Fork 644
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Contract creation transactions don't specify a salt #326
Comments
One can append random bytes(which won't affect contract initialization process) to the bytecode as salt. |
@pipermerriam @hwwhww @jannikluhn |
I will make the PR that together removes |
What's wrong with reusing |
Since If I understand correct, |
Yes, that check would have to be removed. But it's not necessary anyway, right now |
If I understand correctly, |
Yeah, sorry, |
Reusing One thing different is the length of salt for randomness, would that be an issue? Vote for reusing if we can well-documented that. Also, ping @vbuterin to take a look. By the way, we have to open an issue for renaming |
@hwwhww You can't reuse I can update |
EIP232 proposes an alternate format for transactions which might be the right solution for this. The following is a simplified version of the proposed change.
I know it adds one-more-protocol-change to sharding, but it is also the solution I've seen for handling this issue which will only get worse over time. |
@NIC619 sorry for that I missed one comment...! You're right! |
I'm ok with adding salt into the transaction; either adding it as an extra data field or the EIP 232 approach. |
@pipermerriam I'm not sure I understand how EIP232 would be applied here. Like this:
? What I'd like about this is that we don't ever have any unused fields. What I wouldn't like is that it's called "version", "format" may be better. I think with some changes to |
I'm good with renaming Here is a rough sketch of what I'm thinking of for this. class EIP232Transaction(rlp.Serializable):
fields = (
('version', ...),
('inner_data', sedes.binary),
(
transaction_formats = {
1: TransactionFormatA,
2: TransactionFormatB,
}
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
self.txn_data = rlp.decode(self.inner_data, sedes=self.transaction_formats[self.version])
def __getattr__(self, name):
return getattr(self.txn_data, name) We have an outer transaction class which contains a mapping of version numbers to inner transaction classes. Then, during initialization, we decode the outer data packet, and then lookup the appropriate inner transaction class and use it to decode the inner data packet. Then we put some convenience APIs on the outer class to allow direct property access to the inner transaction properties. |
EIP232 looks like a cleaner and better approach in the long term but I suppose it's not going to be as trivial to implement as adding a |
@NIC619 sounds good to me. |
close via #422 |
What is wrong?
Contract creation transactions don't specify a salt (see https://github.com/ethereum/py-evm/blob/sharding/evm/vm/forks/sharding/vm_state.py#L60-L63). As a result, the address of the created contract is given by the bytecode only and thus it's impossible to deploy the same contract twice.
How can it be fixed
Specify the salt somehow. Potential candidates could be
transaction.code
transaction.data
transaction.to
(which is meaningless for contract creation transactions right now)The text was updated successfully, but these errors were encountered: