Да, новый алгоритм консенсуса придумать (а он новый - прямо такого не вижу) - это не поле перейти. Не работает, гад. Тупо клонировать 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 и еще миллион всего). А можно патчи слать имейлом или телегой. А можно бандлы.

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

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

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

К вопросу о ментальных моделях. Если слово не нравится, предложите как-то другое. Есть вот такая вещь, как syncthing. Хорошая штука, именно она вдохновила делать hbs2, потому, что в целом оно работает и у меня есть расшаренный на все девайсы набор данных (файлы, фотки), но (skipped), но сделать на ней то, что мне надо - нельзя, и модель у неё странная. То есть там есть сущность "устройство". Потом "устройство" "предлагает" "папку" (folder) c квази-уникальным id. Потом ты вручную прописываешь, в какой каталог на диске смотрит эта "папка", и если несколько "папок" смотрят в один каталог, syncthing с переменным успехом пытается мержить редактируемые одновременно каталоги. Даже с одним писателем (мной), это время от времени вызывает конфликты, как оно мержит — непонятно, т.е даже невозможно под него подстроиться. С git это не будет работать, если будет несколько писателей, хотя казалось бы, в git каждый объект уникален. Каждый, да не каждый, есть ссылки (которые просто файлы!) на объекты, и еще пачка неверсионируемого контента. Нельзя каталог с гитом безопасно синхронизировать файловыми операциями. Это правда, косяк скорее гита, можно было более нормально сделать (как у нас в hbs2 бгг. ведь это гит на с стероидах (CAS на самом деле) с разными протоколами репликации). Это я просто обновлял мобилу взамен сгнившей и пытался передать с неё файл приватных ключей на новую мобилу, не через телеграм и не будучи уверен, что файл зашифрован, это ж андроид, gui, в нем непонятно ничего, что происходит. Минут через двадцать плюнул и экспортировал с ноута, убедившись, что зашифровано.

Возвращаясь с syncthing — видно, что модель кривая и в ней много лишнего. Мы хотим: иметь общий (виртуальный) каталог на кучу устройств, данные должны быть гарантированно зашифрованы, и доступ на чтение-запись только ограниченному кругу лиц (ключей, на самом деле). Сущности - каталог, ключ, круг ключей. Устройство - не сущность. Какая мне разница, что устройство afd6fcc5-1f28-43e9-a767-0170dc5b597d XPEH-C-BYGRA предлагает мне папку XXX ? Что мне делать с этой информацией? Даже если мне ip скажут (таже моя мобила, но через мобильную сеть).

Если подразумевается одновременное редактирование — то должен быть какой-то ясный алгоритм мержа. Ну и так-то всё.

git имеет такую великую вещь, как remote protocol helper, то есть можно делать push/fetch куда угодно, хоть в гугл диск, хоть в чат в телеграме, хоть в эхоконференцию в FIDO, лишь бы транслировалось в его понятия, которых у него совсем немного - получить объекты да установить ссылки. ссылки не версионируются (хаха!) поэтому внешнее хранилище должно это делать само, т.е должен быть некий алгоритм для ссылок (у нас в hbs2-git это выбор самой длинной цепочки из множества операций установки ссылки, что иногда приводит к лулзам)

Пользоваться корпоративными продуктами, аналоги которых есть в естественном виде в природе, стыдновато потому, что товаром там является не их сервис, а вы. Т.е они берут ваши деньги, а продают вас. Т.е это стыдно вообще с любой стороны, даже проститутки в менее унизительном положении находятся. Ну а если их EULA запостить в Chat GPT и попросить сделать выжимку, то единственным смыслом там останется ПНАХ. Да, от этого невозможно избавиться совсем, но не значит, что нельзя к этому стремиться. Это не бинарное состояние, это измеримый KPI. Количество позора можно снижать год за годом.

В suckless-conf (конфиги на sexp) добавились FromJSON/ToJSON , теперь можно сериализовывать/десериализовывать объекты в sexp-ы и работать с этим конфигом традиционным унылым хаскельным путём. Пользуясь случаем хочу в очередной раз заявить, что sexp-ы сила, json-могила. В json - убогая семантика встроенных когда-то в ecmascript структур данных, а в sexp - вся мощь любых dsl.

hbs2://JAuk1UJzZfbDGKVazSQU5yYQ3NGfk4gVeZzBCduf5TgQ

https://github.com/voidlizard/suckless-conf

Сегодня будет коммит в hbs2-git, который в общем-то не ломает совместимость, но меняет способ вычисления значения ссылок (бранчей), и после него те, кто на новой версии и на старой версии могут видеть разное значение бранча. На текущей "стабильной" версии некорректно работали push —force и удаление бранча. На новой будут, но только для новых пушей, т.е если у вас удалённый бранч не хотел удаляться - то надо будет его удалить еще раз.

Другими словами, надо будет обновиться на master, хотя master ветка, вроде как, не стабильная сейчас. Я думал, что следующим большим релизом будет шифрование резиториев / приватные репозитории, но вот нет. Но зато у нас есть каналы с множеством писателей и возможностью их удалять/добавлять (refchan), и демо онлайн BFT консенсуса поверх hbs2, который, вроде как, работает.

Как работает hbs2-git раньше и сейчас. hbs2-git пишет в "reflog". "Reflog" это некая мутабельная ссылка, в которую может писать только владелец приватного ключа, который и определяет рефлог, т.е приватный ключ это он и есть. В рефлог пишутся "транзакции", каждая может быть чем угодно, порядок не гарантируется, кроме лексикографического, это append-only growing set. Что внутри транзакций знают только писатели-читатели. Например, там могут быть объекты git. Но не по одному: hbs2-git для каждого push формирует лог в виде файла, куда пишет все новые объекты. Формат лога имеет определенную структуру и последовательность в надежде, что он будет хотя бы частично повторно использован. В любом случае, в каждый журнал операции push пишутся только те объекты, которых еще нет в стейте, где стейт - это объединение всех предыдущих журналов. Помимо самих объектов git, с которыми git знает что делать и порядок их (коммитов) - это DAG и управляетс самим git, есть еще "ссылки", они же бранчи, они же теги. Ссылка в git это текстовый файл, в котором лежит хэш коммита. Таким образом, ссылка указывает на голову цепочки. Это буквально неверсионируемый текстовый файл и нам надо обеспечить консенсус относительно него, т.е ввести порядок операций модификации, что не так-то просто. Как нам определить порядок операций? Можно ввести отдельный CRDT счётчик, хоть там есть нюансы. Ну а можно взять естественный. Раньше это была максимальная глубина DAG git для этого журнала, но поскольку в git как угодно можно (и часто нужно) редактировать историю —- это так себе ориентир. Но вот поскольку журнал транзакций рефлога только растёт, можно в момент git push вычислять этот самый счётчик, который суть число транзакций в журнале. У нас один писатель. Если некто на разных хостах запушит операции с одинаковым rank - то возможна неоднозначность. Однако же, поскольку у нас он является единственным владельцем канала, то таким образом он будет византийствовать только в отношении себя самого. Ну и пожалуйста, ССЗБ.