-
Notifications
You must be signed in to change notification settings - Fork 593
Problems
Rumor has it that you, a researcher or manager of researchers, is interested in joint research with the Ethereum Foundation. Below are the primary topics the Foundation will be thinking about for the next 2-3 years. If you, like us, you enjoy the prospect of thinking about one or more of these topics for the majority of your waking hours, do get in touch. The Foundation does have money to pay the salaries/stipend of those undertaking high-value research.
We have topics in both pure research as well as applied research. The Foundation and its agents seek help on either one. Typical outputs from researchers are: peer-reviewed academic papers, technical reports, and/or implementations (prototypes as well as production-ready).
- Algorithmic incentive mechanisms providing information security ("cryptoeconomics")
- Reducing transaction costs:
- How much and when does decentralization reduce transaction costs?
- Transaction costs = transaction fees + coordination costs?
- They may be reduced because of:
- Reduced number of counterparties
- Reduced need for building trust
- And increased because of:
- Increased technical overhead
- Decreased usability
- Increased responsibility
- They may be reduced because of:
- Transaction costs = transaction fees + coordination costs?
- Strategically increasing coordination costs to reduce the risk of undesired outcomes
- How much and when does decentralization reduce transaction costs?
Building on hundreds of impossibility results. E.g., 1 and 2.
- What centralized protocols can be decentralized (while preserving guarantees)?
- At what cost in protocol overhead?
- Are there limits to scalability?
- Only because of the requirement for shared state?
- Are there limits to scalability?
- At what cost in incentivization?
- What are the limits to incentivization?
- Limits to attribution
- Limits to mechanism budgets
- What are the limits to incentivization?
- With how much security (against coordinated choice, trusted majority required)?
- Limits to fault tolerance
- e.g. in objective protocols and subjective protocols
- At what cost in protocol overhead?
-
What are coordination costs?
- Costs associated with executing coordinated strategies (like attacks)
- Discovering potential peers
- Agreeing on/computing/ coalition strategies
- Synchronization required for execution
- Costs of proving to the coalition that players followed coalition strategies
- Cost of getting rid of individual incentives to deviate
- Costs associated with executing coordinated strategies (like attacks)
-
How can we measure coordination costs?
- for players running a particular protocol
- for players executing a particular strategy
-
How do we minimize coordination costs?
-
Modeling behavior of participants in mechanisms
- Simple (crash) faults
- Byzantine faults (arbitrary)
- Byzantine-Altruistic-Rational (BAR) model
- Uncoordinated majority (e.g., as in selfish mining)
- Coordinated choice
- Bribing attacker (as in P+epsilon attacks or iceman)
- Behavioral economics models (endowment effect, loss aversion, morality, etc.)
-
Complex game-theoretic interactions
- Blackmail
- Quantifying cooperative interactions among agents
A protocol fault is uniquely attributable if there is evidence that could be used to umambiguously convince any observer which actor caused the protocol fault.
If a fault is non-uniquely-attributable, the blame for the fault can often at least be narrowed down to 1 of N specific actors.
- Fault attributability in various consensus algorithms
- Chain-based (synchronous) consensus
- Partially synchronous consensus (see minimal slashing conditions)
- Common coins in asynchronous consensus
- Attributability of liveness faults
- Attributability of censorship
- See for background: https://blog.ethereum.org/2015/06/06/the-problem-of-censorship/
- Translating fault attributions into penalties
There are certain patterns that are often used to achieve various goals in cryptoeconomic mechanisms, and these can be studied in the abstract independently of the specific use case.
- Security deposits
- How do we model capital lockup costs?
- Dual-use of security deposits
- Challenge-response games (one group of actors is given the opportunity to submit evidence that fact X is false, and if no one submits evidence within some period of time, then X is assumed to be true)
- Channels
- http://www.jeffcoleman.ca/state-channels/
- How do we minimize the vulnerability of challenge-response games and channels to liveness or censorship faults of the underlying blockchain?
- Escalation games
- Cross-chain interoperability (see the R3 interoperability paper (PDF) )
- Relays
- Hash timelock atomic swaps
Applied Research (Pasteur's Quadrant)
This is all research in
Goal: Fully transition Ethereum from Proof-of-work to Proof-of-stake.
-
Economic Incentive analysis [49%]
-
Deligation protocols (or Voting Pool for PoS) [20%]
-
Formal Verification [45%]
-
Testing and Implementation [20%]
Goal: Allow Ethereum transaction capacity to scale to better than linear with computational capacity of the n nodes.
-
Data availability proofs [65%]
-
Effective state-space partitioning / Cross-shard communication [15%]
- Vitalik's R3 paper, particularly Section "scalability" (p20-30). The whole paper also has a three-page executive summary.
-
High-Level-Languages [20%]
- Topic: Developing a language that knows to send the cross-shard asynchronous messages whenever contracts are located on different shards.
-
Sharded Proof-of-stake architecture [20%]
- The Mauve paper [not ready for release; ask Vitalik for link to pre-release].
-
Topic: Applying prior theory from multicore CPUs/parallel threading to sharding.
Goal: Increase economic incentive confluence in all aspects of the Ethereum protocol.
-
Gas Limit Policy / state-resource pricing
- A theory of Blockchain Resoure Pricing [not ready for release; ask Virgil for link to pre-release]
-
Topic: Validator/miner economic policy---how much should we pay out?
Goal: Have a fast, efficient virtual machine optimized for processing cryptographic operations and smart-contracts.
-
Defining the Ethereum Virtual Machine for Interactive Theorem Provers
-
Contract as Automaton: The Computational Representation of Financial Agreements
-
Topic: Applying theory from chip opcode design to the EVM.
Goal: Smart-contracts are new territory and the best ideas in the space remain undiscovered. When we discover them, we must be able to roll them out gracefully.
-
The beautiful Vlad Zamfir on Soft forks, hard forks, and the Ethereum Social Contract
-
Topic: Hardforking the EVM
Goal: This is an important special-case necessary for many applications. We wish to solve it.
- Implementation
- Ethereum's RANDAO
- A candidate alternative design from Vitalik
- Bitcoin Beacon
- On Bitcoin as a public randomness source
- NIST Randomness Beacon
- Bitcoin Beacon — Princeton Bitcoin seminar final project
Goal: Allow apps to benefit from the transparency of blockchain-execution while preserving author privacy and the confidentiality of zer data. One solution, among several, is homomorphic encryption.
-
General: Privacy on the Blockchain
-
Mixers [30%] Bitcoin mixing remains an unsolved problem. As what's possible in Ethereum is a strict superset of Bitcoin, solving for either case is sufficient.
-
Voting [10%]
-
Zero knowlege proofs [30%]
-
Other
Goal: We wish to minimize the necessity of trusted third parties in currency exchanges.
Goal: Coding contracts (especially secure ones!) is hard. It should be easier. Please help us.
-
Languages
-
Formal Verification of HLLs [15%]
-
Other programming language techniques to analyse smart contracts
-
Defensive programming [30%]
- Ethereum's old list of open problems.