Tea.xyz：可用於激勵開源生態系統的去中心化協議

本協議旨在為所有開源軟體創建開放的、公共的和穩定的註冊表，使得項目能夠獨立發布版本，而不再依賴第三方，將這些不規則的數據集合到數百個獨立（和重複）的系統中。通過 tea 協議，開源軟體包維護者，可以把自己負責的版本發布到由區塊鏈驅動的去中心化註冊表，從而消除單一故障源，發布無法篡改的版本，允許社區管理整個開源生態系統區域，避免外部影響。

Tea 可以激勵開源生態系統，主要方式是是通過讓參與 Tea 協議的開發者，將能夠獲取的價值與所依賴並希望保護的軟體包進行質押。Tea 協議的圖表可以提供不可篡改的的軟體包註冊、對於依賴性要求、驗證軟體包的真實性，以及通過預言機告知 tea 報酬激勵算法。系統性的通貨膨脹，基於算法會被分攤到所有軟體包上，如果發現安全或開發問題，開發者可以通過上傳證據，可以針對軟體包的索賠，系統會對有錯誤和安全上傳方進行索賠。開源社區的成員可以審查軟體包的質量問題，而 Tea 協議可以通過制定比例的削獎勵減，來應對這些審查。  

1. 聲明  

本白皮書中列出的資訊仍處於初步階段。因此，本文作者和任職的相關機構，都不需要對下列資訊的最終結果或者正確性承擔任何責任，本聲明適用於法律允許的最大範圍內，無論和侵權、合約、或者其他與本白皮書有關的內容，上述作者和任職機構都不需要承擔任何責任。

本白皮書或其中的任何內容均不得構成與任何合約或承諾有關的基礎，也不得作為訂立任何合約的原因，本白皮書中的任何內容都不構成對本文討論的任何代幣的銷售推銷。如果本白皮書在某些司法管轄區域，需要有關部門的許可或註冊，那麼，本白皮書不計劃傳遞一切和推銷有關的觀點和資訊，特別地，而且截至本白皮書發布之日，本文討論的任何代幣均沒有，也無計劃根據任何司法管轄區的證券法或相關法律進行登記，如果代幣出售將構成違反該司法管轄區的相關法律，那麼本白皮書提到的 Token 不得在任何司法管轄區提供或出售。

2. 許可證  

本文的源代碼，知識共享 版權歸屬-相同方式共享 4.0 國際公共許可證形式提供。

3. 引言   

網路主要是由開源項目組成的，自其誕生以來一直如此。隨著時間的推移，許多開源項目已經成為今天網路的基礎和基石，所有未來的網路創新都需要建立在這些基礎之上。儘管很多人和公司，都從開源項目建立的網路基礎賺取了財富，但開源項目主要靠的是無償地創造和維護。

我們堅信，僅靠世界上一小部分工程師選擇為愛發電，在需要為工資而奔波，和維護對網路運行起到重大作用的開源項目之間做出選擇，這樣的過程會讓人類的努力受到阻礙。開源是為愛發電，因此經常會因為缺乏經濟激勵而受到阻礙，導致真正存在價值的項目永遠無法發揮潛力，很多開源項目則會因為維護軟體的整個生命周期缺乏激勵措施來，而蒙受安全問題。為了充分發揮開源項目的潛力，我們需要為開源生態系統建立一個公平的報酬制度，並且不從根本上改變它的構建和利用方式。

商業企業通會常圍繞開源包裝商業模式，直接從仁慈的開發人員的工作中獲得收入，同時還依靠他們在問題發生時修復錯誤。一個典型例子是最近的 Log4j 安全漏洞的事件，Log4j 是 Apache 軟體基金會旗下的軟體包，它在企業和政府使用的許多商業軟體和服務發揮着重要作用。2021 年 11 月，一名安全研究員報告了 CVE-2021-442283 漏洞，該漏洞獲得了 Apache 軟體基金會的最高評分，而 Tenable 的 CEO 兼美國計算機應急準備小組 (US-CERT) 的創始主席 Amit Yoran 將此漏洞描述為「過去十年中最大、最嚴重的單一漏洞」。

