Binance Square
Dr Roosh
62 Публикации

Dr Roosh

20 подписок(и/а)
6 подписчиков(а)
15 понравилось
Посты
PINNED
·
--
См. перевод
I went looking for how Citadel actually handles a revoked credential. Turns out the answer isn't "the chain checks it." Dusk Network's Citadel protocol $DUSK #dusk lets a user prove a session is cryptographically valid — that a real License Provider signed a real license — but per the docs, that proof does not decide service policy. That call sits with the Service Provider. Per @Duskfoundation's own documentation, the SP decides which License Providers it trusts, which attributes it accepts, whether a session is expired or revoked, and whether the session cookie can be reused. None of that is written into the on-chain verification itself. What changed for me was realizing "privacy-preserving KYC" here doesn't mean the chain enforces compliance. Personal attributes are never written to the blockchain — that part's explicit in the docs. But expiry, revocation, and trust in the issuer are policy decisions each Service Provider makes independently, off-chain, with nothing on-chain forcing consistency between them. @Dusk_Foundation
I went looking for how Citadel actually handles a revoked credential. Turns out the answer isn't "the chain checks it." Dusk Network's Citadel protocol $DUSK #dusk lets a user prove a session is cryptographically valid — that a real License Provider signed a real license — but per the docs, that proof does not decide service policy.
That call sits with the Service Provider. Per @Duskfoundation's own documentation, the SP decides which License Providers it trusts, which attributes it accepts, whether a session is expired or revoked, and whether the session cookie can be reused. None of that is written into the on-chain verification itself.
What changed for me was realizing "privacy-preserving KYC" here doesn't mean the chain enforces compliance. Personal attributes are never written to the blockchain — that part's explicit in the docs. But expiry, revocation, and trust in the issuer are policy decisions each Service Provider makes independently, off-chain, with nothing on-chain forcing consistency between them.
@Dusk
Проверено
Подождите — то самое «защищающее» ваш торговый DuskEVM от ботов прямо сейчас — это вообще не какая-то модная технология. Все говорят о Hedger, privacy engine DuskEVM ($DUSK #dusk @DuskFoundation) — гомоморфное шифрование плюс ZK-доказательства, зашифрованные балансы, настоящая криптография. Но именно это сегодня не мешает фронтраннингу. Я проверил документацию. Сейчас DuskEVM работает только с секвенсором. Публичного мемпула нет. Один секвенсор — и нечего ботам «подсматривать», чтобы забежать вперёд. Это и есть реальный механизм. То есть здесь наложены друг на друга две разные истории про «приватность», и легко отнести заслуги не к той. Hedger — это настоящая криптографическая приватность, аудитопригодность заложена в дизайн. Защита от фронтраннинга — это другое явление, побочный эффект от того, что есть один секвенсор и ничего не выставлено наружу. Вот что я пока не нашёл: в документах или на дорожной карте есть ли указание, останется ли секвенсор DuskEVM одиночным или будет со временем открываться. Если когда-нибудь он станет многопартийным или публичным, этой конкретной защите нужно будет что-то вместо неё. Нигде это не подтверждено — по крайней мере, мне не попадалось. Это скорее вопрос, который поднимает текущая схема. Любопытно, отслеживал ли кто-то реальную дорожную карту секвенсора DuskEVM. Честно, не знаю ответа. @Dusk_Foundation
Подождите — то самое «защищающее» ваш торговый DuskEVM от ботов прямо сейчас — это вообще не какая-то модная технология.
Все говорят о Hedger, privacy engine DuskEVM ($DUSK #dusk @DuskFoundation) — гомоморфное шифрование плюс ZK-доказательства, зашифрованные балансы, настоящая криптография. Но именно это сегодня не мешает фронтраннингу.
Я проверил документацию. Сейчас DuskEVM работает только с секвенсором. Публичного мемпула нет. Один секвенсор — и нечего ботам «подсматривать», чтобы забежать вперёд. Это и есть реальный механизм.
То есть здесь наложены друг на друга две разные истории про «приватность», и легко отнести заслуги не к той. Hedger — это настоящая криптографическая приватность, аудитопригодность заложена в дизайн. Защита от фронтраннинга — это другое явление, побочный эффект от того, что есть один секвенсор и ничего не выставлено наружу.
Вот что я пока не нашёл: в документах или на дорожной карте есть ли указание, останется ли секвенсор DuskEVM одиночным или будет со временем открываться. Если когда-нибудь он станет многопартийным или публичным, этой конкретной защите нужно будет что-то вместо неё. Нигде это не подтверждено — по крайней мере, мне не попадалось. Это скорее вопрос, который поднимает текущая схема.
Любопытно, отслеживал ли кто-то реальную дорожную карту секвенсора DuskEVM. Честно, не знаю ответа.
@Dusk
См. перевод
Spent the afternoon poking around Dusk's repos instead of just reading the pitch deck. #Dusk $DUSK @DuskFoundation — "privacy on a public chain" is the whole TradFi hook, so I wanted to see what's actually moving, not what's being said. Here's the thing that stuck: duskevm-genesis, the repo holding the genesis block and rollup config, had commits land Aug 8 and Aug 10, 2026. Not RWA settlement code. Not a securities contract. Genesis and rollup plumbing — the boring, load-bearing stuff nobody screenshots. Meanwhile DUSK's most active pair, DUSK/USDT on Binance, was doing about $117k in 24h volume when I checked, against roughly $3.07M total across 51 markets (CoinGecko). For a project whose entire thesis is "institutions will finally transact on a public chain," that's a thin signal. Made me reconsider my own framing going in — I assumed compliant privacy meant invisible institutional flow humming in the background. What I found instead was infra still being wired, quietly, while the market cap sits under $50M. So which comes first here — the institutions Dusk keeps promising, or the plumbing finally catching up to the pitch? @Dusk_Foundation
Spent the afternoon poking around Dusk's repos instead of just reading the pitch deck. #Dusk $DUSK @DuskFoundation — "privacy on a public chain" is the whole TradFi hook, so I wanted to see what's actually moving, not what's being said.
Here's the thing that stuck: duskevm-genesis, the repo holding the genesis block and rollup config, had commits land Aug 8 and Aug 10, 2026. Not RWA settlement code. Not a securities contract. Genesis and rollup plumbing — the boring, load-bearing stuff nobody screenshots.
Meanwhile DUSK's most active pair, DUSK/USDT on Binance, was doing about $117k in 24h volume when I checked, against roughly $3.07M total across 51 markets (CoinGecko). For a project whose entire thesis is "institutions will finally transact on a public chain," that's a thin signal.
Made me reconsider my own framing going in — I assumed compliant privacy meant invisible institutional flow humming in the background. What I found instead was infra still being wired, quietly, while the market cap sits under $50M.
So which comes first here — the institutions Dusk keeps promising, or the plumbing finally catching up to the pitch?
@Dusk
Чтение ограничений схемы Phoenix остановило меня. На Dusk $DUSK #dusk @Duskfoundation Контракт Transfer никогда не смотрит на реальные значения нот и на то, какой именно Merkle-лист используется. Он лишь проверяет PLONK-доказательство, что приватные входные данные удовлетворяют пяти условиям: хэш ноты открывается против недавнего Merkle-корня набора нот, доказчик знает секретный ключ ноты, нуллификатор равен Poseidon(npk′ ‖ position), выходные коммитменты корректно открываются, и сумма входных значений равна сумме выходов плюс fee, плюс любые депозиты. Сами нуллификаторы публикуются, чтобы сеть могла отклонять повторное использование. Поскольку каждый нуллификатор выводится из скрытого ключа ноты и позиции, ни один наблюдатель не может сопоставить нуллификатор обратно с конкретным листом. Проверка корректности полностью живёт внутри удовлетворения схемы; содержимое никогда не попадает в реестр. Для меня изменилось понимание того, что защита от двойных трат и целостность баланса обе встроены в доказательство, а не в какие-либо видимые изменения состояния. Следующая проверка: остаются ли опубликованные нуллификаторы каждого принятого транзакционного Phoenix уникальными в on-chain наборе нуллификаторов после финализации. @Dusk_Foundation
Чтение ограничений схемы Phoenix остановило меня. На Dusk $DUSK #dusk @Duskfoundation Контракт Transfer никогда не смотрит на реальные значения нот и на то, какой именно Merkle-лист используется.
Он лишь проверяет PLONK-доказательство, что приватные входные данные удовлетворяют пяти условиям: хэш ноты открывается против недавнего Merkle-корня набора нот, доказчик знает секретный ключ ноты, нуллификатор равен Poseidon(npk′ ‖ position), выходные коммитменты корректно открываются, и сумма входных значений равна сумме выходов плюс fee, плюс любые депозиты.
Сами нуллификаторы публикуются, чтобы сеть могла отклонять повторное использование. Поскольку каждый нуллификатор выводится из скрытого ключа ноты и позиции, ни один наблюдатель не может сопоставить нуллификатор обратно с конкретным листом. Проверка корректности полностью живёт внутри удовлетворения схемы; содержимое никогда не попадает в реестр.
Для меня изменилось понимание того, что защита от двойных трат и целостность баланса обе встроены в доказательство, а не в какие-либо видимые изменения состояния.
Следующая проверка: остаются ли опубликованные нуллификаторы каждого принятого транзакционного Phoenix уникальными в on-chain наборе нуллификаторов после финализации.
@Dusk
Войдите, чтобы посмотреть больше материала
Присоединяйтесь к пользователям криптовалют по всему миру на Binance Square
⚡️ Получайте новейшую и полезную информацию о криптоактивах.
💬 Нам доверяет крупнейшая в мире криптобиржа.
👍 Получите достоверные аналитические данные от верифицированных создателей контента.
Эл. почта/номер телефона
Структура веб-страницы
Настройки cookie
Правила и условия платформы