Binance Square
0x碎碎念
345 Bài đăng

0x碎碎念

23 Đang theo dõi
28 Người theo dõi
68 Đã thích
Bài đăng
·
--
Xem bản dịch
我发现在看到@Dusk_Foundation 的 Zedger 那部分之前,我对"链上证券"的想象一直很单薄——无非就是把股票、债券包一层智能合约,转账记账而已。看完之后发现自己想简单了。 大多数人对"隐私链"的默认期待是:我的资产别人看不见,也别人动不了。这两件事在直觉里是绑在一起的——既然你看不见我的持仓,你当然也没法动我的资产。但 Zedger 协议里明确写了一个功能:force transfer,强制转让。发行方在满足特定条件下,可以不经持有人签名同意,直接把这笔证券从一个地址转到另一个地址。 这话我本来不想说得这么直接——一条主打隐私的链,内建了一个能让第三方强制拿走你资产的合约功能。 说出来可能有点冒犯,但这其实完全说得通。传统证券法里,法院冻结账户、强制赎回、遗产纠纷强制过户,这些场景现实里天天发生,只是链下靠的是律师函和法院执行令。Dusk 把这套现实义务直接编码进了智能合约,等于把"合规"这个词从口号变成了可执行的代码路径。 我发现我已经坐了将近三个小时没挪过地方。 利益穿透一下:谁受益?发行方和监管方,他们拿到了一个可以在合规框架下"依法处置"资产的技术工具,这是传统证券市场运转的必要条件,没有这个能力,机构级 RWA 根本没法上链。谁承担代价?持有这些代币化证券的普通用户——你以为你拥有的是"你的"资产,实际上你拥有的是一份"发行方在特定条件下可以合法拿走"的资产,这个条件写在合约里,但大多数人根本不会去读合约里那几行强制转让的触发逻辑。 白皮书里对"什么条件会触发 force transfer"、"谁来审批这个触发"这两件事没有展开细节,这块我目前也没找到更具体的说明,算是留着的一个问题。#dusk $DUSK @Dusk_Foundation
我发现在看到@Dusk 的 Zedger 那部分之前,我对"链上证券"的想象一直很单薄——无非就是把股票、债券包一层智能合约,转账记账而已。看完之后发现自己想简单了。

大多数人对"隐私链"的默认期待是:我的资产别人看不见,也别人动不了。这两件事在直觉里是绑在一起的——既然你看不见我的持仓,你当然也没法动我的资产。但 Zedger 协议里明确写了一个功能:force transfer,强制转让。发行方在满足特定条件下,可以不经持有人签名同意,直接把这笔证券从一个地址转到另一个地址。

这话我本来不想说得这么直接——一条主打隐私的链,内建了一个能让第三方强制拿走你资产的合约功能。

说出来可能有点冒犯,但这其实完全说得通。传统证券法里,法院冻结账户、强制赎回、遗产纠纷强制过户,这些场景现实里天天发生,只是链下靠的是律师函和法院执行令。Dusk 把这套现实义务直接编码进了智能合约,等于把"合规"这个词从口号变成了可执行的代码路径。

我发现我已经坐了将近三个小时没挪过地方。

利益穿透一下:谁受益?发行方和监管方,他们拿到了一个可以在合规框架下"依法处置"资产的技术工具,这是传统证券市场运转的必要条件,没有这个能力,机构级 RWA 根本没法上链。谁承担代价?持有这些代币化证券的普通用户——你以为你拥有的是"你的"资产,实际上你拥有的是一份"发行方在特定条件下可以合法拿走"的资产,这个条件写在合约里,但大多数人根本不会去读合约里那几行强制转让的触发逻辑。

白皮书里对"什么条件会触发 force transfer"、"谁来审批这个触发"这两件事没有展开细节,这块我目前也没找到更具体的说明,算是留着的一个问题。#dusk $DUSK @Dusk
Xem bản dịch
灯没开,就着屏幕光在看@termmax 白皮书那句"XT 在 Alpha 市场里扮演类似期权费的角色",看了两遍才确定不是我理解错了。 我自己是先把 XT 当成纯粹的过渡代币来用的——铸出来立刻卖掉换流动性,这不就是白皮书里说的,锁定借款成本嘛,用完即弃,跟循环贷里那个"过桥资金"没什么本质区别。这个操作我做了好几次,一直挺顺手,直到我去查 Alpha 市场那部分文档,才发现自己一直漏看了一层。 XT 不只是"1 FT + 1 XT = 1 债务代币"里那个凑数的另一半。在 Alpha 市场,它实际上承担的是期权权利金的角色——也就是说,你作为借款人卖出 XT 换来的那笔流动性,本质上是收了一笔期权费,而你的仓位背后隐含着一个期权结构,标的和行权条件取决于市场怎么给这份"固定成本"定价。大多数人以为借款成本就是锁定的那个数字,其实这个数字里已经压着一层期权定价逻辑,波动率越高,这份权利金本该越贵,可你在铸造那一刻,看到的只是一个折算后的净成本,看不到里面到底压了多大的隐含波动率。 假设你在一个抵押品波动率骤然拉高的时段进场铸 XT,市场此时应该给这份"权利金"定一个更高的价,但如果流动性提供方或者做市曲线没能及时反映这个变化,你实际上是用一个偏低的价格,把一份被低估的期权卖给了对手方。等到波动真正兑现,你才意识到,你锁定的不是成本,是一个提前被人拿走的价差。 所以我现在的策略是:铸 XT 之前,我会先自己粗略估一下当前抵押品的隐含波动率区间,跟当时市场给出的固定利率倒推回去比一比,差得太多我就先不动。如果你只做几天的短线借贷,这层期权定价噪音对你影响很小,这篇你可以跳过。但如果你是长期限、大仓位的借款人,这份权利金定价偏差,长期下来是真金白银的差距。 #termmax @termmax
灯没开,就着屏幕光在看@TermMax 白皮书那句"XT 在 Alpha 市场里扮演类似期权费的角色",看了两遍才确定不是我理解错了。

我自己是先把 XT 当成纯粹的过渡代币来用的——铸出来立刻卖掉换流动性,这不就是白皮书里说的,锁定借款成本嘛,用完即弃,跟循环贷里那个"过桥资金"没什么本质区别。这个操作我做了好几次,一直挺顺手,直到我去查 Alpha 市场那部分文档,才发现自己一直漏看了一层。

XT 不只是"1 FT + 1 XT = 1 债务代币"里那个凑数的另一半。在 Alpha 市场,它实际上承担的是期权权利金的角色——也就是说,你作为借款人卖出 XT 换来的那笔流动性,本质上是收了一笔期权费,而你的仓位背后隐含着一个期权结构,标的和行权条件取决于市场怎么给这份"固定成本"定价。大多数人以为借款成本就是锁定的那个数字,其实这个数字里已经压着一层期权定价逻辑,波动率越高,这份权利金本该越贵,可你在铸造那一刻,看到的只是一个折算后的净成本,看不到里面到底压了多大的隐含波动率。

假设你在一个抵押品波动率骤然拉高的时段进场铸 XT,市场此时应该给这份"权利金"定一个更高的价,但如果流动性提供方或者做市曲线没能及时反映这个变化,你实际上是用一个偏低的价格,把一份被低估的期权卖给了对手方。等到波动真正兑现,你才意识到,你锁定的不是成本,是一个提前被人拿走的价差。

所以我现在的策略是:铸 XT 之前,我会先自己粗略估一下当前抵押品的隐含波动率区间,跟当时市场给出的固定利率倒推回去比一比,差得太多我就先不动。如果你只做几天的短线借贷,这层期权定价噪音对你影响很小,这篇你可以跳过。但如果你是长期限、大仓位的借款人,这份权利金定价偏差,长期下来是真金白银的差距。
#termmax @TermMax
Xem bản dịch
前几天在验证人社群里看到有人问:"如果链一直选不出块怎么办",当时随口就说"总会有人出块的",现在想想那个回答有点想当然了。 大多数人对 PoS 链的假设是:只要有验证人在线,共识迟早会达成,无非是多等几轮。但 Dusk 白皮书里写得很直白——如果连续失败的迭代数达到 16 次,协议会主动关闭超时机制,进入"紧急模式",这时候 NoCandidate 和 NoQuorum 这两种投票选项直接被禁用,意思是委员会不再被允许"选择什么都不选"。 这个设计本身没什么好意外的,逼着系统必须往前走。真正让我愣住的是后面那句——如果紧急模式下所有迭代的最大超时也耗尽了,还是没能选出候选块,会怎么样?答案是:一部分 provisioner 可以发起"紧急区块请求"(EBR),只要发起请求的这批人持有全网多数质押,他们就能直接产出一个不含任何交易的空区块,只是为了让链继续往前走。 这话我本来不想说得这么直接,但这本质上是一种"多数质押方绕过正常出块流程、强行续命"的合法通道。 利益穿透一下:谁受益?持有多数质押的大户,在极端情况下能单方面决定链是否继续运转,这是权力;谁承担代价?普通用户和小额质押者,在这种场景里没有话语权,只能被动接受一个"空转"的区块,等系统恢复正常再说。表面上看这是个技术兜底方案,往深了想,它其实是把"链的连续性"这件事,在最坏情况下交给了少数大户的联合意愿。 白皮书里没有细说这套 EBR 机制在实际网络里被触发过没有,也没给出"多数质押方联合发起空块"这件事对去中心化叙事的具体冲击评估,这块是我目前没找到答案的地方。 一个系统设计"防止彻底停摆"和"把停摆决定权交给多数质押方",这两件事在极端情况下其实是同一个硬币的两面,你们觉得这个取舍合理吗?#dusk $DUSK @Dusk_Foundation
前几天在验证人社群里看到有人问:"如果链一直选不出块怎么办",当时随口就说"总会有人出块的",现在想想那个回答有点想当然了。

大多数人对 PoS 链的假设是:只要有验证人在线,共识迟早会达成,无非是多等几轮。但 Dusk 白皮书里写得很直白——如果连续失败的迭代数达到 16 次,协议会主动关闭超时机制,进入"紧急模式",这时候 NoCandidate 和 NoQuorum 这两种投票选项直接被禁用,意思是委员会不再被允许"选择什么都不选"。

这个设计本身没什么好意外的,逼着系统必须往前走。真正让我愣住的是后面那句——如果紧急模式下所有迭代的最大超时也耗尽了,还是没能选出候选块,会怎么样?答案是:一部分 provisioner 可以发起"紧急区块请求"(EBR),只要发起请求的这批人持有全网多数质押,他们就能直接产出一个不含任何交易的空区块,只是为了让链继续往前走。

这话我本来不想说得这么直接,但这本质上是一种"多数质押方绕过正常出块流程、强行续命"的合法通道。

利益穿透一下:谁受益?持有多数质押的大户,在极端情况下能单方面决定链是否继续运转,这是权力;谁承担代价?普通用户和小额质押者,在这种场景里没有话语权,只能被动接受一个"空转"的区块,等系统恢复正常再说。表面上看这是个技术兜底方案,往深了想,它其实是把"链的连续性"这件事,在最坏情况下交给了少数大户的联合意愿。

白皮书里没有细说这套 EBR 机制在实际网络里被触发过没有,也没给出"多数质押方联合发起空块"这件事对去中心化叙事的具体冲击评估,这块是我目前没找到答案的地方。

一个系统设计"防止彻底停摆"和"把停摆决定权交给多数质押方",这两件事在极端情况下其实是同一个硬币的两面,你们觉得这个取舍合理吗?#dusk $DUSK @Dusk
Xem bản dịch
我今天在扒@termmax 的一个细节:策展人管理的市场里,没被借出去的那部分资金,是自动扔进 Aave、Morpho、Venus 这些浮动利率协议里生息的。乍一看这是个纯粹的好事——"消除零回报的闲置资本",文档里就是这么写的,听起来跟金库经理帮你把闲钱理财了一样,没毛病。 搞清楚这件事花了我比我愿意承认的更多时间。因为我一开始也是这么想的:反正闲着也是闲着,放去赚点浮动收益总比躺在那不动强。直到我往回倒策展人这一层的激励结构,才发现事情没那么单纯——这笔"自动理财"的资金,决策权不在你手里,在策展人手里。他决定资金什么时候进、什么时候出、进哪个协议。你作为 LP,看到的只是一个综合 APY,你分不清这个数字里有多少是借贷利息,多少是这层浮动收益垫上去的。 假设市场突然进入一个借款需求暴增的时段,比如某个抵押品价格剧烈波动,大量用户想借出去加杠杆。这时候资金本该迅速从 Aave 那边抽回来,填补到 TermMax 自己的借贷池里,保证固定利率订单能被吃到。抽回的速度,取决于策展人的响应速度和目标协议本身的流动性深度——如果 Morpho 那个池子恰好也在被别人抽血,你的资金被卡在半路的窗口期,说长不长,但借款人等不了,他们会去找别的市场。这个时间差,你作为最终的 LP 是看不到的,系统层面它已经发生完了。 所以我现在的做法是:进任何一个策展人管理的市场之前,先去看他历史上闲置资金部署的比例曲线,如果长期维持很高比例挂在外部协议上,说明这个策展人对自己池子的借贷需求预判本来就比较保守,收益结构里"讲故事"的成分更重。如果你只是奔着展示 APY 去决定进不进,这篇对你没什么用。但如果你的仓位周期在一个月以上,这个抽回延迟,值得你自己去核实清楚。#termmax @termmax
我今天在扒@TermMax 的一个细节:策展人管理的市场里,没被借出去的那部分资金,是自动扔进 Aave、Morpho、Venus 这些浮动利率协议里生息的。乍一看这是个纯粹的好事——"消除零回报的闲置资本",文档里就是这么写的,听起来跟金库经理帮你把闲钱理财了一样,没毛病。