恐慌隨之而來，為愛發電去維護這個軟體包的志願者因出現的問題，而受到公開抨擊，儘管系統之後得到了修補。但是企業和政府最終也意識到，Log4j，一個被廣泛的關鍵系統使用了 20 年的軟體包，是由一些志願者靠愛發電無償維護的，這些無名英雄儘管受到行業批判，但他們仍努力採取行動，不知疲倦地修復漏洞。可怕的是，Log4j 並不是唯一的例子。 每周被下載 3000 萬次的 core-js，是 Node.js 的重要基礎，但它也幾乎無法得到任何資金支持。近期，還有幾位比特幣核心開發者宣布辭職，理由之一是大家覺得經濟補償。開源項目在提供激勵結構方面已經進行了很多嘗試，通常主要是關乎於贊助和賞金系統。贊助模式，使開源用戶可以向自己喜歡的項目捐款。

但是，如果我們將開源想象成一座由磚塊砌成的高塔，基礎層早已被遺大家忘，但仍然有專門的工程師去維護它，這些基礎層承載着很多重要的項目，是很多開發者必須要使用的。但是，通常只有塔頂的少量項目是知名的，能夠獲得贊助。這種帶有嚴重偏見的選擇，會導致支撐塔的基礎磚塊得不到任何捐款和贊助，而最受喜歡的項目和人，收到的贊助卻比大家本身需要的要多很多。開源賞金允許項目的用戶為開發人員構建特定功能付費，因此，僅獎勵項目需要做方面，不一定符合工程師的最佳利益，因為只獎勵最受用戶喜歡的項目。

本文我們提出了去中心化協議 Tea，用於根據開源的開發人員對整個生態系統的貢獻公平地給予報酬，並通過 tea 激勵算法應用於 tea 註冊表的所有條目中。  

4. 部分組件  

工程師開發一個應用程序需要 4 個部分：瀏覽器、終端、編輯器和包管理器。在這四樣東西中，軟體包管理器是控制開發者構建其產品所需的工具和框架的東西，而這一層也是可能改變我們看到改變開源報酬和和激勵方式所在之處。

4.1 包管理器

通過軟體包管理器，可以明確開發的應用程序的功能依賴於哪些開源軟體，無論是最上層，還是底層的基礎層。所有對開發應用程序至關重要的組件和版本，都會被記錄下來。軟體包管理器，可以被獨特地放在開發者工具棧中，從而實現基於真實世界應用的自動和精確的價值分配。

本白皮書提出了一個不可篡改的的去中心化註冊表，旨在根據算法來分配價值，這種算法決定了每個條目對整個系統的效用和健康的貢獻。價值可以從頂點--應用程序和基本庫--進入上圖中，並被分配給這些頂點的依賴方，因為註冊表知道整個開源圖表的價值流轉方式。

此外，我們認為必須通過包管理器提供重要性 (實質性) 資訊 (material information)，以便開發者評估他們是否可以信任一個軟體包及其開發者。這種信能是基於聲譽、社區讚譽、從去中心化身份（DID：參見：https://www.w3.org/TR/did-core/）系統中檢索的數據、或是其他軟體包管理器可能依賴網路參與者，將經濟價值置於風險之中的激勵機制。

我們相信，Tea 提供的的工具、資訊和獎勵的組合將可以公正地激勵開發者，幫助激勵開源軟體的增長，同時促進創新。

4.2 去中心化的註冊表

每個包管理器都有自己的包註冊表，重複着相同的元數據（Metadata）。現在，是時候需要一個由社區設計，能夠單一管理的、全面和明確的註冊表了。我們認為，去中心化的、不可篡改的註冊表可以提供安全、穩定和防止人為的惡意操作。

