proof of game

[Vadim Valirov]

1. "ОК, конкретнее: множество узлов формируют блоки, какой из них пойдет в цепочку?" это вопрос реализации правил игрового процесса. Вне зависимости от того, как реализован проект, цепь блоков служит, для хранения данных и не может быть фикцией (пример - proof of stake).
2. "Если proof of game это консенсус, тогда в цепочку пойдет тот блок, какой скажет игровой сервер. Т.е. метод принятия решения исключительно централизованный, в таком случае вся цепочка блоков просто фикция." - почемы Вы это утверждаете? Возможно заранее прописать правила, по которым будет выбрано достижение, для записи блока в цепь. Алгоритм, по которому будет приниматься консенсус, между приложениями. Например, коофицент уровня игрока к уровню монстра (чем круче был монстр, по отношению к игроку, тем большая вероятность, что достижение используется, для подтверждения блока).
Сервер только подтверждает наличае достижения (что тоже можно проверить, поскольку приложения синхронизированы).

В PoS/DPoS все узлы знают у кого сколько ресурса (монеток) есть. В случае с сервером, сервер может любые достижения генерировать для отдельных пользователей.

Я же уже об этом говорил выше - "приложения сверяют подтвержденные сервером результаты между собой). Например, игрок HTGHY убил монстра №34kuyylk8787T, теперь этого монстра нет на карте (в течении определенного интервала времени), следовательно, никакое другое приложение (игрок), не может получить вознаграждение, за  это достижение".
Все приложения хранят обновляют и сверяют между собой информацию об игровом процессе: монстрах, местах локации игроков, их перемещении в пространстве и времени, характеристиках, битвах в игре (в зашифрованом виде). После победы над монстром (подтверждение с сервера), подается запрос на проведение консенсуса. Приложения сверяют данные, если по каким то причинам приложения других участников (оговоренный %) опровергают достижение (монстр был убит и еще не возродился, все еще присутствует в игре, локации не совпадают, время не совпадает, процесс поединка содержит ошибки/нарушения, характеристики игрока не позволяют осуществить достижение, во время боя отсутствовала обратная связь с приложением (нет исходящих запросов к серверу) и т.д.), система не принимает его (достижение не прошло процедуру ревизии). С течением времени, устаревшая информация об игровом процессе сжигается, для освобождения дискового пространства. Достижения игроков сохраняются, в качестве подтверждения блоков.

Решение принимается на основе анализа совокупности N факторов. Если в данных текущего временного интервала игрового процесса, учетной записи, присутствуют разрывы (нет данных, на основании чего менялись характеристики персонажа, локация и т.д.) достижения такого приложения не принимаются другими.

Поскольку со временем, устаревшие данные об игровом процессе сжигаются, то данные об изменениях характеристик (уровень персонажа, его навыки и имущество) каждого участника так же сохраняются в блокчейн. Эта мера поможет избежать проблем с фальсификациями, когда параметры персонажа были неправомочно изменены, но игрок не совершал действий, ожидая сожжения оперативных данных о состоянии игрового процесса, в приложениях.

[1715406483]

1715406483

[1715406483]

1715406483

[1715406483]

1715406483

[1715406483]

1715406483

[1715406483]

1715406483

[knopka]

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

[rorrim]

Я же уже об этом говорил выше - "приложения сверяют подтвержденные сервером результаты между собой). Например, игрок HTGHY убил монстра №34kuyylk8787T, теперь этого монстра нет на карте (в течении определенного интервала времени), следовательно, никакое другое приложение (игрок), не может получить вознаграждение, за  это достижение".
Все приложения хранят обновляют и сверяют между собой информацию об игровом процессе: монстрах, местах локации игроков, их перемещении в пространстве и времени, характеристиках, битвах в игре (в зашифрованом виде). После победы над монстром (подтверждение с сервера), подается запрос на проведение консенсуса. Приложения сверяют данные, если по каким то причинам приложения других участников (оговоренный %) опровергают достижение (монстр был убит и еще не возродился, все еще присутствует в игре, локации не совпадают, время не совпадает, процесс поединка содержит ошибки/нарушения, характеристики игрока не позволяют осуществить достижение, во время боя отсутствовала обратная связь с приложением (нет исходящих запросов к серверу) и т.д.), система не принимает его (достижение не прошло процедуру ревизии). С течением времени, устаревшая информация об игровом процессе сжигается, для освобождения дискового пространства. Достижения игроков сохраняются, в качестве подтверждения блоков.

