Я не понял, у тебя соседние ноды/сиды только должны знать о транзакции? допусти 1 нода дружит с 2,3,4 и они вместе образуют кластер? тоесть 10000 нода, должна просто связаться с этими 5ю и больше ни с кем?
Тут бы самое время разобраться, как работает DHT.
Слово "только" - лишнее. Правильная формулировка примерно такая:
достаточно, чтобы о транзакции знали N ближайших (соседних) нод.
Ближайших к одной и другой стороне транзакции, напоминаю - ибо в транзакции принимают участие две стороны (необходимо и достаточно).
Правильно я тебя понял, что каждая транзакция у тебя будет 2 минуты?
Откуда ты это взял вообще?
2. те которые офлайн вообще не понятно, как будут синхронизироваться, спустя допустим год отключки. сколько им надо будет выкачать инфы?)
Это не блохчейн, там не надо ничего "выкачивать".
Ещё раз, что ты понимаешь под "синхронизироваться"? Состояние своего счёта - так оно не изменяется, если ты сидишь в оффлайне и никуда ничего не отправляешь/получаешь. Счёт с которого тебе прилетела транзакция - ну так ты "проверил" транзакцию на валидность описанным выше способом, вот и вся "синхронизация".
А ты так говоришь или кодил отправку сообщений по сети? Я кодил. когда уже 100 компов, которые могут отвалится, надо проверить обратно связь, записать данные в журнал, записать данные в вектор от кого получил, когда итд. это смерть. это не просто выкачивать файл по списку ip адресов и проверять его хеш. это совсем другая история. если рассмтаривать классические консенсусы и их скорость, так они в системе, где все сервера заведомо доверенные.
Ну я не знаю, если на жаваскрипте с мегабайтными фреймвоками - то как-то так оно и работает.
Нормально написанное, я уже сказал, ближайший аналог в плане скорости - поиск пиров в DHT (т.е., тот же алгоритм и технология).
ну смотри, ты отправляешь адресатам, а каждый следующий адресат должен знать кому уже отправляли, чтобы повторно не спамить обратно. тоесть должен быть вектор
Да нихрена там не надо никаких векторов (и вообще, кто это придумал давать уже даденные названия; я вот лично только вектор прерывания знаю).
Ну прилетит транзакция ноде дважды или трижды, ничего страшного. Можно подумать, tcp пакеты никогда ни разу не дублируются.
если кто-то один отваливается в моменте, опять куча тестов должно быть. это ад.
Да никакого ада и
израиля кучи тестов.
Какая-то QoS служба должна быть, это я ещё сообщений 5 выше писал. Ну, там несложно попинговать ноды, скажем, на начальном этапе раз в секунду - а потом просто присваивать им определённый "рейтинг" доступности.
как второй продавец получит инфу о попытке даблспенда в считаные секунды, если нод/сидов 10000.
Да хоть миллион. Они что, все одновременно к нему ломятся и пытаются даблспендить, по-твоему? Ну, так даже в этом случае никто не мешает обрабатывать транзакции
в порядке живой очереди(с).
напиши простой скрипт, хотяб на zeromq
Ну вот я про что и говорю.
Твой скрипт дольше будет ворочаться со всеми этими вашими фреймворками, чем собственно коммуникация происходить.
Я тебе конкретный вопрос задал, что их этого будет использоваться
- от нее часто прилетает даблспенд транзакция
- нода отправляет неверные данные
- нода не проводит транзакции дальше и засыпает случайным образом
- нода переподисывает транзакцию и делает вид, что она не валидна
- нода сообщает другим нодам, что нода Х плохая и ее надо банить
Не хочешь, не отвечай
А я тебе вполне конкретно ответил - я же не виноват, что ты ответов либо не понимаешь, либо не хочешь понимать ответов, которые тебя не устраивают.
То о чем ты говоришь, это проблема двух веток, а не византийских генералов. поэтому не зачет тебе.
Какая ещё нахер "проблема двух веток".
Это именно следствие того, что нихера там не решено - только иллюзия, что если долго пилить, то все поверят, что гиря золотая.
И то, потом кто-нибудь с 51% хэшрейта всё по-своему перепилить может (на самом деле,
как я уже говорил - достаточно 30%).
