- Provide mechanisms for users to obtain data from the Blockchain
Background and strategic fit
Both users and dApp Developers will want block data pertaining to their transactions and dApps
- This class of users do not want to run a validating node. They do not want to put up stake in the network.
- This class of users wants to run a distributed application, and obtain data from the application, so they can run analytics and mine the data from the blockchain.
|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.
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.
- 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.
RHOL-441Getting issue details...
CORE-994Getting issue details...
RHOL-759Getting issue details...
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.
- Expose the feature in the REPL
- Will need to be either a separate gRPC endpoint for a special flavor of the REPL
- Or an option on the Repl start.
- Expose the code that Michael has authored. Medha Parlikar (Unlicensed) to ticket.
- Wrap it up in a gRPC - would work like eval.
- Need to update it to use the blockhash instead of the tuplespace hash.
- Include this in the front end application.
- 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.
|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|
User interaction and design
Will need to include the API design for retrieving data.
Here's an example of some JS code that uses Rchain-API to query for results: https://gist.github.com/JoshOrndorff/b0fe7aed93d16beabc2885484c6e8c54
|1||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.
|2||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.
|3||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.
Each deployment has a userid and timestamp, for that particular deployment by the client software. These keys should be looked up in the block store.
- Users need a way to retrieve transaction receipts for their deployments.