Peerplays_Blockchain/peerplays_migrated

Fork 0

Transaction signing counters are not proper #502

New issue

Closed

opened 2023-01-25 14:28:19 +00:00 by prandnum · 8 comments

prandnum commented

2023-01-25 14:28:19 +00:00

(Migrated from gitlab.com)

Steps Executed:

Brought up docker QA environment
waited for the maintenance period.
ran test_hive_son.py 20 times
40 transaction objects are created

Issue seen:

total_txs_signed hive counters are less than sidechain transactions objects
txs_signed hive counters are not reset to 0 after maintenance period.

Steps Executed: 1) Brought up docker QA environment 2) waited for the maintenance period. 3) ran test_hive_son.py 20 times 4) 40 transaction objects are created Issue seen: 1. total_txs_signed hive counters are less than sidechain transactions objects 2. txs_signed hive counters are not reset to 0 after maintenance period.

prandnum commented

2023-01-25 14:42:24 +00:00

(Migrated from gitlab.com)

Relevant details:

account-balances.txt

account-history.txt

sidechain-statistics.txt

sidechain-transaction.txt

Relevant details: [account-balances.txt](/uploads/1bc278e228bdfbdfbefff7048a623bcb/account-balances.txt) [account-history.txt](/uploads/a02657b52c3b9f1075417a4139f4c813/account-history.txt) [sidechain-statistics.txt](/uploads/7188561c19afe4be1a30dd61831337d5/sidechain-statistics.txt) [sidechain-transaction.txt](/uploads/17499e15e0aa3bc7ca2ba1ae88c0ba9b/sidechain-transaction.txt)

prandnum commented

2023-01-25 14:42:59 +00:00

(Migrated from gitlab.com)

@bobinson @serkixenos
CC: @tai.sama

@bobinson @serkixenos CC: @tai.sama

vampik commented

2023-02-02 06:38:43 +00:00

(Migrated from gitlab.com)

assigned to @vampik

vampik commented

2023-02-03 06:02:11 +00:00

(Migrated from gitlab.com)

@prandnum

total_txs_signed counters are not equal to sidechain transactions objects. So, it is ok.

When transaction signing happens, we don't need to have signatures of all active SON's. We check how many signatures this transaction already has. And if it is enough (2/3), SON wouldn't sign the transaction. Let's say we have 5 active SONs, we need only 4 SON's to sign the transaction (not all 5).

I checked on my side and txs_signed is reset to 0. Please check this again.

So I don't see the issue here, and I think it can be closed.

@prandnum 1) `total_txs_signed` counters are not equal to sidechain transactions objects. So, it is ok. When transaction signing happens, we don't need to have signatures of all active SON's. We check how many signatures this transaction already has. And if it is enough (2/3), SON wouldn't sign the transaction. Let's say we have 5 active SONs, we need only 4 SON's to sign the transaction (not all 5). 2) I checked on my side and `txs_signed` is reset to 0. Please check this again. So I don't see the issue here, and I think it can be closed.

vampik commented

2023-02-07 06:54:53 +00:00

(Migrated from gitlab.com)

assigned to @prandnum

prandnum commented

2023-02-20 19:44:55 +00:00

(Migrated from gitlab.com)

@vampik even after two maintenance periods finished the counter is not reset to 0.
attaching full logs: counters.log
branch: beatrice

@vampik even after two maintenance periods finished the counter is not reset to 0. attaching full logs: [counters.log](/uploads/0160cb50ab1be09438e945f6513987d9/counters.log) branch: beatrice

serkixenos commented

2023-02-21 05:32:00 +00:00

(Migrated from gitlab.com)

Lets make sure we understand whats happening here... Look into next_maintenance_time and last_son_payout_time

unlocked >>> get_dynamic_global_properties 
get_dynamic_global_properties 
{
  "id": "2.1.0",
  "random": "109d02c3897973194c24a1bcd189440a0767af94",
  "head_block_number": 2038,
  "head_block_id": "000007f67a0db2381ab3a94a092e338368b6df4c",
  "time": "2023-02-20T19:39:36",
  "current_witness": "1.6.8",
  "next_maintenance_time": "2023-02-20T19:40:00",
  "last_budget_time": "2023-02-20T19:30:00",
  "witness_budget": 11000000,
  "last_son_payout_time": "2023-02-20T18:20:00",
  "son_budget": 20000000,
  "accounts_registered_this_interval": 0,
  "recently_missed_count": 0,
  "current_aslot": 15247776,
  "recent_slots_filled": "340282366920938463463374607431768211455",
  "dynamic_flags": 0,
  "last_irreversible_block_num": 2030
}
unlocked >>> get_dynamic_global_properties 
get_dynamic_global_properties 
{
  "id": "2.1.0",
  "random": "1e6fafd8ae87cd1d019e3923a1b579ed3c7a8db9",
  "head_block_number": 2056,
  "head_block_id": "00000808b17c80700754c0acbbd000b50533b1b8",
  "time": "2023-02-20T19:40:39",
  "current_witness": "1.6.1",
  "next_maintenance_time": "2023-02-20T19:50:00",
  "last_budget_time": "2023-02-20T19:40:00",
  "witness_budget": 190000000,
  "last_son_payout_time": "2023-02-20T18:20:00",
  "son_budget": 20000000,
  "accounts_registered_this_interval": 0,
  "recently_missed_count": 0,
  "current_aslot": 15247794,
  "recent_slots_filled": "340282366920938463463374607431768211455",
  "dynamic_flags": 0,
  "last_irreversible_block_num": 2049
}
unlocked >>>

