1. 引言
NEAR为基于sharding的Layer 1扩容方案。与以太坊类似，为account-based system。
相关代码实现可参看：
Near节点可粗分为：
- 1）blockchain 层：用于支撑runtime that processes transactions differently，具有不同的虚拟机（如RISC-V），具有不同的fees。可通过account trie来了解account和validators。除此之外，并不直接操作accounts。
- 2）runtime 层：为交易的来源之处。对区块链层是否采用分片技术，采用何种共识，以及是否作为区块链的一部分运行均无需感知。runtime层本质上为a complex set of rules on what to do with accounts based on the information from the transactions and the receipts。runtime层需深入理解the concept of account。
NEAR协议有2个核心概念：
- 1）Transactions：代表区块链用户发起的请求，如send assets，create account，execute a method等。Transactions在Near节点之外创建，用户通过RPC或网络通信提交。
- 2）Receipts：代表内部结构，可将receipt想象成是a message which is used inside a message-passing system。Receipts由runtime根据交易创建，或者是处理其他receipts产生的结果。
blockchain层并不会创建或处理transactions和receipts，blockchain层仅passing them around and feeding them to a runtime。
仅blockchain层对以下信息感知，runtime层是感知不到的：
- 1）Sharding：runtime层并不知道其被用于a sharded blockchain，如，其不知道the trie it works on is only a part of the overall blockchain state。
- 2）Blocks or chunks：runtime不知道其处理的receipts包含了a chunk，而其输出的receipt将被用于其它chunks。从runtime角度看，其consumes and outputs batches of transactions and receipts。
- 3）Consensus：runtime本身是不知道state是如何维护一致性的。
- 4）Communication：runtime并不知道当前网络拓扑。Receipt仅有一个
receiver_id(a recipient account)，但并不知道目标shard，因此需要由blockchain层来路由特定的receipt。
fees and rewards被利索地封装在runtime层。blockchain 层可通过计算the tokens-to-gas exchange rate and the inflation来间接了解fees and rewards信息。
2. NEAR中的账号模型
NEAR采用account names系统（类似于域名），Account ID类似于用户名。如mutourend.near。
Account ID需遵循以下规则：【正则表达式为^(([a-z\d]+[\-_])*[a-z\d]+\.)*([a-z\d]+[\-_])*[a-z\d]+$】
- 最小长度为2，最大长度为64
- 可通过
.来分隔 - 小写字母之间可以
-或_分隔 - 长度若为64，且包含的都是lowercase hex characters，则该Account ID为implicit account ID。如
98793cd91a3f870fb126f66285808c7e094afcfc4eda8a970f6648cdf0dbd6de为implicit account ID。
单一account的data会分配在同一shard中，具体的account data有：
- Balance：为locked balance + unlocked balance之和。
- Locked balance (for staking)
- Code of the contract：一个account仅可有一个合约（为WebAssembly）。合约需 由account owner明确部署 或 在account creation过程中部署。A contract can be executed by anyone who calls a method on your account. A contract has access to the storage on your account.
- Key-value storage of the contract：每个account都有其自己的strorage，为persistent key-value trie。Keys以字典顺序排序。该storage仅可由该 account上的合约修改。
- Access keys：每个access key都由一个唯一的public key标识。该public key可用于对交易验签。每个access key包含了一个唯一的nonce来differentiate or order transactions signed with this access key。可分为full permission access key 和 function call permission access key。【每个account可有0个或多个access key。】
- Postponed ActionReceipts
- Received DataReceipts
2.1 system account
system为一种特殊的账号，仅用于表示refund receipts。对于refund receipts，可设置其predecessor_id为system来标记其为a refund receipt。用户无法创建或访问system account。事实上，该account不存在state中。
2.2 implicit account
implicit account 类似于比特币、以太坊账号。
本地生成ED25519 key-pair，以其公钥的lowercase hex representation来表示account ID。即ED25519 Public key is 32 bytes that maps to 64 characters account ID。
如 base58表示的公钥BGCCDDHfysuuVnaNVtEhhqeT4k9Muyem3Kpgq2U1m9HX，其对应的account ID为98793cd91a3f870fb126f66285808c7e094afcfc4eda8a970f6648cdf0dbd6de。
具有implicit account ID的account仅可用于send a transaction/receipt with a single Transfer action to the implicit account ID receiver：
- 该account将由该account ID创建。
- 该account由一个新的full access key with the ED25519-curve public key of
decode_hex(account_id)and nonce0。 - 该account balance将have a transfer balance deposited to it。
为了避免劫持，implicit account无法通过CreateAccount action来创建。
Once an implicit account is created it acts as a regular account until it’s deleted.
3. NEAR中的合约
可参看 NEAR Non-fungible Token (NFT) 步骤进行操作，部署示例NFT 合约。
