Encrypted inputs

To integrate a new input into the system, users are required to invoke the validateCiphertext function. This function is specifically designed to handle an input of the Inputtext™ type. The Inputtext™ consists of two critical components that are indispensable for its operation: the input ciphertext and a corresponding user address.

The process begins with the preparation of the input ciphertext, which is the encrypted form of the data. This component ensures that the data is securely transmitted and protected from unauthorized access. The ciphertext is accompanied by a user address who encrypted the ciphertext. Inputtext™ refers to the combination of the ciphertext and the address.

For example, the MpcCore library defines a 64-bit Inputtext™ type and its validateCiphertext function as follows:

struct itUint64 {
    address userAddress;
    ctUint64 ciphertext;
}

function validateCiphertext(itUint64 memory input) internal returns (gtUint64) {
    return gtUint64.wrap(GCExtendedOperations(address(GCHandlerAddress)).
        ValidateCiphertext(bytes1(uint8(MPC_TYPE.SUINT64_T)), input.userAddress, ctUint64.unwrap(input.ciphertext)));
}

The GCHandler smart contract manages the validation and integration processes:

Transaction Validation Process:

The following process outlines how validateCiphertext validates the given Inputtext™ before ciphertext is onboarded into the Bubble system:

1. Transaction Origin Matches User Address:
   • If the origin of the transaction matches the given user address, it indicates that the user encrypting the plaintext is indeed the individual initiating the transaction.
   • In this scenario, the transaction is immediately deemed valid.
   • As a result, the associated ciphertext is authorized to be onboarded into the Bubble system without further checks.
2. Transaction Origin Differs from User Address:
   • In cases where the transaction origin does not match the user’s address, additional checks are necessary.
   • The system relies on the GCACL, which is responsible for handling permissions.
   • The GCHandler's ensures, using the GCACL, that the user has explicitly given permission for the transaction origin to act on their behalf.
   • Only if there is clear evidence of granted permission can the ciphertext be safely added to the Bubble system.
   • If such permission is not verified, the system is designed to revert the transaction to prevent unauthorized actions. This ensures the integrity and security of user data within the Bubble system.

This detailed validation process ensures that every transaction is secure and compliant with user permissions, safeguarding the confidentiality and trust of the Bubble system's users.

Onboard ciphertext:

• After verifying the transaction, the ciphertext is integrated into the system and converted to the garbledtext™ handle. This is done by emitting the GCOnboard event, which is triggers the Bubble connector to initiate the computation flow.