Напомним, что подобные сети являются децентрализованными, поэтому все действия пользователь совершает не на каком-то удаленном сервере, а непосредственно у себя на компьютере или мобильном устройстве. Там же хранятся и все необходимые ключи, в том числе и закрытые. В отличие от классического банка, вопросы хранения секретной персональной информации теперь возложены на самого клиента. Если он потеряет секретный ключ, то автоматически утратит доступ к активам, которые связаны с адресом, сгенерированным на основе этого секретного ключа. В интернете можно найти огромное количество историй о несостоявшихся криптовалютных миллионерах, которые потеряли свои цифровые миллионы вместе с закрытыми ключами от своих адресов. Это достаточно серьезная проблема, поэтому вопросам безопасности хранения криптоактивов будет посвящена отдельная глава.
Теперь, когда у пользователя есть адрес в условной блокчейн-системе, разберемся, каким образом он сможет получать на него и затем переводить с него на другие адреса цифровые активы. Здесь нельзя еще раз не вспомнить аналогию с бухгалтерской книгой, которая состоит из страниц с финансовыми транзакциями: от кого переведено, кому, сколько и за что. Представим, что у нас есть несколько участников в какой-то бизнес-среде, которые постоянно обмениваются товарами, услугами и денежными средствами, а все факты совершения обмена при этом записываются в специальную книгу. Когда один из участников захочет перевести другому определенную сумму, ему для начала необходимо доказать, что он располагает этими средствами. Сделать это можно, только лишь указав на предыдущие входящие транзакции в пользу этого участника, то есть сослаться на них как на доказательство владения определенными активами. Причем сослаться можно не на какую-то одну конкретную транзакцию, а сразу на несколько, если одной будет недостаточно для того, чтобы набрать необходимую сумму для исходящего платежа.
Когда банк переводит деньги с одного счета на другой, он проводит следующие три операции: вычитает сумму перевода и сумму комиссии за перевод со счета отправителя и добавляет сумму перевода на счет получателя. Комиссию же банк оставляет себе как оплату за совершенную посредническую услугу. В блокчейн-системах никаких посредников нет, равно как и средства ниоткуда физически не вычитаются и никуда не прибавляются. Владелец активов просто указывает в транзакции адреса одного или нескольких получателей, то есть опять же формирует ссылки. В итоге транзакция представляет собой набор ссылок на входящие поступления на адрес плательщика, а также набор ссылок на исходящие адреса получателей его платежей. Для таких транзакций в блокчейн-среде оперируют понятиями «входы» и «выходы». Существует правило, что сумма всех средств на «выходах» должна быть равна сумме средств на «входах». Если у владельца адреса нет необходимости тратить все средства на задействованных в транзакции «входах» полностью, он формирует дополнительный «выход» в виде сдачи самому себе, чтобы поддержать равный баланс «входов» и «выходов». Очевидно, что «выход» для отправителя будет являться «входом» для получателя, и он сможет потом на него, в свою очередь, сослаться, когда будет совершать собственные исходящие платежи.
Какие выводы мы можем сделать из описания этой схемы? Во-первых, проанализировав с самого первого (генезисного) блока базы все «входы» на конкретный адрес и все «выходы» с него, можно легко выявить, сколько у владельца данного адреса осталось непотраченных «выходов». Это и есть баланс его счета. То есть баланс как таковой нигде не хранится, а просто вычисляется как сумма всех непотраченных «выходов». Во-вторых, указывая «выход» на конкретный адрес, отправитель предполагает, что в системе существует такой участник, у которого есть закрытый ключ к этому адресу. Иначе, если, например, ввести адрес получателя с ошибкой, то транзакция, на него ссылающаяся, все равно будет принята системой, но средства этой исходящей транзакции будут навсегда потеряны и исключены из обращения. Это связано с тем, что транзакции, помещенные в блок, прошедшие процедуру консенсуса и включенные в общую цепочку блоков, не смогут в будущем быть изменены. Некоторые проекты, например, Биткоин, формируют определенную защиту от ошибки, преобразуя адрес в формате шестнадцатеричного числа в алфавитно-цифровой формат, добавляя в конец полученного адреса его контрольную сумму. При вводе адреса получателя в соответствующее поле формы перевода средств в случае ошибки в расчете и сравнении контрольной суммы система выдаст предупреждение. Также довольно часто используется представление адреса в виде QR-кода, чтобы отправитель мог его отсканировать своим мобильным телефоном и автоматически преобразовать в правильный набор букв и цифр, составляющих адрес получателя.
Возникает вопрос: а может ли участник системы при переводе средств сослаться на «входы», которые ему самому не принадлежат, и каким образом это можно проверить? На самом деле для того, чтобы легитимно сослаться на «входы», необходимо в ссылке указать свой открытый ключ и свою цифровую электронную подпись, сформированную на базе закрытого ключа, связанного с адресом владельца. При помощи алгоритмов проверки цифровой подписи любой участник системы может удостовериться в том, что ссылка на «входы» действительно легитимна. А в случае ошибки проверки данная транзакция просто игнорируется и не включается в блок тем узлом, который его формирует для сети.
Подобная система формирования транзакций и ведения балансов называется UTXO (Unspent Transaction Output – «непотраченные транзакционные выходы»). Как было указано выше, для расчета баланса, связанного с конкретным адресом в системе, необходимо найти и проверить все связанные с ним «входы» и «выходы» с самого начала базы блоков. Плюс этого метода в том, что не нужно отдельно хранить состояние балансов и постоянно их актуализировать, тем самым получая экономию свободного места на носителях. Минус – это время, которое постоянно затрачивается на расчет баланса, особенно если база блоков достаточно выросла в своих размерах. Поэтому ряд проектов все же хранит специальные базы «актуального состояния», где, в частности, находятся и данные о балансах адресов, которые можно быстро оттуда получить.
Теперь рассмотрим, какая еще дополнительная служебная информация может помещаться в транзакции. Во-первых, это идентификатор транзакции с уникальным номером, который не может повторяться. Его получают из хеша самой транзакции, поскольку, как мы знаем, у криптостойких хеш-функций вероятность получения коллизии (то есть одинакового хеша для разных прообразов) очень и очень мала. Во-вторых, в тело транзакции обычно помещают хеш предыдущей транзакции в данном блоке – по аналогии с тем, как это делается в заголовках самих блоков. Наличие этой информации в каждой транзакции преследует ту же самую цель – поддержание целостности хранения данных и ее защиту от несанкционированного изменения. Также при описании ссылок на «входы» указывают открытый ключ адреса и электронную подпись, которая доказывает, что у автора транзакции имеется закрытый ключ от этой пары.
