A reminder of progress and problems unsolved.

We’ve come a long way since the first time I wrote this list in Jan 2022. It has been inspiring to see the space proliferate and build extremely interesting infrastructure for the future of crypto, but we have a long way to go.

I believe that having an open list of problems is a good reminder of progress for a field, nascent or old, research problems or practical applications. These also provide a benchmark to look towards and glance upon while taking stock of the progress the field has made over the years.

While I wrote about open problems just in Defi last time, this time, I attempted to be a little ambitious and cover open problems in crypto. These aren’t just research problems; some will ultimately be protocol-level solutions, and some will even be applications.

Table of Contents

1. Decentralized Finance

2. Mechanism Design

3. MEV

4. Zero Knowledge

5. Other problems in Crypto

Decentralized Finance [Defi]

• Automated risk scoring of lending borrowing pools

  • Possible Solution: Risk assessment without historical data is really hard because it could be so that a pool of users with a good credit history will always pay the loan back. “Credit score” in tradfi.

  • How can we accurately model the risk of default for a pool of borrowers without relying on traditional credit data? → Answering this might lead to a framework for lending pool risk scores.

• A dynamic Lending market parameter model

  • Bad Loans have been increasing. Gauntlet/risk monitoring teams are doing well, but DAOs are moving slowly (Curve example).

  • How do you solve for low liquidity coins? The model could be a function of liquidity and adjust rates dynamically for a given pool.

  • Though there are downfalls to this model, in “Attacks on Dynamic Defi Interest rate curves,” Chitra et al. show that dynamic lending models have more MEV.

• Managing Risk for lenders and distributing risk/ Undercollateralized Loans

  • While active monitoring is excellent. How do we distribute this risk and make it efficient?

  • Is there a world where we could have undercollateralized loans on-chain?

    • Are off-chain contracts the only way? (Wildcat protocol)

• Private Lending

  • Lending protocol transparency of pools has led to the hunting of liquidation levels, which have become Schelling points for traders.

  • How do you design a privacy mechanism that reveals minimal information?

• Designing Cross-chain Defi

  • As lending markets become chain-centric, liquidity across assets is becoming fractionalized.

  • As liquidity generally gets more fractionalized, how do you source liquidity seamlessly at size and settle it?

  • Look at Cross-chain Margining Systems from The Defi Prime Broker for the DEX version.

  • Defining the safety of these protocols in terms of balance between synthetic assets (cross-chain) and Native assets (on-chain)

• What does the future of Spot Dexes look like?

  • Can CLOBs be designed to accommodate tail assets?

    • Is there a unification of AMM/CLOBs beyond CLAMMs possible?

    • CLOBs historically haven’t worked for tail assets (Etherdelta was bad)

• LP Profitability Problem: What is the optimal strategy for passive and active liquidity providers?

  • How can you formulate and model the problem? → Possibility that it doesn’t exist

    • Does Uniswap-X RFQ mean this is not possible onchain? Onchain LPs in uniswap X have become LPs of last resort and get toxic flow possibly.

    • How do you protect LPs better?

• How does DEX design solve for LVR (Loss-Versus-rebalancing)

  • Dynamic fees - How do we best set fees dynamically based on volatility and other signals to optimize returns?

  • Orderflow Discrimination - If you know how to discriminate between uninformed and toxic flow, you could possibly charge them different fees, etc

Open Research Problems - Mechanism Design

• Restaking Equilibria

  • Competitive Equilibria Between staking and on-chain lending discusses how lending and staking equilibria can exist.

  • What does this look like in a restaking world where the return from staking isn’t exactly uniform but definitively higher than simple staking?

  • What does restaking mean for the security of the base layer? Is restaking an anemic phenomenon to the security of a base layer?

• The privacy-information tradeoff for DEXs (privacy-efficiency frontier) - No Free Lunch theorem

  • In Differential privacy in CFMMs, authors show that partial privacy in CFMMs is possible and that there is a tradeoff between price (execution) and privacy. Private Dex Architectures have been rising recently. How do they address this?

• The privacy-information tradeoff for MEV (privacy-efficiency frontier) - No Free Lunch theorem

  • The privacy-efficiency tradeoff in sharing MEV information. Privacy is needed to decentralize the MEV supply chain, but more privacy usually means less efficiency.

• Mechanism Design (Private & Verifiable)

  • Adding ZK to existing mechanisms like CFMMs and auctions does not automatically guarantee strong privacy.

  • Verifiable and auditable mechanisms for applications like auctions, order flow, and matching markets

  • Adopting Mechanisms for a ZK World

• Designing multi-resource Fee markets

  • Resources: Dynamic Pricing for Non-fungible Resources and Transaction fee mechanism design

  • Blockchain resources are being focused on at different granularities (blob market introduced to handle ephemeral data). Does it still make sense to meter all resources at the same level?

  • Finding the right level of pricing granularity between opcodes and full applications to optimize productive efficiency and therefore, develop robust local fee market designs that can practically segment demand and allocate execution efficiently.

  • Multidimensional EIP 1559 Model from Vitalik

Open Problems in MEV

• Minimizing latency advantages in MEV/ Geographic Decentralization

  • Talks by Phil Daian and Robert Miller

  • Low latency provides advantages in optimizing and extracting MEV. This could incentivize geographic centralization if MEV parties co-locate to minimize latency.

  • The challenge is designing MEV systems that are not sensitive to latency and allow geographic distribution of nodes.

  • Ideas include allowing deferred transaction specification at block-building time rather than sending individual transactions.

  • Also, look at “Exploration of MEV Latencies”.

• Credible Private Auctions on-chain

  • In an everything-is-an-auction world, how do we hold auctioneers accountable and trustable?

    • Chitra et al. show a possible world. When will we get this onchain?

    • What are other guarantees that we need for auctions to be practical?

• Design of Order Flow Auctions

  • OFAs follow a common framework with four components: originators/orders, auction/info sharing, bidders/bids, and winning bid/inclusion.

  • Key design decisions exist around order types, information sharing, bidder permissions, bid selection, and execution guarantees.

  • More at “The Orderflow Auction Design Space”

• MEV Distribution Applications

  • MEV is not evil or has any nature associated with it, just an emergent property of an economic system (Can be thought of as inefficiencies being captured)

  • If MEV is captured by the applications and redistributed in the case of AMMs, in essence, LPs would get value or users in the case of sandwiching.

• MEV Mitigation

  • Recent work has shown private RPCs don’t prevent users from experiencing slippage (a popular belief among private RPC users). Are commitments necessary for MEV mitigation?

  • How do you design UX to improve this at the user end?

• A framework for Sequencing rules given payoff/Application?

  • Chitra et al.’s Theory of MEV II proves that MEV handling should be application-specific/ Sequencing criteria for payoffs (properties proven in the paper)

  • Better lower bounds for specific applications/payoffs when sequencing is defined (already shown for CFMMs, O(log n) when abundant liquidity)

• Generalizing PBS

  • How to generalize PBS (proposer-builder separation) to support more flexibility like partial blocks, different block specifications, inclusion lists, etc.

  • Also relevant in the L2 world

    • A key problem is whether to enshrine MEV auctions in the L2 protocol, burn MEV to incentivize proof production, or leave it to proposers and builders. More research is needed on the economics.

    • Other open problems include determining optimal mechanisms for proposer decentralization, managing high compute needs for L2 block production, prover incentivization, and enabling permissionless participation.

• Censorship Resistance Mechanisms

  • Today, five out of the six largest block builders comply with the OFAC sanctions.

  • How do you design mechanisms for avoiding this?

  • To learn more, listen to this talk here.

Some Problems to Upgrade Zero Knowledge

• Impossibility results for Zero-Knowledge Crossovers like ML and Defi

  • Are some applications that are not possible or bounded for some and prevent practical usage?

• Separability results for Zero-knowledge Crossovers

  • Are there any results that possibly allow you to say with ZK, you get better efficiency properties for payoffs, and without ZK, they don’t?

