В рамках этой статьи мы рассмотрим, как работает мультиподпись в протоколе Биткоин. Обратите внимание, что в других криптовалютах и цифровых валютах эти механизмы могут быть реализованы по-другому, — это зависит от модели транзакций. Мы дадим определение мультиподписи, схематично разберем ее структуру на примере транзакции, рассмотрим варианты ее применения и меры предосторожности при работе с ней. Постараемся доступно раскрыть тему предлагаемых улучшений, P2SH, а также на схеме разберем механизм отправки платежа на адрес с мультиподписью. Полагаем, что представленный материал будет интересным читателям, чья деятельность или сфера интересов касается цифровых валют.
Multisignature address
Multisignature address (multisig address, если сокращенно) — это такой Биткоин адрес, к которому привязано сразу несколько пар ECDSA ключей. Каждая пара состоит из личного и открытого ключей. Схемы комбинаций, согласно которым можно использовать эти ключи, могут быть различными. Более того, можно установить условия, при которых нужно будет предоставить несколько подписей, чтобы потратить монеты с адреса.
Bitcoin транзакция, которая использует мультиподпись
Более детально это можно отобразить схематически. Пока достаточно будет представить образно, что multisignature address формируется путем хеширования сразу нескольких сконкатенированных открытых ключей. Детально мы рассмотрим это чуть дальше. На схеме изображена транзакция, которая тратит с multisignature address.
Серым цветом обозначена область заголовка. Он содержит два поля. Синим цветом обозначены два входа, а зеленым — два выхода. В первом входе находятся заполненные поля: записано хеш-значение предыдущей транзакции, которая тратит данные монеты, номер выхода и т. д. Поле scriptSig содержит открытый ключ и подпись, что характерно для обычной транзакции.
Обратим внимание на второй вход транзакции. В поле scriptSig находится другая комбинация данных: перечислено два открытых ключа и две подписи. Они должны проверяться этими открытыми ключами соответственно. Это и есть тот вход транзакции, который тратит монеты с multisignature address. Именно так будет выглядеть доказательство владения монетами.
Варианты комбинаций ключей
Существуют различные комбинации ключей при использовании multisignature address. Наиболее используемыми вариантами являются 2-из-2, 2-из-3, а также 3-из-3. Максимально возможный вариант — 15-из-15.
Самая простая комбинация — 2-из-2. Она подразумевает, что есть multisignature address, к которому привязано две пары ключей, по сути, захешировано два открытых ключа подряд и получен некоторый адрес. Чтобы потратить монеты с этого адреса, нужно предоставить две подписи, которые будут верифицироваться двумя имеющимися открытыми ключами, конкатенация и хеширование которых в нужном порядке должны давать то же значение адреса. Обобщая, есть два заранее установленных ключа и нужны обязательно две подписи, которые будут проверяться этими ключами соответственно.
Схема использования multisignature address 2-из-3 подразумевает, что любые два ключа из трех заранее установленных должны быть задействованы для проверки двух подписей, представленных в качестве доказательства владения монетами. Иначе говоря, чтобы потратить монеты, нужно предоставить две подписи, которые будут проверены двумя открытыми ключами из предустановленных трех.
Комбинация 3-из-3, как вы уже поняли, требует три подписи, которые будут проверяться тремя заранее установленными ключами. Максимальной в отношении количества необходимых подписей и открытых ключей будет схема 15-из-15.
Давайте пройдемся по вариантам применения указанных комбинаций.
2-из-2
Представьте, что муж и жена захотели вести общий бюджет.
Они договариваются, что только при согласии каждого из них средства из бюджета будут тратиться на определенные нужды. С помощью Биткоина это можно реализовать достаточно просто. Они создают multisignature address по данной схеме, где один ключ контролирует жена, а второй — муж. Тогда все доходы семья будет получать на такие адреса, а тратиться средства смогут только по обоюдной договоренности.
Предугадывая ваш вопрос о сценарии, когда муж и жена не договорятся, представим, что жена считает необходимой покупку стиральной машины, потому что она устала стирать руками, а муж считает, что это не такая уж и тяжелая работа, а будет целесообразнее потратить все монеты на последнюю модель PlayStation и проводить таким образом досуг. Жена обижается на мужа и съедает бумажку со своим личным ключом, делая невозможной трату с этого адреса вообще.
Как избежать такой ситуации и защитить монеты от окончательной потери монет?
Есть возможность создать транзакцию, которая потратит все средства с нужного адреса, несмотря на то, что сумма заранее неизвестна. На вход подается не сумма, а ссылка на транзакцию, откуда эти монеты могут быть потрачены. Есть такое понятие, как hash type, — это способ покрытия подписью транзакций. Он позволяет создать подпись заранее, а некоторые данные транзакции, например вход, можно будет подставить позже. Таким образом, можно создать транзакцию, которая потратит монеты из еще не существующей транзакции, и применить ее позже, т. е. когда это будет нужно.
Более того, на эту транзакцию можно поставить ограничение LockTime. Оно позволяет не подтверждать транзакцию сразу, а отложить ее на некоторый срок. Итак, муж и жена сразу после создания multisignature address, еще до получения любых платежей, могут создать две LockTime транзакции, в которых все будущие монеты будут перенаправлены на обычные адреса мужа и жены, которые они контролируют самостоятельно. При этом транзакции будут отсроченными и могут быть подтверждены только, например через два месяца. Эти транзакции могут быть распечатаны на бумаге и храниться в сейфе у каждого по отдельности. Если возникнет ситуация, когда монеты находятся на балансе multisignature address, а ключи потеряны (один или оба), то монеты становятся замороженными. Но есть LockTime транзакция. Тот, кто опубликует такую транзакцию, сможет вывести эти средства на действующий внешний адрес. Монеты будут сохранены. Это был упрощенный пример, однако возможны и более сложные механизмы.
2-из-3
Допустим, есть группа людей, у которых есть общий бюджет.
Они создают multisignature address, в котором есть три ключа, но для подписи транзакции достаточно двух подписей. При согласии участников, которые составляют большинство группы, эти средства могут быть потрачены. Иначе говоря, любые два участника из трех могут потратить монеты. Им для этого достаточно распространить транзакцию в сеть.
Пример с Wallet сервисом
Есть более интересный способ применения комбинации 2-из-3 и он используется в так называемых сервисах кошельков. Сервис кошелька в данном контексте не стоит путать с обычным Биткоин кошельком, который пользователь контролирует самостоятельно. Сервис не предоставляет полноценное хранилище для монет и не владеет ими, а только оказывает услуги для удобной работы.
Если представить подобную ситуацию схематично, то один ключ принадлежит непосредственно сервису, второй генерируется только пользователем (и только ему известен), третий ключ генерируется и хранится тоже пользователем, но отдельно. После этого вычисляются открытые ключи, соответствующие этим личным, и составляется multisignature address. Туда поступают монеты и теперь условия траты ограничиваются.
Представим, что мы имеем дело с некоторым веб-сервисом и на его ресурс можно войти через браузер. Браузером подгружается код Биткоин кошелька, который по этому адресу получает список не потраченных монет, рассчитывает их баланс и готов потратить. Если пользователь хочет потратить монеты, то он прямо в браузере составляет транзакцию и подписывает ее своей (одной из необходимых) подписью.
Заметим, что личный ключ пользователь может получать либо из своего пароля, либо ключ может случайным образом генерироваться, шифроваться паролем пользователя и храниться у сервиса. Тогда пользователь посылает запрос сервису, получает контейнер с зашифрованным ключом, расшифровывает своим паролем и уже имеет доступ к своему личному ключу.
Когда пользователь подписывает транзакцию, она отправляется на сторону сервиса, чтобы он поставил вторую необходимую подпись и отправил транзакцию. Сервис уточняет факт необходимости подписания транзакции через второй канал аутентификации, то есть через установленный заранее другой канал, которым может быть звонок на мобильный телефон, SMS, сообщение на электронную почту и прочие способы альтернативной коммуникации (вплоть до личного визита, если того требует уровень безопасности). Когда сервис удостоверился, что запрос на подпись транзакции действительно инициирует зарегистрированный пользователь, он ставит недостающую подпись с помощью своего ключа. После этого транзакция становится валидной и может быть распространена в сеть для подтверждения.
Третий ключ используется в тех случаях, когда сервис отказывает в обслуживании. ПО генерирует этот ключ и предлагает его сохранить удобным для вас способом. Пользователь обычно хранит его в надежном месте. Если сервис отказывает в обслуживании, то пользователь может подписать транзакцию своими ключами (вторым и третьим). Если же второй ключ хранился на стороне сервиса, то защищенный контейнер с этим ключом будет заранее отправлен пользователю по альтернативному каналу передачи данных, например на электронную почту. Пользователь расшифровывает контейнер с ключом при помощи своего пароля.
Пользователь получает два необходимых личных ключа и вводит в специальное ПО, которое сервис предоставил заранее. Далее это ПО работает уже автономно на компьютере пользователя, без участия сервиса. Стоит отметить, что этим ПО следует пользоваться только в крайних случаях, когда сервис отказывает в обслуживании (т. е. его взломали, он поврежден или перестал существовать). Тогда пользователь подписывает транзакцию своими ключами и переводит монеты куда нужно.
Преимущества Wallet сервисов с подписью 2-из-3
На преимуществах таких Wallet сервисов остановимся подробнее. Это безопасный способ хранения, потому что сервис не владеет всем необходимым набором ключей — он владеет только одной частью, которой недостаточно, чтобы завладеть средствами. Причем доступа к средствам не имеет ни сам сервис, ни хакер, который его может взломать.
Удобство такого подхода состоит в том, что пользователю не обязательно иметь защищенный доступ к этому сервису. Он может иметь обычное устройство, которое может быть заражено вирусами или контролироваться мошенниками, а данные могут быть скомпрометированы или заменены. Но злоумышленнику недостаточно владеть только этим устройством, потому что из него можно добыть только одну из двух подписей.
Еще одно преимущество состоит в том, что если сервис отказывает в обслуживании, то пользователь не теряет доступ к своим монетам. Это были только некоторые из возможных схем использования multisignature адресов, которых достаточно для знакомства.
Меры предосторожности при работе с мультиподписью
И теперь стоит поговорить о мерах предосторожности, касательно мультиподписи. В случае 2-из-2 нужно создавать LockTime транзакции, которые смогут перевести заблокированные средства на определенный адрес. Это актуально, когда происходит потеря ключей.
Если вы используете multisignature address 2-из-3, то очень важно хранить ключи в надежном месте. В случае потери одного из трех ключей нужно сразу переводить средства и не дожидаться момента, когда будут потеряны 2 ключа из 3 необходимых.
Как работает Bitcoin Script (на примере)
Чтобы понять детальнее, как работает мультиподпись, нам нужно немного поговорить о том, как работает Bitcoin Script: как задаются правила траты монет, как им удовлетворять, какие существуют операции описания правил, что такое Bitcoin Script и как устроено его выполнение.
Рассмотрим пример простого случая траты монет, где есть обычный адрес, к которому привязан хеш одного открытого ключа, соответствующий скрипт, который задает условия траты, и скрипт, который удовлетворяет этим условиям.
На схеме слева мы видим стек данных, а справа сам скрипт. Первые две части строки script — signature и открытый ключ, — так называемый unlocking script, то есть скрипт, который указывается во входе транзакции, которая тратит монеты. После этого следует набор данных, который указывается в выходе транзакции — это называется locking script. Иначе говоря, тут представлена конкатенация двух скриптов: скрипт, отпирающий монеты, и скрипт, запирающий монеты. В случае, когда транзакция будет валидироваться уже узлом сети, эти два скрипта объединяются для выполнения проверки условий траты монет. Таким образом сначала идет unlocking script, а за ним следует locking script.
После этого идет последовательное выполнение полного набора операндов и данных. Точка выполнения идет последовательно по каждому операнду и каждому участку данных. Если точка выполнения попадает на участок данных, то они помещаются в стек. Как мы видим на схеме, курсор выполнения скрипта в верхней части указывает на данные подписи, которые после помещаются в стек.
Далее, курсор выполнения указывает на открытый ключ — он также помещается в стек.
Третьим шагом идет выполнение операции дубликации, что подразумевает копирование верхушки стека и помещение этих данных повторно в стек.
После этого выполняется хеширование с помощью хеш-функции Hash-160. Это значит, что верхушка стека хешируется сначала алгоритмом SHA-2 на длине 256 бит, а потом функцией RIPEMD-160 на длине 160 бит. Операция точно такая, как при хешировании открытого ключа и получении адреса. Фактически это она и есть.
Мы имеем стек, подпись, открытый ключ и хеш-значение открытого ключа. Курсор выполнения скрипта указывает на адрес, который был задан в выходе транзакции, то есть то хеш-значение открытого ключа, которое указывалось, когда монеты на него отправлялись. Эта часть данных тоже попадает в стек.
Следующей выполняется операция проверки на идентичность equal verify.
Два верхних элемента стека сравниваются. Если они побайтово полностью одинаковые, то эти данные удаляются из стека и считается, что проверка прошла успешно. После этого в стеке остаются signature и public key. Соответственно, операция check signature берет эти два операнда и проверяет подпись открытым ключом. Если подпись верна относительно транзакции, которая сейчас проходит проверку, потому что подпись покрывает часть транзакции, соответственно, нужно взять хеш-значение от определенных полей этой транзакции. Это задается отдельным байтом структуры hash type, то есть берется хеш-значение и подается на вход верификации подписи вместе с самой подписью и открытым ключом. Если проверка происходит корректно, то результат проверки — true, это значение кладется в стек. На этом выполнение скрипта заканчивается. Данные передаются в вызывающую функцию и там проверяются. Если в стеке находится значение true, значит верификация данного входа транзакции прошла корректно. Если все входы транзакции были корректно проверены, то и вся транзакция считается правильной.
Мы познакомились с тем как работает Bitcoin Script для проверки простых входов и выходов транзакции. Теперь мы поговорим о том, как организована и как работает multisignature при использовании Bitcoin Script.
P2SH
Однажды было предложено BIP16, которое задает новый концепт в протоколе Биткоина — так называемый pay to script hash (P2SH). Это возможность задать правила траты монет не открытым скриптом, где вы подряд прописываете операнды и некоторые данные, которые потом выполняются рассмотренным нами образом, а в виде хеш-значения от нужного вам скрипта, то есть контрольной суммы от этих операндов. Это позволило в выходе транзакции задавать большие и сложные условия траты монет, но при этом сам выход оставался коротким.
Чтобы потратить эти монеты при таких условиях, на входе транзакции нужно указать данные, удовлетворяющие этому скрипту, и исходный скрипт целиком, чтобы доказать, что вы знаете, какие условия были заданы при отправке монет, чтобы хеш-значение исходного скрипта совпало с адресов на который были отправлены монеты. Иначе говоря, доказать, что вы знаете условия, и удовлетворить этим условиям.
Это предложение по улучшению Биткоина было принято 3 января 2012 года. Фактически в день рождения Биткоина. Сейчас оно активно применяется для реализации multisignature address.
Как работает P2SH
Давайте рассмотрим на примере, как это работает. Для построения транзакции нам понадобится иметь представление о таких понятиях, как Redeem Script, Locking Script и Unlocking Script.
Redeem Script содержит в себе открытые ключи, к которым будет привязан multisignature address. В данном случае мы рассматриваем комбинацию ключей “2-из-5”. Сначала идет значение 2, то есть мы указываем, что необходимо будет 2 подписи, которые будут проверяться соответствующими открытыми ключами. После этого следуют открытые ключи, в нашем случае их 5. Далее мы указываем значение 5, так как мы указали 5 открытых ключей, а когда данные будут считываться в обратном порядке это значение понадобиться, чтобы понять, сколько ключей нужно прочесть. После этого указывается операция проверки мультиподписи (operation check multisignature).
Locking Script — скрипт, который указывается в выходе транзакции, которая платит на multisignature address. Здесь будет производиться операция получения хеш-значения, с которой мы подробно уже знакомились. Далее следует хеш-значение Redeem Script, которое занимает 20 байт. После этого проводится операция по проверке соответствия данных фактическому хеш-значению.
Unlocking Script является конкатенацией скриптов на входе транзакции со скриптами в выходе транзакции, которая платила на этот адрес. Есть две подписи, необходимые для траты монет, и полный Redeem Script, который позже будет захеширован и проверен на предмет соответствия адресу, на который были отправлены монеты. После этого скрипт будет выполняться целиком, в том числе для проверки мультиподписи.
Важно, что есть ограничения на максимальный размер для каждого из перечисленных скриптов и это 520 байт. Это число было рассчитано, исходя из того, что в Unlocking Script может поместиться максимум 15 подписей и 15 соответствующих открытых ключей, а также несколько операций для проверки этих значений. Именно так было получено некоторое число, которое при округлении дало 520 байт. Следует сказать, что это число получено с расчетом на то, что multisignature address типа “15 из 15” является достаточно разумным пределом для практического применения. Redeem Script при использовании большого количества подписей становится очень большим по объему. Тот пользователь, который использует multisignature address или другие P2SH адреса, при трате монет с них имеет очень большие по объему транзакции. Это значит, что для подтверждения своих транзакций ему придется платить большие комиссии.
Преимущества P2SH
Отдельно рассмотрим преимущества P2SH. Первое из них состоит в том, что такие адреса могут быть закодированы в привычный вид с использованием Base58, в котором их длина составляет 34 символа. В соответствии с BIP13, которое определяет правила установки версионного байта для Биткоин адресов, кодированных Base58Check, начинаться адрес будет с тройки, то есть туда вставляется определенный версионный байт.
На примере вы можете видеть P2SH адрес.
3P14159f73E4gFr7JterCCQh9QjiTjiZrG
Это может быть не обязательно multisignature address. Redeem Script может описывать не только multisignature address, но и другие сложные правила траты монет.
Добавим, что это не единственный способ организации мультиподписи в Биткоине. Можно и не использовать P2SH, а в выходе, который будет платить на multisignature address, не хеш-значение от скрипта, а сам скрипт, то есть перечислять прямо в выходе все открытые ключи и ставить операцию проверки multisignature. Однако при оправке монет на такой адрес вы сразу разглашаете открытые ключи, так как они будут находиться в открытом доступе и в этот момент на них будут храниться монеты.
И еще одним недостатком является то, что отправитель монет на multisignature address имеет транзакцию большого объема, за которую придется платить большую комиссию. Вряд ли отправитель захочет переплачивать за то, что получатель хочет использовать multisignature. P2SH дает возможность переложить комиссионные затраты на получателя. Если получатель хочет принимать монеты на multisignature address, то он сам будет оплачивать большие транзакции, что является более справедливым подходом.
Добавим, что P2SH позволяет реализовать разные комбинации такого multisignature (2-из-2, 2-из-3 и другие).
Схематично рассмотрим отправку на multisignature address.
Представим, что Алиса хочет заплатить Бобу, который использует только multisignature addresses. Для этого Боб локально на своем компьютере (кстати, вместо Боба может быть какая-то организация) генерирует несколько личных ключей, получает из них соответствующие открытые ключи, которые конкатенируются определенным образом. Чаще всего открытые ключи представлены сначала закодированными Base58Check, а потом они сортируются в алфавитном порядке, после чего конкатенируются.
Такой подход оправдывает себя, когда требуется перерасчет открытых ключей из личных. Их нужно конкатенировать точно в таком же порядке, потому что следующим шагом будет создание Redeem Script и его хеширование. Если точно такие же ключи попадут в Redeem Script, но в другом порядке, мы получим другое хеш-значение и другой адрес. Это повлечет за собой определенные недоразумения. Поэтому перед конкатенацией открытые ключи нужно отсортировать согласно некоторому правилу. И чаще всего используют сортировку по алфавиту в системе счисления Base58.
Итак, Боб посчитал хеш-значение от Redeem Script. Он может его представить в виде 20 байт и отправить Алисе, сказав, что это multisignature address с использованием P2SH. Однако Боб может закодировать его с версионным байтом, как обычный адрес, и просто отправить Алисе. Алиса поймет по версионному байту, что это multisignature address, составит транзакцию и соответствующим образом заполнит ее выход, чтобы Боб получил свои монеты. Далее она распространяет транзакцию в сеть. Они дожидаются подтверждения и Боб принимает платеж от Алисы. Замен Боб, например, оказывает услугу или передает товар.
Наступает момент, когда Боб хочет потратить эти монеты. Следует понимать, что полный Redeem Script не был разглашен публично, пока монеты находились на его multisignature адресе. И даже Алиса не видела, какие именно открытые ключи использовал Боб, сколько их там было и т. д. Она вообще не знает, по каким правилам этот P2SH адрес составлен, multisignature address это или нет и т. д. Соответственно, атаки на электронно-цифровую подпись (на эллиптическую кривую) еще невозможны.
Допустим, Боб хочет отправить платеж Еве.
Она генерирует новый адрес и дает его Бобу. Он создает заготовку транзакции, во входе которой он указывает ту транзакцию, в которой он получил монеты от Алисы, а на выходе — адрес Евы. Теперь он должен предоставить доказательства владения монетами, которые он тратит. Для этого он берет два своих личных ключа (выше мы упоминали, что его multisignature address предполагает вариант “2-из-5”), из которых вычисляет две подписи к данной транзакции. Далее, он берет полный Redeem Script и добавляет его во вход транзакции.
Обратите внимание, что данный Redeem Script должен храниться у Боба на компьютере целиком либо он должен запомнить порядок, в котором он использовал открытые ключи для составления этого скрипта. Если же он применял определенные правила сортировки, то он должен запомнить их. Он также должен помнить, что к определенным личным ключам привязан multisignature address. Без этих знаний Боб не знал бы, какими из его личных ключей оперировать и в каком порядке их следует хешировать для получения нужного адреса.
Итак, у него есть две подписи и полный Redeem Script. Транзакция считается верной и Боб ее распространяет в сеть, а после дожидается подтверждения. Это основное из того, что касается траты с multisignature address.
Вопросы
Сейчас мы переходим к вашим вопросам.
— Можно ли один и тот же кошелек запустить одновременно на трех разных компьютерах и начать синхронизацию?
Скорее всего, речь идет о каком-то узле сети: либо SPV узле, либо полном узле. Было использовано несколько разных компьютеров и один и тот же кошелек. А под кошельком подразумеваются личные ключи. Есть несколько полных узлов, которые реализуют функциональность кошельков. На этих узлах мы вставляем одни и те же личные ключи и начинаем синхронизацию. Скорее всего, при полной синхронизации с сетью мы увидим на каждом кошельке, который использует свой узел, один и тот же баланс. Если же вы увидите изменения на одном узле, то после синхронизации с сетью вы увидите точно такие же изменения на всех остальных узлах. Транзакция не остается в секрете, она распространяется по всем узлам, которые ее верифицируют и отображают соответствующие изменения, если это касается их адресов. Фактически да, можно использовать одни ключи на нескольких узлах, но все транзакции тоже будут синхронизироваться автоматически. Биткоины точно от этого не удвоятся и, более того, не утроятся.
— Как P2SH работает с Segregated Witness?
Segregated Witness — это такая структура транзакций, где доказательства владения монетами выносятся в отдельную структуру, они не попадают в блокчейн, но при валидации транзакций они распространяются вместе, то есть все валидаторы проверяют правильность транзакций по отдельной структуре с доказательством. После подтверждения транзакции доказательства не сохраняются, так как смысла это не имеет. Есть также преимущества в построении таких цепочек транзакций, в которых определенные монеты без фактического подтверждения в текущей транзакции уже тратятся в следующей, построенной на ее основе, но они не распространяются в сеть. Таким образом, формируются цепочки транзакций, которые не разглашают доказательства владения монетами. Это облегчает передачу данных и добавляет приватность. Для Segregated Witness был использован другой тип адресов, он содержит немного другие операнды. Есть возможность отправлять монеты, которые хранятся на обычных адресах, в том числе P2SH адресах, на адреса Witness P2SH.
— Адреса с тройки начинаются в Lighting Network?
По BIP13 определены правила, по которым выбирается версионный байт для Биткоин адресов в test-нете, других валютах и т. п. Да, Lighting Network использует multisignature адреса, которые тоже применяют P2SH способ задания условий.
— Почему нельзя персонализировать кошелек, то есть привязать его к конкретной личности?
Биткоин как протокол платежной системы не требует идентификации личности кошелька, потому что он работает по законам математики, а математика не позволяет описать человека, как личность. Более того, это не является необходимым условием для проверки транзакций. Здесь достаточно электронно-цифровой подписи. Кто может генерировать такие подписи, тот и является их владельцем — к протоколу Биткоина это не относится. Следовательно, подписью может владеть человек, группа из нескольких человек, робот и т. д.
Что касается персонализации, то если вы устанавливаете связь конкретного адреса с конкретной личностью, то вы нарушаете приватность и можете деанонимизировать часть сети с определенной долей вероятности. В общем случае база данных открыта, но никаких данных о личностях в ней нет.
— Если валюта не майнится, а таких валют 70-80%, можно ли им доверять?
Хорошо написано, что это валюта, а не криптовалюта, потому что криптовалюта работает по таким же принципам, как и Биткоин, то есть все процессы максимально децентрализованы: эмиссия, верификация транзакций, хранение данных, принятие изменений и т. д. Но есть такие валюты, мы будем называть их цифровыми валютами, у которых не все из перечисленных процессов децентрализованы. Одним из вариантов может быть централизованная эмиссия, то есть нет такого понятия как добыча, майнинг, то есть нет решения сложной задачи. По такому принципу работает Ripple, Stellar, цифровая валюта NXT, Cardano. Там были применены другие принципы распространения монет среди пользователей, например, через ICO, доказательство личности и т. д. Из-за того, что не все процессы могут быть децентрализованы и независимы, нельзя любую цифровую валюту назвать криптовалютой. Кроме того, вопрос о доверии к той или иной валюте носит личностный характер. Вы сами принимаете решение о размере этого доверия. Нужно учитывать цели, для которых валюта используется, а также ее риски и ограничения.
Автор: Distributed Lab