Жуткая ересь здесь написана. Советую изучить сначала основы, как на самом деле работают основные консенсусы в блокчейне. А в современном геймдизайне, если уж мы говорим о какой-то рпг-подобной игре, все завязано на рандоме со времен D&D.

[Vadim Valirov]

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

Друзья, я уже дважды отвечал на этот вопрос выше (этот ответ третий). Пожалуйста, не задавайте мне одинаковых вопросов.

Монитизировать подобный проект можно, продавая лицензии на участие в игре (как в большинстве существующих on-line игр). Купив лицензию у разработчиков (за фиат), участник получает возможность добывать крипту. Кроме того, при запуске проекта часть токенов (% от общ. кол-ва) может быть эмитирована досрочно и распределена, между членами команды. Число токенов будет ограничено. Все токены, получаемые в качестве комиссионных за переводы, сжигаются. Вместо них, приложения генерируют равное количество токенов (1:1), для перераспределения вознаграждения между участниками.  

Я же уже об этом говорил выше - "приложения сверяют подтвержденные сервером результаты между собой). Например, игрок HTGHY убил монстра №34kuyylk8787T, теперь этого монстра нет на карте (в течении определенного интервала времени), следовательно, никакое другое приложение (игрок), не может получить вознаграждение, за  это достижение".
Все приложения хранят обновляют и сверяют между собой информацию об игровом процессе: монстрах, местах локации игроков, их перемещении в пространстве и времени, характеристиках, битвах в игре (в зашифрованом виде). После победы над монстром (подтверждение с сервера), подается запрос на проведение консенсуса. Приложения сверяют данные, если по каким то причинам приложения других участников (оговоренный %) опровергают достижение (монстр был убит и еще не возродился, все еще присутствует в игре, локации не совпадают, время не совпадает, процесс поединка содержит ошибки/нарушения, характеристики игрока не позволяют осуществить достижение, во время боя отсутствовала обратная связь с приложением (нет исходящих запросов к серверу) и т.д.), система не принимает его (достижение не прошло процедуру ревизии). С течением времени, устаревшая информация об игровом процессе сжигается, для освобождения дискового пространства. Достижения игроков сохраняются, в качестве подтверждения блоков.

Жуткая ересь здесь написана. Советую изучить сначала основы, как на самом деле работают основные консенсусы в блокчейне. А в современном геймдизайне, если уж мы говорим о какой-то рпг-подобной игре, все завязано на рандоме со времен D&D.

Это не конструктивные замечания. Это оценочные суждения и почти хамство. Поучайте пожалуйста своих близких.

«Советую изучить сначала основы, как на самом деле работают основные консенсусы в блокчейне»  (по всей видимости Вы имели ввиду консенсусы proof of worke) - мы сейчас обсуждаем возможности реализации подтверждений достижений в игре (достижение консенсуса между приложениями), так?
Я Вам описал возможную схему реализации подобного проекта. В каждом приложении имеется своего рода оперативная память об игровом процессе, на основании анализа этих данных происходит ревизия достижения, перед его принятием в качестве доказательства блока. Разные приложения подключаются к разным игровым серверам (в соответствии с географией) и следовательно получают данные об обновлениях из разных источников, при этом данные должны совпадать.    

Вцелом, я согласен с тем что вопрос реализации концепции требует доработки. Мне было бы интересно найти единомышленников, для его развития.

Вопрос реализации, это верно. Децентрализованной должна быть область данных, содержащая в себе достижения игроков (цепь блоков) и транзакции, включенные в блоки. Сама игра не обязательно должна быть децентрализованной - достаточно подключения к нескольким on-line серверам. Таким образом, игровой процесс остается под централизованным управлением, а ресурсная экономика проекта - децентрализована. Как вариант.

Как метод консенсуса тогда работать не будет. Или нужно говорить о приватном блокчейне, где блоки формируют только собственные ноды-игровые сервера. Начисление монеток за ачивки игроков это уже совсем другое дело.

