|
| 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 | +* Datum properties encoded as class types |
| 13 | +* Common on-chain optimizations are performed if possible |
| 14 | + * Constraints normalization, and CSE |
| 15 | + * Best error short-cutting |
| 16 | + * Common security problems prevention |
| 17 | + |
| 18 | +## Potential obstacles |
| 19 | + |
| 20 | +* Ease and optimality of backend compilation |
| 21 | +* Robustness of SMT conversion and overall normalization |
| 22 | +* Possibility for parsing and correct offchain usage |
| 23 | +of almost-determinacy |
| 24 | +* Having enough information for Tx submit retrying strategies |
| 25 | +* Design for using custom Datum properties is not obvious |
| 26 | + |
| 27 | +# CEM machine design |
| 28 | + |
| 29 | +As it is done on top of constraints language, |
| 30 | +all their principles and obstacles are affecting CEM as well. |
| 31 | + |
| 32 | +## Principles |
| 33 | + |
| 34 | +* State-machine is deterministic modulo coin-change |
| 35 | + * Transaction can always be parsed back into SM transitions |
| 36 | + * Potential non-deterministic on-chain optimizations |
| 37 | + should not affect this principle. |
| 38 | + |
| 39 | +## Potential obstacles |
| 40 | + |
| 41 | +* Some scripts inexpressible by such model (as it happens in PAB) |
| 42 | +* Sub-optimal code from deterministic transitions model |
0 commit comments