Читаем 1c2b9509b53cb0837976a7dc6c8bcd37 полностью

этого участника, то есть сослаться на них как на доказательство владения

определенными активами. Причем сослаться можно не на какую-то одну

конкретную транзакцию, а сразу на несколько, если одной будет недостаточно

для того, чтобы набрать необходимую сумму для исходящего платежа.

Когда банк переводит деньги с одного счета на другой, он проводит следующие

три операции: вычитает сумму перевода и сумму комиссии за перевод со счета

отправителя и добавляет сумму перевода на счет получателя. Комиссию же

банк оставляет себе как оплату за совершенную посредническую услугу. В

блокчейн-системах никаких посредников нет, равно как и средства ниоткуда

физически не вычитаются и никуда не прибавляются. Владелец активов просто

указывает в транзакции адреса одного или нескольких получателей, то есть

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

ссылок на входящие поступления на адрес плательщика, а также набор ссылок

на исходящие адреса получателей его платежей. Для таких транзакций в

блокчейн-среде оперируют понятиями «входы» и «выходы». Существует

правило, что сумма всех средств на «выходах» должна быть равна сумме

средств на «входах». Если у владельца адреса нет необходимости тратить все

средства на задействованных в транзакции «входах» полностью, он формирует

дополнительный «выход» в виде сдачи самому себе, чтобы поддержать

равный баланс «входов» и «выходов». Очевидно, что «выход» для

отправителя будет являться «входом» для получателя, и он сможет потом на

него, в свою очередь, сослаться, когда будет совершать собственные

исходящие платежи.

Какие выводы мы можем сделать из описания этой схемы? Во-первых, проанализировав с самого первого (генезисного) блока базы все «входы» на

конкретный адрес и все «выходы» с него, можно легко выявить, сколько у

владельца данного адреса осталось непотраченных «выходов». Это и есть

баланс его счета. То есть баланс как таковой нигде не хранится, а просто

вычисляется как сумма всех непотраченных «выходов». Во-вторых, указывая

«выход» на конкретный адрес, отправитель предполагает, что в системе

существует такой участник, у которого есть закрытый ключ к этому адресу.

Иначе, если, например, ввести адрес получателя с ошибкой, то транзакция, на

него ссылающаяся, все равно будет принята системой, но средства этой

исходящей транзакции будут навсегда потеряны и исключены из обращения.

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

консенсуса и включенные в общую цепочку блоков, не смогут в будущем быть

изменены. Некоторые проекты, например, Биткоин, формируют определенную

защиту от ошибки, преобразуя адрес в формате шестнадцатеричного числа в

алфавитно-цифровой формат, добавляя в конец полученного адреса его

контрольную сумму. При вводе адреса получателя в соответствующее поле

формы перевода средств в случае ошибки в расчете и сравнении контрольной

суммы система выдаст предупреждение. Также довольно часто используется

представление адреса в виде QR-кода, чтобы отправитель мог его

отсканировать своим мобильным телефоном и автоматически преобразовать в

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

Возникает вопрос: а может ли участник системы при переводе средств

сослаться на «входы», которые ему самому не принадлежат, и каким образом

это можно проверить? На самом деле для того, чтобы легитимно сослаться на

«входы», необходимо в ссылке указать свой открытый ключ и свою цифровую

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

адресом владельца. При помощи алгоритмов проверки цифровой подписи

любой участник системы может удостовериться в том, что ссылка на «входы»

действительно легитимна. А в случае ошибки проверки данная транзакция

просто игнорируется и не включается в блок тем узлом, который его

формирует для сети.

Подобная система формирования транзакций и ведения балансов называется

UTXO (Unspent Transaction Output — «непотраченные транзакционные

выходы»). Как было указано выше, для расчета баланса, связанного с

конкретным адресом в системе, необходимо найти и проверить все связанные

с ним «входы» и «выходы» с самого начала базы блоков. Плюс этого метода в

том, что не нужно отдельно хранить состояние балансов и постоянно их

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

носителях. Минус — это время, которое постоянно затрачивается на расчет

баланса, особенно если база блоков достаточно выросла в своих размерах.

Поэтому ряд проектов все же хранит специальные базы «актуального

состояния», где, в частности, находятся и данные о балансах адресов, которые

можно быстро оттуда получить.

Теперь рассмотрим, какая еще дополнительная служебная информация может

помещаться в транзакции. Во-первых, это идентификатор транзакции с

уникальным номером, который не может повторяться. Его получают из хеша

самой транзакции, поскольку, как мы знаем, у криптостойких хеш-функций

вероятность получения коллизии (то есть одинакового хеша для разных

прообразов) очень и очень мала. Во-вторых, в тело транзакции обычно