Parser/interpreter access within rholang

[Bill-Kunj]

Introduction/Motivation/Abstract

Users need to be able to see the rholang code they are executing, even when the rholang contract has already been stored on-chain. In support of this, the rholang source code can be stored alongside the actual contract. This leaves a security hole, since the rholang source code can be maliciously different from the stored contract.
Access to the interpreter/parser would allow execution to validate the stored rholang code against the stored contract to resolve malicious activity.

Examples

I would like to be able to do something like

new interpreter(`rho:rholang:interpreter`), someBugger(`someBugger`), compare, theSame in {
  for (@bugger <- "new i in for () { i!(\"blah\") }") {
    interpreter!(bugger, *compare) |
    compare!(*someBugger, *theSame) |
    match theSame {
      true => { blah | blah | blah }
      false => { blah | blah | blah }
    }
  }
}

Where someBugger is a previously stored contract.

[fabcotech]

Yes very cool feature ! A must-have feature that Ethereum has is the capability to verify the source code of a contract.

See the "contract" tab here with Contract Source Code Verified (Exact Match) https://etherscan.io/address/0xB8c77482e45F1F44dE1745F52C74426C631bDD52#code

Maybe in RChain it could ressemble a pattern match of the internal channels structures instead of a source code stored aside the contract (is that even possible in rholang ?).

[dckc]

By way of precedent, see E(zoe).install(bundle) ; and from a Zoe installation, one can get the source bundle back.

In fact, perhaps the ability to "pretty print" a quoted process to rholang is the necessary and sufficient feature?
Folks that want a parser can...

1. deploy their code, using the parser there, but keep the resulting process in quoted form,
2. call the pretty print method to get the source if they want it on chain

This produces a canonicalized version of the source, not the code as the developer wrote it, with comments and such. In Zoe, the comments and such are considered important, so we support it. (We support it also because JavaScript doesn't have another ubiquitous quoted form such as a a monte AST or rholang has with quoted processes.)