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

原文標題：《 Tea.xyz：可用於激勵開源生態系統的去中心化協議 》

原文作者： Max Howell  Timothy Lewis  Thomas Borrel

原文編譯： 阿法兔

本協議旨在爲所有開源軟件創建開放的、公共的和穩定的註冊表，使得項目能夠獨立發佈版本，而不再依賴第三方，將這些不規則的數據集合到數百個獨立（和重複）的系統中。通過 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），有些漏洞在很長一段時間內都沒有被發現。

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

圖 1：Tea 去中心化系統的簡化視圖  

此外，我們認爲，必須通過包管理器提供物質信息，以便開發者評估他們是否可以信任一個包及其作者。這種信息可能是基於聲譽、社區讚譽、從去中心化身份（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：依賴關係分析圖

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

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

- 如果一個依賴關係被升級到一個較新的主要版本，茶葉可能需要增加軟件包的主要版本。

- 同樣地，如果一個依賴關係被升級到一個較新的次要版本，tea 可能要求軟件包的次要版本被增加。

- 如果增加了一個新的依賴關係，Tea 可能會要求增加軟件包的小版本。  

圖 3：依賴關係中的獎勵分佈。

考慮到當上述規則被違反時，任何軟件包用戶都要付出不必要的努力，我們建議削減軟件包維護者沏茶的一部分茶葉代幣，以反映他們缺乏應有的努力。如果一個開發者強迫每個人玩弄他們的杯子，有人會打翻一些茶。由於依賴性掃描預計會在提交時發生，我們應該注意到沒有來自軟件包支持者和贊助商或品茶者的沏茶。

6.2 包和包維護者的聲譽

軟件包維護者必須通過沏茶葉代幣來爲他們的軟件包的聲譽和可信度做出貢獻。然而，僅僅依靠作者的經濟貢獻的聲譽系統並不能提供足夠的用戶保護，而且可能會受到 Sybil 攻擊，即一個人創建多個自己的代表，在他們的工作上留下大量的正面評論，欺騙用戶相信他們的工作是由許多人審查和批准的。

有幾種方法可以防止（女巫攻擊）Sybil Attack，其中一些方法由 Nitish Balachandran 和 Sugata Sanyal 在 "A Review of Techniques to Mitigate Sybil Attacks "中描述。由於 tea 是一個去中心化的協議，使用依賴於中心化證書頒發機構的信任認證系統將違背其核心。我們建議把重點放在緩解 Sybil 攻擊的去中心化方法上，更具體地說，就是依靠一大批網絡參與者的激勵來評估和公開代表每個包及其維護者的聲譽的方法。類似於 PoS（權益證明）區塊鏈上的區塊生產，非生產節點可以驗證其他人的工作，並在必要時強調違反網絡規則的行爲，這將導致通過削減（銷燬他們的一部分權益）來懲罰不良行爲者。我們提出一個系統，讓第三方（又稱品茶師）能夠審查軟件包維護者製作的軟件包，並在經濟上激勵他們的行爲符合開源軟件社區及其用戶的最佳利益，同時認可良好的行爲並懲罰不良行爲。這個系統必須既能抵禦 Sybil，又能防止大型代幣持有者對協議或特定軟件包的聲譽產生實質性影響。我們認爲這種方法與開源更加一致，爲促進採用和信任提供了更肥沃的基質，並最終促進 Tea 協議的發展。

6.3 第三方的軟件包審查

第三方對包裹的審查是信譽建設的一個重要組成部分，然而，第三方審查有其自己的一套獨特的威脅，包括前面提到的 Sybil 攻擊（女巫攻擊）。

區塊鏈技術，更明確地說，賭注，爲茶葉提供了一個獨特的機會來解決這一挑戰。雖然錢包地址可能是無限量的，但茶葉代幣的情況並非如此，其初始供應量預計爲 100 億。此外，開發者的每一個行動，如提交包裹、驗證包裹或沏茶包裹，都將有助於他們的聲譽，從而創造一個獨特的檔案，每個開發者都可以用來爲茶葉社區作出貢獻，並參與茶葉的治理。

通過要求第三方審查者浸泡茶葉代幣，如果他們的行爲違背了網絡的利益或成爲一個壞的行爲者，他們將承擔失去部分浸泡代幣的風險，第三方可以爲一個包提供額外的信譽並獲得獎勵，以茶葉代幣的形式。

