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

Add block and index proofs [ECR-4011] #1355

Merged
merged 22 commits into from
Jan 17, 2020
Merged

Conversation

dmitry-timofeev
Copy link
Contributor

@dmitry-timofeev dmitry-timofeev commented Jan 10, 2020

Overview

Added block and index proofs support. They shall be created through Blockchain.

Documented the various proof types: what they prove, what comprises them, how to create them. Added an example for a commonly used proof type.

Also:

  • Made SignedMessage public to be able to use it in tests; got rid of redundant serialization in #parseFrom.
  • Added Block#parseFrom and Block#fromMessage.

See: ECR-4011


⚠️ There are some questions marked as TODO (@slowli , @bullet-tooth , @vitvakatu ).

Definition of Done

  • There are no TODOs left in the code
  • Change is covered by automated tests
  • The coding guidelines are followed
  • Public API has Javadoc
  • Method preconditions are checked and documented in the Javadoc of the method
  • Changelog is updated if needed (in case of notable or breaking changes)
  • The continuous integration build passes

Make SignedMessage public and prevent redundant
message serialization in #parseFrom.
Also, remove bad/redundant anchors.
Prevent redundant deserialization.
[skip ci]
*
* Link here with <a href="<relative path>/Blockchain.html#proofs">Blockchain Proofs</a>.
* See also: https://stackoverflow.com/a/27522316/ -->
* <h2 id="proofs">Proofs</h2>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ ECR-4106

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The documentation here looks good 👍

todo: Shall we allow creating proofs for invalid (e.g., impossible) index names or throw
an exception?

todo: If index proofs for "uninitialized" indexes are forbidden, document that.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The native will throw an exception, so I think we should document it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But

Why doesn't it return a proof of absence (no such index)? Especially as an index is not "initialized" unless (?) something is recorded in it? Doesn't that place extra burden on the service developers to "initialize" an index? Shall they now write an extra "initialize" method in a schema of each service (and we — document that)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I don't know. I read sources of proof_for_index method - it looks like explicit check for existence of the index can be removed, and the method will return proof of absence. @slowli am I right?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, if the check of existence is removed, proof_for_index may return proof of absence for a non-existing index. The reason the method is implemented as is currently is that returning proof for a non-existing index doesn't make sense in a typical use case (returning the index proof + proof for data within the index, such as proof for a wallet in the cryptocurrency service).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Would you clarify please, if one first requests a proof from an empty index (= no wallets), will it become "initialized"? Will one be able to provide then a proof that the index remains empty?

* @param height the height of the block
*/
static BlockProof createBlockProof(
/* todo: here snapshot is not strictly required — but shall we allow Forks (see the ticket) */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I couldn't find any use case for block proofs in execution context (where fork is available), so I propose to keep such restriction for now.

*
* <p>If an index does not exist in the database, then the MapProof will prove its absence.
*
* @see <a href="../Blockchain.html#service-data-proof">Service Data Proofs</a>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IDEA's quick documentation correctly opens the referenced javadoc, but doesn't recognize anchors. I think it's not the issue for changing links, just fyi

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! That's weird, it works in mine:

зображення

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't anchors work anywhere, even in Blockchain#callerrors?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeap, Blockchain#callerrors doesn't work as well 🤷‍♀️

image

* @see com.exonum.binding.core.blockchain.Block
*/
@AutoValue
public abstract class BlockProof {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is the reason to have this wrapper? Could we use Proofs.BlockProof directly (and index proof as well)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main reason is to have some flexibility to add operations if we release 1.0 without proof verifications. With a wrapper we can add extra operations on top of the proof data if they are needed (e.g., verification).

A side benefit — better documentation, but it can be achieved by other means.

@dmitry-timofeev dmitry-timofeev changed the base branch from new-protos-base to master January 16, 2020 11:32
@dmitry-timofeev
Copy link
Contributor Author

We briefly discussed Optional vs Exception in case of uninitialized indexes in createIndexProof with @vitvakatu , and decided to go with an Exception, because eventually we would like to have them all initialized automatically and not be a burden to service developers: ECR-4121.

@coveralls
Copy link

coveralls commented Jan 16, 2020

Coverage Status

Coverage decreased (-0.6%) to 85.705% when pulling 6fa70f3 on add-index-proof-ECR-4011 into bfc6cf7 on master.

* entire blockchain state and is recorded as such in {@linkplain Block#getStateHash() blocks}
* and Precommit messages.
*
* <p>Exonum starts aggregating a service collection state hash once it is <em>initialized</em>:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* <p>Exonum starts aggregating a service collection state hash once it is <em>initialized</em>:
* <p>Exonum starts aggregating a service collections state hash once it is <em>initialized</em>:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sentence says when Exonum starts aggregating one (any, a single) collection.

@dmitry-timofeev dmitry-timofeev merged commit ec6bed2 into master Jan 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants