ABI（應用程式二進位介面）

什麼是加密貨幣中的 ABI？

ABI 是 Application Binary Interface（應用程式二進位介面）的縮寫。在加密貨幣領域，ABI 通常指一種標準格式，讓錢包、去中心化應用程式、指令碼及智能合約能理解如何與區塊鏈上的智能合約互動。

ABI 就像智能合約通訊時使用的易讀說明手冊。

它會告訴軟體合約包含哪些函式、各函式需要哪些輸入、會傳回哪些輸出、合約能發出哪些事件，以及資料在送上鏈前應如何編碼。

Solidity 官方文件將合約 ABI 描述為 Ethereum 生態系中與合約互動的標準方式，適用於區塊鏈外部與合約彼此之間的互動。

您可以參閱Solidity 合約 ABI 規格中的技術資料。

簡單來說，ABI 是人類可讀的智能合約程式碼與機器可讀的區塊鏈交易資料之間的橋梁。

如果沒有 ABI，使用者介面即使知道合約地址，也可能不知道應提供哪些按鈕、表單、輸入欄位或函式呼叫。

對加密貨幣使用者來說，ABI 很重要，因為它能協助 dApp 顯示合約操作，例如轉帳、核准、質押、鑄造、領取、存入、提領、投票或兌換。

對開發者而言，ABI 能讓智能合約呼叫具備可預測性、結構化與可重複使用的特性，並適用於不同錢包、函式庫、區塊鏈瀏覽器及後端服務。

ABI 對智能合約為何重要

智能合約是存放在區塊鏈地址上的程式，使用者必須傳送格式正確的交易資料才能與其互動。

Ethereum 說明，智能合約是在某個地址執行的程式，內含資料與函式，並會在收到交易時執行。

您可以閱讀 Ethereum 的智能合約結構指南中的官方說明。

區塊鏈本身不需要精美的使用者介面才能執行函式。

它只需要符合使用者欲呼叫函式的正確編碼資料。

ABI 能協助軟體正確建立這些編碼資料。

例如，代幣合約可能包含轉帳函式，並要求提供收款地址與數量。

ABI 會告訴錢包或應用程式該函式存在、第一個輸入值應為地址，第二個輸入值則應為無號整數。

接著，應用程式便能建立合約可理解的交易。

因此，ABI 是加密貨幣使用者介面背後最重要的概念之一。

ABI 的運作方式

ABI 會以結構化格式定義智能合約的外部介面。

大多數 Ethereum 類型的 ABI 都以 JSON 陣列撰寫。

陣列中的每個物件都會描述一種合約項目，例如函式、建構子、事件、receive 函式、fallback 函式或自訂錯誤。

函式的 ABI 可包含函式名稱、輸入類型、輸出類型及狀態可變性。

狀態可變性描述函式是讀取資料、變更資料、接收原生幣，或具有其他執行行為。

事件的 ABI 可包含事件名稱、索引欄位、非索引欄位，以及事件是否為匿名事件。

自訂錯誤的 ABI 可包含錯誤名稱及參數，用來說明交易撤銷的原因。

這項結構化描述可讓鏈下軟體將易懂的指令轉換成低階呼叫資料。

軟體也能將低階傳回資料與事件日誌解碼，轉換成人類看得懂的資訊。

ABI 編碼

ABI 編碼是將函式呼叫及參數轉換為 Ethereum 虛擬機器（EVM）可理解二進位資料的過程。

Solidity ABI 規格說明，ABI 資料會依照型別編碼，而且編碼本身不會自我描述，因此需要結構定義才能解碼。

這項結構定義就是 ABI。

這一點非常重要，因為原始交易資料無法清楚說明自身含義。

一串十六進位資料可能代表代幣轉帳、流動性存入、NFT 鑄造或治理投票。

ABI 能協助軟體正確解讀這些資料。

使用者在 dApp 中點選按鈕時，應用程式會使用 ABI，將選取的函式及其參數編碼。

接著，錢包會顯示交易請求；如果內容看起來正確，使用者便可簽署。

交易送出後，區塊鏈會對合約執行已編碼的指令。

許多日常加密貨幣操作，就是透過這個流程從網頁轉化為實際的鏈上交易。

函式選擇器

函式選擇器是編碼資料的前 4 個位元組，用來識別應呼叫哪個智能合約函式。

在 Ethereum 類型的合約中，函式選擇器是由標準函式簽章的 Keccak-256 雜湊值產生。

標準函式簽章包含函式名稱與參數類型，例如 transfer(address,uint256)。

ABI 可協助軟體取得這個簽章並建立正確的呼叫資料。

例如，代幣轉帳不會將「轉移這個代幣」這幾個字傳送至區塊鏈。

它會傳送精簡的十六進位資料，其中以函式選擇器開頭，後續則是編碼後的參數。

接收合約會讀取選擇器，並將執行流程導向對應函式。

如果選擇器不符合任何可用函式，合約可能會呼叫 fallback 函式，或拒絕該呼叫。

這套系統讓智能合約互動更有效率，但也使 ABI 成為以人類可讀方式解讀資料的關鍵。

ABI 與合約地址

合約地址會告訴軟體智能合約在鏈上的位置。

ABI 則會告訴軟體如何與該合約溝通。

若要提供良好的使用者體驗，通常兩者都不可或缺。

如果開發者只有地址，仍可傳送原始交易資料，但可能不容易知道合約提供哪些函式。

如果開發者只有 ABI，卻沒有地址，就只知道介面，無從得知要呼叫哪個已部署的合約。

合約地址與 ABI 搭配使用，便能讓應用程式在常見的 Web3 函式庫中建立合約實例。

接著，該合約實例便可用來呼叫讀取函式、估算 Gas 費、準備交易及監聽事件。

因此，許多開發者教學在示範如何與已部署合約互動前，都會要求先提供地址和 ABI。

ABI 與讀取函式

讀取函式是能擷取資訊而不變更區塊鏈狀態的智能合約函式。

在 Solidity 中，這些函式通常標記為 view 或 pure。

dApp 可利用 ABI 呼叫讀取函式，並顯示代幣餘額、總供應量、所有者地址、質押倉位、資金池參數或治理提案詳細資訊等資料。

讀取呼叫通常透過節點 RPC 方法處理；如果只是透過節點在本機查詢資料，使用者通常不必支付 Gas 費。

Ethereum 的 JSON-RPC 文件說明，應用程式如何透過標準化 RPC 方法與 Ethereum 節點通訊。

您可以參閱Ethereum JSON-RPC API 文件中的官方參考資料。

ABI 可協助應用程式編碼讀取請求，並解碼傳回的回應。

如果沒有 ABI，回應可能只會以原始十六進位資料呈現。

ABI 與寫入函式

寫入函式是能變更區塊鏈狀態的智能合約函式。

常見操作包括轉移代幣、核准代幣支出、鑄造資產、領取獎勵、質押幣、建立提案或變更協議設定。

由於寫入函式會變更狀態，通常需要已簽署的交易及網路手續費。

ABI 能協助錢包或 dApp 為函式呼叫準備正確的交易資料。

使用者簽署交易後，錢包會將交易廣播至區塊鏈網路。

驗證者會在交易有效且已支付適當費用時，將交易納入區塊。

ABI 不會判斷交易是否安全或能否獲利。

它只會描述合約預期的呼叫結構。

使用者仍須確認自己簽署的內容，尤其是在核准代幣額度或與不熟悉的合約互動時。

ABI 與事件

事件是智能合約發出的訊號，可協助應用程式追蹤交易中發生的事。

例如，代幣合約可能會在代幣從一個地址轉移至另一個地址時發出 Transfer 事件。

借貸合約可能會在使用者存入、借出、償還或提領資產時發出事件。

NFT 合約可能會在代幣鑄造、轉移或核准時發出事件。

ABI 會描述事件名稱與參數類型，讓軟體將日誌解碼成易讀紀錄。

這很重要，因為錢包、儀表板、分析工具、索引器及投資組合追蹤工具都廣泛使用區塊鏈日誌。

事件不只對人類有用。

事件也能協助後端系統追蹤活動，而不必直接讀取每一次內部儲存資料的變化。

在加密貨幣領域，許多使用者餘額、紀錄及分析介面都仰賴正確解碼的事件資料。

ABI 與代幣標準

代幣標準高度仰賴可預期的介面。

例如，可替代代幣合約通常採用 totalSupply、balanceOf、transfer、allowance、approve 及 transferFrom 等標準函式。

ERC-20 標準為 Ethereum 類型網路上的可替代代幣定義了一套通用介面。

您可以直接參閱EIP-20 代幣標準。

由於許多代幣共用標準函式名稱與參數類型，錢包及 dApp 更容易支援這些代幣。

ABI 讓這種支援方式得以實現，因為軟體可以呼叫預期函式並解碼預期事件。

非同質化代幣標準與多代幣標準同樣仰賴定義好的介面。

這也是加密貨幣生態系能建立可重複使用的錢包、市場、區塊鏈瀏覽器及分析工具的原因之一。

標準化介面可減少客製整合工作，並提升不同應用程式之間的互通性。

ABI 與 ERC-165 介面偵測

ABI 會告訴軟體如何與合約互動，但有些合約也支援介面偵測。

ERC-165 是一項標準，讓合約能宣告自己是否支援特定介面。

ERC-165 官方提案指出，該標準統一了介面概念及介面識別方式。

您可以參閱ERC-165 標準介面偵測。

這項功能很重要，因為應用程式可能需要確認合約是否支援特定代幣標準或功能集。

例如，NFT 應用程式可能會先確認合約是否支援特定 NFT 介面，再顯示進階功能。

ABI 與 ERC-165 彼此相關，但並不是同一回事。

ABI 描述可呼叫的函式與事件；ERC-165 則提供標準方法，讓使用者在執行期間檢查支援的介面。

ABI JSON 格式

最常見的 ABI 格式是由智能合約編譯器產生的 JSON 檔案或 JSON 陣列。

一般 ABI 項目會包含 type、name、inputs、outputs、stateMutability 及 anonymous 等欄位。

type 欄位用來識別 ABI 項目是函式、事件、建構子、receive 函式、fallback 函式或錯誤。

inputs 欄位會列出合約預期收到的參數。

outputs 欄位會列出合約傳回的值。

stateMutability 欄位會說明函式是 view、pure、payable 或 nonpayable。

anonymous 欄位適用於事件，並會影響事件的記錄方式。

開發者函式庫也可能支援易讀的 ABI 格式，以方便使用。

例如，ethers.js 在其ABI 文件中說明了數種表示 ABI 片段的方式。

dApp 中的 ABI

去中心化應用程式會透過 ABI 將前端連接至智能合約。

前端看起來可能像一般網站，但其中的按鈕通常會觸發合約讀取或寫入操作。

使用者開啟質押頁面時，應用程式可能會使用 ABI 讀取使用者目前的質押餘額。

使用者點選質押按鈕時，應用程式可能會使用 ABI 編碼質押交易。

交易完成後，應用程式可能會使用事件 ABI 更新畫面上的活動紀錄。

這類流程常見於去中心化金融、NFT、遊戲、去中心化身分、治理及鏈上獎勵。

因此，ABI 是使用者體驗中隱而不顯、卻不可或缺的一環。

大多數使用者不會直接看到 ABI，但每當 dApp 以易懂方式顯示合約函式時，背後都仰賴 ABI。

錢包中的 ABI

錢包會運用 ABI 資訊，向使用者顯示交易可能執行的操作。

能解碼交易資料的錢包，可能會顯示函式名稱與參數，而不只是原始十六進位資料。

這能提升簽署安全性，因為使用者可以更了解自己是在核准代幣、轉移資產、鑄造 NFT，還是與合約模組互動。

不過，解碼資料的可靠性取決於 ABI 本身及錢包的解讀方式。

即使錢包提示尚未出現，惡意介面仍可能誤導使用者。

難以理解的合約也可能讓函式看起來無害，實際上卻會造成意料之外的結果。

使用者應將 ABI 解碼視為有幫助的安全防護層，而非完整保障。

進行高價值交易時，使用者應在簽署前確認合約、函式、收款者、代幣數量及核准範圍。

區塊鏈瀏覽器中的 ABI

區塊鏈瀏覽器經常使用 ABI，讓合約頁面更容易閱讀。

合約經過驗證後，區塊鏈瀏覽器便能顯示易讀的合約函式、解碼後的交易及事件日誌。

