On Wednesday Oct 20, testnet was successfully upgraded to four shards through a protocol upgrade that enables simple nightshade. This signals the beginning of Phase 0 of sharding. While there were some hiccups along the way, we have learned from those issues and will try our best to ensure a smooth mainnet launch in mid November. In this post, however, I will focus on the impact of this upgrade on the entire ecosystem and what the community could expect after the upgrade is done.
Validators
As stated in the AMA, validators will need to run slightly more expensive hardware. We changed the minimal hardware requirements from 4 cores to 8 cores. Other than this change, there is no need for validators to take any other action as all the heavy lifting has been done in the code.
Other node operators
Similar to validators, other node operators, including those who run rpc nodes, archival nodes, or indexers, should not expect any changes after the protocol upgrade other than the hardware requirement change.
Developers
Thanks to the nightshade design, developers are not exposed to the details of sharding from the very beginning and they will remain unaffected by this upgrade. More specifically, internally we treat cross-contract calls the same regardless of whether two contracts are on the same shard. Therefore, developers should expect no changes to their experience of developing on NEAR.
For rpc usage, since all the nodes that track the shard will track all shards after the upgrade, we expect no change to our rpc usage either. In the future, however, there may be rpc nodes that only track one shard instead of all shards and at that point, we may change the API to accommodate such use cases. For a more detailed discussion, please refer to this github issue.
End Users
Similar to developers, end users should not expect any change to their experience of using applications built on NEAR and do not need to care about which shard their accounts are on. With more applications launching on NEAR, users will benefit from the increased capacity on mainnet brought by this upgrade.
Aurora
This upgrade is nothing but good news to Aurora: it puts the aurora (evm) contract on its own shard! This will increase the throughput for Aurora. For the rainbow bridge, we expect no changes to the user experience since the NEAR light client on Ethereum does not care about how many shards there are and the proofs are already designed to work with multiple shards.
Conclusion
I am more than excited to see this upgrade coming to live as it not only transitions NEAR from one shard to four shards, but also lays down a solid foundation for dynamically changing the number of shards in the future and brings us one step closer to the grand vision delineated in the whitepaper. I’d also like to take this opportunity to thank the entire team for their great work, especially @minzhang who led the entire project from start to finish. Finally, @nearmax will present this work at NEARCon in a few days and don’t miss it if you are interested!