Architecture
Near node consists roughly of a blockchain layer and a runtime layer. These layers are designed to be independent from each other: the blockchain layer can in theory support runtime that processes transactions differently, has a different virtual machine (e.g. RISC-V), has different fees; on the other hand the runtime is oblivious to where the transactions are coming from. It is not aware whether the blockchain it runs on is sharded, what consensus it uses, and whether it runs as part of a blockchain at all.
The blockchain layer and the runtime layer share the following components and invariants:
Transactions and Receipts
Transactions and receipts are a fundamental concept in Near Protocol. Transactions represent actions requested by the blockchain user, e.g. send assets, create account, execute a method, etc. Receipts, on the other hand is an internal structure; think of a receipt as a message which is used inside a message-passing system.
Transactions are created outside the Near Protocol node, by the user who sends them via RPC or network communication. Receipts are created by the runtime from transactions or as the result of processing other receipts.
The blockchain layer cannot create or process transactions and receipts, it can only manipulate them by passing them around and feeding them to a runtime.
Account-Based System
Similar to Ethereum, Near Protocol is an account-based system. Each blockchain user is roughly associated with one or several accounts (there are exceptions though, when users share an account and are separated through the access keys).
The runtime is essentially a complex set of rules on what to do with accounts based on the information from the transactions and the receipts. It is therefore deeply aware of the concept of account.
The blockchain layer however is mostly aware of the accounts through the trie and the validators. Outside these two it does not operate on the accounts directly.
Every account at NEAR belongs to some shard. All the information related to this account also belongs to the same shard. The information includes:
Balance
Locked balance (for staking)
Code of the contract
Key-value storage of the contract
All Access Keys
Trie
Near Protocol is a stateful blockchain -- there is a state associated with each account and the user actions performed through transactions mutate that state. The state then is stored as a trie, and both the blockchain layer and the runtime layer are aware of this technical detail.
The blockchain layer manipulates the trie directly. It partitions the trie between the shards to distribute the load. It synchronizes the trie between the nodes, and eventually it is responsible for maintaining the consistency of the trie between the nodes through its consensus mechanism and other game-theoretic methods.
The runtime layer is also aware that the storage that it uses to perform the operations on is a trie.
Validators
Both the blockchain layer and the runtime layer are aware of a special group of participants who are responsible for maintaining the integrity of the Near Protocol. These participants are associated with the accounts and are rewarded accordingly. The reward part is what the runtime layer is aware of, while everything around the orchestration of the validators is inside the blockchain layer.
Attributes of the NEAR blockchain
an asynchronous, sharded runtime, meaning that two contracts can be executed at the same time in different shards
Storage for different contracts and accounts can be located on the different shards.
Two contracts can be executed at the same time in different shards.
a storage staking model that separates gas fees from the storage demands of the network, enabling greater on-chain storage (see Metadata extension) and ultra-low transaction fees
Resources
Last updated