Второй вариант реализации — после подтверждения одним сервером, достижение перепроверяется другими удаленными серверами, в ходе синхронизации данных об игровом процессе. После этого достижение используется в качестве доказательства, при построении цепи блоков. При такой реализации пропадает необходимость нагружать приложения дополнительными задачами по ревизии достижений. На мой взгляд, это даже предпочтительнее, в том числе и для большинства пользователей, поскольку значительно снизит нагрузку на пк.

[rorrim]

Это не конструктивные замечания. Это оценочные суждения и почти хамство. Поучайте пожалуйста своих близких.

«Советую изучить сначала основы, как на самом деле работают основные консенсусы в блокчейне»  (по всей видимости Вы имели ввиду консенсусы proof of worke) - мы сейчас обсуждаем возможности реализации подтверждений достижений в игре (достижение консенсуса между приложениями), так?
Я Вам описал возможную схему реализации подобного проекта. В каждом приложении имеется своего рода оперативная память об игровом процессе, на основании анализа этих данных происходит ревизия достижения, перед его принятием в качестве доказательства блока. Разные приложения подключаются к разным игровым серверам (в соответствии с географией) и следовательно получают данные об обновлениях из разных источников, при этом данные должны совпадать.    

Не описали вы никакой возможной схемы. Это какие-то фантазии в вашей голове, фантазии очень далекие от технического воплощения. Начали вы с экономики на блокчейне, заканчиваете монстрами и их положением на блокчейне. Но и так тоже работать не будет. Я бы еще предположил возможную схему с генерацией некой "игровой" (в кавычках, потому что генерируемая игрой, но в игре не используется) валюты, которая используются для pos/dpos консенсуса, но и то у игры должна быть децентрализованная природа и особый гейм дизайн, не предполагающий рандом посредством выброса игральных костей.

[Vadim Valirov]

Вообще, самый простой вариант реализации концепции proof of game это обучающая игра. Тут нет необходимости в серверах. Игроки решают поставленные задачи. Правильный ответ заранее известен (его хеш уже в памяти приложения). Хеш ответа игрока должен соответствовать заявленному хешу. Чем сложнее коэффициент задачи, по отношению к уровню игрока (он повышается, с течением времени), тем больше вероятность принятия ответа этого участника, в качестве подтверждения цепи блоков. Чем больше человек решает сложных задач, тем быстрее растет его уровень в игре и соответственно, уменьшается вероятность получения вознаграждения (зачем награждать человека за получение знаний, которые у него и так есть?). С другой стороны, размер вознаграждения должен увеличиваться, в зависимости от роста уровня игрока. Это поможет избежать проблем с многократной регистрацией одних и тех же пользователей.
Основная проблема такой формы реализации — монетизация. По сути, это волонтерский, благотворительный проект. Остается возможность выпустить токены, для поощрения работы команды, перед запуском проекта.

Это не конструктивные замечания. Это оценочные суждения и почти хамство. Поучайте пожалуйста своих близких.

«Советую изучить сначала основы, как на самом деле работают основные консенсусы в блокчейне»  (по всей видимости Вы имели ввиду консенсусы proof of worke) - мы сейчас обсуждаем возможности реализации подтверждений достижений в игре (достижение консенсуса между приложениями), так?
Я Вам описал возможную схему реализации подобного проекта. В каждом приложении имеется своего рода оперативная память об игровом процессе, на основании анализа этих данных происходит ревизия достижения, перед его принятием в качестве доказательства блока. Разные приложения подключаются к разным игровым серверам (в соответствии с географией) и следовательно получают данные об обновлениях из разных источников, при этом данные должны совпадать.    

Не описали вы никакой возможной схемы. Это какие-то фантазии в вашей голове, фантазии очень далекие от технического воплощения. Начали вы с экономики на блокчейне, заканчиваете монстрами и их положением на блокчейне. Но и так тоже работать не будет. Я бы еще предположил возможную схему с генерацией некой "игровой" (в кавычках, потому что генерируемая игрой, но в игре не используется) валюты, которая используются для pos/dpos консенсуса, но и то у игры должна быть децентрализованная природа и особый гейм дизайн, не предполагающий рандом посредством выброса игральных костей.

