А делать надо достаточно сложное...
Если по группировке недобор по выигрышному исходу (то есть в группировке на сыгравший исход проставлено меньше, чем в пуле), то это плохо и клиенту, поставившему на группировку надо платить меньше.
Если же в группировке перебор по выигрышному исходу, то это хорошо и клиенту надо выплатить больше.
Как считать эти самые больше и меньше не совсем понятно, но идея видимо такая должна быть. Опять же, в "обычном" рынке, мало-мальски активном и неманипулируемом, разница по выплатам будет минимальной... Да хотя бы даже и мнимальная, почему бы не откорректировать, если поставить какой-то порог терпимости к отклонениям, то злоумышленник может долбить, чтобы в это отклонение попадать, это не выход.
Тут ещё большая проблема...
Если не брать простые рынки, типа аутрайтов (просто список исходов, один из них победит) и best-of (конечное число возможных вариантов) и думать о футболах/баскетболах, то возникает большая проблема в количестве данных.
Тот же футбол нужно построить матрицу... ну хотя бы 25-30 элементов... Да, ещё будет элемент "неуказанный счёт", ну это ладно, это не страшно.
Страшно то, что при ставке на группировку "больше 0.5" нам нужно разбить ставку между всеми исходами. кроме одного "0-0". Это значит, что нужно обновить данные в десятках, а для больших матриц в сотнях ячеек.
Это стоит дорого, это стоит газ, это БУДЕТ стоить дешевле, но сейчас это тупо дорого. Сейчас поэкспериментировал с "плотными" структурами, никакого толка не оказалось, solidity достаточно жёстко привязан к базовым 32байтовым структурам. То есть деваться некуда, надо платить.
То есть наша матрица плюс-минус жёстко ограничена размером в 100 элементов. Этого более чем достаточно для футбола, в принципе достаточно для хоккея, наверное достаточно для бейсбола...
Но в пролёте оказывается баскетбол, в пролёте оказывается ставки на количество убийств в доте, в пролёте любые матчи, где средняя результативность команды больше 15 очков...
И я просто не вижу сейчас способов решить эту проблему. Чтобы оперировать большими (100+ исходов) матрицами, нужно эти 100 плюс исходов инициализировать и обновлять. Инициализация 20 000 газа за одну ячейку, обновление 5 тысяч. И никуда ты не денешься. Ладно, при создании матча не жалко, пусть платят, там даже по текущим ценам это будет стоить 5-10 долларов максимум... А вот накладные расходы при ставке в 1-2 доллара.. как-то неправильно, дорого. Ладно, допустим, что это не проблема. эфир2 поможет сделать транзакции дешевле.
Но это расходы для матрицы на 100 исходов, а что будет для баскетбола, где по-хорошему нужна 1000, если не придумывать группировки? Значит ли это, что мы не можем создавать матрицы для большого разброса счетов? А что можем?
В общем надо подумать... Я сильно надеялся, что упаковка данных может как-то помочь, но нет, не помогает. Если тебе надо сохранить 100 значений - тебе надо заплатить за 100 uint256 значений, изворачиваться с упаковками бесполезно, так как ОБНОВЛЕНИЕ, а это самое главное, стоит столько же или БОЛЬШЕ.
Значит извращаться не будем, храним распределение в uint256, это сильно упрощает код, но что же делать с матрицами...
Пользователь @dimok написал в Тотализатор, в виде букмекерской конторы:
Да, ещё будет элемент "неуказанный счёт", ну это ладно, это не страшно.
С неуказанным счетом, криво будет с форами и тоталами.
Если использовать такой подход
Ленивые игроки ставят на П1 и говорят: "разбросайте мои деньги на выигрышные исходы в точном счеты, чтобы выплата при любом выигрышном исходе была одинаковой".
То в матрицу писать ничего и не надо.
Принимать на руки ничего не надо.
Пользователь @triplea написал в Тотализатор, в виде букмекерской конторы:
С неуказанным счетом, криво будет с форами и тоталами.
Нет не будет, просто немножечко от форы/тотала добавляем на "любой другой". И выплачиваем, соответственно, если поставил ТМ 2.5 - ничего не выплачиваем, если поставил тб 2.5 - немножко выплачиваем.
Если использовать такой подход
То ликвидность от п1 не будет влиять на тоталы, а это недопустимо.
Пользователь @dimok написал в Тотализатор, в виде букмекерской конторы:
Нет не будет, просто немножечко от форы/тотала добавляем на "любой другой". И выплачиваем, соответственно, если поставил ТМ 2.5 - ничего не выплачиваем, если поставил тб 2.5 - немножко выплачиваем.
а при ТБ 6,5 немного отщипнули на неуказанный счет и выиграли при счете 4:3, а при счете 5:1 тоже выиграли.
То ликвидность от п1 не будет влиять на тоталы, а это недопустимо.
Конечно будет
Конечно будет
Я чего-то не понимаю. Человек поставил на П1, мы ничего в матрицу не записывали, как его ставка добавит ликвидности рынку "тотал меньше 2.5"?
а при ТБ 6,5 немного отщипнули на неуказанный счет и выиграли при счете 4:3, а при счете 5:1 тоже выиграли.
Ну а что поделать, такое будет редко происходить.
Проблема, что мы не можем "разбросать" ставку так, чтобы выплата была одинаковой.
В момент ставки выплата неизвестна, а в момент расчёта менять ставку нельзя.
В общем пока решил так, что будет четыре типа рынков
Опять же, это справедливо, поэтому можно рассматривать, но как объяснять клиентам - загадка...
Но других вариантов принимать баскетболы и прочие гандболы я не вижу от слова совсем, пересчитывать матрицу счетов на блокчейне чрезвычайно дорого, а без матрицы неясно, как увязать форототалы. Давать три независимых рынка (победа в матче, победа по данной форе, данный тотал) не выход, мы видели грустнейший баскетбол на бетфаере, ликвидность должна быть общая.
Зная по каким правилам ставка П1 и другие группировки, распределяется по точным счетам, мы можем прикинуть какие выплаты будут, на все остальное. Физически до момента расчета ставки не надо ее дробить в матрицу точного счета(и при расчете тоже). Но можно с помощью интерфейса(вне блокчейна) виртуально показать где какие объемы на текущий момент, а лучше пусть пусть игроки сами прикидывают.
То есть вы предлагаете вынести вообще всю логику расчета коэффициентов на фронтенд...
а ликвидность "рисовать", всё равно коэффициенты меняются по ходу пьесы...
Как-то тут что-то не так, надо подумать.
Просто идея "толстого фронтенда, тонкого бекенда" витает в воздухе...
Ну тут первично желание получить одинаковые выплаты при 1X2, форах, тоталах независимо от счета, и не делая гибрида букмекера-тотализатора. А то что при этом еще в блокчейн меньше пишится, только плюс.
Основная проблема - если фронтенду перед тем, как показывать людям ставки, придётся сначала их все выкачивать и "виртуально" разбрасывать, чтобы показать текущие цены (а без них никак... кажется), то это может быть очень долго.
Проблема решается каким-то промежуточным сервисом, который будет заранее выкачивать данные из блокчейна и отдавать их интересующимся, и такой сервис даже обязательно будет нужен, ну это типа blockexplorer, только для операций конкретного контракта...
А блокчейн оставить делать то, что он делает хорошо - вести реестр данных...
выкачивать при любом варианте нужно. А обработка может и не дорого стоить. Да и вообще пусть игроки сами обрабатывают, кто-то лучше, кто-то хуже)
Просто появляется точка отказа, именно вот этот выкачивальщик... Вопрос, можно ли/нужно ли его в браузере пользователя реализовывать?
А если не получится технически, не будет ли сервис, который выкачивает и обрабатывает данные в блокчейне каким-то боком причастен к "незаконному игорному бизнесу"?
Я не знаю. Но данные ведь при любой реализации надо брать из блокчейна и показывать пользователю.
Не совсем так, если хранить в блокчейне матрицу и при каждой ставке обновлять её ячейки - то это быстро и несложно.
Ладно, допустим мы делаем, как вы предлагаете - просто собираем ставки у народа, допустим даже, что каким-то образом на фронтенде эти ставки выкачиваются, складываются друг с дружкой и показывается приблизительная выплата на текущий момент по возможным выборам.
Даже допустим, что каким-то образом в блокчейн попадает консенсус на правильный исход.
Но как рассчитывать рынок по этому правильному исходу? Для этого нужно... я даже не знаю, что нужно, нужно пройтись по всем ставкам, каждую учитывая в виртуальной матрице в памяти блокчейна, после этого сгенерировать финальное распределение... а если ставок десятки тысяч?
Ну, десятки тысяч может и нет, а десять тысяч может обработать, да и всегда можно разбить на кусочки... просто рассчитывать будет дорого по газу, но это плюс-минус терпимо...
И как же это будет выглядеть?
У нас есть стартовое распределение как-то записано (это вероятности, их прислал создатель рынка). А что, если он прислал неправильные? Тогда будет нужно какое-то время, чтобы ставками поправили кривое распределение... ну ладно.
Прислали кучу ставок, на разные группировки.
Вот первая пришла, п1, мы её "виртуально" разбиваем на кусочки, записываем в виртуальную матрицу на стороне клиента, обновили распределения.
Третья, четвертая, мы их как-то дробим, как-то визуализируем, в принципе всё нормально.
Всё, закончили принимать ставки.
Но нам теперь надо на блокчейне же (мы же не можем считать извне и загнать данные в блокчейн) посчитать выплаты по каждой группе исходов так, чтобы они были связаны, я не знаю, как это сделать без матрицы.
А если матрицу всё равно надо создавать на блокчейне, пусть и единожды, для расчёта, то остаются все те же проблемы, что и были, матрица нужного размера просто не влезет, а меньшего - надо идти на компромиссы.
Я хоть убейте не понимаю, как можно принять ставку 100 на п1, затем принять ставку 200 на ТМ 2.5, затем принять ставку 50 на 2 (+1.5) и затем рассчитать выплаты? Допустим у команд вероятности забить одинаковые и равны 30% на 0 голов, 40% на 1 гол, 20% на 2 гола и 10% на три гола+.
Как обойтись без "любого другого счёта"? Как посчитать выплаты по этим трём ставкам без матрицы? Я не знаю, я тупой.
так суммируйте все П1, ТМ и т.д. в блокчейне.
B матрицу суммируйте только то, что на конкретный счет ставится.
Расчитывайте выплату на П1. Она для всех 10000 игроков, кто пихнул на П1 равна.
Еще раз. Если игрок пихнул на П1, ставка просуммировалась в одну ячейку П1, а не в 10 точного счета - экономия.
Расчет выплат посложнее - затраты, но они в блокчейне проводятся один раз.
А переслать выплаты десяткам тысячам игрокам в любом случае необходимо.
Расчитывайте выплату на П1. Она для всех 10000 игроков, кто пихнул на П1 равна.
Это здорово, но ведь от того, что кто-то пихнул п1 изменятся выплаты на фору 1 (-1.5) например, как их учесть?
А если их не учитывать - то это не тотализатор, а какой-то букмекер получается, если надо отвечать по заранее заданному коэффициенту. Если же не отвечать - то опять проблема ликвидности, где найти обраток на рынок "П1 - не П1"?
Раздельные рынки - это путь на трубы, это нам и бетфаер показывал уже давным-давно.
Так мы по кругу пошли. Когда все ставки приняты, мы распределим П1 по точным счетам, по правилу - выплата при любом выйгрышном счете должна быть равна. Во время приема можно прикинуть вне блокчейна.
Когда все ставки приняты, мы распределим П1 по точным счетам, по правилу - выплата при любом выйгрышном счете должна быть равна
Ну, тогда это не подходит, мы же должны показать людям примерный коэффициент выплаты, если больше никто не поставит, иначе по какому кефу они вообще ставят?
Как распределить П1, Ф+1.5, ТМ2.5 и все прочие группировки, чтобы выплата по любому выигрышу была равна? Это нетривиальная задача, которая точно не решается на блокчейне.
А значит получается, что кто-то как-то должен присылать в блокчейн, как ему рассчитывать, и нафига тут блокчейн, получается? Это централизованный полностью вариант, со всеми недостатками...
Как распределить П1, Ф+1.5, ТМ2.5 и все прочие группировки, чтобы выплата по любому выигрышу была равна? Это нетривиальная задача, которая точно не решается на блокчейне.
Как распределить, надо думать. Вполне может быть не сложным. Может оказаться не сложнее, чем расчитывать выйгрышь в лайве со снимками, как вы писали в смежной теме.
Не, даже если это придумается - дальше-то что с этой радостью делать? Вычёркиваем, даже если не будет вообще даваться ничего кроме футбола и тенниса - этого вполне достаточно, а может быть группированные матрицы не так плохи, как кажутся.
Так, продолжаем разговор.
Негруппированные матрицы - это хорошо, это футбол, он нужен.
Группированные матрицы - это отстой, потому что люди хотят ставить точно на исход форо/тотала, а группированные матрицы не позволяют гарантировать выигрыш/проигрыш.
Но ведь если нам для ставок нужна только фора (она же победа) или тотал... почему бы не группировать по форе и тоталу?
Смотрите, в высокорезультативных видах спорта ничьи обычно не бывает, везде играется овертайм. А даже если ничья и есть, то её вероятность низка, на то они и высокорезультативные спорты.
Значит, если мы дадим пользователю возможность поставить на несколько значений форы, допустим на четыре, а именно:
То ему будет достаточно интересно в это играть. Точно так же три-четыре значения тотала (положим тотал базовый 170.5, и два дополнительных - 163.5 и 177.5).
Пересечения этих группировок создают небольшую матрицу, в описанном случае это будет 5 промежутков для форы (больше -0.5, от -0.5 до -5.5, от -5.5 до -10.5, от -10.5 до -15.5 и меньше -15.5) и четыре для тотала, то есть всего двадцать элементов.
Когда человек ставит победу первых (то есть исход -0.5 и меньше), то он закрывает почти все промежутки (4 из 5 для фор, все 4 для тоталов), это группировка, которая разбрасывается по распределению. Если команда действительно выиграет - одна из этих групп сыграет, человек получит выплату.
Можно ставить на тотал, он тоже повлияет на распределение.
Итоговый результат будет выглядеть, как "фора от -0.5 до -5.5, тотал от 163.5 до 170.5", а на самом деле сыграли 86 - 82...
То есть в дополнение к аутрайту, бест_оф, матрице счетов мы добавляем матрицу интервалов, где результат матча привязывается к промежуткам форототалов.
Это позволяет давать любые высоковероятные события, баскетбол, бейсбол, киберспорт... Да, тут будут только рынки побед (фор) и общих тоталов, не будет ни возможности выбрать свою фору, ни ставок на индивидуальный тотал, но это совершенно не страшно.
