shareyourthinking

智慧合約驗證依賴的可靠性承諾

這件事我想了幾天，因為我之前也曾在智慧合約中加入第三方依賴，而問題總是撞到同一堵牆：如果該依賴掛了，我的協定會怎麼辦。

Newton 要求應用在執行前，必須在其智慧合約中驗證 BLS 驗證（attestation）。沒有有效的驗證就不會執行。

這就是強制機制，也是硬性依賴。

一旦某個協定把這個要求部署到不可變（immutable）的合約中，它就承諾：牛頓（Newton）的運營者網路（operator network）必須在未來每一筆交易中都可用，因為該合約將處理的所有交易都需要它。

這不是批評。這是一個具有真實影響的設計選擇。

把 Newton 整合進來的協定，不再只是信任自己的程式碼。

它信任的是：一個由已質押運營者所組成的多數（quorum）會持續評估政策，並為每一筆交易產生驗證，永不停止。白皮書談到的是透過強制納入（force-inclusion）來應對審查（censorship）。但它並沒有說明：當運營者網路發生真正的退化時會怎麼樣——不只是審查，而是效能不足或部分停機（partial outage）。
#newt
我其實認為，可靠性承諾才是最重要的問題，對評估 Newton 的協定團隊來說，比合規（compliance）功能清單更關鍵。把依賴加到智慧合約是永久性的；而把依賴加到網路服務上就不是。
#NEWT
我還沒弄清楚的是：是否存在一種優雅降級模式（graceful degradation mode），也就是說，當運營者中斷（outages）發生時，協定是否能夠在不完全停止（halt entirely）的情況下改走備援，而不是直接中止。
#ShareYourThinking $LAB $HMSTR
@NewtonProtocol $NEWT #Newt

水龍頭的領取限額決定了測試網到底是否真的測試了接近真實使用的情況，還是僅僅在極小規模下確認流程在“跑通”。

#baby A：每個錢包領取固定“小額”的水龍頭，用來確認充值到借貸機制能夠正常工作是沒問題的。但這不適用於壓力測試：例如健康因子（Health factor）計算會發生什麼、清算觸發條件（Liquidation Triggers）會如何表現，或是 Aave v4 池在接近主網上用戶實際會投入的頭寸規模下會如何運作。無信任比特幣金庫（TBV）測試網之所以存在，是爲了在真正的資金流入之前驗證其設計。而這種驗證的有效性，只取決於被實際測試到的頭寸規模是否足夠真實。$BABY

並不是說有上限的水龍頭是設計缺陷；無限制的水龍頭會被耗盡或被濫用，而大多數測試網正是因爲這個原因纔會設置上限。

並不是說上限沒有影響。如果每個測試者拿到的都是同樣的小額度，那麼在更大頭寸下才會出現的某些故障模式——例如級聯清算（cascading liquidations）、資金池深度問題（pool depth issues）、健康因子邊緣情況（health factor edge cases）——在主網上線之前根本不會被觸發或檢驗。@BabylonLabs_io

我還沒想清楚的是：較低的領取上限，是不是確實作爲一種安全預防措施來防止水龍頭被濫用；還是說它在不聲不響地限制着測試網階段最多能產生多少真實的壓力測試，直到主網資金處於風險之中。$AKE
$BANK #ShareYourThinking