rPman

Проблема терминологии, термин 'участник' неправильно изначально определен и создает кучу неоднозначностей.

Для PoW консенсуса - 'участник' это майнер, все остальные - пользователи, никак не влияющие на работу (точнее влияют на доствку неподтвержденных транзакций до майнеров, не больше)

Для PoS консенсуса - 'участник' это витнес/зверитель или стейкер (по факту тот же майнер но сдругими правилами), в зависимости от реализации консенсуса, с теми же вытекающими последствиями.

Так вот, только майнеры могут что либо менять в блокчейне, и в зависимости от консенсуса, требования к этому соответствующие (у PoW это обладание >50% мощностей, но можно и меньше, если количество попыток достаточно велико, можно 'отменять' изменения в последних блоках и при меньших мощностях, и да, незамеченным это не останется, это мониторят все крупные участники)

p.s. есть еще разработчики, чей код (если) майнеры принимают безоговорочно, в этом случае разработчики самые главные и могут все что угодно (повторяю - согласие майнеров в данном случае требуется все равно).
Например чтобы нарушить провозглашенное правило первого 'цецентрализованного контракта на блокчейне' DAO в сети ethereum - 'код это закон', разработчики ethereum внесли соответствующий фикс а майнеры молча поддержали, заблокировав адреса одного из пользователей (который обнаружил уязвимость в коде и собирался присвоить монеты себе), так появился ethereum classic (в котором блокировки нет), точнее если праивльно формулировать, идеологически верный эфир переименовали в ethereum classic а новый измененный блокчейн стали называть ethereum.

Поэтому, у тебя есть следующие варианты по защите своей информации (в мире криптовалют информация = деньги):

1. Ты физически защищаешь сервер от доступа злоумышленника и шифруешь данные на случай если доступ все же они получат
   Этот путь подразумевает буквально, сервер в сейфе, а для обслуживания к нему катается физически надежный человек, почти все датацентры предоставляют закрытые защищенные помещения для этого. Этот способ самый простой для реализации но самый дорогой.
   
2. Обфусцируешь доступ к информации
   Организуешь всю систему так, чтобы получив доступ злоумышленнику потребовалось бы заметное время понять как именно нужно добраться до критичной информации и главное, расставляешь ловушки, сигнализирующие о том что сервер скомпроментировал, тогда ты уже со своей надежной машины переводишь монеты с горячего кошелька, останавливаешь сервис и разбираешься.
   
   Одним из примеров такой реализации является разделение на 2 сервера, один оперативный, основной, обслуживающий твой веб сервис и твоих пользователей, второй - защищенный, обслуживающий только исходящие переводы. Второй сервер значительно менее требовательный на столько, что его можно разместить чуть ли не у владельца дома или даже к примеру смартфоне (абсурд но как ни странно такая модель имеет место быть). Между серверами, по своему api идут команды, среди которых можно вставить ловушки, которые обязательно тронут злоумышленники и это даст нужный сигнал на отключение системы. В такой схеме нужно понимать концепцию read only частей базы данных, изменения которых могут приходить только со стороннего сервера, например части, отвечающие за работу операторов, обслуживающих доставку товара в интернет магазине, могут быть изменены только с их рабочих мест, реализовывать это можно разными способами, кстати блокчейн - один из них, но как пример - каждая запись снабжается цифровой подписью, и любое изменение подписывается тем кто это изменение произвел, такие записи подделать, взломав только один сервер невозможно, а сервер, отвечающий за отправку монет будет принимать только правильно подписанные записи... в общем реализация потребует творческого подхода но все реально.
   
   Само собой описанный способ не самый лучший но хотя бы доказуемо надежный, из простых способов я посоветовал бы просто хранить критичную информацию исключительно в оперативной памяти, слегка обфусцированной, защита от простого сканирования памяти, а сам процесс ее загрузки делать в момент включения сервера (или его полной установки из резервной копии, для чистоты, каждый раз когда происходит его выключение)
   
