Краткий ответ на ваш вопрос - использование прокси-сервера, в документации, на которую вы ссылаетесь в вопросе, упоминается здесь https://sawtooth.hyperledger.org/docs/core/releases/1.1/sysadmin_guide/rest_auth_proxy.html#using -a-proxy-server-to-authorize-the-rest- api
Возможно, отсутствует готовый компонент, который выполняет то, что вы просите. Там определенно есть возможность делать то, что вы просите. Вы можете добавить фильтрацию logi c по адресу чтения на прокси-сервере.
Дополнительные пояснения:
Если вы рассматриваете один экземпляр Validator на организацию , Организация участвует в случае использования приложения блокчейн, тогда все участники сети могут видеть данные, которые вы храните в хранилище состояний. Участвующие организации несут ответственность за ограничение доступа к своим данным. Использование прокси-сервера является одним из таких способов.
Если вы планируете добавить несколько вариантов использования для каждой организации, участвуя в другой сети, тогда желательно иметь другой экземпляр Validator для этих случаи использования, которые требуют изоляции. Опять же, каждая организация несет ответственность за защиту данных, хранящихся в сети, в которой они участвуют.
Что касается пункта 2, предлагаемое решение Hyperledger Sawtooth 2.0 позволяет запускать несколько экземпляры валидатора как службы в одном процессе. Это означает, что у вас может быть один физический узел (также процесс), участвующий в нескольких каналах, обеспечивающих изоляцию.
Прежде чем я заканчиваю ответ для других, ищущих ответ: блокчейн - это не просто распределенное хранилище, но и децентрализованная сеть. Существует ряд шаблонов проектирования, которые позволяют нам хранить критические данные за пределами сети блокчейна и использовать функциональные возможности сети блокчейна (достижение консенсуса, умная проверка контракта должна быть указана c) для ожидаемых действий.