Взгляд на VIZ #2: что дальше?

Я уже поднимал тему необратимости блоков https://control.viz.world/media/@on1x/irreversible-principle/
С приходом Tendermint (у которого довольно много общего с https://xrpl.org/intro-to-consensus.html консенсусом) необратимость состояния (стэйта сети) претендует на довольно важную роль в развитии блокчейн-систем вообще.

Голосование и согласие с другими, отсчет высоты леджера (как же я не люблю ужасное слово «гроссбух», думаю, русскому языку нужно просто позаимствовать именно слово леджер), гибкая точка отсчета — очень важные и необходимые для эволюции элементы.

Необратимый блок — сугубо индивидуальный параметр для каждой ноды. Речь про доверие консенсусу и ответственным участникам. Как я себе представляю изменение необратимости блоков. Добавить в p2p протокол сообщения вида «подтверждаю валидность блока N» с подписью делегата. Система смотрит такие сообщения и если приходит 75% подтверждений от делегатов в текущем блоке, то она двигает необратимость вперед.

То-есть понятно, что переход на tendermint ломает итерационность в блоках и время их согласования. Тогда всю внутреннюю экономику надо строить не на высоте блоков, а на времени, которое прошло между каждой высотой. Это возможно, но фактически нереально перестроить работающий консенсус с одного на другой. Такое возможно только в отдельном форке или с новой разработкой вовсе, что нам, понятное дело не подходит.

А если согласовать движение вперед в данном консенсусе невозможно, то стоит рассмотреть движение вперед необратимого блока на том же принципе — согласование топ делегатов/заверителей через p2p сообщения. Такое решение не отменяет прошлого, оно может дополнить его для более быстрого движения необратимого блока вперед. Предположу, что даже ОЧЕНЬ СИЛЬНО ускорить.

Обсудили в чате. Речь про то, что на согласование блока уходит достаточно времени, судя по https://www.mintscan.io/blocks
Согласованный блок сразу становится необратимым (irreversible), что позволяет доверять состоянию системы сразу же. Но если в теории использовать плавающее время согласования от 6 до 9 секунд, то нужно переписывать экономику, которая в dpos строится на элементах вида «количество блоков за год». Понятно, что в EOS приложения почти всегда игнорируют irreversible, но мне кажется, что если в p2p протокол добавить сообщение от делегатов с доверием блоку, то это позволит не тратить время на согласование, а использовать смешанный алгоритм — движение irreversible с круговым подтверждением как сейчас, плюс возможность ускорить движение необратимой высоты за счет подтверждения доверия блоку в p2p протоколе.

Хранение всей цепочки блоков. В этом нет никакого смысла. Хранить всю цепочку «должен» тот, кому это «необходимо». Нельзя заставлять и ожидать того, что всю цепочку будет хранить каждая нода (участник сети). Софт так и так обращается к определенному количеству p2p нод, чтобы было с чего начинать и синхронизировать состояние (стэйт) системы. Предположу, что точка отсчета должна быть с необратимого блока. Логично переписать ядро так, чтобы она по p2p запрашивала актуальное состояние и обрабатывала новые блоки начиная с полученного состояния. Также надо сделать опцию, для постепенного скачивания «истории» системы, чтобы те, кому это «необходимо», могли получить эти данные от нод, которые захотели хранить всю историю блоков.

Что нужно для формирования сырой (raw) транзакции?

Знать формат транзакции;
Знать формат операции;
Знать преобразование типов данных;;
Знать о TaPoS (читаем тут https://steemit.com/bitshares/@testz/bitshares-history-transactions-as-proof-of-stake-tapos и тут https://golos.io/ru--blokcheijn/@rusteemitblog/algoritm-konsensusa-delegirovannogo-dokazatelstva-dolei-dpos-nedostayushaya-belaya-bumaga-perevod-stati-dantheman#tranzakczii-kak-dokazatelxstvo-doleij-transactions-as-proof-of-stake-tapos и смотрим код, поиск по block_is_on_preferred_chain, get_block_id_for_num) и дополнить транзакцию слепком текущей цепи (своего рода checksum для номера неподтвержденного блока и его хэша), в которой вы желаете работать.

Вот последнее затруднительно делать — обязательно надо опираться на текущее состояние сети. Нельзя подписать транзакцию на оффлайн устройстве и потом транслировать в сеть, так как требуется обязательно checksum блока из текущей сети. Понятно, что можно заморочиться и переносить данные, необходимые для TaPoS checksum на оффлайн устройство, но это создает дополнительную этапность.

В посте vik https://golos.io/ru--golos/@vik/ref-block-prefix показывает, что golos-js и steem-js выбирают разные блоки для работы TaPoS — в первом случае это блок из неподтвержденной необратимостью цепи (текущая высота минус 3 блока), во втором это блок из подтвержденной необратимости цепи (необратимая высота минус 1 блок).
В первом случае транзакция опирается на текущее неподтвержденное состояние сети. Если оно в мини-форке, то мы получим, что транзакция в основной сети будет невалидна.
Во втором случае транзакция опирается на подтвержденное состояние сети и транзакция будет валидна даже в случае конфликтов мини-форков. Таким образом не надо беспокоиться, что вы, возможно, произвели броадкаст в невалидный форк цепи, так как соседние ноды все равно ее примут.
Оба подхода довольно интересные и можно обсуждать. Первый позволяет фактически «оказывать доверие» той цепочке, которую вы наблюдаете и по которой принимаете решение. Но вам нужно убедиться, что ваше решение попало в необратимое состояние.
Второй подход позволяет быть уверенным, что транзакция не будет отброшена, но и принятие решение о транзакции должно быть уже на вашем доверии состоянию сети.

Довольно сложно для понимания, попробую описать с примером.
Вы смотрите за отдельной нодой, как посредником блокчейн-сети. Пользователь А перевел вам токены и тут же сообщил об этом. Вы проверяете состояние сети на этой ноде и видите перевод. Соответственно вы можете принять решение по вашей сделке и переводите другие токены в этой же сети пользователю А (обмен разными токенами). Если вы сформируете свою транзакцию опираясь на TaPoS checksum с необратимым блоком (куда еще не попала транзакция с переводом токенов от пользователя А вам), то в случае микро-форка на наблюдаемой ноде, может случиться ситуация, когда транзакция от пользователя А к вам будет отброшена цепочкой длинее, а ваша транзакция будет принята, так как вы опирались на необратимый блок.
Правильное решение тут:

1. Либо дождаться когда транзакция с переводом токенов от пользователя А к вам попадет в необратимый блок.
2. Либо опираться на TaPoS checksum с обратимым блоком (>= номер блока транзакции из пункта 1).

То-есть вопрос TaPoS checksum довольно интересный, но мало где обсуждался. Если ваша транзакция зависит от других транзакций, то опираться надо на номер блока больше или равно номеру блоку с этими транзакциями.
Если ваша транзакция не зависит от других транзакций, вы хотите быть уверенным, что она попадет в основную цепь, то надо опираться на номер блока меньший или равный номеру необратимому блоку.

Итак, возвращаясь к подписи сырого блока. Чтобы подписать сырой блок нам надо получить данные: текущий статус сети, рассчитать первую часть TaPoS (по номеру блока на который мы хотим опираться), получить его id-has (который надо запросить путем обращения к ноде с запросом следующего блока (в нем пишется id-hash предыдущего)).
Итого нужно сделать 2 обращения к ноде. И это для формирования каждой транзакции, каждым участником сети. Отсюда возникает идея — дополнить ответ по запросу статуса сети сразу двумя TaPoS принципами: irreversible_tapos_block_id и irreversible_tapos_block_prefix, tapos_block_id и tapos_block_prefix. Это позволит сократить запросы к ноде для расчета TaPoS checksum.

Их можно было бы заполнить в database.cpp при исполнении update_global_dynamic_data

Что можно было бы сделать в хардфорке, когда найдутся желающие:
— отключить операции связанные с восстановлением доступа к аккаунту (они совершенно оторваны от реальности, при наличии мультисига разумнее иметь от 2 персон, которые могли бы подписать транзакцию, требующую master доступ);
— если не отключать восстановление доступа, то продажа аккаунта должна перед исполнением проверять наличие такого запроса на восстановление аккаунта и не позволять осуществлять продажу;
— новую операцию set_auto_withdraw_border для включения автоматического понижения до определенного порога (поля в аккаунт и автоматическое включение понижения, если условия подходят, при осуществлении понижении пролонгировать его если не достигнуты условия, добавить проверку аккаунтов с авто-понижением раз в N блоков, 1 сутки будет достаточно);
— новую операцию split_bandwidth_for_subaccounts которая будет делить пропускную способность аккаунта и делегировать ее подаккаунтам. Нужно добавить поле с счетчиком подаккаунтов и правильно его расчитывать при регистрации новых (или продаже). После чего добавить метку, есть ли родительский аккаунт. И при проверке транзакции на необходимую пропускную способность добавлять к текущей пропускной способности аккаунта родительский вес деленный на количество подаккаунтов. Это не усложняет подсчеты, но позволяет установить резервы токенов приложения для своих внутренних пользователей.