В моей статье показан очень простой пример привязки данных к блокчейну. В реальности ситуация обстоит несколько сложнее. Например, в проекте ION, который реализует стандарт DID на основе блокчейна, используется дополнительный протокол Sidetree, который привязывает к блокчейну с помощью OP_RETURN лишь хэши данных, которые он хранит вне блокчейна. Это сильно уменьшает комиссии транзакций и позволяет реализовать гораздо больше функций.
Ключи А, В, С... подписывают транзакцию. Часть ключей принадлежит одному идентити, часть другому. В случае просирания приватника, можно слинковать другой свой приватник используя другие ключи (свои/не свои) из мультиподписи
Что-то мне подсказывает, что кто потерял один ключ, тот и остальные может потерять. А про схему Шамира для разделения пароля я ещё давно у себя на канале писал.
Ключи А, В, С... подписывают транзакцию. Часть ключей принадлежит одному идентити, часть другому. В случае просирания приватника, можно слинковать другой свой приватник используя другие ключи (свои/не свои) из мультиподписи
Можно использовать ключи из других блокчейнов, главное чтоб ECDSA был такой же
Само собой, но это уже не так вероятно, как если она одна такая. Плюс наверняка нельзя установить соответствие публичных ключей мультиподписи друг другу.
Кстати вы писали за Эстонию в статье. Там это именно так и работает. Потеряли свой приватный ключ, приходите в ментовку, там ваш новый паблик подписывают своим приватником они
Само собой, но это уже не так вероятно, как если она одна такая. Плюс наверняка нельзя установить соответствие публичных ключей мультиподписи друг другу.
Можно. При мультподписи указываются несколько пабликов в транзакции. Если речь не про BLS
Так если просто раздать корпорациям эти ключи, но не использовать их, пока не потребуется, то они не смогут установить, что ключи можно так использовать. А после первого использования они могли бы протухать, например.