Skip to main content

Step 4: Run an Octez baking daemon

Now that you have a layer 1 node and a DAL node, you can run a baking daemon that can create blocks and attests to DAL data. If you already have a baking daemon, you can restart it to connect to the DAL node.

Run one baker per account

Be sure to run only one baking daemon per Tezos account. If you run more than one, you risk double-baking or double-attesting and being slashed.

Single baker and accuser executables

Versions of the Octez suite prior to version 23 provided separate baker binaries for each protocol. Starting in version 23, releases of Octez include a single baker binary named octez-baker and a single accuser binary named octez-accuser that can be used with any supported protocol, including the current protocol and sometimes a proposed or voted upcoming protocol.

Therefore, you no longer need to switch baker and accuser daemons when the protocol changes or run separate daemons for the current protocol and an upcoming protocol. The octez-baker and octez-accuser daemons are aware of protocol changes and switch to new protocols automatically. Instead, you update them when new versions of the Octez suite become available, just like the other components of the Octez suite.

  1. Optional: Set up a remote signer to secure the keys that the baker uses as described in Signer in the Octez documentation.

  2. Run a baking daemon with the following arguments:

    • Use the consensus key, not the baker key, if you are using a consensus key
    • Pass the URL to your DAL node with the --dal-node argument
    • Pass the --liquidity-baking-toggle-vote argument; for more information, see Liquidity baking in the Octez documentation

    For example:

    octez-baker run with local node "$HOME/.tezos-node" consensus_key --liquidity-baking-toggle-vote pass --dal-node http://127.0.0.1:10732

    You can append >>"$HOME/octez-baker.log" 2>&1 to redirect its output in a log file.

  3. Ensure that the baker runs persistently. Look up how to run programs persistently in the documentation for your operating system.

    For example, if your operating system uses the systemd software suite, your service file might look like this example:

    /etc/systemd/system/octez-baker.service
    [Unit]
    Description=Octez baker
    Wants=network-online.target
    After=network-online.target
    Requires=octez-node.service

    [Install]
    WantedBy=multi-user.target

    [Service]
    Type=simple
    User=tezos
    ExecStart=octez-baker run with local node "$HOME/.tezos-node" consensus_key --liquidity-baking-toggle-vote pass --dal-node http://127.0.0.1:10732
    WorkingDirectory=/opt/octez-baker
    Restart=on-failure
    RestartSec=5
    StandardOutput=append:/opt/octez-baker.log
    StandardError=append:/opt/octez-baker.log
    SyslogIdentifier=%n

    If you name this service file /etc/systemd/system/octez-baker.service, you can start it by running these commands:

    sudo systemctl daemon-reload
    sudo systemctl start octez-baker.service

    You can stop it by running this command:

    sudo systemctl stop octez-baker.service

  4. In the same terminal window, run this command:

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

    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.

    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.

    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 excluded.

    You can also look at the baker logs to see if it injects the expected operations. At each level, the baker is expected to do a subset of these operations:

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

Backing up and restoring the baker​

The Octez baking daemon stores persistent operational data in the Octez client's data directory, notably consensus high-water marks and random seed nonces. If you want to back up the baker or move it to another machine and restore it, you must copy the nonce file or files from the Octez client's data directory to the equivalent directory on the new machine. These nonce files are named net<NETWORK_ID>_stateful_nonces and net<NETWORK_ID>_nonces, where <NETWORK_ID> is the ID of the network, such as netXdQprcVkpaWU_stateful_nonces for Mainnet or netXnHfVqm9ie_stateful_nonces for Ghostnet. All deployments have the net<NETWORK_ID>_stateful_nonces file but only legacy baking deployments running versions of Octez prior to 20.0rc1 have the net<NETWORK_ID>_nonces file.

After you have moved the nonce files to the new machine and verified that the baker runs normally for one cycle, you can remove the legacy net<NETWORK_ID>_nonces file.

Upgrading the baker and accuser​

Beginning with Octez version 23.0, upgrading the baker and accuser is just like upgrading the node or any other part of the Octez suite. When a new version of Octez becomes available, you can install the new version of Octez or replace the installed binaries on your system, restart them, and verify that they run correctly.

