Quote from: rorrim on January 24, 2018, 10:43:40 PM

Quote from: Vadim Valirov on January 24, 2018, 11:33:29 AM

"И что в такой концепции должно защищать цепочки от появления параллельной ветки?" - сами приложения, конечно. Если кто либо и взломает одно приложение, то остальные не будут подтверждать блоки в появившейся ветке. С другой стороны, форк возможен практически в любом блокчейне. А что защищает сегодняшние криптовалюты, от появления новых веток (ничего, кроме консенсуса майнеров)?
Единожды решенные задачи (их найденные хэши) будут повторно использоваться в параллельных ветках, их цена нулевая - в памяти приложений есть набор задач, они не уникальны. Каждое приложение (участник) имеет возможность единожды решить (или не решить) одну и ту же задачу (задачи предоставляются, в псевдослучайном порядке) и получить за нее токены (в случае, если его достижение приняли, для подтверждения цепи).
И что будет мешать взломать код децентрализованной игры и достать оттуда все ответы/хэши?" - взломать можно все (это только вопрос возможностей). Ну и что с того, что игрок получит базу с хешем ответов? Всегда есть возможность зашифровать зависимость вопрос/ответ. Пусть даже участник взломал базу и получил набор хешей? Как определить, какой хеш является ответов к вопросу? Единожды ошибившись, при подборе, участник теряет возможность получить вознаграждение, за эту задачу.

1. Причем здесь форк? Изучайте как устроен блокчейн и найдете ответ на свой вопрос- в зависимости от консенсуса, механизмы отличаются. Самый простой для объяснения механизм без всяких подводных камней в PoW консенсусе - хэш нового блока считается исходя из перечисленных в нем транзакций + хэша предыдущего блока, таким образом чтобы сделать параллельную ветку, нужно пересчитать хэши прошлых блоков и чем длиннее цепочка для замены, тем более трудоемко это сделать. В PoS/DPoS используется залог и много разных трюков. Но вы же не хотите разбираться, проще как попугай повторять одну и ту же ахинею.

2. Нет никакой памяти приложений!!! это распределенная сеть и блок может возникнуть в любом месте!!! и никто не знает какой блок раньше и какой позже, консенсус как раз и нужен для того чтобы эти блоки собрать в хронологическом порядке и исключить "неправильные"!!!

3. Участник взломал игру => получил таблицу вопрос=хэш => генерирует блоки без игры. Когда код доступен, обязательно декомпилируют, тут все способы защиты только от детей. И зашифровать не получится, т.к. ключ для дешифровки все равно внутри приложения будет.

1. Вы неточно сформулировали вопрос, я неверно Вас понял. Ответ на Ваш вопрос: Всегда есть возможность исключить появление веток "с нуля". Например, при генерации нового адреса кошелька, система автоматически списывает минимальную сумму (аналог 1 сатоши) со счета специально созданного кошелька-фонда (с этого кошелька начинается вся цепь блоков, это корень цепи. Баланс этого кошелька-фонда пополняется, за счет % от комиссионных, за транзакции). и переводит эту сумму на счет адреса нового кошелька. Таким образом, мы имеем первую входящую транзакцию. Эта ветка волшебным образом превращается в продолжение хеша, с корня цепи (с адреса фонда). То есть, злоумышленнику придется переписать всю цепь, с самого начала. А это уже вилка.
Условия: Транзакции, используемые, для привязки новой ветки (адреса) должны быть бескомиссионными и иметь высочайший приоритет. Без первой входящей транзакции генерация адреса не завершена, сама транзакция входит в хеш адреса

А. В одном кошельке не может быть больше, чем N адресов (иначе будут злоупотребления раздачей).
В. Минимальные входящие транзакции, для привязки ветки, должны быть бескомиссионными и иметь высочайший приоритет.

2. Я Вам пытался описать свое видение технической реализации, соглашусь оно несовершенно и требует доработки. Я рассматриваю все возможные механизмы реализации,для решения возникающих задач.

3. Как один из вариантов, ключ может храниться в памяти стороннего приложения (скорее нескольких случайных приложений), хеш кода для определения зависимости: «вопрос/ответ» передается по запросу, и не чаще чем раз в 5-10 мин (хеш/ключ для каждой зависимости, у каждого приложения уникален).