У меня внутри этого распределенного редактора могут быть разные сценарии, которые требуют разных гарантий согласованности. И я несколько в растерянности как это решать.
Система построена на процессах, которые принимают сообщения, чтобы не было разницы, локальное это сообщение или оно пришло по сети (для совместного редактирования). При этом центрального сервера нет (p2p). Сообщения ходят по UDP и могут обгонять друг друга (но упорядочивать можно по номерам, думаю)
Если я ввожу куда-то текст (например в название узла графа), то я заинтересован, чтобы введенные позже буквы не обгоняли буквы, введенные раньше.
Одновременно с этим, другой пользователь может выполнять перетаскивание узла по графу - тоже путем посылки через сеть нескольких сообщений - и тогда я заинтереснован, чтобы сообщение DRAG_START пришло раньше (вернее, было бы обработано раньше), чем DRAG_DROP.
Эти две паралельные линии редактирования одного графа могут не зависеть друг от друга, а могут и зависеть, в случае, если я ввожу с клавиатуры команду, которая ссылается именно на тот элемент, который перетаскивает другой пользователь: если я своей командой хочу поменять имя элемента, который перетаскивается кем-то другим, то зависимость есть.
Допустим у нас есть существует механизм разрешения таких зависимостей - например, откаты и слияния. Важно чтобы у остальных пользователей в распределенный системе в конечном итоге состояние совпало, вне зависимости от того в каком порядке приходили сообщения. Но как это сделать, если я заранее не могу в каждом сценарии прописать где есть зависимости, а где нет?
Как вообще решать такой класс проблем?
https://en.wikipedia.org/wiki/Interaction_nets#Interaction_calculus
Я про них давно слышал, но как-то ленился разобраться. Но тут по работе попалась ссылка на язык vine, который через interaction nets компилируется, я полез общаться с deepseek, выяснил что еще Curry (в котром логическое программирование поддерживается) через них же реализован. Но как эти сети взаимодействий работают я так и не смог понять.
https://vine.dev/docs/features/inverse
https://se.math.spbu.ru/thesis/slides/Ponomarev_Nikolaj_Alekseevich_Bachelor_Thesis_2025_slides.pdf
И там https://github.com/Lamagraph/interaction-nets-in-fpga
Про Curry (KiCS2) подтверждений не нашел, но deepseek убедительно рассказывает. https://www.curry-lang.org/kics2/
Еще такое https://github.com/HigherOrderCO/HVM2
Еще сейчас попалось https://github.com/etiamz/interaction-net-resources
И там https://github.com/xieyuheng/inet-forth
… у этого должно быть большое будущее, в том числе в символьном ИИ, где узкое место - отсутствие параллельных архитектур, ориентированные на символьные вычисления и логический вывод, хотя казалось бы, там все хорошо параллелится. Было бы интересно реализовать на них LIFE, очень интересный, но почти забытый язык.
Можно еще и Metta. А если туда еще pi-исчисление влезет, то и язык rho.
Я думал сделать блокчейн с распределенным выполнением внутри этого графа - своего рода общую память
А ты rho н есмотрел? Они как-то pi-исчисление (или join-исчисление) в блокчейн как-то запихнули. Как и зачем я не разобрался. По мне rho для автоматизации и игр должен хорошо подойти, но вытащить его из блокчейна легко у меня не получилось.
Ещё не смотрел, но думаю у них там это просто язык смартов. Я ошибаюсь?
Не знаю. Но просто для смартов pi-исчисление странно использовать. Как я понял, нам какая-то философия в этом есть. И возможностью параллельно обрабатывать несколько транзакций они вроде хвастались.
Забавно, что люди из rho задружились с людми из SingularityNet (которые OpenCog/Hyperon/Metta делают) и разрабатывают распределенный ИИ. Гиблидный. Но да, OpenCog скорее про символьный.
…идея прикрутить блокчейн к Inеeraction nets мне нравится все больше. За счет детерминированности и линейной логики они там хорошо подойдут. Нужны агенты монеты и операции с монетами (объединение двух монет в одну и разделение монеты на две). Свободные порты текущего графа защищаются электронной подписью, транзакция выглядит как присоединение своего подграфа к портам, для которых знаешь ключ, и последующие редукции. Нужно придумать, как ограничить количество редукций, вызванных отдельной транзакцией. Либо придумать как проверять терминируемость, либо придумать, как из монет получать что-то типа газа.
Редукции можно газом ограничить, или сделать констрейнт чтобы редукция себя окупала
Механизм, как монеты превращать в газ и передавать майнеру будет нетривиальный. Или выйдет на рамни парадигмы interaction nets.
Да, еще нужно придумать детерминированный алгоритм сериализации графа, чтобы хеши считать. Тоже не очень просто.