• The Imagenet of ZK - Towards a ZK benchmark

  • Imagenet competition ultimately brought about the revolution in AI in the form of deep neural networks. Alex Krizhevsky wrote custom kernels for training Alexnet, and thus GPUs started getting adopted for Deep learning.

  • Is there a ZK equivalent benchmark to make ZKs more performant?

    • Opening this up as a yearly benchmark incentivizes research groups to work on this.

  • The imagenet of ZK could possibly do the same for ZK (maybe need a yearly competition)

• Torch/Tensorflow for ZK circuits

  • Zero Knowledge feels like it’s in the Cuda era

  • Computational graph models for circuits are similar to how neural networks are written.

  • There is no standard framework for ZK applications

• A Fast.ai for Zero Knowledge

  • Some credit to Deep learning’s growth was the ability to top-down learn and this course design subsequently.

  • What do toy applications for learning ZK look like?

• Zero Knowledge Identity/ ZK-KYC

  • Real-world application with outsized impact

  • It does not have to be strictly KYC-centric

  • Issues around making it government-compliant

• ZK Deep Learning/ZKML

  • Verifiable computation inference?

    • Explored for some models in the Cost of Intelligence: Proving Machine Learning Inference with Zero Knowledge by Modulus Labs.

    • Does this need the existence of ZK provers for Models specifically?

  • Is Zero knowledge Deep learning possible?

  • Some other ZK applications possible - Data/Training Provenance

    • Tools for Verifying Neural Models Training Data Any such addition to a system would help determine compliance issues/or verify that the model was actually trained on the data.

    • Also explored in “Experimenting with Zero-Knowledge Proofs of Training.”

Other Problems in Crypto

• Towards a Definition of Intents

  • Intents have become popular over the last year.

    • A formal definition of intent is still missing and could lead to the design of protocols around them and research.

• Private intent solving

  • What minimum knowledge is needed for an intent/requirement to be filled?

• Compiler/Program Synthesis - User-defined compositions and flexibility → I give you a payoff, and you “compile” it by stringing together other primitives.

  • One way to think of a compiler is you are interested in a certain payoff from the assets you have, so you have a compiler that auto-selects and tries to model the desired payoff from the instruments/primitives available on-chain, “auto yield stacker.”

  • Intents but more abstract - over protocols

  • Lego blocks today are only building Lego blocks of composability for protocol builders.

  • As protocols become sophisticated and yields become siloed, what are ways to allow for user composability of protocols/portfolio building?

  • If the atomicity of protocol stacking is lost due to appchains, how do you solve this?

• A Universal Intent DSL to onchain transaction pipeline

  • As we grow towards better UX models, the idea of users signing transactions for taking money in the wallet to stake money/transact/trade is a high effort.

  • Design rules have morphed from early 2000s web2 3-click-rule to even more effortless UX designs today.

  • When you go to a bank, you tell your relationship manager that you want to stake your money in Fixed deposit/tell your broker to buy you stocks, etc. These things might not apply to sophisticated users. Most users would benefit from intent/”objective” based design.

  • Converting intent to meaningful onchain steps unlocks the next level of meaningful UX.

• Better Wallets

  • As we move to an infinite chain world with multiple chains for apps and multiple app chains for a better experience, how do wallets consolidate this experience while maintaining safety and security?

    • For example, you’d need to keep dust on all chains

  • Wallets need to configure RPCs which are best for users

  • Wallets can be intent solvers/broadly everything apps

• Social Recovery Wallets/Towards Better Wallet Security

  • The user experience of maintaining wallets sucks, and hardware wallets aren’t for everyone.

  • Designing Wallets with social recovery or even models that abstract the maintenance of private keys might pave the way to adoption.