搞清楚这件事花了我比我愿意承认的更多时间。因为我一开始也是这么想的:反正闲着也是闲着,放去赚点浮动收益总比躺在那不动强。直到我往回倒策展人这一层的激励结构,才发现事情没那么单纯——这笔"自动理财"的资金,决策权不在你手里,在策展人手里。他决定资金什么时候进、什么时候出、进哪个协议。你作为 LP,看到的只是一个综合 APY,你分不清这个数字里有多少是借贷利息,多少是这层浮动收益垫上去的。

假设市场突然进入一个借款需求暴增的时段,比如某个抵押品价格剧烈波动,大量用户想借出去加杠杆。这时候资金本该迅速从 Aave 那边抽回来,填补到 TermMax 自己的借贷池里,保证固定利率订单能被吃到。抽回的速度,取决于策展人的响应速度和目标协议本身的流动性深度——如果 Morpho 那个池子恰好也在被别人抽血,你的资金被卡在半路的窗口期,说长不长,但借款人等不了,他们会去找别的市场。这个时间差,你作为最终的 LP 是看不到的,系统层面它已经发生完了。

所以我现在的做法是:进任何一个策展人管理的市场之前,先去看他历史上闲置资金部署的比例曲线,如果长期维持很高比例挂在外部协议上,说明这个策展人对自己池子的借贷需求预判本来就比较保守,收益结构里"讲故事"的成分更重。如果你只是奔着展示 APY 去决定进不进,这篇对你没什么用。但如果你的仓位周期在一个月以上,这个抽回延迟,值得你自己去核实清楚。#termmax @TermMax
Xem bản dịch
今晚在看@Dusk_Foundation 白皮书的滚动最终性那部分,本来只是随手翻,结果卡了快两个小时没往下看。 大多数人对"区块确认"的理解很粗糙:区块上链了,就等于安全了,顶多再等几个确认数图个心安。我自己以前也是这么想的,直到我算了一遍 Dusk 的 Rolling Finality 具体规则,才发现这个"等确认数"的直觉在这条链上可能是错的。 Dusk 把区块状态分成四级:accepted、attested、confirmed、final。听起来像常规分级,但魔鬼在细节里——一个区块如果不是在"零前序失败迭代"的情况下达成共识(也就是 n>0,前面有迭代失败过),它只能先标记成 accepted,而不是更稳的 attested。accepted 状态意味着它理论上还能被更低迭代序号的候选块替代掉。 要变成 confirmed,需要多少个后续区块确认?答案不是固定的1个或3个,是 2×n 个。n 是前面失败迭代的数量。白皮书里举的例子是迭代序号5、有2次前序失败,这种情况得等够4个后续 attested/confirmed 区块才算稳。 我把这条规则读了三遍才确认自己没理解错。 这意味着同样"已经上链"的两个区块,风险其实不对等——一个一次成功没有前序失败的区块,几乎立刻就进入更稳的 attested;另一个经历过几次迭代失败才成功的区块,需要等更多个后续块才能达到同等的抗替代强度。表面上看都是"已确认",底层的脆弱程度是分层的。 所以我现在的做法是,遇到需要判断"这笔交易到底稳不稳"的场景,我不再只看确认数这一个指标,而是会去看这笔交易所在区块经历了几次迭代失败——迭代数越高,我愿意多等的确认块也越多,尤其是大额结算场景。 如果你只是小额高频转账,这套细节对你意义不大,风险窗口本来就短。但如果你是在做机构级 DvP 结算或者大额 OTC,这个 n 值,值得你自己去 Dusk 节点数据里查一下。#dusk $DUSK @Dusk_Foundation
今晚在看@Dusk 白皮书的滚动最终性那部分,本来只是随手翻,结果卡了快两个小时没往下看。

大多数人对"区块确认"的理解很粗糙:区块上链了,就等于安全了,顶多再等几个确认数图个心安。我自己以前也是这么想的,直到我算了一遍 Dusk 的 Rolling Finality 具体规则,才发现这个"等确认数"的直觉在这条链上可能是错的。

Dusk 把区块状态分成四级:accepted、attested、confirmed、final。听起来像常规分级,但魔鬼在细节里——一个区块如果不是在"零前序失败迭代"的情况下达成共识(也就是 n>0,前面有迭代失败过),它只能先标记成 accepted,而不是更稳的 attested。accepted 状态意味着它理论上还能被更低迭代序号的候选块替代掉。

要变成 confirmed,需要多少个后续区块确认?答案不是固定的1个或3个,是 2×n 个。n 是前面失败迭代的数量。白皮书里举的例子是迭代序号5、有2次前序失败,这种情况得等够4个后续 attested/confirmed 区块才算稳。

我把这条规则读了三遍才确认自己没理解错。

这意味着同样"已经上链"的两个区块,风险其实不对等——一个一次成功没有前序失败的区块,几乎立刻就进入更稳的 attested;另一个经历过几次迭代失败才成功的区块,需要等更多个后续块才能达到同等的抗替代强度。表面上看都是"已确认",底层的脆弱程度是分层的。

所以我现在的做法是,遇到需要判断"这笔交易到底稳不稳"的场景,我不再只看确认数这一个指标,而是会去看这笔交易所在区块经历了几次迭代失败——迭代数越高,我愿意多等的确认块也越多,尤其是大额结算场景。

如果你只是小额高频转账,这套细节对你意义不大,风险窗口本来就短。但如果你是在做机构级 DvP 结算或者大额 OTC,这个 n 值,值得你自己去 Dusk 节点数据里查一下。#dusk $DUSK @Dusk
Xem bản dịch
眼睛有点花,盯屏幕太久了。刚才在看一笔 GT 仓位的实时估值,数字比我预期低了一截,倒回去核对了三遍,才确认不是我算错了。 我自己是真金白银铸过 GT 的。第一次操作完,看着杠杆一键到位、Gas 只扣了一次,当时确实觉得爽——这不就是把循环贷那套繁琐流程直接砍掉了吗。我以为这东西的估值逻辑跟 Aave 那类货币市场差不多,抵押品减掉当前欠款就是净值,剩下的利息随时间慢慢扣。然后我盯着账户又看了半天。 不对。@termmax 的 GT 不是这么算的。它是前期一次性结算掉全部利息和费用的: GT 价值 = 抵押品 − (债务 + 全部利息 + 费用) 意思是你铸出来那一刻,到期该付的利息已经从你的净值里扣完了,不是慢慢累积的。大多数人下意识用"随用随计息"的老框架去套这个数字,结果看到估值比想象中低,第一反应是"是不是被清算风险吃了一口",其实根本没那回事,是你的会计模型用错了。这个认知差,在临近清算线时候尤其致命——你以为自己安全垫还有多少,跟系统实际算出来的,不是一回事。 窗外在施工,噪音一直没停,我也没去关窗。 所以我现在的策略很简单:每次铸 GT 之前,先自己按公式把全周期利息和手续费算一遍,再拿这个数字去对照清算阈值,而不是拿"抵押品减当前债务"去估。如果你只是短线进出、持仓不超过几天,这篇对你意义不大,利息占比小到可以忽略。但如果你打算拿满整个期限、还叠加了杠杆,这个前置扣除会直接决定你的实际安全垫比你以为的薄多少。 这个坑我没踩过,但我看见它了。你们觉得这种"前置结算"设计,对散户是更友好还是更容易被误读?评论区聊聊。 那组估值页面我还开着,没关。#termmax @termmax
眼睛有点花,盯屏幕太久了。刚才在看一笔 GT 仓位的实时估值,数字比我预期低了一截,倒回去核对了三遍,才确认不是我算错了。

我自己是真金白银铸过 GT 的。第一次操作完,看着杠杆一键到位、Gas 只扣了一次,当时确实觉得爽——这不就是把循环贷那套繁琐流程直接砍掉了吗。我以为这东西的估值逻辑跟 Aave 那类货币市场差不多,抵押品减掉当前欠款就是净值,剩下的利息随时间慢慢扣。然后我盯着账户又看了半天。

不对。@TermMax 的 GT 不是这么算的。它是前期一次性结算掉全部利息和费用的:

GT 价值 = 抵押品 − (债务 + 全部利息 + 费用)

意思是你铸出来那一刻,到期该付的利息已经从你的净值里扣完了,不是慢慢累积的。大多数人下意识用"随用随计息"的老框架去套这个数字,结果看到估值比想象中低,第一反应是"是不是被清算风险吃了一口",其实根本没那回事,是你的会计模型用错了。这个认知差,在临近清算线时候尤其致命——你以为自己安全垫还有多少,跟系统实际算出来的,不是一回事。

窗外在施工,噪音一直没停,我也没去关窗。

所以我现在的策略很简单:每次铸 GT 之前,先自己按公式把全周期利息和手续费算一遍,再拿这个数字去对照清算阈值,而不是拿"抵押品减当前债务"去估。如果你只是短线进出、持仓不超过几天,这篇对你意义不大,利息占比小到可以忽略。但如果你打算拿满整个期限、还叠加了杠杆,这个前置扣除会直接决定你的实际安全垫比你以为的薄多少。

这个坑我没踩过,但我看见它了。你们觉得这种"前置结算"设计,对散户是更友好还是更容易被误读?评论区聊聊。

那组估值页面我还开着,没关。#termmax @TermMax
Xem bản dịch
颈椎已经酸了一阵,我没去管它,盯着@Dusk_Foundation 白皮书里那张迭代结构图看了快一个小时。 前两天我自己拿小仓位在 DuskEVM 测了几笔转账,Gas 体验、确认速度都挺顺滑,当时确实有点意外——一个主打隐私合规的链,工程细节做得这么扎实,我以为我又找到了那种"叙事和产品对得上"的项目。 然后我翻到共识机制那部分,卡住了。 大多数人对 PoS 链的理解是:谁质押多、谁出块概率高,仅此而已。但 Dusk 的 Succinct Attestation 里藏着一个更狠的问题——一轮共识里,所有迭代的出块者顺序是提前可预测的。这意味着排在后面的出块者,理论上有动机故意不参与、不广播、拖垮前几轮,等轮到自己再动手,把奖励留给自己。 这不是理论假设,是白皮书自己承认的"未来出块者激励问题"。 窗外有人在争停车位,吵了很久,然后突然安静了。 搞清楚这件事花了我比我愿意承认的更多时间——Dusk 的解法是四件套:投票奖励、按收录票数分成、下一迭代出块者禁止投票、限制最大迭代数到 50 次。本质上是在用机制设计,逼理性作恶者也没利可图。这套组合拳我在其他 PoS 链的白皮书里没怎么见过这么细的博弈论对抗。 所以我现在的策略很明确:在主网正式跑出足够长的迭代数据、能验证"拖延出块"是否真的被摁住之前,我不会把这套机制当成默认安全的东西直接下重仓判断。不是不信任团队,是任何博弈设计都要拿真实数据检验过才算数。 如果你只看 TVL 和代币价格,这篇对你意义不大。但如果你在关注链上治理和验证人经济模型,这四件套值得你自己去代码仓库里对一遍。 这种"防止理性作恶"的设计,你们觉得是工程问题还是本质上的博弈论问题?评论区聊聊。 那组迭代结构图我还留在屏幕上,没关。#dusk $DUSK @Dusk_Foundation
颈椎已经酸了一阵,我没去管它,盯着@Dusk 白皮书里那张迭代结构图看了快一个小时。

前两天我自己拿小仓位在 DuskEVM 测了几笔转账,Gas 体验、确认速度都挺顺滑,当时确实有点意外——一个主打隐私合规的链,工程细节做得这么扎实,我以为我又找到了那种"叙事和产品对得上"的项目。

然后我翻到共识机制那部分,卡住了。