Вы перевираете мои слова.
«Начали вы с экономики на блокчейне, заканчиваете монстрами и их положением на блокчейне» - я не говорил, что расположение монстров должно быть записано в блокчейн. В блокчейн заносятся только данные, имеющие имущественную ценность (данные о персонажах, как инструментах добычи криптовалюты, данные о транзакциях). Данные о состоянии игрового процеса храняться и обновляются в памяти приложения. На основании этих данных происходит ревизия достижения приложениями. Вот что я говорил.
Еще раз повторю, что мне более импонирует вариант с подтверждением достижения, на уровне серверов ("после подтверждения одним сервером, достижение перепроверяется другими удаленными серверами, в ходе синхронизации данных об игровом процессе"). Если по какой то причине один из серверов принимает недостоверное игровое достижение, для подтверждения блока, остальные сервера, на основе анализа данных об игровом процессе отклоняют его. Такой вариант реализации позволит снизить нагрузку на приложения.

[DannyLenny]

Суть концепции в том, что транзакции в сети соответствующей криптовалюты (назовем ее «gamescoin») подтверждаются программным обеспечением, встроенным в игровое приложение.
Попробую объяснить, на примере: представьте себе видео-игру (например «OpenMarioCoiner»), где вознаграждение генерируется в течении игрового процесса, а приложение, тем временем, занимается подтверждением транзакций в сети. Таким образом, единственными майнерами такой криптовалюты станут участники, получающие вознаграждение, за соответствующие игровые достижения
Кстати, есть вариант реализовать обучающую игру, типа: https://codecombat.com , только с получением вознаграждения в крипте, за достижения.
Ссылка на первоисточник публикации (16.01.18): https://golos.io/proof/@vvalirov/kratkoe-opisanie-koncepcii-podtverzhdeniya-tranzakcii-proof-of-game

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

мне кажется во многом это зависит от типа игры. Если сделать игру визуальной, либо комбинированной - решаешь загадку/смотришь на картинку и тп. Такая интерактивная капча получается. Мне кажется идея норм

[olafflirik]

Суть концепции в том, что транзакции в сети соответствующей криптовалюты (назовем ее «gamescoin») подтверждаются программным обеспечением, встроенным в игровое приложение.
Попробую объяснить, на примере: представьте себе видео-игру (например «OpenMarioCoiner»), где вознаграждение генерируется в течении игрового процесса, а приложение, тем временем, занимается подтверждением транзакций в сети. Таким образом, единственными майнерами такой криптовалюты станут участники, получающие вознаграждение, за соответствующие игровые достижения
Кстати, есть вариант реализовать обучающую игру, типа: https://codecombat.com , только с получением вознаграждения в крипте, за достижения.
Ссылка на первоисточник публикации (16.01.18): https://golos.io/proof/@vvalirov/kratkoe-opisanie-koncepcii-podtverzhdeniya-tranzakcii-proof-of-game

Не очень понятна суть этого подтверждения на более глубоком уровне. Как будут искаться SHA-250 коды для создания блока?

[sttret]

всю жизнь мечтал - играешь, а тебе за это BTCBTCBTC

так теюе нужно в проф геймеры идти. там они хорошо зарабатывают

[rorrim]

Вообще, самый простой вариант реализации концепции proof of game это обучающая игра. Тут нет необходимости в серверах. Игроки решают поставленные задачи. Правильный ответ заранее известен (его хеш уже в памяти приложения). Хеш ответа игрока должен соответствовать заявленному хешу. Чем сложнее коэффициент задачи, по отношению к уровню игрока (он повышается, с течением времени), тем больше вероятность принятия ответа этого участника, в качестве подтверждения цепи блоков. Чем больше человек решает сложных задач, тем быстрее растет его уровень в игре и соответственно, уменьшается вероятность получения вознаграждения (зачем награждать человека за получение знаний, которые у него и так есть?). С другой стороны, размер вознаграждения должен увеличиваться, в зависимости от роста уровня игрока. Это поможет избежать проблем с многократной регистрацией одних и тех же пользователей.
Основная проблема такой формы реализации — монетизация. По сути, это волонтерский, благотворительный проект. Остается возможность выпустить токены, для поощрения работы команды, перед запуском проекта.

