С сегодняшней инфраструктурой это невозможно. Мы можем представить два решения.

Первое решение: обновление биткойнов

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

• Если прошло определенное время
• Выполните поиск UTXO, чтобы найти все выходы, помеченные как относящиеся к стороне A.
• Сделайте тот же поиск для стороны B
• Разберите и суммируйте их, чтобы выяснить, какой из них выиграл. Существующий набор инструкций может быть или не быть достаточно хорошим для этого, но повторное включение кодов операций, которые были отключены в панике давным-давно, не кажется невозможным: просто нужны хорошие модульные тесты.
• Затем, используя результат этого расчета, потребуйте подпись, созданную выигравшим адресом.

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

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

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

Для этого конкретного варианта использования я, вероятно, посчитал бы, что затраты перевешивают преимущества. Конструкция ИМО довольно странная и неубедительная. Однако возможно, что кто-то придумает вариант использования OP_LOOKUP_OUTPUTS, который действительно убедителен, и мы всегда говорили о том, чтобы заставить узлы вычислять больше индексов по набору UTXO. Если мы в конечном итоге сделаем это по другим причинам, в этот момент раскрытие его через скрипт не кажется таким уж большим скачком, и станет возможным (даже легко) сделать эту конструкцию «чистым» смарт-контрактом.

Второе решение: сеть оракула

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

Эфириум — полная противоположность, он дает скриптам огромную мощь и доступ к множеству дорогостоящих возможностей, таких как слоты для хранения данных. Насколько это безопасно, насколько устойчиво к DoS-атакам и т. д., в настоящее время является нерешенным вопросом, но мы знаем из горького опыта с биткойнами, Java, Flash, HTML/JS и т. д., что песочница мобильного кода чрезвычайно сложна. Они собираются получить свою работу для них. Во всех известных мне «песочницах» мобильного кода в какой-то момент были обнаружены дыры, поэтому никому еще не удавалось сделать то, что хочет Ethereum, без повторяющихся эксплойтов. Вот почему биткойн-сообщество так консервативно относится к увеличению мощности скрипта.

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

Есть несколько способов сделать это в биткойнах.

Один из них — иметь независимую p2p-сеть оракулов:

https://en.bitcoin.it/wiki/Contracts#Trust_minimization:_multiple_independent_oracles

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

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

Другой — использовать боковую цепь, когда такая технология станет доступной. В этом случае боковая цепь не содержит монет и двухсторонняя привязка не требуется. Скорее «транзакции» боковой цепи просто утверждают, что программа была запущена и удовлетворена. Затем оракулы «майнят» боковую цепь, тем самым доказывая, что большинство хешрейтов запустило скрипт и получило ожидаемый результат.

Последний способ — использовать SNARK, когда такая технология станет доступной.

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

Дизайн Ethereum, напротив, более тесно связывает вещи друг с другом. Эксплойт в механизме контрактов Ethereum может привести к поломке всей системы.

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

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