Open Grant Proposal: Delorean Protocol - An IPC Subnet for Programmable Encryption

[willemolding]

Open Grant Proposal: Delorean Protocol

Project Name: Delorean Protocol

Proposal Category: Research & protocols

Individual or Entity Name: ChainSafe Systems

Proposer: willemolding

Project Repo(s) https://github.com/ChainSafe/Delorean-Protocol

(Optional) Filecoin ecosystem affiliations:

The team that developed the Delorean prototype was awarded the Filecoin bounty in the EthGlobal HackFS Hackathon.

ChainSafe has previously received a number of grants from the Filecoin Foundation to develop Forest

(Optional) Technical Sponsor: Sarah Thiam - truckerfling

Do you agree to open source all work you do on behalf of this RFP under the MIT/Apache-2 dual-license?: Yes

Project Summary

Delorean is an IPC subnet for programmable timelock encryption that extends upon the work of DRAND and tlock. The tlock protocol is restricted to only being able to encrypt data to a pre-determined point in the future (as defined by a DRAND network block height). Once this height has been reached the decryption keys are automatically generated and published by the network. This limits the protocol to only very specific applications.

Delorean expands this to programmable conditions expressed in Solidity. Using Delorean you can write a smart contract which encodes the conditions under which the key should be generated, for example once the contract has received enough of a particular token, or once a DAO has voted a particular way. This is implemented using the vote extension functionality of CometBFT which allows the chain execution layer to specify additional data that validators must include along with their BFT votes. In this case the additional data is a signature over a chosen string which can be used to derive a decryption key via threshold Identity Based Encryption (IBE).

Because key generation is coupled to the chain execution Delorean can use the existing gas fee mechanism to charge users for key generation. Because key generation takes place as part of consensus voting it inherits the same guarantees as the chain liveness (e.g. keys will be generated provided at least 2/3 of validators are voting).

Being an IPC subnet Delorean is able to use FIL as a gas token and read L1 state.

Comparisons with Similar Protocols

Delorean differentiates itself from Lighthouse and LIT by being an open network and using a recently developed threshold encryption scheme that allows the encryptor to define the committee and threshold. This makes it more suitable for applications that demand much higher security (e.g. many hundreds of nodes may be required to generate a key).

It is more restrictive in the sense that both Lighthouse and LIT allow access control for specific accounts (e.g. they will generate a decryption key for a particular account on request if it satisfies some conditions). Delorean only supports public generation of keys once global conditions are satisfied.

Lighthouse

Lighthouse also offers encrypted Filecoin data storage with programmable access conditions. The two protocols differ by how the decryption keys are generated, the level of communication required between nodes/signers and users, how the conditions are enforced, and the economic guarantees.

In Lighthouse the threshold decryption keys are generated client side and hard-coded to be 3/5 threshold. The shares are distributed to 5 lighthouse nodes and stored along with the access conditions which are defined in a JSON format. These nodes agree to provide the key shares upon request if the access conditions are satisfied. The access conditions can be based upon state from a number of different blockchains.

In Delorean the contract itself defines how and when the decryption keys should be generated and no interaction between the nodes and user is required. At encryption time the user can chose which nodes should participate in the key generation and set the threshold but this is a fully local operation.

LIT Protocol

LIT offers programmable decryption keys as a feature but also differs from Delorean in some important properties.

LIT is a permissioned network make up of a fixed set of signers. Adding a new signer requires all signers to participate in a new distributed key generation (DKS) ceremony. Delorean however is an open network where anyone can join the subnet as a validator and participate as a signer/key-generator.

Impact

A Delorean IPC chain would provide a public, programmable, decryption key generation service. This is both coupled to Filecoin, via IPC and using FIL as a gas token, and allows for new Filecoin use-cases. This is particularly powerful when combined with ZKPs that can prove statements about the content of an encrypted payload without revealing it.

Some concrete examples of capabilities that Delorean unlocks for Filecoin include:

Secret NFT Collections

Current random NFT sales guarantee a buyer a random NFT from a known collection. Delorean enables a new case where the NFT data can remain completely hidden until it is purchased for the firsts time. No interaction from the collection author is required once they have published the encrypted data, Delorean handles the rest.

The flow for this application is as follows:

1. NFT collection author deploys an NFT sale contract to Delorean which will reveal keys upon each successful initial sale
2. Author creates art/data for each NFT in the collection, encrypts with respect to its unique decryption key, and publishes the encrypted NFT data to Filecoin
3. Buyer interacts with the sale contract on Delorean which both transfers them the NFT and triggers the release of the corresponding data decryption key. The data for this NFT becomes public and the buyer becomes the first owner

