KIP 0028: Pact Verifier Plugins

[edmundnoble]

This is a proposal to add Verifier Plugins to Pact as a way to add new cryptography to Pact and integrate it with the capability paradigm. Implementation is at kadena-io/chainweb-node#1777 and kadena-io/pact#1324.

[jwiegley]

Excellent initial exposition, @edmundnoble, you've made the intent of the proposal very clear.

[CryptoPascal31]

Suggestion : The REPL simulation function (env-verfiers ) should be described (or at least mentioned) in the KIP.

Question 1: Is a managed cap automatically installed by a verfier (like it is with a signature) ?

Question 2: Does the magic triggered by GAS_PAYER cap works with verifier ? I mean, can we trigger a gas station from a verifier ?

Question 3: Do you plan to create a new type a guard that automatically enforce a verifier ? (similar to a keyset guard)

Question 4: Do you plan to add some doc for the verifiers (at least one short paragraph ) ? btw: it may answer to my question 1.

[edmundnoble]

@CryptoPascal31 thanks for the questions!

Suggestion : The REPL simulation function (env-verfiers) should be described (or at least mentioned) in the KIP.

Good idea, I'll add that. Edit: done.

Question 1: Is a managed cap automatically installed by a verfier (like it is with a signature) ?

Yes.

Question 2: Does the magic triggered by GAS_PAYER cap works with verifier ? I mean, can we trigger a gas station from a verifier ?

Not initially. This is mentioned in the KIP:

"A verifier may charge gas after gas is bought and before any transaction code is run. Because of this, currently, a verifier cannot grant the GAS_PAYER capability, which would allow paying for gas using a verifier’s attestation. This may change in the future."

Question 3: Do you plan to create a new type a guard that automatically enforce a verifier ? (similar to a keyset guard)

No plans to do this at the moment. I would recommend using a capability guard for this.

Question 4: Do you plan to add some doc for the verifiers (at least one short paragraph ) ? btw: it may answer to my question 1.

What exactly are you asking about documenting? The Pact code, chainweb code, this KIP, or something else? Or is there a particular workflow you're asking about documenting?

[CryptoPascal31]

Thank you for your answers @edmundnoble

Question 2: Does the magic triggered by GAS_PAYER cap works with verifier ? I mean, can we trigger a gas station from a verifier ?

Not initially. This is mentioned in the KIP:

"A verifier may charge gas after gas is bought and before any transaction code is run. Because of this, currently, a verifier cannot grant the GAS_PAYER capability, which would allow paying for gas using a verifier’s attestation. This may change in the future."

In fact, I was especially thinking about this:
kadena-io/chainweb-node#1702

I was wondering whether the "Allow" verifier could be an elegant solution for the suggestion I raised. Currently, a GAS_PAYER triggered gas station is not related to the signature, as it may not be related not to a verifier attestation. I know, I'm not clear..
But maybe you should take a quick look at the code (function findPayer of TransactionExec.hs . The code just searches for GAS_PAYER cap in the signatures and if found it calls the related module, to unlock the guard of the sender ... independently of who signed the cap... I mean, maybe it would be possible to search into the "verifiers caps" in addition to the "signatures caps".

Question 4: Do you plan to add some doc for the verifiers (at least one short paragraph ) ? btw: it may answer to my question 1.

What exactly are you asking about documenting? The Pact code, chainweb code, this KIP, or something else? Or is there a particular workflow you're asking about documenting?

I mean in the official Pact doc:
https://github.com/kadena-io/pact/blob/master/docs/en/pact-reference.md

There is a lot about caps, signatures, managed caps... I think the concept of verifiers should be explained here.

IMHO: new users are not supposed to know that the documentation is spread between the official doc and the KIPs.. I mean, users are not supposed to search into the KIP repository to understand the concept of a verifier.

[edmundnoble]

Thanks Pascal, I've submitted a document update request (kadena-community/kadena.js#1661), we'll have an update in the official docs page soonish, ideally by the release. Word from the Pact team is that we're trying to phase out the readthedocs website in favor of https://docs.kadena.io.

Re: findPayer, that makes sense to me though it seems a bit wasteful to use allow, because it does require that the proof match the cap. Let's continue that discussion on kadena-io/chainweb-node#1702.

[LindaOrtega]

Can we add here something along the lines of:

The verifiers field is in the command object in the same level as the payload, signers, nonce, fields.

[javadkh2]

Is the proof a string or JSON? Since the example is a string, but here it says JSON

[larskuhtz]

I think, that the proof string just be just binary. In the JSON body of the tx it would be encoded as base64url (without padding).

Proof strings messages from the outside world that don't have a meaning in Pact. We should constrain the content as little as possible. So plain bytes seem the right choice.

It is the job of the verifier to understand those plain bytes and relate them to the Pact semantics of the content of the clist.

[LindaOrtega]

Some (nit) wording and spacing suggestions.

Suggested change

	A transaction will be allowed include a list of verifiers, similarly to a list of signers, which for each used verifier will include the name of that verifier, the proof being passed to that verifier, and the capabilities it's being asked to grant. **Note that this means that the creator of a transaction must already know exactly what capabilities a proof grants, to include it into the capability list of a verifier.** This is essential for showing that the things a transaction is allowed to do are included verbatim in the transaction in a human-readable format.
	A transaction will be allowed to include a list of verifiers, similarly to how it includes a list of signers. Each verifier will include the name of that verifier, the proof being passed to that verifier, and the capabilities it's being asked to grant.
	**Note that this means that the creator of a transaction must already know exactly what capabilities a proof grants, to include it into the capability list of a verifier.**
	This is essential for showing that the things a transaction is allowed to do are included verbatim in the transaction in a human-readable format.

[LindaOrtega]

More nit suggestions:

• Some more wording suggestions
• And if it would be possible to add an example of what ZK in (enforce-verifier 'ZK) is referring to.

Suggested change

	In Pact versions above 4, a capability can require that it was signed for by a given keyset via `enforce-keyset`; analogously, a capability can require that it was granted by a particular verifier via the proposed built-in function `enforce-verifier`, for example `(enforce-verifier 'ZK)`.
	In versions above Pact 4, a capability can require that it was signed for by a given keyset via `enforce-keyset`; analogously, a capability can require that it was granted by a particular verifier via the proposed built-in function `enforce-verifier`. For example `(enforce-verifier 'ZK)`, where `'ZK` is `<todo>`.

[LindaOrtega]

Whats the connection between signers and verifiers field? Is it included here to show that both have similar type structures?

[larskuhtz]

Suggested change

	- an arbitrary JSON-encoded Pact value.
	- JSON string with the base64Url (without padding) encoded proof binary data.

Verifier plugins may require any kind of encoding as input -- so the only reasonable assumption we can make is that it is a byte array. base64 seems the most direct encoding of arbitrary data in JSON.

(The current proposal would mean in most cases to first encode the proof object into a pact string, e.g. using base64, and than escaping that Pact string and wrap it into JSON, just for the verifier to undo all of these steps again to retrieve the original content.)