先驗人，再發幣？Base 空投提上日程？

By: rootdata|2026/07/29 09:03:32

設為Google首選來源

SIGN

ONE

空投農場要失靈了？Base 為鏈上應用加上「真人驗證」。

撰文：KarenZ，Foresight News

區塊鏈可以記錄每個錢包的行為，卻無法僅憑地址判斷：十個錢包背後究竟是十個人，還是同一個人。

這在普通轉帳中不是問題，但到了空投、獎勵領取或社區投票環節，就會變成一道難題：規則寫著「每人一次」，智能合約實際能夠識別的卻只有「每個地址一次」。只要不斷更換錢包，同一個人就可能重複參與。

7 月 28 日晚，Base 開發者官方帳號 Base Build 宣布推出 Base Verify Onchain。這項功能試圖解決上述難題：應用可以將「同一經過驗證的身份只能參與一次」以及「只有滿足特定條件的用戶才能參與」等規則寫入智能合約。目前，Base Verify Onchain 運行於 Base Sepolia 測試網。

Base Verify Onchain 是什麼？

簡單來說，Base Verify Onchain 是一套將鏈下身份資格與鏈上合約規則連接起來的驗證機制。

它不是讓智能合約直接訪問用戶的 X、Instagram、TikTok 或 Coinbase 帳號，而是由 Base Verify 的鏈下服務先判斷用戶是否滿足條件，再簽發一份短期有效的驗證結果；智能合約隨後在鏈上核驗這份結果，並決定是否允許用戶領取、存款、鑄造或投票。

完整流程可以分為四步。

第一步，開發者在智能合約中預先寫明資格規則，即一個憑據提供方 provider 和一項或多項條件 conditions。例如，應用可以要求用戶擁有已認證的 X 帳號、X 粉絲數達到一定門檻，或者擁有有效的 Coinbase One 會員資格。

第二步，用戶連接錢包，並簽署一條指向該應用合約的 SIWE（Sign-In with Ethereum）消息。應用將消息及錢包簽名發送給 Base Verify API。

第三步，Base Verify 的鏈下服務首先驗證用戶簽署的 SIWE 消息，並從簽名中恢復出簽名錢包地址；隨後，它讀取消息所指向合約預先設定的 provider 和 conditions，再將這些條件與該錢包在 Base Verify 中保存的已驗證憑據進行比對。只有用戶滿足全部條件時，Base Verify 才會簽發一份短期有效的 EIP-712 驗證，並向應用返回哈希值（identityHash）、到期時間和驗證簽名。其中，這個哈希值是用於識別和去重同一經過驗證身份的單向哈希。

最後，應用將這三項數據提交給智能合約。合約檢查簽名是否來自受信任的簽名方、驗證是否已經過期，以及該驗證是否與當前鏈、合約和資格規則相匹配。檢查通過後，應用合約再查詢 identityHash 是否已經使用過：如果同一經過驗證的身份此前已經參與，即使這次換了另一個錢包，也會得到相同的 identityHash，從而被合約拒絕。

這裡需要分清兩個環節：用戶是否滿足資格條件，由 Base Verify 的鏈下服務判斷；簽名是否有效、是否過期、是否對應當前合約規則，以及該身份是否重複參與，則由鏈上合約檢查。用戶的社交帳號名稱、粉絲數據或會員資料不會因此直接寫入鏈上。

identityHash 也不是一串可以在所有應用中追蹤用戶的統一身份編號。它同時取決於經過驗證的身份和應用合約：同一身份在同一合約中更換錢包，生成的哈希保持一致；進入另一個合約時，哈希則會改變。因此，不同應用不能僅憑 identityHash 直接關聯同一名用戶。

它解決的是資格執行，不是萬能身份系統

Base Verify Onchain 解決的核心問題，是如何讓智能合約可靠執行「誰可以參加」和「同一身份能參加幾次」?

它適用於規則明確的鏈上場景，例如一人只能領取一次的空投、限定特定用戶參加的獎勵活動，以及需要減少多錢包干擾的投票、鑄造、存款或申領流程。官方測試頁面目前展示了兩種示例：用戶可以通過「有效的 Coinbase One 會員」或「已認證的 X 帳號」完成驗證，並在 Base Sepolia 上領取一次測試空投。

需要提醒的是，Base Verify Onchain 並不是一套能夠證明用戶姓名、國籍或其他法律身份的通用身份系統，也不是 KYC。驗證成功只能說明：某個經過驗證的身份滿足合約預先設定的條件。合約既不會因此知道用戶具體是誰，也不應據此推斷用戶的個人資料。