There have been some questions about our focus with regards to protocol development. This post will hopefully provide a clearer picture on what we plan to work on in the next 1-2 years. I’ve made a gantt graph (attached below) to show the roadmap for the major protocol features and improvements. Please note that for those that are planned for next year and beyond, the estimates are likely to be somewhat off.
Some highlights of what we plan to deliver this year:
- Simple nightshade with 8 shards with Aurora in its own shard. This will improve the total tps by 5-8x and potentially reduce the storage cost further.
- Increase the number of validators on mainnet
- Improve single-shard performance. This includes the following:
- Moving contract compilation from runtime to deployment time, which will reduce function call base cost from 4.6Tgas to ~0.2Tgas. This means that for a lot of function calls, it will mean 20% - 50% gas cost reduction.
- Upgrade to wasmer1. This will reduce gas costs across the board and most notably, will reduce regular ops gas cost by ~50%.
Zooming out from the short term focus to look at the longer term picture, we will likely work on and deliver the following in the next couple of years:
-
Gas price auction. The exact details haven’t been fully decided yet, but the idea is that we would like to allow users to specify the maximal gas price they are willing to pay for a transaction and take transactions in the decreasing order of their gas prices. This will be a big change to how transactions are charged currently and we decide to make this change to better handle congestion.
-
Nightshade. This means most of what is described in the original white paper except hidden validators, which we likely won’t need for a while since there are entities who are incentivized to run fishermen in practice. After we deliver simple nightshade, what is left consists of mostly two things: challenges and dynamic resharding. Both require quite some effort to implement due to their technical complexity.
-
Improvements for contract development. There are quite a few things that we plan to work on to both reduce the cost of contract calls and make the developer experience better:
- Reduce storage IO cost. Currently storage reads and writes are relatively expensive, which both leads to lower throughput and also higher transaction fees for smart contracts. We plan to rewrite the storage to make reads and writes faster. A proposal can be found here.
- Rethink how gas and storage costs work. Developers today have to think about how much gas to attach to transactions and cross-contract calls. They also have to take storage cost into consideration when writing methods that modify the contract state, which makes the contract development more cumbersome. One of the possible options to address this issue is to unify gas and storage cost and make transaction attach NEAR explicitly.
- Some form of synchronous execution environment. In the original nightshade design, all executions are asynchronous and there was no consideration for synchronous execution. However, from the feedback of developers it is quite clear that financial applications could benefit immensely from synchronous execution. To address this issue, we have considered several options, including introducing special synchronous shard(s) and building synchronous vaults on top of async shards.
The crypto landscape has changed dramatically since when the nightshade paper was written. While we are still working in the direction prescribed by the white paper, we also happily embrace new ideas to make the protocol better. After all, NEAR stands for iteration, and we will keep evolving to serve our developers, to help grow our community, and to stay true to our mission of empowering all people to control their own money, data, and power of governance