За пределами Нулевого Разглашения (ZK): Подробное руководство по конфиденциальности Web3 (Часть 2)
Вторая часть нашей серии статей о конфиденциальности в Web3 посвящена безопасным вычислениям и устранению неверных представлений обо всем — от ZKP (Доказательств с нулевым разглашением) до TEE (Доверенных сред исполнения)!
Добро пожаловать в серию блогов сообщества Secret Network “За пределами Нулевого Разглашения (ZK)”, в которых рассматриваются прагматичные решения для обеспечения конфиденциальности Web3.
В первой части этого блога мы впервые рассмотрели проблему безопасных вычислений в Web3. Блокчейны — отличный инструмент для корректности , но у них есть важные компромиссы и сложности в отношении конфиденциальности. Блокчейны — потрясающий инструмент для обеспечения корректности — но у них есть важные компромиссы и сложности, связанные с конфиденциальностью. Поскольку блокчейны не являются решением, ориентированным на конфиденциальность, Web3 может быть хуже в плане конфиденциальности, чем когда-либо был Web2. Отсутствие приватных вычислений в блокчейне означает, что все могут видеть все ваши данные, заставляя разработчиков разрабатывать в узком пространстве проектирования, что не позволяет им создавать действительно полезные децентрализованные приложения.
Во второй части этой серии блогов мы углубимся в инструментарий криптографии и поищем потенциальные прагматичные решения проблемы конфиденциальности, которую создает блокчейн. Сегодня мы рассмотрим следующие разнообразные методы:
- Partial or Fully Homomorphic Encryption — Частичное или полностью гомоморфное шифрование (HE/FHE)
- Secure Multi-Party Computation — Безопасные многосторонние вычисления (MPC)
- Trusted Execution Environments — Доверенные среды исполнения (TEEs)
- Zero-Knowledge Proofs — Доказательства с нулевым разглашением (ZKPs)
В криптографии редко бывает “оптимальный” метод. Каждое упомянутое здесь решение имеет несколько конструкций и может быть использовано самостоятельно или в тандеме с другими решениями для решения интересных задач в каждом конкретном случае. Каждая конструкция и комбинация имеет свои компромиссы и относительные преимущества.
В этом посте нас интересует, как упомянутые выше методы могут быть использованы по отдельности для решения обобщенной проблемы конфиденциальности: как выполнить любые вычисления в блокчейне с корректностью, гарантируя при этом, что основные ноды / валидаторы / майнеры не могут видеть данные, на которых они вычисляют.
Это состояние обобщенного приватного вычисления будет называться безопасным вычислением в оставшейся части этого блога. По мере выполнения этого задания мы также рассмотрим некоторые решения конкретных проблем конфиденциальности в блокчейн-пространстве (например, конфиденциальная отправка токенов).
Приступим! 🚀
Полностью гомоморфное шифрование
Полностью гомоморфное шифрование (FHE) — это идея, которую легко понять, но крайне сложно реализовать. На самом деле, хотя первоначальная идея была предложена в 1978 году Ривестом и другими, только в 2009 году Крейг Джентри создал первую конструкцию такой схемы. Этот прорыв положил начало десятилетию возобновления интереса и исследований в области полностью гомоморфных схем шифрования, которые значительно повысили эффективность первоначальной конструкции на много порядков.
Так что же такое FHE? FHE — это схема шифрования, которая позволяет любому выполнять вычисления с зашифрованными данными без предварительной их расшифровки. Вспоминая наш первый пост в этой серии, давайте снова представим упрощенную версию идеального мира, в котором есть один клиент/пользователь (вместо множества) и один сервер. Проблема в этом идеальном мире заключается в том, что мы не можем доверить этому единственному серверу защиту конфиденциальности наших данных. Ну, с FHE это кажется тривиальным: клиент может отправить свои данные на сервер в зашифрованном виде, а сервер затем может вычислять над его данными, не просматривая исходные данные. Задача выполнена?
Ограничения FHE
Не совсем. Во-первых, FHE на сегодняшний день является крайне неэффективной. Фактически, FHE является самой медленной из всех известных нам технологий сохранения конфиденциальности. Однако эффективность вычислений FHE повышается с невероятной скоростью, а специализированное оборудование (CPU → GPU → FPGA → ASICs) в ближайшее десятилетие еще больше увеличит скорость вычислений на несколько порядков. Этот рост эффективности — самая важная причина, по которой сообщество Secret снова рассматривает FHE как потенциально жизнеспособное решение (как упоминалось в посте о Secret 2.0 на нашем форуме).
Однако важно уточнить, что даже через 5–10 лет, скорее всего, использование возможностей FHE будет иметь смысл только для определенных случаев использования или для определенных частей выполнения смарт-контрактов. Например, вы можете захотеть использовать FHE для хранения и работы с чрезвычайно важными (и небольшими) данными, такими как криптографические ключи или SSN (social security number).
FHE с несколькими клиентами
Таким образом, FHE является на первый взгляд простым, хотя и затратным вычислительным решением, когда проблема вычислений касается только одного клиента. Тогда возникает вопрос: как ввести второго клиента в эту проблему безопасных вычислений? Должно быть очевидно, что на практике постановка задачи безопасных вычислений с несколькими клиентами является более интересной, поскольку многие сценарии предполагают объединение данных от множества сторон.
В мире, где есть только один клиент, она сама может арендовать мощный облачный сервер и выполнять вычисления вместо того, чтобы доверять свои данные другим. В случае с одним клиентом проблема доверия внешней стороне, которая сохранит конфиденциальность ваших данных и правильно выполнит вычисления для вас, кажется менее важной на практике.
Добавление второго клиента не является тривиальным изменением и заставляет многих технических специалистов ломать голову. Во-первых, давайте представим, что в мире существует только два клиента. Оба клиента имеют свои собственные исходные данные и хотят вычислить определенную функцию над своими исходными данными. Как обычно, оба хотят конфиденциальности (т.е. чтобы ни сервер, ни другой клиент ничего не узнали об их данных). При использовании “чистого” FHE неясно, как это сделать, поскольку каждый клиент использует свой собственный ключ для шифрования своих данных. FHE — это здорово, но он не может волшебным образом вычислять данные, зашифрованные разными ключами. Как же нам решить эту проблему?
Частичное гомоморфное шифрование (PHE)
Честный ответ заключается в том, что для решения этой проблемы необходимо использовать множество методов. Помимо полностью гомоморфного шифрования, которое может вычислить любую произвольную функцию над зашифрованными данными, существует множество схем частично гомоморфного шифрования (HE или PHE). Эти частичные схемы могут вычислять определенные функции — обычно либо сложение, либо умножение, но не обе (заметим, что все функции могут быть сведены к операциям сложения и умножения). Эти схемы частичного шифрования были изобретены несколько десятилетий назад и являются гораздо более эффективными, и их может быть достаточно для ограниченного набора случаев использования, но их недостаточно для общего случая безопасных вычислений.
Несколько сетей нацелены на использование такой частичной схемы, как PHE, для достижения конфиденциальности (например, Penumbra и Dero). Однако важно понимать, что они по определению не могут поддерживать смарт-контракты общего назначения. Применение этих методов для блокчейнов, ориентированных на конфиденциальность, является новаторским, но случаи использования, которые оно может поддержать, весьма ограничены.
Существуют нетривиальные способы расширить диапазон приложений, которые можно поддерживать с помощью такого частичного решения, но это потребует глубоких знаний в области криптографии. Такие приложения часто приводят к другим скрытым компромиссам, о которых трудно рассуждать. По этой причине PHE, скорее всего, никогда не позволит разработчикам создавать произвольные приложения с конфиденциальностью.
Итак, если только FHE или частичные решения HE не могут решить проблему безопасных вычислений для нескольких клиентов…но что может?
Безопасные многосторонние вычисления (MPC)
Под многосторонними вычислениями (MPC) понимается как сама проблема — выполнение произвольных вычислений над зашифрованными данными, предоставленными несколькими сторонами, так и один из методов, направленных на ее решение.
Во избежание путаницы, мы старались в этой статье называть проблему “безопасными вычислениями”, а термин MPC использовать только для обозначения определенного набора решений, которые непосредственно решают эту проблему.
Обычно существует два типа решений MPC: основанные на Linear Secret Sharing (Схема разделения секрета Шамира) и основанные на Garbled Circuits (Искаженных цепях). Описание этих решений выходит за рамки этой статьи, но компромиссы и модель безопасности, в которой они работают, важны для нашего понимания.
MPC с несколькими клиентами
Решения MPC можно рассматривать как решение распределенных систем (или, если хотите, “блокчейн”) для вычислений над частными данными. В этих схемах вместо того, чтобы доверять одному серверу, мы имеем несколько бездоверительных серверов, которые совместно выполняют вычисления над данными клиента. Изменение предположений о доверии значительно расширяет пространство решений. Решения MPC разрабатываются с учетом множества клиентов, что означает отсутствие теоретических проблем с объединением серверами данных от любого количества клиентов, как в случае с FHE.
Обратите внимание, что способ превратить схему FHE для одного пользователя в схему для нескольких пользователей — это фактически “MPC” путем разделения единого ключа шифрования FHE на доли, общие для всех серверов. Это называется Пороговым FHE, который смешивает MPC с FHE. С точки зрения безопасности, это сводится к той же модели безопасности MPC. Коротко говоря, использование FHE для нескольких пользователей — это, по сути, еще одна форма MPC. Мы рассмотрим это более подробно в одной из следующих статей.
Ограничения MPC
Конечно, использование MPC имеет и свои недостатки. Основным компромиссом является то, что MPC полагается на “безопасность без сговора”. Использование FHE позволяет клиенту хранить свой секретный ключ шифрования без того, чтобы сервер когда-либо получал доступ к его данным. Но в MPC нам нужно, чтобы хотя бы один сервер был честным, потому что если все серверы вступят в сговор, они смогут с легкостью восстановить приватные данные. На самом деле, так и задумано, потому что решения MPC не содержат ключей.
Вместо этого MPC скрывает данные, предоставляя каждому серверу “зашифрованную” долю данных, так что для “расшифровки” данных вам понадобятся все доли. Кроме того, каждый ресурс сам по себе не раскрывает ничего о данных в открытом тексте. Из этого должно быть ясно, что требование сговора является неотъемлемым, и по крайней мере одна сторона должна действовать честно.
На практике для оптимизации пороговых значений сговора можно выбрать либо оперативность, либо конфиденциальность. В приведенном выше примере, где для восстановления данных требуются все доли ключей, мы получаем максимальную конфиденциальность. Однако достаточно одного сервера, чтобы организовать DoS-атаку на всю систему. Это происходит потому, что достаточно одного сервера, не отвечающего на запрос клиента, и результат невозможно вычислить. Однако мы можем потребовать только ½ (или любое произвольное количество) ключевых долей, что означает, что мы требуем, чтобы большинство серверов были честными и не вступали в сговор, чтобы получить вычислительный результат.
Можно еще многое сказать на эту тему, но пока важно заметить сходство между блокчейнами и решениями MPC. Обе они являются распределенными системами, которые основывают свою безопасность на предположениях о борьбе с коллизией, что означает наличие компромисса между корректностью, скрытностью и конфиденциальностью. Теперь остается вопрос: что важнее?
MPC для конфиденциальности против MPC для корректности
Теперь, когда мы рассмотрели компромисс между корректностью и быстродействием, давайте разберемся, почему конфиденциальность в системах MPC, вероятно, сложнее, чем корректность. Корректность поддается проверке — если транзакция подделана, это либо видно, либо консенсус вообще останавливается. Однако нельзя проверить атаки сговора на конфиденциальность, что делает ее “тихой” атакой. Если серверы в системе делятся своими ключевыми долями за пределами системы, они могут сговориться, и мы никогда не узнаем, что они восстановили данные. Этот вектор бесшумной атаки делает решение проблемы конфиденциальности в распределенных системах более сложным, чем обеспечение корректности.
Чтобы устранить этот вектор атаки, мы можем стремиться к тому, чтобы как можно больше серверов выполняли вычисления, избегая тем самым атак сговора. К сожалению, MPC плохо масштабируется с увеличением числа сторон, а увеличение числа серверов препятствует повышению эффективности. Поэтому кажется, что одного MPC недостаточно и необходимо внедрять другие технологии, затрудняющие сговор.
Осложнение сговора
Один из способов затруднить сговор MPC — заставить все серверы в распределенной системе использовать Доверенные среды исполнения (ТЕЕ) (подробнее об этом ниже). Мы стремимся реализовать такое решение для всех методов в текущей основной сети Secret, что обеспечит дополнительную безопасность нашей системы конфиденциальности.
В качестве альтернативы можно усложнить сговор, работая в разрешенной среде, где серверам (частично) доверяют и их можно повторно идентифицировать, если произойдет утечка данных. Именно в этом направлении, по-видимому, работает Блокчейн Partisia: вне сети множество полудоверенных нод выполняют приватные вычисления, а блокчейн только хранит и проверяет состояние.
Другие методы включают в себя конструкцию, упомянутую в моей дипломной работе, и оригинальный whitepaper Enigma. В этих документах предлагается механизм выборки небольших комитетов для выполнения вычислений. Если все сделать аккуратно, можно спроектировать блокчейн, который имеет множество различных серверов, но для каждого вычисления (или набора вычислений) выбирается небольшое количество сторон, которые фактически выполняют тяжелую работу. Хотя это решение звучит многообещающе и асимптотически масштабируется очень хорошо, оно непрактично по многим причинам, которые в основном сводятся к необходимости доверять одной или нескольким сторонам.
Мы более подробно рассмотрим эти виды комбинаций технических приемов в третьей части этой серии блогов, так что оставайтесь с нами!
Доверенные среды исполнения
До сих пор все решения проблемы безопасных вычислений, о которых мы упоминали, были криптографическими по своей природе. “Криптографический” часто означает “крутой” в глазах разработчиков, но “крутой” не всегда означает эффективный, прагматичный или даже выполнимый. Пока что единственным чисто криптографическим методом, который может решить проблему безопасных вычислений, является MPC, который все еще предполагает, что серверы (например, наши валидаторы блокчейна) не сговариваются и не могут сговориться для реконструкции данных. Поэтому давайте рассмотрим еще одно потенциальное решение рассматриваемой проблемы.
Доверенная среда исполнения (Trusted Execution Environment, TEE), говоря простым языком, представляет собой область в процессоре, отделенную от остальной части ЦП. В этой области могут храниться данные (например, ключи шифрования) и выполняться вычисления, которые не могут быть изменены хозяином устройства. Кроме того, хозяин устройства не может извлечь данные, хранящиеся в этой области (по крайней мере, теоретически).
Как TEE решают вопросы конфиденциальности (и корректности)
TEE могут решить проблемы конфиденциальности и корректности, требуя, чтобы наш сервер (или, в условиях блокчейна, серверы) выполняя все вычисления внутри своего TEE. Кроме того, мы можем попросить клиентов шифровать свои входящие данные с помощью ключа, который также доступен только в TEE серверов.
При такой системе никто — даже хозяин, владеющий серверами, — не имеет доступа к данным клиентов. Это происходит потому, что данные расшифровываются и вычисляются только внутри TEE. Для получения дополнительной информации о том, как такая система работает на практике и как обеспечивается безопасность ключей шифрования, ознакомьтесь с технической документацией Secret Network.
Другой способ представить себе TEE — это аппаратная аппроксимация идеального мира, который мы описали в первой части, где есть единственный доверенный сервер, который может выполнять вычисления корректно и конфиденциально. Однако извлечь максимальную пользу из TEE гораздо сложнее, чем то, что мы описали здесь. Для предотвращения цензуры или DoS-атак все же лучше использовать TEE в распределенной системе, такой как блокчейн, а не полагаться на единственный сервер.
Поскольку системы TEE обеспечивают безопасность с помощью аппаратного обеспечения в отличие от чистой криптографии, они очень эффективны. Хотя криптографические решения обычно на порядки медленнее, чем вычисления в чистом виде, в большинстве случаев TEE имеют менее 40% накладных расходов на время вычислений. В основном это связано с требованием расшифровки входных данных и повторного шифрования выходных данных для сохранения конфиденциальности.
Недостатки TEE
Основной недостаток TEE, который беспокоит пользователей, — возможность атак по внешним каналам. В последние годы исследователи показали, как они могут извлекать информацию из TEE, в основном используя спекулятивное выполнение — метод, используемый всеми современными процессорами для повышения эффективности. Хотя большинство этих проблем могут быть решены программно или аппаратно и их трудно использовать на практике, они все же представляют собой недостаток по сравнению с чистыми криптографическими методами в этом конкретном векторе атаки. Архитектурные ошибки (которые могут повлиять на любой тип оборудования, а не только на защищенные анклавы) также возможны и представляют собой серьезный риск, который не следует игнорировать.
С учетом этих компромиссов TEE по-прежнему остаются лучшим практическим решением, особенно для высокопроизводительных вычислений на данных с низкой чувствительностью. Даже если основа потенциального решения — криптографическая, TEE являются ключевым фактором повышения безопасности и помогают предотвратить сговор, одновременно повышая масштабируемость. Именно поэтому Secret продолжает развивать технологию TEE и внедрять ее в наши решения.
Доказательства с нулевым разглашением
И последнее, но не менее важное, мы хотим коснуться использования Доказательств с Нулевым Разглашением (ZKP) для решения проблемы конфиденциальности Web3. Как сеть, мы очень часто получаем вопросы о том, как проект X сравнивается с Secret Network, где X — это проект, использующий какую-либо технику, основанную на Zero-Knowledge Proofs. Если это так, то почему мы оставили ZKP до конца этого длинного поста?
Как выяснилось, ZKP не являются решением проблемы конфиденциальности — по крайней мере, не для той большой проблемы конфиденциальности, которую мы описывали в этой серии постов. Но прежде чем мы сможем объяснить почему, нам нужно вкратце объяснить, что такое ZKP.
Система доказательства с нулевым знанием — это двухсторонний протокол, в котором доказывающий P хочет доказать проверяющему V истинность некоторого утверждения, не раскрывая ничего другого. Если не вдаваться в формальности, проверяющий часто предоставляет доказательство, которое гласит: “Я вычислил что y=f(x) правильно”, где проверяющий знает функцию f и конечный результат y, но не исходные данные x.
Например, представьте, что у Алисы есть подтвержденный цифровой паспорт, и она хочет доказать бармену, что ей больше 21 года, не раскрывая дату своего рождения. В этом случае f — это вычисление “Мне больше 21 года?”, x — ее сертифицированный паспорт, в котором указана дата ее рождения, а y — ответ (True или False). Используя ZKP, Алиса может добиться этого.
ZKP существуют уже несколько десятилетий. В последнее десятилетие была введена особая форма ZKP — такая, которая делает само доказательство чрезвычайно маленьким (существует несколько вариантов с различными компромиссами), а проверку чрезвычайно быстрой и эффективной. Эти доказательства также являются неинтерактивными. Это означает, что проверяющий может сгенерировать доказательство за один раз, отправить его проверяющему, а проверяющий может самостоятельно выполнить проверку, не обращаясь больше к проверяющему. Сама генерация доказательства стоит дорого, в зависимости от сложности вычислений, но и в этом вопросе за последние несколько лет произошли значительные улучшения.
Почему ZKP лучше подходят для масштабирования, чем для обеспечения конфиденциальности
Эти свойства неинтерактивности и легкости вычислений со стороны верификатора делают ZKP отличным способом масштабирования блокчейна вне сети.
Основная идея довольно проста: централизованная сторона (часто называемая секвенсором) выполняет все транзакции (и вычисления) вне сети. Это означает, что клиенты взаимодействуют непосредственно с этим секвенсором, а не с блокчейном, и отправляют ему свои незашифрованные исходные данные. После выполнения всех вычислений секвенсор создает краткое доказательство и отправляет его в блокчейн вместе с исходящими данными (обычно это обновленное состояние). Блокчейн, выступающий в роли верификатора, проверяет правильность доказательства и, если это так, применяет изменения состояния без непосредственного изучения данных клиентов. Все блокчейн ZK-решения общего назначения используют этот метод масштабирования, включая zkEVMs (которых существует несколько), Aleo, Starkware и другие.
Но хотя ZKP являются отличным инструментом масштабирования, должно быть понятно, почему ZKP предлагают ограниченное решение для конфиденциальности в Web3. Пользователям необходимо доверять централизованному секвенсору (как и в Web2) все свои данные. Аналогично, если мы хотим разрешить работу нескольких секвенсоров (чтобы распределить предположение о доверии), ситуация с конфиденциальностью только ухудшается.
Узкое использование ZKP для конфиденциальности
Однако в некоторых ситуациях можно использовать ZKP для обеспечения конфиденциальности. Примером может служить Zcash, где каждый пользователь должен доказать, что он не осуществляет повторного расходования монет. Они должны доказать это, не раскрывая блокчейну, сколько монет у них есть или кому они в данный момент передают. Вообще говоря, ключ к использованию ZKP таким образом заключается в том, что каждый пользователь выполняет вычисления на своей части глобально разделяемого частного состояния. Затем они используют ZKP, чтобы доказать блокчейну, что они не мошенничали.
Но мы должны четко понимать: эта техника ограничена очень специфическими случаями использования, а не обобщенными безопасными вычислениями. Например, аукцион, сравнивающий приватные ставки клиентов, не может использовать эту технику, потому что он должен напрямую использовать входы нескольких клиентов как часть вычислений. Для проведения подобных доказательств клиентам пришлось бы обмениваться данными вне сети и тем самым отказываться от конфиденциальности своих данных. Более того, определение смарт-контрактов таким образом, чтобы облегчить эту задачу, требует глубоких криптографических знаний и часто имеет другие компромиссы с точки зрения развертывания (например, заставляя клиентов выполнять тяжелую криптографию локально).
Отсюда следует, что ZKP — это скорее решение для масштабирования, чем для обеспечения конфиденциальности. ZKP могут решить проблему конфиденциальности в некоторых случаях использования, которые ограничены единичными клиентами, например, конфиденциальность транзакций. Более сложные вычисления требуют значительной адаптации схем и, возможно, никогда не будут осуществимы, если мы не будем полностью доверять секвенсорам в вопросах защиты пользовательской информации. Поэтому ZKP сами по себе не могут решить проблему безопасных вычислений. Однако они могут быть хорошим дополнительным инструментом для масштабирования более медленных приватных базовых схем или как дополнительный инструмент для MPC и FHE. Комбинирование методов таким образом — это то, о чем мы расскажем в одной из следующих статей.
Подводя итоги
На данный момент мы проанализировали практически весь набор инструментов для обеспечения конфиденциальности (за исключением дифференциальной конфиденциальности и некоторых других решений, не связанных с ней). Хотя за каждым из представленных здесь решений стоят десятилетия исследований и многие тысячи статей, присущие им компромиссы остаются неизменными, и мы можем обобщить их здесь.
Напоминаем: общая проблема, которая нас интересует, — это проблема безопасных вычислений , которая задает вопрос о том, как несколько клиентов могут выполнять вычисления над своими общими данными, обеспечивая при этом корректность и конфиденциальность . Мы объяснили, что блокчейны решают только первую половину проблемы (корректность), и представили несколько возможных технологий, решающих вторую проблему (конфиденциальность).
Мы обобщили имеющиеся решения и их компромиссы в таблице ниже. Обратите внимание, что это чрезмерное упрощение этих инструментов и предположений, которые они делают — наша цель состоит в том, чтобы представить только самые большие компромиссы и проблемы безопасности при выборе одного (или нескольких) из этих инструментов. По этой причине мы игнорируем основные криптографические предположения, квантовую безопасность или предположения о доверенной установке, которые могут существовать или не существовать в конкретной конструкции.
В приведенной выше таблице “сжаты” интересующие нас измерения до наиболее важных предположений безопасности, эффективности (разделение между локальными вычислениями и сетевыми затратами) и того, насколько легко разработчикам использовать этот инструмент на практике.
Исходя из этого, самый важный вопрос, который следует задать: какое предположение лучше сделать на практике? Что валидаторы никогда не сговорятся с целью утечки данных (решения Порогового FHE/MPC)? Или лучше доверить одной централизованной стороне хранение и просмотр всех данных (решения ZKP)? Или лучше доверять тому, что атаки по боковым каналам (или аппаратные ошибки, открывающие уязвимости) против TEE могут быть эффективно защищены?
Возможно, на этот вопрос нет однозначного ответа, но он должен заставить вас задуматься. На данный момент времени, похоже, что TEE по-прежнему представляют собой единственное практическое решение для случаев использования с низкой и средней чувствительностью и высокой производительностью. Для всего, что выше, похоже, что комбинация MPC/Threshold FHE с TEEs — это то, что нужно. В Secret 2.0 мы будем двигаться в направлении смешивания различных методов в стеке, чтобы дать разработчикам возможность выбора, который наилучшим образом соответствует их случаю использования.
В третьей части серии “За пределами ZK” мы более подробно рассмотрим модульный стек конфиденциальности для блокчейна и то, что он позволяет решить проблему безопасных вычислений. Если вас интересует ранний взгляд на модульные конструкции конфиденциальности, не упустите возможность прочитать наш блог о Secret 2.0, объясняющий дальнейшую эволюцию Secret Network!
Что дальше?
Мы глубоко обдумывали эти вопросы на протяжении последних лет, и Secret Network гордится тем, что продолжает лидировать в области безопасных вычислений в пространстве блокчейна. Если эти идеи вас заинтересовали — и если вы убеждены в их важности — присоединяйтесь к нам в создании решений и технологий, которые помогут нам защитить децентрализованный интернет и масштабировать Web3!
Если вы разработчик приложений, здесь вы можете ознакомиться с нашими ресурсами. (Secret использует Rust)
Если вы из тех, кто так же как и мы, желает обеспечить пользователям Web3 необходимую и заслуженную защиту конфиденциальности данных, станьте Секретным Агентом. Наша миссия заключается в том, чтобы децентрализованная сеть, которую мы создаем, расширяла свои возможности и была доступна для всех. От Просвещения и Образования до Международного Роста и Сотрудничества с Университетами — существует множество способов помочь внести свой вклад в расширение экосистемы Secret и глобальную доступность технологий конфиденциальности в Web3.
Ознакомьтесь с программой «Секретных Агентов» и присоединитесь к одному из лучших и самых активных сообществ во всем блокчейн-пространстве!
Вперед, к новым вершинам конфиденциальности!
Гай Зискинд — основатель Secret Network, генеральный директор SCRT Labs, бывший научный сотрудник Массачусетского технологического института и автор нескольких наиболее цитируемых работ по конфиденциальности блокчейна (включая “Децентрализация конфиденциальности”, написанную в 2015 году).
Чтобы обсудить Secret Network и Secret Apps, посетите каналы нашего сообщества:
Website | Forum | Twitter |Twitter-RU| Discord | Telegram | Telegram-RU
