Конечно, разберём по порядку. Во-первых, 512 байт оперативной памяти – это маловато, но можно выкрутиться, если упростить Paxos до самого необходимого — только фазы предложения, принятия и обучения, и пока отказаться от выборов лидера. Если упаковать всё в небольшую структуру, скажем, идентификатор предложения и значение по 2 байта, и несколько флагов, то уже получается меньше 16 байт на экземпляр. С пятью узлами это 80 байт на состояние, плюс небольшой буфер для входящих сообщений. Главное – делать каждое сообщение самодостаточным, чтобы не требовалось динамическое выделение памяти. Для детерминированности запускай протокол в одном потоке и избегай капризов планировщика операционной системы. Ну и чтобы обойтись без сплетен, кэшируй последнее принятое значение локально и транслируй его только при реальном продвижении журнала. Так удастся снизить накладные расходы на сообщения и сделать потребление памяти предсказуемым. Совпадает ли это с тем, что ты планировал, или ты думаешь о другом подходе?