大多数人对 PoS 链的理解是:谁质押多、谁出块概率高,仅此而已。但 Dusk 的 Succinct Attestation 里藏着一个更狠的问题——一轮共识里,所有迭代的出块者顺序是提前可预测的。这意味着排在后面的出块者,理论上有动机故意不参与、不广播、拖垮前几轮,等轮到自己再动手,把奖励留给自己。

这不是理论假设,是白皮书自己承认的"未来出块者激励问题"。

窗外有人在争停车位,吵了很久,然后突然安静了。

搞清楚这件事花了我比我愿意承认的更多时间——Dusk 的解法是四件套:投票奖励、按收录票数分成、下一迭代出块者禁止投票、限制最大迭代数到 50 次。本质上是在用机制设计,逼理性作恶者也没利可图。这套组合拳我在其他 PoS 链的白皮书里没怎么见过这么细的博弈论对抗。

所以我现在的策略很明确:在主网正式跑出足够长的迭代数据、能验证"拖延出块"是否真的被摁住之前,我不会把这套机制当成默认安全的东西直接下重仓判断。不是不信任团队,是任何博弈设计都要拿真实数据检验过才算数。

如果你只看 TVL 和代币价格,这篇对你意义不大。但如果你在关注链上治理和验证人经济模型,这四件套值得你自己去代码仓库里对一遍。

这种"防止理性作恶"的设计,你们觉得是工程问题还是本质上的博弈论问题?评论区聊聊。

