Глава 03 - CC vins и vouts

Глава 3 - CC vins и vouts
Возможно вам захочется ознакомиться с основами Bitcoin и другими материалами, чтобы освежить в голове то, как Bitcoin выходы становятся входами. Это немного сложно, но в конечном счете речь идет об одном конкретном количестве монет которые были потрачены, после траты это соединяется с другими, так же потраченными в данной транзакции, монетами, а затем создаются различные выходы.

vin0 + vin1 + vin2 -> vout0 + vout1

Это транзакция с 3-мя входами и 2-мя выходами. Сумма монет из трех выходов объединяется и затем делится на vout0 и vout1, каждый из vout-ов получает скрипт траты, который должен быть удовлетворен, для того чтобы быть потраченым. Это означает что все требования (так, как указаны в выходе которых их создал) удовлетворены для всех трех vin-ов.

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

[хороший график будет здесь]

Из всех аспектов CC контрактов, гибкость которую создали различные vins и vouts была самым большим сюрпризом. Когда я начинал писать первый из них месяц назад, я и понятия не имел о силе скрывающейся в смарт-контрактах на UTXO. Я был просто рад возможности заблокировать средства и освободить их в определенных условиях.
После assets/tokens контрактов, я понял, что это всего лишь верхушка айсберга. Я знал что это Тьюринг-полное, но после всех этих лет ограниченных Bitcoin скриптов, иметь полную силу любого произвольного алгоритма - это открыло глаза. Годы написания блокчейн-кода и очень плохие последствия с каждым багом, делают вас очень пугливым когда дело касается создания агрессивных вещей на уровне консенсуса. И это так, как должно - если не быть очень осторожным, какие нибудь очень плохие вещи могут случиться и случаются. Основание, в виде построения поверх существующей (хорошо протестированной и надежной) UTXO системы, это то, что делает CC контракты менее подверженными ужасным багам. При этом недостаточная валидация может очень просто позволить изымать средства с ненадлежащим образом разработанного CC контракта.

СС контракт выходит за рамки стандартных ограничений Bitcoin транзакции. То, что я уже написал объясняет причину этого, но сначала это было неочевидно даже для меня, поэтому возможно вы тоже упустили это. Если вы гадаете о чем это я говорю - я расскажу об ЭТОМ!

Напомню, у нас теперь есть стандартный bitcoin выход нзываемый СС выходом. Кроме того, на отдельном блокчейне может существовать до 256 различных типов выходов CC контрактов. Мы также знаем что чтобы потратить любой выход, вам нужно удовлетворить его тратящий скрипт, что в нашем случае достигается подписью и любыми ограничениями накладываемыми СС-валидацией. У нас так же есть соглашение о глобально разделенной ключевой паре, которая дает нам главный CC адрес на который можно отправить средства, наряду с конкретным CC-адресом пользователя.
Давайте вернемся к примеру с 3+2 транзакцией:

vin0 + vin1 + vin2 -> vout0 + vout1

Учитывая предыдущий параграф, попробуйте представить возможности простой 3+2 транзакции. Каждый vin может быть обычным vin'ом из глобального адреса контракта, СС адрес пользователя и vout'ы так же могут быть в этом диапазоне. Теоретически может существовать 257 * 257 * 257 * 257 * 257 форм 3+2 транзакций!

В реальности мы хонечно не хотим давать так много степеней свободы, так как это обеспечит нас большим числом багов!  Таким образом нам нужно сократить это число до более управляемого уровня, где для каждой из них должно быть не более 3 типов, а желательно всего 1 тип. Это сделает валидацию гораздо проще, а проще - значит лучше до тек пор пока мы не жертвуем мощью. А мы не жертвуем.

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