-
Notifications
You must be signed in to change notification settings - Fork 190
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs: Updated content on deploying a new account. (#1163)
* Updated content on deploying a new account. * SME comments. * SME comments
- Loading branch information
Showing
3 changed files
with
36 additions
and
70 deletions.
There are no files selected for viewing
This file contains 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
102 changes: 33 additions & 69 deletions
102
...et/modules/architecture_and_concepts/pages/Accounts/deploying_new_accounts.adoc
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,83 +1,47 @@ | ||
[id="deploying_new_accounts"] | ||
= Deploying new accounts | ||
= Deploying a new account | ||
|
||
Starknet provides the `deploy_account` transaction in order to deploy new accounts to the | ||
network. | ||
You can deploy a new account in the following ways: | ||
|
||
== Deploy account transaction | ||
* Send a `DEPLOY_ACCOUNT` transaction. This method does not require a preexisting account. | ||
* Using the Universal Deployer Contract (UDC). This method requires an existing account to send the `INVOKE` transaction. | ||
|
||
In order to deploy a new account on StarkNet you need to complete the following steps: | ||
Upon receiving one of these transactions, the sequencer performs the following steps: | ||
|
||
* Decide on the account contract that you want to deploy | ||
* Compute your would-be account address off-chain | ||
* Send funds to this address | ||
|
||
Once the address has enough funds to pay for the deployment, you can then send a `deploy_account` transaction. | ||
|
||
== Transaction flow | ||
|
||
Upon receiving a `deploy_account` transaction, the sequencer will: | ||
|
||
* Verify that the address has funds to pay for the deployment | ||
* Execute the constructor with the given arguments | ||
* Execute the `+__validate_deploy__+` entry point (See below) | ||
* Charge fee from the new account address | ||
* Advance the nonce to 1 | ||
|
||
== Validate deploy | ||
|
||
Two issues might arise from sending a `deploy_account` transaction without any extra validation: | ||
|
||
* Sequencers having the ability to charge arbitrarily high fees, thus potentially draining user funds from a pre-funded account | ||
* A bad actor having the ability to carry out a sequencer DOS attack by sending multiple, invalid `deploy_account` transactions. This would result in the sequencer not being compensated for work completed. | ||
|
||
|
||
To prevent the scenario described in the first point, a new optional validation entrypoint is provided: `+__validate_deploy__+`. | ||
|
||
To prevent the potential DOS attack from the second point, we introduce some limitations on the constructor and `+__validate_deploy__+` | ||
_ executions, namely: | ||
|
||
* Limited # of Cairo steps | ||
* Limited # of builtin applications | ||
* No external contract calls (library calls and self-calls are allowed) | ||
|
||
This entrypoint should be included in any accounts or contracts that wish to allow this new deployment flow. | ||
. Runs the respective validation function in the contract, as follows: | ||
** When deploying with the `DEPLOY_ACCOUNT` transaction type, the sequencer executes the `+__validate_deploy__+` function in the deployed contract. | ||
** When deploying using the UDC, the sequencer executes the `+__validate__+` function in the contract of the sender's address. | ||
. Executes the constructor with the given arguments. | ||
. Charges fees from the new account address. | ||
+ | ||
[NOTE] | ||
==== | ||
If you use a `DEPLOY_ACCOUNT` transaction, the fees are paid from the address of the deployed account. If you use the UDC, which requires an `INVOKE` transaction, the fees are paid from the sender's account. For information on the differences between V1 and V3 `INVOKE` transactions, see xref:architecture_and_concepts/Network_Architecture/transactions.adoc#invoke_transaction[`INVOKE` transaction] in _Transaction types_. | ||
==== | ||
. Sets the account's nonce as follows: | ||
** `1`, when deployed with a `DEPLOY_ACCOUNT` transaction | ||
** `0`, when deployed with the UDC | ||
|
||
=== Using validate deploy | ||
== Deploying a new account with Starkli | ||
|
||
`+__validate_deploy__+` expects the following arguments: | ||
Starkli simplifies account creation, whether you create an account as a Starknet wallet account, or using the UDC. | ||
|
||
* class hash | ||
* contract address salt | ||
* constructor arguments - the arguments expected by the contract’s constructor (this will be enforced in the compiler). | ||
To create and deploy a new account, use Starkli's `starkli account` command. | ||
|
||
[NOTE] | ||
==== | ||
In determining the contract address, deployer address 0 will be used. | ||
==== | ||
For more information on creating a new account as a Starknet wallet account with a `DEPLOY_ACCOUNT` transaction, or by using the UDC with an `INVOKE` transaction , see link:https://book.starkli.rs/accounts[Accounts] in the Starkli Book. | ||
|
||
Consider an account with the following constructor signature: | ||
[#DEPLOY_ACCOUNT_restrictions] | ||
== `DEPLOY_ACCOUNT` constructor restrictions | ||
|
||
[#constructor_signature] | ||
[source,cairo] | ||
---- | ||
@constructor | ||
func constructor{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}( | ||
_public_key: felt | ||
) | ||
---- | ||
The constructor of the `DEPLOY_ACCOUNT` transaction has the following limitations: | ||
|
||
Then the signature of `+__validate_deploy__+` must be: | ||
* Restricted access to `sequencer_address` in the `get_execution_info` syscall. The syscall returns zero values for `sequencer_address` | ||
* Restricted access to the following syscalls: | ||
** `get_block_hash` for Cairo contracts | ||
** `get_sequencer_address` for Cairo 0 contracts | ||
|
||
[#call_validate_deploy] | ||
[source,cairo,sub="quotes"] | ||
---- | ||
func __validate_deploy__{ | ||
syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr, ecdsa_ptr: SignatureBuiltin* | ||
}(class_hash: felt, contract_address_salt: felt, _public_key: felt) | ||
---- | ||
== Additional resources | ||
|
||
[NOTE] | ||
==== | ||
The transaction hash and `max_fee` are accessible through the `get_tx_info` system call. | ||
==== | ||
* link:https://book.starkli.rs/accounts[Accounts] in the Starkli Book | ||
* xref:Accounts/universal-deployer.adoc[] | ||
* xref:Network_Architecture/transactions.adoc[] |
File renamed without changes.