A web of trust model between registries - shared secrets approach

[wisbech]

A web of trust model for the OriginRegistry could be implemented incorporating a third-party blockchain as the immutable log adds an extra layer of security and transparency to the system.

graph LR
    A[Registry Operator A] -- Validation Request --> B((Smart Contract))
    B -- Validation Request --> C[Registry Operator B]
    B -- Validation Request --> D[Registry Operator C]
    B -- Validation Request --> E[Registry Operator D]
    C -- Signed Validation --> B
    D -- Signed Validation --> B
    E -- Signed Validation --> B
    B -- Consensus --> F((Blockchain))
    F -- Add to Blockchain --> B

Loading

• A, B, C, and D represent different registry operators in the network.
• The Smart Contract node represents the smart contract on the blockchain that handles the validation requests and responses.
• The Blockchain node represents the third-party blockchain used as the immutable log.
• Arrows represent the flow of requests and data between the nodes.

Here's how the model would work:

• Shared Secrets: Each registry in the network holds a piece of a shared secret. This secret is used to validate transactions or batches of transactions. The shared secret is distributed using a secure method such as Shamir's Secret Sharing scheme.

• Batch Validation: When a registry operator wants to validate a batch of transactions, they create a validation request and send it to other nodes in the network. This request includes a hash of the batch, signed with the registry's private key.

• Smart Contract: The validation request is handled by a smart contract deployed on the third-party blockchain. The smart contract verifies the request using the shared secret and the sender's private key. If the request is valid, the smart contract adds the sender's signature to the request.

• k of n Validation: The validation request needs to be approved by a subset (k) of the total nodes (n) in the network. Each of these nodes verifies the request using the shared secret and their own private key. If the request is valid, they sign the hash and send it back to the requesting registry.

• Consensus: Once the requesting registry has received a sufficient number of signatures (k), it considers the batch as validated.

• Blockchain Logging: The validated batch is then added to a third-party blockchain. This serves as an immutable log that provides a transparent and tamper-proof record of all validated batches. The blockchain could be a public one like Ethereum or a permissioned one like Hyperledger Fabric, depending on the requirements of the system.

• Trust: Over time, this process creates a web of trust between the nodes in the network. Each node has a record of the transactions validated by other nodes, contributing to the overall trustworthiness of the system.

By using a third-party blockchain as the immutable log and incorporating a smart contract for validation request handling, the system gains the benefits of decentralization, transparency, immutability, and automated validation. This makes it more difficult for any single party to tamper with the system and provides a clear audit trail of all transactions.

sequenceDiagram
    participant Registry1 as Registry 1
    participant Registry2 as Registry 2
    participant Registry3 as Registry 3
    participant Blockchain as Blockchain

    Registry1->>Registry2: Validation request (with shared secret)
    Registry1->>Registry3: Validation request (with shared secret)
    Note over Registry2,Registry3: Verify request using shared secret and private key
    Registry2->>Registry1: Signed hash (if request is valid)
    Registry3->>Registry1: Signed hash (if request is valid)
    Note over Registry1: Consensus (receives k signatures)
    Registry1->>Blockchain: Add validated batch to blockchain

Loading

This diagram shows that Registry 1 sends a validation request to Registry 2 and Registry 3. These registries verify the request using the shared secret and their own private key. If the request is valid, they sign the hash and send it back to Registry 1. Once Registry 1 has received a sufficient number of signatures (k), it considers the batch as validated and adds it to the blockchain.