Web 3.0. Часть I. Настоящее вчерашнего завтра. И. Белоусов
Чтение книги онлайн.
Читать онлайн книгу Web 3.0. Часть I. Настоящее вчерашнего завтра - И. Белоусов страница 17
И в этом смысле W3 – не идеальное, возможно, но вполне допустимое решение, где каждая цепочка взаимосвязей может быть продиктована разной мотивацией и мотиваторами (будь то токены, социально полезная деятельность или что-то ещё).
Централизация и Web 3.0: коротко
Опять же, о полезности споров (но не дискуссий). Намедни, общаясь с одним из ведущих разработчиков, выявил два важных тезиса:
– Сайт может быть57 централизован, но отдать юзерам «управление» своим пространством.
– Единая авторизация58 предполагает и единый ключ шифрования данных для взаимодействия с другими участника.
Действительно, такой подход имеет место быть, но как он соотносится со степенями свободы, выраженными в разнопорядковых цифровых отпечатках личности?
Никак.
Потому как кастомизация интерфейса на сегодня доступна и в Web 2.0, а что касается единой авторизации, то это – техническая «надстройка» над Oauth 2.0 и аналогами. При этом всегда возникает вопрос «рубильника», потому как никакого распределения ответственности de facto не существует и администратор самостоятельно определяет правила, когда и кто имеет право на те или иные действия. Банальные чёрные списки (читай – антисписок Шиндлера).
Но важнее другое: никакая децентрализованная система не допускает ограничений для централизованных система apriori. Тогда как обратное – вполне объяснимо и существует сплошь и рядом.
То есть при доминирующем положении в Web 3.0 p2p-систем нового уровня (нечто подобное сейчас формируется в экосистеме BitTorent & Tron) сохраняется и возможность многомерного распределения, включая и классические, клиент-серверные архитектуры.
В противном же случае цифровая зависимость будет уже не красивым эпитетом, а реальностью, которая вкупе с VR/AR-действительностью поглотит нас в ближайшую четверть века. Нас – как объекты!
Дапсы и локальные глобальные сети – находка архитектуры Web 3.0
Dapps’ы (децентрализованные приложения) широко пиарятся ныне, не хуже ICO в 2016—2017 гг., но чем именно они так хороши? Задумывались ли вы, что сама по себе архитектура дапсов позволяет им быть фактически бесконечно вложенными?59
Что имеем сегодня: есть, допустим, Facebook & Instagram – взаимозависимые приложения. Но их вложенность минимальна: можно делать перепосты, есть ретаргетинг, указание профиля и всё в этом духе. Для пользователя всё равно два разных сервиса. Даже банальные юридические формальности – разные.
С dapps’ами всё не так: в них имеем возможность не только вертикального, но и горизонтального масштабирования, за счёт связок decentralized applications решений. Но и это не всё.
Как помним, W3, в отличие от создаваемой псевдодецентрализованной системы от корпораций
57
Приведу верное замечание А. Пискунова: «Сайт в текущей ситуации всегда централизован: кто владеет доменом – может указать сервер, который будет выдаваться посетителям; кто владеет сервером – может указать скрипты/файлы для взаимодействия с пользователями; кто владеет скриптами/файлами (имеет к ним доступ) – может менять содержимое и выполнять js-код у посетителей на компьютере; пользование сайтом – акт доверия: во-первых, владельцу домена; во-вторых, владельцу сервера; в-третьих, владельцу файлов. Не бывает децентрализованных сайтов „пока“. Бывают сайты, где открыт код, который можно изучить, где можно посмотреть потоки данных и решить для себя: заслуживают ли они доверия? Сайты/скрипты могут отдать часть ресурсов/данных на управление пользователям – и всё! Дать доступ к файлам/скриптам – не могут, так как нельзя доверять их содержимому, а если дать „управлять“ файлами – то это дыра (как загрузка вредоносных скриптов и взлом изнутри уже)». Всё это так, скажу я (В. П.), но выше идёт речь именно о модели, когда условный сайт становится таким же открытым вместилищем, как и любая ДРС. Методология создания таких «сайтов» представляет собой совокупность практик совместных репозиториев (на Github или других ресурсах), построения p2p-сетей формата TOR или торрентов, а равно и консенсусные решения внутри ДРС.
58
Опять же – адресую к комментарию А. Пискунова: «Единая авторизация предполагает и единый ключ шифрования данных для взаимодействия с другими участниками». Не понял (этот момент): что, если Гугл решит авторизовать другого пользователя от твоего имени? Это акт доверия: исключить «доверие» можно лишь при использовании распределённых систем для получения публичного ключа, чтобы провести проверку действия, когда юзеры будут подписывать своим ключом все действия – только тогда можно убедиться, что перед тобой нужный юзер: юзер должен понимать – что ОН владелец «авторизации». Потерял ключ = потерял личину на сайте, поэтому не понимаю «единая авторизация предполагает и единый ключ шифрования данных» для взаимодействия с другими участника. Возможно, это объяснено не под тем углом: (как) говорил, единая авторизация возможна в том случае, если есть провайдер публичных личин (пространства имён) и ты можешь проверить там публичный ключ (ключ подписи). Тогда любой сайт сможет обратиться к доверительному сервису с доступом к данным из того или иного блокчейна, а может, у него своя нода для доступа к эфиру. Получить проверку – что перед ним тот аккаунт, который «доказал», что это он, с помощью криптографии. Мне не нравится предложение «единая авторизация предполагает и единый ключ шифрования данных для взаимодействия с другими участниками». Оно (несколько) путает: ключ шифрования – всё-таки другая вещь, не ключ для криптографической валидации подписи. Есть криптографические методы для нахождения shared key между двумя ключами, когда каждый участник может с помощью публичного ключа собеседника и своего приватного ключа получить shared key, который уже можно использовать для шифрования сообщений. Этот shared key получается одинаковый у обоих собеседников: никто другой не может получить его, для этого нужно знать один из приватных ключей двух собеседников. Опять же, всё верно (с моей точки зрения – В. П.), но смысл фразы сводится к тому, что сегодня – эпоха мультиблокчейнов, а за ней необходимым образом следует эпоха мультихранилищ ключей авторизации/шифрования/валидации, но пока, конечно же, это лишь гипотеза.