Giters

virtualeconomy / v-systems

V Systems Reference Full Node

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Apparent Mutability of DB API contents

faddat opened this issue · comments

commented

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:

  • Contracts that store state in the db api
  • Applications that store state in the db api
  • Verification of contracts and applications that store state in the db api
  • Content (text) stored in the db api being treated as immutable

Solutions:

  • Each key can be assigned a value exactly once, at which point it can no longer be mutated (probably easier but not as featureful)

OR

  • Values can be mutated like now, but it is possible to retrieve historical state for values by querying their key.
commented

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
commented

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

Note

The current problem is very specifically not one of mutability. All VSYS chain state is immutable.

It is a problem of apparent mutability

commented

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.

commented

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.