Rholang Library Management

[zsluedem]

Purpose

The intention of this issue is to come up with a solution or a plan for a rholang developer to get meta information of the continuation(library) in the chain and make sure they are executing continuation(library) which are safe.

The proposal is for whom

1. rholang library developer
2. dapp developer (actually a little bit duplicate of 1)
3. third party package management software development

The general case to solve

To make the situation more concrete, I would like to imagine a case and let everyone to provide some feedback.

Supposed that. Alice writes a library to calculate the Fibonacci number and wants to publish the library to every other developer to use. Alice deploys her rholang code to the chain and put that continuation in a registry rho:id:z3kotpcwux8ekqb85sdnmj9kj3mwyc1wpoqa1jwc1zcoqc9ptrn9ti and then Alice tells Bob that she publishes a new library. Now Bob wants to use this library and the problems come out.

1. how can Bob be sure that the codes are safe enough and don't steal money from Bob
2. where can Bob get information if Alice doesn't tell Bob where the continuation lives

Solution

Looking forward to the discussions

We can absorb some of the ways how other languages do like npm, pypi and etc. but more like an on-chain solution.

1. Registry the metadata of the library on chain (which users can get source deploy code in the chain)
2. Provide a centralized rholang name to get the lib from chain
3. Provide a more friendly syntax for importing a library(actually this doesn't belong here )

[fabcotech]

This is IMO highly related to the type system, that is still to come, and the "beahavior searching" capabilities rholang potentially has, this library managment system could be the first brick of that. Basically it is the place developers will agree to publish, and make their rholang available for other rholang executions. Great !

[dimworm]

The RhoID is very easy to be misspelled, we need a centralized package manager first, then we can move it on chain.

[lolll1]

This is IMO highly related to the type system, that is still to come, and the "beahavior searching" capabilities rholang potentially has, this library managment system could be the first brick of that. Basically it is the place developers will agree to publish, and make their rholang available for other rholang executions. Great !

Agree. The behavior type system has enormous potentiality on this. Glad to see people bring in bricks for rholang building. Congrats!

[dckc]

Anyone who writes more than a trivial amount of rholang is going to come up with some system for managing deployed libraries; I played around with an rclient register xyz.rho mechanism around Jan 2019: https://github.com/dckc/RChain-API/blob/master/rclient/src/main.js#L36

I'd like to see a lot more experimentation before any sort of standardization effort. I'd like to see several experiments converging on the same design.

And yes, behavioral types are designed to help (my experiments: https://github.com/rchain-community/behavr ). Types could be published and checked even before they are an integral part of the validators.

[dckc]

More recent progress in this area: https://github.com/rchain-community/rgov/blob/master/CONTRIBUTING.md#contract-deployment-with-registry-uri-fixups

https://github.com/rchain-community/rchain-api/blob/master/src/rhopm.js

https://github.com/rchain-community/liquid-democracy/pull/18

3. ~Provide a more friendly syntax for importing a library(actually this doesn't belong here )~

I don't see why discussion of such syntax is out of scope here. In my recent work, I use:

  match ("import", "./directory.rho", `rho:id:...`) {
    (_, _, directoryURI) => lookup!(directoryURI, *ret)
  }

[dckc]

@Bill-Kunj noted a technique in rchain-token that sometimes conflicts with rholang syntax (and hence editing tools):

in {

  TREE_HASH_MAP

  // ...

  for (@boxId <= initLocksForBoxCh) {

-- https://github.com/fabcotech/rchain-token/blob/master/rholang/master.rho#L80-L92

It looks somewhat like the above mechanism in rhopm.

I noted https://github.com/rchain/rchain/tree/dev/rholang/examples/linking

Here's hoping for convergence in this area.

[Bill-Kunj]

@Bill-Kunj noted a technique in rchain-token that sometimes conflicts with rholang syntax (and hence editing tools):

in {

  TREE_HASH_MAP

  // ...

  for (@boxId <= initLocksForBoxCh) {

-- https://github.com/fabcotech/rchain-token/blob/master/rholang/master.rho#L80-L92

It looks somewhat like the above mechanism in rhopm.

I noted https://github.com/rchain/rchain/tree/dev/rholang/examples/linking

Here's hoping for convergence in this area.

I agree.

This is not interpret-able as rholang, meaning that standard rholang tooling is useless for this code. I cannot run this through an "explore" and know that it is valid, let alone any other dev tooling. This formulation of rholang would require tools for a special 'dialect' of rholang that understood things like "TREE_HASH_MAP".

My understanding is that this "rholang" code would be passed through a preprocessor which translates the magic 'TREE_HASH_MAP' identifier and produces supposedly valid, generated rholang code. While this is not uncommon (e.g. the C preprocessor), there is no specification here that guarantees a valid rholang output and no tooling other than a javascript string replacement implementation. I remember doing many things like this in C and C++ with the preprocessor, and they never really worked out because no one could keep up with all the conventions (e.g. the 'dialect') required, and the expansions of such MACROS were never entirely understood. Moreover, since security is paramount in blockchain contracts, generated code from a preprocessor is inherently untrustworthy unless the preprocessor is guaranteed.

This reminds me of old shell script ideas of putting command/code into variables. Over time everyone realizes that no one writes real software in shell script because meta-variable substitutions like TREE_HASH_MAP simply get too complicated.

A better solution would be to solve the dependency (import/export in JS parlance) problems that are currently not solved in rholang

[Bill-Kunj]

@dckc what do think?

Obtain 'TREE_HASH_MAP' from the chain itself.

The only thing required to do this would be a 'library' URI for such contracts:

match [ `libraryURI` ] {
[ libraryURI ] => {
   new
      lookup(`rho:registry:lookup`),
      uriCH,
      capCH
   in {
      lookup!(libraryURI, *uriCH) |
      for (library <- uriCH) {
         library!("TREE_HASH_MAP", *capCh)
         for (TREE_HASH_MAP <- capCH) {
           // some rholang using TREE_HASH_MAP
         }
      }
   }
}}

[dckc]

Hi @Bill-Kunj ,

TreeHashMap is already (1) on chain in full, and (2) in the registry. No linking is needed:

new
  rl(`rho:registry:lookup`),
  MakeMintCh, AuthKeyCh, EitherCh, TreeHashMapCh,
in {
  rl!(`rho:lang:treeHashMap`, *TreeHashMapCh) |
  for (       TreeHashMap    <- TreeHashMapCh) {

-- https://github.com/rchain/rchain/blob/6dc1514e8682d18101a6ca20c99bede81b8ed9f2/casper/src/main/resources/RevVault.rho#L17-L35

and now it's ready to use:

    // ...
    new mintCh, vaultMapStore, initVault in {
      // Initializes the vaultMapStore.
      TreeHashMap!("init", 2, *vaultMapStore) |

Linking is needed if our rholang is in the form of several files in our dev environment but should be bundled / linked for deployment.

Or some library management is in order in the case where there is no rho:lang:treeHashMap short-hand, to maintain a mapping of contracts to registry URIs.

[dckc]

@Bill-Kunj writes:

A better solution would be to solve the dependency (import/export in JS parlance) problems that are currently not solved in rholang

what do you think of my Sep 2020 proposal above? https://github.com/rchain-community/rgov/blob/master/CONTRIBUTING.md#contract-deployment-with-registry-uri-fixups https://github.com/rchain/rchip-proposals/issues/1#issuecomment-694330102

[Bill-Kunj]

@Bill-Kunj writes:

A better solution would be to solve the dependency (import/export in JS parlance) problems that are currently not solved in rholang

what do you think of my Sep 2020 proposal above? https://github.com/rchain-community/rgov/blob/master/CONTRIBUTING.md#contract-deployment-with-registry-uri-fixups #1 (comment)

This is fine, but it risks tying people into the javascript landscape because of the Jake dependency. And the management of URIs still needs to be solved.

Something more tightly bound to rholang source seems appropriate: Perhaps something like

new import(`contract.rho`) in {
  contract!()
}

With a preprocessor similar to https://github.com/rchain/rchain/tree/dev/rholang/examples/linking, contract.rho can be anywhere - perhaps on-chain in a map of filename-to-code, which would eliminate the need for managing URIs

[Bill-Kunj]

Hi @Bill-Kunj ,

TreeHashMap is already (1) on chain in full, and (2) in the registry. No linking is needed:

Yes, I'm aware that TreeHashMap is already a part of the core code. But, more generally, that magic identifier (TREE_HASH_MAP) can refer to anything. Which is what brings linking into the picture.

Linking is needed if our rholang is in the form of several files in our dev environment but should be bundled / linked for deployment.

Yep, and the URI management is a nightmare. What if we create a library solution that doesn't use URIs at all? What if an on-chain library contained capabilities that were addressable by filename?

Such a library is implemented in an RGOV branch https://github.com/rchain-community/rgov/tree/action-on-chain