На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
17 Лайков
Награда
17
8
Репост
Поделиться
комментарий
0/400
TrustlessMaximalist
· 23ч назад
Черт, эта идея действительно довольно крутая. Вписать условия соответствия в протокольный уровень? Кажется, наконец-то кто-то нашел правильный способ решения.
Посмотреть ОригиналОтветить0
GhostChainLoyalist
· 01-17 03:06
Черт, этот подход действительно необычный, включить соответствие в уровень кода... довольно интересно
Посмотреть ОригиналОтветить0
SmartContractPlumber
· 01-16 19:58
Фронтенд-валидация — эта игра давно должна была умереть, во время предыдущих аудитов я не раз сталкивался с такими «комплаенс-спектаклями», когда полностью реализованный на стороне цепочки код всё равно обходили на фронтенде. Идея встроить правила в протокол — сама по себе хорошая, но главный вопрос — кто будет аудитировать эту логику контроля доступа? В случае переполнения целых чисел или уязвимости типа reentrancy, сама кодовая база, обеспечивающая соответствие, становится крупнейшей катастрофой, в сто раз опаснее, чем нарушение на стороне цепочки.
Посмотреть ОригиналОтветить0
GasSavingMaster
· 01-16 19:58
Черт, наконец-то какая-то цепочка начала всерьез заниматься соблюдением нормативных требований, раньше эта обманная быстрая и дешевая схема была совсем неинтересной
Посмотреть ОригиналОтветить0
rugdoc.eth
· 01-16 19:44
Наконец-то кто-то подумал о включении соответствия в код, это гораздо надежнее, чем те, кто на словах говорят о соответствии, а при переходе на фронтенд уже оказываются взломанными.
Посмотреть ОригиналОтветить0
WealthCoffee
· 01-16 19:42
Эй, черт возьми, этот подход действительно необычный, включить соответствие в код? Звучит немного жестоко
Посмотреть ОригиналОтветить0
FastLeaver
· 01-16 19:40
По сути, это перемещение вратаря с оффчейн на ончейн, соответствие нормативам больше не является исправлением после факта, а становится предварительным правилом. Это действительно немного отличается.
Посмотреть ОригиналОтветить0
EyeOfTheTokenStorm
· 01-16 19:40
Ну... звучит довольно убедительно, но действительно ли эта логика, которая включает соответствие в код, сможет работать? Исторические данные показывают, что каждый проект с "революционными" улучшениями в конечном итоге терпит неудачу на этапе реализации. Предупреждение о рисках: регулирующая политика является динамической, как адаптироваться к изменениям, если код зафиксирован?
初次了解到这条公链时,我有点懵。
一般的公链怎么自我介绍?「交易速度快、Gas费便宜」,听得耳朵都要起茧子了。还有些DeFi项目上来就甩APY数据、聊资金利用率,套路都被用烂了。
但这条链不走寻常路。它从一个金融工程的终极问题切入:假如某项资产天生就需要接受监管,那么监管的那套规则,能否直接变成链上的代码逻辑?
听起来很抽象?其实不是。这个问题的答案,决定了整条链的架构基因。
**合规的两种玩法**
目前链圈对合规的处理方式,基本都是「外包模式」——合规在链下搞定,前端页面做校验,链本身只负责执行指令就完事。这样的问题在哪?一旦中间环节出岔子,比如前端被攻击或中介操作不当,链根本反应不过来,压根不知道这笔交易违不违规。
换一种思路呢?把合规条件直接写进协议层。
这是什么意思?具体到三个维度:
- 谁有权持有这项资产
- 谁能把资产转给谁
- 什么情况下允许转移
这些决定权不再是人工判断,而是由链的底层规则强制执行。对金融资产来说,这是一次结构性的改变。
**"违规"从此变成"不可能"**
传统金融怎么应对违规?通常是:交易先发生 → 事后发现问题 → 查证 → 罚款 или追责。整个流程是滞后的。
这条链的设想则是另一种:让违规交易根本没有在链上发生的机会。
两种思路看似差不多,实际上差别巨大。一个是发生了再处理,一个是从根本上封死漏洞。对于需要严格合规的资产(比如证券化代币、受监管的稳定币),这个差异能解决的问题绝对不是小事。
这种设计不仅是技术问题,更是一个关于金融系统如何运作的哲学问题。