Tech Session 16.04.2024Frederik Lührs, Konrad Feldmeier 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

This issue is a result of a brainstorm between me and @konradkonrad, further refined with Jakub. The issue describes a concept how Shutter could be integrated into the current transaction supply chain on Ethereum. In contrast to shutterized beacon chain, the issue describes an off-chain integration. The concept is derived from the current Gnosis Chain integration specs and adjusted to L1’s transaction supply chain. After describing the architecture, economics, limitations and chances are discussed. I think the technical details are not that new, so a lot of things will be known. This is merely an attempt how to integrate into L1’s transaction supply chain and to make it viable for the actors (validators, relay, block builders) to include shutterized transactions. Architecture Note, that we are not discussing changes to modify the STF of Ethereum’s protocol and thus forcing the validator to include shutterized transactions. Once realizing that it is not mandatory to include shutterized transactions into a block, and given the fact that ETH L1’s transaction supply chain is an efficient free market, the introduction of a financial incentive to include shutterized transactions into a Block is necessary.

I will give my view on a broader vision for shutter. Maybe it will be a bit chaotic but feel free to pick phrases, paragraphs which fit into the document. Let's try to start with a far broad vision and then detail down on different dimensions. I see Shutter becoming the solution to achieving information symmetry. Why do we want information symmetry? Information assymetry is a "byproduct" of the native open database what the blockchain really is and what it needs to fulfill other basic criteria (decentralization, thus openness, etc). The problem to date is, that there is no other choice thus information assymetry formed around the fact that information are accessible and smart powerful players can take these information for their benefit, creating an unfair environment. Even in the web2 case, the powerful player is ultiamtely the host of the application but the same concept applies (e.g. Snapshot). We can see that in a more general sense, unfair advantages to these players lead to centralization which is a fundamental risk to blockchains itself. Shutter as the enabler for information symmetry I see that Shutter's vision is having an environment which allows information symmetry thus a more fair environment to interact in the open web. I think it is important to have such an environment available so people have the choice whether to use it or not. Today there is not really an option. Today we are exposed to this environment of information assymetry.

In this paper, AMBs are classified and analyzed on a more architectural basis. Projects implement specific architectures and depending on the implementation evaluations of key metrics can vary vastly. However, we will see that fundamental types of AMBs show strengths and weaknesses in different metrics which can not be turned upside down by a specific implementation. Design space of the analysis Nowadays there exist lots of different types of bridges like token bridges, liquidity layers, optimistic bridges secured by underlying bridges or request-action bridges. The suggestion of analysis solely focusses on "bottom layer" type bridges namely arbitrary message passing bridges (AMBs). As described later, AMBs in the purest form are used to prove the state (or certain parts of the state) of other chains. When there are two isolated chains, it can be easily seen that external actors are needed to provide data of different chains. All other types of bridges mentioned above can actually be build on top of AMBs. Key metrics

Scope The goal would be to refactor the agent from outer parts towards internal structures. First goal should be to reduce the number of RPC calls during event fetching. Architecture Current Architecture digraph hierarchy { nodesep=1.0 // increases the separation between nodes A

Background The withdraw function behaves differently whether the claimer or the challengers won. Since there is only one claimer, if the claimer is the winner, withdraw can be called and the contract can resolve the claim and send all the stakes to the claimer. In fact, anybody can call withdraw and the claim will be resolved correctly. For the case of the challengers, however, there can be multiple and the stakes for each winning challenger needs to be computed per challenger. This results in the fact, that the withdraw is split per challenger (basically each challenger will call withdraw to withdraw its stakes). (Side note: if we wanted to allow withdrawing for all challengers in one transaction, we would need to limit the total number of possible challengers, which again would open up a more severe attack vector, the very one why we allow multiple challengers). Active Claims In the contracts there exists one specific property in the requests struct, called activeClaims. It counts the number of claims opened. Once a claim is finalized (either L1 or expiration), the claim effectively becomes inactive (semantically). However, a contract needs to be triggered to do something. We decrement activeClaims whenever the withdraw function is called for the first time on a claim. Attack