NEP-485: Shared Ephemeral Storage

README.md

@@ -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  |
+| [0485](https://github.com/near/NEPs/blob/master/neps/nep-0485.md) | Shared Ephemeral Storage                 | @jakmeier @encody @firatNEAR                | Draft  |
 
 ## Specification
 

neps/nep-0485.md

@@ -0,0 +1,105 @@
+---
+NEP: 485
+Title: Shared Ephemeral Storage
+Authors: Jakob Meier <@jakmeier>, Jacob Lindahl <@encody>, Firat Sertgoz <@firatNEAR>
+Status: Draft
+DiscussionsTo: https://github.com/near/NEPs/pull/485
+Type: Protocol
+Version: 1.0.0
+Created: 2023-06-17
+LastUpdated: 2023-06-17
+---
+
+## Summary
+
+This proposal introduces shard-locally shared contract code, which enables accounts to refer to contract hashes of deployed conracts that live in a special storage called Shared Ephemeral Storage (SES). SES has no storage staking cost.
+
+Data in SES is shared between every account on the same shard. It has a limited lifetime before it is deleted. But everytime it is accessed, the lifetime is extended.
+Note: Contracts can modify the state of the account, this state is not shared. Only code is shared. Not the data.
+
+The key for data in SES is the hash of the value. This makes it immutable and allows users to trust the shared state is not unexpectedly mutated by someone else.
+
+## Motivation
+
+- Certain basic functionality contracts such as `Dead Man Switch` or `Multi-Sig` contracts require ~1 NEAR just to cover the storage staking. If a user user is using zero-balance acccounts and meta-transactions to cover costs, it is highly likely that they wouldn't have any NEAR on their accounts.
+
+- There are certain `proxy-contracts` that are deployed over and over again on different accounts for certain apps to function. One example is Keypom, where for trial accounts to work, `0.4N` contract has to be deployed as a `proxy-contract` for all of the trial accounts. This is not sustainable for businesses or individual users.
+
+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:
+
+## Specification
+
+### The `SES` TrieKey
+
+We introduce a new TrieKey: `SES`. It maps code hashes to epoch IDs. This defines when the code "expires" and is updated to "current_epoch +2" every time the code is accessed.
+
+### The `SES` RocksDB Column
+
+The contract code itself lives in a separate RocksDB column, which must also be synced during state sync.
+
+### `DeployContract` action
+
+The `DeployContract` action is modified to include a flag named `is_SES` that would deploy the contract to SES.
+
+### RPC view calls
+
+#### `view_account`
+
+The `view_account` call now also returns a field called `shard_id` that reveals which shard the account lives on.
+
+#### `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)
+
+- 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
+
+## References
+
+- https://gov.near.org/t/proposal-account-extensions-contract-namespaces/34227
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).