Инфраструктура Phala

2.5 Обзор

**Phala —**это надежное решение для облачных вычислений для Интернета следующего поколения,Web3. Мы работаем на основеParity Substrateи работаем в экосистеме Polkadot наKusama.

Phala решает проблемы конфиденциальности и производительности устаревших блокчейн-решений, работающих в облачной среде, отделяя вычисления с чейна к secure workers (майнерам) оффчейн: блокчейн используется только как каноническая (зашифрованная) очередь сообщений, а аттестованные secure workers извлекают запросы (т. е. транзакции) с ончейна, проверяют и выполняют их, а затем записывают результаты вычислений обратно.

Наши secure workers используют специальноеSecure Enclave, которое обеспечивает конфиденциальность, безопасность и производительность вычислений в блокчейне. Кроме того, наш код полностью с открытым исходным кодом.

Архитектура

В целом, Phala Network состоит из блокчейна Phala и оффчейн среды выполнения в Secure Enclave. Кроме того, мы вводим мостовой ретранслятор для их соединения. Таким образом, полный стек одного узла Phala содержит следующие три компонента.

• phala-node: узел блокчейна на основе субстрата;

• pRuntime: среда выполнения Secure Enclave. Контракты выполняются в pRuntime;

• pherry: ретранслятор моста Substrate-Enclave. Соединяет блокчейн и pRuntime.

Безопасность транзакций

Основная идея дизайна нашей системы заключается в том, что блокчейн может служить каноническим источником ввода для Secure Enclave, а аппаратное обеспечение Secure Enclave обеспечивает конфиденциальное и точное выполнение, указанное чейном, даже если рабочие workers поступят злонамеренно.

Хотя злоумышленники не могут заглянуть в Secure Enclave, они могут обмануть контракты в нем, подделав транзакции или воспроизведя/изменив порядок действительных транзакций. Важно обеспечить, чтобы конфиденциальные контракты принимали только действительные транзакции и обрабатывали транзакции в ожидаемом порядке. Вот почему мы представляем блокчейн Phala и подключаем его к pRuntime через pherry.

Исходя из сказанного, блокчейн Phala служит каноническим источником действительных транзакций. Только отправленные транзакции могут быть приняты pRuntime, и они будут обрабатываться в том же порядке, что и в блокчейне. Мы реализуем легкий клиент проверки в pRuntime , чтобы определить, принимаются ли допустимые транзакции в ожидаемом порядке. Кроме того, будет введен механизм ротации ключей (rotation mechanism), чтобы предотвратить повторение исторических транзакций. Самое замечательное то, что pRuntime скрывает от вас все эти сложные детали реализации, и реализация конфиденциальных контрактов происходит, как при разработке обычных программ.

ferry работает как мост между блокчейном Phala и pRuntime. Это гарантирует, что все транзакции в блокчейне будут точно перенаправлены в pRuntime, а все экземпляры анклава будут работать с немодифицированной версией pRuntime. Хотя стоит отметить, что pRuntime не доверяет pherry, он по-прежнему будет проверять каждый блок и транзакцию, которые получает от pherry.

2.6 Блокчейн-сущности

В предыдущем разделе (2.5 ) была рассмотрена архитектура Phala, а на этой странице будут затронуты сущности Phala, типы узлов, составляющих сеть Phala.

В Phala Network существует три типа объектов:

• Client, который работает на обычных устройствах без каких-либо особых требований к оборудованию;

• Worker, который работает на Secure Enclave и служит вычислительными узлами для конфиденциальных смарт-контрактов;

• Gatekeeper, который работает на Secure Enclave и выполняет функции органов власти и управления ключами.

Ниже показана взаимодействие между сущностями Phala.

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

Инициализация ключа объекта (Entity Key Initialization)

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

1. IdentityKey

• ansr25519key pair to uniquely identify an entity;

2.EcdhKey

• ansr25519key pair for secure communication;

