Search content
Sort by
Showing 20 of 50 results by Vadim Valirov
Кстати данная монета очень хорошо держится в отличии от общего рынка и как то не привязан не к битку не к эфиру. Очень хороший показатель я считаю
В условиях ограниченной эмиссии можно ожидать роста курса токена с текущих ценовых уровней.
Очень крутая идея! Сам мечтал о почти таком же.. Было бы круто написать игру наподобие wacraft 3 online или в крайнем случае MMORPG.
И придумать новый алгоритм который будет начислять токены всем кто майнит(убивает крипов или проходит квесты) и (игру можно сделать платной, а кошелёк бесплатным, но чтобы начать майнить необходимо купить игру)
1. Создадим лимит токенов например: 100 000 000 000 и распределим. Например: 10 % Bounty Company, 20% На развитие проекта и дополнительные баунти и 70% Отдать игровому миру(за квесты, дроп и тд)
2. Создадим систему налогов и штрафов+ шопы в локациях+ ауционы и многое из обычные mmorpg ( система должна быть построена так, чтобы монеты закончились очень не скоро или не когда... В противном случае придётся делать хардфорки и увеличивать общее количество монет. Поэтому об этом нужно задуматься заранее .
3. Напишем игру с встроенным кошельком и отдельный кошелёк для бирж и тех кто не хочет играть(майнить)
4. Проведём кучу тестов..запустим много бето-версий, а потом уже можно запускать bounty и ICO и дорабатывать монетку.. Главное, чтобы проект заранее заинтриговал геймеров и криптовалютных магнатов) Тогда создатель такой игры станет миллионером..
И придумать новый алгоритм который будет начислять токены всем кто майнит(убивает крипов или проходит квесты) и (игру можно сделать платной, а кошелёк бесплатным, но чтобы начать майнить необходимо купить игру)
1. Создадим лимит токенов например: 100 000 000 000 и распределим. Например: 10 % Bounty Company, 20% На развитие проекта и дополнительные баунти и 70% Отдать игровому миру(за квесты, дроп и тд)
2. Создадим систему налогов и штрафов+ шопы в локациях+ ауционы и многое из обычные mmorpg ( система должна быть построена так, чтобы монеты закончились очень не скоро или не когда... В противном случае придётся делать хардфорки и увеличивать общее количество монет. Поэтому об этом нужно задуматься заранее .
3. Напишем игру с встроенным кошельком и отдельный кошелёк для бирж и тех кто не хочет играть(майнить)
4. Проведём кучу тестов..запустим много бето-версий, а потом уже можно запускать bounty и ICO и дорабатывать монетку.. Главное, чтобы проект заранее заинтриговал геймеров и криптовалютных магнатов) Тогда создатель такой игры станет миллионером..
Рад, то Вы оценили идею. Хочу попросить Вас и всех остальных, перевести мне 1 merit, в знак одобрения. Заранее благодарю
What is your Fiscal Policy? Instamines, premines, buying, spending, icing, discounting, and/or burning any tokens? What is your Monetary Policy? Inflationary? Deflationary? Fixed supply forever or additional tokens to be issued?
very good questions для подтверждения достижений (к примеру: выигранные игровые раунды), можно использовать подобный сервис: https://playbets.io/
Почему «как метод консенсуса тогда работать не будет»?
Потому что это де факто централизованная система.
Я вижу вариант с нечетным количеством независимых серверов, которые приходят к консенсусу по поводу принятия оптимального достижения игрока, к подтверждению блока на основании анализа факторов игрового процесса (данные должны совпадать, решение принимается простым большинством). Так что даже в случае с игрой, где сервера отвечают за игровой процесс, реализацию вряд-ли можно назвать централизованной.
"И что в такой концепции должно защищать цепочки от появления параллельной ветки?" - сами приложения, конечно. Если кто либо и взломает одно приложение, то остальные не будут подтверждать блоки в появившейся ветке. С другой стороны, форк возможен практически в любом блокчейне. А что защищает сегодняшние криптовалюты, от появления новых веток (ничего, кроме консенсуса майнеров)?
Единожды решенные задачи (их найденные хэши) будут повторно использоваться в параллельных ветках, их цена нулевая - в памяти приложений есть набор задач, они не уникальны. Каждое приложение (участник) имеет возможность единожды решить (или не решить) одну и ту же задачу (задачи предоставляются, в псевдослучайном порядке) и получить за нее токены (в случае, если его достижение приняли, для подтверждения цепи).
И что будет мешать взломать код децентрализованной игры и достать оттуда все ответы/хэши?" - взломать можно все (это только вопрос возможностей). Ну и что с того, что игрок получит базу с хешем ответов? Всегда есть возможность зашифровать зависимость вопрос/ответ. Пусть даже участник взломал базу и получил набор хешей? Как определить, какой хеш является ответов к вопросу? Единожды ошибившись, при подборе, участник теряет возможность получить вознаграждение, за эту задачу.
1. Причем здесь форк? Изучайте как устроен блокчейн и найдете ответ на свой вопрос- в зависимости от консенсуса, механизмы отличаются. Самый простой для объяснения механизм без всяких подводных камней в PoW консенсусе - хэш нового блока считается исходя из перечисленных в нем транзакций + хэша предыдущего блока, таким образом чтобы сделать параллельную ветку, нужно пересчитать хэши прошлых блоков и чем длиннее цепочка для замены, тем более трудоемко это сделать. В PoS/DPoS используется залог и много разных трюков. Но вы же не хотите разбираться, проще как попугай повторять одну и ту же ахинею.
2. Нет никакой памяти приложений!!! это распределенная сеть и блок может возникнуть в любом месте!!! и никто не знает какой блок раньше и какой позже, консенсус как раз и нужен для того чтобы эти блоки собрать в хронологическом порядке и исключить "неправильные"!!!
3. Участник взломал игру => получил таблицу вопрос=хэш => генерирует блоки без игры. Когда код доступен, обязательно декомпилируют, тут все способы защиты только от детей. И зашифровать не получится, т.к. ключ для дешифровки все равно внутри приложения будет.
1. Вы неточно сформулировали вопрос, я неверно Вас понял. Ответ на Ваш вопрос: Всегда есть возможность исключить появление веток "с нуля". Например, при генерации нового адреса кошелька, система автоматически списывает минимальную сумму (аналог 1 сатоши) со счета специально созданного кошелька-фонда (с этого кошелька начинается вся цепь блоков, это корень цепи. Баланс этого кошелька-фонда пополняется, за счет % от комиссионных, за транзакции). и переводит эту сумму на счет адреса нового кошелька. Таким образом, мы имеем первую входящую транзакцию. Эта ветка волшебным образом превращается в продолжение хеша, с корня цепи (с адреса фонда). То есть, злоумышленнику придется переписать всю цепь, с самого начала. А это уже вилка.
Условия: Транзакции, используемые, для привязки новой ветки (адреса) должны быть бескомиссионными и иметь высочайший приоритет. Без первой входящей транзакции генерация адреса не завершена, сама транзакция входит в хеш адреса
А. В одном кошельке не может быть больше, чем N адресов (иначе будут злоупотребления раздачей).
В. Минимальные входящие транзакции, для привязки ветки, должны быть бескомиссионными и иметь высочайший приоритет.
2. Я Вам пытался описать свое видение технической реализации, соглашусь оно несовершенно и требует доработки. Я рассматриваю все возможные механизмы реализации,для решения возникающих задач.
3. Как один из вариантов, ключ может храниться в памяти стороннего приложения (скорее нескольких случайных приложений), хеш кода для определения зависимости: «вопрос/ответ» передается по запросу, и не чаще чем раз в 5-10 мин (хеш/ключ для каждой зависимости, у каждого приложения уникален).
После победы над монстром приложение получает задачу для решения (по нахождению хеша), согласно алгоритму: чем сильнее был монстр, по отношению к уровню игрока, тем проще задача встает, для приложения. Следовательно, больше шансов, что достижение данного игрока будет использовано, для записи в блок, после проведения процедуры консенсуса. Что думаете?
Хэш это просто число, результат математической функции. Просто число никак не может защитить транзакции в блоки. Просто число никак не может защитить последовательность блоков. Хэши в PoW не просто числа, это грубо говоря сумма строк транзакций, ее трудно вычислить, но имея, легко убедиться что транзакции корректны. Нельзя просто "от балды" взять какие-то хэши/числа и что-то там защить, оно так не работает.
Я говорю об алгоритме принятия решения, какое из достижений принять, в качестве доказательства, при построении цепи блоков. За какое из достижений назначить вознаграждение. Хотя, возможно процесс подбора хеша тут действительно излишен, достаточно просто сравнить коэффициенты достижений (по признаку монстр/игрок).
Тут надо смотреть в сторону постановки задач, сложно решаемых на компьютере и легко проверяемых, к сожалению для вас в этом направлении думают куда более компетентные люди и кстати у них это тоже не получается) даже POS концепцию, еще думаю как бы правильно реализовать. а тут у вас бац идея и решение... причем на словах..
После победы над монстром приложение получает задачу для решения (по нахождению хеша), согласно алгоритму: чем сильнее был монстр, по отношению к уровню игрока, тем проще задача встает, для приложения. Следовательно, больше шансов, что достижение данного игрока будет использовано, для записи в блок, после проведения процедуры консенсуса. Что думаете?
Тут надо смотреть в сторону постановки задач, сложно решаемых на компьютере и легко проверяемых, к сожалению для вас в этом направлении думают куда более компетентные люди и кстати у них это тоже не получается) даже POS концепцию, еще думаю как бы правильно реализовать. а тут у вас бац идея и решение... причем на словах..
"Тут надо смотреть в сторону постановки задач, сложно решаемых на компьютере и легко проверяемых" - объясните, пожалуйста, подробнее, что Вы имеете ввиду?
Вообще, самый простой вариант реализации концепции proof of game это обучающая игра. Тут нет необходимости в серверах. Игроки решают поставленные задачи. Правильный ответ заранее известен (его хеш уже в памяти приложения). Хеш ответа игрока должен соответствовать заявленному хешу. Чем сложнее коэффициент задачи, по отношению к уровню игрока (он повышается, с течением времени), тем больше вероятность принятия ответа этого участника, в качестве подтверждения цепи блоков. Чем больше человек решает сложных задач, тем быстрее растет его уровень в игре и соответственно, уменьшается вероятность получения вознаграждения (зачем награждать человека за получение знаний, которые у него и так есть?). С другой стороны, размер вознаграждения должен увеличиваться, в зависимости от роста уровня игрока. Это поможет избежать проблем с многократной регистрацией одних и тех же пользователей.
Основная проблема такой формы реализации монетизация. По сути, это волонтерский, благотворительный проект. Остается возможность выпустить токены, для поощрения работы команды, перед запуском проекта.
Основная проблема такой формы реализации монетизация. По сути, это волонтерский, благотворительный проект. Остается возможность выпустить токены, для поощрения работы команды, перед запуском проекта.
facepalm
И что в такой концепции должно защищать цепочки от появления параллельной ветки? Единожды решенные задачи (их найденные хэши) будут повторно использоваться в параллельных ветках, их цена нулевая. И откуда взять так много уникальных задач? И что будет мешать взломать код децентрализованной игры и достать оттуда все ответы/хэши?
Может быть все-таки воспользуетесь моим советом и изучите как устроен блокчейн прежде чем будете писать?
"И что в такой концепции должно защищать цепочки от появления параллельной ветки?" - сами приложения, конечно. Если кто либо и взломает одно приложение, то остальные не будут подтверждать блоки в появившейся ветке. С другой стороны, форк возможен практически в любом блокчейне. А что защищает сегодняшние криптовалюты, от появления новых веток (ничего, кроме консенсуса майнеров)?
Единожды решенные задачи (их найденные хэши) будут повторно использоваться в параллельных ветках, их цена нулевая - в памяти приложений есть набор задач, они не уникальны. Каждое приложение (участник) имеет возможность единожды решить (или не решить) одну и ту же задачу (задачи предоставляются, в псевдослучайном порядке) и получить за нее токены (в случае, если его достижение приняли, для подтверждения цепи).
И что будет мешать взломать код децентрализованной игры и достать оттуда все ответы/хэши?" - взломать можно все (это только вопрос возможностей). Ну и что с того, что игрок получит базу с хешем ответов? Всегда есть возможность зашифровать зависимость вопрос/ответ. Пусть даже участник взломал базу и получил набор хешей? Как определить, какой хеш является ответов к вопросу? Единожды ошибившись, при подборе, участник теряет возможность получить вознаграждение, за эту задачу.
Суть концепции в том, что транзакции в сети соответствующей криптовалюты (назовем ее «gamescoin») подтверждаются программным обеспечением, встроенным в игровое приложение.
Попробую объяснить, на примере: представьте себе видео-игру (например «OpenMarioCoiner»), где вознаграждение генерируется в течении игрового процесса, а приложение, тем временем, занимается подтверждением транзакций в сети. Таким образом, единственными майнерами такой криптовалюты станут участники, получающие вознаграждение, за соответствующие игровые достижения
Кстати, есть вариант реализовать обучающую игру, типа: https://codecombat.com , только с получением вознаграждения в крипте, за достижения.
Ссылка на первоисточник публикации (16.01.18): https://golos.io/proof/@vvalirov/kratkoe-opisanie-koncepcii-podtverzhdeniya-tranzakcii-proof-of-game
Не очень понятна суть этого подтверждения на более глубоком уровне. Как будут искаться SHA-250 коды для создания блока?Попробую объяснить, на примере: представьте себе видео-игру (например «OpenMarioCoiner»), где вознаграждение генерируется в течении игрового процесса, а приложение, тем временем, занимается подтверждением транзакций в сети. Таким образом, единственными майнерами такой криптовалюты станут участники, получающие вознаграждение, за соответствующие игровые достижения
Кстати, есть вариант реализовать обучающую игру, типа: https://codecombat.com , только с получением вознаграждения в крипте, за достижения.
Ссылка на первоисточник публикации (16.01.18): https://golos.io/proof/@vvalirov/kratkoe-opisanie-koncepcii-podtverzhdeniya-tranzakcii-proof-of-game
При реализации игры иного типа, чем обучающая возникают проблемы с подтверждением достижений. По моему мнению, достижения игроков могут подтверждаться на основании анализа совокупности факторов игрового процесса. Чем больше факторов рассматривается, при проверке, тем надежнее система (это для on-line проекта).
The simplest path to realize the "proof of game" concept is to make a learning game. There is no need of servers. Gamers just solve the tasks. The correct answer is already known in advance (its hash is in the application' memory). The hash of the gamer's response must match the declared hash. The more difficult becomes the task in relation to the gamer's level (it increases with time), the greater becomes the probability of accepting the response of this participant as a confirmation in blockchain system. The more difficult tasks gamer solves, the faster his level grows, and accordingly decreases the probability of getting a reward (why is needed to reward a person for gaining knowledge that he already has?). On the other hand, the size of the reward should increase depending of the gamer's level. This will help to avoid problems with multiple registrations of the same users.
Это не конструктивные замечания. Это оценочные суждения и почти хамство. Поучайте пожалуйста своих близких.
«Советую изучить сначала основы, как на самом деле работают основные консенсусы в блокчейне» (по всей видимости Вы имели ввиду консенсусы proof of worke) - мы сейчас обсуждаем возможности реализации подтверждений достижений в игре (достижение консенсуса между приложениями), так?
Я Вам описал возможную схему реализации подобного проекта. В каждом приложении имеется своего рода оперативная память об игровом процессе, на основании анализа этих данных происходит ревизия достижения, перед его принятием в качестве доказательства блока. Разные приложения подключаются к разным игровым серверам (в соответствии с географией) и следовательно получают данные об обновлениях из разных источников, при этом данные должны совпадать.
«Советую изучить сначала основы, как на самом деле работают основные консенсусы в блокчейне» (по всей видимости Вы имели ввиду консенсусы proof of worke) - мы сейчас обсуждаем возможности реализации подтверждений достижений в игре (достижение консенсуса между приложениями), так?
Я Вам описал возможную схему реализации подобного проекта. В каждом приложении имеется своего рода оперативная память об игровом процессе, на основании анализа этих данных происходит ревизия достижения, перед его принятием в качестве доказательства блока. Разные приложения подключаются к разным игровым серверам (в соответствии с географией) и следовательно получают данные об обновлениях из разных источников, при этом данные должны совпадать.
Не описали вы никакой возможной схемы. Это какие-то фантазии в вашей голове, фантазии очень далекие от технического воплощения. Начали вы с экономики на блокчейне, заканчиваете монстрами и их положением на блокчейне. Но и так тоже работать не будет. Я бы еще предположил возможную схему с генерацией некой "игровой" (в кавычках, потому что генерируемая игрой, но в игре не используется) валюты, которая используются для pos/dpos консенсуса, но и то у игры должна быть децентрализованная природа и особый гейм дизайн, не предполагающий рандом посредством выброса игральных костей.
Вы перевираете мои слова.
«Начали вы с экономики на блокчейне, заканчиваете монстрами и их положением на блокчейне» - я не говорил, что расположение монстров должно быть записано в блокчейн. В блокчейн заносятся только данные, имеющие имущественную ценность (данные о персонажах, как инструментах добычи криптовалюты, данные о транзакциях). Данные о состоянии игрового процеса храняться и обновляются в памяти приложения. На основании этих данных происходит ревизия достижения приложениями. Вот что я говорил.
Еще раз повторю, что мне более импонирует вариант с подтверждением достижения, на уровне серверов ("после подтверждения одним сервером, достижение перепроверяется другими удаленными серверами, в ходе синхронизации данных об игровом процессе"). Если по какой то причине один из серверов принимает недостоверное игровое достижение, для подтверждения блока, остальные сервера, на основе анализа данных об игровом процессе отклоняют его. Такой вариант реализации позволит снизить нагрузку на приложения.
Вообще, самый простой вариант реализации концепции proof of game это обучающая игра. Тут нет необходимости в серверах. Игроки решают поставленные задачи. Правильный ответ заранее известен (его хеш уже в памяти приложения). Хеш ответа игрока должен соответствовать заявленному хешу. Чем сложнее коэффициент задачи, по отношению к уровню игрока (он повышается, с течением времени), тем больше вероятность принятия ответа этого участника, в качестве подтверждения цепи блоков. Чем больше человек решает сложных задач, тем быстрее растет его уровень в игре и соответственно, уменьшается вероятность получения вознаграждения (зачем награждать человека за получение знаний, которые у него и так есть?). С другой стороны, размер вознаграждения должен увеличиваться, в зависимости от роста уровня игрока. Это поможет избежать проблем с многократной регистрацией одних и тех же пользователей.
Основная проблема такой формы реализации монетизация. По сути, это волонтерский, благотворительный проект. Остается возможность выпустить токены, для поощрения работы команды, перед запуском проекта.
Основная проблема такой формы реализации монетизация. По сути, это волонтерский, благотворительный проект. Остается возможность выпустить токены, для поощрения работы команды, перед запуском проекта.
Вопрос реализации, это верно. Децентрализованной должна быть область данных, содержащая в себе достижения игроков (цепь блоков) и транзакции, включенные в блоки. Сама игра не обязательно должна быть децентрализованной - достаточно подключения к нескольким on-line серверам. Таким образом, игровой процесс остается под централизованным управлением, а ресурсная экономика проекта - децентрализована. Как вариант.
Как метод консенсуса тогда работать не будет. Или нужно говорить о приватном блокчейне, где блоки формируют только собственные ноды-игровые сервера. Начисление монеток за ачивки игроков это уже совсем другое дело.
Второй вариант реализации после подтверждения одним сервером, достижение перепроверяется другими удаленными серверами, в ходе синхронизации данных об игровом процессе. После этого достижение используется в качестве доказательства, при построении цепи блоков. При такой реализации пропадает необходимость нагружать приложения дополнительными задачами по ревизии достижений. На мой взгляд, это даже предпочтительнее, в том числе и для большинства пользователей, поскольку значительно снизит нагрузку на пк.