Binance Square
B A S I L KHAN
433 貼文

B A S I L KHAN

112 關注
19 粉絲
248 點讚數
貼文
·
--
#dusk $DUSK @Dusk_Foundation 今天我按順序回看了 NPEX/Dusk 的公告歷史,沒有先看最新的炒作帖子,然後把時間線按時間順序對齊後,實際情況看起來不一樣。 2025年12月:Dusk 和 NPEX 合作推出據稱爲“歐洲首個基於區塊鏈的證券交易所”,其中 NPEX 作爲獲得許可的荷蘭 MTF 來運營。2025年2月:Cordial Systems 加入,作爲託管層。2025年11月:Dusk 和 NPEX 採用 Chainlink 的 CCIP 與 DataLink 標準,具體是爲了讓 NPEX 官方交易所數據能夠上鍊發佈。 Dusk Trade dApp 本身被描述爲運行在 DuskEVM 上,起步於來自 NPEX、21X 以及其他機構玩家的代幣化資產,並且在早期報道中提到了諸如“約 3 億歐元資產”等數字。 這套監管架構確實非常“硬”——MTF、經紀商、ECSP 牌照,並且還有一項描述爲即將到來的 DLT-TSS 牌照。這並不是紙面合作;NPEX 已經在荷蘭運行了一個真實的、獲得許可的證券二級市場。 但我翻遍了我能找到的、在過去幾個月裏發佈的每一條來源,卻找不到任何一個已被確認的數字:到底有多少資產今天在 Dusk Trade 上真實上線並可交易,而有多少僅作爲公告中點名的合作方存在。每一處我找到的描述都講的是能力、許可以及集成工作——而不是當前的掛牌/上架數量。把“3 億歐元資產”當作已經完成代幣化並正在交易,那等於把結果當作了原因,而我目前還沒有證據。 接下來我真正要覈查的是:Dusk Trade 是否像交易所那樣發佈一個公開、可查詢的掛牌數量;NPEX 自己面向投資者的網站是否提到的是正在進行的基於 Dusk 的交易,而不是僅僅停留在合作本身;以及 Chainlink DataLink 的數據源是否正在把實時的 NPEX 市場數據推送到鏈上,還是仍處於集成測試階段。
#dusk $DUSK @Dusk 今天我按順序回看了 NPEX/Dusk 的公告歷史,沒有先看最新的炒作帖子,然後把時間線按時間順序對齊後,實際情況看起來不一樣。
2025年12月:Dusk 和 NPEX 合作推出據稱爲“歐洲首個基於區塊鏈的證券交易所”,其中 NPEX 作爲獲得許可的荷蘭 MTF 來運營。2025年2月:Cordial Systems 加入,作爲託管層。2025年11月:Dusk 和 NPEX 採用 Chainlink 的 CCIP 與 DataLink 標準,具體是爲了讓 NPEX 官方交易所數據能夠上鍊發佈。
Dusk Trade dApp 本身被描述爲運行在 DuskEVM 上,起步於來自 NPEX、21X 以及其他機構玩家的代幣化資產,並且在早期報道中提到了諸如“約 3 億歐元資產”等數字。
這套監管架構確實非常“硬”——MTF、經紀商、ECSP 牌照,並且還有一項描述爲即將到來的 DLT-TSS 牌照。這並不是紙面合作;NPEX 已經在荷蘭運行了一個真實的、獲得許可的證券二級市場。
但我翻遍了我能找到的、在過去幾個月裏發佈的每一條來源,卻找不到任何一個已被確認的數字:到底有多少資產今天在 Dusk Trade 上真實上線並可交易,而有多少僅作爲公告中點名的合作方存在。每一處我找到的描述都講的是能力、許可以及集成工作——而不是當前的掛牌/上架數量。把“3 億歐元資產”當作已經完成代幣化並正在交易,那等於把結果當作了原因,而我目前還沒有證據。
接下來我真正要覈查的是:Dusk Trade 是否像交易所那樣發佈一個公開、可查詢的掛牌數量;NPEX 自己面向投資者的網站是否提到的是正在進行的基於 Dusk 的交易,而不是僅僅停留在合作本身;以及 Chainlink DataLink 的數據源是否正在把實時的 NPEX 市場數據推送到鏈上,還是仍處於集成測試階段。
#dusk $DUSK @Dusk_Foundation 今天我試着直接從 DuskEVM 測試網瀏覽器上拉取實時數據,而不是信任公告帖內容。結果遇到了一些改變了我實際要查看的東西。 該測試網瀏覽器基於 Blockscout,通常通過可查詢的 API 提供數據——但頁面本身是由客戶端渲染的,所以我無法通過直接請求提取當前的交易/合約數量。這確實是從瀏覽器之外進行覈查時的真實限制,我也不想在沒有實際驗證的情況下隨口報一個數字。 不過我確實發現了比“原始計數”更有意思的線索。DuskEVM 的公開測試網於 2025 年 12 月 5 日上線,當時的描述是“主網上線前的最後一步”。另一個用於 DuskEVM Mainnet 的 Blockscout 實例已經存在,並且截至今天正在索引數據。這個時間線比八個月前“主網上線前的最後一步”的說法要緊得多——而且 2026 年 8 月 10 日帶有 Dusk 標籤的帖子仍在爲用於 Solidity/Hardhat 測試的測試網做宣傳,這就引出了一個切實的問題:開發者目前究竟被引導去哪個環境。 我還注意到 DuskEVM 的架構有一個值得標記的結構性怪點:它目前是隻運行 sequencer(排序器)的模式,沒有公開的 mempool(內存池)。在這一階段,對 OP Stack rollup 來說這很正常,但這意味着這裏的“活躍度”衡量方式與 L1 並不相同——測試網較低的交易數量並不必然意味着開發者興趣也低,因爲只由 sequencer 的鏈不會像以太坊的 mempool 那樣展示待處理活動。 因此,我現在追蹤的並不是我無法驗證的某個數字:我在看 Dusk 自己的渠道是否開始把開發者導向主網瀏覽器,而不是測試網;測試網是否會被明確棄用或是否會與主網並行繼續運行;以及主網 Blockscout 實例上的“已驗證合約”數量是否開始隨着真實部署而攀升,而不是僅僅來自測試腳本。
#dusk $DUSK @Dusk 今天我試着直接從 DuskEVM 測試網瀏覽器上拉取實時數據,而不是信任公告帖內容。結果遇到了一些改變了我實際要查看的東西。
該測試網瀏覽器基於 Blockscout,通常通過可查詢的 API 提供數據——但頁面本身是由客戶端渲染的,所以我無法通過直接請求提取當前的交易/合約數量。這確實是從瀏覽器之外進行覈查時的真實限制,我也不想在沒有實際驗證的情況下隨口報一個數字。
不過我確實發現了比“原始計數”更有意思的線索。DuskEVM 的公開測試網於 2025 年 12 月 5 日上線,當時的描述是“主網上線前的最後一步”。另一個用於 DuskEVM Mainnet 的 Blockscout 實例已經存在,並且截至今天正在索引數據。這個時間線比八個月前“主網上線前的最後一步”的說法要緊得多——而且 2026 年 8 月 10 日帶有 Dusk 標籤的帖子仍在爲用於 Solidity/Hardhat 測試的測試網做宣傳,這就引出了一個切實的問題:開發者目前究竟被引導去哪個環境。
我還注意到 DuskEVM 的架構有一個值得標記的結構性怪點:它目前是隻運行 sequencer(排序器)的模式,沒有公開的 mempool(內存池)。在這一階段,對 OP Stack rollup 來說這很正常,但這意味着這裏的“活躍度”衡量方式與 L1 並不相同——測試網較低的交易數量並不必然意味着開發者興趣也低,因爲只由 sequencer 的鏈不會像以太坊的 mempool 那樣展示待處理活動。
因此,我現在追蹤的並不是我無法驗證的某個數字:我在看 Dusk 自己的渠道是否開始把開發者導向主網瀏覽器,而不是測試網;測試網是否會被明確棄用或是否會與主網並行繼續運行;以及主網 Blockscout 實例上的“已驗證合約”數量是否開始隨着真實部署而攀升,而不是僅僅來自測試腳本。
#dusk $DUSK @Dusk_Foundation 今天我去查了支撐 Citadel 的實際 GitHub 倉庫,而不是隻看公告頁面;兩個之間的差距比我預想得更大。 Citadel 在 2023 年 1 月就正式發佈了一整套研究論文、一個可運行的協議設計、三個明確參與方(用戶、許可證提供方、服務提供方),以及一個專門爲解決真實問題而構建的私有 NFT 模型:即便零知識證明會隱藏憑證內容,憑證本身通常也會以公開、可追蹤的鏈上數值形式存儲。Citadel 的全部貢獻就在於修補這處泄漏。 相關工具也已經有了——Moat、Citadel SDK 已在 GitHub 上上線了,包含用於基於該協議開發的命令行界面(CLI)和遠程訪問 API;這要求你運行一個 Rusk 節點,並連接錢包。 這不是空談;代碼是真實存在且開源的。 但查看當前的文檔中心時,我發現了一條讓我停下來的註記:SDK “存在,但需要針對當前的 Rusk 模型進行更新。” 這在“協議被設計併發布”與“協議正在針對網絡的當前實現持續維護”之間,構成了一個很有分量的斷層。一份三年前的密碼學設計在技術上依然正確,並不能告訴你集成層是否跟得上——而鏈上此後已經經歷了多層架構的遷移。 我不認爲這意味着 Citadel 被拋棄——研究級的隱私工具往往在集成工作階段之間會沉寂一段時間,尤其是在團隊把注意力放在 DuskDS/DuskEVM/DuskVM 的時候。不過,這確實意味着:現在就把 Citadel 作爲“活躍的合規基礎設施”的證據來引用,會高估了 SDK 實際所處的位置。 接下來我會持續關注三點:Moat 是否會提交更新,使其適配當前的 Rusk 模型;是否有任何被點名的機構或 KYC 提供方會把 Citadel 部署到生產環境,而不是僅把它當作用例來提及;以及 Citadel 是否會被明確納入 DuskEVM/DuskVM 的路線圖,還是仍作爲一個獨立的 2023 年產物。
#dusk $DUSK @Dusk 今天我去查了支撐 Citadel 的實際 GitHub 倉庫,而不是隻看公告頁面;兩個之間的差距比我預想得更大。
Citadel 在 2023 年 1 月就正式發佈了一整套研究論文、一個可運行的協議設計、三個明確參與方(用戶、許可證提供方、服務提供方),以及一個專門爲解決真實問題而構建的私有 NFT 模型:即便零知識證明會隱藏憑證內容,憑證本身通常也會以公開、可追蹤的鏈上數值形式存儲。Citadel 的全部貢獻就在於修補這處泄漏。
相關工具也已經有了——Moat、Citadel SDK 已在 GitHub 上上線了,包含用於基於該協議開發的命令行界面(CLI)和遠程訪問 API;這要求你運行一個 Rusk 節點,並連接錢包。 這不是空談;代碼是真實存在且開源的。
但查看當前的文檔中心時,我發現了一條讓我停下來的註記:SDK “存在,但需要針對當前的 Rusk 模型進行更新。” 這在“協議被設計併發布”與“協議正在針對網絡的當前實現持續維護”之間,構成了一個很有分量的斷層。一份三年前的密碼學設計在技術上依然正確,並不能告訴你集成層是否跟得上——而鏈上此後已經經歷了多層架構的遷移。
我不認爲這意味着 Citadel 被拋棄——研究級的隱私工具往往在集成工作階段之間會沉寂一段時間,尤其是在團隊把注意力放在 DuskDS/DuskEVM/DuskVM 的時候。不過,這確實意味着:現在就把 Citadel 作爲“活躍的合規基礎設施”的證據來引用,會高估了 SDK 實際所處的位置。
接下來我會持續關注三點:Moat 是否會提交更新,使其適配當前的 Rusk 模型;是否有任何被點名的機構或 KYC 提供方會把 Citadel 部署到生產環境,而不是僅把它當作用例來提及;以及 Citadel 是否會被明確納入 DuskEVM/DuskVM 的路線圖,還是仍作爲一個獨立的 2023 年產物。
#dusk $DUSK @Dusk_Foundation 如果有人告訴你“Dusk 上的付款已被確認("confirmed")”,你會真的基於這句話放行貨物、簽署合同,還是發起電匯嗎? 我回頭重新查看了最終性(finality)的各個狀態,才意識到我一直把“confirmed”和“done”當成可互換的詞處理了,但在這條鏈上其實並不準確。 一個區塊會經歷四種獨立的狀態:Accepted(已接受)、Confirmed(已確認)、Stable(穩定)、Final(最終)。只有 Final 是確定性的,並且在加密意義上被真正地、不可逆地保證。Stable 則是緊接在它前一階段的狀態,明確是概率性的,而不是絕對的。它的意思是:區塊已經埋得足夠深,發生回滾的可能性極低,但並不表示回滾在數學上不可能。 在涉及真實資金時,這個區別就至關重要。如果你把一個“穩定但尚未最終(Stable-but-not-yet-Final)”的交易當作結算依據來釋放資產、確認一筆交易、把資金視爲已清算,你接受的是一種“概率”,而不是“保證”;即使僅從錢包或瀏覽器上的狀態標籤來看,二者差別並不顯而易見。 另外,要真正達到“最終(Final)”狀態所需的區塊數量也不是固定不變的。Dusk 已切換到“滾動最終性(rolling finality)”模型:需要的區塊數會隨着網絡狀況在不同輪次間變化。這意味着你無法盲目依賴某條“等 X 個區塊就安全了”的固定規則。 @Dusk_Foundation _Foundation 我還沒有找到在真實網絡條件下,Stable 與 Final 之間的時間差在最壞情況下可能拉長到多長的清晰、已發佈的數字;我只能確定這是設計上可變的。 如果你在 Dusk 上做任何涉及真實結算的事情,你是否真的在把資金視爲安全之前檢查是否達到 Final,還是在達到 Stable 之後就停下了,因爲“聽起來已經完成(finished)”這個詞讓人覺得夠了?
#dusk $DUSK @Dusk 如果有人告訴你“Dusk 上的付款已被確認("confirmed")”,你會真的基於這句話放行貨物、簽署合同,還是發起電匯嗎?
我回頭重新查看了最終性(finality)的各個狀態,才意識到我一直把“confirmed”和“done”當成可互換的詞處理了,但在這條鏈上其實並不準確。
一個區塊會經歷四種獨立的狀態:Accepted(已接受)、Confirmed(已確認)、Stable(穩定)、Final(最終)。只有 Final 是確定性的,並且在加密意義上被真正地、不可逆地保證。Stable 則是緊接在它前一階段的狀態,明確是概率性的,而不是絕對的。它的意思是:區塊已經埋得足夠深,發生回滾的可能性極低,但並不表示回滾在數學上不可能。
在涉及真實資金時,這個區別就至關重要。如果你把一個“穩定但尚未最終(Stable-but-not-yet-Final)”的交易當作結算依據來釋放資產、確認一筆交易、把資金視爲已清算,你接受的是一種“概率”,而不是“保證”;即使僅從錢包或瀏覽器上的狀態標籤來看,二者差別並不顯而易見。
另外,要真正達到“最終(Final)”狀態所需的區塊數量也不是固定不變的。Dusk 已切換到“滾動最終性(rolling finality)”模型:需要的區塊數會隨着網絡狀況在不同輪次間變化。這意味着你無法盲目依賴某條“等 X 個區塊就安全了”的固定規則。
@Dusk _Foundation 我還沒有找到在真實網絡條件下,Stable 與 Final 之間的時間差在最壞情況下可能拉長到多長的清晰、已發佈的數字;我只能確定這是設計上可變的。
如果你在 Dusk 上做任何涉及真實結算的事情,你是否真的在把資金視爲安全之前檢查是否達到 Final,還是在達到 Stable 之後就停下了,因爲“聽起來已經完成(finished)”這個詞讓人覺得夠了?
#dusk $DUSK @Dusk_Foundation 如果你把 DUSK 通過 DuskEVM 橋發送過去,你到底怎麼確定另一邊你的資金是安全、可以用來花的——如果你猜錯了會發生什麼? 我在差點做出一個可能會讓我付出代價的假設之後,去深入瞭解了一下。我的直覺是:區塊瀏覽器裏顯示已包含(inclusion confirmed),所以資金一定能用。結果發現,正是這種想法纔是錯的。 Dusk 自己的開發者文檔對此講得很直白:包含(inclusion)和結算(settlement)是兩個獨立的階段,而在 DuskEVM 與 DuskDS 層之間轉移價值的應用,明確被要求直接檢查協議或錢包狀態——而不是僅因爲過去了一段時間就推斷“已達成最終性”。DuskEVM 上的交易之所以看起來包含得很快,是因爲它是基於 sequencer 的 L2,但這並不等同於你的資金實際已經結算完成,並且在基礎層(base layer)上對其最終性與安全性都已保障的那一刻。 實際意味着什麼:如果你在橋接資產時,發送或消費基於“現在大概已經完成了”,你就在依賴一種協議明確警告不要依賴的“猜測”。“看起來已包含”到“實際上已結算”之間的這段空窗期,正是太早行動會造成真實暴露的那種情形——使用那些在真正最終之前仍可能被重組或判爲無效的資金。 @Dusk_Foundation _Foundation — 我還沒有找到在正常網絡條件下,DuskEVM 包含(inclusion)與 DuskDS 結算最終性(settlement finality)之間的實際典型等待時間的已發佈數字;我只找到的是指導意見:應該檢查狀態,而不是按經過的時間去數。 如果協議本身都說不要用經過時間去估算,那麼大多數錢包和橋接 UI 真的在向用戶展示真實的結算狀態嗎?還是人們仍然只是盯着計時器,然後在猜?
#dusk $DUSK @Dusk 如果你把 DUSK 通過 DuskEVM 橋發送過去,你到底怎麼確定另一邊你的資金是安全、可以用來花的——如果你猜錯了會發生什麼?
我在差點做出一個可能會讓我付出代價的假設之後,去深入瞭解了一下。我的直覺是:區塊瀏覽器裏顯示已包含(inclusion confirmed),所以資金一定能用。結果發現,正是這種想法纔是錯的。
Dusk 自己的開發者文檔對此講得很直白:包含(inclusion)和結算(settlement)是兩個獨立的階段,而在 DuskEVM 與 DuskDS 層之間轉移價值的應用,明確被要求直接檢查協議或錢包狀態——而不是僅因爲過去了一段時間就推斷“已達成最終性”。DuskEVM 上的交易之所以看起來包含得很快,是因爲它是基於 sequencer 的 L2,但這並不等同於你的資金實際已經結算完成,並且在基礎層(base layer)上對其最終性與安全性都已保障的那一刻。
實際意味着什麼:如果你在橋接資產時,發送或消費基於“現在大概已經完成了”,你就在依賴一種協議明確警告不要依賴的“猜測”。“看起來已包含”到“實際上已結算”之間的這段空窗期,正是太早行動會造成真實暴露的那種情形——使用那些在真正最終之前仍可能被重組或判爲無效的資金。
@Dusk _Foundation — 我還沒有找到在正常網絡條件下,DuskEVM 包含(inclusion)與 DuskDS 結算最終性(settlement finality)之間的實際典型等待時間的已發佈數字;我只找到的是指導意見:應該檢查狀態,而不是按經過的時間去數。
如果協議本身都說不要用經過時間去估算,那麼大多數錢包和橋接 UI 真的在向用戶展示真實的結算狀態嗎?還是人們仍然只是盯着計時器,然後在猜?
#dusk $DUSK @Dusk_Foundation 在兩個層面並排測試資產發行流程時,我發現這兩個協議並不只是把同一個工具移植到不同的鏈上——它們是在底層用真正不同的加密方式來解決隱私問題。 Zedger 原生運行在 DuskDS 上,屬於基於 UTXO 的體系,這意味着它能夠以一種結構上很難在基於賬戶的系統中復現的方式提供完整匿名。Hedger 則運行在 DuskEVM 上,爲與標準以太坊工具的完全 EVM 兼容性而構建——但由於 EVM 的基於賬戶模型無法承載與 Zedger 相同的匿名能力,Hedger 走的是完全不同的技術路線。它將同態加密(在橢圓曲線上使用 ElGamal)與零知識證明結合起來:餘額與轉賬在端到端保持加密,同時仍然可以被計算與審計,而不只是“被隱藏”。 我沒想到的一點是:Hedger 的證明會在客戶端、在瀏覽器中生成,並且在兩秒內完成。這不是誇大宣傳——它足夠快,機構級用戶在 EVM 側進行私密交易時不需要專門的證明基礎設施。 因此,在 Zedger 和 Hedger 之間做的實際選擇,並不是“哪個更隱私”。而是發行方需要哪種信任與工具模型。Zedger 提供 UTXO 級別的匿名性,但要求使用原生的 Dusk 工具。Hedger 提供完整的以太坊兼容性以及快速的瀏覽器端證明,但由於其構建在賬戶模型之上,意味着它放棄了同樣的匿名上限。 目前我還沒有看到一個清晰答案:當發行方需要在同一資產中同時實現 EVM 可組合性與 Zedger 級別的匿名時,究竟應該如何在兩者之間做決定——這在今天是否甚至可行,還是說它迫使產生某種無人真正完全解決的權衡。
#dusk $DUSK @Dusk 在兩個層面並排測試資產發行流程時,我發現這兩個協議並不只是把同一個工具移植到不同的鏈上——它們是在底層用真正不同的加密方式來解決隱私問題。
Zedger 原生運行在 DuskDS 上,屬於基於 UTXO 的體系,這意味着它能夠以一種結構上很難在基於賬戶的系統中復現的方式提供完整匿名。Hedger 則運行在 DuskEVM 上,爲與標準以太坊工具的完全 EVM 兼容性而構建——但由於 EVM 的基於賬戶模型無法承載與 Zedger 相同的匿名能力,Hedger 走的是完全不同的技術路線。它將同態加密(在橢圓曲線上使用 ElGamal)與零知識證明結合起來:餘額與轉賬在端到端保持加密,同時仍然可以被計算與審計,而不只是“被隱藏”。
我沒想到的一點是:Hedger 的證明會在客戶端、在瀏覽器中生成,並且在兩秒內完成。這不是誇大宣傳——它足夠快,機構級用戶在 EVM 側進行私密交易時不需要專門的證明基礎設施。
因此,在 Zedger 和 Hedger 之間做的實際選擇,並不是“哪個更隱私”。而是發行方需要哪種信任與工具模型。Zedger 提供 UTXO 級別的匿名性,但要求使用原生的 Dusk 工具。Hedger 提供完整的以太坊兼容性以及快速的瀏覽器端證明,但由於其構建在賬戶模型之上,意味着它放棄了同樣的匿名上限。
目前我還沒有看到一個清晰答案:當發行方需要在同一資產中同時實現 EVM 可組合性與 Zedger 級別的匿名時,究竟應該如何在兩者之間做決定——這在今天是否甚至可行,還是說它迫使產生某種無人真正完全解決的權衡。
#dusk $DUSK @Dusk_Foundation 在本地運行證明生成以基準測試電路性能時,我發現了一些東西,讓我沒有繼續停留在營銷頁面上,而是回頭去閱讀密碼學團隊自己的技術文章。 PLONK的實際數據纔是讓合規論證成立的關鍵,而不僅僅是“隱私”這一角度。無論電路多大,驗證時間都大約保持在6-9毫秒;而證明時間則會隨着電路複雜度線性增長(例如在普通硬件上,2^16門規模的電路大約需要5.46秒)。這種不對稱性對受監管的金融場景尤爲重要,只是很多人沒有意識到:審計師或交易對手在覈驗證明時不會每次都消耗“有意義”的計算資源,即便底層交易邏輯變得更復雜。 我沒想到要發現的是:PLONK本身就披露過一個真實漏洞,而不僅僅是理論風險。Dusk的研究團隊發現了一個關鍵問題,出在Fiat-Shamir變換的實現方式上——這部分工作通過對挑戰進行哈希來把交互式證明改造成非交互式證明,而不是由在線驗證者向其發送挑戰。最初的實現沒有足夠早地對公共輸入進行哈希處理,從而削弱了可靠性(soundness)的保證。Trail of Bits 協調了披露工作,Dusk在主網上線前完成修補,並且選擇公開發布修復,而不是把它藏着不發。 正是這個細節讓我一直念念不忘——一個面向合規的鏈條,建立在密碼學證明系統之上,但該系統在生產臨近代碼裏確實存在可靠性缺陷,並在真正產生影響之前就被發現並修復。我不知道在這件事公開之後,其他在別處使用PLONK的實現還有多少仍處於脆弱狀態,也不知道從披露到其他項目給各自分叉補丁到位,中間究竟有多久的時間差。
#dusk $DUSK @Dusk
在本地運行證明生成以基準測試電路性能時,我發現了一些東西,讓我沒有繼續停留在營銷頁面上,而是回頭去閱讀密碼學團隊自己的技術文章。
PLONK的實際數據纔是讓合規論證成立的關鍵,而不僅僅是“隱私”這一角度。無論電路多大,驗證時間都大約保持在6-9毫秒;而證明時間則會隨着電路複雜度線性增長(例如在普通硬件上,2^16門規模的電路大約需要5.46秒)。這種不對稱性對受監管的金融場景尤爲重要,只是很多人沒有意識到:審計師或交易對手在覈驗證明時不會每次都消耗“有意義”的計算資源,即便底層交易邏輯變得更復雜。
我沒想到要發現的是:PLONK本身就披露過一個真實漏洞,而不僅僅是理論風險。Dusk的研究團隊發現了一個關鍵問題,出在Fiat-Shamir變換的實現方式上——這部分工作通過對挑戰進行哈希來把交互式證明改造成非交互式證明,而不是由在線驗證者向其發送挑戰。最初的實現沒有足夠早地對公共輸入進行哈希處理,從而削弱了可靠性(soundness)的保證。Trail of Bits 協調了披露工作,Dusk在主網上線前完成修補,並且選擇公開發布修復,而不是把它藏着不發。
正是這個細節讓我一直念念不忘——一個面向合規的鏈條,建立在密碼學證明系統之上,但該系統在生產臨近代碼裏確實存在可靠性缺陷,並在真正產生影響之前就被發現並修復。我不知道在這件事公開之後,其他在別處使用PLONK的實現還有多少仍處於脆弱狀態,也不知道從披露到其他項目給各自分叉補丁到位,中間究竟有多久的時間差。
#dusk $DUSK 區塊鏈能否真正做到私密,同時仍讓監管機構能看到他們依法需要看到的內容? 沒想到答案會取決於用另一個密鑰去加密一個密鑰。大多數隱私幣通過徹底移除可見性來解決隱私問題——沒人看得到任何東西,從來都看不到。@Dusk_Foundation 則建立在不同的假設之上:隱私應該是“有選擇的”,而不是“絕對的”。 用戶的交易載荷會先用用戶密鑰加密,而該密鑰本身再用單獨的審計員密鑰加密,因此只有獲得授權的審計員才能解密。鏈本身對公衆保持遮蔽,但零知識證明讓用戶證明審計員密鑰確實被正確使用,且載荷遵循規則,同時不把內容暴露給任何其他人。這在結構上不同於匿名:在定義的條件下,某些人是可以看見的——儘管公開鏈從不顯示。 這種設計同樣延伸到身份層。Citadel(Dusk 的身份層)讓某人只需完成一次 KYC,然後就能通過零知識證明來證明其符合資格,而無需每次都重新暴露個人數據。它也彌補了早期隱私 ID 系統的一個空白:即使是“抗泄漏”的證明,只要仍然附着在可公開追蹤的鏈上數值上,就依然會留下可被關聯的痕跡。 這裏有個我一直沒看到被化解的矛盾:選擇性披露只有在審計員密鑰從未被泄露或被濫用時才成立。隱私幣沒有這樣的密鑰——它的保證是:沒有人能看見,完全如此。Dusk 爲了可監管、可用性,用“絕對保證”換取了“監管可用性”,這正是機構所要的重點,但它的隱私最終也部分取決於審計員訪問權限被治理得有多嚴,而不僅僅是數學本身。 如果 Dusk 的隱私部分取決於誰持有審計員密鑰,那麼“以合規爲先的隱私”有多少來自密碼學,又有多少來自機構信任、穿着零知識證明的外衣?
#dusk $DUSK 區塊鏈能否真正做到私密,同時仍讓監管機構能看到他們依法需要看到的內容?
沒想到答案會取決於用另一個密鑰去加密一個密鑰。大多數隱私幣通過徹底移除可見性來解決隱私問題——沒人看得到任何東西,從來都看不到。@Dusk 則建立在不同的假設之上:隱私應該是“有選擇的”,而不是“絕對的”。
用戶的交易載荷會先用用戶密鑰加密,而該密鑰本身再用單獨的審計員密鑰加密,因此只有獲得授權的審計員才能解密。鏈本身對公衆保持遮蔽,但零知識證明讓用戶證明審計員密鑰確實被正確使用,且載荷遵循規則,同時不把內容暴露給任何其他人。這在結構上不同於匿名:在定義的條件下,某些人是可以看見的——儘管公開鏈從不顯示。
這種設計同樣延伸到身份層。Citadel(Dusk 的身份層)讓某人只需完成一次 KYC,然後就能通過零知識證明來證明其符合資格,而無需每次都重新暴露個人數據。它也彌補了早期隱私 ID 系統的一個空白:即使是“抗泄漏”的證明,只要仍然附着在可公開追蹤的鏈上數值上,就依然會留下可被關聯的痕跡。
這裏有個我一直沒看到被化解的矛盾:選擇性披露只有在審計員密鑰從未被泄露或被濫用時才成立。隱私幣沒有這樣的密鑰——它的保證是:沒有人能看見,完全如此。Dusk 爲了可監管、可用性,用“絕對保證”換取了“監管可用性”,這正是機構所要的重點,但它的隱私最終也部分取決於審計員訪問權限被治理得有多嚴,而不僅僅是數學本身。
如果 Dusk 的隱私部分取決於誰持有審計員密鑰,那麼“以合規爲先的隱私”有多少來自密碼學,又有多少來自機構信任、穿着零知識證明的外衣?
#dusk $DUSK @Dusk_Foundation 你在沒有任何黑客參與的情況下,把自己的代幣在不同鏈之間遷移,真的會花錢嗎? 我在寫這篇之前,花了一個晚上去閱讀 Dusk 的遷移合約代碼,因爲“原生 vs. 包裝”通常會被解釋成只是外觀上的差異。但並不是。 我注意到的關鍵細節如下:原生的 DUSK 使用 9 位小數,而 ERC20/BEP20 版本的 DUSK 使用 18 位。遷移合約會基於一個固定因子進行換算;如果你遷移的數量不是 1 LUX 的整倍數,合約會在不提示的情況下直接向下取整。遷移一個低於該閾值的“塵埃”數量,多出來的部分不會作爲原生 DUSK 返回給你——它就這麼消失了,按設計如此,並非漏洞。 另外,值得單獨點名的是信任模型本身。主網上的原生 DUSK 纔是跨鏈時的真正依據:當你把原生 DUSK 從主網橋接到 BEP20 時,協議會先鎖定你的主網代幣,然後纔在 BSC 上觸發鑄造。這個包裝後的 BEP20 代幣之所以存在,僅僅是因爲那次鎖定;它並沒有被獨立地支撐。即便你在錢包裏看到的都是相同餘額,但其風險畫像與直接持有原生 DUSK 截然不同。 還有一部分根本不是設計上的取捨,而是運行層面的風險。將原生 DUSK 橋接到 BEP20,需要在備忘錄(memo)字段中填寫目標 BSC 地址。你如果遺漏,或填錯了,文檔說得很直白:橋接會忽略這筆交易,資金就會丟失。不會觸發智能合約回滾,也沒有自動退款。另一側從未有地方可去,於是就沒了。 我認爲大多數持有人在把資金從交易所或錢包之間轉移時,並不會先檢查自己到底持有的是哪個版本;他們只會看到“DUSK”,然後就理所當然地以爲它們是可以互換的。 既然原生 DUSK 纔是唯一的真正依據,而包裝版本只是基於“鎖定-鑄造證明”的產物,那麼生態系統爲什麼還要把這種“只因一個 memo 字段缺失就可能丟錢”的流程做得這麼容易?
#dusk $DUSK @Dusk 你在沒有任何黑客參與的情況下,把自己的代幣在不同鏈之間遷移,真的會花錢嗎?

