Delorean Protocol

Practical encryption to the future can be done using a blockchain in combination with witness encryption. A plaintext can is encrypted such that the decryption key is produced when a threshold of validators sign a chosen message. This is used by protocols such as tlock and McFLY.

In these protocols the message is chosen to be a block height in the future. With particular blockchains such as DRAND it is guaranteed that the validators will sign every block height and the decryption key will be automatically generated and made public. The limitation of this is it only supports encryption to the future. No additional constraints can be placed on key generation.

Delorean protocol extends this idea to allow programmable conditions for decryption key release while maintaining the same (and in some cases better) security guarantees. Users can deploy Solidity smart contracts that encode the conditions under which the network operators must generate a decryption key.

Some examples might be:

• Fund Raising - Key is released once the contract raises some amount of funds
• Hush Money - Key is released if the contract does not receive a periodic payment
• Dead Man Switch - Key is released the contract it doesn't receive a 'heartbeat' transaction from a preauthrized account for a number of blocks
• Filecoin Deal integration - Key is released once a particular Filecoin deal is discontinued
• Price Oracle integration - Key is released if some asset reaches a given price
• Encrypted Transactions / Encrypted Mempool

Being an IPC subnet Delorean is a fully fledged EVM chain that can also message other subnets in the wider network. This means conditions could be encoded that rely on other chains (e.g Filecoin deals).

We also developed a CLI that makes it easy to encrypt and decrypt files with keys tied to deployed condition contracts. Encryption and decryption takes place fully off-chain and does not require communication with the validators.

Delorean is implemented as an IPC Subnet allowing it to be easily bootstrapped and have access to assets from parent chains (e.g. FIL). It uses CometBFT for consensus and a modified version of the FVM for execution which communicates with the consensus layer via ABCI.

The feature of CometBFT that makes the protocol possible is the vote extension feature added in ABCI v0.38. In CometBFT validators vote on blocks to be finalized. Vote extensions allow the execution layer to enforce additional data to be included for votes to be valid. In Delorean the additional data is a BLS signature over the next tag in the queue (more detail on this later). If this signature is not included then the vote is invalid and cannot be used to finalize the block. The result is that the liveness of the chain becomes coupled to the release of these signed tags and inherits the same guarantees.

Delorean Actor

Deloran adds a new actor to the FVM that stores the queue of tags and allows contracts in the FEVM to pay gas to enqueue new tags. Once a tag is added to the queue the validators MUST include a signature over it in their next vote or else they are committing a consensus violation. The block proposer combines all of the signatures from the votes into an aggregate and includes an additional transaction which writes it back to the actor state. This aggregate signature is a valid decryption key for data encrypted to this tag!

A tag is defined as:

tag = SHA256(contractAddress || arbitaryData)

It is defined this way so someone else cannot write another contract which causes your key to be released. The tag (and hence decryption key itself) is tied to the address of the contract that manages it.

Cryptography

We use the threshold BLS Identify Based Encryption algorithm of Gailly, Melissaris and Yolan Romailler (2023) for encryption and decryption.

Encryption is done using the tag used in combination with the validator public keys. This takes place fully-offchain and without any communication with the validators as follows:

ciphertext = encrypt(message, aggValidatorKey, tag)

A decryption key is derived from a tag as:

key = aggregate([sign(tag, key) for key in validatorKeys])

and this is produced by the validators and stored back in the actor state after the contract triggers the call to release the key.

---

See the repo README for additional details