Перевод серии статей Джакомо Зукко подготовлен биткоин-энтузиастом Tony ₿. Оригинал серии статей опубликован журналом Bitcoin Magazine

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

Доказательство права собственности: подписи

Наш План ₿ становления денег заставляет нас вновь сосредоточиться на теме личности и вопросе “Кто?”

Ты установил условия выдачи новых сатоши, а как же их передача? Кто уполномочен изменять данные в общем балансе, передавая право собственности?

Представь, что:

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

- эти владельцы (возможно, посредством классического подхода) используют имя пользователя и пароль, как в предыдущем эксперименте с e-gold.

В данной ситуации возникает закономерный вопрос: зачем тогда вообще переходить от физического золота к “цифровой редкости” на основе PoW? Ведь по-прежнему имеет место проблема единой точки уязвимости к атакам Мэллори. С другой стороны, если бы все пользователи обладали равными полномочиями перераспределения права собственности, тогда твоя система оказалась бы и вовсе неработоспособной: все были бы заинтересованы постоянно присваивать чужие сатоши. Следовательно, необходим так называемый “последовательный протокол определения полномочий”, который каждый может проверять самостоятельно.

Решением является криптографический метод, под названием “цифровая подпись”. Он работает следующим образом: сначала Элис выбирает случайное число под названием “приватный ключ” и хранит его в тайне. Затем она пропускает это число через специальную математическую функцию, которую легко применить в одном направлении, но практически невозможно воспроизвести в обратном. В результате получается еще одно число (так называемый “публичный ключ”), доступное другим пользователям. Она сообщает это число Бобу и, в конце концов, передает приватный ключ и сообщение через вторую функцию, не поддающуюся реверсии. Результатом этих операций становится очень большое число под названием “подпись”. Боб же применяет третью и последнюю математическую функцию к сообщению, подписи и публичному ключу Элис. Это приводит либо положительному, либо к отрицательному результату. Если результат положительный, Боб может быть уверен, что Элис санкционировала данное сообщение (“аутентификация”), и что она не сможет впоследствии отрицать эту авторизацию (“невозможность отказа”), и что сообщение не было изменено при передаче (“целостность”).

В некотором смысле, это напоминает рукописные подписи (отсюда и название), которые легко проверить по почерку но сложно воспроизвести, не будучи владельцем “нужной руки”. Или, к примеру — сургучная печать: ее также легко проверить, сравнив с общедоступным реестром печатей, но трудно воспроизвести не имея соответствующего воскового трафарета.

Таким образом, ты изменяешь свой Протокол, чтобы отдельные фрагменты доказательства работы можно было повторно использовать с помощью цифровых подписей. Первая модель, которую ты реализуешь — тривиальна: каждый пользователь самостоятельно генерирует приватный ключ и создает публичную “учетную запись”, помеченную соответствующим публичным ключом. Когда пользователи хотят передать право собственности, они генерируют сообщение, включающее свою учетную запись, учетную запись получателя и количество сатоши, которое они намерены передать. Затем они ставят цифровую подпись и транслируют сообщение, доступное для проверки любым пользователем.

Интересно, что подобная схема может использоваться многими известными (но, возможно, использующими псевдоним) разработчиками для подписи различных версий твоего программного обеспечения. Это позволяет им свободно изменять, улучшать, исправлять, обновлять, проверять и анализировать его. Кроме того, любой пользователь твоей системы может самостоятельно выбрать приемлемую для себя версию ПО и удостовериться в валидности подписей. С этой целью используется сеть минимизированного и фрагментированного доверия. Таким образом, применение данной схемы не требует наличия единого органа для централизованного распространения программного обеспечения. Полноценную децентрализацию кода обеспечивает сам процесс.

Скрипт и “Смарт-контракты”

Однако ты не хочешь ограничивать условия достоверностью цифровой подписи.

Ты приходишь к выводу, что каждое сообщение может также содержать “скрипт”: список инструкций, описывающих дополнительные условия, которые должен выполнять аккаунт (или аккаунты) для воспроизведения транзакции. К примеру, отправитель сможет:

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

Основываясь на этих очень простых (и легко проверяемых) примитивах, можно создавать “смарт-контракты” комплексного характера, что позволяет эффективно “программировать” деньги даже при отсутствии центральных органов управления.

Проблемы секретности (и масштабности)

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

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

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

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

Недостаточная секретность куда серьезнее той проблемы, которая повлияла на твой предыдущий эксперимент с e-gold. Да, раньше ты хранил большинство метаданных транзакций на своих центральных серверах. Но, по крайней мере, это был только ты, в отличие от любого участника (включая многочисленных агентов Мэллори), у которого есть доступ к сети! Кроме того, ты мог бы реализовать некую особенно продвинутую криптографическую стратегию, чтобы хоть частично лишить себя возможности наблюдать за происходящим в твоей сети.

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

