diff --git a/i18n/zh-cn/metadata.yml b/i18n/zh-cn/metadata.yml new file mode 100644 index 0000000..7ae590e --- /dev/null +++ b/i18n/zh-cn/metadata.yml @@ -0,0 +1,67 @@ +title: 开源生态系统的去中心化奖励协议 +abstract: > + 为所有开源软件创建一个公开、开放且稳定的注册表，允许项目独立发布版本并依赖第三方。 + 通过将这些不规则的数据组合成数百个独立（和重复）系统，包维护人员将发布基于区块链驱动的去中心化注册表， + 以提高对拜占庭式错误的容忍度，并消除独特错误来源，从而实现启动过程的一致性，并使社区能够自主管理其本地开源生态系统，与外部议程无关。 + + 通过允许参与者积极参与，鼓励开源维护者将赌注押在他们所依赖和希望保护的软件包上。 + 协议图提供了不可变包、需求日志的依赖关系、软件包真实性以及通知算法使用提示 tea 的报酬。系统性通胀分布基于该算法应用于所有一揽子计划中。 + 如果遇到安全或开发问题，开发人员可以提出有证据支持的索赔请求，并可能面临处罚。 + 代码社区成员Open可以检查软件包质量问题，协议则通过执行相应的惩罚事件来回应这些审查。 + +author: +- Max Howell +- Timothy Lewis +- Thomas Borrel +references: +- id: sources + url: https://github.com/teaxyz/white-paper +- id: cc + url: https://creativecommons.org/licenses/by-sa/4.0/ +- id: nist + url: https://nvd.nist.gov/vuln/detail/CVE-2021-44228 +- id: reuters + url: https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA +- id: twitter + url: https://twitter.com/yazicivo/status/1469349956880408583 +- id: w3 + url: https://www.w3.org/TR/did-core/ +- id: theregister + url: https://www.theregister.com/2016/03/23/npm_left_pad_chaos/ +- id: fossa + url: https://fossa.com/blog/npm-packages-colors-faker-corrupted/ +- id: lunasec + url: https://www.lunasec.io/docs/blog/node-ipc-protestware/ +- id: github + url: https://github.com/dominictarr/event-stream/issues/116 +- id: zdnet + url: https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/ +- id: threatpost + url: https://threatpost.com/backdoor-found-in-utility-for-linux/147581/ +- id: fbi + url: https://www.fbi.gov/news/stories/phantom-secure-takedown-031618 +- id: europol + url: https://www.europol.europa.eu/media-press/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication +- id: medium + url: https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502 +- id: semver + url: https://semver.org/ +- id: npmjsCrossenv + url: https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html +- id: npmjsLodash + url: https://www.npmjs.com/package/lodash +- id: npmjsChalk + url: https://www.npmjs.com/package/chalk +- id: npmjsLogFourjs + url: https://www.npmjs.com/package/log4js/ +- id: arxiv + url: https://arxiv.org/abs/1207.2617/ +- id: web3 + url: https://research.web3.foundation/en/latest/polkadot/overview/2-token-economics.html +header-includes: +- \usepackage{fancyhdr,ragged2e} +- \lhead{\parbox[t]{0.5\textwidth}{\RaggedRight\rightmark\strut}} +- \rhead{\parbox[t]{0.5\textwidth}{\RaggedLeft\leftmark\strut}} +- \setlength{\headheight}{5\baselineskip} +- \pagestyle{fancy} +- \fancyfoot[LE,RO]{© 2022 tea.inc.} diff --git a/i18n/zh-cn/white-paper.md b/i18n/zh-cn/white-paper.md new file mode 100644 index 0000000..3978c72 --- /dev/null +++ b/i18n/zh-cn/white-paper.md @@ -0,0 +1,390 @@ +--- +说明: 版本 2.1.0 +--- + +# 白皮书 + +## 一个去中心化的协议，让开源开发者捕捉他们创造的价值 + +- Max Howell +- Thomas Borrel +- Timothy Lewis +- Troy Wong + +## 摘要 + +一个开源开发者可以根据其贡献获得相应奖励的系统将提高软件供应链的可持续性和完整性。 +通过制定一项权力下放计划，结合名誉和激励措施，可以促进累积价值回报等开源开发者对未来公共效益数据库的维护，从而推动创新和增长开源生态系统内部。 +包维护者将注册他们的项目到一个由容忍拜占庭式错误的区块链驱动注册表中。该协议采用独特的“贡献测试”算法来确定每个项目对系统可用性和健康状态的贡献与影响。 +登记领取赏金项目协议 TEA 适配于相应贡献，并通过 stake 投保者、受益声誉系统等项目选择使社区治理开源生态系统地域化，无论外部议程如何。 +该协议鼓励参与者维护开源，并允许注册项目并遵守网络规则以获取奖励，并为自身及所属项目建立声誉做出贡献。 +如果发现安全或开发问题，开发人员可能会针对该包提出有证据支持的声明，并可能引起斜杠事件。 +成员可以检查包装品质问题，协议可通过执行相应斜杠事件来响应这些检查。 + +## 免责声明 + +本技术文件中提供的信息为初步资料。因此，无论作者与会员是否承担责任最终使得这里的资料正确性，每一位前任推开，在适用法律允许的最大范围内，所有责任均将由其自行承担，无论是侵权、合同或其他方式都与该技术文件有关。本技术文件及其中包含的内容不构成或应被视为与任何类型合同或承诺相关，也不作为订立任何类型合同或承诺的诱因。 + +本技术文档中的任何内容均不构成对此处讨论代币的出售要约或购买要约。在任何情况下，如果将此技术文件视为故意提供或请求、建议或传播该技术文件在任何管辖范围内，都是非法行为，因为这可能需要申请执照、注册或受限地区的投标申请。特别是针对每个代币进行讨论时，请注意此技术文件没有日期，并且不打算根据证券法律进行注册或类似法律管辖权，无论这些代币是否被视为具有价值或类似工具并在任何管辖范围内提供或销售，这样做都将违反相关法律规定。除非您准备承担全部购买价格的风险，请勿购买任何代币。这种购买属于高风险操作，如遇问题，则可能无法获得保护。 + +## 许可证 + +本文档在以下许可下可用[Creative Commons Attribution-ShareAlike 4.0 International license](https://creativecommons.org/licenses/by-sa/4.0/). + +## 前言 + +现代互联网主要由开源项目构建，这一情况从一开始就存在。开源项目通过全球开发者社区的协作开发和维护，其源代码库被作为公共产品可供任何人使用。在过去 80 年中（被普遍认为是自由和开放源码软件的先驱，始于 1953 年），创新精神已经将开源软件从利基技术爱好者转变为广泛应用的基础设施。尽管开源软件至关重要，但那些创建和维护源代码库作为公共服务的开发者并没有因其作为创新者和维护者所做出的巨大贡献而获得相应奖励。 + +企业软件已经成为一个价值数十亿美元的产业，它是建立在开源基础之上的。然而，对于无私地维护自身基础设施的个人来说，几乎没有任何价值积累。尽管开源软件已经创造了巨额利润，但其主要作为一种公共服务被创建和维护，并且缺乏可行的方式让开发人员捕获他们所创造的价值。 + +我们认为，仅依靠世界上一小部分工程师出于利他主义而维持开源软件，限制了现代互联网的潜力。开源是一项充满热情的工作，但常因缺乏对主要维护者的重大激励而受到阻碍。开源开发人员必须在提供体面薪酬的日常工作和维护企业软件之间做出选择。缺乏激励将导致真正有价值的项目无法实现其潜力，同时其他项目也会因在软件生命周期中缺乏维护而遭受安全问题。为了充分发挥整个开源社区的潜力，我们需要一种全民参与评估项目“公平价值”的方法，并确保开源开发者能够捕获创造价值并促进资本流入该社区的基本原则不改变如何发展和使用开源。 + +公司常采用开源商业模式，直接从善意开发人员的工作中获得收入，并依赖他们在出现错误时进行纠正。开放源码库为企业提供即插即用的核心功能；然而，软件漏洞可能给基于开源构建的应用程序带来巨大风险。一个很好的例子是最近发生的涉及 Log4j 的重大安全漏洞的事件，Log4j 是一个来自 [Apache 软件基金会](https://www.apache.org/) 的包，在企业和政府使用的许多商业软件和服务中都发现了它。2021 年 11 月，一名为[阿里巴巴集团控股有限公司](https://www.alibabagroup.com/)工作的安全研究员报告了一个漏洞[CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228)，该漏洞获得了 Apache 软件基金会可能的最高分。 [Tenable](https://www.tenable.com/) 首席执行官兼美国计算机应急响应小组(US-CERT)创始主任阿米特·约兰(Amit Yoran)将此漏洞描述为“[过去十年中最大、最关键的一个漏洞](https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA)”。 +恐慌随之而来，维护这一方案的少数志愿者因失败而受到公开抨击。在以谦逊的公平请求解决了愤怒之后，系统得到了修补。企业和政府最终意识到，Log4j 这个被广泛的关键系统使用了 20 年的软件包，是由一些没有报酬的志愿者维护的，这些无名英雄不顾[行业的滥用](https://twitter.com/yazicivo/status/1469349956880408583)挺身而出，不知疲倦地努力解决漏洞。 + +遗憾的是，Log4j 远不是唯一的例子。core-js 作为每个 Node.js 应用程序的基础，每周下载量为 3000 万次，但它也几乎没有资金，这可能迫使它的主要维护者离开项目，甚至将[许可证更改为闭源](https://www.thestack.technology/core-js-maintainer-denis-pusharev-license-broke-angry/)。最近，几名比特币核心开发者辞职，理由之一是他们的决定得不到经济补偿。 + +

