diff --git a/README.md b/README.md index 1a61e5b5c5a555c4f3a040af5f56ed09703f0e01..e40130bb607cf4802ef0d25527a496595e77b813 100644 --- a/README.md +++ b/README.md @@ -18,7 +18,7 @@ available at https://tezos.gitlab.io/. ## The Tezos software This repository hosts **Octez**, an implementation of the Tezos blockchain. -**Octez** provides a node, a client, a baker, an endorser, an accuser, and other tools, distributed with the Tezos economic protocols of Mainnet for convenience. +Octez provides a node, a client, a baker, an accuser, and other tools, distributed with the Tezos economic protocols of Mainnet for convenience. In more detail, this git repository contains: - the source code, in directory src/ diff --git a/docs/Makefile b/docs/Makefile index 49fc830233dbb486fda292f2de2b90fd5db52186..a34fb10d2a7d80f4cf021fa1accac24306ff2aaa 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -1,3 +1,5 @@ +# TODO #2170: search for old/preceding protocol name AND number, and adapt + # You can set these variables from the command line. SPHINXOPTS = -j auto -aE -n -W --keep-going SPHINXBUILD = poetry run sphinx-build @@ -71,7 +73,7 @@ odoc-lite: docexes rm -rf $(TMPDOCDIR)/ mkdir -p $(TMPDOCDIR)/ rsync --recursive --links --perms \ - --include="src/proto_014*" --include="src/proto_015*" \ + --include="src/proto_015*" --include="src/proto_016*" \ --exclude="src/proto_0*" \ ../src ../tezt ../vendors ../dune ../dune-project $(TMPDOCDIR)/ # FIXME: https://gitlab.com/tezos/tezos/-/issues/2971 diff --git a/docs/README.rst b/docs/README.rst index 8ee14ff16e40524154519071cec8cf2c651b0c17..56bfb4b8e7093d3a3c5cc020125972a6faf1d8a2 100644 --- a/docs/README.rst +++ b/docs/README.rst @@ -36,8 +36,13 @@ To build the documentation locally, you need to install the Python package manager `Poetry `_. For instructions on how to obtain Python and Poetry, see :doc:`the installation instructions for the python testing -framework`. Once this is done, you can -do: +framework`. + +Another pre-requisite for building the documentation is making sure that the Octez sources on your branch are compiled, because part of the documentation is generated by Octez executables. +This involves executing ``make`` in the parent directory (the repository root). +If this step results in errors, you usually have to restart the :ref:`compiling procedure ` from ``make clean`` onwards. + +Once this is done, you can do: .. code-block:: bash diff --git a/docs/alpha/consensus.rst b/docs/alpha/consensus.rst index 795c312eaa5e97a995dcf1f064620155491bd4c3..629f1ab4f459d1c3b8043b5f57f6f2bb6f233202 100644 --- a/docs/alpha/consensus.rst +++ b/docs/alpha/consensus.rst @@ -149,7 +149,7 @@ balance*. Let us first (re)define these and related concepts. - The *(maximal) staking balance* of a delegate is its full balance (i.e. all the tokens owned by the delegate) plus the balances of all accounts that have delegated to it. - It must be at least ``TOKENS_PER_ROLL`` tez, otherwise the delegate cannot be selected as a validator. + It must be at least ``MINIMAL_STAKE`` tez, otherwise the delegate cannot be selected as a validator. - The *active stake* of a delegate is the amount of tez with which it participates in consensus. It is at most its staking balance. We explain below how it is computed. diff --git a/docs/alpha/liquidity_baking.rst b/docs/alpha/liquidity_baking.rst index 6685c0fe8c8ae2a964447140816a6ef45fee23b4..be16b56338d8689807b0dc5ef1217eb32ab7939c 100644 --- a/docs/alpha/liquidity_baking.rst +++ b/docs/alpha/liquidity_baking.rst @@ -10,7 +10,7 @@ During activation of Granada protocol, a constant product market making (CPMM) M .. warning:: - while the CPMM and LQT contract originations provide an ``Origination_result``, the LQT contract contains two big maps not included in a `lazy_storage_diff` field. Indexers and other tooling may need manual updates to include these. + While the CPMM and LQT contract originations provide an ``Origination_result``, the LQT contract contains two big maps not included in a `lazy_storage_diff` field. Indexers and other tooling may need manual updates to include these. The CPMM maintains a balance of ``a`` tez and ``b`` `tzBTC `_, where tzBTC is the `FA1.2 token `_ found at address ``KT1PWx2mnDueood7fEmfbBDKx1D9BAnnXitn``. The smart contract accepts deposits of ``da`` tez and returns ``db`` tzBTC (or vice versa) where the invariant ``(a + da * (1 - f - n)) * (b - db) = a b`` is preserved, and ``f`` and ``n`` are a fee and burn, set at 0.1% each. Calculations are done with precision of 1000, rounding down on division. @@ -46,7 +46,7 @@ the subsidy, and ``Pass`` to abstain. ``e[n+1] = e[n]`` if the flag is set to ``Pass``. ``e[n+1] = (1999 * e[n] // 2000) + 1_000_000`` if the flag is set to ``Off``. ``e[n+1] = (1999 * e[n] // 2000)`` if the flag is set to ``On``. -When computing ``e[n+1]``, the division is rounded toward ``1_000_000_000```. +When computing ``e[n+1]``, the division is rounded toward ``1_000_000_000``. If at any block ``e[n] >= 1_000_000_000`` then it means that an exponential moving average with a window size on the order of two diff --git a/docs/alpha/proof_of_stake.rst b/docs/alpha/proof_of_stake.rst index 5c48e204f94393853cb4ababdc2530390e3c8e6f..1dc55ebe1b99763b2de5c235ca02a046d2c2b891 100644 --- a/docs/alpha/proof_of_stake.rst +++ b/docs/alpha/proof_of_stake.rst @@ -45,7 +45,7 @@ proportional to their *delegated stake* -- that is, the balance of all the accounts that delegate to it, including the balance of the delegate itself. To participate in consensus or in governance, a delegate needs to have at least a minimal stake, which is given by the -``TOKENS_PER_ROLL`` :ref:`protocol constant +``MINIMAL_STAKE`` :ref:`protocol constant `. Delegates place security deposits that may be forfeited in case they do not @@ -115,7 +115,7 @@ At the end of cycle ``n-1-PRESERVED_CYCLES``, the snapshot for cycle PRNG having as seed the :ref:`random seed` for cycle ``n``. -Only the stake of active delegates with the minimal stake of ``TOKENS_PER_ROLL`` is snapshot. +Only the stake of active delegates with the minimal stake of ``MINIMAL_STAKE`` is snapshot. .. _rights_alpha: @@ -164,7 +164,7 @@ Proof-of-stake parameters - 16384 blocks * - ``PRESERVED_CYCLES`` - 5 cycles - * - ``TOKENS_PER_ROLL`` + * - ``MINIMAL_STAKE`` - 6,000 ꜩ * - ``BLOCKS_PER_STAKE_SNAPSHOT`` - 1024 blocks diff --git a/docs/alpha/smart_rollups.rst b/docs/alpha/smart_rollups.rst index b63479931e2aaf18e424d4061e81b13c2bc03052..6d82c7ce6dd55bd0a6fe1a05cbc1532f5fdf44b2 100644 --- a/docs/alpha/smart_rollups.rst +++ b/docs/alpha/smart_rollups.rst @@ -694,7 +694,7 @@ the next inbox are being loaded. The inputs that were not consumed by kernel from yielding by writing arbitrary data under the path ``/kernel/env/reboot`` in its durable storage. In such a case (known as reboot), ``kernel_run`` is called again, without dropping unread -inputs. This value is removed between each call of ``kernel_run``, +inputs. The value at ``/kernel/env/reboot`` is removed between each call of ``kernel_run``, and the ``kernel_run`` function can postpone yielding at most 1,000 reboots for each Tezos level. @@ -1271,7 +1271,7 @@ Glossary #. **Refutation period**: At the end of each commitment period, a period of two weeks starts to allow any commitment related to - this commitment period to be published. + this commitment period to be challenged. #. **Staker**: An implicit account that has made a deposit on a commitment. diff --git a/docs/alpha/token_management.rst b/docs/alpha/token_management.rst index 4f6348b439732469b7be1530b6a5fdbccf66ed2c..c6f73a6539ff7839761aa61f1239c9b29dfec486 100644 --- a/docs/alpha/token_management.rst +++ b/docs/alpha/token_management.rst @@ -6,7 +6,7 @@ This page describes the reporting of tokens transfers in block metadata, as a se Overview ~~~~~~~~ -Minting, transferring or burning tokens is handled by the `Token `_ module. +Minting, transferring or burning tokens is handled by the :package-api:`Token ` module. The module provides functions (``Token.transfer`` and ``Token.transfer_n``) to transfer tokens from one, respectively from more accounts, to another account. Balance updates found in block metadata are generated by these functions as a trace of the token movements having taken place. @@ -203,4 +203,3 @@ For example, for an amount of ``100`` mutez in rewards not distributed due to in "change": "100", ...} ] Double signing evidence rewards and nonce revelation rewards are analogous to endorsing rewards, except that the source accounts used are ``"double signing evidence rewards"`` and ``"nonce revelation rewards"``. - diff --git a/docs/alpha/validation.rst b/docs/alpha/validation.rst index 0d11724be1f29f1e01385c02abbeae409ba6ea6f..be828c88c56f1b724b437b132913b47e77f17989 100644 --- a/docs/alpha/validation.rst +++ b/docs/alpha/validation.rst @@ -53,8 +53,8 @@ state-passing machine where: .. TODO #4155: When creating a new environment, update references to V in the - paragraph below. - + paragraph below (only in the doc for Alpha!). + However, the *concrete* API exported from the Tezos economic protocol does not implement this business logic *monolithically*, as described above, but it rather presents a more fine-grained API. The rationale diff --git a/docs/lima/consensus.rst b/docs/lima/consensus.rst index 5a04bbf7267f4866dd9df64ec130e29fba83fd09..25c6a6050c4ef1dba62fd381de39415a8d8c617c 100644 --- a/docs/lima/consensus.rst +++ b/docs/lima/consensus.rst @@ -154,7 +154,7 @@ balance*. Let us first (re)define these and related concepts. - The *(maximal) staking balance* of a delegate is its full balance (i.e. all the tokens owned by the delegate) plus the balances of all accounts that have delegated to it. - It must be at least ``TOKENS_PER_ROLL`` tez, otherwise the delegate cannot be selected as a validator. + It must be at least ``MINIMAL_STAKE`` tez, otherwise the delegate cannot be selected as a validator. - The *active stake* of a delegate is the amount of tez with which it participates in consensus. It is at most its staking balance. We explain below how it is computed. diff --git a/docs/lima/proof_of_stake.rst b/docs/lima/proof_of_stake.rst index 9b591c034370bbff79f7ec647831c3261701252c..9c53ad9097d91a6c90dfec8e55d84502c3019d3c 100644 --- a/docs/lima/proof_of_stake.rst +++ b/docs/lima/proof_of_stake.rst @@ -42,7 +42,7 @@ proportional with their delegated stake, which includes the balances of all the accounts that delegate to it, and also the balance of the delegate itself. To participate in consensus or in governance, a delegate needs to have at least a minimal stake, which is given by the -``TOKENS_PER_ROLL`` :ref:`protocol constant +``MINIMAL_STAKE`` :ref:`protocol constant `. Delegates place security deposits that may be forfeited in case they do not @@ -105,7 +105,7 @@ At the end of cycle ``n-1-PRESERVED_CYCLES``, the snapshot for cycle PRNG having as seed the :ref:`random seed` for cycle ``n``. -Only the stake of active delegates with the minimal stake of ``TOKENS_PER_ROLL`` is snapshot. +Only the stake of active delegates with the minimal stake of ``MINIMAL_STAKE`` is snapshot. .. _rights: .. _rights_lima: @@ -155,7 +155,7 @@ Proof-of-stake parameters - 8192 blocks * - ``PRESERVED_CYCLES`` - 5 cycles - * - ``TOKENS_PER_ROLL`` + * - ``MINIMAL_STAKE`` - 6,000 ꜩ * - ``BLOCKS_PER_STAKE_SNAPSHOT`` - 512 blocks diff --git a/docs/lima/token_management.rst b/docs/lima/token_management.rst index 4f6348b439732469b7be1530b6a5fdbccf66ed2c..e1a4b639745b6a6975d5d43e572f317d913ec3ba 100644 --- a/docs/lima/token_management.rst +++ b/docs/lima/token_management.rst @@ -6,7 +6,7 @@ This page describes the reporting of tokens transfers in block metadata, as a se Overview ~~~~~~~~ -Minting, transferring or burning tokens is handled by the `Token `_ module. +Minting, transferring or burning tokens is handled by the :package-api:`Token ` module. The module provides functions (``Token.transfer`` and ``Token.transfer_n``) to transfer tokens from one, respectively from more accounts, to another account. Balance updates found in block metadata are generated by these functions as a trace of the token movements having taken place. @@ -203,4 +203,3 @@ For example, for an amount of ``100`` mutez in rewards not distributed due to in "change": "100", ...} ] Double signing evidence rewards and nonce revelation rewards are analogous to endorsing rewards, except that the source accounts used are ``"double signing evidence rewards"`` and ``"nonce revelation rewards"``. - diff --git a/docs/mumbai/blocks_ops.rst b/docs/mumbai/blocks_ops.rst index f832a40e2b15fc7ee5a0c9894ade8fd56fb330bc..d989935c6e6d7fbc1afca7d649ad2d0f12ffb4b4 100644 --- a/docs/mumbai/blocks_ops.rst +++ b/docs/mumbai/blocks_ops.rst @@ -14,7 +14,7 @@ those available to end-users on Tezos Mainnet. The complete list of operations, including those corresponding to features in development or available only on test networks, is given in the :package-api:`OCaml Documentation -`. +`. .. _validation_passes_mumbai: diff --git a/docs/mumbai/consensus.rst b/docs/mumbai/consensus.rst index f5a2d3d6c8c61fcdaf67e84e875113e010eb60d7..e5b38d9e5f656a97f9f9b1b8fcefee2c0b291469 100644 --- a/docs/mumbai/consensus.rst +++ b/docs/mumbai/consensus.rst @@ -149,7 +149,7 @@ balance*. Let us first (re)define these and related concepts. - The *(maximal) staking balance* of a delegate is its full balance (i.e. all the tokens owned by the delegate) plus the balances of all accounts that have delegated to it. - It must be at least ``TOKENS_PER_ROLL`` tez, otherwise the delegate cannot be selected as a validator. + It must be at least ``MINIMAL_STAKE`` tez, otherwise the delegate cannot be selected as a validator. - The *active stake* of a delegate is the amount of tez with which it participates in consensus. It is at most its staking balance. We explain below how it is computed. diff --git a/docs/mumbai/proof_of_stake.rst b/docs/mumbai/proof_of_stake.rst index 613079004f73348fc52e8f96442e9bd97bc8f283..a40935876a4664ae669c51f1988a9b1094c8bede 100644 --- a/docs/mumbai/proof_of_stake.rst +++ b/docs/mumbai/proof_of_stake.rst @@ -43,7 +43,7 @@ proportional with their delegated stake, which includes the balances of all the accounts that delegate to it, and also the balance of the delegate itself. To participate in consensus or in governance, a delegate needs to have at least a minimal stake, which is given by the -``TOKENS_PER_ROLL`` :ref:`protocol constant +``MINIMAL_STAKE`` :ref:`protocol constant `. Delegates place security deposits that may be forfeited in case they do not @@ -103,7 +103,7 @@ At the end of cycle ``n-1-PRESERVED_CYCLES``, the snapshot for cycle PRNG having as seed the :ref:`random seed` for cycle ``n``. -Only the stake of active delegates with the minimal stake of ``TOKENS_PER_ROLL`` is snapshot. +Only the stake of active delegates with the minimal stake of ``MINIMAL_STAKE`` is snapshot. .. _rights_mumbai: @@ -152,7 +152,7 @@ Proof-of-stake parameters - 16384 blocks * - ``PRESERVED_CYCLES`` - 5 cycles - * - ``TOKENS_PER_ROLL`` + * - ``MINIMAL_STAKE`` - 6,000 ꜩ * - ``BLOCKS_PER_STAKE_SNAPSHOT`` - 1024 blocks diff --git a/docs/mumbai/protocol_overview.rst b/docs/mumbai/protocol_overview.rst index 4e849f8b02d94bf44c11bd79861702c07b2468be..5e3ee038dc62468dfba12415ef5be8436865b2fb 100644 --- a/docs/mumbai/protocol_overview.rst +++ b/docs/mumbai/protocol_overview.rst @@ -158,10 +158,10 @@ The *list* of protocol constants can be found in the OCaml APIs: - fixed protocol constants are defined in the module :package-api:`Constants_repr - ` + ` - parametric constants are defined in the module :package-api:`Constants_parametric_repr - ` + ` The *values* of protocol constants in any given protocol can be found using specific RPC calls: diff --git a/docs/mumbai/token_management.rst b/docs/mumbai/token_management.rst index 4f6348b439732469b7be1530b6a5fdbccf66ed2c..7f5aeaf1b19f26b281ec5872d9f511f561154103 100644 --- a/docs/mumbai/token_management.rst +++ b/docs/mumbai/token_management.rst @@ -6,7 +6,7 @@ This page describes the reporting of tokens transfers in block metadata, as a se Overview ~~~~~~~~ -Minting, transferring or burning tokens is handled by the `Token `_ module. +Minting, transferring or burning tokens is handled by the :package-api:`Token ` module. The module provides functions (``Token.transfer`` and ``Token.transfer_n``) to transfer tokens from one, respectively from more accounts, to another account. Balance updates found in block metadata are generated by these functions as a trace of the token movements having taken place. @@ -203,4 +203,3 @@ For example, for an amount of ``100`` mutez in rewards not distributed due to in "change": "100", ...} ] Double signing evidence rewards and nonce revelation rewards are analogous to endorsing rewards, except that the source accounts used are ``"double signing evidence rewards"`` and ``"nonce revelation rewards"``. - diff --git a/docs/mumbai/validation.rst b/docs/mumbai/validation.rst index e36525ae4fe96c83cb0aa444cc2227b62b0d79d2..9908925b0aff4d67da10fc406bc5d4beaeea6ed3 100644 --- a/docs/mumbai/validation.rst +++ b/docs/mumbai/validation.rst @@ -50,11 +50,6 @@ state-passing machine where: on (i.e., it should call) *apply_operation* to validate and apply each operation in the block, and compute intermediate states. -.. TODO #4155: - - When creating a new environment, update references to V in the - paragraph below. - However, the *concrete* API exported from the Tezos economic protocol does not implement this business logic *monolithically*, as described above, but it rather presents a more fine-grained API. The rationale @@ -71,7 +66,7 @@ specified by the :package-api:`Protocol module in the :doc:`protocol environment<../shell/protocol_environment>` ``V8``, and it is implemented by this protocol in the -:package-api:`Main` +:package-api:`Main` module. The rest of this document is organized as follows: we first describe diff --git a/docs/shell/prevalidation.rst b/docs/shell/prevalidation.rst index a98382e6000a5b1875327f9ed9b71f6f28249a9c..aaa26e3ccaae09d9e955a58a690e4f194840c31b 100644 --- a/docs/shell/prevalidation.rst +++ b/docs/shell/prevalidation.rst @@ -57,7 +57,7 @@ the operation and already accepted operations, not taking into account the state of the ledger. Starting from Octez version 12.0, the ``precheck`` filter can be used -instead of ``applying_operation`` to classify operations, as follows: +instead of ``apply_operation`` to classify operations, as follows: If ``precheck`` cannot decide the classification of an operation, the prevalidator uses ``apply_operation`` instead. If an operation passes the ``precheck`` filter, or otherwise it has been successfully diff --git a/docs/user/key-management.rst b/docs/user/key-management.rst index 7fcad5e88af84021831842c7df85fa0f57f1415d..ceb0becbadba33c72a6e277dac865985a1502916 100644 --- a/docs/user/key-management.rst +++ b/docs/user/key-management.rst @@ -20,12 +20,13 @@ The solutions provided to strengthen the security of the default key management + sign user operations (e.g. transfers) interactively on the wallet + automatically sign baking operations, such as (pre-)endorsements, more securely. -- If you don't have a hardware wallet: +- If you don't have a hardware wallet, the option ``--encrypted`` of the client offers a first protection for storing your keys. - + The option ``--encrypted`` of the client offers a first protection for storing your keys. - + A separate signer daemon allows to decouple the client and baker from the signing process. - In particular, this allows executing a remote signer, placed on a different machine than the client and/or the baker, perhaps less exposed to attacks. - As the keys only need to be accessible to the signer, they can also benefit from the lesser exposure. +- A separate signer daemon allows to decouple the client and baker from the signing process. + + In particular, this allows executing the signer remotely (that is, on a different machine than the client and/or the baker), perhaps less exposed to attacks. + + As the keys only need to be accessible to the signer, they can also benefit from the lesser exposure. Even better (and recommended), a remote signer can be combined with a hardware wallet connected to the same machine as the signer. These solutions are detailed in the rest of this page. @@ -266,12 +267,12 @@ Consensus Key .. note:: - Consensus key is available starting with the Tezos L protocol. + The "consensus key" feature is available starting with the Tezos :doc:`Lima<../protocols/015_lima>` protocol. By default, the baker's key, also called manager key, is used to sign in the consensus protocol, i.e. signing blocks while baking, and signing consensus operations (preendorsements and endorsements). -A delegate may elect instead to choose a dedicated key: the consensus key. It can then be changed without redelegation. +A delegate may elect instead to choose a dedicated key: the *consensus key*. It can then be changed without redelegation. It also allows establishment of baking operations in an environment where access is not ultimately guaranteed: for example, a cloud platform providing hosted Key Management Systems (KMS) where the private key is @@ -298,7 +299,7 @@ The command to update the consensus key is:: tezos-client set consensus key for to consensus -The update becomes active after `PRESERVED_CYCLES + 1` cycles. We therefore distinguish +The update becomes active after ``PRESERVED_CYCLES + 1`` cycles. We therefore distinguish the active consensus key and the pending consensus keys. The active consensus key is by default the delegate’s manager key, which cannot change. @@ -324,7 +325,7 @@ The delegate will seamlessly keep baking when the transition happens:: Draining a Manager's Account With its Consensus Key ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This operation immediately transfers all the spendable balance of the `baker_pkh`’s implicit account into the `destination_pkh` implicit account:: +This operation immediately transfers all the spendable balance of the ``baker_pkh``’s implicit account into the ``destination_pkh`` implicit account:: tezos-client drain delegate to with @@ -333,9 +334,9 @@ If the destination is the consensus key account, this can be simplified to:: tezos-client drain delegate to The active consensus key is the signer for this operation, therefore the private key associated to the consensus key must be available -in the wallet of the client typing the command. The delegate's private key needs not be present. +in the wallet of the client typing the command. The delegate's private key does not need to be present. -`drain delegate` has no effect on the frozen balance. +The drain operation has no effect on the frozen balance. A fixed fraction of the drained delegate’s spendable balance is transferred as fees to the baker that includes the operation, i.e. the maximum between 1 tez or 1% of the spendable balance. diff --git a/scripts/snapshot_alpha.sh b/scripts/snapshot_alpha.sh index de23fead6a427260f472af176106615043f120c3..8c1890d262467de79a8248e4556c80a05fe38024 100755 --- a/scripts/snapshot_alpha.sh +++ b/scripts/snapshot_alpha.sh @@ -93,6 +93,8 @@ echo "Fixing versioned links in docs" cd docs/${label} sed -i.old -e s/_alpha:/_${label}:/g \ -e s,src/proto_alpha,src/proto_${version}_${short_hash},g \ + -e s,tezos-protocol-alpha/,tezos-protocol-${version}-${short_hash}/,g \ + -e s,raw_protocol_alpha/,raw_protocol_${version}_${short_hash}/,g \ -e s/_alpha\>/_${label}\>/g \ -e s/_alpha\`/_${label}\`/g \ -e s/-alpha.html/-${label}.html/g \ diff --git a/src/proto_alpha/lib_protocol/contract_storage.mli b/src/proto_alpha/lib_protocol/contract_storage.mli index 23c062aad53bf2e5fd68847c38ce4a3235a3c3da..55720b9e0d71a767bcdafa3d5cc6b7ab1d3bd09a 100644 --- a/src/proto_alpha/lib_protocol/contract_storage.mli +++ b/src/proto_alpha/lib_protocol/contract_storage.mli @@ -58,7 +58,7 @@ type error += val allocated : Raw_context.t -> Contract_repr.t -> bool Lwt.t (** [exists ctxt contract] returns [true] if and only if either the - contract is originated or it is (implicit and) "allocated". *) + contract is implicit or it is (originated and) {!allocated}. *) val exists : Raw_context.t -> Contract_repr.t -> bool Lwt.t (** [must_exist ctxt contract] fails with the [Non_existing_contract] error if