1はじめに

ミナのアカウントのフィールドは次のとおりです。

1）public_key：アカウントの圧縮された公開鍵。
2）token_id：
3）token_permission：Token_permissions.default
4）token_symbol：
5）量：つまり、バランス。
6）nonce：nonce値はトランザクションによって増分されます
7）receipt_chain_hash：
8）委任：委任されたアカウントの圧縮された公開鍵。
9）voting_for：どのstate_hashに投票するか
10）タイミング：タイミング。時間制限なし。
11）permission：Permissions.user_default
12）zkapp：Zkapp_accountの場合
13）zkapp_uri：文字列。

	{ 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アカウントのReceive_chain_hash

アカウントにreceipt_chain_hashフィールドを導入する動機は次のとおりです。

ミナは簡潔なブロックチェーンであり、その状態は一定時間として検証されます。定数時間ルックアップの実装により、履歴トランザクションレコードは保持されません。
場合によっては、トランザクションがブロックチェーンに入ったことをクライアントに証明させると役立つことがあります。これは、クライアントが受信者に多額のお金を送ったことを証明したい場合に特に便利です。

receipt_chain_hashこのアカウントに送信されたすべてのトランザクションの証明書。アカウントがトランザクション $tn⋯t1t_n\cdotst_1を送信したとします。$ 、 $p_n \ cdots p_1$ はこれらのトランザクションのペイロードハッシュであり、次にそのreceipt_chain_hash $r_n$ 是：
$1）r_n = H（p_n、H（p_ {n-1}、\ cdots））= H（p_n、 r_ {n-1}）$
ここで $H$ はハッシュ関数です。
初期状態、 $r_0 =$ Receipt.Chain_hash.empty空のハッシュをreceipt_chain_hashます。【letempty=of_hash Random_oracle。（salt“ CodaReceiptEmpty” |>ダイジェスト）]

クライアントが $rkを保存する場合⋯rnr_k\cdots r_n$ $、トランザクションtkt_k$ を送信したことを証明できます $t$ 。どのベリファイアもチェーンの現在の状態を照会できるため、チェックreceipt_chain_hashは $rnr_nと等しくなります。$ $1）r_i = H（t_i、r_ {i-1}）$ であることを再帰的に検証します。 $r = H （ t 、 r_{i -1} ）$ i=2から $私 = 2 は i_まで開始します = k まで$ 。
つまり、クライアントはすべてのトランザクションとレシートチェーンのハッシュ値を保存する必要があります。クライアントがMinaネットワークから切断されると、これらのデータも保存する必要があります。同時に、クライアントはこれらのトランザクションとレシートチェーンハッシュ値に従ってチェーンの現在の状態を簡単に取得する必要があります-キー値データベースを介して簡単に取得でき、キーはレシートチェーンハッシュ値であり、値には次のフィールドがあります。

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

証明手順は、 $[（t_1、r_1）、\ cdots、（t_k、r_k）]のマークルリストを提供します。$ ，其中 $r_i=H(t_i,r_{i-1})$ fori $=2⋯ki=2\ cdots k$ 。

この設計の欠陥は次のとおりです。

1）トランザクションを送信したことを証明するために、クライアントは送信したすべてのトランザクションを記録する必要があります。複数のトランザクションを送信するユーザーには適していません。そして、証明の複雑さは $O （ n ）$ 、 $n$ は送信されたトランザクションの数です。
2）ピアが同じマシンを介してトランザクションを送信すると想定されています。ノードが複数のマシンでトランザクションを送信する場合、これらのマシンを同期して、送信するトランザクションを共有できます。
ユーザーがこの同期を実現するための最も簡単なソリューションは、データをクラウドデータベースに保存することです。ユーザーは、データをキャッシュ形式でローカルに保存することもできます。

参考文献

[1]ミナrfcs0006-receipt-chain-proving.md

付録1.ミナブログシリーズ

ミナシリーズのブログには次のものが含まれます。

ミナのアカウント

1はじめに

2.MinaアカウントのReceive_chain_hash

参考文献

付録1.ミナブログシリーズ

おすすめ