Как правильно управлять кошельком для лонгующего вычисления на основе событий Multichain
Недавно CEO одного кросс-чейн протокола был задержан полицией, что привело к невозможности связи с его глобальной командой, а также к отзыву операционных ключей доступа к серверам лонгующих вычислительных узлов. Этот инцидент выявил причины аномальной работы данного протокола и также вызвал важный вопрос: почему, несмотря на использование технологий лонгующих вычислений, все еще существуют такие риски?
Ответ на самом деле очень прост: хотя этот протокол использует технологии лонгующего для управления финансами, децентрализация технологий не равнозначна децентрализации управления. Настоящая децентрализация требует единства в применении технологий и способах управления.
Похожие случаи встречаются довольно часто. Например, биткойн децентрализован, но если один майнер монополизирует всю вычислительную мощность, то децентрализация алгоритма теряет смысл; эфириум также децентрализован, но его основатель продолжает подчеркивать важность распределенной верификационной технологии, чтобы избежать появления централизации.
Дальнейшее изучение деталей объявления показывает, что корень проблемы данного протокола заключается в том, что все узловые серверы фактически работают под личной учетной записью облачного сервера CEO. Эта централизованная услуга узлов и монополия одного майнера на всю вычислительную мощность по сути одинаковы, что эквивалентно тому, что CEO использует единый подписанный Кошелек для контроля всех активов. Таким образом, проблема протокола заключается в том, что CEO не должен контролировать все лонгующие вычислительные фрагменты и не предоставил резервное решение на крайний случай.
Так как же можно в полной мере использовать характеристики технологии многопользовательских вычислений? Основные моменты следующие:
Повышение прозрачности, предотвращение конфликта интересов;
Строго следовать децентрализованным способам хранения, избегая чрезмерной концентрации власти;
Разработать планы действий на случай экстремальных ситуаций.
Предотвращение конфликта интересов: отказ от непрозрачных действий
В этом инциденте одна публичная цепочка также понесла серьезные последствия. Основатель этой цепочки на форуме заявил, что ранее получил множество гарантий по децентрализации серверов, доступу и распределению по географическому положению. Однако впоследствии оказалось, что эти гарантии не были выполнены, и данная цепочка не смогла или не имела возможности проверить это, выбрав простой принцип доверия, в конечном итоге понеся совместные убытки.
Можно увидеть, что многосторонняя вычислительная схема данного кросс-чейн протокола по существу является "черным ящиком". Причина появления такого "черного ящика" заключается в том, что этот протокол является как создателем услуги, так и пользователем услуги, и такое совпадение ролей неизбежно приводит к непрозрачности и потенциальному пространству для злоупотреблений. Решением этой проблемы является привлечение полностью нейтрального третьего лица, не имеющего конфликта интересов, то есть использование многосторонних вычислительных услуг третьей стороны с достаточной репутацией, а не создание собственных услуг.
Конфликт интересов широко распространен в области Web3, например, некоторые централизованные биржи одновременно выполняют функции предоставления торговых услуг и хранения активов для пользователей, и могут получать прибыль от использования этих средств, участвуя в майнинге на блокчейне, маркетмейкинге или инвестициях.
Вернемся к этому событию: если данный кросс-чейн протокол использует достаточно авторитетные сторонние лонгующие вычислительные услуги, то, по крайней мере в рамках разрешений протокола, поставщик услуг может предоставить информацию о верификации хостинга для заинтересованных сторон, тем самым устраняя "черный ящик".
Децентрализованное хранение: избегайте риска единой точки
Постфактумный анализ показывает, что единственная точка риска CEO является прямой причиной данного инцидента. Правильным подходом должно быть обеспечение распределения серверов, доступа и географического положения.
Идеальное решение для многопартитных вычислений должно использовать 3-3 многопартитную подпись (также может поддерживать настройку t-n пороговой подписи), где две части контролируются платформой, обеспечивая безопасность с помощью высокоэффективного шифрования и надежной среды выполнения, и три стороны должны совместно участвовать для завершения подписи транзакции, тем самым избегая единой точки риска для пользователей.
Кроме того, поскольку бизнес обычно имеет иерархическую структуру, доступ к данным также должен быть иерархическим. Можно использовать дизайн с многоуровневым производным приватным ключом, который одновременно облегчает управление глобальными процессами и позволяет операторам первого уровня управлять конкретными правами, избегая тем самым рисков, связанных с единой точкой отказа, которые могут блокировать все бизнес-процессы.
В конце концов, следует использовать такие решения, как онлайн-распределенное многоактивное хранение, многоуровенное офлайн-холодное резервное копирование, интеграция услуг резервного восстановления от профессиональных организаций и т.д., чтобы обеспечить максимальный уровень гарантии распределения по географическим позициям. Эта серия механизмов может в максимальной степени избежать потерь активов или недоступности услуг, вызванных рисками единой точки, включая уровень приватного ключа, уровень персонала и уровень внешней среды.
Разработка плана восстановления социальных связей в экстремальных ситуациях
Необходимо признать, что ни одно решение не является идеальным. Обеспечение децентрализации серверов, доступа и географического расположения может решить часть проблем, но не все. Многие риски все еще существуют, такие как непредвиденные обстоятельства в физическом мире. В случае неизбежного мы должны подумать о том, как реагировать, когда такая крайняя ситуация произойдет.
Исходя из этого, можно представить себе "SOS-режим", предназначенный для рисков непреодолимой силы в физическом мире. Эта услуга может быть предложена пользователям с потребностями в качестве нестандартной, дополнительной услуги и разработана с учетом конкретных требований. Кроме традиционного деления приватного ключа, также будут установлены несколько SOS-частей, которые будут управляться отдельно от обычных частей приватного ключа.
В нормальных условиях SOS-фрагменты не будут выполнять никакой функции. Однако в определенных ситуациях SOS-фрагменты будут активированы, например, в случае экстренной ситуации, когда управляющий фрагментами приватного ключа вручную активирует их, когда разрыв фрагментов приватного ключа достигает определенного временного порога, когда SOS-фрагменты инициируют экстренное событие самостоятельно или после одобрения голосования по установленным правилам. После активации "SOS-режима" SOS-фрагменты заменят фрагменты приватного ключа, обеспечивая передачу или ликвидацию активов в экстренных ситуациях.
Чтобы предотвратить злоупотребления со стороны держателей фрагментов SOS, можно ввести некоторые ограничения, например, установить задержку активации "SOS режима"; в это время обычные фрагменты приватного ключа могут отменить "SOS режим"; или после экстренного перевода активов в "SOS режиме" установить срок блокировки, в течение которого дальнейшие переводы невозможны, чтобы предотвратить потерю активов.
С помощью этих мер мы можем максимально снизить различные риски, обеспечивая безопасность активов и эффективность управления, одновременно полностью используя преимущества технологий многопартийных вычислений.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
14 Лайков
Награда
14
7
Репост
Поделиться
комментарий
0/400
HashBrownies
· 07-23 21:33
集中管理 и Децентрализация изначально противоречат друг другу
Посмотреть ОригиналОтветить0
ChainComedian
· 07-23 17:58
Концентрация власти — это самая большая уязвимость.
Посмотреть ОригиналОтветить0
PrivacyMaximalist
· 07-21 04:18
Если есть прозрачность, то это уже не достаточно децентрализовано.
Правильное управление многопользовательским кошельком: прозрачность, децентрализация и реагирование на крайние случаи
Как правильно управлять кошельком для лонгующего вычисления на основе событий Multichain
Недавно CEO одного кросс-чейн протокола был задержан полицией, что привело к невозможности связи с его глобальной командой, а также к отзыву операционных ключей доступа к серверам лонгующих вычислительных узлов. Этот инцидент выявил причины аномальной работы данного протокола и также вызвал важный вопрос: почему, несмотря на использование технологий лонгующих вычислений, все еще существуют такие риски?
Ответ на самом деле очень прост: хотя этот протокол использует технологии лонгующего для управления финансами, децентрализация технологий не равнозначна децентрализации управления. Настоящая децентрализация требует единства в применении технологий и способах управления.
Похожие случаи встречаются довольно часто. Например, биткойн децентрализован, но если один майнер монополизирует всю вычислительную мощность, то децентрализация алгоритма теряет смысл; эфириум также децентрализован, но его основатель продолжает подчеркивать важность распределенной верификационной технологии, чтобы избежать появления централизации.
Дальнейшее изучение деталей объявления показывает, что корень проблемы данного протокола заключается в том, что все узловые серверы фактически работают под личной учетной записью облачного сервера CEO. Эта централизованная услуга узлов и монополия одного майнера на всю вычислительную мощность по сути одинаковы, что эквивалентно тому, что CEO использует единый подписанный Кошелек для контроля всех активов. Таким образом, проблема протокола заключается в том, что CEO не должен контролировать все лонгующие вычислительные фрагменты и не предоставил резервное решение на крайний случай.
Так как же можно в полной мере использовать характеристики технологии многопользовательских вычислений? Основные моменты следующие:
Предотвращение конфликта интересов: отказ от непрозрачных действий
В этом инциденте одна публичная цепочка также понесла серьезные последствия. Основатель этой цепочки на форуме заявил, что ранее получил множество гарантий по децентрализации серверов, доступу и распределению по географическому положению. Однако впоследствии оказалось, что эти гарантии не были выполнены, и данная цепочка не смогла или не имела возможности проверить это, выбрав простой принцип доверия, в конечном итоге понеся совместные убытки.
Можно увидеть, что многосторонняя вычислительная схема данного кросс-чейн протокола по существу является "черным ящиком". Причина появления такого "черного ящика" заключается в том, что этот протокол является как создателем услуги, так и пользователем услуги, и такое совпадение ролей неизбежно приводит к непрозрачности и потенциальному пространству для злоупотреблений. Решением этой проблемы является привлечение полностью нейтрального третьего лица, не имеющего конфликта интересов, то есть использование многосторонних вычислительных услуг третьей стороны с достаточной репутацией, а не создание собственных услуг.
Конфликт интересов широко распространен в области Web3, например, некоторые централизованные биржи одновременно выполняют функции предоставления торговых услуг и хранения активов для пользователей, и могут получать прибыль от использования этих средств, участвуя в майнинге на блокчейне, маркетмейкинге или инвестициях.
Вернемся к этому событию: если данный кросс-чейн протокол использует достаточно авторитетные сторонние лонгующие вычислительные услуги, то, по крайней мере в рамках разрешений протокола, поставщик услуг может предоставить информацию о верификации хостинга для заинтересованных сторон, тем самым устраняя "черный ящик".
Децентрализованное хранение: избегайте риска единой точки
Постфактумный анализ показывает, что единственная точка риска CEO является прямой причиной данного инцидента. Правильным подходом должно быть обеспечение распределения серверов, доступа и географического положения.
Идеальное решение для многопартитных вычислений должно использовать 3-3 многопартитную подпись (также может поддерживать настройку t-n пороговой подписи), где две части контролируются платформой, обеспечивая безопасность с помощью высокоэффективного шифрования и надежной среды выполнения, и три стороны должны совместно участвовать для завершения подписи транзакции, тем самым избегая единой точки риска для пользователей.
Кроме того, поскольку бизнес обычно имеет иерархическую структуру, доступ к данным также должен быть иерархическим. Можно использовать дизайн с многоуровневым производным приватным ключом, который одновременно облегчает управление глобальными процессами и позволяет операторам первого уровня управлять конкретными правами, избегая тем самым рисков, связанных с единой точкой отказа, которые могут блокировать все бизнес-процессы.
В конце концов, следует использовать такие решения, как онлайн-распределенное многоактивное хранение, многоуровенное офлайн-холодное резервное копирование, интеграция услуг резервного восстановления от профессиональных организаций и т.д., чтобы обеспечить максимальный уровень гарантии распределения по географическим позициям. Эта серия механизмов может в максимальной степени избежать потерь активов или недоступности услуг, вызванных рисками единой точки, включая уровень приватного ключа, уровень персонала и уровень внешней среды.
Разработка плана восстановления социальных связей в экстремальных ситуациях
Необходимо признать, что ни одно решение не является идеальным. Обеспечение децентрализации серверов, доступа и географического расположения может решить часть проблем, но не все. Многие риски все еще существуют, такие как непредвиденные обстоятельства в физическом мире. В случае неизбежного мы должны подумать о том, как реагировать, когда такая крайняя ситуация произойдет.
Исходя из этого, можно представить себе "SOS-режим", предназначенный для рисков непреодолимой силы в физическом мире. Эта услуга может быть предложена пользователям с потребностями в качестве нестандартной, дополнительной услуги и разработана с учетом конкретных требований. Кроме традиционного деления приватного ключа, также будут установлены несколько SOS-частей, которые будут управляться отдельно от обычных частей приватного ключа.
В нормальных условиях SOS-фрагменты не будут выполнять никакой функции. Однако в определенных ситуациях SOS-фрагменты будут активированы, например, в случае экстренной ситуации, когда управляющий фрагментами приватного ключа вручную активирует их, когда разрыв фрагментов приватного ключа достигает определенного временного порога, когда SOS-фрагменты инициируют экстренное событие самостоятельно или после одобрения голосования по установленным правилам. После активации "SOS-режима" SOS-фрагменты заменят фрагменты приватного ключа, обеспечивая передачу или ликвидацию активов в экстренных ситуациях.
Чтобы предотвратить злоупотребления со стороны держателей фрагментов SOS, можно ввести некоторые ограничения, например, установить задержку активации "SOS режима"; в это время обычные фрагменты приватного ключа могут отменить "SOS режим"; или после экстренного перевода активов в "SOS режиме" установить срок блокировки, в течение которого дальнейшие переводы невозможны, чтобы предотвратить потерю активов.
С помощью этих мер мы можем максимально снизить различные риски, обеспечивая безопасность активов и эффективность управления, одновременно полностью используя преимущества технологий многопартийных вычислений.