facepalm

И что в такой концепции должно защищать цепочки от появления параллельной ветки? Единожды решенные задачи (их найденные хэши) будут повторно использоваться в параллельных ветках, их цена нулевая. И откуда взять так много уникальных задач? И что будет мешать взломать код децентрализованной игры и достать оттуда все ответы/хэши?

Может быть все-таки воспользуетесь моим советом и изучите как устроен блокчейн прежде чем будете писать?

[kohahan]

Тут надо смотреть в сторону постановки задач, сложно решаемых на компьютере и легко проверяемых, к сожалению для вас в этом направлении думают куда более компетентные люди и кстати у них это тоже не получается) даже POS концепцию, еще думаю как бы правильно реализовать. а тут у вас бац идея и решение... причем на словах..

[Vadim Valirov]

Суть концепции в том, что транзакции в сети соответствующей криптовалюты (назовем ее «gamescoin») подтверждаются программным обеспечением, встроенным в игровое приложение.
Попробую объяснить, на примере: представьте себе видео-игру (например «OpenMarioCoiner»), где вознаграждение генерируется в течении игрового процесса, а приложение, тем временем, занимается подтверждением транзакций в сети. Таким образом, единственными майнерами такой криптовалюты станут участники, получающие вознаграждение, за соответствующие игровые достижения
Кстати, есть вариант реализовать обучающую игру, типа: https://codecombat.com , только с получением вознаграждения в крипте, за достижения.
Ссылка на первоисточник публикации (16.01.18): https://golos.io/proof/@vvalirov/kratkoe-opisanie-koncepcii-podtverzhdeniya-tranzakcii-proof-of-game

Не очень понятна суть этого подтверждения на более глубоком уровне. Как будут искаться SHA-250 коды для создания блока?

При реализации игры иного типа, чем обучающая возникают проблемы с подтверждением достижений. По моему мнению, достижения игроков могут подтверждаться на основании анализа совокупности факторов игрового процесса. Чем больше факторов рассматривается, при проверке, тем надежнее система (это для on-line проекта).

facepalm

И что в такой концепции должно защищать цепочки от появления параллельной ветки? Единожды решенные задачи (их найденные хэши) будут повторно использоваться в параллельных ветках, их цена нулевая. И откуда взять так много уникальных задач? И что будет мешать взломать код децентрализованной игры и достать оттуда все ответы/хэши?

Может быть все-таки воспользуетесь моим советом и изучите как устроен блокчейн прежде чем будете писать?

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

Тут надо смотреть в сторону постановки задач, сложно решаемых на компьютере и легко проверяемых, к сожалению для вас в этом направлении думают куда более компетентные люди и кстати у них это тоже не получается) даже POS концепцию, еще думаю как бы правильно реализовать. а тут у вас бац идея и решение... причем на словах..

"Тут надо смотреть в сторону постановки задач, сложно решаемых на компьютере и легко проверяемых" - объясните, пожалуйста, подробнее, что Вы имеете ввиду?

Тут надо смотреть в сторону постановки задач, сложно решаемых на компьютере и легко проверяемых, к сожалению для вас в этом направлении думают куда более компетентные люди и кстати у них это тоже не получается) даже POS концепцию, еще думаю как бы правильно реализовать. а тут у вас бац идея и решение... причем на словах..

После победы над монстром приложение получает задачу для решения (по нахождению хеша), согласно алгоритму: чем сильнее был монстр, по отношению к уровню игрока, тем проще задача встает, для приложения. Следовательно, больше шансов, что достижение данного игрока будет использовано, для записи в блок, после проведения процедуры консенсуса. Что думаете?

[rorrim]

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

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

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

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

После победы над монстром приложение получает задачу для решения (по нахождению хеша), согласно алгоритму: чем сильнее был монстр, по отношению к уровню игрока, тем проще задача встает, для приложения. Следовательно, больше шансов, что достижение данного игрока будет использовано, для записи в блок, после проведения процедуры консенсуса. Что думаете?

