This blog post is based on the Twitter discussion thread I did a while ago.
1/ In the series of "Let's explore #Ethereum killers Tuesday" we have NEAR blockchain or @NEARProtocol in Twitter
If you are a smart contract dev or blockchain investor you will find this thread interesting.
๐๐๐
If you are a smart contract dev or blockchain investor you will find this thread interesting.
๐๐๐
2/ I participated in an online hackathon sponsored by NEAR: "Hack the rainbow".
This was around NEAR's Rainbow bridge product that allows tokens to move forth and back between NEAR and Ethereum blockchains.
This was around NEAR's Rainbow bridge product that allows tokens to move forth and back between NEAR and Ethereum blockchains.
Hack The Rainbow
Hack The Rainbow | Gitcoin Virtual Hackathon
3/ The good
๐๐๐
NEAR project started back in 2018 as "decentralised platform", aim to be the developer-friendly blockchain solution. However, it was not until 2019 when the project evolved a full blockchain and things became more interesting.
๐๐๐
NEAR project started back in 2018 as "decentralised platform", aim to be the developer-friendly blockchain solution. However, it was not until 2019 when the project evolved a full blockchain and things became more interesting.
4/ NEAR is a beast
It is the first blockchain with both state and transaction sharding.
While there are earlier blockchains like @zilliqa that shard the transactions (processing), NEAR is the first one that shards both state and transactions.
It is the first blockchain with both state and transaction sharding.
While there are earlier blockchains like @zilliqa that shard the transactions (processing), NEAR is the first one that shards both state and transactions.
5/ Sharding the state means that NEAR shards can operate parallel.
* Validator nodes need to process transactions only for their own shard
* Blockchain can scale horizontally by just adding more nodes
* Transaction throughput can grow indefinitely
* Validator nodes need to process transactions only for their own shard
* Blockchain can scale horizontally by just adding more nodes
* Transaction throughput can grow indefinitely
6/ State sharding is what Ethereum 2.0 promises, but it wont there be until Ethereum 2.0 reached its phase 4 ro phase 6, or "ever" in #DeFi time.
Expect Ethereum to match this performance around 2025.
Expect Ethereum to match this performance around 2025.
sharding-roadmap
The roadmap is an active area of research. The outline below is only intended to provide flavour, with more details in specifications (which have been released for phases 0 and 1 as of 14 Dec 2018, as linked to below). It is intended for this document to be maintained with ongoing R&D.
7/ Thus, in theory, unlike other competing blockchains out there, NEAR does not offer just "making more mileage out of existing tech" like AVA, EOS or Solana, but have innovated in the field of theoretical consensus, making it truly different.
8/ NEAR offers smart contracts in two languages: Rust (#rustlang) and AssemblyScript (#assemblyscript) - a statically typed variant of #TypeScript.
Smart contracts are compiled down to #WebAssembly (WASM) runtime. This is similar to EOS, Edgeware.
Smart contracts are compiled down to #WebAssembly (WASM) runtime. This is similar to EOS, Edgeware.
9/ A lot of effort has been put into the developer experience and trying to attract developers to the new blockchain.
NEAR was originally advertised as "developer friendliest blockchain."
NEAR was originally advertised as "developer friendliest blockchain."
10/ In theory, using Rust can make smart contract programming safer.
The compiler and run-time security features catch errors when in Solidity you need to run an external static analyser (mythril) and hope for the best.
An example is integer overflow:
The compiler and run-time security features catch errors when in Solidity you need to run an external static analyser (mythril) and hope for the best.
An example is integer overflow:
NEAR and safe math on unsigned integers
On Ethereum Solidity, a special library called SafeMath needs to be used when dealing with unsigned integer balance number. This is because of the integer overflow exploits. Does NEAR smart contracts
11/ NEAR did early presale for accredited investors in 2019.
Retail investors could buy NEAR in Aug 2020 Coinlist sale that was a complete shitshow. NEAR team members were advised not to talk about Coinlist or the token sale.
Retail investors could buy NEAR in Aug 2020 Coinlist sale that was a complete shitshow. NEAR team members were advised not to talk about Coinlist or the token sale.
12/ The token distribution is heavily skewed towards early private investors.Thus, this is a "VC chain". Usually what we see is that early investors offload their bags as soon as possible, so NEAR near term price action is likely to be ugly. ๐ฅ
NEAR Token Supply and Distribution - NEAR Protocol
Graphs, charts and analytics about the NEAR token circulating supply, total supply, inflation and economics.
13/ How do sharded transactions work?
With sharding, you are not "losing the composability" like some proponents who do not understand technology.
In the software developer language, every cross-smart contract transaction is a cross-shard transaction
and is a promise.
With sharding, you are not "losing the composability" like some proponents who do not understand technology.
In the software developer language, every cross-smart contract transaction is a cross-shard transaction
and is a promise.
14/ The caller SC creates a promise that is eventually executed in another callee SC.
Then the caller SC creates another promise that calls back itself when the first promise is done.
You can find the pattern here in my hackathon submission:
Then the caller SC creates another promise that calls back itself when the first promise is done.
You can find the pattern here in my hackathon submission:
miohtama/advanced-fungible
Advanced Fungible is a modern, secure and user-friendly token standard for NEAR protocol - miohtama/advanced-fungible
15/ Here comes the difference to #Ethereum: Each shard is finalised independently, transactions across cross-shards do not roll back the state automatically.
In Ethereum if any of transaction in a smart contract chain fail with revert() the whole transaction is rolled back.
In Ethereum if any of transaction in a smart contract chain fail with revert() the whole transaction is rolled back.
16/ Thus, in NEAR, developers of smart contracts need to design around the fact that the state is either pending with promises in progress or final, all cross contract calls done.
This is similar to commit cycle management in database design.
This is similar to commit cycle management in database design.
17/ Also, due to the design of NEAR protocol, there are no re-entrancy attacks like in Ethereum, because all cross contract calls can be only processed as promises after your smart contract initiator call is done.
(We come back to this later for nitpicking)
(We come back to this later for nitpicking)
18/ Cross contract call creates a promise that adds a delay of one block. Each promise to process the return value adds delay of another block.
If Ethereum blockchain is 12 seconds, this means that NEAR can match this with 6 cross contract calls in the same wall clock time.
If Ethereum blockchain is 12 seconds, this means that NEAR can match this with 6 cross contract calls in the same wall clock time.
19/ Assuming NEAR shards have 1 second block time (not sure about this figure, I did not find stats.
20/ / The bad
NEAR advertises itself as a developer-friendly blockchain. They are not yet there.
The toolchain is immature and some of the design choices are suboptimal. For a smart contract developer, it makes NEAR less attractive choice.
NEAR advertises itself as a developer-friendly blockchain. They are not yet there.
The toolchain is immature and some of the design choices are suboptimal. For a smart contract developer, it makes NEAR less attractive choice.
21/ Even though NEAR team is fumbling, it is not fumbling as badly as EOS or others.
EOS focused solely on their block producers, completely missed boat on DeFi.
At least NEAR is going after high-quality DeFi projects, stablecoins.
EOS focused solely on their block producers, completely missed boat on DeFi.
At least NEAR is going after high-quality DeFi projects, stablecoins.
22/ Ex 1: Rust toolchain
The toolchain cannot compile multiple smart contracts in a single project, but you need to create a new Rust library for each contract
If you are a senior developer you know this kind of project structuring is just insanity.
The toolchain cannot compile multiple smart contracts in a single project, but you need to create a new Rust library for each contract
How to build and deploy multiple contracts in NEAR protocol
Currently the cargo build produces one WASM file like contract/target/wasm32-unknown-unknown/release/hello.wasm. How can I produce multiple wasm binaries if my contract source tree contains multipleIf you are a senior developer you know this kind of project structuring is just insanity.
23/ Programming the smart contracts is done with NEAR Rust SDK.
It is still underdocumented in the bits you need documentation most.
near_sdk - Rust
API documentation for the Rust `near_sdk` crate.It is still underdocumented in the bits you need documentation most.
24/ For example, declaring smart contract bindings using a macro called near_bindgen, the first macro encounter:
Zero documentation, zero comments.
It is difficult to tell what this thing is supposed to do and WHY.
near_sdk::near_bindgen - Rust
API documentation for the Rust `near_bindgen` attr in crate `near_sdk`.Zero documentation, zero comments.
near/near-sdk-rs
Rust library for writing NEAR smart contracts. Contribute to near/near-sdk-rs development by creating an account on GitHub.It is difficult to tell what this thing is supposed to do and WHY.
25/ Promise errors cannot be resolved.
It is like @soliditylang 0.3. You know something failed in a smart contract call, but you have no idea if it is an recoverable error. There are no error returns. Senior #Ethereum developers know how bad this is.
It is like @soliditylang 0.3. You know something failed in a smart contract call, but you have no idea if it is an recoverable error. There are no error returns. Senior #Ethereum developers know how bad this is.
Dealing with promise chain failures in NEAR blockchain
I am writing a set of interacting smart contracts for a NEAR blockchain. Let's imagine the the following scenario User sends a token to an exchange smart contract Token smart contract calls exchange
26/ / Smart contract arguments are serialised.But sometimes they are serialised using Borsh (
) sometimes using JSON (promise).
What is the point of using JSON in the first place for the system that needs to push most out of each CPU cycle to scale?
Borsh
Borsh stands for Binary Object Representation Serializer for Hashing. It is meant to be used in security-critical projects as it prioritizes consistency, safety, speed; and comes with a strict specification. It optimizes for the following qualities in the decreasing priority:What is the point of using JSON in the first place for the system that needs to push most out of each CPU cycle to scale?
27/ Take one of the efficient serialisation libraries and make it standard across the ecosystem.
As a hint, it is unlikely to be JSON (NEAR team already knows this well)
E.g.
- Dealing amounts like unit128 is not JSON's forte
- JSON is inefficient
As a hint, it is unlikely to be JSON (NEAR team already knows this well)
E.g.
- Dealing amounts like unit128 is not JSON's forte
- JSON is inefficient
Comparison of data-serialization formats
This is a comparison of data-serialization formats, various ways to convert complex objects to sequences of bits. It does not include markup languages used exclusively as document file formats.
28/ / NEP-21 token standard is a direct copy from ERC-20.
However, no thought was spent when cloning ERC-20, including the broken approve() / transferFrom() UX pattern and all of those lost token transfers because of it.
However, no thought was spent when cloning ERC-20, including the broken approve() / transferFrom() UX pattern and all of those lost token transfers because of it.
29/ Namely, the approve() pattern was left in ERC-20 originally because of fear of re-entrancy attacks.
NEAR cannot have re-entrancy attacks, so this choice does not make any sense and smells simple cargo culting.
NEAR cannot have re-entrancy attacks, so this choice does not make any sense and smells simple cargo culting.
30/ Luckily the team is now pushing for better allowance free token standard
Hopefully NEP-21 will be burnt soon and be forgotten, before it becomes widespread.
Proposal: Allowance-free vault-based token standard ยท Issue #122 ยท near/NEPs
Rational: remove the extra space that is used for allowance remove an extra transaction that is required to transfer token to a contract (to set allowance) simplify token standard usage make chaine...Hopefully NEP-21 will be burnt soon and be forgotten, before it becomes widespread.
31/ NEAR does not have explicit events like in Solidity.
Instead, it has indexer and transaction status.
Instead, it has indexer and transaction status.
RPC Endpoints ยท NEAR Documentation
## Setup
32/ There is no way to tell NEAR "Give me all token transfer events since 2020" or "give me all token transfers to this address in an exchange hot wallet".
Integration with wallets and exchanges is hard until this can be queried with one liner.
Integration with wallets and exchanges is hard until this can be queried with one liner.
33/ How NEAR can success?Where do we find happy lemurs?
๐๐๐
34/ Although NEAR scales near infinitely, it is no argument for developers today, or likely for the next 3-4 years. You is mission is not to fix #Ethereum mainnet.
35/ NEAR is working on "EVM shard" to make it easier to attract existing Solidity projects.
Then NEAR is just yet another Ethereum chain, no different from @avalancheavax, @tronfoundation or Binance Smart Chain.
Then NEAR is just yet another Ethereum chain, no different from @avalancheavax, @tronfoundation or Binance Smart Chain.
36/ Furthermore, Ethereum smart contracts need to be completely rewritten any case to take advance of the sharding of @NEARProtocol .
While you rewrite these, you could as well rewrite in #rustlang.
While you rewrite these, you could as well rewrite in #rustlang.
37/ NEAR also cannot compete as better EVM against L2 EVM scaling efforts of Ethereum.
Providing a Frankenstein EVM that does not use ETH as gas is not going to attract hardcore #Ethereum developers.
See: @RSKsmart, @Tronfoundation, @qtumofficial and other failed efforts.
Providing a Frankenstein EVM that does not use ETH as gas is not going to attract hardcore #Ethereum developers.
See: @RSKsmart, @Tronfoundation, @qtumofficial and other failed efforts.
38/ NEAR is working on two different programming languages: Rust (#rustlang) and AssemblyScript (#assemblyscript).
AssemblyScript is simpler, targeted towards more junior, more web, developers.
I think this is a wasted effort.
AssemblyScript is simpler, targeted towards more junior, more web, developers.
I think this is a wasted effort.
39/ Smart contract programming is for smart, senior, people who have a good understanding of computer science. You need to be disciplined and well versed in many low-level topics.
Dumbing down the development is not going to make the developers themselves any smarter.
Dumbing down the development is not going to make the developers themselves any smarter.
40/ Thus, making easy smart contract language does not make sense. Real smart contract and #DeFi developers are already senior and use the best tool for the job, #rustlang.
Creating a toy language SDK for toy projects makes no business sense. You are not going to attract value.
Creating a toy language SDK for toy projects makes no business sense. You are not going to attract value.
41/ What @NEARProtocol could do instead?
42/ NEAR could live up its promise and build a better developer and user experience.
Because no one is going to come if the only selling argument is "cheaper transactions." In that case, we would all be using @Ripple now.
Because no one is going to come if the only selling argument is "cheaper transactions." In that case, we would all be using @Ripple now.
43/ Make tokens on NEAR trivial to integrate any backend, like payments and exchanges.
Solve the problems why it is so hard to use Ethereum tokens, like a need for ETH in the wallet for the gas.
Solve the problems why it is so hard to use Ethereum tokens, like a need for ETH in the wallet for the gas.
44/ Make creating token-based NEAR dApps easy.
However, #Ethereum is already giving you a run for your money here due to the vast amount of example code.
However, #Ethereum is already giving you a run for your money here due to the vast amount of example code.
45/ Make NEAR trivial to integrate mobile wallets with a good SDK, unlike Ethereum.
Wallets should not need massive backends for things like getting tokens in the user wallet and their icons.
Wallets should not need massive backends for things like getting tokens in the user wallet and their icons.
46/ Make NEAR smart contract development more secure by using Rust.
Look top @soliditylang security issues and catch them during the compile time. Insecure code does not compile.
Look top @soliditylang security issues and catch them during the compile time. Insecure code does not compile.
Security review checklist for a smart contract
Is there a tool, checklist of methodology to help reviewing smart contract security? E.g. for each of function you review Is there re-entry possibility and how it behaves on re-entry How it behav...
47/ Make NEAR tokens more attractive than ERC-20 with better features, like automatic add to wallets on the first transfer and token icons out of the box.
No more guides "how to add the custom token in MetaMask" or "how to buy ETH".
No more guides "how to add the custom token in MetaMask" or "how to buy ETH".
48/ When you have a good token standard and support ecosystem, then get over ones like $USDT and $USDC.
Having wide, trivial, wallet support and cheap transactions for stablecoins would be a killer application alone.
Having wide, trivial, wallet support and cheap transactions for stablecoins would be a killer application alone.
49/ That's all this time folks.
I will give @nearprotocol 50% / 50% chance to succeed.
NEAR has better fundamentals than any of other existing blockchains. But the developer experience is not good and scalability promise does not mean anything at the moment.
I will give @nearprotocol 50% / 50% chance to succeed.
NEAR has better fundamentals than any of other existing blockchains. But the developer experience is not good and scalability promise does not mean anything at the moment.
Comments
Send any feedback and comments by replying the Twitter thread.
Discuss