我在寫這篇之前,花了一個晚上去閱讀 Dusk 的遷移合約代碼,因爲“原生 vs. 包裝”通常會被解釋成只是外觀上的差異。但並不是。
我注意到的關鍵細節如下:原生的 DUSK 使用 9 位小數,而 ERC20/BEP20 版本的 DUSK 使用 18 位。遷移合約會基於一個固定因子進行換算;如果你遷移的數量不是 1 LUX 的整倍數,合約會在不提示的情況下直接向下取整。遷移一個低於該閾值的“塵埃”數量,多出來的部分不會作爲原生 DUSK 返回給你——它就這麼消失了,按設計如此,並非漏洞。
另外,值得單獨點名的是信任模型本身。主網上的原生 DUSK 纔是跨鏈時的真正依據:當你把原生 DUSK 從主網橋接到 BEP20 時,協議會先鎖定你的主網代幣,然後纔在 BSC 上觸發鑄造。這個包裝後的 BEP20 代幣之所以存在,僅僅是因爲那次鎖定;它並沒有被獨立地支撐。即便你在錢包裏看到的都是相同餘額,但其風險畫像與直接持有原生 DUSK 截然不同。
還有一部分根本不是設計上的取捨,而是運行層面的風險。將原生 DUSK 橋接到 BEP20,需要在備忘錄(memo)字段中填寫目標 BSC 地址。你如果遺漏,或填錯了,文檔說得很直白:橋接會忽略這筆交易,資金就會丟失。不會觸發智能合約回滾,也沒有自動退款。另一側從未有地方可去,於是就沒了。
我認爲大多數持有人在把資金從交易所或錢包之間轉移時,並不會先檢查自己到底持有的是哪個版本;他們只會看到“DUSK”,然後就理所當然地以爲它們是可以互換的。

