Witness rename

.gitignore

@@ -38,7 +38,7 @@ tests/intense_test
 tests/performance_test
 
 wallet.json
-witness_node_data_dir
+node_data_dir
 
 *.wallet
 

.qoder/docs/block-processing.md

@@ -393,7 +393,7 @@ When block at T=6 is pushed, `update_global_dynamic_data()` counts `missed_block
 |---|---|---|
 | Sync status | Chain is not stale (or `enable-stale-production`) | `not_synced` |
 | Slot time | `get_slot_at_time(now) > 0` | `not_time_yet` |
-| validator ownership | Scheduled validator is in our `_witnesses` set | `not_my_turn` |
+| validator ownership | Scheduled validator is in our `_validators` set | `not_my_turn` |
 | Signing key | validator has non-zero `signing_key` on chain | `not_my_turn` |
 | Private key | We have the private key for the signing key | `no_private_key` |
 | Participation | Network participation ≥ required (pre-HF12 only) | `low_participation` |

.qoder/docs/consensus-emergency-params.md

@@ -428,7 +428,7 @@ maybe_produce_block()
   │
   ├─ [HF12+] Is emergency_consensus_active?
   │   └─ Yes: Three-state safety handles production/sync checks:
-  │       ├─ IS emergency master? (emergency key in _witnesses)
+  │       ├─ IS emergency master? (emergency key in _validators)
   │       │   └─ Yes: _production_enabled = true (bypass sync/stale/participation)
   │       └─ NOT emergency master (slave):
   │           ├─ _production_enabled already? → continue

.qoder/docs/hf13-validator-reward-sharing.md

@@ -113,14 +113,14 @@ wit.pending_stakeholder_reward = 0
 
 ### Important notes
 
-- **Vote weight** used: `stakeholder.witness_vote_fair_weight()` — total stake (own vesting
+- **Vote weight** used: `stakeholder.validator_vote_fair_weight()` — total stake (own vesting
   shares + shares proxied by accounts that delegated voting to this stakeholder) divided by
-  `witnesses_voted_for`.  This matches the per-validator weight used in consensus scheduling:
+  `validators_voted_for`.  This matches the per-validator weight used in consensus scheduling:
   a stakeholder who splits their vote across N validators contributes 1/N of their stake to
   each validator's distribution pool.
 - **Time-weighted distribution**: each stakeholder's weight is multiplied by the number of blocks
   they were actually voting for this validator within the current epoch (see `vote_created_block`
-  on `witness_vote_object`).  A stakeholder who joined mid-epoch receives a proportionally smaller
+  on `validator_vote_object`).  A stakeholder who joined mid-epoch receives a proportionally smaller
   share.
 - **Pre-HF13 votes** (`vote_created_block == 0`) are treated as having voted since epoch start
   (`first_block = epoch_start_block`), so they receive a full-epoch weight.  No penalty for
@@ -129,7 +129,7 @@ wit.pending_stakeholder_reward = 0
   Stakeholders with a computed share below this threshold receive nothing; their portion is
   returned to the validator as dust (see design rationale below).
 - **No-stakeholder case**: if a validator has no stakeholders, the entire accumulated pool is
-  returned to the validator via `witness_reward_operation`.
+  returned to the validator via `validator_reward_operation`.
 
 #### Dust design rationale
 
@@ -141,7 +141,7 @@ lies with the stakeholder, not with the validator.
 
 Consequently, unclaimed dust is **not burned**.  After all eligible stakeholders are paid, any
 remainder (dust from integer rounding, plus skipped sub-threshold shares) is transferred back to
-the validator via `witness_reward_operation`.  The validator retains what their stakeholders
+the validator via `validator_reward_operation`.  The validator retains what their stakeholders
 collectively failed to claim — no TOKEN leaves the system, and the validator is not penalised for
 stakeholders with negligible weight.
 
@@ -163,7 +163,7 @@ pending_stakeholder_reward =
 
 The pool that stakeholders receive at epoch end is thus a weighted mix of both rates.  This is the
 intended behaviour: the validator controls their own split on a per-block basis, and stakeholders
-observe the change immediately on-chain via the `sharing_rate` field of the `witness_object`.
+observe the change immediately on-chain via the `sharing_rate` field of the `validator_object`.
 
 ---
 
@@ -174,7 +174,7 @@ the **time-weighted distribution** described above.
 
 ### How it works
 
-`witness_vote_object` stores `vote_created_block` — the block number when the vote was cast.  At
+`validator_vote_object` stores `vote_created_block` — the block number when the vote was cast.  At
 epoch end, each stakeholder's effective weight is scaled by:
 
 ```
@@ -191,7 +191,7 @@ The protection covers **new votes** only.  If a stakeholder already held a vote
 epoch, they receive a full-epoch weight regardless of their stake changes within the epoch.  This
 is acceptable: they were genuine stakeholders.
 
-Vote removal before epoch end results in the stakeholder not appearing in `witness_vote_index` at
+Vote removal before epoch end results in the stakeholder not appearing in `validator_vote_index` at
 distribution time, so they receive nothing — no exploit in this direction.
 
 ---
@@ -323,15 +323,14 @@ If auto-recovery is not configured, or the recovery path fails, perform the foll
 systemctl stop vizd
 
 # 2. Delete shared memory (forces clean open on next start)
-rm -f /path/to/witness_node_data_dir/shared_memory.bin
-rm -f /path/to/witness_node_data_dir/shared_memory.meta
+rm -f /path/to/node_data_dir/shared_memory.bin
 
 # Option A — restore from snapshot + replay dlt_block_log:
 ./vizd --replay-from-snapshot /path/to/snapshot-block-XXXXXXXX.json \
-       --data-dir /path/to/witness_node_data_dir
+       --data-dir /path/to/node_data_dir
 
 # Option B — full replay from block_log (slow):
-./vizd --replay --data-dir /path/to/witness_node_data_dir
+./vizd --replay --data-dir /path/to/node_data_dir
 ```
 
 After Option A the node replays `dlt_block_log` automatically (same path as auto-recovery),

.qoder/docs/plugins.md

@@ -145,7 +145,7 @@ Peer-to-peer networking for block and transaction propagation.
 **Config options:**
 ```ini
 p2p-endpoint = 0.0.0.0:2001
-p2p-seed-node = seed.viz.world:2001
+p2p-seed-node = seed1.viz.world:2001
 p2p-max-connections = 200
 p2p-stats-enabled = true
 p2p-stats-interval = 300

.qoder/docs/snapshot-plugin.md

@@ -626,13 +626,15 @@ With `config.ini`:
 ```ini
 trusted-snapshot-peer = seed1.viz.world:8092
 trusted-snapshot-peer = seed2.viz.world:8092
+trusted-snapshot-peer = seed3.viz.world:8092
 ```
 
 Since `sync-snapshot-from-trusted-peer` defaults to `false`, you must explicitly enable it in `config.ini` along with `trusted-snapshot-peer`:
 
 ```ini
 trusted-snapshot-peer = seed1.viz.world:8092
 trusted-snapshot-peer = seed2.viz.world:8092
+trusted-snapshot-peer = seed3.viz.world:8092
 sync-snapshot-from-trusted-peer = true
 ```
 

@l10n/ru/docs/advanced/database-schema.md

@@ -48,7 +48,7 @@ VIZ Ledger использует ChainBase — персистентное хра
 
 Аккаунты хранят балансы, состояние вестинга, метрики делегирования, пропускную способность, флаги аукциона/продажи и участие в управлении.
 
-**Ключевые поля:** `name`, `balance` (VIZ), `vesting_shares`, `delegated_vesting_shares`, `received_vesting_shares`, `energy`, `next_vesting_withdrawal`, `witnesses_voted_for`, `recovery_account`.
+**Ключевые поля:** `name`, `balance` (VIZ), `vesting_shares`, `delegated_vesting_shares`, `received_vesting_shares`, `energy`, `next_vesting_withdrawal`, `validators_voted_for`, `recovery_account`.
 
 **Индексы:**
 
@@ -94,9 +94,9 @@ VIZ Ledger использует ChainBase — персистентное хра
 
 ---
 
-## Объекты валидатора (Witness)
+## Объекты валидатора
 
-**Индексы `witness_object`:**
+**Индексы `validator_object`:**
 
 | Тег | Ключ |
 |-----|------|

@l10n/ru/docs/advanced/dlt-architecture.md

@@ -124,7 +124,7 @@ CONNECTING → HANDSHAKING → SYNCING → ACTIVE → DISCONNECTED → BANNED
 
 Подсистема разрешения форков отслеживает конкурирующие верхушки цепочки:
 
-- **Порог:** 42 блока расхождения запускают `resolve_fork()` (= `CHAIN_MAX_WITNESSES × 2`, один полный оборот расписания).
+- **Порог:** 42 блока расхождения запускают `resolve_fork()` (= `CHAIN_MAX_VALIDATORS × 2`, один полный оборот расписания).
 - **Выбор:** Наиболее тяжёлая ветка по весу голосов.
 - **Гистерезис:** 6 последовательных блоков как победитель перед переключением (`CONFIRMATION_BLOCKS`).
 - **Статус:** `_fork_status` открыт через `is_on_majority_fork()` для плагина валидатора для проверки перед производством блоков.

@l10n/ru/docs/advanced/hardfork-management.md

@@ -57,7 +57,7 @@ HF12 вводит автоматическое восстановление се
 
 ### Активация
 
-Если метка времени последнего необратимого блока (LIB) отстаёт от системных часов более чем на `CHAIN_EMERGENCY_CONSENSUS_TIMEOUT_SEC` (1 час), аварийный режим активируется автоматически. Создаётся аварийный аккаунт валидатора (`CHAIN_EMERGENCY_WITNESS_ACCOUNT = "committee"`) с известным публичным ключом (`CHAIN_EMERGENCY_WITNESS_PUBLIC_KEY`) и вставляется в расписание производства блоков.
+Если метка времени последнего необратимого блока (LIB) отстаёт от системных часов более чем на `CHAIN_EMERGENCY_CONSENSUS_TIMEOUT_SEC` (1 час), аварийный режим активируется автоматически. Создаётся аварийный аккаунт валидатора (`CHAIN_EMERGENCY_VALIDATOR_ACCOUNT = "committee"`) с известным публичным ключом (`CHAIN_EMERGENCY_VALIDATOR_PUBLIC_KEY`) и вставляется в расписание производства блоков.
 
 ### Трёхуровневое обеспечение безопасности
 

@l10n/ru/docs/api/json-rpc.md

@@ -52,7 +52,7 @@
 |-----------------|-------|---------|
 | `database_api` | Активен | Запросы блоков, аккаунтов, состояния цепочки |
 | `network_broadcast_api` | Активен | Трансляция транзакций и блоков |
-| `witness_api` | Активен | Запросы валидаторов |
+| `validator_api` | Активен | Запросы валидаторов |
 | `account_by_key` | Активен | Обратный поиск по ключу |
 | `account_history` | Активен | История операций аккаунта |
 | `operation_history` | Активен | Запросы операций блока |
@@ -119,18 +119,18 @@
 
 ---
 
-## Методы `witness_api`
+## Методы `validator_api`
 
 | Метод | Описание |
 |-------|---------|
-| `get_active_witnesses()` | Текущий активный набор валидаторов (21 аккаунт) |
-| `get_witness_schedule()` | Полный объект расписания валидаторов |
-| `get_witnesses(ids[])` | Валидаторы по внутренним ID |
-| `get_witness_by_account(account)` | Объект валидатора для аккаунта |
-| `get_witnesses_by_vote(lower_bound, limit)` | Валидаторы по убыванию веса голосов |
-| `get_witnesses_by_counted_vote(lower_bound, limit)` | Валидаторы по числу голосов |
-| `get_witness_count()` | Общее количество зарегистрированных валидаторов |
-| `lookup_witness_accounts(lower_bound, limit)` | Список имён аккаунтов валидаторов |
+| `get_active_validators()` | Текущий активный набор валидаторов (21 аккаунт) |
+| `get_validator_schedule()` | Полный объект расписания валидаторов |
+| `get_validators(ids[])` | Валидаторы по внутренним ID |
+| `get_validator_by_account(account)` | Объект валидатора для аккаунта |
+| `get_validators_by_vote(lower_bound, limit)` | Валидаторы по убыванию веса голосов |
+| `get_validators_by_counted_vote(lower_bound, limit)` | Валидаторы по числу голосов |
+| `get_validator_count()` | Общее количество зарегистрированных валидаторов |
+| `lookup_validator_accounts(lower_bound, limit)` | Список имён аккаунтов валидаторов |
 
 ---
 
@@ -214,7 +214,7 @@ plugin = database_api network_broadcast_api
 
 **Полный API-узел (добавить):**
 ```ini
-plugin = witness_api account_by_key account_history operation_history
+plugin = validator_api account_by_key account_history operation_history
 plugin = committee_api invite_api paid_subscription_api
 ```
 

@l10n/ru/docs/consensus/block-processing.md

