2021-02-08 Engineering Update


  • 8 shards can now produce 5x TPS of a single shard! It is not exactly linear sharding, but quite close :slight_smile: This closes one of our Q1 goals 2 months ahead of schedule.
  • Significantly dropped CPU consumption, in some cases from 8 full cores to 1 full core. This was achieved by finding a bug in actix 0.9 and upgrading away from it;
  • Network routing table re-computation was made 100 times faster;



  • Check out new EVM tutorials here: one, two, and three;
  • We started migrating to SputnikVM.

Node Interfaces


  • We have examined license compliance for 42 out of 175 repos. This produced 18 issues to investigate;
  • Now you can run all of our nearcore CI scripts yourself! We made them available here. This does not include NayDuck though :slight_smile:

Berry Pickers

Contract Runtime

  • Aleksey Kladov fixed a bunch of code in our repo in his first week :slight_smile: 4 non-trivial PRs!
  • We are rewriting lots of things in Wasmer 1.0 to make module loading fast.

Super cool result for the chain team! Congratulations!

1 Like

@nearmax did you make any crash test? What’s the throughput using simple transactions (eg basic NEP-21 transfer)?

1 Like

@birchmd Do you have any data on @robert 's question?

@nearmax @robert

Throughput testing has focused solely on native (NEAR) transfers, not any smart contract execution. With 8 shards we have observed almost 4000 tps working well, where the transactions in these experiments were only NEAR transfers.

Testing the throughput of smart contract execution will certainly be done in the future. Using NEP-21 as one of the benchmark contracts is an excellent idea! Are there other contracts you would be interested in seeing tps measurements for?

1 Like

Thanks @birchmd . NEP-141 with a transfer_call (notifying receiver) will be definitely one of the most important ones.

1 Like

FYI. We should try doing it both with disabling and enabling in-memory compilation cache for contracts. @olonho and @ailisp know how to do it.