Binance Square
wz爱喝牛奶
760 Публикации

wz爱喝牛奶

Открытая сделка
Трейдер с регулярными сделками
1.2 г
21 подписок(и/а)
50 подписчиков(а)
1.1K+ понравилось
Посты
Портфель
·
--
См. перевод
我看 TermMax V2 的 Smart Unwind 时,第一反应是:借款都还没到期,为什么还要提前给自己设置一个“退出价格”? 后来把资金路径拆开,我才发现这里解决的其实不是还款,而是**被固定期限卡住的流动性**。 TermMax 原来的固定期限借款有个天然问题:借出去的资产可能一路锁到 maturity。V2 的 Smart Unwind 则允许借款人在开仓时设置目标 APR 或价格条件,条件满足后,新的借款人或套利者可以接手原来的仓位,资金重新回到借贷池。 > 固定期限没有被取消,只是协议给仓位增加了一扇提前换手的门。 站在借款人角度,这个设计很有意思。 我原本锁了一笔固定融资。 如果市场后来按我的预期变化,继续抱着这笔仓位反而可能浪费机会。 Smart Unwind 让我提前设一个退出条件,达标就让别人接手。 我拿到预期收益,新的参与者拿到他认为还有价值的仓位,原本被锁住的资金也重新进入市场。 但代价同样明显。 你设置的退出条件不是保证成交。 市场没有人愿意接,你还是得继续扛到下一步。 所以 TermMax 真正解决的不是“固定期限太死”,而是让**固定期限里的仓位也有机会重新定价、重新换手**。 我觉得这才是 V2 真正有意思的地方。 你会愿意为了提前锁定一个退出目标,把自己的仓位交给市场重新接手,还是宁愿拿着固定融资一直到期,少折腾但也少一次主动退出的机会?@termmax #termmax
我看 TermMax V2 的 Smart Unwind 时,第一反应是:借款都还没到期,为什么还要提前给自己设置一个“退出价格”?

后来把资金路径拆开,我才发现这里解决的其实不是还款,而是**被固定期限卡住的流动性**。

TermMax 原来的固定期限借款有个天然问题:借出去的资产可能一路锁到 maturity。V2 的 Smart Unwind 则允许借款人在开仓时设置目标 APR 或价格条件,条件满足后,新的借款人或套利者可以接手原来的仓位,资金重新回到借贷池。

> 固定期限没有被取消,只是协议给仓位增加了一扇提前换手的门。

站在借款人角度,这个设计很有意思。

我原本锁了一笔固定融资。

如果市场后来按我的预期变化,继续抱着这笔仓位反而可能浪费机会。

Smart Unwind 让我提前设一个退出条件,达标就让别人接手。

我拿到预期收益,新的参与者拿到他认为还有价值的仓位,原本被锁住的资金也重新进入市场。

但代价同样明显。

你设置的退出条件不是保证成交。

市场没有人愿意接,你还是得继续扛到下一步。

所以 TermMax 真正解决的不是“固定期限太死”,而是让**固定期限里的仓位也有机会重新定价、重新换手**。

我觉得这才是 V2 真正有意思的地方。

你会愿意为了提前锁定一个退出目标,把自己的仓位交给市场重新接手,还是宁愿拿着固定融资一直到期,少折腾但也少一次主动退出的机会?@TermMax

#termmax
Я недавно смотрел рабочий процесс Dusk на финансовых рынках, и по-настоящему насторожило меня одно довольно традиционное, но после ончейн‑размещения вдруг более сложное обстоятельство: **Ценные бумаги уже переведены вам, но деньги ещё не дошли до продавца — что делать?** Обычные ончейн‑сделки легко заставляют воспринимать «передачу актива» и «платёж» как две независимые транзакции。 Но финансовые рынки так не работают。 Официальная рыночная инфраструктура Dusk строит дизайн так, что в одном и том же вопросе клиринга рассматриваются asset leg и payment leg:подчёркивается, что регулируемые сделки по активам должны предсказуемо координировать обе «ноги», а не позволять одной стороне завершить всё первой, а другой постепенно «догонять»。 > Я думаю, что здесь по-настоящему важно не то, что расчёт происходит быстрее, а то, чтобы стороны сделки не оказались по очереди в разнице по времени, когда другая сторона может не исполнить обязательства. С позиции продавца, конечно, хочется, чтобы в момент, когда актив уже ушёл, платёж был тоже заранее определён。 Покупатель думает так же。 Никто не хочет сначала передать своё, а потом молиться, чтобы деньги другой стороны пришли вовремя。 Именно в этом смысл логики расчётов типа DvP: активная «нога» и платёжная «нога» должны рассматриваться вместе。 Но цена этого очевидна。 Нельзя просто оптимизировать одну из двух переводных операций — нужно одновременно обрабатывать актив, платёж, квалификацию участников и итоговый статус окончательного расчёта。 Процесс становится сложнее。 И правил тоже больше。 Однако для ценных бумаг, фондов или других реальных финансовых активов я, наоборот, думаю, что такая сложность никуда не денется。 Потому что самое проблемное в традиционных финансах — дело никогда не в том, **как именно передаются активы**, а в том: **кто передаёт первым, кто платит первым и когда обе стороны считаются по-настоящему завершившими сделку.** Если вы институциональный трейдер, вы согласитесь добавить ещё один набор правил клиринга, чтобы обе стороны завершили поставку одновременно;или предпочитаете сохранить простоту обычного ончейн‑подхода, где актив и платёж обрабатываются каждый по-своему?@Dusk_Foundation #dusk $DUSK
Я недавно смотрел рабочий процесс Dusk на финансовых рынках, и по-настоящему насторожило меня одно довольно традиционное, но после ончейн‑размещения вдруг более сложное обстоятельство:

**Ценные бумаги уже переведены вам, но деньги ещё не дошли до продавца — что делать?**

Обычные ончейн‑сделки легко заставляют воспринимать «передачу актива» и «платёж» как две независимые транзакции。

Но финансовые рынки так не работают。

Официальная рыночная инфраструктура Dusk строит дизайн так, что в одном и том же вопросе клиринга рассматриваются asset leg и payment leg:подчёркивается, что регулируемые сделки по активам должны предсказуемо координировать обе «ноги», а не позволять одной стороне завершить всё первой, а другой постепенно «догонять»。

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

С позиции продавца, конечно, хочется, чтобы в момент, когда актив уже ушёл, платёж был тоже заранее определён。

Покупатель думает так же。

Никто не хочет сначала передать своё, а потом молиться, чтобы деньги другой стороны пришли вовремя。

Именно в этом смысл логики расчётов типа DvP:

активная «нога» и платёжная «нога» должны рассматриваться вместе。

Но цена этого очевидна。

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

Процесс становится сложнее。

И правил тоже больше。

Однако для ценных бумаг, фондов или других реальных финансовых активов я, наоборот, думаю, что такая сложность никуда не денется。

Потому что самое проблемное в традиционных финансах — дело никогда не в том, **как именно передаются активы**, а в том:

**кто передаёт первым, кто платит первым и когда обе стороны считаются по-настоящему завершившими сделку.**

Если вы институциональный трейдер, вы согласитесь добавить ещё один набор правил клиринга, чтобы обе стороны завершили поставку одновременно;или предпочитаете сохранить простоту обычного ончейн‑подхода, где актив и платёж обрабатываются каждый по-своему?@Dusk

#dusk $DUSK
См. перевод
我最近看 TermMax 的到期机制时,反而卡在一个很现实的问题上:既然借款利率和期限都提前定死了,为什么协议还要给借款人设计 Roll 的出口? 按固定期限借款的直觉,到了 maturity 就还钱,事情结束。 可现实里最麻烦的恰恰是这一天。 本金可能还在抵押资产里。 仓位也没有坏。 只是你手上的现金,刚好没准备好。 TermMax 的固定期限设计天然存在这个“到期悬崖”:借款人到期要么一次性偿还,要么寻找新的融资来源。官方和 Morpho 的集成方案,就是把再融资这条路提前接进来,让借款人在接近到期时可以退出原来的固定利率头寸,再寻找新的资金来源。 > 我觉得这里真正需要管理的,不是利率,而是“时间到了以后,谁来给本金续命”。 这对借款人很重要。 因为固定利率给了你可预测的成本,却没有自动保证你到期那一天刚好有足够现金。 所以 TermMax 这里出现了一个很有意思的取舍: 固定期限让融资计划更清楚。 但期限越明确,到期日也越像一道硬门槛。 提前准备好再融资,仓位可以继续运转。 没准备好,就可能被迫退出原来的融资结构。 我现在反而觉得,固定利率真正难的部分不是“锁住利率”,而是**怎么安全地走出这笔期限交易**。 如果你是借款人,你更愿意接受一个利率稍高、但可以灵活续上的融资方案,还是宁愿锁住更低的固定成本,自己承担到期前找下一笔钱的压力?@termmax #termmax
我最近看 TermMax 的到期机制时,反而卡在一个很现实的问题上:既然借款利率和期限都提前定死了,为什么协议还要给借款人设计 Roll 的出口?

