Timelock Encryption and Delayed Transactions

HI all,

My team (Ideal Labs) has recently completed a w3f grant to build a consensus mechanism that uses identity based encryption and DLEQ proofs to leak IBE secret keys in block headers, on top of which we implemented a timelock encryption scheme. If you’re familiar with drand, our implementation is a little similar conceptually. You can read our (completed) grant proposal here, as well as find links to github and documentation here. As part of the grant, we created a timelock auction proof-of-concept, which you can check out here.

We’ve already submitted a followup grant proposal, however, I want to discuss our next steps and gather input from the community. Our goal is to develop a ‘delayed transactions’ framework using timelock encryption, where transactions can be locked until specific blocks, after which a scheduler (e.g. pallet_scheduler) can decrypt and add the transactions to the transaction pool. This can act as a basis for trustless MPC protocols (as smart contracts), where many participants secretly commit to some input to the protocol (a transaction), and where each input is revealed only when the protocol terminates (by reaching a specific future block).

Dynamic Committees and Proof of Stake Consensus

In our grant, we developed a proof of authority version of our consensus, where each authority is an IBE master key custodian. While this is simple and works, it’s not an optimal solution since there is no clear incentive for authorities to act honesty and it’s really easy for one of them to leak the master key. Instead, a better approach would be to use secret sharing techniques. In particular, we have been looking into using a dynamic-committee proactive secret sharing protocol to be able to 1) split the secret among members of the authority set and 2) share those secrets with a potentially non-overlapping authority set. This could ensure that the master IBE key in both our poa and pos style consensus mechanisms can’t be so easily leaked. With a few changes to our timelock encryption implementation, we can account for this with minimal changes. Specifically, we are looking at the schemes proposed both (here)[https://eprint.iacr.org/2022/971.pdf] and (here)[https://eprint.iacr.org/2019/017.pdf].

Delayed Transactions

There are several mechanisms in place in substrate/polkadot to delay transaction execution, for example with the scheduler pallet, prototypes on a delayed xcm queue, and the time-delay proxy, but each solution is vulnerable to front-running attacks, among other implications of ‘knowing the future’. We propose to secure this process with timelock encryption, ensuring that transactions remain encrypted until a scheduled future block. Apart from front-running protections, this also enables the development of trustless, “atomic” MPC protocols within smart contracts. That is, contracts which allow multiple parties to commit to a protocol without revealing their input, and for that protocol to complete with no further interaction from the participants. In addition, delayed transactions can add secure, decentralized escrow capabilities, for example by transferring a balance to a pure proxy and scheduling a timelocked transaction to add another address (recipient of the balance) and remove yourself (sender of the balance), while the transfer could still be stopped at any time prior to execution.


The general idea is that we will modify the scheduler pallet so that it can perform decryption of encrypted, scheduled transactions (transactions are created through the usage of our etf-sdk). When encrypting transactions for future blocks in the chain, we run into the issue of nonce generation and verification. Normally, transaction nonces are monotonically increasing sequences starting at 1 (or 0). Any origin that encrypts a transaction for a future block must specify a nonce in the transaction, say k for example. By committing to this nonce, the account must only use at most nonce k-1 before the future transaction is executed, otherwise the transactions with nonce k will be invalid (if k is already used). This is quite a major limitation for an account, as it essentially means the account needs to, at some point, not be able to execute anything.

A fairly simple way to solve this, without changing how nonces work, is by using a chain of three accounts, A → B → C where A proxies B proxies C. Likely, C would be a soft-derived account from A. The idea is that we first build a transaction for account C, TX_C. Then we wrap that in a proxy call through C’s proxy, B, producing TX_C’. Then A would encrypt the transaction and produce a ciphertext CT, which A then schedules through an extrinsic. The scheduler pallet takes it away from there, performing decryption as previously discussed.


You’d have each tx encrypted differently? I think your original proposal said roughly that. If so, you’ve some mechanism by which UX looks up the upcoming aura block producers?

Another option is to do whole blocks together, but then folks would worry more about the underlying model.

You’d have each tx encrypted differently? … If so, you’ve some mechanism by which UX looks up the upcoming aura block producers?

That’s indeed the plan. We’re envisioning a ‘delayed transactions’ explorer to ‘schedule’ + cancel delayed transactions. We’ve already built a basic version of this as part of our SDK, which lets us choose future slots, extract secrets from headers, and inspect block producers.

Another option is to do whole blocks together

Could you elaborate? I considered something along these lines, but probably not the same as what you’re thinking. Something along the lines of a ‘timelocked txpool’, basically a consensus-critical form of the idea using the scheduler pallet, where all transaction data is sealed for future slots and authorities are responsible for unsealing and verifying it when producing blocks, but it seemed that it would be better to be able to have standard transaction handling logic remain alongside the delayed transactions. That in addition to the computational overhead added to block producers would not be optimal.

You could say every tx in block x encrypts to 3 of the 6 keys revealed in blocks x+c to x+c+5 maybe? This gives fixed tx order, which simplifies things.

At some point, a DKG becomes preferable, but they’re annoying to deploy. If you guys can get up say a smart contract platform which people like, due to reduced MEV, then you can get more interest in the DKG stuff later.

I’m no fan of EVM but elastic scaling should create an opportunity for parachains that go much faster than the relay chain. An EVM chain could be quite attractive if it’s much faster than ETH, thanks to elastic scaling, and fights off much of the MEV.

I think it could be possible to use something like a Merkle clock to build a sort of “pending future txs”, to give a total order to all of the (encrypted) transactions, basically getting rid of nonces as a monotonic sequence and instead using a merged merkle clock to verify transaction order.