NewbieToNode

@Dusk

Где-то в продуманном дизайне Piecrust есть тихое признание: песочница — не то место, где должно выполняться всё.

Контракты запускаются как WebAssembly, и это дает виртуальной машине контролируемую среду выполнения.

Самое интересное — сколько тяжелой работы вообще не касается среды WASM.

Хеширование вычисляется нативно.

Точно так же выполняется проверка ZK-доказательств — и PlonK, и Groth16.

Проверки подписи тоже — Schnorr и BLS.

И ничто из этого не работает внутри песочницы, исполняющей контракт.

Причина — число, и оно довольно грубое.

Исследование Dusk приводит оценки, что WASM примерно на 45–255 процентов медленнее нативного кода, когда операции становятся сложными. Криптографическая верификация — это как раз тот тип работы, где эта разница особенно важна.

Загружать эту «пеню» на каждую транзакцию — это компромисс, на который Dusk не была готова, поэтому эти операции обрабатываются через нативные функции-хосты.

Вот что меня зацепило.

Те операции, которые выводят наружу, не случайны.

Хеширование, верификация доказательств, подписи — это значительная часть криптографической машинерии, от которой зависят приватность-ориентированные приложения вроде Phoenix и Zedger.

Песочница обрабатывает логику контракта.

А приватные вычисления происходят где-то еще.

Поэтому здесь нет по-настоящему одного границы исполнения. Есть общая граница VM, а затем — продуманные выходы для операций, где нативное выполнение важнее всего.

То, что я все еще хочу понять, — что обеспечивает детерминированность этого нативного пути на каждом узле. WASM дает очень явную среду выполнения; но если контракт вызывает что-то снаружи, какие гарантии, что каждый узел все равно приходит ровно к тому же результату?

$DUSK становится для меня еще интереснее, когда на этот вопрос есть реальный ответ — а не просто тот, что нативная функция делает работу быстрее.

#dusk

@Dusk

Принудительные переводы. Инициатор — эмитент. Сидит внутри спецификации контракта Zedger так, будто так и должно быть.

Я остановился на этом пункте дольше, чем, вероятно, он заслуживал.

Zedger создан для ценных бумаг и реальных активов, где обычно держатель контролирует свои активы с помощью собственных ключей. Но контракт также предоставляет эмитенту возможность принудительного перевода.

Это не баг, который кто-то пропустил.

Это предусмотренная возможность, наряду с чеканкой (minting), сжиганием (burning) и дивидендами.

Вот та часть, которую я еще не успел отследить.

Когда срабатывает это переопределение, оно не обходит механизмы конфиденциальности. Оно использует их.

Заметка держателя аннулируется через тот же механизм, который применяется при расходовании обычной записи Phoenix. Затем актив может быть переэмитирован на адрес назначения, указанный эмитентом, при этом сам перевод по-прежнему обслуживается доказательной (proof-based) механикой протокола.

То есть тот механизм, который обычно позволяет держателю доказывать контроль без раскрытия ненужной информации, также задействован при выполнении перевода, который держатель не инициировал.

Вот что мне здесь интересно.

Токенизированная облигация — это не просто баланс, лежащий в кошельке. Это юридическое требование, и контракт Zedger уже учитывает вещи вроде дивидендов, корпоративных действий и событий, которые запускаются вне цепочки. Эти обязательства не исчезают из-за того, что актив стал токенизированным.

Ответ Zedger не в том, чтобы прицепить полностью отдельную систему переводов.

Он повторно использует уже имеющуюся механику.

То, что я не могу понять только по whitepaper, — насколько узким остается это переопределение, когда реальные эмитенты начинают использовать его. Кто может его триггерить. При каких условиях. Останется ли граница такой же узкой, когда будут добавляться новые типы активов.

$DUSK only становится для меня еще более интересным именно здесь — после того как эта граница была проверена на чем-то, отличном от контракта, который ее описывает.

#dusk

Я всё время думал, что приватность сети идёт с налогом.

Дополнительные переходы, больше трафика, и где‑то часть расходов, которую ты «съедаешь», чтобы сообщение было сложнее отследить.

Потом я на самом деле посмотрел, как @Dusk перемещает сообщения, и пришлось остановиться.

Традиционная рассылка в стиле «слухов» может затопить сообщение наружу. Узел получает его, отправляет соседям, те делают то же самое — и всё повторяется.

