Hack the Rainbow: NEAR 101 – The Very Basics

NEAR 101 is the base level introduction to the technical facets of NEAR protocol. This talk was given to prospective developers interested in building applications on top of NEAR. The talk was a comprehensive overview of key topics related to building solutions on top of NEAR: Accounts, Programming Languages, the differences between Web2 and Web3, and Cross-contract calls (among other topics!). 

Slides for the original presentation on NEAR 101 can be found here: bit.ly/near-101

Point 1: NEAR Inaugurates Web3: How Does that differ from Web2? 

As the graphic above demonstrates, NEAR protocol represents an initial foray into the development of Web3: Web3 is commonly referred to as The Internet of Value. It is the next iteration of internet innovation, insofar as it builds in money to base level protocols. Because of this addition, accounts must also be secured using asymmetric key pairs. 

Sherif explains the main differences between account security in Web2 and Web3: 

In the Web2 world you use oAuth or username to log in to some environment, as opposed to Web3 where accounts are asymmetric key pairs (public and private keys). Your private key is really your password, but strictly it never actually leaves your machine. With Web2, if for instance, you’d log in to Facebook, your username and password travel through the web and then land on some remote server where they get checked and verified. However, you’re still sending this data over the wire, so technically a bad actor could still intercept this and do bad things. This can’t happen with Web3, since you own the private key and sign the message. Servers on web3 (as opposed to AWS / GCP / Azure on Web2) are different from web2: they’re nodes and the consensus secures the network itself. 

Point 2: NEAR Has Two Path Extensions

When it comes to building things on NEAR protocol, Sherif explains how NEAR has two primary extension pathways for developers: 

These two development pathways, reflect the primary focuses of NEAR protocol itself: Scalability and Usability. While developers do not have to worry about the technical details of sharding, they can build contract-based solutions that benefit from low transactions costs and high speed transactions using NEAR Software Developer Kits (SDKs). Meanwhile, Usability can be improved for any dApp using the NEAR API and the JSON-RPC API. 

“When you’re building on NEAR, you have to take into account two areas of development: one is the contract you’re building on the other is the user experience.”

Point 3: Use AssemblyScript for Fast Prototyping and Rust for the Big Leagues

When discussing the dApp contract development pathway on NEAR, Sherif explains the benefits of building through the different SDK’s connected to NEAR: Developers should use the AssemblyScript SDK for fast prototyping and initial project development. However, serious, high-value applications should be built in Rust as the more durable and secure solution. As Sherif explains: 

Again, AssemblyScript  (near-sdk-as) is great for prototyping and great for starting out, but the language is still maturing and as the AS community continues to build and grow, it may grow more stable, but honestly I don’t recommend to build applications that hold a lot of value. For a hackathon, AS is great. It is fast, but if you are building an actual application that’s going to be holding a decent amount of value, then Rust is more sophisticated and reliable.

Notably, on all NEAR applications the frontend and backend do not have to be programmed in the same language. For instance the frontend can run on JavaScript, while the backend runs on Rust.

Point 4: NEAR Accounts are Easy to Setup and Manage

The fourth and final point of the introduction to NEAR centers on Accounts. Accounts on NEAR are different than on Ethereum: An account can represent either a user, a contract or both. In this sense there can be a Master account and sub-accounts. In addition, NEAR accounts do not use hashes – they are instead human readable names that follow a DNS reading pattern. Last but not least, NEAR Accounts also maintain their own storage through the passive storage staking functionality. Sherif specifically breaks down the nature of storage on NEAR:

In terms of storage, if my account is going to keep data store then I need to stake some tokens to offset the maintenance costs of keeping that data on your account. Effectively what youre doing is, you’re taking some tokens out of circulation and you stake them against that data you’re storing and that increases the relative value of other tokens (deflationary mechanism) so that other people who hold tokens are now marginally more valuable, so rewards are more valuable for maintaining integrity of the network. So if you store data, you’ve got to put some tokens against that data, which says “I want to keep this data” and I’m locking these tokens against that data. As soon as you delete the data you get the tokens back. But as long as the data is there and someone, some node, some computer, some hardware, or resource has to be consumed to keep that data around, then you have to stake tokens against it, and this article explains that: https://docs.near.org/docs/concepts/storage

Conclusion: 

As an introduction to NEAR protocol, Sherif’s presentation helps developers get started quickly on building their first Web3 applications. While the rest of the discussion featured Questions and Answers as well as a long discussion on the nature of cross-contract calls and sharding, the main points for developers remain the same: NEAR is easy to build on – in either AssemblyScript or Rust – it inaugurates Web3, and its primary features put Usability and Scalability first, whether that is on the front-end with Human Readable ID’s, or on the back-end with easy to build prototypes with the AssemblyScript SDK or robust applications in Rust.