2018-11-15 Meeting notes: refine and confirm work needed for CORE-1162

Date

Nov 15, 2018, 16 Nov 2018

Attendees

• @Kelly Foster(regrets 16 Nov)

• @Former user (Deleted)

• @Dan Connolly

• @Former user (Deleted)

• @Chris Boscolo

• @Ned Robinson

• @Deanna Duke (regrets 16 Nov)

• @Former user (Deleted)

• @Paolo D'Onorio De Meo (regrets 16 Nov)

• @Patrick Udo Kraenzien

Goals

We will use this time to review the work specified in CORE-1162, discuss refinements, and set next steps.

Friday 16 Nov

Signing

CB: In #development chat with Birch: wallet stuff without signing over the return channel seems feasible. Not sure whether node 8 or node 9 or other.

insertSigned - none of the examples do a lookup on this. [Dan was supposed to look this up; hasn’t managed] CB is “happy” to follow up.

User stories from Ed Eykholt

1. Story: as an Ethereum developer familiar with Infura API, I want to learn and use RChain. Review the Infura API for APIs that the Ethereum dApp developers have relied on. How would an equivalent for each call be accomplished (if applicable) via gRPC? https://infura.io/docs

   1. Ed acks centralization risk around Infura. But indexing services are handy.

   2. Ed: history looks challenging

   3. e.g. how to do analog of eth_getBalance ?

      1. Dan: yup. should be in our docs.

   4. CB: the other bread-and-butter thing is submit transaction.

      1. Dan: yup. (see RSign issue ###)

      2. DC to prototype / document Alice sends 10 REV (that she held at genesis) to Bob

2. Story: as a dApp developer, I want to minimize round-trips to rNode to reduce latency and cost. Consider aggregating some functions, for example including doDeploy and CreateBlock.

3. Story: as a node validator, I want to expose to the internet only those methods needed for production dApps. Need to move some of the diagnostic like interfaces off of the external gRPC?

   1. DC: what to expose is a business decision. “None” is one option.

   2. CB: revenue sharing is weighted toward those that handle the deploy.

   3. DC: I see; we could factor/design gRPCs at ports around risks

4. We should discuss reference architectures for dApps. Jack Mill's work on using Envoy to expose http friendly GET/POST with json (instead of gRPC) seemed good, but didn't get traction. Where will reference architectures for dApps be documented?

   1. Joshy: I saw the demo; I think it’s been promoted less than using gRPC in js as in RChain-API, but only because of what I’m familiar with.

   2. Ed: yes, an explorer is part of expected ecosystem

5. Story: As a wallet application, I want to find the wallet contracts corresponding to my public address. Does the wallet need to know more than its public address to find the registry entries?

   1. DC: I hope insertSigned addresses this; I intend to confirm.

6. Story: As a wallet application, I want to query a wallet contract (or the blocks) for the history of all Rev transfers to/from it. Does each wallet contract need to maintain its own history, or how else would history maintained and for how long?

   1. JO: this seems like ethereum events… one approach is to just log info to a channel. Downside: it leaves junk on chain.

   2. e.g. baseball stats: each hit, out, strike… do we keep it pending at a channel forever? Alternatively, apps can query the blockchain (from outside rholang)

   3. DC: sigma / delta… sometimes rholang needs the delta (history) as well as the current state (sigma). But otherwise, delta can just be in the blockchain history.

   4. DC: there’s a whole set of accounting expectations… transaction ids…

Ned is also working on Mainnet Feature Requirements. https://docs.google.com/document/d/15wd8MpRwIzWEWjo0fDH9aAGCQZv9G_YlaVcbCQFbjP4/edit

udo: EVAL below

DC: got RHOL-752 gRPC “done” yesterday.

Discussion items