From 0a43ba2e3bc4fb85c1df83308998a23f811f38b6 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Wed, 27 Mar 2024 10:07:41 +0100 Subject: [PATCH 1/7] doc: adapt definitions of accounts --- docs/alpha/accounts.rst | 23 +++++++++++++++-------- docs/paris/accounts.rst | 2 +- 2 files changed, 16 insertions(+), 9 deletions(-) diff --git a/docs/alpha/accounts.rst b/docs/alpha/accounts.rst index f56d6ac458c3..fa36e4275d65 100644 --- a/docs/alpha/accounts.rst +++ b/docs/alpha/accounts.rst @@ -5,24 +5,25 @@ The Tezos ledger currently supports two types of accounts that can hold tokens (and be the destinations of transactions), identified by distinct addresses: - - An implicit account is a non-programmable account, whose tokens + - A user account (or implicit account) is a non-programmable account, whose tokens are spendable and delegatable by the owner of a private key. Its address is the hash of the public key, prefixed by ``tz1``, ``tz2``, ``tz3`` or ``tz4``. - - A smart contract is a programmable account, associated with some Michelson code. - A transaction to such - an address can provide data, and can fail, according to the :ref:`transaction semantics `. Its address is a unique hash that depends on - the operation that led to its creation, prefixed by ``KT1``. + - A smart contract is a programmable account, associated with some Michelson code and a piece of data storage. + The address of a smart contract is a unique hash that depends on + the operation that led to its creation, called origination, prefixed by ``KT1``. + This is why smart contracts are also called originated accounts. Finally, addresses prefixed with ``sr1`` identify :doc:`Smart Rollups <./smart_rollups>`. -Implicit accounts -~~~~~~~~~~~~~~~~~ +User accounts +~~~~~~~~~~~~~ -From the economic protocol's point of view, implicit accounts are considered as a particular case +From the economic protocol's point of view, user accounts are considered as a particular case of smart contracts that always succeed in receiving tokens or tickets, and do nothing else. +This is why user accounts are also called implicit accounts. Transactions that are signed by the private key corresponding to the public key hash, *i.e.* address of the account can spend its tokens. Each @@ -78,3 +79,9 @@ multiple signatures can be aggregated into one, and later verified as having been produced for the correct expected public keys. This allows for numerous applications like mutli-signatures schemes, multi-party key exchanges, signatures compaction, etc. BLS is notably used by Zcash and Ethereum 2.0. + +Smart contracts +~~~~~~~~~~~~~~~ + +A transaction to a smart contract +address can provide data and optionally some tokens, and triggers the execution of the code, which may read and update the storage. The transaction can succeed or fail, according to the :ref:`transaction semantics `. diff --git a/docs/paris/accounts.rst b/docs/paris/accounts.rst index f56d6ac458c3..f5c5ca08d78f 100644 --- a/docs/paris/accounts.rst +++ b/docs/paris/accounts.rst @@ -11,7 +11,7 @@ addresses: ``tz3`` or ``tz4``. - A smart contract is a programmable account, associated with some Michelson code. A transaction to such - an address can provide data, and can fail, according to the :ref:`transaction semantics `. Its address is a unique hash that depends on + an address can provide data, and can fail, according to the :ref:`transaction semantics `. Its address is a unique hash that depends on the operation that led to its creation, prefixed by ``KT1``. Finally, addresses prefixed with ``sr1`` identify :doc:`Smart Rollups -- GitLab From f4de397b8649cff0c33634c890f103bccd041ea7 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Wed, 27 Mar 2024 11:38:45 +0100 Subject: [PATCH 2/7] doc: replace originated account by smart contract --- docs/alpha/glossary.rst | 2 +- docs/alpha/michelson.rst | 4 ++-- docs/alpha/proof_of_stake.rst | 2 +- docs/alpha/token_management.rst | 6 +++--- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/alpha/glossary.rst b/docs/alpha/glossary.rst index db8614584e5d..39b040740020 100644 --- a/docs/alpha/glossary.rst +++ b/docs/alpha/glossary.rst @@ -118,7 +118,7 @@ _`Account` In the context_, each account is associated with a balance (an amount of tez available). - An account can be either an `user account`_ or a `smart contract`_. + An account can be either a `user account`_ or a `smart contract`_. _`Baker` When a delegate_ creates a new block_, it is called the baker of this block. diff --git a/docs/alpha/michelson.rst b/docs/alpha/michelson.rst index 914904c3cf89..d4c325a9e114 100644 --- a/docs/alpha/michelson.rst +++ b/docs/alpha/michelson.rst @@ -2461,8 +2461,8 @@ Syntax of other contracts specifications The behaviour of the `CONTRACT `__ -instruction depends on whether or not its input is the address of an -originated contract accepting the expected type as parameter. To test +instruction depends on whether or not its input is the address of a +smart contract accepting the expected type as parameter. To test it, the ``other_contract`` toplevel primitive can be used to specify which contracts are assumed to be originated and which type they accept as parameter. diff --git a/docs/alpha/proof_of_stake.rst b/docs/alpha/proof_of_stake.rst index f7b97df1708b..f9347f72c1fd 100644 --- a/docs/alpha/proof_of_stake.rst +++ b/docs/alpha/proof_of_stake.rst @@ -33,7 +33,7 @@ operation (see below) in which the specified delegate is the same as the operation emitter (its signer). Note that ``tz4`` accounts cannot be registered as delegates. -Any :ref:`account ` (implicit or originated) can specify a delegate +Any :ref:`account ` (implicit account or smart contract) can specify a delegate through a delegation operation. Any account can change or revoke its delegate at any time, again through a delegation operation. However, the change only becomes effective after ``CONSENSUS_RIGHTS_DELAY + 2`` :ref:`cycles `. The diff --git a/docs/alpha/token_management.rst b/docs/alpha/token_management.rst index 4f5c8734ec25..d9cc0742a7ad 100644 --- a/docs/alpha/token_management.rst +++ b/docs/alpha/token_management.rst @@ -80,7 +80,7 @@ Container accounts Container accounts are regular (user and smart contract) accounts, or convenience accounts that hold tokens temporarily (e.g. when parts of a delegate's funds are frozen). The field ``kind`` allows to identify the type of container account, it can have one of the following values: -* ``"contract"`` represents implicit or originated accounts, and comes with the additional field (also called) ``contract`` whose value is the public key hash of the implicit or originated account. +* ``"contract"`` represents an implicit account or smart contract, and comes with the additional field (also called) ``contract`` whose value is the public key hash of the implicit account or the contract hash of the smart contract. * ``"freezer"`` represents frozen accounts, and comes with the additional field ``category`` that can have one of the following values: - ``"deposits"`` represents the accounts of frozen deposits. @@ -111,10 +111,10 @@ The field ``kind`` allows to identify the type of container account, it can have cycle. - ``"bonds"`` represents the accounts of frozen bonds. Bonds are like deposits. - However, they can be associated to implicit or originated accounts, unlike deposits that only apply to implicit accounts that are also delegates. + However, they can be associated to implicit accounts or smart contracts, unlike deposits that only apply to implicit accounts that are also delegates. Accounts in this category are further identified by the following additional fields: - - the field ``contract`` contains the public key hash of the implicit account, or the contract hash of the originated account + - the field ``contract`` contains the public key hash of the implicit account, or the contract hash of the smart contract - the field ``bond_id`` contains the identifier of the bond (e.g. a rollup hash if the bond is associated to a transaction or a smart contract rollup). * ``"accumulator"`` represents accounts used to store tokens for some short period of time. This type of account is further identified by the additional field ``category`` whose (only possible) value ``"block fees"`` designates the container account used to collect manager operation fees while block's operations are being applied. -- GitLab From aa81222ac1ce380dd57266c962f01ac17d4ef9c9 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Wed, 27 Mar 2024 13:45:07 +0100 Subject: [PATCH 3/7] doc: add synonym user account = implicit account --- docs/alpha/michelson.rst | 12 +++++++----- docs/introduction/howtouse.rst | 12 ++++++------ 2 files changed, 13 insertions(+), 11 deletions(-) diff --git a/docs/alpha/michelson.rst b/docs/alpha/michelson.rst index d4c325a9e114..0b9240a8cb99 100644 --- a/docs/alpha/michelson.rst +++ b/docs/alpha/michelson.rst @@ -38,13 +38,15 @@ The Tezos ledger currently has two types of accounts that can hold tokens. Accounts can be used in transactions as senders, to send tokens, or as destinations, to receive tokens. -- Implicit account: non-programmable account whose address is +- User account: non-programmable account whose address is the public key hash, prefixed by ``tz`` and one digit. + User accounts are sometimes called implicit accounts. A transaction to such an address cannot provide data, except :doc:`tickets <./tickets>`. - Smart contract: programmable account associated to some Michelson code, whose address is a unique hash, prefixed by ``KT1``. A transaction to such an address can provide data, and can fail for reasons detailed below. + Smart contracts are sometimes called originated accounts. Finally, addresses prefixed with ``sr1`` identify :doc:`Smart Rollups <./smart_rollups>`, which cannot hold tokens but can be the destination of transactions. @@ -92,7 +94,7 @@ The subset of blockchain operations that can be emitted by Michelson programs as - Transaction transferring: - * tokens and optionally tickets to an implicit account, or + * tokens and optionally tickets to a user account, or * tokens and parameters to a smart contract (or, optionally, to a specified entrypoint of a smart contract), or * parameters to a smart rollup. @@ -101,7 +103,7 @@ The subset of blockchain operations that can be emitted by Michelson programs as source code, an initial amount of tokens transferred from the source, and an initial storage content. - Delegation assigning the tokens of the sender account to the stake of - an implicit account (without transferring any tokens). + a user account (without transferring any tokens). - :doc:`Contract event <./event>` delivering live information from a smart contract to external applications. @@ -178,7 +180,7 @@ In any case, when a failure happens, either total success or total failure is guaranteed. If a transaction (internal or external) fails, then the whole sequence fails and all the effects up to the failure are reverted. These transactions can still be included in blocks, and -the transaction fees are given to the implicit account who baked the +the transaction fees are given to the user account who baked the block. Language semantics @@ -1493,7 +1495,7 @@ that is only well-typed if the current contract has an entrypoint named ``%entry :: 'S -> contract 'p : 'S where contract 'p is the type of the entrypoint %entrypoint of the current contract -Implicit accounts are considered to have a single ``default`` +User accounts are considered to have a single ``default`` entrypoint of type ``Unit``. JSON syntax diff --git a/docs/introduction/howtouse.rst b/docs/introduction/howtouse.rst index 372bcaa47184..94d3a8f93d04 100644 --- a/docs/introduction/howtouse.rst +++ b/docs/introduction/howtouse.rst @@ -454,12 +454,12 @@ Once your transaction is included in a block, you can retrieve it in one of the .. _originated-accounts: -Implicit Accounts and Smart Contracts -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +User Accounts and Smart Contracts +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -In Tezos there are two kinds of accounts: *implicit accounts* and *smart contracts* (see :doc:`../active/accounts` for more details). +In Tezos there are two kinds of accounts: *user accounts* (also called implicit accounts) and *smart contracts* (also called originated accounts), see :doc:`../active/accounts` for more details. -- Addresses with a *tz* prefix, like the *tz1* public key hashes used above, represent implicit accounts. They are created with a transfer +- Addresses with a *tz* prefix, like the *tz1* public key hashes used above, represent user accounts. They are created with a transfer operation to the account's public key hash. - Smart contracts have addresses starting with *KT1* and are created @@ -473,7 +473,7 @@ Let's originate our first contract and call it *id*:: running ./michelson_test_scripts/attic/id.tz \ --init '"hello"' --burn-cap 0.4 -The initial balance is 1 tez, generously provided by implicit account +The initial balance is 1 tez, generously provided by user account *alice*. The contract stores a Michelson program ``id.tz`` (found in file :src:`michelson_test_scripts/attic/id.tz`), with Michelson value ``"hello"`` as initial storage (the extra quotes are @@ -688,7 +688,7 @@ Summary In this tutorial, you have learned: - to start an Octez node and set up its basic configuration; -- to use the Octez client to create implicit accounts and do transfers between them; +- to use the Octez client to create user accounts and do transfers between them; - to deploy and interact with a simple predefined smart contract; - to distinguish between the various costs associated to transactions such as burnt tez, fees, storage costs, and gas consumption; - some further concepts such as transaction validation and the RPC interface; -- GitLab From cb6f55c82cdb86709a9b0f7f19ecbb5e83b49cd4 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Wed, 27 Mar 2024 13:46:02 +0100 Subject: [PATCH 4/7] doc: replace implicit account by user account --- docs/alpha/accounts.rst | 3 ++- docs/alpha/adaptive_issuance.rst | 4 ++-- docs/alpha/blocks_ops.rst | 6 +++--- docs/alpha/liquidity_baking.rst | 2 +- docs/alpha/proof_of_stake.rst | 4 ++-- docs/alpha/sapling.rst | 10 +++++----- docs/alpha/smart_rollups.rst | 2 +- docs/alpha/tickets.rst | 32 ++++++++++++++++---------------- docs/alpha/token_management.rst | 8 ++++---- docs/introduction/howtorun.rst | 16 ++++++++-------- docs/introduction/howtouse.rst | 2 +- docs/shell/smart_rollup_node.rst | 6 +++--- docs/user/key-management.rst | 2 +- docs/user/multisig.rst | 2 +- 14 files changed, 50 insertions(+), 49 deletions(-) diff --git a/docs/alpha/accounts.rst b/docs/alpha/accounts.rst index fa36e4275d65..bcc882a7ea34 100644 --- a/docs/alpha/accounts.rst +++ b/docs/alpha/accounts.rst @@ -23,11 +23,12 @@ User accounts From the economic protocol's point of view, user accounts are considered as a particular case of smart contracts that always succeed in receiving tokens or tickets, and do nothing else. +Transferring toward a user account succeeds even if the address of the account has never appeared on the chain before. This is why user accounts are also called implicit accounts. Transactions that are signed by the private key corresponding to the public key hash, *i.e.* address of the account can spend its tokens. Each -prefix for addresses denote a different cryptographic signing scheme. They are +prefix for addresses denotes a different cryptographic signing scheme. They are briefly described below from a user point of view. The sizes of public keys, secret keys and signatures may differ between the diff --git a/docs/alpha/adaptive_issuance.rst b/docs/alpha/adaptive_issuance.rst index 6b3c0b9a159e..60b406141112 100644 --- a/docs/alpha/adaptive_issuance.rst +++ b/docs/alpha/adaptive_issuance.rst @@ -457,7 +457,7 @@ with the mechanism. It is based on four *pseudo-operations*: ``stake``, ``unstake``, ``finalize_unstake``, and ``set_delegate_parameters``. Pseudo-operations are self-transfers: a transfer operation where the destination matches the source – each involving a special entry-point of -the same name introduced for :ref:`implicit accounts `. +the same name introduced for :ref:`user accounts `. This approach was chosen to minimize the work required by wallets, custodians, exchanges, and other parties to support the functionality. @@ -465,7 +465,7 @@ custodians, exchanges, and other parties to support the functionality. activation `: only *delegates* can stake funds and the relative weight of staked and delegated funds remains unchanged. In the current implementation, only -*implicit accounts* can become stakers. In other words, smart contracts +user accounts can become stakers. In other words, smart contracts cannot stake funds (they can of course still delegate them). .. _staking_policy_configuration_alpha: diff --git a/docs/alpha/blocks_ops.rst b/docs/alpha/blocks_ops.rst index 82020cac9c8c..44ad9aec972b 100644 --- a/docs/alpha/blocks_ops.rst +++ b/docs/alpha/blocks_ops.rst @@ -200,7 +200,7 @@ handled with dedicated manager operations. according to their specific semantics. - The ``Smart_rollup_publish`` operation is used to regularly declare what is the new state of a given smart rollup in a so-called - “commitment”. To publish commitments, an implicit account has to + “commitment”. To publish commitments, a user account has to own at least ꜩ 10,000, which are frozen as long as at least one of their commitments is disputable. - The ``Smart_rollup_cement`` operation is used to cement a @@ -208,9 +208,9 @@ handled with dedicated manager operations. published for long enough, and there is no concurrent commitment for the same state update. Once a commitment is cemented, it cannot be disputed anymore. -- The ``Smart_rollup_recover_bond`` operation is used by an implicit +- The ``Smart_rollup_recover_bond`` operation is used by a user account to unfreeze their ꜩ 10,000. This operation only succeeds if - and only if all the commitments published by the implicit account + and only if all the commitments published by the user account have been cemented. - The ``Smart_rollup_refute`` operation is used to start or pursue a dispute. A dispute is resolved on the Tezos blockchain through a diff --git a/docs/alpha/liquidity_baking.rst b/docs/alpha/liquidity_baking.rst index 0de867612f93..42a76dbc80b8 100644 --- a/docs/alpha/liquidity_baking.rst +++ b/docs/alpha/liquidity_baking.rst @@ -17,7 +17,7 @@ The CPMM maintains a balance of ``a`` tez and ``b`` `tzBTC `_ To implement this contract, we use a fork of the open source code base used by `version two `_ of the "Dexter" project. The implementation of this contract has been `formally verified `_ against its functional specification. The contract code is modified in the following way: 1. The fee is set to 0.1% only (the fee in Dexter v2 is set to 0.3%). Rationale: given the subsidy it is not necessary to charge a large fee and better to improve liquidity. -2. An additional 0.1% of every trade is burned by being transferred to the null implicit account. Rationale: this mechanism offsets inflation from the subsidy. The inflation is exactly balanced at a daily trade volume of 7.2 million tez. +2. An additional 0.1% of every trade is burned by being transferred to the null user account. Rationale: this mechanism offsets inflation from the subsidy. The inflation is exactly balanced at a daily trade volume of 7.2 million tez. 3. The ability to set a delegate has been removed. Rationale: the subsidy means there is no need for a baker for that contract and having one would create an imbalance. 4. The ability to set a manager has been removed. Rationale: the only privilege of the Dexter manager is to set Dexter's delegate so this role is now unnecessary. diff --git a/docs/alpha/proof_of_stake.rst b/docs/alpha/proof_of_stake.rst index f9347f72c1fd..abdf5d751a5c 100644 --- a/docs/alpha/proof_of_stake.rst +++ b/docs/alpha/proof_of_stake.rst @@ -27,13 +27,13 @@ be predicted too much in advance. Delegation and Staking ---------------------- -A *delegate* is any :ref:`implicit account ` registered as +A *delegate* is any :ref:`user account ` registered as such. This is done by *self-delegating*, that is, emitting a delegation operation (see below) in which the specified delegate is the same as the operation emitter (its signer). Note that ``tz4`` accounts cannot be registered as delegates. -Any :ref:`account ` (implicit account or smart contract) can specify a delegate +Any :ref:`account ` (user account or smart contract) can specify a delegate through a delegation operation. Any account can change or revoke its delegate at any time, again through a delegation operation. However, the change only becomes effective after ``CONSENSUS_RIGHTS_DELAY + 2`` :ref:`cycles `. The diff --git a/docs/alpha/sapling.rst b/docs/alpha/sapling.rst index fed70482fe59..2385c8dc6698 100644 --- a/docs/alpha/sapling.rst +++ b/docs/alpha/sapling.rst @@ -29,8 +29,8 @@ On the other hand a viewing key can willingly be shared with a third party, for example with an auditor for regulatory compliance purposes. A viewing key can also derive several diversified addresses. -An address can be used to receive funds, much like the address of an -implicit account. +An address can be used to receive funds, much like the address of a +user account. Additionally *proving keys* can be used to allow the creation of proofs, thus revealing private information, without being able to spend funds. @@ -309,10 +309,10 @@ Fees issue The Sapling integration in Tezos exhibits a privacy issue that Z-cash doesn't have. When interacting with a shielded pool one interacts with a smart contract -via a normal transaction and therefore have to pay fees from an -implicit account. +via a normal transaction and therefore have to pay fees from a +user account. One could guess that private transactions whose fees are paid by the -same implicit account are from the same user. +same user account are from the same user. This can be mitigated by making a service that act as a proxy by forwarding the user transactions and paying its fees. The user would then include in the transaction a shielded output for the service that diff --git a/docs/alpha/smart_rollups.rst b/docs/alpha/smart_rollups.rst index f73fbc3097f9..add886dc6d14 100644 --- a/docs/alpha/smart_rollups.rst +++ b/docs/alpha/smart_rollups.rst @@ -371,7 +371,7 @@ Glossary #. **Refutation period**: When the first commitment for a commitment period is published, a refutation period of two weeks starts to allow this commitment to be challenged. -#. **Staker**: An implicit account that has made a deposit on a +#. **Staker**: A user account that has made a deposit on a commitment. #. **Refutation game**: A process by which the Tezos protocol solves diff --git a/docs/alpha/tickets.rst b/docs/alpha/tickets.rst index b1b9a2fc4b5e..be6838a3940f 100644 --- a/docs/alpha/tickets.rst +++ b/docs/alpha/tickets.rst @@ -1,7 +1,7 @@ Tickets ======= -Tickets are a special class of assets on Tezos that contracts can construct and store, and that can then be transferred between contracts, implicit accounts, or rollups. +Tickets are a special class of assets on Tezos that contracts can construct and store, and that can then be transferred between contracts, user accounts, or rollups. They are useful to model ownership of some digital artefact, existing in a limited number of copies (or instances); this can further serve as a basis for restricting access to the artefact and permissions to use it. In this document, we will explain the semantics and lifetime of tickets, including creation, transfer, and destruction. @@ -35,7 +35,7 @@ Tickets can be constructed by smart contracts. To construct tickets, smart contr `instruction `__ with some ticket amount, ticket content type, and value as inputs. Smart contracts then may store them in contract storage or transfer them along to either -other contracts, rollups, or implicit accounts. +other contracts, rollups, or user accounts. Tickets cannot be constructed with instructions for duplication, such as ``DUP``. Therefore, the issuance of tickets is completely within the control of the ticketer contract by @@ -49,7 +49,7 @@ as long as the sum of the ``amount`` of the two tickets is equal to that of the This operation allows tickets to be spent across several transactions by breaking tickets into smaller tickets. Smart contracts may split tickets by invoking the `SPLIT_TICKET `__ instruction. -The ticket splitting is done automatically when an implicit account transfers part of a ticket. +The ticket splitting is done automatically when a user account transfers part of a ticket. Joining ~~~~~~~ @@ -59,19 +59,19 @@ same ``contents_ty`` type are considered of the same kind. Therefore, two such tickets can be **joined** into one ticket and the output ``amount`` will be the sum of those of the two input tickets. Smart contracts can join tickets via the `JOIN_TICKETS `__ instruction. -Tickets of the same kind are automatically joined when they belong to the same implicit account. +Tickets of the same kind are automatically joined when they belong to the same user account. Transferring ~~~~~~~~~~~~ Once a ticket has been constructed by a smart contract, it may be transferred to other contracts as follows: -- *Smart contract to implicit account*: Smart contracts can transfer a ticket to implicit accounts +- *Smart contract to user account*: Smart contracts can transfer a ticket to user accounts via `TRANSFER_TOKENS `__. - To do so, the contract needs to cast the address of the target implicit account to type ``contract (ticket cty)`` where ``cty`` is the type of the content of the ticket to be sent. This can be done using ``CONTRACT (ticket cty)``. + To do so, the contract needs to cast the address of the target user account to type ``contract (ticket cty)`` where ``cty`` is the type of the content of the ticket to be sent. This can be done using ``CONTRACT (ticket cty)``. The rest is the same as making a contract call. The following Michelson snippet is an example sending a ticket of amount ``10`` with a ``string`` content - ``"some ticket"`` to an implicit account address made available at the top of the stack. + ``"some ticket"`` to a user account address made available at the top of the stack. :: @@ -97,11 +97,11 @@ Once a ticket has been constructed by a smart contract, it may be transferred to calls using the instruction ``TRANFSER_TOKENS``, as long as target contracts accept tickets of matching content type in their ``parameter``\s. -- *Between implicit accounts*: Implicit accounts can transfer existing tickets they own to other implicit accounts +- *Between user accounts*: User accounts can transfer existing tickets they own to other user accounts with ``Transfer_ticket`` operation from their wallets. - For instance, ``octez-client`` can be invoked in the following way by an implicit account holder ``alice`` + For instance, ``octez-client`` can be invoked in the following way by a user account holder ``alice`` to transfer a ticket of amount ``10``, type ``string``, content ``"some ticket"`` and ticketer ``ticketer`` - to another implicit account held by ``bob``. + to another user account held by ``bob``. :: @@ -113,12 +113,12 @@ after which ``alice`` would continue to own the remaining amount. Note that the above command uses the expression "transfer 10 tickets" of the given kind, instead of "transfer a ticket of amount 10". -Indeed, by virtue of automatic joining of tickets of the same kind belonging to the same implicit account, +Indeed, by virtue of automatic joining of tickets of the same kind belonging to the same user account, this formulation does not introduce any ambiguity: -the implicit account cannot hold several distinct tickets of this kind. +the user account cannot hold several distinct tickets of this kind. Of course, these expressions would not be interchangeable for tickets belonging to a smart contract. -- *Implicit account to smart contract*: Using the same ``Transfer_ticket`` operation, implicit accounts +- *User account to smart contract*: Using the same ``Transfer_ticket`` operation, user accounts can also send their tickets to smart contracts. In this case, the entrypoint, as defined by the specification of the target contract, must accept this kind of tickets. Here is an example using ``octez-client`` to transfer a ticket of amount ``10``, type ``string``, @@ -142,11 +142,11 @@ Destroying Only smart contracts can destroy tickets, by simply dropping them. That is, by not storing them anymore in the contract storage and not sending them to other contracts. -Implicit accounts, on the other hand, cannot destroy any ticket in their possession. +User accounts, on the other hand, cannot destroy any ticket in their possession. -For instance, an implicit account ``A`` may receive a ``string`` ticket of amount ``2`` with +For instance, a user account ``A`` may receive a ``string`` ticket of amount ``2`` with content ``Lorem ipsum`` created by a smart contract ``B``. ``A`` may send amount ``1`` of it to a smart contract ``C``. This automatically splits the ticket into two tickets of amount ``1``. Now ``C`` may destroy this ticket by dropping it and ``A`` will still hold a ticket of amount ``1`` with a ``string`` content ``Lorem ipsum`` created by ``B``. -It will remain in the possession of ``A`` until ``A`` sends it to another implicit account or smart contract. +It will remain in the possession of ``A`` until ``A`` sends it to another user account or smart contract. diff --git a/docs/alpha/token_management.rst b/docs/alpha/token_management.rst index d9cc0742a7ad..122c144c9863 100644 --- a/docs/alpha/token_management.rst +++ b/docs/alpha/token_management.rst @@ -80,7 +80,7 @@ Container accounts Container accounts are regular (user and smart contract) accounts, or convenience accounts that hold tokens temporarily (e.g. when parts of a delegate's funds are frozen). The field ``kind`` allows to identify the type of container account, it can have one of the following values: -* ``"contract"`` represents an implicit account or smart contract, and comes with the additional field (also called) ``contract`` whose value is the public key hash of the implicit account or the contract hash of the smart contract. +* ``"contract"`` represents a user account or smart contract, and comes with the additional field (also called) ``contract`` whose value is the public key hash of the user account or the contract hash of the smart contract. * ``"freezer"`` represents frozen accounts, and comes with the additional field ``category`` that can have one of the following values: - ``"deposits"`` represents the accounts of frozen deposits. @@ -92,7 +92,7 @@ The field ``kind`` allows to identify the type of container account, it can have from the deposit, - just a ``"delegate"`` to designate collectively the deposits of all - stakers delegating to the provided implicit account. + stakers delegating to the provided user account. - a ``"baker_own_stake"`` field to designate the delegate's own deposits received from its own stake rewards. - a ``"baker_edge"`` field to designate the delegate's own deposits received from the edge on its staker's rewards. - ``"unstaked_deposits"`` represents the accounts of unstaked frozen tokens. @@ -111,10 +111,10 @@ The field ``kind`` allows to identify the type of container account, it can have cycle. - ``"bonds"`` represents the accounts of frozen bonds. Bonds are like deposits. - However, they can be associated to implicit accounts or smart contracts, unlike deposits that only apply to implicit accounts that are also delegates. + However, they can be associated to user accounts or smart contracts, unlike deposits that only apply to user accounts that are also delegates. Accounts in this category are further identified by the following additional fields: - - the field ``contract`` contains the public key hash of the implicit account, or the contract hash of the smart contract + - the field ``contract`` contains the public key hash of the user account, or the contract hash of the smart contract - the field ``bond_id`` contains the identifier of the bond (e.g. a rollup hash if the bond is associated to a transaction or a smart contract rollup). * ``"accumulator"`` represents accounts used to store tokens for some short period of time. This type of account is further identified by the additional field ``category`` whose (only possible) value ``"block fees"`` designates the container account used to collect manager operation fees while block's operations are being applied. diff --git a/docs/introduction/howtorun.rst b/docs/introduction/howtorun.rst index 59ec3141b530..41108db7b217 100644 --- a/docs/introduction/howtorun.rst +++ b/docs/introduction/howtorun.rst @@ -24,15 +24,15 @@ If you don't want to deal with the complexity of running your own delegate, you can always take part in the protocol by delegating your coins to one. -Both implicit accounts and smart contracts can have a -delegate. Setting or resetting the delegate of an implicit account is +Both user accounts and smart contracts can have a +delegate. Setting or resetting the delegate of a user account is achieved by the following command: :: - octez-client set delegate for to + octez-client set delegate for to -where ```` is the address or alias of the implicit +where ```` is the address or alias of the user account to delegate and ```` is the address or alias of the delegate (which has to be :ref:`registered`). @@ -40,7 +40,7 @@ To stop a delegation, the following command can be used: :: - octez-client withdraw delegate from + octez-client withdraw delegate from @@ -59,10 +59,10 @@ delegation is by using the ``SET_DELEGATE`` Michelson instruction (see details). -Notice that only implicit accounts can be delegates, so your delegate +Notice that only user accounts can be delegates, so your delegate must be a *tz* address. -Funds in implicit accounts which are not registered as delegates +Funds in user accounts which are not registered as delegates do not participate in baking. Note that delegating coins doesn't mean that a delegate can spend @@ -121,7 +121,7 @@ Register and check your rights ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To run a delegate, you first need to register as one using -your implicit account:: +your user account:: octez-client register key bob as delegate diff --git a/docs/introduction/howtouse.rst b/docs/introduction/howtouse.rst index 94d3a8f93d04..bd311c7bf673 100644 --- a/docs/introduction/howtouse.rst +++ b/docs/introduction/howtouse.rst @@ -459,7 +459,7 @@ User Accounts and Smart Contracts In Tezos there are two kinds of accounts: *user accounts* (also called implicit accounts) and *smart contracts* (also called originated accounts), see :doc:`../active/accounts` for more details. -- Addresses with a *tz* prefix, like the *tz1* public key hashes used above, represent user accounts. They are created with a transfer +- Addresses with a *tz* prefix, like the *tz1* public key hashes used above, represent user accounts. They are created with a transfer operation to the account's public key hash. - Smart contracts have addresses starting with *KT1* and are created diff --git a/docs/shell/smart_rollup_node.rst b/docs/shell/smart_rollup_node.rst index ff074dd72427..fbc2bf30023b 100644 --- a/docs/shell/smart_rollup_node.rst +++ b/docs/shell/smart_rollup_node.rst @@ -25,7 +25,7 @@ Prerequisites To experiment with the commands described in this section, we use the `Weeklynet `_. In this section, we assume that ``${OPERATOR_ADDR}`` is a valid -implicit account on Weeklynet owned by the reader. +user account on Weeklynet owned by the reader. Notice that you need a specific development version of Octez to participate to Weeklynet. This version is either available from @@ -81,7 +81,7 @@ This can be checked by: octez-client bootstrapped octez-client rpc get /chains/main/blocks/head/protocols -In case you do not already have an implicit account, you can generate one with: +In case you do not already have a user account, you can generate one with: .. code:: sh @@ -1482,7 +1482,7 @@ with the following schema: [ [ { "payload" : , "sender" : , - "source" : + "source" : "destination" : } .. // or diff --git a/docs/user/key-management.rst b/docs/user/key-management.rst index 0e09b01c883d..b7e8acb733f5 100644 --- a/docs/user/key-management.rst +++ b/docs/user/key-management.rst @@ -325,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 user account into the ``destination_pkh`` user account:: octez-client drain delegate to with diff --git a/docs/user/multisig.rst b/docs/user/multisig.rst index a6cacc80b481..54e5c8753223 100644 --- a/docs/user/multisig.rst +++ b/docs/user/multisig.rst @@ -174,7 +174,7 @@ limitations: - the possible authenticated actions on the contract are: - - transfer without parameter to an implicit account or to a smart + - transfer without parameter to a user account or to a smart contract with an entrypoint of type ``unit`` - set the delegate of the contract - remove the delegate of the contract -- GitLab From 831ec38d47a25af280fc6884a93b82b4a8269bff Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Mon, 22 Apr 2024 16:06:17 +0200 Subject: [PATCH 5/7] doc: fix alphabetic ordering in glossary --- docs/alpha/glossary.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/alpha/glossary.rst b/docs/alpha/glossary.rst index 39b040740020..6ee702086562 100644 --- a/docs/alpha/glossary.rst +++ b/docs/alpha/glossary.rst @@ -120,6 +120,14 @@ _`Account` An account can be either a `user account`_ or a `smart contract`_. +_`Attesting` + When a block_ is created and propagated on the network, delegates that have + `attesting rights`_ for the matching block level_ and round_ can emit an attestation operation_. + Attestation operations are included in the next block_. + +_`Attesting rights` + See `baking rights`_. + _`Baker` When a delegate_ creates a new block_, it is called the baker of this block. `Baking rights`_ are distributed to different delegates based on their @@ -207,14 +215,6 @@ _`Failing Noop` :ref:`sign arbitrary messages` which have no computational semantics. -_`Attesting` - When a block_ is created and propagated on the network, delegates that have - `attesting rights`_ for the matching block level_ and round_ can emit an attestation operation_. - Attestation operations are included in the next block_. - -_`Attesting rights` - See `baking rights`_. - .. _def_fee_alpha: _`Fee` -- GitLab From 00e955f7c84c138f08ddf8e3f19dd72b0e265b81 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Tue, 23 Apr 2024 15:20:38 +0200 Subject: [PATCH 6/7] doc: rename label def_implicit_account --- docs/alpha/glossary.rst | 2 +- docs/alpha/proof_of_stake.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/alpha/glossary.rst b/docs/alpha/glossary.rst index 6ee702086562..fdfff0db9b1b 100644 --- a/docs/alpha/glossary.rst +++ b/docs/alpha/glossary.rst @@ -325,7 +325,7 @@ _`Transaction` An operation_ to transfer tez between two accounts, or to run the code of a `smart contract`_. -.. _def_implicit_account_alpha: +.. _def_user_account_alpha: _`User account` An account_ that is linked to a public key. Contrary to a `smart diff --git a/docs/alpha/proof_of_stake.rst b/docs/alpha/proof_of_stake.rst index abdf5d751a5c..f43248585268 100644 --- a/docs/alpha/proof_of_stake.rst +++ b/docs/alpha/proof_of_stake.rst @@ -27,7 +27,7 @@ be predicted too much in advance. Delegation and Staking ---------------------- -A *delegate* is any :ref:`user account ` registered as +A *delegate* is any :ref:`user account ` registered as such. This is done by *self-delegating*, that is, emitting a delegation operation (see below) in which the specified delegate is the same as the operation emitter (its signer). Note that ``tz4`` accounts cannot be registered -- GitLab From 0b34a01c014205e453766f8c12fcc39e85e9fa41 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Thu, 2 May 2024 16:47:32 +0200 Subject: [PATCH 7/7] doc: define synonyms user accounts & smart contracts, in the code --- src/proto_alpha/lib_protocol/contract_repr.mli | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/proto_alpha/lib_protocol/contract_repr.mli b/src/proto_alpha/lib_protocol/contract_repr.mli index ac50e01d41fb..3d0278f2ff2e 100644 --- a/src/proto_alpha/lib_protocol/contract_repr.mli +++ b/src/proto_alpha/lib_protocol/contract_repr.mli @@ -30,9 +30,12 @@ (** A contract is simply an account on the blockchain ledger. There are two types of contracts: - implicit contracts represent accounts of users of the blockchain; + hence, they are commonly called "user accounts" in the documentation; - originated are special accounts with a Michelson script attached to them. Every time a transaction is sent to an originated account, its associated script is run in order to trigger some action in response. + These scripted accounts are commonly called "smart contracts" in the + documentation. An implicit account is identified by the hash of the public key which was used to create it. The owner of the corresponding private key is the -- GitLab