Virtburg 2.0 - идём к децентрализации

[Shaos]

Про децентрализацию через концепцию Realms я размышлял ещё в 2020 году: viewtopic.php?f=81&t=20142
viewtopic.php?p=156797#p156797
viewtopic.php?p=156807#p156807
В данный момент я пока не хочу притягивать за уши блокчейн и цифровые подписи, поэтому попробую поразмышлять как обойдясь только хешами начать уходить в децентрализацию для экономии траффика...

[Shaos]

Центральный сервер пока останется как координатор реальности нашего реалма Virtburg - он будет периодически выкладывать списки хешей файлов на сколько то дней вперёд (чтобы у тестеров была возможность потестить завтрашнюю реальность например) и т.к. эти списки приходят с известного доменного имени (можно даже https:// организовать для пущей секьюрности), то можно считать, что они заведомо корректные (типа замена цифровой подписи).

Хеши могут быть те же самые RIPEMD-160 (самый маленький криптографический хеш, который ещё не сломан):

https://homes.esat.kuleuven.be/~bosselae/ripemd160.html

Файл манифеста может например называться virtburg_realm-main_reality-2024_12_05.txt в котором могут быть 2 колонки - хеш урла и хеш самого файла (вместо которого может стоять буква x, которая будет означать запрещённый либо более недействительный урл):

Code: Select all

ad32df90903aba23c0129891caa98982aacb12c7 3aba23c0129891caa9898ad32df9009203ad32d2
3e40bc72ce1e4e1d85e89dd5a7d183c3d854c382 3aba23c0129891caa9898ad32df9009203ad32d2
09203ad32df9090ab093982aacb12c7903aba232 x

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

Хеш файла может не только использоваться для проверки целостности файла, но и для его идентификации - например в качестве имени файла при сохранении в локальном кеше или когда файл будет запрашиваться у других нодов. Например программе игры надо скачать файл http://virtburg.com/50_50/main.3d - по этому урлу считаем RIPEMD-160 (3e40bc72ce1e4e1d85e89dd5a7d183c3d854c382) и ищем его в манифесте - если не нашли, то программа пишет сообщение, что в данной реальности этот файл отсутствует (если это скажем спрайт, то он просто игнорируется), а если нашли - запоминаем хэш из второй колонки и смотрим у себя в кеше, если там такого хэша нету, то спрашиваем у соседних нодов, если там тоже нету, то идём на главный сервер используя этот самый урл и выкачав данный файл сверяем хэш, если сходится, то сохраняем в локальный кэш и идём дальше (а если не сходится, то пробуем ещё раз и если всё ещё не сходится - рапортуем ошибку).

Чат пока можно оставить централизованным, однако я наверное знаю как его тоже децентрализовать (без 100% гарантии аутентичности переписки) - в старом Виртбурге клиенты всегда забирали непрочитанную порцию чата, делая запрос с последним ID какое у них есть (каждая строчка чата нумеруется по порядку). Если же у нас несколько копий чата, которые могут разбежаться и которые надо синхронизировать, то инкрементируемый идентификатор не подойдёт (т.к. нет центрального сервера с базой данных) - поэтому мы начинаем идентифицировать сообщения в чате парой unixtime (количество секунд прошедших с 1 января 1970 года) и имени пользователя, который оставляет данное сообщение (предполагается, что один и тот же пользователь не может писать чаще 1 сообщения в секунду). Ноды постоянно сверяют списки последних сообщений отсортированных по времени, и выявляют дырки в своей истории, заполняя их. Но без цифровой подписи нет гарантии, что сообщение от как бы пользователя Shaos действительно написал Shaos - наверное для простого болтания с этим можно жить, а вот всякие банковские дела, покупки/продажи и т.д. должны будут осуществляться на главном сервере (до тех пока мы не дорастём до использования цифровой подписи).

[Shaos]

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

Ecли сразу поддержать цифровую подпись Ed25519, то логичнее в качестве крипографического хэша использовать SHA512, которая уже включена в Ed25519 - в таком случае хэш урла http://virtburg.com/50_50/main.3d будет выглядеть несколько длиннее:

a16506e6a6e1893eac57bb7d7829d903a8d981073b3bf1b979b3a0064072dc09b612a0a48275050006c309a7896dfd254db99024a59b4ed47c5b2fb739ac8661

Спешу заметить, что цифровая подпись Ed25519 будет иметь такую же длину, как собственно и полный ключ Ed25519 (а публичный ключ будет в 2 раза короче).

[Shaos]

Не - всё таки надо без цифровой подписи пока. А валидацию сообщений чата можно делать пост-фактум на главном сервере через алгоритм HMAC-RIPEMD-160-96, который построен на основе того же самого хеша RIPEMD-160 и использует один и тот же ключ для подписи и проверки длиной до 20 символов - пользователь может иметь этот ключ у себя в клиенте и на главном сервере, а простые ноды этого ключа иметь не будут и валидацию проводить не смогут, т.е. им придётся верить наслово если кто-то говорит что он Shaos и находится в секторе Center в координатах 15,15 до следующего сеанса связи с главным сервером, когда тот сможет провалидировать все сообщения чата (включая рапорты текущих координат игроков). Стандарты, описывающие HMAC-RIPEMD-160-96:

RFC2104 (February 1997) - HMAC: Keyed-Hashing for Message Authentication
https://datatracker.ietf.org/doc/html/rfc2104

RFC2286 (February 1998) - Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
https://datatracker.ietf.org/doc/html/rfc2286

RFC2857 (June 2000) - The Use of HMAC-RIPEMD-160-96 within ESP and AH
https://datatracker.ietf.org/doc/html/rfc2857

Файл манифеста может например называться virtburg_realm-main_reality-2024_12_05.txt в котором могут быть 2 колонки - хеш урла и хеш самого файла (вместо которого может стоять буква x, которая будет означать запрещённый либо более недействительный урл):

Code: Select all

ad32df90903aba23c0129891caa98982aacb12c7 3aba23c0129891caa9898ad32df9009203ad32d2
3e40bc72ce1e4e1d85e89dd5a7d183c3d854c382 3aba23c0129891caa9898ad32df9009203ad32d2
09203ad32df9090ab093982aacb12c7903aba232 x

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

Наверное для имён файлов в кеше надо использовать не 16-ричное написание, а BASE32 - при этом длина имени будет уже не 40 символов, а только 32. А сам файл манифеста скорее всего должен быть вообще бинарным (т.е. virtburg_realm-main_reality-2024_12_05.bin) в котором будут идти 20 байт хеш урла затем 20 байт хеш самого файла, 20 байт хеш следующего урла затем 20 байт следующего файла и т.д. (в бинарном виде символ x можно заменить нулевым хешем, вероятность случайного получения которого на произвольных данных равна примерно 6.8e-49). И как я уже писал, валидность манифеста реальности будет проверяться тем фактом, что он скачивается с главного сайта реалма по HTTPS, например:

https://virtburg.com/virtburg_realm-main_reality-2024_12_05.bin

Для генерации таких файлов мне надо написать "компилятор реальности" (Realm Reality Compiler = RRC), который из списка урлов и имён файлов, ставящихся в соответствие этим урлам, будет генерировать бинарное представление их хешей...

P.S. Кстати так можно подменять файлы реалма в текущей реальности - просто ставим в соответствие урлу хеш файла на который подменяем и кладём этот файл в cache сервера - тогда клиент сначала торкнется по прямому урлу, но т.к. файл там не совпадёт по хешу, то клиент может обратиться в кеш сервера используя хеш в BASE32 в качестве имени и получить этот файл там!

[Shaos]

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

Чего-то подумалось, что если HMAC-RIPEMD-160-96 может использоваться для верификации записей в чате, то он также может использоваться и для верификации файла реальности! Правда делать это надо ключом каждого пользователя (которые главный сервер знает) и рядом с файлом реальности virtburg_realm-main_reality-2024_12_05.bin надо будет формировать файл подписей virtburg_realm-main_reality-2024_12_05.sig, где будут перечислены ВСЕ пользователи реалма и для каждого будет подсчитана подпись HMAC-RIPEMD-160-96 - в итоге можно HTTPS даже и не использовать!

Также наверное наряду с реальностями каждого дня должна быть реальность "по умолчанию" для обычных дней или для того времени, когда главный сервер вдруг исчезнет (например если хозяин забудет продлить регистрацию) - оно может лежать в файле virtburg_realm-main_reality-default.bin и быть заранее распространённым по другим узлам... Хотя наверное так можно будет легко запутаться... т.е. чтобы всё было железобетонно надо таки генерировать файл реальности каждый день, однако просто копировать вчерашний день в сегодняшний если ничего не изменилось не пойдёт т.к. мы не будем знать то ли главный сервер его скопировал, то ли какая-то нода поменяла имя файла, а т.к. контент остался неизменным все старые подписи всё ещё будут корректны - видимо надо дату писать внутрь файла тоже - например первой нулевой записью (файл bin будет отсортирован для быстрого поиска) после которой вместо хеша файла будет идти заголовок:
- первые 8 байт - идентификатор реалма (Virtburg)
- вторые 8 байт - идентификатор реальности (Main,0,0,0,0)
- ну и наконец последние 4 байта - дата (20,24,12,05)
В таком случае ото дня ко дню контент файла реальности будет меняться, даже если все ассеты остались теми же, что вызовет изменение подписей (старые подписи уже не пройдут)...

[Shaos]

Не - всё таки надо без цифровой подписи пока. А валидацию сообщений чата можно делать пост-фактум на главном сервере через алгоритм HMAC-RIPEMD-160-96, который построен на основе того же самого хеша RIPEMD-160 и использует один и тот же ключ для подписи и проверки длиной до 20 символов - пользователь может иметь этот ключ у себя в клиенте и на главном сервере, а простые ноды этого ключа иметь не будут и валидацию проводить не смогут, т.е. им придётся верить наслово если кто-то говорит что он Shaos и находится в секторе Center в координатах 15,15 до следующего сеанса связи с главным сервером, когда тот сможет провалидировать все сообщения чата (включая рапорты текущих координат игроков).

Каждое сообщение чата, которое подписывается HMAC-ом, должно содержать следующие вещи:

• reality - идентификатор реальности (полное имя файла реальности по-видимому, например VirtburgRealm-MainReality-20241205);
• chatroom - путь к 3dm-файлу в котором находился пользователь в момент создания сообщения (хэш пути?);
• unixtime - время создания сообщения (количество секунд прошедших с 1 января 1970 года);
• username - имя автора сообщения (ник пользователя должен быть зарегистрирован в соответствующем реалме со своим секретным ключом);
• location - координаты пользователя внутри комнаты (или сектора) в момент создания сообщения (X:Y:Z);
• heading - направление движения (угол в градусах против часовой стрелки начиная с востока) и скорость движения (пока можно всегда ставить 0:0);
• msg - собственно само сообщение в UTF8 закодированное BASE64 (сообщение может и отсутствовать, если мы просто рапортуем изменение местоположения и направление движения).

Далее к этому сообщению добавляется подпись HMAC-RIPEMD-160-96 (12 байт в виде 24 шестнадцатеричных цифр), хэш RIPEMD-160 (покрывающий не только само сообщение, но и подпись для проверки целостности) и возможно маршрут по которому это сообщение пришло (IP-адреса через запятую, хотя проверить это будет невозможно). Далее каждая нода время от времени производит валидацию подписей пачкой ещё непроверенных сообщений через главный сервер реалма (либо через суперноды, которые знают все секреты ну и плюс будет проверяться, что персонаж перемещается не слишком быстро) и ставит себе виртуальную галочку у каждого сообщения, которое валидно (если сообщение оказалось невалидным или битым, то по хорошему его надо бы удалить). Ноды будут постоянно обмениваться (мимо главного сервера) отсортированными списками хэшей сообщений за сегодня (по комнатам? по часам?), чтобы понять что у кого есть и чего у кого нету для дальнейшего обмена непосредственно самими сообщениями (наверное сообщения можно представлять файлами с именами, являющимися их хэшами RIPEMD-160 закодированными в BASE32 - тогда ноды будут просить их друг у друга как обычные файлы).

P.S. Чую я придётся SQLite прикручивать к клиенту (который может являться нодой), чтобы всё быстро сортировалось и индексировалось...