我們今天的網路，運行在數以萬計的重要開源組件上。值得注意的是，到目前為止，因移除基本的開源基礎設施而引起的事件時有發生，最著名的是 2016 年 NPM left-pad7 出的問題，它影響力持續集成和持續部署系統，使開發人員遇到了一些麻煩。這一事件表明，網路建立在脆弱的開發系統之上，其他的例子還包括到軟體包的維護者主動或故意破壞自己開發的軟體包（例如 color.js，faker.js8，和 node-ipc9），或者壞人希望通過假裝維護軟體包，目的是為了破壞它們，從而竊取比特幣的私鑰，或者存在惡意拼寫錯誤的軟體包，也被稱為 tynosquatting，希望欺騙用戶來安裝它們，例如 crossenv 的 cross-env NPM 軟體包（注釋 11）。

隨著整個行業都向着數字資產的方向發展，很多東西都會成為軟體一部分，因此，軟體的完整性需要得到保證。我們不能繼續受到惡意行為者修改軟體的影響。但是，大多數包管理器的工具無法保證這些內置在應用程序和 dApp，因為其中的軟體包是原作者發布的未經修改的開源代碼。GitHub 發現，17% 軟體中存在漏洞和被植入了惡意目的（注釋 12），有些漏洞在很長一段時間內都沒有被發現。

如果存在去中心化的註冊表，再加上一個信譽系統，並存在經濟激勵機制支持，是否可以暴露壞的軟體參與者？並且獎勵好的軟體參與者？這種創新的方法，可能會為當前的開發者社區，提供一直在尋找的解決方案。  

此外，我們認為，必須通過包管理器提供物質資訊，以便開發者評估他們是否可以信任一個包及其作者。這種資訊可能是基於聲譽、社區讚譽、從去中心化身份（DID6）系統中檢索的數據、其他包管理器或可能依賴網路參與者將經濟價值置於風險之中的激勵機制。

我們預測，Tea 的工具、資訊和獎勵的組合將公正地激勵開發者，幫助刺激開源軟體的增長，促進創新。

4.3 儲存系統

開源包提供了非常廣泛的功能，其中一些可能是受限制的或大家不需要的。加密方式（encryption，這裡指密碼學裡的加密）就是典型的例子。然而，這項技術也可以被用於邪惡的目的（見 Phantom Secure，2018 年 3 月被執法機構拆除 14），或者可能會被破壞以支持執法活動（見 Operation Ironside（AFP）、Operation Greenlight（Europol）和 Operation Trojan Shield（FBI）15，FBI 營運一個 "加密的 "通信平台 AN0M，並說服罪犯使用他們 "加密的 "手機進行安全通信）。加密技術的廣泛應用使其成為開源軟體的完美用例，也是一個很好的例子，任何儲存包的解決方案都必須是防篡改。tea 是一個去中心化協議，不計劃根據其功能對軟體包進行干涉、過濾或制裁。雖然 Tea 治理可能會選擇刪除已證實的惡意軟體包（有關這部分更多資訊，請參閱治理部分），但關鍵在於 tea 系統要與多個儲存系統連接，包括證明包未被修改，並且要正確複製去中心化的儲存系統，包的維護者可以選擇最適合自己需要的儲存系統，從而安全地儲存和分發這些軟體包。  

5. 網路的參與者  

Tea 的願景在於賦能整個開源社區，確保開源社區的貢獻者能夠在創造構建網路的基礎工具時得到支持。在本白皮書中，我們通過參與者的貢獻來區分他們，有些人會參與代碼貢獻，有些人會對貢獻的代碼進行驗證，其他人可能會提供經濟價值，用於支持開發者和他們的聲譽。

5.1 包維護者

包維護者必須確保他軟體能夠隨著行業的發展，可以繼續提供越來越多的價值。

tea 會假設包創建者會維護自己的工作，軟體包維護者是開源社區的支柱，這些開發者需要得到授權，並為持續參與貢獻獲得激勵，因為軟體包維護者可能會決定停止維護軟體的工作，或者意識到自己並沒有辦法以符合軟體用戶所期望的速度工作。當軟體包維護者成功提交一個包時，會收到一個不可偽造的代幣（NFT）（更多細節見 NFT 部分）。

