first work in progress implementation of the UDC
14 Likes
exitos !!!
10 Likes
Nice job. I’d argue that it’s just much, much better to have contract deployment functionality built inside the account contract standard. But I guess this is the best we can do right now.
10 Likes
i’m curious, how is it better?
11 Likes
I mean for many of us that have been around in the ecosystem for quite a while it doesn’t make much of a difference, but not being able to deploy contracts directly from an account might surprise anyone from say Ethereum.
And this is not even a technical limitation. It’s just artificially left out of the account standard.
While I agree that having a small attack surface is nice, this is gonna be a very very thin wrapper around the syscall so I don’t really see a lot of risk there…
10 Likes
I don’t think that’s the case, you still do it through your account. The user can’t tell whether it’s implemented in the account or an external library/contract.
Consider that all transactions, even the ones targeting the account contract, are built as an external function call.
9 Likes
I think the UDC should support deploying accounts at the same address as if the account was deployed using the deploy account transaction that will be introduced in 0.10.1. This would make it possible to sponsor the deployment of accounts without introducing some censorship vector.
See Add deployer preset by martriay · Pull Request #467 · OpenZeppelin/cairo-contracts · GitHub
12 Likes
I hope this gets standardized sooner, and have a canonical deployment on each network.
The deploy transaction type will be deprecated soon, and we need a new way for (SDK) users to deploy contracts just as easy. With this standardized and deployed, we can simply hard-code the universal deployer address into the SDKs and users can just deploy mostly as they did before, except now having to do through an account.
9 Likes
Agree.
The PR is in its final stage, please review!
10 Likes
Does this mean that a call to get_caller_address() in the constructor will always return UDC address and if I will want to ogranize access control based on deployer address it will need to be passed via constructor arguments?
7 Likes
Yes, although if you really wanted to bypass that I guess you could do a library call (i.e. delegatecall).
7 Likes
From an account contract?
7 Likes
That’s what i meant, yes
9 Likes
Is it possible with current account implementations?
I would need to do a delegate call from account contract to the UDC. Similar to what good old DSProxy does: ds-proxy/proxy.sol at 20a0e4b13d7f5ff1fd3bcfce4b821db5ee8c5978 · dapphub/ds-proxy · GitHub.
@martriay
7 Likes
no, currently it’s not. it was a theoretical possibility but i would actually recommend passing the address as a parameter.
8 Likes
As brought up by @FabijanC, I forgot to specify a salt value to complete the standard deployment setup. I assumed but never wrote, it should be 0 and the resulting address is 0x041a78e741e5af2fec34b695679bc6891742439f7afb8484ecd7766661ad02bf
9 Likes
(get_caller_address) isn’t 0
Maybe even should be checked?
8 Likes
what do you mean? checked where and for what?
8 Likes
Since the UDC needs to be updated to Cairo 1+ before regenesis, I propose the following changes for the upcoming canonical version (UDC v2):
- Following latest Cairo dev practices, use snake_case instead of camelCase
- Rename
unique, a very confusing argument name, tofrom_zero, which is more straightforward and transparent about its meaning and effects. The only drawback of this approach is that events in the new UDC will have a significant semantics change, since the same event that loggedtrueforuniquewill logfalsewithfrom_zero. This can be slightly confusing for anyone comparing v1 and v2 events, but I think it’s worth the clarity gain.
You can track the change in this commit.