Из того, что я прочитал, я думаю, что это все еще открытый вопрос, который не рассматривается в литературе.
Byzantian Proposer Fast Paxos устраняет отказ в обслуживании, но только будет задерживать отправку сообщений из-за атак, не связанных с флудом, с увеличивающимися (предлагаемыми) счетчиками.
Сказав это, целочисленное переполнение, вероятно, является наименьшей из ваших проблем. Вместо того, чтобы думать о целочисленном переполнении, вы можете сначала рассмотреть атаки членства (через DoS). Получение информации о членстве после получения консенсуса от нескольких узлов может быть жизнеспособной стратегией, но, вероятно, все еще уязвимой для атак Sybil на каком-то уровне.
Другой стратегией может быть включение некоторой системы подтверждения выполнения предложений по ограничению поток запросов. Однако трудно понять, что использовать в качестве метрики для баланса (например, бесплатная валюта при майнинге цепочки блоков в биткойнах). Это действительно зависит от того, какой тип системы вы пытаетесь построить. Вы должны учитывать ценность информации в вашей системе, а затем создать систему проверки работоспособности, для обхода которой потребуется несколько больше затрат.
Однако если у вас есть возможность замедлить работу счетчика предложений, вам все равно придется беспокоиться о целочисленных максимумах в любой системе с большим количеством (действительных) операций. У вас должна быть стратегия переноса чисел или схема с множественной точностью, с помощью которой вы сможете четко определить, сколько лет/десятилетий ваша сеть может работать, не сталкиваясь с проблемами и не сбрасывая счетчик с фиксированной точностью. Если вы можете определить, что ваша система будет работать в течение 100 лет (или сколько-то еще), не сбивая счетчик с фиксированной точностью, даже с вредоносными объектами, тогда вы можете упростить ситуацию.
С другой (важной) стороны, системная модель, используемая в большинстве статей, не отражает всего, что делает практическую реализацию в реальной жизни (Raft является хорошим исключением из этого правила). Во всяком случае, некоторые авторы виновны в создании модели системы, предназначенной для того, чтобы избежать трудной проблемы, на которую они не нашли ответа. Итак, если кто-то говорит, что X решит все, имейте в виду, что они имеют в виду только то, что он решает все в очень конкретной модели системы, которую они определили. С другой стороны, вы должны учитывать, что модель системы тесно связана с утверждением, в котором говорится: «Y невозможно». Хорошим примером для объяснения этой концепции является полностью асинхронная передача сообщений Алгоритм консенсуса Бен-Ор, который использует недетерминизм в конечном автомате модели системы, чтобы избежать ограничений, указанных результат невозможности FLP (который указывает, что консенсус требует частично асинхронной передачи сообщений, когда конечный автомат системной модели является детерминированным).
Таким образом, вы должны продолжать рассматривать «невозможное» после того, как прочтете доказательство, в котором говорится, что это невозможно сделать. Нэнси Линч сделала хорошую статью об этой концепции.
Я думаю, что я действительно говорю, что хорошего решения вашего вопроса пока не существует. Если вы это выясните, пожалуйста, опубликуйте ее (или дайте мне знать, если вы найдете существующую статью).
05.02.2014