這個 NFT 用於證明軟體包維護者的工作，也是指導 Tea 獎勵的關鍵，軟體包的 NFT 的持有者可以轉讓自己的 NFT 給其他開發者（或者一個開發群體），從而使新的開發者可以成為軟體包的維護者和潛在未來獎勵的取得者。同樣地，一個開發者可以承擔軟體包維護者的角色，他可以將現有的軟體包分叉，提交一個新的軟體包，讓自己成為軟體包的創建和維護者。並且可以為開發者社區提供正確的工具來確定哪些軟體包正在被維護，以及確認過去和現在維護聲譽和工作質量是至關重要的。我們經常看到開源貢獻被惡意篡改，許多人的努力被作惡者毀掉。儘管惡意的部分很多時候都會被發現，能夠得到補救，但往往會到了財務或數據損失而造成重大損失時的那一步，才會被發現。以 EventStream npm 軟體包（注釋：16）為例，EventStream npm 每周被下載超過 150 萬次，並被 1500 多個軟體包所依賴，當一個駭客設法滲透到該開源項目，獲得其原作者的信任，並修改 EventStream 以依賴一個惡意軟體包，將比特幣錢包的憑證外泄到第三方服務器。雖然工具可以幫助檢測其中的一些攻擊，但它們並不總是可靠的。我們建議通過 Tea Token 部分，引入激勵機制，鼓勵開源社區建設性地報告自己的發現，以便軟體包維護者能夠在問題出出現之前解決這些問題。

5.2 包用戶

包用戶是專注於解決特定問題的開發人員，開發者們經常會在開源社區尋找他們所需的工具，想要以極少的成本或免費的方式進行技術上的快速實驗和迭代，這部分開發者，會直接受益於軟體包創建者和維護者的工作。傳統情況下，部分人可能會選擇通過捐贈或其他形式的報酬來支持開源軟體包的維護者，但是捐贈其實還是杯水車薪。

贊助也可以成為支持開源軟體開發的有效方式，但是問題在於，贊助得來的報酬通常不會延伸到所有的依賴關係，儘管這種限制有利於贊助者，卻會妨礙開源的創新和軟體建設，為了讓積極和激勵能夠賦能所有軟體開發，無論是初學者還是專家，必須讓所有的開發者都可以參與開源。

Tea 的目標，是在維護開源軟體的核心價值的同時，提供一個去中心化的系統，為維護開源軟體包開發者提供報酬。為了實現這一願景，Tea 計劃採用開發——激勵其他人開發——機制，讓軟體包的用戶能夠通過 Tea Token 的獨特應用場景，來支持軟體包維護者，這部分可以在本白皮書的 Tea Token 的未來工作計劃以及潛在的社區努力部分看到。

5.3 包的支持者和贊助方

在 Web2.0 和 Web3 中，軟體包的支持者通常被稱為 "贊助方"。贊助方是使用開源軟體來構建商業產品的組織或軟體包用戶，也希望支持開源生態系統的積極分子，也包括期望資助團隊，已開發開發更大系統組件的企業家。

tea 提議將包支持方的社區，擴展到整個 tea 社區，無論是組織、開發者、用戶還是技術愛好者。tea 的目標是通過 Tea Token 的獨特用例來實施去中心化的激勵機制，讓 Tea 社區的所有成員，都能為開源的永久可持續性和持續增長作出貢獻。軟體包的支持者和贊助者，可以根據他們的工作、信仰或任何影響決定的標準和尺度，自由決定要支持哪些軟體包或開源軟體的維護工程師。此外，軟體包支持者和贊助者，提供的支持將流向每個軟體包的依賴關係，從而隱含地相信軟體包維護者會對他們的堆棧做出良好的選擇，並利用這些資訊來促進他們的聲譽。

