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
Ed acks centralization risk around Infura. But indexing services are handy.
Ed: history looks challenging
e.g. how to do analog of eth_getBalance ?
Dan: yup. should be in our docs.
CB: the other bread-and-butter thing is submit transaction.
Dan: yup. (see RSign issue ###)
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?
DC: what to expose is a business decision. “None” is one option.
CB: revenue sharing is weighted toward those that handle the deploy.
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?
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.
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?
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?
JO: this seems like ethereum events… one approach is to just log info to a channel. Downside: it leaves junk on chain.
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)
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.
DC: there’s a whole set of accounting expectations… transaction ids…
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.
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:
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?