API/RSS

Social

Tea.xyz: Decentralized protocols that can be used to incentivize open source ecosystems

22-12-07 11:28

Read this article in 79 Minutes

AI summary

View the summary

原文标题：《 Tea.xyz：可用于激励开源生态系统的去中心化协议》

原文作者： Max Howell Timothy Lewis Thomas Borrel

原文编译：阿法兔

The purpose of this agreement is to create an open, public, and stable registry for all open source software, enabling the project to release versions independently, without relying on third parties, into hundreds of separate (and duplicate) systems with these irregular collections of data. Through the tea protocol, the maintainers of open source software packages can release their versions to a decentralized registry driven by blockchain, thus eliminating a single source of failure and releasing versions that cannot be tampered with, allowing the community to manage the entire open source ecosystem region and avoid external influences.

Tea can energize open source ecosystems, primarily by allowing developers who participate in the Tea agreement to pledge the value they can capture against the software packages they rely on and want to protect. Diagrams of the Tea protocol can provide tamper-proof registration of the package, requirements for dependencies, verification of the authenticity of the package, and the predictive machine to inform the tea reward incentive algorithm. Systematic inflation, based on the algorithm will be allocated to all software packages, if security or development problems are found, developers can upload evidence, can be against the software package claims, the system will have errors and security uploads for claims. Members of the open source community can review software packages for quality issues, and the Tea Protocol can respond to these reviews by setting proportional incentives.

1. Statement

The information set out in this white paper is still at a preliminary stage. Therefore, neither the author of this article nor the relevant agencies shall assume any responsibility for the final result or accuracy of the following information. This statement applies to the maximum extent permitted by law, and neither the author nor the relevant agencies shall assume any responsibility for any infringement, contract or other content in connection with this White paper.

Nothing in this White Paper or anything in it shall constitute a basis in connection with, or cause for, any contract or undertaking, and nothing in this White paper shall constitute a sales promotion of any of the tokens discussed herein. This White Paper is not intended to convey all views and information relating to the marketing in any jurisdiction where a license or registration is required and, in particular, as of the date of this White Paper, none of the tokens discussed herein are and are not intended to be registered under the securities or relevant laws of any jurisdiction. The tokens mentioned in this White Paper may not be offered or sold in any jurisdiction where a Token sale would constitute a violation of the relevant laws of that jurisdiction.

2. License

The source code for this article, Creative Commons Copyright Attribution - same way Share 4.0 International Public License form is provided.

3. 引言

The Internet is largely made up of open source projects, as it has been since its inception. Over time, many open source projects have become the foundation and building blocks of today's Internet, upon which all future Internet innovations need to be built. Although many people and companies have made fortunes from the foundation of the Internet built by open source projects, they are largely created and maintained for free.

We firmly believe that human endeavor will be hampered by a process in which a small percentage of the world's engineers choose between generating electricity for love and having to work for a paycheck or maintaining the open-source projects that make the Internet so important. Open source generates electricity for love, so it is often hampered by a lack of financial incentives, so that projects of real value never reach their potential, and many open source projects suffer from security problems due to the lack of incentives to maintain software throughout its life cycle. To realize the full potential of open source projects, we need to establish a fair compensation system for the open source ecosystem without fundamentally changing the way it is built and utilized.

Commercial enterprises often revolve around the open source packaging business model, earning revenue directly from the work of benevolent developers while also relying on them to fix problems as they occur. A prime example is the recent security breach of Log4j, a software package owned by the Apache Software Foundation that plays an important role in many commercial software and services used by enterprises and governments. In November 2021, a security researcher reported the CVE-2021-442283 vulnerability, which received the highest score from the Apache Software Foundation, Amit Yoran, CEO of Tenable and founding president of the United States Computer Emergency Readiness Team (US-CERT), described the vulnerability as "the largest and most serious single vulnerability in the last decade."

Panic ensued, and the volunteers who maintained the software package for Love Power were publicly lambasted for the problems, though the system has since been patched. But businesses and governments have also finally realised that Log4j, a software package that has been used by a wide range of critical systems for 20 years, is maintained by unpaid volunteers who generate electricity, unsung heroes who have worked tirelessly to fix bugs despite industry criticism. Frighteningly, Log4j is not alone. core-js, which is downloaded 30 million times a week, is an important foundation for Node.js, but it's also barely funded at all. Several other key Bitcoin developers have recently resigned, citing in part perceived financial compensation. Open source projects have made many attempts to provide incentive structures, often focusing on sponsorship and bounty systems. Sponsorship model, which allows open source users to donate to their favorite projects.

However, if we think of open source as a tower of bricks, the foundation layer is long forgotten, but still maintained by dedicated engineers. These foundation layers host important projects that many developers must use. But usually only a few projects at the top of the tower are well-known enough to be sponsored. This highly biased selection results in the tower's foundation bricks not receiving any donations or sponsorship, while the most popular projects and people receive far more than they need. Open source bounties allow users of a project to pay developers to build specific features, so it is not necessarily in the best interest of engineers to reward only what the project needs to do, since only the most popular projects are rewarded by users.