只要包維護工程師能夠提供這樣的服務，包的贊助方可以收到高級支持級別的 NFT 作為回報，從而受益於加速的 SLA 或更靈活的許可。此外，軟體包支持者和贊助者可以自主決定支持哪些開源軟體包或開源軟體包的維護工程師，並自動將全部或一定比例的獎勵，轉用於激勵團隊建立新的開源軟體。換句話說，軟體包不需要存在就可以用 tea 來激勵，新生項目可以和更成熟的項目一樣得到支持，進一步激勵不斷發展的開源環境。

5.4 Tea 的試用者

隨著新的軟體包或現有軟體包新版本的發布，需要證明的工作的有效性，因為這些資訊，對於取得開源軟體的用戶信任是非常重要的，用戶會決定是否信任開源軟體包和它的維護方。在 Tea 協議中，這一功能是由 Tea Taster(鑑定師/品茶師) 來承擔的。

鑑定師通常是有經驗的開發者，他們願意花一些時間來檢查與軟體包相關的聲明（功能、安全、語義版本（注釋 17）、許可證的準確性等），並以個人的聲譽和經濟價值為質押，來證明自己的研究和分析結果。在 Tea 協議中，我們稱它為 "Steeping your tea(沏茶）"，即鎖定 Tea Token，以支持鑒茶師的評價，並根據大家對評論的有效性共識，獲得獎勵（或懲罰）。與開源軟體包的支持者一樣，鑑定師可以影響開源軟體包和開源軟體包維護者工程師的聲譽；然而，鑒於鑑定師驗證開源軟體包的安全性、功能和質量方面的覺得，他們的影響力更為顯著。當然，鑑定師也需要構建自己的聲譽，支持他們的主張。鑑定師的工作質量和獲得社區的評論，與其他外部數據來源相結合時，將為每個鑑定師的樹立自己的聲譽，為工作帶來更多價值，關於用於影響開源軟體包和軟體包維護者聲譽的機制的更多細節，請參見本白皮書的軟體包聲譽部分。

6. 協議概述  

設計一個能夠激勵開放源碼貢獻的協議是充滿挑戰的。顧名思義，開源軟體是向所有人開放的，因此可能會出現錯誤的引用、盜用或惡意篡改。然而，開源社區表現出的特質是，它願意彰顯好的社區參與者，揭露壞的社區參與分子。從開源社區的歷史上來看，對其他開發者的代碼貢獻進行審查和評論所花費的精力是完全自願的，儘管報告和捍衛代碼審查結果是非常耗時，又是非常關鍵的。

