Lin Cheng-Chieh
    • Create new note
    • Create a note from template
      • Sharing URL Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Customize slides
      • Note Permission
      • Read
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Write
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Engagement control Commenting, Suggest edit, Emoji Reply
    • Invite by email
      Invitee

      This note has no invitees

    • Publish Note

      Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note

      Your note will be visible on your profile and discoverable by anyone.
      Your note is now live.
      This note is visible on your profile and discoverable online.
      Everyone on the web can find and read all notes of this public team.
      See published notes
      Unpublish note
      Please check the box to agree to the Community Guidelines.
      View profile
    • Commenting
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
      • Everyone
    • Suggest edit
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
    • Emoji Reply
    • Enable
    • Versions and GitHub Sync
    • Note settings
    • Note Insights
    • Engagement control
    • Transfer ownership
    • Delete this note
    • Save as template
    • Insert from template
    • Import from
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
    • Export to
      • Dropbox
      • Google Drive
      • Gist
    • Download
      • Markdown
      • HTML
      • Raw HTML
Menu Note settings Versions and GitHub Sync Note Insights Sharing URL Create Help
Create Create new note Create a note from template
Menu
Options
Engagement control Transfer ownership Delete this note
Import from
Dropbox Google Drive Gist Clipboard
Export to
Dropbox Google Drive Gist
Download
Markdown HTML Raw HTML
Back
Sharing URL Link copied
/edit
View mode
  • Edit mode
  • View mode
  • Book mode
  • Slide mode
