As an API client, I want to verify that the response from a server is verifiable proof

[hansl]

Description

We need a verifiable proof specification (and implementation). It needs to be at least compatible with our current storage using in many-framework (ie. merk), but also extensible in the future with other storage or proofs.

Concerns

The spec should also account for different hashing algorithms and tree structures, allowing design space later on in the future. These algorithms may be implementation-specific or design choices.

For example, the current storage implementation in the framework is merk, which uses in its current version blake3. The latest nomic-io/merk repo uses SHA256 instead. If we were to upgrade our own fork with the latest changes,

Also, hashing is broken every decade or two after being released. It's not improbable that SHA256 will be easy enough to break in the next decade, and networks might want to switch to SHA512. This is just foresight for this and allowing the current spec to move along with technological advances.

Technical Design

The current design uses one network attribute and one request and one response attribute. The network attribute indicates support for asking and generating proofs and also (with an argument) which algorithm can be used to validate said proof. The request and response attributes contain a request for proof and the proof itself in the response.

Requesting proof on a network that does not support it MUST result in an error.

Acceptance Criterion

One should be able to call an endpoint via the CLI in a way that the proper request message attribute (3) is supplied, and receive a response message contains the corresponding response message attribute (3), along with the proof requested. The proof, after deserialization, should take the form indicated in the spec.

Planning Notes:

• Includes everything up to the migration.

[tysloan]

Stories should be created to resolve implementations that are not compliant with the spec.

[MavenRain]

liftedinit/many-rs#245

[MavenRain]

The following are follow-up items to be completed after the core implementation is merged and this item is closed:

• Current hash scheme has security vulnerability many-rs#308
• Problem adding Context context parameter to idstore and event endpoints many-rs#300
• Prove Verification in CLI many-rs#299
• Discover a way to move proof key calculation into background/uniform process many-rs#301