From 650efae8f035748a0a33614223a5e2cfa3211f08 Mon Sep 17 00:00:00 2001 From: Soham Chowdhury Date: Mon, 7 Nov 2022 11:29:29 +0100 Subject: [PATCH] docs: rename some instances of 'tezos-*' to 'octez-*' --- docs/CHANGES.rst | 14 ++++----- docs/alpha/sapling.rst | 6 ++-- docs/alpha/transaction_rollups.rst | 2 +- docs/developer/proposal_testing.rst | 4 +-- docs/doc_gen/errors/dune | 2 +- docs/introduction/compile-sources.sh | 2 +- docs/introduction/howtoget.rst | 4 +-- docs/introduction/howtouse.rst | 4 +-- docs/introduction/install-bin-fedora.sh | 4 +-- docs/introduction/install-bin-ubuntu.sh | 4 +-- docs/introduction/install-opam.sh | 2 +- docs/kathmandu/sapling.rst | 6 ++-- docs/kathmandu/transaction_rollups.rst | 2 +- docs/lima/sapling.rst | 6 ++-- docs/lima/transaction_rollups.rst | 2 +- docs/protocols/003_PsddFKi3.rst | 2 +- docs/protocols/004_Pt24m4xi.rst | 2 +- docs/protocols/005_babylon.rst | 40 ++++++++++++------------- docs/protocols/007_delphi.rst | 4 +-- docs/protocols/009_florence.rst | 2 +- docs/protocols/tenderbake.rst | 12 ++++---- docs/releases/version-10.rst | 2 +- docs/shell/the_big_picture.rst | 8 ++--- docs/user/key-management.rst | 4 +-- docs/user/light.rst | 2 +- docs/user/mockup.rst | 2 +- docs/user/proxy-server.rst | 2 +- docs/user/proxy.rst | 2 +- docs/user/sandbox.rst | 6 ++-- 29 files changed, 77 insertions(+), 77 deletions(-) diff --git a/docs/CHANGES.rst b/docs/CHANGES.rst index 561bac2a3c73..18228f4f2c7f 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 b4a0f3d9b4fe..b6c7aa7113ab 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 3bc2278b5d02..b9ded3d94162 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 78bbc809f08a..9dfa4c8d8d08 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 26e26812abea..0b7faa154e87 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 54f250ee4363..44e68cf2144c 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 e2fa5df66d2b..2d7024abf1b7 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 2a127662492e..270ca1992d50 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 4f4a18f4076a..92c45a7c9051 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 5ca480c786d8..0fa45c35838d 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 4280ffdf41be..dae18902f643 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 3c528f0e7dc2..11438b47b0aa 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 66f42092440c..39a24c32e713 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 baea0baded15..4e93f4b9409c 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 69320973c1dd..4aef1374aa65 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 429b21bcd6b3..ae872106d954 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 f42dda6af5d4..1daef4d64255 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 a50478f3d122..10f720039e39 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 d168ed197802..ba523c52dd96 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 3c4909f5edc5..961b590f4750 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 82afef2c5d9f..2c9fb74969ce 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 -- GitLab