Obtaining Data

1

Code Deployment

As a dApp developer, I get an answer back when the code is deployed if the code runs to completion, or an out of Phlo error

Must Have

• Users get an answer if the code has run out of Phlogiston.  Otherwise, the code is run. 

2

Transaction Receipts

As a dApp developer, when a deploy takes place with a name or set of names from my code api, I get to listen on the name for blocks. 

As a child shard, I need to listen for events taking place in the parent shard.

As a shard validator, I need to listen for events taking place in my shard so that the sharding client can create the correct events in the parent shard.

Must Have

• The full block will not be returned to the client, only the data pertaining to transactions with the name will be returned.

• There is no cost to obtain this data, as the transaction has already been paid for.

• The client that will get the data back will be a thin client.  Data will come in on a return channel. The thin client will need to persist that data locally for future reference.

• Blocks and their statuses that have the names.

• Returns blocks that are not finalized, blocks come back as soon as they are proposed.

• Can add a range of blocks to the request.

https://rchain.atlassian.net/browse/RHOL-441

https://rchain.atlassian.net/browse/CORE-994

https://rchain.atlassian.net/browse/RHOL-759

3

Exploratory Deployment

As a dApp developer, I want to learn about the state of specific processes.

 Must Have

• Same as normal code deployment but can use unforgeable names and you're guaranteed that the deployment will be rolled back.

• You have to know specific names in order to interact with them.

• This mechanism will be a deployment, and will likely cost less than other deployments.  The state won't be updated as a result.  The code will be rolled back. Payment will be made to a single node.  

• This query will not be on the blockchain.

• Uses the node's latest finalized state.

Option:

1. Expose the feature in the REPL

   1. Will need to be either a separate gRPC endpoint for a special flavor of the REPL

   2. Or an option on the Repl start.

2. Expose the code that Michael has authored.   @Medha Parlikar (Unlicensed) to ticket.  

   1. Wrap it up in a gRPC - would work like eval. 

   2. Need to update it to use the blockhash instead of the tuplespace hash.

   3. Include this in the front end application.

4

Streaming API

• Use a gRPC Proto to stream data off of the last finalized block.

• Provide some pretty printing in advance.

5

Full validation

As a dApp developer, I want all the block data for a shard.

Nice to have

• Run a full node, to obtain all the local block data.

6

Read Only Node

As a dApp developer, I want all the block data for a shard

Must Have

• Run a read only node, obtain all the block data locally.

Done.

7

Gossip all blocks

As a dApp developer, I want all the block data for a shard.

Nice to have

• Contact a validator, see if they will gossip their blocks to you for a fee

8

Harden against DOS

As a Node Operator, I want to know that my node cannot be subject to DOS attack via these API's

Must Have

• Implement something similar to HashCash, where the caller has to perform some work before calling the API.  

• Include the ability to turn up the difficulty/tune the difficulty depending on whether the network is being attacked.

• Reference: http://www.hashcash.org/papers/hashcash.pdf

Out of scope of the platform

Retrieve data asynchronously

As a mobile app developer, I need to send all my request asynchronously, so that my apps are fast.

Must Have

• The RSong demo requests the song, song metadata and song artwork asynchronously.  It's not clear to Medha if this is a hard requirement.  There isn't any reason why the song can't be requested first, followed by the metadata.

Monitor Requests for Data

As a validator, I need to know how much of my node's resources are spent on data access requests so that I can set the prices for transactions properly.

Must Have

• There has to be a dashboard that shows how many requests for data the node is servicing.  

• There should also be a dashboard that shows how much data is being returned in these requests. This metric can be in aggregate if needed.

Performance

In principle, A dApp developer will want to provide a user a transaction receipt with at least the same speed at which the transaction itself is processed.  

Must Have

• This means that half of the transaction processing time is in fact, in the retrieval of the transaction confirmation. 

Deployment ID

Each deployment has a userid and timestamp, userid (public key associated with private key used to sign transaction ) for that particular deployment by the client software.  These keys should be looked up in the block store.

Must Have

• Users need a way to retrieve transaction receipts for their deployments.