|
| 1 | +This module provides the model used to do conformance testing of the Haskell |
| 2 | +implementation of the Ledger. |
| 3 | + |
| 4 | +The conformance model differs from the Conway specification in how deposits are |
| 5 | +stored in the Ledger state. |
| 6 | + |
| 7 | +In the Conway specification, deposits are stored in `LState.utxoSt.deposits`{.AgdaField}. |
| 8 | +The conformance model, on the other hand, separates deposits in three disjoint |
| 9 | +maps: |
| 10 | + |
| 11 | +* `LState.utxoSt.deposits`{.AgdaField} |
| 12 | +* `LState.certState.dState.deposits`{.AgdaField} |
| 13 | +* `LState.certState.gState.deposits`{.AgdaField} |
| 14 | + |
| 15 | +## Motivation |
| 16 | + |
| 17 | +The conformance model follows the way in which the Haskell implementation stores |
| 18 | +the deposits, which makes it possible to compare the behaviors of the conformance |
| 19 | +model and the implementation of the `UTXOS`{.AgdaDatatype} rule. |
| 20 | + |
| 21 | +The UTXOS rule transforms `UTxOState`s. While the specification updates the |
| 22 | +deposits in this rule, the implementation cannot do so because its input state |
| 23 | +does not contain the deposits in `DState` and `GState`. |
| 24 | + |
| 25 | +Other rules which use `UTXOS`{.AgdaDatatype} are in a similar predicament, |
| 26 | +namely `UTXO`{.AgdaDatatype} and `UTXOW`{.AgdaDatatype}. The |
| 27 | +`LEDGER`{.AgdaDatatype} rule, which uses `UTXOW`{.AgdaDatatype}, is the first |
| 28 | +rule where the implementation has all the state necessary to reconstruct the |
| 29 | +full deposits that the specification needs. |
| 30 | + |
| 31 | +## Guarantees |
| 32 | + |
| 33 | +Since we still want to check that the implementation behaves as the |
| 34 | +specification, there is a proof of the equivalence between the conformance model |
| 35 | +and the specification: |
| 36 | + |
| 37 | +* `Ledger.Conway.Conformance.Equivalence.bisimilarityProof`{.AgdaBound} |
| 38 | + |
| 39 | +## Alternatives |
| 40 | + |
| 41 | +Rather than providing a conformance model, we could have changed the Conway |
| 42 | +specification to match the implementation way of storing deposits. However, |
| 43 | +there are trade offs to consider. Putting the deposits together in one place |
| 44 | +makes some proofs simpler, while splitting them as in the implementation makes |
| 45 | +it more convenient to write the update functions for the separated pieces. |
| 46 | + |
| 47 | +While we could decide the tradeoff for a particular implementation, it would be |
| 48 | +difficult to adjust the specification when multiple implementations need to be |
| 49 | +accommodated. |
| 50 | + |
| 51 | +Yet another option could have been to skip testing specifically for the |
| 52 | +`UTXOS`{.AgdaDatatype} rule. This was a difficulty for testing, since spotting |
| 53 | +differences in a rule is harder when it is combined with other rules like the |
| 54 | +`LEDGER`{.AgdaDatatype} rule does. |
| 55 | + |
| 56 | +```agda |
| 57 | +{-# OPTIONS --safe #-} |
| 58 | +module Ledger.Conway.Conformance where |
| 59 | +
|
| 60 | +import Ledger.Conway.Conformance.Certs |
| 61 | +import Ledger.Conway.Conformance.Certs.Properties |
| 62 | +import Ledger.Conway.Conformance.Chain |
| 63 | +import Ledger.Conway.Conformance.Chain.Properties |
| 64 | +import Ledger.Conway.Conformance.Equivalence |
| 65 | +import Ledger.Conway.Conformance.Epoch |
| 66 | +import Ledger.Conway.Conformance.Epoch.Properties |
| 67 | +import Ledger.Conway.Conformance.Gov |
| 68 | +import Ledger.Conway.Conformance.Ledger |
| 69 | +import Ledger.Conway.Conformance.Ledger.Properties |
| 70 | +import Ledger.Conway.Conformance.Properties |
| 71 | +import Ledger.Conway.Conformance.Utxo |
| 72 | +import Ledger.Conway.Conformance.Utxo.Properties |
| 73 | +import Ledger.Conway.Conformance.Utxow |
| 74 | +import Ledger.Conway.Conformance.Utxow.Properties |
| 75 | +import Ledger.Conway.Conformance.Script |
| 76 | +``` |
0 commit comments