-
Notifications
You must be signed in to change notification settings - Fork 76
Deploy through Accounts #276
Changes from 29 commits
3ea6b8d
0dc42e5
4d60c2a
7e93f8c
c06dd64
f061781
f9166bc
7b6b9af
2dba075
6d3897b
a6e919f
ae32dba
7a4b484
b88b44d
f648d89
9969311
bf3ea83
d969342
dba3394
9856871
34704c7
953e831
8777ed0
6281b3c
2f62263
3cface7
a53ec32
f41c22e
ce03ca1
048568e
bb949c6
24f396a
9d6b9e5
08cd4f2
7c97c42
4df6e18
21e85eb
a480804
765a7c2
f544ad5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,8 +1,19 @@ | ||
"""Command to deploy StarkNet smart contracts.""" | ||
import logging | ||
|
||
from starkware.cairo.common.hash_chain import compute_hash_chain | ||
from starkware.starknet.core.os.contract_address.contract_address import ( | ||
calculate_contract_address_from_hash, | ||
) | ||
|
||
from nile import deployments | ||
from nile.common import ABIS_DIRECTORY, BUILD_DIRECTORY, parse_information, run_command | ||
from nile.common import ( | ||
ABIS_DIRECTORY, | ||
BUILD_DIRECTORY, | ||
get_class_hash, | ||
parse_information, | ||
run_command, | ||
) | ||
from nile.utils import hex_address | ||
from nile.utils.status import status | ||
|
||
|
@@ -17,8 +28,12 @@ def deploy( | |
mainnet_token=None, | ||
watch_mode=None, | ||
): | ||
"""Deploy StarkNet smart contracts.""" | ||
logging.info(f"🚀 Deploying {contract_name}") | ||
"""Deploy StarkNet smart contracts (DEPRECATED).""" | ||
logging.info( | ||
f"🚀 Deploying {contract_name} without Account. " | ||
+ "This method is deprecated and will be removed soon. " | ||
+ "Use the --account option." | ||
) | ||
base_path = ( | ||
overriding_path if overriding_path else (BUILD_DIRECTORY, ABIS_DIRECTORY) | ||
) | ||
|
@@ -47,3 +62,60 @@ def deploy( | |
return | ||
|
||
return address, register_abi | ||
|
||
|
||
def deploy_contract( | ||
account, | ||
contract_name, | ||
salt, | ||
unique, | ||
calldata, | ||
alias, | ||
deployer_address, | ||
max_fee, | ||
overriding_path=None, | ||
abi=None, | ||
watch_mode=None, | ||
): | ||
"""Deploy StarkNet smart contracts.""" | ||
logging.info(f"🚀 Deploying {contract_name}") | ||
|
||
base_path = ( | ||
overriding_path if overriding_path else (BUILD_DIRECTORY, ABIS_DIRECTORY) | ||
) | ||
register_abi = abi if abi is not None else f"{base_path[1]}/{contract_name}.json" | ||
deployer_for_address_generation = 0 | ||
|
||
if unique: | ||
# Match UDC address generation | ||
salt = compute_hash_chain(data=[account.address, salt]) | ||
deployer_for_address_generation = deployer_address | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do you think about including a random salt generator for deployments without Otherwise, trying to deploy multiple instances of the same contract will result in:
Users can add There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we agree^, I definitely suggest adding some salt tests There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this salt should be part of the protocol (like nonce in Ethereum deployments), but I am not sure why it is left to be passed from the end users (am I missing an important reason?). With this said, agreeing on a format for the automatic generation of this salt, I think, is content enough for another issue/PR. Shouldn't be any problem with releasing this version, right? I don't see a reason to delay it to another milestone. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I agree in general haha but since we're deploying contracts through an
That sounds reasonable to me
I don't disagree |
||
|
||
# This needs to be fixed following the Hex/Int Pattern | ||
martriay marked this conversation as resolved.
Show resolved
Hide resolved
|
||
class_hash = int(get_class_hash(contract_name=contract_name), 16) | ||
|
||
address = calculate_contract_address_from_hash( | ||
salt, class_hash, calldata, deployer_for_address_generation | ||
) | ||
|
||
output = account.send( | ||
deployer_address, | ||
method="deployContract", | ||
calldata=[class_hash, salt, unique, len(calldata), *calldata], | ||
max_fee=max_fee, | ||
) | ||
|
||
_, tx_hash = parse_information(output) | ||
logging.info( | ||
f"⏳ ️Deployment of {contract_name} successfully sent at {hex_address(address)}" | ||
) | ||
logging.info(f"🧾 Transaction hash: {hex(tx_hash)}") | ||
|
||
deployments.register(address, register_abi, account.network, alias) | ||
|
||
if watch_mode is not None: | ||
if status(tx_hash, account.network, watch_mode).status.is_rejected: | ||
deployments.unregister(address, account.network, alias, abi=register_abi) | ||
return | ||
|
||
return address, register_abi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
although i like the
--account
flag much better, for consistency with other commands we should use pk aliases#212 partially addresses it. having an
--account
flag is also the way because it would maintain the API even after having default accounts with #73There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i understand this makes much more difficult to identify therefore support both deployments (with/without account), unclear what's best here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My first thought was the same (to follow the same format of send), but as you state, the difference here is that we need to support both with and without account options. Click parameters (instead of options) are not optional (they could be, but with important restrictions I think are not worth to address).
IMO the best approach would be to let account an option in this PR (because it is potentially the desired behavior anyway) and fix (or improve) pk handling later in the issues you mentioned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm not sure about this. "accountless" deployments are already discouraged and will be prohibited soon. UDC-like deployments are already functional, so we don't really need to support it.
i think it's preferable to have a consistent, expectable API than an inconsistent one with perfect/final portions. i think we should aim for consistency and eventually migrate all methods to use
--account
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you suggesting then removing the support for deploys without accounts? If we remove this support, the current starknet-devnet version we support in Nile (pre 0.10.1) won't work for deployments because it has not predeployed UDC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes that's the suggestion, since this release will require [email protected] already. happy to keep the functionality as long as it doesn't compromise API consistency if there's such alternative
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed the API to match the
send
one, but let a--ignore_account
flag to deploy without an account with the deprecation warning until the direct deploys are fully removed.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks, i appreciate the change and i know it's quirky. i asked the starkware team, they expect to remove it by this week.