У Kadcast от Dusk так не работает.

Узел пересылает только выбранному набору пиров, и дальше каждый переход — ещё дальше. Не «вылетает залпом», а проходит этапами.

На 25–50 процентов меньше потребление пропускной способности, чем при gossip-style broadcasting. Именно это число даёт whitepaper.

И устаревших блоков тоже меньше: 10–30 процентов при более быстрых условиях блоков, с которыми они это сравнивают.

Отличная, эффективная маршрутизация. Я ожидал эту часть, когда увидел структуру.

А вот чего я не ожидал — что та же поэтапность ещё и причина, почему сообщение становится сложнее отследить обратно к тому, кто отправил его первым.

Это не отдельная функция приватности, добавленная поверх.

То же решение маршрутизации выполняет обе задачи. Сообщение, проходящее через многослойные ретрансляторы, а не через один прямой широковещательный посыл, не оставляет такого же очевидного следа обратно к точке старта.

Я не думаю, что раньше видел такое сочетание, когда и ход к эффективности, и свойство приватности возникают из одного и того же решения, а не из двух вещей, прикрученных друг к другу.

Всё ещё не знаю, сохранится ли это, когда сеть станет намного больше.

Возможно, сцепление надёжное. А возможно, где‑то после определённого масштаба, выжимание из системы ещё большей эффективности начнёт стоить стороне приватности чего‑то, чего сегодня это не стоит.

$DUSK для меня становится ещё интереснее, когда это реально протестировали под нагрузкой, а не просто так «на бумаге».

#dusk

#dusk @Dusk

Я искал источник случайности, стоящий за детерминированной сортировкой Dusk.

Я ожидал, что будет совершенно отдельный механизм. Внешний маяк случайности. Значение, сгенерированное независимо от цепочки.

Однако его нет.

Сид, используемый для выбора следующего генератора блоков и голосующих комитетов, берётся из подписи текущего генератора блока по сидy предыдущего блока.

Каждый блок формирует входные данные, необходимые для следующего выбора.

Именно это остановило меня.

Сид не просто передаётся от блока к блоку. Он каждый раз генерируется заново текущим генератором блока. Генератор, который мог бы предсказать будущий выбор, имел бы причину использовать эту осведомлённость.

В whitepaper прямо говорится, почему это важно. Поскольку каждый сид существует только один раз — в момент, когда его генератор подписывает его, — будущие генераторы и члены комитета не могут быть рассчитаны заранее.

Не потому, что информация где-то скрыта.

А потому что она ещё не существует.

Я представлял непредсказуемость как нечто, что консенсусной системе нужно импортировать откуда-то извне.

@Dusk рассматривает её как то, что цепочка производит шаг за шагом.

Это меняет то, что я считаю границей безопасности. Важное свойство не в том, что сид остаётся секретным. Важнее то, что информация, необходимая для следующего выбора, появляется только после того, как текущий блок будет произведён.

То, что мне всё ещё хочется понять, — что происходит, когда одна и та же небольшая группа генераторов случайно производит несколько подряд идущих блоков. Сохраняется ли та же непредсказуемость во всём этом промежутке при связанной конструкции подписи, или повторный контроль над производством блоков меняет какие-либо из допущений по безопасности?

$DUSK становится для меня ещё интереснее только в том случае, если эта цепочка зависимостей выдерживает реальный отрезок подряд идущих генераторов — а не только в модели.

@Dusk

Я ожидал, что on-chain KYC будет работать примерно так же, как везде в других местах.

Отправьте свою идентичность один раз для каждого сервиса, и теперь этот сервис хранит копию того, кто вы.

Citadel заставил меня переосмыслить это.

Пользователь проходит проверку один раз у License Provider, который выпускает лицензию. Затем Service Provider может проверять, действительна ли эта лицензия, не видя идентичность, стоящую за ней.

Я представлял себе нечто ближе к менеджеру паролей. Одна учетная запись, используемая везде, всё равно распознаётся как принадлежащая одному и тому же человеку каждый раз, когда кто-то её проверяет.

Но происходит не это.

Два разных сервиса, проверяющие лицензию одного и того же человека, не могут понять, что смотрят на одного и того же человека. Каждая проверка не связана с последующей, хотя проверяется одна и та же базовая лицензия.

