Делаем блокчейн удобным для пользователя

https://imaginationtarget.info/delaem-blokchejn/

В течение нескольких месяцев мы создавали Proof-of-Technology в рамках программы Frontier Technology Livestreaming (FTL) Министерства международного развития Великобритании (Department for International Development, DFID). Технология, которая должна быть «проверена» в этом случае, — это блокчейн, особенно в рамках системы управления гуманитарными цепочками поставок — вот ссылка на средний пост для получения дополнительной информации по этой теме.

Мы продвигались по плану, успешно завершили наш первый спринт и усердно работали над вторым. Это будет последний спринт перед тем, как мы перейдем к этапу тестирования в реальном времени, где мы проведем полевые испытания системы с реальной цепочкой поставок гуманитарной логистики. «Реальная жизнь» в этом случае будет означать отслеживание регулярных поставок товаров в зону бедствия с использованием приложения, которое мы создаем. В этом посте я хотел бы поделиться некоторыми из наших попыток сделать блокчейн максимально удобным и безопасным для пользователей, две цели, которые обычно рассматриваются как диаметрально противоположные.

Во-первых, при реализации разрешенного (более детального) решения для блокчейна наиболее важно учитывать взаимодействие с пользователем (UX): если и через какую среду пользователь взаимодействует с блокчейн-системой? Можно представить решения, начиная от полностью «авторитетной» системы, в которой конечный пользователь, к счастью, не осведомлен о каких-либо действиях блокчейна, происходящих в фоновом режиме, подобно тому, как немногие интернет-пользователи точно знают, как проверяются пароли при входе в службу, к продуктам, в которых каждому пользователю доверяют (а в некоторых случаях требуется) настроить и запустить собственный узел, управлять ключами, взаимодействовать через вызовы API и проверять все действия. Мы пытаемся найти какое-то среднее положение, рассуждая о том, что наши пользователи на самом деле могут использовать и ценить в системе.

В нашем случае пользователи варьируются от технически подкованных профессионалов DFID с современным подключением к оборудованию и вплоть до персонала провайдеров логистических услуг с ограниченными возможностями подключения и смартфонов первого поколения с Android. Поскольку мы работаем в PoT с относительно ограниченными областями и временными рамками, мы решили сделать некоторые предположения относительно ограничений пользователя. Грубо говоря, мы предполагаем, что все наши пользователи:

Говорят и читают по-английски

Имеют устройство (мобильное или нет) с установленным обновленным браузером
Имеют работающее интернет-соединение с достаточной пропускной способностью для обслуживания веб-приложения на основе React (React — одна из самых распространенных сред веб-программирования для пользовательских интерфейсов)
Эти допущения позволяют нам ориентироваться на очень широкую аудиторию и расширять функциональность в будущем, например, для случаев автономного использования.

Мы делаем это путем создания прогрессивного веб-приложения, то есть надежного, быстрого и достаточно гибкого, чтобы его можно было использовать на мобильных или настольных компьютерах, с простой процедурой входа в систему, чтобы отделить типы пользователей друг от друга. Приложение размещено на нашем облачном провайдере, который подключается к базе данных, а также к нашему блокчейну.

Это означает, что специалист по планированию логистики в офисах DFID может получить доступ к веб-приложению, открыв стандартный браузер, введя адрес приложения в окне URL-адреса, и затем может войти в систему, используя свое личное имя пользователя и пароль. Точно так же пользователь на «земле» может принять заказ на свою часть груза, войдя в приложение через браузер на мобильном устройстве.

После того, как мы установили точку доступа для пользователей к блокчейну, нам нужно было определить, какие действия пользователю необходимо или разрешить предпринять в отношении блокчейн-системы. Наша цель состояла в том, чтобы дать пользователям возможность как можно больше контролировать наиболее важные части в цепочке поставок. Частично это было сделано для того, чтобы обеспечить доверие к системе — цель иметь цепочку блоков состоит в том, чтобы удалить единую точку контроля данных, и частично, чтобы четко донести до пользователя, какая именно информация поступает в цепочку блоков.

Мы работаем с системой на основе Ethereum, которая позволяет заключать умные контракты. Это означает, что мы могли бы закодировать большие части бизнес-логики, например, в цепочке, если захотим. Но чем больше функциональности в сети, тем больше пользователей должны взаимодействовать с блокчейном. Взаимодействия, которые влияют на сложность цепочки, — это операции, в которых пользователю необходимо добавить новую информацию. Чем больше взаимодействий, тем больше подписей сообщений или транзакций в цепочке. Больше подписания означает большее использование пары ключей пользователя, что в основном довольно неудобно и не интуитивно понятно для пользователей.

Именно поэтому мы выбрали решение, в котором пользователь все еще полностью владеет закрытым ключом, и никто другой не может манипулировать подписанной информацией, размещаемой ими в блокчейне. Помогая пользователю сгенерировать новую пару ключей при регистрации, а затем разрешив хранить его локально на своем устройстве, мы надеемся предоставить пользователю столько ответственности, сколько ему хотелось бы, при этом сохраняя при этом риски безопасности минимальными.

Итак, когда пользователь должен подписывать транзакции?

Итак, когда пользователь должен подписывать транзакции? Именно тогда, когда опека меняется. Абсолютно важная информация, которая не должна быть повреждена, таким образом, защищена наиболее. Смена опекуна состоит из двух этапов: во-первых, он должен быть передан текущему хранителю, а во-вторых, он должен быть принят будущим хранителем. До того как обе эти транзакции были подписаны, хранение остается за предыдущим пользователем. Мы стараемся сделать «подпись» как можно более неинвазивной, применяя известные процедуры, такие как «Имя пользователя и пароль», плюс специальный файл ключа, который должен предоставить пользователь. Это показано в упрощенной форме ниже:

Риск такой системы ключей, контролируемых пользователем, состоит в том, что пользователь теряет закрытый ключ, но в нашем случае, поскольку мы работаем в рамках разрешенных настроек, есть смягчение. Доступ к платформе зависит от проверки подлинности каждого пользователя. Следовательно, в случае утерянного ключа пользователь должен пройти перерегистрацию, но информация не будет потеряна. Затем пользователю придется повторно подтвердить личность, чтобы восстановить доступ к учетной записи, где может быть сгенерирована новая пара ключей.

В будущем решении не должно быть центрального органа для сброса пароля без проверки личности, но для PoT это приемлемо.

Теперь мы увидели некоторые проблемы юзабилити, с которыми мы сталкивались при создании блокчейн-решения для гуманитарной цепочки поставок в рамках FTL. Удобство и доступность — огромная проблема для блокчейна в целом. Он стремится расширить возможности людей, но рискует запутать и оттолкнуть людей со сложными процедурами управления ключами и отсутствием интерфейсов.