Использование blockchain для оценки доверия сайту
Давно интересуюсь вопросами доверия в Интернете, и пришла в голову мысль, что тут могла бы пригодиться blockchain-технология для создания отзывов и оценок. В результате придумал алгоритм, который выглядит так (если расписать с помощью традиционных для криптографии персонажей Алиса, Боб и Чарли):
Естественно, все действия проделываются не вручную, а с помощью дополнения для броузера у Алисы и Чарли и небольшого модуля для сайта Боба, который отвечает за проверку токена на шаге 2. Путь к этому модулю может указываться через заголовок link или обнаруживаться через .well-known/host-meta.
В данном алгоритме я вижу две проблемы. Первая — каким должно быть значение N, которое определяет время генерации токена. Если взять его достаточно большим (чтобы токен генерировался за несколько минут), то Боб легко за сутки сможет накрутить себе сотни оценок, что делает всё это бессмысленным. Если взять больше, несколько часов на генерацию каждого токена, то Алиса может не захотеть столько времени ждать и держать свой процессор нагруженным на 100%. Вторая — это Боб может ещё до выставления оценки по каким-либо причинам счесть пользователя проблемным (допустим, Алиса звонит в магазин и скандалит, назвав при этом номер заказа, а уже потом идёт ставить оценку) и отказаться подписывать его токен, чтобы избежать негативной оценки.
Ещё одна сложность — поддержание списка хранилищ в дополнении. По сути, разработчик дополнения может единолично решать, какие дополнения включить в список, какие нет. Но с другой стороны, владелец каждого хранилища может сделать своё дополнение, и дальше выбор будет за пользователем.
- Алиса хочеть оценить сайт Боба bob.example.com. Для этого она генерирует токен T — некоторую строку, которая начинается с доменного имени сайта Боба, далее идёт разделитель (символ, которого не может быть в доменном имени, например верстикальная черта |), далее — произвольный набор символов, но такой, чтобы хеш от строки был меньше значения некоего численного значения N:
T=Hash("bob.example.com|"+random_string()) valid_code=T<N - Алиса отсылает токен T сайту Боба. Тот проверяет его валидность (то, что использовано доменное имя bob.example.com и хеш реально меньше N) и уникальность. Кроме того, Боб может выставить какие-то дополнительные условия для выставления оценки, например, Алиса должна быть зарегистрированным пользователем сайта, написать там как минимум одно сообщение или сделать хотя бы один заказ, что позволит защититься от накруток со стороны конкурентов/недоброжелателей. Если все перечисленные условия выполняются, то Боб подписывает токен T своей цифровой подписью и возвращает Алисе. При этом Боб не знает, какую оценку ему поставит Алиса.
- Алиса выставляет формализованную оценку доверия сайту (причём можно предусмотреть несколько критериев), а также может написать отзыв в свободной форме.
- Результат (токен+подпись+оценка) отсылается как на сайт Боба, так и в централизованное хранилище отзывов. Хранилище проверяет валидность токена и цифровой подписи, если всё верно, отзыв принимается и сохраняется. Важный момент: храниищ может быть несколько, причем они могут быть как универсальные (аналогично сайту Web of Trust), так и специализированные (скажем, принимать отзывы только для сайтов банков или Интернет-магазинов).
- Далее, если пользователь Чарли хочет узнать, стоит ли доверять сайту Боба, он запрашивает в хранилище все отзывы на bob.exapmle.com, получает оценку Алисы и других пользователей, и делает выводы.
Естественно, все действия проделываются не вручную, а с помощью дополнения для броузера у Алисы и Чарли и небольшого модуля для сайта Боба, который отвечает за проверку токена на шаге 2. Путь к этому модулю может указываться через заголовок link или обнаруживаться через .well-known/host-meta.
В данном алгоритме я вижу две проблемы. Первая — каким должно быть значение N, которое определяет время генерации токена. Если взять его достаточно большим (чтобы токен генерировался за несколько минут), то Боб легко за сутки сможет накрутить себе сотни оценок, что делает всё это бессмысленным. Если взять больше, несколько часов на генерацию каждого токена, то Алиса может не захотеть столько времени ждать и держать свой процессор нагруженным на 100%. Вторая — это Боб может ещё до выставления оценки по каким-либо причинам счесть пользователя проблемным (допустим, Алиса звонит в магазин и скандалит, назвав при этом номер заказа, а уже потом идёт ставить оценку) и отказаться подписывать его токен, чтобы избежать негативной оценки.
Ещё одна сложность — поддержание списка хранилищ в дополнении. По сути, разработчик дополнения может единолично решать, какие дополнения включить в список, какие нет. Но с другой стороны, владелец каждого хранилища может сделать своё дополнение, и дальше выбор будет за пользователем.
