В последнее время мне было интересно установить задержки после инициализации и разрешения, чтобы избежать возникновения более одной транзакции.
Мне еще предстоит достаточно внимательно прочитать документы, но я думаю о чем-то вроде
contract GameStake {
adress public playerOne;
address public playerTwo;
delay(15) {
//delayed execution, sends payment after 15 blocks of initialization.
...
}
}
Спасибо.
Технически возможно включить задержки, используя номер блока или отметку времени. Излишне неудобно заставлять контракт «проснуться» в будущем. Клиенты могут снимать выигрыши, а контракт может проверять их права, возможно, с прицелом на часы.
Говоря абстрактно, немного сложно быть точным, поэтому давайте поговорим о камне, ножницах, бумаге. Предположим, что каждый игрок делает ставку на каждый раунд.
Следующее описание основано на предположении, что существует удобное Dapp, которое скрывает все детали транзакций от пользователей... чтобы они могли играть в игру.
Система может определить победителя после размещения двух ставок. Неочевидная проблема заключается в том, что все в блокчейне видно определенному противнику. Это означает, что игрок может жульничать, если только «камень, ножницы или бумага» не хранится в зашифрованном виде. На этапе ставок все скрыто.
Когда все ставки будут сделаны, раунд перейдет в фазу расчета.
Клиенты раскрывали секреты, которые они использовали для кодирования своих ставок (для раунда 123 мой секрет был 0x123). Контракт будет подтверждать правильность секрета и правильность расшифровки записанной информации в «камень, ножницы, бумага».
Контракт сразу определил бы победителя.
Победитель должен был забрать свой приз. Таким образом, они обеспечивают газ для передачи. Эта функция будет проверять законность претензии.
На этапе урегулирования вполне возможно, что решительный (и дешевый) неудачник воздержался бы от скудных затрат на газ для проверки, если бы они могли определить, что они проиграли (выполнимо). Это можно решить с помощью правила, которое предусматривает, что они проигрывают раунд, если они не регистрируются после нескольких блоков.
Мы можем представить пользовательский интерфейс, который непрерывно играет в игру, с предыдущими раундами в состоянии ожидания или в состоянии ожидания. Как правило, выплата будет немедленной. Когда участвуют нечестные игроки, это может привести к небольшой задержке расчетов по определенным раундам; всегда в конце концов решается.
Надеюсь, поможет.
Контракт будильника Ethereum позволяет вам планировать вызовы функций для определенного блока в будущем. Для этого он не полагается на стороннего оракула, хотя и требует, чтобы вы знали все детали транзакции во время планирования.
Документация, с примерами, здесь . Если вы предпочитаете использовать библиотеку JavaScript , вы можете найти учебник здесь.
Основной принцип заключается в том, что функция контракта может выполняться только в том случае, если ее вызывает какая-то внешняя сторона. Сегодня задержкой управляют оракулы (внешняя сторона, которая отслеживает определенные события и вызывает ваш контракт через предопределенный интерфейс, который вы реализуете. Он существует только в общедоступной цепочке блоков, а не в частной. Если вы не реализуете их повторно)
Не существует (насколько мне известно) механизма контрактной функции для асинхронной отправки транзакции и ее майнинга в будущем блоке. Это позволило бы вызвать ваш собственный контракт и, пока номер блока не будет достигнут, снова вызвать async). Возможно, в более поздней версии EVM для Ethereum.
Поэтому на данный момент самый простой способ — инициализировать ваш контракт со ставками, участниками и отметкой времени в будущем. И извне регулярно вызывайте контракт, чтобы проверить, не истекло ли время, а затем вызывайте код после задержки.
Удачи
Роб Хитченс
Дакота Квинт