深入了解The Graph Web3的核心基礎架構—
去年七月首次向外界介紹The Graph時，我們分享了為Web3开發去中心化索引協議的愿景。此後團隊一直兢兢業業，今天我非常高興能夠詳細分享第一版The Graph去中心化網絡的方方面面。The Graph網絡是Web3的核心基礎架構——為去中心化應用提供用戶級體驗的必要組件。
在閱讀本文之前，我假設讀者對The Graph具備基礎的了解。如果您是第一次聽說The Graph，那么我們的公告博客、文檔或來自社區的幾篇佳作是一個很好的入門材料。
全棧去中心化
The Graph的使命是賦能完全由公共基礎架構所驅動的互聯網應用。
全棧去中心化讓應用具備應對商業失敗和尋租的能力，同時帶來前所未有的互操作性。用戶和开發者都清楚知曉他們投入時間和資金打造的軟件不會憑空消失。
為了實現完全去中心化應用（dApp）的愿景，有一點非常關鍵，就是我們要進行一個範式轉移，從為應用正常運行所需的持續存儲、計算和其他服務付費的業務模式，轉變成用戶直接為去中心化服務提供商網絡付費。
目前大多數“去中心化”應用只是在堆棧的最底層（即區塊鏈）採用這種模型，其中用戶對應用狀態進行修改都需要付費。而堆棧的其余部分仍然由中心化業務運營，並且受制於任意故障和尋租問題。
The Graph網絡簡介
The Graph網絡對Web3的查詢層和API層進行了去中心化，消除了dApp开發者目前面臨的取舍難題：到底是开發一個高性能應用，還是开發一個完全去中心化的應用。
目前，开發者可以在自己的基礎架構上運行一個Graph節點，也可以在我們的托管服務上开發一個。其中，开發者構建和部署從Web3數據源提取數據並為其編制索引的子圖。目前已經有許多領先的以太坊項目創建了子圖，包括Uniswap、ENS、DAOstack、Synthetix和Moloch等。在The Graph網絡中，任何索引器都能夠通過抵押Graph代幣（GRT）參與到網絡中，並在提供查詢服務的過程賺取費用和通貨膨脹獎勵。
用戶則按照使用次數進行付費，使用日益增長的索引器，此做法證明了供需規律也適用於該協議提供的服務。
協議角色
與The Graph系統交互的角色有好幾種，他們的恰當參與保證了協議的正常運行，同時也有激勵驅動他們這樣做。
用戶（Comsumer）。用戶向索引器支付查詢費用。他們通常是終端用戶，但也可能是集成The Graph的網絡服務或中間件。
索引器（Indexer）。索引器是The Graph的運行節點。其動力是賺取財務獎勵。
策展人（Curator）。策展人使用GRT代幣來指明哪些子圖值得索引。他們通常是开發者，也可能是支持他們在使用服務的終端用戶，或者純粹出於經濟動機的一種角色。
委托人（Delegator）。委托人向某個Indexer質押GRT代幣，賺取一部分通貨膨脹獎勵和費用，他們無需親自運行一個Graph節點。這類角色主要出於經濟動機。
漁夫（Fisherman）。漁夫們時刻檢查查詢響應是否正確，以此保護網絡。漁夫動機是利他的，因此The Graph將率先為網絡提供漁夫服務。
仲裁員（Arbitrator）。在爭議解決期間，仲裁員決定是否對索引器進行罰沒。他們可能出於經濟或利他動機。
用例
开發者
對开發者來說，構建子圖的API與使用本地或托管Graph節點的API基本相同。
最大的不同之處在於开發者部署子圖的方式。他們不選擇將子圖部署在本地或托管的Graph節點上，而是部署到以太坊托管的注冊表，然後抵押一些GRT對子圖進行策展。這為索引器傳遞了一個信號，表明該子圖也應該被索引。
終端用戶
對於終端用戶，主要區別是他們需要付費查詢索引器的去中心化網絡，而不是與有補貼的中心化API進行交互。這一點是通過他們計算機上運行的查詢引擎（無論是瀏覽器中的插件，或者是內置在dApp中）來實現的。
查詢引擎確保了用戶安全地查詢存儲在The Graph上的大量數據，無需親自處理計算和存儲數據的工作。查詢引擎還充當了交易引擎，根據使用的dApp或用戶偏好，決定選擇哪個索引器，需要支付多少費用等。
查詢引擎為了提供良好的用戶體驗，它將代表用戶自動對小額支付交易進行籤名，而不是每筆交易都需要提示籤名。我們正在與基於以太坊的多個狀態通道團隊進行合作，確保他們的錢包和功能滿足按使用次數進行計價協議的需求（如The Graph）。同時，我們提供了一個允許dApp對用戶查詢進行補貼的網關。
索引器
索引者通過質押GRT代幣，運行一個Graph節點版本參與到The Graph中。
他們還希望運行一個索引器代理，自動化監控索引器資源的使用情況、設置查詢價格、確定對哪些子圖進行索引。索引器代理是可插入式的，並且我們希望節點運營商嘗試使用自己的定價模型和策略，從而在市場上獲得競爭優勢。
策展人和委托人
策展人和委托人通過Graph瀏覽器進行策展和委托。當我們上线網絡後，Graph瀏覽器將成為一個完全去中心化的應用，只需一個支持dApp的瀏覽器和一個以太坊錢包就能使用。
架構
The Graph網絡包含以太坊上的智能合約，以及鏈下運行的各種其他服務和客戶端。
查詢市場
查詢市場的用途與傳統基於雲服務應用的API類似——通過一個運行在用戶設備的前端，有效提供所需的數據。其主要區別是傳統的API有一個經濟實體運營，用戶毫無發言權；而The Graph的查詢市場由去中心化索引器網絡組成，它們彼此競爭，以最低的價格提供最好的服務。
The Graph網絡的這種冗余意味着即使單個索引器宕機，但是只要存在查詢數據的需求，就會激勵其他索引器去完成這些任務。
查詢市場中的交易由處理查詢所需的帶寬和計算資源所決定。
我們來看一下用戶與查詢市場交互的典型流程。
服務發現。用戶詢問The Graph有哪些索引器提供他們感興趣的數據。
索引器選擇。用戶選擇他們認為最有可能以最低價格提供最好服務的索引器。
查詢+限額小額付款。用戶向索引器發送查詢以及限額小額支付，指明他們愿意為計算和帶寬支付的費用。
響應+證明。如果索引器接受用戶的出價，那么他們就會處理查詢請求，返還查詢結果，並證明該響應是正確的。提供了證明後，就會收到用戶的限額小額付款。
這個證明的產生是確定性的，對索引器來說它也是唯一性的（用於驗證目的），爭議解決則由協議的其他板塊負責。
某個去中心化應用查詢The Graph時可利用不同索引器提供的多個子圖，該情況下每個被查詢的子圖都要經歷上述流程。
Graph 代幣
為了支持查詢市場的功能，The Graph協議引入了一種原生代幣：Graph代幣（GRT）。
Graph代幣在協議中主要有兩個用途：
索引器質押。索引器質押Graph代幣，以便自身被查詢市場所發現，同時在執行工作過程中提供經濟安全。
策展人信號。策展人將Graph代幣質押到策展市場中，預測哪些子圖對網絡具備價值，他們因為正確預測而獲得獎勵。
用戶能夠支付ETH或DAI進行查詢。但是最終的結算將以GRT進行，以確保整個協議中使用一種通用的帳戶單位。
此外，持有原生代幣還能夠通過通貨膨脹來激勵特定行為。動態調整通貨膨脹貨幣政策的能力是工具箱中的一個強大手段。
索引器質押
The Graph採用應用型代幣模型，其中索引器必須質押Graph代幣才能在查詢市場上提供服務。該服務的功能主要包括兩方面：
提供經濟安全性。如果索引器做出惡意行為，則面臨着GRT被罰沒的風險。GRT一旦被質押後，只能經過一段解鎖期才能取回，這一點為驗證和解決爭端提供了充足的空間。
提供一個抵抗女巫攻擊的機制。某個特定子圖存在虛假或低質量的索引器會降低查找優質服務商的速度。因此我們只希望發現那些利益相關的索引器。
為了確保上述機制正常運行，有一點非常重要，就是對索引器進行激勵，讓他們持有的GRT與他們為網絡所做出的的貢獻大致相當。
一個最直接的方法是根據質押的GRT，在網絡中為某個索引器分配一定量的任務。但這會帶來兩個問題：首先它為網絡可執行的工作量設定了一個任意上限；其次，該方式幾乎無法進行擴展，因為它要求所有工作都在鏈上進行集中協調。
0x團隊首次提出了一種更好的方法，它對協議中的所有交易收取一定的協議費用，然後根據參與者的質押比例和網絡收入的比例，利用Cobb-Douglas生產函數重新向參與者分配這些費用。
在我們的體系中，索引器i在某段時間獲得的收益Yi為：
其中ωij是索引器i在子圖j上投入的金額，Ω是網絡質押的總量，θij是索引器i在子圖j上為協議產生的協議費，Θ是協議獲得的協議總費用。
我推薦您閱讀這篇論文了解更多內容——但我們發現一點很有趣的是，在平衡狀態下，一個理性決策者能夠根據生產公式，用兩個輸入算出其花費的穩定的大致比例。在我們的情況中，也就是租用或持有GRT的成本與運行一個Graph節點涉及的運營費用，正是這一點決定了一個索引器接到更多任務，從而賺取更多的協議費用。
我們希望所有理性的索引器平衡狀態下能作出相應的預算決策，因此我們期望索引器質押一定比例的GRT，相當於他們在網絡中的任務比例。
該做法的好處在於，協議不需要強制要求它們質押特定比例的代幣，索引器會從最符合自身的經濟利益的角度作出決策。
策展信號
消費者要查詢某個子圖的話，這個子圖必須先建立索引——該過程可能需要幾個小時甚至幾天。如果索引器盲目猜測應該在哪些子圖建立索引，從而賺取查詢費，那么市場就非常低效。
策展人信號是指將GRT質押到某個子圖的聯合曲线，從而為索引器指明該子圖應當被索引的過程。
索引器信任這些信號，因為策展人將GRT質押到聯合曲线，為各個子圖創建策展信號，從而在未來從該子圖賺取部分查詢費用。出於個人利益，理性的策展人應當為子圖質押GRT創建信號，他們期望從中獲取費用。
在聯合曲线（一種價格由函數所決定的算法做市商）中，策展信號越強，GRT和策展的信號之間的匯率就越高。因此，成功的策展人如果認為未來策展費的價格已經回歸價值，便可以立即獲利。同樣，如果他們認為市場對策展信號的價格定價過高，他們可以馬上把GRT提現出來。
這種動態變化意味着對子圖發出的GRT信號應當提供一個持續且有價值的市場信號，它隨着市場對某個子圖上的未來查詢量而改變。
索引器通脹獎勵
將索引器質押以及策展人信號聯系起來的另一種機制是索引器膨脹獎勵。
該獎勵的目的是激勵索引器為還沒有具有大量查詢量的子圖建立索引。該做法有助於解決新子圖的啓動問題，它們在早期可能沒有預先存在的需求來吸引索引器。
它的原理是根據子圖佔總策展信號的比例，對網絡中的每個子圖進行總網絡膨脹獎勵分配。相對應的，該部分分配給所有進行質押的索引器，數量按照它們貢獻的質押比例。
在數學上，索引器i的索引器通脹獎勵為：
其中ωij為索引器i質押到子圖j上的數量，Ωj為質押子圖j上的總量，ψj為分配子圖j的GRT數量，Ψ為網絡中的信號總量，Φ為整個網絡以GRT計價的通脹獎勵。
目前對通貨膨脹率進行動態設置是一個有待探索的領域，但它可能會很低，為個位數。
該機制為索引器對策展人信號提供了額外的激勵，讓策展一種有意義的活動。
從長遠來看，我們希望理性的索引器將GRT質押到子圖上，他們從中獲得通貨膨脹獎勵和查詢費用。但是在網絡啓動早期，有些索引器存在着只進行質押但實際上未在任何子圖上進行索引和服務查詢的動機。
因此，在啓動階段會有一個協議治理設置的索引器監控服務。如果發現某個索引器質押到某個子圖但不提供查詢功能，那么監控服務有權將該索引器加到黑名單中。
由於存在着其他非惡意原因會導致無法提供服務，因此索引器被列入黑名單的唯一懲罰是取消獲得通貨膨脹獎勵的資格，直到從黑名單中移除。被列入黑名單不會對質押的代幣進行罰沒。
Graph瀏覽器以及Graph域名服務
當涉及到有價值的子圖時，為索引器策展子圖才剛剛开始。我們還希望為开發人員展示有價值的子圖。
這是The Graph的核心價值主張之一：幫助开發人員找到有用的可开發數據，讓他們輕易將各種基礎協議和去中心化數據源的數據整合到某一個應用中。
开發者目前可以通過導航到Graph瀏覽器來做到：
在Graph網絡中，Graph瀏覽器是一個基於子圖頂層的dApp，其中子圖能夠對Graph協議的智能合約（元數據，我知道！）進行索引，包括Graph域名服務（GNS，一個子圖的鏈上注冊表）。
子圖是由子圖清單定義的，該清單存儲在IPFS上，不可篡改。不可篡改特性對於具有確定性和可復制性的查詢進行驗證和解決爭端非常重要。GNS允許團隊為子圖添加一個名稱，因此它的角色很重要，然後用戶可以使用該名稱指向連續、無法篡改的子圖“版本”。
這種人性化的名稱以及GNS中存儲的其他元數據，讓Graph瀏覽器的用戶更好地理解子圖的目標和可能的用途，而字母數字字符和已編譯WASM字節碼的隨機字符串則無法做到這一點。
在Graph網絡中，發現有用的子圖更加重要，因為我們會調整子圖的組成。與單純支持dApp在多個單獨的子圖上構建不同，子圖組合還能引入全新的子圖，讓它們直接引用現有子圖中的實體。
讓多個dApp和其他子圖能重復使用相同的子圖是Graph具備的核心效率之一。我們來對比一下現狀，目前每個新的應用都會部署自己的數據庫和API服務器，但他們通常沒有得到充分利用。
限額小額付款
我們的支付層旨盡可能最小化消費者與索引器之間的信任。付款渠道是一項針對可擴展、鏈下、最小化信任付款而开發的技術。它涉及到交易雙方，他們將資金鎖定到鏈上托管，其中資金只能在它們之間進行鏈下的交易，除非提出從托管中提現資金的鏈上交易。
傳統的支付渠道通常強調安全地在鏈下發送小額付款，而不考慮服務或商品實際上是否已經收到。
The Graph在一些數字商品或外包計算微支付的原子交換方面已經取得了一些成果，我們把該架構稱為波浪鎖（WAVE Lock）。波浪代表了任務、證明、驗證和到期時間，其總體設計如下：
-
任務。用戶發送鎖定的小額付款，同時指明需要執行的工作。該項工作即為小額付款的鎖。
-
證明。服務提供商按照用戶請求，返還數字商品或服務以及已正確完成任務的籤名證明。
-
驗證。使用某種方法對上述籤名證明進行驗證。如果無法正確執行任務，可能會存在一些懲罰（如罰沒）。
到期時間。服務提供商必須在小額付款鎖定到期之前收到用戶收據確認，或者在鏈上提交證明，來獲取他們的小額付款。
在付款渠道上進行鎖定並非新鮮事，Lightning和Raiden的論文都探討了通過哈希原象對小額支付進行解鎖。該方法在多hop小額支付中特別有用，其中每個hop都用同一個哈希值鎖定，通過一個原象值解鎖，該數值會在輸入到指定的哈希函數時生成。
雖然我們可以推出自己專門設計嵌入鎖定機制的付款通道方案，但目前使用狀態通道是最實際的。
我們可以將狀態通道看成支付通道，將以太坊等智能合約區塊鏈看成比特幣。他們可以處理簡單的支付場景，也可以編碼更復雜的狀態切換，同時保持着支付通道的可擴展性和安全性。
支付和狀態通道的共同點在於，它們的基本形式是在預先認識的兩個參與方之間進行價值交換或狀態更新。在上文提到的多hop小額付款中，任何兩個參與者之間進行支付都需要在多個其他參與者之間形成一個支付通道鏈，將兩個原始參與方連接起來。
目前有許多不錯的項目正在處理不同形式的Graph遍歷，為任意兩個參與者方提供小額付款。為簡單起見，Graph網絡最初會使用軸輻式（hub and spoke）的結構。
這意味着如果要用The Graph，用戶需要通過狀態通道軸在鏈上开啓一個狀態通道，該通道使用用戶選擇的穩定代幣或ETH。同時索引器也要在軸开通一個狀態通道來接收GRT。
狀態通道軸需要質押GRT並設置付款面額與GRT之間的匯率，讓所有小額付款都以同一單位結算。
驗證
為了確保波浪鎖的構造和索引器質押發揮效果，必須要有一個有效的驗證機制，該機制能夠重現索引器執行的任務、識別故障並懲罰惡意的索引器。
在Graph網絡的第一階段，這一點通過鏈上爭議解決流程來處理，最終結果由仲裁院決定。
漁夫提出爭議、保證金，以及由索引器籤署的證明。如果發現索引器證明了錯誤的查詢響應，則漁夫將獲得一部分罰沒金額作為獎勵。相反，如果爭議不成功，漁夫將會失去保證金。
有一點很重要，就是漁夫的獎勵必須低於罰沒金額。否則，惡意索引器可能（自己舉報自己）大搖大擺繞過解凍期，或者避免被其他人罰沒。
從長遠來看，隨着網絡變得更加可靠，我們預期對活躍漁夫的獎勵將逐漸降低到接近零。因此即使存在着漁夫的獎勵，我們也認為該角色受到利他動機的激勵。
因此The Graph最初有一個漁夫服務，消費者可以在上面發布證明，同時我們將負責驗證查詢響應並在鏈上提交爭議。當然任何希望的人也可以扮演該角色。
此外，協議治理會在網絡初期設置一個仲裁服務，它將充當爭端解決中的唯一仲裁者。這能夠讓我們在軟件漏洞、索引器丟失區塊鏈事件或其他可能導致嚴重攻擊的偶然因素而導致錯誤查詢時做出判斷。
最終，隨着軟件的成熟，索引器會逐漸發展，能夠操作專有技術避免此類錯誤。
未來的工作
The Graph網絡未來的規劃包括探索新的市場機制以及對現有機制進行參數化，讓查詢市場更加動態和高效。後者將涉及對現有機制的設計進行基於代理的動態模擬，以及主網啓動後的分析。
區塊鏈的智能合約通常是支持升級的，因此The Graph協議在啓動後可以進行持續迭代。
從長遠來看，我們希望通過依靠經過驗證的數據結構、共識算法和加密證明最終去掉漁夫和仲裁員兩種角色。The Graph團隊將持續對該領域進行探索，做到高效執行該操作，同時我們在接下來會對此進行更多介紹。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。