near · encody · May 12, 2023 · May 12, 2023 · May 12, 2023 · May 12, 2023
@@ -29,6 +29,7 @@ Changes to the protocol specification and standards are called NEAR Enhancement
 | [0399](https://github.com/near/NEPs/blob/master/neps/nep-0399.md) | Flat Storage                             | @Longarithm @mzhangmzz                      | Review |
 | [0448](https://github.com/near/NEPs/blob/master/neps/nep-0448.md) | Zero-balance Accounts                    | @bowenwang1996                              | Final  |
 | [0455](https://github.com/near/NEPs/blob/master/neps/nep-0455.md) | Parameter Compute Costs                  | @akashin @jakmeier                          | Final  |
+| [0480](https://github.com/near/NEPs/blob/master/neps/nep-0480.md) | Account Namespaces                       | @encody                                     | Draft  |
 
 ## Specification
 

@@ -0,0 +1,143 @@
+---
+NEP: 480
+Title: Account namespaces
+Authors: Jacob Lindahl <@encody>, Firat Sertgoz <@firatNEAR>
+Status: Draft
+DiscussionsTo: https://github.com/near/NEPs/pull/480
+Type: Protocol
+Version: 1.0.0
+Created: 2023-05-12
+LastUpdated: 2023-05-12
+---
+
+## Summary
+
+This proposal introduces account namespaces, which enable deploying multiple WASM binaries to a single account. A WASM binary is deployed to a unique, deployer-selected namespace. Subsequent deployments to the same namespace overwrite the code currently deployed to that namespace. The empty namespace is considered the default namespace.
+
+A WASM binary deployed to a non-default (non-empty) namespace can be invoked explicitly by specifying the namespace in the action. If no namespace is specified, the default namespace is used.
+
+State is isolated between namespaces. That is to say, a contract deployed to `alice.near`'s default namespace cannot read or modify the storage of a contract deployed to `alice.near`'s `multisig` namespace. As described by this NEP, interactions between different namespaces can only be facilitated via reflexive function calls.
+
+## Motivation
+
+- Composing contracts is non-trivial. Currently, it is possible to deploy a single smart contract to a NEAR account using a `DEPLOY_CONTRACT` action. Subsequent `DEPLOY_CONTRACT` actions completely replace existing code with new code, while leaving all storage intact.
+
+- It is impossible for a non-developer user to compose multiple contract standards together into a single contract without actually performing some development work. Account namespaces would enable a user workflow wherein a user only needs to choose which contracts to deploy, and not worry about how to compose them.
+
+- If a developer wants their smart contract to be upgradable, they have to manually write the upgrade functionality into their smart contract, and smart contract upgrades are complex, multi-step operations with many security considerations and opportunities to "brick" the account. Namespaces would allow a developer to deploy a semi-standardized upgrade module to a namespace, and have that manage the upgrade process for the other (default, etc.) namespaces.
+
+As this is a part of the [Account Extensions upgrade](https://github.com/near/NEPs/issues/478), some of the benefits of account namespaces are realized in conjunction with other proposals from the upgrade:
+
+- Certain contracts are frequently deployed on different accounts. "Codeless contracts" allow an account to deploy just the hash of a smart contract instead of the full binary. This, in conjunction with namespaces, would allow a user to pick and choose a set of account features to deploy with negligible gas and storage costs.
+
+- Permissions: It could be possible to set permissions on a particular namespace. For example, restricting the namespace `dao_multisig` to interactions with `dao.near` only.
+
+- Synchronous execution. Namespaced contracts on the same account should be able to communicate with each other synchronously instead of asynchronously.
+
+## Specification
+
+### The `Namespace` type
+
+We introduce a new primitive type: `Namespace`. A `Namespace` is a string that contains only lowercase letters, numbers, and underscores. The empty string is considered the default namespace.
+
+### `DeployContract` action
+
+The `DeployContract` action is modified to include a `namespace` field. If the `namespace` field is not specified in an RPC call, the default namespace (the empty string) is used. The attached code is then deployed to the specified namespace.
+
+If code has already been deployed to the specified namespace, it is replaced, leaving code deployed to other namespaces untouched.
+
+Once a namespace is created, this NEP does not provide a way to delete it. However, namespaces should not be considered permanent.
+
+### `FunctionCall` action
+
+The `FunctionCall` action is modified to include a `namespace` field. If the `namespace` field is not specified in an RPC call, the default namespace (the empty string) is used. The function call is then executed on the code deployed to the specified namespace.
+
+### `FunctionCallPermission`
+
+A `namespaces` field is added to `FunctionCallPermission`. This field contains a list of namespaces that the access key is allowed to call. If the `namespaces` field is not specified, the access key is allowed to call all namespaces.
+
+### NEAR VM host functions
+
+The following host functions are added to the NEAR host environment:
+
+- `predecessor_namespace() -> Namespace`: Returns the namespace of the predecessor account, which may be the empty namespace. In the case that the predecessor is not a smart contract, this is the empty namespace.
+- `current_namespace() -> Namespace`: Returns the namespace of the current account, which may be the empty namespace.
+- `namespace_storage_usage(&Namespace) -> u64`: Returns the storage usage of the given namespace. This includes storage consumed by the contract and state, but not account data (e.g. balance, access keys). That is to say,
+
+  $$\verb|storage_usage()| \ge \sum_{n} \verb|namespace_storage_usage| (n)$$
+
+There is no need for a `signer_namespace` function, because a signer is never a smart contract, and can therefore never have a non-empty namespace.
+
+Some existing host functions will need to be updated to include namespaces:
+
+- `promise_batch_action_function_call`: Updated to include namespace.
+- `promise_batch_action_deploy_contract`: Updated to include namespace.
+- etc.
+
+Existing host functions will generally still refer to the account as a whole:
+
+- `storage_usage() -> u64`: Returns the storage usage of the current account, including all namespaces.
+- `account_balance() -> u128`: Returns the entire balance of the current account. There is no namespace-specific accounting.
+
+### RPC view calls
+
+#### `view_account`
+
+The `code_hash` field contains the hash of the code deployed to the default namespace. The `code_hashes` field contains a map of namespaces to code hashes, including the default namespace. (This means that the hash of the code deployed to the default namespace is returned twice. This is intentional, for backwards compatibility.)
+
+#### `view_state`
+
+The `view_state` call now accepts an optional `namespace` field. If it is not specified, the default namespace is used. The `view_state` call is then executed on the state associated with the specified namespace.
+
+#### `view_code`
+
+The `view_code` call now accepts an optional `namespace` field. If it is not specified, the default namespace is used. The `view_code` call then returns the code deployed on the specified namespace.
+
+## Reference Implementation
+
+- https://github.com/near/nearcore/pull/8890
+
+## Security Implications
+
+- Applications that detect smart contract updates by tracking the `code_hash` field from a `view_account` call will fail to account for updates to namespaces. (Note that the correct way to track code changes is by monitoring the blockchain for `DeployContract` actions targeting the account, not by tracking `code_hash`.)
+- As described by this NEP, namespaces all have full permission to act on behalf of the account, just as any smart contract.
+- If a namespaced contract interacts with a legacy contract (unaware of namespaces), it is possible that the legacy contract may save the account ID of the namespaced contract, but not the namespace. If the legacy contract subsequently attempts to interact with the namespaced contract, it will only be able to interact with the contract deployed to the default namespace instead. However, this is equivalent to the case in which an non-contract account signs the same set of actions to the legacy contract.
+
+## Drawbacks (Optional)
+
+## Unresolved Issues (Optional)
-## Drawbacks (Optional)
-
-## Unresolved Issues (Optional)
+## Drawbacks
+
+## Unresolved Issues
-## Drawbacks (Optional)
-
-## Unresolved Issues (Optional)
+## Drawbacks
+
+## Unresolved Issues
+
+- How to delete a namespace?
+- How to enumerate namespaces from within a smart contract?
+- Backwards compatibility issues could be resolved with a per-account routing table that maps incoming method names to a [namespace, method name] pair.
+
+## Alternatives
+
+- Only using a routing table. However, this increases complexity for end-users significantly.
+
+## Future possibilities
+
+- Sync execution between namespaces.
+- Permissioned namespaces.
+- Codeless contracts / contract subscriptions / global contracts.
+
+See [the Account Extensions upgrade master issue](https://github.com/near/NEPs/issues/478).
+
+## Changelog
+
+### 1.0.0 - Initial Version
+
+#### Benefits
+
+- Easier contract composability, e.g. just deploy the NEP-141 and NEP-330 modules and you’re set. Good for developers (esp. w.r.t. contract factories) and non-developer users (one-click deploy composable modules).
+- Safer and easier contract upgrades, e.g. have an upgrade_controller namespace that manages upgrading the rest of the contract’s components, so a bad upgrade doesn’t brick the account.
+
+#### Concerns
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## References
+
+- https://gov.near.org/t/proposal-account-extensions-contract-namespaces/34227