Буду рад со всеми познакомиться в личке!
Мое интро:
Большой опыт в управлении проектами (Founder&Product manager), а так же BizDev. Работал как в крупных компаниях, так и занимался своими стартапами в качестве Founder или CEO. Так же являюсь криптоэнтузиастом, очень увлекаюсь AI.
Сейчас с командой RocketTech строим supply value chain по миру с упором на tech startups.
За 2 года мы разработали и запустили более 115 проектов, которые зарейзили 100млн$+ инвестиций.
Наша фишка - это 10 технологических фичей в месяц, разработка MVP за 2 недели и гарантированный PMF - 6 мес.
Наш фокус - это фаундеры и корпорации в любой нише рынка.
Где-то работаем как интегратор, где-то как операционные директора, где-то как ангелы, где-то как технологические партнеры
если совсем просто. Все подобные игры делят на два шага. Шаг принятия ответов и шаг их раскрытия/проверки. Смотреть принятые вопросы на первом шагу не обязательно, да и может произойти утечка. Это основное свойство того что данные видел кто-то кроме тебя. Шаг раскрытия может быть публичным потому что проблема не в том, что твои данные раскроют, а в том что они могут повлиять на других участников/самую игру. Когда все ответы уже сданы их массовое раскрытие, как и порядок раскрытия ни на что уже не влияет
Читать полностью…Меня аж испугала такая сложность. Будь аккуратнее в следующий раз.
А в целом для решения задачи нужно понять цели. Потому что хранить данные это одно, не мочь их изменить это другое. Если хранить то в каком виде. Операции над зашифрованными данными так же предполагают необходимость их шифровать заранее.
Хотя, в общем-то, это больше для проведение математических операций с зашифрованными данными, а тут как бы информация от оппонента не должна быть уже закрытой, и можно и обычным шифрованием (но ключ не должен попадать в блокчейн, можно всё доказать и хешами, раскрыв потом исходные данные). А если количество участников больше 2 и для каждого следующего надо скрывать данные предыдущих, но делать с этими данными операции, то да, гомоморфизм привет.
Читать полностью…Пользователь не может использовать для боя больше юнитов, чем у него есть - это валидирует смарт-контракт. Но если кол-во юнитов будет зашифровано, то смарт-контракт не может валидировать это, только в момент боя. А в момент боя данные могут оказаться невалидными, потому что юзер решил обмануть фронт.
Читать полностью…Самое грустное в этом всем, что я уже заканчиваю разработку контрактов и бэка, а тут на тебе, еще на месяц работы)
Читать полностью…В общем возвращаемся к проблеме, что нужен оракл который дает открытый ключ и затем пушит закрытый через n блоков (как prng в чейнлинке)
Читать полностью…В общем вопрос, там есть игровой сервер и готовы лы и вы делать игру так, что она не будет работать без него? (то есть сервер может не подписывать действие каких-то игроков, цензурировать)
Читать полностью…Можно воспользоваться хитростью модулярности. Например, ты знаешь, что значения не превышает какого-то числа (пусть это будет 1.000.000, а может быть и 2^128, назовём его L), тогда можно выбрать произвольное число в диапазоне от 1 (а лучше от числа побольше) до round_down(2^256 / L), умножить на это L и прибавить к нему загаданное число. Остаток от деления такого числа на L и будет твоё значение (например, значения от 0 до 9, тогда L=10, а загаданное число, например 7, может быть 17, 27, 37, ..., 100007 и т. д., и остаток от деления на 10 будет давать всегда 7, но вариантов очень много, и перебор уже не сработает — точнее, сильно усложняет вычисление устремляя время в сторону бесконечности).
Читать полностью…подмена изначального ответа решается так же. Если ответ даёт код только исходя из ответов игроков, то ты уже не можешь его подменить. То, что алгоритм вычисления открыт так же не влияет ни на что. Если алгоритм вычисления является секретом, то ты не можешь его использовать, но вопрос решается так же конвертом. Каждый пользователь его знает. Блокчейн здесь просто третья сторона, которая не даёт тебе подменить этот конверт. Это та проблема, которую он решает. Такую проблему в реальном мире решают всякие урны и прочие механизмы, которые позволяют что-то положить, но не забрать без явного повреждения. При этом забрать что-то ничто не помешает как.
Если вернуться к закрытому алгоритму, то там есть проблема в том, что закрывать тебе нужно потому что из него можно получить ответ. Но ты так же можешь получить ответ. Этот вопрос решается уже отдельно
блокчейн гарантирует открытость данных/вычислений. Подменить нельзя ничего. Безопасно/не безопасно этот вопрос относится к твоей реализации. Не буду обсуждать то, что люди пытаются что-то делать не понимая элементарных примитивов с которыми работают.
У тебя по условию задачи есть две стороны, данные закрыты. Тебе ненужно знать их числа - тебе нужно не дать их подменить и возможность открыть их. В мире существуют тысячи механизмов решения этого. Пишешь на листочке заранее. Тогда ответы других людей не позволят тебе использовать их. Аналогично с закрытыми конвертами. Тут уже есть ответ на твой первый вопрос - никому ненужно знать знать что ты там написал. Как и то записал ли ты вообще что-либо. Важно то, что этот конверт твой. А если ты вместо ответа намялякал каракули, то проблема твоя. Испорченный ответ == неправильный ответ
Все подобные подходы отражены в примитивах криптографии. Поэтому важно понимать что делаешь, а если не понимать, то всегда можно обратиться к тем кто эти проблемы решает уже тысячи лет и без всяких блокчейнов.
Если смарт-контракт может от действия второго пользователя (для которого информация закрыта) узнать то, что зашифровано, то, в целом, это и не зашифровано (ты же можешь всегда сделать eth_call и посмотреть [просимулировать] как оно будет себя вести). Если усложнить цепочку: инициатор-оппонент-инициатор (на последнем этапе подтверждается принятый вызов и раскрывается изначально зашифрованная информация), то это +1 вызов и возможность не завершить бой (хотя за это можно наказывать). В этом случае можно использовать что-то типа криптосистемы Пэйе (Pallier), кури в сторону гомоморфных операций.
Читать полностью…Написал в соседнем чате, тут тоже скину на всякий, вдруг кто что подскажет)):
Попытаюсь упрощенно описать:
Первый игрок имеет 100 юнитов (войско). Эта инфа открыта.
Второй игрок имеет 50 юнитов. Эта инфа тоже открыта.
Первый игрок вызывает на бой второго и выделяет часть юнитов для предстоящего боя. Второй игрок может спрятать своих юнитов, если не хочет участвовать с бое.
Нужно спрятать информацию о кол-ве выделенных первым игроком юнитов для боя. А в момент боя раскрыть эту информацию, что бы смарт-контракт провел бой и получил результаты.
Бэк планировал использовать только как кеширующий сервер, что бы некоторые данные отдавать с бэка.
Читать полностью…