Open faddat opened 3 years ago
Assume internal data structure have done a state transition, we should allow retrieval of value from previous blocks.
This would improve audibility when dapp rely on storage API to expose auditable data, config and events.
GET /database/get/{namespace}/{dbKey}?blockHeight=123412
Does this also makes sense for contract data record?
GET /contract/data/{contract}/{dbKey}?blockHeight=123412
What you propose here is a variant on my 2nd solution -- allow retrieval of historical state.
I was thinking of just returning the full historical state when a key is queried like:
GET /database/get/{namespace}/{dbKey}
Reasoning: in blockchain-land it is pretty common to return a bit too much, then truncate. Perhaps it's better to implement in this order:
FIRST Below should return full history:
GET /database/get/{namespace}/{dbKey}
SECOND Below should return state at a given block height:
GET /database/get/{namespace}/{dbKey}?blockHeight=123412
THIRD Below should return state, filtered or somesuch:
GET /database/get/{namespace}/{dbKey}?filter=something
The current problem is very specifically not one of mutability. All VSYS chain state is immutable.
It is a problem of apparent mutability
Below should return state at a given block height
Block height makes sense, ideally response header should include HTTP ETag with TX Hash as value.
This way, it would be able to utilise HTTP caching and Browser's conditional-get capability with CDN, browsers when value has not change.
This also provides a txid, if app wants to audit previous state they can pull block height from this tx.
I've heard that we're deprecating the DB API-- @ncying could you please confirm this?
If we are deprecating that, it's safe to close this issue.
Please note that this issue is titled apparent mutability. Database API contents are not actually mutable.
But to an outside observer, or any application calling that API, they will appear to be mutable, and state changes are not currently retrievable.
A private key or account holder can overwrite the contents of values for any key in the database API with any arbitrary content, and it is not possible to retrieve changes in state over time.
So, while historical state is stored in the blockchain, only the latest state can be retrieved.
This poses issues for:
Solutions:
OR