|
| 1 | +## Legend |
| 2 | +There are some types of requests to Nodes in the Pool allowing to use StateProof optimization in Client-Node communication. |
| 3 | +Instead of sending requests to all nodes in the Pool, a client can send a request to a single Node and expect StateProof signed by BLS multi-signature. |
| 4 | + |
| 5 | +BLS multi-signature (BLS MS) guaranties that there was a consensus of Nodes which signed some State identified by State RootHash. |
| 6 | +StateProof (SP) is small amount of data which allows to verify particular values against RootHash. |
| 7 | +Combination of BLS MS and SP allows clients to be sure about response of single node is a part of State signed by enough Nodes. |
| 8 | + |
| 9 | +## Goals |
| 10 | +Libindy allows to extend building of supported requests via plugged interface and send them. |
| 11 | +It is nice to have a way to support BLS MS and SP verification for these plugged transactions. |
| 12 | + |
| 13 | +Implementation of math for SP verification is a bit complicate for plugin logic. |
| 14 | +Therefore libindy should perform all math calculation inside. |
| 15 | +A plugin should provide handler to parse custom reply to fixed data structure. |
| 16 | + |
| 17 | +## API |
| 18 | +The signature of the handler is described below together with custom `free` call to deallocate result data. |
| 19 | + |
| 20 | +```rust |
| 21 | +extern fn CustomTransactionParser(reply_from_node: *const c_char, parsed_sp: *mut *const c_char) -> ErrorCode; |
| 22 | +extern fn CustomFree(data: *mut c_char) -> ErrorCode; |
| 23 | +``` |
| 24 | + |
| 25 | +Libindy API will contain call to register handler for specific transaction type: |
| 26 | +```rust |
| 27 | +extern fn indy_register_transaction_parser_for_sp(command_handle: i32, |
| 28 | + pool_handle: i32, |
| 29 | + txn_type: *const c_char, |
| 30 | + parser: CustomTransactionParser, |
| 31 | + free: CustomFree, |
| 32 | + cb: extern fn(command_handle_: i32, err: ErrorCode)) -> ErrorCode; |
| 33 | +``` |
| 34 | + |
| 35 | +### Parsed Data structure |
| 36 | + |
| 37 | +A plugin should parse `reply_from_node` and return back to libindy parsed data as JSON string. |
| 38 | +Actually this data is array of entities each of them is describe SP Trie and set of key-value pairs to verify against this trie. |
| 39 | +It can be represented as `Vec<ParsedSP>` serialized to JSON. |
| 40 | + |
| 41 | + |
| 42 | +```rust |
| 43 | +/** |
| 44 | + Single item to verification: |
| 45 | + - SP Trie with RootHash |
| 46 | + - BLS MS |
| 47 | + - set of key-value to verify |
| 48 | +*/ |
| 49 | +struct ParsedSP { |
| 50 | + /// encoded SP Trie transferred from Node to Client |
| 51 | + proof_nodes: String, |
| 52 | + /// RootHash of the Trie, start point for verification. Should be same with appropriate filed in BLS MS data |
| 53 | + root_hash: String, |
| 54 | + /// entities to verification against current SP Trie |
| 55 | + kvs_to_verify: KeyValuesInSP, |
| 56 | + /// BLS MS data for verification |
| 57 | + multi_signature: serde_json::Value, |
| 58 | +} |
| 59 | + |
| 60 | +/** |
| 61 | + Variants of representation for items to verify against SP Trie |
| 62 | + Right now 2 options are specified: |
| 63 | + - simple array of key-value pair |
| 64 | + - whole subtrie |
| 65 | +*/ |
| 66 | +enum KeyValuesInSP { |
| 67 | + Simple(KeyValueSimpleData), |
| 68 | + SubTrie(KeyValuesSubTrieData), |
| 69 | +} |
| 70 | + |
| 71 | +/** |
| 72 | + Simple variant of `KeyValuesInSP`. |
| 73 | +
|
| 74 | + All required data already present in parent SP Trie (built from `proof_nodes`). |
| 75 | + `kvs` can be verified directly in parent trie |
| 76 | +*/ |
| 77 | +struct KeyValueSimpleData { |
| 78 | + kvs: Vec<(String /* b64-encoded key */, Option<String /* val */>)> |
| 79 | +} |
| 80 | + |
| 81 | +/** |
| 82 | + Subtrie variant of `KeyValuesInSP`. |
| 83 | +
|
| 84 | + In this case Client (libindy) should construct subtrie and append it into trie based on `proof_nodes`. |
| 85 | + After this preparation each kv pair can be checked. |
| 86 | +*/ |
| 87 | +struct KeyValuesSubTrieData { |
| 88 | + /// base64-encoded common prefix of each pair in `kvs`. Should be used to correct merging initial trie and subtrie |
| 89 | + sub_trie_prefix: Option<String>, |
| 90 | + kvs: Vec<(String /* b64-encoded key_suffix */, Option<String /* val */>)>, |
| 91 | +} |
| 92 | +``` |
| 93 | + |
| 94 | +Expected libindy and plugin workflow is the following: |
| 95 | +1. Libindy receive reply from a Node, perform initial processing and pass raw reply to plugin. |
| 96 | +1. Plugin parse reply from the Node and specify one or more SP Trie with metadata and items for verification. |
| 97 | +1. Each SP Trie described by plugin as `ParsedSP`: |
| 98 | + 1. Set of encoded nodes of the SP Trie, received from Node - `proof_nodes`. May be fetched from response "as is". |
| 99 | + 1. RootHash of this Trie. May be fetched from the response "as is" also. |
| 100 | + 1. BLS MS data. Again may be fetched from the response "as is". |
| 101 | + 1. Key-value items to verification. Here plugin should define correct keys (path in the trie) and corresponded values. |
| 102 | +1. Plugin return serialized as JSON array of `ParsedSP` |
| 103 | +1. For each `ParsedSP` libindy: |
| 104 | + 1. build base trie from `proof_nodes` |
| 105 | + 1. if items to verify is `SubTrie`, construct this subtrie from (key-suffix, value) pairs and merge it with trie from clause above |
| 106 | + 1. iterate other key-value pairs and verify that trie (with signed `root_hash`) contains `value` at specified `key` |
| 107 | + 1. verify multi-signature |
| 108 | +1. If any verification is failed, libindy ignore particular SP + BLS MS and try to request same data from another node, |
| 109 | +or collect consensus of same replies from enough count of Nodes. |
| 110 | + |
| 111 | + |
| 112 | +Below is JSON structure for `Simple` case. |
| 113 | +```json |
| 114 | +[ |
| 115 | + { |
| 116 | + "proof_nodes": "string with serialized SP tree", |
| 117 | + "root_hash": "string with root hash", |
| 118 | + "kvs_to_verify": { |
| 119 | + "type": "simple", |
| 120 | + "kvs": [["key1", "value1"], ["key2", "value2"]] |
| 121 | + }, |
| 122 | + "multi_signature": "JSON object from Node`s reply as is" |
| 123 | + } |
| 124 | +] |
| 125 | +``` |
| 126 | + |
| 127 | +### Simple and SubTrie verification |
| 128 | + |
| 129 | +Some use cases require verification multiply pairs of key-value in one Trie. |
| 130 | +Moreover there is possible situation when client would like to verify whole subtrie. |
| 131 | +In this case, the amount of data transferred from Node to Client can be significantly reduced. |
| 132 | +Instead of including all nodes for SP verification to `proof_nodes`, Node can include only prefix path down to subtrie. |
| 133 | +The entire subtrie to verification can be restored on Client side from key-value pairs and combined with prefix part. |
0 commit comments