Когда-то мы делали проект gps мониторинга школьных автобусов. Эпичная история, но не суть. Там каталось около 300 автобусов, с каждым был GLONASS трекер и с каждым - какая-то своя история + охота за ними по тамбовской области, которая больше многих стран. С тех пор мне кажется, что меня преследуют машины из региона 68, а так же многие числа кажутся знакомыми - ведь это номер какого-то автобуса, с которым была какая-то история. 608, 219, вот это всё. К чему это я. Мне теперь кажется, что каждый хэш Blake256 в кодировке Base58 я уже где-то видел.

юникс-сокеты, кстати, оказались отличной штукой. думал внешние приложения как цеплять - по TCP, по HTTPS/вебсокетам. Но вот юникс-сокеты оказалось сделать просто, быстро и без засорения пространства номеров портов, прям доволен

Каждый раз, когда изобретаешь что-то, чувствуешь себя неловко. Вроде бы в области ничего нового быть не может, потому, что люди из академии уже двадцать четыре года мусолят PBFT, а если считать PBFT "лампортом", как это делают на некоторых факультетах, то это вообще 1982-ой год. 1982 (!! ). Вроде бы и понятно, как работает академия в целом: взяли базу (PBFT), добавили что-то вполне очевидное, дальше проводим ИСЛЕДОВАНИЯ, делаем ПУБЛИКАЦИИ, потом рождаем супер-дупер алгоритм, который на 8% эффективнее в определенных обстоятельствах, потом учёный насилует журналиста, а авторы 8% улучшения превышают скорость света и отгребают миллионов 30 на свой стартап на волне общего безумия. В принципе, я внутри такой волны побывал два раза. Проблема в том, что надо быть не внутри волны, а на ней сёрфить, что бы было совсем хорошо - лучше бы её поднять (вспомним Nicira и их софтсвич). Так вот, по идее с этими алгоритмами как - если общий принцип понял, то вроде бы можно разобрать и собрать, с нужными параметрами (отсутствие лидеров и тп). Понятно, что потом надо бы исследовать, позвать математика и что-то там доказать. Понятно, что доказательство само по себе ничего не доказывает еще — как оно может содержать ошибки, так и реализация. Все это утрясается за годы использования в режиме неуловимого Джо. Посмотрим вот на IOTA. Первое, что мы находим про IOTA — "алгоритм часто критикуют за то, что хрен знает, он вообще работает или нет" и второе "в настоящий момент, что бы вся эта хрень на графах точно работала, есть специальный узел-координатор, который фиксирует стейт время от времени" —- ну вон оно чо! Но так-то каждый может. Я это к чему? Вот понадобилось мне алгоритм без лидера запилить, который будет сходиться и делать то, что надо (распределенно объединять множества без лидера) - и вроде бы он есть. Вроде бы сходится. Вроде бы похож на все PBFT-подобные. Вроде бы все нормально, не хуже, чем у других. А всё равно — неловко как-то. Был бы готовый, взял бы готовый. Но прям готовых-готовых я не вижу, а вот IOTA брать и тупо запиливать - стрёмно, потому, что делать, не понимая что, и никто не понимает что - ну такое себе.

Есть такой негативный паттерн - когда только свежеизобретенная НЁХ является ключевой фичей для продакшена.
Регулярно, раз в несколько лет в него попадаю, что делать, что бы такого не было - в принципе не совсем понятно.
Причины каждый раз примерно такие - "нет такого, что бы взял из коробки и воткнул, куда надо и заработало" или
"вроде бы это должно быть несложно" или их суперпозиция. Так-то в норме, этим занимаются где-нибудь в R&D или универах,
пишут много пейперов и прототипов, и потом, когда этого всего накопилось достаточно, можно пытаться тащить это в прод.
С одной стороны. С другой стороны — ну если нет реально готового, что что? Отказываться?

Что делать, что бы этого не возникало — непонятно, в целом, делать, знаешь что - каждый может. А ты вот попробуй сделать
неизвестно что. Думаю, что если назвался HEXResearch, то нужно просто смириться с этой ситуацией. Что иногда будет дольше,
чем планировалось, а иногда может и вовсе не получиться, хорошо бы, правда, иметь план Б на этот случай.

