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