Edit mode View mode Book mode Slide mode
Customize slides
Note Permission
Read
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Write
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Engagement control Commenting, Suggest edit, Emoji Reply
  • Invite by email
    Invitee

    This note has no invitees

  • Publish Note

    Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note

    Your note will be visible on your profile and discoverable by anyone.
    Your note is now live.
    This note is visible on your profile and discoverable online.
    Everyone on the web can find and read all notes of this public team.
    See published notes
    Unpublish note
    Please check the box to agree to the Community Guidelines.
    View profile
    Engagement control
    Commenting
    Permission
    Disabled Forbidden Owners Signed-in users Everyone
    Enable
    Permission
    • Forbidden
    • Owners
    • Signed-in users
    • Everyone
    Suggest edit
    Permission
    Disabled Forbidden Owners Signed-in users Everyone
    Enable
    Permission
    • Forbidden
    • Owners
    • Signed-in users
    Emoji Reply
    Enable
    Import from Dropbox Google Drive Gist Clipboard
       owned this note    owned this note      
    Published Linked with GitHub
    Subscribed
    • Any changes
      Be notified of any changes
    • Mention me
      Be notified of mention me
    • Unsubscribe
    Subscribe
    --- tags: web3 --- # SoK 相關調查(由 ChatGPT 統整) SoK 論文 [SoK: Decentralized Finance (DeFi) Attacks](https://arxiv.org/abs/2208.13035) 最後更新時間:Tue, 20 Sep 2022 20:19:53 UTC (2,188 KB) 2023/03/09 與 Ron 哥討論的統整: Sok 做了很多統整、做了弱點掃描,但是沒有做到讓開發者在開發時期就避開可能產生漏洞的設計模式,目前就 sok 可以我們有機會做的主題: 1、看別人的survey 思考怎麼做 design pattern 才能讓 contract 安全 2、這篇論文是 2021 的,可以延伸思維、把2021之後的攻擊統整。(可能要花較多體力,而且新的 contract 可能把大多漏洞都避掉了) 這周先用以下方法快速累積閱讀論文量: 先利用 chat gpt 快速 survey reference paper 的摘要跟結論、看別人注重的方向、看別人做到甚麼程度,再看未來展望。除非確定那篇很重要,不然數學證明等細節可以先不用看。拿future work 來做。 優先閱讀 sok 的 [10] ~ [16]: ![](https://i.imgur.com/r0mwim0.png) **摘要** 這段論文主要探討區塊鏈去中心化金融(DeFi)生態系統的現況和問題。作者提到,DeFi在短短四年內已累積超過2530億美元的峰值鎖定總值,但同時也伴隨著許多影響深遠的事件,從2018年4月30日到2022年4月30日,用戶、流動性提供者、投機者和協議運營商共損失了至少32.4億美元。作者指出,隨著區塊鏈的透明度和事件頻率越來越高,有兩個問題需要解決:我們如何系統地衡量、評估和比較DeFi事件?我們如何從過去的攻擊中學習,加強DeFi的安全性? 為了解決這些問題,作者引入了一個常見的參考框架,以系統地評估和比較DeFi事件,包括攻擊和事故。作者調查了77篇學術論文、30份審計報告和181起真實世界事件,並公開了數據,揭示了學術界和實踐界之間的一些差距。例如,很少有學術論文涉及“價格預言機攻擊”和“無需權限的交互”,而作者的數據表明,它們是兩種最常見的事件類型(分別占15%和10.5%)。此外,作者還調查了可能的防禦措施,發現:(i)103(56%)的攻擊未被原子地執行,為防禦者提供了拯救時間窗口;(ii)最先進的字節碼相似性分析至少可以檢測到31個易受攻擊/23個對抗合約;(iii)33(15.3%)的對手通過與集中式交易所的互動泄漏可能識別的信息。 **結論** 本文建立了一個 DeFi 參考框架,將 77 篇學術論文、30 份審計報告和 181 個事件進行分類,揭示了學術界和實踐界在防禦和檢查事件方面的差異。我們研究了比較受害者/對抗智能合約的字節碼、量化攻擊時間框架以及追蹤每個攻擊者的資金來源等潛在的防禦機制。我們的結果表明,DeFi 的安全性仍處於起步階段,許多潛在的防禦機制需要進一步研究和實施。 **Future Works** - 我們的方法無法將使用不同編譯器和優化選擇的相似合約聚類。此外,如果攻擊者選擇通過將未使用的函數代碼注入到合約中來混淆字節碼,我們的方法就會變得不太有效。因此,我們強調採用更複雜的策略作為未來工作的有趣途徑。 - 我們的數據集中只有一起事件在發生的第一個小時內觸發了緊急暫停。這表明缺乏入侵檢測工具以自動觸發緊急暫停。我們預計,在未來的研究中,對異常協議狀態或惡意交易的即時檢測將受到更多關注。 - 智能合約(SC)和協議層(PRO)的事件是最常見的事件類型(分別為42%和40%)。然而,安全工具平均僅覆蓋了52%的PRO層事件類型,少於SC層(90%)。因此,我們的數據集表明,大多數防禦工具仍然集中在SC漏洞上。然而,文獻表明,開發有效且通用的PRO事件防禦工具仍然是一個開放的安全挑戰[9]。這主要是由於DeFi的可組合性特徵,導致在檢測PRO層漏洞時產生了行動路徑爆炸。 ## SoKs, Surveys 看 Table III 的 Survey papers: ### [10] [Security analysis methods on ethereum smart contract vulnerabilities: a survey](https://arxiv.org/abs/1908.08605) 最後更新時間:Wed, 16 Sep 2020 22:16:24 UTC (527 KB) **摘要** 智能合約是具備傳統應用程式和區塊鏈分佈式數據存儲功能的軟體程式。以太坊是一個知名的區塊鏈平台,支援智能合約。智能合約在關鍵的去中心化應用程式中作為自主代理,持有大量加密貨幣以進行可信任的交易和協議。自2016年至2018年間,數以百萬計的加密貨幣作為智能合約的資產被盜或凍結,例如DAO攻擊、Parity多重簽名錢包攻擊和整數下溢/上溢攻擊。這些攻擊是由設計和實現軟體代碼的技術漏洞結合而成的。然而,由於Solidity語言的腳本特性和區塊鏈的不可更新特性,還有許多較不嚴重的漏洞有待發現。因此,我們調查了16個智能合約程序中的安全漏洞,其中一些漏洞還沒有適當的解決方案。這項調查旨在從內部機制和軟體安全漏洞的角度識別以太坊智能合約中的關鍵漏洞。通過將16個以太坊漏洞與19個軟體安全問題相關聯,我們預測還有許多攻擊有待開發。我們還探索了許多軟體工具,以靜態分析、動態分析和形式驗證等方面檢測智能合約的安全漏洞。這項調查介紹了智能合約的安全問題以及可用的分析工具和檢測方法。我們還調查了工具或分析方法與智能合約的已識別安全漏洞之間的限制。 **結論** 智能合約在以太坊上已成為分散應用程式中數字化代理人的常用方式。為避免不必要的損失和惡意攻擊,必須確保智能合約的安全性。目前有幾種分析機制可用於測試和確保智能合約的正確性和非易受攻擊的模式。但智能合約的開發人員和使用者應注意這些分析方法的精度和性能。我們的調查確定了以太坊上智能合約中現有的漏洞,並將安全分析方法分為三種類型:靜態分析、動態分析和形式驗證。然後,我們比較了這三種方法在性能、發現漏洞的覆蓋範圍和準確性方面的差異。靜態和動態分析方法使用自動化工具,非常方便使用和分析易受攻擊的合約,但它們只能檢測其特定定義的易受攻擊模式。形式驗證方法使用定理證明器來使用其解釋的證據驗證智能合約中的正確性屬性。 **Future Works** - DAO攻擊發生的原因是由於兩個重要的漏洞,即存在可重入問題和在發送資金後更新合約狀態。可通過使用 address.transfer() 或 address.send() 函數來緩解可重入問題,而不是直接調用address.call.value()[88]。call函數允許調用者在更改合約狀態之前進行多次外部調用[62],[76]。開發人員應該意識到在向用戶發送資金之前應該更新合約狀態或餘額,而不是在之後更新。工具OYENTE、ZEUS、Vandal 和 Ethir 可用於檢測可重入漏洞。Securify 檢查受限轉移屬性,有助於檢測狀態更新問題並在相關代碼行中提供解決方案[66]。 - Parity 多簽錢包攻擊發生是由於缺乏對外部庫函數的適當訪問修飾符[89]。解決這個問題的方法是在外部庫中的函數中使用 private 修飾符,並使用鎖定機制來避免在未經所有者許可的情況下發送資金或更改狀態[117]。MAIAN發現了被凍結並無限期鎖定其資金的貪婪合約。這種方法有助於發現調用公共外部函數而沒有受限訪問權限的合約。像 Parity 多簽錢包問題這樣的攻擊只能部分解決,因為不可能避免所有對公共外部函數的調用[89]。 - 整數下溢/溢出攻擊發生是由於未檢查的轉帳和異常處理問題。ZEUS、Vandal和Securify [64]、[66]、[65]能夠檢測到未檢查和失敗的轉帳問題。此外,最新版本的Solidity編譯器[103]在編譯智能合約時會對整數下溢問題發出警告。因此,如果使用正確版本的Solidity編譯器,就能夠解決這個問題,避免許多未來的攻擊[66]。 - 考慮到 Ethereum 智能合約中存在多種關鍵漏洞,許多有漏洞的合約已經部署在 Ethereum 區塊鏈上。由於智能合約中的不可變性特性,除非進行硬分叉,否則無法修改已經部署的智能合約的功能。即使我們有分析工具和驗證方法來檢測有缺陷的合約 [62],[63],[64],[65],[66],[67],[68],[69],[70],[71],[72],[69],[73],[74],[75],但要消除所有有漏洞的智能合約是非常具有挑戰性的。然而,建議在將合約部署到實時網路之前,使用 Ethereum 編譯器、分析工具或正式驗證方法進行測試和檢測錯誤。 - 工具的易用性有顯著的差異。包括 OYENTE、Securify、MAIAN 和 Vandal 在內的一些工具是全自動化分析工具。自動化工具可以輕易地設置在分析大量智能合約之前。Securify 是一種在線掃描工具 [154],因此智能合約代碼可以掃描可能存在的漏洞。OYENTE 提供了一個 Docker 鏡像 [155],可以快速部署應用程序,因為 Docker 鏡像包含所有所需的依賴項 [156]。然而,只有少數形式驗證方法在 GitHub 上發布了其源代碼 [67],[74]。它們部分自動化地驗證和證明智能合約的正確性屬性。形式驗證方法的初始設置需要比符號執行工具 [62]、[63]、[64]、[65]、[66] 更長的時間。 - Solidity 編譯器 solc [103] 在開發階段已經有了良好的改進,可以檢測智能合約中的基本錯誤和易受攻擊的模式。大多數分析工具依賴 solc 編譯器將智能合約 Solidity 代碼編譯為字節碼,如表 VI 所示。未來的工作可以將檢測工具作為 solc 編譯器的外部插件集成,以幫助開發人員在編譯期間識別易受攻擊的合約 [157],[158]。Johannes 等人 [159] 開發了一個自動化工具 teEther,使用問題合約的通用定義來為合約字節碼創建漏洞利用。 - 靜態分析工具能夠偵測到特定的漏洞,如表格IV所列。發表的文獻中提出了17種漏洞[60],[62],[76],[79],[83]。OYENTE [62]無法檢測與邏輯相關的問題[57]。它已經縮小到檢測與智能合約開發人員所提出的語義誤解有關的安全漏洞[62]。ZEUS的驗證過程是使用抽象語言解釋方法對基於Solidity的智能合約進行的[64]。Kalra等人[64]證明了可以通過一些改變使ZEUS能夠擴展到分析其他區塊鏈平台上的智能合約。Vandal框架[65]也部分使用抽象解釋方法,但它直接使用自己的反編譯器分析EVM字節碼。 - GASPER [71] 可以檢測智能合約中的七種高耗 gas 模式。在複雜的合約程序中,可能會出現更多的高耗氣模式。陳等人已確保他們將擴展研究,以發現更多未經優化的模式並通過其工具進行檢測 [71]。Ethir [68] 框架利用 OYENTE 中開發的控制流圖方法分析以太坊字節碼。但是,Ethir 沒有對控制流圖算法的恢復能力進行任何改進 [64]。Securify 使用 Datalog 求解器 [147] 有效地分析智能合約代碼。Flix [160] 使用 Datalog 增強了分析過程的可擴展性。Securify [66] 可以利用這些 Datalog 求解器的進展作為未來的發展方向。 - 正式驗證方法使用不同的定理證明器,如Isabelle/HOL、F*、KEVM、Lem和Coq [67],[74],[92],[91]。由於它們使用複雜的機制,對於普通用戶使用正式驗證方法分析智能合約並不簡單。也就是說,用戶必須接受教育和培訓,了解證明方法的工作原理以及如何閱讀輸出。此外,正式驗證方法使用一種通用方法構造代碼模式和定理,以證明智能合約的安全屬性 [67],[74],[92],[91]。由於這些證明器是半自動的,正式驗證方法需要大量的人工努力來構建證明和分析智能合約 [67],[65]。因此,這些方法對於目前部署在以太坊網絡上的數千個智能合約的分析能力較差 [110],[65]。但是,正式驗證方法提供準確和及時的結果,驗證智能合約的安全性、安全性和健全性屬性 [67],[73],[91],[93],[95],[96]。 reentrancy 對 vul 分類、點出情境、 dao attack,近期的機制與過去不同 ### [11] [The Security Reference Architecture for Blockchains: Towards a Standardized Model for Studying Vulnerabilities, Threats, and Defenses](https://arxiv.org/abs/1910.09775) 最後更新時間:Wed, 28 Oct 2020 13:25:39 UTC (1,750 KB) **摘要** 區塊鏈是分散式系統,安全性是其成功的關鍵因素。然而,儘管其日益普及和採用,仍缺乏標準化的模型來研究與區塊鏈相關的安全威脅。為填補這一空白,我們的主要工作重點是系統化和擴展有關區塊鏈安全和隱私方面的知識,並為此領域的標準化做出貢獻。我們提出了區塊鏈安全參考架構 (SRA),採用了一種堆疊模型 (類似於 ISO/OSI),描述了各種安全和隱私方面的性質和層次。SRA包含四層:(1) 網絡層,(2) 共識層,(3) 複製狀態機層,以及(4) 應用層。在每一層中,我們識別了已知的安全威脅、其起源和對策,同時也分析了幾個跨層次的依賴關係。接著,為了讓實踐者更好地理解區塊鏈的安全方面,我們提出了區塊鏈特定版本的威脅風險評估標準ISO/IEC 15408,將堆疊模型嵌入到該標準中。最後,我們為區塊鏈平台和應用程序的設計者提供了一種設計方法,遵循SRA模型及其層次結構。 **結論** 本文針對區塊鏈系統的安全性知識進行系統化整理,並旨在建立一個標準化模型以研究漏洞和安全威脅。我們提出了一個基於堆疊模型的安全參考架構(SRA),包含四個層次,並在每個層次中調查了各種實例化的類別和選項,以及相關的安全影響和屬性。我們將特定的類別建模為漏洞/威脅/防禦圖表,並提供作為推斷所強加安全性方面的手段。接著,我們收集了一些實際發生的與區塊鏈有關的事件樣本,並使用我們提出的模型進行進一步分類。我們觀察到,在實際中發生的事件類型數量遠遠小於所描述的威脅數量,特別是在共識和應用層次。在應用層次中,大多數事件是由於外部或內部攻擊者利用集中式組件而導致的,而在共識層次中,大多數事件是由於51%攻擊暫時違反協議假設所致。最後,我們提供了一個針對區塊鏈平台和應用程序設計者的安全導向方法,尊重所提出的SRA。 **Future Works** - 快速最終性。雖然最終性是共識層中最關鍵的安全功能(見第 X-D 節),但它與可擴展性之間存在一個折衷。因此,我們認為,共識研究的未來重點應該是在各種共識協議之間徹底評估這種折衷。 - 網絡層安全。我們了解到,區塊鏈的安全研究主要集中在共識和RSM層,因為這些層通常與區塊鏈密切相關。相反,網絡層不太受歡迎,儘管來自這一層的嚴重威脅可能會損害更高層次的區塊鏈和其資產。因此,未來研究的潛在方向在於研究網絡協議的安全方面,它們在分散式環境中的適用性以及潛在的改進方向。 - 隱私保護和效能。所有的加密隱私保護技術(參見第VII-A1節)都會增加額外的計算負擔,因此它們對區塊鏈的吞吐量產生負面影響。另一方面,基於可信硬體的隱私保護解決方案可能提供更高的效能,但它們依賴於可信硬體的製造商以及它不會被破壞的假設。因此,我們認為在關於RSM層的未來研究方向中,優化效能和隱私保護之間的平衡是一個重要的方向。 - 應用層面的安全分析。儘管這項研究所包含的許多參考資料都呈現在應用層面,但只有很少數的參考資料徹底分析了特定應用層類別或其實例的安全方面。因此,作為未來的研究方向,我們建議基於區塊鏈的應用程式的作者分析他們的應用程式對特定應用程式類別(例如,利用我們的工作)的所有已知威脅的抵抗力,同時廣泛思考可能特定於其應用程式類型的新漏洞和威脅。 - 去中心化。由於某些區塊鏈應用程式使用了集中式的元件,而它們的去中心化變體已經存在(參見第X-F節),因此我們建議研究人員和實踐者未來的研究方向可能是完全去中心化的區塊鏈生態系統的概念。這樣的生態系統可能只包含去中心化(或部分去中心化)的應用程式類型,例如我們在SRA的應用層中審查的那些應用程式。 ### [12] [Exploring the Attack Surface of Blockchain: A Systematic Overview](https://arxiv.org/abs/1904.03487) 最後更新時間:Sat, 6 Apr 2019 16:34:34 UTC (1,749 KB) **摘要** 本論文系統性地探討區塊鏈技術的攻擊面,重點在於公共區塊鏈。為了達到這個目的,我們將攻擊表現歸因於以下三個因素:1)區塊鏈的密碼學構造,2)使用區塊鏈的分散式架構系統,以及3)區塊鏈的應用情境。對於每個因素,我們概述了幾種攻擊方法,包括私有礦業攻擊、51%攻擊、域名系統(DNS)攻擊、分散式拒絕服務(DDoS)攻擊、共識延遲(由於自私行為或分散式拒絕服務攻擊)、區塊鏈分支、孤立和陳舊區塊、區塊鏈資料庫、錢包竊取、智能合約攻擊和隱私攻擊。我們還探討了這些攻擊之間的因果關係,以展示各種攻擊向量如何相互關聯。本文的次要貢獻是概述了區塊鏈技術採取的有效防禦措施或研究人員提出的防禦措施,以減輕這些攻擊的影響並修補相關漏洞。 **結論** 在這篇論文中,我們探索了區塊鏈技術的攻擊面。我們將攻擊歸因於區塊鏈的加密構造、底層通信架構和應用場景。這樣做的目的是突出主要威脅和正在進行的防禦研究活動。我們認為,盡管目前已經存在防禦措施,仍然可以對區塊鏈發動各種攻擊,而其中一些攻擊可以用於促進其他攻擊的實施。通過概述這些攻擊和調查它們的對策,我們強調了需要追求更安全有效的區塊鏈使用的新研究方向。 **Future Work** 這篇 Future Work 都聚焦在基礎設施、Protocal。 ### [13] [A Survey on Ethereum Systems Security: Vulnerabilities, Attacks and Defenses](https://arxiv.org/abs/1908.04507) 最後更新時間:Tue, 13 Aug 2019 06:15:41 UTC (514 KB) **摘要** 本文探討區塊鏈技術,許多人相信它將成為金融應用領域的遊戲改變者。雖然第一代區塊鏈技術(即區塊鏈1.0)幾乎完全用於加密貨幣目的,但以以太坊為代表的第二代區塊鏈技術(即區塊鏈2.0)是一個開放且去中心化的平台,使得運行於區塊鏈之上的去中心化應用程式(DApps)成為可能。DApps 的豐富應用和語義無疑會引入許多安全漏洞,這在純加密貨幣系統(如比特幣)中是不存在的。由於以太坊是一個新的、複雜的系統,因此有必要從全面的角度對其進行系統性和全面的安全性了解,目前缺乏此類研究。據我們所知,本文所提供的調查報告,也可用作教學,填補了這一空白。特別是,我們對以太坊系統的三個方面進行了系統化的分析:漏洞、攻擊和防禦。我們獲得了有關漏洞根本原因、攻擊後果和防禦能力等方面的洞見,這為未來的研究方向提供了啟示。 **結論** 我們提供了一個有系統的調查,針對以太坊系統的安全性進行了分析,包括其應用程序、數據、共識和網絡層。我們從漏洞、攻擊和防御三個方面進行分析,並將它們相互關聯。我們不僅討論了漏洞的位置,還分析了它們的根本原因。我們對以太坊系統的攻擊和防御進行了系統化的分析。此外,我們將行業提出的最佳實踐系統化為一些指導原則,這些原則對實踐者來說可能更易於採用。我們提供了有關現有技術水平的見解,以及未來研究方向的展望。 **Future Work** - A. 屬性的嚴謹定義:我們注意到,要充分保護以太坊和基於區塊鏈的系統,迫切需要了解理想的安全性屬性,但對於像以太坊這樣的複雜系統,這些屬性非常難以形式化。一些非正式的屬性已經在[165]中討論過,這是朝著最終目標邁出的非常初步的第一步。這導致了:洞見13:對於以太坊和基於區塊鏈的系統應該擁有的嚴格規定的理想安全屬性,缺乏深入的理解。 - B. 嚴謹的分析方法論:在定義應該滿足的嚴謹屬性後,我們需要有原則性和嚴謹的方法論來分析是否確實滿足了所需的屬性。針對針對構建區塊鏈的基礎屬性,密碼學和形式化方法是兩種成功的方法,但需要注意它們各自的局限性。由於區塊鏈系統,如以太坊,確實是複雜系統,因此可能無法防止所有攻擊,這意味著攻擊是不可避免的,必須充分了解並管理其風險。這需要從整體角度出發進行嚴謹的分析方法論。為實現這一最終目標,最近提出的“cybersecurity dynamic”方法[166],[167],[168],[169],[170],[171],[172],[173],[174]具有巨大的潛力,儘管我們還沒有看到相關研究成果發表。因此,我們獲得以下見解:見解14:對於分析區塊鏈系統所需的嚴謹屬性,缺乏對必要和充分的嚴謹分析方法論的深刻理解。 - C. Metrics 嚴謹地定義度量標準以系統地測量所感興趣的安全特性是一個非常困難的問題。然而,考慮到基於區塊鏈的系統極有可能成為未來社會的數字基礎設施(如果現在還不是的話),迫切需要定義度量標準來衡量其安全性和風險。儘管已經做出了大量的努力[175],[176],[177],[178],[179],[180],[181],但我們並不知道有任何系統性的研究。這導致:洞見15:缺乏對必要且足夠量化區塊鏈系統安全性和風險的度量標準的深刻理解。 ### [14] [SoK: Decentralized Finance (DeFi)](https://arxiv.org/abs/2101.08778) 最後更新時間:Thu, 15 Sep 2022 17:57:57 UTC (884 KB) **摘要** 去中心化金融(DeFi)是一種區塊鏈驅動的點對點金融系統,正在快速增長。兩年前,DeFi系統中鎖定的總價值約為7億美元,現在截至2022年4月,已經達到約1500億美元。生態系統的狂熱演進使得理解這些系統的基本原理和安全風險變得具有挑戰性。在本篇知識體系統整理(SoK)中,我們沿著以下軸線條理化分DeFi生態系統:其基元、操作協議類型和安全性。我們區分技術安全和經濟安全,前者有健康的文獻,後者則幾乎未被探索,通過新模型將其聯繫起來,並綜合計算機科學、經濟學和金融學的見解。最後,我們概述了跨越這些安全類型的生態系統中的開放性研究挑戰。 **結論** 在這份知識體系統整理中,我們從 DeFi 樂觀主義者和悲觀主義者的兩個角度出發,系統性地研究了 DeFi 的運作。首先,我們列出了 DeFi 的基本構成部分,然後將 DeFi 協議按其提供的操作類型進行了分類。在區分與 DeFi 協議相關的不同類型信息後,我們提供了有關漏洞的工作定義。我們將經濟安全確立在技術安全的同等級別上,並創建了一種新的功能性風險分類方法。此外,我們還提供了這些風險的清晰定義,以及需要理解和防範這些風險的模型類型的見解。最後,我們引起了對需要全面理解技術和經濟風險的開放性研究挑戰的關注。雖然 DeFi 可能具有創建一個無需許可且非托管的金融系統的潛力,這是 DeFi 樂觀主義者提出的觀點,但開放的技術和經濟安全挑戰仍然存在。至少目前來看,DeFi 悲觀主義者的立場是牢固的:以強大和可擴展的方式解決這些挑戰是研究人員和 DeFi 從業者的中心挑戰。然而,最終,正是潛力和挑戰之間的融合——DeFi 樂觀主義者和 DeFi 悲觀主義者觀點之間的緊張關係——使 DeFi 成為一個值得研究的有價值和令人興奮的領域。 ### [15] [A survey of attacks on Ethereum smart contracts](https://eprint.iacr.org/2016/1007.pdf) **摘要** 智能合約是能夠在互不信任的節點網絡中被正確執行的計算機程序,無需外部可信任的權威機構。由於智能合約處理和轉移相當有價值的資產,除了確保它們被正確執行外,確保其實施對於旨在竊取或篡改資產的攻擊也至關重要。我們在迄今為止最為著名和使用的智能合約框架Ethereum中研究這個問題。我們分析了Ethereum智能合約的安全漏洞,提供了常見的編程陷阱分類,這些陷阱可能導致漏洞。我們展示了一系列利用這些漏洞的攻擊,使對手能夠竊取資產或造成其他損害。 **結論** - Future Work: 我們提出了對以太坊智能合約安全性的分析。我們的分析基於學術文獻、以太坊互聯網論壇以及我們在編寫智能合約方面的經驗。我們的分析涵蓋了迄今為止所有主要漏洞和攻擊。我們的分類法擴展了針對軟件安全漏洞的其他分類法[27,28,42,50],並適用於智能合約領域。隨著新的漏洞和攻擊的發現,我們的分類法將不斷發展。可以預見的是,安全敏感區塊鏈應用程序的巨額投資和其當前實現的差劣安全性之間的相互作用將促進對這些問題的研究。本文討論的攻擊突顯了智能合約不安全的一個常見原因,即難以檢測它們預期行為和實際行為之間的不匹配。儘管分析和驗證工具(如下面討論的工具)可能有助於解決這個問題,但使用圖靈完備語言的選擇限制了驗證的可能性。我們預計非圖靈完備、易於閱讀的語言可能會在某些特定應用領域中克服這個問題。最近出現的實驗性語言[31,33,36,38,51]的增多表明,這是一個新興的研究方向。 **Verification of smart contracts:** 近期有一些研究提出了工具,透過靜態分析合約程式碼來偵測漏洞。其中,Oyente [43] 工具會從合約的 EVM bytecode 中提取控制流圖,並對其進行符號執行,以偵測某些漏洞模式。特別是,該工具會考慮導致漏洞的模式,如 "例外錯誤" (例如,未檢查呼叫、發送和委派呼叫的返回值)、"時間限制" (例如,在條件表達式中使用區塊時間戳記)、"不可預測的狀態" 和 "重入攻擊"。 在 [26] 中提出的工具會將智能合約(Solidity 或 EVM bytecode)轉換為函數式語言 F* [53]。然後,在所得到的 F* 代碼上驗證各種性質。特別是,從 Solidity 合約獲得的代碼通過查找特定模式來檢查 "例外混淆" 和 "重入攻擊" 漏洞。從 EVM 獲得的代碼支持低層級分析,例如計算合約函數的 gas consumption。此外,給定一個 Solidity 程序和其聲稱的 EVM bytecode 編譯,該工具驗證這兩個代碼片段具有相等的行為。 這兩種工具都已在以太坊區塊鏈上發布的智能合約上進行實驗。這項大規模分析的結果顯示,安全漏洞非常普遍。例如,[43] 報告說,約有 28% 的分析合約可能包含 "例外錯誤" 漏洞。 [41] 中的工作使用 Isabelle/HOL 證明助手 [47] 驗證了一個特定的合約。更具體地說,分析的目標是由 Ethereum 名稱服務中的 "Deed" 合約的 Solidity 代碼編譯得到的 EVM bytecode。透過 Isabelle/HOL 證明的定理聲明,在調用合約時,只有其擁有者才能減少餘額。 **Low-level attacks:** 此外,除了涉及合約的攻擊之外,Ethereum 網絡本身也成為攻擊者的目標。攻擊利用了 EVM 規範層面的漏洞,並結合 Ethereum 客戶端的安全漏洞。例如,最近的一次拒絕服務攻擊利用了一個 EVM 指令,其在 gas 單位成本方面過低,與其執行所需的計算工作相比 [6]。攻擊者通過該指令向網絡洪水般地攻擊,導致其計算能力大幅降低,並使區塊鏈同步過程變得緩慢。與 DAO 攻擊的恢復類似,也通過分叉區塊鏈來解決這個問題[1, 10]。客戶端實現中的漏洞也可能成為攻擊的原因。最近的一份技術報告[57]分析了 Ethereum 官方客戶端。通過利用區塊傳播算法,他們發現 Ethereum 網絡可以被分成小的節點組:這樣,節點可以被迫接受攻擊者特別創建的區塊序列。 ### [16] [A Survey of Security Vulnerabilities in Ethereum Smart Contracts](https://arxiv.org/abs/2105.06974) 最後更新時間:Fri, 14 May 2021 17:24:34 UTC (3,000 KB) **摘要** 在本研究中,我們回顧現有文獻並廣泛分類區塊鏈應用程序。由於以太坊智能合約主要應用於電子商務應用程序中,我們認為這些應用程序更容易受到攻擊。在這些智能合約中,我們主要集中於識別程序員和智能合約用戶必須避免的漏洞。本文旨在通過分析過去的利用案例情景,解釋八種特定於區塊鏈技術應用層的漏洞。我們還回顧了一些可用的工具和應用程序,以檢測這些漏洞,從其方法和效果方面進行了說明。我們還調查了檢測這些安全漏洞的檢測工具的可用性和缺乏,以識別其中的一些漏洞。 **討論** - 圖1所示的遞歸漏洞統計數據顯示,本文調查的大多數框架和檢測工具,包括Oyente [4]、Mythril [3]、SmartCheck [30]、Vandal [16]、Securify [32]和EthIR [12]等,在智能合約中採用了靜態分析方法來檢測這種漏洞。靜態分析方法可以檢測到為該漏洞定義的模式的存在,但是定義該漏洞的模式也是一個挑戰。該漏洞存在的確認可以更準確地通過來自外部合約到被測試合約的成功遞歸生成交易來概述。只有兩項分析研究工作,ContractFuzzer [23]和Reguard [25],採用了結合靜態和動態分析方法,這被認為是更好的分析方法來檢測該漏洞。 - 圖表[1]顯示,使用靜態分析工具SmartCheck [30]、EthIR [12]、Securify [32],發現智能合約狀態變得不可預測的異常處理例外漏洞最常被識別。然而,使用模糊測試技術生成多個交易場景的ContractFuzzer [23]也成功地檢測到了此漏洞。Call-to-Unknown漏洞被兩個調查的檢測工具[23]、[2]使用結合靜態和動態分析方法檢測到。(見圖表[1])弱字段修改器漏洞僅被一個漏洞檢測工具[30]解決。(見圖表[1])未經檢查的數學漏洞,具體來說是整數下溢/上溢忽略,被兩個檢測工具[24]、[3]檢測到。然而,沒有檢測工具有分析方法來檢測由於Solidity中的類型轉換引起的漏洞。 - **結論** 本文介紹了對以太坊智能合約安全漏洞的分析,這些漏洞的真實世界利用案例以及其預防技術。我們的論文針對區塊鏈2.0應用中的八個安全漏洞,特別是以太坊智能合約。所討論的漏洞位於應用程序層級。因此,預防技術需要在編程層面進行修改。本文提供的研究分析和見解旨在引導未來在該領域的研究,以開發更強大的漏洞檢測工具。我們的分析基於該主題的不斷增長的學術文獻、智能合約程序員的討論論壇和網絡博客。 我: 對嚴重度做分析 加成: - 對程式語言研究,對現有機制研究,目前比較少 ron: 歸類攻擊的類別與成因,找出最近的攻擊是否沒被 cover 到 survey attack 找出原因,看有沒有 paper 跟他相關。 挑選重點以金額排序 --- ## 2023/03/30 下筆前先想這篇研究的 contribution 是甚麼 跟程式漏洞有關的,可以套過往研究的 compiler、linter 來檢測他是否可以被預防的。 從甚麼角度切入一連串攻擊。

    Import from clipboard

    Paste your markdown or webpage here...

    Advanced permission required

    Your current role can only read. Ask the system administrator to acquire write and comment permission.

    This team is disabled

    Sorry, this team is disabled. You can't edit this note.

    This note is locked

    Sorry, only owner can edit this note.

    Reach the limit

    Sorry, you've reached the max length this note can be.
    Please reduce the content or divide it to more notes, thank you!

    Import from Gist

    Import from Snippet

    or

    Export to Snippet

    Are you sure?

    Do you really want to delete this note?
    All users will lose their connection.

    Create a note from template

    Create a note from template

    Oops...
    This template has been removed or transferred.
    Upgrade
    All
    • All
    • Team
    No template.

    Create a template

    Upgrade

    Delete template

    Do you really want to delete this template?
    Turn this template into a regular note and keep its content, versions, and comments.

    This page need refresh

    You have an incompatible client version.
    Refresh to update.
    New version available!
    See releases notes here
    Refresh to enjoy new features.
    Your user state has changed.
    Refresh to load new user state.

    Sign in

    Forgot password

    or

    By clicking below, you agree to our terms of service.

    Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox Sign in with Wallet
    Wallet ( )
    Connect another wallet

    New to HackMD? Sign up

    Help

    • English
    • 中文
    • Français
    • Deutsch
    • 日本語
    • Español
    • Català
    • Ελληνικά
    • Português
    • italiano
    • Türkçe
    • Русский
    • Nederlands
    • hrvatski jezik
    • język polski
    • Українська
    • हिन्दी
    • svenska
    • Esperanto
    • dansk

    Documents

    Help & Tutorial

    How to use Book mode

    Slide Example

    API Docs

    Edit in VSCode

    Install browser extension

    Contacts

    Feedback

    Discord

    Send us email

    Resources

    Releases

    Pricing

    Blog

    Policy

    Terms

    Privacy

    Cheatsheet

    Syntax Example Reference
    # Header Header 基本排版
    - Unordered List
    • Unordered List
    1. Ordered List
    1. Ordered List
    - [ ] Todo List
    • Todo List
    > Blockquote
    Blockquote
    **Bold font** Bold font
    *Italics font* Italics font
    ~~Strikethrough~~ Strikethrough
    19^th^ 19th
    H~2~O H2O
    ++Inserted text++ Inserted text
    ==Marked text== Marked text
    [link text](https:// "title") Link
    ![image alt](https:// "title") Image
    `Code` Code 在筆記中貼入程式碼
    ```javascript
    var i = 0;
    ```
    var i = 0;
    :smile: :smile: Emoji list
    {%youtube youtube_id %} Externals
    $L^aT_eX$ LaTeX
    :::info
    This is a alert area.
    :::

    This is a alert area.

    Versions and GitHub Sync
    Get Full History Access

    • Edit version name
    • Delete

    revision author avatar     named on  

    More Less

    Note content is identical to the latest version.
    Compare
      Choose a version
      No search result
      Version not found
    Sign in to link this note to GitHub
    Learn more
    This note is not linked with GitHub
     

    Feedback

    Submission failed, please try again

    Thanks for your support.

    On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

    Please give us some advice and help us improve HackMD.

     

    Thanks for your feedback

    Remove version name

    Do you want to remove this version name and description?

    Transfer ownership

    Transfer to
      Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

        Link with GitHub

        Please authorize HackMD on GitHub
        • Please sign in to GitHub and install the HackMD app on your GitHub repo.
        • HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.
        Learn more  Sign in to GitHub

        Push the note to GitHub Push to GitHub Pull a file from GitHub

          Authorize again
         

        Choose which file to push to

        Select repo
        Refresh Authorize more repos
        Select branch
        Select file
        Select branch
        Choose version(s) to push
        • Save a new version and push
        • Choose from existing versions
        Include title and tags
        Available push count

        Pull from GitHub

         
        File from GitHub
        File from HackMD

        GitHub Link Settings

        File linked

        Linked by
        File path
        Last synced branch
        Available push count

        Danger Zone

        Unlink
        You will no longer receive notification when GitHub file changes after unlink.

        Syncing

        Push failed

        Push successfully