Virtual blockchains and channels

The Carmentis protocol is fundamentally designed to be multiple purposes and relies on the blockchain to ensure integrity of the data. Hence, our blockchain should be designed to accept data being business-dependent having a inherent different structure. To limit the overall complexity of our protocol, we have introduced the notion of virtual blockchain, being similar to L2-blockchain except that we manage both L1 and L2 blockchains.

Virtual blockchain

The virtual blockchain acts as a dedicated logical blockchain in which the content of an application is anchored. Every execution of an application leads to the creation of virtual blockchain. In other words, multiple virtual blockchains are attached to a single application. To be more concrete, in case where a lawyer wants signers to sign a contract, a new virtual blockchain will be created. To avoid confusion, we note that the block term refers to a block of the blockchain whereas micro-block refers to a block of the virtual blockchain. This notion of virtual blockchain is depicted below.

A virtual blockchain anchors all the data sent by the application to the blockchain, including private ones. Be aware that private data anchored in the virtual blockchain are not revealed to the public, standing in contrast with public data being anchored without any confidentiality protection. To prevent one to access private data without authorisation, we have introduced another notion atop of the virtual blockchain, called channels.

Roles & Channels

Within the Carmentis protocol, a channel is the cornerstone of the feature allowing asymmetry of information. For concreteness, suppose an official government document containing three sections: a public section visible by all the citizens, a second section for all governmental agencies (including NSA), and a last section being accessible only by NSA. The Carmentis protocol is particularly well-suited to solve this asymmetry of information. Assume that a virtual blockchain has been created for the occasion. In this case, the virtual blockchain contains exactly three distinct channels: A public channel for the first public section, a private channel for the government agencies section and a private channel for the secret-defense data being accessible only by the NSA.

When developing your application, you have to specify the channel access rules, defining which role can access which channel and that data included in every channel. For clarity, we provide the channel access rules definition for the example presented above.

// the data being anchored in the virtual blockhain
const fields = {
    publicData: "The public data",
    officialData: "Data accessible by the government and NSA.",
    secretData: "Secret data accessible only by NSA"
}

// the channel access rules
const accessRules = {
    "fields": fields,
    "channels": [ "governmentChannel", "secretChannel" ], // only private channels are defined
    "roles": [ "citizen", "governementAgent", "secretAgent" ],
    "subscriptions": {
        "citizen": [], // a citizen can only access public channels
        "governementAgent": [ "publicChannel, governementChannel" ],
        "secretAgent": [ "*" ] // a secret agent can observe all channels
    },
    "permissions": {
        "governementChannel": [ "fields.officialData" ],
        "secretChannel": [ "fields.officialData, fields.secretData" ]
    },
}

In the above example, the subscriptions and permissions fields are important since there are used to define respectively the access of each role to a set of channels, and to define which data is contained in each channel.

Public channel

Note that there is always a single public channel in which all public fields are stored. The public channel always exist and should not be declared as a channel since all declared channels in the channel access rules are private.

While the public channel do not prevent any illegitimate access to the data being anchored in the channel, the private channel prevents user not having the appropriate role to reade the data using standard encryption. The key used to encrypt the private data are generated by the operator. When a user wants to access the private channel, it has to authenticate to obtain the encryption key used to decrypt all the data being anchored in the private channel.