How to trust/analyze bytecode of existing contracts?

If someone tells me "donate to my kickstarter-style contract!" I want to examine the code of that contract to make sure it works as advertised, but it's not easy to understand the compiled bytecode. It would be very easy to scam people who trust your bytecode.

Has anyone proposed solutions to this problem?

If Serpent etc. has "repeatable builds" (e.g. the same input always produces same bytecode) that would make it possible, though not easy, to verify that someone's Serpent code was indeed compiled into a given contract.

Or should someone could start a site which analyzes contract bytecode and says "This matches github.com/foo/kickstarter-contract v. 12.04.32" or "This appears to be Bitcoin-Hedge 12.34"?

Comments

  • linageelinagee Member Posts: 31 ✭✭
    Make a general purpose contract that can handle re-use, then it only needs to be analyzed once and can become more trusted over time.
  • hegelhegel Member Posts: 1
    edited September 2015
    The Native Client research paper has a discussion of "techniques for safely executing 3rd-party code" (section 6). The paper gives a pretty useful categorization of the space of possible approaches:
    1. system request moderation or permissions management through users, containers, etc. (Android);
    2. fault isolation or static analysis, type validation, memory protection, VM environments, etc. (NaCl) and
    3. trust with authentication which is basically certificates, registries, and so on (ActiveX).
    They basically claim the first and third categories are unworkable. There are valuable things to learn from the process-level isolation approach (the first category), but Microsoft's trust model was totally mistaken. The second category has three (or four) sub-categories: virtual machines, intermediate (portable) representation with a trusted compiler, and static analysis via proof-carrying code. VMs are safe but performance and portability suffers (think JVM). For the IR stuff, interestingly, there appears to be an argument against what's now taking shape as WebAssembly, but it's somewhat weak. Basically, an intermediate representation with a trusted compiler won't be as fast and the compiler then unnecessarily widens the attack surface.

    The really interesting idea they (claim to) implement is the concept of proof-carrying code.

    Not totally sure how to think of Ethereum in these terms.
    Post edited by hegel on
Sign In or Register to comment.