docs: Add limitations to __validate__ function and other improvements to Accounts section

[stoobie]

Description of the Changes

• Add limitations to validate function

Currently the section Validate limitations doesn't actually list the limitations. This PR fixes that.

PR Preview URL

Starknet account structure
Account functions

I moved the info deploying new accounts to PR#1163.

Check List

• Changes have been done against dev branch, and PR does not conflict
• PR title follows the convention: <docs/feat/fix/chore>(optional scope): <description>, e.g: fix: minor typos in code

---

This change is 

[github-actions]

Your preview build is ready! ✨ Check the following link in 1-2 minutes: https://starknet-io.github.io/starknet-docs/pr-945/documentation/ .

[github-actions]

Your preview build is ready! ✨ Check the following link in 1-2 minutes: https://starknet-io.github.io/starknet-docs/pr-945/documentation/ .

[github-actions]

Your preview build is ready! ✨ Check the following link in 1-2 minutes: https://starknet-io.github.io/starknet-docs/pr-945/documentation/ .

[github-actions]

Your preview build is ready! ✨ Check the following link in 1-2 minutes: https://starknet-io.github.io/starknet-docs/pr-945/documentation/ .

[github-actions]

Your preview build is ready! ✨ Check the following link in 1-2 minutes: https://starknet-io.github.io/starknet-docs/pr-945/documentation/ .

[github-actions]

Your preview build is ready! ✨ Check the following link in 1-2 minutes: https://starknet-io.github.io/starknet-docs/pr-945/documentation/ .

[github-actions]

Your preview build is ready! ✨ Check the following link in 1-2 minutes: https://starknet-io.github.io/starknet-docs/pr-945/documentation/ .

[github-actions]

Your preview build is ready! ✨ Check the following link in 1-2 minutes: https://starknet-io.github.io/starknet-docs/pr-945/documentation/ .

[github-actions]

Your preview build is ready! ✨ Check the following link in 1-2 minutes: https://starknet-io.github.io/starknet-docs/pr-945/documentation/ .

[stoobie]

Reviewable status: 0 of 8 files reviewed, 27 unresolved discussions (waiting on @ArielElp and @odednaor)

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/deploying_new_accounts.adoc line 14 at r10 (raw file):

Previously, ArielElp wrote…

agree, suggested starkli

Done. I just said to use Starkli, with a reference to the specific page in the Starkli Book.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/deploying_new_accounts.adoc line 71 at r10 (raw file):

Previously, ArielElp wrote…

an updated example:

  fn __validate_deploy__(
      self: @ComponentState<TContractState>,
      class_hash: felt252,
      contract_address_salt: felt252,
      public_key: felt252
  ) -> felt252

#[constructor]
fn constructor(ref self: ContractState, public_key: felt252)

(ignore the component state / contractstate arguments)

Done. This is now in

[github-actions]

Your preview build is ready! ✨ Check the following link in 1-2 minutes: https://starknet-io.github.io/starknet-docs/pr-945/documentation/ .

[stoobie]

Reviewable status: 0 of 8 files reviewed, 27 unresolved discussions (waiting on @ArielElp and @odednaor)

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/deploying_new_accounts.adoc line 26 at r10 (raw file):

Previously, odednaor wrote…

@ArielElp Please verify this section

Done.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/deploying_new_accounts.adoc line 43 at r10 (raw file):

Previously, ArielElp wrote…

It is mandatory if you want to deploy the account with a deploy_account transaction. This is not a choice, "you" can't and shouldn't prevent DoS, it's the protocol's job of taking care that there are no open DOS vectors. This potential DoS are the reason we are restricting validate_deploy and the constructor during the execution of a deploy_account transaction.

Replace this sentence (and the limitation description below) with:
The requirement to pass validate_deploy after the constructor execution as a prerequisite for charging fees solves 1, and the limitations on validate execution [link to the new limitation section I suggested above] solves 2.

I rewrote this. PTAL.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/deploying_new_accounts.adoc line 32 at r12 (raw file):

Previously, ArielElp wrote…

"Cairo contracts" is weird because all contracts are Cairo, I would say:

1. get_block_hash
2. get_sequencer_address (only exists for Cairo 0 contracts)

Also, replace restricted with "the following syscalls are not callable"