那组迭代结构图我还留在屏幕上,没关。#dusk $DUSK @Dusk
Xem bản dịch
我今天又把@termmax 的 Curator 机制翻了一遍,看到一半突然停住了。很多人看到 Curator,第一反应都是:“帮协议管资金的人。”以前我也是这么理解的。但这次越看越觉得,这个角色可能没这么简单。 真正让我在意的,是它手里其实碰到了一个很敏感的东西:利率定价权。 Curator 不只是把钱放进池子里等收益。它可以管理资金怎么部署,设置订单参数,还能给不同市场配置借贷利率的价格曲线。说白了,就是它可以提前告诉市场:什么利率,我愿意借;什么价格,我愿意接;到什么位置以后,我就不出钱了。 这和我们熟悉的 DeFi 借贷逻辑有点不一样。像 Aave 这种模式,普通用户更多是在接受市场机制算出来的结果,利率涨了就涨了,降了就降了。TermMax 往前挪了一步:有人开始主动给资金报价。 而且真正有意思的,还不是一个 Curator。如果不同 Curator 都往同一个市场里放资金、挂不同的利率曲线,这些深度会一层层叠起来,最后形成的其实有点像一张“利率订单簿”。谁的资金便宜,谁就更靠前;谁要求的回报高,就被推到更后面。 看到这里,我脑子里冒出来一个不太舒服的问题:当越来越多固定利率流动性掌握在少数 Curator 手里,最后决定一个市场资金成本的,到底还是“市场”,还是掌握大部分流动性的那几个人? 这就比“Curator 能不能提高资本效率”有意思多了。因为一旦 Curator 的规模足够大,它就不只是资金管理人了。 它可能慢慢变成一种新的 Rate Maker。以前我们讨论 DeFi,盯的是谁控制资产、谁控制治理、谁控制流动性。以后会不会还要多问一句:谁控制了利率? 我现在反而没那么急着判断 TermMax 这套设计到底好不好。我更想盯着它继续长大以后,会不会出现几个真正有影响力的 Curator。 #termmax @termmax
我今天又把@TermMax 的 Curator 机制翻了一遍,看到一半突然停住了。很多人看到 Curator,第一反应都是:“帮协议管资金的人。”以前我也是这么理解的。但这次越看越觉得,这个角色可能没这么简单。
真正让我在意的,是它手里其实碰到了一个很敏感的东西:利率定价权。 Curator 不只是把钱放进池子里等收益。它可以管理资金怎么部署,设置订单参数,还能给不同市场配置借贷利率的价格曲线。说白了,就是它可以提前告诉市场:什么利率,我愿意借;什么价格,我愿意接;到什么位置以后,我就不出钱了。
这和我们熟悉的 DeFi 借贷逻辑有点不一样。像 Aave 这种模式,普通用户更多是在接受市场机制算出来的结果,利率涨了就涨了,降了就降了。TermMax 往前挪了一步:有人开始主动给资金报价。
而且真正有意思的,还不是一个 Curator。如果不同 Curator 都往同一个市场里放资金、挂不同的利率曲线,这些深度会一层层叠起来,最后形成的其实有点像一张“利率订单簿”。谁的资金便宜,谁就更靠前;谁要求的回报高,就被推到更后面。
看到这里,我脑子里冒出来一个不太舒服的问题:当越来越多固定利率流动性掌握在少数 Curator 手里,最后决定一个市场资金成本的,到底还是“市场”,还是掌握大部分流动性的那几个人?
这就比“Curator 能不能提高资本效率”有意思多了。因为一旦 Curator 的规模足够大,它就不只是资金管理人了。
它可能慢慢变成一种新的 Rate Maker。以前我们讨论 DeFi,盯的是谁控制资产、谁控制治理、谁控制流动性。以后会不会还要多问一句:谁控制了利率?
我现在反而没那么急着判断 TermMax 这套设计到底好不好。我更想盯着它继续长大以后,会不会出现几个真正有影响力的 Curator。
#termmax @TermMax
·
--
Giảm giá
Trong vài năm gần đây tôi xem RWA ngày càng không tin chỉ số “phát bao nhiêu Token”. Nếu thật sự muốn đánh giá một dự án có làm nghiêm túc tài chính hay không, tôi lại sẽ hỏi một câu hơi khó nghe trước: nếu ngày mai xảy ra sự cố thì xử lý thế nào? #dusk Token thông thường thì rất đơn giản, chuyển đi là xong. Nhưng chứng khoán thì không phải. Cổ tức, mua lại/thu hồi (redeem), hủy (burn/destroy), các hành vi của công ty (corporate actions), và việc chuyển nhượng bắt buộc theo yêu cầu của cơ quan tư pháp—chỉ cần bất kỳ mắt xích nào trục trặc thì câu chuyện “tài sản được đưa lên chuỗi” phía trước cũng phải làm lại từ đầu. Zedger của Dusk thì ngược lại, đã đưa thẳng các thao tác này vào logic hợp đồng của chứng khoán và RWA. Chỗ này theo tôi còn thú vị hơn rất nhiều so với việc chỉ nói “RWA lên chuỗi”. Bởi vì tài sản tài chính thật sự không phải đến lúc mua vào mới bắt đầu có giá trị; điều quan trọng nhất là đằng sau nó sẽ diễn ra điều gì—và đó mới là bài kiểm tra năng lực của hạ tầng. Ví dụ, một chứng khoán trên chuỗi cần chi trả cổ tức: hệ thống không thể chỉ biết ghi nhận một khoản chuyển tiền; cần có hủy (destroy) thì cũng không thể dựa vào dự án phát thông báo để mọi người tự xử lý; gặp yêu cầu tuân thủ phải chuyển nhượng bắt buộc thì càng không thể chỉ nói “không thể sửa đổi trên chuỗi” rồi đẩy chuyện đó ra ngoại hệ. Zedger đưa mint, burn, corporate actions và force transfer vào cùng một logic hợp đồng—về bản chất là đang xử lý toàn bộ vòng đời của tài sản. Đó cũng là điều khiến tôi khi xem dự án RWA hiện nay sẽ để ý thêm một chút. Nhiều dự án đặc biệt thích nói “mang tài sản thực lên chuỗi”. Nghe thì rất lớn, nhưng nếu tài sản mà một khi xảy ra cổ tức, mua lại, đóng băng thì vẫn phải quay về hệ thống truyền thống để đi đóng dấu tìm người—thì thực ra chỉ là bọc thêm một lớp vỏ Token cho “tài chính cũ”. Tư duy của Dusk ngược lại có phần hơi “ngốc” nhưng lại giống việc đi làm việc bẩn: trước tiên chuyển những thao tác không mấy “hấp dẫn” của tài sản tài chính—nhưng ngày nào cũng có thể xảy ra—vào trong hợp đồng. Nó thậm chí vẫn giữ khả năng để bên phát hành khởi xướng việc chuyển nhượng bắt buộc trong các trường hợp tuân thủ, đồng thời dùng cơ chế kiểm chứng bằng chứng và cơ chế vô hiệu hóa các chứng khoán đã được chi tiêu để đảm bảo tính hợp pháp. Tôi nghĩ điều thực sự đáng quan sát không phải là Dusk có thể phát hành thêm một loại RWA nữa hay không, mà là khi RWA này thật sự gặp vấn đề, liệu trên chuỗi có một thứ gì đó có thể xử lý mọi chuyện trọn vẹn hay không. Bởi vì hạ tầng tài chính thứ mà sợ nhất, từ trước đến nay, không phải là không có thị trường. Mà là lúc xảy ra sự cố thì không ai tiếp được. #dusk $DUSK @Dusk_Foundation
Trong vài năm gần đây tôi xem RWA ngày càng không tin chỉ số “phát bao nhiêu Token”. Nếu thật sự muốn đánh giá một dự án có làm nghiêm túc tài chính hay không, tôi lại sẽ hỏi một câu hơi khó nghe trước: nếu ngày mai xảy ra sự cố thì xử lý thế nào? #dusk
Token thông thường thì rất đơn giản, chuyển đi là xong. Nhưng chứng khoán thì không phải. Cổ tức, mua lại/thu hồi (redeem), hủy (burn/destroy), các hành vi của công ty (corporate actions), và việc chuyển nhượng bắt buộc theo yêu cầu của cơ quan tư pháp—chỉ cần bất kỳ mắt xích nào trục trặc thì câu chuyện “tài sản được đưa lên chuỗi” phía trước cũng phải làm lại từ đầu. Zedger của Dusk thì ngược lại, đã đưa thẳng các thao tác này vào logic hợp đồng của chứng khoán và RWA.
Chỗ này theo tôi còn thú vị hơn rất nhiều so với việc chỉ nói “RWA lên chuỗi”. Bởi vì tài sản tài chính thật sự không phải đến lúc mua vào mới bắt đầu có giá trị; điều quan trọng nhất là đằng sau nó sẽ diễn ra điều gì—và đó mới là bài kiểm tra năng lực của hạ tầng.
Ví dụ, một chứng khoán trên chuỗi cần chi trả cổ tức: hệ thống không thể chỉ biết ghi nhận một khoản chuyển tiền; cần có hủy (destroy) thì cũng không thể dựa vào dự án phát thông báo để mọi người tự xử lý; gặp yêu cầu tuân thủ phải chuyển nhượng bắt buộc thì càng không thể chỉ nói “không thể sửa đổi trên chuỗi” rồi đẩy chuyện đó ra ngoại hệ.
Zedger đưa mint, burn, corporate actions và force transfer vào cùng một logic hợp đồng—về bản chất là đang xử lý toàn bộ vòng đời của tài sản.
Đó cũng là điều khiến tôi khi xem dự án RWA hiện nay sẽ để ý thêm một chút.
Nhiều dự án đặc biệt thích nói “mang tài sản thực lên chuỗi”. Nghe thì rất lớn, nhưng nếu tài sản mà một khi xảy ra cổ tức, mua lại, đóng băng thì vẫn phải quay về hệ thống truyền thống để đi đóng dấu tìm người—thì thực ra chỉ là bọc thêm một lớp vỏ Token cho “tài chính cũ”.
Tư duy của Dusk ngược lại có phần hơi “ngốc” nhưng lại giống việc đi làm việc bẩn: trước tiên chuyển những thao tác không mấy “hấp dẫn” của tài sản tài chính—nhưng ngày nào cũng có thể xảy ra—vào trong hợp đồng. Nó thậm chí vẫn giữ khả năng để bên phát hành khởi xướng việc chuyển nhượng bắt buộc trong các trường hợp tuân thủ, đồng thời dùng cơ chế kiểm chứng bằng chứng và cơ chế vô hiệu hóa các chứng khoán đã được chi tiêu để đảm bảo tính hợp pháp.
Tôi nghĩ điều thực sự đáng quan sát không phải là Dusk có thể phát hành thêm một loại RWA nữa hay không, mà là khi RWA này thật sự gặp vấn đề, liệu trên chuỗi có một thứ gì đó có thể xử lý mọi chuyện trọn vẹn hay không.
Bởi vì hạ tầng tài chính thứ mà sợ nhất, từ trước đến nay, không phải là không có thị trường.
Mà là lúc xảy ra sự cố thì không ai tiếp được. #dusk $DUSK @Dusk
Đèn chưa bật, chỉ nhờ ánh sáng từ màn hình mà tôi lật đi lật lại vài lần tài liệu cơ chế của TermMax. Càng đọc càng thấy có chỗ khá phi trực giác—DeFi đã hô “lãi suất cố định” suốt nhiều năm, nhưng thứ thực sự khiến mọi thứ kẹt lại thì chưa bao giờ là nhu cầu. Trước đây tôi cũng từng tự giày vò với đòn bẩy vòng lặp. Thế chấp, vay mượn, hoán đổi vị thế, rồi lại thế chấp—các bước nhiều đến mức như đang bê gạch trên chuỗi. Lúc thị trường thuận lợi thì thấy mình thông minh; đến khi xu hướng đảo chiều, tôi mới nhận ra rủi ro lớn nhất không phải là sai hướng, mà là lãi suất và thanh lý cùng lúc mất kiểm soát. TermMax khiến tôi dừng lại để nhìn không phải vì mấy chữ “đòn bẩy một cú chạm”, mà là thiết kế thị trường lãi suất cố định nằm phía sau. Nhiều người nghĩ rằng, vấn đề của DeFi lãi suất cố định chỉ là thiếu một sản phẩm. Thực ra không phải. Điều thật sự khó là ai sẽ cung cấp mức giá hợp lý cho thị trường này. AMM truyền thống thích một đường cong “cứng”, nhưng thị trường cho vay không phải là swap. Chi phí vốn, kỳ hạn, khẩu vị rủi ro thay đổi mỗi ngày. TermMax trao quyền tạo lập thị trường cho “người phụ trách triển lãm”, thông qua Range Order AMM để họ cấu hình khoảng APR mục tiêu, thay vì chỉ treo một mức giá đơn giản. Việc này cũng giống như mở sòng bạc, nhưng chủ sòng bạc không quyết định tỷ lệ—người hiểu rủi ro mới là người điều chỉnh tỷ lệ. Trong whitepaper có một con số tôi nhớ mãi: TermMax đã được triển khai trên nhiều mạng EVM, đạt đỉnh 64M+ USD TVL. Ngoài cửa sổ bắt đầu mưa, nhưng tôi không đóng cửa sổ. Vì vậy, khi bây giờ tôi xem các giao thức dạng này, tôi sẽ không xem trước APY cao cỡ nào—mà xem ai là người gánh chi phí khi định giá sai. Nếu lãi suất cố định chỉ là lớp bọc, thì rốt cuộc người dùng vẫn là người “làm túi” cho phần rủi ro đó; nhưng nếu thị trường thật sự hình thành, thì ngưỡng để tổ chức tham gia DeFi có thể sẽ được viết lại. Nếu bạn chỉ muốn lướt sóng đuổi trend ngắn hạn, bài này không có ích gì. Nhưng nếu bạn đang chờ cơ hội ở lớp hạ tầng DeFi vòng tới, thì điều cần theo dõi là: ai có thể biến “câu chuyện về lợi nhuận” thành “định giá rủi ro”. Chuyện lãi suất cố định rốt cuộc là một thị trường tiếp theo, hay chỉ là một câu chuyện mà chẳng ai chịu mua? Câu trả lời vẫn chưa có. #termmax @termmax
Đèn chưa bật, chỉ nhờ ánh sáng từ màn hình mà tôi lật đi lật lại vài lần tài liệu cơ chế của TermMax. Càng đọc càng thấy có chỗ khá phi trực giác—DeFi đã hô “lãi suất cố định” suốt nhiều năm, nhưng thứ thực sự khiến mọi thứ kẹt lại thì chưa bao giờ là nhu cầu.
Trước đây tôi cũng từng tự giày vò với đòn bẩy vòng lặp. Thế chấp, vay mượn, hoán đổi vị thế, rồi lại thế chấp—các bước nhiều đến mức như đang bê gạch trên chuỗi. Lúc thị trường thuận lợi thì thấy mình thông minh; đến khi xu hướng đảo chiều, tôi mới nhận ra rủi ro lớn nhất không phải là sai hướng, mà là lãi suất và thanh lý cùng lúc mất kiểm soát.
TermMax khiến tôi dừng lại để nhìn không phải vì mấy chữ “đòn bẩy một cú chạm”, mà là thiết kế thị trường lãi suất cố định nằm phía sau.
Nhiều người nghĩ rằng, vấn đề của DeFi lãi suất cố định chỉ là thiếu một sản phẩm.
Thực ra không phải.
Điều thật sự khó là ai sẽ cung cấp mức giá hợp lý cho thị trường này.
AMM truyền thống thích một đường cong “cứng”, nhưng thị trường cho vay không phải là swap. Chi phí vốn, kỳ hạn, khẩu vị rủi ro thay đổi mỗi ngày. TermMax trao quyền tạo lập thị trường cho “người phụ trách triển lãm”, thông qua Range Order AMM để họ cấu hình khoảng APR mục tiêu, thay vì chỉ treo một mức giá đơn giản.
Việc này cũng giống như mở sòng bạc, nhưng chủ sòng bạc không quyết định tỷ lệ—người hiểu rủi ro mới là người điều chỉnh tỷ lệ.
Trong whitepaper có một con số tôi nhớ mãi: TermMax đã được triển khai trên nhiều mạng EVM, đạt đỉnh 64M+ USD TVL.
Ngoài cửa sổ bắt đầu mưa, nhưng tôi không đóng cửa sổ.
Vì vậy, khi bây giờ tôi xem các giao thức dạng này, tôi sẽ không xem trước APY cao cỡ nào—mà xem ai là người gánh chi phí khi định giá sai. Nếu lãi suất cố định chỉ là lớp bọc, thì rốt cuộc người dùng vẫn là người “làm túi” cho phần rủi ro đó; nhưng nếu thị trường thật sự hình thành, thì ngưỡng để tổ chức tham gia DeFi có thể sẽ được viết lại.
Nếu bạn chỉ muốn lướt sóng đuổi trend ngắn hạn, bài này không có ích gì.
Nhưng nếu bạn đang chờ cơ hội ở lớp hạ tầng DeFi vòng tới, thì điều cần theo dõi là: ai có thể biến “câu chuyện về lợi nhuận” thành “định giá rủi ro”.
Chuyện lãi suất cố định rốt cuộc là một thị trường tiếp theo, hay chỉ là một câu chuyện mà chẳng ai chịu mua? Câu trả lời vẫn chưa có. #termmax @TermMax
Xem bản dịch
这几年看过不少 RWA 项目,刚开始我也被“万亿资产上链”这种叙事吸引过。股票上链、债券上链、基金份额 Token 化,听起来像是下一轮大机会。 但看得越多,越觉得有个地方不对。 很多项目把 Token 发出来了,故事也讲完了。可真正的钱,并没有跟着进来。 后来我才意识到,RWA 最大的问题可能从来不是技术。链能不能跑、手续费够不够低、合约能不能写,这些其实都是相对容易解决的问题。 真正难的是传统金融那条几十年形成的责任链:谁发行,谁确认投资者资格,谁处理资产转让限制,谁在监管需要时提供证明。金融机构不是不想上链,它们怕的是上链以后,原来的责任边界消失。 因为金融不是 DeFi 挖矿,错一次不是亏几个点收益,而是谁来承担法律、合规和信任成本的问题。 这也是我重新看 Dusk 和欧盟持牌机构合作方向时,觉得有意思的地方。它没有试图喊一句“我们要颠覆传统金融”,然后重新造一个世界,而是在补传统金融进入链上最缺的几个接口:身份验证、合规规则、选择性披露、隐私保护,以及面向代币化资产的发行和交易流程。 说白了,机构需要的不是一条完全透明的链。它需要的是:该公开的时候能公开,该验证的时候能验证,但不需要把所有商业信息裸奔给全世界。 这可能也是 Dusk 更值得看的地方。它做的不是简单把资产变成 Token,而是在尝试让旧金融体系里的规则,有机会在链上继续运行。 过去几年,币圈最喜欢讲“颠覆”。但真正的大资金迁移,很多时候不是推倒重来,而是先修一座让旧系统敢走过来的桥。 当然,桥修好了只是开始。最后的问题不是链能不能承载金融,而是第一批真正的大资金,愿不愿意把责任和资金一起搬上来。#dusk $DUSK @Dusk_Foundation $BTC
这几年看过不少 RWA 项目,刚开始我也被“万亿资产上链”这种叙事吸引过。股票上链、债券上链、基金份额 Token 化,听起来像是下一轮大机会。
但看得越多,越觉得有个地方不对。
很多项目把 Token 发出来了,故事也讲完了。可真正的钱,并没有跟着进来。
后来我才意识到,RWA 最大的问题可能从来不是技术。链能不能跑、手续费够不够低、合约能不能写,这些其实都是相对容易解决的问题。
真正难的是传统金融那条几十年形成的责任链:谁发行,谁确认投资者资格,谁处理资产转让限制,谁在监管需要时提供证明。金融机构不是不想上链,它们怕的是上链以后,原来的责任边界消失。
因为金融不是 DeFi 挖矿,错一次不是亏几个点收益,而是谁来承担法律、合规和信任成本的问题。
这也是我重新看 Dusk 和欧盟持牌机构合作方向时,觉得有意思的地方。它没有试图喊一句“我们要颠覆传统金融”,然后重新造一个世界,而是在补传统金融进入链上最缺的几个接口:身份验证、合规规则、选择性披露、隐私保护,以及面向代币化资产的发行和交易流程。
说白了,机构需要的不是一条完全透明的链。它需要的是:该公开的时候能公开,该验证的时候能验证,但不需要把所有商业信息裸奔给全世界。
这可能也是 Dusk 更值得看的地方。它做的不是简单把资产变成 Token,而是在尝试让旧金融体系里的规则,有机会在链上继续运行。
过去几年,币圈最喜欢讲“颠覆”。但真正的大资金迁移,很多时候不是推倒重来,而是先修一座让旧系统敢走过来的桥。
当然,桥修好了只是开始。最后的问题不是链能不能承载金融,而是第一批真正的大资金,愿不愿意把责任和资金一起搬上来。#dusk $DUSK @Dusk $BTC
Ngày mai alpha rất có khả năng sẽ lên DGrid AI($DGAI),đã được triển khai trên chuỗi BSC rồi. Tôi dự đoán điểm số vào khoảng 225-230. Dạo này tân coin nhiều hơn rồi, có vẻ ổn hơn đấy! Trước đây khi xem từ “Neobroker”, phản ứng đầu tiên của tôi đều là: liệu đây có phải lại một cổng giao dịch trên chuỗi nữa không? Cho đến khi tôi tháo rời thiết kế của @Dusk_Foundation Trade, tôi mới nhận ra mình đã nhìn vấn đề quá nông. Trong tài chính truyền thống, mua bán một tài sản không hề đơn giản như bấm một nút. Bên phát hành, sàn giao dịch, nhà đầu tư, bên lưu ký, hệ thống thanh toán—mỗi khâu đều có cơ sở dữ liệu và các quy tắc riêng. Tài sản được niêm yết rồi, nhưng việc thẩm định tư cách, các hạn chế chuyển nhượng, yêu cầu công bố thông tin, quy trình thanh toán bù trừ… vẫn nằm rải rác trong nhiều hệ thống khác nhau. Vì vậy, nhiều cái gọi là “đưa tài sản lên chuỗi” về bản chất chỉ là chuyển “trang giao dịch” lên blockchain. Điều thật sự rắc rối nằm ở lớp phía dưới trang giao dịch đó. Dusk Trade làm tôi hứng thú ở chỗ nó không định vị mình như một giao diện giao dịch đơn thuần, mà đang cố gắng nối liền toàn bộ quy trình thị trường của tài sản tài chính được token hóa: nhà đầu tư tìm thấy tài sản, kết nối ví, hoàn tất kiểm tra điều kiện tham gia, mua bán tài sản, rồi phối hợp chuyển nhượng tài sản và thanh toán bù trừ. Ý tưởng này giống như việc thiết kế lại những quy trình “không nhìn thấy” trong back-office của các công ty chứng khoán truyền thống thành các workflow trên chuỗi. Tất nhiên, trong mọi việc, phần khó không phải là “có giao dịch được hay không”. Giao dịch bản thân thì dễ. Khó là sau khi một nhà đầu tư đủ điều kiện bước vào, hệ thống làm sao biết anh ta có quyền nắm giữ hay không? Khi chuyển nhượng tài sản, điều kiện hạn chế sẽ được thực thi như thế nào? Thông tin nào cần công khai, thông tin nào chỉ được cho bên được ủy quyền xem? Dusk Trade giống như đang vận hành lớp thao tác thị trường cho tài sản được token hóa. Nó không chỉ đơn giản là biến chứng khoán thành Token rồi chờ thị trường giao dịch, mà đang cố gắng trả lời một câu hỏi khác: nếu tài sản, danh tính, quyền giao dịch và quy tắc thanh toán vốn vận hành trong cùng một môi trường, thì thị trường tài chính có thể giảm bớt sự phối hợp thủ công đến mức nào? Nhưng vấn đề cũng nằm ở đó—thiết kế lại workflow tài chính còn khó hơn việc phát hành một Token. Liệu thị trường cuối cùng sẽ thưởng cho những cổng vào tiện hơn, hay sẽ thưởng cho hạ tầng đầy đủ hơn? #dusk $DUSK @Dusk_Foundation $BTC
Ngày mai alpha rất có khả năng sẽ lên DGrid AI($DGAI),đã được triển khai trên chuỗi BSC rồi. Tôi dự đoán điểm số vào khoảng 225-230. Dạo này tân coin nhiều hơn rồi, có vẻ ổn hơn đấy!