Хэш это просто число, результат математической функции. Просто число никак не может защитить транзакции в блоки. Просто число никак не может защитить последовательность блоков. Хэши в PoW не просто числа, это грубо говоря сумма строк транзакций, ее трудно вычислить, но имея, легко убедиться что транзакции корректны. Нельзя просто "от балды" взять какие-то хэши/числа и что-то там защить, оно так не работает.

[Vadim Valirov]

После победы над монстром приложение получает задачу для решения (по нахождению хеша), согласно алгоритму: чем сильнее был монстр, по отношению к уровню игрока, тем проще задача встает, для приложения. Следовательно, больше шансов, что достижение данного игрока будет использовано, для записи в блок, после проведения процедуры консенсуса. Что думаете?

Хэш это просто число, результат математической функции. Просто число никак не может защитить транзакции в блоки. Просто число никак не может защитить последовательность блоков. Хэши в PoW не просто числа, это грубо говоря сумма строк транзакций, ее трудно вычислить, но имея, легко убедиться что транзакции корректны. Нельзя просто "от балды" взять какие-то хэши/числа и что-то там защить, оно так не работает.

Я говорю об алгоритме принятия решения, какое из достижений принять, в качестве доказательства, при построении цепи блоков. За какое из достижений назначить вознаграждение. Хотя, возможно процесс подбора хеша тут действительно излишен, достаточно просто сравнить коэффициенты достижений (по признаку монстр/игрок).

[Blockchaincat]

Я говорю об алгоритме принятия решения, какое из достижений принять, в качестве доказательства, при построении цепи блоков. За какое из достижений назначить вознаграждение. Хотя, возможно процесс подбора хеша тут действительно излишен, достаточно просто сравнить коэффициенты достижений (по признаку монстр/игрок).

по моему понижение точности нахождения хэша по рейтингу норм идея. Но получается что надо параллельно и майнить и рейтинг повышать. Сложновато

[Vadim Valirov]

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

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

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

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

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

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

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

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

Почему «как метод консенсуса тогда работать не будет»?

Потому что это де факто централизованная система.

Я вижу вариант с нечетным количеством независимых серверов, которые приходят к консенсусу по поводу принятия оптимального достижения игрока, к подтверждению блока на основании анализа факторов игрового процесса (данные должны совпадать, решение принимается простым большинством). Так что даже в случае с игрой, где сервера отвечают за игровой процесс, реализацию вряд-ли можно назвать централизованной.

для подтверждения достижений (к примеру: выигранные игровые раунды), можно использовать подобный сервис: https://playbets.io/

[Ivan_777]

Суть концепции в том, что транзакции в сети соответствующей криптовалюты (назовем ее «gamescoin») подтверждаются программным обеспечением, встроенным в игровое приложение.
Попробую объяснить, на примере: представьте себе видео-игру (например «OpenMarioCoiner»), где вознаграждение генерируется в течении игрового процесса, а приложение, тем временем, занимается подтверждением транзакций в сети. Таким образом, единственными майнерами такой криптовалюты станут участники, получающие вознаграждение, за соответствующие игровые достижения
Кстати, есть вариант реализовать обучающую игру, типа: https://codecombat.com , только с получением вознаграждения в крипте, за достижения.
Ссылка на первоисточник публикации (16.01.18): https://golos.io/proof/@vvalirov/kratkoe-opisanie-koncepcii-podtverzhdeniya-tranzakcii-proof-of-game

Навряд ли выйдет что-то путное из этого, разве, что кому-то по приколу. Все равно выгоднее отдельно майнить, а отдельно играть. Ну, а если и будут нгачислять какую-нибудь крипту, то её и постараются у тебя увести на премиум аккаунт или премиум снаряжение.

[Oygen]

А что, идея в общем неплохая - сделать игрушку попроще в стиле IO - со встроенным майнером - и пусть люди гоняют. Например продержался ХХ минут - заработал ХХ монет. Будет дополнительный стимул расти в рейтингах))

[Ognik33]

Как геймер, официально заявляю, что это офигенная идея! Наконец-то люди обратили внимание на огромнейшую, платежеспособную и любящую игры аудиторию!

[olgahappy]

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