這有助使用者檢視代幣轉帳、智能合約呼叫、所有權設定、代理合約關係及治理活動。

如果沒有 ABI 資訊，區塊鏈瀏覽器可能只會顯示原始輸入資料與低階日誌。

這些原始資料對進階研究者仍有用處，但多數使用者較難理解。

ABI 也能協助稽核人員、分析師及社群成員檢視協議在鏈上的運作方式。

在加密貨幣領域，透明度不只仰賴公開資料，也仰賴能正確解碼公開資料的工具。

ABI 是讓區塊鏈透明度實際發揮作用的關鍵工具之一。

ABI 與合約驗證

合約驗證是比對已部署位元組碼與公開原始碼及編譯器設定的過程。

智能合約完成驗證後，使用者通常可以一併檢視原始碼與 ABI。

這有助於提升信任，因為使用者能確認 ABI 是否符合合約實際編譯出的介面。

合約驗證並不會自動讓合約變得安全。

已驗證的合約仍可能包含錯誤、不當權限、高風險升級控制或有害邏輯。

不過，相較於未經驗證的合約，驗證能讓使用者及研究者取得更多資訊。

驗證後，ABI 尤其有用，因為介面與區塊鏈瀏覽器能以結構化方式顯示合約互動。

情況允許時，使用者應優先選擇已驗證的合約，但仍須檢查權限、稽核結果、所有權及鏈上行為。

ABI 與位元組碼

ABI 與位元組碼密切相關，但兩者截然不同。

位元組碼是編譯後的機器層級程式碼，會在區塊鏈虛擬機器上執行。

ABI 則是介面說明，告訴軟體如何從外部呼叫這些位元組碼。

即使 ABI 未公開，智能合約仍可能以位元組碼形式存在於鏈上。

在這種情況下，進階使用者仍可手動建立呼叫資料，與合約互動。

大多數使用者與應用程式都需要 ABI，才能方便且安全地互動。

位元組碼是區塊鏈實際執行的內容。

ABI 則是外部工具用來理解如何與這些可執行程式碼溝通的方式。

ABI 與代理合約

代理合約會讓 ABI 的使用更加複雜。

代理合約會將呼叫轉送至另一個包含主要邏輯的合約。

這種模式常用於可升級智能合約。

代理合約地址可能維持不變，但實作合約會變更。

在這種架構中，使用者可能需要的是實作合約的 ABI，而不只是代理合約的基本 ABI。

如果使用錯誤的 ABI，介面可能會顯示缺少函式、錯誤函式或令人困惑的交易資料。

因此，許多區塊鏈瀏覽器及開發者工具都會嘗試偵測代理合約關係。

對使用者而言，可升級合約需要特別留意，因為若治理或管理員權限允許升級，合約邏輯就可能變更。

ABI 與自訂錯誤

現代 Solidity 合約可以使用自訂錯誤，說明交易撤銷的原因。

在許多情況下，自訂錯誤比冗長的撤銷字串更節省 Gas 費。

ABI 可以包含自訂錯誤定義，讓工具將撤銷資料解碼成易懂的說明。

例如，失敗的交易可能傳回錯誤，指出呼叫者未獲授權，或輸入數量過低。

如果沒有 ABI 支援，使用者可能只會看到令人困惑的十六進位錯誤值。

解碼後的自訂錯誤能協助開發者偵錯合約，也有助使用者了解交易失敗的原因。

這再次說明 ABI 如何提升區塊鏈系統的易用性。

更完善的解碼無法消除風險，但有助使用者了解發生了什麼事。

ABI 的安全風險

ABI 本身通常不是智能合約風險的來源，但錯誤或具誤導性的 ABI 資訊可能造成嚴重混淆。

偽造的 ABI 可能讓合約互動看起來與實際操作不同。

過時的 ABI 可能隱藏新函式，或顯示已不符合目前部署版本的舊行為。

不完整的 ABI 可能導致使用者看不到所有可用函式或事件。

惡意 dApp 可能使用正確 ABI，卻呈現誤導性的使用者介面。

如果代理合約的實作隨時間變更，也可能讓 ABI 解讀更加困難。

使用者不應以為易讀的函式名稱就代表交易安全。