我們還建議將信譽系統擴展到對包裹進行獨立驗證的第三方--品茶師。一個正面評論的完成需要兩個原子化的操作。提交代碼審查，由品茶師簽名，並向社區所有成員公開沏上 "支持 "該軟件包（與 "反對 "該軟件包）的行爲，以證實其審查。

完成包含一個或多個關鍵漏洞的負面評論，將要求品茶者首先使用消息傳遞協議聯繫軟件包維護者，通知他們該漏洞，並讓他們及時解決該問題。在分配給軟件包維護者解決其漏洞的治理期限到期後，或者當修正後的軟件包可用時，同樣的消息傳遞協議將被用來通知這個軟件包的所有用戶和測試者（包括依賴者），一個漏洞已經被發現，並希望得到解決，因此他們知道要更新他們的應用程序或依賴關係。爲了防止浪費開發者的時間，品茶者和軟件包維護者之間的交流將需要品茶者沏茶代幣。

在完成這兩項操作後，品茶者將收到一個 NFT，作爲他們對特定軟件包和軟件包版本的工作證據。NFT 的積累與每個被審查的軟件包的浸泡率以及從外部系統提取的信息相結合，將告知品茶師的聲譽。當他們的聲譽達到關鍵的里程碑時，品茶師可以獲得協議中更高的部分或加速的獎勵，由茶葉管理部門決定。

6.4 過時或損壞的軟件包

tea 的使命是獎勵開源社區的貢獻者和參與者；然而，獎勵必須與軟件包維護者和品茶師的努力相稱。維護不足、過期或損壞的軟件包是軟件包維護者沒有達到社區的期望或沒有兌現通過浸泡軟件包而給予他們的信任和支持的明顯跡象。過時軟件包的另一個表現可能是繼續使用遺留語言或多版本語言的遺留版本。軟件包過期或損壞的時間過長，表明品茶師需要定期和持續地審查軟件包維護者的工作。

品茶師是開源社區的關鍵成員，他們的評論和相關的聲明可以引導軟件包用戶使用或不使用軟件包。爲了確保評論可以被持續信任，我們提出了一個機制，即過時或損壞的軟件包可以看到他們的部分浸泡代幣被送到最先發現任何軟件包缺乏維護的品茶師那裏。

任何負面評論，如概述了一個缺陷，如零日漏洞或使用一個過時的依賴，並在治理定義的寬限期後仍然開放，應被視爲軟件包維護者的失敗。他們沒有完成他們被委託和獎勵的任務。同樣的道理也適用於軟件包的支持者和贊助者，他們把自己的聲譽押在了拖欠的軟件包維護者的工作上，並因此獲得了獎勵，但卻沒有發現缺乏維護的問題，或者選擇繼續支持該軟件包而不顧。

隨着軟件包的普及和使用，越來越多的應用程序和潛在的關鍵任務系統依賴於它們，我們必須激勵開發人員謹慎地向軟件包維護者報告缺陷，軟件包維護者要在這些缺陷被利用之前解決這些缺陷。因此，我們建議，任何過期或損壞的軟件包，如果受到一個或多個有證據的負面評論，並在治理定義的寬限期後仍處於這種狀態，那麼其浸泡的代幣將被砍掉一部分，無論其來源如何（軟件包維護者、軟件包支持者、贊助商或先前的品茶者），而另一部分則被髮送給提交負面評論的品茶者。對所有品茶者的分配可以基於他們評論的年齡和他們爲其評論所沏的茶葉代幣的數量。

6.5 開源維護者的 NFT

在成功提交軟件包後，軟件包維護者將收到一個 NFT 來證明他們的工作和貢獻。該 NFT 的持有者將自動獲得與該包相關的所有獎勵。軟件包維護者可以通過簡單地轉讓軟件包的 NFT，將軟件包的維護所有權轉讓給另一個軟件包維護者。成功轉移 NFT 將導致新的所有者自動獲得未來的包獎勵。聲譽建設的一個重要部分是依靠高質量軟件包提交的頻率和數量。交給包維護者的 NFT 作爲他們工作的證據，可以被信譽系統用來更新包維護者的信譽，並讓他們進入協議的高級部分，這由茶葉治理決定。然而，爲了防止攻擊載體，如社區成員購買他們的聲譽，維護者 NFT 的轉讓將不會導致聲譽的轉移。聲譽必須保持與特定開發者的工作直接相關，並且不得轉讓。

