Чем больше я узнаю про Dusk и стейкинг, тем больше понимаю, что эта часть заслуживает внимания сильнее всего — даже по сравнению с историей про приватность. Сейчас, чтобы делать стейкинг, нужно минимум 1.000 DUSK, активация занимает около 1–2 эпох. Протокол планирует выпустить 500M DUSK за 36 лет, при этом эмиссия будет уменьшаться на 50% каждые 4 года Сначала я почти не обращал внимания на эти цифры. Но чем больше я вникаю в то, как всё устроено, тем интереснее становится. @Dusk защищает не только консенсус, но и появляется в стейкинге, gas и settlement по мере расширения экосистемы $DUSK По сравнению с обновлением whitepaper за ноябрь 2024 года, текущая архитектура Dusk заметно изменилась. Тогда Moonlight и Phoenix всё ещё отвечали за public transactions и приватность в regulated finance. К июню 2025 Dusk перешёл к трём частям: DuskDS — для settlement и data availability, DuskEVM — для EVM-приложений, а DuskVM — для приложений, которым нужна приватность Я вижу, что стейкинг может обрести другой смысл, когда Dusk перейдёт в фазу, где появится больше реальной активности. Когда EVM и VM начнут привлекать пользователей, один токен может использоваться сразу на разных уровнях сети. Разумеется, сейчас я лишь выдвигаю эту гипотезу Я также особенно обращаю внимание на Stake Abstraction, потому что она открывает возможность того, чтобы контракты самостоятельно обрабатывали стейкинг. Это, в свою очередь, может поддерживать модели вроде staking pool или стратегии автоматизированного управления напрямую в сети Однако я пока не понимаю текущую активность #dusk — насколько она действительно отражает спрос на использование. Какая часть — это приложения, а какая — просто стейкинг и инфраструктура; сейчас всё ещё не хватает данных, чтобы чётко это различить Если у вас есть более подробные on-chain данные, я очень хотел бы их посмотреть, чтобы сопоставить то, что я наблюдаю, и лучше понять, что именно текущая активность в сети отражает на практике
Я потратил некоторое время на изучение раздела 6 технической документации @Dusk и ушёл с большим количеством вопросов, чем ответов.
Что интересно, я думаю, это хороший знак.
Меня привлекло внимание не только PVM или модель исполнения на основе WASM. Важнее было то, насколько поведение основной сети Dusk, судя по всему, вынесено в контракты.
Transfer обрабатывает $DUSK transfers, комиссионные за валидацию и исполнение. Stake управляет заблокированными DUSK, состоянием стейкинга и выводами. Такие будущие компоненты, как Zedger и Clock, ещё сильнее добавляют логики в контракты.
Это заставило меня пересмотреть одно предположение.
Сначала я в первую очередь рассматривал PVM как лёгкий модульный способ запускать смарт-контракты. Но более глубокий вопрос может быть не в том, насколько аккуратно VM их выполняет.
Вопрос в том, кто контролирует контракты, от которых всё больше зависит сеть.
Если важный контракт становится узким местом безопасности, как он обновляется или заменяется?
Кто на самом деле имеет полномочия это изменить?
И насколько децентрализован такой контроль на практике?
Эти вопросы теперь значат для меня больше, чем просто знание того, что #Dusk имеет WASM-ориентированную VM.
Интересная часть архитектуры может быть меньше связана с тем, что контракты могут делать, и больше — с тем, что происходит, когда сеть начинает полагаться на них в критическом поведении.
Мой следующий шаг — глубже разобраться в том, как управляются, обновляются и защищаются эти генезис-контракты и будущие системные контракты.
Прошлым утром я почти всё время потратил на то, чтобы поиграться с новым testnet DuskEVM от @Dusk , вместо того чтобы заняться чем-то полезным.
Testnet вышел с 10/8, и сейчас больше всего обсуждают “поддержку Solidity и Hardhat”. В целом это, конечно, неплохо, но, честно говоря, это то, из-за чего у меня не возникало бы ощущения “стоп, давай подробнее”.
Больше всего меня зацепил способ #dusk обрабатывает settlement. Контракт работает на DuskEVM, а sequencer отвечает за execution, но batcher отправляет данные транзакций в DuskDS в виде blobs. Затем proposer уже записывает туда state commitment. Если совсем просто: execution происходит на DuskEVM, а финальность “якорится” на базовом слое. Газ оплачивается $DUSK , но перед деплоем нужно сделать bridge DUSK из DuskDS.
Эта мысль постоянно крутится у меня в голове. Чтобы начать писать Solidity на DuskEVM, разработчику пришлось сначала реально перекинуть DUSK через bridge. Для меня этот нюанс делает опыт с сетью более приземлённым — а не просто чем-то теоретическим.
Только что просмотрел explorer testnet и увидел, что контракт уже появился там несколько дней назад. Новая сеть работает всего шесть дней, а активности уже столько — на мой взгляд, это совсем не мало.
Я всё ещё копаюсь и пытаюсь понять, будет ли эта модель settlement-anchoring действительно играть большую роль в том, как в дальнейшем будут работать на EVM такие активы вроде NPEX, или я просто рассматриваю знакомый паттерн из OP Stack и придаю ему слишком много смысла.
Пока я склоняюсь к первой версии, но пока ещё недостаточно уверен, чтобы сделать вывод.
@Dusk @Dusk $DUSK #dusk Раньше я думал, что приватность в блокчейне означает принятие меньшей прозрачности.
Если вы хотели приватность, вам приходилось жертвовать видимостью. Если вы хотели соответствие требованиям, вам приходилось принимать, что всё становится публичным.
Затем я углубился в модель транзакций @Dusk — и одна деталь заставила меня остановиться.
Меня привлекло не само по себе приватностное повествование, а то, как Moonlight и Phoenix работают вместе.
Moonlight может обеспечивать прозрачность для комплаенса, тогда как Phoenix использует ZK, чтобы защищать чувствительные данные — например, балансы и суммы транзакций.
Сначала я увидел в этом ещё один механизм приватности.
Но чем больше я смотрел, тем яснее понимал: реальная идея — отделить проверяемость от видимости.
Институт может доказать то, что нужно регуляторам для проверки, не раскрывая полностью ни своей финансовой позиции, ни торговой стратегии рынку.
Из-за этого мне приходится заново обдумать подход #Dusk .
Возможно, будущее институционального блокчейна — это не полная прозрачность и не полная анонимность, а управляемая приватность.
Я всё ещё задаюсь вопросом:
Если приватность становится проверяемой, не будучи полностью видимой, то это тот самый мост, который приводит институты в крипто, — или компромисс с изначальным безразрешительным видением крипто?
Когда я только начал разбираться в fixed-rate DeFi, мне казалось, что всё довольно просто: высокая ставка — это привлекательно, низкая — почти не вызывает интереса. Но когда RWA появляется в роли залогового актива, я начинаю смотреть иначе. Тогда процентная ставка в какой-то мере отражает то, как рынок оценивает стоимость актива, стоящего за займом.
Больше всего меня увлекло в @TermMax то, как каждый market может формировать собственную «базовую» ставку по займам. Когда RWA используется как залог и привязывается к фиксированному сроку, различия могут возникать из-за ликвидности, качества активов и даже их волатильности. Если эти данные достаточно богаты по времени, @TermMax может позволить построить onchain-базу для оценки кредитоспособности, а не просто стать местом, которое добавляет ещё один APY.
Я хочу увидеть ещё одну вещь: действительно ли пользователи остаются надолго. Высокий reward не обязательно означает устойчивый спрос. Я буду следить за тем, продолжает ли lender предоставлять капитал, выравнивается ли rate, когда бонусы снижаются, и возвращается ли заёмщик на несколько периодов. Тонкая ликвидность также может делать ставку визуально привлекательной, хотя в реальности всё иначе, особенно когда основной объём сделок идёт от небольшой группы.
Я буду относиться к @TermMax лучше, если кредитная активность сможет держать темп: ставка будет отражать особенности каждого типа залога, а ликвидность будет равномерно распределяться по разным terms. И наоборот — если окажется, что рассказа больше, чем реальной картины, я буду сохранять осторожность.
Раньше я представлял процесс конвертации FT довольно прямолинейно: заем погашается, держатель FT получает debt-токен, а затем сделка завершается. Я думал, что это будет простая процедура расчетов по истечении срока.
Но в документации @TermMax предусмотрен вариант обработки, если заем не закрывается так, как ожидалось. Если к концу liquidation window долг все еще остается или был обработан лишь частично, то произойдет автоматическая physical delivery. Эта часть активов обрабатывается прямо в механизме конвертации — пользователю не нужно делать дополнительные шаги.
Важный момент: держатель FT может получить иные виды активов по сравнению со случаем, когда заем погашен полностью. В этот момент пул может включать debt-токены вместе с оставшимися токенами залога. Долю активов @TermMax распределяет пропорционально FT-частке, которую каждый человек держит от общего предложения FT.
Иными словами, коэффициент конвертации 1:1 между FT и debt-токеном отражает только ситуацию, когда все идет по плану. Если в процессе обработки займа возникают проблемы, держатель FT получит соответствующую часть стоимости из пула, и количество этих активов может измениться в зависимости от результатов обработки до даты погашения.
#binancep2pantoan @Binance Vietnam Раньше я обычно был(а) настороже только к тем действиям, которые выглядели как отложенные или не завершившиеся платежи. После некоторого наблюдения я увидел(а) другую ситуацию, которая так же легко может усыпить бдительность пользователей: в процессе общения другая сторона вдруг присылает новую информацию для получения оплаты — просит изменить платежный аккаунт. Причины, которые они приводят, часто звучат вполне обыденно и ничем не выделяются, например, что с прежним аккаунтом возникли проблемы. Но я обратил(а) внимание на главное: данные по ордеру больше не остаются неизменными. Я просмотрел(а) исходный ордер, чтобы понять опорные моменты: кто является контрагентом, какова сумма сделки и куда отправляются деньги
С первого взгляда это может показаться логичным, но одной просьбы сменить аккаунт достаточно, чтобы все стало гораздо труднее подтвердить. Для меня в этом и заключается ключевой момент: из‑за этого мне приходится остановиться и начать проверять заново — кто именно ведет сделку, сумма и способ оплаты
По моему мнению, лучшее решение — не сразу подозревать другую сторону, а перепроверить, что именно было изменено, прежде чем продолжать. Binance также советует пользователям выбирать доступный способ оплаты и проверять, чтобы данные аккаунта соответствовали требованиям сделки. Но это имеет смысл только тогда, когда новые данные все еще соответствуют исходному ордеру и я могу их подтвердить. Если я не уверен(а), я предпочитаю остановить сделку и использовать Appeal, если ситуацию нужно будет дополнительно разрулить
Я до сих пор думаю, когда именно изменение — это просто неудобство, а когда оно уже становится признаком, требующим настороженности. Возможно, именно этот момент мне стоит продолжать отслеживать в последующих сделках $XRP $COLLECT $ON #TinFed #GrayscaleFilesToListZcashTrustOnNYSEArca #WalmartFalls7%
$DUSK @Dusk Однажды я услышал(а), как моя подруга рассказывала о переводе средств между двумя аккаунтами, открытыми в разных местах. Ей казалось, что достаточно выполнить одну операцию в одном аккаунте, и тогда на другом все произойдет аналогичным образом. Но когда она захотела вернуть деньги обратно, процесс снова потребовал дополнительного шага проверки в исходной точке обмена.
Эта история заставила меня задуматься о том, как @Dusk передавался(ась) туда-сюда между Dusk L1 и DuskEVM Testnet.
Я раньше думал(а), что оба направления работают примерно одинаково: при отправке с Dusk L1 DUSK отображается в подключенном кошельке DuskEVM. Но в обратном направлении все оказалось совсем иначе. Команда начинается на DuskEVM, затем нужно вернуться на @Dusk L1, чтобы подтвердить (prove) withdrawal и завершить операцию (finalize). Поэтому, помимо комиссии в месте инициации, пользователю приходится дополнительно оплачивать еще две комиссии на L1.
Самое важное, что я отметил(а), — это логика, стоящая за процессом, а не количество действий. Withdrawal может продолжаться только тогда, когда сетевой статус уже обновлен, proof достиг нужных условий и связанные проверки завершены. Поэтому в руководстве #dusk советуют пользователям смотреть текущий статус напрямую в Web Wallet, а не полагаться только на время ожидания.
#termmax @TermMax Я долго размышлял о том, обязательно ли кредитное плечо должно идти рука об руку с ликвидацией, и в TermMax Alpha Options ответ, похоже, более отличается, чем в большинстве других подходов.
Это не снижение плеча ради того, чтобы избежать ликвидации. Это возможность проверить, может ли фиксированная премия действительно превратить downside в заранее определённый уровень убытка.
То, что я могу реально проверить — это размер премии, которую нужно заплатить, выплата для long/short и максимальный убыток по позиции. Я также могу рассмотреть механизм, при котором депозитор получает премию за предоставление ликвидности, потому что это по сути проверка того, способна ли эта модель распределять риски между обеими сторонами, а не просто делать кредитное плечо визуально «более безопасным».
Я пока не знаю, как система будет работать при сильной волатильности и в реальной ликвидности, а не в контролируемой среде. Вопрос в том, даёт ли теоретически ограниченный downside действительно более качественный опыт управления рисками, когда рынок начинает сильно «качать».
Я наблюдаю, выбирают ли пользователи на практике вариант с выплатой премии в обмен на чётко определённый максимальный убыток. $DOS $ACE $HEMI #CryptoRally #FOMCWatch
#binancep2pantoan @Binance Vietnam Когда сделки P2P длятся достаточно долго с одним и тем же человеком, привычность иногда заставляет нас терять бдительность.
Сначала это были всего несколько Order, потом 5 Order, 10 Order… Всё складывалось удачно: оплата проходила быстро, общение не вызывало трудностей и никогда не случались проблемы. Так постепенно первоначальная настороженность уступила место чувству спокойствия. А затем однажды Merchant предложил: «В следующий раз давай обсудим через Telegram или Zalo — там я смогу дать тебе цену гораздо лучше».
Честно говоря, я понимаю, почему многие так легко соглашаются. Я уже провёл достаточно много сделок: раньше всё было нормально, и на этот раз цена выглядит выгоднее. Но я всегда напоминаю себе: доверять человеку — одно, а обеспечивать безопасность текущей сделки — совсем другое.
В каждом Binance P2P Order есть информация об Order, способ оплаты, Order ID, Order Chat, история, Appeal и Escrow. Когда сделку выносят за пределы платформы, вместе с Order исчезает и защитный слой. Знакомство иногда заставляет нас нарушать правила: перейти в Zalo или Telegram, пропустить проверку, даже сделать Release раньше — просто потому, что раньше проблем не было. Поэтому, хотя Merchant совершал со мной довольно много сделок, я всё равно придерживаюсь своего принципа: сделка всегда должна оставаться внутри Order, а каждый платёж нужно проверять заново.
Хорошая история не означает, что текущую сделку не нужно проверять.
Когда я продаю, я верю только реальному балансу в банковском приложении перед тем, как делать Release. Никаких Zalo, Telegram или скриншотов.
Я доверяю истории, но не ослабляю внимание к текущей сделке. Потому что в P2P проблемы иногда возникают не из-за подозрений, а из-за того, что мы теряем бдительность. $DOS $ACE #TheoDõiFOMC
Я обычно хочу понимать, как устроена сеть, прежде чем думать о токенах или экосистеме. В Dusk Network первым, что действительно привлекло моё внимание, стала довольно чётко определённая архитектура, ориентированная на приватность в финансовых приложениях.
Сначала я воспринимал «приватный блокчейн» Dusk довольно упрощённо. Мне казалось, что главное — просто не раскрывать данные транзакций, но чем больше я читал материалы, тем яснее видел, что всё намного шире: от конфиденциальных смарт-контрактов до стандарта Confidential Security Contract (XSC).
Осознание этого заставило меня взглянуть на Dusk по-другому.
Для меня важный вопрос заключается не только в том, «насколько блокчейн может защитить данные?», но в том, как создавать финансовые приложения, которые могут скрывать часть информации, при этом система за кулисами всё равно исполняет необходимые правила.
Я думаю, что именно это — центральная задача, к которой Dusk стремится в роли Layer-1.
Мне хочется глубже разобраться в том, как XSC решает многоуровневые финансовые задачи. Какие данные разрешено видеть только некоторым участникам, какие всё ещё нужно доказывать всем, и как будет обработана граница между этими сторонами?
#termmax @TermMax Я вернулся к документации TermMax ещё раз — на этот раз с фокусом на то, как именно “fixed-rate” реально меняет заимствования и lending в DeFi.
Сначала меня привлекла сама возможность брать или выдавать средства по ставке, которая заранее зафиксирована. Но чем глубже я копал, тем больше меня затягивало понимание того, что происходит “за кулисами” этого механизма.
Я начал задаваться вопросом, как TermMax удерживает ставку достаточно стабильной, когда рынок постоянно меняется. Если ликвидность внезапно дробится, как это повлияет на позиции? И когда в системе присутствуют options, то как протокол предотвращает наложение рисков друг на друга?
Затем я переключился на изучение governance под другим углом.
Протокол может быть децентрализован на уровне технологий, но фактические полномочия принятия решений всё равно могут быть сосредоточены в очень небольшой группе. У меня пока недостаточно данных, чтобы определить, как TermMax распределяет власть, поэтому для меня этот момент остаётся большим вопросом.
Я также хочу более пристально посмотреть на слой security. Смарт-контракты могут содержать ошибки, но это ещё не вся история. Давление со стороны рынка, оракулов, ликвидности и ликвидаций — каждый фактор может порождать свой отдельный тип риска.
Чем больше я читаю, тем меньше мне кажется, что TermMax — это просто “fixed-rate DeFi”. Я начинаю всё больше интересоваться тем, насколько блокчейн способен обеспечивать стабильность и предсказуемость для финансовых продуктов.
Раньше при каждой сделке с этим покупателем всё проходило без проблем, поэтому сегодня утром я был более невнимателен, чем обычно. До тех пор, пока я не проверил полученные средства: оказалось, что деньги пришли из совершенно другого банка, не как раньше. Новый счёт, хотя имя отправителя по-прежнему совпадает, но они никак не предупредили меня заранее.
Я остановился и прямо в чате задал вопрос, прежде чем продолжить. Оказалось, всё довольно просто: у них появился ещё один банковский счёт, и иногда они используют именно его. Но если бы я не спросил, я легко упустил бы эту деталь, просто потому что уже привык к сделкам с ними.
Тогда я только понял: знать человека в лицо не значит, что личность подтверждена.
Как и всегда, я сам открыл банковское приложение, чтобы подтвердить поступление средств, а не полагался на скриншоты, даже если это покупатель, который уже много раз совершал сделки. Возможно, они никогда не подделывали доказательства. Но для меня сделка не может строиться на двух словах: «может быть».
Успешная история сделок слишком легко усыпляет бдительность, в то время как те самые первоначальные проверки на самом деле не предназначены для того, чтобы внушить доверие, а чтобы сохранить следы сделки на случай необходимости. Поэтому после каждой сделки, как обычно, я сохраняю Order ID и весь отрывок чата. $EDEN $ACE $KII #VIXFallsTo2026Low #DollarHits3MonthLow
@Dusk $DUSK #dusk Весь день я снова и снова сталкивался с STOX, когда просматривал @Dusk ; теперь у него новое название — @Dusk Trade. Есть один момент в этом проекте, который заставляет меня задержаться: Dusk Trade объявил(а) план приблизить частный рынок к SME к 15/8
Ставки (Staking): Более 30% от общего объёма токенов сейчас находятся в staking, при этом APR колеблется около 27%.
Доступ: Механизм selective disclosure позволяет подтверждать место проживания или соответствие требованиям, не раскрывая личность. Подход к privacy довольно интересный, но на данный момент участие всё ещё ограничено некоторыми партнёрами и определёнными группами активов.
#dusk Trade: Пользователи пока могут только подать заявку в ожидание; платформа ещё не открыта для всех.
Этот момент показался мне довольно любопытным.
Privacy может и не требовать посредников, но участие в рынке всё равно должно пройти этап отбора.
Я попробовал(а) поставить немного, чтобы проверить. Но размещение токенов не означает, что можно будет торговать. Одна сторона связана с privacy, а другая — с eligibility. Я не слишком переживаю из‑за акцента на ZK здесь. То, что мне важно знать: кто получит места на раннем этапе участия и какие требования им нужно выполнить.
Кто‑нибудь уже получил доступ после того, как попал в waitlist?
Если выбирать только одно, где, по-вашему, $DUSK Trade должен(а) сильнее всего «вырваться» вперёд: охват пользователей, уровень безопасности, количество активов или барьеры участия? #CryptoRally #FOMCWatch
#termmax @TermMax Прежде чем глубоко разобраться в этом вопросе, я всегда считал, что TGE — это самое важное время для оценки токена.
В то время я еще не проверил, был ли у протокола уже продукт и реальная активность до появления токена.
Поэтому я решил тщательно изучить $TMX, прежде чем наступит дата TGE — 25/08/2026.
Результат оказался более неоднозначным, чем я ожидал.
Есть один момент, который совпал с тем, что я думал: первоначальная оценка TMX будет в значительной степени зависеть от листинга и нарратива на TGE.
Но что меня удивило — это то, что TermMax построил протокол еще до появления токена. Инфраструктура с фиксированной ставкой, развертывание в нескольких сетях и крупные интеграции DeFi — все это уже было готово до TGE.
Вместо того чтобы TGE был тем моментом, когда проект начинает создавать ценность, данные показывают, что у TermMax уже была тяга: более $90 млн TVL по цифрам команды, более 1,5 млн зарегистрированных кошельков и более 90K DAU.
Проблема не в TGE.
В том, сможет ли TMX превратить реальную активность протокола в устойчивую полезность и захват комиссий.
С технической точки зрения у TMX фиксированное общее предложение в 1 миллиард токенов, первоначальная циркуляция около 20%, а у команды и инвесторов есть 12-месячный клифф. Полезность связана с управлением, стейкингом и комиссиями протокола.
Если пользователи приходят только чтобы фармить XP, AP, MP до TGE и затем уходят, TVL и активность могут снизиться.
Но если пользователи продолжат использовать продукты с фиксированной ставкой, генерация комиссий и удержание могут стать основой долгосрочной ценности TMX.
Это полностью меняет то, как нам следует смотреть на TGE TermMax.
С оглядыванием назад я понял, что подошел к этому вопросу, исходя из предположения, что токеномика и TGE — это центр, вместо того чтобы сначала проверить данные.
Процесс исследования не заставил меня думать, что «все хорошо» или что «все неправильно»
Он лишь заставил меня понять, что проблема более неоднозначна, чем я себе представлял
Поэтому изменилась и моя перспектива по TMX
Я все еще хочу увидеть, как TermMax докажет генерацию комиссий и удержание пользователей после TGE $ACE $GPS $PORTAL
#binancep2pantoan Прежде чем внимательно разобраться в этой проблеме, я всегда думал, что если у контрагента хорошая скорость завершения сделок и надежная торговая история, то мне будет спокойнее при работе с P2P-заявкой.
В то время я по-настоящему не проверял сумму, которую получал, прежде чем выпускать средства при небольшом расхождении. Поэтому я решил проверить совсем базовую вещь: соответствует ли сумма, фактически поступившая на счет, сумме, указанной в заявке.
Результат оказался более неоднозначным, чем я ожидал.
Есть один момент, который совпал с моими прежними мыслями: показатель завершения сделок у контрагента и количество заявок все еще были полезны для оценки трейдера.
Но что меня удивило, так это то, что эта информация не может заменить проверку реальной суммы, которую я получил.
Проблема заключалась не в том, надежный ли покупатель или подталкивает к сделке, потому что «спешит».
Вопрос был в том, достаточно ли денег на самом деле.
Если сумма все еще была меньше, то как бы ни был надежен контрагент, я все равно не должен был выпускать средства, пока оставшаяся сумма не будет переведена полностью.
Поглядывая назад, я понял, что подошел к этому вопросу с точки зрения репутации контрагента и уведомления об оплате, вместо того чтобы сначала проверить фактическую сумму.
Возможно, мне стоило раньше проверить остаток на банковском счете, а не предполагать, что уведомление о платеже означает, что денег уже достаточно.
Это только помогло мне яснее осознать главное: если денег недостаточно — не выпускайте средства.
Я просмотрел таблицу распределения наград Dusk и условия, связанные со сжиганием токенов, — и это меня удивило. Генератор блоков получает 70% награды за каждый блок напрямую, плюс к этому еще до 10%, которые привязаны к некоему показателю под названием certificate credits. Любая часть этих дополнительных 10%, которая не была востребована, будет сожжена вместо того, чтобы быть перераспределенной.
В документах никогда по-настоящему не определяется, что именно считается credit. Я несколько раз проверял, думая, что, возможно, упустил связанную страницу, но этот раздел просто указывает и идет дальше.
Этот пробел заставляет меня уделять этому больше внимания, чем, вероятно, следовало бы. Механизм сжигания, привязанный к некоему показателю участия, не определенному в явном виде, отличается от механизмов сжигания по расписанию или запускаемых администрацией, о которых обычно говорят большинство проектов. Остальная часть распределения довольно простая. 10% — на фонд разработки, 5% — на валидацию, 5% — на ратификацию.
Эмиссия работает по расписанию со снижением в течение 36 лет: каждый четыре года — вдвое меньше, и ограничена 500 миллионами новых DUSK из первоначально выпущенных 500 миллионов в обращение. По сравнению с этой кривой любое количество, сжигаемое на каждый блок, выглядит незначительным.
#binancep2pantoan @Binance Vietnam Прежде чем внимательно в это вникнуть, я всегда думал, что Binance P2P в основном защищён эскроу: криптовалюта заблокирована, обе стороны совершают сделку, и в случае проблем есть Апелляция.
Тогда я ещё не проверял, что именно происходит, когда сделка попадает в спор. Я решил вернуться и выяснить, что на самом деле делает P2P-сделку безопасной.
Результат оказался не таким простым, как я когда-то думал.
Эскроу действительно является важным уровнем защиты. Но что меня удивило — эскроу не может рассказать полную историю о том, что на самом деле произошло между двумя людьми.
Когда возникает разногласие, вопрос перестаёт быть чисто техническим. Он превращается в вопрос истины и доказательств.
Вместо того чтобы рассматривать P2P только как площадку с эскроу, я стал видеть в этом систему координации.
Проблема не только в том, сколько у Binance слоёв защиты, но и в том, остаются ли пользователи внутри этих слоёв.
Если они выходят из внутреннего чата, переходят в Telegram или Zalo, доверяют скриншоту вместо того, чтобы проверить данные банковского счёта, или торопятся выпустить средства, пользователи сами выходят за пределы инфраструктуры, созданной для того, чтобы защищать их.
Вспоминая назад, я понял, что думал «Эскроу = безопасность», вместо того чтобы смотреть на весь процесс целиком.
Безопасность в P2P — это сочетание технологии, доказательств, процесса и дисциплины пользователя.
Хорошая инфраструктура — это не то, что делает каждую транзакцию простой.
Есть одна вещь, к которой я снова и снова возвращаюсь, изучая @Dusk : нужно ли на самом деле идти на компромисс между соответствием требованиям и приватностью, и большая часть логики проектирования заключается в том, как Citadel 2 разделяет «доказательство того, что было выполнено проверка» и «раскрытие личности за этим». Процесс начинается с того, что License Provider проверяет пользователя вне цепочки и подписывает необходимые атрибуты. Затем пользователь создает доказательство с нулевым разглашением, чтобы подтвердить, что он владеет действующей лицензией, которая была подписана и зарегистрирована в блокчейне — это та часть, которая мне кажется наиболее интересной.
Доказательство происходит с помощью криптографии, не раскрывая ключ кошелька, атрибуты или конкретную лицензию — и именно здесь вопрос приватности действительно проходит проверку. Политика сервиса всегда присутствует на заднем плане, ожидая, пока Service Provider решит, каким провайдерам доверять, какие атрибуты принимаются и действительна ли сессия. Наконец, контракт лишь подтверждает, что доказательство действительно, и фиксирует публичную сессию. В цепочке все, что остается, — это доказательства того, что была использована действительная учетная запись (credential).
Чего я пока не знаю, так это то, как этот механизм будет работать, когда политика изменится, когда провайдер выпустит некорректную учетную запись или когда старая сессия все еще действительна вместо идеальных условий. Вопрос в том, действительно ли криптография устраняет необходимость раскрывать личность в управлении доступом или просто переносит доверие на выпускающего и на интерпретацию выданного credential. Я слежу за тем, как #dusk $DUSK проводит границу между криптографическим доказательством и политикой сервиса, когда регулируемые финансы реально начинают это использовать. $AIO $KII #LMECopperStocksFall42DaysLongestSince2014 #SP500TopsRecord7800 #USToPressNationsToPickUSOrChinaAICoalition #SP500EarningsBeatExpectations
#binancep2pantoan @Binance Vietnam Прежде чем копнуть глубже в эту проблему, я всегда думал, что P2P-торговля в основном сводится к поиску надежного продавца с бейджем, высокой долей завершения и большим числом заказов — это делает сделку относительно безопасной.
В то время я по-настоящему не проверял, достаточно ли таких признаков, чтобы подтвердить, что транзакция безопасна.
Поэтому я решил вернуться и выяснить, какое доказательство на самом деле следует считать безопасным при P2P-торговле.
Результат оказался более неоднозначным, чем я ожидал.
Есть один момент, который совпал с тем, что я думал: бейдж, высокая доля завершения и торговая история по-прежнему являются полезными сигналами.
Но меня удивило другое: они не могут заменить личную проверку того, что деньги действительно поступили на счет.
Проблема заключается не в том, есть ли у продавца бейдж, а в разрыве между «верой в то, что деньги уже пришли» и тем, когда деньги фактически появляются.
Скриншот — это всего лишь изображение, которое было отправлено. Он не доказывает, что деньги действительно поступили на счет.
Если покупатель выпускает криптовалюту, не проверив все для себя, этот разрыв может стать очень дорогим уроком.
Если оглянуться назад, я понял, что подошел к этой проблеме, опираясь на репутацию и показатели мерчанта, вместо того чтобы проверить все реальными доказательствами.
Процесс исследования не заставил меня думать, что каждый мерчант недоверенный.
Он просто помог мне яснее понять одну вещь: не доверяйте тому, что вы лично не проверили.
Поэтому моя позиция по P2P тоже изменилась.
Бейдж может быть сигналом. Скриншот может быть информацией. Но доказательством это становится только тогда, когда деньги реально поступают на счет.