\n<\/p>\n
\nI\u2019m joining Ethereum as a formal verification engineer. My reasoning: formal verification makes sense as a profession only in a rare situation where<\/p>\n
\n
- the verification target follows short, simple rules (EVM);<\/li>\n
- the target carries lots of value (Eth and other tokens);<\/li>\n
- the target is tricky enough to get right (any nontrivial program);<\/li>\n
- and the community is aware that it\u2019s important to get it right (maybe).<\/li>\n<\/ul>\n
My last job as a formal verification engineer prepared me for this challenge. Besides, around Ethereum, I\u2019ve been playing with two projects: an online service called Dr. Y\u2019s Ethereum Contract Analyzer<\/a> and a github repository<\/a> containing Coq proofs. These projects are at the opposite extremes of a spectrum between an automatic analyzer and a manual proof development.<\/p>\n
Considering the collective impact to the whole ecosystem, I\u2019m attracted to an automatic analyzer integrated in a compiler. Many people would run it and some would notice its warnings. On the other hand, since any surprising behavior can be considered a bug, any surprise should be removed, but computers cannot sense the human expectations. For telling human expectations to the machines, some manual efforts are necessary. The contract developers need to specify the contract in a machine-readable language and give hints to the machines why the implementation matches the specification (in most cases the machine wants more and more hints until the human realizes a bug, frequently in the specification). This is labor intensive, but such manual efforts are justifiable when a contract is designed to carry multi-million dollars.<\/p>\n<\/blockquote>\n
Having a person dedicated to formal methods not only gives us the ability to move faster in this important but also fruitful area, it hopefully also allows us to communicate better with academia in order to connect the various singular projects that have appeared in the past weeks.<\/p>\n
Here are some projects we would like to tackle in the future, most of them will probably be done in cooperation with other teams.<\/p>\n
Solidity:<\/p>\n
\n
- extending the Solidity to Why3 translation to the full Solidity language (maybe switch to F*)<\/li>\n
- formal specification of Solidity<\/li>\n
- syntax and semantics of modal logics for reasoning about multiple parties<\/li>\n<\/ul>\n
Community:<\/p>\n
\n
- creating a map of formal verification projects on Ethereum<\/li>\n
- collecting buggy Solidity codes, for benchmarking automatic analyzers<\/li>\n
- analyzing deployed contracts on the blockchain for vulnerabilities (related: OYENTE tool<\/a>)<\/li>\n<\/ul>\n
Tools:<\/p>\n
\n
- provide a human- and machine-readable formalization of the EVM, which can also be executed<\/li>\n
- developing formally verified libraries in EVM bytecode or Solidity<\/li>\n
- developing a formally verified compiler for a tiny language<\/li>\n
- explore the potential for interaction-oriented languages (“if X happens then do Y; you can only do Z if you did A”)<\/li>\n<\/ul>\n<\/div>\n