# Hyperledger Fabric Network for Tool Data

## HFL Network Members:

- TCM [_Main Actor_]
They are the only member with the ability to create new records.
- Factories [Equal Members]
The other members of the network are organizations working with ToolTracer.

Each organization is a peer in the network. If a member finds a corrupt record it requests an update of this record. As soon as the record is marked with an request flag and the according proposed change, other peer (preferably not all of them) need to verify the update. Since the changes would be (mostly) about a physical property of the tool, the verification needs to be done manually (e.g. measuring the diameter). The verifying organization then needs to publish their results via either approving or rejecting.

For example like this could conclude this:

- If a certain threshold of approvings is exceeded, the record will be updated.

- In case of rejection of the majority, the request will be deleted.

Since this is not yet defined we need to decide on two major questions:

__What are the cases in that an update request would be accepted or would fail?__

This could be a minimum amount of validators and the ratio between accept/reject. It could also be accepted only if 100% of the necessary members approved and none rejected and so on.

__Is it beneficial to store rejected requests for later lookup?__

To avoid spending double effort to one request, already rejected request should preferably not be able to be proposed again by the same company. This would lead to having some kind of blacklist for specific properties of the golden record and the initial requesting organization. The same request could still be proposed by another member.

As stated before, the endorsement policy is met if some amount or percentage of members approve or reject the update request. As each organization is using their own database for production, it's now possible (but questionable) that peers specify their own endorsement policies, regarding their own database update. For example a peer could decide not to sync their database if TCM has not explicitly accepted the request. Another example: Updating everything from HLF except those updates who where approved by the majority (necessary amount of peers) but rejected by at least one peer. Obviously, this does also depend on the network endorsement policy. Extremes like always update and versa vis always require manual confirmation are possible, but these options are either insecure or high-effort solutions.

Since the update validation process is time consuming, there could be some kind of crediting system.
Otherwise the requests will never be processed and the data never changes.

__How should peers be motivated to validate requests?__
__Should there be some kind of mandatory validation participation in order to be part of the network (and receive updates)?__