Optional: Generalization to other languages

[v-bosch]

Allowing all languages - fully trustless/decentralized

To enable users to write unit tests and solutions in all languages, one would like to enable the user to write and evaluate smart contracts in other languages and/or to write smart contracts that can evaluate other languages. This would be completely decentralized and trustless, the strongest form of the protocol, fully generalized. This is what we aim for. A drawback of this option is that it is relatively expensive to run unit tests a few million/billion times by everyone in the blockchain. Below are a few options listed that could be theoretically/potentially pursued to facilitate this solution/market.

EVM of Ethereum 1.0:

• The EVM of Ethereum 1.0 already allows for a few languages, these are listed below. However, this is not the fully generalized option where anyone could straightforwardly submit a code in any language. E.g. a sponsor could not simply write Python unit tests and submit them, instead the sponsor would have to learn Viper and write their unit tests in Viper instead.

• Yul

• Solidity

• Solidity Assembly

• Yul+

• Viper

Ewasm

• The Ewasm of Ethereum 2.0 is extremely promising in this perspective, it allows almost all (practical) languages via the LLVM. A drawback is: it is not yet certain whether the Ewasm will actually make it to the Eth 2.0 implementation. Another concern voiced by the developers, is that it is more difficult for sponsors and bounty hunters to make safe contracts (spotify podcast). Templates provided by TruCol, and automated checks, could help guide the users to an increased level of safety. This project could greatly benefit from the Ewasm.

• C

• C++

• Rust

• JavaScript
  Furthermore, it uses the LLVM compiler that supports the following languages:
  ActionScript, Ada, C#, Common Lisp, Crystal, CUDA, D, Delphi, Dylan, Fortran, Graphical G, Halide, Haskell, Java bytecode, Julia, Kotlin, Lua, Objective-C, OpenCL, PostgreSQL's SQL and PLpgSQL, Ruby, Rust, Scala, Swift, Xojo and Zig.

Here is an overview of different hello world smart contracts for different languages on Ewasm. The answer shows solutions that are submitted to this competition to write Ewasm smart contracts in different languages, which has the pseudocode of the contract that is implemented in multiple languages.

• C
• Rust

Parity

• Parity allows Rust, Rust allows other languages.

[a-t-0]

Allowing All languages (by expanding chain of trust)

Running unit tests and solutions can be expensive on the blockchain. It might even be expensive on an oracle network. The cheapest option would be to run it on a single instance, but that lowers trust/decentralization. In light of real-world applications low cost might be relevant and the ability to ask solutions in other languages than solidity, is expected to be very important. So combining these two issues with a time constraint w.r.t. the competition (and Ewasm development), a temporary "quick fix" might be to (temporarily) allow users to choose to expand the chain of trust to put trust in GitHub and Travis CI to allow tests of all languages to be verified on a "cheap single computer": Travis-CI that has a lot of reputation on stake.

• This could be done by letting a sponsor create a GitHub repo with unit tests in a language of choice, along with a code skeleton and strict code formatting requirements. Then letting the sponsor compute the hash code of the files in the GitHub repo, and uploading that to a smart contract along with a bounty. Then the bounty hunter can look up that contract, fork the repo of the sponsor (check if the hash code is still valid), implement a solution in the chosen language, submit to Travis CI, and get some pass flag like this: in the repo. Next, the bounty hunter submits a smart contract that tells the smart contract of the sponsor where to find its solution. Then the sponsor contract first reads out the pass/fail from the pass flag through an oracle like Chainlink/Tellor, and if it passes, the sponsor contract asks the code/checksum of the files in that fork to compute the checksum. If the queried/computed checksum equals checksum that is stored in the smart contract of the sponsor then it pays out, otherwise the bounty hunter may have modified the unit tests to make them falsely pass.

Assumption: the hash codes/checksum of a set of files is not hackable/gamable. What I mean with that is: if the employer writes a repository and specifies 3 files to contain three strings: abc, def, ghi, and computes a hash code/checksum of those 3 files, the employer is not able to modify those 3 files whilst still obtaining the same hash code/checksum for those files

Possible Attacks & Mitigations

0.a One risk identified in advance is that the bounty hunter could possibly modify the settings within the shielded/private CI by setting evaluation time limit to 0 seconds or withdrawing all CI funds.
0.b But this is not a real risk, because the sponsor smart contract has funds and is its own agent, so it (theoretically) could set up the CI on its own, open source, deterministic and transparent.

1.a A malicious sponsor might want to disable the CI tests.
1.b The sponsor does not have access to the CI, so the employer can't hack the CI.

2.a The bounty hunter has access to the CI and can hence hack it,
2.b But only to break the test (which is not in the interest of the bounty hunter).

3.a E.g. when talking about Travis CI, the bounty hunter could trigger a malicious custom build that always passes the tests
3.b This build is not propagated to the pass flag in the GitHub pull request.

4.a The bounty hunter could maliciously modify the files in the pull request to make the tests falsely pass.
4.b Then the hash code/checksum of the smart contract of the employer would detect this attack and not pay out.

5.a Though I'm sure in the complex system of Travis-CI in a hacker could break it in practice.
5.b But that is because Travis is not defending against this. I think if they were (to facilitate this market), those attacks could be (relatively easily) mitigated by modifying Travis API for this market. So for a proof of concept I think this is fine.

Nevertheless, it would be best if neither of the parties have to be trusted by letting the smart-contract of the sponsor make its own independent account. Ideally the autonomous agent in the sponsor smart contract could just ask for a CI based on a git, and give some ETH to the CI for the one-time job (however Travis does not have this billing option yet).