Skip to main content

Concepts

The Carmentis chain is structured around several key concepts. Understanding these concepts will help you better understand the Carmentis ecosystem and how to interact with it.

Chain structure​

Accounts, Organizations and Applications​

Accounts, organizations and applications are the core concepts of the Carmentis ecosystem and are all related to each other following a hierarchical structure, as depicted below.

Account​

An account corresponds to a unique address and associated with a public (signature) key. As any blockchain, each account is associated with balance, the currency being denoted CMTS.

Public key format

These public keys are formatted in a clear way to be easily recognisable by humans: for instance, the following SIG:SECP256K1:PK{0358f1fb3e26661f29d6cc5bf31d8fa232030cc8277d2493c29e1913d4a7c9b0c0} is a public signature key.

Organization​

An organization corresponds to your company and provides information like your company's name or website. Publishing an organization is mandatory to be able to use the Carmentis protocol, and is currently used to organize the data on-chain chain.

Application​

Similarly to an organization, an application corresponds to a service offered by your organization. An application describes which website the user should visit to use the service, a name and a description of the service.

Behind the hood: Microblocks and Virtual blockchains​

Everything in the Carmentis's blockchain is composed of two ingredients: microblocks and virtual blockchains. In a nutshell, a virtual blockchain is like a standard blockchain, but simulated in a blockchain. As a blockchain is composed of blocks, a virtual blockchain is composed of microblocks. Let's focus on each of these terms.

Microblocks​

A microblock is the smallest unit of data that can be anchored in the blockchain. It contains a header containing standard, transaction processing-related information, as well as a body where all the data being anchored in the blockchain, including private ones are contained.

Creating a microblock programmatically is as simple as the following code snippet:

// we create an empty microblock used inside the account virtual blockchain
const mb = Microblock.createGenesisAccountMicroblock();

// we add two sections to define a public key and an account creation section used to indicate the 
// desire to create an account.
mb.addSections([
    {
        type: SectionType.ACCOUNT_PUBLIC_KEY,
        publicKey: await accountOwnerPublicKey.getPublicKeyAsBytes(),
        schemeId: accountOwnerPublicKey.getSignatureSchemeId()
    },
    {
        type: SectionType.ACCOUNT_CREATION,
        amount: initialAmount.getAmountAsAtomic(),
        sellerAccount: sellerAccountId
    }
]);

Virtual blockchains​

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. flow

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.

Application ledger: Where all your data ends​

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.

flow

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 data = {
    publicData: "The public data",
    aliceData: "Data only accessible by Alice and the Operator"
}

// the channel access rules
const accessRules = {
    // we assign the fields to be anchored in the virtual blockchain
    "fields": fields,
    
    // we declare channels over which the data are splitted
    "channels": [
        { name: "publicChannel", public: true},
        { name: "privateChannel", public: false},
    ],

    // we declare how the data are splitted
    "permissions": {
        "publicChannel": [ "this.publicData" ],
        "privateChannel": [ "this.aliceData" ]
    },
    
    // we declare actors 
    "actors": [ 
        "operator",  // the operator plays a special role of key holder, in addition to handling all the building work.
        "alice", // Alice is role that should be defined.
    ],
    
    // we declare the split of the data over the channels
    "subscriptions": {
        "operator": [ "privateChannel" ], 
        "alice": [ "privateChannel" ],
    },
    
    // we declare the application virtual blockchain id
    "applicationId": 1234,
   
}

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.

Ecosystem Overview​

This diagram illustrates the Carmentis ecosystem architecture. Users interact with the system through Carmentis Desk (desktop application) and a Browser containing their front-end application and the Carmentis Wallet extension. The company operates a server that communicates with the Operator via REST API, which serves as the bridge between the application layer and the blockchain. The Faucet provides tokens to both the Carmentis Wallet and Desk for testing or initial funding. The Operator anchors microblocks on the Carmentis Blockchain and handles transaction fees, while both the Wallet and Desk maintain connections to the blockchain for verification and monitoring purposes.

Operator​

Constructing and publishing microblocks in order to get virtual blockchain is not an easy task, as many technicalities need to be taken into account. For this reason, we have introduced the concept of operator. An operator plays a crucial role in the Carmentis protocol by providing a personnal API used to handle all the complexity for you. We have displayed below a (simplified) sequence diagram illustrating the interaction between the different components of the Carmentis ecosystem. As you can see, the wallet approves the action by signing it. This signed approval takes the form of a Micro block, encapsulating all relevant data associated with the event under review. The operator's signature on the Micro block establishes the event's authenticity, allowing it to proceed toward Wallet validation.

