$TBC

TBC (Тьюринг Битчейн)
На основе этой архитектуры DeFi-приложения на TBC демонстрируют совершенно отличные от традиционной экосистемы характеристики безопасности. Например, в случае децентрализованных бирж: пользователям не требуется разрешать платформе управлять активами их кошелька во время торговли, вместо этого они напрямую завершают сделку с использованием атомарных обменов UTXO, что позволяет осуществить «деньги и товар одновременно»; даже если в контракте платформы есть уязвимость, хакеры не могут украсть активы пользователей, которые они не подписали. То же самое касается кредитных протоколов — активы, которые пользователи закладывают, всегда контролируются ими самими, и автоматическое исполнение происходит только при выполнении условий ликвидации через предварительно подписанную транзакцию, а не путем передачи прав на управление активами в контракт заранее. Даже сделки с NFT реализуют истинный принцип «деньги за товар»: когда покупатель производит оплату, право собственности на NFT передается через одну UTXO, и обе стороны не нуждаются в доверии к посреднику платформы. Общая черта этих сценариев: безопасность больше не зависит от «доверия» к третьим лицам, а достигается благодаря проектированию архитектуры, обеспечивающему «естественную безопасность без доверия».
Более важно обратить внимание на то, что модель UTXO TBC способствует «перемещению парадигмы безопасности». Традиционная концепция безопасности в DeFi заключается в «устранении уязвимостей» и «зависимости от аудитов» — командам проектов необходимо постоянно исправлять уязвимости в контрактах, а пользователи должны постоянно быть настороже в отношении рисков авторизации. В то время как подход TBC заключается в «иммунитете архитектуры» — устранение потребности в авторизации на уровне основы, что делает большинство векторов атак по сути несуществующими. Например:
Нет риска фишинга: поскольку не существует транзакции approve, хакеры не могут подделать страницу авторизации, чтобы получить права;
Без уязвимостей в контрактах для кражи монет: даже если разработанный контракт имеет недостатки, хакеры не могут напрямую перемещать активы пользователей;
Нет злоупотребления безлимитным разрешением: пользователи не могут установить «безлимитный лимит», все сделки должны быть четко подписаны.
Это преобразование не только снизило уровень тревожности пользователей по поводу безопасности, но и освободило творческую силу разработчиков — им больше не нужно тратить много сил на разработку сложной логики управления правами, а можно сосредоточиться на пользовательском опыте и инновациях.