7.Tea Token  

7.1 確保網絡的安全性

儘管許多區塊鏈看起來是有效和安全的基礎設施解決方案，可以支持 Tea 協議想要達成的的目標，但我們認爲。必須審慎考慮構建 Tea 協議的系統的技術堆棧。

可擴展性、成本效益、ESG 和第三方可擴展性是設計 Tea 協議過程中重要的設計考量因素，因爲這樣的話，權益證明的 tea 協議系統才能更好地發揮作用。在權益證明中，節點運營商和網絡參與者以鏈上原生代幣的形式，對經濟價值進行質押，從而提升系統的安全性。節點運營商和網絡參與者，只要成功地生產符合網絡規則、包含準確交易信息的區塊，就會獲得獎勵。不活躍（又稱節點宕機）或惡意/不正確的活動會受到懲罰，會損失一部分質押的代幣。

由 Tea Token 驅動的權益證明系統將允許 Tea token 持有者，通過抵押 Tea Token 爲系統的安全性做出貢獻，並通過沏茶支持開源開發者。我們也意識到，經濟因素可能會阻礙部分開發者對 tea token 進行抵押或沏茶；因此，抵押和浸泡的費用將低至一片葉子，最小的茶葉面額代表一億分之一（10-8）的茶葉。Tea token 的這兩種應用在支持和發展開源生態系統方面發揮着重要作用。

沏茶將確保茶葉系統繼續安全運行，因此所有網絡參與者都可以提交和訪問軟件包，對軟件包進行審查，繼而整合到他們的應用中，等等。相反，沏茶將支持 Teaxi 的目標，即爲所有網絡參與者提供工具，以支持和使用符合質量和可靠性要求的軟件包，這些軟件包是 tea 社區通過對每個軟件包的支持和異議制定的，在定義和實施沏茶參數時，將採取謹慎的態度。

7.2 激勵和懲罰措施

正如前文所討論的，不良分子具備破壞開源軟件的強烈動機，互聯網的大部分關鍵基礎設施都運行在開源軟件上，尋找漏洞和利用漏洞的競賽正在進行中。tea 協議認爲，軟件包維護者不應該受到任何指責（儘管他們經常受到指責）。

tea 協議旨在通過公平、公正的激勵機制解決這個問題。像 Lodash 這樣擁有超過 15.1 萬個依賴項的軟件包是開源開發工作的支柱，它的維護者理應得到相應的獎勵。然而，一個僅建立在依賴者數量上的獎勵系統。會阻止創新者打破這些壟斷，除非有足夠的第三方資金或者已經積累了足夠的資源來自籌資金。這種方法很可能會導致貢獻者的數量縮減，從而導致與 tea 的願景截然相反的結果。

tea 的目標，是能夠代表開源軟件的價值，並在此過程中，通過賦予參與者所需的資源來，促進開源軟件的發展，使他們能夠不受阻礙地追求自己的願景和激情。tea 激勵分配系統需要審慎考慮每個包的沏茶比例，並相應動態調整每個軟件包的激勵。爲了減少在許多應用中作爲依賴關係的少數包收集大部分沏茶獎勵的風險，我們將利用 web3 foundation 作爲基於 Polkadot 權益證明的獎勵機制進行的研究。

我們可能會根據實際情況中的實踐結果，進一步調整實施方案及其變量。當一個軟件包超過其最佳沏茶比例時，沏茶獎勵比例將急劇下降，以抑制軟件包支持者和品茶者的行爲。這種設計可以使低沏茶率的軟件包支持者和品茶者都更有吸引力。這也可以激勵有經驗的開發者建立替代高沏茶率的軟件包，爲 tea 社區創造一個機會，以平衡支持現有軟件和促進創新。在最初的設計中，沏茶比例將使用流通供應量來計算。茶社區可能會改進此種設計，以進一步提高系統的可擴展性。設 是所有包的沏茶比。它代表包維護者、軟件包使用者、軟件包支持者和贊助者，以及茶品嚐者沏茶的 Tea Token 總數除以 Tea Token 總供應量。考慮到今天有多少開源軟件包可用以及它們的預期增長，將始終是一個介於 0 和 1 之間的非常小的值。

