4.3 Introduction CYFS for Developers: Status verification

[streetycat]

Verify status

In the web2 era, any information is read from a central server, you can trust any information from it as you trust the source server. It is very simple.

But in the web3 era, for decentralization, all information comes from servers provided by someone. For single owned information, we can trust it with the signature from owner as proof of accountability. As for shared property rights information, we can only obtain information from one of the members, and these members are likely to falsify information for their interests. Therefore, we need a verification method for the shared property rights information.

As mentioned in the previous article, we use Hotstuff as the consensus algorithm for sharing property rights. Naturally, we also adopt the corresponding verification strategy with 2f+1 signature rate.

1. Verify with block

Every block on the chain can be verified by any node. We use the BFT consensus algorithm. Each valid block holds the voting signatures of 2f+1 nodes naturally, so all the fields contained in the block are recognized, the field result_state_id is the ObjectId of the state of property rights information.

2. Verify the sub-fields

• Verify based on ObjectId

We known earlier that result_state_id is a tree structure object implemented by ObjectMap; result_state_id is obtained by computing Hash from all branches and leaf node values in this tree.

Therefore, all branch and leaf node values of result_state_id are trusted.

However, we must read the full Desc (immutable part) of the Object to verify if an Object is matched with the ObjectId, in other words: we must read all elements of ObjectMap and compare their Hash with result_state_id to verify that one of the elements is correct.

• Which fields will be read to verify the sub-field with the specified path?

Now, it's clear that we must verify ObjectMapId of a branch in each level to verify the sub-field in a tree specified by a path. A flowchart is as follow:

flowchart TB

    Init(path, state_id) --> IsEmptyPath{path is empty}
    IsEmptyPath --no--> Read["obj_map = get(state_id)"]
    IsEmptyPath --yes--> Found(return state_id)
    Read --> Verify["state_id = ObjectId(obj_map)"]
    Verify --> NextPath["sub_paths=split(path,'/');\nnext_path=sub_paths[0];\npath=sub_paths[1..].join('/');"]
    NextPath --> NextState["state_id = obj_map.get(next_path)"]
    NextState --> IsExistState{state_id == None}
    IsExistState --yes--> None(return None)
    IsExistState --no--> IsEmptyPath

We can see that we must read the full content of the first-level subdirectory contained in each level of directory to verify a child node specified by the path in the tree:

flowchart TB

    Root --> P_1_1[p.1.1]
    Root --> P_1_2[p.1.2]
    Root --> P_1_3[p.1.3]
    Root --> P_1_x[...]
    Root --> P_1_f1[folder.1]
    Root --> P_1_x1[...]
    P_1_f1 --> P_2_1[p.2.1]
    P_1_f1 --> P_2_x[...]
    P_1_f1 --> P_2_f2[folder.2]
    P_1_f1 --> p_2_x[...]
    P_2_f2 --> P_x_x[...]
    P_x_x --> P_n_fn[folder.n]

3. Performance

We stated a complete state verification scheme above, but there is a problem that we must read a large amount of redundant data for a specified field of a shared property right information. It is an impossible task in a scenario with a large data.

I think there are several solutions:

• Design each rpath (representing a consensus unit in a shared property rights) carefully so that its capacity is small, and divide the large container structures into segments for management (for example: every 16 is a segment).

• Add 2f+1 signatures to the result of each request. The server returns only the specified field(0 redundancy) for each status request, but servers owned by members of the organization must sign on the field. Of course, the burden on the service node will be increased for signatures, the more queries, the more signatures.