AlizehAli
11.2k 貼文
AlizehAli
592 關注
24.3K+ 粉絲
8.2K+ 點讚數
貼文
全部
引用
直播
置頂
@Dusk 一個國家的建國憲法在國家誕生的那一刻就已經存在——沒有人會在事後把它投票通過才使其成立；它只是從第一天起就在那裏，一切其他制度與建設都會以它爲參照。
黃昏（Dusk）的創世合約也以同樣方式運作。黃昏自身的架構材料描述了兩種：質押合約（stake contract），用於追蹤哪些提供者正在質押，記錄獎勵，並啓用質押、取消質押以及獎勵提取等操作；以及轉賬合約（transfer contract），處理 Moonlight（公開）與 Phoenix（受保護）兩種轉賬，支付 gas，並作爲交易執行的入口，直接在黃昏 DuskDS 上運行。
這種奠基性的作用不只存在於 DuskDS 本身，儘管具體機制會因層級而不同。根據黃昏（Dusk）自身文檔，DuskEVM 通過它自己的橋（bridge）把 DUSK 用於 gas 的資金轉移到黃昏的 L1，最終再回到黃昏的 DuskDS——這是一條與轉賬合約在原生 DuskDS 交易中所承擔直接角色不同的路徑。兩條路都會回到同一底層基礎層；它們並不是相同的機制。 #dusk
自我質疑：這種“憲法類比”是有真實邊界、值得點明的。一個國家的憲法可以通過一個被明確規定的流程來正式修訂。就我所能找到的文檔而言，我還沒有確認：黃昏的創世合約是否存在等價的、清晰規定的修訂路徑；或者“創世（genesis）”在這裏在功能上意味着“按設計永久不變”——考慮到黃昏不斷擴展的多層堆棧中，已經有大量內容依賴這兩個合約始終保持正確，這確實是一個重大的治理問題。 $DUSK
在這些合約承受現實壓力、不得不更新之前，應該先評估：這種不明確性是否能在那之前得到澄清，而不是等到之後。
#dusk $DUSK @Dusk
黃昏（Dusk）的創世合約也以同樣方式運作。黃昏自身的架構材料描述了兩種：質押合約（stake contract），用於追蹤哪些提供者正在質押，記錄獎勵，並啓用質押、取消質押以及獎勵提取等操作；以及轉賬合約（transfer contract），處理 Moonlight（公開）與 Phoenix（受保護）兩種轉賬，支付 gas，並作爲交易執行的入口，直接在黃昏 DuskDS 上運行。
這種奠基性的作用不只存在於 DuskDS 本身，儘管具體機制會因層級而不同。根據黃昏（Dusk）自身文檔，DuskEVM 通過它自己的橋（bridge）把 DUSK 用於 gas 的資金轉移到黃昏的 L1，最終再回到黃昏的 DuskDS——這是一條與轉賬合約在原生 DuskDS 交易中所承擔直接角色不同的路徑。兩條路都會回到同一底層基礎層；它們並不是相同的機制。 #dusk
自我質疑：這種“憲法類比”是有真實邊界、值得點明的。一個國家的憲法可以通過一個被明確規定的流程來正式修訂。就我所能找到的文檔而言，我還沒有確認：黃昏的創世合約是否存在等價的、清晰規定的修訂路徑；或者“創世（genesis）”在這裏在功能上意味着“按設計永久不變”——考慮到黃昏不斷擴展的多層堆棧中，已經有大量內容依賴這兩個合約始終保持正確，這確實是一個重大的治理問題。 $DUSK
在這些合約承受現實壓力、不得不更新之前，應該先評估：這種不明確性是否能在那之前得到澄清，而不是等到之後。
#dusk $DUSK @Dusk
Permanent by design
Should have amendment path
10 剩餘小時數
置頂
@TermMax 我原以爲在 TermMax Alpha 上行使一個獲利的期權會以同一種固定方式運作——到期款項打進你的錢包，就結束了，和我之前用過的任何期權平臺一樣。 $BEAT
但當我讀到 TermMax 實際上提供兩種不同的行權路徑時，這個假設就土崩瓦解了。Exercise-Net-Settle（行權-淨額結算）會關閉持倉並直接支付淨利潤。Exercise-Delivery（行權-交割）則是通過轉移標的資產本身來結算，而不是現金——也就是說，你最終會真正持有你原本做多或做空所基於的那個代幣。 #TermMax
這重新定義了在這裏，“贏得”一筆期權交易意味着什麼。在大多數平臺上，行權只是意味着把一筆數字變現出來。而在 TermMax 上，行權可能意味着帶走實際資產；這點在早期 Binance Alpha 上市中特別重要——因爲獲得代幣的真實敞口，而不僅僅是它價格的波動，可能纔是這筆交易的核心目的。 $TUT
文檔沒有說清楚的是：這兩種方式的選擇是否總是對交易者開放，還是會取決於在結算時該市場的具體配置。 $ENA
TMX 的真正考驗在於：交易者在行權之前是否真的理解這個選擇的存在，還是直接默認使用界面首先展示的那一個。
有人真的用過 Exercise-Delivery（交割）而不是 Net-Settle（淨額結算）嗎？爲什麼？
#termmax @TermMax
但當我讀到 TermMax 實際上提供兩種不同的行權路徑時，這個假設就土崩瓦解了。Exercise-Net-Settle（行權-淨額結算）會關閉持倉並直接支付淨利潤。Exercise-Delivery（行權-交割）則是通過轉移標的資產本身來結算，而不是現金——也就是說，你最終會真正持有你原本做多或做空所基於的那個代幣。 #TermMax
這重新定義了在這裏，“贏得”一筆期權交易意味着什麼。在大多數平臺上，行權只是意味着把一筆數字變現出來。而在 TermMax 上，行權可能意味着帶走實際資產；這點在早期 Binance Alpha 上市中特別重要——因爲獲得代幣的真實敞口，而不僅僅是它價格的波動，可能纔是這筆交易的核心目的。 $TUT
文檔沒有說清楚的是：這兩種方式的選擇是否總是對交易者開放，還是會取決於在結算時該市場的具體配置。 $ENA
TMX 的真正考驗在於：交易者在行權之前是否真的理解這個選擇的存在，還是直接默認使用界面首先展示的那一個。
有人真的用過 Exercise-Delivery（交割）而不是 Net-Settle（淨額結算）嗎？爲什麼？
#termmax @TermMax
真實
@Dusk 回過頭去查看 Dusk 在 2025 年 6 月的自家架構公告可以發現，敘事框架已較其此前的定位發生了變化。
根據 Dusk 當前文檔，其架構分三層：底層是 DuskDS，包括共識（consensus）、結算（settlement）、數據可用性（data availability）以及原生交易模型。其上是 DuskEVM，基於 OP Stack，且具備完整的 Solidity 兼容性。再旁側還有 DuskVM，與之並行，使用 Rust/WASM 合約直接運行在 L1 上，以支持隱私原生（privacy-native）的用例。 #dusk
從最初 2025 年的演進公告到如今的變化在於：當時對 DuskVM 的描述是“即將推出（forthcoming）”。而當前文檔將其表述爲正在運行的基礎設施，而不是路線圖事項。另一個方面，Dusk 自己在 2026 年的更新提到 NPEX 的受監管證券類 dApp 正在有針對性地、持續推進地上線 DuskEVM——我想明確這一點：這是正在進行中的推進（ongoing rollout），而不是我目前就能確認已經完成、並全面投入運行的“上線”。 $DUSK
有一個具體細節把這三層真正地串聯在一起：不論上述推進處於何種狀態，單一的 DUSK 代幣爲每一層提供燃料；同時，由驗證者（validator）運行的原生橋（native bridge）在各層之間傳遞價值——無需包裝資產（wrapped assets）或託管方（custodians）。
這仍然是一個在演進中的系統，而非已完工的系統。DuskEVM 自家的文檔也確認：它當前只運行 sequencer-only（僅序列器）。目前還沒有對外公開的 mempool——這是一個帶日期的、具體的限制，位於它當前在“上層”積極部署的任何內容之下。
如果有人跟蹤過 NPEX 的推進在實踐中到底是如何與這套架構對齊的，我很想把筆記與我在這裏找到的內容進行對照。
#dusk $DUSK @Dusk
根據 Dusk 當前文檔，其架構分三層：底層是 DuskDS，包括共識（consensus）、結算（settlement）、數據可用性（data availability）以及原生交易模型。其上是 DuskEVM，基於 OP Stack，且具備完整的 Solidity 兼容性。再旁側還有 DuskVM，與之並行，使用 Rust/WASM 合約直接運行在 L1 上，以支持隱私原生（privacy-native）的用例。 #dusk
從最初 2025 年的演進公告到如今的變化在於：當時對 DuskVM 的描述是“即將推出（forthcoming）”。而當前文檔將其表述爲正在運行的基礎設施，而不是路線圖事項。另一個方面，Dusk 自己在 2026 年的更新提到 NPEX 的受監管證券類 dApp 正在有針對性地、持續推進地上線 DuskEVM——我想明確這一點：這是正在進行中的推進（ongoing rollout），而不是我目前就能確認已經完成、並全面投入運行的“上線”。 $DUSK
有一個具體細節把這三層真正地串聯在一起：不論上述推進處於何種狀態，單一的 DUSK 代幣爲每一層提供燃料；同時，由驗證者（validator）運行的原生橋（native bridge）在各層之間傳遞價值——無需包裝資產（wrapped assets）或託管方（custodians）。
這仍然是一個在演進中的系統，而非已完工的系統。DuskEVM 自家的文檔也確認：它當前只運行 sequencer-only（僅序列器）。目前還沒有對外公開的 mempool——這是一個帶日期的、具體的限制，位於它當前在“上層”積極部署的任何內容之下。
如果有人跟蹤過 NPEX 的推進在實踐中到底是如何與這套架構對齊的，我很想把筆記與我在這裏找到的內容進行對照。
#dusk $DUSK @Dusk
真實
@TermMax 花了一些時間去梳理 TermMax Alpha 的選項機制，原本以為會是通常那種開放式選項的風險輪廓。
結果並不是這樣。Going Long 的意思是買入一口看漲期權，Short 的意思是買入一口看跌期權，兩者都是針對合約對手方——文件稱之為 Dual Investment（雙重投資）——也就是期權賣方。Max Cost（最大成本）被明確定義為所支付的權利金，主要以 USDT 計價。結算流程透過 Exercise-Net-Settle（行權淨額結算）或 Exercise-Delivery（行權交割），不管採用哪一種方式，最大可能損失在部位開倉的那一刻就被鎖定。
這些條款本身看起來並沒有特別顯著之處。但發布情境讓我停下來多想。TermMax Alpha 於 2025 年 11 月 12 日在 BNB Chain 主網上線，由 Term Structure Labs 打造，並由 Cumberland DRW 背書——這是一家真正的機構級交易公司，而不只是那種代幣上架的噱頭。
這種背書很關鍵，因為產品實際上解決的是什麼。當 Binance Alpha 上市一個新代幣時，交易者常常會等上好幾週，才會在任何地方出現永續合約。TermMax Alpha 的存在就是專門用來填補這個空白——提供槓桿曝險，但成本有上限且可預知，並且從上市當天就能使用，而不是要等好幾週之後。 #TermMax
吸引我注意的是：這使得 TermMax Alpha 真正具有時間敏感型的基礎設施屬性——它的相關性取決於新的 Binance Alpha 上市資訊能以多快的速度持續出現，而不是某個停在原地不動的靜態功能。
我尚未確認目前有多少個正在運行的 Alpha 市場，以及最新上市的合約在點差上有多緊。
Long or Short?
#termmax @TermMax
結果並不是這樣。Going Long 的意思是買入一口看漲期權，Short 的意思是買入一口看跌期權，兩者都是針對合約對手方——文件稱之為 Dual Investment（雙重投資）——也就是期權賣方。Max Cost（最大成本）被明確定義為所支付的權利金，主要以 USDT 計價。結算流程透過 Exercise-Net-Settle（行權淨額結算）或 Exercise-Delivery（行權交割），不管採用哪一種方式，最大可能損失在部位開倉的那一刻就被鎖定。
這些條款本身看起來並沒有特別顯著之處。但發布情境讓我停下來多想。TermMax Alpha 於 2025 年 11 月 12 日在 BNB Chain 主網上線，由 Term Structure Labs 打造，並由 Cumberland DRW 背書——這是一家真正的機構級交易公司，而不只是那種代幣上架的噱頭。
這種背書很關鍵，因為產品實際上解決的是什麼。當 Binance Alpha 上市一個新代幣時，交易者常常會等上好幾週，才會在任何地方出現永續合約。TermMax Alpha 的存在就是專門用來填補這個空白——提供槓桿曝險，但成本有上限且可預知，並且從上市當天就能使用，而不是要等好幾週之後。 #TermMax
吸引我注意的是：這使得 TermMax Alpha 真正具有時間敏感型的基礎設施屬性——它的相關性取決於新的 Binance Alpha 上市資訊能以多快的速度持續出現，而不是某個停在原地不動的靜態功能。
我尚未確認目前有多少個正在運行的 Alpha 市場，以及最新上市的合約在點差上有多緊。
Long or Short?
#termmax @TermMax
Long (call)
75%
Short (put)
0%
Neither, too risky
25%
4 票 • 投票已結束
由 Dusk 自己的團隊專門設計的一種適合“嘲諷”（snark） 的哈希函數，用於在零知識電路中進行抗碰撞哈希。
Mohsin_Trader_King
·
--
一直坐在一個問題上：Dusk 的文檔並沒有直接給出具體數字——兩個不同的 Phoenix 筆記是否有可能產生相同的 nullifier。
我可以明確確認的點是：Dusk 自己的 Phoenix 倉庫表示，nullifier 是這樣計算的，目的是讓外部觀察者無法將它鏈接回該 nullifier 來自哪一條筆記。每條筆記都會被哈希成筆記的 Merkle 樹中的葉子節點，而花費（spend）某一條筆記會生成一個與該特定筆記數據相關的、確定性的 nullifier 值。
其底層的哈希——無論是 Dusk 的 Merkle 樹結構，還是更廣泛的密碼學運算——都基於 Poseidon，這是一種對 SNARK 友好的哈希函數，由 Dusk 自己的團隊專門爲“碰撞抵抗”式哈希設計，用於零知識電路中的承諾計算。這並不是隨便拿來用的通用哈希；它是爲這類 ZK 原生的承諾工作而專門構建的。
但“碰撞抵抗”並不等同於“碰撞證明”。任何哈希函數（包括 Poseidon）都帶有一個理論上的可能性（極其微小、天文級別）——即兩組不同的輸入可能產生相同的輸出；這正是哈希本身的性質，而不是 Dusk 特定的弱點。
在我查閱 Dusk 自己的資料中，我沒有找到任何針對其所用 Poseidon 參數的已發佈碰撞概率數據，或針對該性質進行的專門碰撞測試結果（超出 Poseidon 由設計所繼承的通用安全性質之外）。
如果有人見過一份審計報告，覆蓋了 Dusk 實現中這一特定性質，我希望能把它與公開文檔中已有的信息進行對比。
#dusk $DUSK @Dusk
我可以明確確認的點是：Dusk 自己的 Phoenix 倉庫表示，nullifier 是這樣計算的，目的是讓外部觀察者無法將它鏈接回該 nullifier 來自哪一條筆記。每條筆記都會被哈希成筆記的 Merkle 樹中的葉子節點，而花費（spend）某一條筆記會生成一個與該特定筆記數據相關的、確定性的 nullifier 值。
其底層的哈希——無論是 Dusk 的 Merkle 樹結構，還是更廣泛的密碼學運算——都基於 Poseidon，這是一種對 SNARK 友好的哈希函數，由 Dusk 自己的團隊專門爲“碰撞抵抗”式哈希設計，用於零知識電路中的承諾計算。這並不是隨便拿來用的通用哈希；它是爲這類 ZK 原生的承諾工作而專門構建的。
但“碰撞抵抗”並不等同於“碰撞證明”。任何哈希函數（包括 Poseidon）都帶有一個理論上的可能性（極其微小、天文級別）——即兩組不同的輸入可能產生相同的輸出；這正是哈希本身的性質，而不是 Dusk 特定的弱點。
在我查閱 Dusk 自己的資料中，我沒有找到任何針對其所用 Poseidon 參數的已發佈碰撞概率數據，或針對該性質進行的專門碰撞測試結果（超出 Poseidon 由設計所繼承的通用安全性質之外）。
如果有人見過一份審計報告，覆蓋了 Dusk 實現中這一特定性質，我希望能把它與公開文檔中已有的信息進行對比。
#dusk $DUSK @Dusk
5%的金額作爲獎勵歸清算執行人，因其執行清算而獲得該報酬
Mohsin_Trader_King
·
--
我專門回過頭去查看了 TermMax 的清算文檔，逐步追蹤那筆罰金最終究竟會流向哪裏。
數字很簡單：清算清償的債務價值的 10%，在觸發清算時從借款人自身抵押品中扣取。較不直觀的是拆分方式——並不是一次性全部給到某一方。其中 5% 作爲清算執行者的獎勵。剩下的另外 5% 會直接進入協議自身的儲備金。
對我來說，關鍵變化在於：這並不只是單純的懲罰費用；文檔明確把它寫成“兩段式”的激勵結構，圍繞協議穩定性展開——一方面在貸款上維持所需的 LTV，另一方面也給清算者一個真正的動力，促使其快速行動。公式也印證了優先級順序：被清算的抵押品先用於覆蓋清算者的獎勵，隨後剩餘部分才用於協議層面的罰金，並且這一切都被明確限制在借款人的實際持倉範圍內——因此，無論公式如何運算，罰金在數學上都不可能超過該借款人自身抵押品所能覆蓋的上限。
需要特別標註：文檔清楚寫明瞭拆分比例和上限，但並未說明當儲備金累積起來之後，它會被用於什麼用途，或者在什麼條件下會被動用。
下一步我會覈查：截至目前，這部分儲備金相對於已發生的總清算量，實際增長了多大。
#termmax @TermMax $BTW
$RICE
$GPS
數字很簡單：清算清償的債務價值的 10%，在觸發清算時從借款人自身抵押品中扣取。較不直觀的是拆分方式——並不是一次性全部給到某一方。其中 5% 作爲清算執行者的獎勵。剩下的另外 5% 會直接進入協議自身的儲備金。
對我來說，關鍵變化在於：這並不只是單純的懲罰費用；文檔明確把它寫成“兩段式”的激勵結構，圍繞協議穩定性展開——一方面在貸款上維持所需的 LTV，另一方面也給清算者一個真正的動力，促使其快速行動。公式也印證了優先級順序：被清算的抵押品先用於覆蓋清算者的獎勵，隨後剩餘部分才用於協議層面的罰金，並且這一切都被明確限制在借款人的實際持倉範圍內——因此，無論公式如何運算，罰金在數學上都不可能超過該借款人自身抵押品所能覆蓋的上限。
需要特別標註：文檔清楚寫明瞭拆分比例和上限，但並未說明當儲備金累積起來之後，它會被用於什麼用途，或者在什麼條件下會被動用。
下一步我會覈查：截至目前，這部分儲備金相對於已發生的總清算量，實際增長了多大。
#termmax @TermMax $BTW
$RICE
$GPS
真實
@Dusk 我去找了當鳳凰城（Phoenix）的零知識證明在驗證時失敗到底會發生什麼，因爲大多數解釋停留在“證明被檢查了”。
Dusk 的架構確認：證明必須在同一個證明中共同展示特定性質——被花費的記賬憑證（note）的所有權、輸入與輸出之間的餘額完整性，以及沒有雙重花費（double-spend）——而不是通過分別的旁路檢查來驗證。$DUSK
這纔是值得細細體會的部分：只要其中任意一項性質不成立，整個證明就會作爲一個整體失敗。不存在那種“部分得分”的路徑——例如餘額檢查通過了，但所有權失敗卻靜默不報。
我從實踐層面追蹤到：被拒絕的證明意味着該交易根本不會被納入區塊。運行時不會嘗試修補或部分處理它。交易就只是不會發生，而且這次失敗嘗試的任何信息都不會被記錄爲狀態變化。#dusk
我尚未從 Dusk 自己的資料中確認的是：失敗的證明是否會在 mempool（內存池）日誌裏留下任何痕跡，供節點運營者事後檢查；還是說它會被直接丟棄，完全不產生任何診斷記錄。
接下來我會檢查：Dusk 當前的錢包工具是否會爲“證明失敗”呈現一個具體原因，還是隻給出通用的拒絕（generic rejection）。因爲這種區分對任何真正需要調試“沒有成功走通”的交易的人都非常關鍵。
#dusk $DUSK @Dusk
Dusk 的架構確認：證明必須在同一個證明中共同展示特定性質——被花費的記賬憑證（note）的所有權、輸入與輸出之間的餘額完整性，以及沒有雙重花費（double-spend）——而不是通過分別的旁路檢查來驗證。$DUSK
這纔是值得細細體會的部分：只要其中任意一項性質不成立，整個證明就會作爲一個整體失敗。不存在那種“部分得分”的路徑——例如餘額檢查通過了，但所有權失敗卻靜默不報。
我從實踐層面追蹤到：被拒絕的證明意味着該交易根本不會被納入區塊。運行時不會嘗試修補或部分處理它。交易就只是不會發生，而且這次失敗嘗試的任何信息都不會被記錄爲狀態變化。#dusk
我尚未從 Dusk 自己的資料中確認的是：失敗的證明是否會在 mempool（內存池）日誌裏留下任何痕跡，供節點運營者事後檢查；還是說它會被直接丟棄，完全不產生任何診斷記錄。
接下來我會檢查：Dusk 當前的錢包工具是否會爲“證明失敗”呈現一個具體原因，還是隻給出通用的拒絕（generic rejection）。因爲這種區分對任何真正需要調試“沒有成功走通”的交易的人都非常關鍵。
#dusk $DUSK @Dusk
@TermMax 花了一些時間去梳理 TermMax 的三代幣系統，文檔裏有一行話讓我對整個邏輯豁然開朗：抵押品價值（Collateral Value）等於 GT 價值（GT Value）加上借款本身的價值（Loan itself），而 GT 價值被定義爲抵押品減去債務的價值。代幣並不只是三個彼此分開的對象，它們其實是同一個需要相互平衡的方程的組成部分。
FT 是一種 ERC-20，運作方式類似零息債券——110 FT-USDC 在到期時可兌換 110 USDC；因此用 100 USDC 買入，它會在一年期限內鎖定約 10% 的回報。但文檔明確指出，這個數字會隨到期時間而變化，而不是簡單固定不變：同樣折扣下，180 天的 FT 年化大約是 20%，而不是 10%。XT 的定義也比我預想得更精確：它不只是“另一半”，而是借款人所欠利息的現值（present value of the interest），並將其與本金分離出來。GT 則是那個“位置封裝器”——ERC-721，它把抵押品和債務作爲一個整體來跟蹤，並受 MLTV（最大貸款價值比）上限約束。
讓我特別在意的是：XT 並不是填充項，它是一種獨立的金融工具，用來單獨表達利息風險，並且它的定價與 FT 的本金風險是分開的。在代幣層面把本金和利息拆開，正是讓整個系統的零和方程能夠成立——鏈條中沒有任何價值會憑空出現或消失。#TermMax
對我來說還缺的那一塊是：XT 是否存在真實的二級市場深度（secondary-market depth），因爲它在給一種非常窄的、僅包含短期利息風險的東西定價。
“哪一個代幣對你最重要？”
#termmax
@TermMax
FT 是一種 ERC-20，運作方式類似零息債券——110 FT-USDC 在到期時可兌換 110 USDC；因此用 100 USDC 買入，它會在一年期限內鎖定約 10% 的回報。但文檔明確指出，這個數字會隨到期時間而變化，而不是簡單固定不變：同樣折扣下，180 天的 FT 年化大約是 20%，而不是 10%。XT 的定義也比我預想得更精確：它不只是“另一半”，而是借款人所欠利息的現值（present value of the interest），並將其與本金分離出來。GT 則是那個“位置封裝器”——ERC-721，它把抵押品和債務作爲一個整體來跟蹤，並受 MLTV（最大貸款價值比）上限約束。
讓我特別在意的是：XT 並不是填充項，它是一種獨立的金融工具，用來單獨表達利息風險，並且它的定價與 FT 的本金風險是分開的。在代幣層面把本金和利息拆開，正是讓整個系統的零和方程能夠成立——鏈條中沒有任何價值會憑空出現或消失。#TermMax
對我來說還缺的那一塊是：XT 是否存在真實的二級市場深度（secondary-market depth），因爲它在給一種非常窄的、僅包含短期利息風險的東西定價。
“哪一個代幣對你最重要？”
#termmax
@TermMax
FT (fixed yield)
67%
XT (interest pricing)
33%
GT (leverage wrapper)
0%
All three together
0%
6 票 • 投票已結束
@TermMax 我原先以爲，在 TermMax 中的強制平倉（liquidation）就和我在其他地方用過的含義一樣——跨過危險線，在一次操作中直接清掉整個倉位，中間沒有過渡。
但當我讀到真實公式後，這個假設就崩塌了。強制平倉觸發有兩種方式：LTV 達到或超過市場的 LLTV 閾值，或借款人未能按固定到期償還本金；後一種情況會無論價格如何，開啓爲期兩小時的清算窗口。$ACE
以下這組數字讓我重新理解了一切：如果未償債務超過 10,000 美元，每次事件中清算人的可得上限爲總債務價值的 50%。可被清算的抵押品最大值按以下方式計算——總抵押品乘以被清算債務，再除以總債務。這個比例的設計是：每一次強制平倉後 LTV 都會改善，而不是崩到零。只有當債務恰好降到 0 時纔會發生“完全清算”；屆時剩餘抵押品會自動返還給借款人。
罰金爲被清算債務價值的 10%，並且嚴格平分——其中 5% 作爲獎勵給清算人，另外 5% 進入協議的儲備金庫（reserve vault）。
文檔沒說的是：真實持倉裏，有多少比例的倉位會讓債務實際跨過 10,000 美元，而不是停留在該線之下——那樣的話，限額根本不會生效。 $CLO
對 TMX 的真正檢驗在於：這個 50% 的上限是否能實質性地保護大額借款人，還是僅僅把一次清算拆成兩個更小的清算連着來。$CYS
有人統計過到目前爲止 TermMax 上“部分清算 vs 完全清算”的次數嗎？
#termmax @TermMax
但當我讀到真實公式後，這個假設就崩塌了。強制平倉觸發有兩種方式：LTV 達到或超過市場的 LLTV 閾值，或借款人未能按固定到期償還本金；後一種情況會無論價格如何，開啓爲期兩小時的清算窗口。$ACE
以下這組數字讓我重新理解了一切：如果未償債務超過 10,000 美元，每次事件中清算人的可得上限爲總債務價值的 50%。可被清算的抵押品最大值按以下方式計算——總抵押品乘以被清算債務，再除以總債務。這個比例的設計是：每一次強制平倉後 LTV 都會改善，而不是崩到零。只有當債務恰好降到 0 時纔會發生“完全清算”；屆時剩餘抵押品會自動返還給借款人。
罰金爲被清算債務價值的 10%，並且嚴格平分——其中 5% 作爲獎勵給清算人，另外 5% 進入協議的儲備金庫（reserve vault）。
文檔沒說的是：真實持倉裏，有多少比例的倉位會讓債務實際跨過 10,000 美元，而不是停留在該線之下——那樣的話，限額根本不會生效。 $CLO
對 TMX 的真正檢驗在於：這個 50% 的上限是否能實質性地保護大額借款人，還是僅僅把一次清算拆成兩個更小的清算連着來。$CYS
有人統計過到目前爲止 TermMax 上“部分清算 vs 完全清算”的次數嗎？
#termmax @TermMax
真實
@Dusk 我具體查看了“Dusk如何定位自己對比以太坊”的情況，因爲大多數隱私鏈的對比通常會默認轉向Zcash或Monero，而不是以太坊。
Dusk目前的官網把目標說得很直白：面向受監管數字資產的基礎設施，默認保密，配備零知識證明，併爲審計與受監管披露提供可控的可見性。這種表述要比Dusk更早的公開定位更“鋒利”得多——當時它更側重於把Moonlight的公開交易與Phoenix的隱私保護模型結合起來，用於更廣義的受監管金融場景，而沒有像現在這樣強力地強調與以太坊“透明度”的直接對照。
在這兩種表述之間究竟發生了什麼，這點值得靜下心來想一想。以太坊的默認規則——每個餘額、每一次調用，都對任何人可見——確實非常適合公共協作。而Dusk的DuskEVM在底層保持與以太坊開發者已經熟悉的同一套工具實現完整的EVM等價，同時在下面維持“默認即被保護（shielded-by-default）”的姿態。執行模型並沒有被否定；默認的可見性纔是問題。 $DUSK
Dusk自己的站點還列出了具體的、受歐盟監管的合作伙伴：目前正在基於這種定位積極建設——包括在DLT試點監管框架下獲得許可的市場基礎設施提供商，以及一家歐洲受監管場所，正通過這種框架探索在鏈上直接發行。
這是真實的機構層面動向，而不只是宣傳口徑——但它是否因爲“透明度”這一問題而真正帶來了有意義的開發者遷移（從以太坊優先的技術棧轉向），目前我還沒有找到能夠確認的採用/遷移數據。 #dusk
如果有人追蹤過與“透明度論點”直接相關的實際遷移數據，而不是僅僅因爲Dusk更廣泛的合規主張，我會希望把這些數據與Dusk自己合作伙伴名單中公開點名的對象進行對比。
#dusk $DUSK @Dusk
Dusk目前的官網把目標說得很直白：面向受監管數字資產的基礎設施，默認保密，配備零知識證明，併爲審計與受監管披露提供可控的可見性。這種表述要比Dusk更早的公開定位更“鋒利”得多——當時它更側重於把Moonlight的公開交易與Phoenix的隱私保護模型結合起來，用於更廣義的受監管金融場景，而沒有像現在這樣強力地強調與以太坊“透明度”的直接對照。
在這兩種表述之間究竟發生了什麼，這點值得靜下心來想一想。以太坊的默認規則——每個餘額、每一次調用，都對任何人可見——確實非常適合公共協作。而Dusk的DuskEVM在底層保持與以太坊開發者已經熟悉的同一套工具實現完整的EVM等價，同時在下面維持“默認即被保護（shielded-by-default）”的姿態。執行模型並沒有被否定；默認的可見性纔是問題。 $DUSK
Dusk自己的站點還列出了具體的、受歐盟監管的合作伙伴：目前正在基於這種定位積極建設——包括在DLT試點監管框架下獲得許可的市場基礎設施提供商，以及一家歐洲受監管場所，正通過這種框架探索在鏈上直接發行。
這是真實的機構層面動向，而不只是宣傳口徑——但它是否因爲“透明度”這一問題而真正帶來了有意義的開發者遷移（從以太坊優先的技術棧轉向），目前我還沒有找到能夠確認的採用/遷移數據。 #dusk
如果有人追蹤過與“透明度論點”直接相關的實際遷移數據，而不是僅僅因爲Dusk更廣泛的合規主張，我會希望把這些數據與Dusk自己合作伙伴名單中公開點名的對象進行對比。
#dusk $DUSK @Dusk
@Dusk 過去我以爲在 Dusk 上需要一個驗證者，得看到一筆交易的細節，才能確認它確實是合法的。
但 Phoenix 的情況並不是這樣。
我追蹤的是驗證者實際收到的內容，而不是原始數據本身。Dusk 自己的架構資料也證實：Phoenix 使用零知識證明，專門用於證明未花費輸出的所有權，並防止雙重支付——驗證者校驗的是證明，而不是交易本身。
嗯。
那這個證明裏，機制上到底包含了什麼？
我思考了這點一段時間。花費方證明自己知道通往 Merkle 樹根的路徑，以及知道承諾的打開方式——也就是說，證明在數學上表明：該票據確實存在於這棵樹中，並且花費方確實知道其中包含的內容，同時不會向任何正在觀看的人泄露票據的內容或其位置。
而花費本身需要一個僅由票據所有者獨有的祕密密鑰——因此，連生成證明這一步都不可能在沒有那條別人都沒有的信息的情況下完成。
這比第一眼聽起來更“陌生”的保證。驗證者並不是在相信發送者的話。它也不在相信第三方。它是在確認一個數學命題——“樹成員關係 + 承諾知識”——成立了，但從未重建過使其成立的真實內容。
並不是說這會是更弱的檢查。相反，不去查看也許正是關鍵所在——驗證者根本不可能被它從一開始就從未收到的數據所欺騙。
一個被設計成在從不看到金額的情況下驗證“樹成員關係”和“祕密密鑰知識”的系統，是否比那個通過直接查看數據來驗證的系統更值得信任？
@Dusk #dusk $DUSK
但 Phoenix 的情況並不是這樣。
我追蹤的是驗證者實際收到的內容，而不是原始數據本身。Dusk 自己的架構資料也證實：Phoenix 使用零知識證明，專門用於證明未花費輸出的所有權，並防止雙重支付——驗證者校驗的是證明，而不是交易本身。
嗯。
那這個證明裏，機制上到底包含了什麼？
我思考了這點一段時間。花費方證明自己知道通往 Merkle 樹根的路徑，以及知道承諾的打開方式——也就是說，證明在數學上表明：該票據確實存在於這棵樹中，並且花費方確實知道其中包含的內容，同時不會向任何正在觀看的人泄露票據的內容或其位置。
而花費本身需要一個僅由票據所有者獨有的祕密密鑰——因此，連生成證明這一步都不可能在沒有那條別人都沒有的信息的情況下完成。
這比第一眼聽起來更“陌生”的保證。驗證者並不是在相信發送者的話。它也不在相信第三方。它是在確認一個數學命題——“樹成員關係 + 承諾知識”——成立了，但從未重建過使其成立的真實內容。
並不是說這會是更弱的檢查。相反，不去查看也許正是關鍵所在——驗證者根本不可能被它從一開始就從未收到的數據所欺騙。
一個被設計成在從不看到金額的情況下驗證“樹成員關係”和“祕密密鑰知識”的系統，是否比那個通過直接查看數據來驗證的系統更值得信任？
@Dusk #dusk $DUSK
@TermMax 曾經以爲，貸款只不過是以某個數字形式“出現在”賬戶餘額裏。
但我越深入瞭解 TermMax 實際如何構建一個倉位，這種想法就越站不住腳。
借款人會先鎖定抵押品。TermMax 會基於它鑄造一個“Gearing Token”，也就是 ERC-721，而不是一條賬本分錄。債務代幣、抵押品代幣以及到期日——在那個 GT 誕生之前就已經在市場層面被確定好了。
而 GT 本身只記錄兩件事：其中包含了多少抵押品；以及針對這份抵押品已經鑄造了多少“Fixed-Rate Tokens（固定利率代幣）”。該數量還會受到市場最大貸款價值比（LTV）的上限限制。例如，MLTV 爲 0.8，會把 1 ETH 變成最多 800 $USDC 可鑄造的債務。#TermMax
設計中沒有共享資金池，沒有淨額結算，也沒有在任何地方把數字混在一起。
把“隔離”這部分再重讀兩遍。根據其 2026 年 3 月的更新，TermMax 運行 100+ 個市場，每個市場彼此封閉隔離，因此在某一個市場裏出現的不良抵押品價格，從來不會波及到其他市場中那些正被動作爲 GT 持有的資產。不是記賬問題。是邊界。
你可以直接用債務代幣來償還，或者在公開市場上買回 FTs，再把它們交還回去。無論哪種方式，GT 都會關閉、抵押品釋放，但它從一開始就從未與任何其他人的數字合併過。
所以在 TermMax 借款，不是“一個會隨時間增長或縮小的數字”。而是你開了多少個 GT，就有多少份獨立的借款：每個 GT 都各自攜帶自己的抵押品、自己的債務、自己的到期日——彼此獨立。
逐筆（按每筆貸款）追蹤會讓風險更清晰，還是隻會讓規模化管理更難？
@TermMax #termmax
但我越深入瞭解 TermMax 實際如何構建一個倉位，這種想法就越站不住腳。
借款人會先鎖定抵押品。TermMax 會基於它鑄造一個“Gearing Token”，也就是 ERC-721，而不是一條賬本分錄。債務代幣、抵押品代幣以及到期日——在那個 GT 誕生之前就已經在市場層面被確定好了。
而 GT 本身只記錄兩件事：其中包含了多少抵押品；以及針對這份抵押品已經鑄造了多少“Fixed-Rate Tokens（固定利率代幣）”。該數量還會受到市場最大貸款價值比（LTV）的上限限制。例如，MLTV 爲 0.8，會把 1 ETH 變成最多 800 $USDC 可鑄造的債務。#TermMax
設計中沒有共享資金池，沒有淨額結算，也沒有在任何地方把數字混在一起。
把“隔離”這部分再重讀兩遍。根據其 2026 年 3 月的更新，TermMax 運行 100+ 個市場，每個市場彼此封閉隔離，因此在某一個市場裏出現的不良抵押品價格，從來不會波及到其他市場中那些正被動作爲 GT 持有的資產。不是記賬問題。是邊界。
你可以直接用債務代幣來償還，或者在公開市場上買回 FTs，再把它們交還回去。無論哪種方式，GT 都會關閉、抵押品釋放，但它從一開始就從未與任何其他人的數字合併過。
所以在 TermMax 借款，不是“一個會隨時間增長或縮小的數字”。而是你開了多少個 GT，就有多少份獨立的借款：每個 GT 都各自攜帶自己的抵押品、自己的債務、自己的到期日——彼此獨立。
逐筆（按每筆貸款）追蹤會讓風險更清晰，還是隻會讓規模化管理更難？
@TermMax #termmax
真實
@Dusk 曾經以爲“選擇性披露”只是“透明度”的更溫和說法。
後來我仔細研究了 Citadel 的真實設計，它並不是。
完全透明——那種 Dusk 明確反對的——意味着每一位觀察者都會看到與某一筆交易或身份相關的每個屬性，不管他們需不需要。Citadel 做得更窄，我也追蹤了它的實際機制：有三個不同的參與方，而不是兩個。用戶會向許可證提供方在鏈上發起申請。一旦簽發，這份許可證就讓用戶能夠與服務提供方建立一個私下的、鏈下連接——服務提供方只用鏈上存儲的內容來驗證該聲明，從不獲知用戶的真實身份。
嗯。
那麼當校驗通過時，服務提供方究竟學到了什麼？
只學到這一條聲明爲真——也就是該許可證所涵蓋的內容：居住地、年齡區間、資質等。不會得到賬戶背後的底層數據，也不會了解到用戶持有的任何其他屬性，更不會存在把這次校驗與未來某次校驗關聯起來的持久標識符。
這比“透明度”所承諾的要小得多。一個完全透明的系統會讓所有人永久地看到一切——無論是否相關。Citadel 的三方結構則把“一條真實信息”交給某一個服務提供方：它會基於鏈上記錄得到驗證，但該服務提供方從未觸及用戶完整檔案。
我並不是說透明度在任何地方都不對。公開協作確實受益於大家看到同一份賬本。但對“身份門控的操作”——在不自願披露完整資料的情況下證明資格——要真正可行，需要三種獨立角色的協議，而不是兩種。
通過三個分離的角色來證明一條真實信息，這種隱私保障是否比透明度的“每個人都看見一切，所以沒人能藏什麼”更強？
@Dusk #dusk $DUSK
後來我仔細研究了 Citadel 的真實設計，它並不是。
完全透明——那種 Dusk 明確反對的——意味着每一位觀察者都會看到與某一筆交易或身份相關的每個屬性，不管他們需不需要。Citadel 做得更窄，我也追蹤了它的實際機制：有三個不同的參與方，而不是兩個。用戶會向許可證提供方在鏈上發起申請。一旦簽發，這份許可證就讓用戶能夠與服務提供方建立一個私下的、鏈下連接——服務提供方只用鏈上存儲的內容來驗證該聲明，從不獲知用戶的真實身份。
嗯。
那麼當校驗通過時，服務提供方究竟學到了什麼？
只學到這一條聲明爲真——也就是該許可證所涵蓋的內容：居住地、年齡區間、資質等。不會得到賬戶背後的底層數據，也不會了解到用戶持有的任何其他屬性，更不會存在把這次校驗與未來某次校驗關聯起來的持久標識符。
這比“透明度”所承諾的要小得多。一個完全透明的系統會讓所有人永久地看到一切——無論是否相關。Citadel 的三方結構則把“一條真實信息”交給某一個服務提供方：它會基於鏈上記錄得到驗證，但該服務提供方從未觸及用戶完整檔案。
我並不是說透明度在任何地方都不對。公開協作確實受益於大家看到同一份賬本。但對“身份門控的操作”——在不自願披露完整資料的情況下證明資格——要真正可行，需要三種獨立角色的協議，而不是兩種。
通過三個分離的角色來證明一條真實信息，這種隱私保障是否比透明度的“每個人都看見一切，所以沒人能藏什麼”更強？
@Dusk #dusk $DUSK
Stronger guarantee
100%
Transparency is simpler
0%
4 票 • 投票已結束
暮光的專有倉庫聲明，消除器（nullifier）會被專門計算出來，以確保外部觀察者無法將其與任何特定筆記關聯起來。
precious Zarmalaa
·
--
空投抵消器（Nullifier）到底阻止了什麼事情再次發生
我查了具體的空投抵消器在 Dusk 上到底會阻止什麼，因爲“阻止雙重支付”這句話說得比較籠統。
它阻止的是同一條被加密保護（shielded）的憑證（note）被重複花費——僅此而已，並不比這更廣。
我追蹤了 Dusk 是如何在不泄露“到底花費了哪一條 note”的情況下實現這一點的。Dusk 自己的代碼庫說明，這個空投抵消器之所以被計算出來，是爲了讓外部觀察者無法把它與任何特定的 note 聯繫起來。網絡不會去核對 note 本身是否出現在某個列表裏；它檢查的只是：這份“空投抵消器”是否已經出現過。
我確認：一旦花費，note 並不會從任何地方被刪除。它會繼續保留在 Dusk 的 note 默克爾樹（Merkle tree）記錄中。只有空投抵消器會被加入到一份單獨的、不斷增長的記錄裏。
這一區別很關鍵。如果 note 在花費時會被刪除，我會預期僅僅觀察結構會如何隨之變小，就會泄露時間信息。把每一條 note 都保留下來（無論是否已花費），就消除了這類特定信號。
我也查看了是否會產生碰撞風險——也就是兩條不同的 note 是否可能意外地產生同一個空投抵消器。我在 Dusk 自家資料裏沒有找到任何有記錄的案例。不過，這項保證依賴於與整個系統所依賴的底層密碼學假設相同的前提。
所以在 Dusk 上，空投抵消器並不是真正在任何“可見”的意義上把一條 note 標記爲已花費。它證明確實發生了一次花費，但不會識別到底花費了什麼。
以這種方式阻止雙重支付，是否在永久、不斷增長的存儲成本上，提供了比它價值更大的隱私保護？
@Dusk #dusk $DUSK #dusk
我查了具體的空投抵消器在 Dusk 上到底會阻止什麼，因爲“阻止雙重支付”這句話說得比較籠統。
它阻止的是同一條被加密保護（shielded）的憑證（note）被重複花費——僅此而已，並不比這更廣。
我追蹤了 Dusk 是如何在不泄露“到底花費了哪一條 note”的情況下實現這一點的。Dusk 自己的代碼庫說明，這個空投抵消器之所以被計算出來，是爲了讓外部觀察者無法把它與任何特定的 note 聯繫起來。網絡不會去核對 note 本身是否出現在某個列表裏；它檢查的只是：這份“空投抵消器”是否已經出現過。
我確認：一旦花費，note 並不會從任何地方被刪除。它會繼續保留在 Dusk 的 note 默克爾樹（Merkle tree）記錄中。只有空投抵消器會被加入到一份單獨的、不斷增長的記錄裏。
這一區別很關鍵。如果 note 在花費時會被刪除，我會預期僅僅觀察結構會如何隨之變小，就會泄露時間信息。把每一條 note 都保留下來（無論是否已花費），就消除了這類特定信號。
我也查看了是否會產生碰撞風險——也就是兩條不同的 note 是否可能意外地產生同一個空投抵消器。我在 Dusk 自家資料裏沒有找到任何有記錄的案例。不過，這項保證依賴於與整個系統所依賴的底層密碼學假設相同的前提。
所以在 Dusk 上，空投抵消器並不是真正在任何“可見”的意義上把一條 note 標記爲已花費。它證明確實發生了一次花費，但不會識別到底花費了什麼。
以這種方式阻止雙重支付，是否在永久、不斷增長的存儲成本上，提供了比它價值更大的隱私保護？
@Dusk #dusk $DUSK #dusk
真實
@Dusk 假設在“Dusk”上的資格被保留是一種你曾經獲得並一直保留的東西，就像一枚一直別在身上的徽章。
但實際上這有三個彼此獨立的機制在共同運作，而其中任何一個都可能把它收走。
首先：最低質押額度。我確認一個 Dusk 的出質方（provisioner）需要鎖定 1000 DUSK；低於這個門檻，質押的其他任何情況都不再重要。
第二：成熟度。即使質押高於最低要求，也必須在固定數量的 epoch 之後，Dusk 的 sortition（選取機制）纔會把這筆質押計算在內。$DUSK
第三，也是我差點沒注意到的：懲罰機制。我發現重複的過失不只是減少獎勵——每一次連續的停權都會把一部分不斷升級的質押比例轉入可被申領的獎勵池：從 10% 開始，並且隨着每一次後續違規以 10% 的幅度遞增。
我追蹤了當這種懲罰把一筆質押壓到 1000 DUSK 的最低底線以下時會發生什麼。它不只是讓它在 sortition 裏“變輕”。我發現它會直接被凍結——想要重新回到 Dusk，就只能先解除這部分被凍結餘額的質押，然後再投入新的質押。
所以，資格並不是出質方只需通過一次的單一關卡。這是三個獨立機制——一個底線、一個時鐘、以及一套懲罰計劃——任何一個都可能在不聲不響中取消一個以爲自己仍在活躍中的 Dusk 出質方資格。 #dusk
那麼，把資格疊加在三個彼此獨立的機制上，究竟能讓 Dusk 更不容易被“鑽空子”，還是說只會讓一個誠實的出質方更容易失去狀態，卻又不會立刻知道原因？
#dusk $DUSK @Dusk
但實際上這有三個彼此獨立的機制在共同運作，而其中任何一個都可能把它收走。
首先：最低質押額度。我確認一個 Dusk 的出質方（provisioner）需要鎖定 1000 DUSK；低於這個門檻，質押的其他任何情況都不再重要。
第二：成熟度。即使質押高於最低要求，也必須在固定數量的 epoch 之後，Dusk 的 sortition（選取機制）纔會把這筆質押計算在內。$DUSK
第三，也是我差點沒注意到的：懲罰機制。我發現重複的過失不只是減少獎勵——每一次連續的停權都會把一部分不斷升級的質押比例轉入可被申領的獎勵池：從 10% 開始，並且隨着每一次後續違規以 10% 的幅度遞增。
我追蹤了當這種懲罰把一筆質押壓到 1000 DUSK 的最低底線以下時會發生什麼。它不只是讓它在 sortition 裏“變輕”。我發現它會直接被凍結——想要重新回到 Dusk，就只能先解除這部分被凍結餘額的質押，然後再投入新的質押。
所以，資格並不是出質方只需通過一次的單一關卡。這是三個獨立機制——一個底線、一個時鐘、以及一套懲罰計劃——任何一個都可能在不聲不響中取消一個以爲自己仍在活躍中的 Dusk 出質方資格。 #dusk
那麼，把資格疊加在三個彼此獨立的機制上，究竟能讓 Dusk 更不容易被“鑽空子”，還是說只會讓一個誠實的出質方更容易失去狀態，卻又不會立刻知道原因？
#dusk $DUSK @Dusk
More resistant
100%
Easy to lose status
0%
3 票 • 投票已結束
暮色正在圍繞一個問題逐步成形：透明區塊鏈並不總能有效地高效解決它。
precious Zarmalaa
·
--
DUSK 的兩種交易模型：月光與鳳凰
今晚我在 Dusk 的測試網裏查看了一個簡單的轉賬流程，在同一測試金額下，我在公開錢包視圖和隱蔽（shielded）視圖之間切換。公開側立刻顯示了所有信息：發送方、接收方、金額。隱蔽側幾乎什麼都沒顯示。
我以爲這只是同一底層交易的兩種顯示模式。起初這樣理解也很合理。
但我錯了。月光（Moonlight）是基於賬戶（account-based）的。餘額明文存在，轉賬默認會暴露發送方、接收方以及金額。鳳凰（Phoenix）的工作方式不同。資金以加密注（encrypted notes）的形式存在。
它背後有一套零知識證明（zero-knowledge proof），只用來確認交易檢查通過——並不會顯示金額、發送方，或到底使用了哪些注（notes）。
兩種不同的交易模型，而不是同一種模型的兩種視圖；區分這一點，纔是之所以要對比它們的關鍵。
在我關上筆記本再回來之後，我反覆想到的一點是：兩者最終仍然通過 Dusk 的同一處來完成結算。DuskDS 同時處理兩種情況。Transfer Contract（轉賬合約）接受任意一種載荷類型，並將其路由到對應的校驗邏輯，從而保證無論哪種方式，網絡的全局狀態都保持一致。
在月光與鳳凰之間的選擇，並不是在決定使用哪條鏈。這是在同一個結算層內部、每一筆交易層面做出的取捨：讓網絡的其餘部分能看到多少。
我仍然不知道：當工作流並不嚴格要求隱私時，構建者（builders）通常會默認採用其中哪一種模型。
如果一個錢包讓你可以按每筆交易進行選擇，你會默認先選哪種模型？
@Dusk #dusk $DUSK #dusk
今晚我在 Dusk 的測試網裏查看了一個簡單的轉賬流程，在同一測試金額下，我在公開錢包視圖和隱蔽（shielded）視圖之間切換。公開側立刻顯示了所有信息：發送方、接收方、金額。隱蔽側幾乎什麼都沒顯示。
我以爲這只是同一底層交易的兩種顯示模式。起初這樣理解也很合理。
但我錯了。月光（Moonlight）是基於賬戶（account-based）的。餘額明文存在，轉賬默認會暴露發送方、接收方以及金額。鳳凰（Phoenix）的工作方式不同。資金以加密注（encrypted notes）的形式存在。
它背後有一套零知識證明（zero-knowledge proof），只用來確認交易檢查通過——並不會顯示金額、發送方，或到底使用了哪些注（notes）。
兩種不同的交易模型，而不是同一種模型的兩種視圖；區分這一點，纔是之所以要對比它們的關鍵。
在我關上筆記本再回來之後，我反覆想到的一點是：兩者最終仍然通過 Dusk 的同一處來完成結算。DuskDS 同時處理兩種情況。Transfer Contract（轉賬合約）接受任意一種載荷類型，並將其路由到對應的校驗邏輯，從而保證無論哪種方式，網絡的全局狀態都保持一致。
在月光與鳳凰之間的選擇，並不是在決定使用哪條鏈。這是在同一個結算層內部、每一筆交易層面做出的取捨：讓網絡的其餘部分能看到多少。
我仍然不知道：當工作流並不嚴格要求隱私時，構建者（builders）通常會默認採用其中哪一種模型。
如果一個錢包讓你可以按每筆交易進行選擇，你會默認先選哪種模型？
@Dusk #dusk $DUSK #dusk
真實
#dusk $DUSK
在 DUSK 網絡上，DuskVM 與 DuskEVM 的對比
@Dusk 一開始我以爲，在 DuskVM 和 DuskEVM 之間做選擇，歸根結底就是語言：Rust 與 WASM 對比 Solidity 以及大家早已用慣的 EVM 工具鏈。今晚本來打算很快理清，結果比預期花了更久；在某個瞬間，它不再像是在做“語言選擇”。
DuskVM 直接位於網絡的最底層，因此它能夠直接接入 Dusk 真正圍繞其構建的隱私與零知識相關內容。DuskEVM 會通過標準的 EVM 工具鏈來運行 Solidity 合約，但最終仍會通過同一個 DuskDS 層完成結算併發布其數據；無論哪條路徑，支付的都是同一種 DUSK 代幣燃氣。這裏有一種我反覆在意的“非對稱中的對稱”：執行路徑不同，結算相同；而兩者底層都依賴同一種代幣。
選擇 DuskVM 不只是選擇一種語言，它更像是在選擇與隱私原語本身的“距離”。選擇 DuskEVM 不只是追求熟悉度，它意味着相對這些原語而言更遠——至少對大多數開發者已經熟悉的工具鏈來說是這樣。很多比較都會跳過這種細微的摩擦。#dusk
在這兩者之下，還有第三層：我總是回到它。Dusk 的文檔表明，DuskEVM 允許現有的 EVM 錢包、橋接（bridge）和交易所幾乎不需要改動代碼就能接入，速度要快於原生集成所需的時間。DuskVM 則沒有類似的快捷路徑。每次都必須從零開始爲它構建相應的工具鏈。$DUSK
兩者之間的功能對齊並不能被保證：畢竟它們雖然都通過同一層進行結算，並且共享同一種燃氣代幣。但從表面看“可選性”的地方，實際上是對成本究竟在哪裏被支付的兩種不同押注——要麼前置在工具鏈上，要麼延後在環境本身無法做到的地方。
Dusk 真的在給構建者提供選擇嗎？還是說，它只是替大家決定：這些摩擦究竟會在什麼時候、哪裏出現？ @Dusk
在 DUSK 網絡上，DuskVM 與 DuskEVM 的對比
@Dusk 一開始我以爲，在 DuskVM 和 DuskEVM 之間做選擇，歸根結底就是語言：Rust 與 WASM 對比 Solidity 以及大家早已用慣的 EVM 工具鏈。今晚本來打算很快理清，結果比預期花了更久；在某個瞬間，它不再像是在做“語言選擇”。
DuskVM 直接位於網絡的最底層，因此它能夠直接接入 Dusk 真正圍繞其構建的隱私與零知識相關內容。DuskEVM 會通過標準的 EVM 工具鏈來運行 Solidity 合約，但最終仍會通過同一個 DuskDS 層完成結算併發布其數據；無論哪條路徑，支付的都是同一種 DUSK 代幣燃氣。這裏有一種我反覆在意的“非對稱中的對稱”：執行路徑不同，結算相同；而兩者底層都依賴同一種代幣。
選擇 DuskVM 不只是選擇一種語言，它更像是在選擇與隱私原語本身的“距離”。選擇 DuskEVM 不只是追求熟悉度，它意味着相對這些原語而言更遠——至少對大多數開發者已經熟悉的工具鏈來說是這樣。很多比較都會跳過這種細微的摩擦。#dusk
在這兩者之下，還有第三層：我總是回到它。Dusk 的文檔表明，DuskEVM 允許現有的 EVM 錢包、橋接（bridge）和交易所幾乎不需要改動代碼就能接入，速度要快於原生集成所需的時間。DuskVM 則沒有類似的快捷路徑。每次都必須從零開始爲它構建相應的工具鏈。$DUSK
兩者之間的功能對齊並不能被保證：畢竟它們雖然都通過同一層進行結算，並且共享同一種燃氣代幣。但從表面看“可選性”的地方，實際上是對成本究竟在哪裏被支付的兩種不同押注——要麼前置在工具鏈上，要麼延後在環境本身無法做到的地方。
Dusk 真的在給構建者提供選擇嗎？還是說，它只是替大家決定：這些摩擦究竟會在什麼時候、哪裏出現？ @Dusk
#dusk $DUSK
@Dusk 我曾以爲“隱私鏈”意味着默認情況下每一筆交易都會被隱藏，絕無例外。
後來我讀了 Moonlight 在 Dusk 上究竟是怎麼做的。
Dusk 在同一個結算層上運行兩種原生交易模型。Moonlight 是基於賬戶的、公開的；發送方、接收方以及金額都可見。Phoenix 是基於備註（note）的、被保護（shielded）的；資金以加密備註的形式存放，而不是以持續的餘額形式存在，更接近“可用於支出”的單位，而非一個賬戶總額。#dusk
也就是這句“默認情況下”，改變了我對這件事的理解。我又回去把那一段重新讀了兩遍，只爲確保我理解無誤。
一次轉賬會在兩種模型中選擇其一，從不混用。通過 Moonlight 發送 DUSK 時，它完全透明，適用於那些需要保持可觀察性的流程——文檔裏給出的示例就是類似某種金庫或報表場景。通過 Phoenix 發送時，金額、發送方以及移動了哪些具體備註都會保持隱藏；它通過零知識證明來證明是正確的，而不是直接展示出來。不過，查看密鑰（viewing key）可以讓質押者選擇向其展示同一份隱藏數據。 $DUSK
一個 Transfer Contract 既能處理兩者：將每個載荷路由到相應的校驗邏輯，無論選哪種模型，都能保持全局狀態一致。
所以在這裏，隱私在協議層面也不是二元的。它是每筆轉賬的一個選擇；而且即使是“被保護”的選擇，也有一套在請求時重新變得可見的、被文檔明確說明的方式。
這個選擇在發送方手裏，而不是在協議本身。
給用戶提供一個公開選項，會削弱“隱私”這種說法嗎？還是說，可選且可撤銷的隱私，纔是面向受監管市場時更誠實的設計？
可選的隱私還是隱私嗎？
@Dusk 我曾以爲“隱私鏈”意味着默認情況下每一筆交易都會被隱藏，絕無例外。
後來我讀了 Moonlight 在 Dusk 上究竟是怎麼做的。
Dusk 在同一個結算層上運行兩種原生交易模型。Moonlight 是基於賬戶的、公開的；發送方、接收方以及金額都可見。Phoenix 是基於備註（note）的、被保護（shielded）的；資金以加密備註的形式存放，而不是以持續的餘額形式存在，更接近“可用於支出”的單位，而非一個賬戶總額。#dusk
也就是這句“默認情況下”，改變了我對這件事的理解。我又回去把那一段重新讀了兩遍，只爲確保我理解無誤。
一次轉賬會在兩種模型中選擇其一，從不混用。通過 Moonlight 發送 DUSK 時，它完全透明，適用於那些需要保持可觀察性的流程——文檔裏給出的示例就是類似某種金庫或報表場景。通過 Phoenix 發送時，金額、發送方以及移動了哪些具體備註都會保持隱藏；它通過零知識證明來證明是正確的，而不是直接展示出來。不過，查看密鑰（viewing key）可以讓質押者選擇向其展示同一份隱藏數據。 $DUSK
一個 Transfer Contract 既能處理兩者：將每個載荷路由到相應的校驗邏輯，無論選哪種模型，都能保持全局狀態一致。
所以在這裏，隱私在協議層面也不是二元的。它是每筆轉賬的一個選擇；而且即使是“被保護”的選擇，也有一套在請求時重新變得可見的、被文檔明確說明的方式。
這個選擇在發送方手裏，而不是在協議本身。
給用戶提供一個公開選項，會削弱“隱私”這種說法嗎？還是說，可選且可撤銷的隱私，纔是面向受監管市場時更誠實的設計？
可選的隱私還是隱私嗎？
登入以探索更多內容