This creates a new dynamic between creators and buyers where the buyer is the both the first owner and the one who triggers the public reveal of the data. This could have applications in art/music as well as gaming.

Encrypted Data Release Upon Death (dead-person-switch)

Such a system would work as follows:

1. Encrypt your message and distribute the decryption key to a set of intended recipients
2. Deploy a Deloren contract which will generate another decryption key if a "heartbeat" transaction is not detected from your account for some time period (e.g. 6 months)
3. Re-encrypt the encrypted message with respect to this contract using Threshold IBE
4. Create a Filecoin deal to store the encrypted message to ensure it is available into the future

The result is that if you do not submit a heartbeat to the Delorean contract every 6 months (e.g. because you are dead) then your message can be decrypted by your chosen recipients.

On-chain Hidden Information Games

Games such as Poker that involve hidden information require special protocols to be played on a public blockchain.

Using Delorean players actions can be hidden until such time that the game determines (through on-chain rules) that they should be revealed. For a simple rock-paper-scissors example:

0. A Delorean contract is deployed which encodes the game rules and when moves can be decrypted
1. Alice forms and signs a move payload {gameId, turnNumber, move}, encrypts it, and submits it to the game contract along with a ZKP that it contains a valid signature, is a valid move for the game, and can be decrypted using Delorean
2. Bob does the same
3. The Delorean contract then triggers the conditions to produce the decryption key for both moves and the game can be resolved by anyone

This improves upon the usual way that rock-paper-scissors is implemented using a commit/reveal scheme. There is no longer a determined move ordering and both moves are revealed at the exact same time. This avoids the interactivity requirements and the information imbalance when the second player reveals. The same benefits extend to more complex games with multiple players.

Secret Data Marketplaces

Using Delorean it is possible to create new types of marketplaces for when secrets should be made public. A simple example would be a fund-raiser whereby some data becomes decryptable once some amount of funding is raised.

A more interesting example is an auction where two sides bid for data to either be kept secret or revealed. Delorean protocol can guarantee that if the 'keep secret' side wins then the secret will not be revealed (unless the network signers collude or the original encrypter reveals it).

These could have interesting applications in hidden information games such as Dark Forest where players secrets can be discovered by other players through exploration and revealing them might have significant ramifications in-game.

Outcomes

The primary outcome of this project is a testnet ready IPC subnet chain that extends the FVM to support the programmable signing functionality required for Delorean. This is comprised of:

• An upgrade of the CometBFT version to 0.38
• Modifications to the core runtime to support voteExtensions
• A custom Delorean actor that allows queueing up signing tasks and charges gas for the service

This will be deployed to Filecoin Calibration with validators run by ChainSafe and others as a public testnet.

---

Secondary is the tooling required to encrypt data off-chain with respect to the rules defined in a given contract instance. This tooling must be able to:

• Interact with Delorean network via RPC to
  • Read network state
  • Submit transactions
• Encrypt using the threshold encryption scheme defined in https://eprint.iacr.org/2024/263

It is proposed to implement this as a Rust crate with a CLI and Wasm interface to Javascript.

---

The final part of the delivery is a user-facing web application that provides a useful service backed by the network.

We propose modifying the existing ChainSafe NFT dashboard and marketplace to support secret NFT initial sales using Delorean. This will have the following features:

• Deployment of NFT sale contract to Delorean
• Browser side encryption of uploaded artifacts which are then stored on Delorean
• Author configurable selection of validators/decryption nodes

Adoption, Reach, and Growth Strategies

Full compatibility with the existing EVM ecosystem makes onboarding users to Delorean straightforward. They are able to interact using existing wallets and tooling such as MetaMask.

It is expected that early testnet users would interact via the demo application developed as part of the grant.

The primary target audience for the protocol is dApp developers wishing to include conditional decryption in their applications. Ease of development makes this an appealing.

ChainSafe is uniquely positioned as a provider of web3 gaming tooling and infrastructure to bring Delorean to the attention of developers who might be interested in using it and providing support where required.

Development Roadmap

Milestone 1 - Delorean Subnet

Description

Upon completion of this milestone there will exist a complete and documented repository that allows for running an instance of a Delorean subnet. This will be a fork of consensus-shipyard/IPC to be able to benefit from upstream development.

The changes introduced by this milestone are as follows:

Upgrade IPC to CometBFT 0.38 and ABCI 2.0