Done.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/deploying_new_accounts.adoc line 38 at r12 (raw file):

Previously, ArielElp wrote…

Replace this sentence with "We need to make sure that the account deployment flow is not open to either of the two following attack vectors"

Take a look now.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/deploying_new_accounts.adoc line 41 at r12 (raw file):

Previously, ArielElp wrote…

invalid --> invalid (due to constructor or validate_deploy failing)

Done.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/deploying_new_accounts.adoc line 63 at r12 (raw file):

Previously, ArielElp wrote…

The compiler enforces that the inputs to the constructor are identical to the rest of the inputs for validate_deploy.

Done.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/deploying_new_accounts.adoc line 67 at r12 (raw file):

Previously, ArielElp wrote…

Link to contract address computation page

What is the address?

[ArniStarkware]

Reviewable status: 0 of 8 files reviewed, 36 unresolved discussions (waiting on @ArielElp, @odednaor, and @stoobie)

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 17 at r15 (raw file):

| `+__execute__+` | Alway required
| `+__validate_declare__+` | Required for a contract to be able to send a `DECLARE` transaction.
| `+__validate_deploy__+` | Required when deploying an account with a `DEPLOY_ACCOUNT` _transaction_.

by this I mean the Cairo contract we are discussing, which has these functions.

Suggestion:

Required when deploying an instance of this account with a `DEPLOY_ACCOUNT` _transaction_.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 20 at r15 (raw file):

|===

When the sequencer receives a transaction request, it calls the corresponding validation function with the fields of the transaction request. For an `INVOKE` transaction, after successfully completing validation, the sequencer calls the `+__execute__+` function with the fields of the transaction request.

I wrote a whole comment starting with: Might be out of scope... and then I saw this is already written.

Do you want to write something similar about Deploy Account? The issue is that the order is reversed here.

Suggestion:

For an `INVOKE` transaction, after successfully completing validation, the sequencer calls the `+__execute__+` function with the fields of the transaction request.
For a `DEPLOY_ACCOUNT` transaction, the sequencer calls the `+constructor+` function with the fields of the transaction request. Then, after successfully completing validation, the deployment is finalized.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 23 at r15 (raw file):

* For more information on the available transaction types and their fields, see xref:architecture_and_concepts:Network_Architecture/transactions.adoc[Transaction types].
* For more information on the validation and execution stages, see xref:architecture_and_concepts:Network_Architecture/transaction-life-cycle.adoc[Transaction lifecycle].

Might be out of scope for this PR, but, I followed this link.
It has: The high-level steps in the Starknet transaction lifecycle are as follows:

In Item 2. of this list, it lists for each transaction which validate function is run by the account contract.
In Item 4. of this list, it is simply stated that the transaction has been executed. This can be expanded upon. Invoke -> __execute__ , Deploy account -> __constructor__, Declare -> Does not make a code in the calling account contract run.

Code quote:

* For more information on the validation and execution stages, see xref:architecture_and_concepts:Network_Architecture/transaction-life-cycle.adoc[Transaction lifecycle].

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 45 at r15 (raw file):

* `+__validate__+`, `+__validate_deploy__+`, and `+__validate_declare__+`
* A constructor, when run in a `DEPLOY_ACCOUNT` transaction. That is, if an account is deployed from an existing class via the `deploy` syscall, the constructor can run differently. #Isn't  this scenario run in an `INVOKE` transaction?#

Suggestion:

That is, if an account is deployed from an existing class via the `deploy` syscall, these limitations do not apply.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 45 at r15 (raw file):

* `+__validate__+`, `+__validate_deploy__+`, and `+__validate_declare__+`
* A constructor, when run in a `DEPLOY_ACCOUNT` transaction. That is, if an account is deployed from an existing class via the `deploy` syscall, the constructor can run differently. #Isn't  this scenario run in an `INVOKE` transaction?#

Exactly! This is also the explanation for the reason these limitations do not apply.

Code quote:

#Isn't  this scenario run in an `INVOKE` transaction?#

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 59 at r15 (raw file):

* The maximum number of computational steps, measured in Cairo steps, for a validation function is 1,000,000.
* A builtin can be applied a limited number of times. #What's the limit?#

