Architecture

We have implemented a working prototype or testnet for Palliora, that we call Manas. On the infrastructure side, Manas consists of a set of Validators under Proof of Stake consensus mechanism and Guardian Network (that can scale to a few hundred participants).

Manas Validators maintain the Data Availability (DA) capabilities of the network, including the storage, verification. Validators maintain the blockchain state, therefore complying with both block production and transaction validation and interactions with Guardians.

On the other hand, Manas Guardians are responsible for enabling both data accountability and confidential computation. The standard Guardian network implements flexible threshold setting among a selected subgroup of Guardian nodes participating in managing access to the data on-chain, catering to user-driven/chosen trusted security circle on the Manas network. The Guardian protocol implements the Silent-Threshold Encryption as the cryptographic protocol that provides a safe environment for on-chain requests when they are in-transit or at rest in the DA service. The integrated Trusted and Confidential computing services of the Manas Guardians nodes or Calculators allow for enhanced sources for data generation with built-in confidentiality.

Manas enables two crucial roles of Publishers and Retrievers who can submit encrypted data (new or duplicate) and access existing data, respectively. The value of the data posted on the Manas is determined by the Publisher (i.e. its Owner) and the Retriever must provide the set price to have access. The price is set in PALI tokens; in this way, the network's economics is balanced with the associated cost of maintaining the DAC service of Manas.

The Guardian network participation is open for anyone who follows certain rules set in the runtime contract, As long as they can setup a Palliora node client and stake a minimum amount of PALI tokens. During a node client setup, the operator manages a KeyPair (sk, pk) secret to have ownership of rewards and stakes. When the guardian set evolves, then the guardian set parameter gets updated in the runtime contract. This update is linked to a configured numbers of blocks (termed as an epoch). The KeyPair acts as both an identifier (for the node client) and a security parameter for the threshold decryption. Guardian nodes are capable of downloading the computation program in the containerized framework (e.g. Docker) so that Calculator (a sub-category of Guardian node) can execute a trusted or confidential setup (e.g. TEE).

Lifecycle of the request

A dApp is a decentralized application that works with a user-owned software wallet. Any dApp interacts with the Manas network through RPC calls, mainly to submit compute requests to the Guardians.

Several reference dApps are available that have served as early users of Palliora:

• Veilnyx – Compliant privacy by selective disclosures

• Valorae – Private AI chatbot

• Lynra – Accountable and Private DeFi and AI agents

• Datari – Fine-tuning of LLM models using privately shared data

The request starts with the data submission in encrypted format, where standard Guardian nodes are entrusted with safeguarding the private data. The Manas Data Availability layer utilizes erasure encoding and KZG commitments to offer recoverability, proof of existence, and a confidence metric to its application layers.

Erasure encoding introduces data redundancy, safeguarding against potential losses with a degree of recoverability. KZG commitments enable efficient proof of data existence without revealing the data itself.

Once this Guardian receives the compute request, it generates a shared key and decrypts the encrypted request. The decrypted ciphertext contains the necessary payload for the compute service. If the node that receives the request does not process it, even a corrupt node will fail to access the requested data due to the encryption encapsulating it.

The request follows the Palliora protocol for selective data sharing and pricing between the Publisher and the Retriever.

The request flow continues with the dApp creating a Compute Contract Agreement Request. This contract specifies the economic parameters of the computation, including the cost of the computation the user is willing to pay, threshold decryption fees, and the list of Guardians that the user wants to involve. This contract proposal (agreement request) formalizes the terms under which the computation will be executed.

The dApp sends this proposal to an RPC node. The transaction enters the transaction mempool and is broadcast to the specified Guardian nodes. Each Guardian reviews the contract parameters and provides its agreement. Once all required Guardians have signed their agreement on the contract, the finalized contract is included in a block on the Manas blockchain and assigned a unique Contract ID (CID).

This CID serves as the reference on the chain for subsequent computation operations. The fees are locked at this point.

After the agreement is finalized on-chain, the dApp submits the actual Compute Request, explicitly referencing the CID. The compute payload is submitted in encrypted format, where the selected Guardian group is entrusted with safeguarding and threshold decrypting the private data in accordance with the contract.

After decryption, the compute request is forwarded to the designated computing node (the so-called Calculators). As a matter of fact, depending on the configuration, in Manas any Guardian node can be a Standard node, a Computing node, or even a Verifier node.

As regards computing nodes, they can be either trusted or confidential, where trusted means they can see the input and confidential means they cannot. Users can select the type of computing nodes.

Interestingly, in the current implementation, a Manas Guardian can choose to act simultaneously as both a Trusted and a Confidential Compute node, appropriately serving each type of compute request.

The properties of the Manas network ensure that once decrypted and forwarded according to the contract, the data is processed by the requested computation (for example, a pre-trained AI model), which generates a suitable response.

The dApp continuously monitors block production events on the Manas blockchain. Upon detecting the desired result, the dApp fetches it, decrypts it (if necessary at the application layer), and finally presents it to the user.

Another important aspect of the computation handling is the interaction between blockchain blocks and the dApp. Due to the off-chain nature of the processing, when a Compute Request referencing a specific CID reaches the Manas blockchain in block number t, the computation result will not be available until a future block with block number (t + n), where n represents the total time required for agreement finalization, threshold decryption, and computation.

Performance

The Palliora Manas network comes with a runtime contract that enables 4MB-sized blocks with a block time of 6.0 seconds. The block sizes can be increased in future to accommodate higher throughput. The current testent network can reach a TPS of 700 tx/sec. The Manas testnet is running a BABE-GRANDPA protocol for block authoring, finality, and fork selection, providing a finality time in the range of 15-20 seconds. The DA Manas network incorporates an archive store of block history, as well as large-file storage. Currently, Manas storage node is configured for 300GB of raw storage, served by an erasure encoding-enabled database. Guardian clients can join the network every 4-hour interval.