Hack the Rainbow Session 7: NEAR Accounts and Key Registration

Hack the Rainbow Session 7, led by Matt Lockyer and Sherif Abushadi, was a technical deep dive into the world of Accounts, Keys, and the differences between NEAR and Ethereum. While a full transcript of the main points of this discussion can be found here, this general overview outlines some of the most important and fascinating areas of Account and Key Management on NEAR. 

Point 1: NEAR Accounts Differ From Ethereum In Some Crucial Ways

The session started out by clearly delimiting the primary differences in which the account system for NEAR differed from that of Ethereum: On NEAR it’s all about Accounts as opposed to Key Pairs. NEAR has ENS built into its protocol, with the result being that Account Names are standardized as matt.testnet , or sharif.testnet and are not generated automatically for you. It is then up to the account administrator to deploy a contract for an account or subaccount. 

As Sharif Explains:

“The account name can be any valid account on the network that you create. You can create it first, and then deploy a contract towards it, or you can create an account as part of a transaction – create an account and then deploy the contract.” 

Meanwhile, the primary differences between Accounts on NEAR and Ethereum are summarized in the graphic portrayed below: 

Point 2: Accounts and Subaccounts on NEAR

Uniquely, NEAR offers users the capacity to create not only an account – but also sub accounts as well. The Master account can then manage the permissions of the subaccount. 

“Essentially there are accounts and subaccounts: you can create sub accounts, and have another account be the master account.”

Importantly, there is no primitive action for Master accounts to ask for account information on a contract:  

“You can add keys or delete keys from inside of a contract – when you say can an account do something – the next question is – do we support the ability to ask another account for keys that it has? I don’t think we have a list keys action. You can add a key, delete a key, call a contract, list function, add account, create account, send tokens, transfer or stake, those are the eight primitive actions that we have got. So there is no primitive action from within a contract to ask for account information on a contract.”

Point 3: Function-Call Limited Permissions – What are they? 

In perhaps the most complex part of the discussion, Sherif asked Matt to explain the main idea behind Function-Call Limited Permissions. Essentially, in NEAR accounts, Master accounts can call-certain contracts from sub-accounts using a function-call key. The following example was provided during the session: 

“Let say we have two accounts, Alice and Bob (.near each). It is true that Bob can call a function-call key that has a receiver of Alice and is only scoped to call methods on Alice. So through some sort of construction, whether it is in the CLI or whether it is in a contract or using NEAR API JS and the user approves that transaction – Bob can add a key to that account. So Bob would have this function call Key with the receiver of Alice – and it is scoped to a particular method – and Bob would have approved some sort of allowance.

As tricky as this concept can be to understand, by differentiating accounts from keys, NEAR’s design allows accounts to call contracts on specific sub-accounts:

It is important that we understand the two main concepts: Accounts and then the key pairs are added to the accounts under various permissions, but there is almost like a pseudo concept with these automatic function calls, and that is who controls the private key once you’ve added a key pair with some allowance to call some functions?  That opens up this whole other world of possibilities: For example, I could create an API and people could deposit funds to my contract, to get a key that allows them to add a key to my account, so you could add a key to my API contract, that basically gives you an allowance to call a certain number of functions. So this becomes really interesting because who has the private key is the one who can call that, on the accounts behalf. 

Point 4: An Auction for Top-Level Account Names Is In Store For the Future

A final point to keep in mind on the topic of NEAR accounts is the upcoming – yet still not defined NEAR Auction for Top-Level Account Names. In essence, the .NEAR behind each account will eventually be customizable to specific account names that users can bid on for themselves! 

As far as I know we haven’t made any hard and fast decisions about what is going on with TLA’s – Top Level Account Names – so as of now everyone has to create a something.near account. In the future it will be an auction. NEAR will host a very fair and open auction for TLA’s on NEAR – Top Level Accounts – and then you can deploy a contract on the Account that can govern how you will sell sub accounts. How will users create matt.theoforec. Top level accounts will be auctioned off at some point in the future. 

For a full breakdown of this discussion you can check out the notes from the talk available here.