UTxO как одноразовые пломбы:
Физические одноразовые пломбы встречаются реже, чем их цифровые аналоги. Мы часто используем такие пломбы для защиты целостности безопасной доставки, чтобы убедиться, что продукция не была подделана при транспортировке.
Принцип, однако, обманчиво прост: если пломба еще не вскрыта, значит, она все еще действительна. Аналогично, с помощью цифровых одноразовых печатей (впервые предложенных Питером Тоддом) можно закрыть сообщение цифровой печатью, чтобы гарантировать, что сообщение может быть использовано один и только один раз.
Нерастраченные выходы транзакций Биткойна (UTxO) демонстрируют это свойство. Все выходы транзакций Биткойна криптографически уникальны (UTxO существуют как TX_HASH:OUTPUT_INDEX, хэш и индекс обеспечивают уникальность); никакие два UTxO никогда не будут одинаковыми.
Все выходы транзакций Bitcoin могут быть потрачены только один раз; это намеренная конструкция, встроенная в блокчейн для защиты от двойных трат.
Используя эти уникальные свойства, можно рассматривать UTxO как одноразовые пломбы, где трата UTxO означает снятие пломбы. Если приложить инструкции к снятию пломбы, можно создать последовательную, детерминированную машину состояний, которая представляет собой передачу прав собственности.
Биткойн как истина и консенсус
Блокчейн биткойна - самый используемый, самый децентрализованный и самый безопасный блокчейн в мире. Вместо того чтобы полагаться на централизованную организацию или компанию, проверяющую, были ли нарушены одноразовые пломбы, мы можем передать эту работу блокчейну Bitcoin и, в свою очередь, создать децентрализованный протокол.
Однако для решения всех наших проблем нужны не только одноразовые пломбы, но и механизм, гарантирующий, что конкретное изменение состояния - это то, что задумал владелец UTxO. Этого можно добиться, просто записав хэш изменения состояния и включив его в транзакцию, которая расходует UTxO.
Мы можем решить эту проблему, включив хэш и вставив его в код OP_RETURN в транзакции Биткойна. Чтобы предотвратить двойную трату, действительным считается только хэш первого кода OP_RETURN. Эти данные также можно вставить в дескрипторы taproot.
Это позволит нам получить цепочку взаимодействий/событий передачи контракта, которую можно независимо восстановить и проверить с помощью хэш-анализа серии транзакций. Для полной проверки контракта пользователям понадобятся данные вне цепочки из инструкции, которая была хэширована.
Эта функция может быть использована для сохранения и защиты конфиденциальности, а также создает возможность для хостеров предоставлять эту информацию сообществу бесплатно или за определенный финансовый стимул.
Переходы состояний в SCL
SCL использует описанные выше механизмы для создания серии контрактов, которые работают через переход состояния. Каждый раз, когда расходуется одноразовая печать, может произойти некоторый переход состояния, который изменяет состояние контракта.
Давайте рассмотрим простой пример, а затем расширим его до контракта SCL01:
Первое, что должно произойти, чтобы мы могли передавать активы, - это их майнинг на блокчейне. Это достигается путем включения команды майнинга в транзакцию и привязки активов к адресу изменения команды майнинга.
MINT: [ TICKER, MAX_SUPPLY, DECIMALS, TXID:N ]Это пример того, как может выглядеть команда минтинга, где TXID - это транзакция, в которой находится команда и которая впоследствии станет идентификатором контракта, а N - это номер выхода, к которому привязываются новые активы.
MINT: [ TESTCOIN, 1000000000, 8, TXID:1 ]В приведенном выше примере мы чеканим 10 TESTCOIN и привязываем их ко второму выводу этой транзакции. После того как мы привяжем несколько токенов к UTxO, мы можем перевести их с помощью команды, примерно такой:
TRANSFER: [ UTXOA, UTXOB (AMOUNT), UTXOC (AMOUNT) ]Как видите, мы можем указать, что тратим UTxOA, чтобы отправить некоторую сумму в UTxOB и получить нашу сдачу в UTxOC.
TRANSFER: [ bb8c1cc124d7a29313c7f9d4306afa308a0d4f1f25967192e4e3d2a3bd68bb2e:1,a1ab93a0114313fc69e4b6f377799ed5b9bb1606113055c6561b361dccc54e4a:1(10000),f788b96b716362adc80267f758441be2ccfdad75110683c3121c15074abc096f:0(99999000 0) ]Приведенный выше пример показывает, как может выглядеть транзакция, если в ней явно упомянуты UTxO. Из-за того, что изменение данных в транзакции изменяет хэш транзакции, невозможно включить самореферентные хэши в транзакцию Биткойна. В связи с этим мы можем ссылаться на UTxO, созданные в транзакции, используя сокращение "TXID:N". По сути, SCL рассматривает все UTxO, помеченные TXID, как внутренние (UTxOS в конкретной транзакции). Если мы скорректируем приведенный выше пример, чтобы отправить на наш первый выход и отправить изменение на наш второй выход, результат будет выглядеть следующим образом:
TRANSFER: [ bb8c1cc124d7a29313c7f9d4306afa308a0d4f1f25967192e4e3d2a3bd68bb2e:1, TXID:0(10000),TXID:1(999990000) ]Однако для того, чтобы наша команда перевода работала, необходимо гораздо больше информации. И не только это, но было бы гораздо предпочтительнее, если бы мы могли выполнять несколько взаимодействий со смарт-контрактами с помощью одной транзакции Bitcoin. Мы также хотим указать, к какому контракту мы обращаемся с помощью идентификатора контракта.
CONTRACT_ID_1:TRANSFER[[UTXO_SENDER_1, UTXO_SENDER_2, ... , UTXO_SENDER_N],[UTXO_RECEIVER_1(AMOUNT), UTXO_RECEIVER_2(AMOUNT), ... , UTXO_RECEIVER_N(AMOUNT)]]В приведенном выше примере показана более зрелая версия команды передачи SCL, в которой можно тратить несколько UTxO отправителя и оплачивать несколько получателей. Мы также указали ID контракта. Это пример команды, которую можно объединить с несколькими командами для большей масштабируемости.
Payload и пакетная обработка
В связи с ограничениями масштабируемости блокчейнов первого уровня SCL разработала систему пакетной обработки, предназначенную для объединения нескольких команд в один хэш транзакции. Это позволяет SCL масштабировать блокчейн на первом уровне, используя консервативный подход к данным, и в то же время быть переносимым на второй уровень (наследуя масштабируемость и скорость второго уровня). Мы помещаем все наши команды в то, что мы называем полезной нагрузкой. Только полезная нагрузка хэшируется и включается в транзакции, и именно полезная нагрузка и хэш используются для проверки любого перехода состояния.
<TXID, PAYLOAD>С точки зрения проверки необходимо знать, какая транзакция связана с конкретным Payload. Поэтому мы также включаем транзакцию, состоящую из полезной нагрузки, когда представляем словарь этого Payload-а, который любой клиент может использовать для независимого воссоздания и проверки состояния контракта.
Payload состоит из различных контрактных команд; более подробное описание структуры команд Payload-а можно увидеть ниже:
<TXID, {CONTRACT_ID_1:COMMAND}{CONTRACT_ID_2:COMMAND}...{CONTRACT_ID_N:COMMAND}>Предположим, что мы объединим описанный выше протокол с нашим предыдущим примером масштабируемой команды перевода. В этом случае мы можем создать экземпляр команды SCL, выполняющей несколько переводов активов с помощью одной транзакции Bitcoin!
<TXID, {CONTRACT_ID_1:TRANSFER[[UTXO_SENDER_1, UTXO_SENDER_2, ... , UTXO_SENDER_N],[UTXO_RECEIVER_1(AMOUNT), UTXO_RECEIVER_2(AMOUNT), ... , UTXO_RECEIVER_N(AMOUNT)]]}{CONTRACT_ID_2:TRANSFER[[UTXO_SENDER_1, UTXO_SENDER_2, ... , UTXO_SENDER_N],[UTXO_RECEIVER_1(AMOUNT), UTXO_RECEIVER_2(AMOUNT), ... ,UTXO_RECEIVER_N(AMOUNT)]]}...{CONTRACT_ID_N:TRANSFER[[UTXO_SENDER_1, UTXO_SENDER_2, ... , UTXO_SENDER_N],[UTXO_RECEIVER_1(AMOUNT), UTXO_RECEIVER_2(AMOUNT), ... , UTXO_RECEIVER_N(AMOUNT)]]}>Одно это нововведение значительно улучшает масштабируемость криптоактивов. Для сравнения, при добавлении большего количества выходов в транзакцию биткоина количество байтов увеличивается, что приводит к росту комиссии за транзакцию.
Поскольку вся полезная нагрузка хешируется независимо от количества взаимодействий по контракту, количество байтов, добавляемых в блокчейн, всегда равно тридцати двум. Таким образом, Payload имеет фиксированную стоимость.
В парадигме EVM пользователи платят за обработку ВМ; это означает, что при увеличении количества взаимодействий смарт-контрактов вы выполняете больше обработки на ВМ, что, в свою очередь, увеличивает стоимость транзакций.
SCL имеет известную стоимость одного Payload-а и может объединять тысячи взаимодействий, что позволяет повысить эффективность и удешевить взаимодействие контрактов.
Валидация
Контракты, их состояния и дополнительную информацию можно представить и визуализировать как объекты. Команда на минтинг действительна до тех пор, пока хэш в команде соответствует желаемым минтинговым параметрам Payload.
Когда команда минтинга подтверждена, создается начальный граф состояний:
{ "ticker": "DFG", "contractid": "4eae21aa41695b59ccfbcc2b37417c6e5f3e63028690d1ab9d8705dd0ce47360", "supply": 100000000000000000, "decimals": 8, "owners": {"4eae21aa41695b59ccfbcc2b37417c6e5f3e63028690d1ab9d8705dd0ce47360:1": 100000000000000000 }, "payloads": [“<4eae21aa41695b59ccfbcc2b37417c6e5f3e63028690d1ab9d8705dd0ce47360,{SCL01:[DFG, 100000000000000000,TXID:1]}>" ] }Любой человек может самостоятельно проверить команду майнинга, сравнив хэш исходной полезной нагрузки с хэшем, хранящимся в OP_RETURN транзакции майнинга. Эта же парадигма проверки применяется ко всем полезным нагрузкам для всех взаимодействий контракта.
Ниже приведен пример состояния контракта после выполнения нескольких команд перевода. Важно отметить, что любой желающий может безопасно проверить криптографическую целостность контракта, просто сверив хэши Payload с хэшами в блокчейне.
Поскольку мы не можем потратить UTxO дважды и поскольку мы записываем хэш полезной нагрузки в OP_RETURN транзакции в качестве якоря, мы наследуем модель консенсуса и безопасность базового блокчейна.
{ "ticker": "DFG", "contractid": "4eae21aa41695b59ccfbcc2b37417c6e5f3e63028690d1ab9d8705dd0ce47360", "supply": 100000000000000000, "decimals": 8, "owners": {"f9b87b2907b55afe7d104398787aa5c427c6f5940215ff0434532ce17f674ebd:0":60000,"245f21e498c0e3eb2547298085d67518713eb44bb30f4511e14e5d8362784b64:0":55000,"0ab7b733d75c29caee531959e78c542ef32576331c8efb0edb30ed817ebde8a2:0":420000,"a074bdcf9954347f8e1ed233530abf2f58f5c0da3b9acd2158ea98afa519b41a:0":420000,"4f85e172762dabd1dfca9e3eb7c753156f78af41f743983e04776c16cba31585:0":60000,"b5210f5a098f9f258b9cf3883df5a7103cbb3ed46caae0c6907e110cc8d08496:0":75000,"cf58521c0ad86cdcef2d1bc21a2eb1c940085b5029095b3df96ec9ccf3d54d9f:0":175000,"f9b87b2907b55afe7d104398787aa5c427c6f5940215ff0434532ce17f674ebd:2": 190000,"cf58521c0ad86cdcef2d1bc21a2eb1c940085b5029095b3df96ec9ccf3d54d9f:2": 99999999998545000 },
"payloads": [“<4eae21aa41695b59ccfbcc2b37417c6e5f3e63028690d1ab9d8705dd0ce47360,{SCL01: [DFG,100000000000000000,8,TXID:1]}>","<4bad9f4de415695991f2864f204984daab87e36c3e80787701961fc0021ffc29,{4eae21aa41695b59ccfbcc2b37417c6e5f3e63028690d1ab9d8705dd0ce47360:TRANSFER[[4eae21aa41695b59ccfbcc2b37417c6e5f3e63028690d1ab9d8705dd0ce47360:1], [TXID:0(250000),TXID:2(99999999999750000)]]}>","<245f21e498c0e3eb2547298085d67518713eb44bb30f4511e14e5d8362784b64,{4eae21aa41695b59ccfbcc2b37417c6e5f3e63028690d1ab9d8705dd0ce47360:TRANSFER[[4bad9f4de415695991f2864f204984daab87e36c3e80787701961fc0021ffc29:2], [TXID:0(55000),TXID:2(99999999999695000)]]}>",
"<0ab7b733d75c29caee531959e78c542ef32576331c8efb0edb30ed817ebde8a2,{4eae21aa41695b59ccfbcc2b37417c6e5f3e63028690d1ab9d8705dd0ce47360:TRANSFER[[245f21e498c0e3eb2547298085d67518713eb44bb30f4511e14e5d8362784b64:2], [TXID:0(420000),TXID:2(99999999999275000)]]}>","<a074bdcf9954347f8e1ed233530abf2f58f5c0da3b9acd2158ea98afa519b41a,{4eae21aa41695b59ccfbcc2b37417c6e5f3e63028690d1ab9d8705dd0ce47360:TRANSFER[[0ab7b733d75c29caee531959e78c542ef32576331c8efb0edb30ed817ebde8a2:2], [TXID:0(420000),TXID:2(99999999998855000)]]}>","<4f85e172762dabd1dfca9e3eb7c753156f78af41f743983e04776c16cba31585,{4eae21aa41695b59ccfbcc2b37417c6e5f3e63028690d1ab9d8705dd0ce47360:TRANSFER[[a074bdcf9954347f8e1ed233530abf2f58f5c0da3b9acd2158ea98afa519b41a:2], [TXID:0(60000),TXID:2(99999999998795000)]]}>","<b5210f5a098f9f258b9cf3883df5a7103cbb3ed46caae0c6907e110cc8d08496,{4eae21aa41695b59ccfbcc2b37417c6e5f3e63028690d1ab9d8705dd0ce47360:TRANSFER[[4f85e172762dabd1dfca9e3eb7c753156f78af41f743983e04776c16cba31585:2],[TXID:0(75000),TXID:2(99999999998720000)]]}>", "<f9b87b2907b55afe7d104398787aa5c427c6f5940215ff0434532ce17f674ebd,{4eae21aa41695b59ccfbcc2b37417c6e5f3e63028690d1ab9d8705dd0ce47360:TRANSFER[[4bad9f4de415695991f2864f204984daab87e36c3e80787701961fc0021ffc29:0],[TXID:0(60000),TXID:2(190000)]]}>","<cf58521c0ad86cdcef2d1bc21a2eb1c940085b5029095b3df96ec9ccf3d54d9f,{4eae21aa41695b59ccfbcc2b37417c6e5f3e63028690d1ab9d8705dd0ce47360:TRANSFER[[b5210f5a098f9f258b9cf3883df5a7103cbb3ed46caae0c6907e110cc8d08496:2], [TXID:0(175000),TXID:2(99999999998545000)]]}>" ] }Контрактный хостинг
Все контракты могут быть проверены самостоятельно. Однако передача и хранение дополнительных данных о проверке может быть обременительной для пользователей. Хотя пользователи могут размещать свои собственные контракты, они также могут передать эту обязанность другим. Поскольку размещение контракта не требует консенсуса, предоставление возможности другим пользователям размещать контракты не несет никаких рисков с точки зрения прозрачности данных. Предоставление пользователям возможности размещать контракты самостоятельно, в кластерах, DAO или в частном порядке фактически способствует более высокому уровню децентрализации, особенно по сравнению с EVM, где все контракты размещаются в избыточном количестве на каждом полном узле.
Хозяева контрактов SCL также могут взимать или не взимать плату, в зависимости от требований бизнеса. Например, компания, занимающаяся видеоиграми, может размещать контракты для всех своих игровых активов бесплатно, поскольку их финансово стимулирует успех игры. В качестве альтернативы DAO может децентрализованно размещать свои контракты на различных устройствах.