AlizehAli
11.2k Публикации
AlizehAli
592 подписок(и/а)
24.3K+ подписчиков(а)
8.2K+ понравилось
Посты
Все
Цитирования
Активно
PINNED
@Dusk Конституция страны существует в момент основания страны — ее никто не голосует “впоследствии”, она просто присутствует в первый же день, и все остальное строится, опираясь на нее.
Контракты создания (genesis) Dusk работают так же. Собственные архитектурные материалы Dusk описывают два: контракт ставки (stake), который отслеживает, какие пропорционеры/провайдеры делают стейкинг, фиксирует вознаграждения и обеспечивает действия stake, unstake и вывод reward; и контракт передачи (transfer), который обрабатывает как Moonlight (публичные) так и Phoenix (скрытые) переводы, оплачивает газ и служит точкой входа для выполнения транзакций непосредственно на DuskDS.
Эта базовая роль распространяется дальше, чем один только DuskDS, хотя точный механизм различается по слоям. DuskEVM, согласно собственным документам Dusk, переводит DUSK для оплаты газа через свой мост на Dusk L1, а затем в конечном итоге производит расчет обратно на DuskDS — маршрут, связанный, но отличный от прямой роли контракта transfer в нативных транзакциях DuskDS. Обе дороги ведут к одному и тому же базовому слою; они не являются идентичными механизмами. #dusk
Самокритика: аналогия с конституцией имеет реальный предел, который стоит назвать. Конституцию страны можно формально изменить через определенную процедуру. Чего я не нашел в документации, так это того, следует ли genesis-контрактам Dusk эквивалентный, четко определенный путь изменений, или же под “genesis” здесь функционально подразумевается постоянство по замыслу — настоящий вопрос управления, учитывая, насколько обширный растущий multilayer-стек Dusk сейчас зависит от того, что эти два контракта остаются корректными. $DUSK
DUSK следует оценивать с точки зрения того, проясняется ли эта неоднозначность еще до того, как этим контрактам когда-либо придется обновляться под реальным давлением, а не после.
#dusk $DUSK @Dusk
Контракты создания (genesis) Dusk работают так же. Собственные архитектурные материалы Dusk описывают два: контракт ставки (stake), который отслеживает, какие пропорционеры/провайдеры делают стейкинг, фиксирует вознаграждения и обеспечивает действия stake, unstake и вывод reward; и контракт передачи (transfer), который обрабатывает как Moonlight (публичные) так и Phoenix (скрытые) переводы, оплачивает газ и служит точкой входа для выполнения транзакций непосредственно на DuskDS.
Эта базовая роль распространяется дальше, чем один только DuskDS, хотя точный механизм различается по слоям. DuskEVM, согласно собственным документам Dusk, переводит DUSK для оплаты газа через свой мост на Dusk L1, а затем в конечном итоге производит расчет обратно на DuskDS — маршрут, связанный, но отличный от прямой роли контракта transfer в нативных транзакциях DuskDS. Обе дороги ведут к одному и тому же базовому слою; они не являются идентичными механизмами. #dusk
Самокритика: аналогия с конституцией имеет реальный предел, который стоит назвать. Конституцию страны можно формально изменить через определенную процедуру. Чего я не нашел в документации, так это того, следует ли genesis-контрактам Dusk эквивалентный, четко определенный путь изменений, или же под “genesis” здесь функционально подразумевается постоянство по замыслу — настоящий вопрос управления, учитывая, насколько обширный растущий multilayer-стек Dusk сейчас зависит от того, что эти два контракта остаются корректными. $DUSK
DUSK следует оценивать с точки зрения того, проясняется ли эта неоднозначность еще до того, как этим контрактам когда-либо придется обновляться под реальным давлением, а не после.
#dusk $DUSK @Dusk
Permanent by design
Should have amendment path
14 ч. осталось
PINNED
@TermMax Я предполагал, что использование прибыльного варианта на TermMax Alpha сработает одинаково — выплата поступает на ваш кошелёк, и на этом всё, как на любой платформе опционов, которой я пользовался раньше. $BEAT
Однако это предположение рухнуло, когда я прочитал, что TermMax предоставляет два разных сценария исполнения. Exercise-Net-Settle закрывает позицию и выплачивает чистую прибыль напрямую. Exercise-Delivery же исполняется через перевод базового актива — не наличными: в итоге вы действительно получаете токен, на основе которого была ваша Long- или Short-позиция. #TermMax
Это по-новому определяет, что здесь означает «выиграть» сделку с опционами. На большинстве платформ исполнение просто означает получение определённой суммы. На TermMax исполнение может означать уход с самим активом — и это важно, особенно для ранних листингов Binance Alpha, где реальное получение экспозиции к токену — а не только к движению его цены — может быть главной целью сделки. $TUT
Чего не проясняют документы, так это: доступен ли трейдеру выбор между двумя вариантами всегда, или же он зависит от конкретной конфигурации рынка на момент расчёта. $ENA
Главная проверка для TMX — понимают ли трейдеры, что такой выбор существует, до того как они исполняют опцион, или же по умолчанию выбирают тот вариант, который в интерфейсе показан первым.
Кто-нибудь реально использовал Exercise-Delivery вместо Net-Settle и почему?
#termmax @TermMax
Однако это предположение рухнуло, когда я прочитал, что TermMax предоставляет два разных сценария исполнения. Exercise-Net-Settle закрывает позицию и выплачивает чистую прибыль напрямую. Exercise-Delivery же исполняется через перевод базового актива — не наличными: в итоге вы действительно получаете токен, на основе которого была ваша Long- или Short-позиция. #TermMax
Это по-новому определяет, что здесь означает «выиграть» сделку с опционами. На большинстве платформ исполнение просто означает получение определённой суммы. На TermMax исполнение может означать уход с самим активом — и это важно, особенно для ранних листингов Binance Alpha, где реальное получение экспозиции к токену — а не только к движению его цены — может быть главной целью сделки. $TUT
Чего не проясняют документы, так это: доступен ли трейдеру выбор между двумя вариантами всегда, или же он зависит от конкретной конфигурации рынка на момент расчёта. $ENA
Главная проверка для TMX — понимают ли трейдеры, что такой выбор существует, до того как они исполняют опцион, или же по умолчанию выбирают тот вариант, который в интерфейсе показан первым.
Кто-нибудь реально использовал Exercise-Delivery вместо Net-Settle и почему?
#termmax @TermMax
Проверено
@Dusk Я вернулся к собственному анонсу Dusk об архитектуре от июня 2025 года, и с тех пор рамки изменились по сравнению с более ранним позиционированием Dusk.
Три слоя согласно текущей документации Dusk: DuskDS в основании — консенсус, расчёт, доступность данных, нативные модели транзакций. Сверху DuskEVM — на базе OP Stack, полная совместимость с Solidity. Вместе с ним DuskVM — контракты на Rust/WASM, выполняющиеся непосредственно на L1 для сценариев с приватностью «по умолчанию». #dusk
Что изменилось по сравнению с исходным анонсом эволюции 2025 года и тем, что есть сейчас: на тот момент DuskVM описывался как «предстоящий». Сейчас в документации он описан как работающая инфраструктура, а не как пункт в дорожной карте. Отдельно — собственные обновления Dusk за 2026 год описывают регулируемое securities dApp NPEX как активно разворачиваемое на DuskEVM именно — я хочу точно подчеркнуть, что это описывается как продолжающийся rollout, а не как то, что я могу подтвердить как уже завершённый, полностью функционирующий запуск. $DUSK
Один момент связывает все три слоя воедино конкретно, независимо от статуса этого развёртывания: один токен DUSK питает каждый слой, а нативный бридж, управляемый валидаторами, передаёт ценность между ними без обёрнутых активов или кастодианов.
Это всё ещё развивающаяся система, а не завершённая. Документация DuskEVM подтверждает, что сейчас он работает только как sequencer и пока не имеет публичного mempool — конкретное, датированное ограничение, находящееся «под» тем, что прямо сейчас активно разворачивается поверх.
Если кто-то отслеживал, как rollout NPEX на практике продвигается относительно этой архитектуры, я бы хотел сравнить заметки с тем, что я нашёл здесь.
#dusk $DUSK @Dusk
Три слоя согласно текущей документации Dusk: DuskDS в основании — консенсус, расчёт, доступность данных, нативные модели транзакций. Сверху DuskEVM — на базе OP Stack, полная совместимость с Solidity. Вместе с ним DuskVM — контракты на Rust/WASM, выполняющиеся непосредственно на L1 для сценариев с приватностью «по умолчанию». #dusk
Что изменилось по сравнению с исходным анонсом эволюции 2025 года и тем, что есть сейчас: на тот момент DuskVM описывался как «предстоящий». Сейчас в документации он описан как работающая инфраструктура, а не как пункт в дорожной карте. Отдельно — собственные обновления Dusk за 2026 год описывают регулируемое securities dApp NPEX как активно разворачиваемое на DuskEVM именно — я хочу точно подчеркнуть, что это описывается как продолжающийся rollout, а не как то, что я могу подтвердить как уже завершённый, полностью функционирующий запуск. $DUSK
Один момент связывает все три слоя воедино конкретно, независимо от статуса этого развёртывания: один токен DUSK питает каждый слой, а нативный бридж, управляемый валидаторами, передаёт ценность между ними без обёрнутых активов или кастодианов.
Это всё ещё развивающаяся система, а не завершённая. Документация DuskEVM подтверждает, что сейчас он работает только как sequencer и пока не имеет публичного mempool — конкретное, датированное ограничение, находящееся «под» тем, что прямо сейчас активно разворачивается поверх.
Если кто-то отслеживал, как rollout NPEX на практике продвигается относительно этой архитектуры, я бы хотел сравнить заметки с тем, что я нашёл здесь.
#dusk $DUSK @Dusk
Проверено
@TermMax Я некоторое время разобрался с механикой опционов TermMax Alpha, ожидая привычный профиль риска для открытых (open-ended) опций.
Но оказалось не так. Long означает покупку call, Short — покупку put, оба варианта осуществляются в отношении контрагента, который в документации назван Dual Investment — продавцом опциона. Max Cost определяется строго как премия, уплаченная в первую очередь в USDT. Расчёт проходит через Exercise-Net-Settle или Exercise-Delivery, и в любом случае максимальный возможный убыток был зафиксирован с момента открытия позиции.
Ни один из этих терминов сам по себе не выглядел особенно значимым. Но контекст запуска заставил меня задуматься. TermMax Alpha вышел в прод на mainnet BNB Chain 12 ноября 2025 года, разработан Term Structure Labs, поддержан Cumberland DRW — реальной институциональной торговой компанией, а не просто «маркетинговым» токеном из листинга.
Эта поддержка важна, потому что именно продукт реально решает. Когда Binance Alpha размещает новый токен, трейдеры часто ждут недели, прежде чем фьючерсы perpetual появятся где-либо. TermMax Alpha существует как раз для того, чтобы заполнить этот разрыв — обеспечивать с плечом экспозицию с ограниченной и заранее известной стоимостью, доступной с первого дня листинга, а не через несколько недель. #TermMax
То, что привлекло моё внимание, в том, что это делает TermMax Alpha действительно инфраструктурой, зависящей от времени — её актуальность связана со скоростью, с которой продолжают появляться новые листинги Binance Alpha, а не с неким статичным функционалом, который «стоит на месте».
Я пока не подтвердил, сколько сейчас активных рынков Alpha в работе, и насколько узкими бывают спреды на самых новых листингах.
Long или Short?
#termmax @TermMax
Но оказалось не так. Long означает покупку call, Short — покупку put, оба варианта осуществляются в отношении контрагента, который в документации назван Dual Investment — продавцом опциона. Max Cost определяется строго как премия, уплаченная в первую очередь в USDT. Расчёт проходит через Exercise-Net-Settle или Exercise-Delivery, и в любом случае максимальный возможный убыток был зафиксирован с момента открытия позиции.
Ни один из этих терминов сам по себе не выглядел особенно значимым. Но контекст запуска заставил меня задуматься. TermMax Alpha вышел в прод на mainnet BNB Chain 12 ноября 2025 года, разработан Term Structure Labs, поддержан Cumberland DRW — реальной институциональной торговой компанией, а не просто «маркетинговым» токеном из листинга.
Эта поддержка важна, потому что именно продукт реально решает. Когда Binance Alpha размещает новый токен, трейдеры часто ждут недели, прежде чем фьючерсы perpetual появятся где-либо. TermMax Alpha существует как раз для того, чтобы заполнить этот разрыв — обеспечивать с плечом экспозицию с ограниченной и заранее известной стоимостью, доступной с первого дня листинга, а не через несколько недель. #TermMax
То, что привлекло моё внимание, в том, что это делает TermMax Alpha действительно инфраструктурой, зависящей от времени — её актуальность связана со скоростью, с которой продолжают появляться новые листинги Binance Alpha, а не с неким статичным функционалом, который «стоит на месте».
Я пока не подтвердил, сколько сейчас активных рынков Alpha в работе, и насколько узкими бывают спреды на самых новых листингах.
Long или Short?
#termmax @TermMax
Long (call)
75%
Short (put)
0%
Neither, too risky
25%
4 проголосовали • Голосование закрыто
·
--
🎙️ А теперь кто есть кто и что есть что. Чего на самом деле хочет Binance 😂😂
Завершено
01 ч 56 мин 10 сек
431
0
Хэш-функция, удобная для SNARK, разработанная собственной командой Dusk специально для коллизионно-стойкого хэширования внутри схем с нулевым разглашением.
Mohsin_Trader_King
·
--
Я сидел с одним вопросом: в документации Dusk нет прямого ответа с точными числами. Могут ли два разных заметки Phoenix когда-либо породить один и тот же nullifier.
Что я могу подтвердить точно: в собственном репозитории Phoenix от Dusk сказано, что nullifier вычисляется именно так, чтобы внешний наблюдатель не мог связать его с тем, из какой заметки он получен. Каждая заметка хешируется и попадает в листья дерева Merkle заметок, а расходование одной из них порождает детерминированное значение nullifier, привязанное к данным именно этой заметки.
Хеширование “под капотом” — и в структуре дерева Merkle от Dusk, и в более широких криптографических операциях — выполняется с помощью Poseidon: SNARK-дружественной хэш-функции, разработанной собственной командой Dusk специально для устойчивого к коллизиям хеширования внутри схем занулевания с доказательствами (zero-knowledge). Это не универсальная хэш-функция, взятая “с полки”; она создана под точно такие задачи для ZK-ориентированных коммитментов.
Но устойчивость к коллизиям — это не то же самое, что абсолютная защищённость от коллизий. Любая хэш-функция, включая Poseidon, теоретически допускает (в астрономически малой степени), что два разных входа дадут одинаковый выход — такова природа хеширования, а не какая-то специфическая слабость Dusk.
Чего я не нашёл в собственных материалах Dusk, так это опубликованной оценки вероятности коллизий, относящейся именно к их конкретным параметрам Poseidon, или документации о специализированном тестировании коллизий сверх общих свойств безопасности, которые Poseidon наследует по замыслу.
Если у кого-то есть отчёт аудита, охватывающий именно это свойство для реализации Dusk, я бы хотел сравнить его с тем, что публично задокументировано.
#dusk $DUSK @Dusk
Что я могу подтвердить точно: в собственном репозитории Phoenix от Dusk сказано, что nullifier вычисляется именно так, чтобы внешний наблюдатель не мог связать его с тем, из какой заметки он получен. Каждая заметка хешируется и попадает в листья дерева Merkle заметок, а расходование одной из них порождает детерминированное значение nullifier, привязанное к данным именно этой заметки.
Хеширование “под капотом” — и в структуре дерева Merkle от Dusk, и в более широких криптографических операциях — выполняется с помощью Poseidon: SNARK-дружественной хэш-функции, разработанной собственной командой Dusk специально для устойчивого к коллизиям хеширования внутри схем занулевания с доказательствами (zero-knowledge). Это не универсальная хэш-функция, взятая “с полки”; она создана под точно такие задачи для ZK-ориентированных коммитментов.
Но устойчивость к коллизиям — это не то же самое, что абсолютная защищённость от коллизий. Любая хэш-функция, включая Poseidon, теоретически допускает (в астрономически малой степени), что два разных входа дадут одинаковый выход — такова природа хеширования, а не какая-то специфическая слабость Dusk.
Чего я не нашёл в собственных материалах Dusk, так это опубликованной оценки вероятности коллизий, относящейся именно к их конкретным параметрам Poseidon, или документации о специализированном тестировании коллизий сверх общих свойств безопасности, которые Poseidon наследует по замыслу.
Если у кого-то есть отчёт аудита, охватывающий именно это свойство для реализации Dusk, я бы хотел сравнить его с тем, что публично задокументировано.
#dusk $DUSK @Dusk
5% goes to the liquidator as their reward for executing the liquidation
Mohsin_Trader_King
·
--
Вернулся к ликвидационной документации TermMax именно чтобы отследить, куда фактически уходит штрафная сумма.
Цифра простая: 10% от значения ликвидированного долга — берётся из собственного залога заёмщика каждый раз, когда срабатывает ликвидация. Менее очевидно другое: как именно эта сумма распределяется — это не единый платёж одному участнику. 5% получает ликвидатор как вознаграждение за выполнение ликвидации. Остальные 5% направляются напрямую в собственный резерв протокола.
Для меня изменение в том, что это не просто штрафная комиссия: документы описывают двухкомпонентную систему стимулов — явно ориентированную на стабильность протокола. Её цель — поддерживать требуемый LTV по займам и при этом давать ликвидаторам реальный повод действовать быстро. Формула также подтверждает порядок приоритетов: сначала из ликвидируемого залога покрывается вознаграждение ликвидатора, затем остаток применяется к штрафу протокола — и всё это явно ограничено фактической позицией заёмщика. То есть штраф математически не может превысить то, что этот заёмщик может покрыть своим собственным залогом, независимо от того, как работает формула.
Стоит отметить: в документации чётко указаны и распределение, и лимит, но не сказано, на что расходуется резерв после накопления, или при каких условиях его могут использовать.
Следующее, что я бы проверил: насколько сильно этот резерв фактически вырос по сравнению с общим объёмом ликвидаций на данный момент.
#termmax @TermMax $BTW
$RICE
$GPS
Цифра простая: 10% от значения ликвидированного долга — берётся из собственного залога заёмщика каждый раз, когда срабатывает ликвидация. Менее очевидно другое: как именно эта сумма распределяется — это не единый платёж одному участнику. 5% получает ликвидатор как вознаграждение за выполнение ликвидации. Остальные 5% направляются напрямую в собственный резерв протокола.
Для меня изменение в том, что это не просто штрафная комиссия: документы описывают двухкомпонентную систему стимулов — явно ориентированную на стабильность протокола. Её цель — поддерживать требуемый LTV по займам и при этом давать ликвидаторам реальный повод действовать быстро. Формула также подтверждает порядок приоритетов: сначала из ликвидируемого залога покрывается вознаграждение ликвидатора, затем остаток применяется к штрафу протокола — и всё это явно ограничено фактической позицией заёмщика. То есть штраф математически не может превысить то, что этот заёмщик может покрыть своим собственным залогом, независимо от того, как работает формула.
Стоит отметить: в документации чётко указаны и распределение, и лимит, но не сказано, на что расходуется резерв после накопления, или при каких условиях его могут использовать.
Следующее, что я бы проверил: насколько сильно этот резерв фактически вырос по сравнению с общим объёмом ликвидаций на данный момент.
#termmax @TermMax $BTW
$RICE
$GPS
Проверено
@Dusk Я пошёл выяснять, что именно происходит, когда проверка доказательства с нулевым разглашением Phoenix не проходит, — ведь большинство объяснений заканчиваются на фразе «доказательство проверяется».
Архитектура Dusk подтверждает: доказательство должно одновременно демонстрировать определённые свойства — владение нотой, которая тратится, целостность баланса между входами и выходами и отсутствие двойной траты — и всё это закодировано в одном и том же доказательстве, а не проверяется отдельными «побочными» проверками. $DUSK
Вот с этим и стоит разобраться. Если не выполняется хотя бы одно из этих свойств, всё доказательство целиком считается провалившимся как единое целое. Нельзя получить «частичные» баллы, когда проверки баланса проходят, но владение почему-то не выполняется — беззвучно.
Я проследил, что это значит на практике: отклонённое доказательство означает, что транзакция вообще не включается. Среда выполнения не пытается «спасти» транзакцию или частично обработать её. Транзакция просто не происходит, и ничего из попытки, которая не сработала, не фиксируется как изменение состояния. #dusk
То, что я не подтвердил по материалам Dusk, — остаётся ли след от проваленного доказательства в логах mempool, который оператор узла сможет потом просмотреть, или же оно отбрасывается вообще без какой-либо диагностической записи.
Следующее, что я бы проверил: всплывает ли в текущих инструментах кошелька Dusk конкретная причина неудачи при проверке доказательства, или показывается только общее «отклонено», — потому что это очень важно для тех, кто реально отлаживает транзакцию, которая так и не прошла.
#dusk $DUSK @Dusk
Архитектура Dusk подтверждает: доказательство должно одновременно демонстрировать определённые свойства — владение нотой, которая тратится, целостность баланса между входами и выходами и отсутствие двойной траты — и всё это закодировано в одном и том же доказательстве, а не проверяется отдельными «побочными» проверками. $DUSK
Вот с этим и стоит разобраться. Если не выполняется хотя бы одно из этих свойств, всё доказательство целиком считается провалившимся как единое целое. Нельзя получить «частичные» баллы, когда проверки баланса проходят, но владение почему-то не выполняется — беззвучно.
Я проследил, что это значит на практике: отклонённое доказательство означает, что транзакция вообще не включается. Среда выполнения не пытается «спасти» транзакцию или частично обработать её. Транзакция просто не происходит, и ничего из попытки, которая не сработала, не фиксируется как изменение состояния. #dusk
То, что я не подтвердил по материалам Dusk, — остаётся ли след от проваленного доказательства в логах mempool, который оператор узла сможет потом просмотреть, или же оно отбрасывается вообще без какой-либо диагностической записи.
Следующее, что я бы проверил: всплывает ли в текущих инструментах кошелька Dusk конкретная причина неудачи при проверке доказательства, или показывается только общее «отклонено», — потому что это очень важно для тех, кто реально отлаживает транзакцию, которая так и не прошла.
#dusk $DUSK @Dusk
@TermMax Потратил некоторое время, разбирая трехтокеновую систему TermMax, и одна строка в документации полностью прояснила для меня картину: «Collateral Value (Стоимость обеспечения) равна GT Value (Стоимость GT) плюс Value of the Loan itself (стоимость самого кредита)», где GT Value определяется как Collateral minus Value of Debt (Стоимость обеспечения минус стоимость долга). Эти токены — не просто три отдельных объекта: это части одной уравнения, которое должно сходиться.
FT — это ERC-20, работающий как бескупонная облигация: 110 FT-USDC погашаются на 110 USDC по наступлении срока, так что покупка за 100 USDC фиксирует 10% дохода за один год. Но в документации указано, что эта цифра масштабируется со сроком до погашения, а не остается постоянной: FT на 180 дней при той же скидке годовых составляет примерно 20%, а не 10%. XT определен даже точнее, чем я ожидал: это не просто «вторая половина», это именно текущая стоимость процентов, которые заемщик обязан выплатить, отделенная от основной суммы. GT — это оболочка позиции: ERC-721, который отслеживает обеспечение и долг как единое целое, ограниченное MLTV.
То, что привлекло мое внимание, — что XT не является заполнителем: это самостоятельный финансовый инструмент, отражающий на собственном уровне риск процентной ставки и оцениваемый отдельно от риска основной суммы у FT. Разделение основной суммы и процентов на уровне токенов — это то, что позволяет удерживать нулевую сумму всей системы: нигде в цепочке никакая стоимость не появляется и не исчезает. #TermMax
Недостающий для меня элемент — реальная глубина вторичного рынка именно для XT, потому что он оценивает нечто настолько узкое, как краткосрочный риск процентной ставки.
"Какой токен для вас важнее всего?"
#termmax
@TermMax
FT — это ERC-20, работающий как бескупонная облигация: 110 FT-USDC погашаются на 110 USDC по наступлении срока, так что покупка за 100 USDC фиксирует 10% дохода за один год. Но в документации указано, что эта цифра масштабируется со сроком до погашения, а не остается постоянной: FT на 180 дней при той же скидке годовых составляет примерно 20%, а не 10%. XT определен даже точнее, чем я ожидал: это не просто «вторая половина», это именно текущая стоимость процентов, которые заемщик обязан выплатить, отделенная от основной суммы. GT — это оболочка позиции: ERC-721, который отслеживает обеспечение и долг как единое целое, ограниченное MLTV.
То, что привлекло мое внимание, — что XT не является заполнителем: это самостоятельный финансовый инструмент, отражающий на собственном уровне риск процентной ставки и оцениваемый отдельно от риска основной суммы у FT. Разделение основной суммы и процентов на уровне токенов — это то, что позволяет удерживать нулевую сумму всей системы: нигде в цепочке никакая стоимость не появляется и не исчезает. #TermMax
Недостающий для меня элемент — реальная глубина вторичного рынка именно для XT, потому что он оценивает нечто настолько узкое, как краткосрочный риск процентной ставки.
"Какой токен для вас важнее всего?"
#termmax
@TermMax
FT (fixed yield)
67%
XT (interest pricing)
33%
GT (leverage wrapper)
0%
All three together
0%
6 проголосовали • Голосование закрыто
@TermMax Я считал, что ликвидация на TermMax означает то же самое, что и везде, где я с ней сталкивался — пересекаешь линию опасности, теряешь всю позицию за один заход, без промежуточных вариантов.
Этот взгляд развалился, когда я прочитал реальную формулу. Ликвидация срабатывает одним из двух способов: LTV достигает или превышает порог LLTV на рынке, либо заемщик пропускает фиксированный платеж при наступлении срока, что открывает двухчасовое окно ликвидации независимо от цены. $ACE
Вот число, которое заставило иначе взглянуть на ситуацию. Если непогашенный долг превышает $10,000, ликвидаторам ограничивают размер вознаграждения до 50% от общей стоимости долга за событие. Максимально ликвидируемое обеспечение рассчитывается как общее обеспечение, умноженное на ликвидированный долг, и разделенное на общий долг — коэффициент, устроенный так, что LTV улучшается после каждой ликвидации, а не обваливается до нуля. Полная ликвидация происходит только если долг падает ровно до нуля, после чего оставшееся обеспечение автоматически возвращается заемщику.
Штраф составляет 10% от стоимости ликвидированного долга, и он делится строго пополам — 5% ликвидатору в виде вознаграждения и 5% в резервный хранилище протокола.
Чего в документации не сказано — какая доля реальных позиций на практике пересекает рубеж $10,000 по долгу, а какая остается ниже этой границы, где ограничение вообще не применяется. $CLO
Настоящая проверка для TMX в том, защищает ли этот 50% лимит крупных заемщиков по-настоящему, или же просто превращает одну ликвидацию в две меньшие, следующие друг за другом. $CYS
Кто-нибудь уже отслеживал, как на TermMax считаются частичные против полных ликвидаций — пока что?
#termmax @TermMax
Этот взгляд развалился, когда я прочитал реальную формулу. Ликвидация срабатывает одним из двух способов: LTV достигает или превышает порог LLTV на рынке, либо заемщик пропускает фиксированный платеж при наступлении срока, что открывает двухчасовое окно ликвидации независимо от цены. $ACE
Вот число, которое заставило иначе взглянуть на ситуацию. Если непогашенный долг превышает $10,000, ликвидаторам ограничивают размер вознаграждения до 50% от общей стоимости долга за событие. Максимально ликвидируемое обеспечение рассчитывается как общее обеспечение, умноженное на ликвидированный долг, и разделенное на общий долг — коэффициент, устроенный так, что LTV улучшается после каждой ликвидации, а не обваливается до нуля. Полная ликвидация происходит только если долг падает ровно до нуля, после чего оставшееся обеспечение автоматически возвращается заемщику.
Штраф составляет 10% от стоимости ликвидированного долга, и он делится строго пополам — 5% ликвидатору в виде вознаграждения и 5% в резервный хранилище протокола.
Чего в документации не сказано — какая доля реальных позиций на практике пересекает рубеж $10,000 по долгу, а какая остается ниже этой границы, где ограничение вообще не применяется. $CLO
Настоящая проверка для TMX в том, защищает ли этот 50% лимит крупных заемщиков по-настоящему, или же просто превращает одну ликвидацию в две меньшие, следующие друг за другом. $CYS
Кто-нибудь уже отслеживал, как на TermMax считаются частичные против полных ликвидаций — пока что?
#termmax @TermMax
Проверено
@Dusk Я проверил, как Dusk позиционирует себя по отношению к Ethereum именно, поскольку в большинстве сравнений приватных сетей обычно по умолчанию берут Zcash или Monero.
Текущая главная страница Dusk формулирует цель прямо: инфраструктура для регулируемых цифровых активов, конфиденциальная по умолчанию, с доказательствами с нулевым разглашением и контролируемой видимостью для аудита и регулируемого раскрытия. Это заметно более острое позиционирование, чем то, которое Dusk занимал ранее публично: тогда акцент делался больше на сочетании публичных транзакций Moonlight и модели конфиденциальности Phoenix для регулируемых финансов в целом, без такого сильного упора на прямое противопоставление контрасту прозрачности Ethereum.
Вопрос в том, что именно изменилось между этими формулировками — стоит обдумать. Ethereum по умолчанию — все балансы, каждый вызов видны любому — отлично подходит для публичной координации. DuskEVM от Dusk запускает полную эквивалентность EVM, используя те же инструменты, которые разработчики Ethereum уже знают, при этом сохраняя спрятанную «защищенность по умолчанию» у себя под капотом. Модель исполнения не отвергается. По умолчанию — вот что важно: $DUSK
На собственном сайте Dusk теперь перечислены конкретные партнеры, подпадающие под регулирование в ЕС, которые активно строят на этом позиционировании: лицензированный провайдер инфраструктуры рынка в рамках DLT Pilot Regime, а также европейская регулируемая площадка, изучающая выпуск ончейн непосредственно в этой рамке.
Это реальное институциональное движение, а не просто сообщения — но то, приводит ли это к значимой миграции разработчиков от стека, ориентированного на Ethereum, именно из‑за проблемы прозрачности, — вопрос, для которого мне пока не удалось найти цифры по внедрению, чтобы подтвердить или опровергнуть. #dusk
Если кто-то отслеживал реальные данные о миграции, привязанные именно к аргументу прозрачности, а не к более широкой риторике Dusk о соответствию требованиям, я бы хотел сравнить это с тем, что публично указано в партнерском списке Dusk.
#dusk $DUSK @Dusk
Текущая главная страница Dusk формулирует цель прямо: инфраструктура для регулируемых цифровых активов, конфиденциальная по умолчанию, с доказательствами с нулевым разглашением и контролируемой видимостью для аудита и регулируемого раскрытия. Это заметно более острое позиционирование, чем то, которое Dusk занимал ранее публично: тогда акцент делался больше на сочетании публичных транзакций Moonlight и модели конфиденциальности Phoenix для регулируемых финансов в целом, без такого сильного упора на прямое противопоставление контрасту прозрачности Ethereum.
Вопрос в том, что именно изменилось между этими формулировками — стоит обдумать. Ethereum по умолчанию — все балансы, каждый вызов видны любому — отлично подходит для публичной координации. DuskEVM от Dusk запускает полную эквивалентность EVM, используя те же инструменты, которые разработчики Ethereum уже знают, при этом сохраняя спрятанную «защищенность по умолчанию» у себя под капотом. Модель исполнения не отвергается. По умолчанию — вот что важно: $DUSK
На собственном сайте Dusk теперь перечислены конкретные партнеры, подпадающие под регулирование в ЕС, которые активно строят на этом позиционировании: лицензированный провайдер инфраструктуры рынка в рамках DLT Pilot Regime, а также европейская регулируемая площадка, изучающая выпуск ончейн непосредственно в этой рамке.
Это реальное институциональное движение, а не просто сообщения — но то, приводит ли это к значимой миграции разработчиков от стека, ориентированного на Ethereum, именно из‑за проблемы прозрачности, — вопрос, для которого мне пока не удалось найти цифры по внедрению, чтобы подтвердить или опровергнуть. #dusk
Если кто-то отслеживал реальные данные о миграции, привязанные именно к аргументу прозрачности, а не к более широкой риторике Dusk о соответствию требованиям, я бы хотел сравнить это с тем, что публично указано в партнерском списке Dusk.
#dusk $DUSK @Dusk
@Dusk раньше приходилось полагаться на верификатор на Dusk: ему нужно было видеть детали транзакции, чтобы подтвердить, что она легитимна.
С Phoenix всё иначе.
Я проследил, что именно получает верификатор, вместо того чтобы смотреть на исходные данные. Материалы по архитектуре Dusk подтверждают: Phoenix использует доказательства с нулевым разглашением (zero-knowledge proofs) — чтобы доказать владение неиспользованными выходами и предотвратить двойные траты. Верификатор проверяет доказательство, а не саму транзакцию.
Хм.
А что именно внутри этого доказательства — механически?
Посидел с этим какое-то время. Совершающий трату доказывает знание пути до корня Merkle-дерева и знание открытия (opening) коммита. То есть доказательство математически демонстрирует, что нота (note) существует в дереве, и что совершающий трату действительно знает, что в ней содержится, не раскрывая ни содержимое ноты, ни её местоположение тем, кто наблюдает.
Сама трата требует Secret Key, известного исключительно владельцу ноты — поэтому даже шаг генерации доказательства не может произойти без единственного фрагмента информации, которого нет ни у кого другого.
Это гарантия, более «чужая», чем сначала может показаться. Верификатор не доверяет словам отправителя. Он не доверяет и третьей стороне. Он подтверждает математическое утверждение — что верно сочетание: членство в дереве плюс знание коммита — и при этом ни разу не восстанавливает то, что сделало это утверждение истинным.
Не говорю, что это проверка слабее. Если что, отказ смотреть может быть самой сутью: верификатор не может быть обманут данными, которые он вообще не получает.
Система, построенная для проверки членства в дереве и знания секретного ключа, не видя суммы, заслуживает большего доверия, чем та, которая проверяет, просто взглянув непосредственно на данные?
@Dusk #dusk $DUSK
С Phoenix всё иначе.
Я проследил, что именно получает верификатор, вместо того чтобы смотреть на исходные данные. Материалы по архитектуре Dusk подтверждают: Phoenix использует доказательства с нулевым разглашением (zero-knowledge proofs) — чтобы доказать владение неиспользованными выходами и предотвратить двойные траты. Верификатор проверяет доказательство, а не саму транзакцию.
Хм.
А что именно внутри этого доказательства — механически?
Посидел с этим какое-то время. Совершающий трату доказывает знание пути до корня Merkle-дерева и знание открытия (opening) коммита. То есть доказательство математически демонстрирует, что нота (note) существует в дереве, и что совершающий трату действительно знает, что в ней содержится, не раскрывая ни содержимое ноты, ни её местоположение тем, кто наблюдает.
Сама трата требует Secret Key, известного исключительно владельцу ноты — поэтому даже шаг генерации доказательства не может произойти без единственного фрагмента информации, которого нет ни у кого другого.
Это гарантия, более «чужая», чем сначала может показаться. Верификатор не доверяет словам отправителя. Он не доверяет и третьей стороне. Он подтверждает математическое утверждение — что верно сочетание: членство в дереве плюс знание коммита — и при этом ни разу не восстанавливает то, что сделало это утверждение истинным.
Не говорю, что это проверка слабее. Если что, отказ смотреть может быть самой сутью: верификатор не может быть обманут данными, которые он вообще не получает.
Система, построенная для проверки членства в дереве и знания секретного ключа, не видя суммы, заслуживает большего доверия, чем та, которая проверяет, просто взглянув непосредственно на данные?
@Dusk #dusk $DUSK
@TermMax раньше я думал, что кредит просто появляется в виде числа в каком-то остатке на счёте.
чем больше я изучал, как TermMax фактически формирует позицию, тем меньше это объяснение сходилось.
заёмщик блокирует залог. TermMax чеканит Gearing Token против него — это ERC-721, а не запись в бухгалтерском регистре. долговой токен, токен залога и дата погашения закрепляются на уровне рынка ещё до того, как этот GT вообще появляется.
сам GT фиксирует ровно две вещи. сколько залога в нём находится. сколько Fixed-Rate Tokens выпущено против этого залога — с ограничением по максимальному loan-to-value (LTV) на рынке. MLTV, например 0.8, превращает 1 ETH в до 800 $USDC переводимого в долг. #TermMax
нет общего пула, нет взаимозачёта, нет где-то «смешанного» числа в дизайне.
перечитайте этот фрагмент про изоляцию дважды. TermMax работает с 100+ рынками на момент обновления за март 2026 года — каждый из них изолирован от остальных. так, одна плохая цена залога на одном рынке никогда не затрагивает GT, которые лежат в других. не учётность. граница.
погашайте долг напрямую долговыми токенами или выкупайте FTs на открытом рынке и возвращайте их обратно. в любом случае GT закрывается, и залог высвобождается, но он никогда не «смешивался» с чьими-то числами изначально.
поэтому заимствование на TermMax — это не одно число, которое растёт или уменьшается. это столько GT, сколько вы открыли: каждый несёт свой собственный залог, свою собственную задолженность, свою собственную дату погашения — и всё это отдельно.
помесячное/покредитное отслеживание делает риск более понятным — или просто сложнее управлять в масштабе?
@TermMax #termmax
чем больше я изучал, как TermMax фактически формирует позицию, тем меньше это объяснение сходилось.
заёмщик блокирует залог. TermMax чеканит Gearing Token против него — это ERC-721, а не запись в бухгалтерском регистре. долговой токен, токен залога и дата погашения закрепляются на уровне рынка ещё до того, как этот GT вообще появляется.
сам GT фиксирует ровно две вещи. сколько залога в нём находится. сколько Fixed-Rate Tokens выпущено против этого залога — с ограничением по максимальному loan-to-value (LTV) на рынке. MLTV, например 0.8, превращает 1 ETH в до 800 $USDC переводимого в долг. #TermMax
нет общего пула, нет взаимозачёта, нет где-то «смешанного» числа в дизайне.
перечитайте этот фрагмент про изоляцию дважды. TermMax работает с 100+ рынками на момент обновления за март 2026 года — каждый из них изолирован от остальных. так, одна плохая цена залога на одном рынке никогда не затрагивает GT, которые лежат в других. не учётность. граница.
погашайте долг напрямую долговыми токенами или выкупайте FTs на открытом рынке и возвращайте их обратно. в любом случае GT закрывается, и залог высвобождается, но он никогда не «смешивался» с чьими-то числами изначально.
поэтому заимствование на TermMax — это не одно число, которое растёт или уменьшается. это столько GT, сколько вы открыли: каждый несёт свой собственный залог, свою собственную задолженность, свою собственную дату погашения — и всё это отдельно.
помесячное/покредитное отслеживание делает риск более понятным — или просто сложнее управлять в масштабе?
@TermMax #termmax
Проверено
@Dusk , раньше я думал, что «избирательное раскрытие» — это просто более мягкое слово для «прозрачности».
Провел какое-то время с реальным дизайном Citadel, и оказалось, что это не так.
Полная прозрачность — та, против которой Dusk явно и строит систему — означает, что каждый наблюдатель видит все атрибуты, привязанные к транзакции или личности, независимо от того, нужны они ему или нет. Citadel делает шаг уже — и я проследил реальные механизмы: не две стороны, а три.
Пользователь запрашивает лицензию в ончейне у провайдера лицензий. После выдачи эта лицензия позволяет Пользователю установить приватное, офлайн-соединение с провайдером услуг — который проверяет утверждение, используя только то, что хранится в ончейне, никогда не узнавая лежащую в основе личность Пользователя.
Хм.
Так что именно узнает провайдер услуг, когда проверка проходит?
Только то, что одно конкретное утверждение истинно — место проживания, возрастная категория, аккредитация, что угодно, что покрывает лицензия. Никаких лежащих в основе данных, никаких других атрибутов, которые есть у Пользователя, и никаких постоянных идентификаторов, связывающих эту проверку с будущей.
Это гораздо более узкое обещание, чем то, что подразумевает прозрачность. Полностью прозрачная система показывает всем всё навсегда — релевантно это или нет. Трехсторонняя структура Citadel сообщает одному провайдеру услуг одну истинную вещь, подтвержденную записью в ончейне, при этом этот провайдер никогда не получает доступ к полному профилю Пользователя.
Не говорю, что прозрачность плоха везде. Публичная координация действительно выигрывает от того, что все видят один и тот же реестр. Но действия, завязанные на идентичность — доказательство права на участие без того, чтобы отдавать полный профиль, — требуют протокола с тремя отдельными ролями, а не с двумя, чтобы это работало.
Является ли доказательство одной истинной вещи через три раздельные роли более сильной гарантией приватности, чем прозрачность в стиле «все видят всё, значит никому нечего скрывать»?
@Dusk #dusk $DUSK
Провел какое-то время с реальным дизайном Citadel, и оказалось, что это не так.
Полная прозрачность — та, против которой Dusk явно и строит систему — означает, что каждый наблюдатель видит все атрибуты, привязанные к транзакции или личности, независимо от того, нужны они ему или нет. Citadel делает шаг уже — и я проследил реальные механизмы: не две стороны, а три.
Пользователь запрашивает лицензию в ончейне у провайдера лицензий. После выдачи эта лицензия позволяет Пользователю установить приватное, офлайн-соединение с провайдером услуг — который проверяет утверждение, используя только то, что хранится в ончейне, никогда не узнавая лежащую в основе личность Пользователя.
Хм.
Так что именно узнает провайдер услуг, когда проверка проходит?
Только то, что одно конкретное утверждение истинно — место проживания, возрастная категория, аккредитация, что угодно, что покрывает лицензия. Никаких лежащих в основе данных, никаких других атрибутов, которые есть у Пользователя, и никаких постоянных идентификаторов, связывающих эту проверку с будущей.
Это гораздо более узкое обещание, чем то, что подразумевает прозрачность. Полностью прозрачная система показывает всем всё навсегда — релевантно это или нет. Трехсторонняя структура Citadel сообщает одному провайдеру услуг одну истинную вещь, подтвержденную записью в ончейне, при этом этот провайдер никогда не получает доступ к полному профилю Пользователя.
Не говорю, что прозрачность плоха везде. Публичная координация действительно выигрывает от того, что все видят один и тот же реестр. Но действия, завязанные на идентичность — доказательство права на участие без того, чтобы отдавать полный профиль, — требуют протокола с тремя отдельными ролями, а не с двумя, чтобы это работало.
Является ли доказательство одной истинной вещи через три раздельные роли более сильной гарантией приватности, чем прозрачность в стиле «все видят всё, значит никому нечего скрывать»?
@Dusk #dusk $DUSK
Stronger guarantee
100%
Transparency is simpler
0%
4 проголосовали • Голосование закрыто
Собственный репозиторий Dusk утверждает, что занулятор вычисляется специально так, чтобы внешний наблюдатель не мог связать его с какой-либо конкретной заметкой.
precious Zarmalaa
·
--
Что именно занулятор (nullifier) предотвращает от повторного возникновения
Я проверил, что именно занулятор препятствует на Dusk, так как фраза «предотвращает двойное расходование» произносится без достаточной точности.
Он не позволяет тратить один и тот же скрытый (shielded) нóт больше одного раза — и ничего более широкого.
Я проследил, как Dusk делает это, не раскрывая, какой именно нóт был потрачен. В собственном репозитории Dusk указано, что занулятор вычисляется специально так, чтобы внешний наблюдатель не мог связать его с каким-либо конкретным нóтом. Сеть не проверяет сам нóт по списку; она проверяет, появлялся ли уже именно этот занулятор.
Я подтвердил, что нóт не удаляется откуда бы то ни было после расходования. Он остается записанным в меркле-дереве нóтов Dusk. В отдельную, растущую запись добавляется только занулятор.
Эта разница важна. Если бы нóты удалялись при расходовании, я ожидал бы, что это начнет «протекать» тайминговой информацией только из-за наблюдения за тем, как структура уменьшается. Сохранение каждого нóта на месте, потраченного или нет, убирает именно этот сигнал.
Я также посмотрел, есть ли здесь риск коллизий — что два разных нóта случайно дадут один и тот же занулятор. В материалах Dusk, судя по документации, такого задокументированного случая не найдено, хотя гарантия опирается на те же базовые криптографические допущения, от которых зависит остальная система.
Так что занулятор в Dusk не является чем-то вроде «пометки» нóта как потраченного в каком-либо видимом смысле. Он доказывает, что расходование произошло, не идентифицируя, что именно было потрачено.
Защищает ли предотвращение двойных трат таким образом больше приватности, чем стоит цена в виде постоянного, неуклонно растущего хранилища?
@Dusk #dusk $DUSK #dusk
Я проверил, что именно занулятор препятствует на Dusk, так как фраза «предотвращает двойное расходование» произносится без достаточной точности.
Он не позволяет тратить один и тот же скрытый (shielded) нóт больше одного раза — и ничего более широкого.
Я проследил, как Dusk делает это, не раскрывая, какой именно нóт был потрачен. В собственном репозитории Dusk указано, что занулятор вычисляется специально так, чтобы внешний наблюдатель не мог связать его с каким-либо конкретным нóтом. Сеть не проверяет сам нóт по списку; она проверяет, появлялся ли уже именно этот занулятор.
Я подтвердил, что нóт не удаляется откуда бы то ни было после расходования. Он остается записанным в меркле-дереве нóтов Dusk. В отдельную, растущую запись добавляется только занулятор.
Эта разница важна. Если бы нóты удалялись при расходовании, я ожидал бы, что это начнет «протекать» тайминговой информацией только из-за наблюдения за тем, как структура уменьшается. Сохранение каждого нóта на месте, потраченного или нет, убирает именно этот сигнал.
Я также посмотрел, есть ли здесь риск коллизий — что два разных нóта случайно дадут один и тот же занулятор. В материалах Dusk, судя по документации, такого задокументированного случая не найдено, хотя гарантия опирается на те же базовые криптографические допущения, от которых зависит остальная система.
Так что занулятор в Dusk не является чем-то вроде «пометки» нóта как потраченного в каком-либо видимом смысле. Он доказывает, что расходование произошло, не идентифицируя, что именно было потрачено.
Защищает ли предотвращение двойных трат таким образом больше приватности, чем стоит цена в виде постоянного, неуклонно растущего хранилища?
@Dusk #dusk $DUSK #dusk
Проверено
@Dusk продолжая считать, что соответствие праву на Dusk было чем-то, что ты получил один раз и затем сохранял, как значок, который все время оставался закреплённым.
на самом деле это три отдельных механизма, которые работают вместе, и любой из них может лишить этого.
первое: минимальная ставка. я подтвердил, что провайдеру Dusk нужно иметь заблокированными 1000 DUSK, и ниже этого порога уже не имеет значения, что еще касается ставки.
второе: зрелость. даже ставка выше минимума должна пролежать фиксированное число эпох, прежде чем сортирование Dusk вообще начнёт учитывать её. $DUSK
третье — и это то, что я чуть не пропустил: пенализация. я выяснил, что повторяющиеся нарушения не просто отнимают вознаграждения — каждое последующее приостановление повышает долю ставки, переводя её в пул доступных к получению вознаграждений, начиная с 10% и увеличивая ещё на 10% при каждом следующем нарушении.
я проследил, что происходит, когда эта пенализация опускает ставку ниже порога 1000 DUSK. дело не только в том, что в сортировании она теряет «вес». я выяснил: её полностью замораживает — единственный способ вернуться в Dusk — разморозить оставшуюся часть и затем заново внести свежую ставку.
поэтому соответствие не является одной «дверью», которую провайдер проходит один раз. это три отдельных механизма — пол, часы и график пенализаций — любой из них может тихо лишить прав провайдера Dusk, который считал себя всё ещё активным. #dusk
делает ли наложение критериев пригодности через три независимых механизма Dusk более устойчивым к «игре», или же это просто делает легче честному провайдеру потерять статус, даже не сразу понимая почему?
#dusk $DUSK @Dusk
на самом деле это три отдельных механизма, которые работают вместе, и любой из них может лишить этого.
первое: минимальная ставка. я подтвердил, что провайдеру Dusk нужно иметь заблокированными 1000 DUSK, и ниже этого порога уже не имеет значения, что еще касается ставки.
второе: зрелость. даже ставка выше минимума должна пролежать фиксированное число эпох, прежде чем сортирование Dusk вообще начнёт учитывать её. $DUSK
третье — и это то, что я чуть не пропустил: пенализация. я выяснил, что повторяющиеся нарушения не просто отнимают вознаграждения — каждое последующее приостановление повышает долю ставки, переводя её в пул доступных к получению вознаграждений, начиная с 10% и увеличивая ещё на 10% при каждом следующем нарушении.
я проследил, что происходит, когда эта пенализация опускает ставку ниже порога 1000 DUSK. дело не только в том, что в сортировании она теряет «вес». я выяснил: её полностью замораживает — единственный способ вернуться в Dusk — разморозить оставшуюся часть и затем заново внести свежую ставку.
поэтому соответствие не является одной «дверью», которую провайдер проходит один раз. это три отдельных механизма — пол, часы и график пенализаций — любой из них может тихо лишить прав провайдера Dusk, который считал себя всё ещё активным. #dusk
делает ли наложение критериев пригодности через три независимых механизма Dusk более устойчивым к «игре», или же это просто делает легче честному провайдеру потерять статус, даже не сразу понимая почему?
#dusk $DUSK @Dusk
More resistant
100%
Easy to lose status
0%
3 проголосовали • Голосование закрыто
Сумерки выстраивают вокруг проблемы то, что прозрачные блокчейны не всегда могут эффективно решать.
precious Zarmalaa
·
--
Две модели транзакций DUSK — Moonlight и Phoenix
Сегодня вечером я проверял простой сценарий перевода в тестнете Dusk, переключаясь между публичным представлением кошелька и скрытым — для той же тестовой суммы. В публичной части всё появлялось сразу: отправитель, получатель, сумма. В скрытой части было почти ничего.
Я решил, что это просто два режима отображения одной и той же базовой транзакции. Поначалу это казалось логичным.
Я ошибался. Moonlight — это аккаунтная модель. Балансы видны открыто, и перевод по умолчанию раскрывает отправителя, получателя и сумму. Phoenix работает иначе. Средства хранятся в виде зашифрованных заметок. За этим стоит доказательство с нулевым разглашением, которое лишь подтверждает корректность транзакции; при этом ничего — о сумме, отправителе или о том, какие именно заметки были потрачены — не отображается.
Две разные модели транзакций, а не два представления одной модели — и именно в этом заключается смысл сравнения.
После того как я закрыл ноутбук и вернулся к задаче, меня снова и снова тянуло к мысли, что обе модели всё равно завершаются в одном и том же месте в Dusk. DuskDS обрабатывает обе. Контракт Transfer Contract принимает любой тип полезной нагрузки и направляет её через соответствующую логику проверки, сохраняя согласованность глобального состояния сети в любом случае.
Выбор между Moonlight и Phoenix — не про то, какую цепочку использовать. Это решение принимается на уровне конкретной транзакции, внутри одного слоя расчётов, о том, насколько остальная сеть будет что-либо видеть.
Я всё ещё не знаю, насколько часто билдерам (разработчикам приложений/сборщикам) по умолчанию приходится выбирать одну модель вместо другой, если рабочий процесс не требует приватности строго.
Если бы кошелёк позволял выбирать модель для каждой транзакции, какую бы вы выбирали по умолчанию?
@Dusk #dusk $DUSK #dusk
Сегодня вечером я проверял простой сценарий перевода в тестнете Dusk, переключаясь между публичным представлением кошелька и скрытым — для той же тестовой суммы. В публичной части всё появлялось сразу: отправитель, получатель, сумма. В скрытой части было почти ничего.
Я решил, что это просто два режима отображения одной и той же базовой транзакции. Поначалу это казалось логичным.
Я ошибался. Moonlight — это аккаунтная модель. Балансы видны открыто, и перевод по умолчанию раскрывает отправителя, получателя и сумму. Phoenix работает иначе. Средства хранятся в виде зашифрованных заметок. За этим стоит доказательство с нулевым разглашением, которое лишь подтверждает корректность транзакции; при этом ничего — о сумме, отправителе или о том, какие именно заметки были потрачены — не отображается.
Две разные модели транзакций, а не два представления одной модели — и именно в этом заключается смысл сравнения.
После того как я закрыл ноутбук и вернулся к задаче, меня снова и снова тянуло к мысли, что обе модели всё равно завершаются в одном и том же месте в Dusk. DuskDS обрабатывает обе. Контракт Transfer Contract принимает любой тип полезной нагрузки и направляет её через соответствующую логику проверки, сохраняя согласованность глобального состояния сети в любом случае.
Выбор между Moonlight и Phoenix — не про то, какую цепочку использовать. Это решение принимается на уровне конкретной транзакции, внутри одного слоя расчётов, о том, насколько остальная сеть будет что-либо видеть.
Я всё ещё не знаю, насколько часто билдерам (разработчикам приложений/сборщикам) по умолчанию приходится выбирать одну модель вместо другой, если рабочий процесс не требует приватности строго.
Если бы кошелёк позволял выбирать модель для каждой транзакции, какую бы вы выбирали по умолчанию?
@Dusk #dusk $DUSK #dusk
Проверено
#dusk $DUSK
DuskVM по сравнению с DuskEVM в сети DUSK
@Dusk Сначала я думал, что выбор между DuskVM и DuskEVM сводится к языку: Rust и WASM против Solidity и экосистемы инструментов для EVM, которой уже пользуются все. Сегодня я потратил на это больше времени, чем ожидал, и где-то в процессе это перестало выглядеть просто как выбор языка.
DuskVM стоит прямо у основания сети, поэтому она получает прямой доступ к тому, на чем Dusk действительно построен: приватность и механизмы zero-knowledge. DuskEVM запускает Solidity-контракты через стандартные инструменты EVM, но при этом все равно сводит и публикует свои данные обратно через тот же слой DuskDS, платя газ в токене DUSK в любом случае. Эта странная симметрия постоянно возвращается ко мне: разные пути выполнения, но одинаковое завершение и одинаковый токен под капотом у обоих.
Выбрать DuskVM — значит не просто выбрать язык, а выбрать близость к самим примитивам приватности. Выбрать DuskEVM — значит не только привычность, а удаленность от этих примитивов для инструментов, которые большинство разработчиков уже знает. Это тонкое трение, которое многие сравнения просто пропускают. #dusk
Есть и третья «прослойка» под обоими решениями, на которую я снова и снова возвращаюсь. Документация Dusk подтверждает: DuskEVM позволяет существующим EVM-кошелькам, мостам и биржам подключаться почти без изменений кода — быстрее, чем заняла бы нативная интеграция. Для DuskVM нет аналогичного короткого пути. Под него инструменты нужно каждый раз собирать с нуля. $DUSK
Равенство по функциям между двумя вариантами не гарантируется просто потому, что оба завершают работу через один и тот же слой и используют один и тот же газ-токен. То, что на поверхности выглядит как «опциональность», на деле является двумя разными ставками на то, где оплачивается реальная стоимость: заранее — в инструментах, или позже — в том, что окружение не может сделать.
Вообще Dusk дает билдерам выбор здесь, или просто заранее решает за них, где именно проявится трение? @Dusk
DuskVM по сравнению с DuskEVM в сети DUSK
@Dusk Сначала я думал, что выбор между DuskVM и DuskEVM сводится к языку: Rust и WASM против Solidity и экосистемы инструментов для EVM, которой уже пользуются все. Сегодня я потратил на это больше времени, чем ожидал, и где-то в процессе это перестало выглядеть просто как выбор языка.
DuskVM стоит прямо у основания сети, поэтому она получает прямой доступ к тому, на чем Dusk действительно построен: приватность и механизмы zero-knowledge. DuskEVM запускает Solidity-контракты через стандартные инструменты EVM, но при этом все равно сводит и публикует свои данные обратно через тот же слой DuskDS, платя газ в токене DUSK в любом случае. Эта странная симметрия постоянно возвращается ко мне: разные пути выполнения, но одинаковое завершение и одинаковый токен под капотом у обоих.
Выбрать DuskVM — значит не просто выбрать язык, а выбрать близость к самим примитивам приватности. Выбрать DuskEVM — значит не только привычность, а удаленность от этих примитивов для инструментов, которые большинство разработчиков уже знает. Это тонкое трение, которое многие сравнения просто пропускают. #dusk
Есть и третья «прослойка» под обоими решениями, на которую я снова и снова возвращаюсь. Документация Dusk подтверждает: DuskEVM позволяет существующим EVM-кошелькам, мостам и биржам подключаться почти без изменений кода — быстрее, чем заняла бы нативная интеграция. Для DuskVM нет аналогичного короткого пути. Под него инструменты нужно каждый раз собирать с нуля. $DUSK
Равенство по функциям между двумя вариантами не гарантируется просто потому, что оба завершают работу через один и тот же слой и используют один и тот же газ-токен. То, что на поверхности выглядит как «опциональность», на деле является двумя разными ставками на то, где оплачивается реальная стоимость: заранее — в инструментах, или позже — в том, что окружение не может сделать.
Вообще Dusk дает билдерам выбор здесь, или просто заранее решает за них, где именно проявится трение? @Dusk
#dusk $DUSK
@Dusk я раньше считал, что «цепочка приватности» означает: по умолчанию каждая транзакция защищена, без исключений.
затем я прочитал, что на самом деле делает Moonlight на Dusk.
Dusk использует две нативные модели транзакций на одном расчетном слое. Moonlight — аккаунтная, публичная: отправитель, получатель и сумма видны. Phoenix — нотная, защищенная: средства хранятся в виде зашифрованных нот вместо текущего баланса, ближе к тратимым единицам, чем к общей сумме по аккаунту. #dusk
вот то самое «по умолчанию», которое изменило то, как я прочитал это, и я вернулся перечитать этот раздел дважды, чтобы убедиться.
одна передача выбирает одну из двух моделей, никогда не смешивает их. отправь DUSK через Moonlight — и он полностью прозрачен, создан для сценариев потоков, которые должны оставаться наблюдаемыми; казначейский или отчетный сценарий — пример того, на что указывают документы. отправь через Phoenix — и сумма, отправитель и какие именно ноты переместились остаются скрытыми; это подтверждается с помощью доказательств с нулевым разглашением вместо открытого показа, но ключ просмотра может раскрыть эти скрытые данные тому, кому решит показать их стейкер. $DUSK
один Transfer Contract обрабатывает и то, и другое, направляя каждый пакет полезных данных в нужную логику верификации и сохраняя согласованность глобального состояния в любом случае.
значит, приватность здесь — не «бинарная» и на уровне протокола: это выбор для каждой передачи, и даже выбранная защищенная опция имеет задокументированный способ снова стать видимой по запросу.
этот выбор находится у отправителя, а не у протокола.
подрывает ли предоставление пользователям публичного варианта идею приватности, или же опциональная, отзывная приватность — это на самом деле более честный дизайн для регулируемых рынков?
опциональная приватность всё ещё является приватностью?
@Dusk я раньше считал, что «цепочка приватности» означает: по умолчанию каждая транзакция защищена, без исключений.
затем я прочитал, что на самом деле делает Moonlight на Dusk.
Dusk использует две нативные модели транзакций на одном расчетном слое. Moonlight — аккаунтная, публичная: отправитель, получатель и сумма видны. Phoenix — нотная, защищенная: средства хранятся в виде зашифрованных нот вместо текущего баланса, ближе к тратимым единицам, чем к общей сумме по аккаунту. #dusk
вот то самое «по умолчанию», которое изменило то, как я прочитал это, и я вернулся перечитать этот раздел дважды, чтобы убедиться.
одна передача выбирает одну из двух моделей, никогда не смешивает их. отправь DUSK через Moonlight — и он полностью прозрачен, создан для сценариев потоков, которые должны оставаться наблюдаемыми; казначейский или отчетный сценарий — пример того, на что указывают документы. отправь через Phoenix — и сумма, отправитель и какие именно ноты переместились остаются скрытыми; это подтверждается с помощью доказательств с нулевым разглашением вместо открытого показа, но ключ просмотра может раскрыть эти скрытые данные тому, кому решит показать их стейкер. $DUSK
один Transfer Contract обрабатывает и то, и другое, направляя каждый пакет полезных данных в нужную логику верификации и сохраняя согласованность глобального состояния в любом случае.
значит, приватность здесь — не «бинарная» и на уровне протокола: это выбор для каждой передачи, и даже выбранная защищенная опция имеет задокументированный способ снова стать видимой по запросу.
этот выбор находится у отправителя, а не у протокола.
подрывает ли предоставление пользователям публичного варианта идею приватности, или же опциональная, отзывная приватность — это на самом деле более честный дизайн для регулируемых рынков?
опциональная приватность всё ещё является приватностью?
Войдите, чтобы посмотреть больше материала