remote channels and deploys for cross-shard interaction

[jimscarver]

Introduction/Motivation/Abstract

In order for networks to be fully connected networks acting as a single network, any part of any of the connected network must be reachable from any other. The success of WWW is in part due to being able to use url's to anywhere on the web anywhere. There are good arguments that rchain networks should be fully connected with homogeneous access to resources. Programming concepts does not require knowledge of the location of the parameters if it is to be reusable as a concept such that it needs to be programmed only once, it must work no matter where on the network the resources it references are located.. Rholang is perfect for doing decentralized computing across shards given access to remote channels.

In order to be fully connected remote names need to be supported transparently as do remote deploys.

A remote deploy would need to translate local names to remote names and the receiving shard would translate remote name pointing to it to local mames.

In order to deploy remotely, the rev account deploying remotely must own the rev of the receiving shard on that shard or be allowed sponsored access.

A capability transport (capTP) protocol may be used to implement security across shards..

The results of remote deploys need to be cached in tuple space such that the result of the deploy will be the same for every validator the same remote deploy without redundant execution on the remote shard. A means of inquiring the finalization status of the remote block containing the deploy ought be provided for critical transactions.

Remote names may be implemented as proxy channels transparently forwarding the entire message, e.g. (first, ...rest) to the remote deploy process., Rchain needs proxy channel monitor support for many reifications, e.g. decorator patterns, revocable capabilities and tokenization. Using proxies enables all the sharding logic being used to be in rholang and thus customizable per shard..

Names and even whole processes could be migrated across shards to minimise cross shard access in an evolutionary manner.

Motivating Examples

In the EIES effort including Jim, Rao, kunj, GSJ and w2vy a decentralized object store was developed supporting remote objects transparently across the network of user agents and group agents which successfully supported the virtual classroom and other group system research at NJIT. Unfortunately we have been unable to get it open sourced. However Rchain provides layer one security our system never had. A number of us are here because we see rchain as a potential platform for developing agents for users and groups scalably as we have done before. However reviewing the documentation available on rchain sharding we have not found a design including the transparent decentralization we had on EIES2 at NJIT where the programmer was not required to know the location of any the objects it uses at run time. Without that capability developing a coherent networked system can be a nightmare.

Examples

Comparison Examples

Counter-Examples

Design

Counter-Examples

Drawbacks

Programmers being unaware of which names it accesses are remote could lead to a excess of network traffic. They need to be aware that not considering what is likely to be remote could be expensive.

Alternatives

References

09:51:05 From Rao Bhamidipati to Everyone : @ian could you please give me recording permission ?
10:47:23 From Tomislav Grospić to Everyone : https://rchain.atlassian.net/wiki/spaces/CORE/pages/515899462/Sharding+proposal
11:00:59 From Tomislav Grospić to Everyone : Obsolete
https://rchain.atlassian.net/wiki/spaces/CORE/pages/298549249/Sharding+Via+Localized+Processes
11:01:08 From Tomislav Grospić to Everyone : https://rchain.atlassian.net/wiki/spaces/CORE/pages/478445641/Shards+in+RChain
11:01:14 From Tomislav Grospić to Everyone : https://rchain.atlassian.net/wiki/spaces/CORE/pages/311722016/Powerset+shards
11:02:25 From Tomislav Grospić to Everyone : ETH cross shards
https://ethresear.ch/t/atomic-cross-shard-function-calls-using-system-events-live-parameter-checking-contract-locking/7114

Higher-order Smart Contracts across Chains - Mark Miller https://www.youtube.com/watch?v=iyuo0ymTt4g

dan's saturday RChain Rgov/smart contract call - dan's wisdom, ocap, capTP, erights and cross chain transactions https://youtu.be/OrEZzF2t8Uk?t=4458

[dckc]

A capability transport (capTP) protocol may be used to implement security across shards..

IBC (#35 ) provides a substrate for this.

[dckc]

We didn't get to it today, @jimscarver , but one concise presentation of CapTP: The 4 Tables is in:

• Agoric + Protocol Labs // Part 3 - Distributed Secure Cross-chain Messages - Mark Miller

There's another more thorough presentation somewhere that I can find if you like, but maybe this one will help.