3. Гомоморфное шифрование
   Этот подход я не видел в реализации, так как невероятно сложен (если что математика уже реализована, есть библиотеки, например HElib, зато позволит проводить полностью все операции на сервере а самую последнюю, собственно отсылку - на доверенном сервере
   гомоморфные вычисления позволяют проводить математические операции над зашифрованными данными без их расшифровки, т.е. сервер, выполняющий эти операции не будет знать ответа, поэтому доверять таким вычислениям можно без оглядки (правда сервер может пропустить вычисления, но это легко решается добавлением в каждую операцию какое то вычисление, связанное с прошлой, в общем легко будет заметить что сервер перестал отвечать)
   

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

* деанонимизация, как минимум сайт узнает ваш ip адрес (а из него примерные географические координаты), очень часто об этом забывают пользователи telegram и других анонимных чатов
* спам через уведомления, сайты запрашивают разрешение на прием уведомлений (иногда циклически, пока не нажмешь да) и через некоторое время у вас будут всплывающие окна с картинками (реклама)
* атака уязвимых веб сервисов где вы авторизованы - click jacking (вслепую заставлять нажимать кнопки на авторизованном сайте, рисуя его со 100% прозрачностью в iframe, пододвигая под курсор пользователя), cross site scripting (выполнять действия на сайтах вызывая напрямую там запросы)
* есть опасность доступа к буферу обмена, дело в том что по стандарту, браузер не имеет прямого доступа к буферу, пока пользователь не совершит действие на сайте (клик мышкой), заставить пользователя это сделать не сложно, а содержимое буфера будет у злонамеренного сайта, а что там у вас в буфере бывает - иногда очень интересно
* фишинг - подсовывать визуальную копию других сервисов, требовать авторизацию и таким образом выуживать логин пароль
* многие люди разрешают (поведение браузеров по умолчанию) автоматическую загрузку файлов в каталог загрузки, злонамеренный сайт может подсунуть туда легитимное приложение, зараженное трояном, в надежде что пользователь когда-нибудь запустит его, увидев в папке загрузки (там всегда бардак и никто не запоминает откуда что скачали), на самом деле это одно из самых опасных действий, так как переводит операции из браузерной песочницы в операционную систему, а там уязвимости опаснее
...

на английском
метавселенная это (маркетинговая) философия, ее создают, используя голову и человеческие языки

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

то что в 'эту игру' (я про навешай потребителю лапши побольше) хотят играть другие ничего не меняет, просто смени место приложение вопросов на другую компанию

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

тут несколько подходов, я трогал каждый из них и все они имеют право на существования
1. оставь как есть, я рекомендую, пусть будет 100500 таблиц справочников (если проблем с именами нет ну и отлично), fk-индексы все это свяжут а инструменты анализа базы данных помогут с этим работать (автоматические query builder с мышевозекательным интерфейсом) и база будет сама следить за тем что идентификаторы справочников не противоречивы
недостатков я не могу придумать, кроме может быть сильно разросшейся структуры, когда то давно я слышал что некоторые базы данных при увеличении количества таблиц начинают хуже работать но как я понимаю это если их будет десятки тысяч а не десятки и сотни.. может быть резервное копирование такой базы или ее репликация будет проходить чуть медленнее или еще хуже, организационно репликация может быть настроена на не рассылку ddl модификаций, в этом случае создание нового справочника будет задавать работу еще и админам, что нежелательно.

2. противоположный, использование одной таблицы key-value для нескольких разнородных справочников (id, value, table_name), в 99% случаев можно использовать один сиквенс (одну последовательность идентификаторов), вам же не обязательно чтобы разные справочники начинали счет своих строк с одного и того же числа 1.
Недостаток - база данных теперь не сможет контролировать что вы используете непротиворечивый идентификатор (можно в запись одного справочника указать номер из другого), хотя несуществующий так же нельзя будет указать (и будут работать delete cascade), так же удобной автогенерации sql не будет. Структура будет проще, так же интерфейс редактирования таких справочников может быть один вместо кучи форм и добавлять новые справочники будет сильно проще (хотя с точки зрения разработки нет особой разницы, один insert ты написал или create table перед этим)

3. не хранить справочники в базе данных вообще, т.е. за значение справочников отвечает бакэнд (хранятся в статичных файлах или в коде) самый дибильный подход, редактировать такие справочники скорее всего только руками в конфигах/исходниках. Недостатки - база данных совсем не будет знать ничего о значениях и не сможет ни проконтролировать ни помочь с запросами
Но это позволит снять немного нагрузки с базы данных, сделает структуру проще и позволит перенести управление значениями справочников на откуп ide редактора (если хранить значения справочников в коде, можно дать значениям имена переменных, так как в коде часто их так или иначе заводить придется)

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