Topic: proof of game - page 2. (Read 707 times)

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

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

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

facepalm

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

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

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


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



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

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

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

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

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

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


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

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

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

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

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

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

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

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

Время генерации блока можно уменьшить (например, до 10 секунд), вместе с размером самого блока (но не пропорционально, а в сторону увеличения размера блока ко времени его генерации). Быстрые транзакции + % вероятности равномерного перераспределения вознаграждения между игроками вырастет. Надежность цепи от этого только повысится. Это нужно рассчитывать.

ОК, конкретнее: множество узлов формируют блоки, какой из них пойдет в цепочку? Если proof of game это консенсус, тогда в цепочку пойдет тот блок, какой скажет игровой сервер. Т.е. метод принятия решения исключительно централизованный, в таком случае вся цепочка блоков просто фикция.

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


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