PV Updated Notification

[buckyroberts]

Background Information

Bank will attempt to update PV when:

• the Bank can't communicate with PV (receives an error message after sending the PV a block)
• their CV's are reporting invalid blocks from the PV
• the maintainer of Bank manually updates the trust level of their Validators so that a CV is more trusted than the current PV

Docs - https://thenewboston.com/guide/resync-triggers

---

Feature Requirements

When a Bank updates their PV, in addition to notifying all of their CV's (that logic is already implemented) the Banks also need to stream down notifications to users so their apps can be updated to use the new PV.

Tech Notes

• path - /ws/primary_validator_updated
• notification_type - PRIMARY_VALIDATOR_UPDATED_NOTIFICATION
• payload - /config data of the new PV

Sample Notification Shape

{
  "notification_type": "PRIMARY_VALIDATOR_UPDATED_NOTIFICATION",
  "payload": {
    "primary_validator": null,
    "account_number": "2e86f48216567302527b69eae6c6a188097ed3a9741f43cc3723e570cf47644c",
    "ip_address": "54.183.17.224",
    "node_identifier": "2262026a562b0274163158e92e8fbc4d28e519bc5ba8c1cf403703292be84a51",
    "port": null,
    "protocol": "http",
    "version": "v1.0",
    "default_transaction_fee": 1,
    "root_account_file": "http://54.183.17.224/media/root_account_file.json",
    "root_account_file_hash": "cc9390cc579dc8a99a1f34c1bea5d54a0f45b27ecee7e38662f0cd853f76744d",
    "seed_block_identifier": "",
    "daily_confirmation_rate": null,
    "node_type": "PRIMARY_VALIDATOR"
  }
}

[fonar]

@buckyroberts i'm using standard Validator serializer from Bank project to generate the response payload, but, it different from Validator serializer from Validator project. This is what i get when i use it:

{
  "notification_type": "PRIMARY_VALIDATOR_UPDATED_NOTIFICATION",
  "payload": {
    "account_number": "ad1f8845c6a1abb6011a2a434a079a087c460657aad54329a84b406dce8bf314",
    "ip_address": "192.168.1.65",
    "node_identifier": "3afdf37573f1a511def0bd85553404b7091a76bcd79cdcebba1310527b167521",
    "port": 8000,
    "protocol": "http",
    "version": "v1.0",
    "default_transaction_fee": 4,
    "root_account_file": "https://gist.githubusercontent.com/buckyroberts/519b5cb82a0a5b5d4ae8a2175b722520/raw/9237deb449e27cab93cb89ea3346ecdfc61fe9ea/0.json",
    "root_account_file_hash": "4694e1ee1dcfd8ee5f989e59ae40a9f751812bf5ca52aca2766b322c4060672b",
    "seed_block_identifier": "",
    "daily_confirmation_rate": null,
    "trust": "100.00"
  }
}

the only differences is:

1. missing "node_type": "PRIMARY_VALIDATOR" field, but we clients will know already that it's primary validator
2. "trust": "100.00" field. Maybe it could be useful for clients? Or they can just ignore it.

If that config that was created by Validator serializer on Bank side work for us, we can leave it as it is and merge.
If we need config in the absolutely same format as validator returns, here is ways to do it (maybe i missed somethong and there is more correct way?)

Any of this:

1. Jsut removing 'trust' and adding 'notification type'
2. Add logic that will always requets validator config from PV on changing PV, as now, for example, its not available during status_updated/upgrade_notice, when bank receive notification, it could just switch validator to primary not having his original config at that time
3. Include validator config in upgrade_notice notification from validator
4. Refactor and move serializers to thenewboston-python, so, Bank project will be able to use his own serializer for Validator but also Validator serializer from Validator project.

[buckyroberts]

@fonar the standard Validator serializer from Bank project is good to use. The client won't be using those extra fields.