From 2435652818e0185a70b0a6f0f5bacb00a980454e Mon Sep 17 00:00:00 2001 From: marketing Date: Sat, 30 Sep 2023 23:59:19 +0000 Subject: [PATCH] GITBOOK-Update to white paper version 2.0 --- .github/pull_request_template.md | 9 - LICENSE.md | 171 --------- README (1).md | 13 + README.md | 481 +++++++++++++++++++------ SUMMARY.md | 4 + i18n/be/white-paper.md | 577 ------------------------------ i18n/bg/white-paper.md | 583 ------------------------------- i18n/de/white-paper.md | 581 ------------------------------ i18n/id/white-paper.md | 582 ------------------------------ i18n/ru/white-paper.md | 581 ------------------------------ i18n/uk/white-paper.md | 583 ------------------------------- i18n/zh/white-paper.md | 509 --------------------------- white-paper.md | 583 ------------------------------- 13 files changed, 393 insertions(+), 4864 deletions(-) delete mode 100644 .github/pull_request_template.md delete mode 100644 LICENSE.md create mode 100644 README (1).md create mode 100644 SUMMARY.md delete mode 100644 i18n/be/white-paper.md delete mode 100644 i18n/bg/white-paper.md delete mode 100644 i18n/de/white-paper.md delete mode 100644 i18n/id/white-paper.md delete mode 100644 i18n/ru/white-paper.md delete mode 100644 i18n/uk/white-paper.md delete mode 100644 i18n/zh/white-paper.md delete mode 100644 white-paper.md diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md deleted file mode 100644 index b904e46..0000000 --- a/.github/pull_request_template.md +++ /dev/null @@ -1,9 +0,0 @@ - - - -- [ ] I created a new folder `i18n/[LANG]` for my translated files -- [ ] I translated `metadata.yml` file -- [ ] I translated `white-paper.md` file -- [ ] Tag @teaxyz to enable CI (if not run by default) -- [ ] Ensure all CI checks pass -- [ ] Review CI-generated PDF artifact to ensure correct generation diff --git a/LICENSE.md b/LICENSE.md deleted file mode 100644 index c5f25be..0000000 --- a/LICENSE.md +++ /dev/null @@ -1,171 +0,0 @@ -# Creative Commons Attribution-ShareAlike 4.0 International - -Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible. - -### Using Creative Commons Public Licenses - -Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses. - -* __Considerations for licensors:__ Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. [More considerations for licensors](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensors). - -* __Considerations for the public:__ By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. [More considerations for the public](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensees). - -## Creative Commons Attribution-ShareAlike 4.0 International Public License - -By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. - -### Section 1 – Definitions. - -a. __Adapted Material__ means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. - -b. __Adapter's License__ means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. - -c. __BY-SA Compatible License__ means a license listed at [creativecommons.org/compatiblelicenses](http://creativecommons.org/compatiblelicenses), approved by Creative Commons as essentially the equivalent of this Public License. - -d. __Copyright and Similar Rights__ means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. - -e. __Effective Technological Measures__ means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. - -f. __Exceptions and Limitations__ means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. - -g. __License Elements__ means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike. - -h. __Licensed Material__ means the artistic or literary work, database, or other material to which the Licensor applied this Public License. - -i. __Licensed Rights__ means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. - -j. __Licensor__ means the individual(s) or entity(ies) granting rights under this Public License. - -k. __Share__ means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. - -l. __Sui Generis Database Rights__ means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. - -m. __You__ means the individual or entity exercising the Licensed Rights under this Public License. __Your__ has a corresponding meaning. - -### Section 2 – Scope. - -a. ___License grant.___ - - 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: - - A. reproduce and Share the Licensed Material, in whole or in part; and - - B. produce, reproduce, and Share Adapted Material. - - 2. __Exceptions and Limitations.__ For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. - - 3. __Term.__ The term of this Public License is specified in Section 6(a). - - 4. __Media and formats; technical modifications allowed.__ The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. - - 5. __Downstream recipients.__ - - A. __Offer from the Licensor – Licensed Material.__ Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. - - B. __Additional offer from the Licensor – Adapted Material.__ Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply. - - C. __No downstream restrictions.__ You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. - - 6. __No endorsement.__ Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). - -b. ___Other rights.___ - - 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. - - 2. Patent and trademark rights are not licensed under this Public License. - - 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. - -### Section 3 – License Conditions. - -Your exercise of the Licensed Rights is expressly made subject to the following conditions. - -a. ___Attribution.___ - - 1. If You Share the Licensed Material (including in modified form), You must: - - A. retain the following if it is supplied by the Licensor with the Licensed Material: - - i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); - - ii. a copyright notice; - - iii. a notice that refers to this Public License; - - iv. a notice that refers to the disclaimer of warranties; - - v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; - - B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and - - C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. - - 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. - - 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. - -b. ___ShareAlike.___ - -In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply. - -1. The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License. - -2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material. - -3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply. - -### Section 4 – Sui Generis Database Rights. - -Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: - -a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; - -b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and - -c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. - -For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. - -### Section 5 – Disclaimer of Warranties and Limitation of Liability. - -a. __Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.__ - -b. __To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.__ - -c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. - -### Section 6 – Term and Termination. - -a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. - -b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: - - 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or - - 2. upon express reinstatement by the Licensor. - - For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. - -c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. - -d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. - -### Section 7 – Other Terms and Conditions. - -a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. - -b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. - -### Section 8 – Interpretation. - -a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. - -b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. - -c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. - -d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. - -> Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” The text of the Creative Commons public licenses is dedicated to the public domain under the [CC0 Public Domain Dedication](https://creativecommons.org/publicdomain/zero/1.0/legalcode). Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at [creativecommons.org/policies](http://creativecommons.org/policies), Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses. -> -> Creative Commons may be contacted at creativecommons.org. \ No newline at end of file diff --git a/README (1).md b/README (1).md new file mode 100644 index 0000000..2770b0f --- /dev/null +++ b/README (1).md @@ -0,0 +1,13 @@ +# README + +![tea](https://tea.xyz/banner.png) + +The tea white paper is a [semantically versioned](https://semver.org), [Markdown](https://daringfireball.net/projects/markdown/). New releases are deployed to Gitbook. + +## tea/white-paper 2.0.0 + +### Contributing + +If you have general feedback, please open a [discussion](discussions/) thread. + +If you have edits please refer to our project-wide [contribution guidelines](https://github.com/teaxyz/.github/blob/main/CONTRIBUTING.md). diff --git a/README.md b/README.md index 8f01c03..1d29d57 100644 --- a/README.md +++ b/README.md @@ -1,105 +1,376 @@ -![tea](https://tea.xyz/banner.png) - -The tea white paper is a [semantically versioned][semver], [Markdown] document -with mathematical representations embedded as [LaTeX]. -New releases are compiled to `.pdf` with [Pandoc] before being -[published here at GitHub][releases]. - -# tea/white-paper 1.0.5 - -## Contributing - -If you have general feedback, please open a [discussion] thread. - -If you have edits please refer to our project-wide [contribution guidelines]. -Then you can either: - -1. Edit [`white-paper.md`] right here on GitHub. - When you submit your pull request our CI will attach the pdf to the PR. -2. Or you can build the white paper on your own computer: - ```sh - make #=> ./tea.white-paper.pdf - ``` - -## Dependencies - -Source these yourself or use tea: `sh <(curl tea.xyz)`. - -| Project | Version | -|---------------------|---------| -| pandoc.org | ^2.18 | -| pandoc.org/crossref | ^0.3 | -| gnome.org/librsvg | ^2.54 | -| gnu.org/make | ^4 | - - -## Translate - -We build, publish and feature full PDFs of all translations at tea.xyz. - -1. [Fork `teaxyz/white-paper`][fork] -2. Then in your terminal: - ```sh - $ export LANG=… # https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes - $ export USER=… # your github - $ export VERSION=$(git describe --abbrev=0) # latest version tag - $ git clone https://github.com/${USER}/white-paper tea-white-paper - … - $ cd tea-white-paper - $ git checkout -b i18n/${LANG} ${VERSION} - … - $ mkdir -p i18n/${LANG} - $ cp white-paper.md metadata.yml i18n/${LANG} - ``` -3. Translate `./i18n/${LANG}/metadata.yml` -4. To `./i18n/${LANG}/metadata.yml` append: - ```yml - lang: … # https://pandoc.org/MANUAL.html#language-variables - dir: ltr # language direction; ltr:left-to-right or rtl:right-to-left - header-includes: - - \fancyfoot[L]{${VERSION}+${LANG}} # expand these variables! - translator: - - Your Fullname - ``` - - ⚠️ Chinese, Japanese, and Korean languages only. Please also add the following to the `metadata.yml`: - ```yml - header-includes: - - \usepackage{xeCJK} - - \setCJKmainfont{Noto Serif CJK XX} # where XX can be SC, TC, HK, JP, KR https://github.com/googlefonts/noto-cjk - ``` -5. Translate `./i18n/${LANG}/white-paper.md` -6. Commit translation to git and push to GitHub: - ```sh - git add i18n/${LANG}/* - git commit -m "add ${LANG} translation" - git push origin i18n/${LANG} - ``` -7. Create a pull request: - ```sh - open https://github.com/teaxyz/white-paper/compare/main...${USER}:white-paper:i18n/${LANG} - ``` - -8. (Optional) Preview your work: - ```sh - make tea.white-paper_${LANG}.pdf - ``` - -## Maintenance - -### Set Version - -```sh -echo "- \fancyfoot[L]{$1}" >> metadata.yml -``` - -[`white-paper.md`]: ./white-paper.md -[Pandoc]: https://pandoc.org -[Markdown]: https://daringfireball.net/projects/markdown/ -[LaTeX]: https://latex-project.org/ -[releases]: ../../releases -[brew]: https://brew.sh -[semver]: https://semver.org -[discussion]: ../../discussions -[fork]: ../../fork -[contribution guidelines]: https://github.com/teaxyz/.github/blob/main/CONTRIBUTING.md +--- +description: Max Howell Thomas Borrel Timothy Lewis Troy Wong +--- + +# A Decentralized Protocol for Open-Source Developers to Capture the Value They Create + +## Abstract + +A system in which open-source developers could receive rewards commensurate with their contributions would enhance the sustainability and integrity of the software supply chain. A decentralized protocol secured by reputation and incentives could accomplish this by facilitating value accrual back to the developers that maintain open-source codebases as a public utility, thus promoting future innovation and growth within the open-source ecosystem. Package maintainers will register their projects with a registry powered by a Byzantine fault-tolerant blockchain. The tea Protocol’s unique “Proof of Contribution” algorithm will determine each project’s contribution and impact to the system’s utility and health. Registered projects will receive rewards from the tea Protocol commensurate with their contribution, be secured through staking, benefit from a reputation system that spans projects and contributors, and have the option to allow communities to govern their regions of the open-source ecosystem, independent of external agendas. The tea Protocol will incentivize the maintenance of open-source by allowing network participants who registered their projects and comply with the rules of the network to receive rewards and contribute to their reputation and their projects’. If security or development issues are found, developers can make claims supported by evidence against the package, and slashing may occur. Members of the open-source community can review packages for quality issues, and the protocol can respond to these reviews by enacting proportional slashing events. + +## Disclaimer + +The information set out in this white paper is of a preliminary nature. Consequently, neither the authors nor any of their respective affiliates assume any responsibility that the information set out herein is final or correct and each of the foregoing disclaims, to the fullest extent permitted by applicable law, any and all liability whether arising in tort, contract or otherwise in respect of this white paper. Neither this white paper nor anything contained herein shall form the basis of or be relied on in connection with or act as an inducement to enter into any contract or commitment whatsoever. + +Nothing in this white paper constitutes an offer to sell or a solicitation to purchase any tokens discussed herein. In any event, were this white paper to be deemed to be such an offer or solicitation, no such offer or solicitation is intended or conveyed by this white paper in any jurisdiction where it is unlawful to do so, where such an offer or solicitation would require a license or registration, or where such an offer or solicitation is subject to restrictions. In particular, any tokens discussed herein have not been, and, as of the date of issuance of this white paper, are not intended to be, registered under the securities or similar laws of any jurisdiction, whether or not such jurisdiction considers such tokens to be a security or similar instrument and may not be offered or sold in any jurisdiction where to do so would constitute a violation of the relevant laws of such jurisdiction. Do not purchase any tokens unless you’re prepared to lose the entire purchase price. It is a high-risk purchase and you are unlikely to be protected if something goes wrong. + +## License + +This paper is available under the [Creative Commons Attribution-ShareAlike 4.0 International license](https://creativecommons.org/licenses/by-sa/4.0/). + +## Introduction + +The modern-day Internet is predominantly composed of open-source projects and has been since its inception. Open-source projects are developed and maintained via collaboration amongst global developer communities, and their codebases are made available for anyone to utilize as a public good. In the past 80 years (it is [generally believed](https://archive.org/details/historyofmodernc00ceru) that the first example of free and open-source software was released in 1953), open-source software has evolved from the product of niche technology hobbyists to the infrastructure upon which all innovation has been built. Despite the importance of open-source software, the developers that create and maintain the codebase as a public utility receive no fungible rewards for their immense contribution as innovators and maintainers. + +Enterprise software, which has grown into a multi-billion dollar industry, is built on the foundation laid by open-source. Yet there is almost no value accrual back to the individuals who thanklessly maintain its very underpinnings. And while fortunes have been made from it, open-source software is mainly created and maintained as a public utility with no viable means for developers to capture the value they create. + +We believe that the potential of the modern-day internet has been stunted by relying on a small percentage of the world’s engineers to maintain open-source software purely out of altruism. Open-source is a labor of love often hindered by a lack of meaningful incentives for core maintainers. Open source developers must choose between a day job that provides living wages or maintaining the very foundation of enterprise software. A lack of incentives results in genuinely worthwhile projects never reaching their potential while others suffer from security issues due to a lack of upkeep throughout the software’s lifecycle. To unlock the full potential of open-source, we require a universal method for assessing the “fair value” of open-source projects, enabling open-source developers to capture the value they create by facilitating capital inflows to the open-source community, all without altering the core principles of how open-source is developed and used. + +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. Open-source codebases offer plug-and-play core functionality for enterprises; however, software vulnerabilities can pose an immense risk for applications built on top of open-source. A great example is a recent incident involving a critical security vulnerability in Log4j, a package from the [Apache Software Foundatio](https://www.apache.org/)n 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.](https://www.alibabagroup.com/) reported vulnerability [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228), which received the highest possible base score from the Apache Software Foundation. Amit Yoran, Chief Executive of [Tenable](https://www.tenable.com/) and founding director of the United States Computer Emergency Readiness Team (US-CERT), described this vulnerability as “[the single biggest, most critical vulnerability of the last decade](https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA)”. 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](https://twitter.com/yazicivo/status/1469349956880408583) and worked tirelessly to address the vulnerability. + +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, potentially forcing it’s primary maintainer to [walk away from the project or even change the license to closed source](https://www.thestack.technology/core-js-maintainer-denis-pusharev-license-broke-angry/). Recently several bitcoin core developers resigned, citing, among other reasons, a lack of financial compensation for their decision. + +

Figure 1 - Dependency - Source: https://xkcd.com/2347/

+ +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 rewarding projects for doing things that may not be in their best interest. And again, only rewarding favorites. + +At tea, we’ve seen too many open-source projects suffering from these failed attempts at supporting the open-source community and have made it our mission to enhance the sustainability and integrity of the software supply chain by allowing open-source developers to capture the value they create. + +In this paper, we propose tea — a decentralized system for + +1. computing and assigning a “[Proof of Contribution](./#proof-of-contribution)” to every open-source project relative to the entire ecosystem, +2. ensuring open-source software projects are well maintained, +3. empowering open-source developers with equitable rewards proportionate to their ecosystem-wide contributions, achieved through the implementation of the tea incentive algorithm across every entry in the tea registry, and +4. incentivizing network participants to follow responsible disclosure practices for vulnerabilities and bugs. + +## Components + +A software developer building an application needs four things: a browser, a terminal, an editor, and a package manager. Of these four, the package manager is what controls the tooling and frameworks a developer needs to construct their product. This layer is where we see the potential to change how open-source is secured and rewarded. + +### The Package Manager + +The package manager knows what open-source software a package or application depends upon to function, from the top of the tower to its base. Each project, along with every packaged version, meticulously documents all essential components and their corresponding versions. + +It knows that the top of the tower carefully selects its dependencies, and that careful selection continues down. The package manager is uniquely placed in the developer tool stack to enable automated and precise value distribution based on actual real-world contribution. + +We propose an immutable decentralized registry designed to distribute value based on the tea Protocol’s unique “Proof of Contribution”, an algorithm that determines each project’s contribution and impact to the system’s utility and health. Value can enter the graph at apex points—such as essential libraries—and be distributed to the dependencies of those packages and their dependencies recursively since the registry knows the entire open-source graph. + +Additionally, we believe that the information provided by the protocol’s Proof of Contribution must be available for developers to assess whether they can trust a project and its author. This information may be based on reputation, community kudos, data retrieved from decentralized identity ("[DID](https://www.w3.org/TR/did-core/)") systems, other package managers, or incentive mechanisms that potentially rely on network participants putting value at risk. + +We predict that tea’s combination of tools, information, and rewards will justly incentivize developers, helping secure the software supply chain, stimulating the growth of open-source software, and fostering innovation. + +### The Decentralized Registry + +Every package manager has its own package registry duplicating the same metadata repeatedly. In some cases, this registry may include [information that differs from the project’s manifest](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/), thus allowing bad actors to potentially inject nefarious code unbeknownst to the user. 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 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 dependency](https://www.theregister.com/2016/03/23/npm\_left\_pad\_chaos/) 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 and faker.js](https://fossa.com/blog/npm-packages-colors-faker-corrupted/), as well as [node-ipc](https://www.lunasec.io/docs/blog/node-ipc-protestware/)), 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](https://github.com/dominictarr/event-stream/issues/116)), or malicious packages with intentional misspelling errors, also known as “[typosquatting](https://en.wikipedia.org/wiki/Typosquatting)”, in the hope of tricking users into installing them, for example [crossenv vs. cross-env NPM packages](https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html). + +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. + +Most tools that we call package managers cannot guarantee that these packages built into the apps and dApps are the unaltered open-source code published by their original authors. [Microsoft’s GitHub has found that 17% of vulnerabilities in software were planted for malicious purposes](https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/), with some remaining undetected for extended periods (See [Webmin 1.890](https://threatpost.com/backdoor-found-in-utility-for-linux/147581/)). + +A global decentralized registry augmented by a reputation system and supported by incentives designed to expose bad actors and reward good ones may provide the guarantees developer communities have been looking for to secure the software supply chain. + +### The Storage System + +Open-source projects 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](https://www.fbi.gov/news/stories/phantom-secure-takedown-031618), dismantled by law enforcement agencies in March 2018) or may be compromised to support law enforcement activities (See [Operation Ironside (AFP), Operation Greenlight (Europol), and Operation Trojan Shield (FBI)](https://www.europol.europa.eu/media-press/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication) 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](./#governance) 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. + +## Protocol Overview + +Designing a protocol to reward open-source contributions presents formidable challenges. Open-source software, being universally accessible, is susceptible to misattribution, appropriation, and malicious tampering. However, the open-source community has consistently demonstrated its willingness to highlight good actors and expose bad actors. Historically, the energy spent reviewing and commenting on other developers’ contributions has been strictly voluntary, despite how time-consuming and crucial reporting and defending findings may be. + +We intend to create a decentralized protocol secured by reputation and incentives that enhances the sustainability and integrity of the software supply chain by allowing open-source developers to capture the value they create in a trustless manner. 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 project or the work of a developer. Additionally, 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 projects. + +Transparency into the TEA tokens staked by community members to support each project enhances each project's reputation, much like the number of tokens a package maintainer stakes on their own work signals their commitment to it. These combined data points will help inform a reputation system for all community members and facilitate choice. As the [event-stream package hack](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502) 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 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, 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](https://www.npmjs.com/package/lodash) has 176,308 open-source dependents while [chalk](https://www.npmjs.com/package/chalk) has 100,247 dependents or [log4js](https://www.npmjs.com/package/log4js/) has 3,809 dependents. As more packages are created using the same dependencies, how do we ensure that rewards 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 visibility and incentives has impeded the evolution of open-source software. Supported by the right incentives and rewards, more developers will be in a position to build, improve and augment open-source software for the betterment of the world. + +### Proof of Contribution + +In this white paper, we propose “Proof of Contribution”, a novel consensus mechanism designed to quantify the impact of all projects across all open-source systems. + +Proof of Contribution assigns a dynamic score, referred to as a project’s teaRank, based on each open-source project’s orientation within, and utilization from the broader open-source ecosystem over time. + +We believe that this approach benefits foundational software far removed from the application layer (which tends to be the most visible layer to the public and attracts most of the interest) and extends the reward mechanism to ensure that all components of a project—from the top of the tree, all the way to its base—are rewarded for their contribution. + +To calculate each project’s score, teaRank builds upon the foundation laid by [Google's PageRank](https://en.wikipedia.org/wiki/PageRank) algorithm. Google’s PageRank is the search product’s defining component and is built on the graph-like structure of web pages. PageRank, at its core, is a probability distribution algorithm that assigns scores to nodes in a graph, representing the likelihood that anything randomly navigating the graph will arrive at a particular node. This algorithm is particularly effective in a graph-like data structure, such as the internet, because it quantifies the impact of each node (or web page) based on the quantity and quality of edges (links) to it. This algorithm was modified over time to better discern the web’s topology and identify fraudulent links between web pages, allowing various attacks to be mitigated. + +Because the graph structure of the internet and the tea Protocol’s decentralized registry share remarkable similarities, PageRank initially appeared to be a promising approach for analysis. However, upon further experimentation, it became apparent that PageRank's anti-spam strategies were less effective when applied to open-source. + +The key distinction lies in open-source software metadata. Unlike web pages, most open-source package metadata, such as lines of code and commit messages, are user-generated and susceptible to spoofing. Package managers are vulnerable to spam campaigns, wherein malicious actors flood the registry with packages containing phishing links or other harmful content. Package manager registries may also inaccurately reflect the dependencies of specific projects. This issue, known as “[manifest confusion](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/)” may allow bad actors to inject nefarious code or artificially inflate the impact of third-party dependencies, often for nefarious purposes. + +The arduous task of identifying and addressing these spam packages typically falls to security firms or altruistic individuals, neither of which offers a scalable solution to combat spam attacks in open-source. + +Proof of Contribution is an algorithm specifically designed to address the identification and isolation of spam packages and ensure only impactful projects receive a fair reward. The details of the Proof of Contribution algorithm will be the subject of a dedicated technical paper. + +### Network Participants + +In this white paper, we distinguish participants through their contributions. Some may contribute code or verify contributed code. Others may support developers and their reputation. + +#### Package Maintainers + +tea assumes that package creators maintain their work. In this white paper, we’ll refer to them as “package maintainers”. + +Package maintainers must make sure their software continues to deliver increasing value as the industry evolves. They are pillars of open-source communities who need to be empowered and rewarded for their ongoing contributions. However, a package maintainer may decide to discontinue their maintenance efforts or realize they cannot operate at a pace that matches the project’s users’ expectations. To ensure continuity, they must have the ability to transfer control of their project to another developer or group of developers, thereby appointing them as maintainers and granting them ownership and control over existing and future rewards associated with the project. + +Similarly, a developer may decide to take on the role of package maintainer by forking the existing project and registering a new one which they will maintain moving forward, thus becoming package maintainers. Once registered, projects whose teaRank exceeds a governance defined threshold start receiving rewards from the tea Protocol through the protocol's Proof of Contribution algorithm, in parallel with the legacy forked project. As the open-source community shifts away from the legacy project in favor of its newer iteration, the Proof of Contribution algorithm will gradually decrease the rewards allocated to the legacy project while boosting those assigned to the new forked project. + +It is essential to provide developer communities with the right tools to determine which projects 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](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502) 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. + +We propose introducing incentives via the TEA token described in the "[TEA token](./#tea-token)" section, to encourage open-source communities to report their findings constructively, so package maintainers can address them before they are exploited. + +#### Package Users and tea community members + +“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 little to no cost, directly benefiting from the work of package maintainers. + +With more than 10 million packages accessible across the top 30 package managers, the absence of universal value attribution to open-source projects can transform the selection of secure and efficient packages for development into a high-risk and daunting endeavor. With no discernible means to attribute and measure value, how do package users efficiently select secure packages for their development? + +We believe that the tea Protocol’s Proof of Contribution algorithm combined with other incentives can provide package users with the information they need to select the foundation of their own project quickly and thoughtfully. + +#### Project Supporters + +In Web 2.0 and web3, a subset of package users, often called “sponsors”, has chosen to support package maintainers through donations or other forms of remuneration; however, this has rarely been the case. + +These “project supporters” are organizations or open-source project users who use open-source software to build their commercial products, philanthropists looking to support the ecosystem, or entrepreneurs looking to fund teams to develop components of a larger system. + +tea proposes to extend the communities of open-source project 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. Project supporters are free to decide which projects or package maintainers they want to support based on their work, beliefs, or any criteria and metric that would influence their decision. Additionally, project supporters are free to decide how they want to support these projects. + +Sponsorship can be an effective system to support open-source development; however, these sponsorships do 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. + +To bolster the sustainability and integrity of the software supply chain and enable open-source developers to capture the value they create, tea aims to establish mechanisms where support benefits all aspects of a project. Support from backers will cascade through a project's dependencies, from the top to the base of the tree. This implicitly places trust in the package maintainer's ability to make informed choices about their stack, thus enhancing their reputation. + +

Figure 2 - Rewards distribution across dependencies

+ +#### tea Tasters + +As new projects or new versions of existing projects are released, the validity of the work needs to be provably demonstrated. This information is critical for package users to decide if they can trust the package and its maintainers. Within 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](https://semver.org/), license accuracy, etc.) and stake both their reputation and TEA tokens to demonstrate the outcome of their research and support their reviews. In the tea Protocol, “staking your tea” is the process of locking TEA tokens to support your reviews, potentially earning rewards or facing penalties based on the consensus about the quality of your reviews. tea tasters also have the option to report bugs or vulnerabilities to package managers confidentially. Valid reports result in rewards from the project's treasury, while invalid reports lead to the forfeiture of the tea taster's stake. Lastly, if package maintainers ignore these reported issues, it triggers penalties, or “slashing”, for the project's treasury. + +Like project supporters, tea tasters can influence a project and package maintainer’s reputation; however, their impact is more significant given their role in validating a project’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 TEA tokens they put at risk as they stake their reviews combined with other external data sources will build each tea taster’s reputation, bringing more value to their work. See the "[Package & Package Maintainer Reputation](./#package-and-package-maintainer-reputation)" section for more details on the mechanisms used to influence a project and package maintainer’s reputation. + +### Project Registration and Proof of Contribution Rewards + +The registration of a project release requires multiple transactions to occur atomically. Specifically: + +* The package maintainer must register the project with the decentralized registry, +* The tea Protocol must instantiate a project treasury owned, controlled, and configured by the package maintainers according to the rules defined by the package maintainers, and +* The tea Protocol must register the treasury’s unique name with the Ethereum Naming Service, or ENS, thus simplifying all user interactions with the treasury. + +Failure of any one of the operations will result in the protocol reverting to its previous state. + +Upon successful registration of a project with a teaRank surpassing a governance-defined threshold, the tea Protocol initiates the distribution of Proof of Contribution rewards to the project's treasury. We suggest distributing these rewards following a predetermined curve from a predefined pool of tokens controlled by the tea Protocol and allocated from the TEA tokens total supply. + +Package maintainers are required to bolster their project's reputation and trustworthiness by consistently staking a portion of the Proof of Contribution rewards received by the project's treasury. For each token staked, network participants will receive a non-transferrable “staked TEA”, or stTEA, at a 1:1 ratio, to participate in the governance of the tea Protocol. In line with the protocol's rules, these staked rewards, and their corresponding stTEA, may be subject to reduction (“slashing”) or redistribution if package maintainers fail to address bugs or vulnerabilities. + +Lastly, failure to maintain the minimum staked treasury ratio defined in the governance rules will result in the suspension of Proof of Contribution reward distribution to the project. Instead, these rewards will be redistributed among compliant projects. + +### Package & Package Maintainer Reputation + +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 of 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](https://arxiv.org/abs/1207.2617/)”. 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, leading to a penalization of the bad actor through slashing (destruction of a portion of their stake), we propose a system whereby third-parties, such as tea tasters, would be able to review packages produced by package maintainers and be 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. + +Additionally, as the reputation of any member of the tea community reaches key milestones, they may be granted access to elevated parts of the protocol. + +### Package Review by Third Parties + +The review of packages by third parties is an essential component of reputation building and the security of the software supply chain. However, third-party reviews come with their 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 total supply is expected to be 10 billion. Additionally, each action performed by developers, such as submitting, verifying, or staking packages, 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 stake TEA tokens and incur the risk of losing a portion of their stake 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: + +* 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 staking the package, to substantiate their review. + +The completion of a negative review that includes one or more critical vulnerabilities will require the tea tasters to first contact the package maintainer using a messaging protocol to notify them of the vulnerability and allow them to address the issue in a timely fashion. Upon expiry of the governance-defined period allocated to the package maintainer to address their vulnerability or as the corrected package becomes available, the same messaging protocol will be used to notify users and testers of this package (including dependents) that a vulnerability has been identified, and hopefully addressed, so they know to update their application or dependencies. To disincentivize wasting developers’ time, communication between the tea tasters and package maintainers will require the tea tasters to stake TEA tokens. + +Upon completing both operations, the tea tasters will receive an NFT as evidence of their work on the specific package and package version. The accumulation of NFTs combined with the staking ratio of each of the packages reviewed and information extracted from external systems will inform a tea taster’s reputation. As their reputation reaches key milestones, tea tasters may earn access to elevated parts of the protocol or accelerated rewards from the protocol, as decided by the tea governance. + +### Outdated or Corrupt Packages + +tea’s mission is to enhance the sustainability and integrity of the software supply chain by allowing open-source developers to capture the value they create; 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 staking 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 tasters play a pivotal role in open-source communities, as their reviews and associated claims can influence package users, either guiding them towards or away from specific packages. To ensure that reviews can be trusted on an ongoing basis, we propose a mechanism whereby reviews posted by tea tasters must be associated with staked TEA tokens. Outdated or corrupted packages may see a portion of their treasury slashed, while another portion is sent to the tea taster who first recognized the lack of maintenance of any package. + +As packages gain in popularity and usage, with more applications and potentially mission-critical systems depending on them, we must incentivize developers to discreetly report flaws to the package maintainer and encourage package maintainers to address such flaws before they can be exploited. Consequently, we propose that any negative review which outlines a flaw such as a zero-day vulnerability or the use of an outdated dependency and remains open beyond a grace period defined by governance should be considered a failure on the part of the package maintainer and be subject to the same penalties with the first tea taster to report the flaw receiving a portion of the slashed tokens. + +The same can be said for package supporters who staked their reputation and TEA tokens on the work of delinquent package maintainers and received rewards for it. As they failed to identify the lack of maintenance or elected to continue to support the package regardless, we propose that all slashing activities extend to the supporters of the package. + +Distribution to all tea tasters could be based on the age of their review and the number of TEA tokens they staked for their review. + +## TEA Token + +TEA is a cryptographic token which serves as the access key to certain parts and designated features of the tea Protocol. + +Holders of TEA token have the ability to: + +* Register their packages; +* Support packages by staking TEA tokens to specific packages; +* Contribute to the security of the software supply chain by challenging packages and conducting reviews to report bugs and/or vulnerabilities. + +As discussed, the tea Protocol unlocks the open-source economy and creates value for builders, maintainers, and end-users of enterprise software. Ultimately, the value captured by the tea Protocol accrues back to token holders as the community scales, creating a feedback loop that further incentivizes participation. + +### Rewarding Open-Source Developers + +We expect tea’s Proof of Contribution and staking mechanisms to foster the growth of open-source by empowering its participants with the resources they need to pursue their passion unencumbered. + +As outlined in "[Project Registration and Proof of Contribution Rewards](./#project-registration-and-proof-of-contribution-rewards)", projects registered with the tea Protocol and with a teaRank that surpasses a governance-defined threshold will receive Proof of Contribution rewards in the form of TEA tokens from the tea Protocol. This distribution will persist as long as the package complies with the rules of the protocol. Specifically, the package will have to maintain a teaRank above the governance defined threshold and package maintainers will have to contribute to their project’s reputation and trustworthiness by continuously staking a portion of the Proof of Contribution rewards received by the project’s treasury. Failure to comply with these rules will result in the suspension of the distribution of Proof of Contribution rewards and the redistribution of future rewards among compliant projects. + +Dependencies can significantly affect the reliability and security of a package, and the absence of registration for a package's dependencies should be seen as a potential risk. Package maintainers, being both validators and users of these dependencies, are in a prime position to connect with the maintainers of those dependencies. They can encourage them to register their projects with tea, thus making them subject to oversight by tea tasters and eligible for associated rewards. To encourage this community-wide engagement aimed at enhancing the reputation system, we recommend that any package with dependencies that are not registered with the tea Protocol see a fraction of its Proof of Contribution rewards burnt. This burn would be proportional to the number and contribution, quantified in teaRank, of each unregistered dependency, and continue as long as these dependencies remain unregistered. + +Numerous cases have demonstrated that strong incentives can entice malicious actors to compromise open-source software. Most 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). + +The tea Protocol's incentives address this issue by ensuring a fair and equitable distribution of incentives. A package like lodash with over 176k dependents is a pillar of open-source development, and its maintainers deserve 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. + +To address this limitation and empower every TEA token holder with the ability to support package maintainers, we also recommend that a governance-defined fraction of all staking rewards received by all network participants be directed towards the treasury of the staked package, along with its dependencies. + +### Staking to Secure the Software Supply Chain + +Staking can be an effective methodology to support a decentralized reputation system. However, to facilitate the security of the software supply chain, the tea incentive distribution system must carefully consider the staking 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 most staking rewards, we recommend the implementation of an optimum staking ratio, similar to the approach described in the [research produced by the web3 Foundation](https://research.web3.foundation/Polkadot/overview/token-economics). + +When a package exceeds the governance-defined optimum staking ratio, the total amount of staking rewards allocated to the package will remain fixed, regardless of the number of TEA tokens staked to the package. This measure, designed to de-incentivize package supporters and tea tasters from further staking highly staked packages, will result in a linear decrease of the staking rewards received by each package supporter. + +A curve-based approach, such as the one described in the web3 Foundation’s research would slow down the reduction of the staking rewards pool allocated to the package, thus continuing to take away from lesser staked packages and introducing negative externalities by granting more influence on large token holders over the distribution of the staking rewards pool. + +The recommended linear design should allow lesser staked packages to become more attractive to both package supporters and tea tasters. It may also incentivize experienced developers to build alternatives to highly-staked packages, creating an opportunity for the tea community to balance supporting existing software and promoting innovation. In its initial design, the staking ratio will be calculated using the circulating supply. The tea community may alter this design to improve the system’s scalability further. + +Just as good actors need to be rewarded; bad actors need to be identified and penalized. Open-source software provides many opportunities for bad actors to create pain points and reputational risks for an entire community of developers. From the misappropriation of work to the alteration and redistribution of software packages, or the injection of nefarious code, the war between good and bad actors goes on, often with well-funded bad actors who see the contamination of open-source packages as an opportunity to benefit financially. The downside has been relatively minimal, with packages potentially banned from digital shelves or subjected to a poor reputation. + +To directly address malicious actors and intensify the repercussions for actions contrary to the open-source, we recommend implementing the slashing mechanism detailed in the “[Package Review by Third Parties](./#package-review-by-third-parties)” and “[Outdated or Corrupt Packages](./#outdated-or-corrupt-packages)” sections. + +As tea tasters evaluate and analyze the code in newly submitted packages, we suggest tea tasters receive the tools and incentives to pinpoint and highlight nefarious code so + +* package users can be made aware of the risks, and +* package maintainers and package supporters are penalized for submitting or supporting nefarious code. + +To that extent, for all evidenced negative reviews performed per the network rules and which have been addressed by the package maintainer within the governance defined period, the package maintainer should not incur any penalty contrary to the package supporters or the tea tasters who provided a positive review of the package in question. + +For negative reviews performed per the network rules and that the package maintainer has not addressed within the governance-defined period, a fraction of the TEA tokens staked by the project’s treasury, the package supporters, and previous tea tasters will be slashed and sent to the tea taster who identified the bug or vulnerability. Another fraction will be locked into an insurance pool controlled by the tea governance. The tea governance will establish policies and rules in close collaboration with the community to distribute the pool’s contents to those affected by vulnerabilities. The protocol will distribute a third fraction of the slashed TEA tokens across all tea tasters who contributed to the negative review. + +Staking and slashing are vital components of the tea Protocol's incentive and penalty system. Package maintainers are required to stake a portion of their project's treasury, ensuring they have a substantial stake at risk in case they neglect to address bugs or vulnerabilities. Package users, supporters, and tea tasters can also stake TEA tokens to contribute to a package or package maintainer's reputation and actively participate in the protocol to uphold the software supply chain's sustainability and integrity. + +Governance is closely tied to this active engagement. For each TEA token staked, participants receive non-transferrable "staked TEA" (stTEA) at a 1:1 ratio, enabling them to participate in the governance of the tea Protocol. Staked rewards and their corresponding stTEA tokens may face reduction (slashing) or redistribution if the protocol rules are not followed, reinforcing accountability within the ecosystem. + +### TEA Token Supply Distribution + +A majority of the TEA tokens created by the protocol are used as incentives to encourage package maintainers, users, and supporters to perform activities that provide value to the decentralized network. The distribution of TEA tokens to various stakeholders within the protocol is dictated by a “distribution schedule.” + +Network incentives will be distributed directly by the tea Protocol, in the form of TEA tokens, to four groups of stakeholders: + +* Package Maintainers; +* Package Users (which include all members of the tea community); +* Project Supporters; and, +* tea Tasters. + +TEA tokens will also be utilized to support packages and secure the software supply chain through staking, including the right to challenge a package by conducting a review and reporting bugs or vulnerabilities, reward the open-source developers of registered projects, and participate in the governance of the tea Protocol. + +It’s recommended that a 10 billion maximum token supply be distributed across all members of the tea community as described below: + +

Figure 3 - Token distribution of total supply

+ +Roughly 50% of the maximum token supply should be allocated to “Ecosystem & Governance”, which includes incentives for open-source projects to onboard and maintain their codebase as well as rewards for contributing to decentralized votes and consensus via the tea DAO. Tokens allocated to “Ecosystem & Governance” should be distributed as Proof of Contribution rewards, staking rewards, and other types of developer-centric incentives. + +Roughly 26% of the maximum token supply should be allocated to the “Protocol Development” to ensure the sustainability and continued evolution of the tea Protocol. Roughly 20% should be earmarked for “Early Supporters & Advisors” while the remaining 4% should be allocated to support marketplace liquidity once a token generation event occurs. + +Detailed Tokenomics, including a comprehensive Token Distribution and Emissions schedule will be the subject of a dedicated paper. + +## Governance + +Governance is critical to the development, sustainability, and adoption of any distributed system. + +We propose that the tea Protocol incorporates governance mechanisms that enable active contributors who have staked TEA tokens to propose and vote on non-financial critical parameter changes. The voting process would be weighted by stTEA token ownership and individual reputation. + +Protocol parameters could include the priority to support specific package managers or introduce new protocol features or functions, as well as the impact of external factors on user and package reputation. This functionality will ensure that critical parameters can evolve and be optimized over time by active members of the tea community. We anticipate governance will launch with a simple structure and progressively expand as the tea system matures, facilitating adoption and ensuring progressive decentralization. + +Some system parameters may not be subject to governance or support high frequency changes to reduce the attack surface represented by governance. A progressive transition of parameters to open, decentralized governance will ensure the stability and predictability of the system. + +## Third-Party Extensibility + +As we build the initial tools to ignite the long-overdue support of the open-source communities, we believe part of our mission is to ensure that third parties can extend the overall toolset. In addition to providing the infrastructure for developers to build extensions to the protocol, including new ways to innovate and further the support of open-source developers, our plans include the potential for other package managers to contribute to the protocol. + +The dreams and efforts of open-source developers have built the innovation that supports our everyday life. We look forward to discovering the new uses and extensions for the tea Protocol proposed by the tea community. + +## Future Work and Potential Community Efforts + +As the tea system matures, we foresee the community deciding and contributing to alterations and extensions of the tea system through governance. Below are some ideas that we believe may inspire some, however we do not guarantee any future performance. + +### 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 staking ratio and rewards. In the future, the tea community may propose the development of a system designed to dynamically monitor the staking ratio for each project and rebalance how project supporters stake their TEA tokens based on their own criteria. + +### Royalties on Package Transfer + +We recognize that package maintainers may decide to transfer their rewards stream to one or more developers. The governance of such transfer must remain the decision of the package maintainer and their partners, with no interference from tea. Tools will need to be provided for such transfer to be total or partial (perhaps through only a portion of the rewards being redirected to one or more developers, while the remaining rewards continue to flow to the original package maintainer) and for the staking rewards to flow through a single account controlled by a single network participant, multiple network participants, or automatically distributed across multiple accounts using static or dynamic ratios. + +### Rewards Distribution Across Multiple Maintainers + +The maintenance of a package can rely on the work of one more team of developers. Before rewards start to flow, teams should consider automating the distribution of value amongst themselves. How the distribution occurs must be decided by the maintainers themselves, as they are in the best position to evaluate who contributed and how they should be rewarded. + +To accomplish that, each team (or teams) could set up their own decentralized autonomous organization ([DAO](https://ethereum.org/en/dao/)) and either automate the distribution or deploy more complex systems to determine the adequate value distribution based on external factors such as a vote from all DAO members, or time-based distributions based on continuous contribution, successful completion of bounties, etc. + +### Handling Package “Forks” + +We believe that forks are essential and largely under-utilized. Forks can be an effective tool for developing packages that compete in functionality, performance, security, and even attention. As useful as they may be, forks must recognize the original efforts. Through future work or potential contributions, the tea community may enhance the system to require forks to be declared, perhaps even detected when a project is registered. Undeclared forks revealed by tea tasters may result in a portion of the fork’s treasury’s stake being slashed, transferred to the original package maintainer, or sent to the tea tasters who revealed the fork. + +### Runtime vs. Build Dependencies + +tea may not distinguish build dependencies from runtime dependencies when distributing Proof of Contribution rewards at launch. However, provided the tea community feels strongly about making such a distinction, the tea community may propose enhancements to the rewards distribution algorithm to account for the criticality of each dependency and their contribution to the individual value of the packages that depend upon them. These proposals would be voted upon and implemented based on the community’s decision. + +### Usage-based Rewards + +As more applications are built using projects registered with tea, the community may augment the reward algorithm so that allocation may be influenced by external attested datasets such as usage. This update to the rewards mechanism could allow for a higher allocation of TEA token rewards to flow towards packages with the highest usage while still respecting the constraints of the staking ratio described in the TEA token section. Package maintainers could use a similar approach to distribute rewards across their dependencies based on the transparent logic of their choice. Note that all information used to affect the distribution of rewards across packages and dependencies in the tea system will need to be provably reliable. + +## Acknowledgments + +This white paper would not exist without the support and dedication of many teaophiles. The authors would like to acknowledge Jacob Heider, Jadid Khan, Josh Kruger, and Shane Molidor for their contribution to the tokenomics, Sanchit Ram for his contribution to the teaRank algorithm, and the many discrete individuals who volunteered their time to provide feedback on the contents of this document. + +## Glossary of Terms + +| Term | Definition | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 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 stakers in response to behavior contrary to the protocol rules. | +| Staking | 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. | +| stTEA | Non-transferrable “staked TEA” token or “stTEA” received by network participants for each token staked at a 1:1 ratio. stTEA can be utilised to participate in the governance of the tea Protocol | +| teaRank | Dynamic impact score assigned to each project by the protocol’s “Proof of Contribution” algorithm. | + +## References + +1. [https://creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/) +2. [https://archive.org/details/historyofmodernc00ceru](https://archive.org/details/historyofmodernc00ceru) +3. [https://nvd.nist.gov/vuln/detail/CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) +4. [https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA](https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA) +5. [https://twitter.com/yazicivo/status/1469349956880408583](https://twitter.com/yazicivo/status/1469349956880408583) +6. [https://www.thestack.technology/core-js-maintainer-denis-pusharev-license-broke-angry/](https://www.thestack.technology/core-js-maintainer-denis-pusharev-license-broke-angry/) +7. [https://www.w3.org/TR/did-core/](https://www.w3.org/TR/did-core/) +8. [https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/) +9. [https://www.theregister.com/2016/03/23/npm\_left\_pad\_chaos/](https://www.theregister.com/2016/03/23/npm\_left\_pad\_chaos/) +10. [https://fossa.com/blog/npm-packages-colors-faker-corrupted/](https://fossa.com/blog/npm-packages-colors-faker-corrupted/) +11. [https://www.lunasec.io/docs/blog/node-ipc-protestware/](https://www.lunasec.io/docs/blog/node-ipc-protestware/) +12. [https://github.com/dominictarr/event-stream/issues/116](https://github.com/dominictarr/event-stream/issues/116) +13. [https://blog.npmjs.org/post/163723642530/crossenv-malware-on-thenpm-registry.html](https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html) +14. [https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/](https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/) +15. [https://threatpost.com/backdoor-found-in-utility-for-linux/147581/](https://threatpost.com/backdoor-found-in-utility-for-linux/147581/) +16. [https://www.fbi.gov/news/stories/phantom-secure-takedown-031618](https://www.fbi.gov/news/stories/phantom-secure-takedown-031618) +17. [https://www.europol.europa.eu/media-press/newsroom/news/800-criminalsarrested-in-biggest-ever-law-enforcement-operation-against-encryptedcommunication](https://www.europol.europa.eu/media-press/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication) +18. [https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502) +19. [https://www.npmjs.com/package/lodash](https://www.npmjs.com/package/lodash) +20. [https://www.npmjs.com/package/chalk](https://www.npmjs.com/package/chalk) +21. [https://www.npmjs.com/package/log4js/](https://www.npmjs.com/package/log4js/) +22. [https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/) +23. [https://medium.com/intrinsic-blog/compromised-npm-package-eventstream-d47d08605502](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502) +24. [https://semver.org/](https://semver.org/) +25. [https://arxiv.org/abs/1207.2617](https://arxiv.org/abs/1207.2617) +26. [https://research.web3.foundation/Polkadot/overview/token-economics](https://research.web3.foundation/Polkadot/overview/token-economics) diff --git a/SUMMARY.md b/SUMMARY.md new file mode 100644 index 0000000..33c7c72 --- /dev/null +++ b/SUMMARY.md @@ -0,0 +1,4 @@ +# Table of contents + +* [A Decentralized Protocol for Open-Source Developers to Capture the Value They Create](README.md) +* [README]() diff --git a/i18n/be/white-paper.md b/i18n/be/white-paper.md deleted file mode 100644 index 3dc438a..0000000 --- a/i18n/be/white-paper.md +++ /dev/null @@ -1,577 +0,0 @@ -# Адмова ад адказнасці - -Інфармацыя, выкладзеная ў гэтай белай кнізе, носіць папярэдні характар. -Такім чынам, ні аўтары, ні любыя з іх адпаведных філіялаў не нясуць ніякай адказнасці за тое, што інфармацыя, выкладзеная тут, з'яўляецца канчатковай або правільнай, і кожная з вышэйзгаданых адмоваў ад адказнасці, -у поўнай меры, дазволенай дзеючым заканадаўствам, любую і ўсю адказнасць, якая ўзнікае ў сувязі з дэліктам, кантрактам ці іншым чынам у дачыненні да гэтага тэхнічнага дакумента. -Ні гэтая тэхнічная дакументацыя, ні што-небудзь, што змяшчаецца ў ёй, не павінны служыць асновай для заключэння кантрактаў або абавязацельстваў. - -Нішто ў гэтым тэхнічным дакуменце не з'яўляецца прапановай прадаць або заклікам набыць якія-небудзь токены, якія тут абмяркоўваюцца. -У любым выпадку, калі гэты дакумент будзе разглядацца як такая прапанова або хадайніцтва, ніякая такая прапанова або хадайніцтва не прызначана і не перадаецца гэтым дакументам у любой юрысдыкцыі, дзе гэта з'яўляецца незаконным, -дзе такая прапанова або хадайніцтва патрабуе ліцэнзіі або рэгістрацыі, або калі такая прапанова або хадайніцтва падлягае абмежаванням. -У прыватнасці, любыя токены, якія абмяркоўваюцца ў гэтым дакуменце, не былі і, на дату выпуску гэтага тэхнічнага дакумента, не павінны быць зарэгістраваны ў адпаведнасці з заканадаўствам аб каштоўных паперах або аналагічным заканадаўствам любой юрысдыкцыі, -незалежна ад таго, ці лічыць такая юрысдыкцыя такія токены каштоўнай паперай або падобным інструментам і не можа быць прапанавана або прададзена ў любой юрысдыкцыі, дзе гэта з'яўляецца парушэннем адпаведных законаў такой юрысдыкцыі. - - -# Ліцэнзія - -Зыходны код[^src] гэтага дакумента даступны на ўмовах Creative Commons Attribution-ShareAlike 4.0 International[^cc] ліцэнзіi. - -[^src]: Глядзіце: @sources -[^cc]: Глядзіце: @cc - - -# Увядзенне - -Інтэрнэт у асноўным складаецца з праектаў з адкрытым зыходным кодам, і гэта было з самага пачатку. -З часам многія з гэтых праектаў сталі асновай, на якой будуюцца ўсе будучыя інавацыі. -І хоць на гэтым былі зароблены багацці, адкрыты зыходны код у асноўным ствараецца і падтрымліваецца без кампенсацыі. - -Мы верым, што ўсе сучасныя чалавечыя намаганні застопарыліся з-за таго, што найменшы працэнт інжынераў у свеце выбіраў паміж зарплатай і падтрыманнем працаздольнасці Інтэрнэту. -Адкрыты зыходны код - гэта любоўная праца, якой часта перашкаджае адсутнасць значных эканамічных стымулаў, што прыводзіць да таго, што сапраўды карысныя праекты ніколі не раскрываюць свой патэнцыял, у той час як іншыя пакутуюць ад праблем бяспекі з-за адсутнасці стымулаў падтрымліваць праграмнае забеспячэнне на працягу ўсяго яго жыццёвага цыклу. -Каб цалкам рэалізаваць наш патэнцыял, нам патрэбна справядлівая сістэма ўзнагароджання для экасістэмы з адкрытым зыходным кодам, якая прынцыпова не змяняе спосаб яе стварэння і выкарыстання. - -Прадпрыемствы часта складаюць бізнес-мадэлі з адкрытым зыходным кодам, атрымліваючы прыбытак непасрэдна ад працы добразычлівых распрацоўшчыкаў, а таксама спадзяюцца на іх выпраўленне памылак пры ўзнікненні праблем. -Выдатным прыкладам з'яўляецца нядаўні інцыдэнт з крытычнай уразлівасцю бяспекі ў Log4j, пакеце ад Apache Software Foundation, які знайшоў свой шлях праз многія камерцыйныя праграмы і сэрвісы, якія выкарыстоўваюцца прадпрыемствамі і ўрадамі. -У лістападзе 2021 года даследчык бяспекі, які працуе ў Alibaba Group Holding Ltd., паведаміў аб уразлівасці CVE-2021-44228[^1], які атрымаў максімальна магчымы базавы бал ад Apache Software Foundation. -Аміт Ёран, выканаўчы дырэктар Tenable і дырэктар-заснавальнік групы камп'ютэрнай гатоўнасці да надзвычайных сітуацый ЗША (US-CERT), ахарактарызаваў гэту ўразлівасць як «самую вялікую і крытычную ўразлівасць за апошняе дзесяцігоддзе»[^2]. -Пачалася паніка, і нешматлікія добраахвотнікі, якія падтрымлівалі гэты пакет, трапілі пад публічную крытыку за няўдачу. -Пасля разгляду абурэння сціплай просьбай аб справядлівасці сістэмы былі выпраўлены. -Прадпрыемствы і ўрады ў рэшце рэшт зразумелі, што Log4j, пакет, які выкарыстоўваўся ў шырокім дыяпазоне крытычна важных сістэм на працягу двух дзесяцігоддзяў, падтрымліваўся некалькімі неаплатнымі добраахвотнікамі, тымі самымі неапяванымі героямі, якія пачалі дзейнічаць, нягледзячы на злоўжыванні з боку індустрыі [^3], і нястомна працавалі каб ліквідаваць уразлівасць. - -На жаль, Log4j - далёка не адзіны прыклад. -core-js спампоўваецца 30 мільёнаў разоў на тыдзень у якасці асновы кожнага прыкладання Node.js, але ён таксама амаль не фінансуецца. -Нядаўна некалькі асноўных распрацоўшчыкаў біткойна сышлі ў адстаўку, спасылаючыся, сярод іншых прычын, на *адсутнасць фінансавай кампенсацыі* за сваё рашэнне. - -Былі шматлікія спробы стварэння структур заахвочванняў, звычайна з удзелам спонсарства і сістэм ўзнагароджання. -Спонсарства дазваляе карыстальнікам з адкрытым зыходным кодам ахвяраваць праекты, якія яны аддаюць перавагу. -Аднак уявіце сабе адкрыты зыходны код як цагляную вежу, дзе ніжнія пласты даўно забытыя, але ўсё яшчэ падтрымліваюцца адданымі інжынерамі і на якія спадзяецца яшчэ больш распрацоўшчыкаў. -Толькі праекты на вяршыні вежы звычайна вядомыя і атрымліваюць спонсарскую падтрымку. -Такі неаб'ектыўны выбар прыводзіць да таго, што асноўныя цэглы, якія трымаюць вежу, не прыцягваюць ахвяраванняў, у той час як фаварыты атрымліваюць больш, чым ім трэба. -Баунты дазваляюць спажыўцам праектаў прапаноўваць аплату распрацоўшчыкам за стварэнне пэўных функцый, такім чынам, толькі ўзнагароджваючы праекты за выкананне дзеянняў, якія не абавязкова адпавядаюць іх інтарэсам. -І зноў толькі ўзнагароджванне фаварытаў. - -У гэтым артыкуле мы прапануем tea — дэцэнтралізаваную сістэму для справядлівага ўзнагароджання распрацоўшчыкаў з адкрытым зыходным кодам на аснове іх укладу ва ўсю экасістэму і дзейнічае праз алгарытм стымулявання tea, які прымяняецца да ўсіх запісаў у рэестры tea. - -![Спрошчаны выгляд сістэмы ўзнагароджання за замочванне tea.](img/figure-1.svg) - -$\parskip=0pt plus 1pt$ - -[^1]: Крыніца: @nist -[^2]: Крыніца: @reuters -[^3]: Крыніца: @twitter - - -# Кампаненты - -Распрацоўшчыку праграмнага забеспячэння, які стварае прыкладанне, патрэбныя чатыры рэчы: браўзер, тэрмінал, рэдактар і менеджэр пакетаў. -З гэтых чатырох менеджэр пакетаў - гэта тое, што кіруе інструментамі і фрэймворкамі, неабходнымі распрацоўшчыку для стварэння свайго прадукту. -На гэтым узроўні мы бачым патэнцыял для змены аплаты працы з адкрытым зыходным кодам. - -## Менеджэр пакетаў - -Менеджэр пакетаў ведае, ад якога праграмнага забеспячэння з адкрытым зыходным кодам залежыць функцыянаванне прыкладання, ад вяршыні вежы да яе падставы. -Кожны кампанент і версія, важныя для прыкладання, вядомыя і запісаны. -Яно ведае, што вяршыня вежы старанна адбірае залежныя ад сябе і што пільны адбор працягваецца ўніз. -Менеджэр пакетаў унікальным чынам размешчаны ў стэку інструментаў распрацоўшчыка, каб забяспечыць аўтаматызаванае і дакладнае размеркаванне значэнняў на аснове фактычнага выкарыстання ў рэальным свеце. - -Мы прапануем нязменны дэцэнтралізаваны рэестр, прызначаны для размеркавання кошту на аснове алгарытму, які вызначае ўклад кожнага запісу ў карыснасць і працаздольнасць сістэмы. -Значэнне можа ўваходзіць у графік у вяршынных кропках — праграмах і асноўных бібліятэках — і рэкурсіўна размяркоўвацца па залежнасцях гэтых вяршынь і іх залежнасцей, паколькі рэестр ведае ўвесь графік з адкрытым зыходным кодам. - -Акрамя таго, мы лічым, што істотная інфармацыя павінна быць даступная праз менеджэр пакетаў, каб распрацоўшчыкі маглі ацаніць, ці могуць яны давяраць пакету і яго аўтару. -Гэтая інфармацыя можа быць заснавана на рэпутацыі, адзнаках супольнасці, дадзеных, атрыманых з сістэм дэцэнтралізаванай ідэнтыфікацыі (DID[^4]), іншых мэнэджарах пакетаў або механізмах стымулявання, якія патэнцыйна залежаць ад таго, што ўдзельнікі сеткі падвяргаюць рызыцы эканамічную каштоўнасць. - -Мы прагназуем, што спалучэнне інструментаў, інфармацыі і ўзнагарод у Tea будзе справядліва стымуляваць распрацоўшчыкаў, дапамагаючы стымуляваць рост праграмнага забеспячэння з адкрытым зыходным кодам і спрыяць інавацыям. - -[^4]: Глядзіце: @w3 - -## Дэцэнтралізаваны рэестр - -Кожны менеджэр пакетаў мае ўласны рэестр пакетаў, у якім паўтараюцца адны і тыя ж метаданыя. -Прыйшоў час стварыць адзіны, поўны і канчатковы рэестр, распрацаваны і кіраваны суполкамі, якія ад яго залежаць. -Гэты дэцэнтралізаваны, нязменны рэестр можа забяспечыць бяспеку, стабільнасць і прадухіліць -злы намер. - -Інтэрнэт працуе на дзясятках тысяч жыццёва важных кампанентаў з адкрытым зыходным кодам. -Характэрна, што да гэтага часу інцыдэнты, выкліканыя выдаленнем неабходнай інфраструктуры з адкрытым зыходным кодам, былі мінімальнымі. -Самай вядомай з іх стала выдаленне залежнасці ад левай панэлі NPM[^5] у 2016 годзе, якая каскадна перайшла ў сістэмы бесперапыннай інтэграцыі і бесперапыннага разгортвання, што пакідала распрацоўшчыкаў без працы на некалькі дзён. -Гэтая падзея прадэманстравала, што сам Інтэрнэт заснаваны на далікатных сістэмах развіцця. -Іншыя прыклады ўключаюць актыўны або наўмысны ўдзел распрацоўшчыкаў пакетаў, якія сабатавалі іх папулярныя пакеты (гл. colors.js, faker.js[^6] і node-ipc[^7]), -ці зламыснікі, якія імкнуцца атрымаць прыбытак, прыкідваючыся, што дапамагаюць падтрымліваць пакеты і скажаць іх, каб выкрасці, напрыклад, зачыненыя ключы біткойнаў (гл. Event-stream[^8]), -або шкоднасныя пакеты з наўмыснымі арфаграфічнымі памылкамі, таксама вядомыя як typosquatting, -у надзеі прымусіць карыстальнікаў усталяваць іх падманам, напрыклад, пакеты crossenv супраць cross-env NPM [^npmjsCrossenv]. - -Неабходна гарантаваць цэласнасць праграмнага забеспячэння па меры прасоўвання індустрыі ў будучыню, дзе лічбавыя актывы з'яўляюцца часткай праграмнага забеспячэння. -Мы не можам працягваць заставацца ўразлівымі да зламыснікаў, якія мадыфікуюць праграмнае забеспячэнне. - -Большасць інструментаў, якія мы называем менеджэрамі пакетаў, не могуць гарантаваць, што гэтыя пакеты, убудаваныя ў праграмы і dApps, з'яўляюцца нязменным адкрытым кодам, апублікаваным іх першапачатковымі аўтарамі. -GitHub ад Microsoft выявіў, што 17% уразлівасцяў у праграмным забеспячэнні былі створаны са зламыснымі мэтамі[^9], прычым некаторыя з іх заставаліся незаўважанымі на працягу доўгага часу (гл. Webmin 1.890[^10]). - -Дэцэнтралізаваны рэестр, дапоўнены сістэмай рэпутацыі і які падтрымліваецца эканамічнымі стымуламі, закліканымі выкрываць дрэнных удзельнікаў і ўзнагароджваць добрых удзельнікаў, можа забяспечыць гарантыі, якія шукалі супольнасці распрацоўшчыкаў. - -[^5]: Крыніца: @theregister -[^6]: Крыніца: @fossa -[^7]: Крыніца: @lunasec -[^8]: Крыніца: @github -[^npmjsCrossenv]: Крыніца: @npmjsCrossenv -[^9]: Крыніца: @zdnet -[^10]: Крыніца: @threatpost - - -## Сістэма захоўвання - -Пакеты з адкрытым зыходным кодам забяспечваюць шырокі спектр функцый, некаторыя з якіх могуць быць абмежаванымі або непажаданымі. -Шыфраванне - выдатны таму прыклад. -Важным варыянтам выкарыстання шыфравання з'яўляецца падтрымка прыватнасці людзей па ўсім свеце. -Аднак шыфраванне таксама можа быць выкарыстана ў гнюсных мэтах (гл. Phantom Secure, дэмантаваны праваахоўнымі органамі ў сакавіку 2018 г.[^11]) або можа быць скампраметавана для падтрымкі праваахоўнай дзейнасці (гл. Аперацыя Ironside (AFP), Operation Greenlight (Еўрапол)), -і аперацыя "Траянскі шчыт" (ФБР)[^12], дзе ФБР выкарыстоўвала "зашыфраваную" камунікацыйную платформу AN0M і пераканала злачынцаў выкарыстоўваць свае "зашыфраваныя" тэлефоны для бяспечнай сувязі). - -Шырокае прымяненне шыфравання зрабіла яго ідэальным варыянтам выкарыстання праграмнага забеспячэння з адкрытым зыходным кодам і выдатным прыкладам таго, што любое рашэнне, якое захоўвае пакеты, павінна быць абароненым ад падробкі і цэнзуры. -tea - гэта дэцэнтралізаваны пратакол, які не мае намеру фільтраваць або санкцыянаваць пакеты на аснове іх функцыянальнасці. -У той час як кіраўніцтва tea можа вырашыць выдаліць правераныя шкоднасныя пакеты (гл. раздзел кіравання для атрымання дадатковай інфармацыі), вельмі важна, каб сістэма tea падключалася да некалькіх сістэм захоўвання дадзеных, у тым ліку дэцэнтралізаваных, якія дэманструюць, што пакет не зменены і правільна прайграны. -Супрацоўнікі пакетаў могуць выбраць сістэму захоўвання, якая найбольш адпавядае іх патрэбам бяспечнага захоўвання і распаўсюджвання пакетаў. - -[^11]: Крыніца: @fbi -[^12]: Крыніца: @europol - -# Удзельнікі сеткі - -Місія tea заключаецца ў пашырэнні магчымасцей суполак з адкрытым зыходным кодам і забеспячэнні падтрымкі іх удзельнікаў, якія ствараюць інструменты, якія будуюць Інтэрнэт. -У гэтай тэхнічнай кнізе мы адрозніваем удзельнікаў па іх укладах. -Некаторыя могуць дадаваць код або правяраць дададзены код. -Іншыя могуць забяспечыць эканамічную каштоўнасць для падтрымкі распрацоўшчыкаў і іх рэпутацыі. - -## Абслугоўвальнікі пакетаў - -Супрацоўнікі пакетаў павінны сачыць за тым, каб іх праграмнае забеспячэнне працягвала прыносіць усё большую каштоўнасць па меры развіцця індустрыі. - -tea мяркуе, што стваральнікі пакетаў падтрымліваюць сваю працу. -Абслугоўвальнікі пакетаў з'яўляюцца слупамі суполак з адкрытым зыходным кодам, якія павінны быць пашыраны і ўзнагароджаны за іх пастаянны ўклад. -Супрацоўнік пакета можа вырашыць спыніць свае намаганні па тэхнічным абслугоўванні або зразумець, што ён не можа працаваць у тэмпе, які адпавядае чаканням карыстальнікаў пакета. -Суправаджальнікі пакетаў атрымліваюць незаменны токен (NFT), калі завяршаюць адпраўку пакета (дадатковую інфармацыю глядзіце ў раздзеле NFT суправаджэння). -Гэты NFT выкарыстоўваецца для доказу іх працы і з'яўляецца ключом, які накіроўвае ўзнагароды за tea. -Уладальнік NFT пакета можа перадаць права ўласнасці іншаму распрацоўніку (або групе распрацоўшчыкаў), такім чынам зрабіўшы іх суправаджэннем пакета і атрымальнікам любых будучых узнагарод. -Сапраўды гэтак жа распрацоўшчык можа вырашыць узяць на сябе ролю суправаджальніка пакета, разгалінаваўшы існуючы пакет і адправіўшы новы, які ён будзе падтрымліваць у далейшым, такім чынам, сам становячыся стваральнікам і суправаджальнікам пакета. - -Вельмі важна даць супольнасцям распрацоўшчыкаў правільныя інструменты для вызначэння таго, якія пакеты абслугоўваюцца, а таксама рэпутацыю і якасць працы іх былых і цяперашніх суправаджаючых. -Мы занадта часта бачылі, як працу з адкрытым зыходным кодам фальсіфікавалі і намаганні многіх разбуралі дрэнныя ўдзельнікі. -Нягледзячы на тое, што праца гэтых паганых суб'ектаў у значнай ступені выяўляецца і выпраўляецца, часта гэта адбываецца толькі пасля таго, як будзе нанесены істотны ўрон праз фінансавую страту або страту даных. -Возьмем, напрыклад, пакет EventStream npm[^13], які спампоўваўся больш за 1,5 мільёна разоў на тыдзень і на які абапіраліся больш за 1500 пакетаў, калі хакеру ўдалося пранікнуць у праект з адкрытым зыходным кодам, -заваяваць давер свайго першапачатковага аўтара і змяніць EventStream, каб ён залежаў ад шкоднаснага пакета, які можа выкрасці ўліковыя даныя біткойн-кашалька на старонні сервер. -Нягледзячы на тое, што інструменты могуць дапамагчы выявіць некаторыя з гэтых нападаў, на іх не заўсёды можна спадзявацца, што стварае цэлую супольнасць, залежную ад стараннасці адзін аднаго і жадання падзяліцца сваімі высновамі. - -Мы прапануем увесці стымулы з дапамогай токена tea, апісанага ў раздзеле токена tea, заахвочваючы супольнасці з адкрытым зыходным кодам канструктыўна паведамляць пра свае высновы, каб распрацоўшчыкі пакетаў маглі вырашыць іх, перш чым яны будуць выкарыстоўвацца. - -[^13]: Крыніца: @medium - -## Карыстальнікі пакета - -Карыстальнікі пакетаў - гэта распрацоўшчыкі праграмнага забеспячэння, арыентаваныя на вырашэнне канкрэтнай задачы. -Яны часта шукаюць у суполцы з адкрытым зыходным кодам інструменты, неабходныя ім для хуткага эксперыментавання і ітэрацыі з вельмі невялікімі выдаткамі або бясплатна, атрымліваючы непасрэдную выгаду ад працы стваральнікаў і суправаджэння пакетаў. -Традыцыйна падмноства магло выбраць падтрымку суправаджэння пакетаў праз ахвяраванні або іншыя формы ўзнагароджання; аднак гэта здаралася рэдка. - -Спонсарства можа быць эфектыўнай сістэмай падтрымкі распрацоўкі з адкрытым зыходным кодам; аднак ўзнагароджанне звычайна не распаўсюджваецца на ўсіх залежных асоб. -Гэта абмежаванне прыносіць карысць фаварытам і перашкаджае інавацыям і стварэнні праграмнага забеспячэння. -Каб стаць асновай распрацоўкі праграмнага забеспячэння, адкрыты зыходны код павінен даць магчымасць усім распрацоўшчыкам, пачаткоўцам ці экспертам, на ўсіх узроўнях вежы. - -Мэта tea - падтрымліваць асноўныя каштоўнасці праграмнага забеспячэння з адкрытым зыходным кодам, забяспечваючы пры гэтым дэцэнтралізаваную сістэму ўзнагароджання суправаджэння пакетаў за іх працу. -Каб выканаць гэтую місію, tea мае намер распрацаваць — і стымуляваць іншых да распрацоўкі — механізмы для карыстальнікаў пакетаў для падтрымкі суправаджэння пакетаў праз унікальныя выпадкі выкарыстання токена tea, як апісана ў раздзелах аб токенах tea і будучай працы і патэнцыйных намаганнях супольнасці. - -## Прыхільнікі і спонсары пакета - -У Web 2.0 і web3 прыхільнікаў пакетаў часта называюць «спонсарамі». Гэта арганізацыі або карыстальнікі пакетаў, якія выкарыстоўваюць праграмнае забеспячэнне з адкрытым зыходным кодам для стварэння сваіх камерцыйных прадуктаў, філантропы, якія жадаюць падтрымаць экасістэму, або прадпрымальнікі, якія жадаюць фінансаваць каманды для распрацоўкі кампанентаў большай сістэмы. - -tea прапануе пашырыць суполкі прыхільнікаў пакетаў на ўсю супольнасць tea, незалежна ад таго, арганізацыі, распрацоўшчыкі, карыстальнікі або энтузіясты тэхналогій. -Мэта tea складаецца ў тым, каб укараніць дэцэнтралізаваныя механізмы стымулявання праз унікальныя выпадкі выкарыстання токена tea для любога члена супольнасці tea, каб унесці свой уклад у бесперапынную ўстойлівасць і бесперапынны рост адкрытага зыходнага кода. -Прыхільнікі і спонсары пакетаў вольныя вырашаць, якія пакеты або суправаджэнне пакетаў яны жадаюць падтрымаць, зыходзячы з іх працы, перакананняў або любых крытэрыяў і паказчыкаў, якія паўплываюць на іх рашэнне. -Акрамя таго, падтрымка, якая аказваецца прыхільнікамі і спонсарамі пакета, будзе распаўсюджвацца на залежнасці кожнага пакета, такім чынам, ускосна давяраючы суправаджальніку пакета, што ён зробіць правільны выбар наконт свайго стэка і выкарыстае гэтую інфармацыю для ўмацавання сваёй рэпутацыі. - -Пры ўмове, што суправаджэнне пакета прапануе такую паслугу, прыхільнік і спонсар пакета могуць атрымаць узамен NFT прэміум-ўзроўню падтрымкі, такім чынам, выйграючы ад паскораных SLA або больш гнуткага ліцэнзавання. -Акрамя таго, прыхільнікі і спонсары пакетаў могуць прыняць рашэнне аб падтрымцы пакетаў або суправаджэння пакетаў і аўтаматычна перанакіраваць усе або адсотак сваіх узнагарод, каб стымуляваць каманды для стварэння новага праграмнага забеспячэння з адкрытым зыходным кодам. -Іншымі словамі, упакоўкі не павінны існаваць, каб tea пачала сыпацца. -Праекты, якія зараджаюцца, могуць падтрымлівацца гэтак жа, як і больш сталыя, што яшчэ больш стымулюе пастаянна развіваецца ландшафт з адкрытым зыходным кодам. - -## tea Дэгустатары - -Па меры выпуску новых пакетаў або новых версій існуючых пакетаў неабходна даказальна прадэманстраваць сапраўднасць працы. -Гэтая інфармацыя мае вырашальнае значэнне для карыстальнікаў пакета, каб вырашыць, ці варта давяраць як пакету, так і яго суправаднікам. -У tea пратаколе гэтую функцыю выконваюць дэгустатары tea. - -дэгустатары tea, як правіла, з'яўляюцца дасведчанымі распрацоўшчыкамі праграмнага забеспячэння, гатовымі прысвяціць частку свайго часу праверцы прэтэнзій, звязаных з пакетам (функцыянальнасць, бяспека, семантычная версія[^14], дакладнасць ліцэнзіі і г.д.) -і ставяць як сваю рэпутацыю, так і эканамічную каштоўнасць, каб прадэманстраваць вынікі сваіх даследаванняў і аналізу і падтрымаць свае агляды. -дэгустатары tea атрымліваюць узнагароды за старанне і намаганні. -У tea мы называем «замочваннем гарбаты» дзеянне блакіроўкі чайных токенаў для падтрымкі вашых водгукаў і атрымання ўзнагарод (або штрафаў) на аснове кансенсусу аб сапраўднасці вашых аглядаў. - -Як і прыхільнікі ўпакоўкі, дэгустатары tea могуць паўплываць на ўпакоўку і рэпутацыю яе суправаджэння; аднак іх уплыў больш значны, улічваючы іх ролю ў праверцы бяспекі, функцыянальнасці і якасці пакета. -дэгустатары tea таксама павінны пабудаваць сваю рэпутацыю, каб падтрымаць свае патрабаванні. -Якасць іх працы і эканамічная каштоўнасць, якую яны падвяргаюць рызыцы, калі яны складаюць свае агляды ў спалучэнні з іншымі знешнімі крыніцамі даных, будуць ствараць рэпутацыю кожнага дэгустатара tea, прыносячы большую каштоўнасць іх працы. -Глядзіце раздзел рэпутацыі пакета для больш падрабязнай інфармацыі аб механізмах, якія выкарыстоўваюцца для ўплыву на пакет і рэпутацыю суправаджэння пакета. - -[^14]: Глядзіце: @semver - -# Агляд пратаколу - -Дызайн пратакола ўзнагароджання за ўнёскі з адкрытым зыходным кодам сутыкаецца з праблемамі. -Праграмнае забеспячэнне з адкрытым зыходным кодам па вызначэнні адкрыта для ўсіх і можа, у выніку, падвяргацца няправільнаму прызначэнню, прысваенню або злоснаму маніпуляванню. -Тым не менш, супольнасць з адкрытым зыходным кодам паслядоўна дэманстравала сваю гатоўнасць вылучаць добрых акцёраў і выкрываць дрэнных акцёраў. -Гістарычна склалася так, што энергія, затрачаная на агляд і каментарый да ўкладаў іншых распрацоўшчыкаў, была строга добраахвотнай, нягледзячы на тое, наколькі працаёмкім і важным можа быць справаздачнасць і абарона высноў. - -Мы маем намер стварыць недаверлівую платформу распаўсюджвання прыкладанняў, забяспечаную рэпутацыяй і фінансавымі стымуламі, бо лічым, што адэкватнае ўзнагароджанне за ўнёскі з адкрытым зыходным кодам не можа быць паспяховым без сістэмы рэпутацыі і магчымасці для членаў супольнасці паведамляць пра свае высновы і падтрымку (або нязгоду) для пакета або працы распрацоўшчыка. - -Мы павінны даць распрацоўшчыкам інструменты для доступу і ўнясення ўкладу ў гэтую сістэму рэпутацыі. -Інструменты, якія ўключаюць просты візуальны і праграмуемы доступ да версіі і рэпутацыі ўсіх залежнасцей у іх пакетах. -Дакладнае разуменне таго, якія члены суполкі падтрымліваюць кожны пакет і колькі чайных токенаў яны замочваюць, будзе спрыяць рэпутацыі кожнага пакета, падобна таму, наколькі суправаджэнне пакета замочвае сваю працу, паказвае, наколькі яны стаяць за сваёй працай. -Гэтыя аб'яднаныя пункты даных дапамогуць стварыць сістэму рэпутацыі для ўсіх членаў супольнасці і палегчаць выбар. -Паколькі ўзлом пакета EventStream быў праведзены не праз сам пакет, а праз адну з яго залежнасцей, бачнасць усіх узроўняў залежнасцей будзе мець жыццёва важнае значэнне для стварэння гэтай ненадзейнай сістэмы. -Аднак такія фактары, як выдаткі на вылічэнні і транзакцыі («газ»), павінны мець прыярытэт пры распрацоўцы і стварэнні сістэмы. - -Наша мэта складаецца ў тым, каб узнагародзіць распрацоўшчыкаў як Web 2.0, так і web3. -Тонкасць і спецыфіка кожнага стэка робяць так, што адсочванне ўстаноўкі і выдалення пакетаў можа лёгка стаць ахвярай аднаго або некалькіх злосных суб'ектаў. -Гэта ўключае ў сябе «пакупку» установак для штучнага завышэння лічбаў. -Яшчэ горшым сцэнарыем было б увядзенне фундаментальных змяненняў у прыроду праграмнага забеспячэння з адкрытым зыходным кодам шляхам стварэння непатрэбнага трэння з ліцэнзійнымі ключамі або іншымі механізмамі адсочвання разгортвання. -Каб забяспечыць самы шырокі ахоп, мы лічым, што ўзнагароджанне не павінна абапірацца на спрошчанае ўяўленне аб адсочванні ўстаноўкі або выдалення, а хутчэй на механізмах стымулявання, якія заахвочваюць адпраўку якасных пакетаў і паведамленне аб гнюсных або высокарызыкоўных пакетах. -Нарэшце, многія пакеты абапіраюцца на агульныя залежнасці. -Напрыклад, у Lodash 151 209 утрыманцаў[^15], у той час як у chalk 78 854 утрыманцы[^16] або ў Log4js 3343 утрыманцы[^17]. -Паколькі больш пакетаў ствараецца з выкарыстаннем адных і тых жа залежнасцей, як мы гарантуем, што стымулы размяркоўваюцца справядліва і справядліва? Як мы гарантуем, што найбольш часта выкарыстоўваныя залежнасці будуць узнагароджаны, не губляючы галады новыя або новыя пакеты і распрацоўшчыкаў? -Як мы гарантуем, што сістэма заахвочванняў не скончыцца тым, што адвядзе распрацоўшчыкаў ад нішавых моў і цэнтралізуе іх там, дзе заахвочванні лепшыя? -Але таксама, як распрацоўшчыкі, як мы ідэнтыфікуем пакеты з большасцю залежных, каб стварыць альтэрнатывы - больш простыя, больш эфектыўныя, лепш закадзіраваныя версіі гэтых пакетаў? -У tea мы лічым, што адсутнасць стымулаў перашкаджае развіццю праграмнага забеспячэння з адкрытым зыходным кодам. -Пры падтрымцы правільных эканамічных стымулаў і ўзнагарод больш распрацоўшчыкаў змогуць ствараць, паляпшаць і дапаўняць праграмнае забеспячэнне з адкрытым зыходным кодам для паляпшэння свету. -Толькі тады токен tea зможа прадстаўляць агульную каштоўнасць праграмнага забеспячэння з адкрытым зыходным кодам. - -[^15]: Крыніца: @npmjsLodash -[^16]: Крыніца: @npmjsChalk -[^17]: Крыніца: @npmjsLogFourjs - -## Прадстаўленне пакета - -Адпраўка выпуску пакета патрабуе, каб некалькі транзакцый адбываліся атамарна. -У прыватнасці, суправаджальнік пакета павінен: - -* Зарэгіструйце пакет (і яго семантычную версію) у дэцэнтралізаваным рэестры. -* Загрузіце пакет у дэцэнтралізаваную сістэму захоўвання для ўстойлівасці, устойлівасці да цэнзуры і прастаты распаўсюджвання. -* Унясіце ўклад у рэпутацыю і надзейнасць пакета, *замачыўшы* tea токены. - -Няўдача любой з трох аперацый прывядзе да вяртання пратакола да папярэдняга стану, такім чынам, ухіляючы любыя доказы прадстаўлення. - -Калі пакет будзе паспяхова адпраўлены, суправаджальнік пакета атрымае NFT суправаджэння ў якасці доказу сваёй працы і ўкладу ў адкрыты зыходны код. -Суправаджальнік пакета можа перадаць трэцяй асобе ўзнагароды, звязаныя з суправаджэннем NFT. -Тым не менш, рэпутацыя, звязаная са стварэннем і абслугоўваннем актыву, застанецца ў суправаджэння пакета, таму іх рэпутацыя можа з часам пагоршыцца. -Калі рэпутацыя любога члена супольнасці tea дасягае ключавых этапаў, яны могуць атрымаць доступ да павышаных частак пратаколу або атрымаць паскоранае ўзнагароджанне ў адпаведнасці з рашэннем кіраўніцтва гарбаты. -Больш падрабязную інфармацыю аб суправаджаючай NFT глядзіце ў раздзеле суправаджэння NFT. - -### Аналіз залежнасцей - -Залежнасці пакетаў могуць быць глыбокімі, бо кожны пакет часта мае і залежных, і залежнасці. -Каб забяспечыць простую метадалогію, якая ўзнагароджвае ўсіх распрацоўшчыкаў, якія ўнеслі свой уклад у праграмнае забеспячэнне з адкрытым зыходным кодам, захоўваючы пры гэтым хуткае і эфектыўнае з пункту гледжання вылічэнняў стварэнне дрэва залежнасцей, мы прапануем правяраць толькі залежнасці першага ўзроўню пасля адпраўкі пакета. - -Гэтая канструкцыя абумоўлена гіпотэзай, што кожная залежнасць сама па сабе з'яўляецца пакетам, які быў незалежна адпраўлены ў дрэва tea. -Робячы гэта, кожная з яго залежнасцей можа быць адлюстравана, і калі яе залежнасці самі маюць залежнасці, яны будуць адлюстраваны падчас адпраўкі пакета залежнасцей. - -![Дыяграма аналізу залежнасцей.](img/figure-3.svg){#fig:dep-analysis} - - -У @fig:dep-analysis адпраўка пакета A запускае аналіз залежнасцей выканання з 1 па n і зборкі з 1 па n, у той час як залежнасці выканання з 1.1 па 1.n і залежнасці зборкі з 1.1 па 1.n былі прааналізаваны, калі пакет B быў прадстаўлены. -Мы будзем прымяняць тую ж метадалогію для размеркавання заахвочванняў, паколькі насычаныя токены размяркоўваюцца па ўсіх залежнасцях, такім чынам рэкурсіўна намачваючы пакеты, пералічаныя як залежнасці (гл. @fig:steeping-rewards). - -![Інтэнсіўнае размеркаванне ўзнагарод па залежнасцях.](img/figure-2.svg){#fig:steeping-rewards} - - -Упраўленне версіямі і супярэчлівыя залежнасці з'яўляюцца сур'ёзнымі праблемамі, і ліквідацыя іх непаладак можа абярнуцца вялізнымі выдаткамі часу. -Каб вырашыць гэтую праблему, мы прапануем кожны пакет падвяргаць комплекснаму сканаванню залежнасцей пасля адпраўкі, каб мы маглі гарантаваць, што пакет адпавядае наступным правілам для семантычных дыяпазонаў версій. - -* Пакеты могуць абмяжоўваць свае залежнасці толькі ад асноўнай версіі, хоць пачаткам дыяпазону можа быць любая сапраўдная семантычная версія (напрыклад, >=5.2.1 <6). -* Калі залежнасць абнаўляецца да больш свежай асноўнай версіі, tea можа запатрабаваць павелічэння асноўнай версіі пакета. -* Падобным чынам, калі залежнасць абнаўляецца да больш свежай мінорнай версіі, tea можа запатрабаваць павелічэння мінорнай версіі пакета. -* Калі дадаецца новая залежнасць, для tea можа спатрэбіцца павялічыць мінорную версію пакета. - -Улічваючы непатрэбныя намаганні, якія прыкладаюцца да любога карыстальніка пакета пры парушэнні вышэйпералічаных правілаў, мы прапануем скараціць частку токена tea, прасякнутага суправаджэннем пакета, каб адлюстраваць адсутнасць належнай абачлівасці. -Калі распрацоўнік прымусіць усіх жангляваць кубкамі, нехта пралье крыху tea. -Паколькі чакаецца, што сканаванне залежнасцяў будзе адбывацца пры адпраўцы, мы павінны адзначыць, што ніякага замочвання пакета ад прыхільнікаў і спонсараў або дэгустатараў tea не адбудзецца. - -## Рэпутацыя пакета і суправаджэння пакета - -Абслугоўвальнікі пакетаў павінны ўнесці свой уклад у рэпутацыю і надзейнасць свайго пакета шляхам замочвання tea токенаў. -Аднак сістэма рэпутацыі, якая абапіраецца выключна на эканамічны ўклад аўтара, не забяспечвае дастатковай абароны карыстальнікаў і можа падвяргацца атакам Sybil, калі адзін чалавек стварае некалькі прадстаўленняў сябе, каб пакінуць вялікую колькасць станоўчых водгукаў на сваю працу, прымусіць карыстальнікаў паверыць, што іх праца была разгледжана і ўхвалена многімі. - -Для прадухілення нападаў Sybil даступна некалькі метадалогій, некаторыя з якіх апісаны Ніцішам Балачандранам і Сугатай Саньялам у «Аглядзе метадаў змякчэння нападаў Sybil»[^18]. -Паколькі tea з'яўляецца дэцэнтралізаваным пратаколам, выкарыстанне давернай сістэмы сертыфікацыі, якая абапіраецца на цэнтралізаваны орган выдачы сертыфікатаў, будзе супярэчыць яе аснове. -Мы прапануем засяродзіць увагу на дэцэнтралізаваных падыходах да змякчэння нападаў Sybil і, больш канкрэтна, на метадалогіях, якія абапіраюцца на вялікую групу ўдзельнікаў сеткі, заахвочаных ацэньваць і публічна прадстаўляць рэпутацыю кожнага пакета і яго суправаджальніка. - -Падобна вытворчасці блокаў у блокчейне з доказам долі, дзе вузлы, якія не вырабляюць, могуць правяраць працу іншых і, пры неабходнасці, вылучаць парушэнне правілаў сеткі, што вядзе да пакарання дрэннага ўдзельніка праз падразанне (знішчэнне часткі іх долі), мы прапануем сістэму, з дапамогай якой трэція бакі (яны ж дэгустатары tea) змогуць праглядаць пакеты, створаныя суправаднікамі пакетаў, і атрымліваць эканамічныя стымулы паводзіць сябе ў інтарэсах супольнасці праграмнага забеспячэння з адкрытым зыходным кодам і яго карыстальнікаў, а таксама прызнаваць добрыя паводзіны і караць за дрэнныя паводзіны. -Гэтая сістэма павінна быць адначасова ўстойлівай да Sybil і перашкаджаць буйным уладальнікам токенаў істотна ўплываць на пратакол або рэпутацыю пэўных пакетаў. -Мы лічым, што гэты падыход больш адпавядае адкрытаму зыходнаму коду, забяспечваючы больш урадлівы субстрат для прыняцця і даверу і, у канчатковым выніку, спрыяючы росту tea. - -[^18]: Крыніца: @arxiv - -## Агляд пакета трэцімі асобамі - -Праверка пакетаў трэцімі асобамі з'яўляецца важным кампанентам пабудовы рэпутацыі, аднак праверка трэцімі асобамі мае свой уласны набор унікальных пагроз, уключаючы вышэйзгаданыя атакі Sybil. - -Тэхналогія блокчейн і, больш выразна, стаўка, прапануе ўнікальную магчымасць для tea справіцца з гэтай праблемай. -Нягледзячы на ​​тое, што адрасы кашалькоў могуць быць даступныя ў бясконцай колькасці, гэта не так з токенамi tea, першапачатковы запас якіх, як чакаецца, складзе 10 мільярдаў. -Акрамя таго, кожнае дзеянне, якое выконваюць распрацоўшчыкі, напрыклад, адпраўка пакетаў, праверка пакетаў або іх замочванне, спрыяе іх рэпутацыі, ствараючы такім чынам унікальны профіль, які кожны распрацоўшчык можа выкарыстоўваць, каб унесці свой уклад у супольнасць tea і прыняць удзел у кіраванні tea. - -Патрабуючы ад старонніх рэцэнзентаў настойваць токены tea і рызыкуючы страціць частку сваіх навараных токенаў, калі выявіцца, што яны паводзяць сябе насуперак інтарэсам сеткі або з'яўляюцца дрэнным удзельнікам, трэція асобы могуць забяспечыць дадатковую давер да пакета і атрымаць узнагароду ў выглядзе токенау tea. - -Мы таксама прапануем пашырыць сістэму рэпутацыі на трэціх асоб, якія праводзяць незалежную праверку ўпакоўкі - дэгустатараў tea. -Завяршэнне станоўчага агляду запатрабуе выканання дзвюх атамарных аперацый: - -* Прадстаўленне агляду кода, падпісанае дэгустатарам tea і агульнадаступнае для ўсіх членаў супольнасці, а таксама -* Акт замочвання «за» пакет (супраць «супраць» пакета), каб абгрунтаваць іх агляд. - -Завяршэнне адмоўнага агляду, які змяшчае адну або некалькі крытычных уразлівасцяў, запатрабуе ад дэгустатараў tea звязацца з распрацоўшчыкам упакоўкі з дапамогай пратаколу абмену паведамленнямі, каб паведаміць ім аб уразлівасці і дазволіць ім своечасова вырашыць праблему. -Пасля заканчэння вызначанага кіраваннем перыяду, адведзенага суправаджальніку пакета для ліквідацыі яго ўразлівасці, або калі выпраўлены пакет стане даступным, той жа пратакол абмену паведамленнямі будзе выкарыстоўвацца для паведамлення ўсім карыстальнікам і тэсціроўшчыкам гэтага пакета (уключаючы ўтрыманцаў) аб тым, што ўразлівасць была выяўлена ідэнтыфікаваны, -і, спадзяюся, разгледжаны, каб яны ведалі, што трэба абнавіць сваё прыкладанне або залежнасці. -Каб перашкодзіць марнаваць час распрацоўшчыкаў, камунікацыя паміж дэгустатарамі tea і спецыялістамі па суправаджэнні ўпакоўкі запатрабуе ад дэгустатараў tea настойвання токенаў tea. - -Пасля завяршэння абедзвюх аперацый дэгустатары tea атрымаюць NFT у якасці доказу іх працы над канкрэтнай упакоўкай і версіяй упакоўкі. -Назапашванне NFT у спалучэнні з каэфіцыентам замочвання кожнага з разгледжаных пакетаў і інфармацыяй, атрыманай са знешніх сістэм, будзе спрыяць рэпутацыі дэгустатара tea. -Калі іх рэпутацыя дасягае ключавых вех, дэгустатары tea могуць атрымаць доступ да павышаных частак пратаколу або паскораных узнагарод, згодна з рашэннем кіраўніцтва tea. - -## Састарэлыя або пашкоджаныя пакеты - -Місія tea - узнагароджваць удзельнікаў і ўдзельнікаў суполак з адкрытым зыходным кодам; аднак узнагароды павінны быць сувымерныя з намаганнямі, якія прыкладаюцца спецыялістамі па суправаджэнні пакетаў і дэгустатарамі tea. -Недастатковае абслугоўванне, састарэлыя або пашкоджаныя пакеты з'яўляюцца відавочным сведчаннем таго, што суправаджальнікі пакетаў не апраўдваюць чаканняў супольнасці або не забяспечваюць даверу і падтрымкі, якія ўзніклі на іх праз насычэнне пакетаў. -Яшчэ адной праявай састарэлых пакетаў можа быць пастаяннае выкарыстанне старой мовы або старой версіі шматверсійных моў. -Упакоўкі, якія занадта доўга застаюцца састарэлымі або пашкоджанымі, сведчаць аб тым, што дэгустатары tea павінны рэгулярна і паслядоўна праглядаць працу тых, хто падтрымлівае ўпакоўку. - -дэгустатары tea з'яўляюцца найважнейшымі членамі суполак з адкрытым зыходным кодам, таму што іх агляды і звязаныя з імі прэтэнзіі могуць накіроўваць карыстальнікаў пакетаў да пакетаў або ад іх. -Каб пераканацца, што аглядам можна давяраць на пастаяннай аснове, мы прапануем механізм, з дапамогай якога састарэлыя або пашкоджаныя ўпакоўкі могуць бачыць частку сваіх намочаных токенаў, адпраўленых дэгустатарам tea, якія першымі выявілі адсутнасць абслугоўвання любой упакоўкі. - -Любы адмоўны агляд, які акрэслівае недахоп, такі як уразлівасць нулявога дня або выкарыстанне састарэлай залежнасці, і застаецца адкрытым пасля льготнага перыяду, вызначанага кіраўніцтвам, павінен разглядацца як адмова з боку суправаджэння пакета. -Яны не выканалі даручаную і ўзнагароджаную справу. -Тое ж самае можна сказаць пра прыхільнікаў і спонсараў пакетаў, якія паставілі сваю рэпутацыю на працу правапарушальнікаў суправаджэння пакетаў і атрымалі за гэта ўзнагароды, але не змаглі выявіць недахоп абслугоўвання або вырашылі працягваць падтрымліваць пакет, нягледзячы на гэта. - -Па меры таго, як пакеты набіраюць папулярнасць і карыстанне, з большай колькасцю прыкладанняў і патэнцыйна крытычна важных сістэм, якія залежаць ад іх, мы павінны стымуляваць распрацоўшчыкаў непрыкметна паведамляць аб недахопах суправаджаючаму пакетаў, а таксама суправаджаючым пакетаў для ліквідацыі такіх недахопаў, перш чым іх можна будзе выкарыстоўваць. -Такім чынам, мы прапануем, каб любы састарэлы або пашкоджаны пакет, які падвяргаецца аднаму або некалькім пацверджаным негатыўным водгукам і застаецца ў такім стане пасля перыяду адтэрміноўкі, вызначанага кіраваннем, скараціў частку яго токенаў незалежна ад іх паходжання (суправаджальнік пакета, пакет прыхільнікаў і спонсараў або папярэдніх дэгустатараў tea), іншая порцыя адпраўляецца дэгустатарам tea, якія пакінулі адмоўныя водгукі. -Размеркаванне сярод усіх дэгустатараў tea можа быць заснавана на ўзросце іх агляду і колькасці токенаў tea, якія яны намачылі для агляду. - -## Суправаджальнік NFT - -Пасля паспяховай адпраўкі пакета суправаджэнне пакета атрымае NFT у доказ іх працы і ўкладу. -Уладальнік гэтага NFT аўтаматычна атрымае ўсе ўзнагароды, звязаныя з пакетам. -Суправаджальнікі пакетаў могуць перадаць права ўласнасці на абслугоўванне пакета іншаму суправадзіцелю пакета, проста перадаўшы NFT пакета. -Паспяховая перадача NFT прывядзе да таго, што новы ўладальнік аўтаматычна атрымае будучыя ўзнагароды за пакет. - -Важная частка стварэння рэпутацыі залежыць ад частаты і колькасці адпраўкі якасных пакетаў. -NFT, якія дастаўляюцца суправаднікам пакетаў у якасці доказу іх працы, могуць выкарыстоўвацца сістэмай рэпутацыі для абнаўлення рэпутацыі суправаджэння пакетаў і прадастаўлення ім доступу да павышаных частак пратаколу, згодна з рашэннем кіраўніцтва tea. -Аднак для прадухілення вектараў нападаў, такіх як купля членамі супольнасці іх рэпутацыі, перадача суправаджэння NFT не прывядзе да перадачы рэпутацыі. -Рэпутацыя павінна заставацца непасрэдна звязанай з канкрэтнай працай распрацоўшчыка і не павінна падлягаць перадачы. - -# tea токен - -## Бяспека сеткі - -У той час як многія блокчейны могуць выглядаць як эфектыўныя і бяспечныя інфраструктурныя рашэнні для падтрымкі мэтаў tea, мы лічым, што трэба ўважліва разгледзець тэхналагічны стэк, на якім пабудавана сістэма tea. - -Маштабаванасць, эканамічная эфектыўнасць, ESG і пашыральнасць старонніх з'яўляюцца важнымі фактарамі дызайну, якім можа лепш служыць сістэма пацверджання стаўкі tea-suvereign. -У proof-of-stake аператары вузлоў і ўдзельнікі сеткі робяць стаўку на эканамічную каштоўнасць у выглядзе ўласнага токена ланцужка для павышэння бяспекі сістэмы. -Аператары вузлоў і ўдзельнікі сеткі атрымліваюць узнагароды за паспяховую вытворчасць блокаў, якія адпавядаюць правілам сеткі і ўключаюць дакладную інфармацыю аб транзакцыях. -Бяздзейнасць (яна ж адключаны вузел) або зламысная/няправільная дзейнасць караюцца знішчэннем долі пастаўленых токенаў праз слэш. - -Сістэма proof-of-stake, якая працуе на базе токена tea, дазволіць уладальнікам токена tea ўнесці свой уклад у бяспеку сістэмы, *ставячы* tea, і падтрымліваць распрацоўшчыкаў з адкрытым зыходным кодам, *замочваючы* tea. -Мы цалкам разумеем, што эканамічныя фактары могуць перашкодзіць некаторым распрацоўшчыкам рабіць стаўку або замочваць tea; такім чынам, стэйкінг і замочванне будуць даступныя ўсяго за ліст, найменшы наміналам гарбаты будзе роўная адна стомільённая ($10^{-8}$) tea. - -Абодва прыкладання токена tea выконваюць жыццёва важныя функцыі ў падтрымцы і развіцці экасістэмы з адкрытым зыходным кодам. -Стэйкiнг tea будзе гарантаваць, што сістэма tea будзе працягваць бяспечна працаваць, таму ўсе ўдзельнікі сеткі могуць адпраўляць і атрымліваць доступ да пакетаў, каб праглядаць іх, інтэграваць іх у свае праграмы і г.д. -Наадварот, замочванне tea падтрымае мэту tea па прадастаўленні інструментаў для ўсіх удзельнікаў сеткі для падтрымкі і выкарыстання пакетаў, якія адпавядаюць патрабаванням якасці і надзейнасці, сфармуляваным чайнай супольнасцю праз падтрымку і нязгоду з кожным пакетам. -Будзе праяўлена асцярожнасць пры вызначэнні і рэалізацыі параметраў разбіўкі і замочвання, каб адзін не стаў паразітам на іншым. - -## Заахвочванні і пакаранні - -Як ужо гаварылася раней, у зладзеяў могуць быць моцныя стымулы скампраметаваць праграмнае забеспячэнне з адкрытым зыходным кодам. -Большая частка крытычна важнай інфраструктуры Інтэрнэту працуе з адкрытым зыходным кодам, і гонка за пошукам эксплойтаў і іншых уразлівасцяў працягваецца. -У tea мы лічым, што варта вінаваціць не тых, хто падтрымлівае пакеты (хаця яны часта бываюць). - -Стымулы пратакола tea выпраўляюць гэта шляхам справядлівага і роўнага размеркавання стымулаў. -Такі пакет, як Lodash з больш чым 151 тысячай утрыманцаў, з'яўляецца апорай распрацоўкі з адкрытым зыходным кодам, і яго суправаджэнне заслугоўвае прапарцыйнага ўзнагароджання. -Аднак сістэма ўзнагароджання, пабудаваная выключна на колькасці ўтрыманцаў, не дазволіць наватарам разбурыць гэтыя манаполіі, калі толькі яны не атрымліваюць дастатковага фінансавання трэцімі асобамі або ўжо назапасілі дастаткова рэсурсаў для самафінансавання. -Такі падыход, хутчэй за ўсё, прывядзе да змяншэння колькасці ўдзельнікаў, што прывядзе да палярнай супрацьлегласці таго, што такое tea. - -Мэта tea складаецца ў тым, каб прадставіць каштоўнасць праграмнага забеспячэння з адкрытым зыходным кодам і, робячы гэта, спрыяць яго росту, даючы ўдзельнікам рэсурсы, неабходныя для бесперашкоднага выканання свайго захаплення. -Сістэма размеркавання гарбаты павінна ўважліва ўлічваць каэфіцыент замочвання кожнай упакоўкі і адпаведным чынам карэктаваць заахвочванне кожнай упакоўкі. -Каб знізіць рызыку таго, што невялікая колькасць пакетаў, якія выкарыстоўваюцца ў якасці залежных у многіх праграмах, збіраюць большасць высокіх узнагарод, мы будзем выкарыстоўваць даследаванні, праведзеныя Фондам web3[^19] для механізму ўзнагароджання Polkadot, заснаванага на доказе стаўкі. -Мы можам дадаткова скарэктаваць рэалізацыю і яе зменныя на аснове вынікаў практычных эксперыментаў. - -Па меры набліжэння пакета да аптымальнага каэфіцыента замочвання, вызначанага кіраўніцтвам, яго каэфіцыент узнагароды за замочванне будзе паступова зніжацца. -Калі ўпакоўка перавышае аптымальны каэфіцыент замочвання, каэфіцыент ўзнагароджання за замочванне рэзка зніжаецца, каб пазбавіць прыхільнікаў упакоўкі і дэгустатараў гарбаты ад далейшага замочвання ўпакоўак з моцнай настойкай. -Такая канструкцыя магла б зрабіць упакоўкі з меншай намочанасцю больш прывабнымі як для прыхільнікаў упакоўкі, так і для дэгустатараў tea. -Гэта таксама можа стымуляваць вопытных распрацоўшчыкаў ствараць альтэрнатывы высокапрадукцыйным пакетам, ствараючы магчымасць для супольнасці tea збалансаваць падтрымку існуючага праграмнага забеспячэння і прасоўванне інавацый. -Каэфіцыент замочвання будзе разлічвацца з выкарыстаннем цыркуляцыйнай падачы ў першапачатковай канструкцыі. -Cупольнасць tea можа змяніць гэты дызайн, каб яшчэ больш палепшыць маштабаванасць сістэмы. -Няхай $\chi$ будзе каэфіцыентам замочвання ўсіх пакетаў. -Ён уяўляе сабой агульную колькасць токенаў tea, насычаных супрацоўнікамі пакетаў, карыстальнікамі пакетаў, прыхільнікамі і спонсарамі пакетаў і дэгустатарамі tea, падзеленую на агульную колькасць маркераў tea. -Улічваючы, колькі пакетаў з адкрытым зыходным кодам даступна сёння і іх чаканы рост, $\chi$ заўсёды будзе вельмі малым значэннем ад $0$ да $1$. - -Няхай $\psi$ будзе каэфіцыентам стаўкі. -Ён уяўляе сабой агульную колькасць токенаў tea, пастаўленых любым удзельнікам сеткі для забеспячэння бяспекі сеткі. - -Няхай $\chi_{ideal}$ будзе каэфіцыентам замочвання, якога мы хацелі б дасягнуць для кожнага пакета для справядлівага размеркавання ўзнагароджання па ўсіх пакетах і іх залежнасцях. -Значэнне $\chi_{ideal}$ павінна абнаўляцца па меры дадання новых пакетаў у дэцэнтралізаваны рэестр і стварэння залежнасцей. -Каб вызначыць найлепшае значэнне для $\chi_{ideal}$, мы будзем выкарыстоўваць крывую папулярнасці, якая абнаўляецца ў пачатку кожнага цыкла ўзнагароджання. - -Няхай $\tau = \tau(\chi)$ будзе гадавой працэнтнай стаўкай, якая распаўсюджваецца на ўсіх членаў чайнай супольнасці, якія замочваюць токены tea для падтрымкі распрацоўшчыкаў з адкрытым зыходным кодам. -Іншымі словамі, $\tau(\chi)$ адпавядае ўзнагародзе за замочванне, атрыманай за год членам супольнасці, які замочвае токены tea за ўвесь год. - -Няхай $\gamma = \gamma(\psi)$ будзе гадавой працэнтнай стаўкай стаўкі, размеркаванай паміж усімі аператарамі вузлоў і ўдзельнікамі сеткі, якія ставяць токены гарбаты для бяспекі сеткі. -Іншымі словамі, $\gamma(\psi)$ адпавядае ўзнагародзе за стаўку, атрыманай за год членам супольнасці, які робіць стаўку на токены tea за ўвесь год. - -Няхай $\delta$ - гадавая інфляцыя, накіраваная на сеткавую казну. -$\delta$ можа адрознівацца ў залежнасці ад знешніх фактараў, якія ўплываюць на прапанову токенаў. - -Мы разглядаем штогадовую стаўку ўзнагароджання за замачванне як функцыю $\chi$ і гадавую стаўку ўзнагароджання за стаўку як функцыю $\psi$. - -* $\tau(\chi)$ адпавядае заахвочванню людзей настойваць пакет. -Калі $\chi$ павялічваецца, патрабуецца менш узнагарод $\tau(\chi)$. -* $\gamma(\psi)$ адпавядае стымулу для людзей рабіць стаўку на сетку. -Калі $\psi$ павялічваецца, для забеспячэння бяспекі сеткі патрабуецца менш узнагарод $\gamma(\psi)$. - -Гадавая інфляцыя $I$ будзе эквівалентная $(\tau + \gamma + \delta)$ і разлічваецца наступным чынам: - -$$ -I = \frac{\textrm{прапанова токенаў у канцы года} - \textrm{прапанова токенаў на пачатак года}}{\textrm{прапанова токенаў на пачатак года}} = (\tau + \gamma + \delta) -$$ - -Варта ўзважыць уклад у інфляцыю $\tau_{\textsc{all}}$ (стымул, размеркаваны ўсім удзельнікам пакета) і $\gamma_{\textsc{all}}$ (стымул, размеркаваны паміж усімі ўдзельнікамі бяспекі сеткі). каб гарантаваць, што сістэма стымулюе аптымальнае суадносіны замочвання/стаўкі. - -Паколькі мы засяроджваемся на стымулах, размеркаваных па ўсіх пакетах, мы вызначаем гэта -$\tau_{\textsc{all}}$ -з'яўляецца функцыяй каэфіцыента замочвання $\chi$ і таму -$\tau_{\textsc{all}}(\chi) = \chi \cdot \tau(\chi)$. -З нашага папярэдняга аналізу мы бачым гэта -$\tau_{\textsc{all}}(\chi_{ideal}) = \chi_{ideal} \cdot \tau_{ideal}$. -Паколькі мэта складаецца ў тым, каб дасягнуць стану, дзе -$\chi = \chi_{ideal}$, узнагароды -$\tau_{ideal}(\chi)$ -павінен быць максімальным пры гэтым значэнні. - -Няхай $\tau_{ideal} = \tau(\chi_{ideal})$ -быць стаўкай узнагароджання, якую забяспечвае сетка пры ідэальным сцэнары -$\chi = \chi_{ideal}$. - -Няхай $\tau_{0}$ будзе мяжой $\tau_{\textsc{all}}(\chi)$, бо $\chi$ звяртаецца да нуля, калі ні адзін з членаў супольнасці tea не напаўняе пакеты. -Значэнне $\tau_{0}$ павінна быць блізкім да нуля, але не роўным нулю, каб стымуляваць першых карыстальнікаў. -Як вынікае з даследаванняў фонду web3, мы прапануем, каб: - -* функцыя інфляцыі лінейна расце паміж $\chi = 0$ і $\chi = \chi_{ideal}$, і -* ён экспанентна распадаецца паміж $\chi = \chi_{ideal}$ і $\chi = 1$. - -Мы абралі падобнае экспанентнае зніжэнне для $\tau_{\textsc{all}}(\chi)$, таму што гэта азначае экспанентнае зніжэнне $\tau(\chi)$, і мы хочам, каб узнагароды рэзка ўпалі за $\chi_{ ideal}$, каб адзін пакет не атрымаў усе ўзнагароды. - -Заняпад вызначаецца такім чынам, што ўзровень інфляцыі зніжаецца не больш чым на 50%, калі $\chi$ зрушвае $d$ адзінак управа ад $\chi_{ideal}$ – г.зн. -$\tau_{\textsc{all}}(\chi_{ideal} + d) \geq \tau_{\textsc{all}} \cdot 0,5$. - -Мы прапануем наступныя функцыі працэнтнай стаўкі і ўзроўню інфляцыі, якія залежаць ад параметраў $\chi_{ideal}$, $\tau_{ideal}$, $\tau_{0}$ і $d$. - -\begin{align*} -&\tau_{\textsc{all}}(\chi) = \tau_{0} + (\tau_{\textsc{all}}(\chi_{ideal}) - \tau_{0})\frac{\chi}{\chi_{ideal}}\enspace\textrm{for}\;0 < \chi \leq \chi_{ideal} \\ -&\tau_{\textsc{all}}(\chi) = \tau_{0} + (\tau_{\textsc{all}}(\chi_{ideal}) - \tau_{0}) \cdot 2^{(\chi_{ideal}-\chi)/d}\enspace\textrm{for}\;\chi_{ideal} < \chi \leq 1 -\end{align*} - -Як і добрых акцёраў трэба ўзнагароджваць; кепскіх акцёраў трэба выявіць і пакараць. -Праграмнае забеспячэнне з адкрытым зыходным кодам дае шмат магчымасцей для дрэнных удзельнікаў ствараць балючыя кропкі і рэпутацыйныя рызыкі для ўсёй супольнасці распрацоўшчыкаў. -Вайна паміж добрымі і дрэннымі ўдзельнікамі працягваецца, пачынаючы ад незаконнага прысваення працы і заканчваючы змяненнем і пераразмеркаваннем пакетаў праграмнага забеспячэння або ўкараненнем гнюснага кода, часта з добра фінансаванымі дрэннымі ўдзельнікамі, якія бачаць у забруджванні пакетаў з адкрытым зыходным кодам магчымасць атрымаць фінансавую выгаду. -Адваротны бок быў адносна мінімальным: пакеты патэнцыйна былі забароненыя на лічбавых паліцах або падвяргаліся дрэннай рэпутацыі. - -Мы прапануем увесці механізм скарачэння, каб усталяваць больш істотны недахоп, які непасрэдна ўплывае на эканамічную каштоўнасць дрэнных удзельнікаў. -Пакуль дэгустатары tea ацэньваюць і аналізуюць код у нядаўна адпраўленых упакоўках, мы прапануем дэгустатарам tea атрымаць інструменты і стымулы для дакладнага выяўлення і вылучэння гнюснага кода, каб карыстальнікі ўпакоўкі маглі быць дасведчаныя аб рызыках, а ахоўнікі ўпакоўкі, прыхільнікі ўпакоўкі і спонсары былі пакараныя. за адпраўку або падтрымку гнюснага кода. -У гэтай ступені, за ўсе пацверджаныя негатыўныя агляды, выкананыя ў адпаведнасці з правіламі сеткі і якія былі разгледжаны суправаджэннем пакета на працягу вызначанага кіраваннем перыяду, суправаджэнне пакета не павінна несці ніякіх штрафаў у адрозненне ад прыхільнікаў і спонсараў пакета або дэгустатараў tea, якія даў станоўчы водгук аб разгляданым пакете. -Для негатыўных водгукаў, зробленых у адпаведнасці з правіламі сеткі і якія суправаджэнне пакета не было вырашана на працягу вызначанага кіраваннем перыяду, частка токенаў, прасякнутых суправаджэннем пакета, прыхільнікамі пакета і спонсарамі, а таксама папярэднімі дэгустатарамі tea, будзе скарочана. -Іншая частка будзе зачыненая ў страхавым пуле, які кантралюецца кіраўніцтвам tea. -Упраўленне tea усталюе палітыку і правілы ў цесным супрацоўніцтве з супольнасцю, каб распаўсюджваць змесціва пула тым, хто пацярпеў ад уразлівасцяў. -Пратакол размяркуе трэцюю долю намачаных токенаў паміж усімі дэгустатарамі tea, якія ўнеслі свой уклад у адмоўны водгук і намачылі супраць упакоўкі, у залежнасці ад колькасці токенаў tea, якія яны намачылі «супраць» упакоўкі, і таго, як доўга іх токены настойваліся. -Іншымі словамі, чым раней адзін або некалькі дэгустатараў tea выявяць і паведамяць пра недахоп у адпаведнасці з правіламі сеткі, тым вышэйшую ўзнагароду яны атрымаюць за падтрымку бяспечнай і прадуктыўнай распрацоўкі з адкрытым зыходным кодам. - -Каб члены суполкі не маглі выпадковым чынам галасаваць «супраць» моцна намочаных пакетаў у надзеі атрымаць большасць любых штрафных санкцый, усе токены tea, намочаныя «супраць», не будуць узнагароджаны інфляцыяй і могуць падвяргацца механізму распаду, што з часам зніжае іх кошт . - -[^19]: Крыніца: @web3 - - -# Кіраванне - -Кіраванне мае вырашальнае значэнне для развіцця, устойлівасці і прыняцця любой размеркаванай сістэмы. - -Мы прапануем, каб tea уключала ў сябе кіраванне ў ланцужку, дзе ўсе ўладальнікі токенаў tea могуць прапаноўваць і галасаваць за змены крытычных параметраў, узважаных у залежнасці ад уласнасці токенаў і рэпутацыі. -Гэтыя параметры могуць уключаць інфляцыю, камісію за транзакцыі, узнагароды за стаўку, узнагароды за замочванне або аптымальны каэфіцыент замочвання. -Гэта функцыянальнасць гарантуе, што важныя параметры могуць развівацца і аптымізавацца з цягам часу членамі супольнасці tea. -Мы чакаем, што кіраванне пачнецца з простай структурай і будзе паступова пашырацца па меры сталення сістэмы tea, палягчаючы прыняцце і забяспечваючы паступовую дэцэнтралізацыю. - -Некаторыя сістэмныя параметры могуць не падлягаць кіраванню або падтрымліваць высокачашчынныя змены для памяншэння паверхні атакі, прадстаўленай кіраваннем. -Паступовы пераход параметраў да адкрытага дэцэнтралізаванага кіравання забяспечыць стабільнасць і прадказальнасць сістэмы. - - -# Пашыральнасць іншых вытворцаў - -Калі мы ствараем першапачатковыя інструменты для таго, каб распаліць падтрымку суполак з адкрытым зыходным кодам, якую даўно чакала неабходнасць, мы лічым, што часткай нашай місіі з'яўляецца забеспячэнне таго, каб трэція бакі маглі пашырыць агульны набор інструментаў. -У дадатак да прадастаўлення інфраструктуры для распрацоўшчыкаў для стварэння пашырэнняў пратаколу, у тым ліку новых спосабаў інавацый і далейшай падтрымкі распрацоўшчыкаў з адкрытым зыходным кодам, у нашы планы ўваходзіць магчымасць іншых менеджэраў пакетаў унесці свой уклад у пратакол. -Мары і намаганні распрацоўшчыкаў з адкрытым зыходным кодам стварылі інавацыю, якая падтрымлівае наша паўсядзённае жыццё. -Мы з нецярпеннем чакаем новых спосабаў выкарыстання і пашырэння tea, прапанаваных супольнасцю tea. - - -# Будучая праца і магчымыя намаганні супольнасці - -Па меры сталення сістэмы tea мы мяркуем, што супольнасць будзе прымаць рашэнні і ўносіць свой уклад у змены і пашырэнні сістэмы tea праз кіраванне. -Ніжэй прыведзены некаторыя ідэі, якія, як мы лічым, могуць натхніць некаторых. - -## Аптавікі tea - -Суполкі праграмнага забеспячэння з адкрытым зыходным кодам яркія і пастаянна шукаюць інавацыі і забяспечваюць каштоўнасць. -Гэтая самаадданасць і альтруізм прыводзяць да пастаяннага стварэння новага праграмнага забеспячэння і пакетаў, кожны з якіх утрымлівае залежнасці. -У выніку мы чакаем, што карта залежнасцей будзе пастаянна развівацца, што прывядзе да частых змяненняў каэфіцыента замочвання і ўзнагароджання. -У будучыні супольнасць tea можа прапанаваць распрацоўку сістэмы, прызначанай для дынамічнага маніторынгу каэфіцыента замочвання кожнай упакоўкі і змены балансу таго, як прыхільнікі ўпакоўкі замочваюць свае токены на аснове ўласных крытэрыяў. - -## Роялці за перадачу пакета - -Мы ўсведамляем, што распрацоўшчыкі пакетаў могуць вырашыць перадаць свой паток узнагароджання аднаму або некалькім распрацоўшчыкам. -Кіраванне такой перадачай павінна заставацца рашэннем суправаджэння пакета і іх партнёраў без умяшання з боку tea. -Патрэбны быць прадастаўлены інструменты, каб такая перадача была поўнай або частковай (магчыма, праз перанакіраванне толькі часткі залішніх узнагарод аднаму або некалькім распрацоўшчыкам, у той час як астатнія ўзнагароды працягваюць паступаць да арыгінальнага суправаджэння пакета) -і каб вялікія ўзнагароды паступалі праз адзін уліковы запіс, які кантралюецца адным удзельнікам сеткі, некалькімі ўдзельнікамі сеткі, або аўтаматычна размяркоўваецца паміж некалькімі ўліковымі запісамі з выкарыстаннем статычных або дынамічных суадносін. - -## Размеркаванне ўзнагарод паміж некалькімі суправаджаючымі - -Абслугоўванне пакета можа абапірацца на працу яшчэ адной каманды распрацоўшчыкаў. -Перад тым, як пачнуць паступаць узнагароды, камандам варта падумаць аб аўтаматызацыі размеркавання ўзнагарод паміж сабой. -Як адбываецца размеркаванне, павінны вырашаць самі суправаднікі, бо яны знаходзяцца ў лепшым становішчы, каб ацаніць, хто ўнёс свой уклад і як яны павінны быць узнагароджаны. - -Каб дасягнуць гэтага, кожная каманда (або каманды) можа стварыць сваю ўласную дэцэнтралізаваную аўтаномную арганізацыю (DAO) і альбо аўтаматызаваць размеркаванне ўзнагарод, альбо разгарнуць больш складаныя сістэмы для вызначэння адэкватнага размеркавання ўзнагарод на аснове знешніх фактараў, такіх як галасаванне ўсіх DAO. члены, або размеркаванне на аснове часу, заснаванае на бесперапынным унёску, паспяховым выкананні бонусаў і г.д. - -## Пакет обработки “Форкi” - -Мы лічым, што форкi неабходныя і ў значнай ступені недастаткова выкарыстоўваюцца. -Форкі могуць быць эфектыўным інструментам для распрацоўкі пакетаў, якія канкуруюць у функцыянальнасці, прадукцыйнасці, бяспецы і нават увазе. -Якімі б карыснымі яны ні былі, форкi павінны распазнаваць першапачатковыя намаганні. -Дзякуючы будучай працы або патэнцыйнаму ўкладу, чайная супольнасць можа палепшыць сістэму, каб патрабаваць дэклараваць відэльцы, магчыма, нават выяўляць іх пры адпраўцы пакета. -Незаяўленыя форкi, выяўленыя дэгустатарамі tea, могуць прывесці да таго, што частка намочаных токенаў будзе скарочаная, перададзена арыгінальнаму суправаджальніку ўпакоўкі і адпраўлена дэгустатарам tea, якія выявілі форкi. - -## Залежнасці часу выканання супраць зборкі - -tea можа не адрозніваць залежнасці зборкі ад залежнасцей выканання пры размеркаванні вялікіх узнагарод пры запуску. -Тым не менш, пры ўмове, што супольнасць tea рашуча настроена на такое адрозненне, супольнасць tea можа прапанаваць удасканаленне алгарытму размеркавання ўзнагароджання, каб улічыць важнасць кожнай залежнасці і яе ўклад у кошт пакетаў, якія ад іх залежаць. -Гэтыя прапановы будуць прагаласаваны і рэалізаваны на падставе рашэння супольнасці. - -## Узнагароджанне на аснове выкарыстання - -Па меры стварэння большай колькасці прыкладанняў з выкарыстаннем пакетаў, зарэгістраваных у tea, супольнасць можа павялічыць алгарытм узнагароджання, каб на размеркаванне маглі ўплываць знешнія атэставаныя наборы даных, напрыклад выкарыстанне. -Гэта абнаўленне механізму ўзнагароджання можа дазволіць большае размеркаванне ўзнагароджання токенаў tea для паступлення ў пакеты з найбольшым выкарыстаннем, захоўваючы пры гэтым абмежаванні каэфіцыента замочвання, апісаныя ў раздзеле токенаў tea. -Распрацоўшчыкі пакетаў маглі б выкарыстоўваць падобны падыход для размеркавання вялікіх узнагарод паміж сваімі залежнасцямі на аснове празрыстай логікі іх выбару. -Звярніце ўвагу, што ўся інфармацыя, якая выкарыстоўваецца для ўплыву на размеркаванне ўзнагароджанняў па пакетах і залежнасцях у сістэме tea, павінна быць даказальна надзейнай. - - -# Падзяка - -Гэтая белая кніга не існавала б без падтрымкі і адданасці многіх чаафілаў. -Аўтары выказваюць падзяку Джошу Кругеру, Джадзіду Хану і Джэйкабу Хайдэру за іх уклад у такенаміку, а таксама многім стрыманым асобам, якія добраахвотна выдаткавалі свой час, каб даць водгук аб змесце гэтага дакумента. - -$\parskip=0pt plus 1pt$ - -# Слоўнік тэрмінаў - -| Тэрмін | Азначэнне | -|------|------------| -| Лісток | Найменшы намінал токена tea. Ліст адпавядае адной стомільённай ($10^{-8}$) tea. | -| Сячэнне | Дзеянне пакарання стыпераў або стэйкераў у адказ на паводзіны, якія супярэчаць правілам сеткі. | -| Стаўка | Дзеянне блакіроўкі токенаў tea для забеспячэння бяспекі сеткі доказу стаўкі, на якой пабудавана сістэма tea. | -| Замочванне | Дзеянне блакіроўкі токенаў tea для падтрымкі вашай прэтэнзіі і атрымання ўзнагарод (або штрафаў) на аснове кансенсусу аб абгрунтаванасці вашай прэтэнзіі. | - - -# Спасылкі diff --git a/i18n/bg/white-paper.md b/i18n/bg/white-paper.md deleted file mode 100644 index cb346ee..0000000 --- a/i18n/bg/white-paper.md +++ /dev/null @@ -1,583 +0,0 @@ -# Декларация за отказ от отговорност - -Цялата информацията, изложена в тази "бялa книга" носи предварителен характер. -Следователно нито авторите, нито който и да е от свързаните с тях лица поемат каквато и да е отговорност относно твърдението, че информацията, изложена в този документ е окончателна или достоверно точна и всеки от изброените лица носи отказ от отговорност, -до максимална степен, която е разрешена от съществуващото законодателство, а също така от всякаква отговорност независимо дали произтича от някакъв вид правонарушение, договор или е свързана с тази "бяла книга" по друг начин. -Нито предложената "бяла книга", нито каквато и да е информация, съдържаща се в нея не може да служи като основание за спор или да бъде използвана за такова или да действа като подканване за сключване на какъвто и да е договор или ангажимент. - -Нищо в тази "бяла книга" не представлява оферта за продажба или подкана към покупка на токени, обсъждани в документацията. -Във всеки случай, ако в някои места тази "бяла книга" ще се разглежда като подобно предложение или подкана, заявяваме, че никакво подобно предложение или подкана са били намерение или цел от настоящата документация във всяка юрисдикция, където това е незаконно, -където подобна оферта или подкана изискват лиценз или регистрация, или където подобна оферта или подкана подлежат на ограничения. -По-специално, всички токени, за които ще става въпрос в документацията не са били, и към датата на издаване на тази "бяла книга" не са предназначени да бъдат регистрирани съгласно законите, касаещи ценни книжа на която и да е юрисдикция, -и дали тази юрисдикция приема или не токени като като вид ценни книжа или подобен инструмент и не може да се предлага или продава в която и да е юрисдикция, където подобни действия представляват нарушение на съответнните закони на тази юрисдикция. - - -# Лиценз - -Изходният код [^src] на даденият документ е достъпен под лиценз на Creative Commons Attribution-ShareAlike 4.0 International[^cc] . - -[^src]: See: @sources -[^cc]: See: @cc - - -# Въведение - -Интернет пространството е съставено предимно от проекти с отворен код и е било такъва от самото му създаване. -С течение на времето, много от тези проекти са се превърнали във фундаментални, върху които са изградени всички последващи иновации. -И докато върху тази технология бяха изградени цели състояния, отворения код основно се създава и поддържа без компенсации. - -Ние смятаме, че цялата съвременна човешка дейност е закърняла поради факта, че разчита основно на малък процент инженери от целия свят, които са принудени да избират между заплата и поддържане на Интернет дейността. -Отвореният код е продукт на грижовен труд, често възпрепятстван от липса на значими икономически стимули, водещи до невъзможност на наистина значими проекти да достигнат своя потенциал, при други проекти възникват проблеми със сигурността поради липса на достатъчно стимули за поддържане на софтуера. -За да се реализира напълно потенциала е необходимо създаване на справедлива система на възнаграждения към цялата екосистема с отворен код, което обаче не променя фундаментално начина, по който тя е изградена или използвана. - -Предприятията често използват бизнес модели свързани с отворения код, генерирайки приходи директно от работата на добросъвестните разработчици, докато разчита на тях за коригиране на грешки при възникване на проблеми. -Чудесен пример е скорошният инцидент, включващ критична уязвимост на сигурността в Log4j, пакет от Apache Software Foundation, който намери своето приложение в много търговски софтуери и услуги, използвани от различни предприятия и от правителството. -През Ноември 2021г, изследовател по сигурността, работещ за Alibaba Group Holding Ltd. съобщава за уязвимост CVE-2021-44228[^1], която получава най-висока възможна оценка от Apache Software Foundation. -Amit Yoran, Главен изпълнителен директор на Tenable и директор основател на United States Computer Emergency Readiness Team (US-CERT), описа този вид уязвимост като “най-голямата и най-критична уязвимост от последното десятилетие”[^2]. -След тези събития последва паника и няколко доброволци, отговорни за поддръжка на въпросния пакет, бяха публично критикувани за провала. -След като в отговор на възникналото възмущение се появи скромна молба за възстановяване на справедливост, системите бяха поправени. -Предприятията и правителствата разбраха в крайна сметка, че Log4j, пакет, използван от голям брой критично важни системи в продължение на две десятилетия, беше поддържан от няколко доброволци за тяхна собствена сметка, това са същите невъзпяти герои, които се впускат в действие въпреки злоупотребите от индустрията[^3] и работят неуморно за справяне с уязвимостта. - -За съжаление Log4j далеч не е единственият пример. -core-js се изтегля 30 милиона пъти седмично като база за всяко Node.js приложение, което също така почти не се финансира. -Наскоро няколко от основните биткойн разработчици подадоха оставка, посочвайки наред с други причини *липса на финансова компенсация* за решението си. - -Отбелязваме многобройни опити за предлагане на различни структури за стимулиране, обикновено включващи системи за спонсорство и различни награди. -Системите за спонсорство дават възможност за потребителите, използващи отворен код да даряват в полза на проекти, които те самите предпочитат. -Въпреки това, представете си отворения код като кула от тухли, където долните слоеве са отдавна забравени, но все още поддържани от отдадени на каузата инженери и където все още се разчита на доста разработчици. -Обикновено само проектите на върха на кулата са известни и получават спонсорство. -Този вид избирателна селекция води до това, че тухлите в основата, които поддържат цялата кула не получават дарения, докато горните предпочитани тухли получават повече, отколкото им е необходимо. -Наградите позволяват на потребителите на проекти възможности за предлагане на плащане на разработчиците за изграждане на специфични функции, като по този начин се предлага възнаграждение за проекти, които извършват дейности, не задължително в техен интерес. -И отново, награждават се само фаворитите. - -В този документ, ви представяме tea — децентрализирана система за справедливо възнаграждение на разработчиците с отворен код въз основа на техния принос към цялата екосистема, въведена чрез алгоритъма за финансово стимулиране, прилаган към всички записи в регистъра на tea. - -![Simplified view of the tea steeping rewards system.](img/figure-1.svg) - -$\parskip=0pt plus 1pt$ - -[^1]: Source: @nist -[^2]: Source: @reuters -[^3]: Source: @twitter - - -# Компоненти - -Всеки разработчик на софтуер, създаващ приложения, се нуждае от четири неща: браузър, терминал, редактор и мениджър на пакети. -От изброените четири неща, мениджърът на пакети е това, което контролира инструментите и основите, необходими на разработчика, за създаването на своя продукт. -Точно това ниво представлява елемента, където виждаме потенциала за промяна на начина, по който се възнаграждава отвореният код. - -## Мениджър на пакети - -В самия мениджър на пакети е заложено да знае от какъв софтуер с отворен код зависи функционирането на дадено приложение, от върха на кулата до основата. -Всеки компонент и версия, които са от съществено значение за приложението, са известни и записани. -Той знае, че върхът на кулата внимателно избира своите зависимости и този прецизен подбор продължава отгоре надолу. -Мениджърът на пакети заема уникално място в стека с инструменти за разработчици, за да позволи автоматизирано и прецизно разпределение на стойности въз основа на действителното им използване в реалния свят. - -Ние предлагаме неизменен децентрализиран регистър, предназначен за разпределяне на стойност въз основа на алгоритъм, определящ приноса на всеки запис към полезността и здравето на системата. -Стойността може да стане част от графиката във връхните точки – приложения и основни библиотеки – и да бъде разпределена към зависимостите на тези връхни точки рекурсивно, тъй като регистърът познава цялата графика с отворен код. - -Също така смятаме, че съществена информация трябва да бъде достъпна чрез мениджъра на пакети, за да могат разработчиците да направят преценка дали да се доверят на избрания пакет и неговия автор. -Дадена информация може да се основава на репутация, позитивни отзиви откъм общността, данни, извлечени от системи за децентрализирана самоличност (DID[^4]), други мениджъри на пакети или механизми за финансово стимулиране, които потенциално разчитат на участници в мрежата, излагащи на риск икономическата стойност. - -Предвиждаме, че комбинацията от инструменти, информация и награди на tea справедливо ще стимулират разработчиците, помагайки за стимулиране на развитието на софтуера с отворен код и насърчавайки иновациите. - -[^4]: See: @w3 - -## Децентрализираният регистър - -Всеки един от мениджърите на пакети има свой собствен регистър на пакети, който дублира едни и същи метаданни многократно. -Дойде време за създаване на единен, пълен и окончателен регистър, проектиран и управляван от общностите, които зависят от него. -Такъв тип децентрализиран, постоянен регистър може да осигури сигурност, стабилност и да предотврати -злонамерени намерения. - -Интернет работи с десетки хиляди жизненоважни компоненти с отворен код. -Интересен факт е, че досега инцидентите, причинени от премахването на основна инфраструктура с отворен код, са минимални. -Най-известниятият пример беше премахването на зависимостта на NPM left-pad[^5] през 2016 г., която каскадно оказа влияние върху системите за непрекъсната интеграция и непрекъснато внедряване, оставяйки разработчиците без финансиране в продължение на дни. -Това събитие показа, че самият интернет е основан върху крехки системи за разработка. -Другите примери включват активно или умишлено участие от поддържащите пакети, саботиращи техните популярни пакети (вижте colors.js, faker.js[^6], и node-ipc[^7]), -или лоши участници, които искат да спечелят, като се преструват, че помагат в поддръжката на пакети и ги повреждат за да крадат, например, Bitcoin частни ключове (Вижте event-stream[^8]), -или злонамерени пакети с умишлени правописни грешки, известни също като typosquatting, -чиято цел е да подмамят потребителите за да инсталират, например пакети crossenv vs. cross-env NPM [^npmjsCrossenv]. - -Целостта на софтуера трябва да бъде гарантирана, докато цялата индустрията напредва към бъдещето, в което цифровите активи ще са част от самия софтуер. -Ние не можем да позволим да се оставяме уязвими към злонамерените участници, модифициращи софтуера. - -Повечето инструменти, които наричаме мениджъри на пакети, не могат да гарантират, че тези пакети, вградени в приложенията и dApps, представляват непроменен код с отворен код, публикуван от оригиналните им автори. -В GitHub на Microsoft се установи, че 17% от уязвимостите в софтуерните програми са създадени със злонамерени цели[^9], като някои от тях остават неоткрити за дълъг период от време (See Webmin 1.890[^10]). - -Децентрализираният регистър, подкрепен от система за репутация и от икономическите стимули, създадени да разкриват лошите участници и да възнаграждават добрите участници, може да предостави необходимите гаранциите, които общностите на разработчиците толкова търсят. - -[^5]: Source: @theregister -[^6]: Source: @fossa -[^7]: Source: @lunasec -[^8]: Source: @github -[^npmjsCrossenv]: Source: @npmjsCrossenv -[^9]: Source: @zdnet -[^10]: Source: @threatpost - - -## Система за съхранение - -Пакетите с отворен код предоставят широк набор от функции, някои от които може да са ограничени или нежелани. -Шифроването е отличен пример за това. -Важен случай за използване на криптирането е поддържането на поверителността на хората по целия свят. -Шифроването също така може да се използва и за нечестни цели (вижте Phantom Secure, демонтиран от правоприлагащите органи през март 2018[^11]) или може да бъде компрометирано, за да се подкрепят дейностите на правоприлагащите органи (Вижте Операция Ironside (AFP), Операция Greenlight (Europol), -и Операция Trojan Shield (FBI)[^12], където ФБР управляват „криптирана“ комуникационна платформа, AN0M, и убеждават престъпниците да използват своите „криптирани“ телефони за сигурна комуникация). - -Голямото приложение на криптирането го превърна в идеален случай за използване на софтуер с отворен код и чудесен пример, че всяко решение, с което имаме възможност за съхранение на пакети, трябва да бъде защитено от подправяне и цензура. -tea е децентрализиран протокол, който не е предназначен за филтриране или санкциониране на пакети въз основа на тяхната функционалност. -Докато управлението на tea може да избере да премахне доказано злонамерени пакети (вижте раздела за управление за повече информация), за системата tea е от решаващо значение да се свърже с множество системи за съхранение, включително децентрализирани, които показват, че пакетът е непроменен и правилно репликиран. -Поддържащите пакети могат да изберат системата за съхранение, която е най-подходяща за техните нужди за сигурно съхранение и разпространение на своите пакети. - -[^11]: Source: @fbi -[^12]: Source: @europol - -# Участници в мрежата - -Мисията на проекта tea е да даде по-голяма възможност на общностите с отворен код и да гарантира подкрепа за техните сътрудници, създаващи инструментите за изграждане на интернет. -В настоящата "бяла книга" ние ще разпределим участниците съответно техния принос. -Някои може да допринесат чрез създаване на код или да способстват за потвърждаване на вече създаден такъв. -Други могат да предоставят икономическа стойност в подкрепа на разработчиците и тяхната репутация. - -## Специалисти, поддържащи пакетите - -Разработчиците на пакети трябва да се уверени, че техният софтуер продължава осигуряване на нарастващите изисквания в крак с развитието на индустрията. - -tea предполага, че създателите на пакети постоянно следят и поддържат тяхната работа. -Разработчиците на пакети представляват основа на общностите с отворен код, които трябва да бъдат овластени и възнаградени за техния постоянен принос. -Създателят на пакет може да реши да прекрати своите усилия по поддръжка или да разбере, че темпа, с който от него се очаква да работи, не отговаря на очакванията от потребителите на пакета. -Създателите на пакети получават незаменими токени (NFT), когато завършат изпращане на пакета (вижте раздела NFT на създателите за допълнителни подробности). -Самият NFT се използва кето доказване на резултат от тяхната работа и е ключът, който определя наградите на tea. -Притежателите на NFT пакети имат възможност да прехвърлят собствеността си на друг разработчик (или група разработчици), което по този начин ги прави поддържащи пакета и получатели на всякакви бъдещи награди. -Също така, разработчикът може да реши да поеме ролята на поддържащ пакета, чрез форк на съществуващия пакет и изпрати нов, който ще поддържа занапред, като по този начин сам стане създател и поддържащ пакета. - -Важно е да предоставим на общностите от разработчици правилните инструменти, за да се определят кои пакети се поддържат, а също така репутацията и качеството на поддръжката на техните разработчици, предишни или настоящи. -Честа практика е работата на специалистите с отворен код да се подправя и усилията на мнозина да се съсипват от недобросъвестни участници. -Въпреки че дейността на тези недобросъвестни участници е до голяма степен разкрита и коригирана, наблюдаваме чести случаи тяхната дейност да остане неразкрита, докато не бъдат нанесени значителни щети поради финансова загуба или загуба на данни. -Да вземем за пример пакет EventStream npm[^13], който беше изтеглен над 1.5 милиони пъти седмично и използва над 1,500 пакета, когато хакер успя да проникне в проекта с отворен код, -да спечели доверието на първоначалния разработчик и да модифицира EventStream по начин, по който той да стане зависим от злонамерен пакет, предаващ идентификационните данни на биткойн портфейла към сървър от трета страна\. -Въпреки че инструментите могат да помогнат за откриването на някои от тези атаки, на тях не винаги може да се разчита, което създава една цяла общност, зависима от усърдието и желанието на всички участници да споделят своите открития. - -Ние предлагаме въвеждане на стимули чрез tea токен, описан в секцията "tea токен", като насърчаваме общностите с отворен код да докладват своите констатации конструктивно и навреме, така че поддържащите пакетите специалисти да могат да се справят с тях, преди да бъдат експлоатирани. - -[^13]: Source: @medium - -## Участници, използващи пакети - -Участниците, използващи пакетите са софтуерни разработчици, фокусирани върху решаването на специфични проблеми. -Те често търсят в общността с отворен код инструментите, от които се нуждаят, за да ги използват за бързо експериментиране без големи финанансови плащания, като се възползват директно от работата на създателите и на тези, поддържащите пакети. -Обикновено, една част от групата може да е избрала да подкрепи поддържащите пакетите чрез дарения или други форми на възнаграждение; това обаче рядко се случва. - -Спонсорството може да представлява ефективна система за подпомагане на разработките с отворен код; обаче, възнаграждението обикновено не обхваща всички зависимости. -Това ограничение е изгодно на фаворитите и пречи на иновациите и изграждането на софтуера. -За да се превърне в основа на софтуерни разработки, отвореният код трябва да дава възможност на всички разработчици, независимо дали са начинаещи или експерти, във всички слоеве на кулата. - -Целта на tea е да поддържа основните ценности на софтуера с отворен код, като същевременно предоставя децентрализирана система за възнаграждение на участниците, поддържащи пакети за тяхната работа. -За да изпълни тази мисия, tea възнамерява да разработи — и да стимулира другите да разработват — механизми, позволяващи на потребителите на пакети, да подкрепят участниците поддържащи пакети чрез използване на токена tea, както е описано в разделa "tea токен" и в секциите за бъдеща работа и потенциални усилия на общността. - -## Поддръжници и спонсори на пакета - -В Web 2.0 и web3, поддръжниците на пакета често са наричани „спонсори“. Те представляват организации или потребители на пакети, които използват софтуери с отворен код, за да създават свои търговски продукти, филантропи, подкрепящи екосистемата, или предприемачи, с намерение за финансиране на екипи за разработка на компоненти от по-голяма система. - -tea предлага разширяване на общностите от поддръжници на пакети към цялата tea общност, независимо дали са организации, разработчици, потребители или технологични ентусиасти. -Целта нa проекта tea е прилагане на децентрализирани механизми за стимулиране чрез уникални случаи на използване на tea токенa за всеки член от tea общността, за допринaсяне на постоянната устойчивост и непрекъснат растеж на екосистемата с отворен код. -Поддръжниците и спонсорите на пакети сами са свободни да решават кои пакети или участници поддържащи пакети искат да подкрепят въз основа на тяхната работа, убеждения или други критерии и показатели, които биха повлияли на тяхното решение. -Освен това поддръжката, осигурена от участниците подкрепящи пакетите и спонсорите на пакети, ще се простира към зависимостите на всеки пакет, като по този начин неявно се доверява на поддържащият пакета да направи добър избор относно стека и да използва тази информация, за да допринесе за тяхната репутация. - -При условие, че поддържащият пакет предлага такава услуга, поддръжникът и спонсорът на пакета могат да получат в замяна първокласно ниво на NFT поддръжка, като по този начин се възползват от ускорени SLA или по-гъвкаво лицензиране. -Освен това поддръжниците и спонсорите на пакети могат да решат да подкрепят пакети или разработчици на пакети и автоматично да пренасочат всички или процент от своите награди, за да стимулират екипите да създават нов софтуер с отворен код. -С други думи, не е необходимо да съществуват пакети, за стартиране на tea процеса. -Проектите в начален стадий могат да бъдат подкрепяни също толкова добре, колкото и тези, които съществуват отдавна, което допълнително стимулира непрекъснато развиващата се екосистема с отворен код. - -## tea дегустатори - -След като постоянно се издават нови пакети или нови версии на съществуващите пакети, валидността на работата трябва да бъде демонстрирана по доказуем начин. -Тази информация е от решаващо значение за потребителите на пакета, за да вземат решение дали да се доверят или не както на пакета, така и на поддържащите го специалисти. -В случай с tea протокола, тази функция се осигурява от tea дегустаторите. - -tea дегустаторите, обикновено, са опитни софтуерни разработчици, готови да посветят част от времето си за проверка на твърденията, свързани с пакетите (функционалност, сигурност, семантична версия[^14], точност на лиценза, др.) -и залагат както репутацията си, така и финансовите си приходи, за да демонстрират резултатите от своите изследвания и анализи в подкрепа на своите твърдения. -tea дегустаторите получават награди за старанията и усилията си. -В tea, ние наричаме „накисване на вашия чай“ действието на заключване на tea токени, за да поддържате вашите твърдения и да получавате награди (или санкции) въз основа на консенсуса относно валидността на вашите твърдения. - -Подобно на поддръжниците на пакета, tea дегустаторите могат да окажат влияние върху пакета и репутацията на поддържащия пакет; обаче тяхното въздействие е по-значимо, като се вземе предвид тяхната роля при валидирането на сигурността, функционалността и качеството на пакета. -tea дегустаторите също така ще трябва да изградят репутацията си, за да подкрепят твърденията си. -Качеството на тяхната работа и икономическата стойност, която излагат на риск, докато подготвят рецензиите си, съчетани с други външни източници на данни, ще изградят репутацията на всеки tea дегустатор, придавайки повече стойност на работата им. -Вижте раздела "репутация на пакета" за повече подробности относно механизмите, използвани за повлияване на пакета и репутацията на поддържащия пакет. - -[^14]: See: @semver - -# Преглед на протокола - -Дизайнът на протокола за възнаграждение на приноса към системата с отворен код е пълен с предизвикателства. -По подразбиране софтуерът с отворен код е отворен за всички и в резултат на това може да бъде подложен на погрешно пренаписване, присвояване или злонамерено подправяне. -Въпреки това, общността с отворен код постоянно демонстрира готовността си да разкрива добрите участници или недоброжелателни такива. -През изминалите години, усилията, изразходвани за преглед и коментиране на приноса на други разработчици, са били строго доброволни, въпреки това, че тези усилия отнемат много време и може да са решаващи при докладването и защитата на констатациите при откритията. - -Нашата цел е създаване на платформа за разпространение на приложения без доверители, осигурена от репутация и финансови стимули, тъй като вярваме, че адекватните награди за принос към системата с отворен код няма да са успешни без изградена система за репутация, и способността на членовете на общността да съобщават своите констатации и подкрепа (или несъгласие) за определен пакет или работа на разработчик. - -Необходимо е да предоставим на разработчиците инструменти за достъп и принос към изграждането на системата за репутация. -Инструменти, които включват прост визуален и програмируем достъп до версията и репутацията на всички зависимости в техните пакети. -Ясното разбиране на това кои членове от общността подкрепят всеки пакет и колко tea токени те заключват, ще допринесе за репутацията на всеки пакет, точно както доколко поддържащият пакет "накисва" работата си, съобщава колко от тях подкрепят работата си. -Тези комбинирани точки от данни помогат за информиране и създаване на система за репутация за всички членове на общността и с това улесняват избора. -След като хакването на пакета EventStream не е било извършено чрез самия пакет, а чрез една от неговите зависимости, видимостта във всички слоеве на зависимостите е жизненоважна за изграждането на тази надеждна система. -Обаче подобни съображения като изчислителни и транзакционни („газ“) разходи ще трябва да имат приоритет при проектирането и изграждането на системата. - -Нашата цел е честно възнаграждение на разработчиците както на Web 2.0 така и на web3 екосистемите. -Тънкостите и спецификите на всеки стек водят до това, че при проследяването на инсталирани и деинсталирани пакети, те може лесно да се превърнат в жертва на един или повече злонамерени участници. -Това включва „купуване“ на инсталации за изкуствено увеличаване на числата. -Още по-лош сценарий би бил въвеждането на фундаментални промени в природата на софтуера с отворен код чрез създаване на допълнителни затруднения при използване на лицензни ключове или други механизми за проследяване на внедряването. -За да осигурим по-голямо въздействие, ние вярваме, че наградите не трябва да разчитат на опростена представа за проследяване на инсталирани и деинсталирани пакети, а по-скоро на механизми за стимулиране, които насърчават подаването на качествени пакети и докладването на злонамерени или високорискови пакети. -И накрая, много пакети разчитат на общи зависимости. -Например, Lodash има 151,209 зависимости[^15] докато chalk има 78,854 зависимости[^16] или Log4js има 3,343 зависимости[^17]. -След като повече пакети се създават с помощта на едни и същи зависимости, как да гарантираме, че стимулите се разпределят честно и справедливо? -Как да гарантираме, че най-използваните зависимости са възнаградени, но в същото време не са останали без възнаграждение нови или нововъзникващи пакети и разработчици? -Как да гарантираме, че изградената системата за стимули в крайна сметка не отклонява разработчиците от по-специализираните езици, в полза на централизираните, където стимулите са по-добри? -Но също така, като разработчици, как да сме сигурни, че ще идентифицираме пакети с най-големи зависимости, за да изградим алтернативи - по-прости, по-ефективни, по-добре кодирани версии на тези пакети? -В tea вярваме, че липсата на стимули пречи на еволюцията на софтуера с отворен код. -Подкрепени от правилните икономически стимули и награди, повече разработчици ще бъдат в състояние да изградят, подобрят и разширят софтуера с отворен код за подобряването на цялата система. -Само тогава tea токенът ще може да представлява цялата стойност на софтуера с отворен код. - -[^15]: Source: @npmjsLodash -[^16]: Source: @npmjsChalk -[^17]: Source: @npmjsLogFourjs - -## Подаване на пакета - -Представянето на пускането на пакета изисква множество транзакции да се извършват атомарно. -По-конкретно, поддържащият пакета трябва да: - -* Регистрира пакета (и неговата семантична версия) в децентрализираният регистър. -* Качи пакета в децентрализираната система за осигуряване на устойчивост към цензурата и лесното разпространение. -* Допринесе за репутацията и надеждността на пакета чрез *накисване*/заключване на tea токените. - -Неуспехът на която и да е от трите операции ще доведе до връщане на протокола към предишното му състояние, като по този начин ще елиминира всякакви доказателства за подаването. - -След като пакетът бъде изпратен успешно, участник поддържащ пакета ще получи NFT за поддържка, за да докаже своята работа и принос към отвореният код. -Поддържащият пакета може да трансферира наградите за заключване на токени, свързани с получените NFT към трета страна. -Въпреки това, репутацията, свързана със създаването и поддръжката на актива, ще остане при поддържащият пакета, така че неговата репутация може да бъде доказана с течение на времето. -Когато репутацията на който и да е член на tea общността достигне ключови етапи, те получават възможност за достъп към определени по-високи нива от протокола или получават по-бързо награди, както е решено от tea управлението. -За повече подробности относно поддържащите NFT вижте съответния раздел за NFT. - -### Анализ на зависимостите - -Зависимостите на пакетите могат да бъдат дълбоки, тъй като всеки пакет често има както зависими компоненти, така и зависимости. -За да предоставим проста методология, способстваща възнаграждаването на всички разработчици, които допринасят за изграждане на софтуер с отворен код, като същевременно запазват създаването на дървото на зависимостите бързо и изчислително ефективно, ние предлагаме проверяване само на зависимостите от първо ниво при подаването на пакет. - -Дизайнът е ръководен от хипотезата, че всяка зависимост сама по себе си е пакет, който е бил независимо изпратен от tea дървото. -По този начин всяка от неговите зависимости може да бъде картографирана и ако самите нейни зависимости имат зависимости, те ще бъдат картографирани в момента на изпращане на пакета за зависимости. - -![Диаграма за анализ на зависимостите](img/figure-3.svg){#fig:анализ-зависимости} - - -Във @fig:анализ-зависимости, представяне на пакета A пуска задейства анализ на зависимостите по време на изпълнение 1 чрез n и изгражда зависимост 1 чрез n, докато зависимостите по време на изпълнение 1.1 чрез 1.n и изгражда зависимости 1.1 чрез 1.n където са анализирани при при подаването на пакет B. -Ще приложим същата методология за разпределение на стимули, тъй като заключените токени се разпределят във всички зависимости, като по този начин рекурсивно накисваме "пакетите", посочени като зависимости (виж @fig:заключване-награди). - -![Разпределение на наградите между зависимостите.](img/figure-2.svg){#fig:заключване-награди} - - -Версиите и противоречивите зависимости са значителни предизвикателства и отстраняването им може да отнеме много време. -За да решим този проблем, ние предлагаме всеки пакет да бъде подложен на цялостно сканиране на зависимости при изпращане така, че можем да гарантираме, че пакетът отговаря на следните правила за семантика на диапазоните на версиите. - -* Пакетите могат да ограничат своите зависимости само до основна версия, въпреки че началото на диапазона може да представлява всяка валидна семантична версия (e.g., >=5.2.1 <6). -* Ако определена зависимост бъде ъпгрейдната до по-нова основна версия, tea може да изисква увеличаване на основната версия на пакета. -* Подобно, ако дадена зависимост бъде надстроена до по-нова второстепенна версия, tea може да изисква увеличаване на второстепенната версия на пакета. -* При добавяне на нова зависимост, tea може да изисква увеличаване на второстепенната версия на пакета. - -Имайки предвид ненужните усилия, наложени на всеки потребител на пакета, когато горните правила са нарушени, ние предлагаме част от tea токените, "напоени" от поддържащият пакета, да бъде намалени, за да се отрази липсата от полагане на необходимо усърдие. -Ако разработчик принуждава всички да жонглират с чашите си, някой ще разлее малко чай. -Тъй като се очаква сканирането на зависимостите да се извърши при подаване, трябва да отбележим, че няма да се случи "накисване" от поддръжници и спонсори на пакета или tea дегустатори. - -## Пакет и репутация на участника поддържащ пакета - -Тези, които поддържащат пакетите трябва да допринесат за репутацията и надеждността на своя пакет чрез "накисване" на tea токените. -Обаче, системата за репутация, разчитаща единствено на икономическия принос на автора, не осигурява достатъчна защита на потребителите и може да се превърне в обект на Sybil атаки, при които един човек създава множество представяния на себе си, за да остави голям обем положителни отзиви за работата си, -карайки потребителите да повярват, че тяхната работа е прегледана и одобрена от много хора. - -Съществуват няколко методологии за предотвратяване на атаките на Sybil, някои от които са описани от Nitish Balachandran и Sugata Sanyal в “Преглед на техниките за смекчаване на атаките на Sybil”[^18]. -Тъй като tea представлява децентрализиран протокол, използването на система за сертифициране на доверие, която разчита на централизиран орган за издаване на сертификати, би било в противоречие с неговата същност. -Ние предлагаме да се съсредоточим върху децентрализираните подходи за смекчаване на атаките на Sybil и по-конкретно върху методологии, които разчитат на голяма група участници в мрежата, стимулирани да оценяват и представят публично репутацията на всеки пакет и неговия поддържащ. - -Подобно на производството на блокове в proof-of-stake блокчейн, където нодите, които не произвеждат блокове могат да валидират работата на другите и, когато е необходимо, да подчертаят нарушение на правилата в мрежата, което води до санкциониране на лошите участници чрез слашинг (унищожаване на част от техния залог в стейкинг), -ние предлагаме система, чрез която трети страни (известни още като tea дегустатори) имат възможност да преглеждат пакети, произведени от поддържащите пакети, и да бъдат икономически стимулирани да се държат в най-добрия интерес на общността на софтуера с отворен код и неговите потребители, както и да разпознават доброто и наказват недосбросъвестно поведение. -Тази система трябва да бъде едновременно устойчива на Sybil и да не позволява на големите притежатели на токени да влияят съществено върху протокола или репутацията на конкретни пакети. -Сигурни сме, че този подход е в по-голяма степен съобразен с отворения код, осигурявайки по-добър субстрат за насърчаване на приемането и доверието и в крайна сметка улесняващ развитието на tea проекта. - -[^18]: Source: @arxiv - -## Преглед на пакета от трети страни - -Съществен компонент в изграждането на репутацията, е преглед на пакети от трети страни, но такъв вид преглед има свой собствен набор от евентуални уникални заплахи, включително гореспоменатите атаки на Sybil. - -Блокчейн технологията и по-точно стейкинг предлага уникална възможност за tea проекта да се справи с това предизвикателство. -Въпреки че всеки може да си направи и използва толкова адреси на портфейли, колкото си поиска, това не е така с tea токените, чието първоначално предлагане се очаква да бъде 10 милиарда. -Освен това, всяко действие, извършено от разработчиците, като изпращане на пакети, проверка на пакети или "накисването" им, ще допринесе за тяхната репутация, като по този начин създава уникален профил, който всеки разработчик може да използва, за да участва както в tea общността, така и в tea управлението. - -Чрез изискване към рецензентите от трети страни да "заключват" tea токени и поемат риска от загуба на част от техните "заключени" токени, при положение, че ще се докаже, че се държат против интересите на мрежата или са недобросъвестни участници, третите страни могат да осигурят допълнителна достоверност на пакетите си и да получат награда под формата на tea токени. - -Ние също така предлагаме разширяване на системата за репутация към трети страни, които извършват независима проверка на пакетите - tea дегустатори. -За приключване на положителен преглед ще се изискват две операции, които да се появят атомарно: - -* Подаването на преглед на кода, който е подписан от tea дегустатора и публично достъпен за всички членове на общността, заедно с -* Акта на накисване „за“ пакета (срещу „против“ пакета), за да бъде обоснован самия преглед. - -Подаването на отрицателен преглед, който включва наличие на една или повече критични уязвимости, ще изисква от tea дегустаторите първо да се свържат с поддържащият пакета, използвайки протокол за съобщения, за да уведомят за наличието на уязвимост и да им бъде позволено да решат проблема своевременно. -След изтичане на определения от управлението период, определен на участниците поддържащи пакета за справяне с тяхната уязвимост, или когато коригираният пакет стане достъпен, същият протокол за съобщения ще бъде използван за уведомяване на всички потребители и тестери на този пакет (включително зависими лица), че уязвимостта е била идентифицирана, -и се надяваме отстранена, за да знаят, че е необходимо да актуализират своето приложение или зависимости. -За да се демотивира загубата на време от страната на разработчиците, комуникацията между tea дегустаторите и поддържащите пакети ще изисква от tea дегустаторите да "заключват" tea токени. - -След завършване на двете операции tea дегустаторите ще получат NFT като доказателство за тяхната работа върху конкретния пакет и версията на пакета. -Събирането на NFT, съчетано със съотношението на накисване на "всеки" от прегледаните пакети и информацията, извлечена от външни системи, ще повлияе на репутацията на tea дегустатора. -След като репутацията им достига ключови етапи, tea дегустаторите могат да спечелят достъп до по-висши части от протокола или по-бързо да получат награди, както бъде решено от tea управлението. - -## Остарели или повредени пакети - -Mисията на tea е да възнаграждава сътрудниците и участниците в общностите с отворен код; наградите обаче трябва да са съизмерими с усилията, положени от участниците поддържащите пакети и tea дегустаторите. -Недостатъчно поддържаните, остарели или повредени пакети са ясни индикации, че участниците, поддържащите пакети не отговарят на очакванията на общността или не отговарят на доверието и подкрепата, внушени им чрез "накисването" на пакетите. -Друг показател на остарели пакети може да бъде продължаващото използване на остарял език или остаряла версия на език с няколко вресии. -Пакетите, които остават твърде дълго време остарели или повредени, показват, че e необходимо tea дегустаторите редовно и последователно да преглеждат работата на поддържащите пакета. - -tea дегустаторите са важни членове на общностите с отворен код, тъй като техните рецензии и свързани твърдения могат да насочват потребителите на пакети към тях или съответно да ги откажат от пакетите. -За да се гарантира, че на рецензиите може да се вярва на непрекъснат базис, ние предлагаме механизъм, чрез който остарелите или повредени пакети могат да видят част от техните заключени токени, изпратени към tea дегустаторите, които първи разпознават липсата на поддръжка на който и да е пакет. - -Всеки преглед с отрицателен резултат, който подчертава недостатък като уязвимост от типа zero-day или използване на остаряла зависимост и остава отворен след гратисен период, определен от управлението, трябва да се счита за неуспешен от страна на поддържащият пакета. -Той не е изпълнил задачата, която е била поверена и за която е награден. -Същото може да се каже за поддръжниците и спонсорите на пакети, които са заложили репутацията си на работата на участниците, недобросъвестно поддържащи пакетите и са получили награди за това, но не са успели да идентифицират липсата на поддръжка или са избрали да продължат да поддържат пакета независимо от това. - -След като пакетите набират популярност и използване, с повече приложения и потенциално критични системи, зависещи от тях, ние трябва да стимулираме разработчиците да докладват дискретно за недостатъците на поддържащият пакетс и участниците поддържащите пакети да отстранят тези недостатъци, преди да могат да бъдат експлоатирани. -Затова, ние предлагаме за всеки остарял или повреден пакет, който е обект на една или повече доказани рецензии с отрицателен резултат и остава в такова състояние след определения от управлението гратисен период, да се намали част от неговите натрупани токени, независимо от техния произход (поддръжка на пакет, поддръжници и спонсори на пакет или предишни tea дегустатори), -докато друга част се изпраща към tea дегустаторите, които са изпратили отрицателните отзиви след прегледа. -Разпределението към всички tea дегустатори може да бъде базирана върху давността на техния преглед и броя tea токени, които те са "заключили" за да направят своя преглед. - -## Поддържащи NFT - -След успешно подаване на пакет, участника поддържащ пакета ще получи NFT, за да се докаже неговата работа и принос. -Притежателят на този NFT автоматично получава всички награди, свързани с пакета. -Поддържащите пакети имат възможност да прехвърлят собствеността върху поддръжката на пакет към друг поддържащ пакет, като просто прехвърлят NFT към пакета. -Успешното прехвърляне на NFT ще доведе до автоматично получаване на бъдещи пакетни награди към новия собственик. - -Важен момент при изграждането на репутация разчита на честотата и количеството на подаваните качествени пакети. -NFT получени от поддържащите пакети като доказателство за тяхната работа, могат да бъдат използвани от системата за репутация, за да се актуализира репутацията на поддържащия пакет и да им даде достъп до по-високи нива от протокола, както е решено от tea управлението. -Обаче, за предотвратяване на евентуалните вектори на атаки, като например купуване на репутацията на членове от общността, прехвърлянето на поддържащите NFT, те няма да доведат до прехвърляне и на репутация. -Репутацията трябва да остане пряко свързана с работата на конкретен разработчик и не трябва да се прехвърля. - -# Токен tea - -## Защита на мрежата - -Докато голям брой блокчейни може да изглеждат като ефективни и сигурни инфраструктурни решения в подкрепа на целите на tea проекта, ние вярваме, че трябва да се обърне внимание и на технологичния стек, върху който е изградена системата на проекта tea. - -Мащабируемост, рентабилност, ESG и разширяемост от трети страни са важни аспекти при проектиране, които една суверенна proof-of-stake система би могла да обслужва по-добре. -В системата proof-of-stake, операторите на ноди и участниците в мрежата залагат икономическата стойност под формата на основният токен на мрежата, за увеличаване сигурността на системата. -Операторите на ноди и участниците в мрежата получават награди за успешното производство на блокове, които отговарят на правилата на мрежата и включват точна информация за транзакциите. -Неактивност (известна още като спиране на възел или нода) или злонамерена/неправилна дейност се санкционират чрез унищожаване на част от стейкваните токени чрез слашинг. - -Системата proof-of-stake, осигурена от токена tea, ще позволи на притежателите на токена да допринасят за сигурността на системата чрез tea *стейкинг* и да подкрепят разработчиците с отворен код чрез tea *накисване*. -Наясно сме с факта, че икономическите фактори могат да попречат на някои разработчици да стейкват или "накисват" tea токена; съответно процедурите като, стейкинг и "накисване" ще бъдат достъпни за малки стойности или количества като например един лист/leaf, което е най-малката номинална стойност на tea, представляваща една стомилионна ($10^{-8}$) от tea. - -И двете приложения на tea токенa изпълняват жизненоважни функции в подкрепата и растежа на екосистемата с отворен код. -Стейкинг на токена tea ще гарантира, че tea системата ще продължи да работи сигурно, така че всички участници в мрежата да могат да изпращат и имат достъп до пакети, за да ги прегледат, да ги интегрират в своето приложение и т.н. -За разлика от това, "накисването" на tea ще подкрепи целта на tea за предоставяне на инструменти за всички участници в мрежата за поддръжка и използване на пакети, които отговарят на изискванията за качество и надеждност, както e формулиранo от tea общността чрез тяхната подкрепа и несъгласие с всеки пакет. -Ще се внимава при дефинирането и прилагането на параметри за стейкинг и "накисване" така че единият да не влияе отрицателно върху другия. - -## Стимули и наказания - -Както беше обсъдено по-рано, недобросъвестните участници имат добри финансови стимули за да компрометират софтуери с отворен код. -По-голямата част от важната Интернет инфраструктура работи с отворен код и надпреварата за откриване на експлойти и други уязвимости продължава. -В компанията tea, ние вярваме, че не само поддържащите пакети са тези, които трябва да бъдат обвинявани (въпреки че често са). - -Стимулите на протокола tea коригират тази ситуация чрез честно и справедливо разпределение на стимулите. -Пакет като Lodash с над 151 000 зависими компоненти е основен при разработката с отворен код и неговият поддържащ заслужава да бъде възнаграден пропорционално. -Въпреки това, система за възнаграждение, изградена единствено въз основа на броя на зависимостите, ще попречи на иноваторите да разрушат тези монополи, освен ако не са достатъчно финансирани от трети страни или вече са натрупали достатъчно ресурси, за да се самофинансират. -Този подход вероятно ще доведе до намаляване на броя на участниците, което ще доведе до пълна противоположност на идеята, която представлява tea. - -Целта на tea е да предoстави стойността на софтуера с отворен код и по този начин да насърчи растежа му, като предостави на участниците ресурсите, от които се нуждаят, за безпроблемно следване на целта си. -Системата за разпределение на tea стимули внимателно преценя съотношението на "накисване" на всеки пакет и съответно коригира стимулите за него. -За намаляване риска от това, че малък брой пакети, използвани като зависимости в много приложения, събира по-голямата част от наградите, ние ще използваме изследването, извършено от web3 Foundation[^19] за механизъм за възнаграждения, базиран на proof-of-stake механизъм от Polkadot. -Можем допълнително да коригираме изпълнението и неговите променливи въз основа на резултатите от практически експерименти. - -Тъй като процеса на "накисване" на пакета се доближава до дефинирано от управлението оптимално съотношение на накисване, съотношението на възнаграждение за "накисване" ще намалява прогресивно. -Когато даденият пакет превиши оптималното си съотношение на "накисване", съотношението на наградите за "накисване" ще намалее рязко, за да дестимулира поддръжниците на пакета и tea дегустаторите от допълнително "накисване" на вече силно "накиснати" пакети. -Такъв вид дизайн позволява на по-слабо напоените пакети да станат по-привлекателни както за привържениците на пакета, така и за tea дегустаторите. -Тази процедура може да стимулира опитните разработчици за създаване на алтернативи на силно "накиснатите" пакети, създавайки възможност за tea общността да балансира поддържането на съществуващ софтуер и насърчаването на иновациите. -Коефициентът на "накисване" ще бъде изчислен, чрез използване на циркулационното захранване в първоначалния му проект. -tea общността може да промени този дизайн, за да подобри допълнително мащабируемостта на системата. -Нека $\chi$ да представлява коефициент на "накисване" във всички пакети. -Той представлява общия брой tea токени, "напоени" от участниците, поддържащи пакети, от потребителите на пакети, поддръжниците и спонсори на пакети и tea дегустаторите, разделен на общото предлагане на teа токени. -Имайки предвид колко пакети с отворен код са налични днес и очакваният им растеж, $\chi$ винаги ще бъде много малка стойност между $0$ и $1$. - -Нека $\psi$ да е съотношението при стейкинг. -Той представлява общия брой tea токени, в стейкинг от всеки участник в мрежата за защита на самата мрежата. - -Нека $\chi_{ideal}$ да бъде коефициентът на "накисване", който бихме искали всеки пакет да постигне за справедливо разпределение на наградите във всички пакети и техните зависимости. -Стойността $\chi_{ideal}$ трябва да се актуализира при добавяне на нови пакети към децентрализирания регистър и създаване на зависимости. -За да определим най-добрата стойност за $\chi_{ideal}$, ще използваме камбанна крива на популярността, актуализирана в началото на всеки цикъл на възнаграждение. - -Нека $\tau = \tau(\chi)$ представлява годишният лихвен процент за "накисване", разпределен към всички членове на tea общността, които заключват tea токените в подкрепа на разработчиците с отворен код. -С други думи, $\tau(\chi)$ съответства на наградата за "накисване", получавана в рамките на една година от член на общността, който е "накисвал" tea токени през цялата година. - -Нека $\gamma = \gamma(\psi)$ представлява годишнен лихвен процент при стейкинг, разпределен на всички оператори на възли и участници в мрежата, които стейкват tea токени, осигурявайки сигурността на мрежата. -С други думи, $\gamma(\psi)$ съответства на стейкинг наградата, получена за една година от член на общността, който стейква tea токени през цялата година. - -Нека $\delta$ е годишна инфлация, насочена към хазната на мрежата. -$\delta$ може да варира, тъй като различни външни фактори влияят на токен съплая. - -Ние разглеждаме годишната ставка на възнаграждение за накисване като функция на $\chi$ и годишната ставка на възнаграждение за стейкинг като функция на $\psi$. - -* $\tau(\chi)$ съответства на стимул за хората да "накиснат" пакети. -Тъй като $\chi$ се увеличава, са необходими по-малко награди $\tau(\chi)$ . -* $\gamma(\psi)$ съответства на стимул за хората за да използват стейкинг в мрежата. -С нарастването на $\psi$ са необходими по-малко награди $\gamma(\psi)$ за сигурността на мрежата. - -Годишната инфлация $I$ ще бъде еквивалентна на $(\tau + \gamma + \delta)$ и се изчислява, както следва: - -$$ -I = \frac{\textrm{токен съплай към края на годината} - \textrm{токен съплай в началото на годината}}{\textrm{токен съплай в началото на годината}} = (\tau + \gamma + \delta) -$$ - -Приносът към инфлацията на $\tau_{{all}}$ (награди, разпределени на всички пакети, които се "накисват") и $\gamma_{{all}}$ (награди, разпределени между всички участници в сигурността на мрежата) трябва да се претегли, за да се гарантира, че системата стимулира оптималното съотношение на "накисване"/стейкинг. - -Тъй като се фокусираме върху стимулите, разпределени между всички пакети, ние определяме следното -$\tau_{{all}}$ -е функция на съотношението на накисване $\chi$ и следователно -$\tau_{{all}}(\chi) = \chi \cdot \tau(\chi)$. -От предишния ни анализ можем да видим това -$\tau_{{all}}(\chi_{ideal}) = \chi_{ideal} \cdot \tau_{ideal}$. -Тъй като целта е да се достигне състояние, в което -$\chi = \chi_{ideal}$ -, наградите -$\tau_{ideal}(\chi)$ -трябва да са максимални при тази стойност. - -Нека $\tau_{ideal} = \tau(\chi_{ideal})$ -бъде процентът на възнаграждение, предоставен от мрежата при идеалния сценарий, където -$\chi = \chi_{ideal}$. - -Нека $\tau_{0}$ представлява лимит $\tau_{{all}}(\chi)$ като $\chi$ отива до нула, когато никой от членовете на tea общността не "накисва" никакви пакети. -Стойността на $\tau_{0}$ трябва да бъде близо до нула, но не и нула, за да стимулира ранните участници и последователи. -Както беше предложено от изследването на фондация web3, ние предлагаме, че: - -* функцията на инфлацията нараства линейно между $\chi = 0$ and $\chi = \chi_{ideal}$, и -* тя се разпада експоненциално между $\chi = \chi_{ideal}$ и $\chi = 1$. - -Избрахме подобно експоненциално намаление за $\tau_{{all}}(\chi)$ защото предполага експоненциално намаляване на $\tau(\chi)$, и искаме наградите да паднат рязко под $\chi_{ideal}$ за да предотвратим получаването на всички награди от един пакет. - -Намаляването се определя така, че темпът на инфлация намалява с най-много 50%, когато $\chi$ променя $d$ единици вдясно от $\chi_{ideal}$ – например. -$\tau_{{all}}(\chi_{ideal} + d) \geq \tau_{{all}} \cdot 0.5$. - -Ние предлагаме следните функции на лихвения процент и инфлация, които зависят от параметрите $\chi_{ideal}$, $\tau_{ideal}$, $\tau_{0}$ and $d$. - - -$\tau_{{all}}(\chi)$ = $\tau_{0}$ + $(\tau_{{all}}(\chi_{ideal})$ - $\tau_{0})$ $\frac{\chi}{\chi_{ideal}}\enspace\textrm{for}$\ 0 < $\chi \leq \chi_{ideal}$ \ -$\tau_{{all}}(\chi)$ = $\tau_{0}$ + $(\tau_{{all}}(\chi_{ideal})$ - $\tau_{0})$ $\cdot 2^{(\chi_{ideal}-\chi)/d}\enspace\textrm{for}$ $\chi_{ideal}$ < $\chi \leq 1 \$ - - -Точно както съвестните участници трябва да бъдат възнаградени; недобросъвестните такива трябва да бъдат идентифицирани и наказани. -Софтуерът с отворен код предоставя много възможности за недобросъвестните участници да създават критични моменти и репутационни рискове за цялата общност от разработчици. -От злоупотребата с работния процес до промяната и преразпределението на софтуерни пакети или внедряването на престъпен код, войната между добрите и лошите участници продължава, често с добре финансирани недобросъвестни участници, които виждат възможност да навредят на пакетите с отворен код за да се облагодетелстват финансово. -Обратното въздействие е сравнително минимално, като пакетите потенциално са забранени от дигиталните рафтове или са подложени на лоша репутация. - -Ние предлагаме да се въведе слашинг механизъм, за да се установят по-съществени недостатъци, който пряко засягат финансовото стимулиране на недобросъвестните участници. -Тъй като tea дегустаторите оценяват и анализират кода в новоподадените пакети, ние предлагаме на tea дегустаторите да получават необходими инструменти и стимули за определяне и подчертаване на злонамерен код, така че потребителите на пакети да могат да бъдат информирани за рисковете, а участните, поддържащи пакети, поддръжниците на пакети и спонсорите да бъдат санкционирани за изпращане или поддържане на злонамерен код. -В тази връзка, за всички доказани прегледи с отрицателен резултат, извършени съгласно правилата на мрежата, които са били разгледани и премахнати от поддържащия пакета в рамките на определения от управлението период, поддържащият пакета не трябва да понася никакви санкции в противоречие с поддръжниците и спонсорите на пакета или tea дегустаторите, които дават положителен преглед на въпросния пакет. -За отрицателни прегледи, извършени съгласно правилата на мрежата и които поддържащият пакета не е разгледал в рамките на определения от управлението период, част от токените, "напоени" от участника поддържащия пакет, поддръжниците и спонсорите на пакета и предишните tea дегустатори ще бъдат намалени. -Другата част ще бъде заключена в застрахователен пул, контролиран от управлението на tea проекта. -Управлението на tea проекта ще установи необходимите политики и правила в тясно сътрудничество с общността за разпространение на съдържанието на пула към тези засегнатите от уязвимости. -Протоколът ще разпредели една трета част от "напоените" токени между всички tea дегустатори, допринесли за прегледа с отрицателен резултат, токени, които те са "накиснали" срещу пакета, въз основа на броя tea токени които са заключили „срещу“ пакета, и колко време са били "накисвани". -С други думи, колкото по-скоро един или повече tea дегустатори идентифицират и докладват за недостатъците според правилата на мрежата, толкова по-висока награда ще получат за поддържане на безопасна и продуктивна разработка с отворен код. - -За да попречат на членовете на общността да гласуват на случаен принцип „против“ силно "напоени" пакети, надявайки се да получат по-голямата част от гласовете, всички tea токени, "напоени" „против“, няма да бъдат засегнати от инфлация и може да бъдат обект на механизъм на разпадане, като по този начин намаляват стойността си с течение на времето . - -[^19]: Source: @web3 - - -# Управление - -Управлението е от решаващо значение за развитието, устойчивостта и приемането на всяка разпределена система. - -Ние предлагаме tea да включва управление във веригата, където всички притежатели на tea токени да могат да предлагат и гласуват за промени в критични параметри, претеглени в съответствие със собствеността върху токените и репутацията. -Тези параметри могат да включват инфлация, транзакционни такси, стейкинг награди, награди за "накисване" или оптимално съотношение при накисване. -Тази функционалност ще гарантира, че критичните параметри могат да се развиват и оптимизират с течение на времето от членовете на tea общността. -Очакваме управлението да стартира с проста структура и прогресивно да се разширява с развитието на tea системата, улеснявайки приемането и осигурявайки прогресивна децентрализация. - -Някои системни параметри може да не са обект на управление или да поддържат високочестотни промени за намаляване на повърхността от атака, представена от управлението. -Постепенният преход на параметрите към отворено, децентрализирано управление ще осигури стабилност и предвидимост на системата. - - -# Разширяемост от трети страни - -Докато изграждаме първоначалните инструменти, за насърчаване на дългоочакваната подкрепа на общностите с отворен код, ние вярваме, че част от нашата мисия е да гарантираме, че трети страни могат да разширят цялостния набор от инструменти. -В допълнение към предоставянето на инфраструктура за разработчиците за изграждане на разширения към протокола, включително нови начини за иновации и по-нататъшна поддръжка на разработчици с отворен код, нашите планове включват възможности и за други мениджъри на пакети да допринесат за протокола. -Мечтите и усилията на разработчиците с отворен код изградиха иновациита, която поддържат ежедневието ни. -Очакваме с нетърпение да открием новите начини за употреба и разширения за tea, предложени от нашата общност. - - -# Бъдеща работа и потенциални усилия на общността - -С развитието на tea системата ние предвиждаме, че tea общността ще взима решения и допринася за промените и разширенията на tea системата чрез управление. -По-долу ви представяме някои идеи, които вярваме, че могат да вдъхновят някои от вас. - -## tea Търговци на едро - -Софтуерните общности с отворен код са динамични и постоянно се стремят към иновации и полезни дейности. -Тази всеотдайност и алтруизъм водят до постоянното изграждане на нови софтуери и пакети, всеки от които води със себе си до зависимости. -Като резултат от това, очакваме постоянно развитие на картата на зависимостите, което ще доведе до чести промени в съотношението на "накисване" и наградите. -В бъдеще tea общността може да предложи разработването на система, проектирана да наблюдава динамичното съотношението на "накисване" за всеки пакет и да балансира отново начина, по който поддръжниците на пакета "накисват" своите токени въз основа на собствените си критерии. - -## Роялти за прехвърляне на пакет - -Ние осъзнаваме, че поддържащите пакети може да решат да прехвърлят своята част от възнаграждения на един или повече разработчици. -Управлението на такова прехвърляне трябва да остане решение на участниците, поддържащи пакета и техните партньори, без намеса от страна на tea проекта. -Необходимо е да бъдат осигурени инструменти, за да се осъществи подобно прехвърляне пълно или частично (може би чрез насочване на само част от наградите за "накисване" към един или повече разработчици, докато останалите награди продължават да се насочват към оригиналния поддържащ пакет) -за да има възможност по-големите награди да преминават през един акаунт, контролиран от един участник в мрежата, множество участници в мрежата или автоматично разпределени между множество акаунти, използвайки статични или динамични съотношения. - -## Разпределение на награди между няколко поддържащи участници - -Поддръжката на един пакет може да разчита и на работата на още един екип от разработчици. -Преди започване на получаване на награди за "накисване", екипите трябва да обмислят начините за автоматизиране на разпределение на наградите за "накисване" помежду си. -Начинът на извършване на разпределението трябва да бъде решен от самите поддържащи, тъй като те са в най-добра позиция да оценят кой е допринесъл и как трябва да бъде възнаграден. - -За да се постигне това, всеки екип (или екипи) имат право да създадат своя собствена децентрализирана автономна организация (DAO) или да автоматизират разпределението на наградите, или да внедрят по-сложни системи за определяне на адекватното разпределение на наградите въз основа на външни фактори, като например гласуване от всички DAO членове, -или разпределения, базирани на времеви условия, на непрекъснат принос, успешно завършване на баунти програми и т.н. - -## Пакети за обработка “Forks” - -Вярваме, че forks/ форковете са от съществено значение и до голяма степен не се използват достатъчно. -Форковете могат да бъдат ефективен инструмент за разработване на пакети, които се конкурират във функционалност, производителност, сигурност и дори внимание. -Колкото и полезни да са, форковете трябва да разпознават първоначалните усилия. -Чрез бъдеща работа или потенциални приноси, tea общността може да подобри системата, за да изисква форковете да бъдат декларирани, може би дори открити при подаване на пакет. -Недекларираните форкове, разкрити от tea дегустаторите, може да доведат до нарязване на част от "напоените" токени, прехвърляни към оригиналния участник поддържащ пакет и изпратени към tea дегустаторите, открили съответния форк. - -## Рънтайм vs. Изграждане на зависимости - -tea може да не разграничи зависимостите на изграждане от зависимостите по време на изпълнение при разпределяне на наградите по време на стартиране. -Въпреки това, при условие че tea общността е твърдо решена да направи такова разграничение, тази общност може да предложи подобрения на алгоритъма за разпределение на наградите, за да отчете критичността на всяка зависимост и нейния принос към стойността на пакетите, които зависят от това. -Тези предложения ще бъдат гласувани и изпълнени въз основа на решението на общността. - -## Възнаграждение въз основа на използването - -Тъй като повече приложения се създават с помощта на пакети, регистрирани с tea, общността може да разшири и допълни алгоритъма за възнаграждение, така че разпределението да бъде повлияно от външни удостоверени данни, такива например като употреба. -Тази актуализация на механизма за възнаграждения може да позволи по-голямо разпределение на наградите от tea токени, които да се насочат към пакети с най-голяма употреба, като същевременно се спазват ограниченията на съотношението на "накисване", описано в раздела tea токени. -Поддържащите пакети биха могли да използват подобен подход, за да разпределят награди за "накисване" между своите зависимости въз основа на прозрачната логика по тяхна преценка. -Имайте предвид, че цялата информация, използвана, за да се повлияе на разпределението на наградите между пакетите и зависимостите в tea системата, ще трябва да бъде доказуемо надеждна. - - -# Благодарности - -Тази "бяла книга" не би съществувала без подкрепата и отдадеността на много участници, харесващи tea. -Авторите биха искали да благодарят на Джош Крюгер, Джадид Хан и Джейкъб Хайдер за приноса им към токеномиката и на многото други незабележими лица, които доброволно отделиха времето си, за да предоставят обратна връзка относно съдържанието на този документ. - -$\parskip=0pt plus 1pt$ - -# Речник на термините - -| Наименование |Определение | -|------|------------| -| Лист | Най-малката номинация на tea токена. Едно листо съответства на една стомилионна ($10^{-8}$) tea токена. | -| Слашинг | Действие за наказване на участници в "накисване" или стейкинг в отговор на поведение, което противоречи на правилата на мрежата. | -| Стейкинг | Действие за заключване на tea токени за защита на proof-of-stake мрежата, върху която е изградена tea системата. | -| Накисване | Действието за заключване на tea токени в подкрепа на вашата претенция и получаване на награди (или санкции) въз основа на консенсуса относно валидността на вашата претенция. | - - -# Препратки diff --git a/i18n/de/white-paper.md b/i18n/de/white-paper.md deleted file mode 100644 index 47e3cc8..0000000 --- a/i18n/de/white-paper.md +++ /dev/null @@ -1,581 +0,0 @@ -# Haftungsausschluss - -Die in diesem White Paper enthaltenen Informationen sind vorläufiger Natur. -Daher übernehmen weder die Autoren noch ihre jeweiligen Partner die Verantwortung dafür, dass die hierin enthaltenen Informationen endgültig oder korrekt sind, und jeder der Vorgenannten lehnt ab, -im größtmöglichen Umfang, den das geltende Recht zulässt, jegliche Haftung aus unerlaubter Handlung, Vertrag oder anderweitig in Bezug auf dieses White Paper. -Weder dieses White Paper noch irgendetwas in diesem White Paper darf als Grundlage für einen Vertrag oder eine Verpflichtung dienen oder als Anreiz zum Abschluss eines Vertrags oder einer Verpflichtung, gleich welcher Art. - -Nichts in diesem White Paper stellt ein Angebot zum Verkauf oder eine Aufforderung zum Kauf der hier besprochenen Token dar. -Sollte dieses White Paper als ein solches Angebot oder eine solche Aufforderung angesehen werden, so ist ein solches Angebot oder eine solche Aufforderung in keiner Jurisdiktion, in der dies ungesetzlich ist, beabsichtigt oder wird durch dieses White Paper vermittelt, -wo ein solches Angebot oder eine solche Aufforderung eine Lizenz oder Registrierung erfordern würde oder wo ein solches Angebot oder eine solche Aufforderung Einschränkungen unterliegt. -Insbesondere sind die hierin besprochenen Token nicht gemäß den Wertpapiergesetzen oder ähnlichen Gesetzen einer Rechtsordnung registriert worden, und es ist zum Zeitpunkt der Veröffentlichung dieses Whitepapers auch nicht beabsichtigt, sie zu registrieren, -unabhängig davon, ob eine solche Rechtsordnung die Token als Wertpapier oder ähnliches Instrument betrachtet oder nicht, und sie dürfen nicht in einer Rechtsordnung angeboten oder verkauft werden, in der dies einen Verstoß gegen die entsprechenden Gesetze dieser Rechtsordnung darstellen würde. - - -# Lizenz - -Der Quellcode[^src] dieses Artikels ist verfügbar unter der Creative Commons Attribution-ShareAlike 4.0 International[^cc] Lizenz. - -[^src]: See: @sources -[^cc]: See: @cc - - -# Einführung - -Das Internet besteht überwiegend aus Open-Source-Projekten, und das schon seit seinen Anfängen. -Im Laufe der Zeit haben sich viele dieser Projekte zu Grundpfeilern entwickelt, auf denen alle zukünftigen Innovationen aufgebaut sind. -Und obwohl damit ein Vermögen gemacht wurde, wird Open-Source hauptsächlich ohne Vergütung erstellt und gepflegt. - -Wir sind der Meinung, dass das gesamte moderne menschliche Streben dadurch behindert wird, dass sich der kleinste Prozentsatz der Ingenieure der Welt zwischen einem Gehalt und der Aufrechterhaltung des Internets entscheiden muss. -Open-Source ist ein Werk der Liebe, das oft durch das Fehlen sinnvoller wirtschaftlicher Anreize behindert wird. Das führt dazu, dass wirklich lohnenswerte Projekte nie ihr Potenzial erreichen, während andere unter Sicherheitsproblemen leiden, weil es keine Anreize gibt, die Software während ihres gesamten Lebenszyklus zu pflegen. -Um unser Potenzial voll auszuschöpfen, brauchen wir ein faires Vergütungssystem für das Open-Source-Ökosystem, das die Art und Weise, wie es aufgebaut oder genutzt wird, nicht grundlegend verändert. - -Unternehmen bauen oft Geschäftsmodelle um Open Source herum auf, um direkt von der Arbeit der wohlwollenden Entwickler zu profitieren und sich gleichzeitig darauf zu verlassen, dass sie Fehler beheben, wenn Probleme auftreten. -Ein gutes Beispiel dafür ist der jüngste Vorfall im Zusammenhang mit einer kritischen Sicherheitslücke in Log4j, einem Paket der Apache Software Foundation, das seinen Weg in viele kommerzielle Software und Dienste gefunden hat, die von Unternehmen und Regierungen genutzt werden. -Im November 2021 meldete ein Sicherheitsforscher, der für die Alibaba Group Holding Ltd. arbeitet, die Sicherheitslücke CVE-2021-44228[^1], die von der Apache Software Foundation die höchstmögliche Basisbewertung erhielt. -Amit Yoran, Chief Executive von Tenable und Gründungsdirektor des United States Computer Emergency Readiness Team (US-CERT), bezeichnete diese Sicherheitslücke als "die größte und kritischste Sicherheitslücke des letzten Jahrzehnts"[^2]. -Panik brach aus und die wenigen Freiwilligen, die dieses Paket betreuten, gerieten wegen des Versagens öffentlich unter Beschuss. -Nachdem sie die Empörung mit einem bescheidenen Plädoyer für Fairness angesprochen hatten, wurden die Systeme gepatcht. -Unternehmen und Regierungen erkannten schließlich, dass Log4j, ein Paket, das zwei Jahrzehnte lang von einer Vielzahl kritischer Systeme verwendet wurde, von einigen wenigen unbezahlten Freiwilligen gewartet wurde, denselben unbesungenen Helden, die trotz der Beschimpfungen durch die Industrie[^3] in Aktion traten und unermüdlich an der Behebung der Sicherheitslücke arbeiteten. - -Leider ist Log4j bei weitem nicht das einzige Beispiel. -core-js wird als Basis jeder Node.js-Anwendung 30 Millionen Mal pro Woche heruntergeladen, wird aber ebenfalls kaum finanziert. -Kürzlich haben mehrere Bitcoin-Core-Entwickler gekündigt und dies unter anderem mit dem *Mangel an finanzieller Entschädigung* begründet. - -Es gab mehrere Versuche, Anreizstrukturen zu schaffen, typischerweise in Form von Sponsoring und Bounty-Systemen. -Sponsoring ermöglicht es den Nutzern von Open-Source, für die von ihnen bevorzugten Projekte zu spenden. -Stellen Sie sich Open-Source jedoch wie einen Turm aus Ziegelsteinen vor, bei dem die unteren Schichten längst vergessen sind, aber immer noch von engagierten Ingenieuren gepflegt werden und auf die sich noch mehr Entwickler verlassen. -Nur die Projekte an der Spitze des Turms sind in der Regel bekannt und werden gesponsert. -Diese voreingenommene Auswahl führt dazu, dass wichtige Bausteine, die den Turm hochhalten, keine Spenden erhalten, während die Favoriten mehr erhalten, als sie brauchen. -Bounties ermöglichen es den Nutzern von Projekten, den Entwicklern Zahlungen für den Bau bestimmter Funktionen vorzuschlagen, so dass Projekte nur für Dinge entlohnt werden, die nicht unbedingt in ihrem besten Interesse sind. -Und auch hier werden nur die Favoriten belohnt. - -In diesem Beitrag schlagen wir Tea vor - ein dezentrales System zur fairen Vergütung von Open-Source-Entwicklern auf der Grundlage ihrer Beiträge zum gesamten Ökosystem, das durch den tea-Anreizalgorithmus für alle Einträge in der Tea-Registry umgesetzt wird. - -![Simplified view of the tea steeping rewards system.](img/figure-1.svg) - -$\parskip=0pt plus 1pt$ - -[^1]: Source: @nist -[^2]: Source: @reuters -[^3]: Source: @twitter - - -# Komponenten - -Ein Softwareentwickler, der eine Applikation erstellt, braucht vier Dinge: einen Browser, ein Terminal, einen Editor und einen Paketmanager. -Von diesen vier Dingen steuert der Paketmanager die Werkzeuge und Frameworks, die ein Entwickler benötigt, um sein Produkt zu erstellen. -Auf dieser Ebene sehen wir das Potenzial, die Art und Weise zu verändern, wie Open-Source vergütet wird. - -## Der Paketmanager - -Der Paketmanager weiß, von welcher Open-Source-Software eine Anwendung abhängt, um zu funktionieren, von der Spitze des Turms bis zu seiner Basis. -Jede Komponente und Version, die für die Anwendung wichtig ist, ist bekannt und aufgezeichnet. -Er weiß, dass die Spitze des Turms seine Abhängigkeiten sorgfältig auswählt und diese sorgfältige Auswahl sich nach unten fortsetzt. -Der Paketmanager ist einzigartig im Stapel der Entwicklerwerkzeuge platziert, um eine automatisierte und präzise Werteverteilung auf der Grundlage der tatsächlichen Nutzung in der Praxis zu ermöglichen. - -Wir schlagen eine unveränderliche dezentrale Registry vor, die Werte auf der Grundlage eines Algorithmus verteilt, der den Beitrag jedes Eintrags zum Nutzen und zur Gesundheit des Systems bestimmt. -Werte können an den Spitzenpunkten des Graphen eingetragen werden - Anwendungen und wichtige Bibliotheken - und werden rekursiv an die Abhängigkeiten dieser Spitzenpunkte und deren Abhängigkeiten verteilt, da die Registry den gesamten Open-Source-Graphen kennt. - -Außerdem sind wir der Meinung, dass über den Paketmanager wesentliche Informationen verfügbar sein müssen, damit Entwickler/innen einschätzen können, ob sie einem Paket und seinem Autor vertrauen können. -Diese Informationen können auf Reputation, Ansehen in der Gemeinschaft, Daten aus dezentralen Identitätssystemen (DID[^4]), anderen Paketmanagern oder Anreizmechanismen beruhen, die möglicherweise darauf beruhen, dass Netzwerkteilnehmer einen wirtschaftlichen Wert riskieren. - -Wir gehen davon aus, dass die Kombination aus Werkzeugen, Informationen und Belohnungen von Tea einen Anreiz für Entwickler/innen darstellt, der das Wachstum von Open-Source-Software anregt und die Innovation fördert. - -[^4]: See: @w3 - -## Die dezentralisierte Registratur - -Jeder Paketmanager hat seine eigene Paketregistrierung, in der die gleichen Metadaten immer wieder dupliziert werden. -Es ist an der Zeit, dass es eine einzige, umfassende und endgültige Registrierung gibt, die von den Gemeinschaften, die auf sie angewiesen sind, entwickelt und verwaltet wird. -Diese dezentralisierte, unveränderliche Registrierung könnte Sicherheit und Stabilität bieten und -böswillige Absichten verhindern. - -Das Internet basiert auf Zehntausenden von wichtigen Open-Source-Komponenten. -Es ist bemerkenswert, dass es bisher nur wenige Vorfälle gab, die durch die Entfernung wichtiger Open-Source-Infrastrukturen verursacht wurden. -Der berühmteste Vorfall war die Entfernung einer NPM-Linkspad[^5]-Abhängigkeit im Jahr 2016, die sich auf die Systeme für kontinuierliche Integration und kontinuierliches Deployment auswirkte und Entwickler/innen tagelang auf dem Trockenen sitzen ließ. -Dieses Ereignis zeigte, dass das Internet selbst auf fragilen Entwicklungssystemen basiert. -Andere Beispiele beinhalten die aktive oder absichtliche Beteiligung von Paketverwalter, die ihre beliebten Pakete sabotieren (siehe colors.js, faker.js[^6] und node-ipc[^7]), -oder bösartige Akteure, die Profit machen wollen, indem sie vorgeben, bei der Wartung von Paketen zu helfen, und diese korrumpieren, um z. B. private Bitcoin-Schlüssel zu stehlen (siehe event-stream[^8]), -oder bösartige Pakete mit absichtlichen Rechtschreibfehlern, auch bekannt als Typosquatting, -in der Hoffnung, die Nutzer zur Installation zu verleiten, z. B. crossenv vs. cross-env NPM-Pakete[^npmjsCrossenv]. - -Auf dem Weg in eine Zukunft, in der digitale Güter Teil der Software sind, muss die Integrität der Software gewährleistet sein. -Wir können uns nicht länger der Gefahr aussetzen, dass böswillige Akteure die Software verändern. - -Die meisten Werkzeuge, die wir Paketmanager nennen, können nicht garantieren, dass die in die Apps und dApps eingebauten Pakete der unveränderte Open-Source-Code sind, der von ihren ursprünglichen Autoren veröffentlicht wurde. -Auf Microsofts GitHub wurde festgestellt, dass 17 % der Schwachstellen in Software zu böswilligen Zwecken eingeschleust wurden[^9], wobei einige für längere Zeit unentdeckt blieben (siehe Webmin 1.890[^10]). - -Ein dezentralisiertes Register, das durch ein Reputationssystem ergänzt und durch wirtschaftliche Anreize unterstützt wird, um schlechte Akteure zu entlarven und gute Akteure zu belohnen, könnte die Garantien bieten, nach denen die Entwicklergemeinschaften gesucht haben. - -[^5]: Source: @theregister -[^6]: Source: @fossa -[^7]: Source: @lunasec -[^8]: Source: @github -[^npmjsCrossenv]: Source: @npmjsCrossenv -[^9]: Source: @zdnet -[^10]: Source: @threatpost - - -## Das Speichersystem - -Open-Source-Pakete bieten eine breite Palette an Funktionen, von denen einige eingeschränkt oder unerwünscht sein können. -Die Verschlüsselung ist ein hervorragendes Beispiel dafür. -Ein wichtiger Anwendungsfall für Verschlüsselung ist der Schutz der individuellen Privatsphäre auf der ganzen Welt. -Verschlüsselung kann aber auch für schändliche Zwecke eingesetzt werden (siehe Phantom Secure, das im März 2018 von den Strafverfolgungsbehörden zerschlagen wurde[^11]) oder zur Unterstützung von Strafverfolgungsaktivitäten missbraucht werden (siehe Operation Ironside (AFP), Operation Greenlight (Europol), -und Operation Trojan Shield (FBI)[^12], bei der das FBI eine "verschlüsselte" Kommunikationsplattform, AN0M, betrieb und Kriminelle davon überzeugte, ihre "verschlüsselten" Telefone für eine sichere Kommunikation zu nutzen). - -Die vielfältigen Anwendungsmöglichkeiten der Verschlüsselung haben sie zu einem perfekten Anwendungsfall für Open-Source-Software gemacht und sind ein gutes Beispiel dafür, dass jede Lösung, die Pakete speichert, fälschungssicher und zensurresistent sein muss. -Tea ist ein dezentrales Protokoll, das nicht die Absicht hat, Pakete aufgrund ihrer Funktionalität zu filtern oder zu sanktionieren. -Zwar kann die Tea-Governance nachweislich bösartige Pakete entfernen (weitere Informationen im Abschnitt Governance), doch ist es für das Tea-System wichtig, sich mit mehreren Speichersystemen zu verbinden, darunter auch mit dezentralen Systemen, die nachweisen, dass ein Paket unverändert ist und korrekt repliziert wurde. -Die Paketbetreuer können das Speichersystem wählen, das am besten für die sichere Speicherung und Verteilung ihrer Pakete geeignet ist. - -[^11]: Source: @fbi -[^12]: Source: @europol - -# Netwerk Teilnehmer - -tea hat sich zur Mission gemacht, Open-Source-Gemeinschaften zu stärken und sicherzustellen, dass ihre Mitwirkenden bei der Entwicklung der Werkzeuge, die das Internet aufbauen, unterstützt werden. -In diesem Whitepaper unterscheiden wir die Teilnehmer durch ihre Beiträge. -Einige tragen Code bei oder überprüfen den beigetragenen Code. -Andere bieten einen wirtschaftlichen Wert, um Entwickler und ihren Ruf zu unterstützen. - -## Paket-Maintainer - -Paket-Maintainer müssen dafür sorgen, dass ihre Software mit der Weiterentwicklung der Branche immer mehr Wert liefert. - -tee setzt voraus, dass die Ersteller von Paketen ihre Arbeit pflegen. -Paket-Maintainer sind die Säulen der Open-Source-Gemeinschaft, die für ihre kontinuierlichen Beiträge gestärkt und belohnt werden müssen. -Es kann vorkommen, dass ein Paket-Maintaner seine Wartungsarbeiten einstellt oder feststellt, dass er nicht in dem Tempo arbeiten kann, das den Erwartungen der Paketnutzer entspricht. -Paket-Maintainer erhalten einen nicht fungiblen Token (NFT), wenn sie ein Paket einreichen (weitere Informationen finden Sie im Abschnitt NFT für Paketbetreuer). -Diese NFT wird als Nachweis für ihre Arbeit verwendet und ist der Schlüssel für die Belohnungen. -Der Inhaber der NFT eines Pakets kann sie auf einen anderen Entwickler (oder eine Gruppe von Entwicklern) übertragen, wodurch diese zu Maintainern des Pakets und Empfängern zukünftiger Belohnungen werden. -Ebenso kann ein Entwickler beschließen, die Rolle des Paket-Maintainer zu übernehmen, indem er das bestehende Paket forked und ein neues einreicht, das er in Zukunft betreuen wird. - -Es ist wichtig, den Entwicklergemeinschaften die richtigen Werkzeuge an die Hand zu geben, um herauszufinden, welche Pakete Maintained werden und welchen Ruf und welche Qualität die bisherigen und aktuellen Maintainern haben. -Wir haben schon zu oft erlebt, dass Open-Source-Arbeiten manipuliert und die Bemühungen vieler Menschen durch bösartige Akteure zunichte gemacht wurden. -Obwohl die Arbeit dieser bösartigen Akteure größtenteils entdeckt und behoben wird, geschieht dies oft erst, wenn ein erheblicher Schaden in Form von finanziellen Verlusten oder Datenverlusten entstanden ist. -Nehmen wir zum Beispiel das EventStream npm-Paket[^13], das über 1,5 Millionen Mal pro Woche heruntergeladen wurde und auf das sich über 1.500 Pakete stützten, als es einem Hacker gelang, in das Open-Source-Projekt einzudringen, -in das Open-Source-Projekt einzudringen, das Vertrauen des ursprünglichen Autors zu gewinnen und EventStream so zu verändern, dass es von einem bösartigen Paket abhängt, das die Anmeldedaten für die Bitcoin-Brieftasche an einen Drittanbieter-Server weiterleitet. -Obwohl Tools helfen können, einige dieser Angriffe zu erkennen, kann man sich nicht immer auf sie verlassen, was dazu führt, dass eine ganze Gemeinschaft von der gegenseitigen Sorgfalt und der Bereitschaft, ihre Erkenntnisse zu teilen, abhängig ist. - -Wir schlagen vor, Anreize über den tea-Token einzuführen, der im Abschnitt tea-Token beschrieben wird und die Open-Source-Gemeinschaft dazu ermutigt, ihre Entdeckungen konstruktiv zu melden, damit die Paket-Maintainer sie beheben können, bevor sie ausgenutzt werden. - -[^13]: Source: @medium - -## Paket Benutzer - -Paketnutzer sind Softwareentwickler, die sich auf die Lösung eines bestimmten Problems konzentrieren. -Sie suchen oft in der Open-Source-Gemeinschaft nach den Werkzeugen, die sie brauchen, um schnell zu experimentieren und zu iterieren, und zwar zu sehr geringen oder gar keinen Kosten, so dass sie direkt von der Arbeit der Paketentwickler und -Maintainer profitieren. -Traditionell hat sich ein Teil von ihnen dafür entschieden, die Paket-Maintainer durch Spenden oder andere Formen der Vergütung zu unterstützen; dies ist jedoch selten der Fall. - -Sponsoring kann ein effektives System zur Unterstützung der Open-Source-Entwicklung sein, aber die Vergütung erstreckt sich in der Regel nicht auf alle Abhängigkeiten. -Diese Einschränkung begünstigt und behindert die Innovation und die Entwicklung von Software. -Wenn Open-Source die Grundlage der Softwareentwicklung sein soll, müssen alle Entwickler/innen, egal ob Anfänger/innen oder Expert/innen, über alle Ebenen des Turms hinweg befähigt werden. - -Das Ziel von tea ist es, die Grundwerte von Open-Source-Software aufrechtzuerhalten und gleichzeitig ein dezentrales System zur Verfügung zu stellen, mit dem Paket-Maintainer für ihre Arbeit entlohnt werden. -Um diese Mission zu erfüllen, will tea Mechanismen entwickeln - und andere dazu anregen, diese zu entwickeln -, mit denen Paketnutzer die Paket-Maintainer durch einzigartige Anwendungsfälle des tea-Tokens unterstützen können, wie in den Abschnitten tea-Token, zukünftige Arbeit und potenzielle Gemeinschaftsarbeit beschrieben. - -## Paketunterstützer und Sponsoren -Im Web 2.0 und web3 werden Paketunterstützer oft als "Sponsoren" bezeichnet. Sie sind Organisationen oder Paketnutzer, die Open-Source-Software für ihre kommerziellen Produkte nutzen, Philanthropen, die das Ökosystem unterstützen wollen, oder Unternehmer, die Teams finanzieren wollen, um Komponenten eines größeren Systems zu entwickeln. - -tea schlägt vor, die Gemeinschaft der Paketunterstützer auf die gesamte tea-Gemeinschaft auszuweiten, egal ob es sich um Organisationen, Entwickler, Nutzer oder Technikbegeisterte handelt. -Das Ziel von tea ist es, dezentrale Anreizmechanismen durch einzigartige Anwendungsfälle des tea-Tokens für jedes Mitglied der tea-Gemeinschaft zu implementieren, um zur dauerhaften Nachhaltigkeit und zum kontinuierlichen Wachstum von Open-Source beizutragen. -Paketunterstützer und -sponsoren können frei entscheiden, welche Pakete oder Paket-Maintainer sie auf der Grundlage ihrer Arbeit, ihrer Überzeugungen oder anderer Kriterien und Maßstäbe, die ihre Entscheidung beeinflussen, unterstützen wollen. -Darüber hinaus fließt die Unterstützung der Paketunterstützer und sponsoren in die Abhängigkeiten der einzelnen Pakete ein. Damit wird dem Paket-Maintainer implizit vertraut, dass er gute Entscheidungen für seinen Stack trifft und diese Informationen zu seinem Ansehen beitragen. - -Wenn der Paket-Maintainer einen solchen Service anbietet, kann ein Paketunterstützer und -sponsor im Gegenzug einen Premium-Support-Level NFT erhalten und so von beschleunigten SLAs oder einer flexibleren Lizenzierung profitieren. -Darüber hinaus können Paketunterstützer und sponsoren beschließen, Pakete oder Paket-Maintainer zu unterstützen und automatisch alle oder einen Teil ihrer Belohnungen umzuleiten, um Anreize für Teams zu schaffen, neue Open-Source-Software zu entwickeln. -Mit anderen Worten: Pakete müssen nicht erst existieren, damit der tea fließt. -Aufstrebende Projekte können genauso gut unterstützt werden wie reifere, was einen weiteren Anreiz für eine sich ständig weiterentwickelnde Open-Source-Landschaft darstellt. - -## tea Tasters - -Wenn neue Pakete oder neue Versionen bestehender Pakete veröffentlicht werden, muss die Gültigkeit der Arbeit nachweislich belegt werden. -Diese Informationen sind wichtig, damit die Paketnutzer entscheiden können, ob sie dem Paket und seinen Maintainer vertrauen oder nicht. -Beim teeprotokoll wird diese Aufgabe von den tea Taster übernommen. - -tea-Tasters sind in der Regel erfahrene Softwareentwickler, die bereit sind, einen Teil ihrer Zeit darauf zu verwenden, die mit einem Paket verbundenen Behauptungen zu überprüfen (Funktionalität, Sicherheit, semantische Versionierung[^14], Richtigkeit der Lizenz usw.) -und setzen sowohl ihren Ruf als auch ihren wirtschaftlichen Wert aufs Spiel, um das Ergebnis ihrer Recherchen und Analysen zu belegen und ihre Bewertungen zu unterstützen. -tea-Tasters erhalten eine Belohnung für ihren Fleiß und ihre Bemühungen. -Bei tea nennen wir "steeping your tea" die Aktion, tea-Token zu sperren, um deine Rezensionen zu unterstützen und Belohnungen (oder Strafen) zu erhalten, die auf dem Konsens über die Gültigkeit deiner Rezensionen basieren. - -Wie die Unterstützer eines Pakets können auch tea-Tasters den Ruf eines Pakets und des Paketbetreuers beeinflussen, allerdings ist ihr Einfluss größer, da sie die Sicherheit, Funktionalität und Qualität eines Pakets überprüfen. -tea Tasters müssen auch ihren Ruf aufbauen, um ihre Ansprüche zu untermauern. -Die Qualität ihrer Arbeit und der wirtschaftliche Wert, den sie mit ihren Bewertungen in Verbindung mit anderen externen Datenquellen aufs Spiel setzen, erhöhen den Ruf jedes tea-Tasters und steigern den Wert seiner Arbeit. -Weitere Informationen zu den Mechanismen, die den Ruf eines Pakets und des Paket-Maintainers beeinflussen, findest du im Abschnitt über den Ruf eines Pakets. - -[^14]: See: @semver - -# Protokoll-Übersicht - -Die Entwicklung eines Protokolls zur Belohnung von Open-Source-Beiträgen ist mit vielen Herausforderungen verbunden. -Open-Source-Software ist per Definition offen für alle und kann daher falsch zugeordnet, angeeignet oder böswillig manipuliert werden. -Die Open-Source-Gemeinschaft hat jedoch immer wieder ihre Bereitschaft gezeigt, gute Akteure hervorzuheben und schlechte Akteure zu entlarven. -In der Vergangenheit wurde die Energie, die für die Überprüfung und Kommentierung der Beiträge anderer Entwickler aufgewendet wurde, ausschließlich auf freiwilliger Basis eingesetzt, obwohl das Melden und Verteidigen von Ergebnissen zeitaufwändig und wichtig sein kann. - -Wir wollen eine vertrauenswürdige Verbreitungsplattform für Anwendungen schaffen, die durch Reputation und finanzielle Anreize abgesichert ist. Denn wir glauben, dass eine angemessene Belohnung für Open-Source-Beiträge ohne ein Reputationssystem und die Möglichkeit für die Mitglieder der Community, ihre Erkenntnisse und Unterstützung (oder Ablehnung) für ein Paket oder die Arbeit eines Entwicklers mitzuteilen, nicht gelingen kann. - -Wir müssen Entwicklern Werkzeuge an die Hand geben, mit denen sie auf dieses Reputationssystem zugreifen und zu ihm beitragen können. -Werkzeuge, die einen einfachen visuellen und programmierbaren Zugriff auf die Version und den Ruf aller Abhängigkeiten innerhalb ihrer Pakete ermöglichen. -Ein klares Verständnis darüber, welche Community-Mitglieder jedes Paket unterstützen und wie viele tea-Token sie steeping, wird zum Ansehen jedes Pakets beitragen, genauso wie die Menge, mit der ein Paket-Maintainer seine Arbeit steeped, kommuniziert, wie sehr er hinter seiner Arbeit steht. -Diese kombinierten Daten werden dazu beitragen, ein Reputationssystem für alle Community-Mitglieder zu entwickeln und die Auswahl zu erleichtern. -Da der Hack des EventStream-Pakets nicht über das Paket selbst, sondern über eine seiner Abhängigkeiten durchgeführt wurde, ist die Transparenz über alle Ebenen der Abhängigkeiten hinweg entscheidend für den Aufbau dieses vertrauenswürdigen Systems. -Bei der Entwicklung und dem Aufbau des Systems müssen jedoch auch Überlegungen wie die Kosten für Berechnungen und Transaktionen ("Gas") Vorrang haben. - -Unser Ziel ist es, sowohl Web 2.0- als auch Web3-Entwickler zu belohnen. -Die Feinheiten und Besonderheiten jedes Stacks führen dazu, dass die Verfolgung von Installationen und Deinstallationen von Paketen leicht einem oder mehreren schlechten Akteuren zum Opfer fallen kann. -Dazu gehört auch das "Kaufen" von Installationen, um die Zahlen künstlich aufzublähen. -Ein noch schlimmeres Szenario wäre es, das Wesen von Open-Source-Software grundlegend zu verändern, indem man unnötige Reibungsverluste durch Lizenzschlüssel oder andere Mechanismen zur Verfolgung der Installation verursacht. -Um eine möglichst breite Abdeckung zu erreichen, sollten die Belohnungen nicht auf einer simplen Verfolgung von Installationen oder Deinstallationen beruhen, sondern auf Anreizmechanismen, die die Einreichung von Qualitätspaketen und die Meldung von schändlichen oder risikoreichen Paketen fördern. -Und schließlich sind viele Pakete auf gemeinsame Abhängigkeiten angewiesen. -Lodash hat zum Beispiel 151.209 Abhängigkeiten[^15], während Kreide 78.854 Abhängigkeiten[^16] oder Log4js 3.343 Abhängigkeiten[^17] hat. -Wie stellen wir sicher, dass die Anreize fair und gerecht verteilt werden, wenn mehr Pakete mit denselben Abhängigkeiten erstellt werden? -Wie stellen wir sicher, dass die am meisten genutzten Abhängigkeiten belohnt werden, ohne dass neue oder aufstrebende Pakete und Entwickler ausgehungert werden? -Wie stellen wir sicher, dass das Anreizsystem nicht dazu führt, dass Entwickler von Nischensprachen weggelenkt werden, um sie dort zu zentralisieren, wo die Anreize besser sind? -Und wie können wir als Entwickler die Pakete mit den meisten Abhängigkeiten identifizieren, um Alternativen zu bauen - schlankere, effizientere und besser codierte Versionen dieser Pakete? -Wir bei tea glauben, dass der Mangel an Anreizen die Entwicklung von Open-Source-Software behindert hat. -Mit den richtigen wirtschaftlichen Anreizen und Belohnungen werden mehr Entwickler in der Lage sein, Open-Source-Software zum Wohle der Welt zu entwickeln, zu verbessern und zu erweitern. -Erst dann wird der tea-Token den Gesamtwert von Open-Source-Software repräsentieren können. - -[^15]: Source: @npmjsLodash -[^16]: Source: @npmjsChalk -[^17]: Source: @npmjsLogFourjs - -## Paket Einreichung - -Die Einreichung einer Paketfreigabe erfordert mehrere Transaktionen, die atomar ablaufen. -Insbesondere muss der Paketbetreuer: - -* Das Paket (und seine semantische Version) bei der dezentralen Registrierungsstelle registrieren. -* Das Paket in das dezentrale Speichersystem hochladen, um es widerstandsfähig zu machen, vor Zensur zu schützen und die Verteilung zu erleichtern. -* Zum Ansehen und zur Vertrauenswürdigkeit des Pakets beitragen, indem du Tee-Tokens *steeping*. - -Wenn einer der drei Vorgänge fehlschlägt, kehrt das Protokoll in seinen vorherigen Zustand zurück und löscht alle Beweise für die Einreichung. - -Wenn ein Paket erfolgreich eingereicht wurde, erhält der Paket-Maintainer eine Maintainer-NFT als Nachweis für seine Arbeit und seinen Beitrag zu Open Source. -Der Paket-Maintainer kann die mit der Maintainer-NFT verbundenen Steeping Rewards an eine dritte Partei übertragen. -Der Ruf, der mit der Erstellung und Pflege des Assets verbunden ist, verbleibt jedoch beim Paket-Maintainer, so dass sein Ruf im Laufe der Zeit beeinträchtigt werden kann. -Wenn die Reputation eines Mitglieds der tea-Gemeinschaft wichtige Meilensteine erreicht, kann ihm nach Entscheidung der tea-Governance Zugang zu höheren Teilen des Protokolls gewährt werden oder es kann beschleunigte Belohnungen erhalten. -Weitere Einzelheiten zum Maintainer-NFT findest du im Abschnitt Maintainer-NFT. - - -### Abhängigkeiten Analyse - -Paketabhängigkeiten können tiefgreifend sein, da jedes Paket oft sowohl Abhängigkeiten als auch Abhängigkeiten hat. -Um eine einfache Methode zu schaffen, die alle Entwickler belohnt, die zu Open-Source-Software beigetragen haben, und gleichzeitig die Erstellung des Abhängigkeitsbaums schnell und rechnerisch effizient zu gestalten, schlagen wir vor, nur die Abhängigkeiten der ersten Ebene zu überprüfen, wenn ein Paket eingereicht wird. - -Diesem Entwurf liegt die Hypothese zugrunde, dass jede Abhängigkeit selbst ein Paket ist, das unabhängig im teabaum eingereicht wurde. -Auf diese Weise kann jede seiner Abhängigkeiten abgebildet werden, und wenn seine Abhängigkeiten selbst Abhängigkeiten haben, werden diese zum Zeitpunkt der Einreichung des Abhängigkeitspakets abgebildet. - -![Dependencies analysis diagram.](img/figure-3.svg){#fig:dep-analysis} - -In @fig:dep-analysis löst die Einreichung von Paket A eine Analyse der Laufzeitabhängigkeiten 1 bis n und der Build-Abhängigkeiten 1 bis n aus, während die Laufzeitabhängigkeiten 1.1 bis 1.n und die Build-Abhängigkeiten 1.1 bis 1.n analysiert wurden, als Paket B eingereicht wurde. -Wir wenden dieselbe Methode für die Verteilung der Anreize an, da die Steeping-Token auf alle Abhängigkeiten verteilt werden, also rekursiv die als Abhängigkeiten aufgeführten Pakete steepen (siehe @fig:steeping-rewards). - -![Steeping rewards distribution across dependencies.](img/figure-2.svg){#fig:steeping-rewards} - - -Versionierung und widersprüchliche Abhängigkeiten sind eine große Herausforderung, deren Behebung viel Zeit in Anspruch nehmen kann. -Um dieses Problem anzugehen, schlagen wir vor, jedes Paket bei der Einreichung einer umfassenden Prüfung der Abhängigkeiten zu unterziehen, damit wir sicherstellen können, dass das Paket die folgenden Regeln für semantische Versionsbereiche einhält. - -* Pakete dürfen ihre Abhängigkeiten nur auf eine Hauptversion beschränken, wobei der Beginn des Bereichs jede gültige semantische Version sein kann (z. B. >=5.2.1 <6). -* Wenn eine Abhängigkeit auf eine neuere Hauptversion aktualisiert wird, kann es erforderlich sein, dass die Hauptversion des Pakets erhöht wird. -* Wird eine Abhängigkeit auf eine neuere Nebenversion aktualisiert, kann tea verlangen, dass die Nebenversion des Pakets erhöht wird. -* Wenn eine neue Abhängigkeit hinzugefügt wird, kann tea verlangen, dass die Nebenversion des Pakets erhöht wird. - -In Anbetracht des unnötigen Aufwands, der jedem Nutzer eines Pakets auferlegt wird, wenn die oben genannten Regeln übertreten werden, schlagen wir vor, dass ein Teil der tea-Token, die der Paketbetreuer eingeworfen hat, steeped wird, um den Mangel an Sorgfalt zu reflektieren. -Wenn ein Entwickler jeden dazu zwingt, mit seinen Tassen zu jonglieren, wird jemand etwas tea verschütten. -Da erwartet wird, dass die Überprüfung der Abhängigkeiten bei der Einreichung stattfindet, sollten wir anmerken, dass die Unterstützer und Sponsoren des Pakets oder die tea-Tasters nichts steeped haben. - - -## Reputation von Paketen und Paket-Maintainer - -Paket-Maintainer müssen zur Reputation und Vertrauenswürdigkeit ihres Pakets beitragen, indem sie tea-Tokens eintauschen. -Ein Reputationssystem, das sich ausschließlich auf den wirtschaftlichen Beitrag des Autors stützt, bietet jedoch keinen ausreichenden Schutz für die Nutzer und kann Sybil-Angriffen ausgesetzt sein, bei denen eine einzelne Person mehrere Repräsentationen ihrer selbst erstellt, um eine große Anzahl positiver Bewertungen für ihre Arbeit zu hinterlassen, -Dadurch wird den Nutzern vorgegaukelt, dass ihre Arbeit von vielen überprüft und genehmigt wurde. - -Es gibt mehrere Methoden zur Verhinderung von Sybil-Angriffen, von denen einige von Nitish Balachandran und Sugata Sanyal in "A Review of Techniques to Mitigate Sybil Attacks"[^18] beschrieben werden. -Da es sich bei tea um ein dezentrales Protokoll handelt, würde die Verwendung eines vertrauenswürdigen Zertifizierungssystems, das sich auf eine zentralisierte Zertifizierungsstelle stützt, seinem Kern widersprechen. -Wir schlagen vor, sich auf dezentralisierte Ansätze zur Abschwächung von Sybil-Angriffen zu konzentrieren, und zwar auf Methoden, die sich auf eine große Gruppe von Netzwerkteilnehmern stützen, die einen Anreiz haben, die Reputation jedes Pakets und seines Maintainer zu bewerten und öffentlich darzustellen. - -Ähnlich wie bei der Produktion von Blöcken auf einer Proof-of-Stake-Blockchain, bei der nicht-produzierende Knoten die Arbeit anderer validieren und gegebenenfalls einen Verstoß gegen die Regeln des Netzwerks aufzeigen können, was zu einer Bestrafung des schlechten Akteurs durch Slashing (Zerstörung eines Teils seines Einsatzes) führt, -schlagen wir ein System vor, bei dem Dritte (auch tea-Tasters genannt) in der Lage wären, von Paketbetreuern erstellte Pakete zu überprüfen und einen wirtschaftlichen Anreiz zu haben, sich im besten Interesse der Open-Source-Softwaregemeinschaft und ihrer Nutzer zu verhalten, sowie gutes Verhalten anzuerkennen und schlechtes Verhalten zu bestrafen. -Dieses System muss sowohl sybil-resistent sein als auch verhindern, dass große Token-Inhaber das Protokoll oder den Ruf bestimmter Pakete wesentlich beeinflussen. -Wir sind der Meinung, dass dieser Ansatz besser zu Open-Source passt und ein fruchtbareres Substrat für die Förderung von Akzeptanz und Vertrauen bietet, was letztlich das Wachstum von tea erleichtert. - -[^18]: Source: @arxiv - -## Überprüfung des Pakets durch Dritte -Die Überprüfung von Paketen durch Dritte ist ein wesentlicher Bestandteil des Reputationsaufbaus. Die Überprüfung durch Dritte birgt jedoch eine Reihe einzigartiger Gefahren, darunter die bereits erwähnten Sybil-Angriffe. - -Die Blockchain-Technologie, insbesondere das Staking, bietet tea eine einzigartige Möglichkeit, diese Herausforderung zu meistern. -Obwohl Wallet-Adressen in unendlichen Mengen verfügbar sein können, ist dies bei tea-Token nicht der Fall, deren anfänglicher Vorrat bei 10 Milliarden Stück liegen soll. -Darüber hinaus trägt jede von den Entwicklern durchgeführte Aktion, wie z. B. das Einreichen von Paketen, das Überprüfen von Paketen oder das steeping von Paketen, zu ihrer Reputation bei, wodurch ein einzigartiges Profil erstellt wird, das jeder Entwickler nutzen kann, um sowohl zur tea-Community beizutragen als auch an der Governance von tea teilzunehmen. - -Durch die Verpflichtung von Drittgutachtern, tea-Tokens zu steepen und das Risiko einzugehen, einen Teil ihrer steeped Token zu verlieren, falls sie sich gegen die Interessen des Interesse des Netzwerks handeln oder ein schlechter Akteur sind, können Dritte einem Paket zusätzliche Glaubwürdigkeit verleihen und eine Belohnung in Form von tea-Tokens erhalten.. - -Wir schlagen außerdem vor, das Reputationssystem auf Dritte auszudehnen, die die unabhängige Überprüfung von Paketen durchführen - die tea-Tasters. Der Abschluss einer positiven Überprüfung erfordert zwei Vorgänge, die atomar ablaufen: - -* Die Einreichung der Codeüberprüfung, die vom tea-Taster unterzeichnet und für alle Mitglieder der Gemeinschaft öffentlich zugänglich ist, zusammen mit -* Der Akt des steeping "für" das Paket (im Gegensatz zu "gegen" das Paket), um seine Überprüfung zu untermauern. - -Nach Abschluss einer negativen Bewertung, die eine oder mehrere kritische Schwachstellen enthält, müssen die tea-Tasters zunächst den Paket-Maintainer über ein Nachrichtenprotokoll kontaktieren, um ihn über die Schwachstelle zu informieren und ihm die Möglichkeit zu geben, das Problem rechtzeitig zu beheben. -Nach Ablauf der dem Paket-Maintainer zugestandenen Frist zur Behebung der Schwachstelle oder sobald das korrigierte Paket verfügbar ist, wird dasselbe Nachrichtenprotokoll verwendet, um alle Nutzer und Tester dieses Pakets (einschließlich der Abhängigen) darüber zu informieren, dass eine Schwachstelle gefunden und hoffentlich behoben wurde, -und hoffentlich behoben wurde, damit sie wissen, dass sie ihre Anwendung oder Abhängigkeiten aktualisieren müssen. -Um die Zeit der Entwickler nicht zu verschwenden, wird die Kommunikation zwischen den tea-Tasters und den Paket-Maintainer erfordern, dass die tea-Taster tea-Tokens steep. - -Nach Abschluss beider Vorgänge erhalten die tea-Taster eine NFT als Nachweis für ihre Arbeit an einem bestimmten Paket und einer bestimmten Paketversion. -Die Ansammlung von NFTs in Kombination mit dem Aufgussverhältnis jedes der überprüften Pakete und Informationen aus externen Systemen geben Aufschluss über die Reputation eines tea-Tasters. -Wenn ihr Ruf wichtige Meilensteine erreicht, können tea-Tasters Zugang zu höherwertigen Teilen des Protokolls oder zu beschleunigten Belohnungen erhalten, wie von der Teeverwaltung beschlossen. - -## Veraltete oder korrupte Pakete - -Die Aufgabe von tea ist es, Mitwirkende und Teilnehmer in den Open-Source-Gemeinschaften zu belohnen; die Belohnungen müssen jedoch den Bemühungen der Paketbetreuer und teeverkoster entsprechen. -Unzureichend gepflegte, veraltete oder korrupte Pakete sind klare Anzeichen dafür, dass die Paketbetreuer den Erwartungen der Gemeinschaft nicht gerecht werden oder das Vertrauen und die Unterstützung, die ihnen durch das steeping von Paketen entgegengebracht werden, nicht erfüllen. -Eine weitere Manifestation veralteter Pakete kann die fortgesetzte Verwendung einer Legacy-Sprache oder einer Legacy-Version von Mehrversionssprachen sein. -Pakete, die zu lange veraltet oder korrupt sind, weisen darauf hin, dass die tea-Taster die Arbeit der Paketbetreuer regelmäßig und konsequent überprüfen müssen. - -tea-Tasters sind kritische Mitglieder der Open-Source-Gemeinschaften, da ihre Bewertungen und die damit verbundenen Behauptungen die Paketnutzer zu oder weg von Paketen lenken können. -Um sicherzustellen, dass den Bewertungen kontinuierlich vertraut werden kann, schlagen wir einen Mechanismus vor, bei dem für veraltete oder korrupte Pakete ein Teil der gesammelten Token an die tea-Tasters geschickt wird, die als erste die mangelnde Wartung eines Pakets erkannt haben. - -Jede negative Bewertung, die einen Fehler wie eine Zero-Day-Schwachstelle oder die Verwendung einer veralteten Abhängigkeit aufzeigt und nach Ablauf einer von der Governance festgelegten Frist offen bleibt, sollte als Versagen des Paket-Maintainer angesehen werden. -Er hat die Aufgabe, die ihm anvertraut und für die er belohnt wurde, nicht erfüllt. -Dasselbe gilt für Unterstützer und Sponsoren von Paketen, die ihren Ruf auf die Arbeit von säumigen Paket-Maintainer gesetzt haben und dafür belohnt wurden, es aber versäumt haben, den Mangel an Wartung zu erkennen oder sich entschieden haben, das Paket trotzdem weiter zu unterstützen. - -Da Pakete immer beliebter werden und immer mehr Anwendungen und potenziell unternehmenskritische Systeme von ihnen abhängen, müssen wir Anreize für Entwickler schaffen, Fehler diskret an den Paket-Maintainer zu melden, und die Paket-Maintainer müssen solche Fehler beheben, bevor sie ausgenutzt werden können. -Daher schlagen wir vor, dass jedem veralteten oder korrupten Paket, das eine oder mehrere nachweislich negative Bewertungen erhalten hat und in diesem Zustand über die von der Regierung festgelegte Gnadenfrist hinaus bestehen bleibt, ein Teil seiner Token abgezogen wird, unabhängig von ihrer Herkunft (Paket-Maintainer, Paketunterstützer und Sponsoren oder frühere tea-Taster), -während ein anderer Teil an die tea-Taster geschickt wird, die die negativen Bewertungen abgegeben haben. -Die Verteilung an alle tea-Tasters könnte auf der Grundlage des Alters ihrer Bewertung und der Anzahl der tea-Tokens, die sie für ihre Bewertung aufgegossen haben, erfolgen. - -## Maintainer NFT - -Nach erfolgreicher Einreichung eines Pakets erhält der Paket-Maintainer eine NFT als Nachweis seiner Arbeit und seines Beitrags. -Der Inhaber dieser NFT erhält automatisch alle mit dem Paket verbundenen Belohnungen. -Paket-Maintainer können das Eigentum an einem Paket auf einen anderen Paket-Maintainer übertragen, indem sie einfach die NFT des Pakets weitergeben. -Eine erfolgreiche Übertragung der NFT führt dazu, dass der neue Besitzer automatisch zukünftige Rewards für das Paket erhält. - -Ein wichtiger Teil des Reputationsaufbaus hängt von der Häufigkeit und Quantität der Einreichung von Qualitätspaketen ab. -Die NFT, die den Paket-Maintainer als Beweis für ihre Arbeit ausgehändigt wird, kann vom Reputationssystem verwendet werden, um die Reputation eines Paket-Maintainer zu aktualisieren und ihm Zugang zu höherwertigen Teilen des Protokolls zu gewähren, wie von der tea Governance beschlossen. -Um jedoch Angriffsvektoren zu verhindern, wie z.B. dass Mitglieder der Gemeinschaft ihre Reputation kaufen, wird die Übertragung der Betreuer-NFT nicht zu einer Übertragung der Reputation führen. -Die Reputation muss direkt mit der Arbeit eines bestimmten Entwicklers verbunden bleiben und darf nicht übertragbar sein. - -# tea-Token - -## Absicherung des Netzes - -Während viele Blockchains als effektive und sichere Infrastrukturlösungen erscheinen, um die Ziele von tea zu unterstützen, glauben wir, dass der Technologie-Stack, auf dem das tea-System aufbaut, sorgfältig geprüft werden muss. - -Skalierbarkeit, Kosteneffizienz, ESG und Erweiterbarkeit durch Dritte sind wichtige Designüberlegungen, die ein souveränes Proof-of-Stake-System für tea besser erfüllen könnte. -Beim Proof-of-Stake-System setzen Knotenbetreiber und Netzwerkteilnehmer einen wirtschaftlichen Wert in Form des Tokens der Kette ein, um die Sicherheit des Systems zu erhöhen. -Knotenbetreiber und Netzwerkteilnehmer erhalten Belohnungen für die erfolgreiche Produktion von Blöcken, die den Regeln des Netzwerks entsprechen und genaue Transaktionsinformationen enthalten. -Inaktivität (auch bekannt als "Node Down") oder böswillige/falsche Aktivitäten werden bestraft, indem ein Teil der eingesetzten Token durch Slashing vernichtet wird. - -Ein Proof-of-Stake-System, das durch den tea-Token angetrieben wird, ermöglicht es den tea-Token-Inhabern, zur Sicherheit des Systems beizutragen, indem sie tea *staking* und Open-Source-Entwickler unterstützen, indem sie tea *stepping*. -Wir sind uns bewusst, dass wirtschaftliche Faktoren einige Entwickler davon abhalten könnten, tea zu *staking* oder zu *steeping*; daher wird das staking und steeping von tea für nur ein leaf möglich sein, die kleinste Stückelung von tea, die einem Hundertmillionstel ($10^{-8}$) eines tea's entspricht. - -Beide Anwendungen des tea-Tokens erfüllen wichtige Funktionen für die Unterstützung und das Wachstum des Open-Source-Ökosystems. -Durch das *staking* von tea wird sichergestellt, dass das teasystem weiterhin sicher funktioniert, so dass alle Netzwerkteilnehmer Pakete einreichen und darauf zugreifen können, um sie zu überprüfen, sie in ihre Anwendung zu integrieren, usw. -Im Gegensatz dazu wird das Steeping von tea das Ziel unterstützen, allen Netzwerkteilnehmern Werkzeuge zur Verfügung zu stellen, mit denen sie Pakete unterstützen und nutzen können, die den Qualitäts- und Zuverlässigkeitsanforderungen entsprechen, wie sie von der tea-Gemeinschaft durch ihre Unterstützung und Ablehnung der einzelnen Pakete formuliert wurden. -Bei der Definition und Umsetzung von Staking- und Steeping-Parametern wird sorgfältig darauf geachtet, dass das eine nicht zum Schmarotzer am anderen wird. - -## Anreize und Strafmaßnahmen - -Wie bereits erwähnt, kann es für böswillige Akteure einen starken Anreiz geben, Open-Source-Software zu kompromittieren. -Der größte Teil der kritischen Infrastruktur des Internets läuft auf Open-Source, und der Wettlauf um die Suche nach Exploits und anderen Schwachstellen ist in vollem Gange. -Wir bei tea sind der Meinung, dass die Paket-Maintainer nicht die Schuldigen sind (obwohl sie es oft sind). - -Die Anreize des tea-Protokolls beheben dies durch eine faire und gerechte Verteilung der Anreize. -Ein Paket wie Lodash mit über 151k Abhängigkeiten ist eine Säule der Open-Source-Entwicklung, und sein Maintainer verdient es, entsprechend belohnt zu werden. -Ein Belohnungssystem, das allein auf der Anzahl der Abhängigkeiten aufbaut, würde jedoch Innovatoren davon abhalten, diese Monopole zu durchbrechen, es sei denn, sie werden ausreichend von Dritten finanziert oder haben bereits genug Ressourcen angesammelt, um sich selbst zu finanzieren. -Dieser Ansatz würde wahrscheinlich zu einer schrumpfenden Zahl von Beitragszahlern führen, was das genaue Gegenteil dessen wäre, worum es bei tea geht. - -Das Ziel von tea ist es, den Wert von Open-Source-Software zu repräsentieren und dabei ihr Wachstum zu fördern, indem die Teilnehmer mit den Ressourcen ausgestattet werden, die sie benötigen, um ihrer Leidenschaft unbelastet nachzugehen. -Das System zur Verteilung der Anreize für tea muss das Steeping-Verhältnis der einzelnen Pakete sorgfältig berücksichtigen und die Anreize für jedes Paket entsprechend anpassen. -Um das Risiko zu verringern, dass eine kleine Anzahl von Paketen, die in vielen Anwendungen als Abhängigkeiten verwendet werden, den Großteil der Steeping-Belohnungen erhalten, werden wir die Forschungsergebnisse der web3 Foundation[^19] für den Polkadot-Proof-of-Stake-basierten Belohnungsmechanismus nutzen. -Wir können die Implementierung und ihre Variablen auf der Grundlage der Ergebnisse von praktischen Experimenten weiter anpassen. - -Wenn sich ein Paket einem von der Regierung definierten optimalen Steeping-Verhältnis nähert, wird sein Steeping-Belohnungs-Verhältnis schrittweise abnehmen. -Wenn ein Paket sein optimales Steeping-Verhältnis überschreitet, sinkt das Steeping-Belohnungs-Verhältnis drastisch, um die Paketbefürworter und tea-Tasters davon abzuhalten, weitere Pakete mit hohem Steeping zu *steppen*. -Dieses Konzept könnte es ermöglichen, dass Pakete mit geringerem Steeping sowohl für Paketbefürworter als auch für tea-Tasters attraktiver werden. -Es könnte auch einen Anreiz für erfahrene Entwickler darstellen, Alternativen zu stark getränkten Paketen zu entwickeln, was der teagemeinschaft die Möglichkeit gibt, ein Gleichgewicht zwischen der Unterstützung bestehender Software und der Förderung von Innovationen zu schaffen. -Das Steeping-Verhältnis wird anhand des zirkulierenden Angebots in seinem ursprünglichen Entwurf berechnet. -Die tea-Community kann dieses Design ändern, um die Skalierbarkeit des Systems weiter zu verbessern. -$\chi$ sei das Steeping-verhältnis für alle Pakete. -Sie stellt die Gesamtzahl der von Paketbetreuern, Paketnutzern, Paketunterstützern und -sponsoren sowie tea-Tasters steeped tea-Tokens dar, geteilt durch den Gesamtbestand an tea-Tokens. -In Anbetracht der Anzahl der heute verfügbaren Open-Source-Pakete und ihres erwarteten Wachstums, wird $\chi$ immer ein sehr kleiner Wert zwischen $0$ und $1$ sein. - - -**Sei $\psi$ das staking verhältnis. -Sie stellt die Gesamtzahl der tea-Tokens dar, die jeder Netzwerkteilnehmer zur Sicherung des Netzwerks einsetzt. - -$\chi_{ideal}$ sei das Steeping-Verhältnis, das jedes Paket erreichen soll, um eine faire Verteilung der Belohnungen auf alle Pakete und ihre Abhängigkeiten zu erreichen. -Der Wert von $\chi_{ideal}$ muss aktualisiert werden, wenn neue Pakete zur dezentralen Registrierung hinzugefügt und Abhängigkeiten geschaffen werden. -Um den besten Wert für $\chi_{ideal}$ zu bestimmen, werden wir eine Popularitäts-Glockenkurve verwenden, die zu Beginn jedes Reward-Zyklus aktualisiert wird. - -Sei $\tau = \tau(\chi)$ der jährliche Steeping-Zinssatz, der an alle Mitglieder der tea-Community verteilt wird, die tea-Token steepen, um Open-Source-Entwickler zu unterstützen. -Mit anderen Worten: $\tau(\chi)$ entspricht der Steeping-Belohnung, die ein Community-Mitglied, das ein ganzes Jahr lang tea-Token steeps, über ein Jahr hinweg erhält. - -Sei $\gamma = \gamma(\psi)$ der jährliche staking Zinssatz , der an alle Knotenbetreiber und Netzwerkteilnehmer verteilt wird, die tea-Tokens zur Sicherung des Netzwerks einsetzen. -Mit anderen Worten: $\gamma(\psi)$ entspricht der staking-belohnung, die ein Mitglied der Gemeinschaft, das ein ganzes Jahr lang tea-Tokens staked, über ein Jahr hinweg erhält. - -$\delta$ sei die jährliche Inflation, die in die Kasse des Netzwerks fließt. -$\delta$ kann variieren, da externe Faktoren das Token-Angebot beeinflussen. - -Wir betrachten die jährliche Steeping-Belohnungsrate als eine Funktion von $\chi$ und die jährliche Staking-Belohnungsrate als eine Funktion von $\psi$. - -* $\tau(\chi)$ entspricht dem Anreiz für die Leute, ein Paket zu steepen. -Je höher $\chi$ ist, desto weniger Belohnungen $\tau(\chi)$ werden benötigt. -* $\gamma(\psi)$ entspricht dem Anreiz für die Leute, das Netz zu staken. -Wenn $\psi$ steigt, werden weniger Belohnungen $\gamma(\psi)$ benötigt, um das Netz zu sichern. - -Die jährliche Inflation $I$ entspricht $(\tau + \gamma + \delta)$ und berechnet sich wie folgt: - -$$ -I = \frac{\textrm{Tokenvorrat am Ende des Jahres} - \textrm{Tokenvorrat am Anfang des Jahres}}{\textrm{Tokenvorrat am Anfang des Jahres}} = (\tau + \gamma + \delta) -$$ - -Der Beitrag zur Inflation von $\tau_{\textsc{all}}$ (Anreiz, der an alle Paket-steepers verteilt wird) und $\gamma_{\textsc{all}}$ (Anreiz, der auf alle Teilnehmer an der Netzsicherheit verteilt wird) sollte abgewogen werden, um sicherzustellen, dass das System das optimale Verhältnis zwischen Steeping und Staking anreizt. - -Da wir uns auf die Anreize konzentrieren, die auf alle Steepers verteilt sind, stellen wir fest, dass -$\tau_{\textsc{all}}$ -eine Funktion des Steeping-Verhältnisses $\chi$ ist und somit -$\tau_{\textsc{all}}(\chi) = \chi \cdot \tau(\chi)$. -Aus unserer vorangegangenen Analyse können wir erkennen, dass -$\tau_{\textsc{all}}(\chi_{ideal}) = \chi_{ideal} \cdot \tau_{ideal}$. -Da das Ziel darin besteht, einen Zustand zu erreichen, in dem -$\chi = \chi_{ideal}$ -ist, belohnt -$\tau_{ideal}(\chi)$ -bei diesem Wert maximal sein. - -Sei $\tau_{ideal} = \tau(\chi_{ideal})$ -die Belohnungsrate, die das Netzwerk im idealen Szenario liefert, in dem -$\chi = \chi_{ideal}$. - -Sei $\tau_{0}$ der Grenzwert von $\tau_{\textsc{all}}(\chi)$, da $\chi$ gegen Null geht, wenn kein Mitglied der teagemeinschaft irgendwelche Pakete steeped. -Der Wert von $\tau_{0}$ sollte nahe bei Null, aber nicht bei Null liegen, um Anreize für frühe Anwender zu schaffen. -Wie in der Forschung der web3 Foundation vorgeschlagen, schlagen wir vor, dass: - -* die Inflationsfunktion zwischen $\chi = 0$ und $\chi = \chi_{ideal}$ linear wächst, und -* sie zwischen $\chi = \chi_{ideal}$ und $\chi = 1$ exponentiell abnimmt. - -Wir haben eine ähnliche exponentielle Abnahme für $\tau_{\textsc{all}}(\chi)$ gewählt, weil sie eine exponentielle Abnahme von $\tau(\chi)$ impliziert, und wir wollen, dass die Belohnungen jenseits von $\chi_{ideal}$ stark abfallen, um zu verhindern, dass ein einziges Paket alle Belohnungen erhält. - -Der Zerfall ist so definiert, dass die Inflationsrate um höchstens 50% abnimmt, wenn $\chi$ sich um $d$ Einheiten nach rechts von $\chi_{ideal}$ verschiebt - d.h. -$\tau_{\textsc{all}}(\chi_{ideal} + d) \geq \tau_{\textsc{all}} \cdot 0.5$. - -Wir schlagen die folgenden Zins- und Inflationsratenfunktionen vor, die von den Parametern $\chi_{ideal}$, $\tau_{ideal}$, $\tau_{0}$ und $d$ abhängen. - -\begin{align*} -&\tau_{\textsc{all}}(\chi) = \tau_{0} + (\tau_{\textsc{all}}(\chi_{ideal}) - \tau_{0})\frac{\chi}{\chi_{ideal}}\enspace\textrm{for}\;0 < \chi \leq \chi_{ideal} \\ -&\tau_{\textsc{all}}(\chi) = \tau_{0} + (\tau_{\textsc{all}}(\chi_{ideal}) - \tau_{0}) \cdot 2^{(\chi_{ideal}-\chi)/d}\enspace\textrm{for}\;\chi_{ideal} < \chi \leq 1 -\end{align*} - -Genauso wie gute Akteure belohnt werden müssen, müssen schlechte Akteure identifiziert und bestraft werden. -Open-Source-Software bietet böswilligen Akteuren viele Möglichkeiten, einer ganzen Gemeinschaft von Entwicklern Schmerzen und Reputationsrisiken zu bereiten. -Von der widerrechtlichen Aneignung von Arbeit über die Veränderung und Weitergabe von Softwarepaketen bis hin zur Einschleusung von bösartigem Code - der Krieg zwischen guten und bösen Akteuren geht weiter, oft mit gut finanzierten bösen Akteuren, die in der Verunreinigung von Open-Source-Paketen eine Chance sehen, finanziell zu profitieren. -Die Nachteile sind relativ gering, da die Pakete möglicherweise aus den digitalen Regalen verbannt werden oder einen schlechten Ruf haben. - -Wir schlagen vor, einen Slashing-Mechanismus einzuführen, um einen materielleren Nachteil zu schaffen, der sich direkt auf den wirtschaftlichen Wert der bösen Akteure auswirkt. -Da tea-Tasters den Code in neu eingereichten Paketen bewerten und analysieren, schlagen wir vor, dass tea-Tasters die Werkzeuge und Anreize erhalten, um ruchlosen Code zu identifizieren und hervorzuheben, damit Paketnutzer auf die Risiken aufmerksam gemacht werden können und Paketbetreuer, Paketunterstützer und Sponsoren für das Einreichen oder Unterstützen von ruchlosem Code bestraft werden. -Insofern sollte der Paket-Maintainer für alle nachweislich negativen Bewertungen, die gemäß den Netzwerkregeln durchgeführt wurden und auf die der Paket-Maintainer innerhalb des von der Verwaltung festgelegten Zeitraums reagiert hat, nicht bestraft werden, im Gegensatz zu den Paketunterstützern und -sponsoren oder den tea-Tasters, die eine positive Bewertung des fraglichen Pakets abgegeben haben. -Für negative Bewertungen, die gemäß den Netzwerkregeln durchgeführt werden und die der Paketbetreuer nicht innerhalb des von der Governance definierten Zeitraums angesprochen hat, wird ein Bruchteil der Token, die vom Paketbetreuer, den Paketunterstützern und -sponsoren sowie früheren tea-Tasters steeped sind, slashed. -Ein weiterer Teil fließt in einen Versicherungspool, der von der tea Governance kontrolliert wird. -Die tea Governance wird in enger Zusammenarbeit mit der Gemeinschaft Richtlinien und Regeln aufstellen, um den Inhalt des Pools an die von Schwachstellen Betroffenen zu verteilen. -Das Protokoll verteilt einen dritten Teil der steeped Token an alle tea-Tasters, die zu der negativen Bewertung beigetragen und gegen das Paket steeeped haben, basierend auf der Anzahl der Token, die sie "gegen" das Paket steeped haben, und wie lange ihre Token getränkt wurden. -Mit anderen Worten: Je eher ein oder mehrere tea-Taster den Fehler identifizieren und gemäß den Regeln des Netzwerks melden, desto höher ist die Belohnung, die sie für die Unterstützung einer sicheren und produktiven Open-Source-Entwicklung erhalten. - -Um zu verhindern, dass Mitglieder der Gemeinschaft wahllos gegen stark steeped Pakete stimmen, in der Hoffnung, die Mehrheit der Strafe zu erhalten, werden alle tea-Tokens, die "gegen" steeped wurden, nicht mit Inflation belohnt und können einem Verfallsmechanismus unterliegen, wodurch ihr Wert mit der Zeit sinkt. - -[^19]: Source: @web3 - - -# Die Governance - -Governance ist entscheidend für die Entwicklung, Nachhaltigkeit und Akzeptanz eines jeden verteilten Systems. - -Wir schlagen vor, dass tea eine On-Chain-Governance beinhaltet, bei der alle tea-Token-Inhaber Änderungen an kritischen Parametern, die nach Token-Besitz und Reputation gewichtet sind, vorschlagen und darüber abstimmen können. -Zu diesen Parametern könnten Inflation, Transaktionsgebühren, Staking-Belohnungen, Steeping-Belohnungen oder das optimale Steeping-Verhältnis gehören. -Mit dieser Funktion wird sichergestellt, dass kritische Parameter im Laufe der Zeit von den Mitgliedern der tea-Community weiterentwickelt und optimiert werden können. -Wir gehen davon aus, dass die Governance mit einer einfachen Struktur startet und mit zunehmender Reife des teasystems schrittweise erweitert wird, um die Akzeptanz zu erleichtern und eine fortschreitende Dezentralisierung zu gewährleisten. - -Einige Systemparameter unterliegen möglicherweise nicht der Governance oder unterstützen hochfrequente Änderungen, um die Angriffsfläche der Governance zu verringern. -Ein schrittweiser Übergang von Parametern zu offener, dezentraler Governance wird die Stabilität und Vorhersehbarkeit des Systems gewährleisten. - - -# Erweiterbarkeit durch Drittanbieter - -Während wir die ersten Tools entwickeln, um die längst überfällige Unterstützung der Open-Source-Gemeinschaften zu gewinnen, sehen wir es als Teil unserer Aufgabe an, sicherzustellen, dass Dritte das gesamte Toolset erweitern können. -Neben der Bereitstellung der Infrastruktur für Entwickler zur Erstellung von Erweiterungen des Protokolls, einschließlich neuer Möglichkeiten zur Innovation und zur Förderung der Unterstützung von Open-Source-Entwicklern, sehen unsere Pläne auch die Möglichkeit vor, dass andere Paketmanager zum Protokoll beitragen. -Die Träume und Bemühungen von Open-Source-Entwicklern haben die Innovationen hervorgebracht, die unser tägliches Leben unterstützen. -Wir freuen uns darauf, die neuen Verwendungsmöglichkeiten und Erweiterungen für tea zu entdecken, die von der teagemeinschaft vorgeschlagen werden. - -# Künftige Arbeiten und potenzielle Gemeinschaftsanstrengungen - -Wir gehen davon aus, dass die Gemeinschaft in dem Maße, in dem das teasystem reift, über -Änderungen und Erweiterungen des teasystems mitbestimmen und mitgestalten. Nachfolgend sind -einige Ideen, von denen wir glauben, dass sie einige inspirieren können. - -## tea-Großhändler - -Open-Source-Software-Gemeinschaften sind lebendig und ständig auf der Suche nach Innovation und Wertschöpfung. -Diese Hingabe und dieser Altruismus führen dazu, dass ständig neue Software und Pakete entwickelt werden, von denen jedes einzelne Abhängigkeiten mit sich bringt. -Wir gehen davon aus, dass sich die Karte der Abhängigkeiten ständig weiterentwickeln wird, was zu häufigen Änderungen des Weichenverhältnisses und der Belohnungen führen wird. -In Zukunft könnte die tea-Community die Entwicklung eines Systems vorschlagen, das das Steeping-Verhältnis für jedes Paket dynamisch überwacht und das Steeping-Verhältnis für die Unterstützer von Paketen anhand ihrer eigenen Kriterien neu ausbalanciert. - -## Lizenzgebühren für die Übertragung von Paketen - -Wir erkennen an, dass Paketverwalter beschließen können, ihren Steeping Rewards Stream an einen oder mehrere Entwickler zu übertragen. -Die Verwaltung einer solchen Übertragung muss die Entscheidung des Paketbetreuers und seiner Partner bleiben, ohne Einmischung von tea. -Es müssen Werkzeuge zur Verfügung gestellt werden, damit eine solche Übertragung vollständig oder teilweise erfolgen kann (vielleicht indem nur ein Teil der Steeping Rewards an einen oder mehrere Entwickler weitergeleitet wird, während die restlichen Rewards weiterhin an den ursprünglichen Paket-Maintainer fließen) -und dass die Steeping Rewards über ein einziges Konto fließen, das von einem einzigen Netzwerkteilnehmer kontrolliert wird, über mehrere Netzwerkteilnehmer oder automatisch über mehrere Konten unter Verwendung statischer oder dynamischer Verhältnisse verteilt werden können. - -## Verteilung von Belohnungen auf mehrere Verwalter - -Die Wartung eines Pakets kann sich auf die Arbeit eines weiteren Entwicklerteams stützen. -Bevor Steeping Rewards zu fließen beginnen, sollten Teams in Betracht ziehen, die Verteilung von Steeping Rewards untereinander zu automatisieren. -Wie die Verteilung erfolgt, muss von den Maintainer selbst entschieden werden, da sie am besten einschätzen können, wer einen Beitrag geleistet hat und wie dieser belohnt werden sollte. - -Um dies zu erreichen, könnte jedes Team (oder Teams) seine eigene dezentrale autonome Organisation (DAO) einrichten und entweder die Verteilung der Belohnungen automatisieren oder komplexere Systeme einsetzen, um die angemessene Verteilung der Belohnungen auf der Grundlage externer Faktoren wie einer Abstimmung aller DAO-Mitglieder zu bestimmen, oder zeitbasierte Verteilungen auf der Grundlage von kontinuierlichen Beiträgen, erfolgreichem Abschluss von Kopfgeldern usw. - -## Handhabung des Pakets "Forks" - -Wir sind der Meinung, dass Forks unerlässlich sind und weitgehend unzureichend genutzt werden. -Forks können ein effektives Werkzeug für die Entwicklung von Paketen sein, die in Bezug auf Funktionalität, Leistung, Sicherheit und sogar Aufmerksamkeit konkurrieren. -So nützlich sie auch sein mögen, Forks müssen die ursprünglichen Bemühungen anerkennen. -Durch künftige Arbeiten oder potenzielle Beiträge könnte die tea-Gemeinschaft das System dahingehend verbessern, dass Forks deklariert werden müssen, vielleicht sogar erkannt werden, wenn ein Paket eingereicht wird. -Nicht deklarierte Forks, die von tea-Taster aufgedeckt werden, können dazu führen, dass ein Teil der steeped Tokens gestrichen, an den ursprünglichen Paket-Maintainer übertragen und an die tea-Taster, die den Fork aufgedeckt haben, geschickt wird. - -## Laufzeit- vs. Build-Abhängigkeiten - -tea darf bei der Verteilung von Steeping Rewards beim Start nicht zwischen Build-Abhängigkeiten und Laufzeit-Abhängigkeiten unterscheiden. -Wenn die tea-Gemeinschaft jedoch eine solche Unterscheidung für wichtig hält, kann sie Verbesserungen des Verteilungsalgorithmus für Steeping Rewards vorschlagen, um die Kritikalität jeder Abhängigkeit und ihren Beitrag zum Wert der Pakete, die von ihr abhängen, zu berücksichtigen. -Über diese Vorschläge würde abgestimmt und sie würden auf der Grundlage der Entscheidung der Gemeinschaft umgesetzt. - -## Nutzungsabhängige Vergütung - -Wenn mehr Anwendungen unter Verwendung von Paketen erstellt werden, die mit tea registriert sind, kann die Gemeinschaft den Reward-Algorithmus so erweitern, dass die Zuteilung durch externe, bestätigte Datensätze wie die Nutzung beeinflusst werden kann. -Diese Aktualisierung des Reward-Mechanismus könnte eine höhere Zuteilung von tea-Token-Rewards an Pakete mit der höchsten Nutzung ermöglichen, während die Einschränkungen des Steeping-Verhältnisses, die im Abschnitt über tea-Token beschrieben werden, weiterhin eingehalten werden. -Paketverwalter könnten einen ähnlichen Ansatz verwenden, um Steeping Rewards über ihre Abhängigkeiten zu verteilen, basierend auf der transparenten Logik ihrer Wahl. -Beachten Sie, dass alle Informationen, die verwendet werden, um die Verteilung von Belohnungen auf Pakete und Abhängigkeiten im teasystem zu beeinflussen, nachweislich zuverlässig sein müssen. - - -# Anerkennungen - -Dieses Whitepaper würde ohne die Unterstützung und das Engagement vieler teaophiler nicht existieren. -Die Autoren möchten Josh Kruger, Jadid Khan und Jacob Heider für ihren Beitrag zu den Tokenomics und den vielen diskreten Personen danken, die freiwillig ihre Zeit opferten, um Feedback zum Inhalt dieses Dokuments zu geben. - -$\parskip=0pt plus 1pt$ - -# Glossar der Begriffe - -| Begriff | Definition | -|------|------------| -| Leaf | Die kleinste Stückelung der tea-Token. Ein Leaf entspricht einem Hundertmillionstel ($10^{-8}$) eines teas. | -| Slashing | Die Bestrafung von Steepern oder Stakern als Reaktion auf ein Verhalten, das den Netzregeln zuwiderläuft. | -| Staking | Das Sperren von tea-Token, um das Proof-of-Stake-Netzwerk, auf dem das teasystem aufbaut, zu sichern. | -| Steeping | Die Aktion des Sperrens von tea-Tokens, um Ihren Anspruch zu unterstützen und Belohnungen (oder Strafen) zu erhalten, die auf dem Konsens über die Gültigkeit Ihres Anspruchs basieren. | - - -# Referenzen diff --git a/i18n/id/white-paper.md b/i18n/id/white-paper.md deleted file mode 100644 index 4cc11b8..0000000 --- a/i18n/id/white-paper.md +++ /dev/null @@ -1,582 +0,0 @@ -# Penafian - -Informasi yang ditetapkan dalam buku putih ini bersifat pendahuluan. -Akibatnya, baik penulis maupun afiliasinya masing-masing tidak bertanggung jawab bahwa informasi yang ditetapkan di sini adalah final atau benar dan masing-masing penyangkalan di atas, -sejauh diizinkan oleh hukum yang berlaku, setiap dan semua kewajiban baik yang timbul dalam gugatan, kontrak, atau lainnya sehubungan dengan buku putih ini. -Buku putih ini maupun apa pun yang terkandung di sini tidak boleh menjadi dasar atau diandalkan sehubungan dengan atau bertindak sebagai bujukan untuk mengadakan kontrak atau komitmen apa pun. - -Tidak ada dalam kertas putih ini yang merupakan tawaran untuk menjual atau ajakan untuk membeli token yang dibahas di sini. -Dalam keadaan apa pun, jika buku putih ini dianggap sebagai tawaran atau ajakan semacam itu, tidak ada tawaran atau ajakan seperti itu yang dimaksudkan atau disampaikan oleh buku putih ini di yurisdiksi mana pun yang melanggar hukum untuk melakukannya, -di mana tawaran atau ajakan semacam itu memerlukan lisensi atau pendaftaran, atau di mana tawaran atau ajakan semacam itu tunduk pada pembatasan. -Secara khusus, setiap token yang dibahas di sini belum, dan, sejak tanggal penerbitan buku putih ini, tidak dimaksudkan untuk didaftarkan di bawah sekuritas atau undang-undang serupa di yurisdiksi mana pun, -apakah yurisdiksi tersebut menganggap token tersebut sebagai sekuritas atau instrumen serupa dan tidak boleh ditawarkan atau dijual di yurisdiksi mana pun di mana melakukannya akan merupakan pelanggaran terhadap undang-undang yang relevan dari yurisdiksi tersebut. - -# Lisensi - -Kode sumber[^src] makalah ini tersedia di bawah lisensi Creative Commons Attribution-ShareAlike 4.0 International[^cc]. - -[^src]: See: @sources -[^cc]: See: @cc - - -# Pengantar - -Internet sebagian besar terdiri dari proyek-proyek open-source dan telah sejak awal. -Seiring waktu, banyak dari proyek ini telah menjadi bagian dasar di mana semua inovasi masa depan dibangun. -Dan sementara kekayaan telah dibuat darinya, sumber terbuka terutama dibuat dan dipelihara tanpa kompensasi. - -Kami percaya bahwa keseluruhan upaya manusia modern telah terhambat dengan mengandalkan persentase terkecil dari insinyur dunia untuk memilih antara gaji atau menjaga Internet tetap berjalan. -Sumber terbuka adalah pekerjaan cinta yang sering terhalang oleh kurangnya insentif ekonomi yang berarti sehingga proyek yang benar-benar bermanfaat tidak pernah mencapai potensi mereka sementara yang lain menderita masalah keamanan karena kurangnya insentif untuk memelihara perangkat lunak sepanjang siklus hidupnya. -Untuk sepenuhnya menyadari potensi kami, kami membutuhkan sistem remunerasi yang adil untuk ekosistem open-source yang tidak secara mendasar mengubah cara ia dibangun atau digunakan. - -Perusahaan sering membungkus model bisnis di sekitar sumber terbuka, menghasilkan pendapatan langsung dari pekerjaan pengembang yang baik hati sambil juga mengandalkan mereka untuk memperbaiki bug saat masalah terjadi. -Contoh yang bagus adalah insiden baru-baru ini yang melibatkan kerentanan keamanan kritis di Log4j, sebuah paket dari Apache Software Foundation yang ditemukan di banyak perangkat lunak dan layanan komersial yang digunakan oleh perusahaan dan pemerintah. -Pada November 2021, seorang peneliti keamanan yang bekerja untuk Alibaba Group Holding Ltd. melaporkan kerentanan CVE-2021-44228[^1], yang menerima skor dasar setinggi mungkin dari Apache Software Foundation. -Amit Yoran, Kepala Eksekutif Tenable dan direktur pendiri Tim Kesiapan Darurat Komputer Amerika Serikat (US-CERT), menggambarkan kerentanan ini sebagai "kerentanan tunggal terbesar dan paling kritis dalam dekade terakhir"[^2]. -Kepanikan terjadi dan beberapa sukarelawan yang mempertahankan paket ini mendapat kecaman publik karena kegagalannya. -Setelah mengatasi kemarahan dengan permohonan sederhana untuk keadilan, sistem ditambal. -Perusahaan dan pemerintah akhirnya menyadari bahwa Log4j, sebuah paket yang digunakan oleh berbagai sistem kritis selama dua dekade, dikelola oleh beberapa sukarelawan yang tidak dibayar, pahlawan tanpa tanda jasa yang sama yang langsung beraksi meskipun ada penyalahgunaan dari industri[^3] dan bekerja tanpa lelah untuk mengatasi kerentanan. - -Sayangnya, Log4j jauh dari satu-satunya contoh. -core-js diunduh 30 juta kali per minggu sebagai basis dari setiap aplikasi Node.js, namun juga hampir tidak didanai. -Baru-baru ini beberapa pengembang inti bitcoin mengundurkan diri, dengan alasan, antara lain, *kurangnya kompensasi finansial* untuk keputusan mereka. - -Ada beberapa upaya untuk menyediakan struktur insentif, biasanya melibatkan sistem sponsor dan bounty. -Sponsor memungkinkan konsumen open-source untuk menyumbang ke proyek yang mereka sukai. -Namun, gambarkan sumber terbuka sebagai menara batu bata di mana lapisan bawah sudah lama dilupakan, tetapi masih dipertahankan oleh insinyur yang berdedikasi dan diandalkan oleh lebih banyak pengembang. -Hanya proyek di puncak menara yang biasanya diketahui dan menerima sponsor. -Pilihan yang bias ini menyebabkan batu bata penting yang menopang menara tidak menarik sumbangan, sementara favorit menerima lebih dari yang mereka butuhkan. -Bounty memungkinkan konsumen proyek untuk mengusulkan pembayaran bagi pengembang untuk membangun fitur tertentu, sehingga hanya memberi imbalan proyek untuk melakukan hal-hal yang belum tentu demi kepentingan terbaik mereka. -Dan sekali lagi, hanya favorit yang bermanfaat. - -Dalam makalah ini, kami mengusulkan teh — sistem terdesentralisasi untuk memberi imbalan yang adil kepada pengembang sumber terbuka berdasarkan kontribusi mereka terhadap seluruh ekosistem dan diberlakukan melalui algoritma insentif teh yang diterapkan di semua entri dalam registri teh. - -![Tampilan sederhana dari sistem hadiah seduhan teh.](img/figure-1.svg) - -$\parskip=0pt plus 1pt$ - -[^1]: Sumber: @nist -[^2]: Sumber: @reuters -[^3]: Sumber: @twitter - - -# Komponen - -Pengembang perangkat lunak yang membangun aplikasi membutuhkan empat hal: browser, terminal, editor, dan manajer paket. -Dari keempatnya, manajer paket adalah yang mengontrol perkakas dan kerangka kerja yang dibutuhkan pengembang untuk membangun produk mereka. -Lapisan ini adalah tempat kami melihat potensi untuk mengubah cara sumber terbuka digaji. - -## Manajer Paket - -Manajer paket mengetahui perangkat lunak sumber terbuka apa yang bergantung pada aplikasi untuk berfungsi, dari atas menara hingga dasarnya. -Setiap komponen dan versi yang penting untuk aplikasi diketahui dan direkam. -Ia tahu bahwa bagian atas menara dengan hati-hati memilih ketergantungannya dan bahwa pemilihan yang cermat berlanjut ke bawah. -Manajer paket ditempatkan secara unik di tumpukan alat pengembang untuk memungkinkan distribusi nilai otomatis dan tepat berdasarkan penggunaan dunia nyata yang sebenarnya. - -Kami mengusulkan registri terdesentralisasi yang tidak dapat diubah yang dirancang untuk mendistribusikan nilai berdasarkan algoritme yang menentukan kontribusi setiap entri terhadap utilitas dan kesehatan sistem. -Nilai dapat memasuki grafik pada titik puncak—aplikasi dan pustaka penting—dan didistribusikan ke dependensi titik puncak tersebut dan dependensinya secara rekursif karena registri mengetahui seluruh grafik sumber terbuka. - -Selain itu, kami percaya bahwa informasi material harus tersedia melalui manajer paket agar pengembang dapat menilai apakah mereka dapat mempercayai sebuah paket dan pembuatnya. -Informasi ini mungkin didasarkan pada reputasi, pujian komunitas, data yang diambil dari sistem identitas terdesentralisasi (DID[^4]), manajer paket lain, atau mekanisme insentif yang berpotensi mengandalkan peserta jaringan yang membahayakan nilai ekonomi. - -Kami memperkirakan bahwa kombinasi alat, informasi, dan penghargaan teh akan secara adil memberi insentif kepada pengembang, membantu merangsang pertumbuhan perangkat lunak sumber terbuka dan mendorong inovasi. - -[^4]: See: @w3 - -## Registri Terdesentralisasi - -Setiap manajer paket memiliki registri paketnya sendiri yang menduplikasi metadata yang sama berulang kali. -Sudah saatnya ada registri tunggal, komprehensif dan definitif yang dirancang dan diatur oleh komunitas yang bergantung padanya. -Registri yang terdesentralisasi dan tidak dapat diubah ini dapat memberikan keamanan, stabilitas, dan pencegahan -niat jahat. - -Internet berjalan pada puluhan ribu komponen sumber terbuka yang vital. -Sungguh luar biasa bahwa sejauh ini, insiden yang disebabkan oleh penghapusan infrastruktur sumber terbuka yang penting sangat minim. -Yang paling terkenal adalah penghapusan ketergantungan NPM left-pad[^5] pada tahun 2016, yang mengalir ke dalam integrasi berkelanjutan dan sistem penerapan berkelanjutan yang membuat pengembang tinggi dan kering selama berhari-hari. -Peristiwa ini menunjukkan bahwa Internet itu sendiri didasarkan pada sistem pembangunan yang rapuh. -Contoh lain melibatkan partisipasi aktif atau disengaja dari pengelola paket yang menyabotase paket populer mereka (Lihat colors.js, faker.js[^6], dan node-ipc[^7]), -atau aktor jahat yang mencari untung dengan berpura-pura membantu memelihara paket dan merusaknya untuk mencuri, misalnya, kunci pribadi Bitcoin (Lihat aliran peristiwa[^8]), -atau paket berbahaya dengan kesalahan ejaan yang disengaja, juga dikenal sebagai salah ketik, -dengan harapan mengelabui pengguna agar menginstalnya, misalnya paket NPM crossenv vs. cross-env[^npmjsCrossenv]. - -Integritas perangkat lunak perlu dijamin seiring kemajuan industri menuju masa depan di mana aset digital merupakan bagian dari perangkat lunak. -Kami tidak dapat terus membiarkan diri kami rentan terhadap pelaku jahat yang memodifikasi perangkat lunak. - -Sebagian besar alat yang kami sebut manajer paket tidak dapat menjamin bahwa paket yang ada di dalam aplikasi dan dApps ini adalah kode sumber terbuka yang tidak diubah yang diterbitkan oleh penulis aslinya. -GitHub Microsoft telah menemukan bahwa 17% kerentanan dalam perangkat lunak ditanam untuk tujuan jahat[^9], dengan beberapa sisanya tidak terdeteksi untuk waktu yang lama (Lihat Webmin 1.890[^10]). - -Registri terdesentralisasi ditambah dengan sistem reputasi dan didukung oleh insentif ekonomi yang dirancang untuk mengekspos pelaku buruk dan memberi penghargaan kepada pelaku yang baik dapat memberikan jaminan yang telah dicari oleh komunitas pengembang. - -[^5]: Sumber: @theregister -[^6]: Sumber: @fossa -[^7]: Sumber: @lunasec -[^8]: Sumber: @github -[^npmjsCrossenv]: Sumber: @npmjsCrossenv -[^9]: Sumber: @zdnet -[^10]: Sumber: @threatpost - - -## Sistem Penyimpanan - -Paket sumber terbuka memberikan berbagai fungsionalitas, beberapa di antaranya mungkin dibatasi atau tidak diinginkan. -Enkripsi adalah contoh yang sangat baik untuk itu. -Kasus penggunaan penting untuk enkripsi adalah dukungan privasi individu di seluruh dunia. -Enkripsi, bagaimanapun, juga dapat digunakan untuk tujuan jahat (lihat Phantom Secure, dibongkar oleh lembaga penegak hukum pada Maret 2018[^11]) atau dapat dikompromikan untuk mendukung kegiatan penegakan hukum (Lihat Operasi Ironside (AFP), Operasi Greenlight (Europol ), -dan Operation Trojan Shield (FBI)[^12] di mana FBI mengoperasikan platform komunikasi "terenkripsi", AN0M, dan meyakinkan para penjahat untuk menggunakan ponsel "terenkripsi" mereka untuk komunikasi yang aman). - -Aplikasi luas Enkripsi telah menjadikannya kasus penggunaan yang sempurna untuk perangkat lunak sumber terbuka dan contoh yang bagus bahwa solusi apa pun yang menyimpan paket harus tahan terhadap kerusakan dan sensor. -tea adalah protokol terdesentralisasi yang tidak bermaksud memfilter atau menyetujui paket berdasarkan fungsinya. -Sementara tata kelola teh dapat memilih untuk menghapus paket berbahaya yang terbukti (lihat bagian tata kelola untuk informasi lebih lanjut), sangat penting bagi sistem teh untuk terhubung dengan beberapa sistem penyimpanan, termasuk yang terdesentralisasi yang menunjukkan bahwa sebuah paket tidak diubah dan direplikasi dengan benar. -Pengelola paket dapat memilih sistem penyimpanan yang paling sesuai dengan kebutuhan mereka untuk menyimpan dan mendistribusikan paket mereka dengan aman. - -[^11]: Sumber: @fbi -[^12]: Sumber: @europol - -# Peserta Jaringan - -misi tea adalah untuk memberdayakan komunitas sumber terbuka dan memastikan kontributor mereka didukung saat mereka membuat alat yang membangun Internet. -Dalam buku putih ini, kami membedakan peserta melalui kontribusi mereka. -Beberapa mungkin menyumbangkan kode atau memverifikasi kode yang disumbangkan. -Orang lain mungkin memberikan nilai ekonomi untuk mendukung pengembang dan reputasi mereka. - -## Pengelola Paket - -Pengelola paket harus memastikan perangkat lunak mereka terus memberikan peningkatan nilai seiring perkembangan industri. - -teh mengasumsikan bahwa pembuat paket mempertahankan pekerjaan mereka. -Pengelola paket adalah pilar komunitas sumber terbuka yang perlu diberdayakan dan diberi penghargaan atas kontribusi berkelanjutan mereka. -Pengelola paket dapat memutuskan untuk menghentikan upaya pemeliharaan mereka atau menyadari bahwa mereka tidak dapat beroperasi pada kecepatan yang sesuai dengan harapan pengguna paket. -Pengelola paket menerima token non-fungible (NFT) saat mereka menyelesaikan pengiriman paket (lihat bagian NFT pengelola untuk detail tambahan). -NFT ini digunakan untuk membuktikan pekerjaan mereka dan merupakan kunci yang mengarahkan penghargaan teh. -Pemegang NFT paket dapat mentransfer kepemilikannya ke pengembang lain (atau grup pengembang), sehingga menjadikan mereka pengelola paket dan penerima hadiah di masa mendatang. -Demikian pula, seorang pengembang dapat memutuskan untuk mengambil peran sebagai pengelola paket dengan melakukan forking pada paket yang ada dan mengirimkan yang baru yang akan mereka pertahankan ke depan, sehingga menjadi pembuat dan pengelola paket itu sendiri. - -Sangat penting untuk menyediakan komunitas pengembang dengan alat yang tepat untuk menentukan paket mana yang dipertahankan dan reputasi serta kualitas pekerjaan pengelola masa lalu dan sekarang. -Kami terlalu sering melihat pekerjaan open-source dirusak dan upaya banyak orang dirusak oleh aktor jahat. -Meskipun pekerjaan aktor jahat ini sebagian besar ditemukan dan diperbaiki, seringkali tidak sampai kerusakan signifikan telah terjadi melalui kehilangan keuangan atau data. -Ambil contoh paket EventStream npm[^13] yang diunduh lebih dari 1,5 juta kali per minggu dan diandalkan oleh lebih dari 1.500 paket ketika seorang peretas berhasil menembus proyek sumber terbuka, -dapatkan kepercayaan dari pembuat aslinya dan ubah EventStream agar bergantung pada paket berbahaya yang akan mengekstrak kredensial dompet bitcoin ke server pihak ketiga\. -Meskipun alat dapat membantu mendeteksi beberapa serangan ini, mereka tidak selalu dapat diandalkan, yang membuat seluruh komunitas bergantung pada ketekunan dan kesediaan satu sama lain untuk berbagi temuan mereka. - -Kami mengusulkan untuk memperkenalkan insentif melalui token teh yang dijelaskan di bagian token teh, mendorong komunitas sumber terbuka untuk melaporkan temuan mereka secara konstruktif, sehingga pengelola paket dapat mengatasinya sebelum dieksploitasi. - -[^13]: Sumber: @medium - -## Pengguna Paket - -Pengguna paket adalah pengembang perangkat lunak yang berfokus pada pemecahan masalah tertentu. -Mereka sering mencari di komunitas sumber terbuka untuk alat yang mereka butuhkan untuk bereksperimen dengan cepat dan beralih dengan sangat sedikit atau tanpa biaya, yang secara langsung mendapat manfaat dari pekerjaan pembuat dan pengelola paket. -Secara tradisional, subset mungkin telah memilih untuk mendukung pengelola paket melalui donasi atau bentuk remunerasi lainnya; namun, hal ini jarang terjadi. - -Sponsor dapat menjadi sistem yang efektif untuk mendukung pengembangan sumber terbuka; namun, remunerasi biasanya tidak mencakup semua dependensi. -Keterbatasan ini menguntungkan favorit dan menghalangi inovasi dan pembuatan perangkat lunak. -Untuk berjuang sebagai dasar pengembangan perangkat lunak, sumber terbuka harus memberdayakan semua pengembang, baik pemula atau ahli, di semua lapisan di menara. - -tujuan teh adalah untuk mempertahankan nilai-nilai inti dari perangkat lunak sumber terbuka sambil menyediakan sistem terdesentralisasi untuk memberi imbalan kepada pengelola paket untuk pekerjaan mereka. -Untuk mewujudkan misi ini, teh bermaksud untuk mengembangkan — dan memberi insentif kepada orang lain untuk mengembangkan — mekanisme bagi pengguna paket untuk mendukung pengelola paket melalui kasus penggunaan token teh yang unik, seperti yang dijelaskan dalam token teh dan pekerjaan masa depan dan bagian upaya komunitas potensial. - -## Paket Pendukung dan Sponsor - -Di Web 2.0 dan web3, pendukung paket sering disebut "sponsor". Mereka adalah organisasi atau pengguna paket yang menggunakan perangkat lunak sumber terbuka untuk membangun produk komersial mereka, dermawan yang ingin mendukung ekosistem, atau pengusaha yang ingin mendanai tim untuk mengembangkan komponen sistem yang lebih besar. - -tea mengusulkan untuk memperluas komunitas pendukung paket ke seluruh komunitas teh, baik organisasi, pengembang, pengguna, atau penggemar teknologi. -tujuan teh adalah untuk menerapkan mekanisme insentif terdesentralisasi melalui kasus penggunaan unik dari token teh untuk setiap anggota komunitas teh untuk berkontribusi pada keberlanjutan abadi dan pertumbuhan sumber terbuka yang berkelanjutan. -Pendukung dan sponsor paket bebas memutuskan paket atau pengelola paket mana yang ingin mereka dukung berdasarkan pekerjaan, keyakinan, atau kriteria dan metrik apa pun yang akan memengaruhi keputusan mereka. -Selain itu, dukungan yang diberikan oleh pendukung dan sponsor paket akan mengalir ke dependensi setiap paket, sehingga secara implisit memercayai pengelola paket untuk membuat pilihan yang baik tentang tumpukan mereka dan menggunakan informasi ini untuk berkontribusi pada reputasi mereka. - -Asalkan pengelola paket menawarkan layanan tersebut, pendukung dan sponsor paket dapat menerima NFT tingkat dukungan premium sebagai imbalannya, sehingga mendapat manfaat dari SLA yang dipercepat atau lisensi yang lebih fleksibel. -Selain itu, pendukung dan sponsor paket dapat memutuskan untuk mendukung paket atau pengelola paket dan secara otomatis mengalihkan semua atau sebagian dari hadiah mereka untuk memberi insentif kepada tim untuk membangun perangkat lunak sumber terbuka baru. -Dengan kata lain, paket tidak perlu ada agar teh mulai mengalir. -Proyek yang baru lahir dapat didukung sama seperti proyek yang lebih matang, yang selanjutnya mendorong lanskap sumber terbuka yang terus berkembang. - -## Pencicip teh - -Saat paket baru atau versi baru dari paket yang ada dirilis, validitas pekerjaan perlu dibuktikan. -Informasi ini sangat penting bagi pengguna paket untuk memutuskan apakah akan mempercayai paket dan pengelolanya atau tidak. -Dengan protokol teh, fungsi ini disediakan oleh pencicip teh. - -pencicip teh, biasanya, adalah pengembang perangkat lunak berpengalaman yang bersedia mendedikasikan sebagian waktu mereka untuk memeriksa klaim yang terkait dengan sebuah paket (fungsionalitas, keamanan, versi semantik[^14], akurasi lisensi, dll.) -dan mempertaruhkan reputasi dan nilai ekonomi mereka untuk menunjukkan hasil penelitian dan analisis mereka dan mendukung ulasan mereka. -pencicip teh menerima penghargaan atas ketekunan dan upaya mereka. -Di teh, kami menyebut "menyeduh teh Anda" tindakan mengunci token teh untuk mendukung ulasan Anda dan menerima hadiah (atau penalti) berdasarkan konsensus tentang validitas ulasan Anda. - -Seperti pendukung paket, pencicip teh dapat memengaruhi reputasi pengelola paket dan kemasan; namun, dampaknya lebih signifikan mengingat peran mereka dalam memvalidasi keamanan, fungsionalitas, dan kualitas paket. -pencicip teh juga perlu membangun reputasi mereka untuk mendukung klaim mereka. -Kualitas pekerjaan mereka dan nilai ekonomi yang mereka pertaruhkan saat ulasan mereka curam dikombinasikan dengan sumber data eksternal lainnya akan membangun reputasi masing-masing pencicip teh, membawa nilai lebih pada pekerjaan mereka. -Lihat bagian reputasi paket untuk detail selengkapnya tentang mekanisme yang digunakan untuk memengaruhi reputasi pengelola paket dan paket. - -[^14]: Lihat: @semver - -# Ikhtisar Protokol - -Desain protokol untuk menghargai kontribusi sumber terbuka penuh dengan tantangan. -Perangkat lunak sumber terbuka menurut definisinya terbuka untuk semua dan dapat, sebagai akibatnya, menjadi sasaran kesalahan atribusi, apropriasi, atau gangguan berbahaya. -Namun, komunitas open-source secara konsisten menunjukkan kesediaannya untuk menyoroti aktor yang baik dan mengekspos aktor yang buruk. -Secara historis, energi yang dihabiskan untuk meninjau dan mengomentari kontribusi pengembang lain sepenuhnya bersifat sukarela, meskipun pelaporan dan mempertahankan temuan mungkin memakan waktu dan sangat penting. - -Kami bermaksud membuat platform distribusi tanpa kepercayaan untuk aplikasi yang dijamin dengan reputasi dan insentif keuangan, karena kami yakin imbalan yang memadai untuk kontribusi sumber terbuka tidak akan berhasil tanpa sistem reputasi dan kemampuan anggota komunitas untuk mengomunikasikan temuan dan dukungan mereka (atau perbedaan pendapat) untuk paket atau karya pengembang. - -Kami harus menyediakan alat bagi pengembang untuk mengakses dan berkontribusi pada sistem reputasi ini. -Alat yang menyertakan akses visual dan programmable sederhana ke versi dan reputasi semua dependensi dalam paketnya. -Pemahaman yang jelas tentang anggota komunitas mana yang mendukung setiap paket dan berapa banyak token teh yang mereka minum akan berkontribusi pada reputasi setiap paket, sama seperti seberapa banyak pengelola paket menyeduh pekerjaan mereka mengomunikasikan seberapa besar mereka berdiri di belakang pekerjaan mereka. -Titik data gabungan ini akan membantu menginformasikan sistem reputasi untuk semua anggota komunitas dan memfasilitasi pilihan. -Karena peretasan paket EventStream tidak dilakukan melalui paket itu sendiri, tetapi melalui salah satu dependensinya, visibilitas di semua lapisan dependensi akan sangat penting untuk membangun sistem tanpa kepercayaan ini. -Namun, pertimbangan seperti biaya komputasi dan transaksi (“gas”) perlu diprioritaskan saat sistem dirancang dan dibangun. - -Tujuan kami adalah untuk memberi penghargaan kepada pengembang Web 2.0 dan web3. -Kerumitan dan spesifikasi setiap tumpukan membuatnya sehingga pelacakan instalasi dan penghapusan instalasi paket dapat dengan mudah menjadi korban satu atau lebih aktor jahat. -Itu termasuk "membeli" instalasi untuk meningkatkan angka secara artifisial. -Skenario yang lebih buruk akan memperkenalkan perubahan mendasar pada sifat perangkat lunak sumber terbuka dengan menciptakan gesekan yang tidak perlu dengan kunci lisensi atau mekanisme pelacakan penyebaran lainnya. -Untuk memberikan cakupan terluas, kami percaya bahwa penghargaan tidak boleh bergantung pada gagasan sederhana tentang pelacakan instalasi atau penghapusan instalasi, tetapi lebih pada mekanisme insentif yang mendorong pengiriman paket berkualitas dan pelaporan paket jahat atau berisiko tinggi. -Terakhir, banyak paket bergantung pada dependensi umum. -Misalnya, Lodash memiliki 151.209 tanggungan[^15] sedangkan kapur memiliki 78.854 tanggungan[^16] atau Log4js memiliki 3.343 tanggungan[^17]. -Karena lebih banyak paket dibuat menggunakan dependensi yang sama, bagaimana kita memastikan bahwa insentif didistribusikan secara adil dan merata? -Bagaimana kami memastikan bahwa dependensi yang paling banyak digunakan dihargai tanpa membuat paket dan pengembang baru atau yang baru muncul kelaparan? -Bagaimana kita memastikan bahwa sistem insentif tidak berakhir dengan mengarahkan pengembang dari bahasa khusus untuk memusatkan mereka di tempat yang insentifnya lebih baik? -Tetapi juga, sebagai pengembang, bagaimana kita mengidentifikasi paket dengan tanggungan paling banyak untuk membangun alternatif - versi paket ini yang lebih ramping, lebih efisien, dan memiliki kode yang lebih baik? -Saat minum teh, kami percaya bahwa kurangnya insentif telah menghambat evolusi perangkat lunak sumber terbuka. -Didukung oleh insentif dan penghargaan ekonomi yang tepat, lebih banyak pengembang akan berada dalam posisi untuk membangun, meningkatkan, dan menambah perangkat lunak sumber terbuka untuk kemajuan dunia. -Hanya dengan begitu token teh dapat mewakili nilai total perangkat lunak sumber terbuka. - -[^15]: Sumber: @npmjsLodash -[^16]: Sumber: @npmjsChalk -[^17]: Sumber: @npmjsLogFourjs - -## Pengiriman Paket - -Pengajuan rilis paket membutuhkan beberapa transaksi terjadi secara atom. -Secara khusus, pengelola paket harus: - -* Daftarkan paket (dan versi semantiknya) dengan registri terdesentralisasi. -* Unggah paket ke dalam sistem penyimpanan terdesentralisasi untuk ketahanan, ketahanan sensor, dan kemudahan distribusi. -* Berkontribusi pada reputasi dan kepercayaan paket dengan *menyeduh* token teh. - -Kegagalan salah satu dari tiga operasi akan mengakibatkan protokol kembali ke keadaan sebelumnya, sehingga menghilangkan bukti penyerahan. - -Ketika sebuah paket berhasil dikirimkan, pengelola paket akan menerima NFT pengelola untuk membuktikan pekerjaan dan kontribusi mereka pada sumber terbuka. -Pengelola paket dapat mentransfer hadiah seduhan yang terkait dengan NFT pengelola ke pihak ketiga. -Namun, reputasi yang terkait dengan pembuatan dan pemeliharaan aset akan tetap ada pada pengelola paket, sehingga reputasinya dapat terpengaruh seiring waktu. -Ketika reputasi setiap anggota komunitas teh mencapai tonggak penting, mereka dapat diberikan akses ke bagian protokol yang lebih tinggi atau menerima hadiah yang dipercepat, sebagaimana diputuskan oleh tata kelola teh. -Untuk detail lebih lanjut tentang NFT pengelola, lihat bagian NFT pengelola. - -### Analisis Ketergantungan - -Ketergantungan paket dapat berjalan dalam, karena setiap paket sering kali memiliki dependensi dan dependensi. -Untuk menyediakan metodologi sederhana yang memberi penghargaan kepada semua pengembang yang telah berkontribusi pada perangkat lunak sumber terbuka sambil menjaga pembuatan pohon dependensi cepat dan efisien secara komputasi, kami mengusulkan untuk memverifikasi hanya dependensi tingkat pertama setelah pengiriman paket. - -Desain ini didorong oleh hipotesis bahwa setiap ketergantungan itu sendiri merupakan paket yang secara independen diserahkan ke pohon teh. -Dengan demikian, setiap dependensinya dapat dipetakan, dan jika dependensinya memiliki dependensi sendiri, dependensi tersebut akan dipetakan pada saat paket dependensi dikirimkan. - -![Diagram analisis dependensi.](img/figure-3.svg){#fig:dep-analysis} - - -Dalam @fig:dep-analysis, pengiriman paket A memicu analisis dependensi runtime 1 hingga n dan dependensi build 1 hingga n, sedangkan dependensi runtime 1.1 hingga 1.n dan dependensi build 1.1 hingga 1.n dianalisis saat paket B telah diserahkan. -Kami akan menerapkan metodologi yang sama untuk distribusi insentif karena token yang direndam didistribusikan di semua dependensi, sehingga secara rekursif menyeduh paket yang terdaftar sebagai dependensi (lihat @fig:steeping-rewards). - -![Meningkatkan distribusi hadiah di seluruh dependensi.](img/figure-2.svg){#fig:steeping-rewards} - - -Pembuatan versi dan dependensi yang saling bertentangan adalah tantangan yang signifikan, dan pemecahan masalah dapat berubah menjadi pengurasan waktu yang sangat besar. -Untuk mengatasi hal ini, kami mengusulkan agar setiap paket tunduk pada pemindaian ketergantungan yang komprehensif setelah pengiriman sehingga kami dapat memastikan bahwa paket tersebut mematuhi aturan berikut untuk rentang versi semantik. - -* Paket hanya dapat membatasi dependensinya ke versi utama, meskipun awal rentang dapat berupa versi semantik yang valid (mis., >=5.2.1 <6). -* Jika ketergantungan ditingkatkan ke versi utama yang lebih baru, teh mungkin mengharuskan versi utama paket ditingkatkan. -* Demikian pula, jika ketergantungan ditingkatkan ke versi minor yang lebih baru, teh mungkin mengharuskan versi minor paket ditingkatkan. -* Jika ketergantungan baru ditambahkan, teh mungkin mengharuskan versi minor paket ditingkatkan. - -Mempertimbangkan upaya yang tidak perlu yang dikenakan pada setiap pengguna paket ketika aturan di atas dilanggar, kami mengusulkan agar sebagian dari token teh yang direndam oleh pengelola paket dipotong untuk mencerminkan kurangnya uji tuntas mereka. -Jika pengembang memaksa semua orang untuk menyulap cangkir mereka, seseorang akan menumpahkan teh. -Karena pemindaian ketergantungan diharapkan terjadi saat penyerahan, kami harus mencatat bahwa tidak ada seduhan dari pendukung paket dan sponsor atau pencicip teh yang akan terjadi. - -## Reputasi Pengelola Paket & Paket - -Pengelola paket harus berkontribusi pada reputasi dan kepercayaan paket mereka dengan menyeduh token teh. -Namun, sistem reputasi yang hanya mengandalkan kontribusi ekonomi penulis tidak memberikan perlindungan pengguna yang memadai dan dapat menjadi sasaran serangan Sybil, di mana satu individu membuat beberapa representasi diri mereka sendiri untuk meninggalkan sejumlah besar ulasan positif pada pekerjaan mereka, -menipu pengguna agar percaya bahwa pekerjaan mereka telah ditinjau dan disetujui oleh banyak orang. - -Beberapa metodologi tersedia untuk mencegah serangan Sybil, beberapa di antaranya dijelaskan oleh Nitish Balachandran dan Sugata Sanyal dalam “A Review of Techniques to Mitigate Sybil Attacks”[^18]. -Karena teh adalah protokol terdesentralisasi, menggunakan sistem sertifikasi kepercayaan yang bergantung pada otoritas penerbitan sertifikat terpusat akan bertentangan dengan intinya. -Kami mengusulkan untuk fokus pada pendekatan desentralisasi untuk mitigasi serangan Sybil dan, lebih khusus lagi, pada metodologi yang mengandalkan sekelompok besar peserta jaringan yang diberi insentif untuk menilai dan secara publik mewakili reputasi setiap paket dan pengelolanya. - -Mirip dengan produksi blok pada blockchain proof-of-stake, di mana node yang tidak memproduksi dapat memvalidasi pekerjaan orang lain dan, bila perlu, menyoroti pelanggaran aturan jaringan, yang mengarah pada hukuman aktor jahat melalui tebasan (penghancuran sebagian dari pasak mereka), -kami mengusulkan sistem di mana pihak ketiga (alias pencicip teh) akan dapat meninjau paket yang diproduksi oleh pengelola paket dan diberi insentif secara ekonomi untuk berperilaku demi kepentingan terbaik komunitas perangkat lunak sumber terbuka dan penggunanya serta mengenali perilaku yang baik dan menghukum perilaku buruk. -Sistem ini harus tahan terhadap Sybil dan mencegah pemegang token besar secara material mempengaruhi protokol atau reputasi paket tertentu. -Kami percaya pendekatan ini lebih selaras dengan open-source, menyediakan substrat yang lebih subur untuk mendorong adopsi dan kepercayaan, dan pada akhirnya memfasilitasi pertumbuhan teh. - -[^18]: Sumber: @arxiv - -## Review Paket oleh Pihak Ketiga - -Tinjauan paket oleh pihak ketiga merupakan komponen penting dalam membangun reputasi, namun tinjauan pihak ketiga memiliki serangkaian ancaman uniknya sendiri termasuk serangan Sybil yang disebutkan di atas. - -Teknologi Blockchain, dan secara lebih eksplisit mempertaruhkan, menawarkan peluang unik bagi teh untuk mengatasi tantangan ini. -Meskipun alamat dompet mungkin tersedia dalam jumlah tak terbatas, ini tidak terjadi dengan token teh, yang pasokan awalnya diperkirakan 10 miliar. -Selain itu, setiap tindakan yang dilakukan oleh pengembang, seperti mengirimkan paket, memverifikasi paket, atau menyeduhnya, akan berkontribusi pada reputasi mereka, sehingga menciptakan profil unik yang dapat digunakan setiap pengembang untuk berkontribusi pada komunitas teh dan berpartisipasi dalam tata kelola teh. - -Dengan mengharuskan peninjau pihak ketiga untuk menyeduh token teh dan menanggung risiko kehilangan sebagian dari token mereka jika mereka ternyata berperilaku bertentangan dengan kepentingan jaringan atau menjadi aktor yang buruk, pihak ketiga dapat memberikan kepercayaan tambahan untuk sebuah paket dan menerima hadiah, berupa token teh. - -Kami juga mengusulkan perluasan sistem reputasi kepada pihak ketiga yang melakukan verifikasi independen paket - pencicip teh. -Penyelesaian tinjauan positif akan membutuhkan dua operasi untuk terjadi secara atom: - -* Pengajuan tinjauan kode, ditandatangani oleh pengecap teh dan dapat diakses publik oleh semua anggota komunitas, bersama dengan -* Tindakan seduhan "untuk" paket (vs. "melawan" paket), untuk mendukung ulasan mereka. - -Penyelesaian tinjauan negatif yang mencakup satu atau lebih kerentanan kritis akan mengharuskan para pembuat teh terlebih dahulu untuk menghubungi pengelola paket menggunakan protokol pesan untuk memberi tahu mereka tentang kerentanan dan memungkinkan mereka untuk mengatasi masalah secara tepat waktu. -Setelah berakhirnya periode yang ditentukan tata kelola yang dialokasikan ke pengelola paket untuk mengatasi kerentanan mereka atau saat paket yang diperbaiki tersedia, protokol pesan yang sama akan digunakan untuk memberi tahu semua pengguna dan penguji paket ini (termasuk tanggungan) bahwa kerentanan telah diidentifikasi, -dan mudah-mudahan diatasi, sehingga mereka tahu untuk memperbarui aplikasi atau dependensi mereka. -Untuk mengurangi pemborosan waktu pengembang, komunikasi antara pencicip teh dan pengelola paket akan membutuhkan pencicip teh untuk merendam token teh. - -Setelah menyelesaikan kedua operasi, pencicip teh akan menerima NFT sebagai bukti pekerjaan mereka pada paket dan versi paket tertentu. -Akumulasi NFT dikombinasikan dengan rasio seduhan dari masing-masing paket yang ditinjau dan informasi yang diambil dari sistem eksternal akan menginformasikan reputasi pengecap teh. -Saat reputasi mereka mencapai tonggak penting, pencicip teh dapat memperoleh akses ke bagian protokol yang lebih tinggi atau hadiah yang dipercepat, seperti yang diputuskan oleh tata kelola teh. - -## Paket Kedaluwarsa atau Rusak - -misi teh adalah untuk memberi penghargaan kepada kontributor dan peserta di komunitas sumber terbuka; namun, penghargaan harus sepadan dengan upaya yang dilakukan oleh pengelola paket dan pencicip teh. -Paket yang kurang terawat, usang, atau rusak adalah indikasi yang jelas dari pengelola paket yang tidak memenuhi harapan komunitas atau tidak memberikan kepercayaan dan dukungan yang diberikan kepada mereka melalui seduhan paket. -Manifestasi lain dari paket-paket usang mungkin adalah penggunaan berkelanjutan dari bahasa lama atau versi lama dari bahasa multi-versi. -Paket yang ketinggalan zaman atau rusak terlalu lama menunjukkan bahwa para pencicip teh perlu meninjau pekerjaan pengelola paket secara teratur dan konsisten. - -pencicip teh adalah anggota penting dari komunitas sumber terbuka karena ulasan mereka dan klaim terkait dapat mengarahkan pengguna paket ke atau menjauh dari paket. -Untuk memastikan bahwa ulasan dapat dipercaya secara berkelanjutan, kami mengusulkan mekanisme di mana paket yang sudah usang atau rusak dapat melihat sebagian dari token mereka yang direndam dikirim ke pencicip teh yang pertama kali mengenali kurangnya pemeliharaan paket apa pun. - -Tinjauan negatif apa pun yang menguraikan cacat seperti kerentanan zero-day atau penggunaan ketergantungan yang sudah ketinggalan zaman dan tetap terbuka melewati masa tenggang yang ditentukan oleh tata kelola harus dianggap sebagai kegagalan dari pihak pengelola paket. -Mereka belum menyelesaikan tugas yang dipercayakan dan dihargai. -Hal yang sama dapat dikatakan untuk pendukung paket dan sponsor yang mempertaruhkan reputasi mereka pada pekerjaan pengelola paket yang menunggak dan menerima hadiah untuk itu, tetapi gagal mengidentifikasi kurangnya pemeliharaan atau memilih untuk terus mendukung paket tersebut. - -Seiring popularitas dan penggunaan paket, dengan lebih banyak aplikasi dan sistem yang berpotensi menjadi misi-kritis bergantung pada mereka, kita harus memberi insentif kepada pengembang untuk secara diam-diam melaporkan kekurangan kepada pengelola paket dan pengelola paket untuk mengatasi kekurangan tersebut sebelum dapat dieksploitasi. -Oleh karena itu, kami mengusulkan agar setiap paket usang atau rusak yang tunduk pada satu atau lebih ulasan negatif yang terbukti dan tetap dalam keadaan seperti itu setelah masa tenggang yang ditentukan oleh tata kelola, melihat sebagian dari token yang direndamnya dipotong terlepas dari asalnya (pengelola paket, paket pendukung, dan sponsor atau pencicip teh sebelumnya), -sementara porsi lain dikirim ke para pencicip teh yang memberikan ulasan negatif. -Distribusi ke semua pencicip teh dapat didasarkan pada usia ulasan mereka dan jumlah token teh yang mereka seduh untuk ulasan mereka. - -## Pemelihara NFT - -Setelah pengiriman paket berhasil, pengelola paket akan menerima NFT sebagai bukti kerja dan kontribusi mereka. -Pemegang NFT ini akan secara otomatis menerima semua hadiah yang terkait dengan paket. -Pengelola paket dapat mentransfer kepemilikan pemeliharaan atas sebuah paket ke pengelola paket lain hanya dengan mentransfer NFT paket. -Transfer NFT yang berhasil akan menyebabkan pemilik baru secara otomatis menerima hadiah paket di masa mendatang. - -Bagian penting dari membangun reputasi bergantung pada frekuensi dan kuantitas pengiriman paket yang berkualitas. -NFT yang dikirimkan ke pengelola paket sebagai bukti kerja mereka dapat digunakan oleh sistem reputasi untuk memperbarui reputasi pengelola paket dan memberi mereka akses ke bagian protokol yang lebih tinggi, sebagaimana diputuskan oleh tata kelola teh. -Namun, untuk mencegah vektor serangan, seperti anggota komunitas membeli reputasi mereka, transfer pengelola NFT tidak akan menghasilkan transfer reputasi. -Reputasi harus tetap terkait langsung dengan pekerjaan pengembang tertentu dan tidak boleh dipindahtangankan. - -# tea Token - -## Mengamankan Jaringan - -Sementara banyak blockchain mungkin muncul sebagai solusi infrastruktur yang efektif dan aman untuk mendukung tujuan teh, kami percaya bahwa pertimbangan yang cermat harus diberikan pada tumpukan teknologi di mana sistem teh dibangun. - -Skalabilitas, efektivitas biaya, ESG, dan ekstensibilitas pihak ketiga adalah pertimbangan desain penting yang dapat dilayani dengan lebih baik oleh sistem bukti kepemilikan teh yang berdaulat. -Dalam proof-of-stake, operator node dan peserta jaringan mempertaruhkan nilai ekonomi dalam bentuk token asli rantai untuk meningkatkan keamanan sistem. -Operator node dan peserta jaringan menerima hadiah untuk keberhasilan produksi blok yang mematuhi aturan jaringan dan menyertakan informasi transaksi yang akurat. -Ketidakaktifan (alias node down) atau aktivitas jahat/salah dihukum dengan menghancurkan sebagian kecil dari token yang dipertaruhkan melalui pemotongan. - -Sistem proof-of-stake yang didukung oleh token teh akan memungkinkan pemegang token teh untuk berkontribusi pada keamanan sistem dengan *mempertaruhkan* teh dan mendukung pengembang sumber terbuka dengan *menyeduh* teh. -Kami sepenuhnya menyadari faktor ekonomi dapat mencegah beberapa pengembang mengintai atau menyeduh teh; dengan demikian, staking dan seduhan akan tersedia hanya dengan sehelai daun, denominasi teh terkecil yang mewakili seperseratus juta ($10^{-8}$) teh. - -Kedua aplikasi token teh melayani fungsi vital dalam mendukung dan pertumbuhan ekosistem open-source. -Staking tea akan memastikan bahwa sistem teh terus beroperasi dengan aman, sehingga semua peserta jaringan dapat mengirimkan dan mengakses paket untuk meninjaunya, mengintegrasikannya ke dalam aplikasi mereka, dll. -Sebaliknya, seduhan teh akan mendukung tujuan teh untuk menyediakan alat bagi semua peserta jaringan untuk mendukung dan menggunakan paket yang memenuhi persyaratan kualitas dan keandalan, sebagaimana dirumuskan oleh komunitas teh melalui dukungan dan perbedaan pendapat mereka terhadap setiap paket. -Kehati-hatian akan diambil ketika mendefinisikan dan menerapkan parameter staking dan seduhan sehingga yang satu tidak menjadi parasit pada yang lain. - -## Insentif dan Penalti - -Seperti yang telah dibahas sebelumnya, mungkin ada insentif kuat bagi aktor jahat untuk berkompromi dengan perangkat lunak sumber terbuka. -Mayoritas infrastruktur penting Internet berjalan pada sumber terbuka, dan perlombaan untuk menemukan eksploitasi dan kerentanan lainnya sedang berlangsung. -Di teh, kami percaya bahwa pengelola paket bukanlah pihak yang harus disalahkan (walaupun sering). - -insentif protokol teh memperbaikinya melalui distribusi insentif yang adil dan merata. -Paket seperti Lodash dengan lebih dari 151k tanggungan adalah pilar pengembangan sumber terbuka, dan pengelolanya layak untuk dihargai secara proporsional. -Namun, sistem penghargaan yang dibangun hanya berdasarkan jumlah tanggungan akan mencegah inovator mengganggu monopoli ini kecuali jika mereka didanai secara memadai oleh pihak ketiga atau telah mengumpulkan sumber daya yang cukup untuk mendanai sendiri. -Pendekatan ini kemungkinan akan menyebabkan berkurangnya jumlah kontributor, yang menghasilkan kebalikan dari teh. - -tujuan teh adalah untuk mewakili nilai perangkat lunak sumber terbuka dan, dengan melakukan itu, mendorong pertumbuhannya dengan memberdayakan para pesertanya dengan sumber daya yang mereka butuhkan untuk mengejar hasrat mereka tanpa beban. -Sistem distribusi insentif teh perlu secara hati-hati mempertimbangkan rasio seduhan setiap paket dan menyesuaikan insentif setiap paket. -Untuk mengurangi risiko sejumlah kecil paket yang digunakan sebagai dependensi di banyak aplikasi yang mengumpulkan sebagian besar hadiah seduhan, kami akan memanfaatkan penelitian yang dihasilkan oleh Web3 Foundation[^19] untuk mekanisme hadiah berbasis bukti kepemilikan Polkadot. -Kami selanjutnya dapat menyesuaikan implementasi dan variabelnya berdasarkan hasil eksperimen praktis. - -Saat paket curam mendekati rasio seduhan optimal yang ditentukan oleh tata kelola, rasio imbalan seduhannya akan menurun secara progresif. -Ketika sebuah paket melebihi rasio seduhan optimalnya, rasio hadiah seduhan akan menurun tajam untuk menghilangkan insentif pendukung paket dan pencicip teh dari paket seduhan lebih lanjut. -Desain ini dapat memungkinkan paket yang lebih sedikit direndam menjadi lebih menarik bagi pendukung paket dan pencicip teh. -Ini juga dapat memberi insentif kepada pengembang berpengalaman untuk membangun alternatif untuk paket yang sangat kaya, menciptakan peluang bagi komunitas teh untuk menyeimbangkan dukungan perangkat lunak yang ada dan mempromosikan inovasi. -Rasio seduhan akan dihitung menggunakan suplai sirkulasi dalam desain awalnya. -Komunitas teh dapat mengubah desain ini untuk meningkatkan skalabilitas sistem lebih lanjut. -Biarkan $\chi$ menjadi rasio seduhan di semua paket. -Ini mewakili jumlah total token teh yang direndam oleh pengelola paket, pengguna paket, pendukung dan sponsor paket, dan pencicip teh dibagi dengan total pasokan token teh. -Mengingat berapa banyak paket open-source yang tersedia saat ini dan perkiraan pertumbuhannya, $\chi$ akan selalu bernilai sangat kecil antara $0$ dan $1$. - -Biarkan $\psi$ menjadi rasio taruhan. -Ini mewakili jumlah total token teh yang dipertaruhkan oleh setiap peserta jaringan untuk mengamankan jaringan. - -Biarkan $\chi_{ideal}$ menjadi rasio seduhan yang kami ingin capai setiap paket untuk distribusi hadiah yang adil di semua paket dan dependensinya. -Nilai $\chi_{ideal}$ harus diperbarui saat paket baru ditambahkan ke registri terdesentralisasi, dan dependensi dibuat. -Untuk menentukan nilai terbaik untuk $\chi_{ideal}$, kami akan menggunakan kurva lonceng popularitas yang diperbarui di awal setiap siklus hadiah. - -Biarkan $\tau = \tau(\chi)$ menjadi tingkat bunga seduhan tahunan yang didistribusikan ke semua anggota komunitas teh yang merendam token teh untuk mendukung pengembang sumber terbuka. -Dengan kata lain, $\tau(\chi)$ sesuai dengan hadiah seduhan yang diterima lebih dari setahun oleh anggota komunitas yang menyeduh token teh sepanjang tahun. - -Biarkan $\gamma = \gamma(\psi)$ menjadi tingkat bunga taruhan tahunan yang didistribusikan ke semua operator node dan peserta jaringan yang mempertaruhkan token teh untuk mengamankan jaringan. -Dengan kata lain, $\gamma(\psi)$ sesuai dengan hadiah taruhan yang diterima lebih dari setahun oleh anggota komunitas yang mempertaruhkan token teh sepanjang tahun. - -Biarkan $\delta$ menjadi inflasi tahunan yang diarahkan pada perbendaharaan jaringan. -$\delta$ dapat bervariasi karena faktor eksternal mempengaruhi pasokan token. - -Kami menganggap tingkat hadiah seduhan tahunan sebagai fungsi dari $\chi$ dan tingkat hadiah taruhan tahunan sebagai fungsi dari $\psi$. - -* $\tau(\chi)$ sesuai dengan insentif bagi orang-orang untuk mengambil paket. -Saat $\chi$ meningkat, lebih sedikit hadiah $\tau(\chi)$ yang dibutuhkan. -* $\gamma(\psi)$ sesuai dengan insentif bagi orang-orang untuk mempertaruhkan jaringan. -Saat $\psi$ meningkat, lebih sedikit hadiah $\gamma(\psi)$ diperlukan untuk mengamankan jaringan. - -Inflasi tahunan $I$ akan setara dengan $(\tau + \gamma + \delta)$ dan dihitung sebagai berikut: - -$$ -I = \frac{\textrm{persediaan token di akhir tahun} - \textrm{persediaan token di awal tahun}}{\textrm{persediaan token di awal tahun}} = (\tau + \gamma + \delta) -$$ - -Kontribusi terhadap inflasi $\tau_{\textsc{all}}$ (insentif yang didistribusikan ke semua paket yang lebih curam) dan $\gamma_{\textsc{all}}$ (insentif yang didistribusikan ke semua kontributor untuk keamanan jaringan) harus dipertimbangkan untuk memastikan bahwa sistem mendorong rasio seduhan/staking yang optimal. - -Saat kami fokus pada insentif yang didistribusikan di semua paket yang lebih curam, kami menentukan bahwa -$\tau_{\textsc{all}}$ -adalah fungsi dari rasio seduhan $\chi$ dan oleh karena itu -$\tau_{\textsc{all}}(\chi) = \chi \cdot \tau(\chi)$. -Dari analisis kami sebelumnya, kami dapat melihat bahwa -$\tau_{\textsc{all}}(\chi_{ideal}) = \chi_{ideal} \cdot \tau_{ideal}$. -Karena tujuannya adalah untuk mencapai keadaan di mana -$\chi = \chi_{ideal}$ -, hadiah -$\tau_{ideal}(\chi)$ -harus maksimal pada nilai tersebut. - -Misalkan $\tau_{ideal} = \tau(\chi_{ideal})$ -menjadi tingkat hadiah yang diberikan oleh jaringan pada skenario ideal di mana -$\chi = \chi_{ideal}$. - -Biarkan $\tau_{0}$ menjadi batas $\tau_{\textsc{all}}(\chi)$ karena $\chi$ menjadi nol ketika tidak ada anggota komunitas teh yang mengambil paket apa pun. -Nilai $\tau_{0}$ harus mendekati nol tetapi tidak nol untuk mendorong pengadopsi awal. -Seperti yang disarankan oleh penelitian Yayasan web3, kami mengusulkan bahwa: - -* fungsi inflasi tumbuh secara linier antara $\chi = 0$ dan $\chi = \chi_{ideal}$, dan -* itu meluruh secara eksponensial antara $\chi = \chi_{ideal}$ dan $\chi = 1$. - -Kami memilih penurunan eksponensial serupa untuk $\tau_{\textsc{all}}(\chi)$ karena ini menyiratkan penurunan eksponensial $\tau(\chi)$, dan kami ingin imbalan turun tajam melampaui $\chi_{ideal}$ untuk mencegah satu paket menerima semua hadiah. - -Peluruhan didefinisikan sehingga tingkat inflasi berkurang paling banyak 50% ketika $\chi$ menggeser unit $d$ ke kanan $\chi_{ideal}$ – yaitu. -$\tau_{\textsc{all}}(\chi_{ideal} + d) \geq \tau_{\textsc{all}} \cdot 0.5$. - -Kami mengusulkan fungsi tingkat bunga dan tingkat inflasi berikut, yang bergantung pada parameter $\chi_{ideal}$, $\tau_{ideal}$, $\tau_{0}$ dan $d$. - -\begin{align*} -&\tau_{\textsc{all}}(\chi) = \tau_{0} + (\tau_{\textsc{all}}(\chi_{ideal}) - \tau_{0})\frac{\chi}{\chi_{ideal}}\enspace\textrm{for}\;0 < \chi \leq \chi_{ideal} \\ -&\tau_{\textsc{all}}(\chi) = \tau_{0} + (\tau_{\textsc{all}}(\chi_{ideal}) - \tau_{0}) \cdot 2^{(\chi_{ideal}-\chi)/d}\enspace\textrm{for}\;\chi_{ideal} < \chi \leq 1 -\end{align*} - -Sama seperti aktor yang baik perlu dihargai; aktor jahat perlu diidentifikasi dan dihukum. -Perangkat lunak open-source memberikan banyak peluang bagi pelaku jahat untuk menciptakan masalah dan risiko reputasi bagi seluruh komunitas pengembang. -Dari penyelewengan pekerjaan hingga pengubahan dan redistribusi paket perangkat lunak, atau penyuntikan kode jahat, perang antara aktor baik dan buruk terus berlanjut, seringkali dengan aktor jahat yang didanai dengan baik yang melihat kontaminasi paket sumber terbuka sebagai peluang untuk mendapatkan keuntungan finansial. -Kelemahannya relatif minimal, dengan paket yang berpotensi dilarang dari rak digital atau mengalami reputasi yang buruk. - -Kami mengusulkan untuk memperkenalkan mekanisme tebasan untuk membangun kerugian yang lebih material yang secara langsung mempengaruhi nilai ekonomi pelaku kejahatan. -Saat pencicip teh mengevaluasi dan menganalisis kode dalam paket yang baru dikirimkan, kami menyarankan pencicip teh menerima alat dan insentif untuk menunjukkan dengan tepat dan menyoroti kode jahat sehingga pengguna paket dapat disadarkan akan risikonya, dan pengelola paket, pendukung paket, dan sponsor dihukum untuk mengirimkan atau mendukung kode jahat. -Sejauh itu, untuk semua ulasan negatif yang terbukti dilakukan sesuai aturan jaringan dan yang telah ditangani oleh pengelola paket dalam periode yang ditentukan oleh tata kelola, pengelola paket tidak boleh dikenakan penalti yang bertentangan dengan pendukung dan sponsor paket atau pengecap teh yang memberikan review positif terhadap paket yang dimaksud. -Untuk ulasan negatif yang dilakukan sesuai dengan aturan jaringan dan bahwa pengelola paket belum menangani dalam periode yang ditentukan oleh tata kelola, sebagian kecil dari token yang disimpan oleh pengelola paket, pendukung dan sponsor paket, dan pencicip teh sebelumnya akan dipotong. -Fraksi lain akan dikunci ke dalam kolam asuransi yang dikendalikan oleh tata kelola teh. -Tata kelola teh akan menetapkan kebijakan dan aturan dalam kolaborasi erat dengan komunitas untuk mendistribusikan konten kolam kepada mereka yang terkena dampak kerentanan. -Protokol akan mendistribusikan fraksi ketiga dari token yang direndam di semua pencicip teh yang berkontribusi pada ulasan negatif dan mendalami paket, berdasarkan jumlah token teh yang mereka celupkan "melawan" paket dan berapa lama token mereka telah direndam. -Dengan kata lain, semakin cepat satu atau lebih pencicip teh mengidentifikasi dan melaporkan kekurangan tersebut sesuai dengan aturan jaringan, semakin tinggi imbalan yang akan mereka dapatkan karena mendukung pengembangan sumber terbuka yang aman dan produktif. - -Untuk mencegah anggota komunitas memilih secara acak "melawan" paket yang sangat curam dengan harapan menerima mayoritas penalti, semua token teh yang "melawan" tidak akan diberi inflasi dan dapat dikenakan mekanisme peluruhan, sehingga mengurangi nilainya dari waktu ke waktu . - -[^19]: Sumber: @web3 - - -# Pemerintahan - -Tata kelola sangat penting untuk pengembangan, keberlanjutan, dan adopsi sistem terdistribusi apa pun. - -Kami mengusulkan bahwa teh mencakup tata kelola on-chain di mana semua pemegang token teh dapat menyarankan dan memilih perubahan pada parameter penting yang ditimbang berdasarkan kepemilikan dan reputasi token. -Parameter ini dapat mencakup inflasi, biaya transaksi, imbalan taruhan, imbalan seduhan, atau rasio seduhan optimal. -Fungsionalitas ini akan memastikan bahwa parameter kritis dapat berkembang dan dioptimalkan dari waktu ke waktu oleh anggota komunitas teh. -Kami mengantisipasi tata kelola akan diluncurkan dengan struktur sederhana dan semakin berkembang seiring dengan matangnya sistem teh, memfasilitasi adopsi dan memastikan desentralisasi progresif. - -Beberapa parameter sistem mungkin tidak tunduk pada tata kelola atau mendukung perubahan frekuensi tinggi untuk mengurangi permukaan serangan yang diwakili oleh tata kelola. -Transisi parameter yang progresif ke tata kelola yang terbuka dan terdesentralisasi akan memastikan stabilitas dan prediktabilitas sistem. - - -# Ekstensibilitas Pihak Ketiga - -Saat kami membangun alat awal untuk menyalakan dukungan yang telah lama tertunda dari komunitas sumber terbuka, kami percaya bagian dari misi kami adalah untuk memastikan bahwa pihak ketiga dapat memperluas keseluruhan perangkat. -Selain menyediakan infrastruktur bagi pengembang untuk membangun ekstensi protokol, termasuk cara baru untuk berinovasi dan lebih lanjut mendukung pengembang sumber terbuka, rencana kami mencakup potensi manajer paket lain untuk berkontribusi pada protokol. -Impian dan upaya pengembang open-source telah membangun inovasi yang mendukung kehidupan kita sehari-hari. -Kami berharap dapat menemukan kegunaan dan ekstensi baru untuk teh yang diusulkan oleh komunitas teh. - - -# Pekerjaan Masa Depan dan Upaya Komunitas Potensi - -Saat sistem teh matang, kami memperkirakan komunitas memutuskan dan berkontribusi pada perubahan dan perluasan sistem teh melalui tata kelola. -Di bawah ini adalah beberapa ide yang kami yakini dapat menginspirasi beberapa orang. - -## grosir teh - -Komunitas perangkat lunak sumber terbuka bersemangat dan terus mencari untuk berinovasi dan memberikan nilai. -Dedikasi dan altruisme ini mengarah pada pembangunan perangkat lunak dan paket baru yang konstan, masing-masing menarik dependensi. -Akibatnya, kami mengantisipasi peta dependensi untuk terus berkembang, yang menyebabkan seringnya terjadi perubahan pada rasio seduhan dan penghargaan. -Di masa depan, komunitas teh dapat mengusulkan pengembangan sistem yang dirancang untuk secara dinamis memantau rasio seduhan untuk setiap paket dan menyeimbangkan kembali bagaimana pendukung paket menaikan token mereka berdasarkan kriteria mereka sendiri. - -## Royalti Transfer Paket - -Kami menyadari bahwa pengelola paket dapat memutuskan untuk mentransfer aliran hadiah utama mereka ke satu atau beberapa pengembang. -Tata kelola transfer tersebut harus tetap menjadi keputusan pengelola paket dan mitranya, tanpa campur tangan dari pihak teh. -Alat perlu disediakan untuk transfer tersebut menjadi total atau sebagian (mungkin hanya melalui sebagian dari hadiah seduhan yang dialihkan ke satu atau lebih pengembang, sementara hadiah yang tersisa terus mengalir ke pengelola paket asli) -dan agar hadiah mengalir melalui satu akun yang dikendalikan oleh satu peserta jaringan, beberapa peserta jaringan, atau secara otomatis didistribusikan ke beberapa akun menggunakan rasio statis atau dinamis. - -## Distribusi Hadiah di Beberapa Pengelola - -Pemeliharaan paket dapat mengandalkan pekerjaan satu tim pengembang lagi. -Sebelum hadiah seduhan mulai mengalir, tim harus mempertimbangkan untuk mengotomatiskan distribusi hadiah seduhan di antara mereka sendiri. -Bagaimana distribusi terjadi harus diputuskan oleh pengelola sendiri, karena mereka berada dalam posisi terbaik untuk mengevaluasi siapa yang berkontribusi dan bagaimana mereka harus diberi penghargaan. - -Untuk mencapai itu, setiap tim (atau tim) dapat membentuk organisasi otonom terdesentralisasi (DAO) mereka sendiri dan mengotomatiskan distribusi penghargaan atau menerapkan sistem yang lebih kompleks untuk menentukan distribusi penghargaan yang memadai berdasarkan faktor eksternal seperti pemungutan suara dari semua DAO anggota, -atau distribusi berbasis waktu berdasarkan kontribusi berkelanjutan, penyelesaian bounty yang berhasil, dll. - -## Menangani Paket “Forks” - -Kami percaya bahwa garpu sangat penting dan sebagian besar kurang dimanfaatkan. -Forks dapat menjadi alat yang efektif untuk mengembangkan paket yang bersaing dalam fungsionalitas, kinerja, keamanan, dan bahkan perhatian. -Meskipun berguna, garpu harus mengenali upaya aslinya. -Melalui pekerjaan di masa depan atau kontribusi potensial, komunitas teh dapat meningkatkan sistem untuk meminta garpu dideklarasikan, bahkan mungkin terdeteksi ketika sebuah paket dikirimkan. -Garpu yang tidak dideklarasikan yang diungkapkan oleh pencicip teh dapat mengakibatkan sebagian dari token yang direndam disayat, dipindahkan ke pengelola paket asli, dan dikirim ke pencicip teh yang mengungkapkan garpu. - -## Runtime vs. Membangun Ketergantungan - -teh mungkin tidak membedakan dependensi build dari dependensi runtime saat mendistribusikan hadiah seduhan saat peluncuran. -Namun, komunitas asalkan merasa kuat untuk membedakan perbedaan seperti itu, dapat meningkatkan peningkatan pada perbaikan distribusi seduhan hadiah dengan meningkatkan kekritisan setiap kontribusi dan kontribusinya terhadap nilai-nilai yang ditawarkan komunitas. -Usulan-usulan ini akan dipilih dan dilaksanakan berdasarkan keputusan masyarakat. - -## Remunerasi berdasarkan penggunaan - -Karena semakin banyak aplikasi yang dibangun menggunakan paket yang terdaftar dengan teh, komunitas dapat meningkatkan algoritme penghargaan sehingga alokasi dapat dipengaruhi oleh kumpulan data yang dibuktikan secara eksternal seperti penggunaan. -Pembaruan mekanisme hadiah ini memungkinkan alokasi hadiah token teh yang lebih tinggi mengalir ke paket dengan penggunaan tertinggi sambil tetap menghormati batasan rasio seduhan yang dijelaskan di bagian token teh. -Pengelola paket dapat menggunakan pendekatan serupa untuk mendistribusikan hadiah seduhan di seluruh dependensi mereka berdasarkan logika transparan pilihan mereka. -Perhatikan bahwa semua informasi yang digunakan untuk memengaruhi distribusi hadiah di seluruh paket dan dependensi dalam sistem teh harus terbukti andal. - - -# Ucapan Terima Kasih - -Buku putih ini tidak akan ada tanpa dukungan dan dedikasi dari banyak teaophiles. -Para penulis ingin mengucapkan terima kasih kepada Josh Kruger, Jadid Khan, dan Jacob Heider atas kontribusi mereka pada tokennomics dan banyak individu bijaksana yang secara sukarela meluangkan waktu mereka untuk memberikan umpan balik tentang isi dokumen ini. - -$\parskip=0pt plus 1pt$ - -# Daftar Istilah - -| istilah | Definisi | -|------|------------| -| Daun | Denominasi terkecil dari token teh. Sehelai daun sama dengan seperseratus juta ($10^{-8}$) teh. | -| Memotong | Tindakan menghukum yang lebih curam atau yang mempertaruhkan sebagai tanggapan atas perilaku yang bertentangan dengan aturan jaringan. | -| Mempertaruhkan | Tindakan mengunci token teh untuk mengamankan jaringan bukti kepemilikan tempat sistem teh dibangun. | -| Curam | Tindakan mengunci token teh untuk mendukung klaim Anda dan menerima hadiah (atau penalti) berdasarkan konsensus tentang validitas klaim Anda. | - - -# Referensi diff --git a/i18n/ru/white-paper.md b/i18n/ru/white-paper.md deleted file mode 100644 index cd4a823..0000000 --- a/i18n/ru/white-paper.md +++ /dev/null @@ -1,581 +0,0 @@ -# Отказ от ответственности - -Информация, изложенная в этом официальном документе, носит предварительный характер. -Следовательно, ни авторы, ни какие-либо из их соответствующих аффилированных лиц не несут никакой ответственности за то, что информация, изложенная в настоящем документе, является окончательной или правильной, и каждый из вышеперечисленных отказывается, -в максимально возможной степени, разрешенной применимым законодательством, любой и всей ответственности, возникающей в результате правонарушения, контракта или иным образом в отношении этого официального документа. -Ни этот технический документ, ни что-либо, содержащееся в нем, не должны составлять основу, на них нельзя полагаться в связи или действовать как побуждение к заключению какого-либо контракта или обязательства. - -Ничто в этом техническом документе не является предложением о продаже или призывом к покупке каких-либо токенов, обсуждаемых здесь. -В любом случае, если этот технический документ будет считаться таким предложением или ходатайством, никакое такое предложение или ходатайство не предполагается и не передается в этом официальном документе в любой юрисдикции, где это является незаконным, -когда такое предложение или ходатайство требует лицензии или регистрации, или когда такое предложение или ходатайство подлежит ограничениям. -В частности, какие-либо токены, обсуждаемые здесь, не были и на дату выпуска этого документа не должны быть зарегистрированы в соответствии с законами о ценных бумагах или аналогичными законами какой-либо юрисдикции, -независимо от того, считает ли такая юрисдикция такие токены ценными бумагами или аналогичным инструментом, и их нельзя предлагать или продавать в любой юрисдикции, где это будет представлять собой нарушение соответствующих законов такой юрисдикции. - - -# Лицензия - -Исходный код[^src] этой статьи доступен по лицензии Creative Commons Attribution-ShareAlike 4.0 International[^cc]. - -[^src]: См.: @sources -[^cc]: См.: @cc - - -# Введение - -Интернет преимущественно состоит из проектов с открытым исходным кодом с момента его создания. -Со временем многие из этих проектов стали основой, на которой строятся все будущие инновации. -И хотя на этом были нажиты состояния, открытый исходный код в основном создается и поддерживается безвозмездно. - -Мы верим, что все современные человеческие усилия застопорились из-за того, что наименьший процент инженеров в мире выбирал между зарплатой и поддержанием работоспособности Интернета. -Открытый исходный код — это любимое дело, которому часто мешает отсутствие значимых экономических стимулов, в результате чего действительно достойные проекты никогда не достигают своего потенциала, в то время как другие страдают от проблем с безопасностью из-за отсутствия стимулов для поддержки программного обеспечения на протяжении всего его жизненного цикла. -Чтобы полностью реализовать наш потенциал, нам нужна справедливая система вознаграждения для экосистемы с открытым исходным кодом, которая принципиально не меняет то, как она построена или используется. - -Предприятия часто используют бизнес-модели с открытым исходным кодом, полуtea доход непосредственно от работы доброжелательных разработчиков, а также полагаясь на них в исправлении ошибок по мере их возникновения. -Отличным примером является недавний инцидент, связанный с критической уязвимостью системы безопасности в Log4j, пакете Apache Software Foundation, который нашел свое применение во многих коммерческих программах и службах, используемых предприятиями и правительствами. -В ноябре 2021 года исследователь безопасности, работающий в Alibaba Group Holding Ltd., сообщил об уязвимости CVE-2021-44228[^1], которая получила максимально возможную базовую оценку от Apache Software Foundation. -Амит Йоран, исполнительный директор Tenable и директор-основатель Группы готовности к компьютерным чрезвыteaным ситуациям США (US-CERT), назвал эту уязвимость «самой крупной и критической уязвимостью за последнее десятилетие»[^2]. -Последовала паника, и несколько добровольцев, которые поддерживали этот пакет, подверглись публичной критике за провал. -После обращения к возмущению со скромной мольбой о справедливости системы были исправлены. -Предприятия и правительства в конце концов осознали, что Log4j, пакет, используемый широким спектром критически важных систем в течение двух десятилетий, поддерживается несколькими бесплатными добровольцами, теми же незамеченными героями, которые брались за дело, несмотря на злоупотребления со стороны отрасли[^3] и работали не покладая рук. для устранения уязвимости. - -К сожалению, Log4j далеко не единственный пример. -core-js загружается 30 миллионов раз в неделю в качестве основы для каждого приложения Node.js, но при этом практически не финансируется. -Недавно несколько разработчиков ядра биткойнов ушли в отставку, сославшись, среди прочего, на *отсутствие финансовой компенсации* за свое решение. - -Было предпринято несколько попыток создания структур поощрения, обычно включающих системы спонсорства и вознаграждения. -Спонсорство позволяет потребителям открытого исходного кода делать пожертвования на проекты, которые им нравятся. -Однако представьте открытый исходный код как кирпичную башню, где нижние уровни давно забыты, но все еще поддерживаются преданными своему делу инженерами и на них полагаются еще больше разработчиков. -Только проекты на вершине башни обычно известны и получают спонсорскую поддержку. -Этот предвзятый выбор приводит к тому, что основные кирпичи, поддерживающие башню, не привлекают пожертвований, в то время как фавориты получают больше, чем им нужно. -Баунти позволяют потребителям проектов предлагать разработчикам оплату за создание определенных функций, таким образом вознаграждая проекты только за то, что они делают что-то, что не обязательно отвечает их интересам. -И снова только награждение фаворитов. - -В этой статье мы предлагаем tea — децентрализованную систему справедливого вознаграждения разработчиков с открытым исходным кодом на основе их вклада во всю экосистему и реализуемую с помощью алгоритма поощрения tea, применяемого ко всем записям в реестре tea. - -![Упрощенный вид системы вознаграждений за заваривание tea.](img/figure-1.svg) - -$\parskip=0pt plus 1pt$ - -[^1]: Источник: @nist -[^2]: Источник: @reuters -[^3]: Источник: @twitter - - -# Составные части - -Разработчику программного обеспечения, создающему приложение, нужны четыре вещи: браузер, терминал, редактор и менеджер пакетов. -Из этих четырех менеджер пакетов управляет инструментами и платформами, необходимыми разработчику для создания своего продукта. -Именно на этом уровне мы видим возможность изменить способ вознаграждения за открытый исходный код. - -## Менеджер пакетов - -Менеджер пакетов знает, от какого программного обеспечения с открытым исходным кодом зависит функционирование приложения, от вершины башни до ее основания. -Каждый компонент и версия, необходимые для приложения, известны и зарегистрированы. -Он знает, что вершина башни тщательно выбирает свои зависимости, и этот тщательный отбор продолжается вниз. -Менеджер пакетов занимает уникальное место в стеке инструментов разработчика, чтобы обеспечить автоматическое и точное распределение значений на основе фактического реального использования. - -Мы предлагаем неизменяемый децентрализованный реестр, предназначенный для распределения стоимости на основе алгоритма, определяющего вклад каждой записи в полезность и работоспособность системы. -Ценность может входить в граф в точках вершины — приложениях и основных библиотеках — и рекурсивно распределяться по зависимостям этих точек вершины и их зависимостям, поскольку реестр знает весь граф с открытым исходным кодом. - -Кроме того, мы считаем, что существенная информация должна быть доступна через диспетчер пакетов, чтобы разработчики могли оценить, могут ли они доверять пакету и его автору. -Эта информация может основываться на репутации, известности сообщества, данных, полученных из систем децентрализованной идентификации (DID[^4]), других менеджеров пакетов или механизмов стимулирования, которые потенциально полагаются на участников сети, подвергающих риску экономическую ценность. - -Мы прогнозируем, что сочетание инструментов, информации и вознаграждений, которое предлагает tea, будет справедливо стимулировать разработчиков, помогая стимулировать рост программного обеспечения с открытым исходным кодом и способствовать инновациям. - -[^4]: См.: @w3 - -## Децентрализованный реестр - -У каждого менеджера пакетов есть собственный реестр пакетов, который многократно дублирует одни и те же метаданные. -Пришло время создать единый всеобъемлющий и окончательный реестр, разработанный и управляемый сообществами, которые от него зависят. -Этот децентрализованный неизменяемый реестр может обеспечить безопасность, стабильность и предотвратить -злой умысел. - -Интернет работает на десятках тысяч жизненно важных компонентов с открытым исходным кодом. -Примечательно, что до сих пор инциденты, вызванные удалением необходимой инфраструктуры с открытым исходным кодом, были минимальными. -Самым известным было удаление зависимости NPM left-pad[^5] в 2016 году, которая каскадом привела к системам непрерывной интеграции и непрерывного развертывания, оставив разработчиков без работы на несколько дней. -Это событие продемонстрировало, что сам Интернет основан на хрупких системах развития. -Другие примеры связаны с активным или преднамеренным участием сопровождающих пакетов, саботирующих их популярные пакеты (см. colors.js, faker.js[^6] и node-ipc[^7]), -или злоумышленники, стремящиеся получить прибыль, притворяясь, что помогают поддерживать пакеты и искажать их, чтобы украсть, например, закрытые ключи биткойнов (см. Event-stream[^8]), -или вредоносные пакеты с преднамеренными орфографическими ошибками, также известными как опечатки, -в надежде заставить пользователей установить их, например, crossenv vs. cross-env пакеты NPM[^npmjsCrossenv]. - -Целостность программного обеспечения должна быть гарантирована по мере того, как отрасль движется к будущему, в котором цифровые активы являются частью программного обеспечения. -Мы не можем продолжать оставаться уязвимыми для злоумышленников, модифицирующих программное обеспечение. - -Большинство инструментов, которые мы называем менеджерами пакетов, не могут гарантировать, что эти пакеты, встроенные в приложения и децентрализованные приложения, представляют собой неизмененный код с открытым исходным кодом, опубликованный их первоначальными авторами. -GitHub от Microsoft обнаружил, что 17% уязвимостей в программном обеспечении были заложены в злонамеренных целях[^9], а некоторые оставались незамеченными в течение длительного времени (см. Webmin 1.890[^10]). - -Децентрализованный реестр, дополненный системой репутации и поддерживаемый экономическими стимулами, призванными разоблачать плохих участников и вознаграждать хороших участников, может обеспечить гарантии, которые искали сообщества разработчиков. - -[^5]: Источник: @theregister -[^6]: Источник: @fossa -[^7]: Источник: @lunasec -[^8]: Источник: @github -[^npmjsCrossenv]: Источник: @npmjsCrossenv -[^9]: Источник: @zdnet -[^10]: Источник: @threatpost - - -## Система хранения - -Пакеты с открытым исходным кодом предоставляют широкий спектр функций, некоторые из которых могут быть ограничены или нежелательны. -Шифрование — отличный тому пример. -Важным вариантом использования шифрования является поддержка конфиденциальности людей по всему миру. -Однако шифрование также может использоваться в гнусных целях (см. Phantom Secure, демонтированный правоохранительными органами в марте 2018 г. ), -и операция «Троянский щит» (ФБР)[^12], в ходе которой ФБР управляло «зашифрованной» коммуникационной платформой AN0M и убедило преступников использовать свои «зашифрованные» телефоны для безопасной связи). - -Широкое применение шифрования сделало его идеальным вариантом использования программного обеспечения с открытым исходным кодом и прекрасным примером того, что любое решение, хранящее пакеты, должно быть защищено от несанкционированного доступа и цензуры. -tea — это децентрализованный протокол, который не предназначен для фильтрации или санкции пакетов на основе их функциональности. -Несмотря на то, что управление Tea может принять решение об удалении проверенных вредоносных пакетов (дополнительную информацию см. в разделе управления), для системы Tea очень важно подключаться к нескольким системам хранения, в том числе децентрализованным, которые демонстрируют, что пакет не изменен и правильно реплицирован. -Сопровождающие пакеты могут выбрать систему хранения, которая наилучшим образом соответствует их потребностям в безопасном хранении и распространении своих пакетов. - -[^11]: Источник: @fbi -[^12]: Источник: @europol - -# Участники сети - -Миссия tea состоит в том, чтобы расширять возможности сообществ с открытым исходным кодом и обеспечивать поддержку их участников, когда они создают инструменты для построения Интернета. -В этом техническом документе мы отличаем участников по их вкладу. -Некоторые могут внести свой код или проверить добавленный код. -Другие могут представлять экономическую ценность для поддержки разработчиков и их репутации. - -## Сопровождающие пакеты - -Разработчики пакетов должны следить за тем, чтобы их программное обеспечение продолжало приносить все большую пользу по мере развития отрасли. - -tea предполагает, что создатели пакетов сохраняют свою работу. -Сопровождающие пакеты — это столпы сообществ с открытым исходным кодом, которые нуждаются в расширении прав и возможностей и вознаграждении за их постоянный вклад. -Сопровождающий пакета может принять решение о прекращении своих усилий по сопровождению или понять, что он не может работать в темпе, соответствующем ожиданиям пользователей пакета. -Сопровождающие пакеты получают невзаимозаменяемый токен (NFT) после отправки пакета (дополнительные сведения см. в разделе NFT для сопровождающих). -Этот NFT используется для подтверждения их работы и является ключом, определяющим награды за tea. -Владелец NFT пакета может передать свое право собственности другому разработчику (или группе разработчиков), тем самым сделав их сопровождающими пакета и получателями любых будущих вознаграждений. -Точно так же разработчик может решить взять на себя роль сопровождающего пакета, разветвив существующий пакет и отправив новый, который он будет поддерживать в будущем, таким образом становясь одновременно создателем и сопровождающим пакета. - -Крайне важно предоставить сообществам разработчиков правильные инструменты для определения того, какие пакеты поддерживаются, а также репутации и качества работы их прошлых и настоящих сопровождающих. -Мы слишком часто видели, как работу с открытым исходным кодом подделывали, а усилия многих разрушали плохие деятели. -Хотя работа этих злоумышленников в значительной степени обнаруживается и устраняется, часто это происходит только после того, как был нанесен значительный ущерб в результате потери финансов или данных. -Возьмем, к примеру, npm-пакет EventStream[^13], который загружался более 1,5 миллиона раз в неделю и на который полагалось более 1500 пакетов, когда хакеру удалось проникнуть в проект с открытым исходным кодом, -завоевать доверие своего первоначального автора и модифицировать EventStream, чтобы он зависел от вредоносного пакета, который будет передавать учетные данные биткойн-кошелька на сторонний сервер\. -Хотя инструменты могут помочь обнаружить некоторые из этих атак, на них не всегда можно положиться, что создает целое сообщество, зависящее от усердия друг друга и готовности делиться своими выводами. - -Мы предлагаем ввести поощрения с помощью токена tea, описанного в разделе о токене tea, поощряя сообщества разработчиков открытого исходного кода конструктивно сообщать о своих выводах, чтобы разработчики пакетов могли решить их до того, как они будут использованы. - -[^13]: Источник: @medium - -## Пользователи пакета - -Пользователи пакетов — это разработчики программного обеспечения, сосредоточенные на решении конкретной проблемы. -Они часто ищут в сообществе разработчиков ПО с открытым исходным кодом инструменты, необходимые им для быстрого экспериментирования и итерации с минимальными затратами или бесплатно, полуtea непосредственную выгоду от работы создателей и сопровождающих пакетов. -Традиционно подмножество могло выбрать поддержку сопровождающих пакетов за счет пожертвований или других форм вознаграждения; однако это случалось редко. - -Спонсорство может быть эффективной системой поддержки разработки с открытым исходным кодом; однако вознаграждение обычно не распространяется на все зависимости. -Это ограничение приносит пользу фаворитам и мешает инновациям и созданию программного обеспечения. -Чтобы стать основой разработки программного обеспечения, открытый исходный код должен расширять возможности всех разработчиков, будь то новички или эксперты, на всех уровнях башни. - -цель tea состоит в том, чтобы поддерживать основные ценности программного обеспечения с открытым исходным кодом, предоставляя при этом децентрализованную систему для вознаграждения разработчиков пакетов за их работу. -Чтобы выполнить эту миссию, tea намерен разработать — и стимулировать других к разработке — механизмы, позволяющие пользователям пакетов поддерживать тех, кто занимается поддержкой пакетов, с помощью уникальных вариантов использования токена tea, как описано в разделах о токене tea и будущей работе и потенциальных усилиях сообщества. - -## Сторонники и спонсоры пакета - -В Web 2.0 и web3 сторонников пакетов часто называют «спонсорами». Это организации или пользователи пакетов, которые используют программное обеспечение с открытым исходным кодом для создания своих коммерческих продуктов, филантропы, стремящиеся поддержать экосистему, или предприниматели, желающие финансировать команды для разработки компонентов более крупной системы. - -tea предлагает расширить сообщества сторонников пакета на все tea сообщество, будь то организации, разработчики, пользователи или технические энтузиасты. -цель tea — внедрить децентрализованные механизмы стимулирования с помощью уникальных вариантов использования токена tea для любого члена teaного сообщества, чтобы внести свой вклад в постоянную устойчивость и непрерывный рост открытого исходного кода. -Сторонники и спонсоры пакетов могут свободно решать, какие пакеты или сопровождающих пакетов они хотят поддерживать, основываясь на своей работе, убеждениях или любых критериях и показателях, которые могут повлиять на их решение. -Кроме того, поддержка, предоставляемая сторонниками и спонсорами пакетов, будет распространяться на зависимости каждого пакета, таким образом неявно доверяя сопровождающему пакета делать правильный выбор в отношении своего стека и используя эту информацию для улучшения своей репутации. - -При условии, что сопровождающий пакета предлагает такую услугу, сторонник и спонсор пакета может получить взамен премиальный уровень поддержки NFT, таким образом полуtea выгоду от ускоренных соглашений об уровне обслуживания или более гибкого лицензирования. -Кроме того, сторонники пакетов и спонсоры могут принять решение о поддержке пакетов или сопровождающих пакетов и автоматически перенаправить все или часть своих вознаграждений, чтобы стимулировать команды к созданию нового программного обеспечения с открытым исходным кодом. -Другими словами, для того, чтобы tea начал разливаться, не обязательно, чтобы существовали пакеты. -Зарождающиеся проекты могут поддерживаться так же, как и более зрелые, что еще больше стимулирует постоянно развивающуюся среду с открытым исходным кодом. - -## Тестировщики tea - -По мере выпуска новых пакетов или новых версий существующих пакетов необходимо доказуемо демонстрировать достоверность работы. -Эта информация имеет решающее значение для пользователей пакета, чтобы решить, доверять ли как пакету, так и его сопровождающим. -В teaном протоколе эту функцию выполняют дегустаторы tea. - -дегустаторы tea, как правило, являются опытными разработчиками программного обеспечения, готовыми посвятить часть своего времени проверке утверждений, связанных с пакетом (функциональность, безопасность, семантическое управление версиями[^14], точность лицензии и т. д.) -и поставить на кон свою репутацию и экономическую ценность, чтобы продемонстрировать результаты своих исследований и анализа и поддержать свои обзоры. -дегустаторы tea получают вознаграждение за свое усердие и усилия. -За tea мы называем «завариванием tea» действие по блокировке токенов tea для поддержки ваших отзывов и получения вознаграждений (или штрафов) на основе консенсуса относительно достоверности ваших отзывов. - -Как и сторонники пакетов, дегустаторы tea могут влиять на репутацию пакета и его сопровождающего; однако их влияние более существенно, учитывая их роль в проверке безопасности, функциональности и качества пакета. -дегустаторам tea также необходимо будет создать свою репутацию, чтобы поддержать свои претензии. -Качество их работы и экономическая ценность, которой они рискуют, когда они готовят свои обзоры, в сочетании с другими внешними источниками данных будут способствовать укреплению репутации каждого дегустатора tea, повышая ценность его работы. -Подробнее о механизмах, используемых для влияния на репутацию пакета и его сопровождающего, см. в разделе о репутации пакета. - -[^14]: См.: @semver - -# Обзор протокола - -Дизайн протокола для вознаграждения за вклад в открытый исходный код погряз в проблемах. -Программное обеспечение с открытым исходным кодом по определению открыто для всех и, как следствие, может быть объектом неправильного присвоения, присвоения или злонамеренного вмешательства. -Тем не менее, сообщество разработчиков ПО с открытым исходным кодом последовательно демонстрировало свою готовность выявлять хороших актеров и разоблачать плохих. -Исторически сложилось так, что энергия, затрачиваемая на просмотр и комментирование вкладов других разработчиков, была строго добровольной, несмотря на то, насколько трудоемкими и важными могут быть отчеты и защита результатов. - -Мы намерены создать ненадежную платформу распространения приложений, обеспеченную репутацией и финансовыми стимулами, поскольку мы считаем, что адекватное вознаграждение за вклад в открытый исходный код не может быть успешным без системы репутации и возможности для членов сообщества сообщать о своих выводах и поддержке (или несогласие) за пакет или работу разработчика. - -Мы должны предоставить разработчикам инструменты для доступа и участия в этой системе репутации. -Инструменты, которые включают простой визуальный и программируемый доступ к версии и репутации всех зависимостей в своих пакетах. -Четкое понимание того, какие члены сообщества поддерживают каждый пакет и сколько teaных токенов они заваривают, будет способствовать репутации каждого пакета, так же как то, насколько мейнтейнер пакета пропитывает свою работу, сообщает, насколько он поддерживает свою работу. -Эти объединенные точки данных помогут информировать систему репутации для всех членов сообщества и облегчат выбор. -Поскольку взлом пакета EventStream осуществлялся не через сам пакет, а через одну из его зависимостей, видимость всех уровней зависимостей будет иметь жизненно важное значение для построения этой ненадежной системы. -Однако такие соображения, как затраты на вычисления и транзакции («газ»), должны иметь приоритет при проектировании и построении системы. - -Наша цель — вознаградить разработчиков Web 2.0 и Web3. -Сложности и особенности каждого стека делают так, что отслеживание установки и удаления пакетов может легко стать жертвой одного или нескольких злоумышленников. -Это включает в себя «покупку» установок для искусственного завышения цифр. -Еще худшим сценарием было бы введение фундаментальных изменений в природу программного обеспечения с открытым исходным кодом путем создания ненужных трений с лицензионными ключами или другими механизмами отслеживания развертывания. -Чтобы обеспечить самый широкий охват, мы считаем, что вознаграждение не должно основываться на упрощенном понятии отслеживания установок или удалений, а скорее на механизмах стимулирования, которые поощряют отправку качественных пакетов и сообщения о гнусных пакетах или пакетах с высоким риском. -Наконец, многие пакеты полагаются на общие зависимости. -Например, у Lodash 151 209 иждивенцев[^15], в то время как у chalk — 78 854 иждивенца[^16] или у Log4js — 3343 иждивенца[^17]. -Поскольку все больше пакетов создается с использованием одних и тех же зависимостей, как обеспечить справедливое и равноправное распределение поощрений? -Как мы можем гарантировать, что наиболее часто используемые зависимости вознаграждаются, не ограничивая возможности новых или новых пакетов и разработчиков? -Как мы можем гарантировать, что система поощрений не оттолкнет разработчиков от нишевых языков и сосредоточит их там, где поощрения лучше? -Но кроме того, как мы, как разработчики, определяем пакеты с наибольшим количеством зависимостей для создания альтернатив — более компактных, более эффективных версий этих пакетов с лучшим кодом? -За tea мы считаем, что отсутствие стимула препятствует развитию программного обеспечения с открытым исходным кодом. -Поддерживаемые правильными экономическими стимулами и вознаграждениями, больше разработчиков смогут создавать, улучшать и расширять программное обеспечение с открытым исходным кодом для улучшения мира. -Только тогда teaный токен сможет представлять общую стоимость программного обеспечения с открытым исходным кодом. - -[^15]: Источник: @npmjsLodash -[^16]: Источник: @npmjsChalk -[^17]: Источник: @npmjsLogFourjs - -## Отправка пакета - -Отправка выпуска пакета требует, чтобы несколько транзакций выполнялись атомарно. -В частности, сопровождающий пакета должен: - -* Зарегистрируйте пакет (и его семантическую версию) в децентрализованном реестре. -* Загрузите пакет в децентрализованную систему хранения для устойчивости, защиты от цензуры и простоты распространения. -* Способствуйте репутации и надежности пакета, *заварив* teaные токены. - -Невыполнение любой из трех операций приведет к тому, что протокол вернется в свое предыдущее состояние, что приведет к устранению любых свидетельств отправки. - -Когда пакет успешно отправлен, сопровождающий пакета получит NFT сопровождающего, чтобы подтвердить свою работу и вклад в открытый исходный код. -Сопровождающий пакет может передать вознаграждение за пополнение, связанное с NFT сопровождающего, третьей стороне. -Однако репутация, связанная с созданием и обслуживанием актива, останется у сопровождающего пакета, поэтому его репутация может со временем измениться. -По мере того, как репутация любого члена teaного сообщества достигает ключевых вех, ему может быть предоставлен доступ к повышенным частям протокола или ускоренное вознаграждение по решению руководства tea. -Дополнительные сведения о NFT сопровождающего см. в разделе NFT сопровождающего. - -### Анализ зависимостей - -Зависимости пакетов могут быть глубокими, поскольку у каждого пакета часто есть как зависимые, так и зависимые компоненты. -Чтобы предоставить простую методологию, которая вознаграждает всех разработчиков, внесших свой вклад в программное обеспечение с открытым исходным кодом, сохраняя при этом создание дерева зависимостей быстрым и эффективным с точки зрения вычислений, мы предлагаем проверять только зависимости первого уровня при отправке пакета. - -Этот дизайн основан на гипотезе о том, что каждая зависимость сама по себе является пакетом, который был независимо представлен teaному дереву. -При этом каждая из его зависимостей может быть сопоставлена, и если его зависимости сами имеют зависимости, они будут сопоставлены во время отправки пакета зависимостей. - -![Диаграмма анализа зависимостей.](img/figure-3.svg){#fig:dep-analysis} - -В @fig:dep-analysis отправка пакета A запускает анализ зависимостей среды выполнения с 1 по n и зависимостей сборки с 1 по n, в то время как зависимости среды выполнения с 1.1 по 1.n и зависимости сборки с 1.1 по 1.n анализировались, когда пакет B был представлен. -Мы будем применять ту же методологию для распределения поощрений, поскольку пропитанные токены распределяются по всем зависимостям, таким образом рекурсивно пропитывая пакеты, перечисленные в качестве зависимостей (см. @fig:steeping-rewards). - -![Распределение наград Steeping по зависимостям.](img/figure-2.svg){#fig:steeping-rewards} - -Версии и конфликтующие зависимости — это серьезные проблемы, и их устранение может обернуться огромной тратой времени. -Чтобы решить эту проблему, мы предлагаем, чтобы каждый пакет подвергался всестороннему сканированию зависимостей при отправке, чтобы мы могли убедиться, что пакет соответствует следующим правилам для семантических диапазонов версий. - -* Пакеты могут ограничивать свои зависимости только основной версией, хотя началом диапазона может быть любая допустимая семантическая версия (например, >=5.2.1 <6). -* Если зависимость обновлена ​​до более поздней основной версии, tea может потребовать увеличения основной версии пакета. -* Точно так же, если зависимость обновляется до более поздней дополнительной версии, tea может потребовать увеличения дополнительной версии пакета. -* Если добавляется новая зависимость, tea может потребовать увеличения минорной версии пакета. - -Принимая во внимание ненужные усилия, возлагаемые на любого пользователя пакета при нарушении вышеуказанных правил, мы предлагаем урезать часть токена tea, полученного сопровождающим пакета, чтобы отразить отсутствие должной осмотрительности. -Если разработчик заставит всех жонглировать своими чашками, кто-то прольет tea. -Поскольку ожидается, что сканирование зависимостей произойдет при отправке, мы должны отметить, что не произойдет никакого замачивания со стороны сторонников и спонсоров пакета или дегустаторов tea. - -## Пакет и репутация сопровождающего пакета - -Сопровождающие пакеты должны вносить свой вклад в репутацию и надежность своего пакета, замачивая токены tea. -Однако система репутации, основанная исключительно на экономическом вкладе автора, не обеспечивает достаточной защиты пользователей и может быть подвержена атакам Сивиллы, когда один человек создает несколько представлений о себе, чтобы оставить большое количество положительных отзывов о своей работе. -обманом заставляя пользователей поверить, что их работа была проверена и одобрена многими. - -Для предотвращения атак Sybil доступно несколько методологий, некоторые из которых описаны Нитишем Балачандраном и Сугатой Саньялом в «Обзоре методов смягчения атак Sybil»[^18]. -Поскольку tea является децентрализованным протоколом, использование системы сертификации доверия, основанной на централизованном центре выдачи сертификатов, противоречит ее сути. -Мы предлагаем сосредоточиться на децентрализованных подходах к противодействию атакам Sybil и, в частности, на методологиях, которые полагаются на большую группу участников сети, стимулируемых для оценки и публичного представления репутации каждого пакета и его сопровождающего. - -Подобно производству блоков в блокчейне с доказательством доли, где непроизводящие узлы могут проверять работу других и, при необходимости, подчеркивать нарушение правил сети, что приводит к наказанию злоумышленника. путем рубки (уничтожения части их доли), -мы предлагаем систему, с помощью которой третьи стороны (также известные как дегустаторы tea) смогут просматривать пакеты, созданные сопровождающими пакетов, и будут экономически мотивированы вести себя в интересах сообщества программного обеспечения с открытым исходным кодом и его пользователей, а также признавать хорошее поведение и наказывать плохое поведение. -Эта система должна быть как устойчивой к Sybil, так и предотвращать существенное влияние крупных держателей токенов на протокол или репутацию конкретных пакетов. -Мы считаем, что этот подход больше соответствует открытому исходному коду, обеспечивая более благодатную почву для принятия и доверия и, в конечном итоге, способствуя росту tea. - -[^18]: Источник: @arxiv - -## Проверка пакета третьими сторонами - -Проверка пакетов третьими сторонами является важным компонентом построения репутации, однако сторонняя проверка имеет свой собственный набор уникальных угроз, вклюtea вышеупомянутые атаки Sybil. - -Технология блокчейна и, в более явном виде, стейкинг предлагают tea уникальную возможность решить эту проблему. -Хотя адреса кошельков могут быть доступны в бесконечном количестве, это не относится к teaным токенам, первоначальный запас которых, как ожидается, составит 10 миллиардов. -Кроме того, каждое действие, выполняемое разработчиками, такое как отправка пакетов, проверка пакетов или их замачивание, будет способствовать их репутации, таким образом создавая уникальный профиль, который каждый разработчик может использовать как для вклада в tea сообщество, так и для участия в управлении tea. - -Требуя от сторонних рецензентов заваривать teaные токены и брать на себя риск потери части своих замоченных токенов, если окажется, что они ведут себя вразрез с интересами сети или действуют недобросовестно, третьи лица могут обеспечить дополнительное доверие к пакету и получить награду, в виде teaных токенов. - -Мы также предлагаем распространить систему репутации на третьих лиц, осуществляющих независимую проверку упаковок – дегустаторов tea. -Для завершения положительного обзора потребуются две атомарные операции: - -* Предоставление обзора кода, подписанного дегустатором tea и общедоступного для всех членов сообщества, вместе с -* Акт вымачивания «за» упаковку (против «против» упаковки), чтобы обосновать их отзыв. - -Завершение отрицательного обзора, который включает одну или несколько критических уязвимостей, потребует от дегустаторов tea сначала связаться с сопровождающим пакета, используя протокол обмена сообщениями, чтобы уведомить их об уязвимости и позволить им своевременно решить проблему. -По истечении установленного руководством периода, отведенного сопровождающему пакета для устранения уязвимости, или по мере того, как исправленный пакет станет доступным, будет использоваться один и тот же протокол обмена сообщениями для уведомления всех пользователей и тестировщиков этого пакета (вклюtea зависимых) о том, что уязвимость была обнаружена. идентифицированный, -и, надеюсь, устранены, чтобы они знали, что нужно обновить свое приложение или зависимости. -Чтобы не стимулировать трату времени разработчиков, общение между дегустаторами tea и сопровождающими пакетов потребует, чтобы дегустаторы заваривали teaные токены. - -После выполнения обеих операций дегустаторы tea получат NFT в качестве доказательства их работы над конкретной упаковкой и версией упаковки. -Накопление NFT в сочетании с коэффициентом замачивания каждой из рассмотренных упаковок и информацией, извлеченной из внешних систем, повлияет на репутацию дегустатора tea. -По мере того, как их репутация достигает ключевых показателей, дегустаторы tea могут получить доступ к расширенным частям протокола или ускоренным вознаграждениям, как будет принято руководством tea. - -## Устаревшие или поврежденные пакеты - -миссия tea — вознаграждать авторов и участников сообществ с открытым исходным кодом; однако вознаграждение должно быть соизмеримо с усилиями, приложенными сопровождающими пакетов и дегустаторами tea. -Недостаточно поддерживаемые, устаревшие или поврежденные пакеты — явные признаки того, что сопровождающие пакетов не оправдывают ожиданий сообщества или не оправдывают доверия и поддержки, оказанных им в результате погружения пакетов. -Другим проявлением устаревших пакетов может быть продолжающееся использование устаревшего языка или устаревшей версии многоверсионных языков. -Пакеты, остающиеся устаревшими или поврежденными в течение слишком долгого времени, указывают на то, что дегустаторам tea необходимо регулярно и последовательно проверять работу сопровождающих пакетов. - -Дегустаторы tea являются критически важными членами сообществ открытого исходного кода в том смысле, что их обзоры и связанные с ними претензии могут направлять пользователей пакетов к пакетам или от них. -Чтобы гарантировать, что отзывам можно доверять на постоянной основе, мы предлагаем механизм, с помощью которого устаревшие или поврежденные пакеты могут видеть часть своих пропитанных токенов, отправленных дегустаторам tea, которые первыми обнаружили отсутствие обслуживания любого пакета. - -Любой отрицательный отзыв, в котором указывается недостаток, такой как уязвимость нулевого дня или использование устаревшей зависимости, и который остается открытым по истечении льготного периода, установленного руководством, должен рассматриваться как ошибка со стороны сопровождающего пакета. -Они не выполнили задачу, которую им доверили и за которую они были вознаграждены. -То же самое можно сказать о сторонниках и спонсорах пакетов, которые поставили свою репутацию на работу недобросовестных сопровождающих пакетов и получили за это вознаграждение, но не смогли определить отсутствие поддержки или решили продолжать поддерживать пакет, несмотря ни на что. - -По мере того, как пакеты становятся все более популярными и используются, а от них зависит все больше приложений и потенциально критически важных систем, мы должны стимулировать разработчиков к тому, чтобы они незаметно сообщали о недостатках сопровождающему пакета и сопровождающему пакета для устранения таких недостатков до того, как они могут быть использованы. -Следовательно, мы предлагаем, чтобы любой устаревший или поврежденный пакет, который является предметом одного или нескольких подтвержденных отрицательных отзывов и остается в таком состоянии по истечении установленного руководством периода отсрочки, видел, что часть его защищенных токенов была сокращена независимо от их происхождения (сопровождающий пакет, пакет сторонники и спонсоры или предыдущие дегустаторы tea), -а другая часть отправляется дегустаторам tea, оставившим негативные отзывы. -Распределение среди всех дегустаторов tea может быть основано на возрасте их обзора и количестве teaных токенов, которые они заварили для своего обзора. - -## Сопровождающий NFT - -После успешной отправки пакета сопровождающий пакета получит NFT, подтверждающий их работу и вклад. -Владелец этого NFT автоматически получит все вознаграждения, связанные с пакетом. -Сопровождающие пакеты могут передать права на обслуживание пакета другому сопровождающему, просто передав NFT пакета. -Успешная передача NFT приведет к тому, что новый владелец автоматически получит будущие вознаграждения за пакет. - -Важная часть создания репутации зависит от частоты и количества отправки качественных пакетов. -NFT, доставленный сопровождающим пакета в качестве доказательства их работы, может использоваться системой репутации для обновления репутации сопровождающего пакета и предоставления ему доступа к повышенным частям протокола, как будет принято руководством tea. -Однако для предотвращения векторов атак, таких как покупка репутации членами сообщества, передача NFT сопровождающего не приведет к передаче репутации. -Репутация должна оставаться непосредственно связанной с работой конкретного разработчика и не может быть передана другому лицу. - -# teaный токен - -## Защита сети - -Хотя многие блокчейны могут показаться эффективными и безопасными инфраструктурными решениями для достижения целей tea, мы считаем, что необходимо уделить пристальное внимание технологическому стеку, на котором построена система tea. - -Масштабируемость, экономичность, ESG и сторонняя расширяемость являются важными факторами проектирования, которым могла бы лучше соответствовать суверенная система доказательства доли владения. -При подтверждении доли операторы узлов и участники сети делают ставку на экономическую ценность в виде собственного токена цепи для повышения безопасности системы. -Операторы узлов и участники сети получают вознаграждение за успешное производство блоков, которые соответствуют правилам сети и содержат точную информацию о транзакциях. -Бездействие (т. е. отказ узла) или злонамеренная/неправильная активность наказываются путем уничтожения части поставленных токенов посредством слэшинга. - -Система Proof-of-Stake, основанная на токене tea, позволит держателям токенов tea внести свой вклад в безопасность системы, *ставя* tea, и поддерживать разработчиков с открытым исходным кодом, *заварив* tea. -Мы полностью осознаем, что экономические факторы могут помешать некоторым разработчикам делать ставки или заваривать tea; таким образом, стейкинг и заваривание будут доступны всего за один лист, а наименьший номинал tea составляет одну стомиллионную (10^{-8}$) tea. - -Оба приложения токена tea выполняют жизненно важные функции в поддержке и развитии экосистемы с открытым исходным кодом. -Стейкинг tea обеспечит безопасную работу teaной системы, поэтому все участники сети смогут отправлять и получать доступ к пакетам для их просмотра, интеграции в свое приложение и т. д. -Напротив, заваривание tea будет поддерживать цель tea по предоставлению инструментов для всех участников сети для поддержки и использования пакетов, отвечающих требованиям качества и надежности, сформулированным teaным сообществом посредством их поддержки и несогласия с каждым пакетом. -При определении и реализации параметров стейкинга и замачивания необходимо соблюдать осторожность, чтобы одно не паразитировало на другом. - -## Поощрения и штрафы - -Как обсуждалось ранее, у злоумышленников могут быть серьезные стимулы для компрометации программного обеспечения с открытым исходным кодом. -Большая часть критически важной инфраструктуры Интернета работает на основе открытого исходного кода, и гонка по поиску эксплойтов и других уязвимостей продолжается. -За tea мы считаем, что мейнтейнеры пакетов — не те, кого следует винить (хотя они часто так и делают). - -Стимулы по teaному протоколу исправляют это за счет справедливого и равноправного распределения поощрений. -Такой пакет, как Lodash с более чем 151 тысячами зависимых компонентов, является основой разработки с открытым исходным кодом, и его сопровождающий заслуживает пропорционального вознаграждения. -Однако система вознаграждения, построенная исключительно на количестве иждивенцев, не позволит новаторам разрушить эти монополии, если они не будут достаточно финансироваться третьими сторонами или уже накопили достаточно ресурсов для самофинансирования. -Такой подход, скорее всего, приведет к сокращению числа участников, что приведет к полной противоположности тому, что представляет собой tea. - -цель tea состоит в том, чтобы представлять ценность программного обеспечения с открытым исходным кодом и, таким образом, способствовать его росту, предоставляя его участникам ресурсы, необходимые им для беспрепятственного осуществления своей страсти. -Система поощрения tea должна тщательно учитывать коэффициент заваривания каждой упаковки и соответствующим образом корректировать поощрение каждой упаковки. -Чтобы снизить риск того, что небольшое количество пакетов, используемых в качестве зависимостей во многих приложениях, будет получать большую часть вознаграждений за пополнение, мы воспользуемся исследованием, проведенным фондом web3[^19] для механизма вознаграждений на основе Polkadot. -Мы можем дополнительно скорректировать реализацию и ее переменные на основе результатов практических экспериментов. - -По мере того, как крутой пакет приближается к оптимальному коэффициенту погружения, определенному руководством, его коэффициент вознаграждения за погружение будет постепенно уменьшаться. -Когда пакет превышает оптимальный коэффициент заваривания, коэффициент вознаграждения за заваривание резко снижается, чтобы лишить сторонников пакета и дегустаторов tea дальнейшего заваривания сильно замачиваемых пакетов. -Этот дизайн может позволить упаковкам с меньшим погружением стать более привлекательными как для сторонников упаковки, так и для дегустаторов tea. -Это также может побудить опытных разработчиков создавать альтернативы высококлассным пакетам, создавая возможность для teaного сообщества сбалансировать поддержку существующего программного обеспечения и продвижение инноваций. -Коэффициент замачивания будет рассчитываться с использованием оборотной подачи в его первоначальном проекте. -tea сообщество может изменить этот дизайн, чтобы еще больше улучшить масштабируемость системы. -Пусть $\chi$ будет коэффициентом замачивания для всех пакетов. -Он представляет собой общее количество teaных токенов, полученных сопровождающими пакета, пользователями пакета, сторонниками и спонсорами пакета, а также дегустаторами tea, деленное на общее количество teaных токенов. -Учитывая, сколько пакетов с открытым исходным кодом доступно сегодня и их ожидаемый рост, $\chi$ всегда будет очень небольшим значением между $0$ и $1$. - -Пусть $\psi$ будет коэффициентом ставок. -Он представляет собой общее количество teaных токенов, поставленных любым участником сети для защиты сети. - -Пусть $\chi_{ideal}$ будет коэффициентом погружения, которого мы хотели бы достичь для каждого пакета для справедливого распределения вознаграждений между всеми пакетами и их зависимостями. -Значение $\chi_{ideal}$ необходимо обновлять по мере добавления новых пакетов в децентрализованный реестр и создания зависимостей. -Чтобы определить наилучшее значение для $\chi_{ideal}$, мы будем использовать колоколообразную кривую популярности, обновляемую в начале каждого цикла вознаграждения. - -Пусть $\tau = \tau(\chi)$ будет годовой процентной ставкой за заварку, распределяемой между всеми членами teaного сообщества, которые заваривают teaные токены для поддержки разработчиков с открытым исходным кодом. -Другими словами, $\tau(\chi)$ соответствует вознаграждению за заваривание, полученному в течение года членом сообщества, который заваривает teaные токены в течение всего года. - -Пусть $\gamma = \gamma(\psi)$ будет годовой процентной ставкой, распределяемой между всеми операторами узлов и участниками сети, которые размещают teaные токены для защиты сети. -Другими словами, $\gamma(\psi)$ соответствует вознаграждению за стейкинг, полученному в течение года членом сообщества, который ставит teaные токены на весь год. - -Пусть $\delta$ - годовая инфляция, направленная на сетевую казну. -$\delta$ может варьироваться в зависимости от внешних факторов, влияющих на количество токенов. - -Мы рассматриваем годовую ставку вознаграждения за стейкинг как функцию $\chi$ и годовую ставку вознаграждения за стейкинг как функцию $\psi$. - -* $\tau(\chi)$ соответствует стимулу для людей заваривать пакет. -По мере увеличения $\chi$ требуется меньше наград $\tau(\chi)$. -* $\gamma(\psi)$ соответствует стимулу для людей делать ставки в сети. -По мере увеличения $\psi$ для защиты сети требуется меньше вознаграждений $\gamma(\psi)$. - -Годовая инфляция $I$ будет эквивалентна $(\tau + \gamma + \delta)$ и рассчитывается следующим образом: - -$$ -I = \frac{\textrm{предложение токенов на конец года} - \textrm{предложение токенов на начало года}}{\textrm{предложение токенов на начало года}} = (\tau + \gamma + \delta) -$$ - -Следует взвесить вклад в инфляцию $\tau_{\textsc{all}}$ (поощрение, распространяемое на всех участников пакета) и $\gamma_{\textsc{all}}$ (поощрение, распределяемое между всеми участниками сетевой безопасности). чтобы система стимулировала оптимальное соотношение погружения/стекинга. - -Сосредоточившись на стимулах, распределенных по всем участникам пакета, мы определяем, что -$\tau_{\textsc{all}}$ -является функцией коэффициента замачивания $\chi$ и, следовательно, -$\tau_{\textsc{all}}(\chi) = \chi \cdot \tau(\chi)$. -Из нашего предыдущего анализа мы видим, что -$\tau_{\textsc{all}}(\chi_{ideal}) = \chi_{ideal} \cdot \tau_{ideal}$. -Поскольку цель состоит в том, чтобы достичь состояния, при котором -$\chi = \chi_{ideal}$ -, награды -$\tau_{ideal}(\chi)$ -должно быть максимальным при этом значении. - -Пусть $\tau_{ideal} = \tau(\chi_{ideal})$ -будет ставкой вознаграждения, предоставляемой сетью в идеальном сценарии, когда -$\chi = \chi_{ideal}$. -Пусть $\tau_{0}$ будет пределом $\tau_{\textsc{all}}(\chi)$, поскольку $\chi$ стремится к нулю, когда ни один член teaного сообщества не заваривает пакеты. -Значение $\tau_{0}$ должно быть близко к нулю, но не равно нулю, чтобы стимулировать первых пользователей. -Согласно результатам исследования фонда web3 Foundation, мы предлагаем следующее: - -* функция инфляции растет линейно между $\chi = 0$ и $\chi = \chi_{ideal}$, и -* он экспоненциально затухает между $\chi = \chi_{ideal}$ и $\chi = 1$. - -Мы выбрали аналогичное экспоненциальное уменьшение для $\tau_{\textsc{all}}(\chi)$, потому что оно предполагает экспоненциальное уменьшение $\tau(\chi)$, и мы хотим, чтобы вознаграждение резко упало за пределы $\chi_{ideal}$, чтобы предотвратить получение всех наград одним пакетом. - -Затухание определяется таким образом, что уровень инфляции уменьшается не более чем на 50%, когда $\chi$ смещается на $d$ единиц вправо от $\chi_{ideal}$, т.е. -$\tau_{\textsc{all}}(\chi_{ideal} + d) \geq \tau_{\textsc{all}} \cdot 0,5$. - -Мы предлагаем следующие функции процентной ставки и уровня инфляции, которые зависят от параметров $\chi_{ideal}$, $\tau_{ideal}$, $\tau_{0}$ и $d$. - -\begin{align*} -&\tau_{\textsc{all}}(\chi) = \tau_{0} + (\tau_{\textsc{all}}(\chi_{ideal}) - \tau_{0})\frac{\chi}{\chi_{ideal}}\enspace\textrm{for}\;0 < \chi \leq \chi_{ideal} \\ -&\tau_{\textsc{all}}(\chi) = \tau_{0} + (\tau_{\textsc{all}}(\chi_{ideal}) - \tau_{0}) \cdot 2^{(\chi_{ideal}-\chi)/d}\enspace\textrm{for}\;\chi_{ideal} < \chi \leq 1 -\end{align*} - -Так же, как хороших актеров нужно вознаграждать; плохие актеры должны быть выявлены и наказаны. -Программное обеспечение с открытым исходным кодом предоставляет злоумышленникам множество возможностей для создания болевых точек и репутационных рисков для всего сообщества разработчиков. -От незаконного присвоения работы до изменения и распространения программных пакетов или внедрения гнусного кода война между хорошими и плохими акторами продолжается, часто с хорошо финансируемыми плохими акторами, которые видят в заражении пакетов с открытым исходным кодом возможность. получить финансовую выгоду. -Недостатки были относительно минимальны: пакеты потенциально были запрещены на цифровых полках или имели плохую репутацию. - -Мы предлагаем ввести механизм сокращения, чтобы установить более существенный недостаток, который напрямую влияет на экономическую ценность злоумышленников. -По мере того как дегустаторы tea оценивают и анализируют код во вновь представленных пакетах, мы предлагаем дегустаторам tea получить инструменты и поощрения для выявления и выделения вредоносного кода, чтобы пользователи пакетов могли быть осведомлены о рисках, а сопровождающие пакеты, сторонники пакетов и спонсоры были оштрафованы. за отправку или поддержку нечестного кода. -В этом отношении за все подтвержденные негативные отзывы, выполненные в соответствии с правилами сети и рассмотренные сопровождающим пакета в течение периода, установленного руководством, ответственный за пакет не должен подвергаться никаким штрафам, в отличие от сторонников и спонсоров пакета или дегустаторов tea, которые предоставил положительный отзыв о рассматриваемом пакете. -Для негативных отзывов, выполненных в соответствии с правилами сети и которые сопровождающий пакета не рассмотрел в течение периода, определенного управлением, часть токенов, полученных сопровождающим пакетом, сторонниками и спонсорами пакета, а также предыдущими дегустаторами tea, будет сокращена. -Другая фракция будет заперта в страховом пуле, контролируемом teaным управлением. -Руководство tea установит политики и правила в тесном сотрудничестве с сообществом для распространения содержимого пула среди тех, кто пострадал от уязвимостей. -Протокол будет распределять треть заваренных токенов среди всех дегустаторов tea, которые внесли свой вклад в отрицательный отзыв и заварили пакет, в зависимости от количества teaных токенов, которые они заваривали «против» пакета, и того, как долго их токены замачивались. -Другими словами, чем раньше один или несколько дегустаторов tea выявят и сообщат о недостатке в соответствии с правилами сети, тем выше вознаграждение, которое они получат за поддержку безопасной и продуктивной разработки с открытым исходным кодом. - -Чтобы члены сообщества не могли слуteaным образом голосовать «против» сильно замоченных пакетов в надежде получить большую часть любого штрафа, все teaные токены, замоченные «против», не будут вознаграждены инфляцией и могут подвергаться механизму распада, что со временем снижает их ценность. - -[^19]: Источник: @web3 - - -# Управление - -Управление имеет решающее значение для разработки, устойчивости и внедрения любой распределенной системы. - -Мы предлагаем, чтобы tea включал управление в сети, где все держатели токенов tea могут предлагать и голосовать за изменения критических параметров, взвешенных по владению токеном и репутации. -Эти параметры могут включать в себя инфляцию, комиссию за транзакции, вознаграждение за стекинг, вознаграждение за погружение или оптимальный коэффициент погружения. -Эта функциональность гарантирует, что критические параметры могут развиваться и оптимизироваться с течением времени членами teaного сообщества. -Мы ожидаем, что управление начнется с простой структуры и будет постепенно расширяться по мере развития teaной системы, облегtea внедрение и обеспечивая постепенную децентрализацию. - -Некоторые системные параметры могут не подлежать управлению или поддерживать частое изменение, чтобы уменьшить поверхность атаки, представляемую управлением. -Постепенный переход параметров к открытому, децентрализованному управлению обеспечит стабильность и предсказуемость системы. - - -# Сторонняя расширяемость - -Поскольку мы создаем первоначальные инструменты, чтобы зажечь давно назревшую поддержку сообществ разработчиков открытого исходного кода, мы считаем, что часть нашей миссии состоит в том, чтобы третьи лица могли расширять общий набор инструментов. -В дополнение к предоставлению разработчикам инфраструктуры для создания расширений протокола, вклюtea новые способы инноваций и дальнейшей поддержки разработчиков с открытым исходным кодом, в наши планы входит возможность участия других менеджеров пакетов в протоколе. -Мечты и усилия разработчиков с открытым исходным кодом создали инновации, которые поддерживают нашу повседневную жизнь. -Мы с нетерпением ждем возможности открыть для себя новые способы использования и расширения tea, предложенные teaным сообществом. - - -# Будущая работа и потенциальные усилия сообщества - -По мере развития teaной системы мы предвидим, что сообщество будет принимать решения и вносить свой вклад в изменения и расширения teaной системы посредством управления. -Ниже приведены некоторые идеи, которые, по нашему мнению, могут кого-то вдохновить. - -## Оптовики tea - -Сообщества разработчиков программного обеспечения с открытым исходным кодом динамичны и постоянно ищут инновации и приносят пользу. -Эта самоотверженность и альтруизм приводят к постоянному созданию нового программного обеспечения и пакетов, каждый из которых имеет свои зависимости. -В результате мы ожидаем, что карта зависимостей будет постоянно развиваться, что приведет к частым изменениям коэффициента погружения и вознаграждений. -В будущем tea сообщество может предложить разработку системы, предназначенной для динамического мониторинга коэффициента замачивания для каждого пакета и перебалансировки того, как сторонники пакетов замачивают свои токены на основе их собственных критериев. - -## Роялти за передачу пакета - -Мы понимаем, что сопровождающие пакетов могут решить передать поток своих вознаграждений одному или нескольким разработчикам. -Управление такой передачей должно оставаться на усмотрение сопровождающего пакета и его партнеров без вмешательства tea. -Необходимо будет предоставить инструменты для того, чтобы такая передача была полной или частичной (возможно, за счет перенаправления только части вознаграждения за погружение одному или нескольким разработчикам, в то время как оставшиеся вознаграждения продолжают поступать к сопровождающему исходного пакета). -и чтобы вознаграждения за заваривание проходили через одну учетную запись, контролируемую одним участником сети, несколькими участниками сети, или автоматически распределялись между несколькими учетными записями с использованием статических или динамических коэффициентов. - -## Распределение вознаграждений между несколькими сопровождающими - -Сопровождение пакета может зависеть от работы еще одной команды разработчиков. -Прежде чем начнут поступать вознаграждения за погружение, командам следует подумать об автоматизации распределения вознаграждений за погружение между собой. -Как происходит распределение, должны решать сами сопровождающие, поскольку они лучше всего могут оценить, кто внес свой вклад и как они должны быть вознаграждены. - -Для этого каждая команда (или команды) может создать свою собственную децентрализованную автономную организацию (ДАО) и либо автоматизировать распределение вознаграждений, либо развернуть более сложные системы для определения адекватного распределения вознаграждений на основе внешних факторов, таких как голосование всех ДАО. члены, -или временные распределения, основанные на постоянном вкладе, успешном завершении наград и т. д. - - -## Обработка пакета «Вилки» - -Мы считаем, что вилки необходимы и в значительной степени используются недостаточно. -Форки могут быть эффективным инструментом для разработки пакетов, конкурирующих по функциональности, производительности, безопасности и даже вниманию. -Какими бы полезными они ни были, вилки должны распознавать первоначальные усилия. -Благодаря будущей работе или потенциальному вкладу tea сообщество может усовершенствовать систему, чтобы требовать объявления вилок, возможно, даже обнаружения при отправке пакета. -Необъявленные вилки, обнаруженные дегустаторами tea, могут привести к тому, что часть пропитанных токенов будет урезана, передана сопровождающему оригинального пакета и отправлена ​​дегустаторам tea, которые выявили вилку. - -## Время выполнения и зависимости сборки - -tea может не отличать зависимости сборки от зависимостей времени выполнения при раздаче наград за заварку при запуске. -Однако, при условии, что tea сообщество решительно настроено провести такое различие, tea сообщество может предложить усовершенствования алгоритма распределения вознаграждений за заварку, чтобы учесть критичность каждой зависимости и их вклад в стоимость пакетов, которые от них зависят. -По этим предложениям будет проведено голосование, и они будут реализованы на основе решения сообщества. - -## Вознаграждение за использование - -Поскольку все больше приложений создается с использованием пакетов, зарегистрированных с помощью tea, сообщество может расширить алгоритм вознаграждения, чтобы на распределение могли влиять внешние подтвержденные наборы данных, такие как использование. -Это обновление механизма поощрения может позволить более высокое распределение наград в виде токенов tea для пакетов с наибольшим использованием, при этом соблюдая ограничения коэффициента замачивания, описанные в разделе о токенах tea. -Сопровождающие пакеты могут использовать аналогичный подход для распределения вознаграждений за заварку между своими зависимостями на основе прозрачной логики по своему выбору. -Обратите внимание, что вся информация, используемая для влияния на распределение вознаграждений между пакетами и зависимостями в teaной системе, должна быть доказуемо надежной. - - -# Acknowledgments - -This white paper would not exist without the support and dedication of many teaophiles. -The authors would like to acknowledge Josh Kruger, Jadid Khan, and Jacob Heider for their contribution to the tokenomics and the many discreet individuals who volunteered their time to provide feedback on the contents of this document. - -$\parskip=0pt plus 1pt$ - -# Словарь терминов - -| Срок | Определение | -|------|------------| -| лист | Наименьший номинал teaного токена. Лист соответствует одной стомиллионной ($10^{-8}$) tea. | -| Рубка | Действие по наказанию крутящихся или стейкеров в ответ на поведение, противоречащее правилам сети. | -| Стейкинг | Действие по блокировке teaных токенов для защиты сети Proof-of-Stake, на которой построена teaная система. | -| Замачивание | Действие по блокировке teaных токенов для подтверждения вашего требования и получения вознаграждения (или штрафа) на основе консенсуса относительно обоснованности вашего требования. | - - -# Использованная литература diff --git a/i18n/uk/white-paper.md b/i18n/uk/white-paper.md deleted file mode 100644 index 591241d..0000000 --- a/i18n/uk/white-paper.md +++ /dev/null @@ -1,583 +0,0 @@ -# Відмова від відповідальності - -Інформація, викладена в цьому документі, має попередній характер. -Отже, ані автори, ані будь-яка з їхніх відповідних філій не несуть жодної відповідальності за те, що викладена тут інформація є остаточною чи правильною, а кожне з вищезазначених застережень, -у повному обсязі, дозволеному застосовним законодавством, будь-яка та вся відповідальність, незалежно від того, яка виникає внаслідок делікту, контракту чи іншим чином, стосовно цього документу. -Ні цей білий документ, ні будь-що, що міститься в ньому, не може бути основою для укладення будь-якого контракту чи будь-якого зобов’язання, або на нього можна покладатися у зв’язку з ним або спонукати його укладати. - -Ніщо в цьому білому документі не є пропозицією продати чи закликом придбати будь-які токени, які тут обговорюються. -У будь-якому випадку, якби цей білий документ вважатися такою пропозицією чи проханням, жодна така пропозиція чи прохання не передбачається та не передається цим білим документом у будь-якій юрисдикції, де це є незаконним, -якщо така пропозиція чи прохання потребуватимуть ліцензії чи реєстрації, або якщо така пропозиція чи прохання підпадає під обмеження. -Зокрема, будь-які токени, які обговорюються в цьому документі, не були зареєстровані відповідно до законодавства про цінні папери чи подібних законів будь-якої юрисдикції, і станом на дату випуску цього документу не призначено для реєстрації, -незалежно від того, чи вважає така юрисдикція такі токени цінним папером чи подібним інструментом і чи їх заборонено пропонувати або продавати в будь-якій юрисдикції, де це буде порушенням відповідних законів такої юрисдикції. - - -# Ліцензія - -Вихідний код[^src] цього документа доступний за ліцензією Creative Commons Attribution-ShareAlike 4.0 International[^cc]. - -[^src]: див.: @sources -[^cc]: див.: @cc - - -# Вступ - -Інтернет переважно складається з проектів з відкритим вихідним кодом і є таким з моменту свого створення. -З часом багато з цих проектів стали основоположними елементами, на яких будуються всі майбутні інновації. -І хоча на цьому були зароблені статки, відкритий код в основному створюється та підтримується без винагороди. - -Ми вважаємо, що всі зусилля сучасної людини були загальмовані через те, що вони покладаються на найменший відсоток світових інженерів у виборі між зарплатою чи підтриманням роботи Інтернету. -Відкритий вихідний код — це праця любові, якій часто заважає відсутність значущих економічних стимулів, що призводить до того, що справді варті проекти ніколи не досягають свого потенціалу, тоді як інші страждають від проблем безпеки через відсутність стимулів підтримувати програмне забезпечення протягом усього його життєвого циклу. -Щоб повністю реалізувати наш потенціал, нам потрібна справедлива система винагороди для екосистеми з відкритим вихідним кодом, яка принципово не змінює її побудову чи використання. - -Підприємства часто обертають бізнес-моделі навколо відкритого вихідного коду, отримуючи прибуток безпосередньо від роботи доброзичливих розробників, а також покладаються на них у виправленні помилок, коли виникають проблеми. -Чудовим прикладом є недавній інцидент із критичною вразливістю безпеки в Log4j, пакеті від Apache Software Foundation, який знайшов свій шлях до багатьох комерційних програм і служб, що використовуються підприємствами та урядами. -У листопаді 2021 року дослідник безпеки, який працює в Alibaba Group Holding Ltd., повідомив про вразливість CVE-2021-44228[^1], яка отримала найвищий можливий базовий бал від Apache Software Foundation. -Аміт Йоран, виконавчий директор Tenable і директор-засновник Групи готовності до надзвичайних ситуацій комп’ютерів США (US-CERT), описав цю вразливість як «найбільшу та найбільш критичну вразливість за останнє десятиліття»[^2]. -Почалася паніка, і кілька волонтерів, які обслуговували цей пакет, публічно критикувалися за невдачу. -Після звернення до обурення скромним проханням про справедливість системи були виправлені. -Підприємства та уряди зрештою зрозуміли, що Log4j, пакет, який використовувався багатьма критично важливими системами протягом двох десятиліть, підтримувався кількома неоплачуваними волонтерами, тими самими неоспіваними героями, які почали діяти, незважаючи на зловживання з боку галузі[^3], і працювали не покладаючи рук. щоб усунути вразливість. - -На жаль, Log4j далеко не єдиний приклад. -core-js завантажується 30 мільйонів разів на тиждень як основа кожної програми Node.js, але він також майже не фінансується. -Нещодавно кілька основних розробників біткойнів подали у відставку, посилаючись, серед інших причин, на *відсутність фінансової компенсації* за своє рішення. - -Були численні спроби створення структур заохочення, як правило, із залученням систем спонсорства та винагород. -Спонсорство дає змогу споживачам відкритого програмного забезпечення робити пожертви на проекти, які вони віддають перевагу. -Однак уявіть собі відкритий вихідний код як вежу з цегли, де нижчі рівні давно забуті, але все ще підтримуються відданими інженерами та на які покладається ще більше розробників. -Лише проекти на вершині вежі зазвичай відомі та отримують спонсорську підтримку. -Цей упереджений вибір призводить до того, що основні цеглини, які тримають вежу, не приваблюють пожертвувань, а фаворити отримують більше, ніж їм потрібно. -Баунті дозволяє споживачам проектів пропонувати оплату розробникам за створення певних функцій, таким чином лише винагороджуючи проекти за те, що вони роблять щось не обов’язково в їхніх інтересах. -І знову тільки нагородження фаворитів. - -У цьому документі ми пропонуємо tea — децентралізовану систему для справедливого винагородження розробників з відкритим вихідним кодом на основі їхнього внеску в усю екосистему та введену в дію за допомогою алгоритму заохочення tea, який застосовується до всіх записів у реєстрі tea. - -![Спрощений вигляд системи винагород за замочування чаю.](img/figure-1.svg) - -$\parskip=0pt plus 1pt$ - -[^1]: Джерело: @nist -[^2]: Джерело: @reuters -[^3]: Джерело: @twitter - - -# Компоненти - -Розробнику програмного забезпечення, який створює програму, потрібні чотири речі: браузер, термінал, редактор і менеджер пакетів. -З цих чотирьох менеджер пакунків контролює інструменти та фреймворки, необхідні розробнику для створення свого продукту. -На цьому рівні ми бачимо потенціал для зміни способу оплати праці з відкритим кодом. - -## Менеджер пакетів - -Менеджер пакунків знає, від якого програмного забезпечення з відкритим вихідним кодом залежить функціонування програми, від вершини вежі до її основи. -Кожен компонент і версія, важливі для програми, відомі та записані. -Він знає, що верхівка вежі ретельно відбирає залежні, і що ретельний відбір продовжується вниз. -Менеджер пакетів унікально розміщений у стеку інструментів розробника, щоб забезпечити автоматизований і точний розподіл цінностей на основі фактичного використання в реальному світі. - -Ми пропонуємо незмінний децентралізований реєстр, призначений для розподілу вартості на основі алгоритму, який визначає внесок кожного запису в корисність і працездатність системи. -Значення може входити в графік у вершинних точках — програмах і основних бібліотеках — і рекурсивно розподілятися між залежностями цих вершинних точок і їхніх залежностей, оскільки реєстр знає весь графік із відкритим кодом. - -Крім того, ми вважаємо, що суттєва інформація має бути доступною через менеджер пакетів, щоб розробники могли оцінити, чи можуть вони довіряти пакету та його автору. -Ця інформація може ґрунтуватися на репутації, оцінках спільноти, даних, отриманих із систем децентралізованої ідентифікації (DID[^4]), інших менеджерів пакунків або механізмів заохочення, які потенційно залежать від того, що учасники мережі піддають ризику економічну цінність. - -Ми передбачаємо, що поєднання інструментів, інформації та винагород у Tea справедливо стимулюватиме розробників, допомагаючи стимулювати розвиток програмного забезпечення з відкритим кодом і сприяти інноваціям. - -[^4]: див.: @w3 - -## Децентралізований реєстр - -Кожен менеджер пакунків має власний реєстр пакунків, що повторює ті самі метадані. -Настав час створити єдиний, всеосяжний і остаточний реєстр, розроблений і керований спільнотами, які від нього залежать. -Цей децентралізований незмінний реєстр може забезпечити безпеку, стабільність і запобігти -злий умисел. - -Інтернет працює на десятках тисяч життєво важливих компонентів з відкритим кодом. -Примітно, що досі інциденти, спричинені видаленням важливої інфраструктури з відкритим кодом, були мінімальними. -Найвідомішим було видалення залежності NPM left-pad[^5] у 2016 році, яка каскадно перелилася в системи безперервної інтеграції та безперервного розгортання, що залишило розробників безтурботними на кілька днів. -Ця подія продемонструвала, що сам Інтернет базується на крихких системах розвитку. -Інші приклади включали активну або навмисну участь розробників пакунків, які саботували їхні популярні пакунки (див. colors.js, faker.js[^6] і node-ipc[^7]), -або зловмисники, які прагнуть отримати прибуток, прикидаючись, що допомагають підтримувати пакети та пошкоджують їх, щоб викрасти, наприклад, приватні ключі біткойнів (див. event-stream[^8]), -або шкідливі пакети з навмисними орфографічними помилками, також відомі як typosquatting, -в надії обманом змусити користувачів встановити їх, наприклад crossenv проти cross-env пакетів NPM[^npmjsCrossenv]. - -Необхідно гарантувати цілісність програмного забезпечення, оскільки галузь просувається до майбутнього, де цифрові активи є частиною програмного забезпечення. -Ми не можемо залишатися вразливими для зловмисників, які змінюють програмне забезпечення. - -Більшість інструментів, які ми називаємо менеджерами пакетів, не можуть гарантувати, що ці пакети, вбудовані в програми та dApps, є незмінним відкритим вихідним кодом, опублікованим їхніми оригінальними авторами. -GitHub від Microsoft виявив, що 17% уразливостей у програмному забезпеченні були встановлені зі зловмисними цілями[^9], а деякі залишалися непоміченими протягом тривалого часу (див. Webmin 1.890[^10]). - -Децентралізований реєстр, доповнений системою репутації та підкріплений економічними стимулами, спрямованими на викриття зловмисників і винагороду хороших, може надати гарантії, яких шукали спільноти розробників. - -[^5]: Джерело: @theregister -[^6]: Джерело: @fossa -[^7]: Джерело: @lunasec -[^8]: Джерело: @github -[^npmjsCrossenv]: Джерело: @npmjsCrossenv -[^9]: Джерело: @zdnet -[^10]: Джерело: @threatpost - - -## Система зберігання - -Пакети з відкритим вихідним кодом забезпечують широкий спектр функцій, деякі з яких можуть бути обмеженими або небажаними. -Шифрування є чудовим тому прикладом. -Важливим варіантом використання шифрування є підтримка конфіденційності людей у всьому світі. -Проте шифрування також може використовуватися для підлих цілей (див. Phantom Secure, демонтоване правоохоронними органами в березні 2018 року[^11]) або може бути скомпрометовано для підтримки діяльності правоохоронних органів (див. Операція Ironside (AFP), Operation Greenlight (Європол) ), -і операція «Троянський щит» (ФБР) [^12], де ФБР використовувало «зашифровану» комунікаційну платформу AN0M і переконало злочинців використовувати свої «зашифровані» телефони для безпечного спілкування). - -Широкі можливості застосування шифрування зробили його ідеальним варіантом використання програмного забезпечення з відкритим вихідним кодом і чудовим прикладом того, що будь-яке рішення, яке зберігає пакети, має бути захищеним від підробки та цензури. -tea — це децентралізований протокол, який не передбачає фільтрації чи санкцій щодо пакетів на основі їхньої функціональності. -Хоча керівництво tea може вирішити видалити перевірені шкідливі пакети (додаткову інформацію див. у розділі керування), критично важливо, щоб система tea з’єднувалася з декількома системами зберігання, включаючи децентралізовані, які демонструють, що пакет не змінено та правильно відтворено. -Менеджери пакетів можуть вибрати систему зберігання, яка найкраще відповідає їхнім потребам безпечного зберігання та розповсюдження пакетів. - -[^11]: Джерело: @fbi -[^12]: Джерело: @europol - -# Учасники мережі - -Місія tea полягає в тому, щоб розширити можливості спільнот з відкритим кодом і забезпечити підтримку їхніх співавторів, які створюють інструменти, які створюють Інтернет. -У цьому офіційному документі ми розрізняємо учасників за їх внеском. -Деякі можуть додати код або перевірити наданий код. -Інші можуть мати економічну цінність для підтримки розробників та їхньої репутації. - -## Супроводжувачі пакетів - -Супроводжувачі пакетів повинні переконатися, що їхнє програмне забезпечення продовжує приносити зростаючу цінність у міру розвитку галузі. - -tea припускає, що творці пакунків продовжують свою роботу. -Супроводжувачі пакетів є опорами спільнот із відкритим кодом, які потребують розширення можливостей і винагороди за їхній постійний внесок. -Супроводжуючий пакет може вирішити припинити свої зусилля з обслуговування або зрозуміти, що він не може працювати в темпі, який відповідає очікуванням користувачів пакета. -Супроводжувачі пакетів отримують невзаємозамінний токен (NFT), коли вони завершують надсилання пакета (додаткову інформацію див. у розділі про супроводжуючого NFT). -Цей NFT використовується для підтвердження їхньої роботи та є ключем, який спрямовує винагороди за чай. -Власник NFT пакета може передати його право власності іншому розробнику (або групі розробників), таким чином зробивши їх супроводжувачами пакета та одержувачами будь-яких майбутніх винагород. -Подібним чином розробник може вирішити взяти на себе роль супроводжуючого пакунок, розгалужуючи існуючий пакунок і надсилаючи новий, який він підтримуватиме надалі, таким чином ставши і творцем, і супроводжувачем пакунка. - -Важливо надати спільнотам розробників правильні інструменти, щоб визначити, які пакети обслуговуються, а також репутацію та якість роботи їхніх минулих і нинішніх супроводжувачів. -Ми надто часто спостерігали, як роботу з відкритим вихідним кодом підробляли, а зусилля багатьох руйнували погані гравці. -Хоча роботу цих зловмисників значною мірою виявляють і виправляють, часто це відбувається лише після того, як буде завдано значної шкоди через фінансову втрату чи втрату даних. -Візьмемо, наприклад, пакет EventStream npm [^13], який завантажувався понад 1,5 мільйона разів на тиждень і використовувався понад 1500 пакетами, коли хакеру вдалося проникнути в проект з відкритим кодом, -завоювати довіру оригінального автора та змінити EventStream так, щоб він залежав від шкідливого пакету, який міг би передавати облікові дані біткойн-гаманця на сервер третьої сторони\. -Хоча інструменти можуть допомогти виявити деякі з цих атак, на них не завжди можна покластися, що створює залежність цілої спільноти від старанності та бажання ділитися своїми висновками. - -Ми пропонуємо запровадити заохочення за допомогою токена tea, описаного в розділі токена tea, заохочуючи спільноти з відкритим кодом конструктивно звітувати про свої висновки, щоб супроводжувачі пакунків могли вирішити їх, перш ніж їх використають. - -[^13]: Джерело: @medium - -## Користувачі пакетів - -Користувачі пакетів - це розробники програмного забезпечення, орієнтовані на вирішення конкретної проблеми. -Вони часто шукають у спільноті з відкритим кодом інструменти, необхідні їм для швидкого експериментування та повторного використання за дуже невеликі або безкоштовні витрати, отримуючи пряму вигоду від роботи розробників пакетів і супроводжувачів. -Традиційно підмножина могла підтримувати супроводжуючих пакетів за допомогою пожертвувань або інших форм винагороди; однак це траплялося рідко. - -Спонсорство може бути ефективною системою підтримки розробки з відкритим кодом; однак винагорода зазвичай не поширюється на всіх залежних осіб. -Це обмеження йде на користь фаворитам і заважає інноваціям і розробці програмного забезпечення. -Щоб стати основою розробки програмного забезпечення, відкритий вихідний код повинен надавати можливості всім розробникам, початківцям чи експертам, на всіх рівнях вежі. - -Метою tea є збереження основних цінностей програмного забезпечення з відкритим вихідним кодом, водночас забезпечуючи децентралізовану систему для винагороди супроводжувачів пакетів за їхню роботу. -Щоб виконати цю місію, tea має намір розробити — і заохотити інших до розробки — механізми для користувачів пакетів для підтримки супроводжуючих пакетів за допомогою унікальних випадків використання маркера tea, як описано в розділах про маркер tea та майбутню роботу та потенційні зусилля спільноти. - -## Прихильники та спонсори пакету - -У Web 2.0 і web3 прихильників пакетів часто називають «спонсорами». Це організації або користувачі пакетів, які використовують програмне забезпечення з відкритим кодом для створення своїх комерційних продуктів, філантропи, які прагнуть підтримати екосистему, або підприємці, які хочуть фінансувати команди для розробки компонентів більшої системи. - -tea пропонує поширити спільноти прихильників пакетів на всю спільноту tea, чи то організації, розробники, користувачі чи ентузіасти технологій. -Мета tea полягає в тому, щоб запровадити децентралізовані механізми заохочення через унікальні випадки використання маркера tea для будь-якого члена чайної спільноти, щоб зробити внесок у постійну стабільність і постійне зростання відкритого коду. -Прихильники та спонсори пакетів можуть вирішувати, які пакети чи супроводжувачів пакетів вони хочуть підтримувати, виходячи з їхньої роботи, переконань або будь-яких критеріїв і показників, які можуть вплинути на їх рішення. -Крім того, підтримка, яку надають прихильники та спонсори пакетів, буде надходити до залежностей кожного пакета, таким чином неявно довіряючи супроводжуючому пакету зробити правильний вибір щодо свого стека та використовувати цю інформацію для сприяння своїй репутації. - -За умови, що супроводжуючий пакет пропонує таку послугу, прихильник і спонсор пакету можуть отримати натомість преміальний рівень підтримки NFT, таким чином скориставшись прискореними угодами про рівень обслуговування або більш гнучким ліцензуванням. -Крім того, прихильники та спонсори пакетів можуть вирішити підтримувати пакети або супроводжувачів пакетів і автоматично перенаправляти всі або відсоток своїх винагород, щоб заохотити команди створювати нове програмне забезпечення з відкритим кодом. -Іншими словами, пакети не повинні існувати, щоб чай почав наливатися. -Проекти, що зароджуються, можна підтримувати так само добре, як і більш зрілі, що ще більше стимулює постійно розвивається середовище з відкритим кодом. - -## Дегустатори чаю - -У міру випуску нових пакетів або нових версій існуючих пакетів валідність роботи потрібно підтверджувати. -Ця інформація має вирішальне значення для користувачів пакетів, щоб вирішити, чи довіряти як пакету, так і його супроводжуючим. -У чайному протоколі цю функцію забезпечують дегустатори чаю. - -дегустатори чаю, як правило, є досвідченими розробниками програмного забезпечення, готовими присвятити частину свого часу, щоб перевірити твердження, пов’язані з пакетом (функціональність, безпека, семантичні версії [^14], точність ліцензії тощо) -і ставити як свою репутацію, так і економічну цінність, щоб продемонструвати результати своїх досліджень та аналізу та підтримати свої огляди. -Дегустатори чаю отримують винагороду за свою старанність і старання. -У tea ми називаємо «замочуванням вашого чаю» дію блокування токенів tea для підтримки ваших відгуків і отримання винагород (або штрафів) на основі консенсусу щодо достовірності ваших відгуків. - -Як і прихильники упаковки, дегустатори чаю можуть впливати на упаковку та репутацію супроводжуючої упаковки; однак їхній вплив більш значний, враховуючи їх роль у перевірці безпеки, функціональності та якості пакета. -Дегустаторам чаю також потрібно буде побудувати свою репутацію, щоб підтвердити свої твердження. -Якість їхньої роботи та економічна цінність, яку вони піддають ризику, коли дають свої відгуки, у поєднанні з іншими зовнішніми джерелами даних зміцнять репутацію кожного дегустатора чаю, підвищуючи цінність їхньої роботи. -Перегляньте розділ про репутацію пакета, щоб дізнатися більше про механізми, що використовуються для впливу на репутацію пакета та його супроводжуючого. - -[^14]: див.: @semver - -# Огляд протоколу - -Розробка протоколу винагороди за внески з відкритим кодом пов’язана з проблемами. -Програмне забезпечення з відкритим вихідним кодом за визначенням відкрите для всіх і, як наслідок, може бути піддано неправильному призначенню, привласненню або зловмисному втручанню. -Однак спільнота з відкритим кодом постійно демонструє свою готовність висвітлювати хороших акторів і викривати поганих. -Історично енергія, витрачена на перегляд та коментування внесків інших розробників, була суто добровільною, незважаючи на те, наскільки важливим і трудомістким може бути звітування та захист висновків. - -Ми маємо намір створити надійну платформу розповсюдження програм, забезпечену репутацією та фінансовими стимулами, оскільки вважаємо, що адекватні винагороди за внески з відкритим кодом не можуть бути успішними без системи репутації та можливості для членів спільноти повідомляти про свої висновки та підтримку (або незгода) для пакета або роботи розробника. - -Ми повинні надати розробникам інструменти для доступу до цієї системи репутації та сприяння їй. -Інструменти, які включають простий візуальний і програмований доступ до версії та репутації всіх залежностей у своїх пакетах. -Чітке розуміння того, які учасники спільноти підтримують кожен пакет і скільки токенів tea вони замочують, сприятиме репутації кожного пакета, так само як те, наскільки супроводжуючий пакет замочує свою роботу, говорить про те, наскільки вони стоять за своєю роботою. -Ці об’єднані точки даних допоможуть створити систему репутації для всіх членів спільноти та полегшать вибір. -Оскільки злом пакету EventStream здійснювався не через сам пакет, а через одну з його залежностей, видимість усіх рівнів залежностей буде життєво важливою для створення цієї надійної системи. -Однак такі міркування, як витрати на обчислення та транзакції («газ») повинні мати пріоритет під час проектування та створення системи. - -Наша мета — винагороджувати розробників як Web 2.0, так і web3. -Тонкощі та специфіка кожного стека роблять так, що відстеження встановлення та видалення пакетів може легко стати жертвою одного або кількох зловмисників. -Це включає «купівлю» установок для штучного завищення цифр. -Ще гіршим сценарієм було б внесення фундаментальних змін у природу програмного забезпечення з відкритим вихідним кодом шляхом створення непотрібного тертя з ліцензійними ключами чи іншими механізмами відстеження розгортання. -Щоб забезпечити найширше охоплення, ми вважаємо, що винагорода не повинна спиратися на спрощену ідею відстеження встановлень або видалень, а радше на механізми заохочення, які заохочують надсилати якісні пакети та повідомляти про шкідливі або високоризикові пакети. -Нарешті, багато пакунків покладаються на загальні залежності. -Наприклад, у Lodash 151 209 утриманців[^15], тоді як у chalk 78 854 утриманці[^16] або у Log4js 3343 утриманці[^17]. -Оскільки все більше пакетів створюється з використанням одних і тих самих залежностей, як ми гарантуємо, що стимули розподіляються чесно та справедливо? -Як ми гарантуємо, що найбільш використовувані залежності будуть винагороджені без втрати нових або нових пакетів і розробників? -Як ми гарантуємо, що система заохочення не призведе до того, що розробники відійдуть від нішевих мов і зосередять їх там, де заохочення кращі? -Але також, як розробники, як ми визначаємо пакунки з найбільшою кількістю залежних, щоб створювати альтернативи – простіші, ефективніші, краще закодовані версії цих пакунків? -У tea ми вважаємо, що відсутність стимулів завадила розвитку програмного забезпечення з відкритим кодом. -За підтримки належних економічних стимулів і винагород більше розробників зможуть створювати, покращувати та доповнювати програмне забезпечення з відкритим кодом для кращого світу. -Лише тоді чайний токен зможе представляти загальну вартість програмного забезпечення з відкритим кодом. - -[^15]: Джерело: @npmjsLodash -[^16]: Джерело: @npmjsChalk -[^17]: Джерело: @npmjsLogFourjs - -## Подання пакета - -Подання випуску пакета вимагає, щоб кілька транзакцій відбувалися атомарно. -Зокрема, супроводжуючий пакет повинен: - -* Зареєструйте пакет (і його семантичну версію) у децентралізованому реєстрі. -* Завантажте пакет у децентралізовану систему зберігання для стійкості, стійкості до цензури та простоти розповсюдження. -* Зробіть внесок у репутацію та надійність пакета, *замочуючи* токенів tea. - -Невдача будь-якої з трьох операцій призведе до повернення протоколу до попереднього стану, таким чином усуваючи будь-які докази подання. - -Коли пакет буде успішно подано, супроводжуючий пакет отримає NFT супроводжуючого, щоб підтвердити свою роботу та внесок у відкритий код. -Супроводжуючий пакет може передати винагороди за занурення, пов’язані з NFT супроводжуючого, третій стороні. -Однак репутація, пов’язана зі створенням і підтримкою активу, залишиться у супроводжуючого пакета, тому з часом на його репутацію може вплинути. -Коли репутація будь-якого члена чайної спільноти досягає ключових віх, їм може бути надано доступ до підвищених частин протоколу або прискорена винагорода за рішенням керівництва чаєм. -Для отримання додаткової інформації про супроводжувальний NFT дивіться розділ супроводжуючого NFT. - -### Аналіз залежностей - -Залежності пакетів можуть бути глибокими, оскільки кожен пакет часто має як залежних, так і залежних. -Щоб забезпечити просту методологію, яка винагороджує всіх розробників, які зробили внесок у програмне забезпечення з відкритим вихідним кодом, зберігаючи при цьому створення дерева залежностей швидким і ефективним з точки зору обчислень, ми пропонуємо перевіряти лише залежності першого рівня після надсилання пакета. - -Цей дизайн ґрунтується на гіпотезі, згідно з якою кожна залежність сама по собі є пакетом, який було незалежно передано чайному дереву. -При цьому кожна з його залежностей може бути зіставлена, і якщо її залежності самі мають залежності, вони будуть зіставлені під час подання пакета залежностей. - -![Діаграма аналізу залежностей.](img/figure-3.svg){#fig:dep-analysis} - - -У @fig:dep-analysis подання пакета A запускає аналіз залежностей середовища виконання 1–n і залежностей збірки 1–n, тоді як залежності середовища виконання 1.1–1.n і залежності збірки 1.1–1.n аналізувалися під час пакета B було подано. -Ми застосуємо ту саму методологію для розподілу заохочень, оскільки заглиблені токени розподіляються між усіма залежностями, таким чином рекурсивно занурюючи пакети, перелічені як залежності (див. @fig:steeping-rewards). - -![Розподіл винагород Steeping між залежностями.](img/figure-2.svg){#fig:steeping-rewards} - - -Керування версіями та конфліктні залежності є серйозними проблемами, і їх усунення може призвести до великих витрат часу. -Щоб вирішити цю проблему, ми пропонуємо піддавати кожен пакет комплексному скануванню залежностей після надсилання, щоб ми могли переконатися, що пакет відповідає наведеним нижче правилам для діапазонів семантичних версій. - -* Пакети можуть обмежувати свої залежності лише основною версією, хоча початком діапазону може бути будь-яка дійсна семантична версія (наприклад, >=5.2.1 <6). -* Якщо залежність оновлюється до новішої основної версії, може знадобитися збільшити основну версію пакета. -* Подібним чином, якщо залежність оновлено до новішої проміжної версії, для tea може знадобитися збільшити проміжну версію пакета. -* Якщо додається нова залежність, для tea може знадобитися збільшити проміжну версію пакета. - -Враховуючи непотрібні зусилля, які докладають будь-якому користувачеві пакету, коли порушуються вищезазначені правила, ми пропонуємо скоротити частину маркера чаю, зануреного супроводжуючим пакетом, щоб відобразити їхню відсутність належної обачності. -Якщо розробник змушує всіх жонглювати чашками, хтось проллє чай. -Оскільки очікується, що сканування залежностей відбудеться під час подання, ми маємо зауважити, що жодного замочування від прихильників і спонсорів пакету чи дегустаторів чаю не відбудеться. - -## Пакунок і репутація супроводжуючого пакета - -Супроводжувачі пакетів повинні сприяти репутації та надійності свого пакета шляхом замочування токенів tea. -Однак система репутації, яка покладається виключно на економічний внесок автора, не забезпечує достатнього захисту користувачів і може піддаватися атакам Sybil, коли одна особа створює кілька репрезентацій себе, щоб залишити велику кількість позитивних відгуків про свою роботу, -змусити користувачів повірити, що їх роботу перевірено та схвалено багатьма. - -Існує кілька методологій для запобігання атакам Сибіл, деякі з яких описані Нітішем Балачандраном і Сугатою Саньялом в «Огляді методів пом’якшення атак Сибіл»[^18]. -Оскільки tea є децентралізованим протоколом, використання довірчої системи сертифікації, яка покладається на централізований орган видачі сертифікатів, суперечило б її суті. -Ми пропонуємо зосередитися на децентралізованих підходах до пом’якшення атак Sybil і, точніше, на методологіях, які покладаються на велику групу учасників мережі, стимульованих оцінювати та публічно представляти репутацію кожного пакета та його супроводжуючого. - -Подібно до виробництва блоків у блокчейні з підтвердженням частки, де вузли, що не виробляють, можуть перевіряти роботу інших і, якщо необхідно, висвітлювати порушення правил мережі, що призводить до покарання поганого актора шляхом рубання (знищення частини їхньої частки), -ми пропонуємо систему, за допомогою якої треті сторони (так звані дегустатори чаю) зможуть переглядати пакети, створені супроводжуючими пакунками, і отримувати економічні стимули діяти в інтересах спільноти програмного забезпечення з відкритим кодом та його користувачів, а також визнавати належну поведінку та карати погану поведінку. -Ця система має бути одночасно стійкою до Sybil і запобігати суттєвому впливу великих власників токенів на протокол або репутацію певних пакетів. -Ми вважаємо, що цей підхід більше узгоджується з відкритим вихідним кодом, забезпечуючи більш плідний субстрат для сприяння прийняттю та довірі та, зрештою, сприяючи зростанню чаю. - -[^18]: Джерело: @arxiv - -## Перевірка пакета третіми сторонами - -Перевірка пакетів третіми сторонами є важливою складовою створення репутації, однак стороння перевірка має власний набір унікальних загроз, включаючи згадані вище атаки Sybil. - -Технологія блокчейн, а точніше стейкинг, пропонує компанії Tea унікальну можливість подолати цю проблему. -Хоча адреси гаманців можуть бути доступні в нескінченній кількості, це не стосується токенів tea, початкова пропозиція яких, як очікується, становитиме 10 мільярдів. -Крім того, кожна дія, яку виконують розробники, як-от надсилання пакетів, перевірка пакетів або їх замочування, сприятиме їхній репутації, таким чином створюючи унікальний профіль, який кожен розробник може використовувати, щоб зробити внесок у чайну спільноту та брати участь в управлінні чаєм. - -Вимагаючи від сторонніх рецензентів замочувати чайні токени та ризикуючи втратою частини своїх замочених токенів, якщо виявиться, що вони поводяться проти інтересів мережі або погано діють, треті сторони можуть надати додаткову довіру пакету та отримати винагороду у вигляді чайних токенів. - -Ми також пропонуємо поширити систему репутації на третіх осіб, які здійснюють незалежну перевірку упаковок – дегустаторів чаю. -Завершення позитивного перегляду вимагатиме двох атомарних операцій: - -* Подання огляду коду, підписане дегустатором чаю та загальнодоступне для всіх членів спільноти разом із -* Акт замочування «за» пакет (проти «проти» пакета), щоб обґрунтувати їх огляд. - -Завершення негативної рецензії, яка містить одну або кілька критичних вразливостей, вимагатиме від дегустаторів чаю зв’язатися з розробником пакунків за допомогою протоколу обміну повідомленнями, щоб повідомити їх про вразливість і дозволити їм своєчасно вирішити проблему. -Після закінчення визначеного керуванням періоду, призначеного супроводжувачу пакета для усунення вразливості, або коли виправлений пакет стане доступним, той самий протокол обміну повідомленнями буде використано для сповіщення всіх користувачів і тестувальників цього пакета (включно з утриманцями) про виявлення вразливості. ідентифікований, -і, сподіваємось, розглянуто, щоб вони знали, що потрібно оновити свою програму або залежності. -Щоб перешкодити витрачати час розробників, комунікація між дегустаторами чаю та супроводжувачами упаковки вимагатиме від дегустаторів чаю замочувати чайні токени. - -Після завершення обох операцій дегустатори чаю отримають NFT як доказ їхньої роботи над певною упаковкою та версією упаковки. -Накопичення NFT у поєднанні з коефіцієнтом замочування кожного з розглянутих пакетів та інформацією, отриманою із зовнішніх систем, сприятиме репутації дегустатора чаю. -Коли їхня репутація досягає ключових віх, дегустатори чаю можуть отримати доступ до підвищених частин протоколу або прискорених винагород за рішенням керівництва чаю. - -## Застарілі або пошкоджені пакети - -Місія tea полягає в тому, щоб винагороджувати учасників та учасників спільнот з відкритим кодом; однак винагорода має відповідати зусиллям, які докладають спеціалісти з обслуговування пакетів і дегустатори чаю. -Недостатньо підтримувані, застарілі або пошкоджені пакунки є явними ознаками того, що супроводжувачі пакетів не виправдовують очікувань спільноти або не забезпечують довіри та підтримки, викликаної ними через занурення пакетів. -Іншим проявом застарілих пакетів може бути продовження використання застарілої мови або застарілої версії багатоверсійних мов. -Упаковки, які надто довго залишаються застарілими або пошкодженими, вказують на те, що дегустаторам чаю необхідно регулярно й послідовно переглядати роботу супроводжувачів упаковки. - -Дегустатори чаю є критично важливими членами спільнот з відкритим кодом, оскільки їхні відгуки та пов’язані з ними претензії можуть спрямовувати користувачів пакетів до або від них. -Щоб переконатися, що оглядам можна довіряти на постійній основі, ми пропонуємо механізм, за допомогою якого застарілі або пошкоджені упаковки можуть бачити частину своїх намочених маркерів, надісланих дегустаторам чаю, які першими помітили відсутність обслуговування будь-якої упаковки. - -Будь-яку негативну рецензію, яка окреслює недолік, такий як уразливість нульового дня або використання застарілої залежності, і залишається відкритою після закінчення пільгового періоду, визначеного керівництвом, слід вважати помилкою з боку розробника пакета. -Вони не виконали завдання, яке їм доручили і за яке нагородили. -Те саме можна сказати про прихильників і спонсорів пакетів, які поклали свою репутацію на роботу неналежних супроводжувачів пакетів і отримали за це винагороду, але не змогли виявити відсутність підтримки або вирішили продовжувати підтримувати пакет, незважаючи на це. - -У міру того, як пакунки набувають популярності та використання, з’являється все більше додатків і потенційно критично важливих систем, які залежать від них, ми повинні заохочувати розробників непомітно повідомляти про недоліки розробникам пакетів, а розробникам пакетів – усунути такі недоліки, перш ніж їх можна буде використати. -Отже, ми пропонуємо, щоб будь-який застарілий або пошкоджений пакет, який підлягає одному або більше підтверджено негативним відгукам і залишається в такому стані після закінчення визначеного керівництвом пільгового періоду, мав скоротити частину його наповнених токенів, незалежно від їх походження (супроводжувач пакета, пакет прихильники та спонсори або попередні дегустатори чаю), -інша частина відправляється дегустаторам чаю, які залишили негативні відгуки. -Розподіл серед усіх дегустаторів чаю може ґрунтуватися на віці їх перегляду та кількості токенів tea, які вони замочували для свого огляду. - -## Супроводжувач NFT - -Після успішного надсилання пакета супроводжуючий пакет отримає NFT на підтвердження своєї роботи та внеску. -Власник цього NFT автоматично отримає всі винагороди, пов’язані з пакетом. -Супроводжувачі пакетів можуть передати право власності на обслуговування пакета іншому супроводжувачу, просто передавши NFT пакета. -Успішна передача NFT призведе до того, що новий власник автоматично отримає майбутні пакетні винагороди. - -Важлива частина створення репутації залежить від частоти та кількості якісних пакетів. -NFT, наданий супроводжувачам пакетів як доказ їхньої роботи, може використовуватися системою репутації для оновлення репутації супроводжуючого пакунків і надання їм доступу до підвищених частин протоколу за рішенням керівництва чаю. -Однак, щоб запобігти векторам атак, таким як купівля членами спільноти їхньої репутації, передача супроводжуючого NFT не призведе до передачі репутації. -Репутація має залишатися безпосередньо пов’язаною з конкретною роботою розробника та не підлягає передачі. - -# Токен чаю - -## Захист мережі - -Незважаючи на те, що багато блокчейнів можуть виглядати як ефективні та безпечні інфраструктурні рішення для підтримки цілей Tea, ми вважаємо, що слід уважно розглянути стек технологій, на якому побудована система Tea. - -Масштабованість, економічна ефективність, ESG і розширюваність сторонніми розробниками є важливими аспектами дизайну, яким краще могла б служити теа-суверенна система підтвердження частки. -У proof-of-stake оператори вузлів і учасники мережі роблять ставку на економічну цінність у формі рідного токена ланцюжка для підвищення безпеки системи. -Оператори вузлів і учасники мережі отримують винагороду за успішне виробництво блоків, які відповідають правилам мережі та містять точну інформацію про транзакції. -Бездіяльність (так відома як node down) або зловмисна/некоректна активність караються знищенням частини поставлених токенів за допомогою слеша. - -Система proof-of-stake на базі токена tea дозволить власникам токена tea робити внесок у безпеку системи, *ставляючи* чай, і підтримувати розробників з відкритим кодом, *замочуючи* чай. -Ми повністю усвідомлюємо, що економічні фактори можуть заважати деяким розробникам стейкити чи замочувати чай; таким чином, стейкинг і замочування будуть доступні всього за аркуш, найменший номінал чаю являє собою одну стомільйонну ($10^{-8}$) чаю. - -Обидва застосування токена tea виконують життєво важливі функції в підтримці та розвитку екосистеми з відкритим кодом. -Staking tea забезпечить безперебійну безпечну роботу чайної системи, тому всі учасники мережі зможуть надсилати та отримувати доступ до пакетів, щоб переглядати їх, інтегрувати у свою програму тощо. -Навпаки, замочування чаю підтримуватиме мету tea щодо надання всім учасникам мережі інструментів для підтримки та використання пакетів, які відповідають вимогам якості та надійності, сформульованим чайною спільнотою через їх підтримку та незгоду з кожним пакетом. -Визначаючи та впроваджуючи параметри розбивки та замочування, необхідно дотримуватися обережності, щоб один не став паразитом на іншому. - -## Заохочення та покарання - -Як обговорювалося раніше, для зловмисників можуть існувати сильні стимули скомпрометувати програмне забезпечення з відкритим кодом. -Більшість критичної інфраструктури Інтернету працює з відкритим вихідним кодом, і гонка за пошуком експлойтів та інших вразливостей триває. -У tea ми вважаємо, що слід звинувачувати не супроводжуючих пакетів (хоча вони часто є). - -Стимули чайного протоколу виправляють це через справедливий і справедливий розподіл стимулів. -Такий пакет, як Lodash із понад 151 тис. утриманцями, є основою розробки з відкритим вихідним кодом, і його супроводжувач заслуговує на пропорційну винагороду. -Однак система винагороди, побудована виключно на кількості утриманців, не дасть новаторам зруйнувати ці монополії, якщо тільки вони не мають достатнього фінансування третіми сторонами або вже накопичили достатньо ресурсів для самостійного фінансування. -Такий підхід, швидше за все, призведе до зменшення кількості учасників, що призведе до полярної протилежності до того, що стосується чаю. - -Мета tea полягає в тому, щоб представити цінність програмного забезпечення з відкритим вихідним кодом і, роблячи це, сприяти його розвитку, надаючи учасникам ресурси, необхідні для того, щоб вільно займатися своєю пристрастю. -Система стимулювання розподілу чаю повинна ретельно враховувати коефіцієнт замочування кожної упаковки та відповідним чином коригувати стимули для кожної упаковки. -Щоб зменшити ризик того, що невелика кількість пакетів, які використовуються як залежні від багатьох програм, отримують більшість високих винагород, ми використаємо дослідження, проведене web3 Foundation[^19] для механізму винагород Polkadot на основі підтвердження частки. -Ми можемо додатково налаштувати реалізацію та її змінні на основі результатів практичних експериментів. - -Коли крутий пакет наближається до оптимального коефіцієнта замочування, визначеного керівництвом, його коефіцієнт винагороди за замочування поступово зменшуватиметься. -Коли упаковка перевищує оптимальний коефіцієнт замочування, коефіцієнт винагороди за замочування різко зменшується, щоб позбавити прихильників упаковки та дегустаторів чаю від подальшого замочування сильно замочених упаковок. -Ця конструкція може дозволити упаковці з меншим замочуванням стати більш привабливою як для прихильників упаковки, так і для дегустаторів чаю. -Це також може стимулювати досвідчених розробників створювати альтернативи пакетам із високим ступенем навантаження, створюючи можливість для чайної спільноти збалансувати підтримку існуючого програмного забезпечення та просування інновацій. -Коефіцієнт замочування буде розраховано з використанням циркуляційного джерела в його початковій конструкції. -Чайне співтовариство може змінити цей дизайн, щоб ще більше покращити масштабованість системи. -Нехай $\chi$ буде коефіцієнтом замочування для всіх пакетів. -Він являє собою загальну кількість токенів tea, наповнених супроводжуючими пакетами, користувачами пакетів, прихильниками та спонсорами пакетів, а також дегустаторами чаю, поділену на загальну кількість токенів tea. -Враховуючи, скільки пакетів із відкритим вихідним кодом доступно сьогодні та їхнє очікуване зростання, $\chi$ завжди буде дуже малим значенням від $0$ до $1$. - -Нехай $\psi$ буде коефіцієнтом ставки. -Він представляє загальну кількість токенів tea, поставлених будь-яким учасником мережі для захисту мережі. - -Нехай $\chi_{ideal}$ буде коефіцієнтом занурення, якого ми хочемо досягти для кожного пакета для справедливого розподілу винагород між усіма пакетами та їх залежностями. -Значення $\chi_{ideal}$ потрібно оновлювати, коли нові пакети додаються до децентралізованого реєстру та створюються залежності. -Щоб визначити найкраще значення для $\chi_{ideal}$, ми будемо використовувати криву популярності, оновлену на початку кожного циклу винагороди. - -Нехай $\tau = \tau(\chi)$ буде річною відсотковою ставкою, розподіленою між усіма членами чайної спільноти, які займаються токенами чаю для підтримки розробників з відкритим кодом. -Іншими словами, $\tau(\chi)$ відповідає винагороді за замочування, яку отримує протягом року учасник спільноти, який замочує токени чаю за весь рік. - -Нехай $\gamma = \gamma(\psi)$ буде річною відсотковою ставкою, розподіленою між усіма операторами вузлів і учасниками мережі, які роблять ставку на чайні токени для захисту мережі. -Іншими словами, $\gamma(\psi)$ відповідає винагороді за ставку, отриману протягом року учасником спільноти, який ставить токени чаю за весь рік. - -Нехай $\delta$ буде річною інфляцією, спрямованою на скарбницю мережі. -$\delta$ може змінюватися, оскільки зовнішні фактори впливають на пропозицію токенів. - -Ми розглядаємо річну ставку винагороди за просування як функцію $\chi$ і річну ставку винагороди за ставку як функцію $\psi$. - -* $\tau(\chi)$ відповідає стимулу для людей накачувати пакет. -Зі збільшенням $\chi$ потрібно менше винагород $\tau(\chi)$. -* $\gamma(\psi)$ відповідає стимулу для людей робити ставки в мережі. -Зі збільшенням $\psi$ для захисту мережі потрібно менше винагород $\gamma(\psi)$. - -Річна інфляція $I$ буде еквівалентна $(\tau + \gamma + \delta)$ і розраховуватиметься таким чином: - -$$ -I = \frac{\textrm{пропозиція токенів на кінець року} - \textrm{пропозиція токенів на початок року}}{\textrm{пропозиція токенів на початок року}} = (\tau + \gamma + \delta) -$$ - -Слід зважити внесок в інфляцію $\tau_{\textsc{all}}$ (стимул, розподілений між усіма учасниками пакетів) і $\gamma_{\textsc{all}}$ (стимул, розподілений між усіма учасниками безпеки мережі) щоб переконатися, що система стимулює оптимальне співвідношення замочування/розбивки. - -Оскільки ми зосереджуємось на заохоченнях, розподілених між усіма пакетами, ми визначаємо це -$\tau_{\textsc{all}}$ -є функцією коефіцієнта замочування $\chi$ і тому -$\tau_{\textsc{all}}(\chi) = \chi \cdot \tau(\chi)$. -З нашого попереднього аналізу ми це бачимо -$\tau_{\textsc{all}}(\chi_{ideal}) = \chi_{ideal} \cdot \tau_{ideal}$. -Оскільки мета — досягти стану, де -$\chi = \chi_{ideal}$ -, винагороди -$\tau_{ideal}(\chi)$ -має бути максимальним при цьому значенні. - -Нехай $\tau_{ideal} = \tau(\chi_{ideal})$ -бути ставкою винагороди, яку надає мережа за ідеального сценарію -$\chi = \chi_{ideal}$. - -Нехай $\tau_{0}$ — це межа $\tau_{\textsc{all}}(\chi)$, оскільки $\chi$ дорівнює нулю, коли жоден член спільноти чаю не наповнює пакетів. -Значення $\tau_{0}$ має бути близьким до нуля, але не дорівнювати нулю, щоб стимулювати перших користувачів. -Згідно з дослідженнями фонду web3, ми пропонуємо: - -* функція інфляції зростає лінійно між $\chi = 0$ і $\chi = \chi_{ideal}$, і -* він розпадається експоненціально між $\chi = \chi_{ideal}$ і $\chi = 1$. - -Ми вибрали подібне експоненціальне зменшення для $\tau_{\textsc{all}}(\chi)$, оскільки воно передбачає експоненціальне зменшення $\tau(\chi)$, і ми хочемо, щоб винагорода різко впала за $\chi_{ ideal}$, щоб запобігти отриманню всіх винагород одним пакетом. - -Розпад визначається таким чином, що рівень інфляції зменшується щонайбільше на 50%, коли $\chi$ зміщує $d$ одиниць праворуч від $\chi_{ideal}$ – тобто -$\tau_{\textsc{all}}(\chi_{ideal} + d) \geq \tau_{\textsc{all}} \cdot 0.5$. - -Ми пропонуємо наступні функції процентної ставки та рівня інфляції, які залежать від параметрів $\chi_{ideal}$, $\tau_{ideal}$, $\tau_{0}$ і $d$. - -\begin{align*} -&\tau_{\textsc{all}}(\chi) = \tau_{0} + (\tau_{\textsc{all}}(\chi_{ideal}) - \tau_{0})\frac{\chi}{\chi_{ideal}}\enspace\textrm{for}\;0 < \chi \leq \chi_{ideal} \\ -&\tau_{\textsc{all}}(\chi) = \tau_{0} + (\tau_{\textsc{all}}(\chi_{ideal}) - \tau_{0}) \cdot 2^{(\chi_{ideal}-\chi)/d}\enspace\textrm{for}\;\chi_{ideal} < \chi \leq 1 -\end{align*} - -Так само, як хороші актори потребують винагороди; поганих діячів потрібно виявити та покарати. -Програмне забезпечення з відкритим вихідним кодом надає багато можливостей для зловмисників створювати болючі точки та репутаційні ризики для всієї спільноти розробників. -Від незаконного привласнення роботи до зміни та перерозподілу пакетів програмного забезпечення чи впровадження негідного коду, війна між хорошими та поганими акторами триває, часто з добре фінансованими поганими акторами, які бачать у забрудненні пакетів з відкритим кодом можливість отримати фінансову вигоду. -Недоліки були відносно мінімальними: пакети потенційно були заборонені на цифрових полицях або мали погану репутацію. - -Ми пропонуємо запровадити механізм скорочення, щоб визначити більш суттєвий недолік, який безпосередньо впливає на економічну вартість поганих учасників. -Оскільки дегустатори чаю оцінюють і аналізують код у щойно надісланих упаковках, ми пропонуємо їм отримати інструменти та стимули для точного виявлення та висвітлення негідного коду, щоб користувачі упаковки могли бути обізнані про ризики, а супроводжувачі упаковки, прихильники упаковки та спонсори були покарані. за надсилання або підтримку шкідливого коду. -Таким чином, за всі підтверджені негативні відгуки, виконані згідно з правилами мережі та які були розглянуті супроводжуючим пакетом протягом визначеного управлінням періоду, супроводжуючий пакет не повинен нести жодного покарання всупереч прихильникам пакета та спонсорам або дегустаторам чаю, які надав позитивний відгук про відповідний пакет. -Для негативних відгуків, виконаних відповідно до правил мережі, і які супроводжуючий пакет не розглянув протягом визначеного управлінням періоду, частка токенів, занурених супровідним пакетом, прихильниками пакету та спонсорами, а також попередніми дегустаторами чаю, буде скорочена. -Інша частина буде заблокована в страховому пулі, який контролюється урядом чаю. -Керівництво чаю встановлює політику та правила в тісній співпраці з громадою, щоб розповсюджувати вміст пулу тим, хто постраждав від уразливості. -Протокол розподілятиме третю частку намочених токенів між усіма дегустаторами чаю, які внесли свій внесок у негативний відгук і намочили на упаковці, залежно від кількості токенів tea, які вони намочили «проти» пачки, і того, як довго їхні токени настоювалися. -Іншими словами, чим швидше один або кілька дегустаторів чаю виявлять і повідомлять про недолік відповідно до правил мережі, тим вищу винагороду вони отримають за підтримку безпечної та продуктивної розробки з відкритим кодом. - -Щоб запобігти випадковому голосуванню членів спільноти «проти» сильно намочених пакетів, сподіваючись отримати більшість будь-якого штрафу, усі токенів tea, намочені «проти», не будуть винагороджені інфляцією та можуть бути піддані механізму розпаду, таким чином зменшуючи їхню цінність з часом. . - -[^19]: Джерело: @web3 - - -# Управління - -Управління має вирішальне значення для розробки, стійкості та впровадження будь-якої розподіленої системи. - -Ми пропонуємо, щоб чай включав управління в ланцюжку, де всі власники токенів tea можуть пропонувати та голосувати за зміни критичних параметрів, зважених за володінням токеном і репутацією. -Ці параметри можуть включати інфляцію, комісії за транзакції, винагороди за ставки, винагороди за замочування або оптимальний коефіцієнт замочування. -Ця функція гарантує, що критичні параметри можуть розвиватися та оптимізуватись з часом членами чайної спільноти. -Ми очікуємо, що управління розпочнеться з простою структурою та поступово розширюватиметься в міру розвитку чайної системи, полегшуючи впровадження та забезпечуючи поступову децентралізацію. - -Деякі системні параметри можуть не підлягати керуванню або підтримувати високочастотні зміни, щоб зменшити поверхню атаки, яку представляє керування. -Поступовий перехід параметрів до відкритого, децентралізованого управління забезпечить стабільність і передбачуваність системи. - - -# Розширюваність сторонніх розробників - -Поки ми створюємо початкові інструменти, щоб залучити довготривалу підтримку спільнот із відкритим кодом, ми вважаємо, що частиною нашої місії є забезпечення того, щоб треті сторони могли розширити загальний набір інструментів. -Окрім надання розробникам інфраструктури для створення розширень протоколу, включно з новими способами впровадження інновацій та подальшої підтримки розробників із відкритим кодом, наші плани включають потенціал для інших менеджерів пакунків, щоб зробити свій внесок у протокол. -Мрії та зусилля розробників з відкритим кодом створили інновацію, яка підтримує наше повсякденне життя. -Ми з нетерпінням чекаємо нових способів використання та розширення чаю, запропонованих чайною спільнотою. - - -# Майбутня робота та потенційні зусилля спільноти - -У міру розвитку чайної системи ми передбачаємо, що спільнота вирішуватиме та сприятиме змінам і розширенням чайної системи через управління. -Нижче наведено кілька ідей, які, на нашу думку, можуть когось надихнути. - -## Оптові торговці чаєм - -Спільноти програмного забезпечення з відкритим кодом живуть і постійно прагнуть впроваджувати інновації та приносити користь. -Ця відданість і альтруїзм призводять до постійного створення нового програмного забезпечення та пакетів, кожен з яких тягне за собою залежності. -Як наслідок, ми очікуємо, що карта залежностей буде постійно розвиватися, що призведе до частих змін у коефіцієнті занурення та винагородах. -У майбутньому чайна спільнота може запропонувати розробку системи, призначеної для динамічного моніторингу коефіцієнта замочування для кожної упаковки та зміни балансу того, як прихильники упаковки замочують свої токени на основі власних критеріїв. - -## Роялті за передачу пакету - -Ми розуміємо, що супроводжувачі пакетів можуть вирішити передати свій потік винагород одному або кільком розробникам. -Управління такою передачею має залишатися рішенням супроводжуючого пакета та їхніх партнерів, без втручання з боку чаю. -Необхідно надати інструменти, щоб така передача була повною або частковою (можливо, шляхом перенаправлення лише частини винагороди за занурення одному чи кільком розробникам, тоді як решта винагород продовжує надходити до оригінального супроводжуючого пакета) -а також для надходження великих винагород через один обліковий запис, який контролюється одним учасником мережі, кількома учасниками мережі або автоматично розподіляється між кількома обліковими записами за допомогою статичних чи динамічних коефіцієнтів. - -## Розподіл винагород серед кількох супроводжуючих - -Обслуговування пакету може покладатися на роботу ще однієї команди розробників. -Перш ніж почнуть надходити винагороди за насичення, командам слід подумати про автоматизацію розподілу винагород за насичення між собою. -Спосіб розподілу має бути вирішений самими супроводжувачами, оскільки вони мають найкраще становище для оцінки того, хто зробив внесок і як вони мають бути винагороджені. - -Щоб досягти цього, кожна команда (або команди) може створити власну децентралізовану автономну організацію (DAO) і або автоматизувати розподіл винагород, або розгорнути більш складні системи для визначення адекватного розподілу винагород на основі зовнішніх факторів, таких як голосування всіх DAO. члени, -або часові розподіли на основі постійного внеску, успішного завершення винагород тощо. - -## Транспортний пакет «Вилки» - -Ми вважаємо, що форки є важливими і в основному недостатньо використовуються. -Форки можуть бути ефективним інструментом для розробки пакетів, які змагаються за функціональністю, продуктивністю, безпекою та навіть увагою. -Якими б корисними вони не були, форки повинні розпізнавати вихідні зусилля. -Завдяки майбутнім роботам або потенційним внескам, чайна спільнота може покращити систему, щоб вимагати декларування виделок, можливо, навіть виявлення під час подання пакунка. -Незаявлені вилки, виявлені дегустаторами чаю, можуть призвести до того, що частина намочених токенів буде розрізана, передана оригінальному супроводжувачу упаковки та надіслана дегустаторам чаю, які виявили вилку. - -## Залежності між виконанням і збіркою - -tea може не відрізняти залежності збірки від залежностей виконання під час розподілу високих винагород під час запуску. -Проте, за умови, що чайна спільнота налаштована на таке розмежування, чайна спільнота може запропонувати вдосконалення алгоритму розподілу нагород, щоб врахувати критичність кожної залежності та її внесок у вартість пакетів, які від них залежать. -Ці пропозиції будуть проголосовані та реалізовані на основі рішення громади. - -## Винагорода на основі використання - -Оскільки все більше додатків створюється з використанням пакетів, зареєстрованих у tea, спільнота може розширити алгоритм винагороди, щоб розподіл міг залежати від зовнішніх сертифікованих наборів даних, таких як використання. -Це оновлення механізму винагороди може дозволити більший розподіл винагород токенів tea для пакетів із найбільшим використанням, дотримуючись при цьому обмежень коефіцієнта замочування, описаних у розділі токенів tea. -Супроводжувачі пакетів можуть використовувати подібний підхід, щоб розподілити значну винагороду між своїми залежностями на основі прозорої логіки за своїм вибором. -Зауважте, що вся інформація, яка використовується для впливу на розподіл винагород між пакетами та залежностями в чайній системі, має бути надійною. - - -# Подяки - -Ця біла книга не існувала б без підтримки та відданості багатьох чайофілів. -Автори хотіли б подякувати Джошу Крюгеру, Джадіду Хану та Джейкобу Хайдеру за їхній внесок у токеноміку, а також багатьом обачним особам, які добровільно приділили свій час, щоб надати відгуки про зміст цього документа. - -$\parskip=0pt плюс 1pt$ - -# Глосарій термінів - -| Термін | Визначення | -|------|------------| -| Листок | Найменший номінал токен tea. Листочок відповідає одній стомільйонній ($10^{-8}$) чаю. | -| Рубання | Дія покарання стіперів або стейкерів у відповідь на поведінку, що суперечить правилам мережі. | -| Ставка | Дія блокування чайних токенів для захисту мережі підтвердження частки, на якій побудована чайна система. | -| Замочування | Дія блокування токенів tea для підтвердження вашої претензії та отримання винагород (або штрафів) на основі консенсусу щодо дійсності вашої претензії. | - - -# Список літератури diff --git a/i18n/zh/white-paper.md b/i18n/zh/white-paper.md deleted file mode 100644 index 4946cbd..0000000 --- a/i18n/zh/white-paper.md +++ /dev/null @@ -1,509 +0,0 @@ -# 免责声明 - -本白皮书中列出的信息具有初步性质。 -因此，作者或他们各自的任何附属机构均不对此处列出的信息是最终的或正确的信息承担任何责任，并且在适用法律允许的最大范围内，上述每一项均不承担任何和所有责任，无论是由侵权引起的、合同或其他与本白皮书有关的内容。本白皮书或其中包含的任何内容均不得构成任何合同或承诺的基础或与之相关的依赖或作为订立任何合同或承诺的诱因。 - -本白皮书中的任何内容均不构成出售或招揽购买此处讨论的任何代币的要约。在任何情况下，如果本白皮书被视为此类要约或招揽，则本白皮书无意或传达此类要约或招揽在任何非法的司法管辖区。 -因此，如果此类要约或招揽需要许可或注册，或者此类要约或招揽受到限制。特别是，本文讨论的任何尚未发布的代币，并且截至本白皮书发布之日，不打算根据任何司法管辖区的证券或类似法律进行注册，无论该司法管辖区是否认为此类代币是证券或类似工具，不得在任何司法管辖区发售或出售，如果这样做会构成违反该司法管辖区的相关法律。 - -# 执照 - -本文的源代码[^src]在 Creative Commons Attribution-ShareAlike 4.0 International[^cc]许可下获得。 - -[^src]: See: @sources -[^cc]: See: @cc - - -# 介绍 - -互联网主要由开源项目组成，并且从一开始就是这样。 -随着时间的推移，其中许多项目已成为构建所有未来创新的基础。 -虽然从中获得了财富，但开源主要是在没有补偿的情况下创建和维护的。 - -我们相信，依靠世界上最小比例的工程师在薪水或保持互联网运行之间做出选择，整个现代人类的努力都受到了阻碍。 -开源是一种热爱的劳动，通常由于缺乏有意义的经济激励措施而受到阻碍，导致真正有价值的项目永远无法发挥其潜力，而其他项目则由于缺乏在整个生命周期内维护软件的激励措施而遭受安全问题。 -为了充分发挥我们的潜力，我们需要一个公平的开源生态系统薪酬体系，它不会从根本上改变它的构建或使用方式。 - -企业通常围绕开源包装商业模式，直接从仁慈的开发人员的工作中获得收入，同时还依靠他们在问题发生时修复错误。一个很好的例子是最近发生的涉及 Log4j 中的一个严重安全漏洞的事件，Log4j 是 Apache 软件基金会的一个包，它使用在企业和政府使用的许多商业软件和服务中。 2021 年 11 月，阿里巴巴集团控股有限公司的一名安全研究员报告了 CVE-2021-44228漏洞[^1], 该漏洞获得了 Apache 软件基金会的最高评分。 - -Tenable 首席执行官兼美国计算机应急准备小组 (US-CERT) 的创始主任 Amit Yoran 描述了这个漏洞。这个漏洞被称为“过去十年中最大、最严重的”[^2]。 - -恐慌随之而来，维护这个 packages 的少数志愿者因失败而受到公开抨击。在以谦逊的公平请求解决了愤怒之后，系统得到了修补。企业和政府最终意识到，Log4j，一个被广泛的关键系统使用了 20 年的Package，是由一些无偿志愿者维护的，这些无名英雄尽管受到行业的滥用，但仍采取行动，并不知疲倦地努力解决漏洞.[^3] 。 - -可悲的是，Log4j 远非唯一的例子。 -core-js 每周被下载 3000 万次，作为每个 Node.js 应用程序的基础，但它也几乎没有资金支持。最近，几位比特币核心开发人员辞职，理由之一是他们的 *缺乏经济补偿* . - -人们曾多次尝试提供奖励结构，通常涉及赞助和赏金制度。 -赞助使开源消费者有可能向他们喜欢的项目捐款。 -然而，把开源想象成一座砖砌的塔，底层早已被遗忘，但仍由敬业的工程师维护，并被更多的开发人员所依赖。 -通常只有位于塔顶的项目才为人所知，并获得赞助。 -这种有偏见的选择导致支撑塔的必需品不吸引捐款，而最受欢迎的人收到的捐款超过了他们的需要。 -奖励允许项目的消费者提议向开发人员支付开发特定功能的费用，因此只对那些不一定符合他们最大利益的项目进行补偿。 -同样，只奖励最喜欢的人。 - -在本文中，我们提出了Tea——一个基于开源开发者对整个生态系统的贡献，为他们公平支付报酬的去中心化系统，并通过应用于茶叶登记处所有条目的Tea激励算法制定。 - -![Simplified view of the tea steeping rewards system.](img/figure-1.svg) - -$\parskip=0pt plus 1pt$ - -[^1]: Source: @nist -[^2]: Source: @reuters -[^3]: Source: @twitter - - -# 组件 - -构建应用程序的软件开发人员需要四样组件：浏览器、终端、编辑器和Package管理器。 -在这四个中，Package管理器控制着开发人员构建产品所需的工具和框架。 -这一层是我们看到改变开源报酬方式的潜力的地方。 - -## Package管理器 - -Package管理器知道应用程序依赖于哪些开源软件才能运行，从塔顶到其底部。 -每个组件和对应用程序至关重要的版本是已知的并记录在案。它知道顶部塔楼的主体会仔细选择其依赖项，并且会继续进行仔细选择。 -Package管理器独特地放置在开发人员工具堆栈中，以根据实际的实际使用情况实现自动化和精确的价值分配。 - -我们提出了一个不可变的去中心化注册表，旨在根据一种算法分配价值，该算法确定每个条目对系统效用和健康的贡献。 -值可以在顶点（应用程序和基本库）进入图形，并递归地分发到这些顶点的依赖关系及其依赖关系，因为注册表知道整个开源图形。 - -此外，我们认为必须通过Package管理器获得材料信息，以便开发人员评估他们是否可以信任Package及其作者。此信息可能基于声誉、社区荣誉、去中心化身份(DID[^4])系统、其他Package管理器或可能依赖网络参与者将经济价值置于风险中的激励机制检索的数据。 - -我们预测，Tea的工具、信息和奖励的组合将公平地激励开发人员，帮助刺激开源软件的增长和培育创新。 - -[^4]: See: @w3 - -## 去中心化登记处 - -每个Package管理器都有自己的注册表，重复复制相同的元数据。 -是时候建立一个由依赖它的社区设计和管理的单一、全面和权威的注册表了。 -这种去中心化、不可变的注册表可以提供安全性、稳定性并防止恶意意图。 - -互联网运行在数以万计的重要开源组件上。值得注意的是，到目前为止，由删除基本开源基础设施引起的事件很少。最著名的是在 2016 年移除了 NPM left-pad7 依赖项[^5]， -该依赖项级联到持续集成和持续部署系统，让开发人员数日无所事事。这一事件表明，互联网本身是建立在脆弱的发展系统之上的。其他例子包括包维护者主动或故意参与破坏他们流行的包（参见colors.js、faker.js faker.js[^6],和 node-ipc[^7]),或者通过假装帮助维护Package并破坏它们来窃取利润的不良行为者，例如例如，比特币私钥（参见 event-stream10[^8]), -或带有故意拼写错误的恶意包，也称为域名仿冒，以期诱骗用户安装它们，例如 crossenv与 cross-env NPM packages[^npmjsCrossenv]. - -随着行业朝着数字资产成为软件一部分的未来发展，需要保证软件的完整性。我们不能继续让自己容易受到修改软件的恶意行为者的攻击。 -我们称之为Package管理器的大多数工具不能保证这些内置于应用程序和 dApp 中的包是其原始作者发布的未更改的开源代码。 Microsoft 的 GitHub 发现 17% 的软件漏洞是出于恶意目的而植入的 [^9], 其中一些漏洞在很长一段时间内未被发现（参见 Webmin 1.890[^10]). - -由声誉系统增强并由旨在揭露不良行为者和奖励良好行为者的经济激励措施支持的分散式注册表可能提供开发人员社区一直在寻找的保证。 - - -[^5]: Source: @theregister -[^6]: Source: @fossa -[^7]: Source: @lunasec -[^8]: Source: @github -[^npmjsCrossenv]: Source: @npmjsCrossenv -[^9]: Source: @zdnet -[^10]: Source: @threatpost - - -## 存储系统 - -开源软件Package提供了广泛的功能，其中一些可能受到限制或不需要。加密就是一个很好的例子。加密的一个关键用例是在全球范围内支持个人隐私。然而，加密也可用于不法目的（参见Phantom Secure，执法机构于2018年3月拆除）[^11]) 或可能被滥用以支持执法活动（参见 Ironside 行动 (AFP)、Greenlight 行动 (Europol) 和 Operation Trojan Shield (FBI)[^12] 其中 FBI 运营“加密”通信平台 AN0M，并说服犯罪分子使用他们的“加密”手机进行安全通信）。 - -加密的广泛应用使其成为开源软件的完美用例，并且是一个很好的例子，任何存储包的解决方案都必须是防篡改和抗审查的。 -Tea 是一种去中心化协议，它不打算根据其功能过滤或制裁Package。 -虽然 Tea 治理可能会选择删除已证实的恶意包（有关更多信息，请参阅治理部分），但 Tea 系统连接多个存储系统至关重要，包括证明Package未被更改且正确复制的去中心化存储系统。 -Package维护者可以选择最适合他们需要的存储系统来安全地存储和分发他们的Package。 - -[^11]: Source: @fbi -[^12]: Source: @europol - -# 网络参与者 - -tea 的使命是赋予开源社区权力，并确保他们的贡献者在创建构建互联网的工具时得到支持。 -在本白皮书中，我们通过参与者的贡献来区分他们。有些人可能会贡献代码或验证贡献的代码。 -其他人可能会提供经济价值来支持开发人员及其声誉。 - -## Package维护者 - -Package维护者必须确保他们的软件随着行业的发展继续提供不断增加的价值。 - -Tea 假设Package创建者维护他们的工作。 -Package维护者是开源社区的支柱，他们需要因他们的持续贡献而获得授权和奖励。 -Package维护者可能决定停止维护工作，或者意识到他们无法以符合包用户期望的速度运行。 -Package维护者在完成提交时会收到一个不可替代令牌 (NFT)（有关更多详细信息，请参阅维护者 NFT 部分）。 -该 NFT 用于证明他们的工作，并且是指导Tea奖励的关键。包的 NFT 持有者可以转让它的所有权属于另一个开发人员（或一组开发人员），从而使他们成为Package的维护者和任何未来奖励的接受者。 - -类似地，开发人员可以决定承担Package维护者的角色，通过分叉现有Package并提交,他们将继续维护的新包，从而成为Package创建者和维护者。 -必须为开发人员社区提供正确的工具来确定正在维护的Package以及他们过去和现在的维护者的声誉和工作质量。我们经常看到开源工作被篡改，许多人的努力被坏人毁了。 -尽管这些不良行为者的工作在很大程度上被发现和补救，但通常直到因财务或数据丢失而造成重大损失。 -以 EventStream npm package为例[^13] ，当黑客设法渗透开源项目，获得其原作者的信任并将 EventStream 修改为依赖于恶意将比特币钱包凭证泄露到第三方服务器的Package。 -尽管工具可能有助于检测其中一些攻击，但它们并不总是值得依赖的，这会创建一个依赖于彼此的勤奋和分享他们发现的意愿的整个社区。 - -我们建议通过Tea令牌部分中描述的Tea令牌引入激励措施，鼓励开源社区建设性地报告他们的发现，以便包维护者可以在它们被利用之前解决它们。 - -[^13]: Source: @medium - -## Package用户 - -Package用户是专注于解决特定问题的软件开发人员。 -他们经常在开源社区中寻找快速试验所需的工具，并以很少甚至免费的成本进行迭代，直接受益于Package创建者和维护者的工作。 -传统上，一个子集可能选择通过捐赠或其他形式的报酬来支持包维护者；然而，这种情况很少发生。 - -赞助可以成为支持开源开发的有效系统；但是，报酬通常不会扩展到所有依赖项。这种限制有利于收藏但妨碍创新和软件构建。为了努力成为软件开发的基础，开源必须赋予所有开发人员，无论是初学者还是专家，跨越所有层。 - -Tea 的目的是维护开源软件的核心价值，同时提供一个去中心化的系统来奖励Package维护者的工作。为了实现这一使命，tea 打算开发——并激励其他人开发——Package用户支持Package维护者的机制通过NFT令牌的独特用例，如NFT令牌和未来工作和潜在的社区努力部分所述。 - -## Package支持者和赞助商 - -Web 2.0 和 web3 中，Package支持者通常被称为“赞助者”。他们是使用开源软件构建其商业产品的组织或Package用户、希望支持生态系统的慈善家或希望资助团队开发更大系统组件的企业家。 - -Tea建议将Package支持者社区扩展到整个Tea社区，无论是组织、开发人员、用户还是技术爱好者。 -Tea 的目标是通过Tea 代币的独特用例实现去中心化激励机制，让 Tea 社区的任何成员为开源的永久可持续性和持续增长做出贡献。 -Package支持者和赞助者可以根据他们的工作、信仰或任何会影响他们决定的标准和指标自由决定他们想要支持哪些包或包维护者。 -此外，Package支持者和赞助商提供的支持将流向每个包的依赖项，从而隐含地信任包维护者对其堆栈做出良好选择，并使用此信息为他们的声誉做出贡献。 - -如果Package维护者提供此类服务，Package支持者和赞助商可能会获得高级支持级别的 NFT 作为回报，从而受益于加速的SLA 或更灵活的许可。 -此外，Package支持者和赞助商可能会决定支持Package或Package维护者，并自动重定向他们的全部或部分奖励，以激励团队构建新的开源软件。 -新生项目和更成熟的项目一样可以得到支持，进一步激励不断发展的开源环境。 - -## Tea评价者 - -随着新Package或现有Package的新版本的发布，需要证明工作的有效性。 -此信息对于Package用户决定是否信任Package及其维护者至关重要。 -使用Tea协议，此功能由Tea评价者提供。 - -ea评价者通常是经验丰富的软件开发人员，他们愿意花一些时间来检查Package相关的声明（功能、安全性、语义版本控制[^14],许可准确性等）， -并用他们的声誉和经济价值来证明结果他们的研究和分析，并支持他们的评论。 -Tea评价者因勤奋和努力而获得奖励。 -在tea，我们将“泡茶”称为锁定Tea代币以支持您的评论并根据对您的评论有效性的共识获得奖励（或惩罚）的行为。 - -像Package支持者一样，品茶师可以影响Package和Package维护者的声誉。 -然而，考虑到它们在验证Package的安全性、功能和质量方面的作用，它们的影响更为显着。 -品茶者还需要建立自己的声誉来支持他们的主张。 -他们的工作质量和他们在评估时冒着风险的经济价值与其他外部数据源相结合，将建立每位品茶师的声誉，为他们的工作带来更多价值。 -有关用于影响包和包维护者声誉的机制的更多详细信息，请参阅Package信誉部分。 - -[^14]: See: @semver - -# 协议概述 - -奖励开源贡献的协议设计面临挑战。 -开源软件根据定义对所有人开放，因此可能会受到错误归属、盗用或恶意篡改。 -然而，开源社区一直表现出它愿意突出好人和揭露坏人的意愿。从历史上看，审查和评论其他开发人员的贡献所花费的精力完全是自愿的，尽管报告和捍卫调查结果可能非常耗时且至关重要。 - -我们打算为由声誉和财务激励保护的应用程序创建一个无需信任的分发平台，因为我们认为，如果没有声誉系统和社区成员交流他们的发现和支持的能力（或异议）用于Package或开发人员的工作。 - -我们必须为开发人员提供工具来访问和贡献这个声誉系统。 -包括对其Package中所有依赖项的版本和声誉的简单可视化和可编程访问的工具。 -清楚地了解哪些社区成员支持每个Package以及他们正在锁定多少Tea代币将有助于每个Package的声誉，就像Package维护者锁定代币多少可以传达他们对工作的支持程度一样。 -这些组合数据点将有助于为所有社区成员提供信誉系统并促进选择。 -由于 EventStream Package黑客不是通过Package本身进行的，而是通过其依赖项之一进行的，因此所有依赖关系层的可见性对于构建这个无信任系统至关重要。 -但是，在设计和构建系统时，需要优先考虑计算和交易（“gas”）成本等因素。 - -我们的目标是奖励 Web 2.0 和 web3 开发人员。 -每个堆栈的复杂性和细节使得跟踪Package的安装和卸载很容易成为一个或多个不良行为者的受害者。 -这包括“购买”装置以人为地夸大数字。更糟糕的情况是通过与许可证密钥或其他部署跟踪产生不必要的摩擦，对开源软件的性质进行根本性的改变机制。 -为了提供最广泛的覆盖范围，我们认为奖励不能依赖于跟踪安装或卸载的简单概念，而应依赖于鼓励提交优质Package和报告恶意或高风险Package的激励机制。 -最后，许多Package依赖于公共依赖项。例如，Lodash 有151,209名用户[^15] 而chalk 有 78,854名用户[^16]，或者 Log4js有 3,343 名用户[^17]。 - -随着越来越多的Package使用相同的依赖项创建，我们如何确保公平和公平地分配激励措施？我们如何确保最常用的依赖项得到奖励，而不会让新的或新兴的软件Package和开发人员挨饿？我们如何确保激励系统最终不会引导开发人员远离小众开发语言，将它们集中在激励更好的地方而且，作为开发人员，我们如何识别依赖最多的包来构建替代方案——这些包的更精简、更高效、编码更好的版本在tea，我们认为缺乏激励阻碍了开源软件的发展。 -在正确的经济激励和奖励的支持下，更多的开发人员将能够构建、改进和增强开源软件，以造福世界。只有这样，Tea币才能代表开源软件的总价值。 - -[^15]: Source: @npmjsLodash -[^16]: Source: @npmjsChalk -[^17]: Source: @npmjsLogFourjs - -## Package提交 - -Package发布的提交需要多个事务以原子方式发生。具体来说，包维护者必须： - -* 向去中心化的注册表（及其语义版本）。 -* 将Package上传到去中心化存储系统，以实现弹性、抗审查和易于分发。 -* 通过锁定Tea令牌来提高Package的声誉和可信度。 - -这三个操作中的任何一个失败都将导致协议恢复到之前的状态，从而消除提交的任何证据。 - -成功提交Package后，Package维护者将收到维护者 NFT，以证明他们的工作和对开源的贡献。 -Package维护者可以将与维护者 NFT 相关的锁定奖励转移给第三方。但是，与资产的创建和维护相关的声誉将保留在Package维护者手中，因此他们的声誉可能会随着时间的推移而受到影响。 -随着茶社区的任何成员的声誉达到关键里程碑，他们可能会被授予访问协议的更高部分或获得加速奖励的权限，这由茶治理决定。 -有关维护者 NFT 的更多详细信息，请参阅维护者 NFT 部分。 - -### 依赖分析 - -Package依赖关系可以深入运行，因为每个Package通常都有依赖关系和依赖项。 -为了提供一种简单的方法来奖励所有为开源软件做出贡献的开发人员，同时保持依赖关系树的快速创建和计算效率，我们建议在提交Package时仅验证第一级依赖关系。 - -这种设计是基于这样的假设，即每个依赖项本身都是一个独立提交给茶树的包。这样做时，它的每个依赖项都可以被映射，如果它的依赖项本身有依赖项，那么这些依赖项将在提交依赖包时被映射。 - -![Dependencies analysis diagram.](img/figure-3.svg){#fig:dep-analysis} - - -在 @fig:dep-analysis, PackageA的提交触发了从运行时依赖1到n的分析，并构建从1到n的依赖，而运行时依赖1.1到1.N和构建依赖关系1.1到1。 -在Package B提交时，n个样本被分析。我们将对激励分发采用相同的方法，因为质押令牌分布在所有依赖项上，因此递归地质押作为依赖项列出的Package (在 @fig:steeping-rewards). - -![Steeping rewards distribution across dependencies.](img/figure-2.svg){#fig:steeping-rewards} - - -版本控制和冲突的依赖关系是重大挑战，对它们进行故障排除可能会耗费大量时间。为了解决这个问题，我们建议在提交时对每个Package进行全面的依赖扫描，以便我们可以确保Package符合以下语义版本范围规则。 - -* Package只能将它们的依赖关系限制在一个主要版本上，尽管范围的开始可以是任何有效的语义版本（例如，>=5.2.1 <6). -* 如果依赖项升级到更新的主要版本，tea 可能会要求增加Package的主要版本。 -* 同样，如果依赖项升级到更新的次要版本，tea 可能会要求增加Package的次要版本。 -* 如果添加了新的依赖项，tea 可能会要求增加Package的次要版本。 - -考虑到违反上述规则时对任何Package用户施加的不必要的努力，我们建议削减Package维护者质押的一部分茶代币，以反映他们是否尽职调查。 -如果开发人员欺骗用户，就会有人丢失代币，由于依赖项扫描预计会在提交时进行，我们应该注意，不会发生在Package支持者和赞助商或质押者身上。 - -## Package和Package维护者的声誉 - -Package维护者必须通过质押Tea令牌来为其Package的声誉和可信度做出贡献。 -然而，仅依赖作者经济贡献的声誉系统无法提供足够的用户保护，并且可能会受到 Sybil 攻击，包括个人自刷好评，从而欺骗用户相信他们的工作从而得到了许多人的审查和批准。 - -有几种方法可用于防止 Sybil 攻击，其中一些方法由 NitishBalachandran 和 Sugata Sanyal 在“缓解Sybil 攻击的技术回顾”中进行了描述。[^18]. -由于茶是一种去中心化协议，使用依赖于中心化证书颁发机构的信任认证系统将违背其核心。 -我们建议专注于减轻 Sybil 攻击的分散方法，更具体地说，关注依赖于大量网络参与者的方法，这些参与者受到激励来评估和公开代表每个Package及其维护者的声誉。 - -类似于POS区块链上的区块生产，非生产节点可以验证其他人的工作，并在必要时显示违反网络规则的行为，对不良行为者进行削减（销毁他们的一部分股权）的惩罚，我们提出了一个系统，第三方（又名Tea品尝者）将能够审查Package维护者生产的Package，并在经济上激励他们以开源的最佳利益行事软件社区及其用户以及认可良好行为并惩罚不良行为。 -该系统必须既能抵抗 Sybil，又能防止大型代币持有者对协议或特定包的声誉产生重大影响。我们相信这种方法更符合开源，提供更肥沃的基质来促进采用和信任，并最终促进 Tea的发展。 - -[^18]: Source: @arxiv - -## 第三方Package审查 - -第三方对Package的审查是建立声誉的重要组成部分，但是，第三方审查有其自己的一组独特威胁，包括上述的 Sybil 攻击。 - -区块链技术，以及更明确的质押，为Tea提供了应对这一挑战的独特机会。 -虽然钱包地址可能无限量可用，但Tea代币并非如此，其初始供应量预计为 100 亿。 -此外，开发人员执行的每个操作，例如提交包、验证包或质押它们，都将有助于他们的声誉，从而创建每个开发人员可以用来为茶社区做出贡献并参与茶治理的独特配置文件。 - -通过要求第三方审阅者质押茶代币并承担丢失部分质押代币的风险，如果他们的行为违背网络的利益或成为不良行为者，第三方可以为包裹提供额外的信任，并且以茶叶代币的形式获得奖励。 - -我们还建议将信誉系统扩展到对包装进行独立验证的第三方——品茶者。正面评价的完成将需要两个操作以原子方式发生： - -* 提交代码审查，由品茶师签名，社区所有成员均可公开访问，以及 -* 质押“支持”Package（与“反对”Package）的行为，以证实他们的评论 - -完成包含一个或多个严重漏洞的负面评论将要求品茶者首先使用消息传递协议联系Package维护者，以通知他们该漏洞并允许他们及时解决问题。 -在分配给Package维护者以解决其漏洞的治理定义期限届满时或当更正的Package可用时，将使用相同的消息传递协议通知此Package的所有用户和测试者（包括依赖者）漏洞已被修复已识别并希望得到解决，因此他们知道要更新他们的应用程序或依赖项。 -为了抑制浪费开发人员的时间，品茶师和Package维护者之间的沟通将要求品茶师质押Tea代币。 - -完成这两项操作后，品茶师将收到一份 NFT，作为他们在特定包装和包装版本上工作的证据。 -NFT 的积累与每个被审查的Package质押率和从外部系统提取的信息相结合，将为品茶师的声誉提供信息。 -随着他们的声誉达到关键里程碑，品茶者可能会获得协议的更高部分或加速奖励，这由Tea治理决定。 - -## 过时或损坏的Package - -tea 的使命是奖励开源社区的贡献者和参与者；然而，奖励必须与Package维护者和品茶者所付出的努力相称。 -维护不足、过时或损坏的包清楚地表明包维护者没有达到社区的期望，或者没有提供通过包质押给他们留下的信任和支持。 -过时Package的另一种表现可能是继续使用遗留语言或多版本语言的遗留版本。Package过时或损坏时间过长表明品茶者需要定期和一致地审查Package维护者的工作。 - -品茶师是开源社区的重要成员，因为他们的评论和相关声明可以引导Package用户接近或远离Package。 -为了确保评论可以持续受到信任，我们提出了一种机制，让过时或损坏的包裹可能会看到他们质押过的代币的一部分被发送给最先意识到任何Package缺乏维护的品茶者。 - -任何概述了诸如漏洞或使用过时依赖项之类的缺陷并且在治理定义的宽限期之后保持开放的负面评论都应被视为Package维护者的失败。 -他们没有完成他们被委托和奖励的任务。 -对于Package的支持者和赞助商来说也是如此，他们将自己的声誉押在了拖欠的Package维护者的工作上并因此获得了奖励，但未能发现缺乏维护或选择继续支持该Package。 - -随着Package的普及和使用越来越多，越来越多的应用程序和潜在的关键任务系统依赖于它们，我们必须激励开发人员谨慎地向Package维护者和Package维护者报告缺陷在它们被利用之前解决这些缺陷。 -因此，我们建议任何过时或损坏的Package受到一个或多个有证据的负面评论并在治理定义的宽限期后仍处于这种状态，无论其来源如何（Package维护者、Package支持者，赞助商或先前的品茶者），而另一部分则发送给提交负面评论的品茶者。 -分配给所有品茶者的依据是他们的评论年龄和他们为评论质押的Tea代币数量。 - -## 维护者NFT - -成功提交Package后，维护者将收到NFT 以证明他们的工作和贡献。 -此 NFT 的持有者将自动获得与该Package相关的所有奖励。 -Package维护者可以通过简单地转移NFT 将Package的维护所有权转移给另一个Package维护者。 -NFT 的成功转移将导致新所有者自动获得未来的礼包奖励。 - -声誉建设的一个重要部分依赖于Package提交的频率和数量。 -交付给包维护者作为其工作证据的 NFT 可能会被声誉系统用来更新包维护者的声誉，并允许他们访问协议的提升部分，这由Tea治理决定。 -但是，为了防止攻击媒介，例如社区成员购买他们的声誉，维护者 NFT 的转移不会导致声誉的转移。声誉必须与特定开发人员的工作直接相关，并且不得转让。 - -# Tea代币 - -## 保护网络 - -虽然许多区块链可能看起来是有效且安全的基础设施解决方案，但我们认为必须仔细考虑构建Tea系统的技术堆栈。 - -可扩展性、成本效益、ESG 和第三方可扩展性是Tea选择PoS共识的重要设计考虑因素。 -PoS共识中，节点运营商和网络参与者以链的原生代币的形式抵押经济价值，以提高系统的安全性。 -节点运营商和网络参与者因成功生产符合网络规则并包含准确交易信息的区块而获得奖励。不活动（又名节点宕机）或恶意/不正确的活动会通过通过削减销毁一小部分质押代币来受到惩罚。 - -由Tea代币支持的PoS共识系统将允许Tea代币持有者 -通过质押为系统的安全性做出贡献，并通过质押来支持开源开发人员。我们充分意识到经济因素可能会阻止一些开发商下注或质押茶；因此，只需一片叶子，即代表一亿分之一 ( $10^{-8}$ ) Tea代币的的最小面额，就可以进行转账和质押。 - -Tea代币的两种应用都在支持和发展开源生态系统方面发挥着重要作用。 -质押Tea将确保Tea系统继续安全运行，因此所有网络参与者都可以提交和访问Package以对其进行审查，将它们集成到他们的应用程序中等。 -相反，茶的质押将支持茶的目标，即为所有人提供工具，网络参与者支持和使用满足质量和可靠性要求的Package，这些Package由Tea社区决定每个Package的支持和反对。 -对每个包裹持异议。在定义和实现时要非常小心固定和质押参数，这样一不会混淆两者。 - -## 奖励和惩罚 - -如前所述，不良行为者可能有强烈的动机来破坏开源软件。互联网的大多数关键基础设施都在开源上运行，寻找漏洞利用和其他漏洞的竞赛正在进行中。 -在tea，我们认为Package维护者不应该受到指责（尽管他们经常受到指责）。 - -Tea协议奖励通过公平公正的奖励分配解决了这个问题。 -像 Lodash 这样拥有超过 151k 依赖项的Package是开源开发的支柱，它的维护者应该得到相应的奖励。 -然而，仅建立在受抚养人数量上的奖励制度将阻止创新者破坏这些垄断，除非他们有足够的第三方资助或已经积累了足够的资源来自筹资金。 -这种方法可能会导致贡献者数量的减少，从而导致与Tea的含义截然相反的结果。 - -Tea的目标是代表开源软件的价值，为此，通过赋予其参与者所需的资源，促进其增长不受阻碍地追求自己的激情。Tea激励分配制度需要仔细考虑每个Package的质押率，并调整每个Package的质押率相应的激励。 -为了减少风险，使用了少量的Package，由于许多应用程序之间的依赖关系收集了大部分的渗透为了获得奖励，我们将利用web3基金会的研究成果基于Polkadot股权证明的奖励机制。当一个Package超过最佳质押比率，其质押奖励比率将逐渐降低。 -当包裹超过其最佳质押比率[^19] ，质押奖励比率将急剧下降，以抑制Package支持者和茶品尝者进一步质押高度质押率的Package。这种设计可以使质押较少的软件对支持者和品茶者都更具吸引力。 -它还可能激励有经验的开发人员构建高质押率Package的替代品，为Tea社区创造机会，以平衡支持现有软件和促进创新。 -质押比将在其初始设计中使用循环供应来计算。茶社区可能会改变这种设计，以进一步提高系统的可扩展性。 -设 $\chi$ 是所有包的质押比。 -它代表Package维护者、Package用户、Package支持者和赞助商以及质押者质押的茶代币总数除以茶代币总供应量。 -考虑到今天有多少开源Package可用以及它们的预期增长， $\chi$ 将始终是一个介于 $0$ 和 $1$ 之间的非常小的值。 - -设 $\psi$ 为质押比率。 -它代表任何网络参与者为保护网络而质押的茶代币总数。 - -设 $\chi_{ideal}$ 我们希望每个包在所有包及其依赖项之间公平分配奖励时达到的比率。 -$\chi_{ideal}$ 的值必须随着新Package添加到去中心化注册表并创建依赖关系而更新。为了确定 $\chi_{ideal}$ 的最佳值，我们将使用在每个奖励周期开始时更新的实时曲线。 - -令 $\tau = \tau(\chi)$ 为分配给所有茶代币以支持开源开发者的茶社区成员的年质押利率。 -换句话说， $\tau(\chi)$ 对应于社区成员在一年内获得的质押奖励，该社区成员在整个一年中质押Tea代币。 - -设 $\gamma = \gamma(\psi)$ 为分配给所有节点运营商和网络参与者的年度质押利率，这些节点运营商和网络参与者质押茶代币以保护网络。 -换言之， $\gamma(\psi)$ 对应于一个社区成员在一年内获得的质押奖励，该社区成员质押了一整年的Tea代币。 - -设 $\delta$ 是针对网络金库的年度通货膨胀率。 -$\delta$ 可能会随着外部因素影响代币供应而变化。 -我们将年度质押奖励率视为 $\chi$ 的函数，将年度质押奖励率视为 $\psi$ 的函数。 - -* $\tau(\chi)$ 对应于人们质押包装的动机。 -随着 $\chi$ 增加, 需要更少的奖励 $\tau(\chi)$ 。 -* $\gamma(\psi)$ 对应于人们对网络进行质押的激励。 -随着 $\psi$ 增加, 更少的奖励 $\gamma(\psi)$ 来保护网络. - -年通货膨胀 $I$ 将等于 $(\tau + \gamma + \delta)$ 并且计算如下: - -$$ -I = \frac{\textrm{年末Token供应} - \textrm{年初Token供应}}{\textrm{今年年初的代币供应 }} = (\tau + \gamma + \delta) -$$ - -应权衡 $\tau_{\textsc{all}}$ （分配给所有包的激励）和 $\gamma_{\textsc{all}}$ （分配给网络安全的所有贡献者的激励）对通胀的贡献，以确保系统激励最佳Package/质押比率。 - -当我们关注分布在所有激励措施时，我们应注意到 -$\tau_{\textsc{all}}$ -是Package比率 $\chi$ 的函数，因此 -$\tau_{\textsc{all}}(\chi) = \chi \cdot \tau(\chi)$. -从我们之前的分析可以看出 -$\tau_{\textsc{all}}(\chi_{ideal}) = \chi_{ideal} \cdot \tau_{ideal}$. -由于达到了这种状态 -$\chi = \chi_{ideal}$ -, 因此奖励在 -$\tau_{ideal}(\chi)$ -此处最大 - -令 $\tau_{ideal} = \tau(\chi_{ideal})$ -为网络在 $\chi = \chi_{ideal}$ 的理想场景下提供的奖励率。 - -令 $\tau_{0}$ 为 $\tau_{\textsc{all}}(\chi)$ 的极限，当茶叶社区的任何成员都没有质押任何软件时， $\chi$ 变为零。 - $\tau_{0}$ 的值应接近于零但不为零以激励早期采用者。 -根据 web3 基金会的研究建议，我们建议： - -* 膨胀函数在 $\chi = 0$ 和 $\chi = \chi_{ideal}$ 之间线性增长，并且 -它在 $\chi = \chi_{ideal}$ 和 $\chi = 1$ 之间呈指数衰减。 - -我们为 $\tau_{\textsc{all}}(\chi)$ 选择了类似的指数下降，因为它意味着 $\tau(\chi)$ 的指数下降，并且我们希望奖励急剧下降到 $\chi_{ideal}$ 之外，以防止单个Package收到所有奖励。 - -衰减的定义是通货膨胀率最多下降50%当 $\chi$ 向 $d$ 右边移动了 $\chi_{ideal}$ – i.e. -$\tau_{\textsc{all}}(\chi_{ideal} + d) \geq \tau_{\textsc{all}} \cdot 0.5$. - -我们提出了以下利率和通货膨胀率函数，它们取决于参数 $\chi_{ideal}$, $\tau_{ideal}$, $\tau_{0}$ 和 $d$. - -\begin{align*} -&\tau_{\textsc{all}}(\chi) = \tau_{0} + (\tau_{\textsc{all}}(\chi_{ideal}) - \tau_{0})\frac{\chi}{\chi_{ideal}}\enspace\textrm{for}\;0 < \chi \leq \chi_{ideal} \\ -&\tau_{\textsc{all}}(\chi) = \tau_{0} + (\tau_{\textsc{all}}(\chi_{ideal}) - \tau_{0}) \cdot 2^{(\chi_{ideal}-\chi)/d}\enspace\textrm{for}\;\chi_{ideal} < \chi \leq 1 -\end{align*} - -正如优秀的演员需要得到奖励一样；不良行为者需要被查明并受到惩罚。 -开源软件为不良行为者提供了许多机会，为整个开发人员社区制造痛点和声誉风险。 -从盗用工作到更改和重新分发Package，或者注入恶意代码，好人和坏人之间的战争仍在继续，通常是资金充足的坏人将开源Package的污染视为机会在经济上受益。 -不利的一面相对较小，Package可能被禁止在数字货架上或声誉不佳。 - -我们建议引入一种削减机制，以建立直接影响不良行为者经济价值的更实质性的不利因素。 -分析新提交的Package中的代码，我们建议品茶者接收工具和激励措施来查明和突出恶意代码，以便Package用户可以意识到风险，Package维护者、支持者和赞助商会因提交或支持而受到惩罚恶意代码。 -在这种情况下，对于根据网络规则执行的所有有证据的负面评论，并且已经由Package维护者在治理定义的期限内解决，维护者不应受到与支持者和赞助商或茶品尝者相反的任何惩罚。 -对相关Package进行了正面评价。对于根据网络规则执行的负面评论并且维护者未在治理定义的期限内解决，维护者、支持者和赞助商以及以前的品茶者所持有的一小部分代币将被削减。 -另一部分将被锁定在由Tea治理控制的保险池中。Tea治理将与社区密切合作制定政策和规则，将池中的内容分发给受漏洞影响的人。该协议将根据他们“反对”包裹质押的Tea代币的数量以及他们的代币质押的时间，将三分之一的质押代币分配给所有对负面评论做出贡献并质押在包裹中的茶品尝者。 -换句话说，一个或多个品茶者越早根据网络规则识别并报告缺陷，他们支持安全和高效的开源开发的奖励就越高。 - -为了防止社区成员随机投票“反对”希望获得大部分惩罚的高质押Package，所有“反对”质押的Tea代币都不会获得通货膨胀奖励，并且可能会受到衰减机制的影响，从而随着时间的推移降低其价值。 - -[^19]: Source: @web3 - - -# 治理 - -治理对于任何分布式系统的开发、可持续性和采用都至关重要。 - -我们建议Tea包括链上治理，所有Tea代币持有者都可以建议和投票改变由代币所有权和声誉加权的关键参数。 -这些参数可能包括通货膨胀、交易费用、赌注奖励、质押奖励或最佳质押比率。此功能将确保关键参数可以随着时间的推移由Tea社区成员发展和优化。 -我们预计治理将以简单的结构启动，并随着Tea系统的成熟而逐步扩展，促进采用并确保逐步去中心化。 - -一些系统参数可能不受治理或支持高频更改以减少治理所代表的攻击面。 -参数向开放、去中心化治理的逐步过渡将确保系统的稳定性和可预测性。 - - -# 第三方可扩展性 - -当我们构建初始工具以激发开源社区的长期支持时，我们相信我们的部分使命是确保第三方可以扩展整个工具集。 -除了为开发人员提供构建协议扩展的基础设施，包括创新的新方法和进一步支持开源开发人员之外，我们的计划还包括其他包管理器为协议做出贡献的潜力。 -开源开发人员的梦想和努力打造了支持我们日常生活的创新。我们期待发现Tea社区提出的Tea的新用途和扩展。 - -# 未来的工作和潜在的社区努力 - -随着Tea系统的成熟，我们预计社区将通过治理来决定并为茶系统的改变和扩展做出贡献。以下是我们认为可能会激发一些灵感的一些想法。 - -## Tea交易者 - -开源软件社区充满活力，不断寻求创新和创造价值。 -这种奉献精神和利他主义导致不断构建新的软件和Package，每一个都拉动依赖关系。因此，我们预计依赖关系图会不断发展，从而导致质押比率和奖励的频繁变化。 -未来，Tea社区可能会提议开发一个系统，该系统旨在动态监控每个Package的质押率，并重新平衡支持者如何根据自己的标准质押代币。 - -## Package转让特许权的使用费 - -我们认识到，Package维护者可能会决定将他们的丰厚奖励流转移给一位或多位开发人员。 -这种转移的治理必须由包维护者及其合作伙伴决定，不受Tea的干扰。 -需要提供工具以使此类转移是全部或部分的（可能通过仅将一部分质押奖励重定向给一个或多个开发人员，而剩余的奖励继续流向原始包维护者）和质押奖励流经由单个网络参与者、多个网络参与者控制的单个帐户，或使用静态或动态比率自动分布在多个帐户中。 - -## 跨多个维护者的奖励分配 - -一个Package的维护可以依赖于另外一个开发团队的工作。 -在质押奖励开始流动之前，团队应该考虑在他们之间自动分配质押奖励。 -如何分配必须由维护者自己决定，因为他们最有能力评估谁做出了贡献以及应该如何奖励他们。 - -为此，每个团队（或多个团队）可以建立自己的去中心化自治组织（DAO），并自动分配奖励或部署更复杂的系统，以根据外部因素（例如所有 DAO 的投票）确定适当的奖励分配成员，或基于持续贡献、成功完成赏金等的基于时间的分配。 - -## 处理Package“分叉” - -我们认为分叉是必不可少的，而且在很大程度上没有得到充分利用。分叉 可以成为开发在功能、性能、安全性甚至注意力方面竞争的Package的有效工具。尽管它们可能有用，但分叉必须承认最初的努力。通过未来的工作或潜在的贡献，Tea社区可能会增强系统以要求声明分叉，甚至可能在提交Package时检测到。品茶师透露的未申报分叉可能会导致部分质押过的代币被削减，转移给原始Package包装维护者，并发送给暴露分叉的品茶师。 - -## 运行VS构建依赖项 - -在分配Package质押奖励时，Tea 可能无法区分构建依赖项和运行时依赖项。 -然而，如果Tea社区对做出这样的区分有强烈的感觉，Tea社区可能会建议对质押奖励分配算法进行增强，以说明每个依赖项的重要性以及它们对依赖它们的Package的价值的贡献。 -这些提案将根据社区的决定进行投票和实施。 - -## 基于使用的报酬 - -随着越来越多的应用程序是使用在 tea 注册的Package构建的，社区可能会增加奖励算法，以便分配可能受到外部证明数据集（例如使用情况）的影响。 -奖励机制的这种更新可以允许更高的Tea代币奖励分配流向使用率最高的Package，同时仍然尊重Tea代币部分中描述的质押比率的限制。 -Package维护者可以使用类似的方法根据他们选择的透明逻辑在他们的依赖项之间分配质押的奖励。 -请注意，所有用于影响Tea系统中跨Package和依赖项的奖励分配需要可证明是可靠的。 - - -# 致谢 - -这份白皮书的存在离不开众多茶友的支持和奉献。 -作者要感谢 Josh Kruger、Jadid Khan 和 Jacob Heider 对代币经济学的贡献，以及许多自愿花时间就本文档内容提供反馈的谨慎个人。 - -$\parskip=0pt plus 1pt$ - -# 专业术语 - -| 术语 | 定义 | -|------|------------| -| Leaf | 最小面额的茶叶代币，一片叶子相当于一亿分之一 ($10^{-8}$) 的茶代币。 | -| Slashing | 惩罚违反网络规则的行为的措施 | -| Staking | 锁定茶叶代币以保护构建茶叶系统的权益证明网络的行动。 | -| Steeping | 锁定茶叶代币以支持您的主张并根据对您主张的有效性的共识获得奖励（或惩罚）的行为。 | - - -# 参考文献 diff --git a/white-paper.md b/white-paper.md deleted file mode 100644 index 5dd5768..0000000 --- a/white-paper.md +++ /dev/null @@ -1,583 +0,0 @@ -# Disclaimer - -The information set out in this white paper is of a preliminary nature. -Consequently, neither the authors nor any of their respective affiliates assume any responsibility that the information set out herein is final or correct and each of the foregoing disclaims, -to the fullest extent permitted by applicable law, any and all liability whether arising in tort, contract or otherwise in respect of this white paper. -Neither this white paper nor anything contained herein shall form the basis of or be relied on in connection with or act as an inducement to enter into any contract or commitment whatsoever. - -Nothing in this white paper constitutes an offer to sell or a solicitation to purchase any tokens discussed herein. -In any event, were this white paper to be deemed to be such an offer or solicitation, no such offer or solicitation is intended or conveyed by this white paper in any jurisdiction where it is unlawful to do so, -where such an offer or solicitation would require a license or registration, or where such an offer or solicitation is subject to restrictions. -In particular, any tokens discussed herein have not been, and, as of the date of issuance of this white paper, are not intended to be, registered under the securities or similar laws of any jurisdiction, -whether or not such jurisdiction considers such tokens to be a security or similar instrument and may not be offered or sold in any jurisdiction where to do so would constitute a violation of the relevant laws of such jurisdiction. - - -# License - -The source code[^src] of this paper is available under the Creative Commons Attribution-ShareAlike 4.0 International[^cc] license. - -[^src]: See: @sources -[^cc]: See: @cc - - -# Introduction - -The Internet is predominantly composed of open-source projects and has been since its inception. -Over time, many of these projects have become foundational pieces upon which all future innovation is built. -And while fortunes have been made from it, open-source is mainly created and maintained without compensation. - -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 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 United States 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. -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. - -![Simplified view of the tea steeping rewards system.](img/figure-1.svg) - -$\parskip=0pt plus 1pt$ - -[^1]: Source: @nist -[^2]: Source: @reuters -[^3]: Source: @twitter - - -# Components - -A software developer building an application needs four things: a browser, a terminal, an editor, and a package manager. -Of these four, the package manager is what controls the tooling and frameworks a developer needs to construct their product. -This layer is where we see the potential to change how open-source is remunerated. - -## The Package Manager - -The package manager knows what open-source software an application depends on to function, from the top of the tower to its base. -Every component and version essential to the application is known and recorded. -It knows that the top of the tower carefully selects its dependencies and that careful selection continues down. -The package manager is uniquely placed in the developer tool stack to enable automated and precise value distribution based on actual real-world usage. - -We propose an immutable decentralized registry designed to distribute value based on an algorithm that determines each entry’s contribution to the system’s utility and health. -Value can enter the graph at apex points—apps and essential libraries—and be distributed to the dependencies of those apex points and their dependencies recursively since the registry knows the entire open-source graph. - -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. - -[^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 -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, 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 event-stream[^8]), -or malicious packages with intentional misspelling errors, also known as typosquatting, -in the hope of tricking users into installing them, for example crossenv vs. cross-env NPM packages[^npmjsCrossenv]. - -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. - -Most tools that we call package managers cannot guarantee that these packages built into the apps and dApps are the unaltered open-source code published by their original authors. -Microsoft’s GitHub has found that 17% of vulnerabilities in software were planted for malicious purposes[^9], with some remaining undetected for extended periods (See Webmin 1.890[^10]). - -A decentralized registry augmented by a reputation system and supported by economic incentives designed to expose bad actors and reward good actors may provide the guarantees developer communities have been looking for. - -[^5]: Source: @theregister -[^6]: Source: @fossa -[^7]: Source: @lunasec -[^8]: Source: @github -[^npmjsCrossenv]: Source: @npmjsCrossenv -[^9]: Source: @zdnet -[^10]: Source: @threatpost - - -## 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). - -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 - -# Network Participants - -tea’s mission is to empower open-source communities and ensure their contributors are supported as they create the tools that build the Internet. -In this white paper, we distinguish participants through their contributions. -Some may contribute code or verify contributed code. -Others may provide economic value to support developers and their reputation. - -## Package Maintainers - -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 a non-fungible token (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. - -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. - -[^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 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. - -## Package Supporters and Sponsors - -In Web 2.0 and web3, package supporters have often been called “sponsors.” They are organizations or package users who use open-source software to build their commercial products, philanthropists looking to support the ecosystem, or entrepreneurs looking to fund teams to develop components of a larger system. - -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. - -## 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. - -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. - -[^14]: See: @semver - -# Protocol Overview - -The design of a protocol to reward open-source contributions is mired with challenges. -Open-source software is by definition open to all and can, as a result, be subjected to misattribution, appropriation, or malicious tampering. -However, the open-source community has consistently demonstrated its willingness to highlight good actors and expose bad actors. -Historically, the energy spent reviewing and commenting on other developers’ contributions has been strictly voluntary, despite how time-consuming and crucial reporting and defending findings may be. - -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 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. - -[^15]: Source: @npmjsLodash -[^16]: Source: @npmjsChalk -[^17]: Source: @npmjsLogFourjs - -## Package Submission - -The submission of a package release requires multiple transactions to occur atomically. -Specifically, the package maintainer must: - -* Register the package (and its semantic version) with the decentralized registry. -* Upload the package into the decentralized storage system for resilience, censorship resistance, and ease of distribution. -* Contribute to the package’s reputation and trustworthiness by *steeping* tea tokens. - -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. - -### Dependencies Analysis - -Package dependencies can run deep, as each package often has both dependents and dependencies. -To provide a simple methodology that rewards all developers who have contributed to open-source software while keeping the creation of the dependencies tree quick and computationally efficient, we propose to verify only first-level dependencies upon submission of a package. - -This design is driven by the hypothesis that each dependency is itself a package that was independently submitted to the tea tree. -In doing so, each of its dependencies can be mapped, and if its dependencies have dependencies themselves, those will be mapped at the time the dependency package is submitted. - -![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). - -![Steeping rewards distribution across dependencies.](img/figure-2.svg){#fig:steeping-rewards} - - -Versioning and conflicting dependencies are significant challenges, and troubleshooting them can turn into massive time drains. -To address this, we propose each package be subject to a comprehensive dependency scan upon submission so we can ensure that the package complies with the following rules for semantic version ranges. - -* Packages may only constrain their dependencies to a major version, though the start of the range can be any valid semantic version (e.g., >=5.2.1 <6). -* If a dependency is upgraded to a more recent major version, tea may require that the package’s major version be increased. -* 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 transgressed, 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 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. - -[^18]: Source: @arxiv - -## Package Review by Third Parties - -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. - -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: - -* 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. - -The completion of a negative review that includes one or more critical vulnerabilities will require the tea tasters first to contact the package maintainer using a messaging protocol to notify them of the vulnerability and allow them to address the issue in a timely fashion. -Upon expiry of the governance-defined period allocated to the package maintainer to address their vulnerability or as the corrected package becomes available, the same messaging protocol will be used to notify all users and testers of this package (including dependents) that a vulnerability has been identified, -and hopefully addressed, so they know to update their application or dependencies. -To disincentivize wasting developers’ time, communication between the tea tasters and package maintainers will require the tea tasters to steep tea tokens. - -Upon completing both operations, the tea tasters will receive an NFT as evidence of their work on the specific package and package version. -The accumulation of NFTs combined with the steeping ratio of each of the packages reviewed and information extracted from external systems will inform a tea taster’s reputation. -As their reputation reaches key milestones, tea tasters may earn access to elevated parts of the protocol or accelerated rewards, as decided by the tea governance. - -## 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 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. - -Any negative review which outlines a flaw such as a zero-day vulnerability or the use of an outdated dependency and remains open past a grace period defined by governance should be considered a failure on the part of the package maintainer. -They have not completed the task they were entrusted with and rewarded for. -The same can be said for package supporters and sponsors who staked their reputation on the work of delinquent package maintainers and received rewards for it, but failed to identify the lack of maintenance or elected to continue to support the package regardless. - -As packages gain in popularity and usage, with more applications and potentially mission-critical systems depending on them, we must incentivize developers to discreetly report flaws to the package maintainer and package maintainers to address such flaws before they can be exploited. -Consequently, we propose that any outdated or corrupted package which is subject to one or more evidenced negative reviews and remains in such state past the governance-defined grace period see a portion of its steeped tokens be slashed regardless of their origin (package maintainer, package supporters, and sponsors or prior tea tasters), -while another portion is sent to the tea tasters who submitted the negative reviews. -Distribution to all tea tasters could be based on the age of their review and the number of tea tokens they steeped for their review. - -## Maintainer NFT - -Upon successful submission of a package, the package maintainer will receive an 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. - -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. - -# tea Token - -## Securing the Network - -While many blockchains may appear as effective and secure infrastructure solutions to support tea’s objectives, we believe that careful consideration must be given to the technology stack upon which the tea system is built. - -Scalability, cost-effectiveness, ESG, and third-party extensibility are important design considerations that a tea-sovereign proof-of-stake system could better serve. -In proof-of-stake, node operators and network participants stake economic value in the form of the chain’s native token to increase the system’s security. -Node operators and network participants receive rewards for the successful production of blocks that comply with the rules of the network and include accurate transaction information. -Inactivity (aka node down) or malicious/incorrect activity are penalized by destroying a fraction of the staked tokens through slashing. - -A proof-of-stake system powered by the tea token will allow tea token holders to contribute to the system’s security by *staking* tea and support open-source developers by *steeping* tea. -We're fully aware economic factors may prevent some developers from staking or steeping tea; as such, staking and steeping will be available for as little as a leaf, the smallest denomination of tea representing one one-hundred-millionth ($10^{-8}$) of a tea. - -Both applications of the tea token serve vital functions in the support and growth of the open-source ecosystem. -Staking tea will ensure that the tea system continues to operate securely, so all network participants can submit and access packages to review them, integrate them into their application, etc. -In contrast, the steeping of tea will support tea’s goal of providing tools for all network participants to support and use packages that meet quality and dependability requirements, as formulated by the tea community through their support and dissent of each package. -Care will be taken when defining and implementing staking and steeping parameters so one does not become parasitic on the other. - -## Incentives and Penalties - -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’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 $\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. - -Let $\gamma = \gamma(\psi)$ be the annual staking interest rate distributed to all node operators and network participants who stake tea tokens to secure the network. -In other words, $\gamma(\psi)$ corresponds to the staking reward received over a year by a community member that stakes tea tokens for the entire year. - -Let $\delta$ be the annual inflation directed at the network treasury. -$\delta$ may vary as external factors affect the token supply. - -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. - -The annual inflation $I$ will be equivalent to $(\tau + \gamma + \delta)$ and calculated as follows: - -$$ -I = \frac{\textrm{token supply at the end of the year} - \textrm{token supply at the beginning of the year}}{\textrm{token supply at the beginning of the year}} = (\tau + \gamma + \delta) -$$ - -The contribution to inflation of $\tau_{\textsc{all}}$ (incentive distributed to all package steepers) and $\gamma_{\textsc{all}}$ (incentive distributed across all contributors to the network security) should be weighed to ensure that the system incentivizes the optimal steeping/staking ratio. - -As we focus on the incentives distributed across all package steepers, we determine that -$\tau_{\textsc{all}}$ -is a function of the steeping ratio $\chi$ and therefore -$\tau_{\textsc{all}}(\chi) = \chi \cdot \tau(\chi)$. -From our previous analysis, we can see that -$\tau_{\textsc{all}}(\chi_{ideal}) = \chi_{ideal} \cdot \tau_{ideal}$. -Since the goal is to reach a state where -$\chi = \chi_{ideal}$ -, rewards -$\tau_{ideal}(\chi)$ -should be maximal at that value. - -Let $\tau_{ideal} = \tau(\chi_{ideal})$ -be the reward rate delivered by the network at the ideal scenario where -$\chi = \chi_{ideal}$. - -Let $\tau_{0}$ be the limit of $\tau_{\textsc{all}}(\chi)$ as $\chi$ goes to zero when no members of the tea community steep any packages. -The value of $\tau_{0}$ should be close to zero but not zero to incentivize early adopters. -As suggested by the web3 Foundation’s research, we propose that: - -* the inflation function grows linearly between $\chi = 0$ and $\chi = \chi_{ideal}$, and -* it decay exponentially between $\chi = \chi_{ideal}$ and $\chi = 1$. - -We chose a similar exponential decrease for $\tau_{\textsc{all}}(\chi)$ because it implies an exponential decrease of $\tau(\chi)$, and we want rewards to fall sharply beyond $\chi_{ideal}$ to prevent a single package from receiving all the rewards. - -The decay is defined so that the inflation rate decreases by at most 50% when $\chi$ shifts $d$ units to the right of $\chi_{ideal}$ – i.e. -$\tau_{\textsc{all}}(\chi_{ideal} + d) \geq \tau_{\textsc{all}} \cdot 0.5$. - -We propose the following interest rate and inflation rate functions, which depend on the parameters $\chi_{ideal}$, $\tau_{ideal}$, $\tau_{0}$ and $d$. - -\begin{align*} -&\tau_{\textsc{all}}(\chi) = \tau_{0} + (\tau_{\textsc{all}}(\chi_{ideal}) - \tau_{0})\frac{\chi}{\chi_{ideal}}\enspace\textrm{for}\;0 < \chi \leq \chi_{ideal} \\ -&\tau_{\textsc{all}}(\chi) = \tau_{0} + (\tau_{\textsc{all}}(\chi_{ideal}) - \tau_{0}) \cdot 2^{(\chi_{ideal}-\chi)/d}\enspace\textrm{for}\;\chi_{ideal} < \chi \leq 1 -\end{align*} - -Just as good actors need to be rewarded; bad actors need to be identified and penalized. -Open-source software provides many opportunities for bad actors to create pain points and reputational risks for an entire community of developers. -From the misappropriation of work to the alteration and redistribution of software packages, or the injection of nefarious code, the war between good and bad actors goes on, often with well-funded bad actors who see the contamination of open-source packages as an opportunity to benefit financially. -The downside has been relatively minimal, with packages potentially banned from digital shelves or subjected to a poor reputation. - -We propose introducing a slashing mechanism to establish a more material downside that directly affects bad actors’ economic value. -As tea tasters evaluate and analyze the code in newly submitted packages, we suggest tea tasters receive the tools and incentives to pinpoint and highlight nefarious code so package users can be made aware of the risks, and package maintainers, package supporters, and sponsors are penalized for submitting or supporting nefarious code. -To that extent, for all evidenced negative reviews performed per the network rules and which have been addressed by the package maintainer within the governance-defined period, the package maintainer should not incur any penalty contrary to the package supporters and sponsors or the tea tasters who provided a positive review of the package in question. -For negative reviews performed per the network rules and that the package maintainer has not addressed within the governance-defined period, a fraction of the tokens steeped by the package maintainer, the package supporters and sponsors, and previous tea tasters will be slashed. -Another fraction will be locked into an insurance pool controlled by the tea governance. -The tea governance will establish policies and rules in close collaboration with the community to distribute the pool’s contents to those affected by vulnerabilities. -The protocol will distribute a third fraction of the steeped tokens across all tea tasters who contributed to the negative review and steeped against the package, based on the number of tea tokens they steeped “against” the package and how long their tokens have steeped. -In other words, the sooner one or more tea tasters identify and report the flaw according to the rules of the network, the higher the reward they will get for supporting safe and productive open-source development. - -To prevent community members from randomly voting “against” highly steeped packages hoping to receive the majority of any penalty, all tea tokens steeped “against” will not be rewarded with inflation and may be subject to a decay mechanism, thus reducing their value over time. - -[^19]: Source: @web3 - - -# Governance - -Governance is critical to the development, sustainability, and adoption of any distributed system. - -We propose that tea includes on-chain governance where all tea token holders can suggest and vote on changes to critical parameters weighted by token ownership and reputation. -These parameters could include inflation, transaction fees, staking rewards, steeping rewards, or optimum steeping ratio. -This functionality will ensure that critical parameters can evolve and be optimized over time by members of the tea community. -We anticipate governance will launch with a simple structure and progressively expand as the tea system matures, facilitating adoption and ensuring progressive decentralization. - -Some system parameters may not be subject to governance or support high-frequency changes to reduce the attack surface represented by governance. -A progressive transition of parameters to open, decentralized governance will ensure the stability and predictability of the system. - - -# Third-Party Extensibility - -As we build the initial tools to ignite the long-overdue support of the open-source communities, we believe part of our mission is to ensure that third parties can extend the overall toolset. -In addition to providing the infrastructure for developers to build extensions to the protocol, including new ways to innovate and further the support of open-source developers, our plans include the potential for other package managers to contribute to the protocol. -The dreams and efforts of open-source developers have built the innovation that supports our everyday life. -We look forward to discovering the new uses and extensions for tea proposed by the tea community. - - -# Future Work and Potential Community Efforts - -As the tea system matures, we foresee the community deciding and contributing to alterations and extensions of the tea system through governance. -Below are some ideas that we believe may inspire some. - -## 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. - -## Royalties on Package Transfer - -We recognize that package maintainers may decide to transfer their steeping rewards stream to one or more developers. -The governance of such transfer must remain the decision of the package maintainer and their partners, with no interference from tea. -Tools will need to be provided for such transfer to be total or partial (perhaps through only a portion of the steeping rewards being redirected to one or more developers, while the remaining rewards continue to flow to the original package maintainer) -and for the steeping rewards to flow through a single account controlled by a single network participant, multiple network participants, or automatically distributed across multiple accounts using static or dynamic ratios. - -## Rewards Distribution Across Multiple Maintainers - -The maintenance of a package can rely on the work of one more team of developers. -Before steeping rewards start to flow, teams should consider automating the distribution of steeping rewards amongst themselves. -How the distribution occurs must be decided by the maintainers themselves, as they are in the best position to evaluate who contributed and how they should be rewarded. - -To accomplish that, each team (or teams) could set up their own decentralized autonomous organization (DAO) and either automate the distribution of rewards or deploy more complex systems to determine the adequate rewards distribution based on external factors such as a vote from all DAO members, -or time-based distributions based on continuous contribution, successful completion of bounties, etc. - -## Handling Package “Forks” - -We believe that forks are essential and largely under-utilized. -Forks can be an effective tool for developing packages that compete in functionality, performance, security, and even attention. -As useful as they may be, forks must recognize the original efforts. -Through future work or potential contributions, the tea community may enhance the system to require forks to be declared, perhaps even detected when a package is submitted. -Undeclared forks revealed by tea tasters may result in a portion of the steeped tokens being slashed, transferred to the original package maintainer, and sent to the tea tasters who revealed the fork. - -## Runtime vs. Build Dependencies - -tea may not distinguish build dependencies from runtime dependencies when distributing steeping rewards at launch. -However, provided the tea community feels strongly about making such a distinction, the tea community may propose enhancements to the steeping rewards distribution algorithm to account for the criticality of each dependency and their contribution to the value of the packages that depend upon them. -These proposals would be voted upon and implemented based on the community’s decision. - -## Usage-based Remuneration - -As more applications are built using packages registered with tea, the community may augment the reward algorithm so that allocation may be influenced by external attested datasets such as usage. -This update to the rewards mechanism could allow for a higher allocation of tea token rewards to flow towards packages with the highest usage while still respecting the constraints of the steeping ratio described in the tea token section. -Package maintainers could use a similar approach to distribute steeping rewards across their dependencies based on the transparent logic of their choice. -Note that all information used to affect the distribution of rewards across packages and dependencies in the tea system will need to be provably reliable. - - -# Acknowledgments - -This white paper would not exist without the support and dedication of many teaophiles. -The authors would like to acknowledge Josh Kruger, Jadid Khan, and Jacob Heider for their contribution to the tokenomics and the many discreet individuals who volunteered their time to provide feedback on the contents of this document. - -$\parskip=0pt plus 1pt$ - -# Glossary of Terms - -| Term | Definition | -|------|------------| -| 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. | -| 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. | - - -# References