Here are some remarks about the sequence diagram:

  • During the anchoring request between the server and the operator, the server provides the data and application ledger building instructions (as previously described in the application ledger section). Then, the operator follows the instructions to create the application ledger microblock, generates a random anchor request identifier and returns it to the server.
  • The REST API used by the server to initiate the anchoring request with the operator is protected via an API-key system. Therefore, to use the operator, you must setup the operator accordingly and finally obtain an API key. Running the operator can be done via Docker, while configuring the operator is done via the Carmentis Desk.

Wallet​

In the Carmentis ecosystem, a wallet serves as a secure digital identity that enables users to interact with the protocol. It stores the user's private keys, which are essential for signing transactions and approving actions within the system. The wallet facilitates authentication, allowing users to log into applications without relying on traditional usernames and passwords. Moreover, it enables users to manage their approvals and share proofs of actions securely, all while ensuring privacy by keeping personal data confidential. Overall, the wallet is a crucial component that enhances security and usability within the Carmentis framework.

Carmentis Desk​

In the Carmentis ecosystem, a wallet serves as a secure digital identity that enables users to interact with the protocol. It stores the user's private keys, which are essential for signing transactions and approving actions within the system. The wallet facilitates authentication, allowing users to log into applications without relying on traditional usernames and passwords. Moreover, it enables users to manage their approvals and share proofs of actions securely, all while ensuring privacy by keeping personal data confidential. Overall, the wallet is a crucial component that enhances security and usability within the Carmentis framework.

Proof of authenticity​

With the advance of artificial intelligence used to produce close-to-real data including official documents, a shift of paradigm has been initiated, in which a document in considered false unless a proof of authenticity is provided. A natural following question might be "What kind of proof can we use to prove authenticity"?

It is exactly this point that Carmentis is trying to address, by providing an easy-to-use and flexible method to generate and share a proof of authenticity: The core of the proof mechanism is based on both the blockchain and on a cryptographic hash-based construction called a Merkle-tree. In few words, a Merkle-tree allows one, the prover, to create a so-called hash root over a given set of data. This hash root is anchored in the blockchain, preventing a tampering of this hash root. The prover then generates a proof of authenticity for a given subset of the data being inputted to compute the hash root. Later, the proof verifier, given the hash root anchored in the blockchain, the proof and the subset of data being inputted by the prover during the proof generation, can efficiently verify the authenticity of the same subset of the data.

An interesting property is that all the data being out of the subset used during the proof generation and proof verification do not have to be revealed. From an efficiency purpose, the Merkle-tree allows a short proof and an efficient proof verification.

Find more information about how to generate a proof and how to verify a proof in the dedicated documentation pages.

Themis network (Testnet)​

The currently deployed Testnet in Carmentis is called Themis. This network is composed of two types of nodes: Replication nodes and validator nodes. A replication node receives an approved event from the operator, taking the form of a micro-block, later being anchored in the chain. A validation node follows the same specification of the replication node, and is also in charge to validate the micro blocks, create the master blocks and anchor them in the blockchain.

The Carmentis network is composed of three validator nodes:

Validator nameValidator domainValidator IPv4Public key
Aphroditeaphrodite.carmentis.io148.113.194.97ircknIP9z3vVHF1J9PmW/Z6cyFoLIVxJ1HibuK2DtgU=
Apolloapollo.carmentis.io57.128.159.173XJMIspPDnlyo55RhN6X99tpi3vE2V93R+CUBfDirWJ8=
Aresares.carmentis.io54.36.209.1412O1nNS8Y1MZBWBBoF9w9wyMs7NVQZp6g56wfim6N7eU=

To check the liveness of Aphrodite, go to the following address http://aphrodite.carmentis.io:26657/status. The URL is the same for Apollo and Ares validators.

Static set of validators setup​

Currently, the set of validators is static. The list of validators is defined in the genesis block of Themis, accessible at http://ares.carmentis.io:26657/genesis. We provide you the following (editable) code to observe the genesis.

Live Editor
/**
 * React component asking the genesis block's data from Aphrodite replication node.
 */
function Component() {
    const [data, setData] = useState(null);

    useEffect(() => {
        const fetchData = async () => {
            const response = await fetch("http://aphrodite.carmentis.io:26657/genesis");
            const result = await response.json();
            setData(result);
        };

        fetchData();
    }, []);

    return (
        <div>
            <pre>{JSON.stringify(data, null, 2)}</pre>
        </div>
    );
}
Result
Loading...

Replication nodes​

In addition to the three existing validators, we have set up a replication node available at https://node.testapps.carmentis.io. Be aware that this replication node is optional: We provide all the necessary to let you launch your own node replication node. See the dedicated page for more details.

Related pages

Get your wallet

Wallet usage