Waiting 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. You must wait until the end of the current cycle and then for this number of cycles to pass before the baker receives attestation rights.

You can check the time remaining in the current cycle on most block explorers. For example, you can go to https://tzkt.io/ and click the network indicator at the top left of the page, as in this picture:

The TZKT block explorer, showing information about the current cycle

At the end of the current cycle, baking rights for a future cycle are calculated and should include rights for your baker.

You can see when your baker will receive attestation rights by checking block explorers after the end of the cycle in which you staked your tez. For example, TzKT has a "Schedule" page that shows baker performance in the recent past and their projected rights in the near future. The following screencap shows the schedule for a new baker. In this case, the baker has attestation rights for two cycles at the times specified in the schedule.

The TZKT block explorer Schedules page, showing attestation rights

The delay on Mainnet is about 2 days because a cycle is about 1 day and consensus rights are calculated 2 cycles in advance (as set by the consensus_rights_delay constant). Block drift and the remaining time in the current cycle can add to this delay.

You can calculate the approximate time that it takes a new baker to receive attestation rights with this formula, where remaining_current_cycle is the time remaining in the current cycle and the other values are protocol constants:

remaining_current_cycle + (consensus_rights_delay * blocks_per_cycle * minimal_block_delay)

To get a protocol constant, make sure that your Octez client is connected to the correct network and then call the /chains/main/blocks/head/context/constants RPC endpoint. For example, this command gets the consensus_rights_delay constant:

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

After the delay has passed, the baker log (not the Octez node log, neither the DAL node log) should contain lines that look like this:

  • Consensus pre-attestations: injected preattestation ...
  • Consensus attestations: injected attestation ...
  • Attach DAL attestations: ready to attach DAL attestation ...

These lines log the attestations that the baker makes.

If the baker does not have attestation rights, the log contains lines that start with The following delegates have no attesting rights at level ....

note

Even though the baker binary is using the consensus key, the attestations refer to the main baking key. In spite of this, the baking daemon does not need access to the baker key.

You can see the keys that the baker uses in its log. When the baker injects a preattestation with a consensus key, the log shows that it used a consensus key on behalf of the main baking key, as in this example:

Aug 22 12:52:40.033 NOTICE │ received new forge event:
Aug 22 12:52:40.033 NOTICE │   preattestation ready for delegate consensus_key (tz3cveMb6Pt65pPcjeR8KWfyad2YSqd1wjE3)
Aug 22 12:52:40.033 NOTICE │   on behalf of tz1TGKSrZrBpND3PELJ43nVdyadoeiM1WMzb at level 3961560 (round 0)
Aug 22 12:52:40.047 NOTICE │ injected preattestation ooE8gUSRYxnKhQUFuzZf2TtpseGdxCmP54YZq3CEShwUn9vB8Bp
Aug 22 12:52:40.047 NOTICE │   for consensus_key (tz3cveMb6Pt65pPcjeR8KWfyad2YSqd1wjE3)
Aug 22 12:52:40.047 NOTICE │   on behalf of tz1TGKSrZrBpND3PELJ43nVdyadoeiM1WMzb for level 3961560, round
Aug 22 12:52:40.047 NOTICE │   0

After the attestation delay, whether or not you have attestation rights, proceed to Step 5: Verifications.

Optional: Run an accuser​

The accuser is a daemon that monitors blocks and looks for problems, such as bakers who double-sign blocks or inject multiple attestations. If it finds a problem, it posts a denunciation operation, which leads to penalizing the misbehaving baker. You don't have to run an accuser, but if you do, you can receive as a reward part of the penalties of the denounced baker.

For example, if your operating system uses the systemd software suite, the attester service file might look like this example:

/etc/systemd/system/octez-accuser.service
[Unit]
Description=Octez accuser
Wants=network-online.target
After=network-online.target
Requires=octez-node.service

[Install]
WantedBy=multi-user.target

[Service]
Type=simple
User=tezos
ExecStart=octez-accuser run
WorkingDirectory=/opt/octez-accuser
Restart=on-failure
RestartSec=5
StandardOutput=append:/opt/octez-accuser.log
StandardError=append:/opt/octez-accuser.log
SyslogIdentifier=%n
Last updated on