Trước đây khi xem từ “Neobroker”, phản ứng đầu tiên của tôi đều là: liệu đây có phải lại một cổng giao dịch trên chuỗi nữa không? Cho đến khi tôi tháo rời thiết kế của @Dusk Trade, tôi mới nhận ra mình đã nhìn vấn đề quá nông.

Trong tài chính truyền thống, mua bán một tài sản không hề đơn giản như bấm một nút. Bên phát hành, sàn giao dịch, nhà đầu tư, bên lưu ký, hệ thống thanh toán—mỗi khâu đều có cơ sở dữ liệu và các quy tắc riêng. Tài sản được niêm yết rồi, nhưng việc thẩm định tư cách, các hạn chế chuyển nhượng, yêu cầu công bố thông tin, quy trình thanh toán bù trừ… vẫn nằm rải rác trong nhiều hệ thống khác nhau.

Vì vậy, nhiều cái gọi là “đưa tài sản lên chuỗi” về bản chất chỉ là chuyển “trang giao dịch” lên blockchain.

Điều thật sự rắc rối nằm ở lớp phía dưới trang giao dịch đó.

Dusk Trade làm tôi hứng thú ở chỗ nó không định vị mình như một giao diện giao dịch đơn thuần, mà đang cố gắng nối liền toàn bộ quy trình thị trường của tài sản tài chính được token hóa: nhà đầu tư tìm thấy tài sản, kết nối ví, hoàn tất kiểm tra điều kiện tham gia, mua bán tài sản, rồi phối hợp chuyển nhượng tài sản và thanh toán bù trừ.

Ý tưởng này giống như việc thiết kế lại những quy trình “không nhìn thấy” trong back-office của các công ty chứng khoán truyền thống thành các workflow trên chuỗi. Tất nhiên, trong mọi việc, phần khó không phải là “có giao dịch được hay không”.

Giao dịch bản thân thì dễ. Khó là sau khi một nhà đầu tư đủ điều kiện bước vào, hệ thống làm sao biết anh ta có quyền nắm giữ hay không? Khi chuyển nhượng tài sản, điều kiện hạn chế sẽ được thực thi như thế nào? Thông tin nào cần công khai, thông tin nào chỉ được cho bên được ủy quyền xem?

Dusk Trade giống như đang vận hành lớp thao tác thị trường cho tài sản được token hóa. Nó không chỉ đơn giản là biến chứng khoán thành Token rồi chờ thị trường giao dịch, mà đang cố gắng trả lời một câu hỏi khác: nếu tài sản, danh tính, quyền giao dịch và quy tắc thanh toán vốn vận hành trong cùng một môi trường, thì thị trường tài chính có thể giảm bớt sự phối hợp thủ công đến mức nào?

Nhưng vấn đề cũng nằm ở đó—thiết kế lại workflow tài chính còn khó hơn việc phát hành một Token. Liệu thị trường cuối cùng sẽ thưởng cho những cổng vào tiện hơn, hay sẽ thưởng cho hạ tầng đầy đủ hơn? #dusk $DUSK @Dusk $BTC
Xem bản dịch
我今天第一次看DuskEVM技术文档的时候,第一反应其实很普通:又一个 EVM。Solidity、Foundry、Hardhat、viem、ethers,连钱包都能接,这些对开发者当然友好,但如果只是把以太坊那套东西搬到另一条链上,我没觉得有什么好研究的。 后来我把架构图重新拆了一遍,才发现自己一开始看反了。DuskEVM真正想做的,可能不是把@Dusk_Foundation 变成另一条 Ethereum,而是让开发者继续用熟悉的 EVM工作流,同时把执行背后的结算和数据底座换掉。 交易先在 DuskEVM 的 Sequencer 排序、执行,再由 Batcher 把数据发布到 DuskDS,状态承诺和故障证明继续把这部分状态接到 Dusk 的结算层。换句话说,EVM负责“把应用跑起来”,DuskDS负责“这笔状态最终怎么被确认”。 这个区别看起来只是架构图上的几根线,放到金融应用里就完全不一样了。因为交易被快速包含,不等于已经完成最终结算。尤其是 EVM 和 Dusk L1 之间要转移价值的时候,不能简单看着页面上的时间过去了,就默认事情结束。 我以前用 EVM,确实很容易形成这个肌肉记忆:交易成功,差不多就完了。DuskEVM反而逼你把“执行完成”和“最终结算”分开看。 我又回头看了一遍那张图。 这时候 DuskVM 的存在也就没那么奇怪了:需要 Solidity、EVM钱包和现有工具的应用,可以走 DuskEVM;需要直接贴近 Dusk L1 的交易模型、隐私或 ZK 能力,则有另一套执行环境。 所以我现在觉得,DuskEVM最值得看的不是“兼容了多少以太坊工具”,而是它试图解决一个更麻烦的问题:怎么让开发者不用重新学一套东西,却把应用带进一个不同于普通 EVM 链的隐私金融结算体系。 但这也留下了真正的问题:开发门槛降低了,架构理解的门槛有没有反而升高?这件事,主网跑起来以后才知道。#dusk $DUSK @Dusk_Foundation
我今天第一次看DuskEVM技术文档的时候,第一反应其实很普通:又一个 EVM。Solidity、Foundry、Hardhat、viem、ethers,连钱包都能接,这些对开发者当然友好,但如果只是把以太坊那套东西搬到另一条链上,我没觉得有什么好研究的。
后来我把架构图重新拆了一遍,才发现自己一开始看反了。DuskEVM真正想做的,可能不是把@Dusk 变成另一条 Ethereum,而是让开发者继续用熟悉的 EVM工作流,同时把执行背后的结算和数据底座换掉。
交易先在 DuskEVM 的 Sequencer 排序、执行,再由 Batcher 把数据发布到 DuskDS,状态承诺和故障证明继续把这部分状态接到 Dusk 的结算层。换句话说,EVM负责“把应用跑起来”,DuskDS负责“这笔状态最终怎么被确认”。
这个区别看起来只是架构图上的几根线,放到金融应用里就完全不一样了。因为交易被快速包含,不等于已经完成最终结算。尤其是 EVM 和 Dusk L1 之间要转移价值的时候,不能简单看着页面上的时间过去了,就默认事情结束。
我以前用 EVM,确实很容易形成这个肌肉记忆:交易成功,差不多就完了。DuskEVM反而逼你把“执行完成”和“最终结算”分开看。
我又回头看了一遍那张图。
这时候 DuskVM 的存在也就没那么奇怪了:需要 Solidity、EVM钱包和现有工具的应用,可以走 DuskEVM;需要直接贴近 Dusk L1 的交易模型、隐私或 ZK 能力,则有另一套执行环境。
所以我现在觉得,DuskEVM最值得看的不是“兼容了多少以太坊工具”,而是它试图解决一个更麻烦的问题:怎么让开发者不用重新学一套东西,却把应用带进一个不同于普通 EVM 链的隐私金融结算体系。
但这也留下了真正的问题:开发门槛降低了,架构理解的门槛有没有反而升高?这件事,主网跑起来以后才知道。#dusk $DUSK @Dusk
Xem bản dịch
今天把关于@Dusk_Foundation 隐私的材料又扒了一遍。我突然想到一个挺反直觉的问题:金融机构为什么要上公链?如果答案是“为了透明”,那我觉得这件事从一开始就有点站不住。 一家机构不会希望竞争对手知道自己的持仓,一笔大额交易也不应该把交易策略、余额和交易对手全部摊在公共账本上。做市商更不可能一边报价,一边把自己的牌全翻出来。所以金融真正需要的,可能从来不是“透明”或者“隐私”二选一,而是谁可以在什么时候看到什么。 这也是我重新看 Dusk 后觉得有意思的地方。普通公链的逻辑很简单:交易发生了,所有人都能看。Dusk 试图把这个逻辑改成:交易可以保持私密,但需要证明的时候,能够证明给正确的人看。 比如一个机构需要满足 KYC/AML 要求,不一定非要把身份和交易细节全部暴露出来。通过零知识合规,可以证明“我符合要求”,而不是把“我是谁、我做了什么”全部交出去。 更关键的是,监管并没有因此被挡在门外。Dusk强调的选择性披露,本质上是在给隐私加权限边界:普通市场参与者不需要看到的东西,可以继续保持机密;监管机构、交易场所或者授权方需要验证的信息,则可以获得相应的证明。 我觉得“可编程隐私”这四个字,真正有意思的地方就在这里。它不是把隐私做成一堵墙,而是把隐私做成一扇门。谁能开、什么时候开、能看到多少,都可以成为工作流的一部分。 这对受监管金融尤其重要。因为合规真正麻烦的地方,从来不是“有没有数据”,而是数据该给谁看、什么时候给、给到什么程度。 我现在反而觉得,Dusk做的不是让金融“变得不透明”,而是让透明这件事终于有了权限控制。 这个区别,看起来很小,可能决定了公链到底能不能进入真正的金融市场。#dusk $DUSK @Dusk_Foundation
今天把关于@Dusk 隐私的材料又扒了一遍。我突然想到一个挺反直觉的问题:金融机构为什么要上公链?如果答案是“为了透明”,那我觉得这件事从一开始就有点站不住。

一家机构不会希望竞争对手知道自己的持仓,一笔大额交易也不应该把交易策略、余额和交易对手全部摊在公共账本上。做市商更不可能一边报价,一边把自己的牌全翻出来。所以金融真正需要的,可能从来不是“透明”或者“隐私”二选一,而是谁可以在什么时候看到什么。

这也是我重新看 Dusk 后觉得有意思的地方。普通公链的逻辑很简单:交易发生了,所有人都能看。Dusk 试图把这个逻辑改成:交易可以保持私密,但需要证明的时候,能够证明给正确的人看。

比如一个机构需要满足 KYC/AML 要求,不一定非要把身份和交易细节全部暴露出来。通过零知识合规,可以证明“我符合要求”,而不是把“我是谁、我做了什么”全部交出去。

更关键的是,监管并没有因此被挡在门外。Dusk强调的选择性披露,本质上是在给隐私加权限边界:普通市场参与者不需要看到的东西,可以继续保持机密;监管机构、交易场所或者授权方需要验证的信息,则可以获得相应的证明。

我觉得“可编程隐私”这四个字,真正有意思的地方就在这里。它不是把隐私做成一堵墙,而是把隐私做成一扇门。谁能开、什么时候开、能看到多少,都可以成为工作流的一部分。

这对受监管金融尤其重要。因为合规真正麻烦的地方,从来不是“有没有数据”,而是数据该给谁看、什么时候给、给到什么程度。

我现在反而觉得,Dusk做的不是让金融“变得不透明”,而是让透明这件事终于有了权限控制。