我們計劃為應用程序的開發，創建一個由社區成員聲譽和經濟激勵保障的去信任的發布平台，因為我們認為，如果沒有聲譽系統和社區成員及時溝通自己的發現，如果沒有本身對對開源社區開發者或開發工作的支持 (與反對）的能力，對開源貢獻的高效激勵就無法成功。

我們需要為開發者提供工具，用於聲譽系統的訪問和貢獻，工具包括簡單可視化和可編程訪問的工具，以了解軟體的依賴關係和聲譽情況。這樣的機制有助於清晰地地了解到底有哪些開源社區成員在對這些軟體包的維護做出貢獻，以及社區成員手中有多少 Tea 的代幣，這將有助於提高所提交的軟體包的聲譽，因為某個軟體包的維護開發者擁有 tea 代幣的數量，能夠傳達了開發者對自己工作的支持程度。這些綜合數據點將有助於為所有社區成員提供一個聲譽系統，並促進社區的選擇。注意，由於 EventStream 遭到的駭客攻擊並不是通過軟體本身進行的，而是通過它和其他軟體的依賴關係進行的，因此，所有軟體之間的依賴關係的可見性，對於建立這個無信任的系統至關重要。然而，我們在設計和構建系統時，需要優先考慮計算和交易（"Gas 費"）成本等因素。

本協議的的目標是激勵 Web2.0 和 Web3 開發者。軟體堆棧的錯綜複雜和大量的細節，使得追蹤軟體包的安裝和卸載，很容易成為駭客攻擊或其他不良行為的受害者。這包括人為地誇大數字。更糟糕的情況是，通過與許可證密鑰或其他部署跟蹤機制產生不必要的摩擦，對開源軟體的性質進行根本性的改變。為了提供最廣泛的覆蓋面，我們認為激勵不能簡單地依賴跟蹤安裝或卸載的概念，而是要依靠鼓勵提交高質量軟體包，和報告有問題或高風險軟體包的機制進行激勵。最後，許多軟體依賴於共同的依賴關係。例如，Lodash 有 151,209 個依賴項，而 chalk 有 78,854 個依賴項，Log4js 有 3,343 個依賴項。隨著越來越多的軟體包使用相同的依賴關係被，如何確保激勵措施被公平和公正地分配？如何確保對利用率最高的依賴關係進行激勵，而不使新的或新興的軟體包和開發者陷入困境？如何確保激勵系統最終不會讓小眾開發者失去信心，讓他們因為有激勵，而跑去獎勵更多的地方？同時，作為開發者，如何識別依賴關係最強的軟體包，以建立更精簡、更高效、更好的軟體替代方案的版本？在 tea 協議中，我們認為，正式因為激勵機制的缺乏，才阻礙了開源軟體的發展。在正確的經濟激勵和獎勵的支持下，更多的開發者將有能力構造、完善和迭代開源軟體，從而讓整個技術世界更好。只有這樣，Tea 代幣，才能夠代表開源軟體的真正價值。

6.1 軟體包的提交

軟體包發布的提交需要多個事務原子化地發生。具體來說，軟體包維護者必須

- 在去中心化的註冊處註冊軟體包（及其語義版本）。

- 將軟體包上傳到去中心化的儲存系統中，以保證其彈性、抗審查性和易於分發。

- 通過 Tea token 為包的聲譽和可信度做出貢獻。

這三項操作中的任何一項失敗，都會導致協議恢復到之前的狀態，從而消除提交的任何證據。

當軟體包成功提交後，軟體包維護者將收到一個維護者 NFT 來證明他們的工作和對開源的貢獻。軟體包維護者可以將與維護者 NFT 相關的沏茶的獎勵轉讓給第三方。然而，與資產的創建和維護相關的聲譽將保留在軟體包維護者身上，所以他們的聲譽會隨著時間的推移而受到影響。當茶葉社區的任何成員的聲譽達到關鍵的里程碑時，他們可能會被授予訪問協議的高級部分或獲得加速的獎勵，這由茶葉管理部門決定。關於維護者 NFT 的更多細節，見維護者 NFT 部分。

6.1.1 依賴關係分析

軟體包的依賴關係可以很深，因為每個軟體包往往都有依賴者和被依賴者。為了提供一種簡單的方法，獎勵所有為開源軟體做出貢獻的開發者，同時保持依賴關係樹的快速創建和計算效率，我們建議在提交軟體包時只驗證第一級依賴關係。

這種設計是由這樣的假設驅動的：每個依賴關係本身就是一個獨立提交給茶樹的包。這樣一來，它的每一個依賴關係都可以被映射，如果它的依賴關係本身有依賴關係，那麼這些依賴關係將在提交依賴包時被映射出來。  

在圖 2 中，包 A 的提交觸發了對運行時依賴關係 1 到 n 和構建依賴關係 1 到 n 的分析，而運行時依賴關係 1.1 到 1.n 和構建依賴關係 1.1 到 1.n 在包 B 被提交時被分析。我們將應用同樣的方法進行激勵分配，因為沏茶的令牌分布在所有的依賴關係中，從而遞歸地沏茶被列為依賴關係的包（見圖 3）。

版本和衝突的依賴關係是重大的挑戰，解決這些問題會變成大量的時間消耗。為了解決這個問題，我們建議每個軟體包在提交時都要接受全面的依賴性掃描，這樣我們就可以確保該軟體包符合以下語義版本範圍的規則。軟體包只能將其依賴關係限制在一個主要的版本上，儘管該範圍的起點可以是任何有效的語義版本（例如，>=5.2.1

原文連結