CapTP using RhoTypes.proto under Agoric @endo/marshal

[dckc]

@erights you expressed interest in the details when, after presenting marshal types and such, I said it's remarkable how much it looks like rholang.

Note the correspondence between marshal types and the rholang data structures in RhoTypes.proto (see also: cheat sheet, BNFC grammar):

@agoric/marshal	rholang
CopyArray	Elist
CopySet	ESet
CopyMap	EMap
CopyTagged	??
??	ETuple
??	Par
(pattern/matcher)	EMatches
boolean	g_bool
bignum@@	g_int
string	g_string
	g_uri
	g_byte_array
null	Nil	The Nil process is a Par with no sends, receives, etc.
undefined

• use CopyTagged for ETuple, (non-Nil) Par, g_uri, g_byte_array?
• for undefined, add a distinguished UnforgeableName to the RChain registry
  • using insertSigned so that the representation doesn't depend on the state of the registry.

I wonder about a Justin context with makeCopySet and such in scope, bound to Set. It would look even more like rholang.

A possible fun project:

• a suitable VatTP layer (#94)
• implement the above marshaling layer
• translate @agoric/captp to rholang using js2rho
  • built platform-specific parts that aren't suitable for this sort of translation

cc @Bill-Kunj , @jimscarver , @michaelfig

see also: OCapn
cc @cwebber

[dckc]

some type-directed prototyping: marshal-rhoproto.js

[dckc]

ordering?

rholang terms are totally ordered; that's too strong for remotables. plus I wonder if the arbitrary things like whether strings or numbers go first are consistent with compareKeys.

Here's hoping there are interesting interop targets that don't depend on the orders on both sides being exactly the same.

[dckc]

ag-solo as outboard IBC implementation for rnode

once we get rnode and ag-solo talking CapTP, rnode can talk IBC via ag-solo.

cosmos-testnet <-IBC-> ag-solo <-CapTP-> rnode

see also:

• remote channels and deploys for cross-shard interaction rchain/rchip-proposals#45
• RChain light client? Merkle tree to transactions? (IBC for RChain?) rchain/rchip-proposals#35

[tgrospic]

ordering?

rholang terms are totally ordered; that's too strong for remotables. plus I wonder if the arbitrary things like whether strings or numbers go first are consistent with compareKeys.

Here's hoping there are interesting interop targets that don't depend on the orders on both sides being exactly the same.

Rholang terms are normalized with total ordering so that they be hashed, but it's not required on the protocol level.

[dckc]

progress in office hours today:

• 2022-03-12 dan's office hours, agoric, capTP to rholang gateway - YouTube

https://github.com/rchain-community/js2rho/blob/captp/lib/capTPTool.js 331e08d

we saw in https://rhobot.net/rnode-log/ :

19:10:02.835 [�[34mINFO �[0;39m] [�[36mnode-runner-23      �[0;39m] [�[36mc.r.c.MultiParentCasperImpl  �[0;39m] - Received DeployData #1647112202396 -- {"type": "CTP_BOOTSTRAP", "epoch": 0, "questionID": "myid#1"}, Sig: 30440220603abc6545a6...20457cafead7228c134e, SigAlgorithm: secp256k1, ValidAfterBlockNumber: 146

cc @jimscarver

[dckc]

@Bill-Kunj I just found a smaller implementation of (some part of) CapTP: https://github.com/Agoric/agoric-sdk/blob/master/packages/solo/src/captp.js

https://github.com/Agoric/agoric-sdk/tree/b7c2a9b3205ccf348959cc22fc474f40137e416d

[dckc]

More progress today, with @David405 @jimscarver
cc @Bill-Kunj

• f6f90f7 * feat: send CapTP message in VatTP messaging layer

https://discord.com/channels/257555930173014017/687879575451336760/975035826067107900

~/projects/js2rho
11:24 connolly@jambox$ node lib/capTPTool.js 
TODO: start polling; call dispatch when a message is available
startTerm {
  deployRequest: {
    data: {
      term: '\n' +
        'new ack(`rho:rchain:deployId`), deployerId(`rho:rchain:deployerId`) in {\n' +
        '  match {[*deployerId, "3a240a220a2075a41673f53fb857d320099a088d796f2fc5a521c24db04f5c02c2864097f4d6"]} {\n' +
        '    {*target} => target!({"type": "CTP_BOOTSTRAP", "epoch": 0, "questionID": "myid#1"}, *ack)\n' +
        '  }\n' +
        '}',
      timestamp: 1652545499613,
      phloPrice: 1,
      phloLimit: 250000,
      validAfterBlockNumber: 158
    },
    sigAlgorithm: 'secp256k1',
    signature: '3045022100dabcdac473f2db8fc97cd21eeab45fefa7f03d13ccbd5e2fe718fff7dfadb68c02205fb1605685b7373974699211a31ffd72bdd88fc5ffa98255fbff8d824879d7aa',
    deployer: '04be064356846e36e485408df50b877dd99ba406d87208add4c92b3c7d4e4c663c2fbc6a1e6534c7e5c0aec00b26486fad1daf20079423b7c8ebffbbdff3682b58'
  }
}

new ack(`rho:rchain:deployId`), deployerId(`rho:rchain:deployerId`) in {
  match {[*deployerId, "3a240a220a2075a41673f53fb857d320099a088d796f2fc5a521c24db04f5c02c2864097f4d6"]} {
    {*target} => target!({"type": "CTP_BOOTSTRAP", "epoch": 0, "questionID": "myid#1"}, *ack)
  }
}