В целом, отладка распределенных алгоритмов с одной стороны ад, с другой стороны - консоль, куда можно печатать
буквы даёт практически бесконечные возможности для отладки, по сравнению с отладочным светодиодом, например.

Помните, до всего этого блокчейна - PAXOS и RAFT казались сложными?

Да, новый алгоритм консенсуса придумать (а он новый - прямо такого не вижу) - это не поле перейти. Не работает, гад. Тупо клонировать PBFT-like не хочется, и хочется, что бы был без лидера. И вроде бы должен работать. Но пока нет. Из готовых без лидера нашёл HoneyBadgerBFT, и это что-то такая лютая наркомания, что тащить такое к себе я не готов. IOTA и Avalanche - аналогично. IOTA понятная, но сомнительная, аваланч - непонятный и сомнительный. Распределенные алгоритмы с лидерами - какие-то и не распределенные особо, на мой взгляд

Не знаю где еще спросить - надо бы построить модель распределенного алгоритма на каком-нибудь из фреймворков. Алгоритм вроде бы простой, но я инструментарием для подобного плана моделирования вообще не владею, и не представляю, сколько это (построение модели) займет времени. Есть ли где-то тусовки по этим инструментам (spin, tla+) или есть кто-то, кто готов приватно пообщаться на эту тему, что бы тут эфир не засорять?

курс лекций Лампорта (тот самый Лампорт!) по tla+ https://lamport.azurewebsites.net/video/videos.html

Вообще не собирался в это лезть, если честно, но как всегда — стало надо. Есть ли, интересно, какой-то КМБ по формальной верификации и модел-чекингу (как оно по русски-то хоть)?

консенсус qblf делает вид, что работает на нескольких хостах. какой-то тут должен быть подвох, конечно. отлаживать это всё дико. две реплики расходятся, надо минимум три и желательно с сетью - т.к. что бы блоки подъезжали с задержкой

Внимательный читатель конечно спросит, на кой чёрт тут в hbs2 понадобился вообще консенсус. Суть такова, что есть еще те проекты, за которые деньги платят, и там нужен какой-то "блокчейн", я извиняюсь. У нас был один, но там легче застрелиться, чем на нём делать это вот всё. Честно говоря думалось, что имея в hbs2-peer gossip + pex + библиотеку для реализации протоколов + merkle деревья + подписи + распространение блоков, как-то можно намутить "блокчейн" малой кровью, ну там, CRDT какое-нибудь с подписями, типа такого. Но нет, просто это не решается. Впиливать какой-то прямо tendermint поверх этого всего... Ну такое. Была идея, что можно такие вещи делать внешними процессами, если от hbs2-peer провесить какие-то удобные ручки, и в общем-то, такие ручки нашлись - это unix socket-ы, на них исключительно удобно делать двухстороннюю коммуникацию, без всяких заморочек, как с вебсокетами бы было. Т.е в hbs2-peer решает вопрос организации сети, а FSM крутится во внешнем процессе. Ну и вроде как оно работает. Была еще идея, что множества идемпотентных транзакций можно как-то проще приводить к общему знаменателю, чем вот это вот всё prevote/vote/precommit/commit c лидером, и, вроде, так оно и есть. Еще в библиотеку Raft запиливаем на всякий случай, пусть будет.

Что даёт консенсус в отличие от CRDT: нам не надо вообще заморачиваться структурой, пиры за несколько раундов договорятся и согласуют любые данные, т.е например, блоб репозитория гита. мы можем не париться порядком транзакций в нём, а можем тупо дописывать новые объекты в конец, и новый стейт будет хэшом нового получившегося файла, который будет эффективно расходиться по hbs2 меркл-деревьями (будут докачиваться только отсутствующие блоки). Минус в том, что какое-то количество пиров должно быть всегда онлайн. Причем, пока что это совершенно конкретное количество - типа 2/3 от всех пиров, указанных в настройках канала. Для рефлогов/рефчанов такое необязательно, пира загасил, хоть всех, поднял, они засинкаются. Вот и думай теперь, как с этим быть

Что он еще даёт: стресс-тесты для всего hbs2. Напрягает сеть очень сильно и это воспроизводимая нагрузка, более того, можно иметь определенные начальное и конечное состояние, что даёт возможность сделать повторяемые тесты. Ну, пусть будет. (UPD: и походу, он работает)

В QBLF опять сталкиваемся с некоей проблемой, которая
устойчиво повторяется и в других протоколах: большое
количество маленьких объектов, которая отчасти проистекает
из желания видеть каждый маленький объект, всё ж таки,
объектом, адресуемым по его хэшу, и наличием некоего
состояния, как списка ссылок на эти объекты.

Таким образом, у нас есть как сами объекты, так и
хэш-ссылки на них, и множества хэш-ссылок.

Больше объектов - больше блоков - больше раундтрипов, т.к.
у нас преимущественно pull-модель, т.е каждый узел сам
пытается получить, что ему нужно, спрашивая у всех.
Единица запроса --- как раз блок (который еще бьётся на
чанки, т.е *неадресуемые глобально* части, имеющие смысл
только в контексте сессии передачи блока. Смысл чанков ---
помещаться в UDP пакет, т.к системы для работы нужен
минимум UDP).

Практически это означает, что на 100 TPS QBLF начинает
как-то грустнеть, и на текущий момент основной проблемой
видится именно передача состояния --- она прямо заметно
вносит задержки.

C количеством раундтрипов падает скорость, т.к.
критичными становятся задержки.

В hbs2-git вопрос решился переходом от объектов к журналам
объектов, каждый журнал - по сути объекты, создаваемые
каждым push -- то есть все объекты, доступные из git
commit, отсутствующие в текущем состоянии ссылки, куда мы
этот push делаем.

Можно ли сделать так же в QBLF, т.е состоянием сделать не

 State = [HashRef]

HashRef -> Transaction 

а, например:

 State = [Transaction] 

т.е стейтом являются сами транзакции, а не их хэши.

Можно, но: если транзакция не несёт свой хэш, то придется
его вычислять (каждый раз).

Ок, решается изменением типа

 State = [Wrapped HashRef Transaction] 

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


Есть еще вариант --- ввести специальный протокол и
структуру данных для передачи большого числа маленьких
объектов, ключом сделать, например, [HashRef] - т.е список
хэшей, а значением - список объектов в порядке хэшей в
ключе. Еще точнее, ключом будет не [HashRef], а хэш
соответствующего ему merkle tree.

Тогда тот, кто раздаёт --- сам заботится о создании ключа,
и создании журнала.

Тот, кто получает --- может поинтересоваться, а нет ли для
этого запроса ([HashRef]) --- журнала объектов, и если да
-- то выкачать его.

Что плохо: ну, сами журналы прежде всего. Они лежат в том
же хранилище и засоряют его, дублируя инфомацию.

Это с одной стороны. С другой стороны, они могут быть
чем-то типа LRU кэша списка объектов, которые по какой-то
причине всем требуются вместе, т.е при падении
популярности ключа --- можно со временем удалять и сам
журнал.

Можно ли избежать дублирования? Теоретически --- да, видно
несколько путей. Практически, все они выглядят сложными, и
по сравнению с использованием плоского файла неизбежно
замедлят чтение и передачу.

Никогда всёрьез не задумывался про пресловутый KYC, относился к нему, как к некоей докуке. Но если подумать, то главной вещью, отвечающей за KYC как оно сделано у большинства является сложность подмены фото/видео с камеры мобильного. Ну то есть натурально, тебе не дают загрузить фотку, а вынуждают фоткать из самого приложения. Естественно, это выглядит достаточно смехотворно и должно быть наказано. Конечно, по мыльной фотке определить аутентичность, например, российских (да и любых) водительских прав, которые даже реальные выглядят как мутно напечатанный фейк на дешевой картонке — малореально. Доступа к базам никакого нет, особенно сейчас. Это даже не театр безопасности, это утренник в детском саду безопасности. Если что, я вообще KYC считаю порочной практикой, которая только осложняет жизнь нормальным людям. Надо будет с этим разобраться, но потом.

