Условный контроль доступа IPFS через смарт-контракты ethereum

Вы проверили алгоритм обмена секретами Шамира? Вы можете использовать IPFS для обмена секретами между всеми сторонами и использовать открытые ключи ethereum друг друга для отправки зашифрованных сообщений друг другу.

https://en.wikipedia.org/wiki/Шамир%27s_Secret_Sharing

Если вам абсолютно не нужно использовать основную цепочку Эфириума, вы можете создать частную цепочку кворума между сторонами https://www.jpmorgan.com/global/Quorum , используя секретные контракты.

Вы должны посмотреть на повторное шифрование прокси и Nucypher .

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

Могу поспорить, что сделать это с Ethereum будет чрезвычайно сложно. С учетом сказанного есть следующие варианты, которые вы можете проверить:

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

Ни 1, ни 2 не являются точным решением вашей проблемы, но могут стать отправной точкой для обсуждения.

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

Шифрование медиафайлов обычно требует больших вычислительных ресурсов и памяти, а также общего времени и газа. Но на самом деле в свете того, что сказал @Kherwa; вы можете использовать открытый ключ Алисы, чтобы зашифровать файл и сохранить его в IPFS. Однако это ограничит носитель одним кошельком, использование невзаимозаменяемых токенов ERC721 может сделать то же самое для вас, но с дополнительной гибкостью.

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

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

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