From 4607114a9ccad5620a5c9df3a5f6225c8267ebf2 Mon Sep 17 00:00:00 2001 From: Arthur Burkart Date: Tue, 24 May 2022 20:51:56 -0400 Subject: [PATCH] Copy edits This commit includes copy edits of "white-paper.md". --- white-paper.md | 66 +++++++++++++++++++++++++------------------------- 1 file changed, 33 insertions(+), 33 deletions(-) diff --git a/white-paper.md b/white-paper.md index 745a37a..78e131a 100644 --- a/white-paper.md +++ b/white-paper.md @@ -19,13 +19,13 @@ The Internet is predominantly composed of open-source projects and has been sinc We believe that the entirety of modern human endeavor has been stunted by relying on the smallest percentage of the world's engineers to choose between a salary or keeping the Internet running. Open-source is a labor of love often hindered by a lack of meaningful economic incentives resulting in genuinely worthwhile projects never reaching their potential while others suffer from security issues due to the lack of incentives to maintain software throughout its lifecycle. To fully realize our potential, we need a fair remuneration system for the open-source ecosystem that doesn’t fundamentally change how it is built or utilized. -Enterprises often wrap business models around open-source, generating revenue directly from the work of the benevolent developers while also relying on them to fix bugs as issues occur. A great example is a recent incident involving a critical security vulnerability in Log4J, a package from the Apache Software Foundation that found its way across many commercial software and services employed by enterprises and governments. In Nov. 2021, a security researcher working for Alibaba Group Holding Ltd. reported vulnerability CVE-2021-44228[^1], which received the highest possible base score from the Apache Software Foundation. Amit Yoran, Chief Executive of Tenable and founding director of the U.S. Computer Emergency Readiness Team, described this vulnerability as “the single biggest, most critical vulnerability of the last decade”[^2]. Panic ensued and the few volunteers who maintained this package came publicly under fire for the failure. After addressing the outrage with a humble plea for fairness, systems got patched. Enterprises and governments eventually realized that Log4j, a package used by a broad range of critical systems for two decades, was maintained by a few unpaid volunteers, the same unsung heroes who sprang into action despite abuse from the industry[^3] and worked tirelessly to address the vulnerability. +Enterprises often wrap business models around open-source, generating revenue directly from the work of the benevolent developers while also relying on them to fix bugs as issues occur. A great example is an incident from 2021 involving a critical security vulnerability in Log4j, a package from the Apache Software Foundation that found its way across many commercial software and services employed by enterprises and governments. In November 2021, a security researcher working for Alibaba Group Holding Ltd. reported vulnerability CVE-2021-44228[^1], which received the highest possible base score from the Apache Software Foundation. Amit Yoran, Chief Executive of Tenable and founding director of the U.S. Computer Emergency Readiness Team (US CERT), described this vulnerability as “the single biggest, most critical vulnerability of the last decade”[^2]. Panic ensued, and the few volunteers who maintained this package came publicly under fire for the failure. After addressing the outrage with a humble plea for fairness, systems got patched. Enterprises and governments eventually realized that Log4j, a package used by a broad range of critical systems for two decades, was maintained by a few unpaid volunteers, the same unsung heroes who sprang into action despite abuse from the industry[^3] and worked tirelessly to address the vulnerability. -Sadly, Log4J is far from the only example. JSCore is downloaded 30 million times per week as the base of every NodeJS application, yet it is also barely funded. Recently several bitcoin core developers resigned, citing, among other reasons, a *lack of financial compensation* for their decision. +Sadly, Log4j is far from the only example. core-js is downloaded 30 million times per week as the base of every Node.js application, yet it is also barely funded. Recently several Bitcoin core developers resigned, citing, among other reasons, a *lack of financial compensation* for their decision. There have been multiple attempts at providing incentive structures, typically involving sponsorship and bounty systems. Sponsorship makes it possible for consumers of open-source to donate to the projects they favor. However, picture open-source as a tower of bricks where lower layers are long forgotten, but still maintained by dedicated engineers and relied upon by even more developers. Only projects at the top of the tower are typically known and receive sponsorship. This biased selection leads to essential bricks that hold up the tower attracting no donations, while favorites receive more than they need. Bounties allow consumers of projects to propose payment for developers to build specific features, thus only remunerating projects for doing things not necessarily in their best interest. And again, only rewarding favorites. -In this paper, we propose tea — a decentralized system for fairly remunerating open-source developers based on their contributions to the entire ecosystem and enacted through the tea incentive algorithm applied across all entries in the tea registry. +In this paper, we propose tea—a decentralized system for fairly remunerating open-source developers based on their contributions to the entire ecosystem and enacted through the tea incentive algorithm applied across all entries in the tea registry. ![Simplified view of the tea steeping rewards system.](img/figure-1.svg) @@ -48,16 +48,16 @@ We propose an immutable decentralized registry designed to distribute value base Additionally, we believe that material information must be available via the package manager for developers to assess whether they can trust a package and its author. This information may be based on reputation, community kudos, data retrieved from decentralized identity (DID[^4]) systems, other package managers, or incentive mechanisms that potentially rely on network participants putting economic value at risk. -We predict that tea’s combination of tools, information, and rewards will justly incentivize developers, helping stimulate the growth of open-source software and fostering innovation. +We predict that tea’s combination of tools, information, and rewards will fairly incentivize developers, helping stimulate the growth of open-source software and fostering innovation. [^4]: See: @w3 ## The Decentralized Registry -Every package manager has its own package registry duplicating the same metadata repeatedly. It’s time there was a single, comprehensive and definitive registry designed and governed by the communities that depend on it. This decentralized, immutable registry could provide security, stability and prevent +Every package manager has its own package registry duplicating the same metadata repeatedly. It’s time there was a single, comprehensive, and definitive registry designed and governed by the communities that depend on it. This decentralized, immutable registry could provide security and stability and prevent malevolent intent. -The Internet runs on tens of thousands of vital open-source components. It’s remarkable that thus far, incidents caused by the removal of essential open-source infrastructure have been minimal. The most famous was the removal of an NPM left-pad[^5] dependency in 2016, which cascaded into continuous integration and continuous deployment systems leaving developers high and dry for days. This event demonstrated that the Internet itself is based on fragile systems of development. Other examples involved active or intentional participation from the package maintainers sabotaging their popular packages (See colors.js, fakers.js[^6], and node-ipc[^7]), or bad actors looking to profit by pretending to help maintain packages and corrupting them to steal, for example, Bitcoin private keys (See event-stream[^8]). +The Internet runs on tens of thousands of vital open-source components. It’s remarkable that thus far, incidents caused by the removal of essential open-source infrastructure have been minimal. The most famous was the removal of an NPM left-pad[^5] dependency in 2016, which cascaded into continuous integration and continuous deployment systems leaving developers unable to build their software for days. This event demonstrated that the Internet itself is based on fragile systems of development. Other examples involved active or intentional participation from package maintainers sabotaging their popular packages (See colors.js, faker.js[^6], and node-ipc[^7]), or bad actors looking to profit by pretending to help maintain packages and corrupting them to steal, for example, Bitcoin private keys (See EventStream[^8]). Software integrity needs to be guaranteed as the industry progresses towards a future where digital assets are part of the software. We cannot continue to leave ourselves vulnerable to malicious actors modifying the software. @@ -75,9 +75,9 @@ A decentralized registry augmented by a reputation system and supported by econo ## The Storage System -Open-source packages deliver a broad range of functionality, some of which may be restricted or unwanted. Encryption is an excellent example of that. A critical use case for encryption is the support of individuals’ privacy across the globe. Encryption, however, can also be used for nefarious purposes (see Phantom Secure, dismantled by law enforcement agencies in March 2018[^11]) or may be compromised to support law enforcement activities (See Operation Ironside (AFP), Operation Greenlight (Europol), and Operation Trojan Shield (FBI)[^12] where the FBI operated an “encrypted” communication platform, AN0M, and convinced criminals to use their “encrypted” phones for secure communication). +Open-source packages deliver a broad range of functionality, some of which may be restricted or unwanted. Encryption is an excellent example of that. A critical use case for encryption is the support of individuals’ privacy across the globe. Encryption, however, can also be used for nefarious purposes (See Phantom Secure, dismantled by law enforcement agencies in March 2018[^11]) or may be compromised to support law enforcement activities (See Operation Ironside (AFP), Operation Greenlight (Europol), and Operation Trojan Shield (FBI)[^12] where the FBI operated an “encrypted” communication platform, AN0M, and convinced criminals to use their “encrypted” phones for secure communication). -Encryption’s broad applications have made it a perfect use case for open-source software and a great example that any solution that stores packages must be tamper-proof and censorship-resistant. tea is a decentralized protocol that does not intend to filter or sanction packages based on their functionality. While the tea governance may elect to remove proven malicious packages (see the governance section for more information), it is critical for the tea system to connect with multiple storage systems, including decentralized ones that demonstrate that a package is unaltered and correctly replicated. Package maintainers may choose the storage system best suited for their need to store and distribute their packages securely. +Encryption’s broad applications have made it a perfect use case for open-source software and a great example that any solution that stores packages must be tamper-proof and censorship-resistant. tea is a decentralized protocol that does not intend to filter or sanction packages based on their functionality. While the tea governance may elect to remove proven malicious packages (See the governance section for more information), it is critical for the tea system to connect with multiple storage systems, including decentralized ones that demonstrate that a package is unaltered and correctly replicated. Package maintainers may choose the storage system best suited for their need to store and distribute their packages securely. [^11]: Source: @fbi [^12]: Source: @europol @@ -90,21 +90,21 @@ tea’s mission is to empower open-source communities and ensure their contribut Package maintainers must make sure their software continues to deliver increasing value as the industry evolves. -tea assumes that package creators maintain their work. Package maintainers are pillars of open-source communities who need to be empowered and rewarded for their ongoing contributions. A package maintainer may decide to discontinue their maintenance efforts or realize they cannot operate at a pace that matches the package users' expectations. Package maintainers receive an NFT when they complete a package submission (see the maintainer NFT section for additional details). This NFT is used to evidence their work and is the key that directs tea rewards. The holder of a package’s NFT can transfer its ownership to another developer (or group of developers), thus making them maintainers of the package and recipients of any future rewards. Similarly, a developer may decide to take on the role of package maintainer by forking the existing package and submitting a new one which they will maintain moving forward, thus becoming themselves both package creator and maintainer. +tea assumes that package creators maintain their work. Package maintainers are pillars of open-source communities who need to be empowered and rewarded for their ongoing contributions. A package maintainer may decide to discontinue their maintenance efforts or realize they cannot operate at a pace that matches the package users' expectations. Package maintainers receive an NFT when they complete a package submission (See the [Maintainer NFT](#maintainer-nft) section for additional details). This NFT is used to evidence their work and is the key that directs tea rewards. The holder of a package’s NFT can transfer its ownership to another developer or group of developers, thus making them maintainers of the package and recipients of any future rewards. Similarly, a developer may decide to take on the role of package maintainer by forking the existing package and submitting a new one which they will maintain moving forward, thus becoming themselves both package creator and maintainer. -It is essential to provide developer communities with the right tools to determine which packages are being maintained and their past and present maintainers’ reputation and quality of work. We’ve too often seen open-source work being tampered with and the efforts of many ruined by bad actors. Although the work of these bad actors is largely discovered and remediated, it is often not until significant damage has been incurred through financial or data loss. Take for example the event-stream npm package[^13] that was downloaded over 1.5 million times per week and relied upon by over 1,500 packages when a hacker managed to penetrate the open-source project, gain the trust of its original author and modify event-stream to depend on a malicious package that would exfiltrate bitcoin wallet credentials to a third-party server. Although tools may help detect some of these attacks, they cannot always be relied upon, which creates an entire community dependent upon each other’s diligence and willingness to share their findings. +It is essential to provide developer communities with the right tools to determine which packages are being maintained and their past and present maintainers’ reputation and quality of work. We’ve too often seen open-source work being tampered with and the efforts of many ruined by bad actors. Although the work of these bad actors is largely discovered and remediated, it is often not until significant damage has been incurred through financial or data loss. Take for example the EventStream npm package[^13] that was downloaded over 1.5 million times per week and relied upon by over 1,500 packages when a hacker managed to penetrate the open-source project, gain the trust of its original author, and modify EventStream to depend on a malicious package that would exfiltrate bitcoin wallet credentials to a third-party server. Although tools may help detect some of these attacks, they cannot always be relied upon, which creates an entire community dependent upon each other’s diligence and willingness to share their findings. -We propose introducing incentives via the tea token described in the tea token section, encouraging open-source communities to report their findings constructively, so package maintainers can address them before they are exploited. +We propose introducing incentives via the tea token described in the [tea Token](#tea-token) section, encouraging open-source communities to report their findings constructively, so package maintainers can address them before they are exploited. [^13]: Source: @medium ## Package Users -Package users are software developers focused on solving a specific problem. They often look in the open-source community for the tools they need to experiment quickly and iterate at very little to no cost, directly benefitting from the work of package creators and maintainers. Traditionally, a subset may have chosen to support package maintainers through donations or other forms of remuneration; however, this has rarely been the case. +Package users are software developers focused on solving a specific problem. They often look in the open-source community for the tools they need to experiment quickly and iterate at very little to no cost, directly benefiting from the work of package creators and maintainers. Traditionally, a subset may have chosen to support package maintainers through donations or other forms of remuneration; however, this has rarely been the case. Sponsorship can be an effective system to support open-source development; however, remuneration does not typically extend to all dependencies. This limitation benefits favorites and gets in the way of innovation and software building. To strive as the foundation of software development, open-source must empower all developers, whether beginners or experts, across all layers in the tower. -tea’s purpose is to maintain the core values of open-source software while providing a decentralized system to remunerate package maintainers for their work. To deliver on this mission, tea intends to develop — and incentivize others to develop — mechanisms for package users to support package maintainers through unique use cases of the tea token, as described in the tea token and future work and potential community effort sections. +tea’s purpose is to maintain the core values of open-source software while providing a decentralized system to remunerate package maintainers for their work. To deliver on this mission, tea intends to develop—and incentivize others to develop—mechanisms for package users to support package maintainers through unique use cases of the tea token, as described in the [tea Token](#tea-token) and [Future Work and Potential Community Effort](#future-work-and-potential-community-efforts) sections. ## Package Supporters and Sponsors @@ -112,13 +112,13 @@ In Web 2.0 and web3, package supporters have often been called “sponsors.” T tea proposes to extend the communities of package supporters to the entire tea community, whether organizations, developers, users, or tech enthusiasts. tea’s goal is to implement decentralized incentive mechanisms through unique use cases of the tea token for any member of the tea community to contribute to the perpetual sustainability and continuous growth of open-source. Package supporters and sponsors are free to decide which packages or package maintainers they want to support based on their work, beliefs, or any criteria and metric that would influence their decision. Additionally, the support provided by package supporters and sponsors will flow to each package’s dependencies, thus implicitly trusting the package maintainer to make good choices about their stack and using this information to contribute to their reputation. -Provided that the package maintainer offers such service, a package supporter and sponsor may receive a premium support level NFT in return, thus benefiting from accelerated SLAs or more flexible licensing. Additionally, package supporters and sponsors may decide to support packages or package maintainers and automatically redirect all or a percentage of their rewards to incentivize teams to build new open-source software. In other words, packages don’t need to exist for tea to start pouring in. Nascent projects can be supported just as well as more mature ones, further incentivizing a constantly evolving open-source landscape. +Provided that the package maintainer offers such a service, a package supporter and sponsor may receive a premium support-level NFT in return, thus benefiting from accelerated SLAs or more flexible licensing. Additionally, package supporters and sponsors may decide to support packages or package maintainers and automatically redirect all or a percentage of their rewards to incentivize teams to build new open-source software. In other words, packages don’t need to exist for tea to start pouring in. Nascent projects can be supported just as well as more mature ones, further incentivizing a constantly evolving open-source landscape. ## tea Tasters As new packages or new versions of existing packages are released, the validity of the work needs to be provably demonstrated. This information is critical for package users to decide whether or not to trust both the package and its maintainers. With the tea protocol, this function is provided by the tea tasters. -tea tasters, typically, are experienced software developers willing to dedicate some of their time to check the claims associated with a package (functionality, security, semantic versioning[^14], license accuracy, etc.) and stake both their reputation and economic value to demonstrate the outcome of their research and analysis and support their reviews. tea tasters receive rewards for their diligence and efforts. At tea, we call “steeping your tea” the action of locking tea tokens to support your reviews and receive rewards (or penalties) based on the consensus on the validity of your reviews. +tea tasters, typically, are experienced software developers willing to dedicate some of their time to check the claims associated with a package (e.g., functionality, security, semantic versioning[^14], license accuracy, etc.) and stake both their reputation and economic value to demonstrate the outcome of their research and analysis and support their reviews. tea tasters receive rewards for their diligence and efforts. At tea, we call “steeping your tea” the action of locking tea tokens to support your reviews and receive rewards (or penalties) based on the consensus on the validity of your reviews. Like package supporters, tea tasters can influence a package and package maintainer’s reputation; however, their impact is more significant given their role in validating a package’s security, functionality, and quality. tea tasters will also need to build their reputation to support their claims. The quality of their work and the economic value they put at risk as they steep their reviews combined with other external data sources will build each tea taster’s reputation, bringing more value to their work. See the package reputation section for more details on the mechanisms used to influence a package and package maintainer’s reputation. @@ -130,9 +130,9 @@ The design of a protocol to reward open-source contributions is mired with chall We intend to create a trustless distribution platform for applications secured by reputation and financial incentives, as we believe adequate rewards for open-source contributions cannot succeed without both a reputation system and the ability for members of the community to communicate their findings and support (or dissent) for a package or the work of a developer. -We must provide developers with tools to access and contribute to this reputation system. Tools that include simple visual and programmable access to the version and reputation of all dependencies within their packages. A clear understanding of which community members support each package and how many tea tokens they are steeping will contribute to the reputation of each package, just as how much a package maintainer is steeping their work communicates how much they stand behind their work. These combined data points will help inform a reputation system for all community members and facilitate choice. As the event-stream package hack was not conducted through the package itself, but via one of its dependencies, visibility across all layers of dependencies will be vital to building this trustless system. However, considerations such as computation and transaction (“gas”) costs will need to take priority as the system is designed and built. +We must provide developers with tools to access and contribute to this reputation system. Tools that include simple visual and programmable access to the version and reputation of all dependencies within their packages. A clear understanding of which community members support each package and how many tea tokens they are steeping will contribute to the reputation of each package, just as how much a package maintainer is steeping their work communicates how much they stand behind their work. These combined data points will help inform a reputation system for all community members and facilitate choice. As the EventStream package hack was not conducted through the package itself, but via one of its dependencies, visibility across all layers of dependencies will be vital to building this trustless system. However, considerations such as computation and transaction (“gas”) costs will need to take priority as the system is designed and built. -Our goal is to reward both Web 2.0 and web3 developers. The intricacies and specifics of each stack make it so that tracking installations and uninstallations of packages could easily fall victim to one or more bad actors. That includes “buying” installations to artificially inflate numbers. An even worse scenario would be introducing fundamental changes to the nature of open-source software by creating unnecessary friction with license keys or other deployment tracking mechanisms. To provide the broadest coverage, we believe that rewards mustn’t rely on a simplistic notion of tracking installations or uninstallations, but rather on incentive mechanisms that encourage the submission of quality packages and the reporting of nefarious or high-risk packages. Lastly, many packages rely on common dependencies. For example, lodash has 151,209 dependents[^15] while chalk has 78,854 dependents[^16] or log4js has 3,343 dependents[^17]. As more packages are created using the same dependencies, how do we ensure that incentives are distributed fairly and equitably? How do we ensure that the most utilized dependencies are rewarded without starving new or emerging packages and developers? How do we ensure that the incentive system does not end-up steering developers away from niche languages to centralize them where incentives are better? But also, as developers, how do we identify packages with the most dependents to build alternatives - leaner, more efficient, better-coded versions of these packages? At tea, we believe that the lack of incentive has impeded the evolution of open-source software. Supported by the right economic incentives and rewards, more developers will be in a position to build, improve and augment open–source software for the betterment of the world. Only then will the tea token be able to represent the total value of open-source software. +Our goal is to reward both Web 2.0 and web3 developers. The intricacies and specifics of each stack make it so that tracking installations and uninstallations of packages could easily fall victim to one or more bad actors. That includes “buying” installations to artificially inflate numbers. An even worse scenario would be introducing fundamental changes to the nature of open-source software by creating unnecessary friction with license keys or other deployment tracking mechanisms. To provide the broadest coverage, we believe that rewards must not rely on a simplistic notion of tracking installations or uninstallations, but rather on incentive mechanisms that encourage the submission of quality packages and the reporting of nefarious or high-risk packages. Lastly, many packages (i.e., dependents) rely on common dependencies. For example, at the time of writing, Lodash has 151,209 dependents[^15], while Chalk has 78,854 dependents[^16] and log4js has 3,343 dependents[^17]. As more packages are created using the same dependencies, how do we ensure that incentives are distributed fairly and equitably? How do we ensure that the most utilized dependencies are rewarded without starving new or emerging packages and developers? How do we ensure that the incentive system does not steer developers away from niche programming languages to centralize them where incentives are better? And as developers, how do we identify packages with the most dependents to build alternatives—leaner, more efficient, better-coded versions of these packages? At tea, we believe that the lack of incentive has impeded the evolution of open-source software. Supported by the right economic incentives and rewards, more developers will be in a position to build, improve, and augment open–source software for the betterment of the world. Only then will the tea token be able to represent the total value of open-source software. [^15]: Source: @npmjsLodash [^16]: Source: @npmjsChalk @@ -148,7 +148,7 @@ The submission of a package release requires multiple transactions to occur atom Failure of any one of the three operations will result in the protocol reverting to its previous state, thus eliminating any evidence of the submission. -When a package is successfully submitted, the package maintainer will receive a maintainer NFT to evidence their work and contribution to open-source. The package maintainer may transfer the steeping rewards associated with the maintainer NFT to a third party. However, the reputation associated with the creation and maintenance of the asset will remain with the package maintainer, so their reputation can be affected over time. As the reputation of any member of the tea community reaches key milestones, they may be granted access to elevated parts of the protocol or receive accelerated rewards, as decided by the tea governance. For more details on the maintainer NFT, see the maintainer NFT section. +When a package is successfully submitted, the package maintainer will receive a maintainer NFT to evidence their work and contribution to open-source. The package maintainer may transfer the steeping rewards associated with the maintainer NFT to a third party. However, the reputation associated with the creation and maintenance of the asset will remain with the package maintainer, so their reputation can be affected over time. As the reputation of any member of the tea community reaches key milestones, they may be granted access to elevated parts of the protocol or receive accelerated rewards, as decided by the tea governance. For more details on the maintainer NFT, see the [Maintainer NFT](#maintainer-nft) section. ### Dependencies Analysis @@ -159,7 +159,7 @@ This design is driven by the hypothesis that each dependency is itself a package ![Dependencies analysis diagram.](img/figure-3.svg){#fig:dep-analysis} -In @fig:dep-analysis, the submission of package A triggers an analysis of runtime dependencies 1 through n and build dependencies 1 through n, while runtime dependencies 1.1 through 1.n and build dependencies 1.1 through 1.n were analyzed when package B was submitted. We will apply the same methodology for incentive distribution as the steeped tokens are distributed across all dependencies, thus recursively steeping the packages listed as dependencies (see @fig:steeping-rewards). +In @fig:dep-analysis, the submission of package A triggers an analysis of runtime dependencies 1 through n and build dependencies 1 through n, while runtime dependencies 1.1 through 1.n and build dependencies 1.1 through 1.n were analyzed when package B was submitted. We will apply the same methodology for incentive distribution as the steeped tokens are distributed across all dependencies, thus recursively steeping the packages listed as dependencies (See @fig:steeping-rewards). ![Steeping rewards distribution across dependencies.](img/figure-2.svg){#fig:steeping-rewards} @@ -171,15 +171,15 @@ Versioning and conflicting dependencies are significant challenges, and troubles * Similarly, if a dependency is upgraded to a more recent minor version, tea may require that the package’s minor version be increased. * If a new dependency is added, tea may require that the package’s minor version be increased. -Considering the unnecessary effort imposed upon any package user when the above rules are flaunted, we propose that a portion of the tea token steeped by the package maintainer be slashed to reflect their lack of due diligence. If a developer forces everyone to juggle their cups, someone will spill some tea. Since the dependency scan is expected to occur at submission, we should note that no steeping from package supporters and sponsors or tea tasters will have happened. +Considering the unnecessary effort imposed upon any package user when the above rules are violated, we propose that a portion of the tea token steeped by the package maintainer be slashed to reflect their lack of due diligence. If a developer forces everyone to juggle their cups, someone will spill some tea. Since the dependency scan is expected to occur at submission, we should note that no steeping from package supporters and sponsors or tea tasters will have happened. -## Package & Package Maintainer Reputation +## Package and Package Maintainer Reputation Package maintainers must contribute to their package’s reputation and trustworthiness by steeping tea tokens. However, a reputation system that relies solely on the author’s economic contribution does not provide sufficient user protection and can be subject to Sybil attacks, where a single individual creates multiple representations of themselves to leave a large volume of positive reviews on their work, tricking users into believing their work was reviewed and approved by many. Several methodologies are available to prevent Sybil attacks, some of which are described by Nitish Balachandran and Sugata Sanyal in “A Review of Techniques to Mitigate Sybil Attacks”[^18]. As tea is a decentralized protocol, using a trust certification system that relies on a centralized certificate issuance authority would be contrary to its core. We propose to focus on decentralized approaches to Sybil attack mitigation and, more specifically, on methodologies that rely on a large group of network participants incentivized to assess and publicly represent the reputation of each package and its maintainer. -Similar to the production of blocks on a proof-of-stake blockchain, where non-producing nodes can validate the work of others and, when necessary, highlight a violation of the rules of the network, which leads to a penalization of the bad actor through slashing (destruction of a portion of their stake), we propose a system whereby third-parties (aka tea tasters) would be able to review packages produced by package maintainers and be economically incentivized to behave in the best interest of the open-source software community and its users as well as recognize good behavior and penalize bad behavior. This system must be both Sybil resistant and prevent large token holders from materially influencing the protocol or the reputation of specific packages. We believe this approach to be more aligned with open-source, providing a more fertile substrate to foster adoption and trust, and ultimately facilitate the growth of tea. +Similar to the production of blocks on a proof of stake blockchain, where non-producing nodes can validate the work of others and, when necessary, highlight a violation of the rules of the network, which leads to a penalization of the bad actor through slashing (i.e., destruction of a portion of their stake), we propose a system whereby third-parties (aka tea tasters) would be able to review packages produced by package maintainers and be economically incentivized to behave in the best interest of the open-source software community and its users as well as recognize good behavior and penalize bad behavior. This system must be both Sybil resistant and prevent large token holders from materially influencing the protocol or the reputation of specific packages. We believe this approach to be more aligned with open-source, providing a more fertile substrate to foster adoption and trust and ultimately facilitate the growth of tea. [^18]: Source: @arxiv @@ -187,11 +187,11 @@ Similar to the production of blocks on a proof-of-stake blockchain, where non-pr The review of packages by third parties is an essential component of reputation building, however, third-party review has its own set of unique threats including the aforementioned Sybil attacks. -Blockchain technology, and more explicitly staking, offers a unique opportunity for tea to tackle this challenge. Although wallet addresses may be available in infinite quantities, this is not the case with tea tokens, whose initial supply is expected to be 10 billion. Additionally, each action performed by developers, such as submitting packages, verifying packages, or steeping them, will contribute to their reputation, thus creating a unique profile each developer can use to both contribute to the tea community and participate in tea’s governance. +Blockchain technology, and more explicitly staking, offers a unique opportunity for tea to tackle this challenge. Although wallet addresses may be available in infinite quantities, this is not the case with tea tokens, whose initial supply is expected to be 10 billion. Additionally, each action performed by developers, such as submitting packages, verifying packages, or steeping them will contribute to their reputation, thus creating a unique profile each developer can use to both contribute to the tea community and participate in tea’s governance. -By requiring third-party reviewers to steep tea tokens and incur the risk of losing a portion of their steeped tokens should they turn out to behave against the interest of the network or be a bad actor, third parties can provide additional credence to a package and receive a reward, in the form of tea tokens. +By requiring third-party reviewers to steep tea tokens and incur the risk of losing a portion of their steeped tokens should they turn out to behave against the interest of the network or be a bad actor, third parties can provide additional credence to a package and receive a reward in the form of tea tokens. -We also propose extending the reputation system to the third parties who perform the independent verification of packages - the tea tasters. The completion of a positive review will require two operations to occur atomically: +We also propose extending the reputation system to the third parties who perform the independent verification of packages—the tea tasters. The completion of a positive review will require two operations to occur atomically: * The submission of the code review, signed by the tea taster and publicly accessible to all members of the community, along with * The act of steeping “for” the package (vs. “against” the package), to substantiate their review. @@ -202,7 +202,7 @@ Upon completing both operations, the tea tasters will receive an NFT as evidence ## Outdated or Corrupt Packages -tea’s mission is to reward contributors and participants in the open-source communities; however, rewards must be commensurate with the efforts deployed by package maintainers and tea tasters. Under-maintained, outdated, or corrupted packages are clear indications of package maintainers not living up to the community’s expectations or not delivering on the trust and support impressed upon them through the steeping of packages. Another manifestation of outdated packages may be the continued use of a legacy language or legacy version of multi-version languages. Packages remaining outdated or corrupt for too long indicate that tea tasters need to review package maintainers’ work regularly and consistently. +tea’s mission is to reward contributors and participants in the open-source communities; however, rewards must be commensurate with the efforts deployed by package maintainers and tea tasters. Under-maintained, outdated, or corrupted packages are clear indications of package maintainers not living up to the community’s expectations or not delivering on the trust and support impressed upon them through the steeping of packages. Another manifestation of outdated packages may be the continued use of a legacy programming language or legacy version of multi-version languages. Packages remaining outdated or corrupt for too long indicate that tea tasters need to review package maintainers’ work regularly and consistently. tea tasters are critical members of the open-source communities in that their reviews and associated claims can steer package users towards or away from packages. To ensure that reviews can be trusted on an ongoing basis, we propose a mechanism whereby outdated or corrupted packages may see a portion of their steeped tokens sent to the tea tasters who were first to recognize the lack of maintenance of any package. @@ -212,7 +212,7 @@ As packages gain in popularity and usage, with more applications and potentially ## Maintainer NFT -Upon successful submission of a package, the package maintainer will receive a non-fungible token (NFT) to evidence their work and contribution. The holder of this NFT will automatically receive all rewards associated with the package. Package maintainers may transfer maintenance ownership over a package to another package maintainer by simply transferring the package’s NFT. Successful transfer of the NFT will lead to the new owner automatically receiving future package rewards. +Upon successful submission of a package, the package maintainer will receive an NFT as evidence of their work and contribution. The holder of this NFT will automatically receive all rewards associated with the package. Package maintainers may transfer maintenance ownership over a package to another package maintainer by simply transferring the package’s NFT. Successful transfer of the NFT will lead to the new owner automatically receiving future package rewards. An important part of reputation building relies on the frequency and quantity of quality package submissions. The NFT delivered to package maintainers as evidence of their work may be used by the reputation system to update a package maintainer’s reputation and give them access to elevated parts of the protocol, as decided by the tea governance. However, to prevent attack vectors, such as community members buying their reputation, the transfer of the maintainer NFT will not result in a transfer of reputation. Reputation must remain directly associated with a specific developer’s work and must not be transferable. @@ -232,15 +232,15 @@ Both applications of the tea token serve vital functions in the support and grow As discussed earlier, there can be strong incentives for bad actors to compromise open-source software. The majority of the Internet’s critical infrastructure is running on open-source, and the race to find exploits and other vulnerabilities is on. At tea, we believe that package maintainers are not the ones that should be blamed (although they often are). -tea protocol incentives fix this through a fair and equitable incentive distribution. A package like lodash with over 151k dependents is a pillar of open-source development, and its maintainer deserves to be rewarded proportionally. However, a reward system built solely on the number of dependents would prevent innovators from disrupting these monopolies unless they are sufficiently funded by third parties or have already accumulated enough resources to self-fund. This approach would likely lead to a shrinking number of contributors, resulting in the polar opposite of what tea is about. +tea protocol incentives fix this through a fair and equitable incentive distribution. A package like Lodash with over 151k dependents is a pillar of open-source development, and its maintainer deserves to be rewarded proportionally. However, a reward system built solely on the number of dependents would prevent innovators from disrupting these monopolies unless they are sufficiently funded by third parties or have already accumulated enough resources to self-fund. This approach would likely lead to a shrinking number of contributors, resulting in the polar opposite of what tea is about. -tea’s goal is to represent the value of open-source software and, in doing so, foster its growth by empowering its participants with the resources they need to pursue their passion unencumbered. The tea incentive distribution system needs to carefully consider the steeping ratio of each package and adjust each package’s incentive accordingly. To reduce the risk of a small number of packages used as dependencies across many applications collecting the majority of steeping rewards, we will leverage the research produced by the web3 Foundation[^19] for the Polkadot proof-of-stake-based rewards mechanism. We may further adjust the implementation and its variables based on the results of practical experiments. +tea’s goal is to represent the value of open-source software and, in doing so, foster its growth by empowering its participants with the resources they need to pursue their passion unencumbered. The tea incentive distribution system needs to carefully consider the steeping ratio of each package and adjust each package’s incentive accordingly. To reduce the risk of a small number of packages used as dependencies across many applications collecting the majority of steeping rewards, we will leverage the research produced by the web3 Foundation[^19] for the Polkadot proof of stake-based rewards mechanism. We may further adjust the implementation and its variables based on the results of practical experiments. As a package steep approaches a governance-defined optimum steeping ratio, its steeping rewards ratio will decrease progressively. When a package exceeds its optimum steeping ratio, the steeping rewards ratio will decrease sharply to de-incentivize package supporters and tea tasters from further steeping highly steeped packages. This design could allow lesser steeped packages to become more attractive to both package supporters and tea tasters. It may also incentivize experienced developers to build alternatives to highly-steeped packages, creating an opportunity for the tea community to balance supporting existing software and promoting innovation. The steeping ratio will be calculated using the circulating supply in its initial design. The tea community may alter this design to improve the system’s scalability further. Let $\chi$ be the steeping ratio across all packages. It represents the total number of tea tokens steeped by package maintainers, package users, package supporters and sponsors, and tea tasters divided by the total tea token supply. Given how many open-source packages are available today and their expected growth, $\chi$ will always be a very small value between $0$ and $1$. Let $\psi$ be the staking ratio. It represents the total number of tea tokens staked by any network participant to secure the network. -Let $\chi_{ideal}$ be the steeping ratio we would like each package to attain for a fair distribution of rewards across all packages and their dependencies. The value of $\chi_{ideal}$ must be updated as new packages are added to the decentralized registry, and dependencies are created. To determine the best value for $\chi_{ideal}$, we will use a popularity bell curve updated at the start of each reward cycle. +Let $\chi_{ideal}$ be the steeping ratio we would like each package to attain for a fair distribution of rewards across all packages and their dependencies. The value of $\chi_{ideal}$ must be updated as new packages are added to the decentralized registry and dependencies are created. To determine the best value for $\chi_{ideal}$, we will use a popularity bell curve updated at the start of each reward cycle. Let $\tau = \tau(\chi)$ be the annual steeping interest rate distributed to all tea community members who steep tea tokens to support open-source developers. In other words, $\tau(\chi)$ corresponds to the steeping reward received over a year by a community member that steeps tea tokens for the entire year. @@ -251,7 +251,7 @@ Let $\delta$ be the annual inflation directed at the network treasury. $\delta$ We consider the annual steeping reward rate as a function of $\chi$ and the annual staking reward rate as a function of $\psi$. * $\tau(\chi)$ corresponds to the incentive for people to steep a package. As $\chi$ increases, fewer rewards $\tau(\chi)$ are needed. -* $\gamma(\psi)$ corresponds to the incentive for people to stake the network. As $\psi$ increases, fewer rewards $\gamma(\psi)$ are needed to secure the network. +* $\gamma(\psi)$ corresponds to the incentive for people to stake on the network. As $\psi$ increases, fewer rewards $\gamma(\psi)$ are needed to secure the network. The annual inflation $I$ will be equivalent to $(\tau + \gamma + \delta)$ and calculated as follows: @@ -323,7 +323,7 @@ As the tea system matures, we foresee the community deciding and contributing to ## tea Wholesalers -Open-source software communities are vibrant and constantly looking to innovate and deliver value. This dedication and altruism lead to the constant building of new software and packages, each one pulling dependencies. As a result, we anticipate the dependencies map to evolve constantly, leading to frequent changes to the steeping ratio and rewards. In the future, the tea community may propose the development of a system designed to dynamically monitor the steeping ratio for each package and rebalance how package supporters steep their tokens based on their own criteria. +Open-source software communities are vibrant and constantly looking to innovate and deliver value. This dedication and altruism leads to the constant building of new software and packages, each one pulling dependencies. As a result, we anticipate the dependencies map to evolve constantly, leading to frequent changes to the steeping ratio and rewards. In the future, the tea community may propose the development of a system designed to dynamically monitor the steeping ratio for each package and rebalance how package supporters steep their tokens based on their own criteria. ## Royalties on Package Transfer @@ -360,7 +360,7 @@ $\parskip=0pt plus 1pt$ |------|------------| | Leaf | The smallest denomination of the tea token. A leaf corresponds to one one-hundred-millionth ($10^{-8}$) of a tea. | | Slashing | The action of penalizing steepers or stakers in response to behavior contrary to the network rules. | -| Staking | The action of locking tea tokens to secure the proof-of-stake network upon which the tea system is built. | +| Staking | The action of locking tea tokens to secure the proof of stake network upon which the tea system is built. | | Steeping | The action of locking tea tokens to support your claim and receive rewards (or penalties) based on the consensus on the validity of your claim. |