@@ -279,7 +279,7 @@ check_block_post_validation_chain():
 struct block_post_validation_message {
     block_id_type  block_id;
     std::string    witness_account;   // имя валидатора
-    signature_type witness_signature; // sign(chain_id + block_id)
+    signature_type validator_signature; // sign(chain_id + block_id)
 };
 ```
 

@l10n/ru/docs/consensus/emergency-consensus.md

@@ -9,11 +9,11 @@
 | Константа | Значение | Значение |
 |-----------|---------|---------|
 | `CHAIN_EMERGENCY_CONSENSUS_TIMEOUT_SEC` | 3600 с | Время простоя до активации |
-| `CHAIN_EMERGENCY_WITNESS_ACCOUNT` | `"committee"` | Аккаунт экстренного производителя блоков |
-| `CHAIN_EMERGENCY_WITNESS_PUBLIC_KEY` | `VIZ75CR...` | Детерминированный ключ подписи для экстренного режима |
+| `CHAIN_EMERGENCY_VALIDATOR_ACCOUNT` | `"committee"` | Аккаунт экстренного производителя блоков |
+| `CHAIN_EMERGENCY_VALIDATOR_PUBLIC_KEY` | `VIZ75CR...` | Детерминированный ключ подписи для экстренного режима |
 | `CHAIN_EMERGENCY_EXIT_NORMAL_BLOCKS` | 21 | Последовательные блоки реальных валидаторов для выхода |
 | `CHAIN_IRREVERSIBLE_THRESHOLD` | 75% | Доля слотов расписания для выхода |
-| `CHAIN_MAX_WITNESSES` | 21 | Максимальное количество слотов валидаторов |
+| `CHAIN_MAX_VALIDATORS` | 21 | Максимальное количество слотов валидаторов |
 
 ### Поля состояния в `dynamic_global_property_object`
 
@@ -41,12 +41,12 @@
 
 1. Установить `dgp.emergency_consensus_active = true` и `dgp.emergency_consensus_start_block = block_num`.
 2. Создать или обновить объект валидатора "committee":
-   - `signing_key = CHAIN_EMERGENCY_WITNESS_PUBLIC_KEY`
+   - `signing_key = CHAIN_EMERGENCY_VALIDATOR_PUBLIC_KEY`
    - `props = current_median_props`
    - Голоса за харфорки установлены на текущую применённую версию (нейтральный голосователь).
 3. Отключить ВСЕХ реальных валидаторов: установить `signing_key = zero`, сбросить `penalty_percent = 0`, `current_run = 0`.
 4. Удалить все объекты `witness_penalty_expire`.
-5. Переопределить расписание валидаторов: все `CHAIN_MAX_WITNESSES` слотов → "committee".
+5. Переопределить расписание валидаторов: все `CHAIN_MAX_VALIDATORS` слотов → "committee".
 6. Уведомить fork DB: `_fork_db.set_emergency_mode(true)` (включает детерминированное разрешение хэш-ничьих).
 7. Лог: `"EMERGENCY CONSENSUS MODE activated at block #N. No blocks for X seconds since LIB Y."`
 
@@ -60,7 +60,7 @@
 
 ```ini
 # Только для экстренного мастер-узла
-emergency-private-key = 5Jzzz...   # приватный ключ CHAIN_EMERGENCY_WITNESS_ACCOUNT
+emergency-private-key = 5Jzzz...   # приватный ключ CHAIN_EMERGENCY_VALIDATOR_ACCOUNT
 ```
 
 | Роль | Проверка DLT-синхронизации | Проверка minority fork | Производство |
@@ -105,7 +105,7 @@ Committee исключается из подсчёта версий харфор
 Каждое перестроение расписания проверяет условие выхода:
 
 ```
-real_witness_slots >= CHAIN_MAX_WITNESSES × 75%
+real_witness_slots >= CHAIN_MAX_VALIDATORS × 75%
 ```
 
 При 21 валидаторе: `21 × 0.75 = 15.75 → 15` слотов реальных валидаторов требуется.
@@ -133,7 +133,7 @@ real_witness_slots >= CHAIN_MAX_WITNESSES × 75%
 
 ## Интеграция с Validator Guard
 
-Плагин `witness_guard` продолжает работу во время экстренного режима и фактически становится более критичным:
+Плагин `validator_guard` продолжает работу во время экстренного режима и фактически становится более критичным:
 
 - Реальные валидаторы отключаются (ключ подписи обнуляется) при активации.
 - Защита валидатора автоматически транслирует `validator_update_operation` для восстановления ключа подписи каждого валидатора, как только на цепочке обнаруживается нулевой ключ.
@@ -199,7 +199,7 @@ real_witness_slots >= CHAIN_MAX_WITNESSES × 75%
 | 9 | `stale_sync_check_task` | Пропустить если голова мастера продвигается; разрешить если последователь застрял |
 | 10 | `handle_block` | Почти догнавшие блоки обрабатываются как нормальные в DLT-экстренном режиме |
 | 11 | `database::open` | Исправление расписания при запуске |
-| 12 | `witness_guard` | Не подавлять восстановление ключей в экстренном режиме |
+| 12 | `validator_guard` | Не подавлять восстановление ключей в экстренном режиме |
 | 13 | `snapshot import` | Совместимая обработка полей |
 | 14 | `update_witness_schedule` | Исключать committee из подсчёта версий харфорков |
 | 15 | `update_median_witness_props` | Исключать committee из вычисления медианы |