Ему не нужна альтернатива. Она нужна другим. Web 3.0 не для домохозяек, а для тех кто работает с контентом и генерит контент. А домохозяйки останутся при своем)
Тогда она и ничего менять не будет.
Конечно) За нее все поменяют. А что, она что-то меняла при появлении web 2.0?
Вы не совсем точно сформулировали хотелки пользователя. Он не хочет зайти на FB (сайт), он хочет либо высказаться сам, либо почитать, что написал некто другой и оставить комментарий. И он это получит. Но без Facebook'а, без сайта — места, которое некоторая корпорация определила для реализации хотелок пользователей.
что изменится для «домохозяйки»
Ничего. Она даже не заметит, что общение между домохозяйками перешло на другую технологию. Изменения заметят те, кто профессионально работает с контентом.
Описанное — это естественное развитие идеи блокчейна (прочитайте по ссылкам вначале статьи предыдущие тексты). А рейтинг, как и другие частные решения, прицепят.
И у меня была попытка реализовать подобную идею в 2012 году (http://noospherenetwork.com/), но ряд обстоятельств также застопорили проект.
Сейчас я планирую заходить с другой стороны — собирать по частям, ориентируясь на корпоративные продукты и IoT. Плюс есть надежда на смену объектной онтологии темпоральной/событийной. Без этого может получиться только очередной граф знаний.
Собственно, эту стратегию и реализует потихоньку яндекс
Да, и это так) Проблема только в централизованном управлении, в держании корня в одних руках. Не факт, что получится по-другому. Но мыслить в эту сторону надо.
Либо доверие к новому устройству устанавливается кругом ближайших пользователей, которые «голосуют» и делают запись, например, в блокчейн о новом устройстве и его открытом ключе.
Да, исходно мыслится именно это вариант — создание децентрализованных сетей доверия открытых ключей. Блокчейн не нужен, поскольку сам граф (отдельные его ветки с достаточным уровнем консенсуса выполняют его роль).
он сможет сделать с ней всё, что захочет.
Да, конечно. В тексте и не было заявлено решение проблемы защиты данных. Главная решаемая задача — унификация хранения и поиска данных, устранение дублирование и защита от фальсификации.
На мой взгляд, работа в семантическом браузере будет не сложнее, чем навигация по миллионам сайтов: в минимальном варианте просто текстовый запрос — ответ по связанным с ним моделям или выбор из каталога view-моделей.
И про «кто разрабатывать» ответ есть. Дело в том, что закладываемые технологии (субъектно-событийный подход к моделированию сложных систем, темпоральный граф знаний и семантическая кластеризация пиринговой сети) нужны для совершенно прагматических вещей: моделирование бизнес процессов и обслуживания интернета вещей. То есть, основные компоненты могут быть подготовлены по отдельности.
Спасибо. Сначала отвечу предложением из текста: «Конечно, тут надо говорить не о блокчейне как таковом (цепочке криптосцепленных блоков), а о технологии, обеспечивающей идентификацию пользователей, консенсусную валидацию и защиту контента на основе криптографических методов в одноранговой сети». Таки да, обсуждать надо не блокчейн, а именно доверительное хранилище данных или чуть шире Trusted Digital Systems (как я это называю), то есть системы, которые поддерживают достоверность данных при их хранении и преобразованиях.
Действительно задачу доверительных данных надо формулировать с нуля и решать по-разному на разных уровнях и в разных предметных кластерах, а не городить цепочку блоков. От блокчейна оставить хеш-связывание, даже децентрализация хранения и работа с крипто-ключами реализовывалось до и вне его.
С ходу в голову не приходит какие данные от вещей могут быть публично доступны, при этом критически важно должна быть гарантия неизменности их истории
А это все, что подпадает под простое понятие «юридическая значимость» — все дипломы, сертификаты, права собственности, контракты и пр. ну и данные на которые они непосредственно ссылаются. По сути, речь идет о следующем этапе работы с электронной подписью, когда все операции подписания, проверки и создания юридически значимых ссылок должны уйти в сеть и реализовываться автоматически. И конечно, исходно должна поддерживаться темпоральность (историчность) хранилилища. И городить это надо в комплексе с сетевыми и семантическими решениями. Иначе не заработает.
Спасибо за комментарий. Позитивный, умный, профессиональный.
Блокчейн-то бы туда, быть может.
Блокчейн в его блок-цепочном виде, конечно, не покатит. Но от него можно взять историю с криптографией (идентификация по ключам, подписывание ключами, хеш-сцепка в графе), валидацию с консенсусом, ну и дублирование данных на узлах, то есть по сути то, что можно поименовать словами Trusted Digital System — системы, в которых преобразование данных происходит с сохранением их достоверности.
Сделать triplestorе поверх какой-то ledger database наверняка можно, но вызывает вопросы производительность.
Хранилище данных поверх блоков — это нормально (пока, правда, используются стандартные БД, у нас в Apla — PG). В этом случае производительность падает только на запись (формирование блоков, консенсус, виртуальная машина), а запросы к хранилищу — как обычно (если только не запрашивать несколько узлов для валидации).
Но поскольку речь идет именно о семантике, то есть однозначной сепарации транзакций по предметным областям и моделям, то нет необходимости сваливать их в один блок, можно обрабатывать параллельно и встраивать сразу в хранилище (в соответствующий фрагмент графа). Ну и стоит заметить, что RDF (в его стандартном виде) уже следует заслуженно похоронить (складывается такой консенсус в отрасли). Мне хочется заменить его на событийное описание. Тогда граф получится направленным и ациклическим. (Но это уже отдельная тема).
Мне это ваше утверждение кажется большим авансом.
Ветви событийного графа могут представлять собой потоки событий, организующих процессы и действия, а это нечто иное, чем объектные графы. Скармливать сеткам такие ветки гораздо интересней.
Еще раз спасибо за комментарий.
P.S. Мне очень понравилась ваша NitrosBase. Это именно то, о чем я мечтал для реализации событийной БД. Мы в ближайшем будущем возобновляем работу над прототипом и обязательно попробуем реализовать его на NitrosBase.
P.P.S. Про событийный подход можно прочитать мою статью на хабре (если заинтересует могу предложить материалы на уровне ТЗ).
Насколько мне известно, Hyperledger не использует майнинг, правда ли это?
У них продукт исключительно для приватных сетей — для бизнес и финтех приложений, и нет не только майнинга, но и токенов.
Если так, то мне не понятно, как это может функционировать?
Есть множество алгоритмов консенсуса, то есть путей достижения согласия о том, что транзакции и в целом блок валидны. Поскольку узлами Fabric являются не случайные пользователи, а бизнес агенты, то они сами выбирают требуемый уровень безопасности.
Вот если бы вам сказали, мол, есть такая IT система (база данных и движок для исполнения программных модулей), которую ни взломать, ни фальсифицировать невозожно, данные из которой пропасть не могут и она способна гарантированно и однозначно выполнять встраиваемые в нее алгоритмы — нашли бы вы для такой системы применение? Вот всем и показалось, что практических применений для такой штуки — туча. Дело за малым — дождаться первых выходов тестовых версий на уровень продакшн. А пока еще нет ни одного блокчейн проекта (кроме крипты, конечно), который можно было бы отнести к 100% реализованным. Слишком мало прошло еще времени. Ближе всех к практическому применению IBM со своим Hyperledger Fabric в проекте цепочек поставок.
Из этого текста, что разрабатывается, конечно, не понять: вчитывайся — не вчитывайся. А вот посмотреть ссылку на исходный код можно, там есть переход на документацию.
Отмечу, что в той же истории с «кражей» в TheDao — такого или любого иного заранее продуманного механизма разрешения конфликтов не было. Что собственно и сделало его неразрешимым.
Да, здесь самые главные слова это «заранее продуманного». По сути, законы — это и есть такие заранее продуманные алгоритмы разрешения проблемных ситуаций (наравне с регламентирующими/ограничивающими законами). Ситуации с TheDao можно было бы избежать при наличии нескольких законов: (1) предоставление права остановить контракт, (2) процедура устранения нарушения (возврат денег на счет), (3) предоставления права после выполнения (1) применить или не применить (2).
1. Не скажу, что все затронутые вами вопросы уже досконально проработаны, но известны и обсуждаются.
Или нужен специализированный программист-юрист (которых пока что нет).
Здесь нет никакой специфики по сравнению с обычной работой обычного программиста: тысячи и тысячи программистов пишут код по ТЗ совершенно не разбираясь в предметной области, по сути, они просто реализуют алгоритмы составленные специалистами-аналитиками.
как верифицировать код смарт контракта на его соответствие тому, что мне надо?
Так же как верифицируется код любой программы на его соответствие ТЗ — пишутся программные тесты, привлекаются специалисты по тестированию. Ведь задача вполне формальная — проверить работу исходного алгоритма.
Это будет некий диалог с программой-конструктором контрактов?
Да, уже сейчас мы ставим задачу перехода к графическим интерфейсам для написания контрактов — необходимо дать юристу интуитивно понятный инструмент для написания и проверки контракта не прибегая к языку программирования.
2.
Но среди описанных функций смарт законов я не увидел функции разрешения конфликтов.
Во-первых, этот момент просто вышел за рамки сугубо технического текста. Во-вторых, и в оффлайн жизни это не функция закона, а задача суда. То есть в системе будет предусмотрены «заглушки», останавливающие выполнение контракта или закона в специально прописанных конфликтных ситуациях и отсылающие запрос в реальный суд (или другой контрольный орган). Для возобновления работы алгоритма будет требоваться решение, подписанное ключом судьи.
Ну какой-то смысл, конечно, есть. И некоторые государства (тот же Дубай) уже начинают переход на цифровую платформу.
Но полностью система заработает только как международная (это кстати понимают и сразу декларируют в Дубае), поскольку огромное число транзакций и сделок у любого государства именно внешние. Если система e-Government в каждой стране будет своя, то отношения между агентами из разных стран будут по типу смены колесных пар под вагонами при пересечении границы)))
Конечно) За нее все поменяют. А что, она что-то меняла при появлении web 2.0?
Ничего. Она даже не заметит, что общение между домохозяйками перешло на другую технологию. Изменения заметят те, кто профессионально работает с контентом.
Сейчас я планирую заходить с другой стороны — собирать по частям, ориентируясь на корпоративные продукты и IoT. Плюс есть надежда на смену объектной онтологии темпоральной/событийной. Без этого может получиться только очередной граф знаний.
Да, конечно. В тексте и не было заявлено решение проблемы защиты данных. Главная решаемая задача — унификация хранения и поиска данных, устранение дублирование и защита от фальсификации.
И про «кто разрабатывать» ответ есть. Дело в том, что закладываемые технологии (субъектно-событийный подход к моделированию сложных систем, темпоральный граф знаний и семантическая кластеризация пиринговой сети) нужны для совершенно прагматических вещей: моделирование бизнес процессов и обслуживания интернета вещей. То есть, основные компоненты могут быть подготовлены по отдельности.
Действительно задачу доверительных данных надо формулировать с нуля и решать по-разному на разных уровнях и в разных предметных кластерах, а не городить цепочку блоков. От блокчейна оставить хеш-связывание, даже децентрализация хранения и работа с крипто-ключами реализовывалось до и вне его.
А это все, что подпадает под простое понятие «юридическая значимость» — все дипломы, сертификаты, права собственности, контракты и пр. ну и данные на которые они непосредственно ссылаются. По сути, речь идет о следующем этапе работы с электронной подписью, когда все операции подписания, проверки и создания юридически значимых ссылок должны уйти в сеть и реализовываться автоматически. И конечно, исходно должна поддерживаться темпоральность (историчность) хранилилища. И городить это надо в комплексе с сетевыми и семантическими решениями. Иначе не заработает.
P.S. Вот тут подробнее: Блокчейн и государство
WEB 3.0 или жизнь без сайтов
Блокчейн в его блок-цепочном виде, конечно, не покатит. Но от него можно взять историю с криптографией (идентификация по ключам, подписывание ключами, хеш-сцепка в графе), валидацию с консенсусом, ну и дублирование данных на узлах, то есть по сути то, что можно поименовать словами Trusted Digital System — системы, в которых преобразование данных происходит с сохранением их достоверности.
Хранилище данных поверх блоков — это нормально (пока, правда, используются стандартные БД, у нас в Apla — PG). В этом случае производительность падает только на запись (формирование блоков, консенсус, виртуальная машина), а запросы к хранилищу — как обычно (если только не запрашивать несколько узлов для валидации).
Но поскольку речь идет именно о семантике, то есть однозначной сепарации транзакций по предметным областям и моделям, то нет необходимости сваливать их в один блок, можно обрабатывать параллельно и встраивать сразу в хранилище (в соответствующий фрагмент графа). Ну и стоит заметить, что RDF (в его стандартном виде) уже следует заслуженно похоронить (складывается такой консенсус в отрасли). Мне хочется заменить его на событийное описание. Тогда граф получится направленным и ациклическим. (Но это уже отдельная тема).
Ветви событийного графа могут представлять собой потоки событий, организующих процессы и действия, а это нечто иное, чем объектные графы. Скармливать сеткам такие ветки гораздо интересней.
Еще раз спасибо за комментарий.
P.S. Мне очень понравилась ваша NitrosBase. Это именно то, о чем я мечтал для реализации событийной БД. Мы в ближайшем будущем возобновляем работу над прототипом и обязательно попробуем реализовать его на NitrosBase.
P.P.S. Про событийный подход можно прочитать мою статью на хабре (если заинтересует могу предложить материалы на уровне ТЗ).
Есть множество алгоритмов консенсуса, то есть путей достижения согласия о том, что транзакции и в целом блок валидны. Поскольку узлами Fabric являются не случайные пользователи, а бизнес агенты, то они сами выбирают требуемый уровень безопасности.
1. Не скажу, что все затронутые вами вопросы уже досконально проработаны, но известны и обсуждаются.
Здесь нет никакой специфики по сравнению с обычной работой обычного программиста: тысячи и тысячи программистов пишут код по ТЗ совершенно не разбираясь в предметной области, по сути, они просто реализуют алгоритмы составленные специалистами-аналитиками.
Так же как верифицируется код любой программы на его соответствие ТЗ — пишутся программные тесты, привлекаются специалисты по тестированию. Ведь задача вполне формальная — проверить работу исходного алгоритма.
Да, уже сейчас мы ставим задачу перехода к графическим интерфейсам для написания контрактов — необходимо дать юристу интуитивно понятный инструмент для написания и проверки контракта не прибегая к языку программирования.
2.
Во-первых, этот момент просто вышел за рамки сугубо технического текста. Во-вторых, и в оффлайн жизни это не функция закона, а задача суда. То есть в системе будет предусмотрены «заглушки», останавливающие выполнение контракта или закона в специально прописанных конфликтных ситуациях и отсылающие запрос в реальный суд (или другой контрольный орган). Для возобновления работы алгоритма будет требоваться решение, подписанное ключом судьи.
Более развернуто это проблема описана мной в тексте "Код — это не закон, а закон – это не код"
Но полностью система заработает только как международная (это кстати понимают и сразу декларируют в Дубае), поскольку огромное число транзакций и сделок у любого государства именно внешние. Если система e-Government в каждой стране будет своя, то отношения между агентами из разных стран будут по типу смены колесных пар под вагонами при пересечении границы)))