alternatives

neps/nep-0508.md

@@ -120,11 +120,14 @@ The transaction pool is sharded e.i. it groups transactions by the shard where e
 ## Alternatives
 
 * Why is this design the best in the space of possible designs?
-  * TBD
+  * This design is the simplest, most robust and safe while meeting all of the requirements. 
 * What other designs have been considered and what is the rationale for not choosing them?
-  * TBD
+  * Splitting the trie by iterating over the boundaries between children shards for each trie record type. This implementation has the potential to be faster but it is more complex and it would take longer to implement. We opted in for the much simpler one using flat storage given it is already quite performant. 
+  * Changing the trie structure to have the account id first and type of record later. This change would allow for much faster resharding by only iterating over the nodes on the boundary. This approach has two major drawbacks. 1) It would require a massive migration. 2) We would need to maintain the old and the new trie structure forever. 
+  * Changing the storage structure by having the storage key to have the format of account_id.node_hash. This structure would make it much easier to split the trie on storage level because the children shards are simple sub-ranges of the parent shard. Unfortunately we found that the migration would not be feasible. 
+  * Changing the storage structure by having the key to have the format of only node_hash. This is a feasible approach but it adds complexity to the garbage collection and data deletion. We opted in for the much simpler one by using the existing scheme of prefixing storage entries by shard uid. 
 * What is the impact of not doing this?
-  * TBD
+  * We need resharding in order to scale up the system. Without resharding eventually shards would grow so big (in either storage or cpu usage) that a single node would not be able to handle it. 
 
 ## Integration with State Sync
 
@@ -144,6 +147,7 @@ As noted above, dynamic resharding is out of scope for this NEP and should be im
 Other useful features that can be considered as a follow up:
 
 * account colocation for low latency across account call
+* removal of shard uids and introducing globally unique shard ids
 * shard on demand
 
 ## Consequences
@@ -164,7 +168,7 @@ Other useful features that can be considered as a follow up:
 ### Negative
 
 * The resharding process is still not fully automated. Analyzing shard data, determining the split boundary, and triggering an actual shard split all need to be manually curated by a person.
-* During resharding, a node is expected to do more work as it will have to apply changes twice (for the current shard and future shard).
+* During resharding, a node is expected to do more work as it will first need to copy a lot of data around the then will have to apply changes twice (for the current shard and future shard).
 * Increased potential for apps and tools to break without proper shard layout change handling.
 
 ### Backwards Compatibility