合約可以是正確的，而我的 DuskVM 調用仍然會因爲兩個字符而死掉。
DuskVM 的輸入不會作爲可讀的 JSON 發送。它們是 rkyv 編碼後的字節，Forge 使用合約的鏈下數據驅動程序，把像 42 這種對人類可讀的東西轉換成合約實際期望的字節。
尷尬之處在於交接。Forge 會把我給到的那個編碼值以帶 0x 前綴的十六進制形式給出來。某些 SDK 可能希望保留這個前綴。Rusk Wallet 的 --fn-args 要求我把它去掉。
所以我可以測試合約邏輯，驗證 WASM，正確編碼參數，然後通過用“錯誤的傳輸形狀”傳入完全相同的字節來中斷真實調用。
這就是我會最嚴防的集成漏洞。不是因爲它很戲劇化，而是因爲上游看起來一切正常。函數存在。模式是對的。值也是對的。失敗發生在數據驅動和發送方之間的邊界。
如果我要構建一個 DuskVM 應用，我會在一次調用中規範化調用參數，並且用我支持的每一種提交路徑去測試這條邊界。
兩個字符絕不應該成爲一個有效的合約操作變成失敗用戶交易的原因。
#dusk $DUSK @Dusk
DuskVM 的輸入不會作爲可讀的 JSON 發送。它們是 rkyv 編碼後的字節，Forge 使用合約的鏈下數據驅動程序，把像 42 這種對人類可讀的東西轉換成合約實際期望的字節。
尷尬之處在於交接。Forge 會把我給到的那個編碼值以帶 0x 前綴的十六進制形式給出來。某些 SDK 可能希望保留這個前綴。Rusk Wallet 的 --fn-args 要求我把它去掉。
所以我可以測試合約邏輯，驗證 WASM，正確編碼參數，然後通過用“錯誤的傳輸形狀”傳入完全相同的字節來中斷真實調用。
這就是我會最嚴防的集成漏洞。不是因爲它很戲劇化，而是因爲上游看起來一切正常。函數存在。模式是對的。值也是對的。失敗發生在數據驅動和發送方之間的邊界。
如果我要構建一個 DuskVM 應用，我會在一次調用中規範化調用參數，並且用我支持的每一種提交路徑去測試這條邊界。
兩個字符絕不應該成爲一個有效的合約操作變成失敗用戶交易的原因。
#dusk $DUSK @Dusk