• Coprocessor/Verifiable Off-chain computation architectures

  • Succinct zero-knowledge proofs allow reasoning about secret data owned by one party. Fully homomorphic encryption and MPC allow joint reasoning on secret data. A combination could allow joint reasoning without interaction.

  • The ideal model is a trusted execution environment (TEE) that can run arbitrary programs and keep secrets, but TEEs face challenges with communication and state.

  • What applications are ZK-coprocessors not possible for (Computation heavy possibly) → Designing FHE/MPC-based solutions with blockchains for these applications?

  • Security guarantees of TEEs vs. FHE vs. ZK and the applications that these unlock.

• Coprocessor/Verifiable Off-chain Computation Architectures - Some Applications

  • On-chain Security Monitoring

  • ML/RL controllers for stablecoins

  • Off-chain margining systems

• Gas derivatives

  • Derivatives could allow Ethereum stakeholders like validators, developers, and users to manage risk and volatility in gas prices better. They could pay fixed rates and hedge exposure to spot price fluctuations.

  • Historical analogies exist in markets like oil and VIX futures, where derivatives volumes far exceed the underlying spot market. This shows the potential for major growth in gas/blockspace derivatives.

  • Explored in “Opportunities and Considerations of Ethereum’s Blockspace Future.”

• Designing Encrypted Mempools/Alt Mempools

  • Initial Exploration is done in “Cryptographic Approaches to mempool privacy.”

• Handling State Growth with State Rent

  • How do you price state growth? This is a common problem in highly performant blockchains like Solana and, ultimately, an issue for ethereum as well.

• Decentralized Sequencers

  • How to make the decentralized sequencer implementation faster while preserving security guarantees?

  • There is a tradeoff between speed and trust assumptions while guaranteeing censorship resistance and liveness.

  • Block production on L2s has higher compute needs due to larger proofs, more transactions, and proof generation. This increases centralization risks.

• Shared Sequencers

  • Shared sequencing is gaining popularity for rollups, where a separate sequencing layer orders transactions before app-specific rollup chains execute them.

  • How do we design economic mechanisms for revenue sharing between rollups that accurately capture their marginal contributions to MEV transparently?

  • Developing fee mechanisms for the sequencer that don't require it to execute transactions or maintain excessive state?

  • Goals include low latency, resisting front-running, avoiding centralization, and independence of unrelated transactions.

  • Look at this talk for more.

• Oracle Systems, which gives access to more varieties of data

  • Comments from SoK: Oracles from the Ground Truth to Market Manipulation

    • Two conditions seem necessary for securing oracle systems: the token's market capitalization stays material, and the token is evenly distributed.

    • Oracle systems with on-chain modules are expensive to run on public blockchains like Ethereum, which prices out certain use cases that consume a lot of Oracle data but do not generate a proportional amount of revenue (e.g., Weather data).

• The tokenomics/governance problem

  • A boilerplate for tokenomics doesn’t exist.

  • Are there better models possible? Buyback and burn are done to skirt regulations.

  • Will we classes of shares in tokens like in tradfi? Class A shares, priority shares, etc., for better governance? Could this be the decaying power of priority over time? so the team has control to set forth a vision and then decentralize it?

• The governance framework problem

  • There have been a myriad of token takeovers of DAOs with no recourse and loss of funds every few months, and the most recent one is Tornado cash

  • Is there a good distribution or holding model or a delegation model that avoids voter apathy (most votes are decided by whale votes today)

  • Dual Governance models are being explored - OP labs and Lido.

• Governance beyond coin-voting

• • Is the Governance framework problem stuck as a plutocracy?

  • What other models reward or incentivize governance participation from those who care about the protocol's future?

• Better Fiat on-ramps/off-ramps: Are centralized exchanges the single point of fiat on-ramps to blockchains?

• Crypto x AI

  • Is Decentralized Computing the only idea?

  • POC for model control via decentralized protocols

    • Helpful for AI safety

  • Trustless AI inference

  • Decentralized Data networks for High-quality data with provenance

  • AI model marketplace

• Reputation Systems

  • A good decentralized reputation system can replace the need for identity.

This list was inspired by Riva Tez’s following tweet :D

https://twitter.com/rivatez/status/1121733391043502081