既然原生 DUSK 纔是唯一的真正依據,而包裝版本只是基於“鎖定-鑄造證明”的產物,那麼生態系統爲什麼還要把這種“只因一個 memo 字段缺失就可能丟錢”的流程做得這麼容易?
#dusk $DUSK @Dusk_Foundation 當一座橋在兩個不同的執行層之間轉移你的資產時,“無信任(trustless)”到底是什麼意思? 在讀了 Dusk 如何把 DuskDS 連接到 DuskEVM 之後,我一直回到這個問題,因爲“無信任橋”幾乎到處都被當作營銷話術使用,而且很少經得起仔細的推敲。 下面是實際發生的事情:DuskDS 是結算與共識層——終局性、安全性和數據可用性都在這裏。DuskEVM 則在其上運行,作爲承載 Solidity 合約的獨立執行環境。把資產在它們之間移動,並不等同於在同一條鏈的自身狀態內部移動——這意味着必須由一層向另一層證明某個狀態變化確實真實發生了,而不是讓任何一方僅僅憑藉“對方說了算”就直接接受。 真正關鍵在於“原生(native)”這一點。這裏並不是依賴外部驗證者集合或多籤託管方來持有被包裝的資產——那種經典橋接設計正是導致本行業大多數跨鏈漏洞的原因——而是把橋直接構建在協議自身的結算保證之中。DuskDS 的終局性(“Final”狀態,經過密碼學保證且不可逆)就是橋所依賴的基礎,用來確認:在另一側識別該轉賬確實是安全的。 這與由一組獨立簽名者來保障的橋,其信任模型有着實質性的不同。但這也意味着:橋的安全性只有在 DuskDS 自身的共識假設足夠強時才同樣足夠強——如果曾經出現某種情況,導致委員會式終局被質疑或被延遲,那麼橋也會繼承這種不確定性,而不是承擔一份獨立的額外風險。 還沒找到明確的答案:DuskDS 達到“Final”之後,到資產在 DuskEVM 上變得可用之間實際存在怎樣的延遲?這個時間差會不會製造一個窗口,讓理性的行爲者通過時序來進行利用,而不是去破壞密碼學本身? 橋是否僅僅和它下方的結算層一樣“無信任”,還是說 DuskEVM 還會在其基礎之上額外引入一份獨立風險?
#dusk $DUSK @Dusk
當一座橋在兩個不同的執行層之間轉移你的資產時,“無信任(trustless)”到底是什麼意思?
在讀了 Dusk 如何把 DuskDS 連接到 DuskEVM 之後,我一直回到這個問題,因爲“無信任橋”幾乎到處都被當作營銷話術使用,而且很少經得起仔細的推敲。
下面是實際發生的事情:DuskDS 是結算與共識層——終局性、安全性和數據可用性都在這裏。DuskEVM 則在其上運行,作爲承載 Solidity 合約的獨立執行環境。把資產在它們之間移動,並不等同於在同一條鏈的自身狀態內部移動——這意味着必須由一層向另一層證明某個狀態變化確實真實發生了,而不是讓任何一方僅僅憑藉“對方說了算”就直接接受。
真正關鍵在於“原生(native)”這一點。這裏並不是依賴外部驗證者集合或多籤託管方來持有被包裝的資產——那種經典橋接設計正是導致本行業大多數跨鏈漏洞的原因——而是把橋直接構建在協議自身的結算保證之中。DuskDS 的終局性(“Final”狀態,經過密碼學保證且不可逆)就是橋所依賴的基礎,用來確認:在另一側識別該轉賬確實是安全的。
這與由一組獨立簽名者來保障的橋,其信任模型有着實質性的不同。但這也意味着:橋的安全性只有在 DuskDS 自身的共識假設足夠強時才同樣足夠強——如果曾經出現某種情況,導致委員會式終局被質疑或被延遲,那麼橋也會繼承這種不確定性,而不是承擔一份獨立的額外風險。
還沒找到明確的答案:DuskDS 達到“Final”之後,到資產在 DuskEVM 上變得可用之間實際存在怎樣的延遲?這個時間差會不會製造一個窗口,讓理性的行爲者通過時序來進行利用,而不是去破壞密碼學本身?
橋是否僅僅和它下方的結算層一樣“無信任”,還是說 DuskEVM 還會在其基礎之上額外引入一份獨立風險?
#baby @babylonlabs_io 如果某個驗證者變得惡意,那麼所有委託給他的人的資金都會一起受到懲罰,還是隻會懲罰他實際針對的人? 沒想到答案會涉及加密技巧,而不是那種“是的,所有人都失去自己的質押”的簡單情況。我天真地以爲削減(slashing)的機制就像大多數 PoS 鏈那樣:一個壞驗證者,一羣委託給他的人的集體懲罰。 Babylon 的做法不一樣,它使用了適配器簽名(adaptor signatures)。當一個質押者進行委託時,質押者和契約委員會(covenant committee)會事先共同批准這項安排,但真正用於後續觸發削減的唯一需要的,是被委託驗證者自己的簽名。爲了防止一個流氓驗證者在沒有授權的情況下,單方面削減無辜質押者的資金,質押者會使用該驗證者自己的 EOTS 公鑰來加密他們的預先批准。這意味着:如果驗證者曾經試圖惡意地針對這個特定質押者,那麼要解密簽名來實施攻擊,就會導致驗證者自己的私鑰泄露——而這又會讓該驗證者全部“自我委託”的質押,以及所有其他與他綁定的委託者的質押,都變得可以一起被削減。 換句話說,去攻擊一個人會觸發驗證者自身在所有與之綁定的人身上的暴露。這不是靠“策略隔離”,而是通過讓攻擊對攻擊者本身具有自毀性來實現隔離。 我還沒找到令人滿意的答案是:這種設計是否會產生一種扭曲激勵——一旦驗證者被攻破,就不再有什麼可失去的,於是它乾脆一次性最大化對所有委託者的損害,而不是隻針對一個人? 如果對一個人的削減會自動級聯到該驗證者名下的所有人,那麼“隔離式削減(isolated slashing)”這種說法在現實中到底能站得住嗎? #baby $BABY
#baby @BabylonLabs_io 如果某個驗證者變得惡意,那麼所有委託給他的人的資金都會一起受到懲罰,還是隻會懲罰他實際針對的人?
沒想到答案會涉及加密技巧,而不是那種“是的,所有人都失去自己的質押”的簡單情況。我天真地以爲削減(slashing)的機制就像大多數 PoS 鏈那樣:一個壞驗證者,一羣委託給他的人的集體懲罰。
Babylon 的做法不一樣,它使用了適配器簽名(adaptor signatures)。當一個質押者進行委託時,質押者和契約委員會(covenant committee)會事先共同批准這項安排,但真正用於後續觸發削減的唯一需要的,是被委託驗證者自己的簽名。爲了防止一個流氓驗證者在沒有授權的情況下,單方面削減無辜質押者的資金,質押者會使用該驗證者自己的 EOTS 公鑰來加密他們的預先批准。這意味着:如果驗證者曾經試圖惡意地針對這個特定質押者,那麼要解密簽名來實施攻擊,就會導致驗證者自己的私鑰泄露——而這又會讓該驗證者全部“自我委託”的質押,以及所有其他與他綁定的委託者的質押,都變得可以一起被削減。
換句話說,去攻擊一個人會觸發驗證者自身在所有與之綁定的人身上的暴露。這不是靠“策略隔離”,而是通過讓攻擊對攻擊者本身具有自毀性來實現隔離。
我還沒找到令人滿意的答案是:這種設計是否會產生一種扭曲激勵——一旦驗證者被攻破,就不再有什麼可失去的,於是它乾脆一次性最大化對所有委託者的損害,而不是隻針對一個人?
如果對一個人的削減會自動級聯到該驗證者名下的所有人,那麼“隔離式削減(isolated slashing)”這種說法在現實中到底能站得住嗎?
#baby $BABY
#baby $BABY 當比特幣本身沒有內置懲罰(slashing)邏輯時,你如何在比特幣上懲罰一個驗證者? 要真正理解這個問題,我花的時間比預期更久,因爲答案並不是一個智能合約,而是一種簽名方案:用巧妙的數學而不是代碼來實現。 @babylonlabs_io 使用的是所謂的可提取一次性簽名(Extractable One-Time Signature, EOTS),建立在比特幣原生的 Schnorr 簽名之上。核心訣竅是:終局性提供者會爲他們爲每個區塊高度投票時生成一對唯一的密鑰。只要他們在同一個高度上只簽署一個區塊,簽名就會完全安全,不會泄露任何東西。但如果他們在同一高度上對兩個互相沖突的區塊都簽了名,數學就會崩壞。因爲當 Schnorr 簽名在重複使用 nonce(一次性隨機數)時的數學關係被觸發,複用該“每高度密鑰”去簽署兩條不同的消息會直接暴露他們的私鑰。 終局輪本身要求:要讓一個區塊真正完成終局,必須獲得來自已質押 BTC 權重中超過三分之二的簽名;因此,按照定義,任何安全違規都意味着存在超過三分之一的質押發生了雙籤。這也是爲什麼“完全可懲罰(fully slashable)”的保證是通過數學強制實現的,而不是僅僅靠政策承諾:一旦密鑰泄露,任何人——不僅僅是 Babylon,也不僅僅是驗證者——都可以構造並廣播懲罰交易。該階段不需要委員會投票,也沒有上訴流程,只有被暴露出來的數學關係。 我還沒看到明確回答的是:爲每個區塊高度生成密鑰,會不會給同時運行多個 BSN 的終局性提供者帶來有意義的運維開銷?而這種開銷本身會不會成爲攻擊面——例如,如果某個提供者在高負載下由於失誤而重複使用隨機數(而不是出於惡意)? EOTS 的安全性是純粹的數學保證,還是它在不聲不響地依賴終局性提供者具備穩健的密鑰管理基礎設施? $BABY
#baby $BABY 當比特幣本身沒有內置懲罰(slashing)邏輯時,你如何在比特幣上懲罰一個驗證者?
要真正理解這個問題,我花的時間比預期更久,因爲答案並不是一個智能合約,而是一種簽名方案:用巧妙的數學而不是代碼來實現。
@BabylonLabs_io 使用的是所謂的可提取一次性簽名(Extractable One-Time Signature, EOTS),建立在比特幣原生的 Schnorr 簽名之上。核心訣竅是:終局性提供者會爲他們爲每個區塊高度投票時生成一對唯一的密鑰。只要他們在同一個高度上只簽署一個區塊,簽名就會完全安全,不會泄露任何東西。但如果他們在同一高度上對兩個互相沖突的區塊都簽了名,數學就會崩壞。因爲當 Schnorr 簽名在重複使用 nonce(一次性隨機數)時的數學關係被觸發,複用該“每高度密鑰”去簽署兩條不同的消息會直接暴露他們的私鑰。
終局輪本身要求:要讓一個區塊真正完成終局,必須獲得來自已質押 BTC 權重中超過三分之二的簽名;因此,按照定義,任何安全違規都意味着存在超過三分之一的質押發生了雙籤。這也是爲什麼“完全可懲罰(fully slashable)”的保證是通過數學強制實現的,而不是僅僅靠政策承諾:一旦密鑰泄露,任何人——不僅僅是 Babylon,也不僅僅是驗證者——都可以構造並廣播懲罰交易。該階段不需要委員會投票,也沒有上訴流程,只有被暴露出來的數學關係。
我還沒看到明確回答的是:爲每個區塊高度生成密鑰,會不會給同時運行多個 BSN 的終局性提供者帶來有意義的運維開銷?而這種開銷本身會不會成爲攻擊面——例如,如果某個提供者在高負載下由於失誤而重複使用隨機數(而不是出於惡意)?
EOTS 的安全性是純粹的數學保證,還是它在不聲不響地依賴終局性提供者具備穩健的密鑰管理基礎設施?
$BABY
#baby $BABY 我曾經把比特幣的閒置供應視爲一個固定的限制——一種資產,只有在“靜置不動”時纔會比拿去投入使用更有價值。後來我去看了一下“閒置”到底加起來有多少。 目前,流通中的比特幣中有超過99%完全沒有被質押。 這絕不是一個小小的誤差——這是整個加密市場裏最大的休眠資金池,約一萬億美元的經濟體量只是待在錢包裏什麼都不做。 這件事讓我重新理解了:其他主要鏈的安全性都是從零開始構建的,要去競爭那些必須被創造、激勵並在數年中從零增長起來的質押資本。比特幣不面臨這個問題。資金早就已經存在。它已經是這個領域裏最值得信賴的價值儲存。唯一缺少的是某種機制,能夠在不破壞它之所以值得信賴的託管保證的前提下,把這些資金投入到工作中。 這就是賭注 @babylonlabs_io 正在下注的——並不是說比特幣需要一個新的用例,而是這個用例從一開始就在那裏,只是整個時間都沒有被使用;阻礙它的並不是需求不足,而是一個技術層面的缺口。 我不認爲這會在一夜之間發生。真正的採用取決於:足夠多的 BSNs 上線、足夠多的終局性提供方證明其可靠性、以及足夠多的委託人真正去做我在這次競選活動中一直寫到的那種盡職調查。機制已經上線了。但它能否擴展到那一萬億美元中的一個有意義的比例,仍然是一個開放問題,而不是一個必然結果。 我在進入下一階段時關注的並不是已宣佈的 BSNs 總數——而是那份閒置的99%裏,究竟有多少開始真正流動。 $1000RATS $IDOL @babylonlabs_io #1000sats #HedgeFundsAddBullishOilBets #OpenAIFindsMoreAgentsEscapedContainment #AmazonRaises2026CapexTo$220B 有多少閒置比特幣會流向 Babylon?
#baby $BABY 我曾經把比特幣的閒置供應視爲一個固定的限制——一種資產,只有在“靜置不動”時纔會比拿去投入使用更有價值。後來我去看了一下“閒置”到底加起來有多少。

目前,流通中的比特幣中有超過99%完全沒有被質押。 這絕不是一個小小的誤差——這是整個加密市場裏最大的休眠資金池,約一萬億美元的經濟體量只是待在錢包裏什麼都不做。

這件事讓我重新理解了:其他主要鏈的安全性都是從零開始構建的,要去競爭那些必須被創造、激勵並在數年中從零增長起來的質押資本。比特幣不面臨這個問題。資金早就已經存在。它已經是這個領域裏最值得信賴的價值儲存。唯一缺少的是某種機制,能夠在不破壞它之所以值得信賴的託管保證的前提下,把這些資金投入到工作中。

這就是賭注 @BabylonLabs_io 正在下注的——並不是說比特幣需要一個新的用例,而是這個用例從一開始就在那裏,只是整個時間都沒有被使用;阻礙它的並不是需求不足,而是一個技術層面的缺口。

我不認爲這會在一夜之間發生。真正的採用取決於:足夠多的 BSNs 上線、足夠多的終局性提供方證明其可靠性、以及足夠多的委託人真正去做我在這次競選活動中一直寫到的那種盡職調查。機制已經上線了。但它能否擴展到那一萬億美元中的一個有意義的比例,仍然是一個開放問題,而不是一個必然結果。

我在進入下一階段時關注的並不是已宣佈的 BSNs 總數——而是那份閒置的99%裏,究竟有多少開始真正流動。
$1000RATS $IDOL
@BabylonLabs_io #1000sats

#HedgeFundsAddBullishOilBets #OpenAIFindsMoreAgentsEscapedContainment #AmazonRaises2026CapexTo$220B

有多少閒置比特幣會流向 Babylon?
🟢 < 5%
100%
🚀 5% - 15%
0%
🔥 15%+
0%
1 票 • 投票已結束
#baby $BABY @babylonlabs_io 我過去一直以爲,“質押(staking)”自動就意味着把你的幣交給別人,直到你提現的時候纔拿回來。後來我纔去看,當我的 BTC 一進入 Babylon 的質押交易時,實際會發生什麼。 它從未離開我的控制。 BTC 會直接通過原生的比特幣腳本被鎖定:沒有託管方持有密鑰,沒有用包裝代幣來替代真正的資產,也沒有可能被利用的橋合約。這個鎖定存在於比特幣自己的鏈上,受比特幣自身規則強制執行——也就是那些已經保障我迄今所有交易的規則。 真正發生的是,一個內置了兩種花費路徑的 Taproot 腳本。一種路徑允許我在時間鎖(timelock)結束後贖回我的 BTC。另一種路徑只有在我所委託的驗證者違反協議時纔會觸發——這就是“削減/罰沒(slashing)”路徑,也是我的資金會偏離我原本設定路徑、從而流向我未預期用途的唯一情形。 我並不認爲這意味着零風險。仍然有一個“契約委員會(covenant committee)”參與,以強制執行某些條件;而將資金委託給不良的最終性提供方(finality provider)仍然會帶來後果。但“把密鑰交給某一家公司去信任”與“信任一個由比特幣腳本強制執行、且可定義、可審計的機制”之間,確實存在差別。託管式質押要求你相信一個承諾;而這套機制則要求你去核驗代碼。 對任何一直持有 BTC、尤其是因爲不想依賴他人這一點的人來說,真正關鍵的並不是收益數字,而是:賺取這部分收益的過程,是否在悄悄地重新引入了比特幣被設計來移除的那種依賴。
#baby $BABY @BabylonLabs_io

我過去一直以爲,“質押(staking)”自動就意味着把你的幣交給別人,直到你提現的時候纔拿回來。後來我纔去看,當我的 BTC 一進入 Babylon 的質押交易時,實際會發生什麼。

它從未離開我的控制。

BTC 會直接通過原生的比特幣腳本被鎖定:沒有託管方持有密鑰,沒有用包裝代幣來替代真正的資產,也沒有可能被利用的橋合約。這個鎖定存在於比特幣自己的鏈上,受比特幣自身規則強制執行——也就是那些已經保障我迄今所有交易的規則。

真正發生的是,一個內置了兩種花費路徑的 Taproot 腳本。一種路徑允許我在時間鎖(timelock)結束後贖回我的 BTC。另一種路徑只有在我所委託的驗證者違反協議時纔會觸發——這就是“削減/罰沒(slashing)”路徑,也是我的資金會偏離我原本設定路徑、從而流向我未預期用途的唯一情形。

我並不認爲這意味着零風險。仍然有一個“契約委員會(covenant committee)”參與,以強制執行某些條件;而將資金委託給不良的最終性提供方(finality provider)仍然會帶來後果。但“把密鑰交給某一家公司去信任”與“信任一個由比特幣腳本強制執行、且可定義、可審計的機制”之間,確實存在差別。託管式質押要求你相信一個承諾;而這套機制則要求你去核驗代碼。

對任何一直持有 BTC、尤其是因爲不想依賴他人這一點的人來說,真正關鍵的並不是收益數字,而是:賺取這部分收益的過程,是否在悄悄地重新引入了比特幣被設計來移除的那種依賴。
@babylonlabs_io 我在對比巴比倫的最終性提供者(Finality Provider)模型和普通的 PoS 委託時,發現一件很突出的問題:激勵結構並不像人們想象的那樣是對稱的。 在大多數被委託的 PoS 系統裏,如果你的驗證者(validator)行爲不當,你的代幣也會因爲驗證者被懲罰而一起被削減(slashed),也就是你會與他們一同承擔處罰。其核心目的就是:迫使委託人真正去審查他們所委託的對象。 而巴比倫的設置把這個核心理念用於比特幣:你所選擇的最終性提供者會決定你的 BTC 暴露在多大程度的被削減風險之下,儘管你從未把幣的託管權限交出去。 這爲什麼重要:自我託管(self-custody)通常被宣傳爲“安全”,一句話帶過。但自我託管並不會消除你對他人不當行爲的暴露,它只是特意移除了託管(custodial)的特定風險。你可以完全掌控你的 BTC,卻仍然可能因爲你在委託時不夠謹慎而在被削減中失去它。這與“我的交易所被黑了”屬於意義上不同的風險,但它並非零風險。我認爲,關於比特幣質押的傳播有時會把這條界線講得有點模糊。 值得點名的權衡:這會把真正的盡職調查壓力推給質押者。選擇最終性提供者不只是“看起來更好”的選擇,而是一種主動的風險決策:正常運行時間(uptime)、簽名行爲(signing behavior)、運營安全性(operational security)都會通過這種方式變成你的責任。許多第一次質押 BTC 的持有者並不習慣用這種方式去思考,因爲 BTC 本身訓練了人們更多關注託管風險,而忽略其他方面。 所以,從紙面上看,這套激勵設計是合理的——理論上它應當能形成一種市場:可靠的最終性提供者獲得信任,不可靠的會因爲得不到委託而被“餓死”。但這個市場是否真的會形成,取決於質押者是否會像設計所假設的那樣去做盡職調查。#baby $BABY
@BabylonLabs_io 我在對比巴比倫的最終性提供者(Finality Provider)模型和普通的 PoS 委託時,發現一件很突出的問題:激勵結構並不像人們想象的那樣是對稱的。
在大多數被委託的 PoS 系統裏,如果你的驗證者(validator)行爲不當,你的代幣也會因爲驗證者被懲罰而一起被削減(slashed),也就是你會與他們一同承擔處罰。其核心目的就是:迫使委託人真正去審查他們所委託的對象。
而巴比倫的設置把這個核心理念用於比特幣:你所選擇的最終性提供者會決定你的 BTC 暴露在多大程度的被削減風險之下,儘管你從未把幣的託管權限交出去。
這爲什麼重要:自我託管(self-custody)通常被宣傳爲“安全”,一句話帶過。但自我託管並不會消除你對他人不當行爲的暴露,它只是特意移除了託管(custodial)的特定風險。你可以完全掌控你的 BTC,卻仍然可能因爲你在委託時不夠謹慎而在被削減中失去它。這與“我的交易所被黑了”屬於意義上不同的風險,但它並非零風險。我認爲,關於比特幣質押的傳播有時會把這條界線講得有點模糊。
值得點名的權衡:這會把真正的盡職調查壓力推給質押者。選擇最終性提供者不只是“看起來更好”的選擇,而是一種主動的風險決策:正常運行時間(uptime)、簽名行爲(signing behavior)、運營安全性(operational security)都會通過這種方式變成你的責任。許多第一次質押 BTC 的持有者並不習慣用這種方式去思考,因爲 BTC 本身訓練了人們更多關注託管風險,而忽略其他方面。
所以,從紙面上看,這套激勵設計是合理的——理論上它應當能形成一種市場:可靠的最終性提供者獲得信任,不可靠的會因爲得不到委託而被“餓死”。但這個市場是否真的會形成,取決於質押者是否會像設計所假設的那樣去做盡職調查。#baby $BABY
·
--
看漲
今天花了時間在 @babylonlabs_io 的 docs 上試圖理解最終性提供者(Finality Providers)到底做什麼。這個角色看起來沒有第一眼那麼顯而易見。 在一個普通的 PoS 鏈中,驗證者會將鏈的原生代幣質押,以獲得投票權(voting power)。而最終性提供者做的事情不一樣。他們從質押者(stakers)那裏接收 BTC 委託(delegations),並把這筆被委託的比特幣作爲其在區塊最終性(block finality)投票背後的經濟權重。 質押者從未轉移自己的 BTC。沒有任何私鑰發生移動。BTC 會被鎖定在比特幣上的自託管腳本(self-custodial script)中。被委託的只是由 BTC 所代表的投票權(voting power)。最終性提供者(Finality Provider)進行投票。比特幣在經濟上支撐着這次投票,但它從未離開質押者的控制範圍。 讓我改變思路的是:這對依賴這種安全性的 PoS 網絡意味着什麼。它們的安全性不再只取決於自身原生代幣的價值多少。它取決於比特幣的經濟權重,背後支撐着每一次最終性投票。這相較於今天大多數 PoS 鏈所能獲得的安全基礎,是根本不同的安全底座。 斜倉/懲罰(slashing)這一面也把全貌補齊。如果某個最終性提供者雙重簽名(double signs),EOTS 會暴露他們的私鑰(private key),並且懲罰條件會自動執行。委託給他們的投票權附帶了真實的後果。 我一直在思考的是質押者在這一切中的位置。你會把權力委託給一個最終性提供者,而你無法直接控制它的行爲。密碼學保護了你的本金(principal)。但你選擇的提供者仍然會影響被其所保障的網絡健康。 如果投票權被委託了,但 BTC 從未移動,那麼質押者在選擇將權力委託給誰時,真正的問責(accountability)會是什麼樣子? #baby $BABY
今天花了時間在 @BabylonLabs_io 的 docs 上試圖理解最終性提供者(Finality Providers)到底做什麼。這個角色看起來沒有第一眼那麼顯而易見。

在一個普通的 PoS 鏈中,驗證者會將鏈的原生代幣質押,以獲得投票權(voting power)。而最終性提供者做的事情不一樣。他們從質押者(stakers)那裏接收 BTC 委託(delegations),並把這筆被委託的比特幣作爲其在區塊最終性(block finality)投票背後的經濟權重。

質押者從未轉移自己的 BTC。沒有任何私鑰發生移動。BTC 會被鎖定在比特幣上的自託管腳本(self-custodial script)中。被委託的只是由 BTC 所代表的投票權(voting power)。最終性提供者(Finality Provider)進行投票。比特幣在經濟上支撐着這次投票,但它從未離開質押者的控制範圍。

讓我改變思路的是:這對依賴這種安全性的 PoS 網絡意味着什麼。它們的安全性不再只取決於自身原生代幣的價值多少。它取決於比特幣的經濟權重,背後支撐着每一次最終性投票。這相較於今天大多數 PoS 鏈所能獲得的安全基礎,是根本不同的安全底座。

斜倉/懲罰(slashing)這一面也把全貌補齊。如果某個最終性提供者雙重簽名(double signs),EOTS 會暴露他們的私鑰(private key),並且懲罰條件會自動執行。委託給他們的投票權附帶了真實的後果。

我一直在思考的是質押者在這一切中的位置。你會把權力委託給一個最終性提供者,而你無法直接控制它的行爲。密碼學保護了你的本金(principal)。但你選擇的提供者仍然會影響被其所保障的網絡健康。

如果投票權被委託了,但 BTC 從未移動,那麼質押者在選擇將權力委託給誰時,真正的問責(accountability)會是什麼樣子?

#baby $BABY
#baby $BABY / @babylonlabs_io 今天讀巴比倫(Babylon)的文檔時,我反覆停在同一個問題上。 比特幣沒有智能合約。那一個協議又如何對從未離開比特幣鏈的 BTC 強制執行削減(slashing)? 契約委員會(Covenant Committee)是答案,但方式並不像我起初以爲的那樣。 每一筆質押交易在生效前都會經過委員會審查。他們會覈對解除質押(unbonding)和削減(slashing)條件是否符合巴比倫的規則。如果他們達到法定人數(quorum),他們會當場對解除質押和削減交易進行預先簽名(pre-sign)。在質押期開始之前,他們的簽名就已經就位了。 這個“預先簽名”的細節改變了我對整個模型的理解。委員會並不是在監視不當行爲並對其作出反應。他們會在一開始就把所有內容都簽好。之後,要執行削減所缺少的唯一一枚簽名,就是最終性提供者(Finality Provider)自己的。而這枚簽名只有在提供者雙重簽名(double signs)時纔會變得可用——這正是 EOTS(事件觀察與閾值系統)旨在暴露的內容。 讓我印象最深的是爲質押者(stakers)內置的保護。委員會無法竊取你的質押資金。他們也無法造成錯誤的削減。削減條件中需要你自己的 EOTS 密鑰,而只有你持有它。即便委員會完全被攻破,他們也無法違揹你的意願移動你的比特幣……
#baby $BABY / @BabylonLabs_io
今天讀巴比倫(Babylon)的文檔時,我反覆停在同一個問題上。

比特幣沒有智能合約。那一個協議又如何對從未離開比特幣鏈的 BTC 強制執行削減(slashing)?

契約委員會(Covenant Committee)是答案,但方式並不像我起初以爲的那樣。

每一筆質押交易在生效前都會經過委員會審查。他們會覈對解除質押(unbonding)和削減(slashing)條件是否符合巴比倫的規則。如果他們達到法定人數(quorum),他們會當場對解除質押和削減交易進行預先簽名(pre-sign)。在質押期開始之前,他們的簽名就已經就位了。

這個“預先簽名”的細節改變了我對整個模型的理解。委員會並不是在監視不當行爲並對其作出反應。他們會在一開始就把所有內容都簽好。之後,要執行削減所缺少的唯一一枚簽名,就是最終性提供者(Finality Provider)自己的。而這枚簽名只有在提供者雙重簽名(double signs)時纔會變得可用——這正是 EOTS(事件觀察與閾值系統)旨在暴露的內容。

讓我印象最深的是爲質押者(stakers)內置的保護。委員會無法竊取你的質押資金。他們也無法造成錯誤的削減。削減條件中需要你自己的 EOTS 密鑰,而只有你持有它。即便委員會完全被攻破,他們也無法違揹你的意願移動你的比特幣……
真實
我一直到處都在看到“無信任(trustless)比特幣質押”,就把它當作字面意思。然後我真的去讀了質押合約腳本的文檔。 裏面有一個“契約委員會(covenant committee)”。 一組參與方的比特幣公鑰被直接寫死在質押交易裏。他們的工作:對某些支出路徑進行共同簽名,這樣協議才能在不必每次都依賴鏈上共識的情況下,強制執行削減(slashing)和解綁(unbonding)。 沒有他們,這整個機制就跑不起來——解綁不會那麼快,削減也無法被強制執行。 所以這裏是沒人會寫在標題裏的真實取捨:Babylon 移除了託管方(custodian),但並沒有移除所有被信任的方。它把“信任”縮減成一個由明確委員會組成的體系,並且用加密約束來限定規則,而不是把信任交給某一家公司、再讓你面對一份你根本無法審計的賬本。 這確實是差別——有公開規則的多重簽名委員會,並不等同於那種可以凍結你賬戶的託管方。但這也不是“零信任(zero trust)”,把它當成那樣只會讓人後來更容易感到意外。 今天大多數人質押時都不會去檢查:委員會裏都有誰,或者說要達到多少簽名閾值才能移動資金。 我去查了。在你把 BTC 鎖進任何東西之前,值得做。 “無信任”並不是非黑即白。它是一條光譜,而 Babylon 只是把它往這條光譜的更遠處推了一點——在託管型橋接之外,但還沒有走到終點。 #baby $BABY @babylonlabs_io
我一直到處都在看到“無信任(trustless)比特幣質押”,就把它當作字面意思。然後我真的去讀了質押合約腳本的文檔。

裏面有一個“契約委員會(covenant committee)”。

一組參與方的比特幣公鑰被直接寫死在質押交易裏。他們的工作:對某些支出路徑進行共同簽名,這樣協議才能在不必每次都依賴鏈上共識的情況下,強制執行削減(slashing)和解綁(unbonding)。

沒有他們,這整個機制就跑不起來——解綁不會那麼快,削減也無法被強制執行。

所以這裏是沒人會寫在標題裏的真實取捨:Babylon 移除了託管方(custodian),但並沒有移除所有被信任的方。它把“信任”縮減成一個由明確委員會組成的體系,並且用加密約束來限定規則,而不是把信任交給某一家公司、再讓你面對一份你根本無法審計的賬本。

這確實是差別——有公開規則的多重簽名委員會,並不等同於那種可以凍結你賬戶的託管方。但這也不是“零信任(zero trust)”,把它當成那樣只會讓人後來更容易感到意外。

今天大多數人質押時都不會去檢查:委員會裏都有誰,或者說要達到多少簽名閾值才能移動資金。

我去查了。在你把 BTC 鎖進任何東西之前,值得做。

“無信任”並不是非黑即白。它是一條光譜,而 Babylon 只是把它往這條光譜的更遠處推了一點——在託管型橋接之外,但還沒有走到終點。

#baby $BABY @BabylonLabs_io
#baby $BABY 今天我查看了 @babylonlabs_io staking(質押)文檔,今天有一個細節重新定義了我對這裏“原生(native)”含義的理解。 通往比特幣收益的每一條現有路徑,某個時刻都需要進行資產互換。封裝(wrapping)會把你的 BTC 變成一種合成衍生品,其價值取決於持有它的橋(bridge)。橋接(bridging)會把某種代表你 BTC 的東西轉移到另一條鏈上,而原來的部分則被鎖在別處。在這兩種情況下,你最終都持有的是對比特幣的索取權(claim),而不是真正的比特幣本身。 Babylon 的質押機制則不同。你的 BTC 通過比特幣自身的腳本語言來直接鎖定在比特幣鏈上,使用時間鎖(timelocks)和簽名聚合(signature aggregation),在比特幣側不需要智能合約系統。BTC 從未變成別的東西。它仍然保持原樣——作爲一個比特幣 UTXO——位於由質押者控制的、可自我託管的腳本(self-custodied script)之中。 當這筆 BTC 在鎖定期間“在做什麼”纔是關鍵所在。它爲依賴 Finality Providers(最終性提供者)背書/委託(delegated stake)的權益證明(proof of stake)網絡提供經濟安全性。若某個 Finality Provider 發生雙重簽名(double signs),其背後的質押就可能被削減(slashed)。比特幣作爲真實經濟抵押品(collateral)的存在,正是讓這種安全性對依賴它的網絡而言更可信。 “解除質押(unbonding)細節”讓我印象很深。默認的贖回(withdrawal)在時間鎖到期時觸發,不需要 Babylon 或任何外部運營方的合作。提前解除質押則需要 Covenant Committee(契約委員會)的共同簽名,然後還要等待 7 天,資金纔可被提取。即使所有外部方都消失了,質押者仍然可以通過默認路徑隨時退出。 這種獨立性,是大多數“封裝 BTC(wrapped BTC)”方案無法複製的性質。退出路徑是在保管金庫(vault)創建時就被寫入比特幣腳本(Bitcoin script)裏的,而不是掌握在別人的託管之中。 如果將比特幣上的質押收益最終變得可能,而你根本不需要離開比特幣,那麼長期來看,被封裝替代品的需求會發生什麼變化????
#baby $BABY 今天我查看了 @BabylonLabs_io staking(質押)文檔,今天有一個細節重新定義了我對這裏“原生(native)”含義的理解。

通往比特幣收益的每一條現有路徑,某個時刻都需要進行資產互換。封裝(wrapping)會把你的 BTC 變成一種合成衍生品,其價值取決於持有它的橋(bridge)。橋接(bridging)會把某種代表你 BTC 的東西轉移到另一條鏈上,而原來的部分則被鎖在別處。在這兩種情況下,你最終都持有的是對比特幣的索取權(claim),而不是真正的比特幣本身。

Babylon 的質押機制則不同。你的 BTC 通過比特幣自身的腳本語言來直接鎖定在比特幣鏈上,使用時間鎖(timelocks)和簽名聚合(signature aggregation),在比特幣側不需要智能合約系統。BTC 從未變成別的東西。它仍然保持原樣——作爲一個比特幣 UTXO——位於由質押者控制的、可自我託管的腳本(self-custodied script)之中。

當這筆 BTC 在鎖定期間“在做什麼”纔是關鍵所在。它爲依賴 Finality Providers(最終性提供者)背書/委託(delegated stake)的權益證明(proof of stake)網絡提供經濟安全性。若某個 Finality Provider 發生雙重簽名(double signs),其背後的質押就可能被削減(slashed)。比特幣作爲真實經濟抵押品(collateral)的存在,正是讓這種安全性對依賴它的網絡而言更可信。

“解除質押(unbonding)細節”讓我印象很深。默認的贖回(withdrawal)在時間鎖到期時觸發,不需要 Babylon 或任何外部運營方的合作。提前解除質押則需要 Covenant Committee(契約委員會)的共同簽名,然後還要等待 7 天,資金纔可被提取。即使所有外部方都消失了,質押者仍然可以通過默認路徑隨時退出。

這種獨立性,是大多數“封裝 BTC(wrapped BTC)”方案無法複製的性質。退出路徑是在保管金庫(vault)創建時就被寫入比特幣腳本(Bitcoin script)裏的,而不是掌握在別人的託管之中。

如果將比特幣上的質押收益最終變得可能,而你根本不需要離開比特幣,那麼長期來看,被封裝替代品的需求會發生什麼變化????
真實
#baby $BABY 今天我通讀了 Babylon 的文檔,有一個數字一直讓我停下來。只有 1% 的比特幣被用於 DeFi。 比特幣按市值計算是最大的加密資產。也是在去中心化金融領域裏,遠遠最多“閒置”的那一個。原因並不是冷漠。原因是“進入門檻”。目前所有通往 DeFi 的路徑,都要求比特幣持有者在以下某種情況下讓渡控制權:要麼把託管交給第三方;要麼跨鏈橋接;要麼把資產包裝成合成版本;要麼信任一個中介,而中介的償付能力纔是真正的風險所在。長期以來,正是這些權衡,讓比特幣長期持有者拒絕走進 DeFi。 而 @babylonlabs_io 正在圍繞着打造的是一個不同的起點。BTC 從未離開比特幣。它會在創建金庫(vault)的過程中,由存款人共同簽署一段 Taproot 腳本鎖定。金庫上線之前,所有合法的支出路徑都會被預先簽好。之後,任何一方都無法僞造新的支出。協議也無法把 BTC 轉移出去、借貸到別處,或重新利用它。抵押品只會做腳本允許它做的事。 在以太坊側,一個協議合約會爲每個金庫做狀態跟蹤,讓集成的 DeFi 應用能夠把它當作抵押品來使用。跨鏈狀態轉換是通過加密技術來強制執行的,而不是依賴受信任的中介。信任假設從“託管方的償付能力”轉移到了“協議的加密機制”以及“底層的兩個網絡”。 一直留在我腦海裏的表述,是 Babylon 所說的“vault”,在原始意義上的金庫。它不是一種把很多用戶風險混在一起的資金池合約。而是一種被隔離的、由存款人擁有的比特幣輸出。更像銀行裏的安全隔間,而不是 DeFi 的流動性池。 如果有 99% 的比特幣之所以在 DeFi 之外,是因爲每一條現有路徑都需要付出某種代價,那麼當這種進入成本真的消失時,這個空間會是什麼樣子???
#baby $BABY
今天我通讀了 Babylon 的文檔,有一個數字一直讓我停下來。只有 1% 的比特幣被用於 DeFi。

比特幣按市值計算是最大的加密資產。也是在去中心化金融領域裏,遠遠最多“閒置”的那一個。原因並不是冷漠。原因是“進入門檻”。目前所有通往 DeFi 的路徑,都要求比特幣持有者在以下某種情況下讓渡控制權:要麼把託管交給第三方;要麼跨鏈橋接;要麼把資產包裝成合成版本;要麼信任一個中介,而中介的償付能力纔是真正的風險所在。長期以來,正是這些權衡,讓比特幣長期持有者拒絕走進 DeFi。

@BabylonLabs_io 正在圍繞着打造的是一個不同的起點。BTC 從未離開比特幣。它會在創建金庫(vault)的過程中,由存款人共同簽署一段 Taproot 腳本鎖定。金庫上線之前,所有合法的支出路徑都會被預先簽好。之後,任何一方都無法僞造新的支出。協議也無法把 BTC 轉移出去、借貸到別處,或重新利用它。抵押品只會做腳本允許它做的事。

在以太坊側,一個協議合約會爲每個金庫做狀態跟蹤,讓集成的 DeFi 應用能夠把它當作抵押品來使用。跨鏈狀態轉換是通過加密技術來強制執行的,而不是依賴受信任的中介。信任假設從“託管方的償付能力”轉移到了“協議的加密機制”以及“底層的兩個網絡”。

一直留在我腦海裏的表述,是 Babylon 所說的“vault”,在原始意義上的金庫。它不是一種把很多用戶風險混在一起的資金池合約。而是一種被隔離的、由存款人擁有的比特幣輸出。更像銀行裏的安全隔間,而不是 DeFi 的流動性池。

如果有 99% 的比特幣之所以在 DeFi 之外,是因爲每一條現有路徑都需要付出某種代價,那麼當這種進入成本真的消失時,這個空間會是什麼樣子???
登入以探索更多內容
加入幣安廣場中的全球加密貨幣用戶
⚡️ 獲取加密貨幣的最新和實用資訊。
💬 受到全球最大加密貨幣交易所的信任。
👍 發掘來自經過驗證創作者的真實見解。
電子郵件 / 電話號碼
網站地圖
Cookie 偏好設定
平台條款