|
| 1 | +--- |
| 2 | +id: architecture |
| 3 | +title: Architecture |
| 4 | +description: "Comprehensive high-level overview of NEAR Protocol's architecture." |
| 5 | +--- |
| 6 | + |
| 7 | +# Architecture |
| 8 | + |
| 9 | +NEAR consists roughly of a blockchain layer and a [runtime layer](network/runtime.md). |
| 10 | +These layers are designed to be independent from each other: the blockchain layer can in theory support runtime that processes |
| 11 | +transactions differently, has a different virtual machine (e.g. RISC-V), has different fees; on the other hand the runtime |
| 12 | +is oblivious to where the transactions are coming from. It is not aware whether the |
| 13 | +blockchain it runs on is sharded, what consensus it uses, and whether it runs as part of a blockchain at all. |
| 14 | + |
| 15 | +The blockchain layer and the runtime layer share the following components and invariants: |
| 16 | + |
| 17 | +## Transactions and Receipts |
| 18 | + |
| 19 | +[Transactions](transactions.md) and receipts are a fundamental concept in Near Protocol. Transactions represent actions requested by the |
| 20 | +blockchain user, e.g. send assets, create account, execute a method, etc. Receipts, on the other hand is an internal |
| 21 | +structure; think of a receipt as a message which is used inside a message-passing system. |
| 22 | + |
| 23 | +Transactions are created outside the Near Protocol node, by the user who sends them via RPC or network communication. |
| 24 | +Receipts are created by the runtime from transactions or as the result of processing other receipts. |
| 25 | + |
| 26 | +Blockchain layer cannot create or process transactions and receipts, it can only manipulate them by passing them |
| 27 | +around and feeding them to a runtime. |
| 28 | + |
| 29 | +## Account-Based System |
| 30 | + |
| 31 | +Similar to Ethereum, Near Protocol is an [account-based system](account-model.md). Which means that each blockchain user is roughly |
| 32 | +associated with one or several accounts (there are exceptions though, when users share an account and are separated |
| 33 | +through the [access keys](access-keys.md)). |
| 34 | + |
| 35 | +The runtime is essentially a complex set of rules on what to do with accounts based on the information from the |
| 36 | +transactions and the receipts. It is therefore deeply aware of the concept of account. |
| 37 | + |
| 38 | +Blockchain layer however is mostly aware of the accounts through [the trie](#trie) and [the validators](#validators). |
| 39 | +Outside these two it does not operate on the accounts directly. |
| 40 | + |
| 41 | +### Assume every account belongs to its own shard |
| 42 | + |
| 43 | +Every account at NEAR belongs to some shard. |
| 44 | +All the information related to this account also belongs to the same shard. The information includes: |
| 45 | + |
| 46 | +- Balance |
| 47 | +- Locked balance (for staking) |
| 48 | +- Code of the contract |
| 49 | +- Key-value storage of the contract |
| 50 | +- All Access Keys |
| 51 | + |
| 52 | +Runtime assumes, it's the only information that is available for the contract execution. |
| 53 | +While other accounts may belong to the same shards, the Runtime never uses or provides them during contract execution. |
| 54 | +We can just assume that every account belongs to its own shard. So there is no reason to intentionally try to collocate accounts. |
| 55 | + |
| 56 | +## Trie |
| 57 | + |
| 58 | +Near Protocol is a stateful blockchain -- there is a state associated with each account and the user actions performed |
| 59 | +through transactions mutate that state. The state then is stored as a trie, and both the blockchain layer and the |
| 60 | +runtime layer are aware of this technical detail. |
| 61 | + |
| 62 | +The blockchain layer manipulates the trie directly. It partitions the trie between the shards to distribute the load. |
| 63 | +It synchronizes the trie between the nodes, and eventually it is responsible for maintaining the consistency of the trie |
| 64 | +between the nodes through its consensus mechanism and other game-theoretic methods. |
| 65 | + |
| 66 | +The runtime layer is also aware that the storage that it uses to perform the operations on is a trie. In general it does |
| 67 | +not have to know this technical detail and in theory we could have abstracted out the trie as a generic key-value storage. |
| 68 | +However, we allow some trie-specific operations that we expose to the smart contract developers so that they utilize |
| 69 | +Near Protocol to its maximum efficiency. |
| 70 | + |
| 71 | +## Tokens and gas |
| 72 | + |
| 73 | +Even though [tokens](network/tokens.md) is a fundamental concept of the blockchain, it is neatly encapsulated |
| 74 | +inside the runtime layer together with the [gas](gas.md), [fees](gas.md#understanding-gas-fees), and rewards. |
| 75 | + |
| 76 | +The only way the blockchain layer is aware of the tokens and the gas is through the computation of the exchange rate |
| 77 | +and the inflation which is based strictly on the block production mechanics. |
| 78 | + |
| 79 | +## Validators |
| 80 | + |
| 81 | +Both the blockchain layer and the runtime layer are aware of a special group of participants who are |
| 82 | +responsible for maintaining the integrity of the Near Protocol. These participants called [Validators](network/validators.md) are associated with the |
| 83 | +accounts and are rewarded accordingly. The reward part is what the runtime layer is aware of, while everything |
| 84 | +around the orchestration of the validators is inside the blockchain layer. |
| 85 | + |
| 86 | +## Blockchain Layer Concepts |
| 87 | + |
| 88 | +Interestingly, the following concepts are for the blockchain layer only and the runtime layer is not aware of them: |
| 89 | + |
| 90 | +- Sharding -- the runtime layer does not know that it is being used in a sharded blockchain, e.g. it does not know |
| 91 | + that the trie it works on is only a part of the overall blockchain state; |
| 92 | +- Blocks or chunks -- the runtime does not know that the receipts that it processes constitute a chunk and that the output |
| 93 | + receipts will be used in other chunks. From the runtime perspective it consumes and outputs batches of transactions and receipts; |
| 94 | +- Consensus -- the runtime does not know how consistency of the state is maintained; |
| 95 | +- Communication -- the runtime does not know anything about the current network topology. Receipt has only a `receiver_id` (a recipient account), but knows nothing about the destination shard, so it's a responsibility of the blockchain layer to route a particular receipt. |
| 96 | + |
| 97 | +## Runtime Layer Concepts |
| 98 | + |
| 99 | +- [Fees and rewards](gas.md) -- fees and rewards are neatly encapsulated in the runtime layer. The blockchain layer, however, |
| 100 | + has an indirect knowledge of them through the computation of the tokens-to-gas exchange rate and the inflation. |
0 commit comments