Новая парадигма: “CoinJoin”

Обращаясь к этим проблемам, ты решаешь изменить базовые элементы модели “счетов” по аналогии с банковскими на “неизрасходованные транзакционные выходы” (UTXO).

Вместо инструкций по перемещению сатоши с одной учетной записи на другую каждое сообщение теперь включает в себя список старых UTXO, полученных из прошлых транзакций и “использованных” в качестве ингредиентов, и список новых UTXO, “сгенерированных”, подобно товарам, готовым к будущим транзакциям. Вместо того, чтобы разместить для общего доступа на счет один фиксированный публичный ключ (например, банковский IBAN или адрес электронной почты), Бобу будет необходимо обеспечивать каждый последующий ожидаемый платеж новыми одноразовыми публичными ключами. Когда Элис платит ему, она подписывает сообщение, которое “снимает блокировку” с определенного количества сатоши из ранее созданного UTXO, и снова “блокирует” их уже в новом UTXO.

Так же, как и в случае с наличными деньгами, где расходные банкноты не всегда соответствуют платежным запросам, в сети Биткоин часто требуется сдача. Допустим, что, Элис хочет заплатить Бобу 1000 сатоши, но контролирует только несколько UTXO, заблокировавших по 700 сатоши. В таком случае ей необходимо подписать транзакцию, потребляющую два из этих UTXO с 700 единицами (разблокировав общее количество 1400 сатоши) и генерирующую два новых UTXO: один из них будет связан с ключами Боба, блокируя платеж (1000 сат), а другой — с ключами Элис, блокируя сдачу (400 сат).

При условии, что участники не используют один ключ для получения нескольких платежей, этот дизайн сам по себе увеличивает секретность. А когда пользователи твоей сети понимают, что UTXO, потребляемые и генерируемые одной транзакцией, могут исходить от неограниченного количества пользователей (тем самым смешивая множество UTXO между собой — прим. пер.), уровень секретности возрастает в разы! Элис может создать сообщение, тратя старые подконтрольные ей UTXO, и генерируя новые UTXO (предназначенные Бобу). Затем она может передать данное сообщение Кэрол. В свою очередь Кэрол просто добавит свои старые UTXO, которые она хочет использовать, и новые UTXO (предназначенные Дэниэлу), которые она хочет создать. Наконец, Элис и Кэрол подписывают и передают совместное сообщение (то есть, платят и Бобу, и Дэниелу).

Это особое использование модели UTXO называется “CoinJoin”. Внимание: в реальной истории Биткоина модель CoinJoin не являлась частью Биткоин-протокола, выпущенного Сатоши. Она была разработана с целью усовершенствования дизайна спустя несколько лет после запуска последователями Сатоши. Это нарушает статистическую связь между выходами, сохраняя то, что называется “атомарностью”: транзакции либо действительны, либо недействительны, поэтому Элис и Кэрол не нужно доверять друг другу: если одна из них попытается изменить подпись сообщения перед добавлением своей собственной подписи, существующая подпись становится недействительной.

В твоей системе возможны изменения, которые, на самом деле, могут значительнее улучшить ситуацию. Альтернативой твоей нынешней схеме является так называемая “линейность подписей”. Это процесс использования двух приватных ключей (которые являются ни чем иным, как двумя числами), подписывая одно и то же сообщение каждым из них и комбинируя полученные подписи (которые также являются ни чем иным, как двумя очень большими числами). Результатом данной операции является подпись, соответствующая сумме двух публичных ключей, связанных с двумя первичными приватными ключами!

Это звучит запутанно, но смысл прост: используя CoinJoin, Элис и Кэрол, могут скомбинировать свои индивидуальные подписи и передать только сумму, которую каждая может проверить относительно суммы их публичных ключей! Поскольку, как мы уже говорили, подписи являются “самой объемной” частью транзакций, возможность передачи одной комбинированной подписи вместо множества отдельных значительно снизит затраты. В конечном итоге, складывается впечатление, что каждая транзакция использует CoinJoin. Ведь многие пользователи стремились бы к повышению эффективности посредством применения данной модели. Это предположение развенчало бы каноны судебной эвристики.

Даже если модель UTXO не будет усовершенствована, она уже в определенной степени расширяет масштабность: в отличие от изменений состояния при использовании модели “счетов”, она позволяет эффективно группировать и параллельно подтверждать транзакции.

Итак, ты узнал, что:

• использование цифровых подписей для передачи транзакций позволяет децентрализовать собственность;
• использование системы скриптов позволяет превратить транзакции в программируемые “контракты”;
• использование более сложной парадигмы под названием CoinJoin позволяет повысить секретность и масштабность сети.

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