使用者應確認合約地址、查閱可信來源、仔細閱讀錢包提示、限制代幣核准權限，並避免簽署自己不了解的交易。

ABI 的常見用途

開發者使用 ABI 建立能呼叫智能合約函式的 dApp。

錢包使用 ABI 解碼交易請求，讓簽署內容更加清楚。

區塊鏈瀏覽器使用 ABI 顯示易讀的合約呼叫與事件日誌。

索引器使用 ABI 蒐集並整理鏈上資料，以供分析使用。

稽核人員使用 ABI 了解合約的外部介面並測試互動。

交易機器人與自動化指令碼使用 ABI，以程式化方式呼叫合約函式。

治理儀表板使用 ABI 讀取提案、投票、法定人數設定及執行狀態。

投資組合工具使用 ABI 讀取餘額、倉位、獎勵及歷史活動。

在上述各種情況中，ABI 都能讓智能合約資料更容易編碼、解碼、顯示及使用。

白話說明 ABI 範例

想像一台只能接受特定按鈕代碼的自動販賣機。

這台機器可能支援購買零食、查看庫存、補充商品及收取款項等操作。

一般人不會想親手傳送機器層級的二進位指令。

他們需要的是清楚的選單，列出可用操作及所需輸入資料。

ABI 在智能合約中扮演類似的角色。

它會告訴軟體有哪些操作，以及每項操作需要哪些資訊。

接著，軟體便能將使用者的選擇轉換成合約預期的精確編碼資料。

因此，ABI 常被稱為合約的通訊介面。

ABI 與 API 的差異

ABI 和 API 聽起來相似，但兩者並不相同。

API 是 Application Programming Interface（應用程式介面）的縮寫，通常描述軟體系統如何以較高層級進行通訊。

ABI 是 Application Binary Interface（應用程式二進位介面）的縮寫，描述軟體如何在二進位資料層級進行通訊。

在加密貨幣領域，API 可能讓應用程式向服務請求代幣價格、餘額或交易紀錄。

ABI 則讓應用程式能對直接的智能合約互動進行編碼與解碼。

dApp 可能同時使用 API 與 ABI。

例如，dApp 可能透過 API 取得市場資料，並使用 ABI 建立鏈上質押交易。

API 協助處理資訊流通，ABI 則協助執行合約與解碼資料。

如何取得合約 ABI

開發者通常會從智能合約編譯器的輸出取得 ABI。

編譯 Solidity 合約時，編譯器可以同時產生位元組碼與 ABI 資料。

位元組碼會部署至區塊鏈。

ABI 則會儲存起來，供需要與已部署合約互動的應用程式使用。

使用者也可以在已驗證的合約頁面、官方專案程式碼儲存庫、開發者文件或套件版本中找到 ABI。

通常最安全的來源是官方專案文件，或與確切地址及網路相符的已驗證合約紀錄。

從不明網站、聊天內容或未經驗證的來源複製 ABI 檔案時，使用者應格外謹慎。

錯誤的 ABI 可能導致交易失敗、顯示內容誤導或資料解碼錯誤。

開發者如何使用 ABI

開發者通常會將 ABI 匯入 Web3 函式庫，並與合約地址一併使用。

接著，函式庫會建立合約物件，其中包含與 ABI 相符、可供呼叫的函式。

開發者可透過該物件讀取合約狀態、傳送交易、估算 Gas 費及監聽事件。

這種工作流程常見於 JavaScript、TypeScript、Python、Rust、Go 及其他區塊鏈開發環境。

開發者也會在測試中使用 ABI，確認合約是否正常運作。

後端服務會使用 ABI 監控事件，並在鏈上活動發生時更新資料庫。

前端應用程式則會使用 ABI 呈現按鈕、表單及交易提示。

在正式環境中，ABI 版本控管很重要，因為合約升級可能會改變可用函式與事件。

常見 ABI 錯誤

常見錯誤之一是使用錯誤合約版本的 ABI。

另一個常見錯誤是 ABI 正確，但合約地址錯誤。

第三個錯誤是在某條網路上的合約互動中，使用另一條網路的 ABI。

第四個錯誤是忽略代理合約，在需要實作合約 ABI 時卻使用代理合約 ABI。

第五個錯誤是沒有確認實際的錢包提示，就盲目相信使用者介面。

第六個錯誤是以為解碼後的函式名稱能完整說明合約可能執行的所有內部操作。

第七個錯誤是不了解獲核准的合約能執行哪些操作，就授予無限額代幣支出權限。

這些錯誤顯示，即使不是開發者，了解 ABI 仍然很有用。

ABI 為何與加密貨幣安全有關

了解 ABI 有助使用者理解錢包及 dApp 顯示的內容。

錢包顯示已解碼的函式時，解碼流程通常會用到 ABI。

了解 ABI 的使用者更容易明白，為何合約互動有時會以原始資料呈現。

當合法合約難以解碼時，這有助於減少不必要的疑慮。

如果交易提示顯示危險的核准權限或不熟悉的函式，也能提高使用者的警覺。

在去中心化金融中，許多操作都涉及智能合約權限，因此了解 ABI 特別有用。

使用者應特別留意核准、操作員、委派呼叫、可升級合約及具有管理員控制權的合約。

ABI 有助揭露互動介面，但安全性仍取決於程式碼品質、權限、稽核及使用者判斷。

常見問題

加密貨幣中的 ABI 是什麼意思？

ABI 是 Application Binary Interface（應用程式二進位介面）的縮寫，用來描述軟體應如何編碼、呼叫及解碼智能合約函式與事件。

ABI 有什麼用途？

錢包、dApp、指令碼、區塊鏈瀏覽器及開發者工具會使用 ABI，以結構化方式與智能合約互動。

ABI 等同於智能合約嗎？

不等同。智能合約是鏈上程式；ABI 則是介面說明，告訴軟體如何與該程式溝通。

ABI 等同於位元組碼嗎？

不等同。位元組碼是可執行的合約程式碼；ABI 則是用來編碼及解碼與該程式碼互動的易讀介面格式。

dApp 為什麼需要 ABI？

dApp 需要 ABI，才能顯示合約函式、收集使用者輸入、建立交易資料、呼叫讀取函式及解碼合約回應。

合約沒有公開 ABI 也能運作嗎？

可以。合約即使沒有公開 ABI 仍能運作，但大多數使用者及應用程式需要 ABI，才能方便且安全地與合約互動。

在哪裡可以找到合約 ABI？

通常可在編譯器輸出、官方專案程式碼儲存庫、開發者文件，或區塊鏈瀏覽器上的已驗證合約頁面找到 ABI。

ABI 可能是假造的嗎？

可能。如果來源不可信，ABI 可能有誤、過時、不完整或具誤導性。

ABI 能保護使用者免於詐騙嗎？

不能。ABI 有助於解碼合約互動，但無法證明合約安全、已通過稽核或值得信任。

為什麼我的錢包會顯示原始十六進位資料？

如果錢包沒有合約互動所需的正確 ABI 或解碼資訊，就可能顯示原始十六進位資料。

什麼是 ABI 編碼？

ABI 編碼是將函式名稱與參數轉換為智能合約可理解的二進位格式的過程。

什麼是 ABI 解碼？

ABI 解碼是將原始區塊鏈資料轉換回易讀的函式呼叫、傳回值、事件或錯誤的過程。

結論

ABI 是智能合約生態系中最重要的底層組件之一。

它讓錢包、dApp、開發者工具、區塊鏈瀏覽器及分析系統能理解如何與智能合約溝通。

對新手來說，可以把 ABI 想成合約的說明手冊，其中列出可呼叫函式、預期輸入、輸出、事件及錯誤。

對開發者而言，ABI 是結構化介面，讓合約整合、測試、監控及自動化成為可能。

對一般加密貨幣使用者而言，ABI 很重要，因為它能協助錢包及應用程式將原始區塊鏈資料轉換成易讀操作。

正確的 ABI 能讓智能合約互動更清楚、安全且容易理解。

錯誤或具誤導性的 ABI 則可能造成混淆，並提高交易風險。

最佳做法是使用官方或已驗證來源提供的 ABI、仔細核對合約地址、閱讀錢包提示，並避免簽署內容不清楚的交易。

在加密貨幣領域，ABI 本身並不是合約，而是協助人類與軟體正確和合約溝通的語言指南。