Негруппированные матрицы - это хорошо, это футбол, он нужен.

Группированные матрицы - это отстой, потому что люди хотят ставить точно на исход форо/тотала, а группированные матрицы не позволяют гарантировать выигрыш/проигрыш.

Но ведь если нам для ставок нужна только фора (она же победа) или тотал... почему бы не группировать по форе и тоталу?

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

Значит, если мы дадим пользователю возможность поставить на несколько значений форы, допустим на четыре, а именно:

• победа первой команды (фора -0.5)
• базовая равновероятная фора (например -10.5 в баскетболе)
• и две дополнительных (-15.5 и -5.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...

То есть в дополнение к аутрайту, бест_оф, матрице счетов мы добавляем матрицу интервалов, где результат матча привязывается к промежуткам форототалов.

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

Как распределить П1, Ф+1.5, ТМ2.5 и все прочие группировки, чтобы выплата по любому выигрышу была равна? Это нетривиальная задача, которая точно не решается на блокчейне.

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

Когда все ставки приняты, мы распределим П1 по точным счетам, по правилу - выплата при любом выйгрышном счете должна быть равна

Ну, тогда это не подходит, мы же должны показать людям примерный коэффициент выплаты, если больше никто не поставит, иначе по какому кефу они вообще ставят?
Как распределить П1, Ф+1.5, ТМ2.5 и все прочие группировки, чтобы выплата по любому выигрышу была равна? Это нетривиальная задача, которая точно не решается на блокчейне.
А значит получается, что кто-то как-то должен присылать в блокчейн, как ему рассчитывать, и нафига тут блокчейн, получается? Это централизованный полностью вариант, со всеми недостатками...

Расчитывайте выплату на П1. Она для всех 10000 игроков, кто пихнул на П1 равна.

Это здорово, но ведь от того, что кто-то пихнул п1 изменятся выплаты на фору 1 (-1.5) например, как их учесть?

А если их не учитывать - то это не тотализатор, а какой-то букмекер получается, если надо отвечать по заранее заданному коэффициенту. Если же не отвечать - то опять проблема ликвидности, где найти обраток на рынок "П1 - не П1"?

Раздельные рынки - это путь на трубы, это нам и бетфаер показывал уже давным-давно.

И как же это будет выглядеть?

У нас есть стартовое распределение как-то записано (это вероятности, их прислал создатель рынка). А что, если он прислал неправильные? Тогда будет нужно какое-то время, чтобы ставками поправили кривое распределение... ну ладно.

Прислали кучу ставок, на разные группировки.

Вот первая пришла, п1, мы её "виртуально" разбиваем на кусочки, записываем в виртуальную матрицу на стороне клиента, обновили распределения.
Третья, четвертая, мы их как-то дробим, как-то визуализируем, в принципе всё нормально.

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

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

Я хоть убейте не понимаю, как можно принять ставку 100 на п1, затем принять ставку 200 на ТМ 2.5, затем принять ставку 50 на 2 (+1.5) и затем рассчитать выплаты? Допустим у команд вероятности забить одинаковые и равны 30% на 0 голов, 40% на 1 гол, 20% на 2 гола и 10% на три гола+.

Как обойтись без "любого другого счёта"? Как посчитать выплаты по этим трём ставкам без матрицы? Я не знаю, я тупой.

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

Даже допустим, что каким-то образом в блокчейн попадает консенсус на правильный исход.

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

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

А блокчейн оставить делать то, что он делает хорошо - вести реестр данных...

Как-то тут что-то не так, надо подумать.

• Аутрайт, то есть есть несколько исходов, выигрывает один из них, пример "кто выиграет Уимблдон".
• Бест_оф (3-5-7), матч до 2-3-4-5-6 побед, тут ставки с форой, ставки на тотал, ставки на индивидуальный тотал, на точный счёт, на каждый раунд, всё как обычно, итоговый счёт всегда известен и находится в заданных рамках.
• несгруппированная матрица - это для футбола, когда достаточно задать 5-7 исходов, чтобы итоговая матрица была не больше 50 элементов, тут никаких проблем, всё просто, делаем группировки, записываем распределение.
• группированная матрица, в которой каждой ячейке соответствует несколько исходов. Например ячейка "первая команда от 75 до 80 очков, вторая команда от 75 до 80 очков". При ставке на "тотал больше 159.5" в этой матрице на нужный исход подходит только 1/25, ну мы и поставим на неё в 25 раз меньше, чем на матрицу, которая подходит полностью. Какой именно счёт зашёл нас особо не касается, интересует только какая ячейка. Проблема огроменная тут, как выше заметили, что человек может поставить тотал меньше 150.5, случится счёт 151, а он получит выплату, пусть и маленькую, так же и наоборот - человек полностью угадает тотал больше 159.5, допустим даже набьют 160, а он получит такую же маленькую выплату, как и при счёте 155, например...

Опять же, это справедливо, поэтому можно рассматривать, но как объяснять клиентам - загадка...
Но других вариантов принимать баскетболы и прочие гандболы я не вижу от слова совсем, пересчитывать матрицу счетов на блокчейне чрезвычайно дорого, а без матрицы неясно, как увязать форототалы. Давать три независимых рынка (победа в матче, победа по данной форе, данный тотал) не выход, мы видели грустнейший баскетбол на бетфаере, ликвидность должна быть общая.

Конечно будет

Я чего-то не понимаю. Человек поставил на П1, мы ничего в матрицу не записывали, как его ставка добавит ликвидности рынку "тотал меньше 2.5"?

а при ТБ 6,5 немного отщипнули на неуказанный счет и выиграли при счете 4:3, а при счете 5:1 тоже выиграли.

Ну а что поделать, такое будет редко происходить.

Нет не будет, просто немножечко от форы/тотала добавляем на "любой другой". И выплачиваем, соответственно, если поставил ТМ 2.5 - ничего не выплачиваем, если поставил тб 2.5 - немножко выплачиваем.

а при ТБ 6,5 немного отщипнули на неуказанный счет и выиграли при счете 4:3, а при счете 5:1 тоже выиграли.

То ликвидность от п1 не будет влиять на тоталы, а это недопустимо.

Конечно будет

С неуказанным счетом, криво будет с форами и тоталами.

Нет не будет, просто немножечко от форы/тотала добавляем на "любой другой". И выплачиваем, соответственно, если поставил ТМ 2.5 - ничего не выплачиваем, если поставил тб 2.5 - немножко выплачиваем.

Если использовать такой подход

То ликвидность от п1 не будет влиять на тоталы, а это недопустимо.

Да, ещё будет элемент "неуказанный счёт", ну это ладно, это не страшно.

С неуказанным счетом, криво будет с форами и тоталами.

Если использовать такой подход

Ленивые игроки ставят на П1 и говорят: "разбросайте мои деньги на выигрышные исходы в точном счеты, чтобы выплата при любом выигрышном исходе была одинаковой".

То в матрицу писать ничего и не надо.
Принимать на руки ничего не надо.

Если не брать простые рынки, типа аутрайтов (просто список исходов, один из них победит) и 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, это сильно упрощает код, но что же делать с матрицами...