Read on Twitter
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. https://gitcoin.co/hackathon/hack-the-rainbow/
This was around NEAR's Rainbow bridge product that allows tokens to move forth and back between NEAR and Ethereum blockchains. https://gitcoin.co/hackathon/hack-the-rainbow/
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. https://eth.wiki/en/sharding/sharding-roadmap
Expect Ethereum to match this performance around 2025. https://eth.wiki/en/sharding/sharding-roadmap
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: https://stackoverflow.com/a/64136471/315168
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: https://stackoverflow.com/a/64136471/315168
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. https://twitter.com/moo9000/status/1293183462342459395
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. https://twitter.com/moo9000/status/1293183462342459395
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.
https://near.org/blog/near-token-supply-and-distribution/
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.
https://near.org/blog/near-token-supply-and-distribution/
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: https://github.com/miohtama/advanced-fungible/blob/master/contract/token/src/token.rs#L123
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: https://github.com/miohtama/advanced-fungible/blob/master/contract/token/src/token.rs#L123
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
https://stackoverflow.com/questions/64110056/how-to-build-and-deploy-multiple-contracts-in-near-protocol
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
https://stackoverflow.com/questions/64110056/how-to-build-and-deploy-multiple-contracts-in-near-protocol
If 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.
https://docs.rs/near-sdk/2.0.0/near_sdk/
It is still underdocumented in the bits you need documentation most.
https://docs.rs/near-sdk/2.0.0/near_sdk/
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:
https://docs.rs/near-sdk/2.0.0/near_sdk/attr.near_bindgen.html
Zero documentation, zero comments.
https://github.com/near/near-sdk-rs/blob/master/near-sdk-macros/src/lib.rs#L13
It is difficult to tell what this thing is supposed to do and WHY.
https://docs.rs/near-sdk/2.0.0/near_sdk/attr.near_bindgen.html
Zero documentation, zero comments.
https://github.com/near/near-sdk-rs/blob/master/near-sdk-macros/src/lib.rs#L13
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. https://stackoverflow.com/a/64054342/315168
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. https://stackoverflow.com/a/64054342/315168
26/ / Smart contract arguments are serialised.But sometimes they are serialised using Borsh ( https://borsh.io/ ) 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?
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
https://en.wikipedia.org/wiki/Comparison_of_data-serialization_formats
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
https://en.wikipedia.org/wiki/Comparison_of_data-serialization_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
https://github.com/nearprotocol/NEPs/issues/122
Hopefully NEP-21 will be burnt soon and be forgotten, before it becomes widespread.
https://github.com/nearprotocol/NEPs/issues/122
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. https://docs.near.org/docs/api/rpc#transaction-status-with-receipts
Instead, it has indexer and transaction status. https://docs.near.org/docs/api/rpc#transaction-status-with-receipts
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?
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. https://ethereum.stackexchange.com/questions/8551/security-review-checklist-for-a-smart-contract
Look top @soliditylang security issues and catch them during the compile time. Insecure code does not compile. https://ethereum.stackexchange.com/questions/8551/security-review-checklist-for-a-smart-contract
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.
