From reddid:

Thank you for the well thought-out response.

I was also thinking that the data would specify what to do with the multiple chains after the network heals. The multiple chains could label themselves and remain as separate, or a resolution system could happen.

Anyway, I was just hoping that someone would start thinking about how to make a system that offers both availability and consistency as needed because Tendermint looks cool and Casper looks like it'll be cool, but it'd be best if someone could find a protocol that can offer them both.

and

The first use case that came to mind is scaling: Data set to available can have very high write rates, while data set to consistent can be trusted to not fragment. We could have one token contract set to available, which is used to do high bandwidth trading, and another token contract set to consistent, which is used to settle those trades and reject double spends when they occur in the available contract.

I'm not sure if this is possible with CheckTx

and

Not yet, but imagine if the CheckTx message returned a flag that said whether it touched any "consistent" fields. If we returned this data to the RPC caller with "requires_consistency=true", the caller can just decide to submit the transaction for real and wait for it to be committed. Finally, we can expose an RPC endpoint that did this all automatically so it either returned the result of CheckTx or DeliverTx depending on what it touched in CheckTx.

Ref DeliverTx: https://github.com/tendermint/abci#delivertx
Ref CheckTx: https://github.com/tendermint/abci#checktx
Like that?

Data scaling: Allow data to set itself as either consistent or available #380

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions