Closed willemolding closed 1 week ago
HI @willemolding, thank you for your proposal. This project is still under consideration by our review committee. We expect to have an update available shortly. Thank you for your patience and for your interest in our grants program!
Hi @willemolding, Thank you for your time with this proposal and for your patience with our review. Unfortunately, we will not be moving forward with a grant at this time. To contact our team with inquiries regarding our review or grants program, please send an email to grants@fil.org.
Wishing you the best as you continue building!
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:
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:
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:
{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 DeloreanThis 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:
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:
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:
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
BeginBlock
,DeliverTx
, andEndBlock
with a single call toFinalizeBlock
ExtendVote
/VerifyVoteExtension
)Delorean System Actor Implementation
Actor and Runtime Integration
extendVote
andverifyVoteExtension
integrated with Delorean system actorMilestone 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
[ ] Rust and web SDK
Milestone 3 - Example Application
Modify existing ChainSafe NFT launchpad and marketplace to support secret NFTs using Delorean
Total Budget Requested
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
Team Member LinkedIn Profiles
Team Website
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:
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
Additional Information
Please send any follow-ups or questions to willem@chainsafe.io