Scribble in a Nutshell, Joran Honig - DeFi Security Summit 2022
三句話摘要
介紹Scribble規格語言如何簡化Solidity合約的屬性型測試流程。 Scribble透過規格語言自動化，讓開發者用簡潔的屬性定義取代繁瑣的單位測試，同時相容Fuzzing、形式驗證等多種工具，提高Solidity合約的測試效率與覆蓋率。 傳統單位測試要求開發者逐一列舉測試案例（如add(1,2)→3），而屬性型測試改為定義通用行為規則，例如排序函數應返回原列表的有序排列。Scribble是規格語言工具，開發者在合約和函數註解中用簡潔表達式定義屬性，系統自動轉譯為運行時檢查代碼。這些運行時檢查框架無關且相容多種分析工具，開發者可在同一套屬性定義基礎上應用單位測試、Fuzzing、符號執行或形式驗證。
重點整理
重點- 1
傳統單位測試要求開發者逐一列舉測試案例（如add(1,2)→3），而屬性型測試改為定義通用行為規則，例如排序函數應返回原列表的有序排列。Scribble是規格語言工具，開發者在合約和函數註解中用簡潔表達式定義屬性，系統自動轉譯為運行時檢查代碼。這些運行時檢查框架無關且相容多種分析工具，開發者可在同一套屬性定義基礎上應用單位測試、Fuzzing、符號執行或形式驗證。
實用技巧與重點
乾貨- 屬性型測試（Property-Based Testing）
- 參數化單位測試（Parametric Unit Testing）
- Fuzzing 工具
- 符號執行（Symbolic Execution）
- 形式驗證（Formal Verification）
- Scribble：規格語言工具
- 運行時檢查（Runtime Checks）
- Diligence Fuzzing：相關Fuzzing工具
- 在函數和合約上方用註解定義屬性
- 框架無關的檢查邏輯設計
結論
結論“Scribble透過規格語言自動化，讓開發者用簡潔的屬性定義取代繁瑣的單位測試，同時相容Fuzzing、形式驗證等多種工具，提高Solidity合約的測試效率與覆蓋率。”
完整解析
詳細在Solidity開發實踐中，傳統單位測試存在明顯的時間成本與覆蓋不完善的問題。開發者需針對每個函數設計多個具體測試案例來涵蓋邊界情況，例如測試add函數需分別驗證add(1,2)=3、add(0,5)=5等各種輸入組合。隨著合約複雜度增加，這種逐案例測試法不僅耗費大量開發時間，也容易因人為疏漏而遺漏某些關鍵邊界條件，最終導致上線後才發現的關鍵缺陷。
屬性型測試提供了從另一個角度解決此問題的方案。與其手寫具體案例，開發者改為定義通用的行為屬性。以排序函數為例，開發者不再逐一寫出「輸入[3,1,2]應得[1,2,3]」的測試，而是聲明「排序結果必為有序列表且為原列表的排列」這樣的規則。這個屬性定義一旦成立，就自動涵蓋了所有可能的輸入組合。開發者可用參數化單位測試方式反覆調用函數驗證屬性，或交由自動化Fuzzing工具生成邊界案例進行測試，顯著提升測試效率。
Scribble正是為簡化屬性定義與驗證而設計的規格語言。開發者在Solidity合約與函數層級的註解中用Scribble語法撰寫屬性描述，這些表達式比純Solidity更簡潔且富有表現力。Scribble工具隨後將這些高階屬性定義自動編譯為運行時檢查代碼，這些檢查邏輯是框架無關的，幾乎能與所有主流測試工具無縫整合。開發者可基於同一套屬性定義，搭配傳統單位測試框架進行驗證，或結合Diligence Fuzzing工具進行自動化邊界探測，甚至應用符號執行與形式驗證進行深層次分析。這種設計哲學使Scribble成為能跨越整個工具生態的樞紐，大幅降低Solidity合約的測試負擔。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