我們可以根據實際實驗的結果進一步調整實現及其變量。隨着一攬子沏茶接近治理定義的最佳泡茶比率，其沏茶獎勵比率將逐漸降低。當一個包裝超過其最佳沏茶比例時，沏茶獎勵比率將急劇下降，以抑制包裝支持者和品茶者進一步浸泡高度浸泡的包裝。這種設計可以使沏茶較少的包裝對包裝支持者和品茶者都更具吸引力。它還可能激勵有經驗的開發人員構建高度沏茶率的軟件包的替代品，爲茶社區創造機會，以平衡支持現有軟件和促進創新。沏茶比將在其初始設計中使用循環供應來計算。

設 爲質押比率，代表任何網絡參與者爲保護整個協議的網絡安全而質押的 Tea Token 總數

設 ideal 是我們希望每個包在所有包及其依賴項之間公平分配獎勵時達到的沏茶比率。ideal 的值必須隨着新包添加到去中心化註冊表，並創建依賴關係而更新。爲了確定 ideal 的最佳值，我們將使用在每個獎勵週期開始時更新的流行度鐘形曲線。

令 = () 是分配給所有 Tea Token 以支持開源開發者的 Tea 社區成員的年沏茶利率。換句話說，() 對應於社區成員在整個一年中沏茶 Tea Token 所獲得的浸泡獎勵。

設 = () 爲分配給所有節點運營商和網絡參與者的年度質押利率，這些節點運營商和網絡參與者質押 Tea Token 以維護整個網絡的安全。換言之，() 對應於社區成員在一整年內押注茶葉代幣所獲得的押注獎勵。

設成爲針對整個 Tea 代幣國庫的年度通貨膨脹率。可能隨着外部因素對 Token 供應的影響而變化。

我們認爲，年沏茶獎勵率視爲的函數，年押注獎勵率的關於的函數。

• () 對應於人們購買包裹的動機。隨着 的增加，需要更少的獎勵 ()。

• () 對應於人們對網絡進行質押的激勵。隨着 的增加，需要更少的獎勵 () 來保護網絡。

年度通脹 I，將等於 ( + + ) 並計算如下：I = 年末代幣供應量 - 年初代幣供應量 年初代幣供應量 = ( ++)

應權衡 all（分配給所有沏茶者的的激勵）和 all（分配給網絡安全的所有貢獻者的激勵）對通脹的貢獻，以確保系統激勵最佳沏茶率/抵押比率。

由於我們關注的是分佈在所有軟件包內的激勵，我們確定 all 是沏茶率的函數，因此 all() = - ()。從我們之前的分析中，我們可以看到 all(ideal)= ideal -ideal。由於目標是達到 = ideal 的狀態，因此獎勵 ideal() 應該在該值處最大。

令 ideal = (ideal) 爲網絡在 = ideal 的理想場景下提供的獎勵率。令 0 爲 all() 的極限，因爲當 Tea 社區的任何成員都沒有沏掉任何軟件包時，變爲零。0 的值應趨近於零但不完全爲零，以激勵早期採用者。根據 web3 基金會的研究建議，我們建議：

• 通貨膨脹函數在 = 0 和 = ideal 之間線性增長，並且在=ideal 和=1 之間呈指數型衰減。

我們爲 all() 選擇了一個類似的指數遞減，因爲它意味着 () 的指數遞減，而且我們希望獎勵急劇下降，超過 ideal，以防止單個包獲得所有的獎勵。

衰減的定義是，當向 ideal 右移 d 個單位時，通貨膨脹率最多下降 50%，即 all(ideal + d) all - 0.5。

我們提出以下利率和通貨膨脹率函數，它們取決於參數 ideal、ideal、0 和 d。

all() = 0 + (all(ideal)- 0) ideal 爲 0 < ideal all() = 0 + (all(ideal)- 0) - 2 (ideal-)/d 對於 ideal < 1

好的行爲者需要得到獎勵，不良行爲者也需要被清晰識別並受到懲罰。開源軟件的特性，有時爲不良行爲者提供了不少機會，爲整個開發者的社區製造痛點，帶來了聲譽上的風險。無論是盜用開源貢獻者的工作，再到篡改和重新分發軟件包，或注入惡意代碼，好人和壞人之間的戰爭仍在繼續，往往有資金雄厚的壞行爲者把污染開源軟件包看作是一個在經濟上獲益的機會，軟件包有可能被禁止放在數字貨架上，或者帶來不良的聲譽影響。

