Тебе для чего? Если речь о распределённой бухгалтерской книге для недоверенного окружения, то всё гораздо тривиальнее и я несколько месяцев назад набросал вполне годную схему, но не забывай чем больше нод, тем выше задержки до наступления консенсуса, поэтому между совершением и подтверждением транзакции придётся ждать. Производительность на глаз 150 TPS на любом пылесосе, думаю можно вытянуть и 300 TPS без особых проблем, требования к дисковому пространству до 75Гб на 1млрд. активных адресов, OTP как в банках, можно проё*ывать приватный ключ без последствий.
Если же требуется чтобы все ноды перманентно находились в синхронном состоянии, то это фантастика даже в централизованных системах и я джва года хочу такую
Я не видел того предложения. Можно ссылку? Или может поучаствуете в обсуждении тут?
Всё достаточно тривиально и уже давно используется в синхронизации БД, единственное там нет костылей для недоверенного окружения, но прикрутить их ничего не мешает.
Что такое БД? Это набор данных актуальный на определённый момент времени. Что такое блокчейн? Это WAL, то есть история транзакций внесённых в БД. Пользователю не нужна вся история, если того не требует архитектура, ему нужна синхронизированная БД. Каким образом этого добиться? Достаточно регулярно, скажем раз в X блоков или транзакций, записывать в WAL (он же блокчейн) корневой хеш БД и хеши её частей используемые для вычисления корневого хеша, таким образом клиент для синхронизации читает хеши из WAL и выкачивает БД частями, как это происходит при скачивании торрента, последующие транзакции клиент берёт из WAL и накатывает в полученную БД. Для снижения нагрузки на диск при хешировании больших БД в теории можно распределить хеширование на большое количество нод, которые должны предоставить подписи свидетелей, заверяющие валидность хеша данной части. Журналов (*чейнов) должно быть 2, один - история транзакций, другой - история снимков БД.