Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
24 лайків
Нагородити
24
8
Репост
Поділіться
Прокоментувати
0/400
GateUser-addcaaf7
· 01-20 16:56
Нарешті хтось чітко пояснив Dusk, це не так просто, як приватність
Ідея пріоритету правил дійсно крута, інші ланцюги спочатку додають потім доповнюють, а цей хлопець одразу ж вбудовує
Попередня перевірка проти виправлення після події, у фінансових сценаріях справді немає вибору — якщо щось трапиться, все закінчиться
Але чи не призведе це до зниження продуктивності, додавання відповідності у протокол здається складним
Переглянути оригіналвідповісти на0
ContractHunter
· 01-20 14:38
Ей, нарешті хтось сказав це. Більшість ланцюгів просто змінюють інтерфейс і хваляться відповідністю, але Dusk із цим підходом, коли правила закріплені на рівні низу, дійсно круті.
Перш ніж говорити про пріоритетність правил, це здається простим, але насправді зробити це дуже важко, і витрати на це дійсно високі.
Але мені все одно цікаво, чи не стане ця сувора попередня перевірка механізмом, що зжере продуктивність, і як вона працює у реальних сценаріях?
Я вважаю, що саме це і є ключовим для того, чи зможе Dusk вийти на передній план, а не питання приватності чи ні.
Переглянути оригіналвідповісти на0
GateUser-5854de8b
· 01-18 19:54
Ей, нарешті хтось пояснив цю справу з Dusk. Це не просто приватний ланцюг, головне — передумови правил, і це справжня фінансова робота
Переглянути оригіналвідповісти на0
NotSatoshi
· 01-18 19:52
Ну, ця ідея дійсно інша, додавання до протоколу з точки зору відповідності має цікавість
Переглянути оригіналвідповісти на0
ValidatorViking
· 01-18 19:49
ngl, це такий тип філософії проектування протоколів, який насправді відрізняє перевірені часом рішення від порожніх обіцянок. попередня валідація перевершує розбір польотів кожного разу, коли на кону стоїть реальний капітал.
提起Dusk Network,很多人下意识就會貼上"隱私鏈"的標籤。但這樣想的話,其實錯過了最關鍵的東西。
Dusk真正在做的,不是讓鏈上交互變得花里胡哨,而是回答一個更扎根的問題:當真實的金融資產(帶著監管、法律責任這些包袱)要上鏈時,系統能不能真的撐住?
這不是行銷口號。打開Dusk的每一層設計,你會發現都指向同一個答案。
**資產生成的第一性原理:規則必須先走**
大多數公鏈怎么玩的?先把資產甩出來,再用前端、白名單或鏈外流程去補規則。反著來嘛。
但現實金融資產不是這麼誕生的。證券、基金份額、受監管資產,從第一天就自帶邊界——誰能持有、什麼條件下能轉讓、是否需要持續披露。所有這些東西都不是後加的。
Dusk的選擇是完全貼近現實邏輯。
在這套體系裡,資產創建的那一刻,合規條件就被寫進協議層了。持有資格、轉讓限制、驗證要求——系統在每一次狀態變更之前都必須校驗這些。
這就產生了一個關鍵差異:規則不是貼在資產上的貼紙,而是資產本身的骨架。
**前置檢驗和事後補救,哪個更靠譜**
很多鏈採用事後處理模式,出問題了再凍結、回滾、打補丁。但在金融場景下,這種方式天然有bug——某些違規操作一旦發生,後果就鎖死了。
Dusk要求的是無法發生。不是發生後處理,而是系統根本不會讓那一步邁出去。這樣做成本高嗎?高。但對標的是現實金融系統的運作邏輯,這種選擇其實是有道理的。