package octez-protocol-017-PtNairob-libs
Install
Dune Dependency
Authors
Maintainers
Sources
sha256=c6df840ebbf115e454db949028c595bec558a59a66cade73b52a6d099d6fa4d4
sha512=d8aee903b9fe130d73176bc8ec38b78c9ff65317da3cb4f3415f09af0c625b4384e7498201fdb61aa39086a7d5d409d0ab3423f9bc3ab989a680cf444a79bc13
doc/octez-protocol-017-PtNairob-libs.test-helpers/Tezos_017_PtNairob_test_helpers/Liquidity_baking_generator/index.html
Module Tezos_017_PtNairob_test_helpers.Liquidity_baking_generatorSource
This module provides a set of abstractions to reason about the so-called “liquidity baking” feature1.
1: https://gitlab.com/tezos/tzip/-/blob/367628e1a576c3926bedc1d6107b2945607c2605/drafts/current/draft-liquidity_baking.md
We remind that this feature is built upon three smart contracts: (1) a CPMM contract initially based on Dexter 2, and (2) two tokens contracts.
Our purpose for Liquidity Baking is to easily express and test invariants regarding the execution of these contracts. To that end, we have introduced a set of dedicated types to describe arbitrary contexts in terms of account balances (see Liquidity_baking_machine.specs), along with build functions that turn a description of a context into concrete states.
In this module, we provide QCheck2 generators which allow to construct arbitrary specifications for states, and so-called scenarios (i.e., sequences of entrypoint calls).
val gen_specs :
Liquidity_baking_machine.tzbtc ->
Liquidity_baking_machine.liquidity ->
Liquidity_baking_machine.specs QCheck2.Gen.tgen_specs max_tzbtc max_liquidity constructs arbitrary Liquidity Baking specs for an initial state, where at most max_tzbtc and max_liquidity are shared among an arbitrary number of implicit accounts.
val gen_scenario :
Liquidity_baking_machine.tzbtc ->
Liquidity_baking_machine.liquidity ->
int ->
(Liquidity_baking_machine.specs
* Liquidity_baking_machine.contract_id Liquidity_baking_machine.step list)
QCheck2.Gen.tgen_scenario max_tzbtc max_liquidity size constructs arbitrary Liquidity Baking specs with a semantics similar to gen_specs, along with sequences of valid scenarios (i.e., sequences of entrypoint calls) of length size. By valid, we mean that running the scenario using a Liquidity baking machine initialized with the specs should succeed.
val print_scenario :
(Liquidity_baking_machine.specs
* Liquidity_baking_machine.contract_id Liquidity_baking_machine.step list) ->
stringprint_scenario scenario produces a string representation of scenario, as produced by gen_scenario.
val gen_adversary_scenario :
Liquidity_baking_machine.tzbtc ->
Liquidity_baking_machine.liquidity ->
int ->
(Liquidity_baking_machine.specs
* Liquidity_baking_machine.contract_id
* Liquidity_baking_machine.contract_id Liquidity_baking_machine.step list)
QCheck2.Gen.tgen_adversary_scenario max_tzbtc max_liquidity size constructs arbitrary scenarios that can be used to challenge the “no global gain” property of Liquidity Baking.
The key idea of this property is the following: a given contract cannot profit from Liquidity Baking if they are the only one to interact with the CPMM (in the absence of subsidies). The scenario generated by gen_adversary_scenario only consists in step performed by one contract. This contract is identified by the contract_id returned by this function.
val print_adversary_scenario :
(Liquidity_baking_machine.specs
* Liquidity_baking_machine.contract_id
* Liquidity_baking_machine.contract_id Liquidity_baking_machine.step list) ->
stringprint_adversary_scenario scenario produces a string representation of scenario, as produced by gen_adversary_scenario.