Add another alternative: user-facing sharding (#2)

neps/nep-0481.md

@@ -157,6 +157,23 @@ Cons:
 - Handling traps in submodules is likely to be more challenging when the submodule is executed in the same virtual machine as the parent.
 - In some programming languages similar `eval` functions have a notoriously bad reputation, see for instance [Python](https://stackoverflow.com/questions/1832940/why-is-using-eval-a-bad-practice/1832957#1832957) and [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval#never_use_eval!).
 
+### User-facing sharding
+
+The purpose of namespaces in this proposal is to ensure all state and code needed for the synchronous execution is co-located in the same shard. In Near's current design sharding is invisible to users in the sense that all accounts appear to be on separate shards (and therefore only asynchronous calls are possible between accounts). However, in practice there are many accounts on the same shard and if this information was surfaced to users then synchronous calls could be possible between those co-located accounts. The only thing that would change about this proposal is that namespaces would no longer be necessary and therefore it would no longer depend on NEP-480.
+
+Pros:
+
+- Proposal becomes independent of NEP-480.
+- More use cases are possible because synchronous calls can extend beyond a single account.
+
+Cons:
+
+- Many open questions about how sharding should be exposed to users. Examples:
+    - Should we change the sharding boundaries? Today shards are split (somewhat arbitrarily) based on lexicographical ordering of the account IDs, but if users know about sharding should they be allowed to choose what shard the account exists on when it is created? Should a sub-account be located in the same shard as its parent by default?
+    - Should it be possible to move an account from one shard to another?
+    - How will new shards be introduced in the future without breaking user contracts (which may rely on the details of shard boundaries)? Would new shards simply be empty? Could an existing shard be split based on data about synchronous calls?
+- May reduce the effectiveness of Near's sharding solution if users intentionally co-locate to a specific shard (e.g. because it contains a popular contract).
+
 ## Drawbacks
 
 ### Disallowing recursive synchronous calls