Tech Session 16.04.2024
Frederik Lührs, Konrad Feldmeier

# Lambda Keypers: universal decryption trigger

## Problem

With a growing ecosystem of shutterized applications, keypers will become the bottleneck for the system.

Currently keypers run application specific condition checks, to decide whether to release a decryption keyshare or not.

Depending on the application this can also lead to

* an increased **risk** of censorship or collusion: if keypers *know* what kind of application they work for, the political/economic landscape can change to the point, where subsets of keypers may chose to no longer work for a certain application/user group
* increase in software **complexity** thus potential centralization effects for operators of keypers
* **fragmentation** of keyper sets: different applications may deploy different keyper sets, because they apply different requirements/assumptions (eon length, threshold, economic security)

## Goals

* Keyper should have no (or less) **knowledge** about the context of the encrypted message
* Keypers should not need to track multiple chains or multiple decryption conditions/triggers \-\> **scalability**
* decryption triggers should be application agnostic, to prevent **fragmentation** of keyper sets
* triggering decryption should be **flexible** as to how the trigger is initiated (user based, oracle based (time based)), and must be **secure** against adversarial triggering (computational integrity).

## Idea

The epoch used by the keypers to identify which decryption key is to be created, is so far a *fixed* input parameter, based on application specific rules. The decryption trigger (condition for keypers to start the decryption process for a certain epoch) is based on on-chain inputs: block numbers, contract data, ….

We propose to change that to the output of a zero knowledge circuit.

Applications can register a verifier with the keyper set for a fee (subscription).

Keypers track only the Ethereum main chain (headers) which can be used as input for verifiers.

Epoch: hash(verifier) \+ epoch ID

\-\> Single name space per epoch for verifier
\-\> You cannot forge a verifier for a different application

## Benefits

New decryption trigger mechanisms can be added to this system with 0 involvement of the keyper software provider.

Potentially larger keyper set possible and heterogenous sharding of application specific decryption verifiers

\-\> Generalized keyper software interconnected
\-\> Verifier can be registered to a subset of keypers (auctioned)
\-\> No application specific keypers
\-\> Lambda keyper