Глава 02 - Основы CC контрактов

Глава 2 - Основы CC контрактов
Каждый CC контракт имеет "eval" код, это просто произвольное число, связанное с конкретным СС конрактом. Детали конкретного CC конртакта полностью определяются логикой валидации, которая в конечном итоге реализует CC контракт.
Однако, в отличие от обычных биткоин-платежей, которые проверяются только информацией в транзакции, СС контракт имеет право делать почти все что угодно. Он имеет полный доступ к блочейну и даже mempool, хотя использование информации из mempool является в своей сути более рискованным, и должно быть реализовано тщательно или для исключений, а не для включений.

Тем не менее эта глава называется "Основы" СС контрактов, поэтому давайте игнорировать проблемы с mempool и рассмотрим только основы. Фундаментально не существует структуры для сериализованных скриптов OP_CHECKCRYPTOCONDITION, но если вы такой же как и я - вы не хотите читать и понимать 1000 страниц стандарта IETF. То, что мы действительно хотим сделать - это логичный способ создать новый контракт и иметь возможность эффективно его кодировать и отлаживать.

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

В файле ~/komodo/src/cc/eval.h представлены все eval коды. На данный момент он выглядит так:

#define FOREACH_EVAL(EVAL)             \
        EVAL(EVAL_IMPORTPAYOUT, 0xe1)  \
        EVAL(EVAL_IMPORTCOIN,   0xe2)  \
        EVAL(EVAL_ASSETS,   0xe3)  \
        EVAL(EVAL_FAUCET, 0xe4) \
        EVAL(EVAL_REWARDS, 0xe5) \
        EVAL(EVAL_DICE, 0xe6) \
        EVAL(EVAL_FSM, 0xe7) \
        EVAL(EVAL_AUCTION, 0xe8) \
        EVAL(EVAL_LOTTO, 0xe9) \
        EVAL(EVAL_MOFN, 0xea) \
        EVAL(EVAL_CHANNELS, 0xeb) \
        EVAL(EVAL_ORACLES, 0xec) \
        EVAL(EVAL_PRICES, 0xed) \
        EVAL(EVAL_PEGS, 0xee) \
        EVAL(EVAL_TRIGGERS, 0xef) \
        EVAL(EVAL_PAYMENTS, 0xf0) \
        EVAL(EVAL_GATEWAYS, 0xf1)
В конечном счете, мы вероятно закончим использованием всех 256 eval кодов, сейчас есть много места. Я представил что с похожим на мои монеты репозиторием мы можем закончить с гораздо большим чем 256 числом СС контрактов и вы просто выберете 256 которые вы хотите активировать для вашего блокчейна. Это означает, что любой конкретный блокчейн будет ограничен наличием "только" 256 контрактов. Поскольку до сих пор, похоже, так мало действительно полезных контрактов, этого предела, по-видимому, достаточно. Я говорил о том, что eval-код может быть любой длины, но текущие CC контракты предполагают размер в 1 байт.

Простейшим CC скриптом будет тот, который требует подписи от публичного ключа вместе с СС валидацией. Это эквивалентно платежу на pubkey bitcoin скрипт и это то, что использует большинство СС контрактов. Только каналы требуют большего и я объясню это в данной главе.
В итоге мы получаем СС скрипты в форме: (evalcode) + (pubkey) + (другие вещи), не беспокойтесь насчет других вещей, они обрабатываются автоматически при помощи некоторых удобных внутренних функций. Важно отметить, что каждый СС контракт этой формы требует единчного публичного ключа и eval кода и из этого мы получаем CC скрипт. Используя стандартный метод bitcoin "берем хэш и делаем из него адрес", это значит что тот же публичный ключ будет генерировать разные адреса для каждого разного CC контракта!

Это важный момент, поэтому я расскажу об этом еще, но по-другому. В Bitcoin раньше использовались несжатые публичные ключи, имевшие в сумме при сложении правой и левой частей, огромный 64 байтовый публичный ключ. Но так как вы можете извлечь одно из другого, сжатые публичные ключи стали стандартом, вот почему ваши публичные ключи Bitcoin имеют размер 33 байта а не 65. Существуют префиксы 02, 03 или 04, чтобы обозначить нечетный, четный или большой публичный ключ. Это означает, что существует два разных публичных ключа для каждого приватного ключа, сжатый и несжатый. И действительно у вас могут быть два различных адреса протокола bitcoin которые могут быть потрачены одинаковым приватным ключом. Если вы используете генераторы бумажных кошельков - вы уже наверное это заметили.

СС контракты устроены так, что каждый публичный ключ получает другой адрес для каждого eval кода. Это тот же публичный ключ, разные адреса просто потому что фактический скрипт имеет другой eval код, он заканчивается на другой хэш и отсюда разные адреса. Теперь средства отправляемые на конкретный СС адрес доступны только через этот СС контракт и должны следовать правилам данного контракта.
Я так же добавил еще одну полезную функцию, в которой есть соглашение иметь специальный адрес для каждого СС контракта, известный всем, включая его приватный ключ. До того, как вы начнете паниковать по поводу публикации приватного ключа, запомните, что чтобы потратить выход СС, вы должны правильно подписать его И выполнить все правила. Все у кого есть приватный ключ для СС контракта могут сделать часть "правильной подписи", однако им все рвно нужно следовать оставшимся правилам.

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