|
| 1 | +# Constraints design |
| 2 | + |
| 3 | +## Principles |
| 4 | + |
| 5 | +* Generic compilation across: on-chain code, |
| 6 | +offchain Tx construction and indexing backend |
| 7 | +* Simple normalization and SMT conversion for: |
| 8 | + * Equivalence checking |
| 9 | + * Bi-simulation checking |
| 10 | +* Constraints determine TxIn/Outs up to UTxO coin-selection |
| 11 | +(we call it almost-determinacy) |
| 12 | +@todo #3: wording for almost-determinacy |
| 13 | +* Datum properties encoded as class types |
| 14 | +* Common on-chain optimizations are perfomed if possible |
| 15 | + * Constraints normalization, and CSE |
| 16 | + * Best error short-cutting |
| 17 | + * Common security problems prevention |
| 18 | + |
| 19 | +## Potential obstacles |
| 20 | + |
| 21 | +* Ease and optimality of backend compilation |
| 22 | +* Robustnes of SMT conversion and overall normalization |
| 23 | +* Possibility for parsing and correct offchain usage |
| 24 | +of almost-determinacy |
| 25 | +* Having enough information for Tx submit retrying strategies |
| 26 | +* Desing for using custom Datum properties is not obvious |
| 27 | + |
| 28 | +# CEM machine design |
| 29 | + |
| 30 | +As it is done on top of constraints language, |
| 31 | +all their principles and obstacles are affecting CEM as well. |
| 32 | + |
| 33 | +## Principles |
| 34 | + |
| 35 | +* State-machine is deterministic modulo coin-change |
| 36 | + * Transaction can always be parsed back into SM transitions |
| 37 | + * Potential non-deterministic on-chain optimizations |
| 38 | + should not affect this principle. |
| 39 | + |
| 40 | +## Potential obstacles |
| 41 | + |
| 42 | +* Some scripts inexpressible by such model (as it happens in PAB) |
| 43 | +* Sub-optimal code from determenistic transitions model |
0 commit comments