这个区别,看起来很小,可能决定了公链到底能不能进入真正的金融市场。#dusk $DUSK @Dusk
Hôm nay rốt cuộc bàn nhiệm vụ cũng có việc rồi! Tôi lập tức bắt đầu nghiên cứu @Dusk_Foundation , trước tiên đọc xong hai tài liệu về phát hành gốc của Dusk. Xem xong, tôi ngược lại thấy cách nói “RWA đưa lên chuỗi” có vẻ hơi nhẹ. Trước đây tôi cũng hiểu việc token hóa như sau: biến cổ phiếu, trái phiếu, chứng chỉ quỹ thành Token, rồi giao dịch chúng trên chuỗi. Cách hiểu đó không sai, nhưng nó thực chất chỉ giải quyết vấn đề “tài sản được biểu diễn như thế nào”. Cái rắc rối thật sự nằm ở chuỗi vấn đề phía sau: ai có thể nắm giữ? khi nào thì được tính là đã chuyển giao quyền sở hữu? tài sản và tiền có thể kết toán đồng thời không? các đối tác giao dịch và cơ quan quản lý nên thấy gì? những thông tin nào lại bắt buộc phải giữ bí mật? Đây cũng là điểm khiến tôi thấy hướng đi của Dusk thú vị. Nó không dừng trọng tâm ở ba chữ “Token hóa”, mà tách token hóa và phát hành gốc ra làm hai phần. Token hóa, về bản chất, vẫn là khoác cho tài sản ngoài chuỗi một lớp biểu diễn trên chuỗi; tài sản nền tảng, lưu ký, đăng ký, kết toán có thể vẫn nằm trong hệ thống truyền thống. Còn phát hành gốc thì hoàn toàn khác—bản thân tài sản được tạo và quản lý ngay trên chuỗi; việc phát hành, chuyển nhượng, cung cấp dịch vụ, kết toán đều có thể được thiết kế xoay quanh cùng một sổ cái. Giá trị ở đây không phải là “thiếu đi một lớp Token”. Mà là “thiếu đi một số khe hở” nơi tài sản trên chuỗi và hệ thống ngoài chuỗi liên tục phải đối soát, bàn giao. Tính tất định và tính cuối cùng trong giao dịch của Dusk, giao dịch riêng tư, công bố chọn lọc và các quy tắc tuân thủ—đúng là đang bù vào lớp “hạ tầng” nằm ngoài bản thân tài sản. Đặc biệt trong tài chính được quản lý, minh bạch công khai không đồng nghĩa với việc có thể dùng được. Các tổ chức không thể đem toàn bộ vị thế, đối tác giao dịch và số dư ra rải thẳng trên sổ cái công cộng, nhưng cơ quan giám sát lại phải có khả năng xác minh khi cần. Vì vậy bây giờ khi xem RWA, tôi sẽ hỏi thêm một câu: tài sản này chỉ đơn giản là “được chuyển lên chuỗi”, hay toàn bộ vòng đời của nó thật sự bắt đầu vận hành xoay quanh chuỗi? Hai câu trả lời này, nhìn thì chỉ khác nhau một bước, nhưng trên thực tế có thể là hai bộ hạ tầng thị trường khác nhau. Thứ Dusk thật sự muốn cược có lẽ nằm ở đây. #dusk $DUSK @Dusk_Foundation
Hôm nay rốt cuộc bàn nhiệm vụ cũng có việc rồi! Tôi lập tức bắt đầu nghiên cứu @Dusk , trước tiên đọc xong hai tài liệu về phát hành gốc của Dusk. Xem xong, tôi ngược lại thấy cách nói “RWA đưa lên chuỗi” có vẻ hơi nhẹ.
Trước đây tôi cũng hiểu việc token hóa như sau: biến cổ phiếu, trái phiếu, chứng chỉ quỹ thành Token, rồi giao dịch chúng trên chuỗi. Cách hiểu đó không sai, nhưng nó thực chất chỉ giải quyết vấn đề “tài sản được biểu diễn như thế nào”.
Cái rắc rối thật sự nằm ở chuỗi vấn đề phía sau: ai có thể nắm giữ? khi nào thì được tính là đã chuyển giao quyền sở hữu? tài sản và tiền có thể kết toán đồng thời không? các đối tác giao dịch và cơ quan quản lý nên thấy gì? những thông tin nào lại bắt buộc phải giữ bí mật?
Đây cũng là điểm khiến tôi thấy hướng đi của Dusk thú vị.
Nó không dừng trọng tâm ở ba chữ “Token hóa”, mà tách token hóa và phát hành gốc ra làm hai phần. Token hóa, về bản chất, vẫn là khoác cho tài sản ngoài chuỗi một lớp biểu diễn trên chuỗi; tài sản nền tảng, lưu ký, đăng ký, kết toán có thể vẫn nằm trong hệ thống truyền thống. Còn phát hành gốc thì hoàn toàn khác—bản thân tài sản được tạo và quản lý ngay trên chuỗi; việc phát hành, chuyển nhượng, cung cấp dịch vụ, kết toán đều có thể được thiết kế xoay quanh cùng một sổ cái.
Giá trị ở đây không phải là “thiếu đi một lớp Token”.
Mà là “thiếu đi một số khe hở” nơi tài sản trên chuỗi và hệ thống ngoài chuỗi liên tục phải đối soát, bàn giao.
Tính tất định và tính cuối cùng trong giao dịch của Dusk, giao dịch riêng tư, công bố chọn lọc và các quy tắc tuân thủ—đúng là đang bù vào lớp “hạ tầng” nằm ngoài bản thân tài sản. Đặc biệt trong tài chính được quản lý, minh bạch công khai không đồng nghĩa với việc có thể dùng được. Các tổ chức không thể đem toàn bộ vị thế, đối tác giao dịch và số dư ra rải thẳng trên sổ cái công cộng, nhưng cơ quan giám sát lại phải có khả năng xác minh khi cần.
Vì vậy bây giờ khi xem RWA, tôi sẽ hỏi thêm một câu: tài sản này chỉ đơn giản là “được chuyển lên chuỗi”, hay toàn bộ vòng đời của nó thật sự bắt đầu vận hành xoay quanh chuỗi?
Hai câu trả lời này, nhìn thì chỉ khác nhau một bước, nhưng trên thực tế có thể là hai bộ hạ tầng thị trường khác nhau.
Thứ Dusk thật sự muốn cược có lẽ nằm ở đây. #dusk $DUSK @Dusk
Hôm nay tôi thấy mọi người trong nhóm bàn về cơ chế “phạt tịch thu” liên quan đến @babylonlabs_io . Ai cũng tập trung vào đúng cái kết quả “phạt tịch thu” đó. Nhưng tôi muốn nhìn theo một góc khác để làm rõ: nếu ngưỡng phạt tịch thu không phải là 1/3 mà là 1/2 hoặc 1/4 thì chuyện gì sẽ xảy ra? Vì sao lại là 1/3? Lý do cốt lõi của thiết kế này nằm ở logic của lý thuyết dung lỗi Byzantine (BFT) — trên một chuỗi PoS, cần có 2/3 phiếu bầu của các người xác thực để xác nhận một khối. Nếu tỷ lệ gian ác thấp hơn 1/3 thì an ninh của chuỗi sẽ không bị phá vỡ; nếu tỷ lệ thành thật cao hơn 2/3 thì hiệu suất hoạt động của chuỗi vẫn được duy trì. Cộng 1/3 và 2/3 đúng bằng toàn bộ — không phải ngẫu nhiên, mà là ranh giới của mật mã. Thế còn nếu kẹt ở mức 1/2? Bề ngoài có vẻ “công bằng” hơn — chỉ khi hơn một nửa gian ác mới bị phạt. Nhưng rắc rối nằm ở chỗ: kẻ tấn công chỉ cần tập hợp vượt quá 1/3 quyền lợi (stake) là đã có thể ngăn chặn việc xác nhận khối cuối cùng và quá trình kiểm duyệt giao dịch. Kẹt ở 1/2 nghĩa là “mối đe dọa đã xảy ra, chuỗi không còn vận hành bình thường được”, nhưng cơ chế phạt tịch thu vẫn chưa kích hoạt. Đợi tới lúc đủ 1/2 thì đã quá muộn. Ngược lại, nếu kẹt ở mức 1/4 thì sao? Trông có vẻ “nghiêm” hơn — chỉ cần ít gian ác hơn cũng có thể kích hoạt phạt tịch thu. Nhưng cái giá là gì? Có thể xảy ra trừng phạt nhầm những nút số ít không hề thông đồng. Các nút ở mức 1/4 có thể chỉ bị hiểu nhầm là “gian ác” do độ trễ mạng hoặc sự cố tạm thời, kết quả là BTC bị thế chấp bị tiêu hủy. Nếu đặt ngưỡng quá thấp, việc trừng phạt không còn nhằm vào “kẻ gian ác” mà có thể trừng phạt “người xui xẻo”. Tôi cho rằng việc đặt đường ranh phạt tịch thu ở 1/3 là vừa đúng với “biên an toàn” của lý thuyết BFT — thấp hơn ngưỡng đó thì chuỗi vẫn có thể vận hành bình thường, không cần phạt; vượt qua ngưỡng đó thì mối đe dọa đã trở nên hiện thực, và việc phạt tịch thu mới thực sự có ý nghĩa. Giao thức của Babylon thậm chí còn hỗ trợ hình thức phạt tịch thu một phần: chỉ một phần BTC bị tiêu hủy, phần còn lại được hoàn trả cho người đặt thế chấp. 1/3 là “đường ranh trách nhiệm”, không phải “số lượng bị tiêu hủy”. Nhiều người trộn lẫn hai khái niệm này. Vì vậy, quan điểm của tôi là ngưỡng này đáng để suy nghĩ hơn chính hành động “phạt tịch thu”. Phần lớn mọi người chỉ thấy kết luận bề nổi rằng “kẻ gian ác phải trả giá”, nhưng không nhận ra rằng con số 1/3 bản thân nó là bộ khung toán học của toàn bộ chứng minh an toàn. Đặt ngưỡng sai vị trí thì hoặc là khả năng răn đe bị vô hiệu, hoặc là trừng phạt nhầm người vô tội. #baby $BABY
Hôm nay tôi thấy mọi người trong nhóm bàn về cơ chế “phạt tịch thu” liên quan đến @BabylonLabs_io . Ai cũng tập trung vào đúng cái kết quả “phạt tịch thu” đó. Nhưng tôi muốn nhìn theo một góc khác để làm rõ: nếu ngưỡng phạt tịch thu không phải là 1/3 mà là 1/2 hoặc 1/4 thì chuyện gì sẽ xảy ra?

Vì sao lại là 1/3? Lý do cốt lõi của thiết kế này nằm ở logic của lý thuyết dung lỗi Byzantine (BFT) — trên một chuỗi PoS, cần có 2/3 phiếu bầu của các người xác thực để xác nhận một khối. Nếu tỷ lệ gian ác thấp hơn 1/3 thì an ninh của chuỗi sẽ không bị phá vỡ; nếu tỷ lệ thành thật cao hơn 2/3 thì hiệu suất hoạt động của chuỗi vẫn được duy trì. Cộng 1/3 và 2/3 đúng bằng toàn bộ — không phải ngẫu nhiên, mà là ranh giới của mật mã.

Thế còn nếu kẹt ở mức 1/2? Bề ngoài có vẻ “công bằng” hơn — chỉ khi hơn một nửa gian ác mới bị phạt. Nhưng rắc rối nằm ở chỗ: kẻ tấn công chỉ cần tập hợp vượt quá 1/3 quyền lợi (stake) là đã có thể ngăn chặn việc xác nhận khối cuối cùng và quá trình kiểm duyệt giao dịch. Kẹt ở 1/2 nghĩa là “mối đe dọa đã xảy ra, chuỗi không còn vận hành bình thường được”, nhưng cơ chế phạt tịch thu vẫn chưa kích hoạt. Đợi tới lúc đủ 1/2 thì đã quá muộn.

Ngược lại, nếu kẹt ở mức 1/4 thì sao? Trông có vẻ “nghiêm” hơn — chỉ cần ít gian ác hơn cũng có thể kích hoạt phạt tịch thu. Nhưng cái giá là gì? Có thể xảy ra trừng phạt nhầm những nút số ít không hề thông đồng. Các nút ở mức 1/4 có thể chỉ bị hiểu nhầm là “gian ác” do độ trễ mạng hoặc sự cố tạm thời, kết quả là BTC bị thế chấp bị tiêu hủy. Nếu đặt ngưỡng quá thấp, việc trừng phạt không còn nhằm vào “kẻ gian ác” mà có thể trừng phạt “người xui xẻo”.

Tôi cho rằng việc đặt đường ranh phạt tịch thu ở 1/3 là vừa đúng với “biên an toàn” của lý thuyết BFT — thấp hơn ngưỡng đó thì chuỗi vẫn có thể vận hành bình thường, không cần phạt; vượt qua ngưỡng đó thì mối đe dọa đã trở nên hiện thực, và việc phạt tịch thu mới thực sự có ý nghĩa.

Giao thức của Babylon thậm chí còn hỗ trợ hình thức phạt tịch thu một phần: chỉ một phần BTC bị tiêu hủy, phần còn lại được hoàn trả cho người đặt thế chấp. 1/3 là “đường ranh trách nhiệm”, không phải “số lượng bị tiêu hủy”. Nhiều người trộn lẫn hai khái niệm này.

