# Hello potential research collaborator!

Rumour has it that _you_, a researcher or manager of researchers, are interested in _joint research_ with the [Ethereum Foundation](https://ethereum.org). Below are the primary topics the Foundation will be thinking about for the next 2-3 years. If you, like us, 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](https://hackmd.io/s/HkLkj55yb#questions-in-fundamental-research) and [applied research](https://hackmd.io/s/HkLkj55yb#objectives-in-applied-research). The Foundation as well as the larger Ethereum community seek help on both. Typical outputs from researchers are: peer-reviewed academic papers, technical reports, and/or implementations (prototypes as well as production-ready).

---
# Questions in Fundamental Research

## Q1: Can we create a theory of cryptoeconomic mechanisms?
* There are certain patterns that are often used in [_cryptoeconomic_](https://theethereum.wiki/w/index.php/Cryptoeconomics) mechanisms. These can be studied in the abstract independently of any specific use case.
* Security deposits (see also [proof of stake](https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ))
* 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). See also [challenge-response authentication](https://en.wikipedia.org/wiki/Challenge–response_authentication).
* Channels
* [State 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](https://www.acsu.buffalo.edu/~fczagare/Articles/Dynamics%20of%20Escalation.PDF)
* Cross-chain interoperability (see the [R3 interoperability paper]() <todo: add link>)
* Relays
* Hash timelock atomic swaps

## Q2: What is the role of cryptoeconomics in distributed systems? What is the role of economics in cryptography?

* Can we formalize how [algorithmic incentives](http://dl.acm.org/citation.cfm?id=1296179) ("cryptoeconomics") can enhance information security?
* Modeling behavior of participants in mechanisms
* Simple (crash) faults
* [Byzantine faults](https://en.wikipedia.org/wiki/Byzantine_fault_tolerance) (arbitrary)
* [Byzantine-Altruistic-Rational (BAR) model](http://www.cs.utexas.edu/users/dahlin/projects/bft/#BAR)
* Uncoordinated majority (e.g., as in [selfish mining](https://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf))
* Coordinated choice
* Bribing attacker (as in [P+epsilon attacks](https://blog.ethereum.org/2015/01/28/p-epsilon-attack/) or [iceman](https://dl.dropboxusercontent.com/u/3308162/iceman.pdf))
* Behavioral economics models ([prospect theory](https://www.princeton.edu/~kahneman/docs/Publications/prospect_theory.pdf), [endowment effect](http://www.jstor.org/stable/1942711), [loss aversion](https://academic.oup.com/qje/article-abstract/106/4/1039/1873382/Loss-Aversion-in-Riskless-Choice-A-Reference), [morality](https://link.springer.com/chapter/10.1007%2F978-3-319-19671-8_14), etc.)

* Complex game-theoretic interactions
* [Blackmail](http://www.jstor.org/stable/3312653?seq=1#page_scan_tab_contents)
* Quantifying cooperative interactions among agents (e.g. [dynamic coalition formation](http://www.sciencedirect.com/science/article/pii/S0022053103000048))
* [Evolution and enforcements of group norms](http://amr.aom.org/content/9/1/47.short)

## Q3: How do distributed systems influence current economics?

* On net, when and how much does decentralization lower transaction costs?
* No obvious answer. Decentralization _decreases_transaction costs because of: Reduced number of counterparties and reduced need for building trust
* Yet decentralization _increases_ transaction costs because of: increased technical overhead, Decreased usability, increased responsibility.
* Are Transaction costs = transaction fees + coordination costs?

## Q4: Within game-theory, can we quantify coordination costs?
* for players running a particular protocol
* for players executing a particular strategy

## Q5: What are ways we can manipulate (e.g., guarantee/minimize) coordination costs?
* For example, we can reduce risk by [increasing coordination costs](http://vitalik.ca/general/2017/05/08/coordination_problems.html).
* Coordination costs are costs from multiple-agents coordinating.
* For example: 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

## Q6: What protocols have better fault attribution?
* 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 within N specific actors.

* Fault attributability in various consensus algorithms
* Chain-based (synchronous) consensus
* Partially synchronous consensus (see [minimal slashing conditions](https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c))
* Common coins in asynchronous consensus
* Attributability of [censorship](https://blog.ethereum.org/2015/06/06/the-problem-of-censorship/) or liveness faults.

* Translating fault attributions into penalties
* [Shapley values](https://en.wikipedia.org/wiki/Shapley_value)

## Q7: What are decentralization's fundamental limits?
Building on hundreds of impossibility results. E.g., [1](http://link.springer.com/article/10.1007/s00446-003-0091-y) and [2](http://groups.csail.mit.edu/tds/papers/Lynch/MIT-LCS-TM-394.pdf), or even [fundamental limits](https://en.wikipedia.org/wiki/Landauer%27s_principle) from other areas of computer science.

* What centralized protocols can be decentralized (while preserving guarantees)?
* At what cost in protocol overhead?
* Are there limits to scalability?
* For Bitcoin: [On Scaling Decentralized Blockchains](http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf)
* Only because of the requirement for shared state?
* At what cost in incentivization?
* What are the limits to incentivization?
* Limits to attribution
* Limits to mechanism budgets
* With how much security (against coordinated choice, trusted majority required)?
* Limits to fault tolerance
* e.g. in objective protocols and subjective protocols
---

# Objectives in Applied Research

Also knows as [Pasteur's Quadrant](https://en.wikipedia.org/wiki/Pasteur%27s_quadrant).

## 1. Base Layer (core protocols)

### 1.1 Proof of Stake [50% complete]
**Goal: Fully transition Ethereum from Proof-of-work to Proof-of-stake.**

* [Proof of stake FAQ](https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ)
* Economic Incentive analysis [49%]
- [Cryptocurrencies without Proof of Work](https://arxiv.org/abs/1406.5694)
- [Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol](https://eprint.iacr.org/2016/889.pdf)
- [Minimum Slashing Conditions](https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c)
- [Slasher Ghost, and Other Developments in Proof of Stake](https://blog.ethereum.org/2014/10/03/slasher-ghost-developments-proof-stake/)
- [Least Authority Performs Incentive Analysis For Ethereum](https://leastauthority.com/blog/least_authority_performs_incentive_analysis_for_ethereum/)
- [Demystifying incentives in the consensus computer](https://eprint.iacr.org/2015/702)
- [On Stake](https://blog.ethereum.org/2014/07/05/stake/)
- [Safety Under Dynamic Validator Sets](https://medium.com/@VitalikButerin/safety-under-dynamic-validator-sets-ef0c3bbdf9f6)

* Delegation protocols (or Voting Pool for PoS) [20%]
* [Using trusted hardware](https://medium.com/@loiluu/casper-sgx-8475e56244b)
* Formal Verification [45%]
- [Formal methods on some PoS stuff](https://medium.com/@pirapira/formal-methods-on-some-pos-stuff-e309775c2ab8)
- [A mechanized safety proof with dynamic validators](https://medium.com/@pirapira/a-mechanized-safety-proof-for-pos-with-dynamic-validators-17e9b45faff4)
- [Formal methods on another Casper](https://medium.com/@pirapira/formal-methods-on-another-casper-8a75f6e02073)
- [Securify.ch](http://securify.ch/)

* Testing and Implementation [20%]
- History of Casper: Chapters [1](https://blog.ethereum.org/2016/12/06/history-casper-chapter-1/), [2](https://blog.ethereum.org/2016/12/07/history-casper-chapter-2/), [3](https://medium.com/@Vlad_Zamfir/the-history-of-casper-chapter-3-70fefb1182fc), [4](https://medium.com/@Vlad_Zamfir/the-history-of-casper-chapter-4-3855638b5f0e), and [5](https://medium.com/@Vlad_Zamfir/the-history-of-casper-chapter-5-8652959cef58)
- [Stage 1 CASPER contract and JSON RPC demo](https://github.com/ethereum/casper)

### 1.2 Sharding [49%]
**Goal: Allow Ethereum transaction capacity to scale to better than linear with computational capacity of the n nodes.**
* [Sharding FAQ](https://github.com/ethereum/wiki/wiki/Sharding-FAQ)

* Data availability proofs [65%]
- [A note on data availability and erasure coding
](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding)

* Effective state-space partitioning / Cross-shard communication [15%]
- Vitalik's [R3 paper](http://r3cev.com/s/Ethereum_Paper-97k4.pdf), particularly Section "scalability" (p20-30).
The whole paper also has a [three-page executive summary](http://r3cev.com/s/Ethereum_Paper_Executive_Summary.pdf).

* 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._

### 1.3 Protocol Economics [50%]
**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?_

### 1.4 Ethereum Virtual Machine (EVM) upgrades and optimization [40%]
**Goal: Have a fast, efficient virtual machine optimized for processing cryptographic operations and smart-contracts.**

- [Defining the Ethereum Virtual Machine for Interactive Theorem Provers](https://yoichihirai.com/malta-paper.pdf)

- [Optimising the Ethereum Virtual Machine](https://medium.com/@jeff.ethereum/optimising-the-ethereum-virtual-machine-58457e61ca15)

- [Go Ethereum’s JIT-EVM](https://blog.ethereum.org/2016/06/02/go-ethereums-jit-evm/)

- [Contract as Automaton: The Computational Representation of Financial Agreements](https://www.financialresearch.gov/working-papers/files/OFRwp-2015-04_Contract-as-Automaton-The-Computational-Representation-of-Financial-Agreements.pdf)

- [Subroutines and Static Jumps for the EVM](https://github.com/ethereum/cpp-ethereum/issues/3404)

- Topic: _Applying theory from chip opcode design to the EVM._

### 1.5 Stategies for efficaciously hardforking for upgrades [40%]
**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.**
- [Hard Forks, Soft Forks, Defaults and Coercion
](http://vitalik.ca/general/2017/03/14/forks_and_markets.html)

- The beautiful Vlad Zamfir on [Soft forks, hard forks, and the Ethereum Social Contract](https://www.youtube.com/watch?v=OWSxbELIJqM)

- Topic: _Hardforking the EVM_

---

## 2. Layer 2

### 2.1 On-chain Random Number Generation [63%]
**Goal: This is an important special-case necessary for many applications. We wish to solve it.**

* Implementation
- Ethereum's [RANDAO](https://github.com/randao/randao)
- A candidate [alternative design](https://www.reddit.com/r/ethereum/comments/4mdkku/could_ethereum_do_this_better_tor_project_is/d3v6djb/) from Vitalik
- [Bitcoin Beacon](https://arxiv.org/abs/1605.04559)
- [On Bitcoin as a public randomness source](https://eprint.iacr.org/2015/1015.pdf)
- [NIST Randomness Beacon](https://www.nist.gov/programs-projects/nist-randomness-beacon)
- [Bitcoin Beacon — Princeton Bitcoin seminar final project](https://www.youtube.com/watch?v=h5dwp4T-MWE)
- Tor project's [attempt](https://blog.torproject.org/blog/mission-montreal-building-next-generation-onion-services) at the same.

### 2.2 Privacy [40%]
**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](https://en.wikipedia.org/wiki/Homomorphic_encryption).**

* General: [Privacy on the Blockchain](https://blog.ethereum.org/2016/01/15/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. Incentivized Mixing?
- [Princeton Bitcoin course: Anonymity (Lecture 6)](https://www.youtube.com/watch?v=glyQy_e5LmM)
- [An Empirical Analysis of Linkability in the Monero Blockchain](https://arxiv.org/abs/1704.04299)
- [CoinParty: Secure Multi-Party Mixing of Bitcoins](https://www.martinhenze.de/wp-content/papercite-data/pdf/zmh+16.pdf)
- [Secure and Anonymous Decentralized Bitcoin Mixing](https://www.martinhenze.de/wp-content/papercite-data/pdf/zmh+16.pdf)
- [Decentralized Mixer based on RingSignature](https://github.com/sontol/RingToken)
- [Laundromat: Mixing via ring signatures](https://github.com/blackyblack/laundromat)

* Voting [10%]
- [A Smart Contract for Boardroom Voting with Maximum Voter Privacy](http://fc17.ifca.ai/preproceedings/paper_80.pdf)

* Zero knowlege proofs [30%]
- [ZK-Snarks](https://medium.com/@VitalikButerin/zk-snarks-under-the-hood-b33151a013f6)

* Other
- [Confidential assets](https://people.xiph.org/~greg/confidential_values.txt)

### 2.3 Decentralized exchanges [50%]
**Goal: We wish to minimize the necessity of trusted third parties in currency exchanges.**

* [Atomic swap](https://en.bitcoin.it/wiki/Atomic_cross-chain_trading)
* [on-chain decentralized exchanges](https://www.reddit.com/r/ethereum/comments/55m04x/lets_run_onchain_decentralized_exchanges_the_way/)
* [mkr market](https://oasisdex.com/)
* [etherdelta](https://etherdelta.github.io/)

### 2.4 High-level-languages (HLLs) [40%]
**Goal: Coding contracts (especially secure ones!) [is hard](https://en.wikipedia.org/wiki/The_DAO_(organization)). It should be easier. Please help us.**

* Our packet for recruiting [PLT researchers](https://hackmd.io/s/H1KG6GN4b).

* Languages
- [Solidity](https://github.com/ethereum/solidity/)
- [Viper](https://github.com/ethereum/viper)
- [Pact](http://kadena.io/pact/)
- [Composing contrats: an adventure in finanial engineering](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/contracts-icfp.pdf)
- [Ivy](https://chain.com/docs/1.1/protocol/papers/blockchain-programs)
- [Bamboo](https://github.com/pirapira/bamboo)
- [functional-solidity-language](https://github.com/raineorshine/functional-solidity-language)
- [Pax Codex](https://medium.com/@PaxDirectory/codex-a-legal-scripting-language-e3723cc76662)
- [Hammurabi Project](https://github.com/mpoulshock/HammurabiProject) in Wolfram Language

* Formal Verification of HLLs [15%]
- [Formal Certification of a Compiler Back-end or: Programming a Compiler with a Proof Assistant](http://gallium.inria.fr/~xleroy/publi/compiler-certif.pdf)
- [Short Paper: Formal Verification of Smart Contracts](https://www.cs.umd.edu/~aseem/solidetherplas.pdf)

* Other programming language techniques to analyse smart contracts
- [Oyente, a symbolic execution based analyser for smart contracts](https://github.com/melonproject/oyente)
- [Using Oyente to optimize smart contracts](https://arxiv.org/pdf/1703.03994.pdf)

* Defensive programming [30%]
- [Step by Step Towards Creating a Safe Smart Contract: Lessons and Insights from a Cryptocurrency Lab](https://eprint.iacr.org/2015/460.pdf)
- [A Programmer’s Guide to Ethereum and Serpent](https://mc2-umd.github.io/ethereumlab/docs/serpent_tutorial.pdf)
- [A survey of attacks on Ethereum smart contracts](https://eprint.iacr.org/2016/1007.pdf)
- [Thinking About Smart Contract Security](https://blog.ethereum.org/2016/06/19/thinking-smart-contract-security/)
- [Ethereum Contract Security Techniques and Tips](https://github.com/ethereum/wiki/wiki/Safety)

# Appendix
* Ethereum's old list of [open problems](https://github.com/ethereum/wiki/wiki/Problems).

## Relevant Conferences
Research communities whose interests intersect with Ethereum's research include (in alphabetical order, non-exhaustive):

* **Algorithmic Game Theory.** ACM Conference on Economics and Computation, Conference on Web and Internet Economics, Symposium on Algorithmic Game Theory, International Conference on Game Theory
* **Blockchain.** Annual Blockchain Summit, Coinfest, Consensus, Internet of Things World, Workshop on Bitcoin and Blockchain Research
* **Computer Security.** ACM Conference on Computer and Communications Security, IEEE Computer Security Foundations Symposium, USENIX Security Symposium
* **Cryptography.** CRYPTO (International Association for Cryptologic Research), EUROCRYPT (Annual International Conference on the Theory and Applications of Cryptographic Techniques)
* **Distributed Computation.** ACM Symposium on Principles of Distributed Computing, ACM Symposium on Parallelism in Algorithms and Architectures
* **Multi-Agent Systems.** International Conference on Autonomous Agents and Multiagent Sytems, AAAI Conference on Artificial Intelligence, International Joint Conference on Artificial Intelligence