Obtaining Data

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

• 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-441 - Getting issue details... STATUS

CORE-994 - Getting issue details... STATUS

RHOL-759 - Getting issue details... STATUS

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

• Use a gRPC Proto to stream data off of the last finalized block.
• Provide some pretty printing in advance.

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

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

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

• 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

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

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

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

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