## Section: Application Domains

### Implementing trusted proof checkers

Traditionally, theorem provers—whether interactive or automatic—are usually monolithic: if any part of a formal development was to be done in a particular theorem prover, then all parts of it would need to be done in that prover. Increasingly, however, formal systems are being developed to integrate the results returned from several, independent and high-performing, specialized provers: see, for example, the integration of Isabelle with an SMT solver [51] as well as the Why3 and ESC/Java systems.

Within the Parsifal team, we have been working on foundational aspects of this problem of integrating different provers. As we have described above, we have been developing a formal framework for defining the semantics of proof evidence. We have also been working on building prototype checkers of proof evidence which are capable to executing such formal definitions. The proof definition language described in the papers [47] , [46] is currently given an implementation in the $\lambda $Prolog programming language [69] . This initial implementation will be able to serve as a “reference” proof checker: others developing proof evidence definitions will be able to use this reference checker to make sure that they are getting their definitions to do what they expect.

Using $\lambda $Prolog as an implementation language has both good and bad points. The good points are that it is rather simple to confirm that the checker is, in fact, sound. The language also supports a rich set of abstracts which make it impossible to interfere with the code of the checker (no injection attacks are possible). On the negative side, however, the performance of our $\lambda $Prolog interpreters is lower than specially written checkers and kernels.