• [ ] Rewrite core app code in terms of the alternative interface used by ABCI 2.0
  • [ ] Replace the call sequence BeginBlock, DeliverTx, and EndBlock with a single call to FinalizeBlock
  • [ ] Stub new methods introduced in 0.38 (ExtendVote/VerifyVoteExtension)
• [ ] Submit PR upstream

Delorean System Actor Implementation

• [ ] FIFO data structure backed by actor blockstore for queued tasks
• [ ] External callable function to enqueue new signing task
  • [ ] Hashes payload with calling contract address
  • [ ] Custom configurable gas cost per signing task
• [ ] System callable function to store aggregated signatures in actor state
• [ ] Actor test suite
  • [ ] enqueuing/dequeueing signing tasks
  • [ ] ensure correct authority for external functions

Actor and Runtime Integration

• [ ] Implementations of extendVote and verifyVoteExtension integrated with Delorean system actor

Milestone 2 - Delorean Tooling

Implement the required tools to integrate with the Delorean actor from within contracts deployed to the network and from off-chain actors to allow encryption/decryption.

The Rust SDK is where the majority of the novel cryptography is implemented with the network itself just performing signing. The Rust SDK will wrap an existing implementation of Threshold IBE with silent setup (either https://github.com/guruvamsi-policharla/silent-threshold-encryption or https://github.com/webb-tools/silent-threshold-encryption-gadget a proper investigation still needs to be made).

It will use AGE in a similar way to tlock to allow encrypting arbitrary length files.

• [ ] Solidity SDK

  • [ ] Encoding structures for calls
  • [ ] Abstracts calling precompile to call actors

• [ ] Rust and web SDK

  • [ ] Helpers for querying network to retrieve encryption parameters and validator/signer data
  • [ ] Wrap silent threshold encryption crate configured for compatibility with Delorean network
  • [ ] Integration with AGE crate for encrypting arbitary length data
  • [ ] High level interface for encrypting arbitrary length data with respect to a deployed delorean contract
  • [ ] Javascript/Typescript support via WASM

Milestone 3 - Example Application

Modify existing ChainSafe NFT launchpad and marketplace to support secret NFTs using Delorean

• [ ] Solidity contract to manage NFT sale and key release on Delorean
• [ ] Launchpad deploys secret NFT sale contract instance for each collection
• [ ] Browser side encryption of assets and upload interface to Delorean network
  • [ ] User configurable selection of decryptor nodes
• [ ] Markplace updated to decrypt and display NFT data if key released or display placeholder if not

Total Budget Requested

Milestone #	Description	Deliverables	Completion Date	Funding
1	Implementation of the Delorean subnet as a fork of consensus-shipyard/IPC	Upgrades to IPC template, runtime modifications, custom delorean actor, actor runtime integration		$20,000 USD
2	Rust and Solidity SDKs	Solidity libs for on-chain integration, Rust crates for client side tasks		$20,000 USD
3	Example application	Secret NFT sale contract, ChainSafe launchpad and marketplace integration		$10,000 USD

Maintenance and Upgrade Plans

Our goal is for Delorean to develop into a ChainSafe product from which sustainable revenue can be made by providing consulting services and support for teams wanting to integrate it into their own applications.

Team

Team Members

• Willem Olding
• Eric Tu

Team Member LinkedIn Profiles

• https://www.linkedin.com/in/willem-olding/
• https://www.linkedin.com/in/eric-tu-61602850/

Team Website

• https://solutions.chainsafe.io/

Relevant Experience

ChainSafe R&D is a consulting team within ChainSafe with specialized skills in cryptography and systems design. Founded in 2020 we have successfully delivered projects for dozens of notable clients including:

• Ethereum Foundation
• Mina
• ZCash
• Protocol Labs
• Gnosis

ChainSafe R&D sets itself apart by bridging the gaps between research, design and implementation. All of our team members are accomplished developers in addition to being practitioners in applied cryptography and protocol design.

---

Willem has 6 years professional Rust experience and has worked on the Rust implementations of Holochain and Mina protocols. Willem joined ChainSafe in 2020 to found the R&D team and since then has shipped ma

---

Eric has 5+ years professional Rust experience and has worked on the Rust implementation of Filecoin (Forest) since its inception in 2019.

---

Willem and Eric developed Delorean for the 2024 HackFS Hackathon. The project was select as a finalist and 3rd place recipient of the Filecoin bounty.

Team code repositories

• https://github.com/ChainSafe/Delorean-Protocol

Additional Information

Please send any follow-ups or questions to [email protected]