Live-testing Adaptive Issuance and Adaptive Slashing on Weeklynet

Research and Development
1

:mega: Tezos bakers and all!

Starting from this week’s Weeklynet deployment – that is, with the network starting on Wed Feb 28th –, we will deploy a series of live test scenarios to showcase baking and staking UX and Adaptive Slashing in the upcoming Paris protocol proposal.

Each day, we will deploy different scenarios, and we will provide you a small report on these actions and their effects – updating this thread accordingly.

The goal is to present realistic scenarios which Tezos bakers and users in general can witness on a live testnet, eventually replicate on their own and/or ask questions (either in this thread, or in the #baking channel on Tezos Discord).

Scheduled Scenarios

We will deploy a series of specific baker and staker accounts which will be involved in the different scenarios.

Then, each day, we will run different specific scenarios (described below) and report their observable effects.

We will include client commands and RPC endpoints used in this process, to allow bakers and any interested participant to replicate these scenarios on their own.

In that case, please note that as Weeklynet moves fast, these RPC endpoints may only return data if querying full or archive nodes.

Note we may modify these scenarios as the whole experiment progresses.

Dedicated accounts

Note that these accounts will be bootstrapped with funds from the creation of the test network. Any baker or user interested in deploying these scenarios can rely on Weeklynet’s faucet for funds.

delegate1 tz1dLg1FCT9HahvrfjsjyRdg3io5BjuRHCYk
delegate2 tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT
staker1 tz1StA1g3ZuXALEcSYnh5bGFpv6mUg1SYd9Q
staker2 tz1STA2CG3Z7XGKCcmWkuYbbBjQYQcVmgJ6C
staker3 tz1STa3McBCrYBXvcA5bCW4KFQQxCQyxDnXG
staker4 tz1STA4fbG657scmYahaLnFSxz4s2MqzH2bY
staker5 tz1Sta5sAAHotnBvcecV2Cr41c4Uczv23TvT

Day 1 (Wednesday)

Focus of this scenario:

  • Setting up delegates, stakers and delegators;
  • Manually manipulating stake and delegations;
  • Updating staking parameters.

Delegate1

  • delegate1 is bootstrapped with a balance of 400,000 tez.
  • delegate1 registers as delegate.
  • delegate1 stakes 100,000 tez of their own balance.
  • delegate1 sets staking parameters edge-of-baking-over-staking to 1 and limit-of-staking-over-baking to 0.1.

These steps can be implemented with the following client commands:

octez-client register key delegate1 as delegate
octez-client stake 100000 for delegate1
octez-client set delegate parameters for delegate1 --edge-of-baking-over-staking 1 --limit-of-staking-over-baking 0.1

Delegate2

  • delegate2 is bootstrapped with a balance of 400,000 tez.
  • delegate2 registers as delegate.
  • delegate2 stakes 399,000 tez – almost all its balance.
  • delegate2 sets staking parameters edge-of-baking-over-staking to 0.1 and limit-of-staking-over-baking to 5.
octez-client register key delegate2 as delegate
octez-client stake 399000 for delegate2
octez-client set delegate parameters for delegate2 --edge-of-baking-over-staking 0.1 --limit-of-staking-over-baking 5

Staker1

  • staker1 is bootstrapped with 10,000 tez.
  • staker1 delegates to delegate1.
  • staker1 stakes 7,000 tez.
octez-client set delegate for staker1 to delegate1
octez-client stake 7000 for staker1

Staker2

  • staker2 is bootstrapped with 10,000 tez.
  • staker2 delegates to delegate1.
  • staker2 stakes 9,990 tez.
octez-client set delegate for staker2 to delegate1
octez-client stake 9990 for staker2

Staker3

  • staker3 is bootstrapped with 10,000 tez
  • staker3 delegates to delegate2
  • staker3 stakes 1,000 tez
octez-client set delegate for staker3 to delegate2
octez-client stake 1000 for staker3

Staker4

  • staker4 is bootstrapped with 10_000 tez.
  • staker4 delegates to delegate2.
octez-client set delegate for staker4 to delegate2

Staker5

  • staker5 is bootstrapped with 10_000 tez.
  • staker5 delegates to delegate2.
  • staker5 stakes 3,000 tez.
octez-client set delegate for staker5 to delegate2
octez-client stake 3000 for staker5

Day 2 (Thursday)

Focus:

  • Stake manipulation;
  • Staking parameters manipulation.

Delegate1

  • delegate1 updates staking parameters edge-of-baking-over-staking to 1 and limit-of-staking-over-baking to 2.
octez-client set delegate parameters for delegate1 --edge-of-baking-over-staking 1 --limit-of-staking-over-baking 2

Staker1

  • stake1 unstakes 5,000 tez.
octez-client unstake 5000 for staker1

Staker3

  • staker3 stakes 1,000 tez.
octez-client stake 1000 for staker3

Staker5

  • staker5 unstakes all its stake.
  • staker5 stakes 3,000 tez.
  • staker5 changes delegate from delegate2 to delegate1.
octez-client unstake everything for staker5
octez-client stake 3000 for staker5
octez-client set delegate for staker5 to delegate1

Note that the everything argument enables unstaking all staked funds.

Day 3 (Friday)

Focus:

  • Staking manipulations;
  • Witnessing the effect of Adaptive Slashing after double baking.

Delegate1

  • delegate1 updates staking parameters edge-of-baking-over-staking to 0.5 and limit-of-staking-over-baking to 5.
  • delegate1 stakes 3,000 tez.
octez-client set delegate parameters for delegate1 --edge-of-baking-over-staking 0.5 --limit-of-staking-over-baking 5
octez-client stake 3000 for delegate1

Delegate2

  • delegate2 launches a second baker and may double bake. In which case, it would eventually result in delegate2 being slashed.

Staker1

  • staker1 changes delegation to delegate2.
octez-client set delegate for staker1 to delegate2

Staker3

  • staker3 stakes 1,000 tez
octez-client stake 1000 for staker3

Staker5

  • staker5 unstakes 4,000 tez
octez-client unstake 4000 for staker5

Day 4 (Saturday)

Focus:

  • Unstaking funds; finalizing stakes.

Delegate1

  • delegate1 stakes 5,000 tez.
  • delegate1 stakes almost all available liquid funds – leaving 1 tez staked.
full_balance=$(octez-client rpc get /chains/main/blocks/head/context/delegates/tz1dLg1FCT9HahvrfjsjyRdg3io5BjuRHCYk/full_balance)
frozen_deposits=$(octez-client rpc get /chains/main/blocks/head/context/delegates/tz1dLg1FCT9HahvrfjsjyRdg3io5BjuRHCYk/current_frozen_deposits)
to_stake=$(((full_balance - frozen_deposits) / 1000000 - 1))
octez-client stake $to_stake for delegate1

Delegate2

  • delegate2 stops its second baker.

Staker2

  • staker2 unstakes all its stake.
octez-client unstake everything for staker2

Staker3

  • staker3 stakes 1,000 tez
octez-client stake 1000 for staker3

Staker5

  • staker5 transfers 1,000 tez to each of staker1, staker2 and staker3.
octez-client transfer 1000 from staker5 to staker1
octez-client transfer 1000 from staker5 to staker2
octez-client transfer 1000 from staker5 to staker3

Day 5 (Sunday)

Staker3

  • Staker3 unstakes 1,000 tez
octez-client unstake 1000 for staker3

Day 6 (Monday)

Staker1

  • staker1 unstakes all its stake
octez-client unstake everything for staker1

Staker3

  • staker3 unstakes 1,000 tez
octez-client unstake 1000 for staker3

Staker5

  • staker5 finalizes previously unstaked funds.
  • staker5 transfers 1,000 tez to staker4.
octez-client finalize unstake for staker5
octez-client transfer 1000 from staker5 to staker4

Day 7 (Tuesday)

Staker3

  • staker3 unstakes all its stake
octez-client unstake everything for staker3
5 Likes
2

That looks good! Is there a chance the scheduled scenarios scripts are published somewhere or they will be produced manually?

2 Likes
3

Day 1 report

Here is a summary of the scenario executed today.

Today’s scenario showcases:

  • how new delegates can start staking and start accepting stakers.
  • how delegators can start staking via their delegate

Delegate Actions

  • delegate1 (pkh: tz1dLg1FCT9HahvrfjsjyRdg3io5BjuRHCYk) was registered as a delegate on block #3,119.
  • delegate1 staked 100,000 tez on block level #3,120.
  • At this point, delegate1 will not accept stakes from delegators as the default limit-of-staking-over-baking is set to 0.
  • delegate1 set staking parameters edge-of-baking-over-staking to 1 and limit-of-staking-over-baking to 0.1 on block #3,121.
  • delegate2 (pkh:tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT) was registered as a delegate on block #3,122.
  • delegate2 staked 399,000 tez on block #3,123.
  • delegate2 set staking parameters edge-of-baking-over-staking to 0.1 and limit-of-staking-over-baking to 5 on block #3,124.
  • The updated staking parameters for both delegates became active 4 cycles later, on block #3,584.

Observations

  • stake operations: the effect of stakecommand can be observed by querying the operation content on each level. For example, the effect of,
octez-client stake 100000 for delegate1

can be witnessed by the following RPC query:

octez-client rpc get /chains/main/blocks/3120/operations/3/

[ { "protocol": "ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK",
    "chain_id": "NetY1QgDPf4tnp3",
    "hash": "oorxQ56UYnQPVJEQRzxMBp6NA4TyFrGHVY6kwpyuEHxgamdujjZ",
    "branch": "BLGUqg8PpKoSH93yi9BtLt2DndCoDgnG2BJPCiqVmoSJJPsw8de",
    "contents":
      [ { "kind": "transaction",
          "source": "tz1dLg1FCT9HahvrfjsjyRdg3io5BjuRHCYk", "fee": "624",
          "counter": "320", "gas_limit": "3630", "storage_limit": "0",
          "amount": "100000000000",
          "destination": "tz1dLg1FCT9HahvrfjsjyRdg3io5BjuRHCYk",
          "parameters":
            { "entrypoint": "stake", "value": { "prim": "Unit" } },
          "metadata":
            { "balance_updates":
                [ { "kind": "contract",
                    "contract": "tz1dLg1FCT9HahvrfjsjyRdg3io5BjuRHCYk",
                    "change": "-624", "origin": "block" },
                  { "kind": "accumulator", "category": "block fees",
                    "change": "624", "origin": "block" } ],
              "operation_result":
                { "status": "applied",
                  "balance_updates":
                    [ { "kind": "contract",
                        "contract": "tz1dLg1FCT9HahvrfjsjyRdg3io5BjuRHCYk",
                        "change": "-100000000000", "origin": "block" },
                      { "kind": "freezer", "category": "deposits",
                        "staker":
                          { "baker": "tz1dLg1FCT9HahvrfjsjyRdg3io5BjuRHCYk" },
                        "change": "100000000000", "origin": "block" } ],
                  "consumed_milligas": "3629053" } } } ],
    "signature":
      "siggBAaMvkRLuFwewbcfHdo1k6iSsfXMbsWotHNgVaJVTYTxuZiXY6izaSXQzRyvnHo7KEVKkwUzqSrcLE2jEeQXeS8PHdVm" } ]
  • updating staking parameters: again, the effect of changing delegate staking parameters can be observed by querying the operation content on each level. For example, the effect of,
octez-client set delegate parameters for delegate1 --edge-of-baking-over-staking 1 --limit-of-staking-over-baking 0.1

can be witnessed by the following RPC query:

octez-client rpc get /chains/main/blocks/3121/operations/3/


[ { "protocol": "ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK",
    "chain_id": "NetY1QgDPf4tnp3",
    "hash": "oozU6AGDgLuyhV2o48UkxjoiA5vMT611rWuPmTRQNS96hkru83P",
    "branch": "BLfoU6wqpYb5YYupU3cZKjXPEoenvpjFDwokv8XNcHd1eFB2V55",
    "contents":
      [ { "kind": "transaction",
          "source": "tz1dLg1FCT9HahvrfjsjyRdg3io5BjuRHCYk", "fee": "356",
          "counter": "321", "gas_limit": "791", "storage_limit": "0",
          "amount": "0",
          "destination": "tz1dLg1FCT9HahvrfjsjyRdg3io5BjuRHCYk",
          "parameters":
            { "entrypoint": "set_delegate_parameters",
              "value":
                { "prim": "Pair",
                  "args":
                    [ { "int": "100000" }, { "int": "1000000000" },
                      { "prim": "Unit" } ] } },
          "metadata":
            { "balance_updates":
                [ { "kind": "contract",
                    "contract": "tz1dLg1FCT9HahvrfjsjyRdg3io5BjuRHCYk",
                    "change": "-356", "origin": "block" },
                  { "kind": "accumulator", "category": "block fees",
                    "change": "356", "origin": "block" } ],
              "operation_result":
                { "status": "applied", "consumed_milligas": "790450" } } } ],
    "signature":
      "sigs5C5YRKTgSBBPKqDWQ1jQkzfySCAB2i8a1dEQos6aCRgJb5NpXQEMoAiN6SuBGiaDMM6iLw2mFHWaV28iJQd6VBdkAeJi" } ]

Update occured 4 cycles later at block 3584. For levels between 3121 and 3584, calls to

octez-client rpc get /chains/main/blocks/<level>/context/delegates/tz1dLg1FCT9HahvrfjsjyRdg3io5BjuRHCYk/active_staking_parameters

should return

{ "limit_of_staking_over_baking_millionth": 0,
  "edge_of_baking_over_staking_billionth": 1000000000 }

However, these pending changes can be observed using the following call:

octez-client rpc get /chains/main/blocks/<level>/context/delegates/tz1dLg1FCT9HahvrfjsjyRdg3io5BjuRHCYk/pending_staking_parameters

From block #3,584, queries to active_staking_parameteres return

{ "limit_of_staking_over_baking_millionth": 100000,
  "edge_of_baking_over_staking_billionth": 1000000000 }

as expected.

Staker Actions

  • staker1 (pkh: tz1StA1g3ZuXALEcSYnh5bGFpv6mUg1SYd9Q) received 10,000 tez on block #3,264.
  • staker2 (pkh: tz1STA2CG3Z7XGKCcmWkuYbbBjQYQcVmgJ6C) received 10,000 tez on block #3,265.
  • staker3 (pkh: tz1STa3McBCrYBXvcA5bCW4KFQQxCQyxDnXG) received 10,000 tez on block #3,266.
  • staker4 (pkh: tz1STA4fbG657scmYahaLnFSxz4s2MqzH2bY) received 10,000 tez on block #3,267.
  • staker5 (pkh: tz1Sta5sAAHotnBvcecV2Cr41c4Uczv23TvT) received 10,000 tez on block #3,268.
  • staker1 delegated its balance to delegate1 on block #3,269.
  • staker2 delegated its balance to delegate1 on block #3,270.
  • staker3 delegated its balance to delegate2 at block #3,271.
  • staker4 delegated its balance to delegate2 on block #3,272.
  • staker5 delegated its balance to delegate2 on block #3,273.
  • staker1 and staker2 waited for the updated staking parameters from delegate1 to become active at the beginning of cycle #28.
  • staker3 and staker5 waited for the updated staking parameters from delegate2 to become active at the beginning of cycle #28.
  • staker1 staked 7,000 tez on block #3,593.
  • staker2 staked 9,900 tez on block #3,594.
  • staker3 staked 1,000 tez on block #3,595.
  • staker5 staked 3,000 tez on block #3,596.

Observations

  • staked balance: the effect of the stake command can be queried from the context, using the staked_balance RPC endpoint. For example, after having done
octez-client stake 7000 for staker1

we see

 ./octez-client rpc get /chains/main/blocks/3593/context/contracts/tz1StA1g3ZuXALEcSYnh5bGFpv6mUg1SYd9Q/staked_balance

"7000000000"

Staking rewards

From cycle #28 onward, consensus rewards accrued to delegate1 and delegate2 and their stakers, according to the delegates performance.

  • Baking rewards (both the fixed and the variable bonus reward) are distributed to delegates and their stakers on the same level that they accrue – that is, on each block baked by delegate1 or delegate2.

  • Attestation rewards are distributed at the end of the cycle.

We don’t cover seed nonce and VDF revelation tips in today’s scenario.

Reward allocation and distribution can be observed in the balance updates in blocks’metadata.

In particular, we can observe the part allocated to the bakers and the part allocated to its stakers, following their chosen parameters.

We can observe this, for example on #8,392’s metadata, which was baked by delegate2, with the following command:

octez-client rpc get /chains/main/blocks/8392/metadata  | jq .balance_updates

See full details in the proposed New Staking UX document.

3 Likes
4

Thanks @MisterWalker for your interest in these tests. Regarding our scripts, parts of them are quite ad hoc and may not be relevant to others, in particular the execution of nodes and bakers and the setup to double bake. Besides, for daily scenarios, they mostly consist in sequentially running the commands presented in the first post. However, we will probably add them to tezos/tezos gitlab repository in the near future.

1 Like
5

Day 2 report

Here is a summary of the scenario executed today.

Today’s scenario showcases:

  • how delegates can update their staking parameters.
  • how stakers can unstake and stake their tez.
  • how to monitor unstake requests.

Delegate Actions

  • delegate1 updated staking parameters edge-of-baking-over-staking to 1 and limit-of-staking-over-baking to 2 on block #15,402.

Observations

  • updating staking parameters: As for yesterday’s actions, the effect of changing delegate staking parameters can be observed by querying the operation content on each level. For example, delegate1’s action today

can be witnessed by the following RPC query:

octez-client rpc get /chains/main/blocks/15402/operations/3/

Active staking parameters can be observed using:

octez-client rpc get /chains/main/blocks/<level>/context/delegates/<delegate pkh>/active_staking_parameters

Activating new staking parameters takes 4 cycles, during this period, pending staking parameters are observable via:

octez-client rpc get /chains/main/blocks/<level>/context/delegates/<delegate_pkh>/pending_staking_parameters

Staker Actions

  • staker1 unstaked 5,000 tez on block #15,403.
  • staker3 staked 1,000 tez on block #15,404.
  • staker5 unstaked all its tez on block #15,405.
  • staker5 staked 3,000 tez on block #15,406.
  • staker5 changed its delegate to delegate1 on block #15,407.

Observations

  • unstake operations: the effect of unstake operations can be observed by querying the operation content on each level. For example, the effect of,
octez-client unstake 5000 for staker1

can be witnessed by the following RPC query:

octez-client rpc get /chains/main/blocks/15403/operations/3/

Unlike stake operations, which have an immediate effect on both the liquid balance and the staked frozen deposits of the staker, for safety reasons, unstake operations do not make unstaked amounts immediately liquid. Unstaked amounts are effectively deduced from the staked balance of the unstaker but they cannot be made spendable until 4 (CONSENSUS_RIGHTS_DELAY + MAX_SLASHING_PERIOD) cycles later. When an unstake operation is triggered, it initiates an unstake request which can be monitored using RPC queries.

For example, to track the unstake request of staker1, we can use the following query:

octez-client rpc get /chains/main/blocks/15403/context/contracts/tz1StA1g3ZuXALEcSYnh5bGFpv6mUg1SYd9Q/unstake_requests

{ "finalizable": [],
  "unfinalizable":
    { "delegate": "tz1dLg1FCT9HahvrfjsjyRdg3io5BjuRHCYk",
      "requests": [ { "cycle": 120, "amount": "5000000000" } ] } }

Until the end of the 4th cycle after the unstake request, the request is unfinalizable. Despite the staked balance of the staker decreasing by the requested amount, those funds remain frozen. Once the 4th cycle concludes, the request becomes finalizable. Upon finalization, the previously unstaked funds are made spendable again.

This can be observed starting from block level #16,001 when staker1’s unstake request become finalizable:

octez-client rpc get /chains/main/blocks/16001/context/contracts/tz1StA1g3ZuXALEcSYnh5bGFpv6mUg1SYd9Q/unstake_requests

{ "finalizable":
    [ { "delegate": "tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT", "cycle": 120,
        "amount": "6532673491" } ],
  "unfinalizable":
    { "delegate": "tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT", "requests": [] } }

The change in stake balance can be observed using the staked_balance RPC endpoint. For example, before unstaking, staker1’s staked balance was 7,000 tez as observed by the following query:

octez-client rpc get /chains/main/blocks/15402/context/contracts/tz1StA1g3ZuXALEcSYnh5bGFpv6mUg1SYd9Q/staked_balance

"7000000000"

After unstaking, its staked balance became 2,000 tez as observed by the following query:

 ./octez-client rpc get /chains/main/blocks/15403/context/contracts/tz1StA1g3ZuXALEcSYnh5bGFpv6mUg1SYd9Q/staked_balance

"2000000000"
  • stake operations: the effect of the stake command can be queried from the context, using the staked_balance RPC endpoint:
octez-client rpc get /chains/main/blocks/<level>/context/contracts/<staker_pkh>/staked_balance
  • changing delegate: the effect of changing delegate can be observed by querying the operation content on each level. For example, the effect of,
octez-client set delegate for staker5 to delegate1

can be witnessed by the following RPC query:

octez-client rpc get /chains/main/blocks/15407/operations/3/

Changing delegate triggers an implicit unstake request for the full frozen deposits of the staker. This can be observed using the
unstake_requests RPC endpoint. For example, the unstake request of staker5 can be observed using the following query:

octez-client rpc get /chains/main/blocks/15407/context/contracts/tz1Sta5sAAHotnBvcecV2Cr41c4Uczv23TvT/unstake_requests

As long as the unstake request is not finalized, the frozen tez will continue to be delegated to the previous delegate, however the spending balance of the account is accounted in the new delegate’s stake. It will not be possible to stake with the new delegate as long as there are unfinalizable unstake requests for tez staked with the old delegate.

It’s worth noting that unstake requests are recorded per cycle. For instance, in the case of staker5, who submitted two requests in the same cycle (one explicitly at block #15,405 and another implicitly triggered by a delegate change at block #15,407), we can observe that the latter request simply adds up to the amount already registered for the unstake request.

2 Likes
6

Day 3 report

Here is a summary of the scenario executed today.

Today’s scenario showcases:

  • Effects of double baking/denunciations/slashing

Important note on double baking:
Both octez-node and octez-baker are equipped with numerous safety mechanisms designed to prevent instances of double baking or double attestation. However, for today’s experiment, we deliberately configured a specific system to induce double baking. Achieving this required us to adjust our configurations, consciously deviating from recommendations and default parameters. It’s important to note that we will not delve into these settings in this report, and we wish to emphasize that double baking (as well as double attesting) is considered a misbehavior that poses a risk to the chain’s integrity, and as such, is subject to penalties and slashing. We strongly advise against attempting to replicate this particular experiment.

Delegate Actions

  • delegate1 updated staking parameters edge-of-baking-over-staking to 0.5 and limit-of-staking-over-baking to 5 on block #27,713.
  • delegate1 staked 3,000 tez on block #27,715.
  • delegate2 started a second baker on block #27,718.

Observations

  • updating staking parameters: following yesterday’s actions, the effect of changing delegate staking parameters can be observed by querying the operation content on the corresponding level.

  • double baking: double baking can be observed live either by running an alpha accuser binary, or by observing the blocks received by an Octez node. Once the chain has reached consensus on its new head, using the /chains/main/blocks/<level> RPC endpoint will only show the selected block. However, once a denunciation operation has been included in a succesor block, it can be observed via delegates’ RPC entrypoints. For example, a denunciation of delegate2’s double-baking can be observed using the following query:

 octez-client rpc get /chains/main/blocks/31046/context/delegates/tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT/denunciations

[ { "operation_hash": "ooX9YDDP7iLZUCfevbMgSdWoZVyp6VjtTvYy6K1J7VKh3C79qVT",
    "rewarded": "tz1VXDXJKNZ6Vd8WGoSyrfEXNpManegYm7gd",
    "misbehaviour": { "level": 30988, "round": 0, "kind": "block" } } ]

This query shows the concerned level – here, #30,988 – as well as the hash of the denunciation operation.

In this example, the denunciation operation was included at level #30,989 (just after our delegate misbehaved) and its details can be observed using usual block content queries.

octez-client rpc get /chains/main/blocks/30989/operations/2

[ { "protocol": "ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK",
    "chain_id": "NetY1QgDPf4tnp3",
    "hash": "ooX9YDDP7iLZUCfevbMgSdWoZVyp6VjtTvYy6K1J7VKh3C79qVT",
    "branch": "BLAj4g2A92CXRwkGuKUvgfBghYWGHvsV7tZvKrh3DiMxTYy6wCx",
    "contents":
      [ { "kind": "double_baking_evidence",
          "bh1":
            { "level": 30988, "proto": 2,
              "predecessor":
                "BL2JDK6ABvDpMUYV8dyJ8xeaGpaeUzvSNikQjXRELPhCgJLM5dr",
              "timestamp": "2024-03-01T15:06:45Z", "validation_pass": 4,
              "operations_hash":
                "LLoZSMZQEkdSkbJ1zSsaM2M66mys689aUWSAmL29bW447dkQzRCt7",
              "fitness": [ "02", "0000790c", "", "ffffffff", "00000000" ],
              "context":
                "CoVpwvgxqjiyHuDZjmoF2q7pVKtPzWQtoE7mwL2JSweff3BDqAf8",
              "payload_hash":
                "vh2cAMGdJpYDPtQmC4TJY7MRaPiCFDFgbovotTA4oA2tAUSHYain",
              "payload_round": 0, "proof_of_work_nonce": "4b10075700000000",
              "liquidity_baking_toggle_vote": "pass",
              "adaptive_issuance_vote": "on",
              "signature":
                "sigXgX9MxD7cNudAiqAUWsGZJPP51r3HfP5GewEmwPn3m4aAGdQHJt25DGoi4K71u9CrANAqjGi3wUdNoFoKJqDRNiPZiiyp" },
          "bh2":
            { "level": 30988, "proto": 2,
              "predecessor":
                "BL2JDK6ABvDpMUYV8dyJ8xeaGpaeUzvSNikQjXRELPhCgJLM5dr",
              "timestamp": "2024-03-01T15:06:45Z", "validation_pass": 4,
              "operations_hash":
                "LLoapWr6xBACqgUp3rKabCFZaAdr7QrpXWimXwrpRCtgdeCj7Q5Yt",
              "fitness": [ "02", "0000790c", "", "ffffffff", "00000000" ],
              "context":
                "CoVpwvgxqjiyHuDZjmoF2q7pVKtPzWQtoE7mwL2JSweff3BDqAf8",
              "payload_hash":
                "vh2cAMGdJpYDPtQmC4TJY7MRaPiCFDFgbovotTA4oA2tAUSHYain",
              "payload_round": 0, "proof_of_work_nonce": "4b10075700000000",
              "liquidity_baking_toggle_vote": "pass",
              "adaptive_issuance_vote": "on",
              "signature":
                "sigNzTeoA8Ezy9qwje1D8pquEpPSHgXZKRRxEPCHLfsMECyvrkpyoRWeQToiJbnyXmHiSKgBWLEiDEhdcZNThm2FAyoGy53h" },
          "metadata":
            { "forbidden_delegate": "tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT" } } ] } ]

Once denunced, delegate2 became forbidden and could no longer participate in consensus. This means that its (pre)attestations and block proposals were refused by the Tezos protocol until the delegate had been slashed and then unforbidden. This interdiction is lifted once all pending slashes have been applied and the delegate has enough frozen deposits to insure their baking rights for the next cycle. This will happen automatically afterCONSENSUS_RIGHTS_DELAY (which is 2) cycles when rights computed right after the slash take effect, or possibly sooner if the delegate was overstaked or actively stakes more funds to match their previously computed rights. This change aims to protect bakers from incurring further penalties if a faulty configuration causes them to double bake/attest, by giving them some time to fix it.

In our scenario, delegate2 keeps its two bakers running. Thus, several occurrences of the sequence (1) double-baking, (2) denunciation, (3) forbidding, and (4) slashing can be observed.

Slashing happens at the end of the cycle following the one where the misbehaviour was made (letting at least one cycle for denunciations to be made).

Here, we can observe the effect of slashing and how the associated denunciation rewards are alllocated on block #31,232.

    octez-client rpc get /chains/main/blocks/31232/metadata  | jq .balance_updates

[
 ...
  {
    "kind": "freezer",
    "category": "deposits",
    "staker": {
      "baker": "tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT"
    },
    "change": "-28254579268",
    "origin": "delayed_operation",
    "delayed_operation_hash": "ooX9YDDP7iLZUCfevbMgSdWoZVyp6VjtTvYy6K1J7VKh3C79qVT"
  },
  {
    "kind": "freezer",
    "category": "deposits",
    "staker": {
      "delegate": "tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT"
    },
    "change": "-181839777",
    "origin": "delayed_operation",
    "delayed_operation_hash": "ooX9YDDP7iLZUCfevbMgSdWoZVyp6VjtTvYy6K1J7VKh3C79qVT"
  },
  {
    "kind": "burned",
    "category": "punishments",
    "change": "28436419045",
    "origin": "delayed_operation",
    "delayed_operation_hash": "ooX9YDDP7iLZUCfevbMgSdWoZVyp6VjtTvYy6K1J7VKh3C79qVT"
  },
  {
    "kind": "freezer",
    "category": "deposits",
    "staker": {
      "baker": "tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT"
    },
    "change": "-4709096545",
    "origin": "delayed_operation",
    "delayed_operation_hash": "ooX9YDDP7iLZUCfevbMgSdWoZVyp6VjtTvYy6K1J7VKh3C79qVT"
  },
  {
    "kind": "freezer",
    "category": "deposits",
    "staker": {
      "delegate": "tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT"
    },
    "change": "-30306629",
    "origin": "delayed_operation",
    "delayed_operation_hash": "ooX9YDDP7iLZUCfevbMgSdWoZVyp6VjtTvYy6K1J7VKh3C79qVT"
  },
  {
    "kind": "contract",
    "contract": "tz1VXDXJKNZ6Vd8WGoSyrfEXNpManegYm7gd",
    "change": "4739403174",
    "origin": "delayed_operation",
    "delayed_operation_hash": "ooX9YDDP7iLZUCfevbMgSdWoZVyp6VjtTvYy6K1J7VKh3C79qVT"
  },
 ...
  {
    "kind": "burned",
    "category": "lost attesting rewards",
    "delegate": "tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT",
    "participation": true,
    "revelation": false,
    "change": "441366142",
    "origin": "block"
  }
]

We encourage you to look at our New Staking UX proposal document for more information.

It’s also worth noting that, by having misbehaved early in the cycle, and thus being unable to participate in consensus, delegate2 lost all its attesting rewards for the cycle.

Frozen staked balances are impacted by slashing:

delegate2’s balance can be compared before/after slashing using the usual RPC queries:

octez-client rpc get /chains/main/blocks/31231/context/contracts/tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT/staked_balance

"438059817290"

and

octez-client rpc get /chains/main/blocks/31232/context/contracts/tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT/staked_balance

"405096141477"

Same goes for its stakers, as they are slashed proportionally to their contribution of delegate2s stake. For instance, for staker3 we get:

octez-client rpc get /chains/main/blocks/31231/context/contracts/tz1STa3McBCrYBXvcA5bCW4KFQQxCQyxDnXG/staked_balance

"2819249185"

and

octez-client rpc get /chains/main/blocks/31232/context/contracts/tz1STa3McBCrYBXvcA5bCW4KFQQxCQyxDnXG/staked_balance

"2607102779"

As expected, for double baking, slashing induces a penalty of 7% of the frozen_deposits of the offending delegate (as well as for its stakers). 1/7th of this penalty is used to reward the denunciator.

This can be verified with the following RPCs:

octez-client rpc get /chains/main/blocks/30988/context/contracts/tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT/frozen_deposits

"473940317416"

From the balance updates we get:

burned from baker deposits:    28254579268
rewarded from baker deposits:   4709096545
burned from staker deposits:     181839777 
rewarded from staker deposits:    30306629
-------------------------------------------
Total slashed :                33175822219

This total slashed value corresponds to 7% of the total stake deposits observed 473940317416 * 7% = 33175822219.

Note that 7% is the current constant used with Weeklynet, while on Mainnet it’s set to 5% since the activation of Oxford.

1 Like
7

Days 4,5,6 report

Here is a summary of the scenarios executed in the last 3 days.

This report showcases:

  • finalization of unstake requests.

Delegate Actions

  • delegate1 staked 5000 tez on block #40,627
  • delegate2 stopped its second baker on block #40,630
  • delegate1 staked most of its stake on block #40,633

Note on double baking:

The double baking scenario spanning over Days 3 and 4, is both highly improbable, and highly unlikely to occur on Tezos Mainnet.

Delegate2 engaged in double baking on Weeklynet for over 1 day, spanning from block #27,118 to block #40,630, which equates to more than 100 cycles. It’s crucial to grasp the gravity of this situation, as such behavior on Mainnet would entail allowing a misconfigured system to double bake continuously for almost 9 months!.

Additionally, it’s noteworthy that the mechanism in place for forbidding mibehaving delegates effectively halted delegate2 from further instances of double baking after each denunciation, imposing a pause of 1 to 2 cycles. On Mainnet, this would translate to nearly a week, providing ample time for baker operators to identify and rectify any issue in their setup.

Staker Actions

  • staker2 unstaked everything on block #40,628
  • staker3 staked 1000 tez on block #40,629
  • staker5 transferred 1000 tez to staker1 on block #40,630
  • staker5 transferred 1000 tez to staker2 on block #40,631
  • staker5 transferred 1000 tez to staker3 on block #40,632
  • staker3 unstaked 1000 tez on block #51,886
  • staker1 unstaked everything on block #63,674
  • staker3 unstaked 1000 tez on block #63,675
  • staker5 finalized its unstake request on block #66,244
  • staker5 transferred 1000 tez to staker4 on block #66,279

Observations

  • unstake requests finalization: Unstake requests undergo finalization 4 cycles after their registration. However, for optimal performance, they are only finalized upon request, either explicitly through calls to finalize unstake or implicitly when using other staker-related commands such as stake/unstake. In this instance, after transferring funds to staker1, staker2, and staker3, staker5 lacks a sufficient spendable balance to transfer #1000 tez to staker4. To enable this transfer, staker5 explicitly finalizes its unstake requests at block #66,244.

This process can be observed using the unstake_requests RPC endpoint. For example, the unstake request of staker5 before this call can be viewed using the following query:

octez-client rpc get /chains/main/blocks/66243/context/contracts/tz1STa5sAAHotnBvcecV2Cr41c4Uczv23TvT/unstake_requests

{ "finalizable":
    [ { "delegate": "tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT", "cycle": 120,
        "amount": "6532673491" } ],
  "unfinalizable":
    { "delegate": "tz1dLG2tSWJzYXRNEeQQWoYpF5rCB5WF33yT", "requests": [] } }

It’s spendable balance is observable using the balance RPC endpoint. For example, before finalizing its unstake request, staker5’s spendable balance was not sufficient to do the transfer of 1000 tez as observed by the following query:

octez-client rpc get /chains/main/blocks/66243/context/contracts/tz1STa5sAAHotnBvcecV2Cr41c4Uczv23TvT/balance

"999995870"

After finalization, both requests and spendable balance are updated allowing staker5 to transfer tez to others.

octez-client rpc get /chains/main/blocks/66244/context/contracts/tz1Sta5sAAHotnBvcecV2Cr41c4Uczv2
3TvT/unstake_requests

null

and

octez-client rpc get /chains/main/blocks/66244/context/contracts/tz1Sta5sAAHotnBvcecV2Cr41c4Uczv2
3TvT/balance

"7532668932"
1 Like
8

Last day report

Today, we’ll reflect on the entire week and delve into how various events and delegate parameters influenced stakes and rewards.

Bakers

Throughout the week, the two delegates pursued distinct strategies:

  • Delegate1 adopted a conservative approach, initially staking a smaller amount of tez. It began with a staking over baking edge set at 100%, later adjusted to 50%, which was more enticing for stakers as depicted in the following chart.

delegate1
delegate1960×540 16.9 KB

  • In contrast, Delegate2 staked a substantial amount of tez and maintained a staking over baking edge of 10% from the outset.
    However, on Day 3, Delegate2 encountered challenges with double baking, triggering a cascade of denunciations and slashing. While not directly tied to the staking user experience, this scenario provided insight into how the network handles misbehaving delegates. Notably, despite Delegate2 possessing a considerable stake, its exclusion from consensus had minimal impact on the network.
    The following chart illustrates the progression of Delegate2’s staked balance over the week:

delegate2
delegate2960×540 20.8 KB

We observeDelegate2’s stake growing with rewards before being impacted by slashing. The staircase pattern reflects the effect of the forbidding mechanism, which imposed a 1 to 2-cycle prohibition on double baking after each denunciation.

Stakers

Similarly, we can track the evolution of staker’s balances throughout the week.

Staker1 pursued a straigthforward strategy. Initially, it staked a significant portion of its balance. However, due to Delegate1 maintaining a 100% edge, Staker1 did not receive any staking rewards. Subsequently, it unstaked part of its stake and changed its delegate. It’s important to note that changing delegates triggers an implicit unstake everything, and funds cannot be staked via the new delegate until all unstake requests are finalized. As a result, Staker1 did not restake and therefore did not benefit from the staking mechanism.

staker1
staker1960×540 16.5 KB

In contrast, Staker2 pursued a simpler strategy, staking its entire balance with Delegate1 and eventually unstaking everything:

staker2
staker2960×540 22 KB

Although Staker2’s behavior was straightforward, it’s worth noting how its chosen delegate’s settings influenced its rewards. With Delegate1 maintaining a 100% edge, Staker2 did not receive any staking rewards initially. However, after Delegate1 adjusted its baking over staking edge to 50% on Day 3, Staker2 began accruing staking rewards.

Staker3’s scenario was more intricate. Initially, it increased its staked balance through regular manual stake operations before choosing to unstake towards the end of the week. Since Staker3 delegated to Delegate2, it was affected by its chosen baker’s misbehavior and consequently was slashed proportionally.

staker3
staker3960×540 28.6 KB

Staker4 chose not to stake at all, thus never earning staking rewards from its delegate. However, it was also unaffected by its delegate’s misbehavior and subsequent slashing.

Staker5 initially delegated to Delegate2 and began receiving staking rewards immediately. However, it later changed its delegate, resulting in Staker5 unstaking all its stake as it did not restake.

staker5
staker5960×540 15.9 KB

Tracking Adaptive Issuance

Additionally, examining the overall issuance during the week provides valuable insights. The following figure illustrates how both the issuance rate and stake ratio evolved over the week.

issuance
issuance960×540 31.9 KB

As expected, with the progressive min-max mechanism in place, the yearly rate followed the progressive max curve, increasing from 5.5% to almost 10%. The high issuance rate can be attributed to the low stake ratio observed on Weeklynet (below 1% of the total supply). Furthermore, this chart depicts the effect of the double baking scenario on the stake ratio, particularly highlighting the impact of the forbidding mechanism. This mechanism repeatedly forbade Delegate2 , rendering it inactive for one cycle, which decreased the total staked supply until its automatic reactivation.

Conclusions

Throughout the week, we explored various scenarios demonstrating how delegates and stakers manage their stakes. We showcased how these actions can be effectively observed, monitored, and managed with the support provided by the Octez suite – that is, by quering the RPC endpoints provided by Octez nodes and the staking commands implemented as a part of the Octez client’s CLI.

Our aim was to provide insight on the intricacies of the staking process, including how the parameters set up by bakers influence protocol-allocated rewards and staked balances.

We also illustrated how the protocol is equipped to address potential delegate’s missbehavior, and how it might impact their stakers – Again, the scenario presented is highly improbable on Mainnet.

As this reports marks the end of our initial exploration, we wait eagerly for your feedback. It will allow us to build further upon this experience, delving into the evolving features of the protocol, and developing additional scenarios to address bakers and users concerns.

2 Likes