В последнее время, читая обсуждения в сообществе @BabylonLabs_io , я наткнулся на упоминание тем, связанных с Finality Provider, и вдруг подумал: если в будущем все больше сетей будет полагаться на Babylon для обеспечения безопасности, то на чем будут основываться те, кто участвует в безопасности, чтобы гарантировать, что они не будут творить зло?
Этот вопрос на самом деле довольно интересный. Когда люди обсуждают разделяемую (shared) безопасность, первая реакция обычно — посмотреть, сколько активов заходит, сколько сетей подключено, но почти никто не пытается выяснить, как система узнаёт, если участник действительно начинает действовать во вред. И как тогда его наказывать?
Раньше в PoS-сетях эта проблема решалась относительно напрямую: валидаторы блокировали свои активы, и если возникал дабл-сйн (двойная подпись), то цепочка могла просто применить Slash. Но в случае Babylon ситуация не совсем такая. Участники предоставляют дополнительные возможности для обеспечения безопасности, и система должна учитывать, как сохранить для таких внешних участников достаточно сильные ограничения.
Однако здесь есть различие: в традиционных PoS валидаторы и сама сеть находятся в одной и той же системе. Если кто-то ошибается, цепочка может обработать это напрямую. А $BABY имеет дело с другой ситуацией — люди, которые предоставляют безопасность, не относятся к тем же сетям.
Именно на этом вопросе я начал обращать внимание на EOTS. Finality Provider, участвуя в подтверждении, должен генерировать одноразовую подпись с помощью EOTS. Если участник попытается создать конфликтное состояние на одном и том же уровне (в одной высоте), такое действие оставит распознаваемые доказательства, что затем запустит наказание.
Мне кажется, по-настоящему EOTS работает не в том, чтобы сделать участников сильнее, а в том, чтобы они понимали: совершать зло означает оставлять следы.
Только на этом этапе я понял, что задача, которую пытался решить #baby , может оказаться не такой простой. Многие проекты, говоря о безопасности, подчеркивают, сколько средств участвует. Но то, что действительно определяет, сможет ли система безопасности работать долго, — есть ли у системы возможность найти участника, если он допустил ошибку.
Возвращаясь к EOTS, я думаю, что интересная его сторона заключается не в том, что он создает новый тип подписи, а в том, что он закрывает звено, которое в shared security-системе легко упустить. Когда во все больше сетей безопасности входят внешние участники, вопрос о том, как доказать, кто соблюдает правила, а кто пытается их нарушить, может стать ключевой проблемой в конкуренции инфраструктур.
Конечно, сможет ли этот механизм в итоге пройти проверку временем — покажет время.
Этот вопрос на самом деле довольно интересный. Когда люди обсуждают разделяемую (shared) безопасность, первая реакция обычно — посмотреть, сколько активов заходит, сколько сетей подключено, но почти никто не пытается выяснить, как система узнаёт, если участник действительно начинает действовать во вред. И как тогда его наказывать?
Раньше в PoS-сетях эта проблема решалась относительно напрямую: валидаторы блокировали свои активы, и если возникал дабл-сйн (двойная подпись), то цепочка могла просто применить Slash. Но в случае Babylon ситуация не совсем такая. Участники предоставляют дополнительные возможности для обеспечения безопасности, и система должна учитывать, как сохранить для таких внешних участников достаточно сильные ограничения.
Однако здесь есть различие: в традиционных PoS валидаторы и сама сеть находятся в одной и той же системе. Если кто-то ошибается, цепочка может обработать это напрямую. А $BABY имеет дело с другой ситуацией — люди, которые предоставляют безопасность, не относятся к тем же сетям.
Именно на этом вопросе я начал обращать внимание на EOTS. Finality Provider, участвуя в подтверждении, должен генерировать одноразовую подпись с помощью EOTS. Если участник попытается создать конфликтное состояние на одном и том же уровне (в одной высоте), такое действие оставит распознаваемые доказательства, что затем запустит наказание.
Мне кажется, по-настоящему EOTS работает не в том, чтобы сделать участников сильнее, а в том, чтобы они понимали: совершать зло означает оставлять следы.
Только на этом этапе я понял, что задача, которую пытался решить #baby , может оказаться не такой простой. Многие проекты, говоря о безопасности, подчеркивают, сколько средств участвует. Но то, что действительно определяет, сможет ли система безопасности работать долго, — есть ли у системы возможность найти участника, если он допустил ошибку.
Возвращаясь к EOTS, я думаю, что интересная его сторона заключается не в том, что он создает новый тип подписи, а в том, что он закрывает звено, которое в shared security-системе легко упустить. Когда во все больше сетей безопасности входят внешние участники, вопрос о том, как доказать, кто соблюдает правила, а кто пытается их нарушить, может стать ключевой проблемой в конкуренции инфраструктур.
Конечно, сможет ли этот механизм в итоге пройти проверку временем — покажет время.