Tezos Reward Distributor (TRD) v9.0 Florence - Development Overview

We (the TRD maintainers) would like to inform the community, especially the bakers, about a new TRD release . There have been many changes in the development of the TRD since a grant was awarded by the Tezos Foundation over a year ago. Many new features have been added and some are still planned. It is gratifying that the open-source tool is being further developed by developers all over the world and that the compensation with Tez is done via a multi-sig wallet depending on the effort spent. The guidelines for the contribution can of course be used as a blueprint for other Tezos open source projects.

Organizational

@nicolasochem and vkresch have joined the list of maintainers. We are very glad to have Nicolas and Viktor on board. Furthermore, we saw increasing contributions from denver-s. Amzid will be leaving us soon and we wish him all the best for his new job and thank him for dedication with which he fixed bugs late at night. We hope to see him around in the repository and Tezos in general.

Furthermore, we would like to ask that especially larger bakers allocate more resources to TRD. Due to the regular protocol upgrades, TRD must be also continuously adapted and the support of smart contracts is a tricky business to do right. Also, our grant ended as planned and we need some help to prepare a new grant proposal.

Here is an overview of the features for version 9.0:

Additional Features:

  • Breaking: New reward_type ideal introducing payouts like Bäckerei. Old ideal has been renamed to estimated. The discussion in can be found here: #415. Users of Bäckerei can now migrate to TRD, as development on Bäckerei will soon stop.
old new
actual actual
ideal estimated
ideal
  • Payment reporting: New payment status “skipped”, i.e. liquidated (Kolibri) ovens are skipped. Payments to KT1 accounts are skipped if fee > payment_amount as a precaution and are marked as skipped. Important debugging advice: Consider redirecting KT1 payments to the entitled tz address through the configuration. Furthermore, done and failed payouts are now split into two CSV files.

  • Docker images are now available HERE

  • Optimization of fees, gas limits and batch sizes ordered by transaction type (tz, kt)

  • Frozen rewards can now be paid out using RPC as the source

  • Log archives are now compressed using gzip

Changes:

  • Major: Introduction of a finite state machine, FSM to increase application safety and prepare to store application states for program recovery.

  • Major: Accusation rewards are not part of any calculation for any reward type and any data source. We will probably introduce a toggle-on button within the next release.

  • Breaking: -C --initial_cycle has now a default value of -1 meaning start at last unfrozen cycle and now only allows positive cycle values

  • Breaking: -R --release_override is now restricted to [-11,0]

  • Breaking: -M --run_mode 4 does honor the -C parameter and runs all failed payments by default

  • Breaking: fee.ini has been removed

  • Resolved issue when payments resulted in an invalid branch error

  • Unit testing has been increased

  • Improved logging

  • Exception handling and robustness has been increased

  • Documentation improvements

  • Using gh-actions now for automated unit tests and builds

  • Fixed several bugs (see PR list)

Findings

  • When using ideal: Tzkt counts missed baking fees, but because it also counts the missed block reward more accurately, it can end up lower than tzstats. Therefore, we currently encourage users when using ideal, to use tzkt. We will reach out to the tzstats team.
5 Likes

What do you mean by this?

The „Findings" part from above should be a neutral representation related to a recommended action towards a backend in the specific case of using the rewards type “ideal”. The definition of “ideal” is a pure takeover from the Bäckerei Tool which was the requirement. The only thing we can do is show the discrepancy so that the community/parties involved are able to start a conversation. Therefore, when using ideal:

Missed baking fees from missed blocks:

  • TzKT counts missed baking fees within the missed block

  • TzStats does not count baking fees within the missed block

  • RPC/pRPC does not count baking fees within the missed block

Missed Block Rewards:

  • TzKT adjusts the missed block reward (i.e. 38,75 ęś© if the previous block was not fully endorsed)

  • TzStats assumes the maximum missed block reward (currently 40 ęś©)

  • RPC/pRPC assumes the maximum missed block reward (currently 40 ęś©)

A harmonization might be useful because if we as users are confused, others might be as well. However, we underline that this is not a bug but a different viewing perspective. A possible solution (tbd) is offering a dedicated RPC in each of the indexers including an explanation of different miss reward views.