Возвращаясь к передаче стейта в QBLF и вообще. Протокол передачи журналов объектов по хэшу журнала ссылок смущает меня тем, что в p2p сети можно легко генерить и заставлять скачивать мусор, просто генерируя рандомные хэши в ответ на запрос. Должно быть легко проверить и сложно сгенерировать, а тут получается наоборот. Заставлять генерирующего хэш включать туда какие-то элементы PoW - выглядит довольно-таки бредово: становится сложно/сложно. Решений, видимо, два: 1) список доверенных пиров, мы считаем, что они не будут генерить мусор 2) опять же, онлайн-консенсус: по запросу собираем все ответы, выбираем популярный, проверяем все, наказываем вредителей. Минус в том, что это всё сложно и много движущихся частей. Торренты вон тоже потенциально подвержены замусориванию, но на практике этого не происходит в значительных масштабах, т.к. нет экономической мотивации

Меня несклолько пугает, что я не понимаю ментальную модель гита тех, кто не понимает гит. А значительная часть его не понимает, а как тогда они
функционируют. У них ментальная модель - чего? svn ? Кто в наши дни видел svn, даже деды не помнят. А как тогда. Это вообще не праздный вопрос, когда делаешь "распределенный git".

Что-то бы с hbs2-git балансируем ровно в однгом в шаге от MVP и никак его не сделаем. То тюлень позвонит, то олень. То риалтайм консенсус прикручиваем, то Raft, то теперь программу лояльности на этом хотят запускать мульти-конторную (чисто потому, что можем, других причин нет)

Шаг называется "приватные репозитории"

собственно, структура репо сейчас:

State = [HashRef] 

HashRef -> Merkle (GitRepoLog)

таким образом. что бы перейти к приватным репо, надо

1. протестировать, что история с групповым ключом работает - мы это делали когда-то, надо опять убедиться. прямо сделать ключ, добавить туда всех участников, сделать с ним зашифрованное merkle дерево, раздать участникам и убедиться, что работает.

это само про себе круто, иметь такой примитив, групповое end-to-end шифрование.

2. определить политику работы с ключами в репо. поскольку один репо = одна ссылка, и у репо только один писатель, то, кажется, дело обстоит так:

1. создать групповой ключ
2. добавить настройку в настройки репо - шифровать данным групповым ключом
3. при создании merkle tree - шифровать
4. при import - при чтении - расшифровывать

отягчающие: hbs2-git работает через http api hbs2-peer, постя туда / читая оттуда кусками, каждый кусок = блок, т.е надо или написать ФВП, которая будет расшифровывать, или вручную каждый блок расшифровывать, равно как и шифровать. но это же, блин, несложно.

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

Учитывая, что некоторые вещи в git и придумали, во всяком случае, до него они не были широко известны, т.е понятия такого до git не было.

Конечно же, модель есть. Просто у одних это интуиция, выработанная пробами и ошибками, после обрывочных рассказов тех, кто читал про git flow, а у других это статья (вроде Торвальдса, но не уверен) + выступление Торвальдса, где он разносит svn и рассказывает про git. В принципе этого достаточно, что бы понимать, что ты делаешь, когда что-то делаешь в гите. В первом случае же просто зажмуриваешься и давишь на кнопки.

Но git это прост пачка утилит для работы с базой в специфическом формате, например, можно работать, как описано в git flow, а можно, как в gerrit, и кстати, в gerrit есть резонные причины делать именно так ( repeat (commit —amend) && push) , но можно и сяк ( merge —squash —no-commit && push ) и у того или иного способа есть свои последствия. Не говоря о же о том, что там есть еще и что до git не было известно (cherry-pick, read-tree и еще миллион всего). А можно патчи слать имейлом или телегой. А можно бандлы.

В гите многое сделано концептуально криво, из-за того, что на старте не шарили (бранчи, ссылки).

Мутабельные ссылки в распределенном окружении без механизмов согласования (их можно было бы хотя бы версионировать!)

Что я хочу сказать? Вот ты делаешь что-то гитом (это ответ на вопрос "как". гитом), а откуда ты знаешь, чего ты хочешь добиться и что это делается именно так? Первый вопрос совершенно точно из ментальной модели "распределенный контроль версий и что нам от него надо".