Web3 身份驗證指南
作者 Alchemy Team

Web3 認證透過公鑰驗證使用者身分,而非傳統的電子郵件或密碼。這種加密方式雖然免除了集中式密碼資料庫,並讓使用者真正擁有自己的數位憑證,但助記詞、十六進位地址和金鑰管理的複雜性,已對主流採用形成了顯著障礙。近期在內嵌錢包(embedded wallets)、帳戶抽象化(account abstraction)和智能合約帳戶方面的創新,正在解決這些問題。
本指南說明 Web3 認證的運作方式,探討讓其更易於使用的技術方案,並示範如何運用現代 Smart Wallets 基礎架構,實作可供正式環境使用的認證機制。
Web3 認證如何運作?
傳統的網路認證依賴儲存在集中式伺服器上的憑證。使用者輸入使用者名稱和密碼,伺服器查核資料庫,若憑證相符則授予存取權限。這種模式要求使用者將認證資料的信任託付給服務提供者。
Web3 認證顛覆了這種模式。使用者透過連結 web3 錢包來與應用程式進行認證,通常是透過簽署一筆交易。以下是技術流程:
1. 錢包連結
當使用者點選「Connect Wallet」時,應用程式會向使用者的錢包軟體(例如 MetaMask、Phantom 或 Rainbow)發起連結請求。此連結尚未授予任何權限,僅是建立通訊管道。
2. 生成挑戰訊息
應用程式會生成一個獨特的挑戰訊息。這通常是一個隨機的 nonce,或是包含應用程式網域、時間戳記及認證請求目的的格式化訊息。這可防止重放攻擊(replay attack)。
3. 加密簽署
使用者的錢包會使用其私鑰對挑戰訊息進行簽署。私鑰須保密,用於證明對應公鑰的所有權。此簽章可證明使用者掌控與其錢包地址相關的私鑰,同時不會洩露私鑰本身。
4. 簽章驗證
應用程式使用使用者的公鑰(錢包地址)驗證簽章。若簽章有效,應用程式即確認使用者擁有該錢包地址並授予存取權限。此驗證可在用戶端或後端進行,視你的架構而定。
5. 工作階段管理
認證完成後,應用程式通常會發出一個工作階段權杖(session token),供後續請求使用,類似於傳統的網路工作階段。這可避免使用者每個操作都要重新簽署訊息。
其加密基礎讓這個流程在多方面比密碼式認證更為安全。不存在可從資料庫外洩事件中竊取的密碼。網路釣魚攻擊需要誘騙使用者簽署惡意交易,這比竊取密碼更容易被察覺。使用者能掌控自己的認證憑證,而非將其信任託付給集中式提供者。
Web3 認證目前存在哪些問題?
儘管具備加密上的優勢,Web3 認證在使用者體驗上仍存在顯著挑戰,限制了其主流採用。理解這些問題,是打造適用於更廣泛受眾的解決方案的關鍵。
助記詞如何影響使用者體驗?
Web3 要求使用者設置錢包、管理私鑰、儲存助記詞,且經常需要處理雜亂的瀏覽器擴充功能或行動應用程式。使用者必須寫下並妥善保存 12 到 24 個隨機單字的助記詞模式,與主流使用者的期望根本不相容。
資料顯示,35% 的使用者從未備份自己的錢包助記詞,使他們面臨失去資金存取權的重大風險。這並非使用者疏失,而是設計上的問題。多年來,我們都能透過電子郵件找回密碼。而加密貨幣錢包的運作方式不同:一旦遺失助記詞,就沒有重設選項。這是一個值得在開始使用前理解的關鍵差異。
為什麼錢包的使用體驗令人困惑?
在加密貨幣中簽署交易的感覺就像在閱讀使用者授權協議,只是取代法律術語的,是十六進位代碼和原始函式呼叫。當使用者在錢包中點選「Sign」時,他們通常會看到:
- 十六進位格式的原始交易資料
- 以 Gwei 為單位的 gas 費用估算
- 他們不認得的合約地址
- 像
approve\(address,uint256\)這類的函式呼叫

