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)
@Joshy Orndorff
@Dan Connolly
@Ed Eykholt
@Chris Boscolo
@Ned Robinson
@Deanna Duke (regrets 16 Nov)
@Joshy Orndorff
@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

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
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.
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
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
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.
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

Item	Notes

Item	Notes
Resources	https://rchain.atlassian.net/browse/CORE-1162 Wallet contract https://github.com/rchain/rchain/blob/dev/casper/src/main/rholang/BasicWallet.rho Obtaining data https://rchain.atlassian.net/wiki/spaces/CORE/pages/492732472/Obtaining+Data
Get URIs back when creating registry entry	As a dApp developer who creates a smart contract that I would like to call multiple times, I register it in the registry. What I want get back is a URI in the deploy response as the end of the registration process. Today getting the URI requires scraping from the log or listening for it on name. Possible because gRPC was listening for the call. Originally intended for debugging. As a wallet application I need a way to recover my lost wallet Could be solved if I can predict an unforgeable name I want to pay Bob. I know his public key, but I don’t have the URI of his wallet. IDEA wallet URI is based on public key
Knowing unforgeable names Get IDs back with grpc response Docs for how IDs are calculated	Kyle’s RCon3 talk: https://www.youtube.com/watch?v=RtA6hMJUP8E&list=PLf2bbiic5ZjCt_HA_wJR6_EMpxIsiSaFK&index=9 I want to deploy a contract and pay for it. To do that I need to create a signature over an unforgeable name. I need to be able to predict the unforgeable name. Kyle says this is possible. IDEA is the solution to be able to generate unforgeable names offline? CONCERN redesigning the wallet system prior to Mercury is likely out of scope, so we do need way to generate and predict unforgeable names This covered in RHOL-752 NEED documentation for how unforgeable names are generated Current documentation not enough NEED Venus redesign the wallet CONCERN man in the middle attack - create an unforgeable name/URI offline and then deploy contract and start interacting with it, how do I know someone isn’t changing the facts in the middle or that someone else isn't interacting with the contract
Make local deploys and then roll them back for development or cost estimating What is short leash deployment? Not critical: gRPC call to shutdown node?
Get an ast/adt back instead of a string when doing tuplespace dump
Solution that generalizes these: Ethereum-style events A way to get stdout back in grpc response.	I want to record a log of my CryptoKitties given a range of blockheights. I want to listen on name given a certain depth I want to monitor a contract without operating a node or making a call to a node. I want to subscribe to events via a gRPC response. NEED subscription feature gRPC level subscribe feature is available, it needs to be implemented in RChain IDEA to refactor existing listen for data on name to serve this purpose since it’s pretty close do delivering the functionality Current architecture requires you to have nodes that look at the state (not validating nodes). Read only nodes do this at no cost to watch. Cost is to operate the node. IDEA some sort of channel where everything I send on the channel would return the results and deploy response. A function call.
Does end user need to enlist validator services?	Validators are incentivized to take deploys because deploys to collect transaction fees. pokt.network is building some infrastructure around this. JO: I met someone at SFBW. Their architecture is nicely decentralized but provides a service equivalent to Infura. Relationship was via Patrick, so I’m not sure of the status. Ned to check
Not critical: gRPC call to shutdown node? Would be nice for node-operator tools Nice for npm run fresh Is it possible to expose a deploy service without exposing the shutdown service?
Support binary files as part of deployments	CORE-1177 Support binary files as part of deployments IDEA hex to bytes computation CONCERN payment requirement for converting hex to bytes. RSong does this
Reference idea	Need a reference for gRPC calls and a description of what they do IDEA take .proto file and publish as HTML CONCERN .proto file is not particularly readable. Publishing this for dApp developers with refinements would be helpful. EXAMPLE listen for data response needs to be parsed, and it’s unclear how to parse based on available documentation RECOMMENDATION collect a list of what people want to do, to inform the documentation created MVP a list of available gRPC calls in HTML with examples
EVAL	Needs for rchain.cloud Use case - we want to deploy a contract and get a return of the evaluation via 1 gRPC call Needs Storage content STDOUT via gRPC call STDOUT is for printing not a gRPC call What the node evaluated (send back what was sent) - used for debugging Discussion to confirm EVAL operates separately from Casper https://rchain.atlassian.net/browse/CORE-879?jql=text ~ "captureresults" CB: captureResults isn’t quite right; I’m willing to discuss further with a developer
Questions for later	How do you ask questions of the blockchain? Listen for data at name Spelunking through the blockchain If you want to ask the current value of data in a wallet, how can you it if it requires Rholang?
Next steps	Decision to meet again on Nov. 16 at 16:00 UTC. @Dan Connolly to host and facilitate. Everyone, please add to this document use cases and questions you’d like to discuss tomorrow.

Action items

@Dan Connolly research if the public key is all you need to find URI connected to wallet (insertSigned)

@Dan Connolly create ticket for subscription feature or work to refine listen on name to be a subscription - RHOL-1066 subscribe at name via gRPC

@Joshy Orndorff file a bug related to listen on name at depth https://rchain.atlassian.net/browse/CORE-1440

@Dan Connolly please ticket gRPC calls documentation : RHOL-1065 gRPC calls reference documentation

@Dan Connolly to prototype / document Alice sends 10 REV (that she held at genesis) to Bob along with “what’s my balance?” CORE-1466 Alice pays Bob 10 REV

@Ned Robinson to check with pokt.network about their service on RChain

@Chris Boscolo to walk Dan thru the captureResults code and concerns related to CORE-879 captureResults via gRPC

RChain wiki