Figura 1 - Dependencia - Fuente:https://xkcd.com/2347/

+ +人们曾多次尝试提供激励机制，通常包括赞助和赏金制度。赞助使得开源的消费者可以向他们喜欢的项目捐款。然而，如果把开源想象成一座砖塔，底层早已被遗忘，但仍然由敬业的工程师维护，并被更多的开发人员所依赖。只有在塔顶的项目通常是已知的，并得到赞助。这种有偏见的选择导致支撑塔楼的基本砖块没有吸引到任何捐赠，而最受欢迎的砖块则得到更多。同样，只奖励最喜欢的人。 + +在茶会上，我们看到太多的开源项目在支持开源社区的尝试中失败了，我们的使命是通过允许开源开发者获取他们创造的价值来增强软件供应链的可持续性和完整性。 + +在本文中，我们提出了茶——一个去中心化的系统： + +1. 计算并为与整个生态系统相关的每个开源项目分配一个“[贡献证明](white-paper.md#proof-of-contribution)”。 +2. 确保开源软件项目得到良好维护。 +3. 通过在茶叶登记的每一项中实施茶叶奖励算法，为开源开发者提供与生态系统范围内的贡献相称的公平奖励。 +4. 鼓励网络参与者遵循负责任的漏洞和漏洞披露实践。 + +## 组件 + +构建应用程序的软件开发人员需要四样东西:浏览器、终端、编辑器和包管理器。在这四种工具中，包管理器控制开发人员构建产品所需的工具和框架。在这一层，我们看到了改变开源保护和奖励方式的潜力。 + +### 包管理器 + +包管理器知道软件包或应用程序的功能依赖于什么开源软件，从塔顶到塔底。每个项目，连同每个打包的版本，都一丝不苟地记录了所有基本组件及其相应的版本。 + +它知道塔顶仔细地选择了它的依赖，这种仔细的选择继续向下。包管理器被独特地放置在开发人员工具栈中，以支持基于实际贡献的自动化和精确的值分发。 + +我们提出了一个不可变的去中心化注册表，旨在基于 tea 协议独特的“贡献证明”(Proof of Contribution)来分配价值，这是一种确定每个项目对系统效用和健康的贡献和影响的算法。值可以在顶点(例如基本库)进入图，并递归地分发到这些包的依赖项及其依赖项，因为注册中心知道整个开源图。 + +此外，我们认为协议的贡献证明提供的信息必须可供开发人员评估他们是否可以信任项目及其作者。这些信息可能基于声誉，社区荣誉，从分散身份(“[DID](https://www.w3.org/TR/did-core/)”)系统检索的数据，其他包管理器或激励机制，这些机制可能依赖于网络参与者将价值置于风险之中。 + +我们预测，tea 的工具、信息和奖励组合将公正地激励开发人员，帮助确保软件供应链的安全，刺激开源软件的增长，并促进创新。 + +### 去中心化注册 + +每个包管理器都有自己的包注册表，重复复制相同的元数据。在某些情况下，该注册表可能包含[与项目清单不同的信息](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/)，从而允许不良行为者在用户不知情的情况下潜在地注入恶意代码。现在是时候有一个单一的、全面的、明确的登记处，由依赖它的社区设计和管理。这种分散的、不可变的注册表可以提供安全性、稳定性和防止恶意意图。 + +互联网运行在成千上万个重要的开源组件上。值得注意的是，到目前为止，由于移除重要的开源基础设施而引起的事件已经很少了。最著名的是在 2016 年[删除了 NPM 的左键依赖](https://www.theregister.com/2016/03/23/npm_left_pad_chaos/)，它会导致持续集成和持续部署系统，让开发人员陷入困境。这一事件表明，互联网本身是建立在脆弱的发展系统之上的。其他例子包括包维护者主动或故意参与破坏他们的流行包(参见[colors.js 和 fakers .js](https://fossa.com/blog/npm-packages-colors-faker-corrupted/)，以及 [node-ipc](https://www.lunasec.io/docs/blog/node-ipc-protestware/))，或者恶意行为者通过假装帮助维护包并破坏它们来窃取，例如，比特币私钥(参见[event-stream](https://github.com/dominictarr/event-stream/issues/116))，或者故意拼写错误的恶意包，也称为“[typposquatting](https://en.wikipedia.org/wiki/Typosquatting)”，希望欺骗用户安装它们。例如[跨环境与跨环境的 NPM 包](https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html)。 + +随着行业朝着数字资产成为软件一部分的未来发展，软件的完整性需要得到保证。我们不能继续让自己容易受到恶意行为者修改软件的攻击。 + +我们称为包管理器的大多数工具不能保证这些内置于应用程序和 dapp 中的包是由其原作者发布的未经修改的开源代码。[微软的 GitHub 发现软件中有 17% 的漏洞是出于恶意目的而植入的](https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/)，有些漏洞在很长一段时间内未被发现(参见[Webmin 1.890](https://threatpost.com/backdoor-found-in-utility-for-linux/147581/))。 + +一个由声誉系统增强的全球去中心化注册，并由旨在揭露坏人和奖励好人的激励机制支持，可能会为开发人员社区提供一直在寻找的保证，以确保软件供应链的安全。 + +### 存储系统 + +开源项目提供了广泛的功能，其中一些可能是受限的或不需要的。加密就是一个很好的例子。加密的一个关键用例是支持全球范围内的个人隐私。然而，加密也可以用于邪恶目的(参见[幻影安全](https://www.fbi.gov/news/stories/phantom-secure-takedown-031618)，执法机构于 2018 年 3 月拆除)或可能被破坏以支持执法活动(参见[运行 Ironside(法新社)，运行绿光(欧洲刑警组织)和运行特洛伊盾(FBI)](https://www.europol.europa.eu/media-press/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication)，其中 FBI 操作“加密”通信平台 AN0M，并说服犯罪分子使用“加密”手机进行安全通信)。 + +加密的广泛应用使其成为开源软件的完美用例，也是一个很好的例子，说明任何存储软件包的解决方案都必须是防篡改和抗审查的。Tea 是一个去中心化的协议，它不打算根据包的功能来过滤或制裁包。虽然 tea 治理可以选择删除经过验证的恶意包(有关更多信息，请参阅[治理部分](white-paper.md#governance))，但对于 tea 系统来说，连接多个存储系统是至关重要的，包括证明包未被更改并正确复制的分散存储系统。包维护者可以选择最适合他们安全存储和分发包的存储系统。 + +## 协议概述 + +设计一个奖励开源贡献的协议是一个艰巨的挑战。开源软件是普遍可访问的，但容易受到错误归属、挪用和恶意篡改的影响。然而，开源社区始终如一地表明，它愿意突出好的参与者，揭露坏的参与者。从历史上看，花费在审查和评论其他开发人员的贡献上的精力是严格自愿的，尽管报告和捍卫发现可能是多么耗时和关键。 + +我们打算创建一个由声誉和激励保护的去中心化协议，通过允许开源开发者以一种无需信任的方式获取他们创造的价值，从而增强软件供应链的可持续性和完整性。我们相信，如果没有声誉系统和社区成员交流他们的发现和对项目或开发人员工作的支持(或异议)的能力，对开源贡献的充分奖励就不可能成功。此外，我们必须为开发人员提供工具来访问和贡献这个声誉系统。这些工具包括对项目中所有依赖项的版本和声誉的简单可视化和可编程访问。 + +社区成员为支持每个项目而投入的 TEA 代币的透明度提高了每个项目的声誉，就像一个包维护者在自己的工作中投入的代币数量表明了他们对项目的承诺一样。这些综合数据点将有助于告知所有社区成员的声誉系统，并促进选择。由于[事件流包攻击](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502)不是通过包本身进行的，而是通过它的一个依赖项进行的，因此跨所有依赖项层的可见性对于构建这个无需信任的系统至关重要。然而，在设计和构建系统时，需要优先考虑计算和交易(“gas”)成本。 + +我们的目标是同时奖励 web2.0 和 web3 开发人员。每个堆栈的复杂性和特殊性使得跟踪软件包的安装很容易成为一个或多个不良行为者的牺牲品。这包括“购买”设备以人为地夸大数字。更糟糕的情况是，通过与许可密钥或其他部署跟踪机制产生不必要的摩擦，对开源软件的本质进行根本性的改变。为了提供最广泛的覆盖范围，我们认为奖励不应依赖于跟踪安装的简单概念，而应依赖于鼓励提交优质包和报告恶意或高风险包的激励机制。最后，许多包依赖于共同的依赖项。例如，[lodash](https://www.npmjs.com/package/lodash)有 176,308 个开源依赖项，而[chalk](https://www.npmjs.com/package/chalk)有 100,247 个依赖项，或[log4js](https://www.npmjs.com/package/log4js/)有 3,809 个依赖项。当使用相同的依赖项创建更多的包时，我们如何确保奖励公平地分配?我们如何确保最常用的依赖项得到奖励，而不会饿死新的或新兴的软件包和开发人员?我们如何确保激励系统不会最终引导开发人员远离利基语言，而将他们集中到激励更好的地方?但是，作为开发人员，我们如何识别最依赖的包来构建替代品——这些包的更精简、更高效、编码更好的版本? + +在茶，我们认为缺乏可见性和激励阻碍了开源软件的发展。在适当的激励和奖励的支持下，更多的开发人员将能够构建、改进和扩大开源软件，以改善世界。 + +### 贡献证明 + +在本白皮书中，我们提出了“贡献证明”，这是一种新的共识机制，旨在量化所有开源系统中所有项目的影响。 + +贡献证明根据每个开源项目内部的方向以及长期以来更广泛的开源生态系统的利用率，分配一个动态分数，称为项目的 teaRank。 + +我们相信，这种方法有利于远离应用层的基础软件(应用层往往是公众最可见的层，吸引了大部分的兴趣)，并扩展了奖励机制，以确保项目的所有组件——从树的顶部，一直到它的基础——都因他们的贡献而得到奖励。 + +为了计算每个项目的分数，teaRank 建立在[Google 的 PageRank](https://en.wikipedia.org/wiki/PageRank)算法奠定的基础上。谷歌的 PageRank 是搜索产品的定义组件，建立在网页的图形结构上。PageRank 的核心是一种概率分布算法，它将分数分配给图中的节点，表示任何随机导航到图中特定节点的可能性。这种算法在类似图的数据结构中特别有效，比如互联网，因为它根据边(链接)的数量和质量来量化每个节点(或网页)的影响。随着时间的推移，该算法被修改，以更好地识别网络的拓扑结构，并识别网页之间的欺诈链接，从而减轻各种攻击。 + +由于互联网的图形结构和茶协议的去中心化注册表有着惊人的相似之处，PageRank 最初似乎是一种很有前途的分析方法。然而，经过进一步的实验，PageRank 的反垃圾邮件策略显然在应用于开源时效果不佳。 + +关键的区别在于开源软件的元数据。与网页不同，大多数开源包元数据，如代码行和提交消息，都是用户生成的，容易受到欺骗。包管理器很容易受到垃圾邮件活动的攻击，其中恶意行为者向注册表发送包含网络钓鱼链接或其他有害内容的包。包管理器注册表也可能不准确地反映特定项目的依赖关系。这个被称为“[明显混淆](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/)”的问题可能会允许恶意行为者注入恶意代码或人为地夸大第三方依赖的影响，通常是出于恶意目的。 + +识别和处理这些垃圾邮件包的艰巨任务通常落在安全公司或无私的个人身上，两者都没有提供一个可扩展的解决方案来对抗开源的垃圾邮件攻击。 + +贡献证明是一种算法，专门用于识别和隔离垃圾邮件包，并确保只有有影响力的项目才能获得公平的奖励。贡献证明算法的细节将是专门技术论文的主题。 + +### 网络参与者 + +在本白皮书中，我们通过参与者的贡献来区分他们。有些人可能会贡献代码或验证所贡献的代码。其他人可能会支持开发者和他们的声誉。 + +#### 包维护者 + +Tea 假设包创建者维护他们的工作。在本白皮书中，我们将把他们称为“包维护者”。 + +软件包维护者必须确保他们的软件随着行业的发展而不断地交付越来越多的价值。他们是开源社区的支柱，他们的持续贡献需要得到授权和奖励。然而，包维护者可能决定停止他们的维护工作，或者意识到他们不能以符合项目用户期望的速度运行。为了确保连续性，他们必须有能力将项目的控制权转移给另一个开发人员或开发人员组，从而任命他们为维护者，并授予他们对与项目相关的现有和未来奖励的所有权和控制权。 + +似地，开发人员可能决定承担包维护者的角色，通过将现有项目分叉并注册一个他们将继续维护的新项目，从而成为包维护者。一旦注册，其 teaRank 超过治理定义阈值的项目开始通过协议的贡献证明算法从 tea 协议获得奖励，与遗留分叉项目并行。随着开源社区从遗留项目转向更新的迭代，贡献证明算法将逐渐减少分配给遗留项目的奖励，同时增加分配给新分叉项目的奖励。 + +必须为开发人员社区提供正确的工具，以确定哪些项目正在维护，以及它们过去和现在的维护者的声誉和工作质量。我们经常看到开源工作被篡改，许多人的努力被坏人破坏。尽管这些不良行为者的工作在很大程度上是被发现和补救的，但通常要等到经济或数据损失造成重大损害时才会发现。以每周下载超过 150 万次的[event-stream npm 包](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502)为例，当黑客设法渗透到开源项目中，获得原作者的信任，并修改事件流，使其依赖于将比特币钱包凭证泄露到第三方服务器的恶意包时，超过 1500 个包依赖于此。尽管工具可以帮助检测这些攻击中的一些，但它们并不总是可靠的，这就创建了一个依赖于彼此的勤奋和分享发现的意愿的整个社区。 + +我们建议通过“[TEA token](white-paper.md#tea-token)”一节中描述的 TEA 代币引入激励措施，以鼓励开源社区建设性地报告他们的发现，以便软件包维护者可以在它们被利用之前解决它们。 + +#### 包的使用者和茶社区成员 + +“包的使用者”是专注于解决特定问题的软件开发人员。他们经常在开源社区中寻找他们需要的工具，以快速实验和迭代，几乎没有成本，直接受益于包维护者的工作。 + +在前 30 个包管理器中有超过 1000 万个可访问的包，缺乏对开源项目的普遍价值归属可以将安全高效的开发包的选择转变为高风险和令人生畏的努力。由于没有可识别的方法来定义和度量价值，包用户如何有效地为他们的开发选择安全的包? + +我们相信，tea 协议的贡献证明算法与其他激励措施相结合，可以为包用户提供他们需要的信息，以便快速周到地选择自己项目的基础。 + +#### 项目的支持者 + +在 Web 2.0 和 web3 中，软件包用户的一个子集，通常被称为“赞助者”，选择通过捐赠或其他形式的报酬来支持软件包维护者。然而，这种情况很少出现。 + +这些“项目支持者”是使用开源软件构建其商业产品的组织或开源项目用户，希望支持生态系统的慈善家，或者希望资助团队开发更大系统组件的企业家。 + +Tea 建议将开源项目支持者社区扩展到整个茶社区，无论是组织、开发人员、用户还是技术爱好者。Tea 的目标是通过 TEA 代币的独特用例，为茶社区的任何成员实施去中心化激励机制，为开源的永久可持续性和持续增长做出贡献。项目支持者可以根据他们的工作、信念或任何影响他们决定的标准和度量来自由地决定他们想要支持哪个项目或包维护者。此外，项目支持者可以自由决定他们想要如何支持这些项目。 + +赞助可以成为支持开源开发的有效系统。然而，这些赞助通常不会扩展到所有依赖项。这种限制有利于偏爱者，但阻碍了创新和软件构建。为了努力成为软件开发的基础，开源必须赋予所有开发人员权力，无论是初学者还是专家，跨越各个层次。 + +为了支持软件供应链的可持续性和完整性，并使开源开发者能够获得他们创造的价值，tea 的目标是建立支持有利于项目所有方面的机制。来自支持者的支持将贯穿项目的依赖关系，从树的顶部到底部。这隐含地信任了包维护者对他们的堆栈做出明智选择的能力，从而提高了他们的声誉。 + +

Figure 2 - Rewards distribution across dependencies

+ +#### 品茶师 + +当新项目或现有项目的新版本发布时，需要证明工作的有效性。这些信息对于包用户决定他们是否可以信任包及其维护者至关重要。在茶礼仪中，这个功能是由“品茶师”提供的。 + +品茶师通常是经验丰富的软件开发人员，他们愿意花一些时间来检查与包相关的声明(功能、安全性、[语义版本控制](https://semver.org/)、许可证准确性等)，并将他们的声誉和 tea 代币押在一起，以展示他们的研究结果并支持他们的评论。在茶协议中，“下注你的茶”是锁定 tea 代币以支持你的评论的过程，可能会获得奖励或面临基于对你的评论质量的共识的惩罚。品茶者还可以选择秘密地向包管理器报告错误或漏洞。有效的报告导致项目资金的奖励，而无效的报告导致品茶者的股份被没收。最后，如果包维护者忽略了这些报告的问题，它将触发对项目资金的惩罚或“削减”。 + +像项目支持者一样，品茶师可以影响项目和包维护者的声誉。然而，考虑到它们在验证项目的安全性、功能和质量方面的作用，它们的影响更为重要。品茶师也需要建立自己的声誉来支持他们的主张。他们的工作质量和他们所冒的风险，因为他们将他们的评论与其他外部数据源相结合，将建立每个品茶者的声誉，为他们的工作带来更多价值。请参阅“[Package & Package 维护者声誉](white-paper.md#%E5%8C%85%26%E5%8C%85%E7%BB%B4%E6%8A%A4%E8%80%85%E7%9A%84%E5%A3%B0%E8%AA%89)”一节，了解用于影响项目和包维护者声誉的机制的更多细节。 + +### 项目注册和贡献奖励证明 + +一个项目发布的注册需要多个事务自动发生。具体地说: + +- 包维护者必须在去中心化注册中心注册项目。 +- tea 协议必须实例化一个由包维护者根据包维护者定义的规则拥有、控制和配置的项目库。 +- tea 协议必须在以太坊命名服务(ENS)中注册国库的唯一名称，从而简化用户与国库的所有交互。 + +任何一个操作的失败都将导致协议恢复到之前的状态。 + +当一个项目成功注册到一个超过治理定义阈值的 teaRank 时，tea 协 议启动向项目库分配贡献证明奖励。我们建议按照由 tea 协议控制的预定义代币池中的预定曲线分配这些奖励，并从 tea 代币总供应量中分配。 + +软件包维护者需要通过持续地将项目资金库收到的贡献证明奖励的一部分作为赌注来支持其项目的声誉和可信度。对于每个代币，网络参与者将以 1:1 的比例获得不可转让的“有价值的 TEA”或 stTEA，以参与茶叶协议的治理。根据协议的规则，如果包维护者未能解决错误或漏洞，这些赌注奖励及其相应的 stTEA 可能会减少(“削减”)或重新分配。 + +最后，未能保持治理规则中定义的最小股权资金比率将导致项目的贡献证明奖励分配暂停。相反，这些奖励将在符合要求的项目中重新分配。 + +### 包&包维护者的声誉 + +仅依赖于作者经济贡献的声誉系统不能提供足够的用户保护，并且可能受到 Sybil 攻击，即单个人创建自己的多个表示，以留下大量对其工作的积极评论，欺骗用户相信他们的工作得到了许多人的审查和批准。 + +有几种方法可用于防止 Sybil 攻击，其中一些方法由 Nitish Balachandran 和 Sugata Sanyal 在“[缓解 Sybil 攻击的技术回顾](https://arxiv.org/abs/1207.2617/)”中描述。由于 tea 是一个去中心化的协议，使用依赖于中心化证书颁发机构的信任认证系统将违背其核心。我们建议将重点放在分散的 Sybil 攻击缓解方法上，更具体地说，是依赖于一大批网络参与者来评估和公开代表每个包及其维护者的声誉的方法。 + +类似于权益证明区块链上的区块生产，非生产节点可以验证其他人的工作，并在必要时突出违反网络规则的行为，从而通过削减(破坏其部分股权)来惩罚不良行为者，我们提出了一个系统，其中第三方，如品茶师，能够审查由软件包维护者制作的软件包，并被激励为开源软件社区及其用户的最佳利益行事，以及识别好的行为和惩罚坏的行为。该系统必须既能抵抗 sybil，又能防止大型代币持有者对协议或特定包的声誉产生实质性影响。我们相信这种方法更符合开源，提供了一个更肥沃的基础来促进采用和信任，并最终促进茶的发展。 + +此外，当茶社区的任何成员的声誉达到关键里程碑时，他们可能被授予访问协议的提升部分。 + +### 第三方审核包 + +第三方对软件包的审查是建立声誉和确保软件供应链安全的重要组成部分。然而，第三方审查也有自己的一套独特的威胁，包括前面提到的 Sybil 攻击。 + +区块链技术，以及更明确的赌注，为茶叶解决这一挑战提供了一个独特的机会。虽然钱包地址可能无限多，但 TEA 代币并非如此，其总供应量预计为 100 亿。此外，开发人员执行的每个操作，例如提交、验证或打包包，都将有助于他们的声誉，从而创建一个独特的配置文件，每个开发人员都可以使用它来为茶社区做出贡献并参与茶的治理。 + +通过要求第三方审查员持有 TEA 代币，并承担失去部分股权的风险，如果他们的行为违背了网络的利益或成为一个不良行为者，第三方可以为一个包提供额外的凭证，并以 TEA 代币的形式获得奖励。 + +我们还建议将信誉系统扩展到对包装进行独立验证的第三方——品茶师。完成一个积极的审查将需要自动执行两个操作: + +- 提交代码审查，由品茶师签名，并向社区的所有成员公开访问。 +- 用木桩固定包裹的行为，以证实他们的审查。 + +完成包含一个或多个关键漏洞的负面审查将要求品茶师首先使用消息传递协议与包维护者联系，通知他们存在漏洞，并允许他们及时解决问题。在分配给包维护者以解决其漏洞的治理定义的期限到期时，或者当纠正的包变得可用时，将使用相同的消息传递协议来通知该包(包括依赖项)的用户和测试人员，漏洞已经被识别出来，并且有希望得到解决，因此他们知道更新他们的应用程序或依赖项。为了防止浪费开发人员的时间，品茶员和包维护者之间的通信将要求品茶师下注 tea 令牌。 + +在完成这两项操作后，品茶师将收到一份 NFT，作为他们在特定包装和包装版本上工作的证据。NFT 的积累，加上每个包装的比例和从外部系统中提取的信息，将告知品茶者的声誉。当他们的声誉达到关键里程碑时，品茶者可以获得协议的提升部分或协议的加速奖励，这由茶治理决定。 + +### 过期或损坏的软件包 + +Tea 的使命是通过允许开源开发者获取他们创造的价值来增强软件供应链的可持续性和完整性。然而，回报必须与包装维护人员和品茶者所付出的努力相称。维护不足、过时或损坏的包清楚地表明，包维护者没有达到社区的期望，或者没有交付信任和支持，这些都是通过包的担保给他们留下的印象。过时软件包的另一种表现形式可能是继续使用遗留语言或多版本语言的遗留版本。包过期或损坏的时间太长表明品茶师需要定期和一致地检查包维护者的工作。 + +品茶师在开源社区中扮演着关键的角色，因为他们的评论和相关声明可以影响包用户，引导他们使用或远离特定的包。为了确保评论能够持续可信，我们提出了一种机制，即品茶者发布的评论必须与有赌注的 tea 代币相关联。过时或损坏的包装可能会被削减一部分资金，而另一部分则被送到第一个发现任何包装缺乏维护的品茶师那里。 + +随着包的流行和使用，越来越多的应用程序和潜在的关键任务系统依赖于它们，我们必须激励开发人员谨慎地向包维护者报告缺陷，并鼓励包维护者在漏洞被利用之前解决这些缺陷。因此，我们建议，任何概述缺陷(如零日漏洞或使用过时依赖项)并在治理定义的宽限期之外保持开放的负面审查都应被视为包维护者的失败，并受到与第一个品茶师相同的惩罚，以报告收到部分削减代币的缺陷。 + +同样的道理也适用于包的支持者，他们把自己的声誉和 TEA 代币押在了拖欠的包维护者的工作上，并因此获得了奖励。由于他们没有发现缺乏维护或选择继续支持一揽子计划，我们建议所有削减活动都延伸到一揽子计划的支持者。 + +分发给所有品茶师可以基于他们评论的年龄和他们为他们的评论下注的 tea 代币的数量。 + +## TEA 代币 + +TEA 是一个加密代币，作为 TEA 协议某些部分和指定功能的访问密钥。 + +TEA 代币的持有者有能力: + +- 登记他们的包裹。 +- 通过将 TEA 代币押注到特定的软件包来支持软件包。 +- 通过挑战软件包和进行审查以报告错误和/或漏洞，为软件供应链的安全做出贡献。 + +如前所述，tea 协议解锁了开源经济，并为企业软件的构建者、维护者和最终用户创造了价值。最终，随着社区规模的扩大，茶叶协议所获得的价值会回馈给代币持有者，从而形成一个反馈循环，进一步激励参与。 + +### 奖励开源开发者 + +我们希望 tea 的贡献证明和赌注机制能够通过赋予参与者所需的资源来促进开源的发展，使他们能够不受阻碍地追求自己的激情。 + +正如“[项目注册和贡献奖励证明](white-paper.md#project-registration-and-proof-of-contribution-rewards)”中概述的那样，使用 tea 协议注册的项目和超过治理定义的阈值的 teaRank 将获得 tea 协议中以 tea 令牌形式的贡献奖励证明。只要包符合协议的规则，这个发行版就会持续存在。具体来说，包必须保持一个高于治理定义阈值的 teaRank，包维护者必须通过不断地将项目资金收到的贡献证明奖励的一部分作为投资，来为他们的项目的声誉和可信度做出贡献。不遵守这些规则将导致暂停分配贡献证明奖励和在合规项目之间重新分配未来奖励。 + +依赖关系会极大地影响包的可靠性和安全性，没有注册包的依赖关系应该被视为一种潜在的风险。作为这些依赖项的验证者和用户，包维护者处于与这些依赖项的维护者联系的最佳位置。他们可以鼓励他们用茶来注册他们的项目，从而使他们受到品茶师的监督，并有资格获得相关奖励。为了鼓励这种旨在增强声誉系统的社区参与，我们建议任何没有在 tea 协议中注册的依赖项包，其贡献证明奖励的一小部分都会被烧掉。这种消耗将与每个未注册依赖项的数量和贡献成正比，并在 teaRank 中量化，只要这些依赖项保持未注册，这种消耗就会持续下去。 + +大量案例表明，强大的激励机制可以诱使恶意行为者破坏开源软件。大多数互联网的关键基础设施都在开源上运行，寻找漏洞和其他漏洞的竞赛正在进行。实际上，我们认为软件包维护者不应该受到指责(尽管他们经常受到指责)。 + +《茶叶议定书》的激励措施通过确保公平公正地分配激励措施来解决这一问题。像 lodash 这样拥有超过 17.6 万个依赖项的软件包是开源开发的支柱，它的维护者应该得到相应的奖励。然而，一个完全建立在依赖者数量上的奖励制度会阻止创新者打破这些垄断，除非他们得到了第三方的足够资助，或者已经积累了足够的资源来自筹资金。这种方法可能会导致贡献者数量的减少，从而导致与茶的本质截然相反的结果。 + +为了解决这一限制，并赋予每个 TEA 令牌持有者支持包维护者的能力，我们还建议将所有网络参与者收到的所有权益奖励的治理定义的一部分，直接用于权益包的库，以及它的依赖项。 + +### 押注确保软件供应链的安全 + +赌注可以是一种有效的方法来支持分散的声誉系统。然而，为了保证软件供应链的安全，茶叶激励分配系统必须仔细考虑每包的股权比例，并相应地调整每包的激励。 + +为了减少在许多应用程序中作为依赖项使用的少量包的风险，我们建议实现最佳的赌注比例，类似于[由 web3 基金会产生的研究](https://research.web3.foundation/Polkadot/overview/token-economics)中描述的方法。 + +当一个包超过治理定义的最佳下注比例时，分配给该包的下注奖励总额将保持固定，而与该包下注的 TEA 令牌数量无关。这一措施旨在减少包装支持者和品茶者对高赌注包装的进一步下注，将导致每个包装支持者收到的下注奖励线性减少。 + +基于曲线的方法，例如 web3 基金会的研究中描述的方法，将减缓分配给包的赌注奖励池的减少，从而继续从较小的赌注包中抽走，并通过赋予大型代币持有者对赌注奖励池分配的更大影响力来引入负外部性。 + +推荐的线性设计应该允许较少的赌注包装变得更有吸引力的包装支持者和品茶师。它还可以激励有经验的开发人员构建高风险软件包的替代方案，为茶社区创造一个平衡支持现有软件和促进创新的机会。在其初始设计中，将使用循环供应来计算加注比。茶社区可能会改变这种设计，以进一步提高系统的可扩展性。 + +就像好的演员需要得到奖励一样。不良行为者需要被识别和惩罚。开源软件为不良行为者提供了许多机会，为整个开发人员社区创造痛点和声誉风险。从滥用工作成果到修改和重新分发软件包，或者注入恶意代码，好人和坏人之间的战争仍在继续，通常是资金充足的坏人将开源软件包的污染视为谋取经济利益的机会。负面影响相对较小，这些包装可能会被禁止上架，或者名声不佳。 + +为了直接解决恶意行为者并加强对违反开源行为的影响，我们建议实现“[第三方包审查](white-paper.md#package-review-by-third-parties)”和“[过时或损坏的包](white-paper.md#outdated-or-corrupt-packages)”部分中详细介绍的削减机制。 + +当品茶师评估和分析新提交的包中的代码时，我们建议品茶者获得工具和奖励，以查明并突出显示恶意代码： + +- 包用户可以意识到风险。 +- 包维护者和包支持者会因提交或支持恶意代码而受到处罚。 + +在这种程度上，对于所有根据网络规则执行的负面评论，并且包维护者已经在治理定义的期间内处理了这些负面评论，包维护者不应该受到任何与包支持者或对有问题的包提供积极评论的品茶者相反的惩罚。 + +对于按照网络规则执行的负面评论，以及包维护者没有在治理定义的期限内解决的问题，项目资金、包支持者和以前的试茶者所持有的一小部分 TEA 代币将被削减，并发送给识别错误或漏洞的试茶者。另一部分将被锁定在茶治理控制的保险池中。茶治理将与社区密切合作，制定政策和规则，将池中的内容分发给受脆弱性影响的人。该协议将把被削减的 TEA 代币的三分之一分发给所有参与负面评论的品茶师。 + +押注和削减是《茶叶议定书》奖惩制度的重要组成部分。包维护者被要求拿出一部分项目资金，以确保他们在忽视处理 bug 或漏洞的情况下有相当大的风险。软件包用户、支持者和品茶者也可以下注 TEA 代币，为软件包或软件包维护者的声誉做出贡献，并积极参与协议，以维护软件供应链的可持续性和完整性。 + +治理与这种积极参与密切相关。对于每个押注的 TEA 代币，参与者以 1:1 的比例接收不可转让的“押注 TEA”(stTEA)，使他们能够参与茶叶协议的治理。如果不遵守协议规则，权益奖励及其相应的 stTEA 令牌可能面临减少(削减)或重新分配，从而加强生态系统内的问责制。 + +### TEA 代币供应分布 + +该协议创建的大多数 TEA 令牌被用作激励措施，以鼓励软件包维护者、用户和支持者执行为去中心化网络提供价值的活动。将 TEA 令牌分发给协议内的各种利益相关者是由“分发时间表”决定的。 + +网络奖励将通过 tea 协议以 tea 代币的形式直接分配给四组利益相关者: + +- 包维护者 +- 包的使用者(包括茶社区的所有成员) +- 项目支持者 +- 品茶师 + +TEA 代币还将用于支持软件包并通过下注来保护软件供应链，包括通过审查和报告错误或漏洞来挑战软件包的权利，奖励注册项目的开源开发人员，并参与 TEA 协议的治理。 + +建议在茶社区的所有成员中分配 100 亿的最大代币供应量，如下所述: + +

Figure 3 - Token distribution of maximum supply

+ +最大代币供应量的大约 51.4% 应分配给“生态系统与治理”，其中包括激励开源项目加入并维护其代码库，以及通过茶 DAO 为分散投票和共识做出贡献的奖励。分配给“生态系统和治理”的代币应该作为贡献证明奖励、赌注奖励和其他类型的以开发者为中心的激励来分发。 + +最大代币供应量的大约 18.6% 应分配给“协议开发”，以确保茶协议的可持续性和持续发展。大约 12.7% 的资金应该专门用于“早期支持者和顾问”。大约 11.0% 应指定用于私人销售，3.0% 用于公开销售，而剩余的 3.2% 应分配用于支持一旦代币生成事件发生的市场流动性。 + +详细的代币经济学，包括全面的代币分发和排放时间表，将是一篇专门论文的主题。 + +## 治理 + +治理对于任何分布式系统的开发、可持续性和采用都是至关重要的。 + +我们建议 tea 协议纳入治理机制，使持有 tea 代币的活跃贡献者能够就非金融关键参数更改提出建议和投票。投票过程将由 stTEA 代币所有权和个人声誉加权。 + +协议参数可能包括支持特定包管理器或引入新协议特性或功能的优先级，以及外部因素对用户和包声誉的影响。这一功能将确保关键参数可以随着时间的推移，由茶社区的活跃成员发展和优化。我们预计治理将以简单的结构开始，并随着茶系统的成熟而逐步扩大，促进采用并确保逐步去中心化。 + +某些系统参数可能不受治理的约束，或者不支持高频率的更改，以减少治理所代表的攻击面。将参数逐步过渡到开放、分散的治理将确保系统的稳定性和可预测性。 + +## 第三方可扩展性 + +当我们构建最初的工具来点燃开源社区期待已久的支持时，我们相信我们的部分使命是确保第三方可以扩展整个工具集。除了为开发人员提供构建协议扩展的基础设施(包括创新和进一步支持开源开发人员的新方法)之外，我们的计划还包括其他包管理器为协议做出贡献的可能性。 + +开源开发者的梦想和努力造就了支持我们日常生活的创新。我们期待着发现茶界提出的茶协议的新用途和扩展。 + +## 未来的工作和潜在的社区努力 + +随着茶系统的成熟，我们预计社区将通过治理来决定和促进茶系统的改变和扩展。以下是一些想法，我们相信可能会启发一些，但我们不保证任何未来的表现。 + +### 茶叶批发商 + +开源软件社区充满活力，不断寻求创新和交付价值。这种奉献和利他主义导致了新软件和软件包的不断构建，每个软件包都需要依赖。因此，我们预期依赖关系映射会不断地演化，从而导致投资比例和回报的频繁变化。未来，茶社区可能会提出开发一个系统，旨在动态监控每个项目的权益比例，并根据自己的标准重新平衡项目支持者如何权益他们的 tea 代币。 + +### 包装转让特许权使用费 + +我们认识到软件包维护者可能决定将他们的奖励流转移给一个或多个开发人员。这种转移的治理必须仍然是一揽子计划维护者及其合作伙伴的决定，不受茶的干扰。将需要提供工具来实现这种全部或部分的转移(可能通过只有一部分奖励被重定向到一个或多个开发人员，而剩余的奖励继续流向原始包维护者)，并且为赌注奖励通过由单个网络参与者控制的单个帐户流动，多个网络参与者，或者使用静态或动态比率在多个帐户之间自动分配。 + +### 奖励分布在多个维护者之间 + +一个包的维护可以依赖于另一个开发团队的工作。在奖励开始流动之前，团队应该考虑在他们之间自动分配价值。如何分发必须由维护者自己决定，因为他们处于评估谁做出了贡献以及他们应该如何获得奖励的最佳位置。 + +为了实现这一目标，每个团队(或多个团队)可以建立自己的去中心化自治组织([DAO](https://ethereum.org/en/dao/))，并自动分配或部署更复杂的系统，以确定基于外部因素的适当价值分配，例如所有 DAO 成员的投票，或基于持续贡献的基于时间的分配，成功完成奖励等。 + +### 处理包的分叉 + +我们认为，分叉是必不可少的，但在很大程度上没有得到充分利用。对于开发在功能、性能、安全性甚至关注度方面都具有竞争力的包来说，fork 是一种有效的工具。尽管它们可能很有用，但分支必须承认原始的努力。通过未来的工作或潜在的贡献，茶社区可能会增强系统，要求声明分叉，甚至可能在项目注册时检测到分叉。品茶师发现的未申报的叉子可能会导致叉子的一部分资金被削减，转移到原来的包装维护人员那里，或者被送到透露叉子的品茶师那里。 + +### 运行时与构建依赖关系 + +在发布时分发贡献证明奖励时，tea 可能无法区分构建依赖项和运行时依赖项。然而，如果茶社区强烈希望做出这样的区分，茶社区可能会提出改进奖励分配算法，以考虑每个依赖项的重要性以及它们对依赖于它们的软件包的个人价值的贡献。这些建议将根据社区的决定进行表决和实施。 + +### 基于使用奖励 + +随着越来越多的应用程序使用在 tea 注册的项目构建，社区可能会增强奖励算法，以便分配可能受到外部认证数据集(如使用率)的影响。对奖励机制的更新可以允许更高的 TEA 令牌奖励分配流向使用率最高的包，同时仍然尊重 TEA 令牌部分中描述的权益比率的约束。包维护者可以使用类似的方法，根据他们选择的透明逻辑，跨依赖项分发奖励。注意，所有用于影响跨包和茶叶系统中的依赖关系的奖励分配的信息都需要是可靠的。 + +## 致谢 + +这份白皮书的出版离不开广大茶友的支持和奉献。作者要感谢 Jacob Heider, Jadid Khan, Josh Kruger 和 Shane Molidor 对代币经济学的贡献，Sanchit Ram 对 teaRank 算法的贡献，以及许多自愿花时间对本文内容提供反馈的个人。 + +## 术语表 + +| 术语 | 释义 | +| --------------------- | ------------------------------------------------------------------------------------------------------------- | +| 叶子（Leaf） | TEA 令牌的最小面额。一片叶子相当于一杯茶的五分之一(10^−18)。 | +| 惩罚/削减（Slashing） | 对违反协议的行为进行惩罚的行为 | +| 押注 | 锁定 TEA 代币以支持您的索赔并根据对索赔有效性的共识获得奖励(或惩罚)的行为。 | +| stTEA | 不可转让的“押注 TEA”代币或“stTEA”，由网络参与者以 1:1 的比例获得每个代币。可以利用 stTEA 参与茶叶议定书的治理 | +| teaRank | 根据协议的“贡献证明”算法分配给每个项目的动态影响评分。 | + +## 参考文献 + +1. [https://creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/) +2. [https://archive.org/details/historyofmodernc00ceru](https://archive.org/details/historyofmodernc00ceru) +3. [https://nvd.nist.gov/vuln/detail/CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) +4. [https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA](https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA) +5. [https://twitter.com/yazicivo/status/1469349956880408583](https://twitter.com/yazicivo/status/1469349956880408583) +6. [https://www.thestack.technology/core-js-maintainer-denis-pusharev-license-broke-angry/](https://www.thestack.technology/core-js-maintainer-denis-pusharev-license-broke-angry/) +7. [https://www.w3.org/TR/did-core/](https://www.w3.org/TR/did-core/) +8. [https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/) +9. [https://www.theregister.com/2016/03/23/npm_left_pad_chaos/](https://www.theregister.com/2016/03/23/npm_left_pad_chaos/) +10. [https://fossa.com/blog/npm-packages-colors-faker-corrupted/](https://fossa.com/blog/npm-packages-colors-faker-corrupted/) +11. [https://www.lunasec.io/docs/blog/node-ipc-protestware/](https://www.lunasec.io/docs/blog/node-ipc-protestware/) +12. [https://github.com/dominictarr/event-stream/issues/116](https://github.com/dominictarr/event-stream/issues/116) +13. [https://blog.npmjs.org/post/163723642530/crossenv-malware-on-thenpm-registry.html](https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html) +14. [https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/](https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/) +15. [https://threatpost.com/backdoor-found-in-utility-for-linux/147581/](https://threatpost.com/backdoor-found-in-utility-for-linux/147581/) +16. [https://www.fbi.gov/news/stories/phantom-secure-takedown-031618](https://www.fbi.gov/news/stories/phantom-secure-takedown-031618) +17. [https://www.europol.europa.eu/media-press/newsroom/news/800-criminalsarrested-in-biggest-ever-law-enforcement-operation-against-encryptedcommunication](https://www.europol.europa.eu/media-press/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication) +18. [https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502) +19. [https://www.npmjs.com/package/lodash](https://www.npmjs.com/package/lodash) +20. [https://www.npmjs.com/package/chalk](https://www.npmjs.com/package/chalk) +21. [https://www.npmjs.com/package/log4js/](https://www.npmjs.com/package/log4js/) +22. [https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/) +23. [https://medium.com/intrinsic-blog/compromised-npm-package-eventstream-d47d08605502](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502) +24. [https://semver.org/](https://semver.org/) +25. [https://arxiv.org/abs/1207.2617](https://arxiv.org/abs/1207.2617) +26. [https://research.web3.foundation/Polkadot/overview/token-economics](https://research.web3.foundation/Polkadot/overview/token-economics)