💬 Чтобы стать основной платформой Биткойн, Nostr придется решить свои ключевые проблемы управления

Чтобы стать основной платформой Биткойн, Nostr придется решить свои ключевые проблемы управления

Это редакционная статья Шиноби, преподавателя-самоучки в биткойн-пространстве и ориентированного на технологии ведущего биткойн-подкастов.

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

Как я уже говорил в предыдущей статье, пары пользовательских открытых и закрытых ключей являются неотъемлемой частью того, как Nostr работает как протокол. Нет имен пользователей или идентификаторов любого типа, которыми управляет сервер ретрансляции и которые можно связать с отдельными пользователями. Это просто ключи тех пользователей, которые полностью находятся под их контролем.

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

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

Как вы справляетесь с этим? Просто проверить их аккаунт в Твиттере? Что ж, тогда это не очень децентрализованная система, в конечном счете, если вам требуется использовать централизованную платформу, где они не контролируют свою личность, чтобы подтвердить свою личность Nostr.

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

Nostr нужна реальная криптографическая схема, связывающая ротацию одного ключа с другим. Существует предложение от разработчика fiatjaf по базовой схеме, которая потенциально может решить эту проблему. Основная идея заключалась бы в том, чтобы взять длинный набор адресов, полученных из одного основного семени, и создать набор «подправленных» ключей, подобно тому, как деревья Taproot привязаны к ключу Биткойн. Taproot берет корень дерева Merkle из дерева Taproot и «добавляет» его к открытому ключу для создания нового открытого ключа. Это можно воспроизвести, добавив этот корень дерева Меркла к закрытому ключу, чтобы получить соответствующий закрытый ключ для нового открытого ключа. Идея Fiatjaf состоит в том, чтобы объединить обязательства, идущие в обратном порядке от конца к началу, чтобы каждый измененный ключ фактически содержал доказательство того, что для его создания использовался следующий измененный ключ.

Итак, представьте, что вы начинаете с клавиши Z, последней в цепочке. Вы бы подправили это чем-то, а затем вернетесь назад и создадите измененную версию ключа Y, используя измененный ключ Z (Z' + Y = Y'). Отсюда вы должны взять Y', а затем использовать его для настройки X (Y' + X = X'). Вы должны сделать это до самого ключа A, чтобы получить A', и оттуда начать использовать этот ключ. Когда он скомпрометирован, пользователь может транслировать событие, содержащее неподключенный ключ A и подправленный ключ B'. Это будет содержать все данные, необходимые для того, чтобы показать, что B' был использован для создания A', и пользователи могли бы немедленно прекратить подписку на A' и вместо этого подписаться на B'. Они бы точно знали, что B' является следующей клавишей этого пользователя, и вместо этого следовали бы этому.

Однако это предложение все еще имеет некоторые проблемы. Во-первых, вы должны заранее сгенерировать все ключи, которые вы когда-либо использовали, и у него нет возможности перейти на совершенно новый набор ключей. С этим можно было бы справиться, зафиксировав мастер-ключ в этой схеме, который мог бы нотариально удостоверять такие повороты, или просто сгенерировав очень большой набор ключей с самого начала. Любой путь был бы допустимым курсом, но в конечном итоге потребовал бы безопасного хранения корневого ключа или ключевого материала и раскрытия отдельных горячих клавиш только клиентам Nostr.

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

Чтобы немного порассуждать о возможных решениях, представьте, что вместо цепочки настраиваемых ключей, как он предлагает, ключ настраивается с помощью главного холодного ключа, который также должен использоваться для подписи события, меняющегося от одного ключа к другому. У вас есть ключ A', полученный путем сложения A и M (мастер-ключ), и событием ротации будут A, M и B' (сгенерированные путем сложения B и M) с подписью из M. M может быть пороговый ключ с мультиподписью — два из трех, три из пяти и т. д. Это потенциально может добавить избыточность на случай потери, а также обеспечить безопасный механизм ротации ключей. Это также открывает двери для использования сервисов, помогающих в восстановлении, или распространения некоторых из этих ключей среди доверенных друзей. Он предлагает ту же гибкость, что и мультиподпись в самом Биткойне.

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

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

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

Для тех, кто читает и интересуется, почему я не упомянул децентрализованные идентификаторы (DID): да, это потенциальное решение этих проблем, которое, на мой взгляд, является довольно всеобъемлющим. Однако разработчики Nostr, похоже, очень не решаются интегрировать DID в протокол или клиенты из-за того, что это создаст внешние зависимости за пределами протокола Nostr. Если вы не знакомы с тем, как работают DID на техническом уровне, и вам интересно, эта статья от Level 39 представляет собой очень хорошо написанное резюме того, как они работают.

Это гостевой пост Шиноби. Высказанные мнения являются полностью их собственными и не обязательно отражают точку зрения BTC Inc или Bitcoin Magazine.