Vì vậy, quan điểm của tôi là ngưỡng này đáng để suy nghĩ hơn chính hành động “phạt tịch thu”. Phần lớn mọi người chỉ thấy kết luận bề nổi rằng “kẻ gian ác phải trả giá”, nhưng không nhận ra rằng con số 1/3 bản thân nó là bộ khung toán học của toàn bộ chứng minh an toàn. Đặt ngưỡng sai vị trí thì hoặc là khả năng răn đe bị vô hiệu, hoặc là trừng phạt nhầm người vô tội. #baby $BABY
·
--
Tăng giá
Hôm nay mình khi đọc thông báo TBV trên TBV thì thấy một chi tiết khiến mình hơi khựng lại. @babylonlabs_io hợp tác với Aegis để triển khai khoản vay lãi suất cố định, dự kiến ra mắt vào Q4 năm 2026. Không phải lãi suất thả nổi mà là lãi suất cố định. Ban đầu mình không nghĩ chuyện này lớn đến thế. Sau đó nghĩ lại mới hiểu ra—đối với nhà đầu tư lẻ, chênh lệch giữa lãi suất thả nổi và lãi suất cố định không nhiều, vì dù sao thì vẫn là đi vay tiền. Nhưng đối với các tổ chức, lãi suất thả nổi đồng nghĩa với “chi phí của khoản vay này mình không tính chắc được”. Không tính chắc thì quản trị rủi ro sẽ không duyệt. Trên Aave, phần lớn khoản vay là lãi suất thả nổi; theo biến động của thị trường, hôm nay là 2% thì ngày mai có thể là 5%. Bạn dùng BTC làm tài sản thế chấp để vay một khoản và rồi dùng nó để triển khai chiến lược—nhưng chi phí tài trợ lại tự bạn cũng không tính rõ được, thì việc đó không thể làm được. #baby Trong bản whitepaper có nói: nếu BTC muốn đi vào DeFi, trở ngại lớn nhất không phải là kỹ thuật, mà là giả định về niềm tin. Sự do dự của các tổ chức trước “lãi suất thả nổi” thực ra cũng là vấn đề niềm tin—không phải không tin vào mật mã học, mà là không tin vào việc “chi phí có thể sẽ thay đổi hay không” trong phần không chắc chắn đó. Giải pháp của Aegis nối TBV và Aave v4 theo ba bước: BTC được khóa vào kho; sau đó vay ra stablecoin trên Aave; và cuối cùng, thông qua Aegis để cố định chi phí khoản vay. Làm xong ba bước là có ngay một khoản vay BTC thế chấp với “chi phí đã xác định”. Con đường này có ý nghĩa với các tổ chức lớn hơn rất nhiều so với nhà đầu tư lẻ. Bộ phận tài chính có thể dự đoán được chi phí lãi suất, quỹ có thể tính rõ chi phí về vị thế, còn market maker có thể so sánh chi phí huy động với lợi nhuận kỳ vọng. Nếu không có lãi suất cố định thì những vai trò này gần như không thể tham gia. Song song với hướng đi này còn có hai nhánh khác: 84 Labs đang triển khai mảng vay/cho vay thế chấp BTC bản địa tại thị trường Hàn Quốc, và kế hoạch triển khai Upbit cũng đang được tính đến; bên GoMining đã nêu kế hoạch tích hợp tối đa 1,000 BTC, để số BTC bị khóa trong TBV có thể tự động được vay ra và đưa vào máy đào. Tỷ lệ áp dụng DeFi của BTC khó đi lên không chỉ vì rào cản kỹ thuật. Tính không rõ sổ sách còn đáng ngại hơn cả việc không tin người lưu ký. Bước đi về lãi suất cố định này chính là để lấp khoảng trống đó. #baby $BABY
Hôm nay mình khi đọc thông báo TBV trên TBV thì thấy một chi tiết khiến mình hơi khựng lại. @BabylonLabs_io hợp tác với Aegis để triển khai khoản vay lãi suất cố định, dự kiến ra mắt vào Q4 năm 2026. Không phải lãi suất thả nổi mà là lãi suất cố định.

Ban đầu mình không nghĩ chuyện này lớn đến thế. Sau đó nghĩ lại mới hiểu ra—đối với nhà đầu tư lẻ, chênh lệch giữa lãi suất thả nổi và lãi suất cố định không nhiều, vì dù sao thì vẫn là đi vay tiền. Nhưng đối với các tổ chức, lãi suất thả nổi đồng nghĩa với “chi phí của khoản vay này mình không tính chắc được”. Không tính chắc thì quản trị rủi ro sẽ không duyệt. Trên Aave, phần lớn khoản vay là lãi suất thả nổi; theo biến động của thị trường, hôm nay là 2% thì ngày mai có thể là 5%. Bạn dùng BTC làm tài sản thế chấp để vay một khoản và rồi dùng nó để triển khai chiến lược—nhưng chi phí tài trợ lại tự bạn cũng không tính rõ được, thì việc đó không thể làm được. #baby

Trong bản whitepaper có nói: nếu BTC muốn đi vào DeFi, trở ngại lớn nhất không phải là kỹ thuật, mà là giả định về niềm tin. Sự do dự của các tổ chức trước “lãi suất thả nổi” thực ra cũng là vấn đề niềm tin—không phải không tin vào mật mã học, mà là không tin vào việc “chi phí có thể sẽ thay đổi hay không” trong phần không chắc chắn đó.

Giải pháp của Aegis nối TBV và Aave v4 theo ba bước: BTC được khóa vào kho; sau đó vay ra stablecoin trên Aave; và cuối cùng, thông qua Aegis để cố định chi phí khoản vay. Làm xong ba bước là có ngay một khoản vay BTC thế chấp với “chi phí đã xác định”.

Con đường này có ý nghĩa với các tổ chức lớn hơn rất nhiều so với nhà đầu tư lẻ. Bộ phận tài chính có thể dự đoán được chi phí lãi suất, quỹ có thể tính rõ chi phí về vị thế, còn market maker có thể so sánh chi phí huy động với lợi nhuận kỳ vọng. Nếu không có lãi suất cố định thì những vai trò này gần như không thể tham gia.

Song song với hướng đi này còn có hai nhánh khác: 84 Labs đang triển khai mảng vay/cho vay thế chấp BTC bản địa tại thị trường Hàn Quốc, và kế hoạch triển khai Upbit cũng đang được tính đến; bên GoMining đã nêu kế hoạch tích hợp tối đa 1,000 BTC, để số BTC bị khóa trong TBV có thể tự động được vay ra và đưa vào máy đào.

Tỷ lệ áp dụng DeFi của BTC khó đi lên không chỉ vì rào cản kỹ thuật. Tính không rõ sổ sách còn đáng ngại hơn cả việc không tin người lưu ký. Bước đi về lãi suất cố định này chính là để lấp khoảng trống đó. #baby $BABY
Ban đầu khi tôi xem tài liệu TBV, tôi còn khá xem thường: chẳng phải đây lại là một cây cầu liên kết chuỗi nữa sao——quấn (wrap) BTC rồi mang sang Ethereum? Sau khi đi sâu vào mới phát hiện hoàn toàn không phải vậy.@babylonlabs_io Điều thật sự khiến tôi dừng lại là một câu hỏi: Bitcoin vốn không hề “nhận thức” Ethereum, vậy nó dựa vào đâu để biết có nên cho phép chuyển tiếp một khoản BTC nào đó? Tôi không còn cố chấp bới móc quy trình rút tiền nữa, mà lôi toàn bộ những chỗ trong tài liệu có chữ “proof” ra xem riêng, rồi mới nhận ra mình đã nghĩ ngược. Bitcoin đúng là không cần hiểu trên Ethereum đã xảy ra điều gì. TBV làm việc đó là: chuyển những sự kiện vay/mượn, trả nợ hoặc thanh lý đã hoàn tất trên Ethereum thành các bằng chứng mật mã mà Bitcoin Script có thể xác minh—không phải “BTC đi qua chuỗi”, mà là “bằng chứng đi qua chuỗi”. Cơ chế dịch này được chống đỡ bởi hai module.#baby Một cái gọi là BABE. Khi tạo kho tiền (vault), nó thiết lập sẵn một khung cho mỗi cặp “người đi nhận – người thách thức”. Trong đường đi bình thường, bạn nộp bằng chứng, không ai chất vấn, rồi BTC được mở khóa. Nếu có ai đó muốn nộp một bằng chứng sai để “cố rút”, bên đối thủ có thể dùng sản phẩm của BABE để chặn lại. Bitcoin không cần hiểu trạng thái hợp đồng của Ethereum; nó chỉ cần xác minh rằng bằng chứng này có đúng hay không. Cái còn lại là BitVM3, chịu trách nhiệm để các bằng chứng zero-knowledge có thể được Bitcoin script hiện có “tiếp nhận”, không cần chờ Bitcoin soft fork. Thời BitVM2 trước đó, việc đăng một bằng chứng on-chain có phí vượt 15.000 USD; BitVM3 hạ chi phí đó xuống khoảng 93 USD—biến ngưỡng ký quỹ từ “chỉ đại gia mới chơi nổi” thành “người bình thường cũng chấp nhận được”. Trong dữ liệu thử nghiệm của whitepaper, một bộ so sánh khá trực quan: trong kịch bản lạc quan chỉ cần 3 giao dịch Bitcoin, tổng chi phí 2,66 USD. Tỷ lệ ứng dụng DeFi trên BTC vẫn luôn không lên được—tổng WBTC và cbBTC cộng lại còn chưa tới 1% vốn hóa thị trường của BTC. Vấn đề cốt lõi nằm ở hai chữ “niềm tin”: người nắm giữ Bitcoin không muốn giao đồng của mình cho bên quản lý hộ hoặc cầu đa chữ ký. Toàn bộ logic trọng tâm của thiết kế này thực ra chỉ gói gọn trong một câu: BTC không di chuyển, bằng chứng di chuyển. Cái trước là tin người, cái sau là tin vào toán học.#baby $BABY $BTC
Ban đầu khi tôi xem tài liệu TBV, tôi còn khá xem thường: chẳng phải đây lại là một cây cầu liên kết chuỗi nữa sao——quấn (wrap) BTC rồi mang sang Ethereum? Sau khi đi sâu vào mới phát hiện hoàn toàn không phải vậy.@BabylonLabs_io

Điều thật sự khiến tôi dừng lại là một câu hỏi: Bitcoin vốn không hề “nhận thức” Ethereum, vậy nó dựa vào đâu để biết có nên cho phép chuyển tiếp một khoản BTC nào đó?

Tôi không còn cố chấp bới móc quy trình rút tiền nữa, mà lôi toàn bộ những chỗ trong tài liệu có chữ “proof” ra xem riêng, rồi mới nhận ra mình đã nghĩ ngược. Bitcoin đúng là không cần hiểu trên Ethereum đã xảy ra điều gì. TBV làm việc đó là: chuyển những sự kiện vay/mượn, trả nợ hoặc thanh lý đã hoàn tất trên Ethereum thành các bằng chứng mật mã mà Bitcoin Script có thể xác minh—không phải “BTC đi qua chuỗi”, mà là “bằng chứng đi qua chuỗi”.

Cơ chế dịch này được chống đỡ bởi hai module.#baby

Một cái gọi là BABE. Khi tạo kho tiền (vault), nó thiết lập sẵn một khung cho mỗi cặp “người đi nhận – người thách thức”. Trong đường đi bình thường, bạn nộp bằng chứng, không ai chất vấn, rồi BTC được mở khóa. Nếu có ai đó muốn nộp một bằng chứng sai để “cố rút”, bên đối thủ có thể dùng sản phẩm của BABE để chặn lại. Bitcoin không cần hiểu trạng thái hợp đồng của Ethereum; nó chỉ cần xác minh rằng bằng chứng này có đúng hay không.

Cái còn lại là BitVM3, chịu trách nhiệm để các bằng chứng zero-knowledge có thể được Bitcoin script hiện có “tiếp nhận”, không cần chờ Bitcoin soft fork. Thời BitVM2 trước đó, việc đăng một bằng chứng on-chain có phí vượt 15.000 USD; BitVM3 hạ chi phí đó xuống khoảng 93 USD—biến ngưỡng ký quỹ từ “chỉ đại gia mới chơi nổi” thành “người bình thường cũng chấp nhận được”. Trong dữ liệu thử nghiệm của whitepaper, một bộ so sánh khá trực quan: trong kịch bản lạc quan chỉ cần 3 giao dịch Bitcoin, tổng chi phí 2,66 USD.

Tỷ lệ ứng dụng DeFi trên BTC vẫn luôn không lên được—tổng WBTC và cbBTC cộng lại còn chưa tới 1% vốn hóa thị trường của BTC. Vấn đề cốt lõi nằm ở hai chữ “niềm tin”: người nắm giữ Bitcoin không muốn giao đồng của mình cho bên quản lý hộ hoặc cầu đa chữ ký.