按固定期限借款的直觉,到了 maturity 就还钱,事情结束。

可现实里最麻烦的恰恰是这一天。

本金可能还在抵押资产里。

仓位也没有坏。

只是你手上的现金,刚好没准备好。

TermMax 的固定期限设计天然存在这个“到期悬崖”:借款人到期要么一次性偿还,要么寻找新的融资来源。官方和 Morpho 的集成方案,就是把再融资这条路提前接进来,让借款人在接近到期时可以退出原来的固定利率头寸,再寻找新的资金来源。

> 我觉得这里真正需要管理的,不是利率,而是“时间到了以后,谁来给本金续命”。

这对借款人很重要。

因为固定利率给了你可预测的成本,却没有自动保证你到期那一天刚好有足够现金。

所以 TermMax 这里出现了一个很有意思的取舍:

固定期限让融资计划更清楚。

但期限越明确,到期日也越像一道硬门槛。

提前准备好再融资,仓位可以继续运转。

没准备好,就可能被迫退出原来的融资结构。

我现在反而觉得,固定利率真正难的部分不是“锁住利率”,而是**怎么安全地走出这笔期限交易**。

如果你是借款人,你更愿意接受一个利率稍高、但可以灵活续上的融资方案,还是宁愿锁住更低的固定成本,自己承担到期前找下一笔钱的压力?@TermMax

#termmax
См. перевод
我最近看 Dusk 的受监管资产设计时,真正让我停下来的是一个很小的区别:为什么“这个钱包能签交易”,还不能直接等于“这个钱包有资格买这项资产”? 普通代币逻辑很简单。 有余额。 有签名。 交易就走。 但如果换成证券类资产,这套逻辑马上不够用了。Dusk 当前文档把 eligibility、身份、wallet binding 和 access control 单独放进资产工作流里。也就是说,链上要判断的不只是“谁在发起交易”,还包括“这个参与者是否符合这项资产的持有条件”。 > 我觉得这里真正被拆开的,是“控制钱包”和“拥有资格”这两件事。 站在投资者角度,这意味着一个地址即使掌握私钥,也不代表它天然可以接收所有受监管资产。 站在发行方角度,这反而是必要的。 因为证券上链以后,最怕的不是没人交易,而是资产被转给一个本来就不应该进入这个市场的地址。 Dusk 的 Citadel 作为身份与访问层,就是在处理这条边界,让资格和链上账户之间建立关系,同时又支持只披露必要的信息,而不是把整套身份资料摊在公网上。 代价也很明显。 普通代币只要钱包和签名没问题就能转。 受监管资产却多了一层资格判断。 体验没那么“无脑”。 但这恰恰可能是金融资产真正上链后逃不开的一笔账: **开放的地址,不等于开放的资产资格。** 如果你是资产发行方,你会接受多一层身份和资格限制,换取资产真正进入合规市场;还是宁愿保持普通代币那种“谁有钱包,谁就能接”的简单规则?@Dusk_Foundation #dusk $DUSK
我最近看 Dusk 的受监管资产设计时,真正让我停下来的是一个很小的区别:为什么“这个钱包能签交易”,还不能直接等于“这个钱包有资格买这项资产”?

普通代币逻辑很简单。

有余额。

有签名。

交易就走。

但如果换成证券类资产,这套逻辑马上不够用了。Dusk 当前文档把 eligibility、身份、wallet binding 和 access control 单独放进资产工作流里。也就是说,链上要判断的不只是“谁在发起交易”,还包括“这个参与者是否符合这项资产的持有条件”。

> 我觉得这里真正被拆开的,是“控制钱包”和“拥有资格”这两件事。

站在投资者角度,这意味着一个地址即使掌握私钥,也不代表它天然可以接收所有受监管资产。

站在发行方角度,这反而是必要的。

因为证券上链以后,最怕的不是没人交易,而是资产被转给一个本来就不应该进入这个市场的地址。

Dusk 的 Citadel 作为身份与访问层,就是在处理这条边界,让资格和链上账户之间建立关系,同时又支持只披露必要的信息,而不是把整套身份资料摊在公网上。

代价也很明显。

普通代币只要钱包和签名没问题就能转。

受监管资产却多了一层资格判断。

体验没那么“无脑”。

但这恰恰可能是金融资产真正上链后逃不开的一笔账:

**开放的地址,不等于开放的资产资格。**

如果你是资产发行方,你会接受多一层身份和资格限制,换取资产真正进入合规市场;还是宁愿保持普通代币那种“谁有钱包,谁就能接”的简单规则?@Dusk

#dusk $DUSK
См. перевод
我看到 TermMax V2 有个设计,第一反应其实挺矛盾:一个主打“固定利率”的协议,为什么还要把没借出去的钱放进 Aave、Morpho、Venus 这种浮动利率市场? 按直觉,既然都来 TermMax 了,不应该把资金老老实实锁在固定收益里吗? 我把资金路径重新拆了一遍,才发现这其实是在解决一个很现实的 LP 问题。 固定利率订单最怕什么? 不是收益低。 而是**钱挂着,没人借。** TermMax 的 Composable Base Yield 做的事情,就是让还没被匹配的资金先去底层收益协议产生基础收益,等固定利率订单真正成交,再回到 TermMax 的固定收益逻辑里。官方目前明确把 Aave、Morpho、Venus 作为这类底层收益来源。 > 我觉得这个设计真正解决的不是“收益更高”,而是把“等待成交”这段原本可能浪费掉的时间也拿来利用。 站在 LP 角度就很直观: 钱已经准备好了。 但借款人没出现。 如果只能干等,资本利用率天然被拖低。 TermMax 反过来把这段空档接到浮动收益市场上。 不过代价也很明确。 你追求固定收益,却不得不接受一部分资金在等待期间暴露于底层浮动利率和协议风险。 也就是说,TermMax 并没有消灭浮动利率,只是把它从“借款成本”挪成了“闲置资本的等待收益”。 这点我觉得比“固定利率”四个字本身有意思得多。 真正的问题变成: **一个固定收益协议,到底该不该为了提高资金利用率,主动拥抱一点浮动收益风险?** 如果你是 LP,你会宁愿让资金躺着等固定订单,还是接受底层浮动收益,换取这段等待时间也不吃空窗期?@termmax #termmax
我看到 TermMax V2 有个设计,第一反应其实挺矛盾:一个主打“固定利率”的协议,为什么还要把没借出去的钱放进 Aave、Morpho、Venus 这种浮动利率市场?

按直觉,既然都来 TermMax 了,不应该把资金老老实实锁在固定收益里吗?

我把资金路径重新拆了一遍,才发现这其实是在解决一个很现实的 LP 问题。

固定利率订单最怕什么?

不是收益低。

而是**钱挂着,没人借。**

TermMax 的 Composable Base Yield 做的事情,就是让还没被匹配的资金先去底层收益协议产生基础收益,等固定利率订单真正成交,再回到 TermMax 的固定收益逻辑里。官方目前明确把 Aave、Morpho、Venus 作为这类底层收益来源。

> 我觉得这个设计真正解决的不是“收益更高”,而是把“等待成交”这段原本可能浪费掉的时间也拿来利用。

站在 LP 角度就很直观:

钱已经准备好了。

但借款人没出现。

如果只能干等,资本利用率天然被拖低。

TermMax 反过来把这段空档接到浮动收益市场上。

不过代价也很明确。

你追求固定收益,却不得不接受一部分资金在等待期间暴露于底层浮动利率和协议风险。

也就是说,TermMax 并没有消灭浮动利率,只是把它从“借款成本”挪成了“闲置资本的等待收益”。

这点我觉得比“固定利率”四个字本身有意思得多。

真正的问题变成:

**一个固定收益协议,到底该不该为了提高资金利用率,主动拥抱一点浮动收益风险?**

如果你是 LP,你会宁愿让资金躺着等固定订单,还是接受底层浮动收益,换取这段等待时间也不吃空窗期?@TermMax

