Нараян Прасти

Глава 1 
____________________________________ 
[ 30 ] 
___________________________________ 
телей для взаимодействия, потому что разные клиенты имеют разные наборы про-
веренных пользователей. Все пользователи могут захотеть использовать одного 
клиента, создавая, таким образом, монополию среди приложений. Но это не глав-
ная проблема, потому что если один клиент не способен правильно проверить 
идентификатор, пользователи могут перейти к использованию другого клиента, не 
теряя свои критические данные, хранящиеся децентрализованно. 
Проверка подлинности пользователя в приложении затрудняет уход от ответст-
венности после совершения каких-либо мошеннических действий, предотвраща-
ет использование приложения лицами с криминальным прошлым и дает пользо-
вателям уверенность, что другой пользователь является тем, за кого себя выда-
ет. Неважно, какая процедура применяется для проверки пользователя — у него
всегда остается возможность выдать себя за другого. Цифровые идентификато-
ры и копии бумажных документов в равной степени могут быть украдены и ис-
пользованы без согласия владельца. Важно лишь максимально затруднить под-
мену личности, а также собрать достаточный объем данных для идентификации
пользователя и доказательства мошеннической деятельности. 
Учетные записи пользователей 
Приложения часто используют механизм 
учетных записей
. Данные, связанные
с учетной записью, должны быть доступны для редактирования только владельцу 
учетной записи. Децентрализованные приложения не могут обеспечить эту функ-
циональность на основе пары логин-пароль, потому что наличие пароля еще не до-
казывает, что изменение учетной записи было запрошено владельцем. 
Существует несколько способов реализации учетных записей пользователей в ДП. 
Но самый популярный путь — это использование пары открытого и закрытого 
ключей для представления владельца учетной записи. Хеш открытого ключа явля-
ется уникальным идентификатором учетной записи. Чтобы внести правки в учет-
ную запись, пользователь должен подписать изменения своим закрытым ключом. 
Мы должны полагать, что пользователи хранят свои закрытые ключи надежно
и безопасно. Если пользователи теряют свои секретные ключи, они навсегда теря-
ют доступ к своей учетной записи. 
Доступ к централизованным приложениям 
ДП не должно зависеть от централизованных приложений, потому что такая зави-
симость станет точкой отказа. Но иногда не остается другого выхода. Например, 
если приложению нужно получить счет футбольного матча, где оно возьмет эти 
данные? Разумеется, одни ДП могут зависеть от других ДП, но зачем FIFA созда-
вать децентрализованное приложение? FIFA не станет создавать свое ДП лишь по-
тому, что другие ДП нуждаются в данных. Децентрализованное приложение для 
предоставления счета матча не имеет смысла, поскольку будет полностью под кон-
тролем FIFA. 

---

Децентрализованные 
приложения 
____________________________________ 
[ 31 ] 
___________________________________ 
Итак, в некоторых случаях ДП вынуждено получать данные из централизованного 
приложения. Но вот проблема — как ДП может убедиться, что данные не подмени-
ли при передаче, и они являются актуальным ответом на запрос? Есть несколько 
способов решить эту проблему в зависимости от архитектуры ДП. Например,
в Ethereum смарт-контракты, которые нуждаются в доступе к централизованным 
API, могут в качестве посредника воспользоваться сервисом Oraclize, потому что 
смарт-контракты не выполняют прямые HTTP-запросы. А сервис Oraclize предос-
тавляет доказательство подлинности TLSNotary для данных, собираемых с центра-
лизованных сервисов. 
Внутренняя валюта приложений 
Чтобы централизованное приложение сохраняло работоспособность в течение дли-
тельного времени, его владельцу нужно как-то извлекать прибыль. У ДП нет вла-
дельца, но все равно узлы ДП нуждаются в оборудовании и сетевых ресурсах
4
для 
поддержания работы. То есть узлы ДП должны приносить какую-то выгоду в обмен 
на усилия по поддержанию их работоспособности. Именно здесь вступает в игру 
внутренняя валюта
. Большинство ДП имеют встроенную внутреннюю валюту. 
Точнее, большинство 
успешных
ДП имеют встроенную внутреннюю валюту.
Протокол консенсуса определяет, сколько валюты получает узел. В зависимости от 
протокола, только определенные узлы получают валюту. Мы также можем сказать, 
что лишь те узлы, которые способствуют поддержанию и управлению ДП, зараба-
тывают валюту. Узлы, которые только считывают данные, не получают ничего. 
Например, в Bitcoin только майнеры зарабатывают биткойны за успешно добытые 
блоки.
Самый важный вопрос о цифровой валюте — почему ее вообще кто-то ценит? Со-
гласно экономической теории, все, что имеет достаточный спрос и недостаточное 
количество, имеет ценность. 
Заставляя пользователей расплачиваться внутренней валютой приложения, мы ре-
шаем проблему спроса. Чем больше пользователей используют ДП, тем больше 
спрос на валюту и тем выше она ценится. 
Установление фиксированного объема выпускаемой валюты приводит к ее нехват-
ке и повышает стоимость
5
. Обычно валюта вводится в оборот постепенно, чтобы 
вновь подключившиеся узлы тоже имели возможность заработать. 
4
А также в обслуживающем персонале, который в общем случае не согласен работать бесплатно.
5
Иногда не только ограничивают объем выпускаемой валюты, но и вводят механизм сделок, при ко-
тором уничтожение небольшого количества валюты является условием успешного завершения тран-
закции. Кроме защиты от массового мошенничества такой метод повышает стоимость валюты.

---