1. 引言

1）public_key：账号的压缩公钥。
2）token_id：
3）token_permission：Token_permissions.default
4）token_symbol：
5）amount：即balance。
6）nonce：nonce值逐交易递增
7）receipt_chain_hash：
8）delegate：委托账号的压缩公钥。
9）voting_for：对哪个state_hash投票
10）timing：Timing.Untimed。
11）permission：Permissions.user_default
12）zkapp：为Zkapp_account
13）zkapp_uri：为String。

	{ public_key
     ; token_id
     ; token_permissions
     ; token_symbol
     ; balance
     ; nonce
     ; receipt_chain_hash
     ; delegate
     ; voting_for
     ; timing
     ; permissions
     ; zkapp
     ; zkapp_uri
     }
(* Zkapp_account结构体为： *)
type ('app_state, 'vk, 'zkapp_version, 'field, 'slot, 'bool) t =
        { app_state : 'app_state
        ; verification_key : 'vk
        ; zkapp_version : 'zkapp_version
        ; sequence_state : 'field Pickles_types.Vector.Vector_5.Stable.V1.t
        ; last_sequence_slot : 'slot
        ; proved_state : 'bool
        }
        
(* Permission.user_default为： *)
let user_default : t =
  { edit_state = Signature
  ; send = Signature
  ; receive = None
  ; set_delegate = Signature
  ; set_permissions = Signature
  ; set_verification_key = Signature
  ; set_zkapp_uri = Signature
  ; edit_sequence_state = Signature
  ; set_token_symbol = Signature
  ; increment_nonce = Signature
  ; set_voting_for = Signature
  }

2. Mina account中的receipt_chain_hash

在account中引入receipt_chain_hash字段的动机在于：

Mina为succinct区块链，验证其状态为constant time。由于实现了constant-time lookup，不保留历史交易记录。
在某些情况下，让client证明他们的交易进入区块链是有帮助的。如果client想要证明他们向接收者发送了一大笔钱，这一点尤其有用。

receipt_chain_hash为该账号发送的所有交易的certificate。假设某账号已发送交易 $t_n\cdots t_1$ ， $p_n\cdots p_1$ 为这些交易的payload hash，则其receipt_chain_hash $r_n$ 为：
$r_n=H(p_n,H(p_{n-1},\cdots))=H(p_n,r_{n-1})$
其中 $H$ 为哈希函数。
初始状态， $r_0=$ Receipt.Chain_hash.empty 为the empty hash for receipt_chain_hash。【let empty = of_hash Random_oracle.(salt “CodaReceiptEmpty” |> digest)】

若client存储了 $r_k\cdots r_n$ ，则可证明其发送了交易 $t_k$ 。因为任何Verifier都可查询链上的当前状态，检查receipt_chain_hash等于 $r_n$ ，然后递归验证 $r_i=H(t_i,r_{i-1})$ 从 $i = 2 开始，直到 i = k 为止$ 。
也就是说，client需要存储所有的交易和receipt chain hash值，当client与Mina网络断开时，也必须保存这些数据。与此同时，client需要很容易根据这些交易和receipt chain hash值来获得链的当前状态——通过key-value数据库很容易实现，key为receipt chain hash值，value具有如下字段：

type value = Root | Child of {parent: receipt_chain_hash; value: transaction}

prove过程会提供a merkle list of $[(t_1,r_1),\cdots,(t_k,r_k)]$ ，其中 $r_i=H(t_i,r_{i-1})$ for $i=2\cdots k$ 。

这种设计的缺陷在于：

1）为了证明其发送了某笔交易，client需记录其发送的所有交易。对于发送多笔交易的用户来说不可行。且证明的复杂度为 $O (n)$ ， $n$ 为其已发送的交易数。
2）假定了a peer会通过同一机器发送交易。当a node在多台机器发送交易时，可将这些机器同步并共享其发送的交易。
对于用户来说，实现这种同步的最简单方案是在云数据库中存储其数据。用户也可在本地以cache形式存储其数据。

参考资料

[1] Mina rfcs 0006-receipt-chain-proving.md

附录1. Mina系列博客

Mina系列博客有：

Mina中的account

1. 引言

2. Mina account中的receipt_chain_hash

参考资料

附录1. Mina系列博客

猜你喜欢