Делегатские параметры.

[asuleymanov]

Предлагаю по возможности подумать над вариантом сделать параметры опциональными, т.е. при что бы обновлении конкретного делегатского параметра не пришлось передавать каждый раз и все остальные.
Когда параметров 2-4 это еще ничего терпимо. Но при увеличении их колличества обновление становиться похожа на пытку.
А как понимаю они увеличатся в 19 ХФ.

[afalaleev]

Это можно сделать на стороне клиента.
Берутся текущие настройки из чейна и нужные параметры заменяются новыми значениями.
Такая стратегия уже реализована в cli_wallet.

[asuleymanov]

А почемубы не облегчить жизнь клиентам.
Ведь как я понимаю всего лишь надо выставить optional в БЧ.

[afalaleev]

Сделать несложно, последствия не очень хорошие.
Логика на уровне БЧ должна быть как можно более универсальной, не стоит ее перегружать всевозможными вариантами под всевозможные модели поведения клиентов.
Любые подобные изменения приводят к необходимости выпускать ХФ. В случае Голос у ХФ есть жесткие сроки на запуск, в отличие от CyberWay где подобная тактика не требует выпусков ХФ.
Поэтому предпочтительнее в Голос-е делать подобные вещи на стороне клиентов.

[asuleymanov]

Сделать несложно, последствия не очень хорошие.

Можно по подробнее что за последствия.

Логика на уровне БЧ должна быть как можно более универсальной, не стоит ее перегружать всевозможными вариантами под всевозможные модели поведения клиентов.
Любые подобные изменения приводят к необходимости выпускать ХФ. В случае Голос у ХФ есть жесткие сроки на запуск, в отличие от CyberWay где подобная тактика не требует выпусков ХФ.

А причем тут ХФ если это не изменение экономики то это СФ как я понимаю.

[afalaleev]

А причем тут ХФ если это не изменение экономики то это СФ как я понимаю.
Изменение операций, структур внутри операций, валидации структур - это все ХФ.

Чейн не может изменить твою транзакцию с включенной операцией - она подписана твоим ключом. Эта транзакция должна одинаково обрабатываться всеми нодами.
Если выпустить optional в пределах СФ, то ноды, понимающие optional, примут такую транзакцию и включат ее в блок, а ноды, не понимающие optional, блок не примут, и цепочка форкнется.

Сделать все параметры optional внутри chain_properties не проблема. Не проблема добавить проверки на требование указывать взаимосвязанные параметры.

Проблема в самой практике - невозможно удовлетворить потребности всех клиентов, нужен тот вариант логики, вокруг которой можно построить любую логику на уровне клиента.

В данном случае - это требовать предоставлять все параметры.
А на стороне клиента можно реализовать произвольную логику:

• получить текущие значения из цепочки -> заменить нужные значение -> отправить в чейн
• получить значения из конфигурационного файлы -> заменить нужные значения -> отправить в чейн
• так и многие другие ....

[asuleymanov]

Вообщето странный подход. Увеличивать нагрузку на ноду засчет не желания сделать такое изменени.

Почему же тогда в других БД не надо запрашивать полностью запись чтобы обновить одно из значений записи.

[afalaleev]

БЧ без проблем горизонтально масштабируется на чтение.
У него проблемы с масштабированием на запись.

[asuleymanov]

Тем более записать 10 байт или 200.