#termmax
На этот раз, разбираясь с правилами перевода активов в Dusk, я наоборот зацепился за довольно незаметный шаг: почему перед тем, как транзакция действительно отправляется, сначала нужно пройти проверку и симуляцию? Раньше, когда я смотрел ончейн-переводы, привычный порядок был такой: подпись, отправка, а потом ожидание результата. Но регулируемые активы работают иначе. Инвестор может иметь баланс, но при этом не иметь права владеть определённым видом активов; адрес может теоретически получать платежи, но текущие правила могут не разрешать ему принять именно этот актив. Официальный дизайн Dusk переносит такие проверки прав и трансферов в сам процесс: транзакцию можно проверять или симулировать до её официальной отправки. > Я думаю, что эта ступень по-настоящему решает не просто проблему фразы «транзакция не удалась», а то, чтобы ошибочные действия не успели стать фактом прямо в блокчейне. Если смотреть с позиции эмитента или площадки, разница получается очень существенной. Традиционная логика в ончейне больше похожа на: сначала отправить; если не получилось — потом разбираться. А Dusk хочет сделать иначе: сначала определить; если не соответствует правилам — по возможности остановить до отправки. Конечно, это добавляет дополнительный слой логики проверок, и передача активов уже не будет зависеть только от баланса и подписи, как у обычных токенов. Но взамен вы переносите множество комплаенс-проверок, которые раньше приходилось исправлять вручную силами бэк-офиса, прямо в ончейн-процесс. Именно это, как мне кажется, и делает Dusk действительно интересным. Это не просто «перенести ценные бумаги в блокчейн», а попытаться сделать саму логику «кто может переводить, кто может получать и в каких случаях нужно отказать» частью правил работы актива. Если вы эмитент, вы бы скорее согласились на дополнительную предварительную проверку, или предпочли бы сохранить простую схему как у обычных токенов: сначала перевести, а потом обрабатывать исключения?@Dusk_Foundation #dusk $DUSK
На этот раз, разбираясь с правилами перевода активов в Dusk, я наоборот зацепился за довольно незаметный шаг: почему перед тем, как транзакция действительно отправляется, сначала нужно пройти проверку и симуляцию?

Раньше, когда я смотрел ончейн-переводы, привычный порядок был такой: подпись, отправка, а потом ожидание результата.

Но регулируемые активы работают иначе.

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

> Я думаю, что эта ступень по-настоящему решает не просто проблему фразы «транзакция не удалась», а то, чтобы ошибочные действия не успели стать фактом прямо в блокчейне.

Если смотреть с позиции эмитента или площадки, разница получается очень существенной.

Традиционная логика в ончейне больше похожа на:

сначала отправить;

если не получилось — потом разбираться.

А Dusk хочет сделать иначе:

сначала определить;

если не соответствует правилам — по возможности остановить до отправки.

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

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

Именно это, как мне кажется, и делает Dusk действительно интересным.

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

Если вы эмитент, вы бы скорее согласились на дополнительную предварительную проверку, или предпочли бы сохранить простую схему как у обычных токенов: сначала перевести, а потом обрабатывать исключения?@Dusk

#dusk $DUSK
Я в этот раз изучал Atomic Order у TermMax V2, и первая реакция была, честно говоря, немного неприятной: почему одна и та же сумма USDC может одновременно быть размещена на нескольких рынках? Похоже, будто бы ликвидность «просто из воздуха» увеличивают. Если продолжить разбор механики, ключевой момент как раз не в том, что это «появляется одновременно», а в том, **как это исчезает после совершения сделки**. Atomic Order у TermMax позволяет одной и той же порции ликвидности одновременно обслуживать несколько рынков. Допустим, у одного Vault есть некая сумма капитала — она может одновременно фигурировать в разных рынках кредитования, но фактически эту сумму можно исполнить (продать/забрать) только один раз. Какой-то рынок сначала забирает часть средств — соответствующие лимиты на остальных рынках в рамках той же транзакции синхронно снимаются. Официально эта логика оформлена как атомарная операция. > Реальная ценность не в том, что деньги «выглядят больше», а в том, что протокол позволяет нескольким рынкам разделять одну и ту же сумму, но при этом не допускает, чтобы её можно было потратить повторно. С точки зрения заемщика это решает проблему крупных ордеров. Раньше ликвидность дробилась между разными рынками, и большие заявки легко упирались в ситуацию, когда на каком-то одном рынке глубины не хватает. Теперь протокол может сначала подложить доступную ликвидность сразу с нескольких рынков под одну и ту же логику исполнения, а уже одной сделкой определить, какие именно средства в итоге получит тот или иной рынок. Но цена тоже вполне конкретная. То, что пользователь видит в бухгалтерских цифрах как «ликвидность», не означает, что каждый рынок располагает отдельной независимой суммой. Вы видите глубину — по сути это **конкурентные лимиты из общего пула**. Это означает, что атомарная синхронизация протокола должна быть действительно надежной. Иначе «совместное использование несколькими рынками» — это не эффективность капитала, а фальшивая ликвидность. Я думаю, это одно из тех решений TermMax V2, которые легко упустить: протокол не просто добавляет деньги, он заново определяет, кому принадлежит рыночная глубина. Если вы крупный заемщик, что вам выгоднее — иметь стакан, который выглядит глубже, но где средства разделяются, или рынок с меньшей глубиной, но где у каждого рынка капитал полностью независимый? @termmax #termmax
Я в этот раз изучал Atomic Order у TermMax V2, и первая реакция была, честно говоря, немного неприятной: почему одна и та же сумма USDC может одновременно быть размещена на нескольких рынках? Похоже, будто бы ликвидность «просто из воздуха» увеличивают.

Если продолжить разбор механики, ключевой момент как раз не в том, что это «появляется одновременно», а в том, **как это исчезает после совершения сделки**.

Atomic Order у TermMax позволяет одной и той же порции ликвидности одновременно обслуживать несколько рынков. Допустим, у одного Vault есть некая сумма капитала — она может одновременно фигурировать в разных рынках кредитования, но фактически эту сумму можно исполнить (продать/забрать) только один раз. Какой-то рынок сначала забирает часть средств — соответствующие лимиты на остальных рынках в рамках той же транзакции синхронно снимаются. Официально эта логика оформлена как атомарная операция.

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

С точки зрения заемщика это решает проблему крупных ордеров.

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

Но цена тоже вполне конкретная.

То, что пользователь видит в бухгалтерских цифрах как «ликвидность», не означает, что каждый рынок располагает отдельной независимой суммой. Вы видите глубину — по сути это **конкурентные лимиты из общего пула**.

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

Иначе «совместное использование несколькими рынками» — это не эффективность капитала, а фальшивая ликвидность.

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

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

#termmax
См. перевод
我这次看 Dusk 的交易生命周期时,真正让我停下来的,是它没有把“确认”和“最终完成”当成一回事。 官方文档把一笔交易拆得很清楚:先从 mempool 移除,再进入 confirmed,最后 block 达到 finality,交易才变成不可逆的最终状态。 乍看像是多做了一层状态。 但站在金融资产结算的人角度,这个区别其实很要命。 普通转账里,看到 confirmed,很多人可能就继续下一步了。 但证券、支付或者资产交割不一样。 你真正需要确认的不是: “这笔交易大概率没问题。” 而是: “这笔资产现在到底能不能当成最终结果记账?” > 对金融市场来说,“大概率不会回滚”和“已经不可逆”不是一回事。 Dusk 的设计把这两个阶段拆开,就是把“先看到结果”和“结果已经锁死”分开处理。 这会带来一个很现实的成本。 等待 finality,意味着应用不能只盯着第一条确认状态就立刻把后续流程全部推进。 但换来的,是更明确的结算边界。 对于普通链上转账,这点差异可能没那么刺眼。 对于代币化证券、支付腿和资产腿同时推进的交易,结算边界一旦模糊,后面的交割、记录和权限判断都会跟着乱。 所以我现在越来越觉得,Dusk强调 deterministic settlement,不只是为了“快”。 它更在乎: **什么时候可以真正把这笔交易从“发生了”变成“已经定了”。** 如果你是金融机构的后台,你会更在意几乎立刻看到成交,还是宁愿多等一个明确的 finality,再把整笔资产正式记入账?@Dusk_Foundation #dusk $DUSK
我这次看 Dusk 的交易生命周期时,真正让我停下来的,是它没有把“确认”和“最终完成”当成一回事。

官方文档把一笔交易拆得很清楚:先从 mempool 移除,再进入 confirmed,最后 block 达到 finality,交易才变成不可逆的最终状态。

乍看像是多做了一层状态。

但站在金融资产结算的人角度,这个区别其实很要命。

普通转账里,看到 confirmed,很多人可能就继续下一步了。

但证券、支付或者资产交割不一样。

你真正需要确认的不是:

“这笔交易大概率没问题。”

而是:

“这笔资产现在到底能不能当成最终结果记账?”

> 对金融市场来说,“大概率不会回滚”和“已经不可逆”不是一回事。

Dusk 的设计把这两个阶段拆开,就是把“先看到结果”和“结果已经锁死”分开处理。

这会带来一个很现实的成本。

等待 finality,意味着应用不能只盯着第一条确认状态就立刻把后续流程全部推进。

但换来的,是更明确的结算边界。

对于普通链上转账,这点差异可能没那么刺眼。

对于代币化证券、支付腿和资产腿同时推进的交易,结算边界一旦模糊,后面的交割、记录和权限判断都会跟着乱。

所以我现在越来越觉得,Dusk强调 deterministic settlement,不只是为了“快”。

它更在乎:

**什么时候可以真正把这笔交易从“发生了”变成“已经定了”。**

如果你是金融机构的后台,你会更在意几乎立刻看到成交,还是宁愿多等一个明确的 finality,再把整笔资产正式记入账?@Dusk

#dusk $DUSK
В эти пару дней, когда я изучал дизайн Vault у TermMax, меня, наоборот, привлекло одно решение, которое выглядит довольно «антиистиннопользовательским»: если рынок с фиксированной ставкой уже четко расписал доходность и сроки, зачем всё равно заставлять пользователей отдавать деньги Curator? По моему пониманию, самый интуитивный сценарий должен быть таким: самому выбрать рынок, самому посмотреть сроки, самому купить FT и просто дождаться погашения. Но Vault TermMax V2 пошёл по другому пути: пользователь кладёт активы, а затем капитал передается Curator, который распределяет средства по нескольким рынкам фиксированных сроков кредитования в соответствии со стратегией. Сейчас официально также задан лимит по ёмкости Vault, чтобы один конкретный рынок не мог бесконечно «высасывать» деньги. > По сути, это продажа части права «я сам решаю», в обмен на более низкую операционную стоимость. С точки зрения вкладчика я делаю гораздо меньше отборов. Не нужно каждый день следить за разными датами погашения. Не нужно самому сравнивать несколько фиксированных ставок. И не нужно каждый раз при изменениях на рынке заново перекладывать портфель. Но цена при этом тоже очевидна: Твоё право принимать решения передают вовне. Если Curator ошибётся с рынком или сама стратегия окажется неподходящей для текущей среды по ставкам, в итоге ответственность за последствия всё равно лежит на вкладчике. Поэтому мне кажется, что TermMax Vault продаёт не «удобство», а именно **профессионализацию этой неприятной работы — выбора рынка**. И вот в этом — главное отличие от традиционного DeFi. Раньше: деньги отдаёшь протоколу, а стратегия делает всё сама. Теперь: деньги отдаёшь Vault, а стратегию делает Curator. А то, что TermMax по-настоящему должен доказать, сводится к другому вопросу: сможет ли доход, который создаёт Curator, в долгосрочной перспективе перекрыть ту часть риска, которую пользователь принимает, отказавшись от самостоятельного принятия решений? Если бы это были вы, вам было бы приятнее самому выбирать рынки с фиксированной ставкой, или всё же хотелось бы отдать это право Curator, взамен получив более удобный вход в фиксированную доходность?@termmax #termmax
В эти пару дней, когда я изучал дизайн Vault у TermMax, меня, наоборот, привлекло одно решение, которое выглядит довольно «антиистиннопользовательским»: если рынок с фиксированной ставкой уже четко расписал доходность и сроки, зачем всё равно заставлять пользователей отдавать деньги Curator?

По моему пониманию, самый интуитивный сценарий должен быть таким: самому выбрать рынок, самому посмотреть сроки, самому купить FT и просто дождаться погашения.

Но Vault TermMax V2 пошёл по другому пути: пользователь кладёт активы, а затем капитал передается Curator, который распределяет средства по нескольким рынкам фиксированных сроков кредитования в соответствии со стратегией. Сейчас официально также задан лимит по ёмкости Vault, чтобы один конкретный рынок не мог бесконечно «высасывать» деньги.

> По сути, это продажа части права «я сам решаю», в обмен на более низкую операционную стоимость.

С точки зрения вкладчика я делаю гораздо меньше отборов.

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

Не нужно самому сравнивать несколько фиксированных ставок.

И не нужно каждый раз при изменениях на рынке заново перекладывать портфель.

Но цена при этом тоже очевидна:

Твоё право принимать решения передают вовне.

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

Поэтому мне кажется, что TermMax Vault продаёт не «удобство», а именно **профессионализацию этой неприятной работы — выбора рынка**.

И вот в этом — главное отличие от традиционного DeFi.

Раньше:

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

Теперь:

деньги отдаёшь Vault, а стратегию делает Curator.

А то, что TermMax по-настоящему должен доказать, сводится к другому вопросу:

сможет ли доход, который создаёт Curator, в долгосрочной перспективе перекрыть ту часть риска, которую пользователь принимает, отказавшись от самостоятельного принятия решений?

Если бы это были вы, вам было бы приятнее самому выбирать рынки с фиксированной ставкой, или всё же хотелось бы отдать это право Curator, взамен получив более удобный вход в фиксированную доходность?@TermMax

#termmax
На этот раз, когда я читал документацию по разработке Dusk, меня остановило не столько решение для приватности, сколько то, почему они не сделали просто EVM. Сейчас Dusk одновременно сохраняет DuskVM и DuskEVM: первая запускается напрямую в Dusk L1 и ориентирована на контракты на Rust/WASM; вторая же предоставляет Solidity, Vyper и знакомую всем EVM-экосистему инструментов. Официальный ответ разработчикам на самом деле очень прямой: эти два пути решают не одну и ту же задачу. > Похоже на дублирование, но на самом деле это обмен «удобства разработки» на «нативные возможности». Если смотреть глазами обычного EVM-разработчика, DuskEVM явно проще. Кошельки, языки, инструменты — всё более привычно, затраты на миграцию ниже, команде не нужно заново осваивать полностью незнакомый способ разработки. Но если приложению нужно напрямую работать с нативными активами Dusk, задействовать возможности приватности, логику на нулевых знаниях или же быть ближе к среде исполнения L1, тогда у DuskVM есть смысл. В официальной документации чётко разделены эти два маршрута, а не пытаются заставить все приложения идти по одному и тому же пути. И вот тут начинается проблема. Две среды исполнения означают более высокую сложность разработки и сопровождения, а инструменты экосистемы не смогут быть полностью унифицированы. Но если стремиться только к совместимости с EVM, Dusk может «запереть» свои самые особенные возможности в рамках одного универсального механизма исполнения. Сейчас всё больше кажется, что Dusk ставит не на «нужно ли совместиться с Ethereum», а на следующее: **Сможет ли Dusk сначала привести разработчиков в систему через знакомые вещи, а когда действительно понадобятся нативные возможности — сделать так, чтобы они были готовы выбрать другой путь.** Если вы разработчик, вы бы выбрали более знакомый EVM, чтобы быстрее запуститься, или ради приватности и нативных возможностей согласились бы принять стоимость обучения новой среды исполнения?@Dusk_Foundation #dusk $DUSK
На этот раз, когда я читал документацию по разработке Dusk, меня остановило не столько решение для приватности, сколько то, почему они не сделали просто EVM.

Сейчас Dusk одновременно сохраняет DuskVM и DuskEVM: первая запускается напрямую в Dusk L1 и ориентирована на контракты на Rust/WASM; вторая же предоставляет Solidity, Vyper и знакомую всем EVM-экосистему инструментов. Официальный ответ разработчикам на самом деле очень прямой: эти два пути решают не одну и ту же задачу.

> Похоже на дублирование, но на самом деле это обмен «удобства разработки» на «нативные возможности».

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

Но если приложению нужно напрямую работать с нативными активами Dusk, задействовать возможности приватности, логику на нулевых знаниях или же быть ближе к среде исполнения L1, тогда у DuskVM есть смысл.

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

И вот тут начинается проблема.

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

Но если стремиться только к совместимости с EVM, Dusk может «запереть» свои самые особенные возможности в рамках одного универсального механизма исполнения.

Сейчас всё больше кажется, что Dusk ставит не на «нужно ли совместиться с Ethereum», а на следующее:

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

Если вы разработчик, вы бы выбрали более знакомый EVM, чтобы быстрее запуститься, или ради приватности и нативных возможностей согласились бы принять стоимость обучения новой среды исполнения?@Dusk

#dusk $DUSK
См. перевод
我这次看 Dusk 节点质押时,真正停下来的不是最低质押门槛,而是它为什么要把一笔 Staking 的钥匙拆成两种:Consensus Key 负责节点参与共识,Owner Key 负责解除质押和提取资金。 乍看很麻烦。 一把钥匙不就够了吗? 但站在节点运营者的位置,这其实是在处理一个很现实的问题:**“让机器能签块”,和“让资金能被拿走”,根本不该是同一件事。** > 节点天天在线,热密钥要持续工作;质押资产却没必要跟着一起暴露。 如果共识密钥和资产控制权绑死,节点机器一旦成为攻击入口,风险就不只是“节点掉线”这么简单,资金控制权也可能被一起拖进去。 Dusk 的拆分思路很直接: Consensus Key 管运行。 Owner Key 管资产。 机器负责干活,资金控制权留给另一套权限。 这套设计当然不是白赚的。 钥匙拆开后,节点运维更复杂,备份、恢复、权限管理都要多一道流程。对于小型节点来说,这甚至可能变成新的操作负担。 但我觉得这正是基础设施和普通钱包最大的区别。 普通用户最怕记不住助记词。 节点运营者更怕的是: **一台长期在线的机器,顺手把自己的资金也变成在线资产。** 所以我现在更关注一个问题: 你会愿意为了少一道操作,把“签块权”和“提款权”绑在一起,还是宁愿多一点运维麻烦,也把机器和资金彻底隔开?@Dusk_Foundation #dusk $DUSK
我这次看 Dusk 节点质押时,真正停下来的不是最低质押门槛,而是它为什么要把一笔 Staking 的钥匙拆成两种:Consensus Key 负责节点参与共识,Owner Key 负责解除质押和提取资金。

