Skip to main content

Step 5: Run an Octez baking daemon

To run a baking daemon that connects to the DAL, start it as usual and pass the URL to your DAL node to it:

  1. In a new terminal window, run this command:

    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

  2. Verify that the baker is subscribed to the DAL by opening another terminal window and running this RPC call:

    curl http://localhost:10732/p2p/gossipsub/topics

    If you are using the tezos/tezos Docker image, you can install the curl program by running the command sudo apk add curl.

    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.

    Then, the baker daemon automatically asks the DAL node to subscribe to the topics that provide the shards that it is assigned to.

    In the results of this command, each topic contains a shard and the address of the baker that is assigned to it. Your DAL node and baker are listening to these topics and attesting to the data in them.

    This command returns all of the topics that the baker is subscribed to in the format {"slot_index":<index>,"pkh":"<ADDRESS OF BAKER>"} where index varies between 0 included and the number of slot indexes (32 on Weeklynet) excluded.

    You 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 ...")

  3. (Optional) Launch an accuser daemon by opening a new terminal window and running this command:

    octez-accuser-alpha run >> "$HOME/octez-accuser.log" 2>&1

    The accuser monitors the behavior of the other bakers and denounces them to the Tezos protocol if they double-sign any block or consensus operation.

Receiving attestation rights​

Now that the account has staked enough tez and the baking daemon is running, the account will soon receive attestation rights. The delay is a number of cycles determined by the value of the consensus_rights_delay constant plus two cycles.

To get the current value of this constant, query the constants RPC endpoint on your node, as in this example:

octez-client rpc get /chains/main/blocks/head/context/constants | jq | grep consensus_rights_delay

To run this command you may need to install the jq program. If you are using the tezos/tezos Docker image, you can install it by running the command sudo apk add jq.

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

For example, if consensus_rights_delay is 2, blocks_per_cycle is 160, and minimal_block_delay is 5, a new baker receives attestation rights after a delay of 3200 seconds, or about 53 minutes. The exact time depends on what time in the current cycle the account staked its tez. The amount of tez that the account stakes determines how often it is called on to make attestations, not how quickly it receives rights.

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:

    MY_BAKER="$(octez-client show address my_baker | head -n 1 | cut -d ' ' -f 2)"

  2. Run this command to get the consensus attestation rights for your baker in the current cycle:

    octez-client rpc get /chains/main/blocks/head/helpers/attestation_rights?delegate="$MY_BAKER"

    When your baker has attestation rights, the command returns information about them, as in this example:

    [ { "level": 9484,
     "delegates":
       [ { "delegate": "tz1Zs6zjxtLxmff51tK2AVgvm4PNmdNhLcHE",
           "first_slot": 280, "attestation_power": 58,
           "consensus_key": "tz1Zs6zjxtLxmff51tK2AVgvm4PNmdNhLcHE" } ] } ]

  3. If the command returns an empty array ([]), wait for the delay to 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 in the next cycle:

      1. Run this command to get the current cycle:

        octez-client rpc get /chains/main/blocks/head | jq | grep '"cycle"'

      2. Add two to the cycle and run this command to see what rights your account will have in the next cycle. For example, if the current cycle is 149, run this command:

        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 attestation rights for your account, the delay has not expired yet and you must wait for that cycle to arrive.

  4. 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:

    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:

    [ { "delegate": "tz1QCVQinE8iVj1H2fckqx6oiM85CNJSK9Sx",
     "indexes": [ 25, 27, 67, 73, 158, 494 ] } ]

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.

You can verify your baker's activity by going to the Bakers page of the block explorer at https://explorus.io/bakers_activity, selecting Weeklynet, and searching for your account's address.

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.

Optional: Unstaking your tez and receiving 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 40,000 tez:

octez-client unstake 40000 for my_baker

Then run this command to retrieve the tez:

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.

For a summary of this tutorial, see Conclusion.

Last updated on