使用者缺乏足夠的背景資訊來判斷這些交易是否合法或惡意。這種資訊不對稱造成了安全漏洞。使用者往往在不了解自己授權內容的情況下點選「Confirm」。
使用者面臨哪些技術障礙?
使用者在能夠嘗試登入之前,就得先面對多個區塊鏈網路、十六進位地址與 gas 費用。想想這樣的認知負擔:
- 網路選擇:該使用 Ethereum mainnet、Polygon、Arbitrum、Base 還是 Optimism?
- 地址管理:理解
0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb代表他們的帳戶 - Gas 費用:僅為了完成認證,就必須持有原生代幣(ETH、MATIC 等)
- 瀏覽器擴充功能:需要安裝並管理獨立的錢包軟體
上述每一項都是導致使用者流失的摩擦點。
錢包分散化如何影響使用者?
許多 Web3 使用者管理多個錢包,各自有獨立的金鑰和助記詞,每個都需要妥善保護。一位使用者可能會有:
- 一個用於 Ethereum 及 EVM 鏈的錢包
- 一個獨立的 Solana wallet
- 針對不同應用程式或使用情境的不同錢包
- 用於存放高價值資產的硬體錢包
管理這種分散狀態需要技術知識和組織紀律,而這是大多數使用者所不具備的。
現行的認證方式帶來哪些安全風險?
智能合約與 DeFi 平台經常成為駭客攻擊的目標,網路釣魚攻擊誘騙使用者洩露私鑰。當以下情況發生時,認證機制本身就成了攻擊面:
- 授權釣魚:使用者在不知情的狀況下簽署了無限額度的代幣授權
- 域名偽造:模仿正版應用程式的假冒網站
- 社交工程:攻擊者冒充客服以取得助記詞
- 惡意合約:使用者與會掏空錢包的合約互動
在 Web3 中,私鑰的安全性至關重要,因為失去私鑰的存取權,可能意味著失去對你數位身分和資產的存取權。這造成了一個高風險的環境,一個失誤就可能帶來災難性後果。
Web3 認證正在如何改善?
鏈上生態系正透過多項技術創新積極應對這些挑戰,在不犧牲安全性或去中心化的前提下,大幅改善認證體驗。

什麼是內嵌錢包?
內嵌錢包直接內建於 Web3 應用程式中,提供熟悉的登入體驗,且不需要記住並保管助記詞。應用程式的錢包功能是直接整合進去的,不需要使用者安裝瀏覽器擴充功能或獨立的錢包應用程式。
透過內嵌錢包,使用者可以選擇用 Google、Apple ID 或 X 帳戶登入,而系統會在背後代為建立一個自我保管(self-custodial)錢包。這種方式帶來幾項關鍵優勢:
熟悉的認證流程
使用者可用自己已經熟悉的方式進行認證:電子郵件、OAuth 或生物辨識。錢包的建立和復原都透過熟悉的認證流程處理,讓使用者無需理解或直接管理私鑰。
免除瀏覽器擴充功能
錢包存在於你應用程式的情境之中。使用者不需要安裝 MetaMask 或任何其他第三方軟體。這消除了主要的導入障礙,並讓你能完全掌控認證體驗。
無縫的使用體驗
由於錢包內嵌在你應用程式的介面中,你能完全掌控外觀、感受和流程,不會出現彈出視窗或重新導向畫面。認證過程與你既有的使用者體驗無縫整合。
社交登入如何實現 Web3 存取?
社交登入整合利用既有的認證提供者,銜接了 Web2 與 Web3 之間的落差。以下說明其技術架構:
透過 MPC 進行金鑰拆分
TSS-MPC,即多方運算門檻簽章方案(Threshold Signature Scheme with Multi-Party Computation),是一種讓多方共同生成單一數位簽章的加密方法,透過在參與方之間分散簽署權限而不向任何單一方洩露私鑰,來提升安全性。
當使用者以 Google 帳戶登入時:
- 你的應用程式透過 OAuth 對使用者進行認證
- 系統生成一組私鑰並將其拆分給多方
- 沒有任何單一方(包括你的應用程式)能取得完整的金鑰
- 交易簽署需要各方達到門檻協作
- 使用者維持自我保管,無需直接管理金鑰
Passkey 認證
Passkeys 是一種免密碼認證方式,其設計比傳統密碼更安全、更方便,並以 WebAuthn 標準為基礎。Passkeys 使用公鑰加密技術,運作方式為:
- 私鑰儲存在使用者裝置的安全隔離區(例如 Apple 的 Secure Enclave 或 Android 的 Trusted Execution Environment)
- 公鑰儲存在你的認證伺服器上
- 與會造成摩擦並帶來釣魚風險的傳統密碼不同,Passkeys 利用使用者熟悉的模式,透過生物辨識來安全地建立並將憑證儲存在使用者裝置上。
這提供了強大的安全性(私鑰永不離開裝置),同時搭配熟悉的使用體驗(FaceID 或 TouchID)。
什麼是帳戶抽象化,為何重要?
帳戶抽象化(ERC-4337)代表鏈上帳戶運作方式的根本轉變。使用帳戶抽象化的智能合約錢包,是以智能合約管理的錢包,而非由單一私鑰管理的錢包。
傳統的 Ethereum 帳戶(外部擁有帳戶,Externally Owned Accounts 或 EOAs)由單一私鑰控制。智能合約帳戶則由程式碼控制,這使其能提供顯著更豐富的功能:
Gas 費用贊助
透過帳戶抽象化,使用者的錢包或帳戶變得可程式化,讓開發者能代為贊助使用者的 gas 費用。這意味著:
- 使用者不需要持有 ETH 就能與你的應用程式互動
- 你可以贊助導入流程的交易以降低摩擦
- 使用者可以用穩定幣或其他 ERC-20 代幣來支付 gas 費用
- 你可以設定要贊助哪些交易的特定政策
批次交易
作為可程式化的 smart account,交易可以被批次執行,大幅簡化使用體驗並降低延遲。使用者可以:
- 在單一筆交易中批准一枚代幣並將其兌換
- 原子化地鑄造 NFT 並將其上架出售
- 執行多步驟的 DeFi 策略,而不需多次錢包確認
社交復原
智能合約帳戶可以實作不依賴助記詞的復原機制:
- 指定信任的聯絡人協助復原你的帳戶
- 使用以電子郵件或電話為基礎的復原流程
- 實作有時間鎖定的帳戶復原程序
可程式化的安全性
由於帳戶本身就是智能合約,你可以實作自訂邏輯:
- 針對高價值交易的多重簽章要求
- 每日或每筆交易的花費上限
- 自動核准的白名單地址
- 針對特定操作的時間限制
Ethereum 共同創辦人 Vitalik 認為,從 EOA過渡到 Smart Wallets,是讓主流使用者上鏈的必要條件。帳戶抽象化不是一項可有可無的功能,而是主流採用的基礎建設。
Passkeys 如何提升認證安全性?
Passkeys 具備多項內建安全優勢。具體來說,與密碼或通行碼不同,使用者不需要記住 passkey 相關的資訊,而這些資訊也無法從使用者身上被釣魚取得。
其安全模型運作如下:
綁定裝置的憑證
私鑰在裝置的安全硬體(Trusted Platform Module、Secure Enclave 等)中生成並儲存,永不離開裝置,消除了透過網路攻擊竊取金鑰的風險。
防釣魚能力
由於 passkeys 綁定於建立它們的網域,因此無法在釣魚網站上使用。即使使用者被誘騙前往假冒網站,passkey 也不會作用,因為網域不相符。
不共用密鑰
與密碼這種使用者和伺服器共享的密鑰不同,passkeys 使用非對稱加密技術。伺服器僅儲存公鑰,即使資料庫遭到入侵,該公鑰對攻擊者也毫無用處。
生物辨識認證
此外,由於 passkeys 綁定於你的 iCloud 或 Google 帳戶,它們受到 Apple 和 Google 安全機制的保護。這提供了:
- 預設的多重要素認證(持有裝置 + 生物辨識)
- 防範 SIM 卡置換攻擊
- 跨裝置備份與同步
有哪些開發者解決方案能讓 Web3 認證變得簡單?
有多家供應商提供基礎架構,以簡化 Web3 認證的實作。以下是你需要了解的相關現況。
有哪些第三方認證提供者可供選擇?
Web3Auth
一個簡單、非託管的認證基礎架構,讓 Web3 錢包與應用程式能為主流使用者和原生 Web3 使用者提供無縫的登入體驗。Web3Auth 支援社交登入、電子郵件認證,並可整合多家錢包提供者。
Magic
提供基於電子郵件的錢包建立方式,並以多方運算進行金鑰管理。Magic 處理金鑰拆分與復原的複雜性,同時為開發者提供簡單的 API。
Dynamic
提供非託管的內嵌錢包,支援社交登入與帳戶抽象化整合。Dynamic 同時提供內嵌錢包及外部錢包連結支援。
Privy
為 EVM、Solana、Bitcoin 等多個鏈上的任何使用者提供硬體級安全、符合 SOC 2 標準的錢包。Privy 專注於企業級安全下的無縫登入體驗,並支援 passkey 和硬體權杖。
Alchemy 的 smart wallet 基礎架構如何運作?
我們打造 Smart Wallets 的目的,是提供垂直整合的錢包和交易基礎架構。你不需要拼湊多項服務,只要一個 SDK 就能取得實作正式環境可用認證機制所需的一切。
用於零摩擦導入流程的內嵌錢包
Smart Wallets 讓你能打造出感覺像 web2、底層卻完全是 web3 的產品。實際上這代表:
使用者可以透過以下方式註冊:
- 電子郵件認證
- 社交登入(Google、Apple、Twitter)
- Passkeys(FaceID、TouchID)
- 自訂認證(自帶你自己的認證方式)
- 供加密原生使用者使用的傳統錢包連結
實作方式相當直接。這份指南能協助你上手。
建立智能合約帳戶
完成認證後,你就能為使用者建立一個智能合約帳戶。我們所有的智能合約帳戶都經過 Quantstamp 審計,並在正式環境中經過超過 3.8 億筆以上交易的實戰驗證:
該智能合約帳戶提供帳戶抽象化的所有優勢——gas 費用贊助、批次交易和可程式化的安全性。
Gas 費用贊助設定
透過可程式化的政策贊助 gas。你可以精確控制要贊助哪些交易,且可使用任何 ERC-20 代幣進行。
透過我們的 dashboard 設定政策:
- 每個錢包或全域的花費上限
- 特定地址的允許清單/封鎖清單
- 贊助特定合約互動
- 設定每日/每月的花費上限
多鏈支援
Smart Wallets 已在超過 30 條鏈上提供支援,包括 Ethereum、Polygon、Base、Optimism、Arbitrum 等。你只需撰寫一次認證邏輯,即可部署到多條鏈上。
正式環境可用的基礎架構
建構於 Alchemy 業界頂尖、可靠的基礎架構之上,讓智能合約錢包的核心功能始終可供使用者使用。我們提供:
- 99.99% 正常運行時間 SLA
- 亞秒級的回應時間
- 自動擴展
- 為企業客戶提供 24/7 支援
Alchemy Smart Wallets 已處理超過 3800 億筆以上交易,是使用量第一的 smart wallet,其應用範圍從小型新創公司到大型企業都涵蓋在內。
你該如何實作 Web3 認證?
根據為數千個應用程式建構認證機制的經驗,以下是在正式環境中有效的模式。
你應該先從社交登入還是 wallet connect 開始?
若應用程式的目標受眾是主流使用者,就從社交登入開始。若目標受眾是加密原生使用者,則兩者都要支援。
- 社交登入優先模式:這種做法能為尚未擁有加密貨幣錢包的新使用者,最大化轉換率。你之後隨時可以為想要完全掌控錢包的使用者,加入「匯出至 MetaMask」的功能。
- Wallet Connect 優先模式:這種做法適用於 DeFi 應用程式、NFT 市集,或其他使用者很可能已經擁有錢包的應用程式。
你應該如何處理 gas 費用?
不要讓使用者在使用你的應用程式之前先購買 ETH。贊助 gas 費用,讓使用者能免費試用你的應用程式,不需要任何 ETH。根據你的商業模式設定贊助政策:
免費增值模式:
- 贊助每位使用者的前 N 筆交易
- 免費層級用完後要求付費或質押
- 監控每個錢包的花費以防範濫用
訂閱模式:
- 為付費訂閱者贊助全部 gas 費用
- 限制免費層級使用者的贊助額度
按交易計費模式:
- 對每筆交易收取手續費
- 將 gas 費用贊助納入交易成本的一部分
設定全域花費上限以控管成本,同時提供流暢的使用體驗。
你應該使用交易批次處理嗎?
只要使用者需要多個操作才能完成一個流程,就應該使用。這些交易會依照陣列中出現的順序依序執行,讓你能夠:
改善使用體驗:
- 一次確認取代多個錢包彈出視窗
- 原子化執行(所有操作全部成功或全部失敗)
- 降低整體 gas 成本
常見模式:
- 批准 + 兌換:讓使用者一鍵完成批准並執行兌換
- 鑄造 + 上架:以原子化方式建立並上架 NFT
- 多代幣操作:在一筆交易中與多個合約互動
你應該如何處理行動裝置使用者?
Dynamic 花費心力優化行動裝置流程,利用 passkeys 讓 FaceID 和 TouchID 登入及建立錢包更容易。行動優先的認證機制至關重要,原因如下:
- 多數使用者是透過行動裝置存取應用程式
- 在行動裝置上,生物辨識認證更容易取得
- 行動端錢包應用程式(MetaMask Mobile、Rainbow)需要 deep linking
行動裝置最佳實務:
- 優先採用 passkeys:FaceID 和 TouchID 提供最佳的行動裝置使用體驗
- 支援 WalletConnect:適用於擁有行動端錢包應用程式的使用者
- 測試 deep linking:確保能順暢轉接至錢包應用程式
- 針對小螢幕設計:認證介面應在 320px 的顯示區域中正常運作
- 減少重新導向:盡可能讓使用者停留在你應用程式的情境中
漸進式揭露又是怎麼一回事?
不要用進階功能讓新使用者感到不知所措。一開始先設計自己的結帳流程,並在背景中簽署交易,再逐步公開更多控制權。
第一階段:隱形錢包
- 僅提供社交登入
- 所有交易自動簽署
- 不顯示任何錢包相關術語
- Gas 費用全額贊助
第二階段:基本控制
- 顯示交易確認
- 讓使用者查看自己的錢包地址
- 顯示交易紀錄
- 說明 gas 費用贊助機制
第三階段:進階功能
- 允許匯出至外部錢包
- 顯示進階交易細節
- 開放手動支付 gas 費用
- 支援硬體錢包簽署
這種做法能在最大化轉換率的同時,仍為進階使用者提供控制權。
Web3 認證的未來會是什麼樣子?
鏈上認證的發展軌跡很清楚:預設隱形,需要時才展現強大功能。
Smart account 會取代 EOA 嗎?
Ethereum 共同創辦人 Vitalik 認為,從 EOA 過渡到 Smart Wallets,是讓主流使用者上鏈的必要條件。這不是臆測——這是技術發展藍圖。
Smart wallets 提供:
- 透過可程式化權限實現更佳的安全性
- 透過 gas 抽象化和批次處理帶來更優異的使用體驗
- 不需助記詞的帳戶復原
- 跨鏈互通性
生態系正朝著以 smart wallets 為預設方向發展。EOA 會為了向後相容性而持續受到支援,但新應用程式應建構於 smart wallet 基礎架構之上。
Chain 抽象化將如何影響認證?
Chain 抽象化解決的問題在於,讓使用者能一次完成註冊,不需要金鑰、復原助記詞或多個錢包。使用者不應該需要知道自己正在使用哪一條鏈。
未來的認證機制將會:
- 在所有鏈上使用相同的帳戶地址
- 抽象化掉特定鏈的細節
- 自動將交易路由至最佳鏈
- 透明地處理跨鏈操作
這需要錢包提供者、橋接服務和應用程式之間的協調,但這些技術基礎目前正在建構中。
生物辨識認證會成為標準嗎?
使用者可以透過 Face ID 或 Touch ID 等生物辨識方式生成一個自我保管的錢包。Passkeys 已獲得 Apple、Google 和 Microsoft 的支援,採用速度正在加快。
在未來 2 到 3 年內,可以預期:
- Passkeys 成為預設的認證方式
- 助記詞僅供有需求的進階使用者使用
- 生物辨識認證涵蓋所有裝置
- 透過 iCloud/Google 帳戶實現無縫同步
AI 將扮演什麼角色?
AI agents 能將混亂的 DeFi 亂象,轉化為無縫、對人類友善的金融體驗,讓加密貨幣不只是技術上可行,而是真正可用。AI 將透過以下方式影響認證:
交易意圖解析:
- 使用者用自然語言描述想做的事
- AI 生成對應的交易
- 使用者只需簡單確認即可批准
詐騙偵測:
- AI 分析交易模式以找出異常
- 在使用者批准可疑交易前提出警示
- 從過往攻擊中學習,以防範新型攻擊
個人化安全性:
- 根據風險等級調整的自適應認證
- AI 推薦的安全設定
- 自動化的安全監控
你今天要如何開始建構?
Web3 的願景與其使用者體驗之間的落差正在迅速縮小。現代認證基礎架構讓我們有可能在不犧牲去中心化或安全性的前提下,導入主流使用者。
我們打造 Smart Wallets,就是為了讓每一位開發者都能輕鬆使用這項技術。你將獲得:
- 支援社交登入和 passkeys 的 embedded wallets
- 具備 gas 費用贊助和批次處理功能的 smart accounts
- 99.99% 正常運行時間的企業級基礎架構
- 涵蓋 EVM 和 Solana 的多鏈支援
數千位開發者運用我們的基礎架構,導入了數百萬名使用者。認證的未來,不在於教導使用者了解區塊鏈的運作方式,而在於打造出直覺到使用者無需思考底層技術的系統。
準備好實作現代化的 Web3 認證了嗎?註冊開發者帳戶,透過文件開始上手,並聯絡我們以取得更多資訊或整合協助。
常見問題
為我的應用程式加入以錢包為基礎的認證,有哪些基本步驟?
整合一個錢包連結流程,讓使用者簽署一則獨特的訊息,在你的後端驗證該簽章,接著建立一個工作階段權杖,讓使用者維持登入狀態,不需要每次請求都重新簽署。
簽署訊息如何證明使用者擁有某個錢包?
應用程式會傳送一則挑戰訊息,只有持有該錢包私鑰的人才能簽署;接著應用程式會用該錢包的公開地址驗證簽章,以確認使用者掌控該地址。
對於 Web3 認證,我應該使用社交登入、錢包登入,還是兩者都用?
對於主流受眾,先從社交登入開始,並可選擇在背後代為建立錢包;而加密原生應用程式通常會優先採用直接的錢包連結,並可能加入社交登入作為備用方案。
使用者以錢包完成認證後,我該如何管理工作階段?
在驗證完已簽署的訊息後,發出一個工作階段權杖或 cookie 供後續 API 請求使用,類似傳統的網路工作階段,讓使用者不需要每個操作都重新簽署。
什麼是內嵌錢包,它們如何改善認證體驗?
內嵌錢包直接內建於應用程式中,讓使用者能以 Google 或 Apple ID 等熟悉方式進行認證,同時系統會在背後建立一個自我保管的錢包。這消除了瀏覽器擴充功能或助記詞管理的需求。
Passkeys 如何讓 Web3 認證更安全?
Passkeys 使用綁定於裝置的憑證,儲存在永不離開裝置的安全硬體中,能抵禦網路釣魚攻擊,並提供生物辨識認證,而不需與伺服器共享密鑰。
什麼是帳戶抽象化,它對認證為何重要?
帳戶抽象化讓智能合約帳戶得以贊助 gas 費用、批次處理交易,並實作如社交復原等可程式化的安全功能,消除了許多阻礙主流採用的障礙。
我應該為使用者認證贊助 gas 費用嗎?
應該。贊助 gas 費用能消除尚未擁有加密貨幣的新使用者所面臨的一大障礙,讓他們不需要先購買 ETH 就能試用你的應用程式。
相關總覽
錢包2026年9月2日
代理錢包:AI 代理的工作階段與權限模型
AI 代理如何在不持有私鑰的情況下,取得範圍受限、可撤銷的錢包存取權限:工作階段、委派簽署與即時撤銷。
錢包2026年7月29日
別再把私鑰貼進 Cursor:如何為你的 coding agent 建立錢包
為你的 coding agent 建立錢包,但不用把私鑰交給它。了解 Alchemy CLI agent wallets 如何透過限定範圍的 session,讓 agent 在 .env 中沒有私鑰的情況下完成交易。
錢包2026年6月24日
什麼是加密貨幣 Bundler?
加密貨幣 Bundler 會將多筆交易或操作合併為一次鏈上提交,涵蓋批次處理、MEV、rollups、代幣發行與帳戶抽象化等場景。

打造區塊鏈魔法
Alchemy 結合最強大的 Web3 開發者產品與工具,並提供資源、社群與卓越的支援。