NEAR协议简介

Posted 2021-12-10 mutourend

1. 引言

NEAR为基于sharding的Layer 1扩容方案。与以太坊类似，为account-based system。

相关代码实现可参看：

• https://github.com/near

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 nonce 0。
• 该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 合约。

参考资料

[1] NEAR Protocol Specification