I am not sure. It might be different for each builtin.

Code quote:

 #What's the limit?#

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 60 at r15 (raw file):

* The maximum number of computational steps, measured in Cairo steps, for a validation function is 1,000,000.
* A builtin can be applied a limited number of times. #What's the limit?#
* Access is restricted to `sequencer_address` in the `get_execution_info` syscall. The syscall returns zero values for `sequencer_address`.

Suggestion:

* Access is restricted to `sequencer_address` in the `get_execution_info` syscall. The syscall returns zero values for `sequencer_address`.
* The values of `block_number` and `block_timestamp` in the `get_execution_info` syscall are modified #see our last discussion.#

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 67 at r15 (raw file):

[NOTE]
====
#Is this note obsolete?#

Are you asking because we wrote a few lines ago about The maximum number of computational steps?

Yes, I think you are right - and that is the same point. The upside of this note is it explains some rational.

Code quote:

#Is this note obsolete?#

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 77 at r15 (raw file):

When the `+__validate__+`, `+__validate_deploy__+`, or `+__validate_declare__+`, function fails, the account in question does not pay any fee.

#Is the transaction reverted?#

I think it gets the status REJECTED.. but not sure...

Code quote:

#Is the transaction reverted?#

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 120 at r15 (raw file):

_Always required_

Initiates the validation stage in the sequencer. Validates the sender's address. The sequencer calls this function upon receiving any transaction.

I am not sure this sentence is necessary.

Suggestion:

The sequencer calls this function upon receiving any INVOKE transaction.

[github-actions]

Your preview build is ready! ✨ Check the following link in 1-2 minutes: https://starknet-io.github.io/starknet-docs/pr-945/documentation/ .

[github-actions]

Your preview build is ready! ✨ Check the following link in 1-2 minutes: https://starknet-io.github.io/starknet-docs/pr-945/documentation/ .

[stoobie]

Reviewable status: 0 of 37 files reviewed, 36 unresolved discussions (waiting on @ArielElp, @ArniStarkware, and @odednaor)

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 17 at r15 (raw file):

Previously, ArniStarkware (Arnon Hod) wrote…

by this I mean the Cairo contract we are discussing, which has these functions.

Done.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 20 at r15 (raw file):

Previously, ArniStarkware (Arnon Hod) wrote…

I wrote a whole comment starting with: Might be out of scope... and then I saw this is already written.

Do you want to write something similar about Deploy Account? The issue is that the order is reversed here.

Done.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 23 at r15 (raw file):

Previously, ArniStarkware (Arnon Hod) wrote…

Might be out of scope for this PR, but, I followed this link.
It has: The high-level steps in the Starknet transaction lifecycle are as follows:

In Item 2. of this list, it lists for each transaction which validate function is run by the account contract.
In Item 4. of this list, it is simply stated that the transaction has been executed. This can be expanded upon. Invoke -> __execute__ , Deploy account -> __constructor__, Declare -> Does not make a code in the calling account contract run.

OK. PTAL.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 45 at r15 (raw file):

Previously, ArniStarkware (Arnon Hod) wrote…

Exactly! This is also the explanation for the reason these limitations do not apply.

Done.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 45 at r15 (raw file):

* `+__validate__+`, `+__validate_deploy__+`, and `+__validate_declare__+`
* A constructor, when run in a `DEPLOY_ACCOUNT` transaction. That is, if an account is deployed from an existing class via the `deploy` syscall, the constructor can run differently. #Isn't  this scenario run in an `INVOKE` transaction?#

Done.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 59 at r15 (raw file):

Previously, ArniStarkware (Arnon Hod) wrote…

I am not sure. It might be different for each builtin.

Oh yeah, now that you mention it, we have a page that lists these limits. I'll add an xref.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 67 at r15 (raw file):

Previously, ArniStarkware (Arnon Hod) wrote…

Are you asking because we wrote a few lines ago about The maximum number of computational steps?

Yes, I think you are right - and that is the same point. The upside of this note is it explains some rational.

OK. I removed the note.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 120 at r15 (raw file):

Previously, ArniStarkware (Arnon Hod) wrote…

I am not sure this sentence is necessary.

For me, this sentence is necessary. Fixed.

[stoobie]

