The reality is that writing trustworthy smart contracts that are bug-free is difficult, regardless of how much precaution you take. Moreover, with Ethereum, for example, verifying EVM code is incredibly difficult because of the way the EVM instructions are designed. This makes building formal verification solutions for Ethereum even more difficult. Regardless, formal verification is a strong approach to reducing the risk of bugs and attacks. They provide a higher guarantee of correctness than traditional approaches (e.g. testing, peer reviews, etc.) and we desperately need better solutions.
現実はバグなしの信頼可能なスマート契約を書くことは、あなたがどれぐらいの用心をするかにかかわらず、難しいということです。 さらに、 イーサリアムと共に、例えば、 EVM コードを検証することは EVM 命令が設計される方法のために信じられないほど難しいです。 これはイーサリアムのための正式の検証解決構築をさらにもっと困難にさせます。いずれにしても、正式の検証はバグの危険と攻撃を減らすことへの強いアプローチです。 それらは伝統的なアプローチ（例えばテスト、同僚評価など）より高い正しさの保証を提供します、そして我々は絶望的にもっと良い解決を必要とします。
Formal verification solutions
正式の検証解決
I wish I had more publicly available solutions to show off in this section, but unfortunately there aren’t many. One very early set of examples I found was done by Yoichi Hirai, who is a formal verification engineer for the Ethereum foundation. He was able to produce early results for verifying several smart contracts, including a small “deed” contract. Although very small, this is the first “real” contract that I’ve seen analyzed in a theorem proving environment.
私は私がこのセクションで披露するため、いっそう公的に利用可能な解決を持っていたならいいのにと思いますが、しかし不幸にも多くはありません。 私が発見した例の１つの非常に早いセットは、イーサリアム基金のための公式検証エンジニアである平井洋一 によって行われました。 彼は、小さい「権利証書」契約を含めて、いくつかのスマート契約を照合することに対する早い結果を出すことが可能でした。 非常に小さいけれども、これは私が定理を証明している環境で解析されるのを見た最初の「現実の」契約です。
=====================================================================
|
|
|
|
=====================================================================