Инициализация pRuntime

Во время инициализации pRuntime автоматически генерирует указанные выше пары ключей объекта с помощью генератора случайных чисел. Сгенерированные пары ключей управляются в pRuntime в Secure Enclave, что означает, что рабочие процессы и привратники могут использовать его только с ограниченными API-интерфейсами, экспортируемыми pRuntime, и никогда не могут получить пары ключей открытого текста для считывания зашифрованных данных из Secure Enclave.

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

Защищенные каналы связи

Открытый EcdhKey ключ pRuntime исполнителя или привратника общедоступен. Следовательно,протокол согласования ключей ECDH(ECDH key agreement protocol**)**может применяться для установления безопасного канала связи между исполнителем (или привратником) (worker (or a gatekeeper) и любым другим объектом в не интерактивном режиме.

Канал между двумя объектами,AиB, обозначается как Channel(PkA,PkB) , гдеPkAиPkB— это открытые ключи их пар ключей ECDH соответственно. Общий секрет может быть получен из личного ключа ECDH и открытого ключа контрагента с помощью алгоритма Диффи Хеллмана (Diffie Hellman algorithm). Затем окончательный ключ связи CommKey(A, B) можно вычислить с помощью односторонней функции. Наконец, CommKey(A, B) используется для шифрования сообщений между двумя объектами.

В Khala EcdhKey sr25519 ключевая пара . Мы можем использовать функции получениядочерних ключей (CKD)из биткойн BIP32, чтобы получить CommKey(A, B) из ключа, согласованного ECDH. Сообщения шифруются сквозным шифрованием с помощью aes-gcm-256.

**Открытый ключ объектов регистрируется в сети.**Таким образом, мы можем создавать каналы связи внутри цепочки или за ее пределами:

• Связь в цепочке

1. Оба, A и B знают открытый ключ друг друга из блокчейна. Они могут получить CommKey(A, B);

2. A шифрованное сообщение, зашифрованное CommKey(A, B) , в блокчейн;

3. B получает его и расшифровывает с помощью CommKey(A, B);

• Оффчейн (A находится вне сети, а B является ончейн worker) Коммуникация

1. Aможет узнатьBпубличный ключ из CommKey(A, B);

2. Aможет узнать точку API endpointBиз своего WorkerInfo в WorkerState ончейн;

3. Aотправляет подписанное шифрованное сообщение (зашифрованное CommKey(A, B)) со своим открытым ключом B непосредственно

4. BполучаетAпубличный ключ из сообщения и извлекает CommKey(A, B) для его расшифровки;

Пример полезной нагрузки Client-worker

Клиент взаимодействует с worker только для вызова контракта. Вызов состоит как минимум из следующих полезных данных.

{

from: Client_IdentityKey,

payload: {

to: Contract_IdentityKey,

input: “0xdeadbeef”,

},

nonce: 12345,

sig: UserSignature,

}

• nonceнеобходим для защиты от атаки Double-spend и Replay.

• fromпоказывает личность вызывающего абонента и может быть проверено с помощью sig, from будет далее передано контракту.

• поскольку рабочий процесс может запускать несколько контрактов (или даже разные экземпляры одного и того же контракта),toнеобходимо указать цель вызова.

• inputкодирует вызываемую функцию и аргументы, он должен быть сериализован (serialized) в соответствии с ABI контрактов.

Сериализация (Serialization)

EcdhKey Ротация

В отличие от IdentityKey , который показывает личность работника или gatekeeper, поэтому его не следует изменять. Мы рекомендуем регулярную ротацию EcdhKey для обеспечения безопасности каналов связи между различными объектами. В будущем pRuntime будет автоматически менять управляемый EcdhKey через определенный интервал времени.

С первоисточником статьи можно ознакомиться здесь1и2

💎 —Discord PhalaNetwork|Телеграм|Telegram en

✅ — |Website|Twitter|Github|Forum|

🤖 —Discord Phala Word