Обзор кода NuCypher от Andre Cronje

0
543
views

Команда ICOdaily подготовила перевод статьи «Обзор кода NuCypher» от Andre Cronje

Еще больше новых проектов, переводов интересных статьей и новостей на нашем телеграм канале


Обзор кода NuCypher — KMS для децентрализованных сетей

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

  1. У Алисы есть конфиденциальные данные, доступ к которым она хочет предоставить делегату.
  2. Алиса шифрует свои данные, используя открытый ключ, и хранит их в облаке или децентрализованном хранилище.
  3. Алиса предоставляет доступ к данным Бобу. Ключ доступа к данным меняется на ключ Боба.
  4. Боб скачивает данные и расшифровывает их при помощи своего открытого ключа.

Ключ для доступа в хранилище с данными был изменен на ключ Боба. Оригинальное подписание не может происходить с помощью только единственного частного ключа, в противном случае, смена ключа не будет возможной. Давайте быстренько пройдемся по ключам.

Представим, что я беру сообщение “NuCypher Code Review” и шифрую его при помощи открытого ключа. В таком случае, я получаю

0xca92b9be89c0506044cacd947f1630f271aa8c2cb97916b65487f3944245b67b5f2166ff995c605a5ae1c8ac9bd77760f1e90837545fd5be9c87c4f9bf3c71f11b

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

Теперь вы знаете, что у меня есть закрытый ключ для соответствующего открытого ключа. Вот так я могу доказать право на владение.

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

nucleypher-kms и mock-net — это те, которые меня интересуют больше всего, давайте сначала возьмем nucleypher-kms.

У нас тут стандартный набор всего необходимого, kademlia, rpcudp, lmdb (этот новый) и контракты Ethereum VM.

Тут я понял, что Umbral является основой, таким образом мы приступили к pyUmbral.

Очень круто, Алиса может создавать смену ключа для Боба, создавая новый общий ключ через закрытый ключ Алисы и открытый ключ Боба. Затем Боб может перешифровать данные, отталкиваясь от этого.

Таким образом, процесс бы протекал следующим образом:

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

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

Вернемся к nucypher-kms:

Хорошая структура, хорошие комментарии, хорошая инкапсуляция.  Пока мне нравится расположение и содержимое.

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

REST — сервер с несколькими базовыми конечными точками, ничего лишнего.

Местное хранилище использует sqlite. Функции REST очень надежные, двигаемся дальше.

Еще одна хорошая реализация, p2p node swarm. Узлы могут соединяться и быть запрошены для хранения зашифрованных данных.

Хорошая прямая реализация на узлах.

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

Давайте взглянем на блокчейн:

Время для смарт-контрактов. Контракт эскроу.

Сначала нужно изучить PolicyManager, двинем к нему.

До конца не уверен, что делает PolicyManager, это своего рода смесь из политики хранения и политики ставок. У него есть особенности и того и другого. Я сверюсь с вайтпепером.

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

Выводы по обзору:

Очень хороший код, сильная архитектура, все основные случаи использования были проверены. Прочная реализация с набором навыков высокого калибра. Система использует стандартную философию “давайте, стимулируем людей предоставлять Процессор/Хранилище/Сеть путем оплаты всего этого токенами нашей сети, кажется, стейкинг (вестинг) и экономику токенов немного притянули для решения проблемы, она не выглядит естественным компонентом для системы, но у меня нет никаких фундаментальных проблем с этим подходом. Децентрализация, в конце концов, совсем другой зверь.

Не блокчейн, но новая идея. Есть ли на самом деле спрос на децентрализованный Dropbox, зашифрованный Slack или контролируемые пациентом электронные медицинские записи, за которые вы должны платить? Не знаю, но код хороший.

 

 


Еще больше новых проектов, переводов интересных статьей и новостей на нашем телеграм канале

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here