fracting / draft Goto Github PK

EtherProof:

• port formal verification engine like Isabelle/Coq to Ethereum, naming EtherProof
• Add EVM opt code backend for PollyML/OCaml compiler
• Recompile Isabelle/Coq core to EVM opt code

Prove Request:

• A Prove Request is an unproven theorem (or more precisely unproven hypothesis since it’s not guaranteed to be true), which is submitted to a proof market.
• Encrypted Prove Request - zkSNARK?

Eth Proof Market:

• A customer submits a Prove Request to a proof market. The Prove Request is encoded as EVM opt code in a smart contract, with a deposit in ETH.
• A proof engineer who wants to earn the money has to provide either a formal proof or a counterexample of the hypothesis within the Prove Request.
• Miners run EtherProof to confirm the proof engineer done the right thing and transfer the deposit to the proof engineer’s address.

Eth Software Market:

• A spec designer defines the spec and property of an algorithm, including features, security property, performance property, etc, described in formal verification language.
• The spec designer submits the spec and property to the Eth Software Market, deposits some ETHs in the submission.
• A software engineer who wants to earn the money has to provide an implementation of the algorithm as well as a formal proof which shows the implementation matches the spec and satisfies all properties.
• Miners run EtherProof to confirm the software engineer done the right thing and transfer the deposit to the software engineer’s address.

Crowdfunding automation for open source software development:

• A software engineer herself could raise a crowdfunding for an open source software, or even part of it, like implementing a feature or fixing a bug, by providing the spec/property first but hold on the implementation for some time.
• Once the communities pay the deposit to the crowdfunding, she publishes her improvement, and once her improvement is automatically verified by EtherProof, the funding would be transfer to her wallet address automatically.

Decentralized Auto Theorem Prover (DATP):

• A customer submits an unproven hypothesis to a proof market with a deposit in ETH
• A miner proves the hypothesis or find a counterexample using an ATP and earns the ETH directly. Note that ATP itself does not need to be executed in an EVM environment, only the output of ATP matter.

ICO for an EtherProof upgrade (or ICO for any open source Ethereum infrastructure):

• An EtherProof developer invents a better EtherProof implementation, she could:
  • Benchmark the new EtherProof with a public dataset to show how good the performance is
  • Submit the new EtherProof implementation and a benchmark to a third party ICO platform, raise an ICO for her new EtherProof implementation
• Mining pool owners / Individual miners might have the incentive to invest the new EtherProof in order to improve the performance.
• Once the ICO success, the new EtherProof implementation will be automatically open sourced by the ICO platform, miners will deploy the new EtherProof implementation. Eths mined by the new EtherProof implementation will be taxed, the tax would be shared between ICO investors according to their equity. The wallet address of those investors would be embedded into the new EtherProof protocol.

ICO for new ATP algorithm:

• This seems tricky, there seems no way to guarantee investors could get a return proportional to their equity. A crowdfunding is possible where sponsors are not guaranteed to get a return in money, instead, they get a better open source implementation of some ATP algorithm.
• Competition for new ATP algorithm sponsored by large mining pool owners might be more realistic, however, it would be closed source.

Chain of partially proved theorems:

• For large theorem, it would be too difficult to be proved by a single proof engineer. In this case, one can divide a theorem into multiple subgoals, prove some of them, and ask someone else to prove the remain subgoals by promising to share the prize. Assume there are two subgoals in the example below:
  • Proof Engineer Alice proves Subgoal A, and publish Subgoal B to the proof market.
  • Alice shows Subgoal A + Subgoal B really imply the original puzzle.
  • Alice shows she knows a proof of Subgoal A, without revealing the proof.
  • Alice specifies how many proportions of the prize she wants to share with her unknown partner who can prove Subgoal B.
  • Proof Engineer Bob picked Subgoal B, proves it and submits the proof to the proof market, and shares the prize with Alice. At this point, Alice’s proof of Subgoal A will be revealed automatically.
  • Bob could also divide Subgoal B to more subgoals, proves part of them and published the remain parts on the proof market with a promise of sharing the prize. This process constructs a chain of partially proved theorems.
  • If nobody else proves Subgoal B, Alice could also do it by herself and earn all the money.
  • Optional for timeout setting: proof of subgoal A would be automatically published if it reaches a timeout.

Library of Lemmas:

• A lemma is useful for proving large theorems. A theorem could import multiple lemmas, and each lemma could import multiple other lemmas.
• Lemma library is store in decentralized storage like Storj.
• Each lemma has a unique Id, every time a proof of a theorem uses a lemma, the miner will increase credit of that lemma when verifying the proof.
• ICO or Crowdfunding for lemmas? Does Storj storage provider have the incentive to sponsor lemma development?

Migrate from Proof-of-W/S to Proof-of-Theorem

• Mix of Proof-of-W/S with Proof-of-Theorem
• Proof-of-Theorem is more efficient since it does not waste energy for computing non-sense problems, instead, it solves real-world problems.
• Instead of hashing a random string like what Proof-of-Work does, in Proof-of-Theorem, a miner runs ATPs and hashes the proof code generated by ATP.
• Fully bootstrap Ethereum network by Proof-of-Theorem

Misc

• Running EtherProof might be crazy expensive until Ethereum is fully bootstrapped with Proof-of-Theorem
• Discovering and verifying a proof is naturally a verifiable computation task, where discovering is expensive and verifying is cheap
• Training and evaluating a neural network is also naturally a variable computation task, where training is expensive but evaluating is cheap. However, there is a simple way to cheat in the training task, by just remembering every examples in testing set (overfitting). In order to prevent cheating, we need some kind of blind testing. One could hide the blind testing dataset until the trainer is confident enough to run the test: there is only one chance, if the trainer's model performs well on the testing dataset, then it earns the money, if it fails then it lost the money. We can extend the design to provide multiple chances, by randomly divide the testing set to multiple parts with the same size, each time reveals one part. We could modify the design so the trainer must put a deposit before asking for revealing the testing set, if the model fails on the testing set then the frozen deposit would be transferred to the custom's wallet as a punishment, otherwise it would return back to the trainer's.

Here is another following up of #2, showing how RNN seq2seq fails to translate the English word cousin to Chinese when the right selection of target word depends on logical deduction according to the context.

Original English text:

Mary is a ten years old girl, Mike is an eight years old boy.
Mary's father and Mike's father are brothers. Mary is Mike's cousin.

Incorrect Chinese translation generated by Google Translation:

玛丽是一个十岁的女孩，迈克是一个八岁的男孩。 玛丽的父亲和麦克的父亲是兄弟。 玛丽是麦克的表弟。

Expected Chinese translation:

玛丽是一个十岁的女孩，迈克是一个八岁的男孩。 玛丽的父亲和麦克的父亲是兄弟。 玛丽是麦克的 *堂姐*。

Note that the English word cousin could be translated to at least 8 different words depending on the context, including 堂兄 堂弟 堂姐 堂妹 表兄 表弟 表姐 表妹. Since there is no common Chinese word which can express the exact meaning of cousin by covering all 8 cases at the same time, in order to make a perfect Chinese translation we are forced to pick one of those 8 candidates, which involves logical deduction on the relationship between the two people in the passage.

In the carefully selected demo above, Google Translate incorrectly translated cousin to 表弟 when it should be 堂姐, which made all possible mistakes it could make: the order of birth is wrong, the gender is wrong, and the type of family connection is also wrong. Today none of neural machine translation systems from Google/Bing/Youdao/etc can translate this passage correctly. (If any NMT system translates it correctly by luck, we can slightly change the age or gender to fool the NMT system immediately)