Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement read set for composite key get_state #506

Open
bvavala opened this issue Dec 19, 2020 · 4 comments
Open

Implement read set for composite key get_state #506

bvavala opened this issue Dec 19, 2020 · 4 comments

Comments

@bvavala
Copy link
Contributor

bvavala commented Dec 19, 2020

Although reads and writes of composite keys are handled just like regular keys,
the get_public_state_by_partial_composite_key fetches a json blob with a set of kv pairs, which are unmarshalled and passed to the caller. As of #501 FPC does not keep track of this set in the rwset. Also the kv pairs cannot be simply put in the read set, because they are not the result of single reads.

Handling this properly requires to handle the RangeQueryInfo protobuf, include it in the rwset protobuf, and finally check and replay it at endorse time.

@g2flyer
Copy link
Contributor

g2flyer commented Dec 19, 2020

Do we really want to do this as part of MVP mileston? We don’t support composite keys in FPC lite security model? And even if we would decide to implement composite keys completely inside of stub via (de)multiplexing onto single external fabric key, the read-write set discussed in issue would essentially be irrelevant, as to untrusted side no composite query would happen?

I would assign this to rollback-protection extension so it is in same bucket as full-fpc stuff.
BTW: isn't this also really a special instance with more details of #446 (where i mentioned this and which is in rollback-protection milestone) and might be better merged into #446?
BTW(2): as implemented i thought it also is fail-safe that you abort? So it wouldn't really be a security issue (as the label would indicate) as-is in the code?

@bvavala
Copy link
Contributor Author

bvavala commented Dec 19, 2020

Do we really want to do this as part of MVP mileston? We don’t support composite keys in FPC lite security model? And even if we would decide to implement composite keys completely inside of stub via (de)multiplexing onto single external fabric key, the read-write set discussed in issue would essentially be irrelevant, as to untrusted side no composite query would happen?

I would assign this to rollback-protection extension so it is in same bucket as full-fpc stuff.
BTW: isn't this also really a special instance with more details of #446 (where i mentioned this and which is in rollback-protection milestone) and might be better merged into #446?
BTW(2): as implemented i thought it also is fail-safe that you abort? So it wouldn't really be a security issue (as the label would indicate) as-is in the code?

It is good simplification, there is some effort hidden in this.

But we should remove (or fail-safe) get_public_state_by_partial_composite_key and get_state_by_partial_composite_key from the shim, because they are there and used by the auction.

@g2flyer
Copy link
Contributor

g2flyer commented Dec 19, 2020

But we should remove (or fail-safe) get_public_state_by_partial_composite_key and get_state_by_partial_composite_key from the shim, because they are there and used by the auction.

Hmm, we discussed this in a meeting (see minutes from 2020-11-12) and decided we just document that these functions are not supported in fpc lite for which i then generate a corresponding pr #465 which updated shim.h?

@bvavala
Copy link
Contributor Author

bvavala commented Dec 19, 2020

Sounds good to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants