This blog post is based on the Twitter discussion thread I did a while ago.
If you are a smart contract dev or blockchain investor you will find this thread interesting.
This was around NEAR's Rainbow bridge product that allows tokens to move forth and back between NEAR and Ethereum blockchains.
Hack The RainbowHack The Rainbow | Gitcoin Virtual Hackathon
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.
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.
* 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
Expect Ethereum to match this performance around 2025.
sharding-roadmapThe 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.
Smart contracts are compiled down to #WebAssembly (WASM) runtime. This is similar to EOS, Edgeware.
NEAR was originally advertised as "developer friendliest blockchain."
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 integersOn 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
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.
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 ProtocolGraphs, charts and analytics about the NEAR token circulating supply, total supply, inflation and economics.
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.
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-fungibleAdvanced Fungible is a modern, secure and user-friendly token standard for NEAR protocol - miohtama/advanced-fungible
In Ethereum if any of transaction in a smart contract chain fail with revert() the whole transaction is rolled back.
This is similar to commit cycle management in database design.
(We come back to this later for nitpicking)
If Ethereum blockchain is 12 seconds, this means that NEAR can match this with 6 cross contract calls in the same wall clock time.
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.
EOS focused solely on their block producers, completely missed boat on DeFi.
At least NEAR is going after high-quality DeFi projects, stablecoins.
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 protocolCurrently 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 multiple
If you are a senior developer you know this kind of project structuring is just insanity.
near_sdk - RustAPI documentation for the Rust `near_sdk` crate.
It is still underdocumented in the bits you need documentation most.
near_sdk::near_bindgen - RustAPI documentation for the Rust `near_bindgen` attr in crate `near_sdk`.
Zero documentation, zero comments.
near/near-sdk-rsRust 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.
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 blockchainI 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
BorshBorsh 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?
As a hint, it is unlikely to be JSON (NEAR team already knows this well)
- Dealing amounts like unit128 is not JSON's forte
- JSON is inefficient
Comparison of data-serialization formatsThis 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.
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.
NEAR cannot have re-entrancy attacks, so this choice does not make any sense and smells simple cargo culting.
Proposal: Allowance-free vault-based token standard · Issue #122 · near/NEPsRational: 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.
Instead, it has indexer and transaction status.
RPC Endpoints · NEAR Documentation## Setup
Integration with wallets and exchanges is hard until this can be queried with one liner.
Then NEAR is just yet another Ethereum chain, no different from @avalancheavax, @tronfoundation or Binance Smart Chain.
While you rewrite these, you could as well rewrite in #rustlang.
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.
AssemblyScript is simpler, targeted towards more junior, more web, developers.
I think this is a wasted effort.
Dumbing down the development is not going to make the developers themselves any smarter.
Creating a toy language SDK for toy projects makes no business sense. You are not going to attract value.
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.
Solve the problems why it is so hard to use Ethereum tokens, like a need for ETH in the wallet for the gas.
However, #Ethereum is already giving you a run for your money here due to the vast amount of example code.
Wallets should not need massive backends for things like getting tokens in the user wallet and their icons.
Look top @soliditylang security issues and catch them during the compile time. Insecure code does not compile.
Security review checklist for a smart contractIs 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...
No more guides "how to add the custom token in MetaMask" or "how to buy ETH".
Having wide, trivial, wallet support and cheap transactions for stablecoins would be a killer application alone.
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.