Проверка, разрешен ли отзыв контракта

Я пытаюсь концептуализировать, как будет написан конкретный вид смарт-контракта.

Контракт в основном будет обрабатывать ввод и вывод ETH или какого-либо токена ERC20.

Затем баланс будет использоваться для игры в различные игры вне сети, в основном в стиле казино для нескольких игроков, такие как техасский холдем. Игры вне сети, потому что они требуют много операций, а комиссия за Tx не будет удобной для пользователя.

Пользователи будут увеличивать (или уменьшать) свой баланс внутри контракта, играя в эти игры.

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

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

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

Любое понимание будет с благодарностью!

Спасибо

Ответы (3)

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

Не могли бы вы объяснить реализацию «подписей с государственных каналов», я не знаком с этим
Вам следует взглянуть на Plasma Cash -> karl.tech/plasma-cash-simple-spec , так как он прольет свет на то, как осуществлять фактическое управление активами вне сети и разрешение конфликтов в сети.

У вас есть игра вне сети, поэтому есть элемент доверия к игровым серверам. У вас есть отдельные средства в игре и средства, которые можно вывести бесплатно (необремененные).

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

В случае, если это не ясно.

У Алисы 10 эфиров. Она покупает 5 фишек за 5 эфиров, и у нее есть 5 эфиров, доступных для вывода. Она обналичивает свои фишки, когда они не в игре, но это забота игрового сервера, потому что он знает, какие из них «свободны и чисты», а какие в игре. Когда Алиса продает, скажем, 7 фишек (повезло Алисе), она получает обратно 7 эфиров.

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

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

Это, по общему признанию, слишком упрощенный пример, чтобы дать вам некоторые идеи.

pragma solidity 0.5.1;

contract Holdem {

    mapping(address => uint) public balances;

    event LogDeposit(address sender, uint amount);
    event LogWithdrawal(address receiver, uint amount);
    event LogTransfer(address sender, address receiver, uint amount);

    function depost() public payable {
        balances[msg.sender] += msg.value;
        emit LogDeposit(msg.sender, msg.value);
    }

    function withdraw(uint amount) public {
        uint bal = balances[msg.sender];
        require(bal >= amount, "Insufficient Funds.");
        balances[msg.sender] -= amount;
        emit LogWithdrawal(msg.sender, amount);
        msg.sender.transfer(amount);
    }

    function transfer(uint amount, address receiver) public {
        uint bal = balances[msg.sender];
        require(bal >= amount, "Insufficient Funds.");
        balances[msg.sender] -= amount;
        balances[receiver] += amount;
        emit LogTransfer(msg.sender, receiver, amount);
    }

}

Функция transfer()позволяет Алисе давать деньги дому, а дому давать Алисе. Он генерирует событие, достаточное для того, чтобы честный дом отчитался о полученных средствах.

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

Надеюсь, поможет.

То, о чем вы говорите, по сути, является концепцией «оркалей» вне сети. Примеры того, как это делается, можно посмотреть на средства, предоставляемые https://chain.link .

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

В сценарии, подобном тому, который вы описываете, ваши игровые серверы вне сети должны будут «заблокировать» определенное количество ценности в цепочке, а затем «разблокировать» любую ценность, которая не была потрачена во время игры. Очевидно, что функции контракта, которые они вызывают, должны быть функциями "onlyOwner" (т. е. иметь элементы управления доступом), и вы также можете потенциально захотеть использовать некоторую криптографию обмениваемых данных. Все в цепочке видно, даже если переменные объявлены как «частные» в Solidity. Следовательно, сохранение конфиденциальности информации, передаваемой по цепочке и вне ее, нетривиально.