Section: Scientific Foundations
Keywords : proof certificates.
Proof structure and proof certificates
There has been a good deal of concern in the proof theory literature on the nature of proofs as objects. An example of such a concern is the question as to whether or not two proofs should be considered equal. Such considerations were largely of interest to philosophers and logicians. Computer scientists started to get involved with the structure of proofs more generally in essentially two ways. The first is the extraction of algorithms from constructive proofs. The second is the use of proof-like objects to help make theorem proving systems more sophisticated (proofs could be stored, edited, and replayed, for example).
It was not until the development of the topic of proof carrying code (PCC) that computer scientists from outside the theorem proving discipline took a particular interesting in having proofs as actual data structure within computations. In the PCC setting, proofs of safety properties need to be communicated from one host to another: the existence of the proof means that one does not need to trust the correctness of a piece of software (for example, that it is not a virus). Given this need to produce, communicate, and check proofs, the actual structure and nature of proofs-as-objects becomes increasingly important.
Often the term proof certificate (or just certificate ) is used to refer to some data structure that can be used to communicate a proof so that it can be checked. A number of proposals have been made for possible structure of such certificates: for examples, proof scripts in theorem provers such as Coq are frequently used. Other notions include oracle  and fixed points  .
The earliest papers on PCC made use of logic programming systems Twelf  and Prolog  . It seems that the setting of logic programming is a natural one for exploring the structure of proofs and the trade-offs between proof size and the need for run-time proof search. For example, there is a general trade-off between the size of a proof object and the amount of search one must do to verify that an object does, in fact, describe a proof. Exploring such trade-off should be easy and natural in the proof search setting where such search is automated. In particular, focused proof systems should be a large component of such an analysis.