LITMIR.BIZ

На самом деле для меня близка парадигма, что разработчик-будущего (условно в «Тени завтрашнего солнца» называю его «модельер») создаёт некие бизнес- или же модели быта, а уже искусственный интеллект пишет собственно смарт-контракт (В. П.).

Приведу верное замечание А. Пискунова: «Сайт в текущей ситуации всегда централизован: кто владеет доменом – может указать сервер, который будет выдаваться посетителям; кто владеет сервером – может указать скрипты/файлы для взаимодействия с пользователями; кто владеет скриптами/файлами (имеет к ним доступ) – может менять содержимое и выполнять js-код у посетителей на компьютере; пользование сайтом – акт доверия: во-первых, владельцу домена; во-вторых, владельцу сервера; в-третьих, владельцу файлов. Не бывает децентрализованных сайтов „пока“. Бывают сайты, где открыт код, который можно изучить, где можно посмотреть потоки данных и решить для себя: заслуживают ли они доверия? Сайты/скрипты могут отдать часть ресурсов/данных на управление пользователям – и всё! Дать доступ к файлам/скриптам – не могут, так как нельзя доверять их содержимому, а если дать „управлять“ файлами – то это дыра (как загрузка вредоносных скриптов и взлом изнутри уже)». Всё это так, скажу я (В. П.), но выше идёт речь именно о модели, когда условный сайт становится таким же открытым вместилищем, как и любая ДРС. Методология создания таких «сайтов» представляет собой совокупность практик совместных репозиториев (на Github или других ресурсах), построения p2p-сетей формата TOR или торрентов, а равно и консенсусные решения внутри ДРС.

Опять же – адресую к комментарию А. Пискунова: «Единая авторизация предполагает и единый ключ шифрования данных для взаимодействия с другими участниками». Не понял (этот момент): что, если Гугл решит авторизовать другого пользователя от твоего имени? Это акт доверия: исключить «доверие» можно лишь при использовании распределённых систем для получения публичного ключа, чтобы провести проверку действия, когда юзеры будут подписывать своим ключом все действия – только тогда можно убедиться, что перед тобой нужный юзер: юзер должен понимать – что ОН владелец «авторизации». Потерял ключ = потерял личину на сайте, поэтому не понимаю «единая авторизация предполагает и единый ключ шифрования данных» для взаимодействия с другими участника. Возможно, это объяснено не под тем углом: (как) говорил, единая авторизация возможна в том случае, если есть провайдер публичных личин (пространства имён) и ты можешь проверить там публичный ключ (ключ подписи). Тогда любой сайт сможет обратиться к доверительному сервису с доступом к данным из того или иного блокчейна, а может, у него своя нода для доступа к эфиру. Получить проверку – что перед ним тот аккаунт, который «доказал», что это он, с помощью криптографии. Мне не нравится предложение «единая авторизация предполагает и единый ключ шифрования данных для взаимодействия с другими участниками». Оно (несколько) путает: ключ шифрования – всё-таки другая вещь, не ключ для криптографической валидации подписи. Есть криптографические методы для нахождения shared key между двумя ключами, когда каждый участник может с помощью публичного ключа собеседника и своего приватного ключа получить shared key, который уже можно использовать для шифрования сообщений. Этот shared key получается одинаковый у обоих собеседников: никто другой не может получить его, для этого нужно знать один из приватных ключей двух собеседников. Опять же, всё верно (с моей точки зрения – В. П.), но смысл фразы сводится к тому, что сегодня – эпоха мультиблокчейнов, а за ней необходимым образом следует эпоха мультихранилищ ключей авторизации/шифрования/валидации, но пока, конечно же, это лишь гипотеза.