In this paper, we propose a decentralized protocol Tea to equitably reward open source developers based on their contributions to the overall ecosystem, and apply the tea incentive algorithm to all entries in the tea registry.

4. Some components

An engineer needs four parts to develop an application: a browser, a terminal, an editor, and a package manager. Of these four things, the package manager is the one that controls the tools and frameworks developers need to build their products, and this layer is where we are likely to change the way we see open source paid and incentivise.

4.1 Package Manager

With the package manager, you can identify which open source software the functionality of your developed application depends on, either at the top level or at the underlying base layer. All components and versions that are critical to developing the application are documented. The package manager can be uniquely placed in the developer's tool stack to enable automatic and precise value allocation based on real-world applications.

This white paper proposes a tamper-free, decentralized registry designed to assign value based on algorithms that determine each entry's contribution to the utility and health of the overall system. Value can enter the figure from the vertices -- applications and base libraries -- and be assigned to the dependencies of those vertices because the registry knows how value flows throughout the open source diagram.

In addition, we believe that material information must be provided through the package manager so that developers can assess whether they can trust a software package and its developers. This letter can be based on reputation, community recognition, from decentralized identity (DID: see: https://www.w3.org/TR/did-core/) system to retrieve the data, or other package manager may depend on the network participants, the economic value at risk of incentive mechanism.

We believe that the combination of tools, information, and rewards provided by Tea will provide fair incentives to developers, help spur the growth of open source software, and promote innovation.

4.2 Decentralized registry

Each package manager has its own package registry, repeating the same Metadata. Now is the time for a comprehensive and unambiguous registry designed by the community that can be managed singly. We believe that decentralized, tamper-proof registries provide security, stability, and protection against human malfeasance.

The Internet we have today runs on tens of thousands of important open source components. It's worth noting that so far, there have been a number of incidents caused by the removal of basic open source infrastructure, most notably the 2016 NPM left-pad7 issue, which affected continuous integration and continuous deployment systems and caused some problems for developers. This incident shows that the Internet is built on fragile development systems, and other examples include software package maintainers who actively or intentionally sabotage their own software packages (such as colo.js, faker.js8, and node-ipc9), or bad guys who wish to sabotage software packages by pretending to maintain them, To steal bitcoins' private keys, or packages with malicious misspellings, also known as tynosquatting, hoping to trick users into installing them, such as crossenv's cross-env NPM package (note 11).

As the industry moves toward digital assets, many things become part of the software, so the integrity of the software needs to be ensured. We cannot continue to be affected by malicious actors modifying software. However, most package manager tools do not guarantee these built-in applications and Dapps because the software packages are unmodified open source code released by the original author. GitHub found that 17% of the software had bugs and malicious purposes (note 12), some of which went undetected for long periods of time.

If there is a decentralized registry, coupled with a reputation system, supported by financial incentives, can bad software actors be exposed? And reward good software participants? This innovative approach may provide the solution that the current developer community has been looking for.

Figure 1: Simplified view of the Tea decentralized system

In addition, we believe that material information must be provided through the package manager so that developers can assess whether they can trust a package and its authors. This information may be based on reputation, community acclaim, data retrieved from the decentralized Identity (DID6) system, other package managers, or incentives that may rely on network participants to put economic value at risk.

We predict that Tea's combination of tools, information, and rewards will serve as a fair incentive for developers, helping spur the growth of open source software and fostering innovation.

4.3 Storage System

Open source packages offer a very wide range of features, some of which may be limited or not needed. encryption is a typical example of this. However, this technology can also be used for nefarious purposes (see Phantom Secure, dismantled by law enforcement agencies, March 2018 14), Or may be compromised to support law enforcement activities (see Operation Ironside (AFP), Operation Greenlight (Europol), and Operation Trojan Shield (FBI) 15, The FBI operates an "encrypted" communications platform, AN0M, and persuades criminals to use their "encrypted" phones for secure communications). The widespread use of encryption makes it a perfect use case for open source software and a good example that any solution for storing packages must be tamper-proof. tea is a decentralized protocol that does not plan to interfere, filter, or sanction software packages based on their functionality. While Tea governance may choose to remove proven malware packages (see the Governance section for more information on this section), it is critical that tea systems connect to multiple storage systems, including proof that packages have not been modified, and that decentralized storage systems are replicated correctly, so that the package maintainer can choose the storage system that best suits his needs. To securely store and distribute these packages.

5. Network participants

Tea's vision is to empower the entire open source community and ensure that its contributors are supported in creating the basic tools that build the Internet. In this whitepaper, we distinguish participants by their contributions, some who contribute code, some who validate the code they contribute, and others who may provide financial value to support the developers and their reputation.

5.1 Package Maintainer

Package maintainers must ensure that their software continues to provide more and more value as the industry evolves.

tea would assume that package creators maintain their work. Package maintainers are the backbone of the open source community, and these developers need to be empowered and incentivified to contribute on an ongoing basis, because package maintainers may decide to stop maintaining the software or realize that they don't have the means to work at a pace that is consistent with the expectations of the software users. When a package is successfully submitted, the package maintainer receives an unforgerable token (NFT) (see the NFT section for more details).

This NFT is used to demonstrate the work of the package maintainer and is the key to guiding the Tea award. The NFT holder of a package can transfer his or her NFT to other developers (or a group of developers) so that the new developer can become the maintainer of the package and the recipient of potential future awards. Similarly, a developer can assume the role of package maintainer by forking an existing package and submitting a new package, making himself the creator and maintainer of the package. It also provides the developer community with the right tools to determine which packages are being maintained, and to confirm that maintaining reputation and quality of work was and is critical. We often see open source contributions maliciously tampered with, and many people's efforts destroyed by the perpetrators. While the malicious elements are often discovered and remedied, they are often not discovered until financial or data losses cause significant damage. With the EventStream npm package (note: 16) For example, EventStream npm is downloaded over 1.5 million times per week and is relied upon by over 1,500 software packages. When a hacker managed to infiltrate the open source project, gain the trust of its original author, and modify EventStream to rely on a malicious software package, The bitcoin wallet's credentials are leaked to a third-party server. While tools can help detect some of these attacks, they are not always reliable. We propose that through the Tea Token section, incentives be introduced to encourage the open source community to report their findings constructively so that package maintainers can address problems before they arise.

5.2 Package Users

Package users are developers focused on solving specific problems. Developers often look to the open source community for the tools they need, and want to quickly experiment and iterate on technology at little or no cost. These developers benefit directly from the work of package creators and maintainers. Traditionally, some people might choose to support the maintainers of open source software packages through donations or other forms of compensation, but donations are a drop in the bucket.

Sponsorship can also be an effective way to support open source software development, but the problem is that payments from sponsorship often do not extend to all dependencies. While this limitation benefits the sponsor, it impedes open source innovation and software building. In order for positive motivation and motivation to empower all software developers, beginner and expert alike, Open source must be accessible to all developers.

The goal of Tea is to provide a decentralized system while maintaining the core values of open source software, and to pay developers for maintaining open source software packages. To achieve this vision, Tea plans to use a development -- incentivizy-development -- mechanism to enable users of the software package to support the software package maintainers through the unique application scenarios of Tea Token, which can be seen in the Tea Token future work Plans and potential community efforts section of this white paper.

5.3 Package supporters and sponsors

In Web2.0 and Web3, backers of a software package are often referred to as "sponsors". Sponsors are organizations or software package users who use open source software to build commercial products, as well as activists who want to support the open source ecosystem, as well as entrepreneurs who want to fund teams that have developed components for larger systems.

tea proposes to extend the community of package supporters to the entire tea community, be it organizations, developers, users, or technology enthusiasts. The goal of tea is to implement decentralized incentives through the unique use cases of Tea Token so that all members of the Tea community can contribute to the permanent sustainability and continued growth of open source. Package supporters and sponsors are free to decide which packages or maintainers of open source software they want to support based on their work, beliefs, or any criteria and metrics that influence their decisions. In addition, package backers and sponsors provide support that flows to the dependencies of each package, thereby implicitly trusting that package maintainers will make good choices about their stack and use this information to promote their reputation.

As long as the package maintenance engineer is able to provide such a service, package sponsors can benefit from accelerated SLAs or more flexible licensing by receiving advanced support levels of NFT in return. In addition, package backers and sponsors can decide which open source packages or open source package maintainers to support, and automatically redirect all or a percentage of their incentives to motivate teams to build new open source software. In other words, the software package does not need to exist to be incentivized with tea, and nascent projects can be supported as well as more mature projects, further incentivizing the evolving open source environment.

5.4 Tea testers

With the release of a new package or a new version of an existing package, proof of the effectiveness of the work is needed, because this information is very important to gain the trust of the users of the open source software, who will decide whether to trust the open source package and its maintainers. In the Tea protocol, this function is performed by the Tea Taster(appraiser/taster).

Appraisers are usually experienced developers who are willing to spend some time examining the claims related to the software package (functionality, security, semantic version (Note 17), license accuracy, etc.) and put their reputation and financial value on the line to justify their research and analysis.In the Tea protocol, we call it "Steeping your tea ", locking in Tea tokens to support the appraisals of the tea connoisseur and receiving rewards (or penalties) based on the consensus on the validity of the comments. Like proponents of open source packages, evaluators can influence the reputation of open source packages and the engineers who maintain them; However, their influence is even more pronounced because of their ability to verify the security, functionality, and quality of open source software packages. Of course, appraisers also need to build their own reputations to back up their claims. The quality of an appraiser's work and access to community reviews, when combined with other external data sources, will build each appraiser's own reputation and add value to the work. For more details on the mechanisms used to influence the reputation of open source packages and package maintainers, see the Package Reputation section of this whitepaper.

6. Agreement Overview

Designing a protocol that incentivizes open source contributions is challenging. As the name implies, open source software is open to all, and is therefore subject to misreference, appropriation, or malicious tampering. However, the open source community has demonstrated a willingness to highlight good community participants and expose bad ones. Historically in the open source community, the effort to review and comment on the code contributions of other developers has been entirely voluntary, although reporting and defending the results of code reviews has been time-consuming and critical.

We plan to create a trusted publishing platform for application development that is guaranteed by the reputation and financial incentives of community members, because we believe that effective incentives for open source contributions cannot succeed without a reputation system and the ability of community members to communicate their findings in a timely manner, and without their own ability to support (and oppose) developers or development efforts in the open source community.

We need to provide developers with tools for accessing and contributing to the reputation system, including simple visual and programmable access to understand software dependencies and reputation. Such a mechanism would help to clearly understand which members of the open source community are contributing to the maintenance of these packages and how many Tea tokens are in the hands of community members. This would help to improve the reputation of the submitted packages given the number of tea tokens owned by the maintenance developer of a particular package, It shows how much support the developer has for their work. These integrated data points will help provide a reputation system for all community members and facilitate community choice. Note that since EventStream was hacked not through the software itself, but through its dependencies with other software, visibility of dependencies between all software is critical to establishing this untrusted system. However, we need to prioritize factors such as computing and transaction ("Gas fees ") costs when designing and building the system.

The goal of this Agreement is to motivate Web2.0 and Web3 developers. The complexity and sheer amount of detail in the software stack makes tracking the installation and uninstallation of software packages an easy victim of hacking or other bad actors. This includes artificially inflating the numbers. Worse is to fundamentally change the nature of open source software by creating unnecessary friction with license keys or other deployment tracking mechanisms. In order to provide the broadest coverage, we believe that incentives cannot simply rely on the concept of tracking installs or uninstalls, but rather on mechanisms that encourage the submission of high-quality packages and the reporting of problematic or high-risk packages. Finally, many pieces of software depend on common dependencies. For example, Lodash has 151,209 dependencies, while chalk has 78,854 and Log4js has 3,343. With more and more software packages using the same dependencies being used, how can incentives be ensured to be distributed fairly and impartially? How do you ensure that the most utilized dependencies are incentivized without bogging down new or emerging packages and developers? How do you make sure that the incentive system doesn't end up discouraging niche developers and sending them off to more rewarding places just because they have incentives? Also, as a developer, how can you identify the packages with the strongest dependencies in order to build leaner, more efficient, and better versions of software alternatives? In the tea agreement, we argued that it was the lack of incentives that hindered the development of open source software. With the right financial incentives and rewards, more developers will be able to build, refine, and iterate on open source software, making the technology world better. Only in this way can Tea tokens represent the true value of open source software.

6.1 Submitting Software Packages

The delivery of a package release requires multiple transactions to occur atomically. Specifically, the package maintainer must

- Register software packages (and their semantic versions) in a decentralized registry.

- Upload software packages to a decentralized storage system to ensure resiliency, censorship resistance, and easy distribution.

- Contribute to the reputation and credibility of the package through the Tea token.

Failure in any of these three operations causes the protocol to revert to its previous state, thus eliminating any evidence submitted.

When the package is successfully submitted, the package maintainer will receive a maintainer NFT to certify their work and contribution to open source. The package maintainer may transfer the tea making awards 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 will suffer over time. When the reputation of any member of the tea community reaches a key milestone, they may be granted an advanced part of the access agreement or receive an accelerated award, as determined by the tea administration. For more details on the Maintainer NFT, see the Maintainer NFT section.

6.1.1 Dependency Analysis

The dependencies of a software package can be deep, because every software package tends to have dependents and dependents. To provide an easy way to reward all developers who contribute to open source software, while maintaining quick creation and computational efficiency of the dependency tree, we recommend that only the first level of dependencies be verified when submitting packages.

This design is driven by the assumption that each dependency is itself an independent package submitted to the tea plant. In this way, each of its dependencies can be mapped, and if its dependencies themselves have dependencies, those dependencies will be mapped when the dependency package is submitted.

Figure 2: Dependency analysis diagram

In Figure 2, the submission of package A triggers analysis of runtime dependencies 1 to n and build dependencies 1 to n, while runtime dependencies 1.1 to 1.n and build dependencies 1.1 to 1.n are analyzed when package B is committed. We will apply the same approach to incentive allocation because the tea making token is distributed across all the dependencies, so that the tea making is recursively listed as the packet of the dependency (see Figure 3).

Versioning and conflicting dependencies are significant challenges, and resolving these issues can become a significant time drain. To solve this problem, we recommend that every package be fully scanned for dependencies upon submission so that we can ensure that the package complies with the following semantic version-range rules. Software packages can only limit their dependencies to one major version, although the starting point for this range can be any valid semantic version (e.g., > = 5.2.1 & lt; 6) :

- If a dependency is upgraded to a newer major version, Tea may need to add the major version of the package.

- Similarly, if a dependency is upgraded to a newer minor version, tea may require a minor version of the package to be added.

- Tea may require a smaller version of the package if a new dependency is added.

Figure 3: Reward distribution in dependencies.

Given the unnecessary effort that any software package user expend when the above rules are violated, we suggest that a portion of the tea token made by the software package maintainers be cut to reflect their lack of due effort. If a developer forces everyone to play with their cups, someone will knock over some tea. Since dependency scanning is expected to occur at submission time, we should note that there is no tea brewing from package supporters and sponsors or tea tasters.

6.2 Reputation of packages and package maintainers

Package maintainers must contribute to the reputation and credibility of their packages by making Tea leaf tokens. However, a reputation system that relies solely on the financial contributions of the author does not provide adequate user protection and may be subject to Sybil attacks, where a person creates multiple representatives of their own and leaves a large number of positive reviews on their work, tricking users into believing that their work has been reviewed and approved by many people.

There are several ways to prevent a Sybil Attack, Some of these methods are described by Nitish Balachandran and Sugata Sanyal in "A Review of Techniques to Mitigate Sybil Attacks ". Because tea is a decentralized protocol, using a trusted authentication system that relies on a centralized certificate authority would violate its core. We propose to focus on a decentralized approach to mitigating the Sybil attack, more specifically, one that relies on incentives from a large group of network participants to evaluate and publicly represent the reputation of each package and its maintainers. Similar to block production on a PoS (proof of interest) blockchain, non-production nodes can verify the work of others and highlight violations of network rules if necessary, which will result in punishing bad actors by paring (destroying a portion of their equity). We propose a system where third parties (aka tea tasters) can review packages produced by package maintainers and financially incentivize them to act in the best interests of the open source software community and its users, while recognizing good behavior and punishing bad behavior. The system must be both Sybil resistant and prevent large token holders from having a material impact on the reputation of the protocol or specific software package. We see this approach as more consistent with open source, providing a more fertile substrate for promoting adoption and trust, and ultimately the development of the Tea protocol.

6.3 Third-party Software package Review

Third-party package review is an important component of reputation building, however, third-party review has its own unique set of threats, including the aforementioned Sybil attack (witch attack).

Blockchain technology, and more specifically, bets, offer tea a unique opportunity to address this challenge. While wallet addresses may be unlimited, that is not the case with tea tokens, whose initial supply is expected to be $10 billion. In addition, every action taken by a developer, such as submitting a parcel, verifying a parcel, or making a tea parcel, will contribute to their reputation, thus creating a unique profile that each developer can use to contribute to the tea community and participate in the governance of tea.

By requiring third-party reviewers to soak tea tokens, who risk losing part of the soaked token if they act against the interests of the network or become a bad actor, the third party can provide a package with additional credibility and receive a reward, in the form of tea tokens.

We also propose that the reputation system be extended to third parties who independently verify packages - tea tasters. A positive review requires two atomization operations to complete. Submit the code for review, be signed by the taster, and demonstrate the review by publicly brewing the "pro" (and "against") package to all members of the community.

Completing a negative review that contains one or more critical vulnerabilities will require the tea taster to first contact the package maintainer using a messaging protocol to notify them of the vulnerability and have them resolve the issue in a timely manner. After the governance period assigned to the package maintainer to address its vulnerabilities expires, or when the corrected package becomes available, the same messaging protocol is used to notify all users and testers (including dependencies) of the package that a vulnerability has been discovered and is expected to be resolved, so they know to update their application or dependencies. To prevent wasting the developer's time, the communication between the tea taster and the package maintainer will require the tea taster to make tea tokens.

After completing these two operations, the tea taster will receive an NFT as evidence of their work on the specific package and package version. The accumulation of NFT, combined with the soaking rate of each package reviewed and information extracted from external systems, will inform the taster's reputation. When their reputation reaches key milestones, tasters can receive a higher portion of the agreement or an accelerated award, as determined by the tea administration.

6.4 Outdated or Damaged Software Packages

tea's mission is to reward contributors and participants in the open source community; However, the rewards must be commensurate with the efforts of the package maintainers and tea tasters. Undermaintained, out-of-date, or damaged software packages are clear signs that the package maintainers are not living up to community expectations or honoring the trust and support given to them by soaking the package. Another manifestation of outdated software packages may be the continued use of legacy languages or legacy versions of multi-version languages. The length of time the software package is out of date or damaged indicates that the taster needs to regularly and continuously review the work of the software package maintainer.

Tea tasters are key members of the open source community, and their comments and related statements can guide package users to use or not use the package. To ensure that reviews can be trusted on an ongoing basis, we have come up with a mechanism whereby outdated or damaged packages can see part of their soaking token sent to the tea taster who first notices that any package lacks maintenance.

Any negative comments that outline a flaw, such as a zero-day vulnerability or use an outdated dependency, and remain open after a grace period defined by governance should be viewed as a failure on the part of the package maintainer. They did not perform the tasks they were entrusted and rewarded for. The same goes for package boosters and sponsors who have staked their reputations on the work of delinquent package maintainers and been rewarded for it, yet failed to spot the lack of maintenance, or have chosen to continue supporting the package regardless.

As software packages grow in popularity and use, and more applications and potentially mission-critical systems depend on them, we must incentivitize developers to prudently report defects to package maintainers, who address them before they can be exploited. We therefore recommend that any expired or damaged package that is subject to one or more documented negative reviews and remains in that state after the grace period defined by governance will have a portion of its soaked token cut off, regardless of its source (package maintainer, package supporter, sponsor or previous tea taster), The other was sent to tea tasters who submitted negative reviews. The allocation of all tea tasters can be based on the age of their reviews and the number of tea tokens they have made for their reviews.

6.5 NFT for Open Source maintainers

Upon successful submission of the package, the package maintainer will receive an NFT to certify their work and contribution. The holder of the NFT will automatically receive all rewards associated with the package. The package maintainer can transfer maintenance ownership of the package to another package maintainer by simply transferring the NFT of the package. A successful transfer of the NFT will result in the new owner automatically receiving future package incentives. An important part of reputation building depends on the frequency and quantity of quality package submissions. The NFT given to the package maintainer as evidence of their work can be used by the reputation system to renew the reputation of the package maintainer and give them access to the senior part of the agreement, as determined by the Tea governance. However, in order to prevent attack vectors such as community members from buying their reputation, the transfer of maintainer NFT will not result in the transfer of reputation. Reputation must remain directly related to the work of a particular developer and must not be transferable.

7.Tea Token

7.1 Ensuring network Security

Although many blockchains appear to be effective and secure infrastructure solutions that can support the goals the Tea protocol is intended to achieve, we believe that. The technology stack of the system building the Tea protocol must be carefully considered.

Scalability, cost-effectiveness, ESG, and third party scalability are important design considerations in the design of the Tea protocol, because in this way, the proof-of-equity tea protocol system works better. In the proof of interest, node operators and network participants pledge the economic value in the form of original tokens on the chain, so as to improve the security of the system. Node operators and network participants are rewarded for successfully producing blocks that conform to network rules and contain accurate transaction information. Inactivity (aka node downtime) or malicious/incorrect activity is penalized by the loss of a portion of the pledged tokens.

A Tea Token-driven proof of equity system would allow Tea Token holders, by mortgaging Tea tokens, to contribute to the security of the system and support open source developers by making tea. We are also aware that economic factors may prevent some developers from mortgaging or serving tea tokens; Thus, the cost of mortgage and soaking would be as low as one leaf, with the smallest tea denomination representing one in 100 million (10-8) tea leaves. These two applications of Tea token play an important role in supporting and growing open source ecosystems.

Making tea ensures that the tea system continues to operate safely, so that all network participants can submit and access packages, review them, and integrate them into their applications, etc. Instead, tea making will support Teaxi's goal of providing all network participants with the tools to support and use packages that meet quality and reliability requirements, as formulated by the tea community through support and dissent for each package, and will take a cautious approach in defining and implementing tea making parameters.

7.2 Incentives and penalties

As discussed above, bad actors have strong incentives to damage open-source software, on which much of the Internet's critical infrastructure runs, and the race is on to find and exploit vulnerabilities. The tea protocol holds that package maintainers are not to blame (though they often are).

The tea agreement aims to solve this problem through fair and just incentives. Packages like Lodash, with more than 151,000 dependencies, are the backbone of open source development efforts, and their maintainers deserve to be rewarded accordingly. However, a reward system based solely on the number of dependents. Will prevent innovators from breaking these monopolies unless they have sufficient third-party funding or have accumulated sufficient resources to self-fund. This approach is likely to shrink the number of contributors, leading to the opposite of the tea's vision.

The goal of tea is to represent the values of open source software and, in the process, to promote the development of open source software by empowering participants with the resources they need to pursue their vision and passion unhindered. tea incentive distribution systems require careful consideration of the proportion of tea served in each package and dynamic adjustment of the incentive for each package accordingly. To reduce the risk of collecting the majority of the tea making rewards as a few packets of dependency in many applications, we will utilize the web3 foundation as a reward mechanism based on Polkadot proof of equity.

We may further adjust the implementation plan and its variables based on the results of practice in the actual situation. When a package exceeds its optimal tea making ratio, the tea making reward ratio will drop sharply to discourage the behavior of package supporters and tea drinkers. This design can make the low tea preparation rate of the package supporters and tea drinkers alike more attractive. This can also incentivise experienced developers to build alternative packages with high tea-making rates, creating an opportunity for the tea community to balance support for existing software with fostering innovation. In the initial design, the tea serving ratio will be calculated using the circulating supply. The tea community may improve the design to further improve the scalability of the system. Let be the tea making ratio of all bags. It represents the total number of Tea tokens made by package maintainers, package users, package supporters and sponsors, and Tea tasters divided by the total supply of tea tokens. Given how many open source packages are available today and their expected growth, it will always be a very small value between 0 and 1.

We can further adjust the implementation and its variables according to the results of practical experiments. As the tea brew package approaches the optimal tea brew ratio as defined by governance, its tea brew reward ratio will gradually decrease. When a package exceeds its optimal tea preparation ratio, the tea preparation reward ratio will drop sharply to discourage packaging proponents and tea tasters from further soaking the highly infused package. The design could make packaging with less tea more appealing to both packaging proponents and tea drinkers. It may also incentivise experienced developers to build highly tea-making alternatives to software packages, creating opportunities for the tea community to balance support for existing software with fostering innovation. The tea brewing ratio will be calculated using a circular supply in its initial design.

Let be the pledge ratio, representing the total number of Tea tokens pledged by any network participant to protect the network security of the entire protocol

Let the ideal be the tea making ratio that we want each package to achieve when the reward is distributed fairly among all packages and their dependencies. The value of ideal must be updated as new packages are added to the decentralized registry and dependencies are created. To determine the optimal value for ideal, we will use a bell curve of popularity that is updated at the beginning of each reward cycle.

Let = () be the annual Tea brew rate assigned to all Tea Token members of the TEA community to support open source developers. In other words, () corresponds to the steeping reward earned by community members for making Tea tokens throughout the year.

Let = () be the annual pledge rate allocated to all node operators and network participants who pledge Tea tokens to maintain the security of the entire network. In other words, () corresponds to the wager reward received by community members who bet tea tokens over the course of the year.

Let be the annual inflation rate for the entire Tea token Treasury. It may vary with the influence of external factors on Token supply.

We consider the annual tea serving reward rate as a function of the annual betting reward rate.

• () corresponds to people's motivation to buy packages. With the increase, less reward is required ().

• () corresponds to incentives for people to pledge the network. With the increase, fewer rewards () are needed to protect the network.

Annual inflation, I, will be equal to (++) and calculated as follows: I = supply of tokens at the end of the year - supply of tokens at the beginning of the year = (++)

The contribution to inflation of all (incentives allocated to all tea preparers) and all (incentives allocated to all contributors to network security) should be weighed to ensure that the system incentivise the optimal tea preparers/collateral ratio.

Since we are concerned with the incentives distributed within all packages, we determine that all is a function of the rate of tea making, hence all() = - (). From our previous analysis, we can see that all(ideal)= ideal-ideal. Since the goal is to achieve a state of = ideal, the reward ideal() should be maximum at that value.

Let ideal = (ideal) be the reward rate provided by the network under the ideal scenario of = ideal. Let 0 be the limit of all(), because it becomes zero when no member of the Tea community has brewed any packages. The value of 0 should approach zero but not quite zero to incentivize early adopters. Based on research recommendations from the web3 Foundation, we recommend:

• The inflation function grows linearly between = 0 and =ideal and decays exponentially between =ideal and =1.

We chose a similar exponential decrement for all() because it implies exponential decrement for (), and we want the reward to drop sharply above ideal to prevent a single package from getting all the rewards.

The definition of attenuation is that the inflation rate falls by a maximum of 50% when moving d units to the right of ideal, i.e. all(ideal + d) all-0.5.

We present the following interest rate and inflation rate functions, which depend on parameters ideal, ideal, 0, and d.

all() = 0 + (all(ideal) -0) ideal is 0 < ideal all() = 0 + (all(ideal)- 0) -2 (ideal-)/d for ideal < 1

Good actors need to be rewarded, and bad actors need to be clearly identified and punished. The nature of open source software sometimes provides opportunities for bad actors, creating pain points and reputational risks for the entire developer community. Whether it's appropriating the work of open source contributors, to tampering and redistributing packages, or injecting malicious code, the battle between the good guys and the bad guys continues, often with well-funded bad actors who see contaminating open source packages as an opportunity to benefit financially, get them banned from digital shelves, or bring bad reputational effects.

We propose the introduction of a reduction mechanism to create a more substantial disadvantage that directly affects the economic value of the bad actor. As tea tasters evaluate and analyze the code in newly submitted packages, we recommend that tea tasters be given tools and incentives to identify and highlight malicious code so that package users can be aware of the risks and penalize package maintainers, package supporters and sponsors who submit or support harmful code. In this case, the package maintainer should not incur any punishment contrary to that of the package proponents and sponsors or tea tasters who provide positive reviews of the package in question for all evidence-based negative reviews performed according to the rules of the network, and which the package maintainer has dealt with within the prescribed time.

For negative comments made in accordance with the rules of the network, a portion of the tea Token made by the package maintainer, package supporters and sponsors, and previous tea tasters will be reduced if the package maintainer does not resolve within the time limit set by the governance. The other will be locked into an insurance pool controlled by tea governance. The responsible part of tea Governance will work closely with the community to develop policies and rules to distribute the contents of the pool to those affected by the software bug.

The agreement will allocate a third of the tea token soaking to all tea tasters who contribute to negative reviews and soak in the package, based on the number of tea tokens they "object" to the package brewing and how long their token is soaked. In other words, the sooner tea tasters identify and report defects in software packages according to network rules, the more they can be rewarded for supporting safe and efficient open source development.

To prevent community members from randomly voting "against" high brew rate software packages that expect to receive most of the penalty, all tea tokens "against" brew are not rewarded with inflation, and may be subject to decay mechanisms that reduce their value over time.

8. Governance

Governance is critical to the growth, sustainability, and application of any distributed system. The Tea agreement will cover on-chain governance where all Tea Token holders can suggest and vote to change key parameters weighted by Token ownership and reputation. These can include inflation parameters, transaction costs, pledge incentives, tea preparation incentives, or optimal tea preparation ratios. This feature will ensure that these key parameters continue to be iterated and optimized by members of the tea community over time. It is expected that governance will be initiated with a simple model, gradually expanding as the tea system matures, facilitating application, and ensuring progressive decentralization. Some system parameters are not currently subject to governance or support frequent changes to reduce the attack surface due to governance, and the gradual transition to open, decentralized governance will ensure system stability and predictability.

9. Third-party scalability

When we first started building this tool to inspire long-term support from the open source community, we believed it was part of our mission to ensure that third parties could extend the entire tool set. In addition to providing developers with the infrastructure to extend the protocol (including innovative and new ways to further support open source developers), our plans also include the potential to enable other package managers to contribute to the protocol. It is the dreams and efforts of open source engineers that have built these technological innovations that can support our daily lives. We are looking forward to the new uses and expansion of tea proposed by the tea community.

10. Future work vs. Potential community effort.

As the tea system matures, it is foreseen that the community will determine and facilitate the improvement and further expansion of the tea system through governance. Here are a few ideas that we think might spark some inspiration:

10.1 tea Wholesalers

The open source community is dynamic, constantly seeking to innovate and provide value. This dedication and altruism has led to a steady stream of new software and packages, each adding to the software dependency. As a result, we expect this dependency graph to continue to evolve, leading to frequent changes in the steeping ratio and incentives. In the future, the tea community may propose the development of a system designed to dynamically monitor the steeping ratio of each package and, according to its own standards, rebalance how package supporters steeping their own tokens.

10.2 Transfer the copyright fee of the software package

Software package maintainers may decide to transfer their lucrative rewards stream to one or more developers. The management of this transfer must remain the decision of the package maintainer and the partner, free from tea interference. The Tea protocol needs to provide tools so that this transfer can be in whole or in part (perhaps only through a portion of the steeping rewards, redirected to one or more developers, while the rest continues to the original package maintainer), And steeping rewards a single account controlled by a single network participant, multiple network participants, or automatically allocated to multiple accounts using static or dynamic proportions.

10.3 Award distribution among multiple open source software maintainers

The maintenance of a software package can depend on the work of multiple teams of developers. Before the Tea rewards begin to flow, teams should think about how they will be distributed automatically among each other, and how they will be distributed must be decided by the maintainers themselves, as they are best placed to assess who has contributed and how they should be rewarded. To achieve this, each team (or teams) can set up its own decentralized autonomous organization (DAO) and automatically distribute rewards or deploy more complex systems that determine appropriate reward allocations based on external factors such as votes of all DAO members, or time allocations based on continuous contributions, rewards for successful completion, and so on.

10.4 Handling Fork of a Software Package

We think forks are necessary but largely underutilized. Fork can be an effective tool for developing software packages with powerful competitive capabilities in terms of functionality, performance, security, and even attentiveness. Useful as they may be, forking must also acknowledge the original contribution. To pass future work or potential contributions, the Tea community may strengthen the system to require a declaration of forks, perhaps even to detect when the package is submitted. Undeclared forks discovered by the divider may result in some of Steeping's tokens being cut back to the maintainer of the original package and sent to the divider who discovered the fork.

10.5 Running and Building Software Dependencies

tea may not distinguish between built dependencies and runtime dependencies when allocating rewards at startup. However, if there is a strong demand for such a distinction, the tea community can suggest that the allocation algorithm for Steeping rewards be strengthened to take into account the importance of each dependency and their value contribution to dependent packages. These proposals will be voted on and implemented based on community decisions.

10.6 Application Based compensation

As more applications are built using packages registered with tea, the community may add reward algorithms to allocate data sets that can be influenced by external certification (such as usage data sets). This update to the reward system allows more tea token rewards to flow to the software package with the highest usage rate, while still respecting the limit on the soaking ratio described in the Tea Token section. Package maintainers can use a similar approach to assign steeping rewards among their dependencies based on the transparent logic of their choice. Note that all information used to influence the allocation of rewards to packages and dependencies in the tea system needs to be certified as reliable first.

11. Glossary

Reference Materials:

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-operati on-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