Welcome to the Frequently Asked Questions. To contribute, use the Edit button on the right.
This Technical FAQ is dedicated to technical questions about the technical architecture of the project.
Comparisons to Other Technologies
How does NEAR’s design compare to ETH 2.0?
Last updated: 20200805
Note that Ethereum 2.0 is just a proposal at the moment, so it may change. Overall, Eth 2 is essentially designed to be nuclear-war-proof.
We optimized for liveness with BFT assumptions so we say a block is final within 2-3 seconds
On NEAR, all calls are asynchronous and shards are homogeneous so itâs easy for contracts to operate across shards. We ensure messages get routed properly between the blocks.
On Eth2.0 thatâs not really designed yet but generally youâll have an account on every shard, youâll have to decide where you want to deploy your contract and youâll be very aware of which shard youâre on and have to program around it.
On a deeper level, the major difference between NEAR and ETH 2.0 is that NEAR uses a single chain that shards each block, instead of having a separate beacon chain. Each block produced contains âchunksâ that are processed by a different subset of nodes. This allows us to ensure data availability for transactions in each shard on the consensus level and easily mitigate any shard-level attacks. And at the same time, it provides cross-shard communication that arrives in one block to the other shard – allowing to remove the need for developers to understand shards.
Because of that, we also are not going to have a fixed number of shards – it will be changing depending on the demand (e.g. dynamic resharding) – allowing the network to maintain low transaction fees. Interestingly, this approach is actually simpler to implement than maintaining many chains in parallel, as it allows everyone in the network just to track one chain and verify itâs correctness depending on the level of security they need. We strive to build simple solutions for hard problems, because in the end simplicity is what leads to more people being able to interact with the software.
What tradeoffs did this design require you to make?
Last Updated: 20200625
The main thing that is different with NEAR is that a number of block producers that maintain consensus canât be too big. So right now weâre going after 100. The top consensus will be operated by 100, then another set thatâs 100 * # shards, then building up layers.
Vs Eth2 which is planning to have millions (or at least tens of thousands). If you need consensus fast, you need fewer nodes to come up with consensus.
Also, asynchronous systems donât have transactions as much so composability isnât quite as strong. You have to keep in mind that youâre in an asynchronous environment (so there are async callbacks floating around). You have all the tools to manage callbacks, so not too bad for a programmer used to that.
How does NEAR’s design compare to Polkadot?
Last updated: 20200103
The main difference is that in Polkadot every application needs to have its own blockchain (which is pretty hard to launch) and there are only 32 slots (up to 100 later). Whereas in NEAR it’s straightforward to launch an app (you can try it on testnet now – https://near.dev/) and there is no limit on how many apps. Additionally, there are a bunch of consensus, security, staking, economics, smart contracting differences on top of it but they won’t fit here.
The other major difference is our focus on user and developer experience – we are really trying to make it easy for non-crypto ppl to build stuff. We measure ourselves based on how easy it is to start using apps on NEAR by folks who never owned crypto for example.
Asynchronous System Questions
How does Atomicity work on NEAR?
Last Updated: 20200625
Atomicity is more complex in an asynchronous system. Weâre still figuring it out a bit since you have to see how the system is actually used before designing this appropriately.
NEAR is expected to bundle things into a Safe, which is sort of like that, but it hasnât been implemented that since first there needs to be proven demand for it.
Ask it on StackOverflow!