乍看很麻烦。

一把钥匙不就够了吗?

但站在节点运营者的位置,这其实是在处理一个很现实的问题:**“让机器能签块”,和“让资金能被拿走”,根本不该是同一件事。**

> 节点天天在线,热密钥要持续工作;质押资产却没必要跟着一起暴露。

如果共识密钥和资产控制权绑死,节点机器一旦成为攻击入口,风险就不只是“节点掉线”这么简单,资金控制权也可能被一起拖进去。

Dusk 的拆分思路很直接:

Consensus Key 管运行。

Owner Key 管资产。

机器负责干活,资金控制权留给另一套权限。

这套设计当然不是白赚的。

钥匙拆开后,节点运维更复杂,备份、恢复、权限管理都要多一道流程。对于小型节点来说,这甚至可能变成新的操作负担。

但我觉得这正是基础设施和普通钱包最大的区别。

普通用户最怕记不住助记词。

节点运营者更怕的是:

**一台长期在线的机器,顺手把自己的资金也变成在线资产。**

所以我现在更关注一个问题:

你会愿意为了少一道操作,把“签块权”和“提款权”绑在一起,还是宁愿多一点运维麻烦,也把机器和资金彻底隔开?@Dusk

#dusk $DUSK
См. перевод
Dusk 的节点,不靠算力靠抵押 聊 Dusk 的人都在说隐私,但很少人看它节点怎么跑。 我查了一下,它不做 PoW,也不走普通 PoS,而是用抵押加抽签的方式选验证者。DUSK 不押进去,节点身份都没有。押进去之后,出块权靠随机,不是谁钱多谁说了算。 这背后有个挺别扭的设计:你要帮全网验证交易,但你手里跑的那些交易,很多都是加密的。也就是说,作为验证者,你得确认一批你自己也看不清完整内容的交易合法。做不到?系统用零知识证明来补,验证者只需要确认证明成立,不需要看懂全貌。 但这件事的成本,最后压在质押的人身上。节点要稳定在线,要跑 Rusk 这套虚拟机,硬件和运维不便宜。出块奖励能否覆盖,官方文档里没有写死一个保证收益,这比多数 PoS 链更冷。 有意思的是,普通用户质押 DUSK,收益不是靠“参与治理”,而是你的币被系统当成安全垫。网络越需要隐私验证,对节点的要求就越高,要求越高,愿意跑节点的人越少。那收益从哪来?早期靠通胀,长期得靠网络的手续费。手续费上不来,节点会走。 我原本以为 Dusk 节点和别的链差不多,看完机制才发现,它把隐私成本转成了验证成本,又把这成本转给了质押者。 所以问题来了:你愿意拿着 DUSK 去质押,赚一份说不清的收益,同时替全网隐私交易扛成本吗? 还是说,宁可拿着币什么都不干,也不让自己成为那个“不知道在验什么却要负责”的人?@Dusk_Foundation #dusk $DUSK
Dusk 的节点,不靠算力靠抵押
聊 Dusk 的人都在说隐私,但很少人看它节点怎么跑。

我查了一下,它不做 PoW,也不走普通 PoS,而是用抵押加抽签的方式选验证者。DUSK 不押进去,节点身份都没有。押进去之后,出块权靠随机,不是谁钱多谁说了算。

这背后有个挺别扭的设计:你要帮全网验证交易,但你手里跑的那些交易,很多都是加密的。也就是说,作为验证者,你得确认一批你自己也看不清完整内容的交易合法。做不到?系统用零知识证明来补,验证者只需要确认证明成立,不需要看懂全貌。

但这件事的成本,最后压在质押的人身上。节点要稳定在线,要跑 Rusk 这套虚拟机,硬件和运维不便宜。出块奖励能否覆盖,官方文档里没有写死一个保证收益,这比多数 PoS 链更冷。

有意思的是,普通用户质押 DUSK,收益不是靠“参与治理”,而是你的币被系统当成安全垫。网络越需要隐私验证,对节点的要求就越高,要求越高,愿意跑节点的人越少。那收益从哪来?早期靠通胀,长期得靠网络的手续费。手续费上不来,节点会走。

我原本以为 Dusk 节点和别的链差不多,看完机制才发现,它把隐私成本转成了验证成本,又把这成本转给了质押者。

所以问题来了:你愿意拿着 DUSK 去质押,赚一份说不清的收益,同时替全网隐私交易扛成本吗?

还是说,宁可拿着币什么都不干,也不让自己成为那个“不知道在验什么却要负责”的人?@Dusk

#dusk $DUSK
Ваша конфиденциальность — переключатель не у вас Те, кто покупают монеты конфиденциальности, чаще всего рассчитывают на фразу «меня никто не сможет найти». Но в XSC-контракте Dusk эмитент может оставить аудитору ключ. Звучит как бэкдор, но на самом деле это «комплаенс-раскрытие», прописанное в дизайне черным по белому. Изначально я думал, что конечная точка приватной сети — это полная анонимность. Но когда я прочитал документацию Dusk, увидел, что стандарт XSC разрешает эмитенту активов задавать «аудиторскую роль»: только этот субъект при наступлении определенных условий может просматривать детали транзакций. Не каждый сможет это сделать, но и вам не дадут возможность отказаться. Что это значит? Ваша приватность транзакций не под вашим контролем — она в руках эмитента и аудитора. Вы просто держите монеты, но переключатель «кто имеет право смотреть вашу бухгалтерию» вы не сможете нажать. Почему это сделано официально? Потому что финансовые активы нужно размещать в сети, учреждениям требуется KYC/AML, а регуляторам нужно видеть отчеты. Полностью анонимная сеть, в которую не рискнут заходить институции, а биржи еще могут снять с листинга. Dusk делает ставку: часть пользовательской приватности — в обмен на возможность соответствовать требованиям и выжить активам. Цена понятна: держатели жертвуют «абсолютной приватностью» ради канала, который, возможно, примут в мейнстриме. Выгода в том, что активы на DUSK не будут восприниматься как инструмент «черной индустрии», и риск делистинга ниже. Риск в том, что если аудиторская роль будет злоупотреблена или правила изменятся, у вас почти не будет позиции торга. Сейчас перед вами стоит вопрос: вы готовы передать часть контроля над приватностью, чтобы активы оставались на игровом столе; или предпочитаете полную анонимность, даже если в итоге эта сеть будет изолирована? Я не буду выбирать за вас, но я задам себе вопрос: если переключатель приватности моего кошелька окажется у другого, смогу ли я спокойно спать? @Dusk_Foundation #dusk $DUSK
Ваша конфиденциальность — переключатель не у вас
Те, кто покупают монеты конфиденциальности, чаще всего рассчитывают на фразу «меня никто не сможет найти». Но в XSC-контракте Dusk эмитент может оставить аудитору ключ. Звучит как бэкдор, но на самом деле это «комплаенс-раскрытие», прописанное в дизайне черным по белому.

Изначально я думал, что конечная точка приватной сети — это полная анонимность. Но когда я прочитал документацию Dusk, увидел, что стандарт XSC разрешает эмитенту активов задавать «аудиторскую роль»: только этот субъект при наступлении определенных условий может просматривать детали транзакций. Не каждый сможет это сделать, но и вам не дадут возможность отказаться.

Что это значит? Ваша приватность транзакций не под вашим контролем — она в руках эмитента и аудитора. Вы просто держите монеты, но переключатель «кто имеет право смотреть вашу бухгалтерию» вы не сможете нажать.

Почему это сделано официально? Потому что финансовые активы нужно размещать в сети, учреждениям требуется KYC/AML, а регуляторам нужно видеть отчеты. Полностью анонимная сеть, в которую не рискнут заходить институции, а биржи еще могут снять с листинга. Dusk делает ставку: часть пользовательской приватности — в обмен на возможность соответствовать требованиям и выжить активам.

Цена понятна: держатели жертвуют «абсолютной приватностью» ради канала, который, возможно, примут в мейнстриме. Выгода в том, что активы на DUSK не будут восприниматься как инструмент «черной индустрии», и риск делистинга ниже. Риск в том, что если аудиторская роль будет злоупотреблена или правила изменятся, у вас почти не будет позиции торга.

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

