# Academic Grants Round 2023 Wishlist

We're compiling a wishlist for the next AGR. Please add any areas of research you would like to open for Academic Research with your name next the topic.

### Theoretical Cryptography
- Lattice-based SNARKs
- Lattice-based aggregate signatures

### Applied Cryptography
- Privacy solutions
- ZK-EVMs
- ZK [beacon chain](https://notes.ethereum.org/3t5cbN7cQnG6VxjgNMKymA) state transition or important components (e.g. signatures, casper FFG, etc)

### Econ & Game Theory
- [RIG Open Problems](https://efdn.notion.site/ROPs-RIG-Open-Problems-c11382c213f949a4b89927ef4e962adf) and related projects
- [Open questions](https://barnabe.substack.com/p/pbs) in Proposer-Builder Separation and market structure of block production
- MEV
- Techniques to [smooth](https://ethresear.ch/t/committee-driven-mev-smoothing/10408) or [burn](https://ethresear.ch/t/burning-mev-through-block-proposer-auctions/14029) MEV to reduce variance in validator rewards
- MEV market designs to allow open access and reduce centralization pressures
- (@ralexstokes) theoretical foundations of MEV (in single and cross domain)
- e.g.https://arxiv.org/abs/2112.01472
- can we write (or improve) a specific formalization of MEV as seen in empirical contexts?
- can this model inform redistribution efforts? (cf. http://people.eecs.berkeley.edu/~ksk/files/MEV_Redistribution.pdf)

### Consensus/Protocol

#### Research areas

[Gasper](https://notes.ethereum.org/@luca-zanolini/SyZAX6V8o) is the current implemented proof-of-stake consensus protocol of Ethereum; it is obtained by combining the finality gadget Casper on top and the fork-choice LMD-GHOST as a basis. The [Ethereum consensus specifications](https://github.com/ethereum/consensus-specs) reflect the current state-of-the-art of Gasper, as a consequence of the developments that happened during the years. Because of that, one of the research areas in which the Consensus R&D team is involved is on the improvement of both the protocol *and* the consensus specifications. In particular,

* Improvement of some functionality without changing the fundamental design;
* Identification of bugs and proposing fixes;
* Performance improvements;
* Identification of attacks to the protocol and their solutions.

This can also be extended by analyzing lesser-reviewed components, such as [weak-subjectivity](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) or security of committee sampling.

Today, Ethereum blocks take 64-95 slots (~15 minutes) to finalize. A long-term goal is to be able to finalize within one slot, in order to prevent [some attack vectors](https://arxiv.org/abs/2110.10086) caused by the current way in which the protocol reaches finalization. This is generally called

* [Single-slot finality](https://notes.ethereum.org/@vbuterin/single_slot_finality).

More generally, we aim at a fundamental redesign of the consensus protocol with a focus on simplicity. On this line, we are also interested in deeply analyzing *dynamically available* consensus protocols: protocols that allow system participation to flow, while preserving safety and liveness. Some recent research results include [Momose-Ren](https://eprint.iacr.org/2022/404.pdf), [Malkhi-Momose-Ren](https://eprint.iacr.org/2022/1448.pdf), and [Neu-Tas-Tse](https://arxiv.org/abs/2009.04987). Outputs from this line of work would have an inpact on the Ethereum consensus protocol.

Finally, we are focusing our attention on the [Proposer/Builder separation](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) paradigm, where the block construction role is separated from the block proposal role, in order to prevent validator centralization risks that come from MEV. This is a new research direction and, because of that, we aim at the following goals:

* Precise identification of the problem;
* Properties we want to achieve;
* Analysis of possible scenarios in a post-PBS world.

#### Censorship resistance

* Censorship resistance in the era of account abstraction: Proposer-builder separation and inclusion lists when transaction validity depends on mutable state.

### Society & Impact

- 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 and political 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 political, historical, and technological movements in countries outside of north american 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.*

### Networking & P2P
- Performance and security improvements:
- Better signature aggregation techniques -- [original context](https://ethresear.ch/t/pragmatic-signature-aggregation-with-bls/2105), [current specification](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/validator.md#attestation-aggregation), [recent research](https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219)
- Message gossip -- [gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
- Peer discovery, etc. -- [discovery v5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md)
- Advanced sync techniques:
- Advanced node sync techniques, state size compression, etc.
- Monitoring & analysis:
- Tools & techniques for analysis of p2p network health, early detection of attacks, identification of p2p bugs, overall data analysis, etc.
- Application of tools/techniques to Ethereum mainnet. What previously unknown conclusions can be drawn?
- Client diversity break down - Michael Sproul has done a lot of work here, might be good to formalize further. Would also be extremely valuable to investigate how to determine EL break down of validators. Idea: very likely that clients have different block building heuristics that could be exploited.
- Privacy
- Nodes leak a lot of information. What techniques can be used at the p2p layer to add more privacy guarantees? -- [some recent work in the domain](https://ethresear.ch/t/a-tor-based-validator-anonymity-approach-incl-comparison-to-dandelion/14134)
- What non-protocol techniques can be utilized -- VPNs, TOR, sentry nodes, etc -- at what cost, efficacy, etc

### Client Engineering
- 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
- More efficient EVM interpreters, EVM JIT compilation, compilers, etc
- EVM parallelization

### Application Layer
-

### Layer 2
- **Rollup economics:** incentives for decentralised sequencers, risk management for bridges/rollup operators, congestion/resource pricing, decentralised markets for fraud proofs/validity proofs. *Sample works in this direction:*
- [Understanding rollup economics from first principles](https://barnabe.substack.com/p/understanding-rollup-economics-from?utm_source=url)
- [Efficient L2 Batch Posting Strategy on L1](https://arxiv.org/abs/2212.10337), Mamageishvili, Felten, 2022
- [SoK: Validating Bridges as a Scaling Solution for Blockchains](https://stonecoldpat.github.io/images/validatingbridges.pdf), McCorry et al., 2021
- [MEV Auction: Auctioning transaction ordering rights as a solution to Miner Extractable Value](https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788)
- [Spam resistant block creator selection via burn auction](https://ethresear.ch/t/spam-resistant-block-creator-selection-via-burn-auction/5851)
- [Against PoS for rollup leader election](https://ethresear.ch/t/against-proof-of-stake-for-zk-op-rollup-leader-election/7698)

### Security
- Researching and implementing new fuzzing targets, e.g. p2p layer
- Is GPU based fuzzing of the EVM/p2p feasible and more efficient compared to CPU fuzzing?
- Machine Learning on a network level to find anomalies and enable early warning systems for issues that start occurring
- What does validator diversity look like if not taking clients into account? For example ISPs, Countries, OS, HW, etc.
- What are the security risks with these factors, if for example 70% of validators are running Ubuntu.
- Additional Security proposals can be found under "Networking & P2P"

### 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 executable specifications and identification of bugs.

Additionally, we are interested in novel tools and techniques to ensure correctness of application-layer smart contracts.

#### Research Areas
- Formal verification of the new [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
- 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.

#### 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 |