我們建議引入一種削減機制，以建立一個更實質性的不利因素，從而直接影響不良行爲者的經濟價值。當品茶者評估和分析新提交的包中的代碼時，我們建議品茶師獲得工具和激勵措施，來查明和突出惡意代碼，以便軟件包用戶可以意識到風險，並對提交或支持有害代碼的軟件包維護者、軟件包支持者和贊助商進行懲罰。在這種情況下，對於根據網絡規則執行的所有有證據的負面評論，並且軟件包維護者已經在規定的時間內進行了處理，軟件包維護者不應該招致任何與軟件包支持者和贊助商或對有關軟件包提供正面評論的品茶者相反的懲罰。

對於按照網絡規則進行的負面評論，如果軟件包維護者沒有在治理規定的期限內解決，軟件包維護者、軟件包支持者和贊助方以及以前的品茶者所沏茶的 Token 的一部分將被削減。另一部分將被鎖定在一個由 tea 治理控制的保險池中。tea 治理負責部分將與社區密切合作，共同制定政策和規則，將池子裏的內容分配給受軟件漏洞影響的人。

該協議將根據他們「反對」包裹沏的茶代幣的數量以及他們的代幣浸泡多長時間，將三分之一的浸泡代幣分配給所有對負面評論做出貢獻並浸泡在軟件包的茶品嚐者。換句話說，品茶者（們）越早根據網絡規則識別並報告軟件包中的缺陷，他們能夠因爲支持安全和高效的開源開發所獲得獎勵就越高。

爲了防止社區成員隨機投票「反對」希望獲得大部分懲罰的高沏茶率軟件包，所有「反對」沏的茶代幣都不會獲得通貨膨脹獎勵，並且可能會受到衰減機制的影響，從而隨着時間的推移而降低其價值。

8. 治理  

對於任何分佈式系統的發展、可持續性和應用，治理都是至關重要的。Tea 協議會涵蓋鏈上治理，所有 Tea Token 持有者，都可以建議並投票修改由 Token 所有權和聲譽加權的關鍵參數。這些參數可以包括通貨膨脹參數、交易費用、質押獎勵、沏茶獎勵或最佳沏茶比例。這項功能將確保哪怕隨着時間的推移，這些關鍵參數也能夠能由 tea 社區的成員繼續迭代和優化。預計，治理將以簡單的模式先行啓動，隨着 tea 系統的成熟而逐步擴大，促進應用，並確保逐步將權力下放。部分系統參數目前暫時不會受到治理或支持高頻率的改動，以減少因爲治理所帶來的攻擊面，之後將逐步將參數過渡到開放、去中心化的治理將確保系統的穩定性和可預測性。  

9. 第三方可擴展性  

在我們剛開始構建這項工具，來激發開源社區的長期支持時，相信我們是使命之一，是確保第三方可以擴展整個工具集。除了爲開發者提供協議擴展的基礎設施之外（包括創新和進一步支持開源開發者的新方法），我們的計劃還包括能夠賦能其他軟件包管理器爲協議作出貢獻的潛力。開源工程師的夢想和努力，才構建了這些能夠支持我們日常生活的科技創新，我們期待着 tea 社區提出 tea 的新用途和擴展方案。  

10. 未來的工作 VS 潛在的社區努力  

隨着 tea 系統的成熟，可以預見，社區將通過治理來決定和促進 tea 系統的改進和進一步擴展。以下是我們認爲可能會激發一些靈感的一些想法：

10.1 茶葉批發商（tea Wholesalers）

開源社區是充滿活力的，不斷尋求創新和提供價值。這種奉獻精神和利他主義導致了新軟件和軟件包的源源不斷地出現，每一個都給軟件的依賴關係添磚加瓦。因此，我們預計這個依賴關係圖會不斷髮展，導致 steeping ratio 和激勵情況的的頻繁變化。在未來，tea 社區可能會提議開發一個系統，旨在動態監測每個軟件包的 steeping ratio，並根據自己的標準，重新平衡軟件包支持者如何 steeping 自己的代幣。

10.2 轉讓軟件包的版權費