Поэтому интересный тезис — не просто «ваши данные остаются приватными».

А в том, что повторяющиеся проверки соответствия не обязаны создавать цепочку, связывающую эти проверки между собой.

Это меняет компромисс.

Независимый KYC в каждом сервисе повторяется и стоит дорого, но каждый сервис контролирует собственную верификацию. Citadel устраняет эту повторяемость, делая License Provider той стороной, которая устанавливает исходную лицензию.

Даже восстановление следует этой архитектуре: чтобы восстановить кошелёк из seed phrase, достаточно восстановить лицензии, без необходимости, чтобы пользователь хранил отдельную резервную копию лицензии.

Пользовательский опыт ниже по цепочке становится проще и более приватным.

Но вопрос доверия смещается вверх по цепочке.

Чего я всё ещё не знаю, так это того, как License Provider вообще получает эту роль, и исчезло ли действительно то бремя соответствия, которое раньше лежало на каждом отдельном сервисе — или оно просто переместилось на один уровень выше.

$DUSK становится для меня действительно интересным только тогда, когда я пойму, кто может стать License Provider, и что удерживает эту роль от превращения в новый центральный источник отказа.

#dusk

@Dusk

Я снова и снова возвращался к слову «подтверждено», отслеживая путь окончательности Dusk.

Удивляет не то, что состояний четыре.

Удивительно то, что путь к подтверждению меняется в зависимости от того, что произошло ранее в раунде.

В модели скользящей окончательности первая итерация начинается с n = 0 предыдущих неаттестованных итераций, поэтому она идет по быстрому пути.

Теперь допустим, что две итерации не смогли произвести требуемую аттестацию.

n = 2.

Правило становится 2×n, то есть нужны четыре последовательных блока с требуемыми аттестациями или подтверждениями, прежде чем блок, который оценивается, станет подтвержденным.

Что меня зацепило: это происходит, когда раунд уже ведет себя плохо. Подтверждение на самом деле может потребовать больше доказательств, прежде чем оно продвинется дальше.

История раунда меняет то, сколько доказательств нужно следующему блоку.

Так что подтверждение — это не только про блок. Это отчасти про то, что раунд сделал до этого.

То, чего я до сих пор не могу понять из статьи, — как часто эта дополнительная глубина появляется в реальных условиях сети.

$DUSK becomes для меня более интересным, если эта адаптивная окончательность остается предсказуемой, когда сеть начинает «путаться».

#dusk

#termmax @TermMax

Пример TermMax от Alice начинается довольно просто.

ETH вносится в качестве залога. В итоге на момент погашения у неё остаётся обязательство в 1 600 USDC. Задействованная (с плечом) позиция упаковывается в один Gearing Token вместо того, чтобы управлять ею через отдельные циклы.

Затем я заметила кое-что на другом конце.

На момент погашения Алиса не обязательно должна отдавать 1 600 USDC.

Она может купить 1 600 FTs на рынке.

Если эти FTs торгуются по $0,95, то это $1 520 для закрытия обязательства на 1 600 USDC.

Возможная экономия $80 — просто если выбрать другой маршрут расчётов.

Вот что я раньше по-настоящему не связывала.

GT — это не только «упаковка» плечевой позиции на входе.

Он создаёт второе рыночное решение на выходе.

Долг фиксирован.

Срок погашения фиксирован.

Но самый дешёвый способ его закрыть может измениться.

Так что держать GT — это не просто держать плечо до момента погашения.

Вы также несёте решение по выходу.

И это решение зависит от того, как выглядит рынок FT именно тогда, когда вам реально нужно закрываться.

$TMX пока не запущен, так что я не буду делать вид, что сегодня это имеет последствия для ценности токена.

Но если GT станет одним из основных способов, которыми пользователи входят в плечевые позиции, ликвидность и ценообразование FT станут намного более важными для пользовательского опыта.

На момент погашения долг не меняется.

Меняется решение.

И то, что всё ещё вызывает у меня интерес: сохраняется ли эта возможность в $80, когда использование GT станет большим, или более высокий спрос на GT в итоге сделает скидку на FT слишком маленькой, чтобы это имело значение.

ну вот, безработные заявки сегодня составили 206 тыс., что ниже 212 тыс. на прошлой неделе. заголовки назовут это «сильным рынком труда», но если посмотреть дальше первой цифры… 4-недельная скользящая средняя выросла до 204 тыс., а продолжающиеся заявки поднялись до 1,8 млн. людям становится сложнее находить новые работы, даже если прямо сейчас увольняют меньше.
и вот что — экономист буквально сказал, что рынок труда «не демонстрировал никаких признаков износа» из‑за скачка цен на нефть, связанного с войной в Иране. вот настоящая история, о которой никто не делает заголовки.
рынки, вероятно, воспримут это как «златовласка» (не слишком горячо и не слишком холодно), что сохраняет ФРС на траектории снижения ставок. это, по сути, неплохие новости для риск‑активов — более низкие ожидания по ставкам обычно поддерживают BTC и крупные валютные пары. смотрим, будет ли зелёная реакция к закрытию или же смешанные внутренние показатели (рост продолжающихся заявок) все испортят.
это не инвестиционный совет, просто мысли вслух 🤔

#USJoblessClaimsFallTo206000

@Dusk

16 последовательных неудачных итераций — достаточно, чтобы Dusk перестал вести себя нормально.

Я несколько раз прочитал это число, прежде чем оно дошло до меня.

В обычных условиях шаги консенсуса выполняются с таймаутом. Если шаг не дает результата вовремя, он ничего не возвращает, и раунд повторяется.

Попробуй. Таймаут. Попробуй снова.

Я думал, что путь отказа остается на месте, независимо от того, насколько все плохо.

Оказалось, что нет.

После 16 подряд неудач Dusk отключает эти таймауты. Шаги больше не могут возвращать NoCandidate или NoQuorum. Итерации продолжают выполняться, пока кандидат фактически не достигнет кворума для валидации и ратификации.

Это создает второй режим отказа, который я раньше не отделял.

Обычный сбой ограничен часами. Аварийный режим убирает эту границу.

И это приводит к другой проблеме: несколько итераций с открытым окончанием могут выполняться одновременно, создавая возможность того, что конкурирующие кандидаты достигнут кворума в одном и том же раунде.

У Dusk уже есть правило для такого случая: выигрывает кандидат, который достиг кворума на минимальной итерации.

Но чего я все еще не знаю — как именно выглядит эти 16 последовательных неудач в реальной сети.

Какая именно длительная сетевая ситуация доводит до этого и как часто правило разрешения развилки действительно применяется, а не остается теоретическим сценарием?

$DUSK становится для меня более интересным, если этот аварийный путь оказывается надежным, когда сети он действительно нужен.

#dusk

#termmax @TermMax

Сегодня я проверял TVL TermMax и одна цифра отправила меня обратно к документации по ликвидациям.

$31.22M, снижение на 7.2% за последние 30 дней, по данным DeFiLlama.

Это не крах. Но это заставило меня пристальнее посмотреть, что происходит, когда ликвидация идет не по плану.

Когда по займу достигается порог LLTV или заемщик пропускает дату погашения, позиция получает 2-часовое окно ликвидации.

Ликвидаторы получают 5% вознаграждение от залога. Протокол взимает штраф в размере 5%.

Обычно на этом все.

Но что происходит, когда 2 часов недостаточно?

В собственных документах по рискам TermMax описан резервный сценарий. Если ликвидацию нельзя полностью выполнить из‑за резкого движения цены или низкой ликвидности, кредиторам предоставляется пропорциональная доля залога заемщика вместо актива, который они изначально выдали в кредит.

Физическая передача.

Автоматически. Без опции со стороны кредитора.

Вот это место мне пришлось обдумывать дважды.

Ставка фиксированная.

Срок фиксированный.

Путь восстановления не фиксирован.

И я не думаю, что это обязательно недостаток. Если альтернатива — провал ликвидации и более крупные потери, то получение лежащего в основе залога может оказаться лучшим исходом.

Но это меняет то, что для кредитора означает «определенность».

Вы знаете ставку.

Вы знаете срок.

Но вы не обязательно знаете, какой именно актив окажется у вас в кошельке, если стандартный сценарий ликвидации сломается.

Снижение TVL на 7.2% не говорит мне о том, что Физическая передача близка к срабатыванию где‑то. У меня нет этих данных.

Зато это заставляет меня захотеть увидеть рядом с TVL еще одну цифру: сколько залога в реальности можно расчистить внутри того самого 2-часового окна?

Потому что именно эту границу я хотел бы понимать, прежде чем называть механизм ликвидации устойчивым под нагрузкой.

Если TermMax когда‑нибудь сделает эту цифру видимой, именно за ней я и буду следить.

#dusk $DUSK @Dusk

Я начал с требования 1 000 DUSK, а затем застрял на настройке кошелька.

Одна ставка может использовать два разных ключа.

Консенсусный ключ управляет узлом. Он голосует и подписывает блоки.

Ключ владельца контролирует другую сторону: анстейкинг и вывод средств.

Dusk рекомендует держать их раздельно.

Это изменило то, как я стал воспринимать требование в 1 000 DUSK.

Это не просто капитал, лежащий в кошельке. Это рабочая позиция, привязанная к машине, которая должна быть постоянно в сети 24/7 и участвовать в консенсусе.

Dusk разделяет полномочия на управление консенсусом и полномочия на контроль ставки.

Компрометация консенсусной стороны не дает автоматически контроль над ставкой.

Компромисс получается интересным.

Граница безопасности становится лучше. Путь восстановления — сложнее.

Если провайдеру/валидатору нужно выполнить миграцию или восстановление в условиях цейтнота, как операторы сохраняют это разделение, не теряя свою роль в консенсусе?

#termmax @TermMax

Пример на 45 дней в Morpho-интеграции TermMax застал меня врасплох.

Один заёмщик имеет 50 000 USDC под залог wstETH, зафиксированные в позиции TermMax со сроком погашения.

Фиксированная ставка. Известный срок.

Всё достаточно просто.

Затем я заметил «путь для выхода».

Переход в Morpho позволяет этому же заёмщику закрыть позицию TermMax до наступления срока и перевести тот же самый залог в плавающий по ставке кредит на Morpho — атомарно.

Без перерывов в покрытии. Не нужно заранее искать средства на погашение.

Их собственный пример показывает, почему это важно: если заёмщик ожидает снижения плавающих ставок, он может выйти из фиксированной позиции раньше и рефинансироваться через Morpho.

Так что интересен не сам процент.

А именно обязательство.

TermMax создала продукт с фиксированной ставкой, а затем — продуманный вариант с низким трением для выхода из фиксированной части.

Это означает, что дата погашения не является «стеной».

Скорее это настройка по умолчанию, которую заёмщик может переопределить, когда меняется его взгляд на ставки.

Вот что я не могу ответить, просто прочитав механизм:

Когда ставки достаточно сильно сдвигаются, чтобы Roll to Morpho стало привлекательным, то этот выход защищает ликвидность TermMax или, наоборот, откачивает фиксированную часть ровно тогда, когда протоколу нужно обязательство удерживать позиции?

Именно такое поведение мне бы хотелось увидеть, когда через систему пойдёт реальный объём, а не «чистый» пример на 50 000 USDC.

$TMX пока не в сети, поэтому меня меньше интересует, что делает токен сегодня. Меня больше интересует, сможет ли эта архитектура выдержать нагрузку в масштабе до того, как токен станет частью уравнения.

#dusk $DUSK @Dusk

Я остановился на вознаграждении генератора в 80% в первый раз, когда прочитал разделение блок-награды у Dusk.

Затем я заметил, что эти 80% на самом деле не являются ровными.

Награда разделяется: 80% — генератору, 10% — комитету по голосованию и 10% — Dusk.

Только 70% доли генератора фиксированы. Остальные 10% зависят от того, сколько голосов комитета попадает в сертификат блока, с учетом веса кредитов избирателей. Учитывайте все голоса, и тогда генератор получает все 80%.

Так что победа в блоке и максимизация его награды — это разные вещи.

Генератору нужно сделать больше, чем просто создать блок; ему также необходимо включить работу комитета в сертификат.

Это создает простую, но интересную мотивацию: часть экономики генератора зависит от того, насколько полный этот сертификат.

То, чего я не могу понять по документации, — насколько это важно на практике. Когда голоса приходят с опозданием, как часто эти переменные 10% действительно удается заполучить?

#termmax @TermMax

2M $TMX.

Вот число, к которому я постоянно возвращался после просмотра бустер-кампании TermMax...

1,7M идет в лотерею. 300K — создателям в Binance Square.

А самый большой призовой пул — довольно беспрепятственный. Указанные задачи лотереи по сути сводятся к подписке, репосту, квизу, Discord и подключению кошелька — для этого маршрута не требуется депозит или реальная активность по заимствованиям, кредитованию или опционам.

Постойте...

Вся история продукта TermMax — это фиксированные ставки по заимствованию, кредитованию и опционам, капитал, где вы заранее знаете ставку и срок.

Но самый большой «рельс» с наградами на самом деле не требует, чтобы пользователи использовали эти продукты.

Меньший пул в 300K TMX — это сторона Binance Square, где создателям приходится конкурировать за качество контента и позиции в рейтинге.

Так, возможно, я рассматривал Booster не с той стороны.

Похоже, что пул 1,7M TMX сделан для низкопорогового охвата и подключений кошельков... а меньший пул Square вознаграждает заметность и ранжирование создателей.

Это, возможно, и правда имеет смысл для TGE-кампании.

Но что происходит после того, как TMX попадет на руки?

Станут ли участники из 1,7M TMX пользователями TermMax... или же кампания заканчивается там, где заканчивается награда?

#termmax @TermMax

Сегодня утром я просматривал(а) последнее обновление TermMax... начал(а) с деталей TGE от 25 августа и в итоге как-то случайно увлёкся(лась) цифрами.

$90M+ TVL. 1.5M+ зарегистрированных кошельков. 90K+ ежедневных активных пользователей. 10 EVM-сетей.

Окей... это довольно серьёзный охват.

Но потом я заметил(а), где сейчас фактически появляется та же идея фиксированной ставки.

Кредитование, опционы, токенизированные акции... и даже институциональное финансирование на Canton.

Это заставило меня на секунду задуматься.

Потому что это не просто @TermMax берёт один продукт кредитования с фиксированной ставкой и переносит его на большее число сетей. Они продвигают ту же идею «известная ставка, известный срок» в совершенно разные типы капитала.

Хм... не уверен(а), что это так просто, как звучит.

Если капитал становится больше и людям, которые им пользуются, нужно планировать денежные потоки, то определённость, вероятно, становится более ценной.

Но DeFi годами строился вокруг гибкости.

Так что же победит, когда эти два направления начнут тянуть в разные стороны?

$TMX выходит в эфир 25 августа.

Полагаю, именно это я сейчас и отслеживаю.

#dusk $DUSK @Dusk

Раньше я думал, что регулирующая часть ончейн-активов в основном сводится к самому активу.

Может ли этот токен существовать? Может ли он торговаться?

Но когда я посмотрел, как лицензии NPEX разбиваются на составляющие, мне показалось, что это, вероятно, слишком простое объяснение.

MTF, Broker, ECSP и DLT-TSS совсем не похожи на одну-единственную маркировку соответствия, прикреплённую к активу.

Скорее это выглядит как разные разрешения на разные действия, которые можно совершать с этим активом.

И именно это изменило то, как я теперь об этом думаю.

Один и тот же актив может находиться и в выпуске, и в дистрибуции, и на вторичном рынке, но это не одно и то же регулируемое действие.

Поэтому извне формулировка «регулируемые финансы на Dusk» может звучать как одна возможность.

Чем больше я в это вглядываюсь, тем меньше это ощущается как одна вещь.

Скорее это набор отдельных функций, которые в разной точке соприкасаются с одним и тем же активом.

Возможно, это разделение в основном сохраняется на уровне лицензирования.

То, что меня сейчас интересует, — проявляется ли оно также в реальной архитектуре продукта.

#dusk $DUSK @Dusk

Что если токен говорит, что вам принадлежит ценная бумага, но закон утверждает, что реальная запись находится где-то в другом месте?

Я столкнулся с этим вопросом, читая последний материал Дуска о токенизации для SME.

В статье приводится конкретный пример из Нидерландов: передача долей в BV требует нотариального акта.

Это вызывает вопрос, который я раньше особо не обдумывал. Если ценная бумага представлена on-chain, но юридически обязательная процедура при этом остается вне цепочки, что именно тогда представляет собой токен?

Я в основном думал о токенизированном владении как о задаче размещения актива в on-chain. Но, возможно, сложнее всего — поддерживать согласованность цифрового состояния владения с тем, какую запись юрисдикция реально признаёт.

