Какова история существующего в настоящее время языка сценариев в биткойнах?
В оригинальном техническом документе Сатоши о Биткойне не упоминается язык сценариев на основе стека. Так кто же первым предложил эту идею и реализовал ее? И почему они решили выбрать язык на основе стека?
Скрипт был в первой версии Биткойна. Сатоши разработал Биткойн в частном порядке, прежде чем выпустить полностью пригодную для использования Биткойн 0.1, и он очень мало рассказал о своем мыслительном процессе, поэтому мы, вероятно, никогда не узнаем точно, почему многие вещи были сделаны именно так.
Скрипт имел несколько серьезных ошибок, когда Биткойн был впервые выпущен, и некоторые ошибки все еще существуют. Понятно, что Сатоши не тщательно тестировал скрипт перед выпуском биткойнов. И хотя он содержит много сложностей, он все еще слишком неполный, чтобы большинство кодов операций могли иметь какое-либо реальное применение. В свете этого часто предполагают, что Script был чем-то вроде запоздалой мысли. Возможно, дизайн Сатоши изначально отправлял биткойны только напрямую на открытые ключи, но при добавлении поддержки биткойн-адресов и обдумывании будущих типов транзакций он понял, что язык сценариев будет полезен для прямой совместимости.
Язык, основанный на стеке, является здесь естественным выбором. Обработка сценария предельно проста и очень быстра: просто продолжайте считывать коды операций из сценария и оценивать их, пока сценарий не будет завершен. Каждый код операции в значительной степени автономен. Скрипты также легко анализировать благодаря тому, что все, что находится справа от определенной точки в скрипте, можно считать функцией. Вы можете точно знать, что любой scriptPubKey, начинающийся с OP_RETURN, всегда не пройдет проверку, и что любой сценарий, заканчивающийся на <pubKey> OP_CHECKSIG, всегда будет требовать подписи этого открытого ключа, независимо от того, что содержит остальная часть сценария.
Этот функциональный аспект Script был особенно важен, когда сценарии все еще оценивались путем прямой конкатенации scriptSig и scriptPubKey, а не оценивались по отдельности, как это делается сегодня. Теоретически вы можете поместить что угодно в scriptPubKey и быть уверенным, что независимо от того, что находится в scriptSig, ваш scriptPubKey будет вести себя как функция, принимающая соответствующее количество аргументов из стека. Однако изначально опкод OP_RETURN приводил к преждевременному завершению скрипта, а не к сбою, поэтому вы могли украсть чьи-либо биткойны, просто используя scriptSig.OP_TRUE OP_RETURN. Также можно было поместить код операции pushdata прямо в конец scriptSig, чтобы превратить весь scriptPubKey в константу (которая оценивается как истинная). Сатоши исправил эти ошибки, изменив поведение OP_RETURN, чтобы транзакция немедленно завершалась неудачно, и сделав так, чтобы scriptSig и scriptPubKey оценивались в два отдельных шага.
Я наткнулся на комментарий Майка Хирна в контексте старой ошибки OP_RETURN, который показался мне поучительным:
Система сценариев всегда казалась мне довольно поздним дополнением к дизайну. Сатоши признал это, когда сказал, что добавил его после того, как столкнулся со взрывом особых случаев, когда он разрабатывал различные типы контрактов. Тот факт, что в CHECKMULTISIG есть очевидная ошибка, является еще одним свидетельством того, что эта часть является общей спешной работой, наряду с готовностью Сатоши отключить большую часть его функций позже с проверками IsStandard. Кроме того, дизайн CHECKSIG является очевидным усовершенствованием, было бы гораздо разумнее его разложить, и мы так и не нашли вариант использования для 99% кодов операций, несмотря на то, что успешно разработали (переработали?) все типы контрактов, которые он когда-либо упоминал.
амаклин
онимос
Кайкурокава