Academic Grants Round 2024 Wishlist

# Academic Grants Round 2024 Wishlist [TOC] ### Econ & Game Theory * **General comments** * Relevant fields include mechanism design, algorithmic game theory, econometrics, market microstructure, consensus mechanisms, learning, finance. * We strongly encourage applicants to survey current discussions such as the latest [Columbia Cryptoeconomics workshop](http://columbiacryptoeconomics.org/) (see [videos](https://www.youtube.com/playlist?list=PLpktWkixc1gX-L5NT-vuDP54kW--3gDnK)).  * **Staking Economics** * *Modeling of stake supply* (including over time and for different classes of stakers). This can involve empirical studies such as the [tracking](https://dune.com/hildobby/eth2-staking) of staking service providers (SSPs) by @hildobby. We are also interested in studies and attempts to quantify cost structures of SSPs as well as solo stakers. * *Special priority to consensus researchers* with an understanding of economics. For example to quantify the impact of the staking deposit size on security, relevant in [research around revised issuance policies](https://ethresear.ch/t/properties-of-issuance-level-consensus-incentives-and-variability-across-potential-reward-curves/18448). * General focus on security and robustness to attacks * [STAKESURE: Proof of Stake Mechanisms with Strong Cryptoeconomic Safety](https://arxiv.org/abs/2401.05797), Deb et al., 2024  * **Beyond single leader mechanisms** * Inclusion lists are a suggested mechanism to improve Ethereum censorship-resistance (see [No free lunch – a new inclusion list design](https://ethresear.ch/t/no-free-lunch-a-new-inclusion-list-design/16389), [EIP-7547: Inclusion lists](https://eips.ethereum.org/EIPS/eip-7547)). Can they be hardened with committee-based solutions such as [Multiplicity](https://blog.duality.xyz/introducing-multiplicity/) / "mempool consensus" gadgets? See [ROP-9](https://efdn.notion.site/ROP-9-Multiplicity-gadgets-for-censorship-resistance-7def9d354f8a4ed5a0722f4eb04ca73b?pvs=4) for more details. * Commitment attacks consist in some party deploying a smart contract committing them to a (conditional) course of action. Accordingly, they are able to extort or bribe other parties and induce different outcomes from those intended by the mechanism designers (see e.g., [Fun and games with inclusion lists](https://ethresear.ch/t/fun-and-games-with-inclusion-lists/16557) or [ROP-6](https://efdn.notion.site/ROP-6-FRP-41-Stackelberg-attacks-and-Miner-Extractable-Value-MEV-73f290f95b06447cb96a099a094323a9?pvs=4)). Are single-leader mechanisms more brittle in the face of such attacks? How can mechanisms be hardened to offer as little surface for "game mining" as possible? (see [Game Mining: How to Make Money from those about to Play a Game](https://arxiv.org/abs/2401.02353), Bono, Wolpert, 2024) * **Auction theory** * Understand strategic behaviour from builders, relays and proposers to design more robust block/slot auctions. This topic can be investigated using [empirical](https://ethresear.ch/t/empirical-analysis-of-builders-behavioral-profiles-bbps/16327) (data-driven), theoretical (game theoretic) and [simulation-based](https://arxiv.org/abs/2312.14510) analyses. Some design goals: Study games that can be played in the current MEV-boost design, prevent or limit vertical integration across searchers/builders/relays/proposers, favor naive dominant strategies. * **Preconfirmation and financial engineering** * [Confirmation rules](https://dba.xyz/do-rollups-inherit-security/) offer various degrees of certainty regarding the finality of some transaction, e.g., "this transaction will be included against state xyz unless this party loses at least X dollars". For instance, rollups offer "fast preconfirmations" as soon as a sequencer acknowledges receipt of a user transaction. These preconfirmations are valuable from a UX perspective, but may also be considered as a way to lock in some outcome early. It makes sense to then consider preconfirmations as financial assets whose value is derived from their properties. * [Analyzing BFT & Proposer-Promised Preconfirmations](https://hackmd.io/@EspressoSystems/bft-and-proposer-promised-preconfirmations) * [Value-Capturing Based Rollups with Based Preconfirmations](https://collective.flashbots.net/t/value-capturing-based-rollups-with-based-preconfirmations/2884) * **Restaking** * Restaking consists in encumbering a fixed set of assets with more obligations, e.g., adding slashing conditions allowing for the loss of part or whole of these assets in case some service is provided incorrectly. We are looking for further economic analysis of this phenomenon to understand principal-agent problems, use cases, systemic risks and associated mechanisms. * [EigenLayer whitepaper](https://docs.eigenlayer.xyz/assets/files/EigenLayer_WhitePaper-88c47923ca0319870c611decd6e562ad.pdf) * [Semantics of staking: Re-staking](https://mirror.xyz/barnabe.eth/96MD_A194uXLLjcOWePW3O2N3P-JG-SHtNxU0b40o50) * **Blockchain + AI** * In a recent paper, we investigate the links between decentralized coordination and the possibility of cooperative AI ([Cooperative AI via Decentralized Commitment Devices](https://arxiv.org/abs/2311.07815), Sun et al., 2023, appeared in NeurIPS [MASEC workshop](https://openreview.net/group?id=NeurIPS.cc/2023/Workshop/MASEC#tab-accept-oral)). See also [crediblecommitments.wtf](http://crediblecommitments.wtf/). * To what extent can Ethereum provide AI with autonomy as an economic agent? What is the expected impact of such autonomy? * Contributions from applied fields high priority (e.g., machine learning) but other fields (e.g., economics) also of interest. * Can autonomous agents be used to automate tasks across the Ethereum supply network (e.g., build valuable blocks)? ### Theoretical and Applied Cryptography - Post-quantum aggregate signatures - Ethereum Proof-of-Stake relies heavily on BLS signature aggregation to support a large number of economic participants (validators) in the consensus. We're interested in efficient and practical methods that are secure under the existence of a quantum adversary. - Concretely efficient homomorphic time-lock puzzles without trusted setup - Groebner basis computation - Bounds and performance estimates for the systems arising from algebraic hash functions. - Witness Encryption Theorems - A number of new papers proposing novel witness encryption mechanisms rely on newly introduced theorems that would be valuable to make progress on proving. For instance, the evasive LWE assumption was introduced by https://eprint.iacr.org/2022/1140 but there is no known proof. - More flexible multi-signatures - Constructions of multi-signatures that can be repeatedly aggregated, even if the sets are intersecting, *without having to track the multiplicity of each participant* i.e. one can aggregate an aggregate signature for public key A, B and one for B, C into one for public keys A, B, C, only knowing that A, B, C are included, rather than having to know that B is included twice. - ZK-EVMs -- optimizations, formalizations, etc - ZK beacon chain existing components or proposals for modifications to make more ZK friendly - Random beacon design and analysis in the context of Proof-of-Stake systems. - The Ethereum Beacon Chain utilizes a [modified RANDAO construction](https://eth2book.info/altair/part2/building_blocks/randomness/#randomness) as the source of pseudo-randomness in assigning validator roles (e.g. proposals, attestation committees, etc). This method has known limitations and biasability under certain adversarial thresholds -- see [1](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability), [2](https://ethresear.ch/t/selfish-mixing-and-randao-manipulation/16081), [3](https://github.com/runtimeverification/rdao-smc). - We're interested in constructions that reduce or eliminate biasability under different adversarial assumptions while remaining available even when a large fraction of the validators are offline. - Work on improving the prover time of the Proof-Carrying Data paradigm in a setting with multiple untrusted provers. For more context, please see work with folding/Nova in https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386. ### Consensus/Protocol * **Theory** * Further investigation of [Rational Byzantine Consensus](https://notes.ethereum.org/@luca-zanolini/B1dF-eWcp) * **Censorship resistance** * In the era of account abstraction, proposer-builder separation and inclusion lists when transaction validity depends on mutable state. * **Light client protocol** * Improvements or security analysis of the current [beacon chain light client protocol](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair/light-client) * Practical light client proposals for the beacon chain that leverage the entire security of the valdiator set rather than the current committee-based approach. This might include proposed changes to the beacon chain to support efficiency/simplicity. * **Confirmation rules** * Analysis of the [exisitng confirmation rule](https://github.com/ethereum/consensus-specs/pull/3339) or improvements the algorithm. ### Networking & P2P * Adversarially robust DHTs * Improvements in P2P gossip efficiency and security * Formal improvements under various attacks/adversarial models (e.g. like found in [gossipsubv1.1](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md)) * Efficiency gains that reduce data amplification factor while still disseminating data quickly to the mesh (e.g. [epidemic broadcast trees](https://www.dpss.inesc-id.pt/~ler/docencia/rcs1617/papers/srds07.pdf) / [episub spec](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/episub.md)) * Novel methods in disseminating data into a DHT * Often the bottleneck in DHT retrieval constructions for consensus data (e.g. blocks, DA samples, etc) is not the steady state of querying the DHT but instead the potentially high load in populating the DHT which by default simply uses topic based gossip schemes. * Topic based gossip schemes are quite wasteful because topics generally span more data than a particular node will custody in the DHT. This is to ensure that gossip meshes have high enough density of nodes to function properly/securely. They are also wasteful due to the amplification factor generally found in gossip as a function of the network degree. * Analysis, formalization, improvements, simluations, etc of [PeerDAS/Danksharding](https://ethresear.ch/t/from-4844-to-danksharding-a-path-to-scaling-ethereum-da/18046) -- Ethereum's current path to scale data availability. * General work in design and analysis of [data-availability-sampling](https://notes.ethereum.org/GXEonbG3SQayOfsZ91GJ6Q?view) * [Improved p2p signature aggregation techniques](https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386) * Privacy * Nodes leak a lot of information. What techniques can be used at the p2p layer to add more privacy guarantees? * What non-protocol techniques can be utilized -- VPNs, TOR, sentry nodes, etc -- at what cost, efficacy, etc * Advanced sync techniques: * Advanced node sync techniques, state size compression, etc. ### Client Engineering - More efficient EVM interpreters, EVM JIT compilation, compilers, etc - EVM parallelization - Database optimizations - Ethereum has relatively unique data access patterns, would be interesting to investigate performance characteristics across different kinds of databases (LSM, B tree, etc). Supporting reorgs efficiently is where Ethereum access patterns begin to diverge a bit from traditional access patterns ### Security * Security research on devp2p and/or libp2p with proposals for improvements * P2P stress testing * Novel fuzzing: Network layers, EVM, Clients * Network privacy; techniques to improve privacy on the p2p layer * Analysis on dependencies used widely across the Ethereum ecosystem * Tooling to analyze p2p network health, including tooling such as early detection systems for attacks on the p2p network (e.g. through anomaly detection) * Analysis of effectiveness and/or coverage of Ethereum L1's current cross-client testing techniques and infrastructure -- e.g. [consensus-spec tests](https://github.com/ethereum/consensus-spec-tests/), [execution-spec tests](https://github.com/ethereum/execution-spec-tests), [hive](https://github.com/ethereum/hive), etc ### Formal Verification #### Context Formal verification allows for automated, machine-based verification of the correctness of software programs. A major interest is in verifying the correctness of Ethereum specifications, clients, compilers, and other critical tools. Additionally, we are interested in novel tools and techniques to ensure correctness of application-layer smart contracts. #### Research Areas ##### Formalizations We are interested in machine checkable and executable formalizations of core parts of the ethereum protocol and its surrounding ecosystem. This includes but is not limited to: - The EVM - The consensus layer - ZK constraint systems (e.g. PIL) We prefer to see these implemented in a mainstream theorem prover (i.e. Coq / Issabelle / Lean4). Concrete examples include: - Formal verification of the [Executable Execution Layer specs](https://github.com/ethereum/execution-specs#consensus-specification-work-in-progress) (EELS) - Improvements & extensions of existing formal verification projects: - E.g., verifying the fork choice component - (Semi)Automatic and/or novel formal verification of the Ethereum specifications - Anything that helps verify the correctness of the Python "specs" and/or full client implementations of the protocol. - Novel techniques for analysing and verifying applications in the execution layer. ##### SMT Performance We are interested in contributions that can significantly advance the state of the art in smt solver performance in the following theories: - Uninterpreted functions - Arrays - Bitvectors (in particular for large sizes) We are particulary interested in contributions that can easily be practically applied (i.e. are implemented and available for use in a solver that supports all of the above three theories). ##### Game Theory We are interested in contributions that enable or perform verification of game theoretic properties relevant to Ethereum and its surrounding ecosystem. This includes but is not limited to the following areas: - Application level (i.e. EVM programs) - Block building / MEV - Consensus layer We are also interested in contributions that generally advance the state of the art for formal verification of game theoretic properties. #### Past Ethereum Specification FV | Ethereum Component | Formal Verification Work | Verified By | | ------------------ | -------------------------------------------------------------------------------------------- | -------------------- | | Deposit Contract | [Deposit Contract](https://github.com/runtimeverification/deposit-contract-verification) | Runtime Verification | | Beacon Chain | [Coq Model & Verification](https://github.com/runtimeverification/beacon-chain-verification) | Runtime Verification | | Beacon Chain | [K Model & Verification](https://github.com/runtimeverification/beacon-chain-verification) | Runtime Verification | | Beacon Chain | [K Specification](https://github.com/runtimeverification/beacon-chain-spec) | Runtime Verification | | Beacon Chain | [Dafny Spec & Verification](https://github.com/ConsenSys/eth2.0-dafny) | ConsenSys Dafny Team | | Engineering optimizations | [FV optimized epoch processing](https://ethresear.ch/t/formally-verified-optimised-epoch-processing/17359) | Sigma Prime ### Humanities * Work that explores how blockchain tooling can help equitably owned and governed organizations, like co-ops, level the playing field with corporate competitors? * For instance, how an equitably owned and governed organization could use those tools to improve governance, member engagement, compensation, transparency, accountability, financing, and cost-reduction. * Potentially relevant [research](https://www.belfercenter.org/publication/toward-equitable-ownership-and-governance-digital-public-sphere). * Work that explores how blockchain tooling can help mitigate key risks presented by proliferation of artificial intelligence, including but not limited to mitigating AI’s risk to digital identity? * Potentially relevant [research](https://stanford-jblp.pubpub.org/pub/ai-democracy-digital-identity/release/1). * Work that explores how blockchain tooling can improve outcomes for antitrust and consumer protection regulators? * Potentially relevant [research](https://www.elgaronline.com/monobook-oa/9781800885523.xml). * Work that explores how principles of international law might be relevant to blockchain networks. International law includes norms of behaviour and principles that states have used to manage relationships with shared resources (e.g. natural resources and environments that cross international borders) or territory outside of their control (e.g. international waters). *Could credibly neutral blockchains like Ethereum be said to share similar properties, such that principles of international law could be used to inform how states should relate to blockchains?* * The crypto ecosystem might be comparable to a small, developing economy which is surrounded by much larger economies. There is a rich body of work in the context of development economics that may contain lessons that are applicable by analogy to Ethereum and other “blockchain economies”. *What can Ethereum learn from this history?* * Work that explores how the history of unionization and labour movements may contain useful analogs to the use of blockchains to better distribute control & profit over internet services and platforms. * The blockchain ecosystem is generally focused on western historical contexts. *What can we learn from historical parallels from outside the western tradition?* We'd like work that explores what the blockchain ecosystem can learn from succesful political and technological movements in regions outside of North America and Europe. * Open source software and the communities that form around it are a relatively recent phenomenon. Yet understanding their dynamics may be necessary to build a long-term foundation for credibly neutral blockchains like Ethereum. *We'd like work that explores the history of open source to draw lessons that blockchains must take into account to avoid common failure modes.* * Crucial to blockchain adoption is whether an individual user can, using the resources available to them, come to an informed opinion about the reliability of that blockchain. *We'd like empirical research on how users form expectations about a blockchain or blockchain application.*