| # | Title | User Story | Importance | Notes | Ticket |
|---|
| 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.
| | Jira Legacy |
|---|
| showSummary | false |
|---|
| server | System JIRA |
|---|
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
|---|
| serverId | 50130123-f232-3df4-bccb-c16e7d83cd3e |
|---|
| key | RHOL-441 |
|---|
|
| Jira Legacy |
|---|
| showSummary | false |
|---|
| server | System JIRA |
|---|
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
|---|
| serverId | 50130123-f232-3df4-bccb-c16e7d83cd3e |
|---|
| key | CORE-994 |
|---|
|
| Jira Legacy |
|---|
| server | System JIRA |
|---|
| serverId | 50130123-f232-3df4-bccb-c16e7d83cd3e |
|---|
| key | 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: - 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.
|
|
| 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
|
|
| 78 | 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 |