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