Я не буду выбирать за вас, но я задам себе вопрос: если переключатель приватности моего кошелька окажется у другого, смогу ли я спокойно спать?
@Dusk

#dusk $DUSK
Я в эти дни пересмотрел торговую модель Dusk и, наоборот, застрял на одном очень неинтуитивном решении: почему бы им не сделать все сделки сразу приватными? Ответ на самом деле довольно реалистичный. Сейчас Dusk разделяет обращение нативных активов на две модели: Moonlight и Phoenix. В Moonlight аккаунты, балансы, отправитель и получатель — всё публично; Phoenix же помещает средства в зашифрованную Note, где транзакцию подтверждают с помощью доказательств с нулевым разглашением, при этом скрываются суммы и связь между операциями, а при необходимости можно выполнить выборочное раскрытие через viewing key. > Это не вопрос о том, «насколько сильная приватность». В финансовом рынке есть сведения, которые невозможно навсегда скрыть. Для обычных переводов и сценариев частичного управления капиталом нужно иметь возможность сверять. Для институциональных сделок, которые не хотят напрямую выкладывать начейн ни состав портфеля, ни суммы. А для регуляторных проверок тем более неприемлем вариант «вообще ничего не видно». Поэтому Dusk не пошёл по пути «единого решения анонимности», а встроил**публичный расчёт и приватный расчёт в одну и ту же базовую сеть**. Самое интересное здесь, как мне кажется, — это компромисс. Если всё публично, аудит проще, но институции не хотят полностью вывешивать чувствительные потоки активов. Если всё приватно, пользователям комфортно, но комплаенс и управление активами тогда быстро упрутся в тупик. Решение Dusk довольно жёсткое: разные транзакции сами выбирают, какой объём информации нужно раскрыть. Это также объясняет, почему они постоянно подчёркивают regulated onchain finance, а не просто продают историю про «приватный блокчейн». Архитектура Dusk сейчас сама по себе разбита на модули вокруг расчётов, приватности, личности и выборочного раскрытия. Но мне хочется увидеть ещё один вопрос: Если бы вы были институцией, которая реально управляет финансовыми активами, чего бы вы больше боялись: утечки ончейн-информации или того, что при запросе на проверку со стороны регулятора вы не сможете предоставить доказательства?@Dusk_Foundation #dusk $DUSK
Я в эти дни пересмотрел торговую модель Dusk и, наоборот, застрял на одном очень неинтуитивном решении: почему бы им не сделать все сделки сразу приватными?

Ответ на самом деле довольно реалистичный.

Сейчас Dusk разделяет обращение нативных активов на две модели: Moonlight и Phoenix. В Moonlight аккаунты, балансы, отправитель и получатель — всё публично; Phoenix же помещает средства в зашифрованную Note, где транзакцию подтверждают с помощью доказательств с нулевым разглашением, при этом скрываются суммы и связь между операциями, а при необходимости можно выполнить выборочное раскрытие через viewing key.

> Это не вопрос о том, «насколько сильная приватность». В финансовом рынке есть сведения, которые невозможно навсегда скрыть.

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

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

А для регуляторных проверок тем более неприемлем вариант «вообще ничего не видно».

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

Самое интересное здесь, как мне кажется, — это компромисс.

Если всё публично, аудит проще, но институции не хотят полностью вывешивать чувствительные потоки активов.

Если всё приватно, пользователям комфортно, но комплаенс и управление активами тогда быстро упрутся в тупик.

Решение Dusk довольно жёсткое: разные транзакции сами выбирают, какой объём информации нужно раскрыть.

Это также объясняет, почему они постоянно подчёркивают regulated onchain finance, а не просто продают историю про «приватный блокчейн». Архитектура Dusk сейчас сама по себе разбита на модули вокруг расчётов, приватности, личности и выборочного раскрытия.

Но мне хочется увидеть ещё один вопрос:

Если бы вы были институцией, которая реально управляет финансовыми активами, чего бы вы больше боялись: утечки ончейн-информации или того, что при запросе на проверку со стороны регулятора вы не сможете предоставить доказательства?@Dusk

#dusk $DUSK
См. перевод
昨天重新看 Babylon 的验证参与机制时,我一直在关注一个容易被忽略的角色:那些真正跑节点、维护网络安全的人。 很多讨论都会把重点放在 BTC 持有人能不能获得收益,但对于验证者来说,问题完全不同。 他们面对的不是“要不要锁一部分 BTC”,而是: 接入新的安全体系,会不会让自己的运营成本增加? 一个节点运营者最关心的事情很现实。 服务器成本。 维护时间。 风险控制。 收益是否覆盖投入。 Babylon 想连接 Bitcoin 的经济安全,但这套设计最终也需要有人参与维护网络运行。 > 任何安全模型最后都绕不开一个问题:有没有足够多的人愿意长期承担成本。 如果收益足够吸引,更多参与者进入,可以增强网络安全。 但如果运营门槛提高,或者收益无法覆盖实际投入,参与者可能会减少。 这也是很多链上基础设施都会遇到的矛盾。 安全越强,通常意味着更多规则和要求。 规则越多,参与成本也可能提高。 我觉得 Babylon 有意思的地方,不只是让 BTC 产生新的使用场景,而是在尝试重新分配链上安全市场里的角色。 过去: 一条链需要自己培养验证者。 现在: 验证者可以通过新的方式参与更广泛的安全体系。 但最终决定这套模式能不能长期运行的,不只是技术设计,而是现实中的节点运营者愿不愿意持续投入。 因为区块链世界里,真正支撑安全的从来不是一句理念,而是一群每天维护机器、承担成本的人。 如果未来 Babylon 生态扩大,你认为最关键的竞争会是吸引更多 BTC,还是吸引更多愿意长期运行节点的人? #baby $BABY
昨天重新看 Babylon 的验证参与机制时,我一直在关注一个容易被忽略的角色:那些真正跑节点、维护网络安全的人。

很多讨论都会把重点放在 BTC 持有人能不能获得收益,但对于验证者来说,问题完全不同。

他们面对的不是“要不要锁一部分 BTC”,而是:

接入新的安全体系,会不会让自己的运营成本增加?

一个节点运营者最关心的事情很现实。

服务器成本。

维护时间。

风险控制。

收益是否覆盖投入。

Babylon 想连接 Bitcoin 的经济安全,但这套设计最终也需要有人参与维护网络运行。

> 任何安全模型最后都绕不开一个问题:有没有足够多的人愿意长期承担成本。

如果收益足够吸引,更多参与者进入,可以增强网络安全。

但如果运营门槛提高,或者收益无法覆盖实际投入,参与者可能会减少。

这也是很多链上基础设施都会遇到的矛盾。

安全越强,通常意味着更多规则和要求。

规则越多,参与成本也可能提高。

我觉得 Babylon 有意思的地方,不只是让 BTC 产生新的使用场景,而是在尝试重新分配链上安全市场里的角色。

过去:

一条链需要自己培养验证者。

现在:

验证者可以通过新的方式参与更广泛的安全体系。

但最终决定这套模式能不能长期运行的,不只是技术设计,而是现实中的节点运营者愿不愿意持续投入。

因为区块链世界里,真正支撑安全的从来不是一句理念,而是一群每天维护机器、承担成本的人。

如果未来 Babylon 生态扩大,你认为最关键的竞争会是吸引更多 BTC,还是吸引更多愿意长期运行节点的人?

#baby $BABY
См. перевод
昨天看 Babylon 生态项目接入情况时,我一直在想一个问题:对于一条刚启动的新链来说,拥有 Bitcoin Security 到底是一种加速器,还是另一种新的依赖? 很多项目上线前都会面临同一个现实。 功能可以快速开发。 代币可以快速发行。 但安全体系不是靠宣传就能建立。 验证者数量、经济激励、长期维护,这些都需要时间积累。 所以 Babylon 提供的 BTC 安全方案,对于很多新链来说像是一条捷径。 > 但捷径背后也有一个选择:获得更快的安全启动,还是坚持完全依靠自己的验证网络成长。 站在新链团队角度,接入成熟安全来源,可以降低早期冷启动压力。 不用一开始就承担巨大安全预算,也不用等待多年才能建立足够强的验证者体系。 但另一面,依赖外部安全层,也意味着未来发展过程中需要持续协调双方关系。 如果一条链越来越依赖外部安全,它自己的安全体系还会不会继续成长? 这个问题没有简单答案。 因为完全自主建设安全,也不是免费的。 很多新链最后失败,并不是因为技术不好,而是因为没有足够经济规模支撑安全。 Babylon 的设计,其实是在解决一个长期存在的矛盾: 小链需要安全,但安全本身需要规模。 Bitcoin 拥有规模。 新链需要规模。 两者之间产生了连接。 我觉得 Babylon 真正有意思的地方,不只是让 BTC 参与安全,而是改变了新链建立信任的路径。 以前: 一条链需要自己慢慢证明安全。 未来: 它可能先借助已有经济安全,再逐渐建立自己的网络价值。 但问题也留给市场: 一条新链如果靠 Bitcoin Security 起步,当它成长起来后,你认为它应该继续依赖外部安全,还是最终必须建立完全属于自己的安全体系? #baby $BABY
昨天看 Babylon 生态项目接入情况时,我一直在想一个问题:对于一条刚启动的新链来说,拥有 Bitcoin Security 到底是一种加速器,还是另一种新的依赖?

