diff --git a/docs/tutorials.mdx b/docs/tutorials.mdx index 4f5120747..ba78cbd65 100644 --- a/docs/tutorials.mdx +++ b/docs/tutorials.mdx @@ -134,7 +134,7 @@ These tutorials are intended for developers who are familiar with Tezos and want /> +## Prerequisites + +This tutorial requires a cloud-based computer or a computer that stays running constantly. + ## References - For an overview of the DAL, see [Data Availability Layer](../architecture/data-availability-layer). - For an introduction to how the DAL works, see the tutorial [Implement a file archive with the DAL and a Smart Rollup](./build-files-archive-with-dal). - For technical information about the DAL, see [Data-Availability Layer](https://tezos.gitlab.io/shell/dal.html) in the Octez documentation. -:::warning -This tutorial uses a very simple setup running all required daemons on the same machine. In a production environment, we advise against running a DAL attester node under the same IP address than a baker's node because the DAL node may leak the IP address and ease DOS attacks on the baker. See also [the DAL documentation page on baking](https://tezos.gitlab.io/shell/dal_bakers.html). -::: - -:::warning -The UX of the DAL components will be subject to changes with the feedback from the testers following this tutorial, so this tutorial will be updated accordingly. Feel free to file issues if it's not up-to-date. -::: +## Getting started -- [Step 1: Get a Weeklynet-compatible Octez version](./join-dal-baker/get-octez) -- [Step 2: Run an Octez node on Weeklynet](./join-dal-baker/run-node) -- [Step 3: Set up a baker account on Weeklynet](./join-dal-baker/prepare-account) -- [Step 4: Run an Octez DAL node on Weeklynet](./join-dal-baker/run-dal-node) -- [Step 5: Run an Octez baking daemon on Weeklynet](./join-dal-baker/run-baker) -- [Conclusion](./join-dal-baker/conclusion) +To get started, go to [Step 1: Run an Octez node](./join-dal-baker/run-node). diff --git a/docs/tutorials/join-dal-baker/conclusion.md b/docs/tutorials/join-dal-baker/conclusion.md index afb66d3ac..752233b91 100644 --- a/docs/tutorials/join-dal-baker/conclusion.md +++ b/docs/tutorials/join-dal-baker/conclusion.md @@ -2,7 +2,15 @@ title: "Conclusion" authors: Tezos core developers last_update: - date: 23 January 2024 + date: 13 August 2024 --- -In this tutorial we have gone through all the steps needed to participate in the Weeklynet test network as a baker and DAL attester. We could further improve the setup by defining system services so that the daemons are automatically launched when the machine starts or when the network restarts on Wednesday. We could also plug a monitoring solution such as the Prometheus + Grafana combo; a Grafana dashboard template for DAL nodes is available in Grafazos. The interactions between our baker and the Weeklynet chain can be observed on the Explorus block explorer which is aware of the DAL and can in particular display which DAL slots are being used at each level. +In this tutorial you have gone through all the steps needed to participate as a baker and DAL node. +The steps for participating on any other network, including Tezos Mainnet, are similar, but other networks have different parameters. +For example, the attestation delay on Mainnet is 2 weeks. + +You could further improve the setup by defining system services so that the daemons are automatically launched when the machine starts. +You could also plug a monitoring solution such as the Prometheus + Grafana combo; a Grafana dashboard template for DAL nodes is available in Grafazos. +The interactions between your baker and the chain can be observed on the Explorus block explorer which is aware of the DAL and can in particular display which DAL slots are being used at each level. + +As a next step, you can create a Smart Rollup that uses DAL data in the tutorial [Implement a file archive with the DAL and a Smart Rollup](../build-files-archive-with-dal). diff --git a/docs/tutorials/join-dal-baker/get-octez.md b/docs/tutorials/join-dal-baker/get-octez.md deleted file mode 100644 index ef7b06a22..000000000 --- a/docs/tutorials/join-dal-baker/get-octez.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Step 1: Get a Weeklynet-compatible Octez version" -authors: Tezos core developers -last_update: - date: 28 February 2024 ---- - -The Weeklynet test network restarts every Wednesday at 0h UTC, and for most of its lifetime (from level 512) it runs a development version of the Tezos protocol, called Alpha, which is not part of any released version of Octez. -To work with Weeklynet, you must use the exact same version of the Octez suite that Weeklynet is using. - -The easiest way to do this is to use the Docker image that is generated each time Weeklynet is reset and recreated. -As another option, you can build the specific version of the Octez suite locally. -For instructions, see the Weeklynet page at https://teztnets.com/weeklynet-about. - -To set up an environment and account in a Docker container, follow these steps: - -1. From the [Weeklynet](https://teztnets.com/weeklynet-about) page, find the Docker command to create a container from the correct Docker image. -For example, the command to start a Docker image for the Weeklynet launched on January 17 2024 was: - - ```bash - docker run -it --entrypoint=/bin/sh tezos/tezos:master_7f3bfc90_20240116181914 - ``` - - The image tag in this command changes each time the network is reset. - -1. In the container, initialize the Octez node with the command on the Weeklynet page, such as this example: - - ```bash - octez-node config init --network https://teztnets.com/weeklynet-2024-01-17 - ``` - - The specific command is on the Weeklynet page at https://teztnets.com/weeklynet-about. - -Now you have the Octez node configured to work with Weeklynet. -The next step is to start the Octez node; continue to [Step 2: Run an Octez node on Weeklynet](./run-node). diff --git a/docs/tutorials/join-dal-baker/prepare-account.md b/docs/tutorials/join-dal-baker/prepare-account.md index 99c33facc..4144fef62 100644 --- a/docs/tutorials/join-dal-baker/prepare-account.md +++ b/docs/tutorials/join-dal-baker/prepare-account.md @@ -1,16 +1,30 @@ --- -title: "Step 3: Set up a baker account on Weeklynet" -authors: Tezos core developers +title: "Step 2: Set up a baker account" +authors: Tezos core developers, Tim McMackin last_update: - date: 6 March 2024 + date: 19 August 2024 --- -Our baker needs a user account consisting of a pair of keys and an address. -In this section, you use the Octez client to create an account and register it as a delegate. +The baker needs a user account that stakes tez. +In this section, you use the Octez client to create an account, register it as a delegate, and stake tez with it. -1. Open a new terminal window in the same environment. -If you are using a Docker container, you can enter the container with the `docker exec` command, as in `docker exec -it my-image /bin/sh`. -To get the name of the Docker container, you run the `docker ps` command. +1. Connect the Octez client to your node by running this command: + + ```bash + octez-client -E http://localhost:8732 config update + ``` + + If you see an error that says "Failed to acquire the protocol version from the node," ensure that your node is running and verify that the host name and port in the `config update` command are correct. + +1. Make sure that the installation of the Octez client is using your node by running this command: + + ```bash + octez-client bootstrapped + ``` + + The client waits until it is connected and the node is running at the current level. + When it is connected and the node is updated, the command prints the message `Node is bootstrapped`. + The time it takes depends on how many blocks the node must retrieve to catch up from the snapshot to the current head block. 1. Optional: Hide the Octez client's network warning message by running this command: @@ -21,7 +35,7 @@ To get the name of the Docker container, you run the `docker ps` command. This command suppresses the message that your instance of the Octez client is not using Mainnet. 1. Create or import an account in the Octez client. -The simplest way to get an account that works with Weeklynet is to use the Octez client to randomly generate an account. +The simplest way to get an account is to use the Octez client to randomly generate an account. This command creates an account and associates it with the `my_baker` alias: ```bash @@ -34,31 +48,18 @@ This command creates an account and associates it with the `my_baker` alias: octez-client show address my_baker ``` -1. Record this address in a shell variable so you can use it for commands that cannot get addresses by their Octez client aliases: - - ```bash - MY_BAKER="$(octez-client show address my_baker | head -n 1 | cut -d ' ' -f 2)" - ``` - At this point, the balance of the `my_baker` account is still zero, as you can see by running this command: ```bash octez-client get balance for my_baker ``` - If you get an error on this command, your local node isn't ready yet. - Until the node has finished bootstrapping, pass the public RPC endpoint for Weeklynet in the `--endpoint` argument, as in this example: - - ```bash - octez-client --endpoint https://rpc.weeklynet-2024-01-17.teztnets.com get balance for my_baker - ``` - - Don't set the client endpoint to the public node permanently because it should use your local node whenever possible. - For bakers, it's important to set the Octez client to use their node rather than a public node because the baker daemon uses the client configuration and the baker daemon should use the local node. +1. Get at least 6,000 tez from the Ghostnet faucet. -1. Get some tez from the Weeklynet faucet. + The account must stake tez to get consensus and DAL rights. + To get tez, use the Ghostnet faucet linked from https://teztnets.com/ghostnet-about to send tez to the baker account. - In order to get some consensus and DAL rights, we need to put some tez in the account. Fortunately, getting free testnet tez is easy thanks to the testnet faucet. To use it, we need to enter the generated address in the Weeklynet faucet linked from https://teztnets.com/weeklynet-about. We need at least 6k tez for running a baker but the more tez we have the more rights we will get and the shorter we will have to wait to produce blocks and attestations. That being said, baking with too much stake prevents us from leaving the network without disturbing or even halting it so to avoid breaking the network for all other testers let's not be too greedy. 50k tez is enough to get enough rights to easily check if our baker behaves as expected while not disturbing the network too much when our baker stops operating. + Running a baker requires staking at least 6,000 tez, but the more tez it stakes, the more rights it gets and the less time it has to wait to produce blocks and make attestations. 1. Verify that the faucet sent the tez to the account with the same `get balance` command: @@ -66,7 +67,10 @@ This command creates an account and associates it with the `my_baker` alias: octez-client get balance for my_baker ``` - At this point, the `my_baker` account owns enough stake to bake but has still no consensus or DAL rights because we haven't declared our intention to become a baker to the Tezos protocol. + If the balance still shows 0, the local node may not be ready yet. + In this case you can temporarily use the public RPC endpoint. + + When the account receives its tez, it owns enough stake to bake but has still no consensus or DAL rights because it has not declared its intention to become a baker. 1. Register your account as a delegate by running the following command: @@ -74,41 +78,13 @@ This command creates an account and associates it with the `my_baker` alias: octez-client register key my_baker as delegate ``` - Again, pass the `--endpoint` argument if your node has not finished bootstrapping. - -1. Stake the tez, saving a small amount for transaction fees. -For example, if your account has 50k tez, stake 49990 tez by running this command: - - ```bash - octez-client stake 49990 for my_baker - ``` - - Seven cycles later (about 1h40 on Weeklynet), our baker will start receiving rights. To see for instance its consensus attestation rights in the current cycle, we can use the following RPC call: - - ```bash - octez-client rpc get /chains/main/blocks/head/helpers/attestation_rights\?delegate="$MY_BAKER" - ``` - - When your baker has attestation rights, the previous command returns information about them, as in this example: - - ```json - [ { "level": 9484, - "delegates": - [ { "delegate": "tz1Zs6zjxtLxmff51tK2AVgvm4PNmdNhLcHE", - "first_slot": 280, "attestation_power": 58, - "consensus_key": "tz1Zs6zjxtLxmff51tK2AVgvm4PNmdNhLcHE" } ] } ] - ``` - - To see the DAL attestation rights of all bakers, we can use the following RPC call: +1. Stake at least 6,000 tez, saving a small amount for transaction fees,by running this command: ```bash - octez-client rpc get /chains/main/blocks/head/context/dal/shards + octez-client stake 6000 for my_baker ``` - This command returns an array of DAL attestation rights. The 2048 shards which are expected to be attested at this level are shared between active bakers proportionally to their stake. Each baker is assigned a slice of shard indices represented in the output of this command by a pair consisting of the first index and the length of the slice. So to check if some rights were assigned to us we can filter the array to our baker by running this command: - - ```bash - octez-client rpc get /chains/main/blocks/head/context/dal/shards | grep "$MY_BAKER" - ``` +Now the account has staked enough tez to earn the right to make attestations, including attestations that data is available on the DAL. +However, it does not receive these rights until the baking daemon is running and a certain amount of time has passed. -When attestation rights are assigned to your baker, continue to [Step 4: Run an Octez DAL node on Weeklynet](./run-dal-node.md). +While you wait for attestation rights, continue to [Step 3: Run an Octez DAL node](./run-dal-node). diff --git a/docs/tutorials/join-dal-baker/run-baker.md b/docs/tutorials/join-dal-baker/run-baker.md index 23aca1849..e157ce599 100644 --- a/docs/tutorials/join-dal-baker/run-baker.md +++ b/docs/tutorials/join-dal-baker/run-baker.md @@ -1,35 +1,93 @@ --- -title: "Step 5: Run an Octez baking daemon on Weeklynet" -authors: Tezos core developers +title: "Step 4: Run an Octez baking daemon" +authors: Tezos core developers, Tim McMackin last_update: - date: 23 January 2024 + date: 27 August 2024 --- -The baking daemon is launched almost as usual, the only difference is that we use the `--dal-node http://127.0.0.1:10732` option to tell it to connect to the DAL node that we just launched in the previous step. +Now that you have a DAL node, you can run a baking daemon that can attest to DAL data or restart an existing baking daemon to connect it to the DAL node. +1. To run a baking daemon that connects to the DAL, start it as usual and pass the URL to your DAL node to it with the `--dal-node` argument: -```bash -octez-baker-alpha run with local node "$HOME/.tezos-node" my_baker --liquidity-baking-toggle-vote on --adaptive-issuance-vote on --dal-node http://127.0.0.1:10732 >> "$HOME/octez-baker.log" 2>&1 -``` + ```bash + octez-baker-PsParisC run with local node "$HOME/.tezos-node" my_baker --liquidity-baking-toggle-vote pass --adaptive-issuance-vote on --dal-node http://127.0.0.1:10732 >> "$HOME/octez-baker.log" 2>&1 + ``` -We can check that the DAL is now subscribed to the relevant topics by retrying the following RPC call, which should now return all the topics of the form `{"slot_index":,"pkh":"
"}` where `index` varies between `0` included and the number of slot indexes (`32` on Weeklynet) excluded: +1. Ensure that the baker runs persistently. +Look up how to run programs persistently in the documentation for your operating system. +You can also refer to [Run a persistent baking node](https://opentezos.com/node-baking/baking/persistent-baker/) on opentezos.com. -```bash -curl http://localhost:10732/p2p/gossipsub/topics -``` +1. In the same terminal window, run this command: + + ```bash + curl http://localhost:10732/p2p/gossipsub/topics + ``` + + You may need to install the `curl` program. + + DAL nodes share shards and information about them over a peer-to-peer pub/sub network built on the Gossipsub P2P protocol. + As layer 1 assigns shards to the bakers, the Gossipsub network manages topics that DAL nodes can subscribe to. + For example, if a user submits data to slot 1, the network has a list of topics: a topic to identify the slot 1 shards assigned to baker A, a topic to identify the slot 1 shards assigned to baker B, and so on for all the bakers that are assigned shards from slot 1. + + Then, the baker daemon automatically asks the DAL node to subscribe to the topics that provide the shards that it is assigned to. -We can also look at the baker logs to see if it manages to inject the expected operations. At each level, the baker is expected to: -- Receive a block proposal (log message: "received new proposal ... at level ..., round ...") -- Inject a preattestation for it (log message: "injected preattestation ... for my_baker (<address>) for level ..., round ...") -- Receive a block (log message: "received new head ... at level ..., round ...") -- Inject a consensus attestation for it (log message: "injected attestation ... for my_baker (<address>) for level ..., round ...") -- Attach a DAL attestation to it, indicating which of the shards assigned to the baker have been seen on the DAL network (log message: "ready to attach DAL attestation for level ..., round ..., with bitset ... for my_baker (<address>) to attest slots published at level ...") + In the results of this command, each topic contains a shard and the address of the baker that is assigned to it. + The DAL node and baker are listening to these topics and attesting that the data that they refer to is available. -Optionally, we can also launch an accuser which will monitor the behaviour of the other Weeklynet bakers and denounce them to the Tezos protocol if they are caught double-signing any block or consensus operation. + This command returns all of the topics that the baker is subscribed to in the format `{"slot_index":,"pkh":"
"}` where `index` varies between `0` included and the number of slot indexes excluded. -```bash -octez-accuser-alpha run >> "$HOME/octez-accuser.log" 2>&1 + You can also look at the baker logs to see if it injects the expected operations. At each level, the baker is expected to: + + - Receive a block proposal (log message: "received new proposal ... at level ..., round ...") + - Inject a preattestation for it (log message: "injected preattestation ... for my_baker (<address>) for level ..., round ...") + - Receive a block (log message: "received new head ... at level ..., round ...") + - Inject a consensus attestation for it (log message: "injected attestation ... for my_baker (<address>) for level ..., round ...") + - Attach a DAL attestation to it, indicating which of the shards assigned to the baker have been seen on the DAL network (log message: "ready to attach DAL attestation for level ..., round ..., with bitset ... for my_baker (<address>) to attest slots published at level ...") + +## Calculating the delay for attestation rights + +If you are setting up a new baker, you must wait until it receives attestation rights before it can bake blocks or attest to DAL data. +The delay to receive attestation rights is a number of cycles determined by the value of the `consensus_rights_delay` constant plus two cycles. + +A cycle is a number of blocks; the `blocks_per_cycle` constant determines how many blocks are in a cycle. +The `minimal_block_delay` constant determines the time between blocks in seconds. +Therefore, you can calculate the approximate time in seconds that it takes a baker to receive attestation rights with this formula: + +``` +(consensus_rights_delay + 2) * blocks_per_cycle * minimal_block_delay ``` -Now you have a complete DAL baking setup. -For a summary, see [Conclusion](./conclusion). +Follow these steps to calculate the delay to receive attestation rights: + +1. Run these commands to get the values of the network constants: + + ```bash + octez-client rpc get /chains/main/blocks/head/context/constants | jq | grep consensus_rights_delay + ``` + + ```bash + octez-client rpc get /chains/main/blocks/head/context/constants | jq | grep blocks_per_cycle + ``` + + ```bash + octez-client rpc get /chains/main/blocks/head/context/constants | jq | grep minimal_block_delay + ``` + + You may need to install the `jq` program to run these commands. + +1. Using the values from the responses, calculate the attestation rights delay in seconds. +For example, if `consensus_rights_delay` is 3, `blocks_per_cycle` is 12,288, and `minimal_block_delay` is 5, a new baker receives attestation rights after a delay of 307,200 seconds. + +1. Divide the number of seconds by 86,400 to get the attestation delay in days. +For example, if the delay is 307,200 seconds, that time is about 3.5 days. + + The exact time depends on what time in the current cycle the account staked its tez. + +1. Wait for the attestation delay to be over and then proceed to [Step 5: Verify attestation rights](./verify-rights). + +:::note + +The amount of tez that the account stakes determines how often it is called on to make attestations, not how quickly it receives rights. +Therefore, staking more tez brings more rewards but does not reduce the attestation delay. + +::: diff --git a/docs/tutorials/join-dal-baker/run-dal-node.md b/docs/tutorials/join-dal-baker/run-dal-node.md index e82c25cb7..302007578 100644 --- a/docs/tutorials/join-dal-baker/run-dal-node.md +++ b/docs/tutorials/join-dal-baker/run-dal-node.md @@ -1,35 +1,72 @@ --- -title: "Step 4: Run an Octez DAL node on Weeklynet" -authors: Tezos core developers +title: "Step 3: Run an Octez DAL node" +authors: Tezos core developers, Tim McMackin last_update: - date: 23 January 2024 + date: 27 August 2024 --- The DAL node is responsible for temporarily storing data and providing it to bakers and Smart Rollups. -To start the DAL node, open a new terminal window in the same environment and run this command: +1. Start the DAL node by running this command: -```bash -octez-dal-node run >> "$HOME/octez-dal-node.log" 2>&1 -``` + ```bash + octez-dal-node run >> "$HOME/octez-dal-node.log" 2>&1 + ``` -This, too, may take some time to launch the first time because it needs to generate a new identity file, this time for the DAL network. + This, too, may take some time to launch the first time because it needs to generate a new identity file, this time for the DAL network. -The DAL node connects to the DAL network but it is not yet receiving shards. + If the IP address of the computer that you are running the DAL node on is not public, add the `--public-addr` argument to specify the host name and port that clients should use to connect to the DAL node. -DAL nodes share shards and information about them over a peer-to-peer pub/sub network built on the Gossipsub protocol. -As layer 1 assigns shards to the bakers, the Gossipsub network manages topics that DAL nodes can subscribe to. -For example, if a user submits data to slot 1, the network has a list of topics: a topic to identify the slot 1 shards assigned to baker A, a topic to identify the slot 1 shards assigned to baker B, and so on for all the bakers that are assigned shards from slot 1. +1. Verify that the DAL node is connected to the DAL network by running this command: -Then, the baker daemon automatically asks the DAL node to subscribe to the topic that provides the shards that it is assigned to. -You can see the topics that the DAL node is subscribed to by running this RPC call: + ```bash + curl http://localhost:10732/p2p/gossipsub/connections + ``` -```bash -curl http://localhost:10732/p2p/gossipsub/topics -``` + The response lists the network connections that the DAL node has. + It may take a few minutes for the node to connect to the DAL network. -If you are using the `tezos/tezos` Docker image, you can install the `curl` program by running the command `sudo apk add curl`. + You can also verify that the DAL node is connected by viewing its log. + When the node is bootstrapped it logs messages that look like this: -In the results, each topic contains a shard and the address of the baker that is assigned to it. -Now you can run a baker to verify these shards. -Continue to [Step 5: Run an Octez baking daemon on Weeklynet](./run-baker). + ``` + Aug 12 17:44:19.985: started tracking layer 1's node + Aug 12 17:44:24.418: layer 1 node's block at level 7538687, round 0 is final + Aug 12 17:44:29.328: layer 1 node's block at level 7538688, round 0 is final + ``` + + The DAL node waits for blocks to be finalized, so this log lags 2 blocks behind the layer 1 node's log. + + Now the DAL node is connected to the DAL network but it is not yet receiving data. + +1. Ensure that the DAL node runs persistently. +Look up how to run programs persistently in the documentation for your operating system. +You can also refer to [Run a persistent baking node](https://opentezos.com/node-baking/baking/persistent-baker/) on opentezos.com. + + For example, if your operating system uses the `systemd` software suite, your service file might look like this example: + + ```systemd + [Unit] + Description=Octez DAL node + Wants = network-online.target + After = network-online.target + Requires = octez-node.service + + [Install] + WantedBy=multi-user.target + RequiredBy = octez-baker.service + + [Service] + Type=simple + User=mybaker + ExecStart=/usr/bin/octez-dal-node run --data-dir /opt/dal + WorkingDirectory=/opt/dal + Restart=on-failure + RestartSec=5 + StandardOutput=append:/opt/dal/octez-dal-node.log + StandardError=append:/opt/dal/octez-dal-node.log + SyslogIdentifier=%n + ``` + +Now that you have a DAL node running, you can start a baking daemon that uses that DAL node. +Continue to [Step 4: Run an Octez baking daemon](./run-baker). diff --git a/docs/tutorials/join-dal-baker/run-node.md b/docs/tutorials/join-dal-baker/run-node.md index 0fc91b467..b771f5dc6 100644 --- a/docs/tutorials/join-dal-baker/run-node.md +++ b/docs/tutorials/join-dal-baker/run-node.md @@ -1,19 +1,37 @@ --- -title: "Step 2: Run an Octez node on Weeklynet" -authors: Tezos core developers +title: "Step 1: Run an Octez node" +authors: Tezos core developers, Tim McMackin last_update: - date: 24 January 2024 + date: 27 August 2024 --- -Now that the Octez node is configured to join Weeklynet, we can launch it and make its RPC available. +To use the Octez suite with Ghostnet, you need a recent build of the Octez binaries. +You can build the Octez suite from the source code or install prebuilt binaries as described at https://tezos.gitlab.io/introduction/howtoget.html. -1. Optional: If it has been a few days since Weeklynet was restarted on Wednesday morning, you can speed up the bootstrapping process by loading a snapshot: +:::note - 1. Download a snapshot of Weeklynet from https://snapshot.tzinit.org based on the instructions on that site. - For example, the command to download the snapshot may look like this: +If you already have an Octez node and baker running with a delegated account, you can skip to [Step 3: Run an Octez DAL node](./run-dal-node). + +::: + +The first step is to configure a Tezos node with the `octez-node` program: + +1. Install the Octez suite of programs, including `octez-client`, `octez-node`, and `octez-dal-node` as described in [Installing Octez](https://tezos.gitlab.io/introduction/howtoget.html) in the Octez documentation. +If you build from source, you can use the `latest_branch` branch to work with Ghostnet. + +1. Initialize the Octez node for Ghostnet, such as in this example: + + ```bash + octez-node config init --network ghostnet + ``` + +1. Speed up the process of initializing the node by loading a snapshot: + + 1. Download a rolling snapshot of Ghostnet from https://snapshot.tzinit.org based on the instructions on that site. + For example, the command to download the snapshot from the EU servers might look like this: ```bash - wget -O snapshot_file https://snapshots.eu.tzinit.org/weeklynet/rolling + wget -O snapshot_file https://snapshots.eu.tzinit.org/ghostnet/rolling ``` 1. Load the snapshot in the node by running this command: @@ -22,18 +40,20 @@ Now that the Octez node is configured to join Weeklynet, we can launch it and ma octez-node snapshot import snapshot_file ``` - If you see the error "The chain name contained in the snapshot file is not consistent with the network configured in the targeted data directory," the snapshot is for the previous instance of Weeklynet and no snapshot is available for this week. - Continue with the next step as usual. - 1. Start the node: ``` octez-node run --rpc-addr 127.0.0.1:8732 --log-output="$HOME/octez-node.log" ``` -At first launch, the node generates a fresh identity file used to identify itself on the Weeklynet L1 network. +1. Ensure that the node runs persistently. +Look up how to run programs persistently in the documentation for your operating system. +You can also refer to [Run a persistent baking node](https://opentezos.com/node-baking/baking/persistent-baker/) on opentezos.com. + +1. Optional: When the node has bootstrapped and caught up with the current head block, you can delete the snapshot file to save space. + +At first launch, the node generates a fresh identity file used to identify itself on the network. Then it bootstraps the chain, which takes a variable amount of time depending on how many blocks need to be loaded. -At worst, if the network has been running for nearly a week, it can take a few hours. -Fortunately, we can continue to set up our Weeklynet baking infrastructure while the node is bootstrapping. -Continue to [Step 3: Set up a baker account on Weeklynet](./prepare-account). +In the meantime, you can continue the baking infrastructure while the node is bootstrapping. +Continue to [Step 2: Set up a baker account](./prepare-account). diff --git a/docs/tutorials/join-dal-baker/verify-rights.md b/docs/tutorials/join-dal-baker/verify-rights.md new file mode 100644 index 000000000..cf35cb585 --- /dev/null +++ b/docs/tutorials/join-dal-baker/verify-rights.md @@ -0,0 +1,142 @@ +--- +title: "Step 5: Verify attestation rights" +authors: Tezos core developers, Tim McMackin +last_update: + date: 22 August 2024 +--- + +After the delay that you calculated in [Step 4: Run an Octez baking daemon](./run-baker), the baker starts receiving attestation rights, including the rights to attest that DAL data is available. + +Follow these steps to verify that your DAL node is receiving attestation rights: + +1. Record the address of your baker account in an environment variable so you can use it for commands that cannot get addresses by their Octez client aliases: + + ```bash + MY_BAKER="$(octez-client show address my_baker | head -n 1 | cut -d ' ' -f 2)" + ``` + +1. Run this command to get the attestation rights for the baker in the current cycle: + + ```bash + octez-client rpc get /chains/main/blocks/head/helpers/attestation_rights?delegate="$MY_BAKER" + ``` + + If the baker has no rights, the command returns an empty array: `[]`. + + When the baker has attestation rights, the command returns information about them, as in this example: + + ```json + [ { "level": 9484, + "delegates": + [ { "delegate": "tz1Zs6zjxtLxmff51tK2AVgvm4PNmdNhLcHE", + "first_slot": 280, "attestation_power": 58, + "consensus_key": "tz1Zs6zjxtLxmff51tK2AVgvm4PNmdNhLcHE" } ] } ] + ``` + + If the command returns an empty array (`[]`), the delay may not be over. + + If the delay has expired and you still haven't received attestation rights, try these troubleshooting steps: + + - Make sure that your node and baker are running. + + - Verify that the staked balance of your account is at least 6,000 tez by running the command `octez-client get staked balance for my_baker`. + If the response is less than 6,000 tez, you have not staked enough. + Ensure that you are registered as a delegate and stake more tez, retaining a small amount for transaction fees. + If necessary you can get more from the faucet. + + - Check to see if you will receive rights two cycles in the future: + + 1. Run this command to get the current cycle: + + ```bash + octez-client rpc get /chains/main/blocks/head | jq | grep '"cycle"' + ``` + + 1. Add two to the cycle and run this command to see what rights your account will have in that cycle. + For example, if the current cycle is 149, run this command to get its rights in cycle 151: + + ```bash + octez-client rpc get /chains/main/blocks/head/helpers/baking_rights\?cycle=151\&delegate=$MY_BAKER\&max_round=2 + ``` + + If this command returns a list of future attestation rights for your account, the delay has not expired yet and you must wait for that cycle to arrive. + + - Check to see if you are active and re-register as a delegate if necessary: + + 1. Run this command to see if your account is active: + + ```bash + octez-client rpc get /chains/main/blocks/head/context/delegates/$MY_BAKER/deactivated + ``` + + Baker accounts are deactivated when the baker is offline for a certain time. + + 1. If the value for the `deactivated` field is `true`, re-register as a baker by running this command: + + ```bash + octez-client register key my_baker as delegate + ``` + + 1. Find when the next cycle will start by going to a block explorer such as https://ghostnet.tzkt.io. + For example, this drop-down shows that the next cycle starts in 29 minutes: + + The TZKT block explorer, showing information about the current cycle + + When this cycle starts, Tezos calculates attestation rights for a certain number of cycles in the future and includes your baker. + The number of cycles is the `consensus_rights_delay` network parameter. + + 1. Wait for your baker to receive attestation rights. + +1. When your baker receives attestation rights as determined by the `/chains/main/blocks/head/helpers/attestation_rights` RPC call, run this command to get the shards that are assigned to your DAL node: + + ```bash + octez-client rpc get /chains/main/blocks/head/context/dal/shards?delegates=$MY_BAKER + ``` + + The response includes your account's address and a list of shards, as in this example: + + ```json + [ { "delegate": "tz1QCVQinE8iVj1H2fckqx6oiM85CNJSK9Sx", + "indexes": [ 25, 27, 67, 73, 158, 494 ] } ] + ``` + + These shards are pieces of data that the baker is assigned to attest. + +1. Verify the baker's activity on the Explorus block explorer by going to the Consensus Ops page at https://explorus.io/consensus_ops, selecting Ghostnet, and searching for your address. + + For example, this screenshot shows consensus operations that include DAL attestations, indicated by a number in the "DAL attestation bitset" column. + + ![DAL consensus operations, showing DAL consensus operations](/img/tutorials/dal-explorus-consensus-ops.png) + + If there is no DAL attestation, the block explorer shows a document icon with an X in it: ![](/img/tutorials/dal-explorus-no-attestation-icon.png). + This icon can appear before the bakers complete attestations and then turn into a binary number when they attest. + +Now you have a complete DAL baking setup. +Your baker is attesting to the availability of DAL data and the DAL node is sharing it to Smart Rollups across the network. + +## Optional: Unstaking your tez and receiving your baking rewards + +If you leave the baker running, you can see rewards accrue by running the command `octez-client get staked balance for my_baker`. +This amount starts at the amount that you originally staked and increases with your baking rewards. + +You can unstake your tez and withdraw your stake and any baking rewards with the `octez-client unstake` command. +For example, this command unstakes 6,000 tez: + +```bash +octez-client unstake 6000 for my_baker +``` + +Then run this command to retrieve the tez: + +```bash +octez-client finalize unstake for my_baker +``` + +Then you can do whatever you want with the tez, including sending it back to the faucet for someone else to use. +The Ghostnet faucet's address is `tz1a4GT7THHaGDiTxgXoatDWcZfJ5j29z5RC`, so you can send funds back with this command: + +```bash +octez-client transfer 6000 from my_baker to tz1a4GT7THHaGDiTxgXoatDWcZfJ5j29z5RC +``` + +For a summary of this tutorial, see [Conclusion](./conclusion). diff --git a/sidebars.js b/sidebars.js index 4f4af104b..2279eb080 100644 --- a/sidebars.js +++ b/sidebars.js @@ -409,17 +409,17 @@ const sidebars = { }, { type: 'category', - label: 'Join the DAL as a Weeklynet baker', + label: 'Join the DAL as a baker', link: { type: 'doc', id: 'tutorials/join-dal-baker', }, items: [ - 'tutorials/join-dal-baker/get-octez', 'tutorials/join-dal-baker/run-node', 'tutorials/join-dal-baker/prepare-account', 'tutorials/join-dal-baker/run-dal-node', 'tutorials/join-dal-baker/run-baker', + 'tutorials/join-dal-baker/verify-rights', 'tutorials/join-dal-baker/conclusion', ], }, diff --git a/static/img/tutorials/dal-explorus-consensus-ops.png b/static/img/tutorials/dal-explorus-consensus-ops.png new file mode 100644 index 000000000..b88e4bd46 Binary files /dev/null and b/static/img/tutorials/dal-explorus-consensus-ops.png differ diff --git a/static/img/tutorials/dal-explorus-no-attestation-icon.png b/static/img/tutorials/dal-explorus-no-attestation-icon.png new file mode 100644 index 000000000..744c202c2 Binary files /dev/null and b/static/img/tutorials/dal-explorus-no-attestation-icon.png differ diff --git a/static/img/tutorials/dal-file-tutorial-setup.png b/static/img/tutorials/dal-file-tutorial-setup.png index abc2df7a4..9434fadfc 100644 Binary files a/static/img/tutorials/dal-file-tutorial-setup.png and b/static/img/tutorials/dal-file-tutorial-setup.png differ diff --git a/static/img/tutorials/tzkt-next-cycle.png b/static/img/tutorials/tzkt-next-cycle.png new file mode 100644 index 000000000..0d166e440 Binary files /dev/null and b/static/img/tutorials/tzkt-next-cycle.png differ