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

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

The dApp sends this agreement request to an RPC node. The transaction enters the transaction mempool and is broadcast to the specified Guardian nodes. Each Guardian reviews the agreement parameters and provides its agreement. Once all required Guardians have given their agreement, the finalized agreement is included in a block on the Manas Blockchain and assigned a unique Agreement ID. This Agreement ID serves as the on-chain reference for subsequent compute 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 Agreement ID. 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 established agreement.

After decryption, the compute request is forwarded to the designated compute node. Depending on the configuration, in Manas, any Guardian Node can be a Standard Guardian Node or a Computing Guardian node. More precisely, a Non-computing Trusted Node does not process the computation itself but delegates it to servers it trusts, where communication with said servers is fully protected by cryptographic means (both from tampering and from leakage). A Confidential Computing Trusted Node actively takes part in the requested computation. In the current implementation, a Manas Guardian can simultaneously act 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 agreement, the data are consumed by the defined computation or 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, decrypts (if necessary at the application layer), and presents it within the application.

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 Agreement ID arrives at 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 time required for agreement finalization, threshold decryption, and computation.

Therefore, the node client assigns a unique identifier to each Compute Request to establish a connection between the agreement, the compute request, and its result. In Manas, this identifier is generated by hashing key data points from the Compute Request together with the Agreement ID. The dApp can independently compute and track this identifier in each block’s event log, ensuring deterministic linkage between request and result.

The dapp monitors block production events on the Manas Blockchain. Upon detecting the desired result, the dapp fetches, decrypts, and presents it within the application. Another important aspect of the computation handling is the interaction between blockchain blocks and the dapp. Due to the offchain nature of the processing, when a 'Compute Request' arrives at the Manas Blockchain in block number t, clearly the computation result will not be available until a future block with block number (t + n), where n represents the time required for the computation. Therefore, the node client assigns a unique identifier to each request to establish a connection between the compute request and its result. In Manas, this identifier is generated by hashing key data points from the 'Compute Request.' The dapp can then independently compute and find this identifier in each block's event log.

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.