很多项目上线前都会面临同一个现实。

功能可以快速开发。

代币可以快速发行。

但安全体系不是靠宣传就能建立。

验证者数量、经济激励、长期维护,这些都需要时间积累。

所以 Babylon 提供的 BTC 安全方案,对于很多新链来说像是一条捷径。

> 但捷径背后也有一个选择:获得更快的安全启动,还是坚持完全依靠自己的验证网络成长。

站在新链团队角度,接入成熟安全来源,可以降低早期冷启动压力。

不用一开始就承担巨大安全预算,也不用等待多年才能建立足够强的验证者体系。

但另一面,依赖外部安全层,也意味着未来发展过程中需要持续协调双方关系。

如果一条链越来越依赖外部安全,它自己的安全体系还会不会继续成长?

这个问题没有简单答案。

因为完全自主建设安全,也不是免费的。

很多新链最后失败,并不是因为技术不好,而是因为没有足够经济规模支撑安全。

Babylon 的设计,其实是在解决一个长期存在的矛盾:

小链需要安全,但安全本身需要规模。

Bitcoin 拥有规模。

新链需要规模。

两者之间产生了连接。

我觉得 Babylon 真正有意思的地方,不只是让 BTC 参与安全,而是改变了新链建立信任的路径。

以前:

一条链需要自己慢慢证明安全。

未来:

它可能先借助已有经济安全,再逐渐建立自己的网络价值。

但问题也留给市场:

一条新链如果靠 Bitcoin Security 起步,当它成长起来后,你认为它应该继续依赖外部安全,还是最终必须建立完全属于自己的安全体系?

#baby $BABY
См. перевод
最近和几个跑节点的朋友聊天,我发现一个挺有意思的变化。 以前大家讨论一条PoS链,最关心的是节点能不能赚到奖励。 现在提到Babylon,很多人开始问另一件事: 如果未来越来越多网络共享Bitcoin安全,节点还能靠什么建立自己的竞争力? 以前节点之间拼的是硬件、稳定性和运营能力。 这些差距虽然存在,但规则相对清楚。 可一旦安全来源开始发生变化,节点的角色也会慢慢变化。 安全不再只是自己提供。 更多时候,节点需要思考的是: 怎样和新的安全体系协同,而不是重复投入。 我觉得这可能是很多人容易忽略的一点。 大家总在讨论BTC有没有释放流动性,却很少讨论节点生态会不会因此重新分工。 一个成熟的基础设施,不一定会让节点消失。 更大的可能,是让节点把更多精力放到网络服务、数据同步、运行效率这些真正能够体现价值的地方。 这和过去不断堆质押规模,其实是两种完全不同的发展思路。 所以我现在看Babylon,已经不会只盯着TVL或者质押数据。 我更想观察的是: 未来节点运营者会不会主动调整自己的角色。 如果答案是会,那Babylon影响的就不只是BTC资产利用率。 它还有可能改变一部分PoS网络的运行方式。 真正值得长期关注的,也许不是有多少BTC进入协议。 而是越来越多生态参与者,开始重新定义自己在整个网络里的位置。 #baby $BABY
最近和几个跑节点的朋友聊天,我发现一个挺有意思的变化。

以前大家讨论一条PoS链,最关心的是节点能不能赚到奖励。

现在提到Babylon,很多人开始问另一件事:

如果未来越来越多网络共享Bitcoin安全,节点还能靠什么建立自己的竞争力?

以前节点之间拼的是硬件、稳定性和运营能力。

这些差距虽然存在,但规则相对清楚。

可一旦安全来源开始发生变化,节点的角色也会慢慢变化。

安全不再只是自己提供。

更多时候,节点需要思考的是:

怎样和新的安全体系协同,而不是重复投入。

我觉得这可能是很多人容易忽略的一点。

大家总在讨论BTC有没有释放流动性,却很少讨论节点生态会不会因此重新分工。

一个成熟的基础设施,不一定会让节点消失。

更大的可能,是让节点把更多精力放到网络服务、数据同步、运行效率这些真正能够体现价值的地方。

这和过去不断堆质押规模,其实是两种完全不同的发展思路。

所以我现在看Babylon,已经不会只盯着TVL或者质押数据。

我更想观察的是:

未来节点运营者会不会主动调整自己的角色。

如果答案是会,那Babylon影响的就不只是BTC资产利用率。

它还有可能改变一部分PoS网络的运行方式。

真正值得长期关注的,也许不是有多少BTC进入协议。

而是越来越多生态参与者,开始重新定义自己在整个网络里的位置。

#baby $BABY
Вчера, когда я изучал механизм BTC Staking в Babylon, я не стал дальше углубляться в технические детали, а вместо этого сосредоточился на более практичном вопросе: почему человек, который долго держит BTC, вообще готов добровольно изменить свои привычки хранения? Раньше для многих держателей BTC самым важным было простое. Купить. Перенести в холодный кошелёк. Ждать. И они доверяли Bitcoin во многом потому, что у него нет сложных точек для получения дохода и нет слишком большого количества дополнительных действий. Но Babylon как раз и хочет поменять эту привычку. Он стремится вовлечь простаивающий BTC в обеспечение безопасности сети, а держателям дать новый источник ценности. Но здесь есть противоречие, которое многие легко упускают из виду: > Если BTC начинает приносить доход, то он перестаёт быть просто «лежачим» активом — он превращается в рынок, где нужно оценивать риски и альтернативные издержки. Для протокола больше BTC означает более сильную экономическую безопасность. А для пользователей это означает новую проблему: Если во время периода блокировки появится возможность на рынке — что делать? Если в других сетях возникнут проблемы — что делать? Если доход не сможет покрыть риски, которые приходится брать на себя — что тогда? Вот с какими реальными вызовами Babylon предстоит столкнуться. Технически — подключить BTC к системе безопасности — это одно. А вот убедить тех, кто больше всего верит в простую ценность BTC, изменить поведение — совсем другое. Я думаю, что реальным конкурентом Babylon являются не другие BTC-проекты, а собственная психологическая защита держателей BTC. Потому что многие покупают BTC не ради того, чтобы выполнять больше действий, а ради того, чтобы сократить количество действий. Babylon предлагает новую возможность: превратить BTC из статического актива для сбережения в ончейн-капитал, обеспечивающий безопасность. Но цена тоже понятна: с ростом доходности увеличиваются и издержки на принятие решений. Раньше вопрос был только такой: «Покупать ли BTC?» А в будущем, возможно, он будет звучать так: «Моему BTC стоит ли участвовать в безопасности других сетей?» Если в будущем BTC Staking станет постепенно всё более распространённым, вы скорее предпочтёте, чтобы ваш BTC работал и приносил доход, или будете считать, что главная ценность BTC — навсегда оставаться простым? #baby $BABY
Вчера, когда я изучал механизм BTC Staking в Babylon, я не стал дальше углубляться в технические детали, а вместо этого сосредоточился на более практичном вопросе: почему человек, который долго держит BTC, вообще готов добровольно изменить свои привычки хранения?

Раньше для многих держателей BTC самым важным было простое.

Купить.

Перенести в холодный кошелёк.

Ждать.

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

Но Babylon как раз и хочет поменять эту привычку.

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

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

Для протокола больше BTC означает более сильную экономическую безопасность.

А для пользователей это означает новую проблему:

Если во время периода блокировки появится возможность на рынке — что делать?

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

Если доход не сможет покрыть риски, которые приходится брать на себя — что тогда?

Вот с какими реальными вызовами Babylon предстоит столкнуться.

Технически — подключить BTC к системе безопасности — это одно.

А вот убедить тех, кто больше всего верит в простую ценность BTC, изменить поведение — совсем другое.

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

Потому что многие покупают BTC не ради того, чтобы выполнять больше действий, а ради того, чтобы сократить количество действий.

Babylon предлагает новую возможность:

превратить BTC из статического актива для сбережения в ончейн-капитал, обеспечивающий безопасность.

Но цена тоже понятна:

с ростом доходности увеличиваются и издержки на принятие решений.

Раньше вопрос был только такой:

