Юра, ты сильно спалился.
Внешний слой, внутренний слой - а это вообще что такое ?
Если зайти github.com/prizmspace/PrizmCore ,
скачать себе tech.prizm.space/files/prizm-dist-1.9.17-win.exe
запустить его у себя, то в нём никакой настройки "слоёв" нету.
Я может тоже хочу сделать у себя пул
по схемы Юры:
"2 узла внешнего слоя для фильтрации приходящих блоков
2 узла-посредника, передающие сфорженное из внутренного слоя на внешний
1 внутренний узел, занятый форжингом или обслуживанием онлайн сервиса.
Так делать - ПРАВИЛЬНО, и такая схема ориентирована на ОТКАЗОУСТОЙЧИВОСТЬ."
Но я этого не смогу, потому что в prizm-dist-1.9.17-win.exe
нет таких функций и настроек, о которых говорит Юра.
// а ещё у меня нет управления чёрным списком кошельков
// а у Юры есть.
Вывод: сам Майоров у себя использует совсем другой софт,
а не prizm-dist-1.9.17-win.exe, предлагаемый всем
желающим для "построения сети".
В кавычках, потому что для Майоровской сети все ноды
энтузиастов никакой роли не имеют и значения не играют.
И да, так делать - НЕПРАВИЛЬНО, потому что получается
не децентрализованная криптовалюта, а *****************
А как же в настоящих криптовалютах ?
А в настощих криптовалютах есть единый софт с полностью
открытым кодом, прошедшим инспекцию общественности.
И что энтузиасты, что мелкие инвесторы, что крупные,
что сами "создатели" запускают один и тот же софт
и весь его функционал доступен всем, и никаких "слоёв" там
нет и быть не может, есть полная децентрализация и равноправие,
единый список всех серверов, защита на основе распределения
кворума сети по множеству независимых серверов.
Бурановский Дедок сказал:
| "2 узла внешнего слоя для фильтрации приходящих блоков
| 2 узла-посредника, передающие сфорженное из внутренного слоя на внешний
| 1 внутренний узел, занятый форжингом или обслуживанием онлайн сервиса.
| Так делать - ПРАВИЛЬНО, и такая схема ориентирована на ОТКАЗОУСТОЙЧИВОСТЬ."
| Но я этого не смогу, потому что в prizm-dist-1.9.17-win.exe
| нет таких функций и настроек”
Написано - 6 узлов в среднем слое.
Как пытается это сделать дед - с помощью настроек ОДНОГО узла.??!!
Такое ощущение, словно с ботами общаюсь
Метафорическая аналогия:
(безымянная космическая корпорация)
Мы сделали ракету, летающую на смеси керосина и кислорода!
Дедуля:
Я выпил литр керосина и наглотался воздуха. И вы знаете что? Я НЕ ПОЛЕТЕЛ. Вы все обманщики! Земля - плоская, призма - скам, Маск - аферист!
| Вывод: сам Майоров у себя использует совсем другой софт,
| а не prizm-dist-1.9.17-win.exe, предлагаемый всем
| желающим для "построения сети".
| В кавычках, потому что для Майоровской сети все ноды
| энтузиастов никакой роли не имеют и значения не играют.
Так-то клевета - это статья, и я б советовал тебе искать реальные проблемы, а не просто поливаться своими испражнениями.
| И да, так делать - НЕПРАВИЛЬНО, потому что получается
| не децентрализованная криптовалюта, а *****************
Расскажи нам, чем же пул нарушает децентрализацию. Давай, занюхай дорожку того, что ты там нюхаешь, и ответь.
| И что энтузиасты, что мелкие инвесторы, что крупные,
| что сами "создатели" запускают один и тот же софт
| и весь его функционал доступен всем, ... есть полная децентрализация и равноправие,
| единый список всех серверов, защита на основе распределения
| кворума сети по множеству независимых серверов.
Спасибо за такое крутое и - впервые от тебя - правдивое описание призмы, надеюсь его где-нибудь применят )
Сделаем пул из 5 узлов.
Дано:
5 VPS
Дистрибутив(ы) Prizm отсюда
https://github.com/prizmspace/PrizmCore для Операционных Систем наших виртуалок
Рука, желательно - две руки, в идеале - растущие из плеч
PRIZM
http://prntscr.com/mpz98k
Краткая инструкция для пула из 5 узлов:
А. Качаешь ноду
Б. Разворачиваешь на 5 виртуалках, на каждой виртуалке по ноде
В. Дадим им номера 1 , 2 , 3 , 4 , 5 для удобства
Г. Настраиваешь фаервол на них следующим образом:
ВХОДЯЩИЕ:
1 - 9974 открыт для всех
2 , 3 и 4 - 9974 открыт для IP-адресов нод 1 и 5
5 - 9974 открыт для IP-адресов нод 2 , 3 и
ИСХОДЯЩИЕ:
1 - 9974 открыт на все направления
2 , 3 и 4 - 9974 открыт только на ноду 1 и ноду 5 .
5 - 9974 открыт только на ноды 2 , 3 и 4 .
Д. Редактируешь prizm.properties / prizm.default.properties:
1 - numberOfForkConfirmations = 2
2 , 3 и 4 - numberOfForkConfirmations = 0
5 - numberOfForkConfirmations = 2
(numberOfForkConfirmations определяет необходимое количество ДОПОЛНИТЕЛЬНЫХ подтверждений форка, то есть значение 1 приводит к необходимости ноды получить блок от 1 ноды и от 1-й дополнительной, подтверждающей ноды)
Е. Также корректируешь список defaultPeers и wellKnownPeers у всех нод.
2 , 3 и 4 ноды имеют только по два доступных пира - это нода 1 и нода 5 .
5 нода видит только 2 , 3 и 4 ноды.
1 нода видит всех снаружи и только 2 , 3 и 4 изнутри.
Ж. выключаем getMorePeers=false у всех внутренних нод (можно забить и не делать, если правильно настроили фаервол)
К чему это приводит:
1 -
внешняя нода
2 , 3 , 4 -
средняя прослойка
5 -
отказоустойчивая нода
Приходит блок из сети на 1 . Она его проверяет. Скачивает этот же блок с ещё нескольких дополнительных нод, количество которых равно numberOfForkConfirmations для 1-й ноды, то есть с двух дополнительных нод сети.
Результат: 2 дополнительных подтверждения снижают вероятность оказаться в форке.
Ноды 2 , 3 , 4 среднего слоя скачивают блок с ноды 1 . У них установлено 0 дополнительных подтверждений (numberOfForkConfirmations=0), потому что первая нода уже сделала проверки по форку. Они обрабатывают и проверяют блок.
Если блок соответствует всем формальным правилам, включая комиссии, выплаты парамайнинга и правильный hit, то он естественно принимается.
Внутрення нода скачивает блок с узла 2 (как пример), затем спрашивает 3 и 4 о его наличии (numberOfForkConfirmations = 2). Они говорят - да, есть такой,
норм блок. Она его
принимает.
А теперь -
магия!
Если
внутрення нода сфоржила этот же блок, то она пытается отдать его 3 , 4 и . Они в свою очередь принимают решение, какой же блок лучше - полученный снаружи или сделанный внутри. В случае, если они единогласно принимают решение:
1. Внешний лучше
Внутрення нода свитчится на их форк, потому что её форк не принят единогласно. Помним, что ей нужно 3 узла, чтобы свичнуться на их форк.
2. Внутренний лучше
Внешняя нода получает 3 подтверждения изнутри (со среднего слоя) и свитчится на блок, пришедший изнутри. Теперь, зная, что 3 внутренних узла единогласно приняли внутренний блок, мы можем быть уверены, что блоки не равны по значению и сфорженный нами блок однозначно приоритетен по логике всех нод. Внешняя нода отдаёт блок в сеть и все остальные во внешнем мире принимают его.
3. Они равны по значимости
Узлы среднего слоя не смогли определиться единогласно, какой блок для них “вкуснее” и разделились во мнениях. Какие-то два узла приняли внешний блок, третий узел принял внутренний или наоборот.
Это означает, что блоки равноценны по кумулятивной сложности и содержащимся транзакциям/выплатам.
При этом внешняя нода не получает изнутри 2-х подтверждений внутреннего форка, и не принимает внутренний форк. Со следующим пришедшим снаружи блоком, форк внешней ноды будет длиннее и однозначно приоритетнее для нод среднего слоя и они свитчатся на него. От них уже свитчится и внутренняя нода, потому что она не могла так же быстро сфоржить второй блок и её форк в любом случае короче внешнего.
Плюсы:
избегаем путаницы. мы отдаём во внешний мир только те блоки, которые однозначно лучше среди всех сфорженных, если же наши блоки не будут приняты всей сетью единогласно, мы не нагружаем лишний раз сеть их проверкой, делая эти проверки в своём пуле. они всё равно в конце концов будут отброшены, но это займет у сети время. а близко расположенные серваки/впски примут решения по блоку за доли секунды.
избегаем видимости внутренней ноды снаружи. если внутрення нода обслуживает сайт, будет очень обидно, если она застопорится на каком-то блоке и повиснет. шансы крайне малы, но если такой блок придёт - на нем стопорнется внешняя нода или в крайнем случае - нода среднего слоя. Внутренняя всё так же будет спокойно обслуживать сервис/сайт.
также мы защищаем внутреннюю ноду, которая должна работать стабильно 24/7, от внешней агрессии. никто, кроме нас, даже не знает её IP-адреса!
Минусы
надо много виртуалок.
геморрой при настройке
Обычные люди спокойно форжат и на одной ноде, а если человек решил серьёзно форжить на крупном балансе на постоянной основе, ему будет удобнее сделать пул, облегчая жизнь себе и внешнему миру.
Ниже приведены персональные настройки для разных слоёв нод. Настройки для каждой ноды одного слоя идентичны.
Настраиваем Linux IPTABLES:
Примем несколько условностей для удобства:
$IP_OF_FIRST_NODE = IP адрес внешней ноды (нода 1 )
$IP_OF_INTERNAL_NODE = IP адрес внутренней ноды (нода 5 )
$IP_OF_MIDDLE_NODE_2= IP адрес средней ноды (нода 2 )
$IP_OF_MIDDLE_NODE_3 = IP адрес средней ноды (нода 3 )
$IP_OF_MIDDLE_NODE_4 = IP адрес средней ноды (нода 4 )
Если где-то ниже по тексту использованы эти строки, при использовании заменяйте их на IP-адреса соответствующих нод.
Ниже будут приведены команды для ввода в консоли Linux. Символ доллара символизирует начало строки, и вводить его не нужно.
Во-первых, нужно установить пакет iptables-persistent, чтобы после перезагрузки не слетели правила фаервола.
$ sudo apt-get install iptables-persistent
По завершении конфигурации (введения соответствующих команд) каждой виртуальной машины, напишите в терминале
$ sudo iptables-save > /etc/iptables/rules.v4
Это сохранит настройки фаерволла и они не слетят в случае перезагрузки машины.
Если вы действуете от имени пользователя root, вводить sudo в начале команды не нужно.
Внешний слой - Нода 1
$ sudo iptables -A INPUT -p tcp --dport 9974 -j ACCEPT
$ sudo iptables -A OUTPUT -p tcp --dport 9974 -j ACCEPT
Средний слой - Ноды 2 , 3 , 4 .
# открываем доступ к ВНЕШНЕЙ ноде и ВНУТРЕННЕЙ ноде
$ sudo iptables -A INPUT -p tcp --dport 9974 -s $IP_OF_FIRST_NODE -j ACCEPT
$ sudo iptables -A INPUT -p tcp --dport 9974 -s $IP_OF_INTERNAL_NODE -j ACCEPT
$ sudo iptables -A INPUT -p tcp --dport 9974 -j DROP
$ sudo iptables -A OUTPUT -p tcp --dport 9974 -d $IP_OF_FIRST_NODE -j ACCEPT
$ sudo iptables -A OUTPUT -p tcp --dport 9974 -d $IP_OF_INTERNAL_NODE -j ACCEPT
$ sudo iptables -A OUTPUT -p tcp --dport 9974 -j DROP
Внутренний слой - Нода 5 .
$ sudo iptables -A INPUT -p tcp --dport 9974 -s $IP_OF_MIDDLE_NODE_2 -j ACCEPT
$ sudo iptables -A INPUT -p tcp --dport 9974 -s $IP_OF_MIDDLE_NODE_3 -j ACCEPT
$ sudo iptables -A INPUT -p tcp --dport 9974 -s $IP_OF_MIDDLE_NODE_4 -j ACCEPT
$ sudo iptables -A INPUT -p tcp --dport 9974 -j DROP
$ sudo iptables -A OUTPUT -p tcp --dport 9974 -d $IP_OF_MIDDLE_NODE_2 -j ACCEPT
$ sudo iptables -A OUTPUT -p tcp --dport 9974 -d $IP_OF_MIDDLE_NODE_3 -j ACCEPT
$ sudo iptables -A OUTPUT -p tcp --dport 9974 -d $IP_OF_MIDDLE_NODE_4 -j ACCEPT
$ sudo iptables -A OUTPUT -p tcp --dport 9974 -j DROP
На других ОС используйте их средства настройки фаервола, их мы здесь рассматривать не будем. Посмотрите на инфографику выше и настраивайте фаерволы в соответствии с ней.
Конфигурируем prizm.default.properties / prizm.properties
Нам нужно найти файл prizm.default.properties
На Windows: C:/Program Files/Prizm/conf/prizm.default.properties
На Mac: /Applications/Prizm.app правой кнопкой мыши, “Показать содержимое пакета”, далее Contents > MacOS > conf > prizm.default.properties
На Linux: в папке куда вы распаковали PrizmCore будет подпапка conf, в ней искомый файл.
---
Внешний слой - Нода 1 .
prizm.getMorePeers=true
prizm.numberOfForkConfirmations=2
http://prntscr.com/mpzewv
# В wellKnownPeers и defaultPeers после всех
# пиров нужно добавить IP адреса 2, 3 и 4 нод
prizm.wellKnownPeers=...;$IP_OF_MIDDLE_NODE_2;$IP_OF_MIDDLE_NODE_3;$IP_OF_MIDDLE_NODE_4;
prizm.defaultPeers=...;$IP_OF_MIDDLE_NODE_2;$IP_OF_MIDDLE_NODE_3;$IP_OF_MIDDLE_NODE_4;
---
Средний слой - Ноды 2 , 3 , 4 .
prizm.getMorePeers=false
prizm.numberOfForkConfirmations=0
http://prntscr.com/mpzfk0
# В wellKnownPeers нужно полностью
# заменить wellKnownPeers и defaultPeers
prizm.wellKnownPeers=$IP_OF_FIRST_NODE;$IP_OF_INTERNAL_NODE;
prizm.defaultPeers=$IP_OF_FIRST_NODE;$IP_OF_INTERNAL_NODE;
http://prntscr.com/mpzfva
пример, где 1 и 5 ноды имеют адреса 90.90.90.1 и 90.90.90.5 соответственно
---
Внутренний слой - Нода 5 .
prizm.getMorePeers=false
prizm.numberOfForkConfirmations=2
http://prntscr.com/mpzgb9
# В wellKnownPeers нужно полностью
# заменить wellKnownPeers и defaultPeers
prizm.wellKnownPeers=$IP_OF_MIDDLE_NODE_2;$IP_OF_MIDDLE_NODE_3;$IP_OF_MIDDLE_NODE_4;
prizm.defaultPeers=$IP_OF_MIDDLE_NODE_2;$IP_OF_MIDDLE_NODE_3;$IP_OF_MIDDLE_NODE_4;
http://prntscr.com/mpzgow
пример, где 2, 3 и 4 ноды имеют адреса 90.90.90.2, 90.90.90.3 и 90.90.90.4 соответственно
Почему форжить следует именно так? Потому что это избавляет от кучи проблем (в частности, защищает от злых школьников по типу ultratech’a) и в разы повышает стабильность форжащей ноды.
Что ещё можно посоветовать:
В файле prizm.default.properties всех нод в пуле замените prizm.allowedBotHosts=* на
prizm.allowedBotHosts=%ВАШ_ДОМАШНИЙ_IP_АДРЕС%
Если Вы это сделаете, доступ к API этих нод будет ТОЛЬКО с Вашего домашнего IP-адреса. Если у Вас не статический IP адрес, можно использовать туннель через какой-то Ваш сервер, чтобы получать доступ с того сервера. Это нужно для того, чтобы никто не лазил по веб-интерфейсу Ваших нод и не перегружал их лишний раз, посколько цель существования такого пула - стабильность.
В принципе, для всех нод, кроме внутренней, можно вообще выключить API, установив параметр prizm.enableAPIServer=false, а для внутренней уже разрешить доступ только с доверенных IP адресов с помощью prizm.allowedBotHosts=, указывая IP адреса через точку с запятой.
До призма нужно дорасти мозгами, а у кого их нет - селяви)