diff --git a/apps/nextra/pages/en/build/_meta.tsx b/apps/nextra/pages/en/build/_meta.tsx index 0ea47ec60..e1b42a0f8 100644 --- a/apps/nextra/pages/en/build/_meta.tsx +++ b/apps/nextra/pages/en/build/_meta.tsx @@ -7,4 +7,5 @@ export default { cli: "CLI", "create-aptos-dapp": "create-aptos-dapp", guides: "Guides", + aips: "Aptos Improvement Proposals (AIPs)", }; diff --git a/apps/nextra/pages/en/build/aips/_meta.tsx b/apps/nextra/pages/en/build/aips/_meta.tsx new file mode 100644 index 000000000..8f0b932de --- /dev/null +++ b/apps/nextra/pages/en/build/aips/_meta.tsx @@ -0,0 +1,4 @@ +export default { + overview: "Overview", + "aip-115": "AIP-115 - Stateless Accounts", +}; diff --git a/apps/nextra/pages/en/build/aips/aip-115.mdx b/apps/nextra/pages/en/build/aips/aip-115.mdx new file mode 100644 index 000000000..fb3a0498b --- /dev/null +++ b/apps/nextra/pages/en/build/aips/aip-115.mdx @@ -0,0 +1,136 @@ +--- +title: AIP-115 - Stateless Accounts +--- + +# AIP-115: Stateless Accounts + +[AIP-115](https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-115.md) covers +stateless accounts. + +## General FAQ +### What is a Stateless Account? + +A Stateless Account is a new behavior for Aptos accounts that allows them to +operate without requiring an explicitly created `0x1::account::Account` resource. +Instead, these accounts use default behaviors until an action necessitates the +creation of the resource. This change simplifies account management and reduces +unnecessary resource creation, making it easier for developers and users to +interact with the Aptos blockchain. + +### How is it different from a regular account? + +Technically, there is no separate account type. All accounts are the same under +the hood. The difference is that accounts without a resource behave in a +"stateless" manner using default values. The account resource is only created +on-demand when needed. + +### How does it work? + +When an account signs its first transaction sequence number transaction, it +will not have the `0x1::account::Account` resource created. Instead, it will +create the `0x1::account::Account` resource only when an action that requires to +increment the sequence number. + +For an orderless transaction, the account resource is not needed at all, and the +account resource will not be created. + +## Technical Details FAQ + +### What is the default auth_key for Stateless Accounts? + +If the `0x1::account::Account` resource does not exist, the auth_key defaults to +the account address itself. This allows the account to sign and submit +transactions without needing a resource. + +### What is the sequence number of a Stateless Account? + +It defaults to `0` if the account resource does not exist. In the future, with +Orderless Transactions, the sequence number may be eliminated entirely. + +### When is the account resource automatically created? + +The resource is created when an action that requires on-chain state, such as: +- Rotating the authentication key +- Using capabilities or features that rely on the account resource such as sequence number +- Explicitly calling functions that access fields in the account resource + +### Does creating the account resource incur extra gas cost? + +Yes. The creation of the resource is deferred, and the corresponding gas and +storage fees are only charged at the moment of actual creation, not beforehand. + +### Any behavior change to account module at the Move level? + +`0x1::account::exists_at` always returns true, as all on-chain account addresses +are considered valid and treated as existing by default. There is no move +function in the module to check whether the underlying account resource really +exists since the goal is to make it transparent to users. As a result, any logic +that first checks whether an account exists before attempting to create it is +now obsolete. + +### Can users force-create the account resource upfront? + +Yes. Users can explicitly call functions like +`0x1::account::create_account_if_does_not_exist` to create the resource +manually, if desired. + +### Any behavior change to API? + +If you rely on the following API behavior, please adjust correspondingly. +`GET /accounts/{address}` will never return “404 not found” but the default +authentication key and sequence number mentioned above for stateless accounts. +Therefore, if it is desired to check whether the account resource exists or not, +try `GET /accounts/{address}/resource/0x1::account::Account` + +### Do existing accounts get affected? + +No. Existing accounts with resources already created will continue to work +exactly as they do now. Stateless Account behavior only applies to accounts that +have not yet created a resource. + + +### Do dApps / CEX need to change anything? + +Maybe. Previously, checking whether an account existed often relied on calling +APIs that return a 404 error if the account resource was not found. Applications +would then use this as a signal to warn users (e.g., "This account does not +exist"). Under the new model, all addresses are considered valid, and such +404-based existence checks are no longer reliable or meaningful. However, we are +not banning this pattern—developers may still choose to warn users that an +account may not have performed any on-chain activity and thus might not have a +resource created yet. + +If you still want to detect whether an account has an associated resource, you +can refer to the method described in Q9 or check whether the sequence_number is +0. But be aware that with the introduction of orderless transactions, some +accounts may only submit transactions that never create a resource, which could +result in false negatives. + +We recommend designing your application to be robust regardless of whether the +account resource exists, and to avoid assuming resource presence as a proxy for +account existence. + +Examples: +- A wallet might check for an account to see if it’s a new account, and provide +a user a warning. With this change, instead a mitigation like Q9 will be needed. +- A custodial wallet may send funds to initialize an account with gas. With +this change, it will need to check the account’s balance instead of just the +account existing. + +### Is this compatible with Orderless Transactions? + +Yes. Orderless Transactions and Stateless Accounts are complementary. Once +Orderless Transactions are enabled, sequence numbers will no longer be needed, +enabling truly stateless usage. + +## Will all accounts become Stateless in the future? + +No. Stateless Accounts are not a new account type. It simply allows accounts to +behave with default logic until the account resource is needed. This lazy +resource creation, does not transform existing account state. All accounts can +behave in a stateless way by default, but they will still create the standard +resource if and when advanced features are used. + + + + diff --git a/apps/nextra/pages/en/build/aips/overview.mdx b/apps/nextra/pages/en/build/aips/overview.mdx new file mode 100644 index 000000000..dd1bc8f1e --- /dev/null +++ b/apps/nextra/pages/en/build/aips/overview.mdx @@ -0,0 +1,27 @@ +--- +title: Overview +--- + +# Aptos Improvement Proposals (AIPs) Overview + +Aptos Improvement Proposals (AIPs) are a way for the Aptos community to propose +changes, improvements, and new features to the Aptos protocol. AIPs are designed +to be a collaborative process that allows anyone in the community to contribute +ideas and feedback. + +AIPs are documented in the [AIPs repository](https://github.com/aptos-foundation/AIPs) +and are administered by the Aptos Foundation. Each AIP is assigned a unique +number and goes through a rigorous review process before it is accepted or rejected. + +## What do AIPs cover? + +AIPs can cover a wide range of topics, including: +- Node protocol changes - Mempool changes, consensus changes, etc. +- Framework (smart contract) changes - New modules, new functions, etc. +- Governance changes - Changes to the way the Aptos Foundation operates, changes +to the way AIPs are processed, etc. + +## What is this section of the docs mostly about? + +This section of the docs is mostly about AIPs that are relevant to developers +and providing FAQs and quick information about them.