«Покупать ли BTC?»

А в будущем, возможно, он будет звучать так:

«Моему BTC стоит ли участвовать в безопасности других сетей?»

Если в будущем BTC Staking станет постепенно всё более распространённым, вы скорее предпочтёте, чтобы ваш BTC работал и приносил доход, или будете считать, что главная ценность BTC — навсегда оставаться простым?

#baby $BABY
Вчера вечером, перечитывая белую книгу Babylon, я никак не мог отделаться от одной фразы: Bitcoin Security, а не Bitcoin Consensus. Эти два слова отличаются всего несколькими иероглифами, но смысл и лежащая в основе дизайн-логика — совершенно разные. Сначала я подумал: раз Babylon хочет ввести биткоин в сеть PoS, значит ли это, что BTC будет напрямую участвовать в валидации, в создании блоков или в голосовании? Но чем дальше я читал, тем яснее становилось: официальный подход сознательно уходит от этого пути. Роль BTC в Babylon ближе к тому, чтобы выступать в качестве открыто предоставляемого экономического залога, а не к тому, чтобы быть исполнителем в самой сети. За реальный запуск PoS-сети по-прежнему отвечают исходные валидирующие ноды. BTC же добавляет дополнительный слой безопасности: повышает цену злонамеренных действий, но не подменяет собой чужой консенсус. > Потом я внезапно понял: это похоже на то, как добавить страховку к зданию, а не на то, чтобы полностью разобрать несущие конструкции и перестроить их заново. Если же заставить Bitcoin нести на себе консенсусный процесс PoS, это не только упрётся в ограничения скриптовых возможностей биткоина и сетевых характеристик, но и приведёт к тому, что две совершенно разные механики начнут «сдерживать» друг друга. Babylon, напротив, проводит границу очень чётко: BTC отвечает за безопасность, PoS-цепь продолжает выполнять работу, и каждая сторона сохраняет свои прежние сильные стороны. У такого дизайна, конечно, тоже есть цена. Протоколу нужно дополнительно выстроить целый набор механизмов, чтобы «отобразить» экономическую безопасность биткоина на разные PoS-сети; в итоге система будет сложнее, чем традиционные модели стейкинга, а порог понимания — выше. Но взамен вы не обязаны менять сам биткоин и можете использовать то накопленное за десятилетия ценностное обеспечение, которое уже есть. Раньше мне казалось, что инновация Babylon — это просто «BTC можно стейкать». Теперь, оглядываясь назад, я вижу: по сути оно превращает биткоин из транзакционного актива в переиспользуемый ресурс безопасности. Если в будущем всё больше публичных цепей начнут заимствовать Bitcoin Security, как ты думаешь, BTC постепенно перейдёт из роли «сохранения ценности» в роль базового слоя безопасности для всего мира PoS? #baby $BABY
Вчера вечером, перечитывая белую книгу Babylon, я никак не мог отделаться от одной фразы: Bitcoin Security, а не Bitcoin Consensus. Эти два слова отличаются всего несколькими иероглифами, но смысл и лежащая в основе дизайн-логика — совершенно разные.

Сначала я подумал: раз Babylon хочет ввести биткоин в сеть PoS, значит ли это, что BTC будет напрямую участвовать в валидации, в создании блоков или в голосовании? Но чем дальше я читал, тем яснее становилось: официальный подход сознательно уходит от этого пути.

Роль BTC в Babylon ближе к тому, чтобы выступать в качестве открыто предоставляемого экономического залога, а не к тому, чтобы быть исполнителем в самой сети. За реальный запуск PoS-сети по-прежнему отвечают исходные валидирующие ноды. BTC же добавляет дополнительный слой безопасности: повышает цену злонамеренных действий, но не подменяет собой чужой консенсус.

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

Если же заставить Bitcoin нести на себе консенсусный процесс PoS, это не только упрётся в ограничения скриптовых возможностей биткоина и сетевых характеристик, но и приведёт к тому, что две совершенно разные механики начнут «сдерживать» друг друга. Babylon, напротив, проводит границу очень чётко: BTC отвечает за безопасность, PoS-цепь продолжает выполнять работу, и каждая сторона сохраняет свои прежние сильные стороны.

У такого дизайна, конечно, тоже есть цена. Протоколу нужно дополнительно выстроить целый набор механизмов, чтобы «отобразить» экономическую безопасность биткоина на разные PoS-сети; в итоге система будет сложнее, чем традиционные модели стейкинга, а порог понимания — выше. Но взамен вы не обязаны менять сам биткоин и можете использовать то накопленное за десятилетия ценностное обеспечение, которое уже есть.

Раньше мне казалось, что инновация Babylon — это просто «BTC можно стейкать». Теперь, оглядываясь назад, я вижу: по сути оно превращает биткоин из транзакционного актива в переиспользуемый ресурс безопасности.

Если в будущем всё больше публичных цепей начнут заимствовать Bitcoin Security, как ты думаешь, BTC постепенно перейдёт из роли «сохранения ценности» в роль базового слоя безопасности для всего мира PoS?

#baby $BABY
См. перевод
今天重新翻 Babylon Genesis 的设计时,我一直在盯着一个问题:既然整个协议都是围绕 BTC 安全性展开,为什么官方还要单独发行 BABY,而不是直接让 BTC 承担所有功能? 继续看下去才发现,官方从一开始就没打算让 BTC 变成网络里的“万能资产”。 BTC 在 Babylon 更像一块安全保证金。它负责提供经济安全,让接入的 PoS 网络能够借用比特币的价值背书。但真正让网络运行起来的,是另一套逻辑。Gas 支付、治理投票、生态激励,这些高频动作都交给了 BABY。 我后来发现,这其实是在刻意避免一种矛盾:让一种偏储值属性的资产,同时承担高频运行任务。 如果所有操作都依赖 BTC,每一次网络交互都会直接绑定比特币资产本身,无论是交易体验还是激励设计都会受到限制。Babylon 选择把执行层交给 BABY,把安全层留给 BTC,本质上是在让两种资产各自做自己最擅长的事情,而不是互相替代。 当然,这样设计也有代价。协议需要维护两套经济体系,用户理解门槛会提高,生态建设也必须同时兼顾 BTC 持有者和 BABY 使用者。但相比把所有责任压到一种资产身上,这种分工反而给后续扩展留下了更多空间。 以前我总觉得 Babylon 的创新只是“BTC 可以原生质押”。现在再看,它真正想建立的是一套安全层和执行层分离的架构,而 BABY 的存在,就是这套分工能够长期运转的重要一环。 如果未来更多 Bitcoin 生态协议都采用类似模式,你会更认可“一种资产负责安全、一种资产负责运行”,还是坚持所有功能都集中在 BTC 身上? #baby $BABY
今天重新翻 Babylon Genesis 的设计时,我一直在盯着一个问题:既然整个协议都是围绕 BTC 安全性展开,为什么官方还要单独发行 BABY,而不是直接让 BTC 承担所有功能?

继续看下去才发现,官方从一开始就没打算让 BTC 变成网络里的“万能资产”。

BTC 在 Babylon 更像一块安全保证金。它负责提供经济安全,让接入的 PoS 网络能够借用比特币的价值背书。但真正让网络运行起来的,是另一套逻辑。Gas 支付、治理投票、生态激励,这些高频动作都交给了 BABY。

我后来发现,这其实是在刻意避免一种矛盾:让一种偏储值属性的资产,同时承担高频运行任务。

如果所有操作都依赖 BTC,每一次网络交互都会直接绑定比特币资产本身,无论是交易体验还是激励设计都会受到限制。Babylon 选择把执行层交给 BABY,把安全层留给 BTC,本质上是在让两种资产各自做自己最擅长的事情,而不是互相替代。

当然,这样设计也有代价。协议需要维护两套经济体系,用户理解门槛会提高,生态建设也必须同时兼顾 BTC 持有者和 BABY 使用者。但相比把所有责任压到一种资产身上,这种分工反而给后续扩展留下了更多空间。

以前我总觉得 Babylon 的创新只是“BTC 可以原生质押”。现在再看,它真正想建立的是一套安全层和执行层分离的架构,而 BABY 的存在,就是这套分工能够长期运转的重要一环。

如果未来更多 Bitcoin 生态协议都采用类似模式,你会更认可“一种资产负责安全、一种资产负责运行”,还是坚持所有功能都集中在 BTC 身上?

#baby $BABY
Войдите, чтобы посмотреть больше материала
Присоединяйтесь к пользователям криптовалют по всему миру на Binance Square
⚡️ Получайте новейшую и полезную информацию о криптоактивах.
💬 Нам доверяет крупнейшая в мире криптобиржа.
👍 Получите достоверные аналитические данные от верифицированных создателей контента.
Эл. почта/номер телефона
Структура веб-страницы
Настройки cookie
Правила и условия платформы