diff --git a/docs/CHANGES.rst b/docs/CHANGES.rst index 561bac2a3c7323bde9e7a20987254b1afa59e88b..18228f4f2c7fda5bf6e9e5341d99a339d093d47b 100644 --- a/docs/CHANGES.rst +++ b/docs/CHANGES.rst @@ -143,7 +143,7 @@ Node Client ------ -- The light client (`tezos-client --mode light`) now uses the +- The light client (`octez-client --mode light`) now uses the `../block//merkle_tree_v2` RPC introduced in this version, removing a lot of delicate verification code and relying on Irmin instead. The client for this version will thus not work with older node versions that do not have @@ -157,8 +157,8 @@ Client source. - Added commands to get the used and paid storage spaces of contracts: - ``tezos-client get used storage space for `` and - ``tezos-client get paid storage space for ``. + ``octez-client get used storage space for `` and + ``octez-client get paid storage space for ``. - Added RPCs to get the used and paid storage spaces of contracts: ``GET /chains//blocks//context/contracts//storage/used_space`` @@ -169,13 +169,13 @@ Client Update the consensus key of a baker: ```shell -tezos-client set consensus key for to +octez-client set consensus key for to ``` It is also possible to register as a delegate and immediately set the consensus key: ```shell -tezos-client register key as delegate with consensus key +octez-client register key as delegate with consensus key ``` (The current registration command still works.) @@ -184,13 +184,13 @@ tezos-client register key as delegate with consensus key Drain a baker's account: ```shell -tezos-client drain delegate to +octez-client drain delegate to ``` or, if the destination account is different from the consensus key ```shell -tezos-client drain delegate to with +octez-client drain delegate to with ``` diff --git a/docs/alpha/sapling.rst b/docs/alpha/sapling.rst index b4a0f3d9b4fee992eceeb5441dea2ee2c93140d6..b6c7aa7113ab9ca688546d890c4d4532bef0b446 100644 --- a/docs/alpha/sapling.rst +++ b/docs/alpha/sapling.rst @@ -355,7 +355,7 @@ hierarchical deterministic wallets. As usual, in this case it is important to note the derivation path of the key to be able to recover it in case of loss. At the moment there is no hardware wallet support, keys are stored in -`~/.tezos-client/sapling_keys` by default encrypted with a password. +`~/.octez-client/sapling_keys` by default encrypted with a password. **Users should take care to backup this file.** The client can also derive addresses from viewing keys. @@ -455,7 +455,7 @@ The update is done using the RPCs to recover the new updates since the last known position. The state of all sapling contracts is stored in -`~/.tezos-client/sapling_states`. This file can be regenerated from +`~/.octez-client/sapling_states`. This file can be regenerated from the chain in case of loss. However disclosure of this file will reveal the balance and the unspent outputs of all viewing keys. @@ -485,7 +485,7 @@ unshielding. # set up the sandbox ./src/bin_node/octez-sandboxed-node.sh 1 --connections 0 & eval `./src/bin_client/octez-init-sandboxed-client.sh 1` - tezos-activate-alpha + octez-activate-alpha # originate the contract with its initial empty sapling storage, # bake a block to include it. diff --git a/docs/alpha/transaction_rollups.rst b/docs/alpha/transaction_rollups.rst index 3bc2278b5d0221c55b0793a8c86d6bb4d7967db9..b9ded3d941620d9787db9abd7f45ca1e261f07f0 100644 --- a/docs/alpha/transaction_rollups.rst +++ b/docs/alpha/transaction_rollups.rst @@ -653,7 +653,7 @@ These operations notably includes: - Posting rejections (``--rejection-signer``) These various command-line arguments accept the Tezos implicit account -aliases registered in the ``~/.tezos-client`` directory. +aliases registered in the ``~/.octez-client`` directory. Note that the same keys can be used to sign several kind of layer-1 operations. diff --git a/docs/developer/proposal_testing.rst b/docs/developer/proposal_testing.rst index 78bbc809f08ada9dadbefe9b97a8cf72720086d3..9dfa4c8d8d08d05a0147d3ae3293737f7e9dc45b 100644 --- a/docs/developer/proposal_testing.rst +++ b/docs/developer/proposal_testing.rst @@ -43,7 +43,7 @@ By default, the sandbox starts from the `genesis` block at level 0, and the sandbox's active protocol is the `Genesis protocol`. Once the sandbox is started, the Alpha protocol can be activated by invoking the command:: - $ tezos-activate-alpha + $ octez-activate-alpha This command inserts a new block after which the active protocol is the Alpha protocol. From this point on, making the chain progress is straightforward @@ -495,7 +495,7 @@ We can also start the client:: $ eval `./src/bin_client/octez-init-sandboxed-client.sh 1` -Instead of command ``tezos-activate-alpha``, the sandboxed client script +Instead of command ``octez-activate-alpha``, the sandboxed client script ``src/bin_client/octez-init-sandboxed-client.sh`` now accepts a command ``tezos-activate-XXX-`` that activates the predecessor protocol with version number ``XXX`` and short hash ````. In our example, the diff --git a/docs/doc_gen/errors/dune b/docs/doc_gen/errors/dune index 26e26812abea7626371b4521121f243a09e1a8b6..0b7faa154e87e8f3b7006649eb658277f7fc2215 100644 --- a/docs/doc_gen/errors/dune +++ b/docs/doc_gen/errors/dune @@ -2,7 +2,7 @@ (name error_doc) (libraries data-encoding tezos-shell - tezos-client-alpha) + octez-client-alpha) (flags (:standard -open Tezos_base -open Tezos_error_monad -open Data_encoding diff --git a/docs/introduction/compile-sources.sh b/docs/introduction/compile-sources.sh index 54f250ee436315697222b181b4ef49002ed5a249..44e68cf2144c70916a06ce40104efc172aa6f9d5 100755 --- a/docs/introduction/compile-sources.sh +++ b/docs/introduction/compile-sources.sh @@ -64,7 +64,7 @@ make # removes Mainnet/testnet disclaimers: # export TEZOS_CLIENT_UNSAFE_DISABLE_DISCLAIMER=Y # [test executables] -./tezos-client --version +./octez-client --version ./tezos-node --version ./tezos-baker-alpha --version ./tezos-accuser-alpha --version diff --git a/docs/introduction/howtoget.rst b/docs/introduction/howtoget.rst index e2fa5df66d2b6d0e3fc5a13b22c48ddd7b5755e6..2d7024abf1b7107d0b82fecd88198def380f6bd6 100644 --- a/docs/introduction/howtoget.rst +++ b/docs/introduction/howtoget.rst @@ -169,11 +169,11 @@ You can open a new shell session and run ``docker ps`` in it, to display all the 3ee7fcbc2158 docker.io/tezos/tezos:latest tezos-accuser 3 minutes ago Up 35 seconds ago accuser-alpha -The node's RPC interface will be available on localhost and can be queried with ``tezos-client``. +The node's RPC interface will be available on localhost and can be queried with ``octez-client``. :: - docker exec node-alpha tezos-client rpc list + docker exec node-alpha octez-client rpc list Building Docker Images Locally ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/introduction/howtouse.rst b/docs/introduction/howtouse.rst index 2a127662492e1b944f8ad5f5b406319ee0016340..270ca1992d5055784d5fc5a1f60680e56de1f148 100644 --- a/docs/introduction/howtouse.rst +++ b/docs/introduction/howtouse.rst @@ -275,7 +275,7 @@ To check the account (also called a contract) for Alice has been created:: $ octez-client list known contracts -You will notice that the client data directory (by default, ``~/.tezos-client``) has been populated with +You will notice that the client data directory (by default, ``~/.octez-client``) has been populated with 3 files ``public_key_hashs``, ``public_keys`` and ``secret_keys``. The content of each file is in JSON and keeps the mapping between aliases (e.g., ``alice``) and the kind of keys indicated by the name @@ -619,7 +619,7 @@ Environment variables for the client The behavior of the client can be configured using the following environment variables: - `TEZOS_CLIENT_UNSAFE_DISABLE_DISCLAIMER`: Setting this variable to "YES" (or: "yes", "Y", "y") disables the warning displayed by the client at startup when it is not launched on Mainnet. -- `TEZOS_CLIENT_DIR`: This variable may be used to supply the client data directory (by default, ``~/.tezos-client``). +- `TEZOS_CLIENT_DIR`: This variable may be used to supply the client data directory (by default, ``~/.octez-client``). Its value is overridden by option ``-d``. - `TEZOS_SIGNER_*`: These variables are used for connecting the client to a remote :ref:`signer ` (see there for details). - `TEZOS_CLIENT_RPC_TIMEOUT_SECONDS`: This variable controls how long (in seconds, as an integer) diff --git a/docs/introduction/install-bin-fedora.sh b/docs/introduction/install-bin-fedora.sh index 4f4a18f4076aef8bb047e6b9fa8c14b5c43b9178..92c45a7c905185f7f02c7b1539466f519c0a61d4 100755 --- a/docs/introduction/install-bin-fedora.sh +++ b/docs/introduction/install-bin-fedora.sh @@ -29,12 +29,12 @@ set -x dnf install -y dnf-plugins-core # [install tezos] dnf copr enable -y $REPO && dnf update -y -dnf install -y tezos-client +dnf install -y octez-client dnf install -y tezos-node dnf install -y tezos-baker-014-PtKathma dnf install -y tezos-accuser-014-PtKathma # [test executables] -tezos-client --version +octez-client --version tezos-node --version tezos-baker-014-PtKathma --version tezos-accuser-014-PtKathma --version diff --git a/docs/introduction/install-bin-ubuntu.sh b/docs/introduction/install-bin-ubuntu.sh index 5ca480c786d8ff8cd030924807e9fd26ee0ee4b4..0fa45c35838d6f117f6673db1446fe7e3ca3b8be 100755 --- a/docs/introduction/install-bin-ubuntu.sh +++ b/docs/introduction/install-bin-ubuntu.sh @@ -31,12 +31,12 @@ apt-get install sudo apt-get install -y software-properties-common `` and ``tezos-client rpc format +command ``octez-client rpc list `` and ``octez-client rpc format ``. @@ -401,15 +401,15 @@ This section explains how to interact with the manager.tz contract that all exis will have after the migration. Wallets can either urge their users to migrate to use implicit accounts or can support implicit accounts as well as scriptful KT1s. -The ``tezos-client`` has been updated to be mostly backwards compatible, and the below explanations -are mostly directed at RPC users and the invocation of the ``tezos-client`` are given as +The ``octez-client`` has been updated to be mostly backwards compatible, and the below explanations +are mostly directed at RPC users and the invocation of the ``octez-client`` are given as examples. To set delegate using the manager.tz script, one can use: .. code-block:: bash - tezos-client transfer 0 from to \ + octez-client transfer 0 from to \ --entrypoint 'do' \ --arg '{ DROP ; NIL operation ; PUSH key_hash "" ; SOME ; SET_DELEGATE ; CONS }' @@ -422,7 +422,7 @@ To remove delegate, use: .. code-block:: bash - tezos-client transfer 0 from to \ + octez-client transfer 0 from to \ --entrypoint 'do' \ --arg '{ DROP ; NIL operation ; NONE key_hash ; SET_DELEGATE ; CONS }' @@ -434,7 +434,7 @@ To transfer (spend) tezos from originated contract to an implicit account, use: .. code-block:: bash - tezos-client transfer 0 from to \ + octez-client transfer 0 from to \ --entrypoint 'do' \ --arg '{ DROP ; NIL operation ; PUSH key_hash "" ; IMPLICIT_ACCOUNT ; PUSH mutez ; UNIT ; TRANSFER_TOKENS ; CONS }' @@ -448,7 +448,7 @@ To transfer tezos from originated contract to another originated contract, use: .. code-block:: bash - tezos-client transfer 0 from to \ + octez-client transfer 0 from to \ --entrypoint 'do' \ --arg '{ DROP ; NIL operation ; PUSH address ; CONTRACT % ; ASSERT_SOME ; PUSH mutez ; ; TRANSFER_TOKENS ; CONS }' @@ -521,7 +521,7 @@ To set delegate using the added entrypoint, one can use: .. code-block:: bash - tezos-client transfer 0 from to \ + octez-client transfer 0 from to \ --entrypoint 'set_delegate' \ --arg '""' @@ -534,7 +534,7 @@ To remove delegate, use: .. code-block:: bash - tezos-client transfer 0 from to \ + octez-client transfer 0 from to \ --entrypoint 'remove_delegate' \ --arg 'Unit' # arg is optional, it defaults to Unit when omitted @@ -544,7 +544,7 @@ To remove delegate, use: Please note, that you are not allowed to transfer tokens on ``%do``, ``%set_delegate``, or ``%remove_delegate`` entrypoints calls. Invoke these -entrypoints with ``tezos-client transfer 0``. +entrypoints with ``octez-client transfer 0``. Gas cost changes ^^^^^^^^^^^^^^^^ @@ -1189,9 +1189,9 @@ Migration the newly introduced `CHAIN_ID` instruction in order to add extra replay protection between the main chain and the test chain. - Smart contract users that do not use the `tezos-client` but a custom + Smart contract users that do not use the `octez-client` but a custom tool to interact with multi-signature contracts deployed with the - `tezos-client` should also include the `CHAIN_ID` in the commands they + `octez-client` should also include the `CHAIN_ID` in the commands they sign. - Proto/Migration: migrate KT1s with and without script @@ -1207,23 +1207,23 @@ Migration with `%set_delegate` and `%remove_delegate` entrypoints. Interacting with converted contracts must now be done via smart - contract calls. As an example, here is how `tezos-client` handles + contract calls. As an example, here is how `octez-client` handles retro-compatibility for the `transfer` and `set delegate` commands. When crafting a transaction, if the source is a KT1, if checks that its storage is either of type `key_hash` or `pair key_hash _`, and retrieve this `key_hash`. Let's name this `key_hash` . - To implement `tezos-client set delegate for to `, + To implement `octez-client set delegate for to `, it starts by looking for entrypoints. If `%set_delegate` is present, it does the equivalent of - 'tezos-client transfer 0 from to \ + 'octez-client transfer 0 from to \ --entrypoint 'set_delegate' --arg '' where is the key_hash found in the contract's storage If `%do` is present, it does the equivalent of - 'tezos-client transfer 0 from to \ + 'octez-client transfer 0 from to \ --entrypoint 'do' \ --arg '{ NIL operation ; \ PUSH key_hash ; \ @@ -1232,11 +1232,11 @@ Migration CONS }' where is the key_hash found in the contract's storage - To implement `tezos-client transfer from to `, + To implement `octez-client transfer from to `, when the destination is a simple address or a contract of type `unit`, it does the equivalent of ``` - tezos-client transfer 0 from to \ + octez-client transfer 0 from to \ --entrypoint "do" \ --arg '{ NIL operation ; \ PUSH address ; \ @@ -1248,7 +1248,7 @@ Migration PAIR }' ``` - To implement `tezos-client transfer from to \ + To implement `octez-client transfer from to \ [--arg ] [--entrypoint ]`, it starts by checking that the contract has a `%do` entrypoint. @@ -1256,7 +1256,7 @@ Migration And it does the equivalent of ``` - tezos-client transfer 0 from to \ + octez-client transfer 0 from to \ --entrypoint "do" \ --arg '{ NIL operation ; \ PUSH address ; \ diff --git a/docs/protocols/007_delphi.rst b/docs/protocols/007_delphi.rst index 4280ffdf41bee48c474e3b8eb425faa20f136bcc..dae18902f64335779e391828d6d73b200b859add 100644 --- a/docs/protocols/007_delphi.rst +++ b/docs/protocols/007_delphi.rst @@ -155,7 +155,7 @@ Let us originate this contract. :: - tezos-client -l originate contract mini transferring 0 from bootstrap1 running minimal.tz --burn-cap 0.07375 --init 'Unit' + octez-client -l originate contract mini transferring 0 from bootstrap1 running minimal.tz --burn-cap 0.07375 --init 'Unit' During simulation, the ``preapply`` RPC is given the following operation: @@ -199,7 +199,7 @@ corresponding to the **exact** amount of gas consumed, labelled in **milligas**; - the field ``consumed_gas``, obtained by ceiling the milligas value as described above, labelled in **gas**. -Note that the ``tezos-client`` binary prints gas, not milligas. However +Note that the ``octez-client`` binary prints gas, not milligas. However it displays three decimals: :: diff --git a/docs/protocols/009_florence.rst b/docs/protocols/009_florence.rst index 3c528f0e7dc29f594c8e11b400df9f658ba15327..11438b47b0aa7a3952fddadb40f41b93489f9707 100644 --- a/docs/protocols/009_florence.rst +++ b/docs/protocols/009_florence.rst @@ -79,7 +79,7 @@ New ``failing_noop`` Operation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A new operation has been added to the protocol that is guaranteed to -fail. This feature can be used by tooling (such as ``tezos-client``) to +fail. This feature can be used by tooling (such as ``octez-client``) to sign arbitrary data securely, without fear of malicious injection into future protocols. diff --git a/docs/protocols/tenderbake.rst b/docs/protocols/tenderbake.rst index 66f42092440c70eecf8c1be89e3a9d80ab62831d..39a24c32e713ed1114d987e696a3a13ba8fa9194 100644 --- a/docs/protocols/tenderbake.rst +++ b/docs/protocols/tenderbake.rst @@ -275,19 +275,19 @@ The baker daemon takes the same options as in Hangzhou. Client ------ -The command ``tezos-client bake for`` has been changed: +The command ``octez-client bake for`` has been changed: - It takes a (possibly empty) list of delegate references. It then bakes a block and (pre)endorses this block, using the rights of all the specified delegates. When the list is empty is does so for all delegates whose secret keys are known. - It performs a full consensus round: it "proposes" a block (that is, it injects a block candidate), it preendorses the block, and it endorses the block, if possible. The following commands have been added: -- ``tezos-client propose for``: forge and inject a candidate block (a `proposal`). +- ``octez-client propose for``: forge and inject a candidate block (a `proposal`). -- ``tezos-client preendorse for``: forge and inject a preendorsement operation. +- ``octez-client preendorse for``: forge and inject a preendorsement operation. -- ``tezos-client endorse for``: forge and inject an endorsement operation. +- ``octez-client endorse for``: forge and inject an endorsement operation. -- ``tezos-client set deposits limit for to ``: sets the deposits limit for a registered delegate. +- ``octez-client set deposits limit for to ``: sets the deposits limit for a registered delegate. -- ``tezos-client unset deposits limit for ``: remove the deposits limit of a registered delegate. +- ``octez-client unset deposits limit for ``: remove the deposits limit of a registered delegate. diff --git a/docs/releases/version-10.rst b/docs/releases/version-10.rst index baea0baded15e3af809c2066368631f61ed61e46..4e93f4b9409cc5443d52fc27b12eb7452669fefd 100644 --- a/docs/releases/version-10.rst +++ b/docs/releases/version-10.rst @@ -138,7 +138,7 @@ Some of the previous instructions require you to export a snapshot. Here is how to do so. You may also just download a recent snapshot instead. -- Get the hash of the current block using: ``./tezos-client rpc get +- Get the hash of the current block using: ``./octez-client rpc get /chains/main/blocks/head | grep 'hash\": \"BL'`` (or simply find the hash in the logs of your running node). diff --git a/docs/shell/the_big_picture.rst b/docs/shell/the_big_picture.rst index 69320973c1dd69b47e83e736b64914dbf66b8328..4aef1374aa65955be6f76143a1e58c53956fdf97 100644 --- a/docs/shell/the_big_picture.rst +++ b/docs/shell/the_big_picture.rst @@ -250,7 +250,7 @@ The client is split into many packages, to enforce three separation lines: shell vs economic protocol, Unix dependent vs JavaScript compatible, and library vs command-line interface. - - :package:`tezos-client-base` defines the client context, which is + - :package:`octez-client-base` defines the client context, which is an object whose methods allow for: accessing a wallet of keys, interacting via the user, making RPC calls, and signing data using signer plug-ins. Most of them, including RPC calling functions from @@ -258,12 +258,12 @@ compatible, and library vs command-line interface. :package:`tezos-protocol-alpha`, are abstracted over this object type. That way, it is possible to use the same code for different platforms or toolkits. - - :package:`tezos-client-alpha` provides some functions to perform + - :package:`octez-client-alpha` provides some functions to perform the operations of protocol Alpha using the wallet and signers from the client context. - - :package:`tezos-client-genesis` contains the basic activator + - :package:`octez-client-genesis` contains the basic activator commands available on the genesis protocol. - - :package:`tezos-client-base-unix` implements configuration file + - :package:`octez-client-base-unix` implements configuration file and wallet storage in Unix files, user interaction via the Unix console, and terminal based signer plug-ins. diff --git a/docs/user/key-management.rst b/docs/user/key-management.rst index 429b21bcd6b3c508eca7d163caba24e40f91f91e..ae872106d954fffc481f37af117dfd49e1fb5040 100644 --- a/docs/user/key-management.rst +++ b/docs/user/key-management.rst @@ -213,7 +213,7 @@ signer and it is not used as a Tezos account. :: vps~$ octez-client gen keys vps - vps~$ cat ~/.tezos-client/public_keys + vps~$ cat ~/.octez-client/public_keys [ { "name": "vps", "value": "unencrypted:edpk123456789" } ] @@ -266,7 +266,7 @@ foundation. octez-client activate fundraiser account alice with -Like explained above, your keys are stored under ``~/.tezos-client``. +Like explained above, your keys are stored under ``~/.octez-client``. We strongly advice you to first **make a backup** and then transfer your tokens to a new pair of keys imported from a ledger (see :ref:`ledger`). diff --git a/docs/user/light.rst b/docs/user/light.rst index f42dda6af5d4798305b82ae14bb846c07f986683..1daef4d642556427840df0c8766c99aa5733b49d 100644 --- a/docs/user/light.rst +++ b/docs/user/light.rst @@ -104,7 +104,7 @@ Then upgrade the node to protocol alpha: :: - $ tezos-activate-alpha # Triggers output in terminal of first node + $ octez-activate-alpha # Triggers output in terminal of first node $ octez-client bake for bootstrap1 # Triggers output in terminal of first node To avoid warnings being printed in upcoming commands (optional): diff --git a/docs/user/mockup.rst b/docs/user/mockup.rst index a50478f3d12290b9beed95770fe159290693fe66..10f720039e39f5b1fe6557424e7a37b9488a8c22 100644 --- a/docs/user/mockup.rst +++ b/docs/user/mockup.rst @@ -472,5 +472,5 @@ This is mostly useful for protocol developers, but also for other developers, e. See also ======== -This tutorial has also served as a base for `a nice blog post `__, written in a more casual way and intended for a larger audience of application developers. +This tutorial has also served as a base for `a nice blog post `__, written in a more casual way and intended for a larger audience of application developers. Of course, some aspects may gradually become outdated in the blog version. diff --git a/docs/user/proxy-server.rst b/docs/user/proxy-server.rst index d168ed197802d0e2c10b5693418cbd0b1b8a98b8..ba523c52dd96c74bd4e78a0863b999d94e0f70b5 100644 --- a/docs/user/proxy-server.rst +++ b/docs/user/proxy-server.rst @@ -78,7 +78,7 @@ Then upgrade the node to protocol alpha: :: - $ tezos-activate-alpha + $ octez-activate-alpha $ octez-client bake for bootstrap1 To avoid warnings being printed in upcoming commands (optional): diff --git a/docs/user/proxy.rst b/docs/user/proxy.rst index 3c4909f5edc538537441d4d31a13bc4b2c51e928..961b590f47500bb049da12acb23e757da8705ade 100644 --- a/docs/user/proxy.rst +++ b/docs/user/proxy.rst @@ -56,7 +56,7 @@ Then upgrade the node to protocol alpha: :: - $ tezos-activate-alpha + $ octez-activate-alpha $ octez-client bake for bootstrap1 To avoid warnings being printed in upcoming commands (optional): diff --git a/docs/user/sandbox.rst b/docs/user/sandbox.rst index 82afef2c5d9f7b360c33f69471781af3f916cdbb..2c9fb74969cefda7bd0083f4430cb4af42bbed23 100644 --- a/docs/user/sandbox.rst +++ b/docs/user/sandbox.rst @@ -56,7 +56,7 @@ preconfigured for communicating with the same-numbered node. When you bootstrap a new network, the network is initialized with a dummy economic protocol, called `genesis`. If you want to run the whole implemented protocol, ``init-sandboxed-client`` also defines an -alias ``tezos-activate-alpha``, that you need to execute once for +alias ``octez-activate-alpha``, that you need to execute once for activating the whole network. For instance: @@ -64,7 +64,7 @@ For instance: $ octez-client rpc get /chains/main/blocks/head/metadata "next_protocol": "Ps9mPmXaRzmzk35gbAYNCAw6UXdE2qoABTHbN2oEEc1qM7CwT9P" - $ tezos-activate-alpha + $ octez-activate-alpha Injected BMV9KnSPE1yw $ octez-client rpc get /chains/main/blocks/head/metadata "protocol": "Ps9mPmXaRzmzk35gbAYNCAw6UXdE2qoABTHbN2oEEc1qM7CwT9P" @@ -115,7 +115,7 @@ binary. Tune protocol Alpha parameters ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The ``tezos-activate-alpha`` alias uses parameters from +The ``octez-activate-alpha`` alias uses parameters from ``src/proto_alpha/parameters/sandbox-parameters.json`` to activate protocol Alpha. It can be useful to tune these parameters when you need to debug something, for example, change the number of blocks per cycle, the time between