Toàn bộ logic trọng tâm của thiết kế này thực ra chỉ gói gọn trong một câu: BTC không di chuyển, bằng chứng di chuyển. Cái trước là tin người, cái sau là tin vào toán học.#baby $BABY $BTC
Hôm nay mình đang tháo phần tài liệu “Mô hình niềm tin: so sánh quá khứ và hiện tại” trong bản PDF trắng @babylonlabs_io thì để ý một câu bình thường hay bị lướt qua: Niềm tin đã chuyển từ khâu lưu ký sang khâu tính toán. Nhìn thoáng qua thì giống một khẩu hiệu, nhưng nghĩ kỹ mới thấy câu này đang mô tả một thay đổi rất cụ thể—trước đây khi đánh giá BTC có an toàn hay không, bạn nhìn xem bên lưu ký có đáng tin không, và người vận hành cầu có bỏ chạy không; còn bây giờ, chuyện này biến thành việc xem chính bản thân script (tập lệnh) có viết đúng không, không còn liên quan gì đến “con người”. Lật tiếp xuống thì thấy phần “không có bên trung gian” được triển khai cụ thể như thế nào. Khóa riêng của người gửi tiền của chính họ phải tham gia vào từng lộ trình “phát hành” mà họ tự kiểm soát. Điều này có nghĩa là việc chuộc lại BTC không cần bất kỳ ai phối hợp hay bất kỳ ai phê duyệt. Ngay cả hợp đồng của giao thức cũng không thể di chuyển BTC ra khỏi script, đem đi cho mượn hoặc dùng sai mục đích—lời trong tài liệu nguyên văn là “vật thế chấp chỉ có thể thực hiện các thao tác được script cho phép”. Ràng buộc này được khắc từ lúc tạo ra, nên sau đó không ai có thể chỉnh sửa.#baby Những chỗ còn giữ lại yếu tố niềm tin thì chỉ còn hai mảng: quản trị (governance) và đa chữ ký phản ứng khẩn cấp (emergency response) của giao thức—hai phần này được gắn nhãn rõ ràng là biện pháp đảm bảo an toàn mang tính “quá độ”. Theo cách nói chính thức, chúng sẽ bị dần dần loại bỏ theo thời gian. Cái nhãn “thẳng thắn” này khá quan trọng: nó tương đương với việc thừa nhận hiện tại vẫn chưa phải hoàn toàn loại bỏ niềm tin (100% không cần tin ai), nhưng đồng thời cũng đưa ra hướng thu hẹp, không mơ hồ bỏ qua. Nếu mình ví von thì nó giống như việc mật khẩu tủ sắt của bạn chỉ mình bạn biết, còn ngân hàng thậm chí không giữ lấy một chìa khóa dự phòng. Còn chuyện “ngân hàng nói sẽ bảo quản tốt đồ của bạn, nên bạn chọn tin” hoàn toàn là logic an toàn khác hẳn. Khi nào multi-sig quản trị thực sự bắt đầu bị loại bỏ, và sẽ siết theo nhịp nào—tài liệu không đưa lịch trình. Bạn có thể để ý tiến triển sau này.#baby $BABY $BTC
Hôm nay mình đang tháo phần tài liệu “Mô hình niềm tin: so sánh quá khứ và hiện tại” trong bản PDF trắng @BabylonLabs_io thì để ý một câu bình thường hay bị lướt qua: Niềm tin đã chuyển từ khâu lưu ký sang khâu tính toán. Nhìn thoáng qua thì giống một khẩu hiệu, nhưng nghĩ kỹ mới thấy câu này đang mô tả một thay đổi rất cụ thể—trước đây khi đánh giá BTC có an toàn hay không, bạn nhìn xem bên lưu ký có đáng tin không, và người vận hành cầu có bỏ chạy không; còn bây giờ, chuyện này biến thành việc xem chính bản thân script (tập lệnh) có viết đúng không, không còn liên quan gì đến “con người”.

Lật tiếp xuống thì thấy phần “không có bên trung gian” được triển khai cụ thể như thế nào. Khóa riêng của người gửi tiền của chính họ phải tham gia vào từng lộ trình “phát hành” mà họ tự kiểm soát. Điều này có nghĩa là việc chuộc lại BTC không cần bất kỳ ai phối hợp hay bất kỳ ai phê duyệt. Ngay cả hợp đồng của giao thức cũng không thể di chuyển BTC ra khỏi script, đem đi cho mượn hoặc dùng sai mục đích—lời trong tài liệu nguyên văn là “vật thế chấp chỉ có thể thực hiện các thao tác được script cho phép”. Ràng buộc này được khắc từ lúc tạo ra, nên sau đó không ai có thể chỉnh sửa.#baby

Những chỗ còn giữ lại yếu tố niềm tin thì chỉ còn hai mảng: quản trị (governance) và đa chữ ký phản ứng khẩn cấp (emergency response) của giao thức—hai phần này được gắn nhãn rõ ràng là biện pháp đảm bảo an toàn mang tính “quá độ”. Theo cách nói chính thức, chúng sẽ bị dần dần loại bỏ theo thời gian. Cái nhãn “thẳng thắn” này khá quan trọng: nó tương đương với việc thừa nhận hiện tại vẫn chưa phải hoàn toàn loại bỏ niềm tin (100% không cần tin ai), nhưng đồng thời cũng đưa ra hướng thu hẹp, không mơ hồ bỏ qua.

Nếu mình ví von thì nó giống như việc mật khẩu tủ sắt của bạn chỉ mình bạn biết, còn ngân hàng thậm chí không giữ lấy một chìa khóa dự phòng. Còn chuyện “ngân hàng nói sẽ bảo quản tốt đồ của bạn, nên bạn chọn tin” hoàn toàn là logic an toàn khác hẳn.

Khi nào multi-sig quản trị thực sự bắt đầu bị loại bỏ, và sẽ siết theo nhịp nào—tài liệu không đưa lịch trình. Bạn có thể để ý tiến triển sau này.#baby $BABY $BTC
Hôm nay tôi đã xem xét các bước trong quy trình thanh lý của bản whitepaper suốt một hồi (@babylonlabs_io ). Ban đầu tôi nghĩ rằng người thanh lý sẽ giống như trong DeFi truyền thống: thanh lý xong là trực tiếp chuyển tài sản thế chấp từ hợp đồng sang tài khoản của chính mình là xong. Nhưng khi đọc đến từng bước cụ thể mới phát hiện không phải vậy—để lấy được BTC, người thanh lý phải tự mở thêm một kho (vault) nữa. Quy trình cụ thể như sau: Khi giá BTC giảm và phá vỡ ngưỡng thanh lý, người thanh lý trước hết sẽ hoàn trả khoản nợ của người vay thông qua hợp đồng cho vay. Sau khi hợp đồng nhận được tiền trả, nó sẽ hủy (destroy) trên chuỗi các token ghi sổ collBTC tương ứng. Tiếp theo sẽ tạo ra một chứng nhận hủy (destroy proof), nhưng chứng nhận này không được gửi đến kho ban đầu của người vay, mà lại được gửi đến một kho mới do chính người thanh lý tạo. Sau khi hết cửa sổ thời gian (timeout window), BTC mới được mở khóa từ kho mới đó để chuyển cho người thanh lý. Nói cách khác, để nhận được khoản bù khi đóng vị thế, người thanh lý bắt buộc phải tự đi trọn quy trình: mở kho, chờ cửa sổ thách thức… gần như đối xứng với đường đi mà người vay đã thực hiện khi nạp tiền. #baby Thiết kế này đi kèm các ràng buộc rất cụ thể: nếu người thanh lý có thể chuyển BTC trực tiếp từ kho ban đầu cho chính mình, thì “luật bất di bất dịch: điều kiện chi trả của kho được quyết định bởi các bên ký chung khi tạo” sẽ bị phá vỡ—bởi vì giao dịch đã được ký sẵn sẵn của kho ban đầu về bản chất không hề có biến “người thanh lý là ai”. Việc bắt người thanh lý phải mở một kho khác đồng nghĩa với việc đưa hành động “thanh lý” vào cùng một khung đường đi chi tiêu không cần tin tưởng (trustless) thay vì tạo cho người thanh lý một “cửa hậu” đặc quyền. Tôi ví dụ như thế này: đây không phải kiểu “công ty quản lý tòa nhà tự ý vào nhà chủ nhà rồi mang đồ đi để trừ nợ”, mà là công ty quản lý phải trước tiên tự mở một giấy tờ/chứng nhận mới, đi đúng một quy trình y hệt như lúc chủ nhà làm thủ tục ban đầu, thì mới hợp pháp được chuyển quyền sở hữu sang tên mình. Bước thêm đó chính là để không chừa kênh đặc biệt cho bất kỳ vai trò nào. Riêng về việc “kho thách thức” (challenge window) của “kho người thanh lý” có trùng khớp với “cửa sổ” của kho ban đầu của người vay hay không, trong whitepaper không ghi rõ riêng. Điều này có thể ảnh hưởng đến thời gian thực tế tiền về cho người thanh lý, nên đáng để lưu ý. TBV hiện tại trên testnet vẫn chạy logic thanh lý với Signet BTC và tài sản mô phỏng trên Sepolia, chưa có áp lực kiểm thử bằng vốn thật. Tuy nhiên, thiết kế đối xứng “người thanh lý cũng phải mở kho” này—là thứ tôi thấy cho đến nay—đã là một trong những chi tiết làm khá triệt để nhất, khi nhét cả khâu thanh lý vào khung không cần tin tưởng (trustless). #baby $BABY $BTC
Hôm nay tôi đã xem xét các bước trong quy trình thanh lý của bản whitepaper suốt một hồi (@BabylonLabs_io ). Ban đầu tôi nghĩ rằng người thanh lý sẽ giống như trong DeFi truyền thống: thanh lý xong là trực tiếp chuyển tài sản thế chấp từ hợp đồng sang tài khoản của chính mình là xong. Nhưng khi đọc đến từng bước cụ thể mới phát hiện không phải vậy—để lấy được BTC, người thanh lý phải tự mở thêm một kho (vault) nữa.

Quy trình cụ thể như sau: Khi giá BTC giảm và phá vỡ ngưỡng thanh lý, người thanh lý trước hết sẽ hoàn trả khoản nợ của người vay thông qua hợp đồng cho vay. Sau khi hợp đồng nhận được tiền trả, nó sẽ hủy (destroy) trên chuỗi các token ghi sổ collBTC tương ứng. Tiếp theo sẽ tạo ra một chứng nhận hủy (destroy proof), nhưng chứng nhận này không được gửi đến kho ban đầu của người vay, mà lại được gửi đến một kho mới do chính người thanh lý tạo. Sau khi hết cửa sổ thời gian (timeout window), BTC mới được mở khóa từ kho mới đó để chuyển cho người thanh lý. Nói cách khác, để nhận được khoản bù khi đóng vị thế, người thanh lý bắt buộc phải tự đi trọn quy trình: mở kho, chờ cửa sổ thách thức… gần như đối xứng với đường đi mà người vay đã thực hiện khi nạp tiền. #baby

Thiết kế này đi kèm các ràng buộc rất cụ thể: nếu người thanh lý có thể chuyển BTC trực tiếp từ kho ban đầu cho chính mình, thì “luật bất di bất dịch: điều kiện chi trả của kho được quyết định bởi các bên ký chung khi tạo” sẽ bị phá vỡ—bởi vì giao dịch đã được ký sẵn sẵn của kho ban đầu về bản chất không hề có biến “người thanh lý là ai”. Việc bắt người thanh lý phải mở một kho khác đồng nghĩa với việc đưa hành động “thanh lý” vào cùng một khung đường đi chi tiêu không cần tin tưởng (trustless) thay vì tạo cho người thanh lý một “cửa hậu” đặc quyền.

Tôi ví dụ như thế này: đây không phải kiểu “công ty quản lý tòa nhà tự ý vào nhà chủ nhà rồi mang đồ đi để trừ nợ”, mà là công ty quản lý phải trước tiên tự mở một giấy tờ/chứng nhận mới, đi đúng một quy trình y hệt như lúc chủ nhà làm thủ tục ban đầu, thì mới hợp pháp được chuyển quyền sở hữu sang tên mình. Bước thêm đó chính là để không chừa kênh đặc biệt cho bất kỳ vai trò nào.

Riêng về việc “kho thách thức” (challenge window) của “kho người thanh lý” có trùng khớp với “cửa sổ” của kho ban đầu của người vay hay không, trong whitepaper không ghi rõ riêng. Điều này có thể ảnh hưởng đến thời gian thực tế tiền về cho người thanh lý, nên đáng để lưu ý.

TBV hiện tại trên testnet vẫn chạy logic thanh lý với Signet BTC và tài sản mô phỏng trên Sepolia, chưa có áp lực kiểm thử bằng vốn thật. Tuy nhiên, thiết kế đối xứng “người thanh lý cũng phải mở kho” này—là thứ tôi thấy cho đến nay—đã là một trong những chi tiết làm khá triệt để nhất, khi nhét cả khâu thanh lý vào khung không cần tin tưởng (trustless). #baby $BABY $BTC
Đăng nhập để khám phá thêm nội dung
Tham gia cùng người dùng tiền mã hóa toàn cầu trên Binance Square
⚡️ Nhận thông tin mới nhất và hữu ích về tiền mã hóa.
💬 Được tin cậy bởi sàn giao dịch tiền mã hóa lớn nhất thế giới.
👍 Khám phá những thông tin chuyên sâu thực tế từ những nhà sáng tạo đã xác minh.
Email / Số điện thoại
Sơ đồ trang web
Tùy chọn Cookie
Điều khoản & Điều kiện