Reviewable status: 0 of 37 files reviewed, 36 unresolved discussions (waiting on @ArielElp, @ArniStarkware, and @odednaor)

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 77 at r15 (raw file):

Previously, ArniStarkware (Arnon Hod) wrote…

I think it gets the status REJECTED.. but not sure...

I changed this to:

When the `+__validate__+`, `+__validate_deploy__+`, or `+__validate_declare__+`, function fails, the account in question does not pay any fee, and the transaction's status is `REJECTED`.

[ArniStarkware]

Reviewed 1 of 2 files at r18.
Reviewable status: 1 of 37 files reviewed, 29 unresolved discussions (waiting on @ArielElp, @odednaor, and @stoobie)

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 17 at r15 (raw file):

Previously, stoobie (Steve Goodman) wrote…

Done.

I don't like the use of an account here. It implies that you can use the __validate_deploy__ function written in one contract to validate the deploy account transaction of another contract.

I do realize this does not make sense grammatically and technically.

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 23 at r15 (raw file):

Previously, stoobie (Steve Goodman) wrote…

OK. PTAL.

nice.

---

components/Starknet/modules/architecture_and_concepts/pages/Network_Architecture/transaction-life-cycle.adoc line 19 at r18 (raw file):

. *Sequencer validation:* The sequencer performs preliminary validation on the transaction before executing it to ensure that the transaction is still valid. If the transaction is invalid, it does not proceed.
+
Validation in this context is analogous to Ethereum's signature checking, including running the account's `+__validate__+` function, ensuring that the current account balance exceeds the value of `max_fee` (prior to v3 transactions), and more.

We just talked (through slack) about how confusing this terminology is.

Code quote:

including running the account's `+__validate__+` 

[stoobie]

Reviewable status: 0 of 37 files reviewed, 29 unresolved discussions (waiting on @ArielElp, @ArniStarkware, and @odednaor)

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 17 at r15 (raw file):

Previously, ArniStarkware (Arnon Hod) wrote…

I don't like the use of an account here. It implies that you can use the __validate_deploy__ function written in one contract to validate the deploy account transaction of another contract.

I do realize this does not make sense grammatically and technically.

I added a note to clarify:

[NOTE]
====
You can only use the `+__validate_deploy__+` function in an account contract to validate the `DEPLOY_ACCOUNT` transaction for that same contract.
====

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 60 at r15 (raw file):

* The maximum number of computational steps, measured in Cairo steps, for a validation function is 1,000,000.
* A builtin can be applied a limited number of times. #What's the limit?#
* Access is restricted to `sequencer_address` in the `get_execution_info` syscall. The syscall returns zero values for `sequencer_address`.

Done. I added more details here.

---

components/Starknet/modules/architecture_and_concepts/pages/Network_Architecture/transaction-life-cycle.adoc line 19 at r18 (raw file):

Previously, ArniStarkware (Arnon Hod) wrote…

We just talked (through slack) about how confusing this terminology is.

Changed to:

Validation in this context is analogous to Ethereum's signature checking, including running the account's `+__validate__+`, `+__validate_deploy__+`, or `+__validate_declare__+` function, depending on the type of transaction, ensuring that the current account balance exceeds the value of `max_fee` (prior to v3 transactions), and more.

[ArniStarkware]

Reviewed 1 of 8 files at r13, 2 of 2 files at r19.
Reviewable status: 3 of 37 files reviewed, 27 unresolved discussions (waiting on @ArielElp and @odednaor)

---

components/Starknet/modules/architecture_and_concepts/pages/Accounts/account_functions.adoc line 17 at r15 (raw file):

Previously, stoobie (Steve Goodman) wrote…

I added a note to clarify:

[NOTE]
====
You can only use the `+__validate_deploy__+` function in an account contract to validate the `DEPLOY_ACCOUNT` transaction for that same contract.
====

love it.

[github-actions]

Your preview build is ready! ✨ Check the following link in 1-2 minutes: https://starknet-io.github.io/starknet-docs/pr-945/documentation/ .

[github-actions]

Your preview build is ready! ✨ Check the following link in 1-2 minutes: https://starknet-io.github.io/starknet-docs/pr-945/documentation/ .

[stoobie]

#1198 Replaces this PR.