change by consent / evolve over generations

[dckc]

one of the essential parts of the staking smart contract is the bit where it can be changed by consent. This reminds me of @leithaus saying we need to imitate living things - the contract needs to evolve over generations.

@leithaus , if you would sketch how to do this in Rholang, I'd appreciate it. Otherwise, I expect I / we can fumble through it.

cc @jimscarver

[jimscarver]

I presume is would be done the same way as ethereum controlled contracts where you can set the controller and use that for operations. e.g. minime token, uport (self sovereign id)

We need a simple proxy pattern to support revocable capabilities where the proxy can be set to point to Nil or some other capability using a control capability.

[dckc]

I presume is would be done the same way as ethereum controlled contracts

I doubt it; ethereum uses ACLs, not capabilities.

We need a simple proxy pattern to support revocable capabilities

exactly: https://github.com/rchain/rchain/blob/master/docs/rholang/rholangtut.md#revocation http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Computing#Revocable_Capabilities

aka the caretaker pattern

[jimscarver]

Yes, caretaker implies a revocable capability which we need but in order to evolve I think we need a replaceable implementation of the interface, e.g. a proxy consisting of a state map (instance) and contract (class) with a capability to change the contract. It is what I call "objects in the state of becoming".

[dckc]

Eventually we'll want a replaceable implementation. But the simplest way to start is to just make it so we can revoke it by consent and then start over.

We'll need it to give us back the unforgeable name associated with its rev vault.

[dckc]

https://gist.github.com/dckc/1af26f2f0e439d406e201d0427aed35c RevocableForwarderBuggy.rho

10:29:42.012 [node-runner-56] INFO  c.r.casper.MultiParentCasperImpl - New fork-choice tip is block dd57b6aae8....
{"MakeRevocableForwarder target" : Unforgeable(0x4372a17dfccd0de31ed48a8ff692a78cb26cb99462b5c457eb95e231326798ce)}
{"kill switch" : Unforgeable(0xd630d68d1c67e8b5dfffea93be52b60b33c7b8ca47957adbdbb568b466ff002f), "revokable" : Unforgeable(0xc1d6c405ea86b53729f2b97a33c9e0752f8654305bf5cab3355f11bbbf4036b5)}
{"MakeRevocableForwarder uri" : `rho:id:oys79hhqwb8ofdasr3eowyzd5mmwmfpnic4bbznaccjf8i5xqed9dp`}

discussion in #staking-pool-colab

[jimscarver]

we can have replaceable capabilities but how to get the consent of the governed in order to do that is at issue.

eval: new return(`rho:io:stdout`), // return(`rho:rchain:deployId`),
  insertArbitrary(`rho:registry:insertArbitrary`),   ReplaceableCapability in {
   new uriCh, valueCh in {
    insertArbitrary!(bundle+{*ReplaceableCapability}, *uriCh) |
    for (@uri <- uriCh) {
      return!(("#define $ReplaceableCapability", uri))
    }
  } |
 contract ReplaceableCapability(capability, ret) = {
  new capCh, current, replace in {
   capCh!(*capability) |
   contract current(arg) = {
    for ( curr <<- capCh ) {
     curr!(*arg)
   }}|
   contract replace(newcapability, ret) = {
    for ( curr <- capCh ) {
     capCh!(*newcapability) |
     ret!(*current)
   }}|
   ret!(*current,*replace)
 }} |
new stdout(`rho:io:stdout`), ret, kickme in {
 for (kick <- kickme) {
  stdout!(*kick ++ " kicked")
 }|
 ReplaceableCapability!(*stdout,*ret) |
 for ( thiscap, thisrep <- ret ) {
  thiscap!("hello world.") |
  thisrep!(*kickme, *ret)
}}}

[dckc]

... but how to get the consent of the governed in order to do that is at issue.

See Promise.all

[dckc]

@leithaus , if you would sketch how to do this in Rholang, I'd appreciate it. Otherwise, I expect I / we can fumble through it.

This presentation seems to have some relevant sketches:

• Biologically inspired consensus Apr 2018

[dckc]

WorkingGroup.rho is one governance mechanism for contract upgrade. https://github.com/rchain-community/liquid-democracy/pull/36