Если эти два состояния когда-либо могут расходиться, токенизация ещё не полностью устранила необходимость согласования. Она создала новую проблему координации между цифровой и юридической сторонами.

Так что, когда on-chain-состояние владения и юридически авторитетная запись расходятся, что Дуск считает источником достоверности?

$HEMI
$ACE

#dusk $DUSK @Dusk

Раньше я думал, что «регулируемые активы в ончейне» — это по сути один регуляторный барьер.

Когда я разобрался в партнерстве Dusk и NPEX, стало ясно: это устроено гораздо сложнее.

В материалах самой Dusk перечислены четыре лицензии: лицензия MTF для регулируемого вторичного рынка, лицензия брокера для привлечения активов — например, MMF и облигаций, лицензия ECSP для инвестиционных инструментов для розничных клиентов с финансированием от населения, а также лицензия DLT-TSS, связанная с нативной эмиссией и токенизацией регулируемых активов в ончейне.

Самое интересное не то, что у NPEX четыре лицензии. А то, что они соответствуют разным действиям, которые институция может реально выполнять с активом.

Торговля уже существующим регулируемым активом и создание этого актива нативно в ончейне — это два разных процесса, у которых под капотом разные регуляторные требования.

Я раньше это не разделял. «Регулируемые финансы в Dusk» звучит как одна возможность со стороны, но инфраструктура за этим гораздо более детализирована.

То, за чем я сейчас наблюдаю, — проявляется ли это разделение в регулировании также в реальной архитектуре продукта.

Требует ли нативная эмиссия в Dusk принципиально другого процесса, чем подключение уже существующего регулируемого актива в сеть?

@Dusk

После предупреждения распорядитель Dusk может перевести 10% своего стейка в Rewards, но токены не сжигаются.

Это был тот момент, которого я не ожидал.

Окончательно утверждённый механизм soft-slashing у Dusk ужесточается при последовательных нарушениях. N нарушений означают, что N × 10% стейка переносится на баланс Rewards того же узла, а распорядитель исключается из консенсуса на N эпох.

Так что штраф — это не просто «ваши токены исчезают».

Стейк остаётся у того же распорядителя. Меняется лишь то, какая его часть остаётся активной для участия в консенсусе.

Есть ещё одна деталь, которая показалась мне даже более интересной. Счётчик ошибок не сбрасывается только потому, что приостановка заканчивается. Dusk говорит, что предупреждение и счётчик ошибок сбрасываются, когда распорядитель действительно получает награду — создавая блок или успешно голосуя.

То есть ожидание не восстанавливает запись. Восстанавливает её успешное участие.

Снижение активного стейка может также продолжаться вплоть до сетевого минимума в 1 000 DUSK.

После прочтения этого я начал думать о soft slashing иначе. Это меньше похоже на изъятие токенов у кого-то и больше — на постепенное снижение активного веса и права на участие распорядителя, который продолжает допускать сбои.

Значит ли это, что восстановление после повторяющихся ошибок намеренно сложнее, чем просто переждать приостановку?

@Dusk #dusk $DUSK

#dusk $DUSK

Я думал, что быстрая транзакция в DuskEVM — это по сути уже “завершённая” транзакция.

Но потом я нашёл предупреждение в документации Dusk, которое заставило меня пересмотреть это предположение.

DuskEVM разделяет включение транзакции и её финализацию.

Транзакция может быстро попасть в блок уровня L2, но это не значит, что получившееся состояние уже финализировано и возвращено в Dusk L1. Эти две стадии связаны через батчирование, подтверждения состояния и fault proof’ы.


Самая интересная деталь, которую я нашёл: @Dusk explicitly прямо говорит приложениям, которые перемещают средства между DuskEVM и Dusk L1, НЕ делать вывод о финальности только на основании прошедшего времени.

Звучит очевидно после прочтения, но на самом деле это важное различие в дизайне.

«Подтверждено быстро» и «можно безопасно считать завершённым» — не обязательно одно и то же.

Для приложения, которое перемещает реальные средства, использование таймера как “ярлыка” может означать действия по факту включения, пока кросс-уровневая процедура финализации ещё не завершена.

Так что у меня остался один вопрос:

Какой именно статус протокола приложение должно считать авторитетным, прежде чем выпускать средства через границу DuskEVM ↔ Dusk L1?