Look at the condition for executing son payment in pay_sons function:

void database::pay_sons()
{
   const time_point_sec now = head_block_time();
   const dynamic_global_property_object& dpo = get_dynamic_global_properties();
   // Current requirement is that we have to pay every 24 hours, so the following check
   if( dpo.son_budget.value > 0 && ((now - dpo.last_son_payout_time) >= fc::seconds(get_global_properties().parameters.son_pay_time())))

Transaction counters reset is happening on son payout. According to logs, son payout did not happened, otherwise last_son_payout_time would be updated. SON payout time is 1 day in QA env. Maintenance period is 10 minutes. It is not expected to execute son payments in each maintenance. It is expected that son payment will be executed during maintenance block, when son pay time expires.

However, maybe we should align son_pay_time with maintenance_interval in QA env, Eg, we should check whats the current values of these two params on the mainnet, and align to that...

Lets make sure we understand whats happening here... Look into next_maintenance_time and last_son_payout_time ``` unlocked >>> get_dynamic_global_properties get_dynamic_global_properties { "id": "2.1.0", "random": "109d02c3897973194c24a1bcd189440a0767af94", "head_block_number": 2038, "head_block_id": "000007f67a0db2381ab3a94a092e338368b6df4c", "time": "2023-02-20T19:39:36", "current_witness": "1.6.8", "next_maintenance_time": "2023-02-20T19:40:00", "last_budget_time": "2023-02-20T19:30:00", "witness_budget": 11000000, "last_son_payout_time": "2023-02-20T18:20:00", "son_budget": 20000000, "accounts_registered_this_interval": 0, "recently_missed_count": 0, "current_aslot": 15247776, "recent_slots_filled": "340282366920938463463374607431768211455", "dynamic_flags": 0, "last_irreversible_block_num": 2030 } unlocked >>> get_dynamic_global_properties get_dynamic_global_properties { "id": "2.1.0", "random": "1e6fafd8ae87cd1d019e3923a1b579ed3c7a8db9", "head_block_number": 2056, "head_block_id": "00000808b17c80700754c0acbbd000b50533b1b8", "time": "2023-02-20T19:40:39", "current_witness": "1.6.1", "next_maintenance_time": "2023-02-20T19:50:00", "last_budget_time": "2023-02-20T19:40:00", "witness_budget": 190000000, "last_son_payout_time": "2023-02-20T18:20:00", "son_budget": 20000000, "accounts_registered_this_interval": 0, "recently_missed_count": 0, "current_aslot": 15247794, "recent_slots_filled": "340282366920938463463374607431768211455", "dynamic_flags": 0, "last_irreversible_block_num": 2049 } unlocked >>> ``` Look at the condition for executing son payment in pay_sons function: ``` void database::pay_sons() { const time_point_sec now = head_block_time(); const dynamic_global_property_object& dpo = get_dynamic_global_properties(); // Current requirement is that we have to pay every 24 hours, so the following check if( dpo.son_budget.value > 0 && ((now - dpo.last_son_payout_time) >= fc::seconds(get_global_properties().parameters.son_pay_time()))) ``` Transaction counters reset is happening on son payout. According to logs, son payout did not happened, otherwise last_son_payout_time would be updated. SON payout time is 1 day in QA env. Maintenance period is 10 minutes. It is not expected to execute son payments in each maintenance. It is expected that son payment will be executed during maintenance block, when son pay time expires. However, maybe we should align son_pay_time with maintenance_interval in QA env, Eg, we should check whats the current values of these two params on the mainnet, and align to that...

prandnum commented

2023-02-23 17:53:01 +00:00

(Migrated from gitlab.com)

After payout the txs_signed counters are reset. closing it.

prandnum (Migrated from gitlab.com) closed this issue

2023-02-23 17:53:02 +00:00