軟件包維護者可能會決定將自己得到的豐厚獎勵流，轉讓給一個或多個開發者。這種轉讓的管理必須仍然是軟件包維護者和合作夥伴的決定，不受 tea 的干擾。Tea 協議需要提供工具，使這種轉讓可以是全部或部分的（也許只通過一部分 steeping 獎勵，被重新定向到一個或多個開發人員，而其餘的獎勵繼續流向原來的包維護者），並使 steeping 獎勵通過單個網絡參與者控制的單一賬戶、多個網絡參與者，或使用靜態或動態比例自動分配到多個賬戶。

10.3 多個開源軟件維護者之間的獎勵分配

一個軟件包的維護可以依靠多個開發者團隊的工作。在 Tea 的獎勵開始流轉之前，團隊應該考慮如何在彼此之間自動分配獎勵，如何分配必須由維護者自己決定，因爲他們最有資格評估誰做出了貢獻，以及他們應該如何得到獎勵。爲了達到這個目的，每個團隊（或多個團隊）可以建立自己的去中心化自治組織（DAO），並自動分配獎勵或部署更復雜的系統，根據外部因素決定適當的獎勵分配，如所有 DAO 成員的投票，或基於持續貢獻的時間分配，成功完成就可以獲得賞金等等。

10.4 處理軟件包的分叉（Fork）

我們認爲分叉是必要的，但在很大程度上沒有得到充分利用。Fork 可以成爲開發軟件包在功能、性能、安全，甚至是吸引關注方面具備強大競爭力功能的有效工具。儘管它們可能很有用，但分叉也必須承認原本的貢獻。要通過未來的工作或潛在的貢獻，Tea 社區可能會加強系統，以要求分叉的聲明，甚至可能在提交軟件包時檢測到。由鑑定師發現的，未申報的分叉可能會導致部分 Steeping 的代幣被削減，轉給原始包的維護人員，併發送給發現分叉的鑑定師。

10.5 運行與構建的軟件依賴關係

tea 在啓動時分配獎勵時，可能不會區分構建的依賴項和運行時的依賴項。然而，如果 tea 社區強烈要求進行這樣的區分，tea 社區可以提議對 Steeping 獎勵的分配算法進行強化，以考慮每個依賴的重要性以及它們對依賴包的價值貢獻。這些提案將根據社區的決策，進行投票和實施。

10.6 基於應用的報酬

隨着越來越多的應用程序使用在 tea 註冊的軟件包所構建的，社區可能會增加獎勵算法，以便分配可以受到外部認證的數據集的影響（例如使用情況的數據集）。這種獎勵機制的更新，可以讓更多的 tea 代幣獎勵流向使用率最高的軟件包，同時仍然尊重茶葉代幣部分描述的浸泡比例的限制。軟件包維護者可以使用類似的方法，根據他們選擇的透明邏輯，在他們的依賴關係中分配 steeping 獎勵。請注意，所有用於影響茶葉系統中包和依賴關係的獎勵分配的信息，都需要先被認證爲是可靠的。

11. 術語表  

參考資料：

1. https://github.com/teaxyz/white-paper

2. https://creativecommons.org/licenses/by-sa/4.0/

3. https://nvd.nist.gov/vuln/detail/CVE-2021-44228

4. https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA

5. https://twitter.com/yazicivo/status/1469349956880408583

6. https://www.w3.org/TR/did-core/

7. https://www.theregister.com/2016/03/23/npm_left_pad_chaos/

8. https://fossa.com/blog/npm-packages-colors-faker-corrupted/

9. https://www.lunasec.io/docs/blog/node-ipc-protestware/

10. https://github.com/dominictarr/event-stream/issues/116

11.https://blog.npmjs.org/post/163723642530/crossenv-malware-on-thenpm-registry.html

12. https://www.zdnet.com/article/open-source-software-how-many-bugs-arev hidden-there-on-purpose/

13. https://threatpost.com/backdoor-found-in-utility-for-linux/147581/

14. https://www.fbi.gov/news/stories/phantom-secure-takedown-031618

15.https://www.europol.europa.eu/media-press/newsroom/news/800-criminalsarrested-in-biggest-ever-law-enforcement-operation-against-encryptedcommunication

16.https://medium.com/intrinsic-blog/compromised-npm-package-eventstream-d47d08605502

17. https://semver.org/

18. https://www.npmjs.com/package/lodash

19. https://www.npmjs.com/package/chalk

20. https://www.npmjs.com/package/log4js/21. https://arxiv.org/abs/12    

原文來源

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia