# Clutch Specification

This is a brief document to delineate the specification of Clutch. The goal of Clutch is to enable application development using Lurk and its zero knowledge proof capabilities. Clutch incorporates elements of what has been previously caled "Meta-Lurk," as well as what is known as `fcomm` (functional commitments).

Clutch features an augmentation of Lurk's syntax so that claims, proofs, openings, and proof verification are first-class objects and operations, respectively (this is meta-lurk). It also features a REPL front-end and a (potentially git-like) backend so that untrusting parties can share proofs and verify them trustlessly.

### Timeline

TODO

## Syntax Augmentation

Clutch adds two objects and three functions to Lurk. The objects are:
- Claims
- Proofs

And the functions are:
- Verify
- Prove
- Open

### Objects

#### Claims
A `claim` either refers to a specific evaluation---which includes an input, output, status, and iterations---or an opening, which includes the functional commitment, input, output, and an optional updated functional commitment.
Claims can be proved via that `proof` function.

#### Proofs
A `proof` features *[TODO some proof data]*, and is connected to a `claim`. A proof can be verified to be correct via the `verify` function.

An `opening` features *[TODO some proof data]*, and links two functional commitments. An `opening` is also connected to a `claim`.

It is likely that both will be able to be expressed in an LDON format (Lurk data object notation).

### Functions

#### Verify
`Verify` can be applied to a proof, and returns a `bool`, where `nil` indicates the verification was false (but well-formed) and an error indicates that the proof was not well-formed.

#### Prove
`Prove` can be applied to a claim, evaluating to a proof object, which can be verified with the `verify` function.

#### Open
`Open` can be applied to a functional commitment, evaluating to an `opening` and a `claim`. The `claim` associated to the `opening` can be proved or disproved with the `prove` function.

### Stipulations

A few points:
- The `opening` and `claim` objects should be manipulable so that one can see (at least roughly) what their contents are, and also use them in Lurk expressions. We will likely not want to enable claim or proof literals, though it may be a good idea to provide an API for *creating claims* within meta-lurk expressions.
- In the syntax, there should be a clear delineation between what is purely Lurk (and thus proved) in an expression and what is not. This is important for the semantics of the `proof` object.
- Chained openings should likely be linkable in some way in how they're stored, and what they look like as LDON objects. It might be nice to be able to reason about the chain or access the chain (*e.g.* backtrace along the chain) in some way.
- We may explore some logical connectives on claims, such as `and` or `or`, which the `Prove` function can still operate on.

### What is Needed
To accomplish the above:
- [ ] Parser which can read meta-lurk expressions and properly evaluate them.
- [ ] Clear specification of LDON data types for `proofs` and `openings`.
- [ ] Complete specification of the `verify`, `prove`, and `open` functions, as well as a specification of any auxiliary functions for `claims` and `proofs` (e.g. some way to generate a claim).

## Network Backend

The goal is to be able to share claims and proofs in such a way that verification holds over the transfer.

TODO