Showing preview only (369K chars total). Download the full file or copy to clipboard to get everything.
Repository: teaxyz/white-paper
Branch: main
Commit: eee77661fc07
Files: 19
Total size: 357.6 KB
Directory structure:
gitextract_8v2qfkg5/
├── .github/
│ ├── mk-pantry-accessible.sh
│ └── workflows/
│ ├── cd.yml
│ ├── ci.yml
│ ├── make.yml
│ └── release.yml
├── .gitignore
├── .markdownlint.json
├── Makefile
├── README.md
├── SUMMARY.md
├── i18n/
│ ├── es/
│ │ ├── metadata.yml
│ │ └── white-paper.md
│ ├── pt-br/
│ │ ├── metadata.yml
│ │ └── white-paper.md
│ └── vi/
│ ├── metadata.yml
│ └── white-paper.md
├── metadata.yml
├── tea.csl
└── white-paper.md
================================================
FILE CONTENTS
================================================
================================================
FILE: .github/mk-pantry-accessible.sh
================================================
#!/bin/sh
git config --global url."https://teaxyz:$1@github.com/teaxyz/pantry".insteadOf "https://github.com/teaxyz/pantry"
================================================
FILE: .github/workflows/cd.yml
================================================
name: CD
on:
push:
branches: [main]
paths: ['i18n/**']
env:
TEA_SECRET: ${{ secrets.TEA_SECRET }}
jobs:
cd:
uses: ./.github/workflows/make.yml
with:
upload: true
secrets: inherit
================================================
FILE: .github/workflows/ci.yml
================================================
name: CI
on:
pull_request:
paths:
- white-paper.md
- metadata.yml
- 'i18n/**'
- 'img/**'
- .github/workflows/ci.yml
- Makefile
concurrency:
group: ${{ github.ref }}
cancel-in-progress: true
jobs:
compile:
uses: ./.github/workflows/make.yml
secrets: inherit
================================================
FILE: .github/workflows/make.yml
================================================
name: make
on:
workflow_call:
inputs:
release:
default: false
required: false
type: boolean
upload:
default: false
required: false
type: boolean
env:
TEA_SECRET: ${{ secrets.TEA_SECRET }}
jobs:
make:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: | # Use on-box make until tea/pantry revlock is resolved
sudo apt-get update
sudo apt-get install \
texlive-latex-base \
texlive-fonts-recommended \
texlive-fonts-extra \
texlive \
texlive-latex-extra \
texlive-xetex
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
brew install \
pandoc \
pandoc-crossref \
librsvg
#FIXME: Can't pass secrets to remote-branch CI, so this is until teaxyz/pantry is public
sed -ne 's/^# tea\/white-paper \([0-9]*\.[0-9]*\.[0-9]*\)/VERSION=\1/p' README.md >> $GITHUB_ENV
- run: | # install noto fonts for translated pdfs
sudo apt-get install fonts-noto fonts-noto-cjk
# - run: .github/mk-pantry-accessible.sh ${{ secrets.TEMP_JACOBS_GITHUB_PAT }}
# - uses: teaxyz/setup@v0
- name: Set Version - Release
if: ${{ inputs.release }}
run: echo "- \fancyfoot[L]{$VERSION}" >> metadata.yml
- name: Set Version - CI/CD
if: ${{ !inputs.release }}
run: |
date=$(date '+%Y%m%d')
echo "- \fancyfoot[L]{$VERSION+$date}" >> metadata.yml
# - run: tea make
- run: | # Use on-box make until tea/pantry revlock is resolved
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
make
- uses: actions/upload-artifact@v3
with:
name: tea.white-paper
path: |
tea.white-paper.pdf
tea.white-paper_??.pdf
# Following steps only run for upload: true
- name: AWS credentials
if: ${{ inputs.upload }}
uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-east-1
- name: Bundle translations
if: ${{ inputs.upload }}
run: |
mkdir white-papers
cp tea.white-paper_??.pdf white-papers/
- name: Bundle release
if: ${{ inputs.upload && inputs.release }}
run: cp tea.white-paper.pdf white-papers/
- name: Upload to S3
if: ${{ inputs.upload }}
run: |
aws s3 sync \
./white-papers s3://www.tea.xyz/ \
--metadata-directive REPLACE \
--cache-control no-cache,must-revalidate
- name: Invalidate cache
if: ${{ inputs.upload }}
run: |
aws cloudfront create-invalidation \
--distribution-id ${{ secrets.AWS_CF_DISTRIBUTION_ID }} \
--paths / /tea.white-paper*.pdf
================================================
FILE: .github/workflows/release.yml
================================================
name: Release
permissions:
contents: write
on:
push:
branches: [main]
paths: [README.md]
env:
TEA_SECRET: ${{ secrets.TEA_SECRET }}
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: .github/mk-pantry-accessible.sh ${{ secrets.TEMP_JACOBS_GITHUB_PAT }}
- uses: teaxyz/setup@v0
- id: rev-parse
name: did we already publish this version?
run: |
# fetch tags since actions/checkout is a shallow checkout
git fetch --prune --unshallow --tags
if git show-ref --tags v$VERSION --quiet; then
echo "::set-output name=result::cancel"
fi
- uses: andymckay/cancel-action@0.2
if: ${{ steps.rev-parse.outputs.result == 'cancel' }}
make:
needs: [check]
uses: ./.github/workflows/make.yml
with:
release: true
upload: true
secrets: inherit
release:
runs-on: ubuntu-latest
needs: [make]
steps:
- name: Tag Release
uses: rickstaa/action-create-tag@v1
with:
tag: ${{ env.VERSION }}
- name: Release
uses: softprops/action-gh-release@v1
with:
tag_name: ${{ env.VERSION }}
files: |
tea.white-paper.pdf
tea.white-paper_??.pdf
================================================
FILE: .gitignore
================================================
*.pdf
================================================
FILE: .markdownlint.json
================================================
{
"MD012": false,
"MD013": false,
"MD025": false
}
================================================
FILE: Makefile
================================================
.PHONY: all
.PHONY: i18n
.PHONY: clean
translations := $(patsubst i18n/%/white-paper.md,tea.white-paper_%.pdf,$(wildcard i18n/*/white-paper.md))
all: tea.white-paper.pdf $(translations)
tea.white-paper.pdf: white-paper.md metadata.yml tea.csl img/*
pandoc \
--number-sections \
--output $@ \
--metadata-file metadata.yml \
--filter pandoc-crossref \
--csl=tea.csl \
--citeproc \
$<
i18n: $(translations)
tea.white-paper_%.pdf: i18n/%/white-paper.md i18n/%/metadata.yml tea.csl img/*
pandoc \
--number-sections \
--output $@ \
--metadata-file i18n/$*/metadata.yml \
--filter pandoc-crossref \
--csl=tea.csl \
--citeproc \
--pdf-engine=xelatex \
--variable mainfont="Noto Serif" \
$<
clean:
rm -f tea.white-paper*.pdf
================================================
FILE: README.md
================================================
# README
The tea white paper is a [semantically versioned](https://semver.org), [Markdown](https://daringfireball.net/projects/markdown/) document. New releases are deployed to Gitbook.
## Contributing
If you have general feedback, please open a [discussion](discussions/) thread.
================================================
FILE: SUMMARY.md
================================================
# Table of contents
* [README](README.md)
* [white-paper](white-paper.md)
================================================
FILE: i18n/es/metadata.yml
================================================
title: Un Protocolo Descentralizado para Remunerar el Ecosistema de Código Abierto
abstract: >
Crear un registro público, abierto y estable para todo el software de código abierto
permitirá a los proyectos publicar lanzamientos de forma independiente en lugar
de depender de terceros que ensamblan estos datos irregulares en cientos de
sistemas separados (y duplicados). Los mantenedores de paquetes publicarán
sus lanzamientos en un registro descentralizado impulsado por una blockchain
tolerante a fallos bizantinos para eliminar fuentes únicas de fallo, proporcionar
lanzamientos inmutables y permitir que las comunidades gobiernen sus regiones
del ecosistema de código abierto, independientemente de agendas externas.
tea incentiva el mantenimiento de código abierto permitiendo a los participantes
de la red apostar valor contra los paquetes de los que dependen y quieren asegurar.
El graph del protocolo tea proporciona registro de paquetes inmutable, requisitos
de dependencia, autenticidad de paquetes y oráculos de uso para informar al algoritmo
de remuneración de tea. La inflación sistemática se distribuye a todos los paquetes
basándose en ese algoritmo. Si se encuentran problemas de seguridad o desarrollo,
los desarrolladores pueden hacer reclamaciones respaldadas por evidencia contra
el paquete, y pueden ocurrir penalizaciones. Los miembros de la comunidad de código
abierto pueden revisar paquetes por problemas de calidad, y el protocolo puede
responder a estas revisiones realizando eventos de penalización proporcionales.
author:
- Max Howell
- Timothy Lewis
- Thomas Borrel
references:
- id: sources
url: https://github.com/teaxyz/white-paper
- id: cc
url: https://creativecommons.org/licenses/by-sa/4.0/
- id: nist
url: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- id: reuters
url: https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA
- id: twitter
url: https://twitter.com/yazicivo/status/1469349956880408583
- id: w3
url: https://www.w3.org/TR/did-core/
- id: theregister
url: https://www.theregister.com/2016/03/23/npm_left_pad_chaos/
- id: fossa
url: https://fossa.com/blog/npm-packages-colors-faker-corrupted/
- id: lunasec
url: https://www.lunasec.io/docs/blog/node-ipc-protestware/
- id: github
url: https://github.com/dominictarr/event-stream/issues/116
- id: zdnet
url: https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/
- id: threatpost
url: https://threatpost.com/backdoor-found-in-utility-for-linux/147581/
- id: fbi
url: https://www.fbi.gov/news/stories/phantom-secure-takedown-031618
- id: europol
url: https://www.europol.europa.eu/media-press/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication
- id: medium
url: https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502
- id: semver
url: https://semver.org/
- id: npmjsCrossenv
url: https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html
- id: npmjsLodash
url: https://www.npmjs.com/package/lodash
- id: npmjsChalk
url: https://www.npmjs.com/package/chalk
- id: npmjsLogFourjs
url: https://www.npmjs.com/package/log4js/
- id: arxiv
url: https://arxiv.org/abs/1207.2617/
- id: web3
url: https://research.web3.foundation/en/latest/polkadot/overview/2-token-economics.html
header-includes:
- \usepackage{fancyhdr,ragged2e}
- \lhead{\parbox[t]{0.5\textwidth}{\RaggedRight\rightmark\strut}}
- \rhead{\parbox[t]{0.5\textwidth}{\RaggedLeft\leftmark\strut}}
- \setlength{\headheight}{5\baselineskip}
- \pagestyle{fancy}
- \fancyfoot[LE,RO]{© 2022 tea.inc.}
- \fancyfoot[L]{v2.1.0+es} # expand these variables!
lang: es # https://pandoc.org/MANUAL.html#language-variables
dir: ltr # language direction; ltr:left-to-right or rtl:right-to-left
translator:
- boredray
================================================
FILE: i18n/es/white-paper.md
================================================
---
descripción: Versión 2.1.0
---
# white-paper
## Un Protocolo Descentralizado para que Desarrolladores de Código Abierto Capturen el Valor que Crean
* Max Howell
* Thomas Borrel
* Timothy Lewis
* Troy Wong
## Resumen
Un sistema en el que los desarrolladores de código abierto puedan recibir recompensas proporcionales a sus contribuciones mejoraría la sostenibilidad e integridad de la cadena de suministro de software. Un protocolo descentralizado, asegurado por la reputación y los incentivos, podría lograr esto facilitando la acumulación de valor de vuelta a los desarrolladores que mantienen bases de código abierto como una utilidad pública, promoviendo así la innovación futura y el crecimiento dentro del ecosistema de código abierto. Los mantenedores de paquetes registrarán sus proyectos en un registro impulsado por una blockchain tolerante a faltas bizantinas. El algoritmo único de “Prueba de Contribución” del Protocolo tea determinará la contribución e impacto de cada proyecto en la utilidad y salud del sistema. Los proyectos registrados recibirán recompensas del Protocolo tea proporcionales a su contribución, estarán asegurados mediante staking, se beneficiarán de un sistema de reputación que abarca proyectos y colaboradores, y tendrán la opción de permitir que las comunidades gobiernen sus regiones del ecosistema de código abierto, independientemente de agendas externas. El Protocolo tea incentivará el mantenimiento del código abierto permitiendo a los participantes de la red que registraron sus proyectos y cumplen con las reglas de la red recibir recompensas y contribuir a su reputación y la de sus proyectos. Si se encuentran problemas de seguridad o desarrollo, los desarrolladores pueden hacer reclamos respaldados por evidencia contra el paquete, y puede ocurrir un slashing. Los miembros de la comunidad de código abierto pueden revisar paquetes por problemas de calidad, y el protocolo puede responder a estas revisiones realizando eventos de slashing proporcionales.
## Descargo de Responsabilidad
La información presentada en este documento técnico es de naturaleza preliminar. En consecuencia, ni los autores ni ninguna de sus respectivas afiliadas asumen responsabilidad alguna de que la información aquí presentada sea definitiva o correcta y cada uno de los anteriores rechaza, en la medida máxima permitida por la ley aplicable, toda responsabilidad, ya sea que surja en agravio, contrato u otra forma, con respecto a este documento técnico. Ni este documento técnico ni nada de lo que contiene formarán la base de o serán considerados en conexión con, o actuarán como un incentivo para entrar en cualquier contrato o compromiso de cualquier tipo.
Nada en este documento técnico constituye una oferta de venta o una solicitud de compra de los tokens aquí discutidos. En cualquier caso, si este documento técnico fuera considerado como tal oferta o solicitud, ninguna oferta o solicitud está intencionada o transmitida por este documento técnico en ninguna jurisdicción donde esto sea ilegal, donde dicha oferta o solicitud requiriera licencia o registro, o donde tal oferta o solicitud esté sujeta a restricciones. En particular, cualquier token aquí discutido no ha sido, y, a la fecha de emisión de este documento técnico, no se pretende que sea, registrado bajo las leyes de valores o leyes similares de ninguna jurisdicción, ya sea que dicha jurisdicción considere tales tokens como un valor o instrumento similar y no se puede ofrecer o vender en ninguna jurisdicción donde hacerlo constituiría una violación de las leyes relevantes de dicha jurisdicción. No compre ningún token a menos que esté preparado para perder el precio total de la compra. Es una compra de alto riesgo y es poco probable que esté protegido si algo sale mal.
## Licencia
Este documento está disponible bajo la licencia [Creative Commons Attribution-ShareAlike 4.0 International license](https://creativecommons.org/licenses/by-sa/4.0/).
## Introducción
El Internet moderno está predominantemente compuesto por proyectos de código abierto y ha sido así desde su inicio. Los proyectos de código abierto se desarrollan y mantienen a través de la colaboración entre comunidades de desarrolladores globales, y sus bases de código están disponibles para que cualquiera las utilice como un bien público. En los últimos 80 años (se cree generalmente que el primer ejemplo de software libre y de código abierto se lanzó en 1953), el software de código abierto ha evolucionado desde ser el producto de aficionados tecnológicos de nicho hasta la infraestructura sobre la cual se ha construido toda innovación. A pesar de la importancia del software de código abierto, los desarrolladores que crean y mantienen la base de código como un servicio público no reciben recompensas fungibles por su inmensa contribución como innovadores y mantenedores.
El software empresarial, que se ha convertido en una industria de miles de millones de dólares, se construye sobre la base establecida por el código abierto. Sin embargo, casi no hay acumulación de valor de vuelta a los individuos que mantienen desinteresadamente sus cimientos. Y aunque se han hecho fortunas a partir de él, el software de código abierto se crea y mantiene principalmente como un servicio público sin medios viables para que los desarrolladores capturen el valor que crean.
Creemos que el potencial del Internet moderno ha sido limitado al depender de un pequeño porcentaje de los ingenieros del mundo para mantener el software de código abierto puramente por altruismo. El código abierto es un trabajo de amor a menudo obstaculizado por la falta de incentivos significativos para los mantenedores principales. Los desarrolladores de código abierto deben elegir entre un trabajo diario que proporciona salarios dignos o mantener la base misma del software empresarial. La falta de incentivos resulta en que proyectos realmente valiosos nunca alcancen su potencial mientras que otros sufren de problemas de seguridad debido a la falta de mantenimiento a lo largo del ciclo de vida del software. Para desbloquear todo el potencial del código abierto, necesitamos un método universal para evaluar el "valor justo" de los proyectos de código abierto, permitiendo a los desarrolladores de código abierto capturar el valor que crean facilitando la entrada de capital a la comunidad de código abierto, todo sin alterar los principios fundamentales de cómo se desarrolla y utiliza el código abierto.
Las empresas a menudo envuelven modelos de negocio alrededor del código abierto, generando ingresos directamente del trabajo de los desarrolladores benevolentes y también dependiendo de ellos para corregir errores a medida que ocurren. Las bases de código de código abierto ofrecen funcionalidad central plug-and-play para las empresas; sin embargo, las vulnerabilidades de software pueden representar un riesgo inmenso para las aplicaciones construidas sobre código abierto. Un gran ejemplo es un incidente reciente que involucra una vulnerabilidad crítica de seguridad en Log4j, un paquete de la [Apache Software Foundation](https://www.apache.org/) que se encontró en muchos software y servicios comerciales empleados por empresas y gobiernos. En noviembre de 2021, un investigador de seguridad que trabajaba para [Alibaba Group Holding Ltd.](https://www.alibabagroup.com/) reported vulnerability [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228), que recibió la puntuación base más alta posible de la Apache Software Foundation. Amit Yoran, Director Ejecutivo de [Tenable](https://www.tenable.com/) y director fundador del Equipo de Preparación para Emergencias Informáticas de los Estados Unidos (US-CERT), describió esta vulnerabilidad como “["la vulnerabilidad más crítica y grande de la última década"](https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA)”. Se desató el pánico y los pocos voluntarios que mantenían este paquete se vieron públicamente criticados por el fallo. Tras abordar la indignación con un humilde llamado a la justicia, los sistemas se parchearon. Las empresas y los gobiernos eventualmente se dieron cuenta de que Log4j, un paquete utilizado por una amplia gama de sistemas críticos durante dos décadas, fue mantenido por unos pocos voluntarios no remunerados, los mismos héroes anónimos que entraron en acción a pesar de [los abusos de la industria](https://twitter.com/yazicivo/status/1469349956880408583) y trabajaron incansablemente para abordar la vulnerabilidad.
Lamentablemente, Log4j está lejos de ser el único ejemplo. core-js se descarga 30 millones de veces por semana como la base de cada aplicación de Node.js, pero también está apenas financiado, lo que podría obligar a su mantenedor principal [a alejarse del proyecto o incluso cambiar la licencia a código cerrado](https://www.thestack.technology/core-js-maintainer-denis-pusharev-license-broke-angry/). Recientemente, varios desarrolladores principales de bitcoin renunciaron, citando, entre otras razones, la falta de compensación financiera por su decisión.
<figure><img src=".gitbook/assets/xkcd-dependency (1).png" alt=""><figcaption><p>Figura 1 - Dependencia - Fuente:<a href="https://xkcd.com/2347/">https://xkcd.com/2347/</a></p></figcaption></figure>
Ha habido múltiples intentos de proporcionar estructuras de incentivos, que típicamente involucran sistemas de patrocinio y recompensas. El patrocinio hace posible que los consumidores de código abierto donen a los proyectos que prefieren. Sin embargo, imagina el código abierto como una torre de ladrillos donde las capas inferiores son largamente olvidadas, pero aún mantenidas por ingenieros dedicados y en las que confían aún más desarrolladores. Solo los proyectos en la parte superior de la torre son típicamente conocidos y reciben patrocinio. Esta selección sesgada lleva a que los ladrillos esenciales que sostienen la torre no atraigan donaciones, mientras que los favoritos reciben más de lo que necesitan. Las recompensas permiten a los consumidores de proyectos proponer pagos para que los desarrolladores construyan características específicas, recompensando así solo a los proyectos por hacer cosas que pueden no estar en su mejor interés. Y, nuevamente, solo recompensando a los favoritos.
En tea, hemos visto demasiados proyectos de código abierto sufrir por estos intentos fallidos de apoyar a la comunidad de código abierto y hemos hecho de nuestra misión mejorar la sostenibilidad e integridad de la cadena de suministro de software permitiendo a los desarrolladores de código abierto capturar el valor que crean.
En este documento, proponemos tea — un sistema descentralizado para
1. calcular y asignar una “[Prueba de Contribución](white-paper.md#proof-of-contribution)” cada proyecto de código abierto en relación con todo el ecosistema,
2. asegurando que los proyectos de software de código abierto estén bien mantenidos,
3. empoderando a los desarrolladores de código abierto con recompensas equitativas proporcionales a sus contribuciones en todo el ecosistema, logrado a través de la implementación del algoritmo de incentivos de tea en cada entrada del registro de tea, e
4. incentivando a los participantes de la red a seguir prácticas de divulgación responsable de vulnerabilidades y errores.
## Componentes
Un desarrollador de software que construye una aplicación necesita cuatro cosas: un navegador, una terminal, un editor y un gestor de paquetes. De estos cuatro, el gestor de paquetes es lo que controla las herramientas y marcos que un desarrollador necesita para construir su producto. Esta capa es donde vemos el potencial para cambiar cómo se asegura y se recompensa el código abierto.
### El Gestor de Paquetes
El gestor de paquetes sabe qué software de código abierto necesita un paquete o aplicación para funcionar, desde la cima de la torre hasta su base. Cada proyecto, junto con cada versión empaquetada, documenta meticulosamente todos los componentes esenciales y sus correspondientes versiones.
Sabe que la cima de la torre selecciona cuidadosamente sus dependencias, y que esta selección cuidadosa continúa hacia abajo. El gestor de paquetes está ubicado de manera única en el conjunto de herramientas del desarrollador para permitir una distribución de valor automatizada y precisa basada en la contribución real y práctica.
Proponemos un registro descentralizado e inmutable diseñado para distribuir valor basado en el “Prueba de Contribución” único del Protocolo tea, un algoritmo que determina la contribución de cada proyecto y su impacto en la utilidad y salud del sistema. El valor puede entrar en el gráfico en puntos ápice, como bibliotecas esenciales, y distribuirse a las dependencias de esos paquetes y sus dependencias de manera recursiva, ya que el registro conoce todo el graph de código abierto.
Además, creemos que la información proporcionada por el Prueba de Contribución del protocolo debe estar disponible para que los desarrolladores evalúen si pueden confiar en un proyecto y su autor. Esta información puede basarse en la reputación, el reconocimiento de la comunidad, datos obtenidos de sistemas de identidad descentralizada ("[DID](https://www.w3.org/TR/did-core/)") otros gestores de paquetes o mecanismos de incentivos que potencialmente dependen de que los participantes de la red pongan valor en riesgo.
Predecimos que la combinación de herramientas, información y recompensas de tea incentivará justamente a los desarrolladores, ayudando a asegurar la cadena de suministro de software, estimulando el crecimiento del software de código abierto y fomentando la innovación.
### El Registro Descentralizado
Cada gestor de paquetes tiene su propio registro de paquetes, duplicando repetidamente los mismos metadatos. En algunos casos, este registro puede incluir [información que difiere del manifiesto del proyecto](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/), permitiendo así que actores maliciosos potencialmente inyecten código nefasto sin que el usuario lo sepa. Es hora de que exista un registro único, integral y definitivo diseñado y gobernado por las comunidades que dependen de él. Este registro descentralizado e inmutable podría proporcionar seguridad, estabilidad y prevenir intenciones malévolas.
Internet funciona con decenas de miles de componentes esenciales de código abierto. Es notable que hasta ahora, los incidentes causados por la eliminación de infraestructura esencial de código abierto hayan sido mínimos. El más famoso fue la [la eliminación de una dependencia de NPM left-pad](https://www.theregister.com/2016/03/23/npm\_left\_pad\_chaos/) en 2016, que se propagó a sistemas de integración continua y despliegue continuo, dejando a los desarrolladores en la estacada durante días. Este evento demostró que Internet en sí está basado en sistemas de desarrollo frágiles. Otros ejemplos involucraron la participación activa o intencional de los mantenedores de paquetes saboteando sus paquetes populares (ver [colors.js and faker.js](https://fossa.com/blog/npm-packages-colors-faker-corrupted/), así como [node-ipc](https://www.lunasec.io/docs/blog/node-ipc-protestware/)), o actores maliciosos buscando beneficiarse pretendiendo ayudar a mantener paquetes y corrompiéndolos para robar, por ejemplo, claves privadas de Bitcoin (Ver [event-stream](https://github.com/dominictarr/event-stream/issues/116)), o paquetes maliciosos con errores intencionales de ortografía, también conocidos como “[typosquatting](https://en.wikipedia.org/wiki/Typosquatting)”, con la esperanza de engañar a los usuarios para que los instalen, por ejemplo [crossenv vs. cross-env NPM packages](https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html).
La integridad del software necesita ser garantizada a medida que la industria avanza hacia un futuro donde los activos digitales son parte del software. No podemos continuar dejándonos vulnerables a actores maliciosos que modifican el software.
La mayoría de las herramientas que llamamos gestores de paquetes no pueden garantizar que estos paquetes incorporados en las aplicaciones y dApps sean el código de código abierto sin alterar publicado por sus autores originales. [GitHub de Microsoft ha encontrado que el 17% de las vulnerabilidades en el software fueron plantadas con fines maliciosos](https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/), con algunas permaneciendo sin ser detectadas durante períodos prolongados (Ver [Webmin 1.890](https://threatpost.com/backdoor-found-in-utility-for-linux/147581/)).
Un registro descentralizado global, complementado por un sistema de reputación y respaldado por incentivos diseñados para exponer a los actores maliciosos y recompensar a los buenos, puede proporcionar las garantías que las comunidades de desarrolladores han estado buscando para asegurar la cadena de suministro de software.
### El Sistema de Almacenamiento
Los proyectos de código abierto ofrecen una amplia gama de funcionalidades, algunas de las cuales pueden ser restringidas o no deseadas. La encriptación es un excelente ejemplo de esto. Un caso de uso crítico para la encriptación es el apoyo a la privacidad de las personas en todo el mundo. Sin embargo, la encriptación también puede ser utilizada con fines nefastos (ver [Phantom Secure](https://www.fbi.gov/news/stories/phantom-secure-takedown-031618), desmantelada por agencias de aplicación de la ley en marzo de 2018) o puede ser comprometida para apoyar actividades de las fuerzas del orden (ver [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) donde el FBI operó una plataforma de comunicación “encriptada”, AN0M, y convenció a criminales a usar sus teléfonos “encriptados” para comunicación segura).
Las amplias aplicaciones de la encriptación la han hecho un caso de uso perfecto para el software de código abierto y un gran ejemplo de que cualquier solución que almacene paquetes debe ser a prueba de manipulaciones y resistente a la censura. tea es un protocolo descentralizado que no pretende filtrar ni sancionar paquetes basados en su funcionalidad. Aunque la gobernanza de tea puede optar por eliminar paquetes maliciosos comprobados (ver la [sección de gobernanza](white-paper.md#governance) para más información), es crítico para el sistema tea conectarse con múltiples sistemas de almacenamiento, incluyendo aquellos descentralizados que demuestren que un paquete no está alterado y correctamente replicado. Los mantenedores de paquetes pueden elegir el sistema de almacenamiento más adecuado para sus necesidades para almacenar y distribuir sus paquetes de forma segura.
## Resumen del Protocolo
Diseñar un protocolo para recompensar las contribuciones de código abierto presenta desafíos formidables. El software de código abierto, al ser universalmente accesible, es susceptible a la mala atribución, apropiación y manipulación maliciosa. Sin embargo, la comunidad de código abierto ha demostrado consistentemente su voluntad de destacar a los buenos actores y exponer a los malos actores. Históricamente, la energía dedicada a revisar y comentar sobre las contribuciones de otros desarrolladores ha sido estrictamente voluntaria, a pesar de lo que consume tiempo y lo crucial que puede ser informar y defender los hallazgos.
Nuestra intención es crear un protocolo descentralizado asegurado por la reputación y los incentivos que mejoren la sostenibilidad e integridad de la cadena de suministro de software permitiendo a los desarrolladores de código abierto capturar el valor que crean de una manera sin confianza. Creemos que las recompensas adecuadas para las contribuciones de código abierto no pueden tener éxito sin un sistema de reputación y la capacidad de los miembros de la comunidad para comunicar sus hallazgos y apoyar (o disentir) un proyecto o el trabajo de un desarrollador. Además, debemos proporcionar a los desarrolladores herramientas para acceder y contribuir a este sistema de reputación. Herramientas que incluyan acceso visual y programable simple a la versión y reputación de todas las dependencias dentro de sus proyectos.
La transparencia en los tokens TEA en staking por los miembros de la comunidad para apoyar cada proyecto mejora la reputación de cada proyecto, de manera similar a cómo la cantidad de tokens que un mantenedor de paquetes pone en staking en su propio trabajo señala su compromiso con él. Estos puntos de datos combinados ayudarán a informar un sistema de reputación para todos los miembros de la comunidad y facilitarán la elección. Como el [event-stream package hack](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502) no se realizó a través del paquete en sí, sino a través de una de sus dependencias, la visibilidad en todas las capas de dependencias será vital para construir este sistema sin confianza. Sin embargo, consideraciones como los costos de computación y transacción (“gas”) necesitarán tener prioridad a medida que el sistema se diseñe y construya.
Nuestro objetivo es recompensar tanto a los desarrolladores de Web 2.0 como a los de web3. Las complejidades y especificidades de cada pila hacen que el seguimiento de instalaciones de paquetes pueda fácilmente caer víctima de uno o más actores maliciosos. Esto incluye "comprar" instalaciones para inflar artificialmente los números. Un escenario aún peor sería introducir cambios fundamentales en la naturaleza del software de código abierto creando fricciones innecesarias con claves de licencia u otros mecanismos de seguimiento de implementación. Para proporcionar la cobertura más amplia, creemos que las recompensas no deben depender de una noción simplista de seguimiento de instalaciones, sino más bien de mecanismos de incentivo que fomenten la presentación de paquetes de calidad y la denuncia de paquetes nefastos o de alto riesgo. Por último, muchos paquetes dependen de dependencias comunes. Por ejemplo, [lodash](https://www.npmjs.com/package/lodash) tiene 176,308 dependientes de código abierto, mientras que [chalk](https://www.npmjs.com/package/chalk) tiene 100,247 dependientes o [log4js](https://www.npmjs.com/package/log4js/) tiene 3,809 dependientes. A medida que se crean más paquetes utilizando las mismas dependencias, ¿cómo aseguramos que las recompensas se distribuyan de manera justa y equitativa? ¿Cómo garantizamos que las dependencias más utilizadas sean recompensadas sin dejar de lado a los paquetes y desarrolladores nuevos o emergentes? ¿Cómo aseguramos que el sistema de incentivos no termine desviando a los desarrolladores de lenguajes de nicho para centralizarlos donde los incentivos son mejores? Pero también, como desarrolladores, ¿cómo identificamos los paquetes con más dependientes para construir alternativas - versiones más ligeras, más eficientes y mejor codificadas de estos paquetes?
En tea, creemos que la falta de visibilidad e incentivos ha impedido la evolución del software de código abierto. Respaldados por los incentivos y recompensas adecuados, más desarrolladores estarán en posición de construir, mejorar y aumentar el software de código abierto para el beneficio del mundo.
### Prueba de Contribución
En este documento técnico, proponemos la "Prueba de Contribución", un novedoso mecanismo de consenso diseñado para cuantificar el impacto de todos los proyectos en todos los sistemas de código abierto.
Prueba de Contribución asigna una puntuación dinámica, denominada teaRank del proyecto, basada en la orientación de cada proyecto de código abierto dentro de, y su utilización desde, el ecosistema de código abierto más amplio a lo largo del tiempo.
Creemos que este enfoque beneficia al software fundamental alejado de la capa de aplicación (que tiende a ser la capa más visible para el público y atrae la mayor parte del interés) y extiende el mecanismo de recompensa para asegurar que todos los componentes de un proyecto, desde la cima del árbol hasta su base, sean recompensados por su contribución.
Para calcular la puntuación de cada proyecto, teaRank se basa en los fundamentos establecidos por el algoritmo [Google's PageRank](https://en.wikipedia.org/wiki/PageRank). PageRank de Google es el componente definitorio del producto de búsqueda y se basa en la estructura similar a un graph de las páginas web. PageRank, en su esencia, es un algoritmo de distribución de probabilidad que asigna puntuaciones a los nodos en un graph, representando la probabilidad de que algo que navegue al azar por el graph llegue a un nodo particular. Este algoritmo es particularmente efectivo en una estructura de datos similar a un graph, como internet, porque cuantifica el impacto de cada nodo (o página web) basado en la cantidad y calidad de los bordes (enlaces) hacia él. Este algoritmo fue modificado con el tiempo para discernir mejor la topología de la web e identificar enlaces fraudulentos entre páginas web, permitiendo mitigar varios ataques.
Dado que la estructura de graph de internet y el registro descentralizado del Protocolo tea comparten notables similitudes, PageRank inicialmente pareció ser un enfoque prometedor para el análisis. Sin embargo, tras experimentación adicional, se hizo evidente que las estrategias anti-spam de PageRank eran menos efectivas cuando se aplicaban a código abierto.
La distinción clave radica en los metadatos del software de código abierto. A diferencia de las páginas web, la mayoría de los metadatos de paquetes de código abierto, como líneas de código y mensajes de commit, son generados por el usuario y susceptibles de ser falsificados. Los gestores de paquetes son vulnerables a campañas de spam, donde actores maliciosos inundan el registro con paquetes que contienen enlaces de phishing u otro contenido dañino. Los registros de los gestores de paquetes también pueden reflejar de manera inexacta las dependencias de proyectos específicos. Este problema, conocido como “[manifest confusion](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/)” puede permitir a los actores maliciosos inyectar código nefasto o inflar artificialmente el impacto de dependencias de terceros, a menudo con fines nefastos.
La ardua tarea de identificar y abordar estos paquetes de spam generalmente recae en firmas de seguridad o individuos altruistas, ninguno de los cuales ofrece una solución escalable para combatir ataques de spam en código abierto.
Prueba de Contribución es un algoritmo específicamente diseñado para abordar la identificación y aislamiento de paquetes de spam y asegurar que solo los proyectos impactantes reciban una recompensa justa. Los detalles del algoritmo de Prueba de Contribución serán el tema de un documento técnico dedicado.
### Participantes de la Red
En este documento técnico, distinguimos a los participantes por sus contribuciones. Algunos pueden contribuir con código o verificar el código contribuido. Otros pueden apoyar a los desarrolladores y su reputación.
#### Mantenedores de Paquete
tea asume que los creadores de paquetes mantienen su trabajo. En este documento, nos referiremos a ellos como "mantenedores de paquetes".
Los mantenedores de paquetes deben asegurarse de que su software continúe entregando un valor creciente a medida que evoluciona la industria. Son pilares de las comunidades de código abierto que necesitan ser empoderados y recompensados por sus contribuciones continuas. Sin embargo, un mantenedor de paquetes puede decidir discontinuar sus esfuerzos de mantenimiento o darse cuenta de que no pueden operar al ritmo que las expectativas de los usuarios del proyecto requieren. Para garantizar la continuidad, deben tener la capacidad de transferir el control de su proyecto a otro desarrollador o grupo de desarrolladores, nombrándolos como mantenedores y otorgándoles propiedad y control sobre las recompensas existentes y futuras asociadas con el proyecto.
De manera similar, un desarrollador puede decidir asumir el papel de mantenedor de paquetes al bifurcar el proyecto existente y registrar uno nuevo que mantendrán en adelante, convirtiéndose así en mantenedores de paquetes. Una vez registrado, los proyectos cuyo teaRank exceda un umbral definido por la gobernanza comienzan a recibir recompensas del Protocolo tea a través del algoritmo de Prueba de Contribución del protocolo, en paralelo con el proyecto bifurcado legado. A medida que la comunidad de código abierto se aleja del proyecto legado en favor de su nueva iteración, el algoritmo de Prueba de Contribución disminuirá gradualmente las recompensas asignadas al proyecto legado mientras aumenta las asignadas al nuevo proyecto bifurcado.
Es esencial proporcionar a las comunidades de desarrolladores las herramientas adecuadas para determinar qué proyectos se están manteniendo y la reputación y calidad del trabajo de sus mantenedores pasados y presentes. Hemos visto con demasiada frecuencia cómo el trabajo de código abierto es manipulado y los esfuerzos de muchos arruinados por actores maliciosos. Aunque el trabajo de estos actores maliciosos generalmente se descubre y se remedia, a menudo no es hasta que se ha incurrido en daños significativos a través de pérdidas financieras o de datos. Tomemos como ejemplo el [event-stream npm package](https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502) que fue descargado más de 1.5 millones de veces por semana y en el que confiaban más de 1,500 paquetes cuando un hacker logró penetrar en el proyecto de código abierto, ganar la confianza de su autor original y modificar event-stream para que dependiera de un paquete malicioso que exfiltrara credenciales de billetera de bitcoin a un servidor de terceros. Aunque las herramientas pueden ayudar a detectar algunos de estos ataques, no siempre se pueden confiar, lo que crea una comunidad entera dependiente de la diligencia de los demás y la voluntad de compartir sus hallazgos.
Proponemos introducir incentivos a través del token TEA descrito en la sección "[token TEA](white-paper.md#tea-token)", para alentar a las comunidades de código abierto a informar sus hallazgos de manera constructiva, para que los mantenedores de paquetes puedan abordarlos antes de que sean explotados.
#### Usuarios de Paquetes y miembros de la comunidad tea
Los "usuarios de paquetes" son desarrolladores de software enfocados en resolver un problema específico. A menudo buscan en la comunidad de código abierto las herramientas que necesitan para experimentar rápidamente e iterar con poco o ningún costo, beneficiándose directamente del trabajo de los mantenedores de paquetes.
Con más de 10 millones de paquetes accesibles a través de los 30 principales gestores de paquetes, la ausencia de una atribución de valor universal a los proyectos de código abierto puede transformar la selección de paquetes seguros y eficientes para el desarrollo en un esfuerzo arriesgado y desalentador. Sin medios discernibles para atribuir y medir el valor, ¿cómo seleccionan los usuarios de paquetes de manera eficiente paquetes seguros para su desarrollo?
Creemos que el algoritmo de Prueba de Contribución del Protocolo tea, combinado con otros incentivos, puede proporcionar a los usuarios de paquetes la información que necesitan para seleccionar rápidamente y con reflexión la base de su propio proyecto.
#### Participantes del Proyecto
En Web 2.0 y web3, un subconjunto de usuarios de paquetes, a menudo llamados "patrocinadores", ha optado por apoyar a los mantenedores de paquetes a través de donaciones u otras formas de remuneración; sin embargo, esto raramente ha sido el caso.
Estos "participantes del proyecto" son organizaciones o usuarios de proyectos de código abierto que utilizan software de código abierto para construir sus productos comerciales, filántropos que buscan apoyar el ecosistema, o emprendedores que buscan financiar equipos para desarrollar componentes de un sistema más grande.
tea propone extender las comunidades de participantes de proyectos de código abierto a toda la comunidad tea, ya sean organizaciones, desarrolladores, usuarios o entusiastas de la tecnología. El objetivo de tea es implementar mecanismos de incentivos descentralizados a través de casos de uso únicos del token TEA para que cualquier miembro de la comunidad tea contribuya a la sostenibilidad perpetua y el crecimiento continuo del código abierto. Los participantes del proyecto son libres de decidir qué proyectos o mantenedores de paquetes quieren apoyar en función de su trabajo, creencias o cualquier criterio y métrica que influya en su decisión. Además, los participantes del proyecto son libres de decidir cómo quieren apoyar estos proyectos.
El patrocinio puede ser un sistema efectivo para apoyar el desarrollo de código abierto; sin embargo, estos patrocinios no suelen extenderse a todas las dependencias. Esta limitación beneficia a los favoritos y obstaculiza la innovación y la construcción de software. Para esforzarse como la base del desarrollo de software, el código abierto debe empoderar a todos los desarrolladores, ya sean principiantes o expertos, en todas las capas de la torre.
#### Usuarios de Paquetes y miembros de la comunidad tea
Los "usuarios de paquetes" son desarrolladores de software enfocados en resolver un problema específico. A menudo buscan en la comunidad de código abierto las herramientas que necesitan para experimentar rápidamente e iterar con poco o ningún costo, beneficiándose directamente del trabajo de los mantenedores de paquetes.
Con más de 10 millones de paquetes accesibles a través de los 30 principales gestores de paquetes, la ausencia de una atribución de valor universal a los proyectos de código abierto puede transformar la selección de paquetes seguros y eficientes para el desarrollo en un esfuerzo arriesgado y desalentador. Sin medios discernibles para atribuir y medir el valor, ¿cómo seleccionan los usuarios de paquetes de manera eficiente paquetes seguros para su desarrollo?
Creemos que el algoritmo de Prueba de Contribución del Protocolo tea, combinado con otros incentivos, puede proporcionar a los usuarios de paquetes la información que necesitan para seleccionar rápidamente y con reflexión la base de su propio proyecto.
Participantes del Proyecto
En Web 2.0 y web3, un subconjunto de usuarios de paquetes, a menudo llamados "patrocinadores", ha optado por apoyar a los mantenedores de paquetes a través de donaciones u otras formas de remuneración; sin embargo, esto raramente ha sido el caso.
Estos "participantes del proyecto" son organizaciones o usuarios de proyectos de código abierto que utilizan software de código abierto para construir sus productos comerciales, filántropos que buscan apoyar el ecosistema, o emprendedores que buscan financiar equipos para desarrollar componentes de un sistema más grande.
tea propone extender las comunidades de participantes de proyectos de código abierto a toda la comunidad tea, ya sean organizaciones, desarrolladores, usuarios o entusiastas de la tecnología. El objetivo de tea es implementar mecanismos de incentivos descentralizados a través de casos de uso únicos del token TEA para que cualquier miembro de la comunidad tea contribuya a la sostenibilidad perpetua y el crecimiento continuo del código abierto. Los participantes del proyecto son libres de decidir qué proyectos o mantenedores de paquetes quieren apoyar en función de su trabajo, creencias o cualquier criterio y métrica que influya en su decisión. Además, los participantes del proyecto son libres de decidir cómo quieren apoyar estos proyectos.
El patrocinio puede ser un sistema efectivo para apoyar el desarrollo de código abierto; sin embargo, estos patrocinios no suelen extenderse a todas las dependencias. Esta limitación beneficia a los favoritos y obstaculiza la innovación y la construcción de software. Para esforzarse como la base del desarrollo de software, el código abierto debe empoderar a todos los desarrolladores, ya sean principiantes o expertos, en todas las capas de la torre.
Para reforzar la sostenibilidad e integridad de la cadena de suministro de software y permitir que los desarrolladores de código abierto capturen el valor que crean, tea tiene como objetivo establecer mecanismos donde el apoyo beneficie a todos los aspectos de un proyecto. El apoyo de los patrocinadores se extenderá a través de las dependencias de un proyecto, desde la cima hasta la base del árbol. Esto coloca implícitamente la confianza en la capacidad del mantenedor de paquetes para tomar decisiones informadas sobre su pila, mejorando así su reputación.
<figure><img src=".gitbook/assets/figure-2.png" alt=""><figcaption><p>Figura 2 - Distribución de recompensas a través de las dependencias</p></figcaption></figure>
#### Catacatadores de tea
A medida que se lanzan nuevos proyectos o nuevas versiones de proyectos existentes, la validez del trabajo necesita ser demostrada de manera comprobable. Esta información es crítica para que los usuarios de paquetes decidan si pueden confiar en el paquete y sus mantenedores. Dentro del Protocolo tea, esta función es proporcionada por los "catacatadores de tea".
Los catacatadores de tea, típicamente, son desarrolladores de software experimentados dispuestos a dedicar parte de su tiempo a verificar las afirmaciones asociadas con un paquete (funcionalidad, seguridad, [versionado semántico](https://semver.org/) precisión de la licencia, etc.) y apostar tanto su reputación como tokens TEA para demostrar el resultado de su investigación y respaldar sus revisiones. En el Protocolo tea, "apostar tu tea" es el proceso de bloquear tokens TEA para respaldar tus revisiones, potencialmente ganando recompensas o enfrentando penalizaciones basadas en el consenso sobre la calidad de tus revisiones. Los catacatadores de tea también tienen la opción de informar confidencialmente sobre errores o vulnerabilidades a los mantenedores de paquetes. Los informes válidos resultan en recompensas del tesoro del proyecto, mientras que los informes inválidos llevan a la pérdida de la apuesta del catacatador de tea. Por último, si los mantenedores de paquetes ignoran estos problemas reportados, desencadena penalizaciones, o "reducciones", para el tesoro del proyecto.
Al igual que los partidarios del proyecto, los catacatadores de tea pueden influir en la reputación de un proyecto y de un mantenedor de paquetes; sin embargo, su impacto es mayor dado su papel en validar la seguridad, funcionalidad y calidad de un proyecto. Los catacatadores de tea también necesitarán construir su reputación para respaldar sus afirmaciones. La calidad de su trabajo y los tokens TEA que ponen en riesgo al apostar sus revisiones combinados con otras fuentes de datos externas construirán la reputación de cada catacatador de tea, aportando más valor a su trabajo. Ver la sección "[Reputación del Paquete y del Mantenedor del Paquete](white-paper.md#package-and-package-maintainer-reputation)" para más detalles sobre los mecanismos utilizados para influir en la reputación de un proyecto y de un mantenedor de paquetes.
### Registro de Proyecto y Recompensas de Prueba de Contribución
El registro de un lanzamiento de proyecto requiere que ocurran múltiples transacciones de manera atómica. Específicamente:
* El mantenedor del paquete debe registrar el proyecto en el registro descentralizado,
* El Protocolo tea debe instanciar un tesoro del proyecto propiedad, controlado y configurado por los mantenedores de paquetes de acuerdo con las reglas definidas por los mantenedores de paquetes, y
* El Protocolo tea debe registrar el nombre único del tesoro en el Servicio de Nombres de Ethereum, o ENS, simplificando así todas las interacciones de los usuarios con el tesoro.
El fracaso de cualquiera de las operaciones resultará en que el protocolo vuelva a su estado anterior.
ras el registro exitoso de un proyecto con un teaRank que supera un umbral definido por la gobernanza, el Protocolo tea inicia la distribución de recompensas de Prueba de Contribución al tesoro del proyecto. Sugerimos distribuir estas recompensas siguiendo una curva predeterminada desde un grupo predefinido de tokens controlado por el Protocolo tea y asignado desde el suministro total de tokens TEA.
Se requiere que los mantenedores de paquetes refuercen la reputación y confiabilidad de su proyecto apostando constantemente una parte de las recompensas de Prueba de Contribución recibidas por el tesoro del proyecto. Por cada staked token, los participantes de la red recibirán un “staked TEA” no transferible, o stTEA, en una relación de 1:1, para participar en la gobernanza del Protocolo tea. De acuerdo con las reglas del protocolo, estas recompensas apostadas, y sus correspondientes stTEA, pueden estar sujetas a reducción (“reducción”) o redistribución si los mantenedores de paquetes no abordan errores o vulnerabilidades.
Por último, el no mantener la proporción mínima del tesoro apostado definida en las reglas de gobernanza resultará en la suspensión de la distribución de recompensas de Prueba de Contribución al proyecto. En su lugar, estas recompensas se redistribuirán entre los proyectos que cumplan con las normas.
### Reputación del Paquete y del Mantenedor del Paquete
Un sistema de reputación que depende únicamente de la contribución económica del autor no proporciona suficiente protección al usuario y puede estar sujeto a ataques Sybil, donde un individuo crea múltiples representaciones de sí mismo para dejar un gran volumen de reseñas positivas sobre su trabajo, engañando a los usuarios para que crean que su trabajo fue revisado y aprobado por muchos.
Existen varias metodologías disponibles para prevenir ataques Sybil, algunas de las cuales son descritas por Nitish Balachandran y Sugata Sanyal en “[A Review of Techniques to Mitigate Sybil Attacks](https://arxiv.org/abs/1207.2617/)”. Como tea es un protocolo descentralizado, usar un sistema de certificación de confianza que dependa de una autoridad centralizada de emisión de certificados sería contrario a su esencia. Proponemos enfocarnos en enfoques descentralizados para la mitigación de ataques Sybil y, más específicamente, en metodologías que dependan de un gran grupo de participantes de la red incentivados para evaluar y representar públicamente la reputación de cada paquete y su mantenedor.
Similar a la producción de bloques en una blockchain de prueba de participación, donde los nodos no productores pueden validar el trabajo de otros y, cuando sea necesario, destacar una violación de las reglas de la red, lo que lleva a una penalización del actor malicioso a través del slashing (destrucción de una parte de su staking), proponemos un sistema donde terceros, como los catacatadores de tea, puedan revisar los paquetes producidos por los mantenedores de paquetes y ser incentivados para actuar en el mejor interés de la comunidad de software de código abierto y sus usuarios, así como reconocer el buen comportamiento y penalizar el mal comportamiento. Este sistema debe ser resistente a Sybil y evitar que los poseedores de grandes cantidades de tokens influyan materialmente en el protocolo o en la reputación de paquetes específicos. Creemos que este enfoque está más alineado con el código abierto, proporcionando un sustrato más fértil para fomentar la adopción y la confianza, y facilitar en última instancia el crecimiento de tea.
Además, a medida que la reputación de cualquier miembro de la comunidad tea alcance hitos clave, se le puede otorgar acceso a partes elevadas del protocolo.
### Revisión de Paquetes por Terceros
La revisión de paquetes por terceros es un componente esencial en la construcción de reputación y la seguridad de la cadena de suministro de software. Sin embargo, las revisiones de terceros vienen con su propio conjunto de amenazas únicas, incluyendo los ataques Sybil mencionados anteriormente.
La tecnología blockchain, y más explícitamente el staking, ofrece una oportunidad única para que tea aborde este desafío. Aunque las direcciones de billetera pueden estar disponibles en cantidades infinitas, no es el caso con los tokens TEA, cuyo suministro total se espera sea de 10 mil millones. Además, cada acción realizada por los desarrolladores, como enviar, verificar o staking paquetes, contribuirá a su reputación, creando así un perfil único que cada desarrollador puede usar tanto para contribuir a la comunidad tea como para participar en la gobernanza de tea.
Al requerir que los revisores realicen staking de TEA tokens e incurran en el riesgo de perder una parte de su apuesta si resultan actuar en contra del interés de la red o ser un actor malicioso, los terceros pueden proporcionar credibilidad adicional a un paquete y recibir una recompensa, en forma de tokens TEA.
También proponemos extender el sistema de reputación a los terceros que realizan la verificación independiente de los paquetes, los catacatadores de tea. La finalización de una revisión positiva requerirá que ocurran dos operaciones de manera atómica:
* La presentación de la revisión de código, firmada por el catacatador de tea y accesible públicamente para todos los miembros de la comunidad, junto con
* El acto de staking del paquete, para fundamentar su revisión.
La finalización de una revisión negativa que incluye una o más vulnerabilidades críticas requerirá que los catacatadores de tea primero contacten al mantenedor del paquete usando un protocolo de mensajería para notificarles sobre la vulnerabilidad y permitirles abordar el problema de manera oportuna. Tras la expiración del período definido por la gobernanza asignado al mantenedor del paquete para abordar su vulnerabilidad o a medida que el paquete corregido esté disponible, el mismo protocolo de mensajería se utilizará para notificar a los usuarios y probadores de este paquete (incluyendo dependientes) que se ha identificado una vulnerabilidad, y con suerte abordado, para que sepan actualizar su aplicación o dependencias. Para desincentivar la pérdida de tiempo de los desarrolladores, la comunicación entre los catacatadores de tea y los mantenedores de paquetes requerirá que los catacatadores de tea apuesten tokens TEA.
Tras completar ambas operaciones, los catacatadores de tea recibirán un NFT como evidencia de su trabajo en el paquete y versión específica del paquete. La acumulación de NFTs combinada con la proporción de staking de cada uno de los paquetes revisados e información extraída de sistemas externos informará la reputación de un catacatador de tea. A medida que su reputación alcance hitos clave, los catacatadores de tea pueden ganar acceso a partes elevadas del protocolo o recompensas aceleradas del protocolo, según lo decida la gobernanza de tea.
### Paquetes Desactualizados o Corruptos
La misión de tea es mejorar la sostenibilidad e integridad de la cadena de suministro de software permitiendo a los desarrolladores de código abierto capturar el valor que crean; sin embargo, las recompensas deben ser proporcionales a los esfuerzos desplegados por los mantenedores de paquetes y los catacatadores de tea. Los paquetes poco mantenidos, desactualizados o corruptos son claras indicaciones de que los mantenedores de paquetes no están cumpliendo con las expectativas de la comunidad o no están entregando en la confianza y el apoyo impresionados sobre ellos a través del staking de paquetes. Otra manifestación de paquetes desactualizados puede ser el uso continuado de un lenguaje heredado o una versión heredada de lenguajes multi-versión. Paquetes que permanecen desactualizados o corruptos durante demasiado tiempo indican que los catacatadores de tea necesitan revisar regular y consistentemente el trabajo de los mantenedores de paquetes.
Los catacatadores de tea juegan un papel pivotal en las comunidades de código abierto, ya que sus revisiones y reclamaciones asociadas pueden influir en los usuarios de paquetes, guiándolos hacia o alejándolos de paquetes específicos. Para garantizar que las revisiones puedan ser confiables de manera continua, proponemos un mecanismo por el cual las revisiones publicadas por los catacatadores de tea deben estar asociadas con tokens TEA apostados. Los paquetes desactualizados o corruptos pueden ver una parte de su tesoro reducida, mientras que otra parte se envía al catacatador de tea que primero reconoció la falta de mantenimiento de cualquier paquete.
A medida que los paquetes ganan popularidad y uso, con más aplicaciones y potencialmente sistemas críticos dependiendo de ellos, debemos incentivar a los desarrolladores a informar discretamente los defectos al mantenedor del paquete y animar a los mantenedores de paquetes a abordar tales defectos antes de que puedan ser explotados. En consecuencia, proponemos que cualquier revisión negativa que describa un defecto, como una vulnerabilidad de día cero o el uso de una dependencia desactualizada y que permanezca abierta más allá de un período de gracia definido por la gobernanza, debe considerarse un fallo por parte del mantenedor del paquete y estar sujeto a las mismas penalizaciones, con el primer catacatador de tea que informe del defecto recibiendo una parte de los tokens reducidos.
Lo mismo se puede decir de los partidarios del paquete que apostaron su reputación y tokens TEA en el trabajo de mantenedores de paquetes delincuentes y recibieron recompensas por ello. Como no lograron identificar la falta de mantenimiento o eligieron continuar apoyando el paquete independientemente, proponemos que todas las actividades de reducción se extiendan a los partidarios del paquete.
La distribución a todos los catacatadores de tea podría basarse en la antigüedad de su revisión y la cantidad de tokens TEA que apostaron por su revisión.
## Token TEA
TEA es un token criptográfico que sirve como clave de acceso a ciertas partes y características designadas del Protocolo tea.
Los poseedores del token TEA tienen la capacidad de:
* Registrar sus paquetes;
* Apoyar paquetes apostando tokens TEA en paquetes específicos;
* Contribuir a la seguridad de la cadena de suministro de software desafiando paquetes y realizando revisiones para informar sobre errores y/o vulnerabilidades.
Como se ha discutido, el Protocolo tea desbloquea la economía de código abierto y crea valor para los constructores, mantenedores y usuarios finales del software empresarial. En última instancia, el valor capturado por el Protocolo tea se acumula de nuevo a los poseedores de tokens a medida que la comunidad escala, creando un ciclo de retroalimentación que incentiva aún más la participación.
### Recompensando a los Desarrolladores de Código Abierto
Esperamos que los mecanismos de Prueba de Contribución y staking de tea fomenten el crecimiento del código abierto al empoderar a sus participantes con los recursos que necesitan para seguir su pasión sin trabas.
Como se detalla en "[Registro de Proyecto y Recompensas de Prueba de Contribución](white-paper.md#project-registration-and-proof-of-contribution-rewards)", los proyectos registrados en el Protocolo tea y con un teaRank que supere un umbral definido por la gobernanza recibirán recompensas de Prueba de Contribución en forma de tokens TEA del Protocolo tea. Esta distribución persistirá siempre y cuando el paquete cumpla con las reglas del protocolo. Específicamente, el paquete deberá mantener un teaRank por encima del umbral definido por la gobernanza y los mantenedores del paquete tendrán que contribuir a la reputación y confiabilidad de su proyecto apostando continuamente una parte de las recompensas de Prueba de Contribución recibidas por el tesoro del proyecto. El incumplimiento de estas reglas resultará en la suspensión de la distribución de recompensas de Prueba de Contribución y la redistribución de futuras recompensas entre proyectos que cumplan con las normas.
Las dependencias pueden afectar significativamente la fiabilidad y seguridad de un paquete, y la ausencia de registro para las dependencias de un paquete debe ser vista como un riesgo potencial. Los mantenedores de paquetes, siendo tanto validadores como usuarios de estas dependencias, están en una posición privilegiada para conectar con los mantenedores de esas dependencias. Pueden animarlos a registrar sus proyectos en tea, haciéndolos así sujetos a la supervisión de los catacatadores de tea y elegibles para recompensas asociadas. Para fomentar este compromiso comunitario dirigido a mejorar el sistema de reputación, recomendamos que cualquier paquete con dependencias que no estén registradas en el Protocolo tea vea una fracción de sus recompensas de Prueba de Contribución quemadas. Esta quema sería proporcional al número y contribución, cuantificada en teaRank, de cada dependencia no registrada, y continuaría mientras estas dependencias permanezcan sin registrarse.
Numerosos casos han demostrado que fuertes incentivos pueden tentar a actores maliciosos a comprometer el software de código abierto. La mayoría de la infraestructura crítica de Internet funciona con código abierto, y la carrera para encontrar exploits y otras vulnerabilidades está en marcha. En tea, creemos que los mantenedores de paquetes no son los que deberían ser culpados (aunque a menudo lo son).
Los incentivos del Protocolo tea abordan este problema asegurando una distribución justa y equitativa de incentivos. Un paquete como lodash con más de 176k dependientes es un pilar del desarrollo de código abierto, y sus mantenedores merecen ser recompensados proporcionalmente. Sin embargo, un sistema de recompensas basado únicamente en el número de dependientes impediría a los innovadores perturbar estos monopolios a menos que estén suficientemente financiados por terceros o ya hayan acumulado suficientes recursos para autofinanciarse. Este enfoque probablemente llevaría a un número decreciente de contribuyentes, resultando en lo opuesto a lo que tea pretende.
Para abordar esta limitación y empoderar a cada poseedor de tokens TEA con la capacidad de apoyar a los mantenedores de paquetes, también recomendamos que una fracción definida por la gobernanza de todas las recompensas de staking recibidas por todos los participantes de la red se dirija hacia el tesoro del paquete apostado, junto con sus dependencias.
### Apostando para Asegurar la Cadena de Suministro de Software
El staking puede ser una metodología efectiva para apoyar un sistema descentralizado de reputación. Sin embargo, para facilitar la seguridad de la cadena de suministro de software, el sistema de distribución de incentivos de tea debe considerar cuidadosamente la proporción de staking de cada paquete y ajustar el incentivo de cada paquete en consecuencia.
Para reducir el riesgo de que un pequeño número de paquetes utilizados como dependencias en muchas aplicaciones recolecten la mayoría de las recompensas de staking, recomendamos la implementación de una proporción óptima de staking, similar al enfoque descrito en la [investigación producida por la web3 Foundation](https://research.web3.foundation/Polkadot/overview/token-economics).
Cuando un paquete excede la proporción óptima de staking definida por la gobernanza, la cantidad total de recompensas de staking asignadas al paquete permanecerá fija, independientemente del número de tokens TEA apostados al paquete. Esta medida, diseñada para desincentivar a los partidarios del paquete y a los catacatadores de tea de seguir apostando paquetes altamente apostados, resultará en una disminución lineal de las recompensas de staking recibidas por cada partidario del paquete.
Un enfoque basado en curvas, como el descrito en la investigación de la web3 Foundation, ralentizaría la reducción del fondo de recompensas de staking asignado al paquete, continuando así quitando a paquetes menos apostados e introduciendo externalidades negativas al otorgar más influencia a los grandes poseedores de tokens sobre la distribución del fondo de recompensas de staking.
El diseño lineal recomendado debería permitir que los paquetes menos apostados sean más atractivos tanto para los partidarios del paquete como para los catacatadores de tea. También puede incentivar a los desarrolladores experimentados a construir alternativas a paquetes altamente apostados, creando una oportunidad para que la comunidad tea equilibre el apoyo al software existente y promueva la innovación. En su diseño inicial, la proporción de staking se calculará utilizando el suministro circulante. La comunidad tea puede alterar este diseño para mejorar aún más la escalabilidad del sistema.
Así como es necesario recompensar a los buenos actores, también es necesario identificar y penalizar a los malos actores. El software de código abierto ofrece muchas oportunidades para que los malos actores creen puntos de dolor y riesgos reputacionales para toda una comunidad de desarrolladores. Desde la apropiación indebida de trabajo hasta la alteración y redistribución de paquetes de software, o la inyección de código nefasto, la guerra entre buenos y malos actores continúa, a menudo con malos actores bien financiados que ven la contaminación de paquetes de código abierto como una oportunidad para beneficiarse financieramente. Las desventajas han sido relativamente mínimas, con paquetes potencialmente prohibidos de los estantes digitales o sujetos a una mala reputación.
Para abordar directamente a los actores maliciosos e intensificar las repercusiones por acciones contrarias al código abierto, recomendamos implementar el mecanismo de slashing detallado en las secciones “[Revisión de Paquetes por Terceros](white-paper.md#package-review-by-third-parties)” and “[Paquetes Desactualizados o Corruptos](white-paper.md#outdated-or-corrupt-packages)” sections.
A medida que los catacatadores de tea evalúan y analizan el código en paquetes recién enviados, sugerimos que los catacatadores de tea reciban las herramientas e incentivos para identificar y resaltar código nefasto para que:
* los usuarios de paquetes puedan ser conscientes de los riesgos, y
* los mantenedores de paquetes y los partidarios de paquetes sean penalizados por enviar o apoyar código nefasto.
En ese sentido, para todas las revisiones negativas evidenciadas realizadas según las reglas de la red y que hayan sido abordadas por el mantenedor del paquete dentro del período definido por la gobernanza, el mantenedor del paquete no debería incurrir en ninguna penalización, a diferencia de los partidarios del paquete o los catacatadores de tea que proporcionaron una revisión positiva del paquete en cuestión.
Para las revisiones negativas realizadas según las reglas de la red y que el mantenedor del paquete no haya abordado dentro del período definido por la gobernanza, una fracción de los tokens TEA en staking por el tesoro del proyecto, los partidarios del paquete y los catacatadores de tea anteriores será reducida y enviada al catador de tea que identificó el error o vulnerabilidad. Otra fracción será bloqueada en un fondo de seguro controlado por la gobernanza de tea. La gobernanza de tea establecerá políticas y reglas en estrecha colaboración con la comunidad para distribuir los contenidos del fondo a los afectados por vulnerabilidades. El protocolo distribuirá una tercera fracción de los tokens TEA reducidos entre todos los catacatadores de tea que contribuyeron a la revisión negativa.
El staking y el slashing son componentes vitales del sistema de incentivos y penalizaciones del Protocolo tea. Se requiere que los mantenedores de paquetes apuesten una parte del tesoro de su proyecto, asegurando que tengan una participación sustancial en riesgo en caso de que descuiden abordar errores o vulnerabilidades. Los usuarios de paquetes, partidarios y catacatadores de tea también pueden hacer staking de tokens TEA para contribuir a la reputación de un paquete o mantenedor de paquetes y participar activamente en el protocolo para mantener la sostenibilidad e integridad de la cadena de suministro de software.
La gobernanza está estrechamente vinculada a este compromiso activo. Por cada token TEA en staking, los participantes reciben "staked TEA" no transferible (stTEA) en una relación de 1:1, lo que les permite participar en la gobernanza del Protocolo tea. Las recompensas apostadas y sus correspondientes tokens stTEA pueden enfrentar reducción (slashing) o redistribución si no se siguen las reglas del protocolo, reforzando la responsabilidad dentro del ecosistema.
### Distribución del Suministro de Tokens TEA
La mayoría de los tokens TEA creados por el protocolo se utilizan como incentivos para animar a los mantenedores de paquetes, usuarios y partidarios a realizar actividades que aporten valor a la red descentralizada. La distribución de tokens TEA a varios interesados dentro del protocolo está dictada por un "calendario de distribución".
Los incentivos de la red serán distribuidos directamente por el Protocolo tea, en forma de tokens TEA, a cuatro grupos de interesados:
* Mantenedores de Paquetes;
* Usuarios de Paquetes (que incluyen a todos los miembros de la comunidad tea);
* Partidarios del Proyecto; y,
* Catacatadores de tea.
Los tokens TEA también se utilizarán para apoyar paquetes y asegurar la cadena de suministro de software a través del staking, incluyendo el derecho de desafiar un paquete realizando una revisión e informando errores o vulnerabilidades, recompensar a los desarrolladores de código abierto de proyectos registrados y participar en la gobernanza del Protocolo tea.
Se recomienda que un suministro máximo de 10 mil millones de tokens sea distribuido entre todos los miembros de la comunidad tea como se describe a continuación:
<figure><img src=".gitbook/assets/Token Allocation-Updated.svg" alt=""><figcaption><p>Figura 3 - Distribución de tokens del suministro máximo</p></figcaption></figure>
Aproximadamente el 51.4% del suministro máximo de tokens debería asignarse a "Ecosistema y Gobernanza", que incluye incentivos para que los proyectos de código abierto se unan y mantengan su base de código, así como recompensas por contribuir a votaciones descentralizadas y consenso a través del tea DAO. Los tokens asignados a "Ecosistema y Gobernanza" deben distribuirse como recompensas de Prueba de Contribución, recompensas de staking y otros tipos de incentivos centrados en el desarrollador.
Aproximadamente el 18.6% del suministro máximo de tokens debería asignarse al "Desarrollo del Protocolo" para garantizar la sostenibilidad y la evolución continua del Protocolo tea. Aproximadamente el 12.7% debería reservarse para "Partidarios y Asesores Iniciales". Aproximadamente el 11.0% debería reservarse para una venta privada, el 3.0% para una venta pública, mientras que el 3.2% restante debería asignarse para apoyar la liquidez del mercado una vez que ocurra un evento de generación de tokens.
Tokenomics detallados, incluyendo una Distribución de Tokens integral y un calendario de Emisiones serán el tema de un documento dedicado.
## Gobernanza
La gobernanza es crítica para el desarrollo, la sostenibilidad y la adopción de cualquier sistema distribuido.
Proponemos que el Protocolo tea incorpore mecanismos de gobernanza que permitan a los contribuyentes activos que han puesto sus tokens TEA en staking proponer y votar sobre cambios de parámetros críticos no financieros. El proceso de votación estaría ponderado por la propiedad de tokens stTEA y la reputación individual.
Los parámetros del protocolo podrían incluir la prioridad para apoyar gestores de paquetes específicos o introducir nuevas características o funciones del protocolo, así como el impacto de factores externos en la reputación de usuarios y paquetes. Esta funcionalidad asegurará que los parámetros críticos puedan evolucionar y optimizarse a lo largo del tiempo por miembros activos de la comunidad tea. Anticipamos que la gobernanza se lanzará con una estructura simple y se expandirá progresivamente a medida que el sistema tea madure, facilitando la adopción y garantizando una descentralización progresiva.
Algunos parámetros del sistema pueden no estar sujetos a la gobernanza o admitir cambios de alta frecuencia para reducir la superficie de ataque representada por la gobernanza. Una transición progresiva de parámetros a una gobernanza abierta y descentralizada asegurará la estabilidad y previsibilidad del sistema.
## Extensibilidad de Terceros
Mientras construimos las herramientas iniciales para encender el tan esperado apoyo a las comunidades de código abierto, creemos que parte de nuestra misión es asegurar que terceros puedan extender el conjunto total de herramientas. Además de proporcionar la infraestructura para que los desarrolladores construyan extensiones al protocolo, incluyendo nuevas formas de innovar y apoyar aún más a los desarrolladores de código abierto, nuestros planes incluyen la posibilidad de que otros gestores de paquetes contribuyan al protocolo.
Los sueños y esfuerzos de los desarrolladores de código abierto han construido la innovación que respalda nuestra vida cotidiana. Esperamos descubrir los nuevos usos y extensiones para el Protocolo tea propuestos por la comunidad tea.
## El Futuro y Posibles Esfuerzos de la Comunidad
A medida que el sistema tea madure, prevemos que la comunidad decida y contribuya a alteraciones y extensiones del sistema tea a través de la gobernanza. A continuación, presentamos algunas ideas que creemos que pueden inspirar a algunos, sin embargo, no garantizamos ningún rendimiento futuro.
### Mayoristas de tea
Las comunidades de software de código abierto son vibrantes y constantemente buscan innovar y entregar valor. Esta dedicación y altruismo llevan a la construcción constante de nuevo software y paquetes, cada uno utilizando dependencias. Como resultado, anticipamos que el mapa de dependencias evolucione constantemente, llevando a cambios frecuentes en la proporción de staking y recompensas. En el futuro, la comunidad tea puede proponer el desarrollo de un sistema diseñado para monitorear dinámicamente la proporción de staking para cada proyecto y reequilibrar cómo los partidarios del proyecto apuestan sus tokens TEA basándose en sus propios criterios.
### Regalías por Transferencia de Paquetes
Reconocemos que los mantenedores de paquetes pueden decidir transferir su flujo de recompensas a uno o más desarrolladores. La gobernanza de tal transferencia debe permanecer como la decisión del mantenedor del paquete y sus socios, sin interferencia de tea. Se necesitarán herramientas para que dicha transferencia sea total o parcial (tal vez a través de solo una porción de las recompensas siendo redirigidas a uno o más desarrolladores, mientras que las recompensas restantes continúan fluyendo al mantenedor del paquete original) y para que las recompensas de staking fluyan a través de una única cuenta controlada por un único participante de la red, múltiples participantes de la red, o distribuidas automáticamente entre múltiples cuentas usando proporciones estáticas o dinámicas.
### Distribución de Recompensas Entre Varios Mantenedores
El mantenimiento de un paquete puede depender del trabajo de un equipo o más de desarrolladores. Antes de que comiencen a fluir las recompensas, los equipos deberían considerar automatizar la distribución del valor entre ellos mismos. Cómo ocurre la distribución debe ser decidido por los propios mantenedores, ya que están en la mejor posición para evaluar quién contribuyó y cómo deben ser recompensados.
Para lograrlo, cada equipo (o equipos) podría configurar su propia organización autónoma descentralizada ([DAO](https://ethereum.org/en/dao/)) y automatizar la distribución o desplegar sistemas más complejos para determinar la distribución de valor adecuada basada en factores externos como un voto de todos los miembros de la DAO, o distribuciones basadas en tiempo en función de la contribución continua, la finalización exitosa de recompensas, etc.
### Manejo de Paquetes "forks"
Creemos que los forks son esenciales y en gran medida subutilizados. Los forks pueden ser una herramienta efectiva para desarrollar paquetes que compiten en funcionalidad, rendimiento, seguridad e incluso atención. Por útiles que puedan ser, los forks deben reconocer los esfuerzos originales. A través del trabajo futuro o posibles contribuciones, la comunidad tea puede mejorar el sistema para requerir que los forks sean declarados, tal vez incluso detectados cuando un proyecto se registre. Los forks no declarados revelados por los catacatadores de tea pueden resultar en una reducción de una parte de la apuesta del tesoro del fork, transferida al mantenedor del paquete original o enviada a los catacatadores de tea que revelaron el fork.
### Dependencias de Ejecución vs. Construcción
tea puede no distinguir entre dependencias de construcción y dependencias de ejecución al distribuir recompensas de Prueba de Contribución en el lanzamiento. Sin embargo, si la comunidad tea siente fuertemente acerca de hacer tal distinción, la comunidad tea puede proponer mejoras al algoritmo de distribución de recompensas para tener en cuenta la criticidad de cada dependencia y su contribución al valor individual de los paquetes que dependen de ellas. Estas propuestas serían votadas e implementadas según la decisión de la comunidad.
### Recompensas Basadas en el Uso
A medida que se construyan más aplicaciones utilizando proyectos registrados con tea, la comunidad puede aumentar el algoritmo de recompensas para que la asignación pueda ser influenciada por conjuntos de datos externos atestiguados como el uso. Esta actualización al mecanismo de recompensas podría permitir una mayor asignación de recompensas de tokens TEA hacia paquetes con el uso más alto, respetando aún las restricciones de la proporción de staking descrita en la sección de tokens TEA. Los mantenedores de paquetes podrían usar un enfoque similar para distribuir recompensas a través de sus dependencias basado en la lógica transparente de su elección. Tenga en cuenta que toda la información utilizada para afectar la distribución de recompensas entre paquetes y dependencias en el sistema tea necesitará ser comprobablemente confiable.
## Agradecimientos
Este documento técnico no existiría sin el apoyo y la dedicación de muchos teaófilos. Los autores desean reconocer a Jacob Heider, Jadid Khan, Josh Kruger y Shane Molidor por su contribución a la tokenomía, Sanchit Ram por su contribución al algoritmo teaRank, y a los muchos individuos discretos que ofrecieron voluntariamente su tiempo para proporcionar retroalimentación sobre el contenido de este documento.
## Glosario de Términos
| Término | Definición |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Leaf | TLa denominación más pequeña del token TEA. Un "leaf" corresponde a una quintillonésima parte (10^−18) de un TEA. |
| Slashing | La acción de penalizar a los que hacen staking en respuesta a comportamientos contrarios a las reglas del protocolo. |
| Staking | La acción de bloquear tokens TEA para respaldar tu reclamo y recibir recompensas (o penalizaciones) basadas en el consenso sobre la validez de tu reclamo. |
| stTEA | Token “TEA en staking” no transferible o “stTEA” recibido por los participantes de la red por cada token apostado en una relación de 1:1. stTEA puede utilizarse para participar en la gobernanza del Protocolo tea |
| teaRank | Puntuación de impacto dinámica asignada a cada proyecto por el algoritmo “Prueba de Contribución” del protocolo. |
## Referencias
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)
================================================
FILE: i18n/pt-br/metadata.yml
================================================
title: Um Protocolo Descentralizado Para Remunerar o Ecossistema de Código Aberto
abstract: |-
A criação de um registro aberto, público e estável para todos os softwares de código aberto
autorizaria os projetos a publicar lançamentos de forma independente, ao invés de confiar
em terceiros que reúnem esses dados irregulares em centenas de sistemas separados e duplicados.
Os mantenedores de pacotes publicarão seus lançamentos para um registro descentralizado
alimentado por uma blockchain Bizantina tolerante a falhas para eliminar fontes únicas de falha,
fornecer liberações imutáveis e permitir que comunidades governem suas regiões
do ecossistema de código aberto, independentemente de agendas externas.
O tea incentiva a manutenção do código aberto, permitindo que os participantes da rede
apostem valor em relação aos pacotes dos quais dependem e desejam garantir.
O gráfico do protocolo tea fornece o registro imutável do pacote, os requisitos de dependência,
a autenticidade do pacote e os oráculos de utilização para informar o algoritmo de
remuneração do tea. A inflação sistemática é distribuída a todos os pacotes com base
nesse algoritmo. Se forem encontrados problemas de segurança ou desenvolvimento,
os desenvolvedores podem fazer reivindicações apoiadas por evidências contra o pacote,
e pode ocorrer Slashing. Os membros da comunidade de código aberto podem rever os
pacotes para questões de qualidade, e o protocolo pode responder a essas avaliações
executando eventos de Slashing proporcionais.
author:
- Max Howell
- Timothy Lewis
- Thomas Borrel
references:
- id: sources
url: https://github.com/teaxyz/white-paper
- id: cc
url: https://creativecommons.org/licenses/by-sa/4.0/
- id: nist
url: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- id: reuters
url: https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA
- id: twitter
url: https://twitter.com/yazicivo/status/1469349956880408583
- id: w3
url: https://www.w3.org/TR/did-core/
- id: theregister
url: https://www.theregister.com/2016/03/23/npm_left_pad_chaos/
- id: fossa
url: https://fossa.com/blog/npm-packages-colors-faker-corrupted/
- id: lunasec
url: https://www.lunasec.io/docs/blog/node-ipc-protestware/
- id: github
url: https://github.com/dominictarr/event-stream/issues/116
- id: zdnet
url: https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/
- id: threatpost
url: https://threatpost.com/backdoor-found-in-utility-for-linux/147581/
- id: fbi
url: https://www.fbi.gov/news/stories/phantom-secure-takedown-031618
- id: europol
url: https://www.europol.europa.eu/media-press/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication
- id: medium
url: https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502
- id: semver
url: https://semver.org/
- id: npmjsCrossenv
url: https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html
- id: npmjsLodash
url: https://www.npmjs.com/package/lodash
- id: npmjsChalk
url: https://www.npmjs.com/package/chalk
- id: npmjsLogFourjs
url: https://www.npmjs.com/package/log4js/
- id: arxiv
url: https://arxiv.org/abs/1207.2617/
- id: web3
url: https://research.web3.foundation/en/latest/polkadot/overview/2-token-economics.html
header-includes:
- \usepackage{fancyhdr,ragged2e}
- \lhead{\parbox[t]{0.5\textwidth}{\RaggedRight\rightmark\strut}}
- \rhead{\parbox[t]{0.5\textwidth}{\RaggedLeft\leftmark\strut}}
- \setlength{\headheight}{5\baselineskip}
- \pagestyle{fancy}
- \fancyfoot[LE,RO]{© 2022 tea.inc.}
- \fancyfoot[L]{v${1.0.5}+${pt-br}}
lang: pt-br
dir: ltr
translator:
- Lucas Eduardo de Lima
================================================
FILE: i18n/pt-br/white-paper.md
================================================
# Isenção de responsabilidade
As informações apresentadas no presente livro branco são de caráter preliminar.
Consequentemente, nem os autores nem qualquer uma dos seus respectivos afiliados assumem qualquer responsabilidade de que as informações aqui estabelecidas sejam finais ou corretas e cada uma das anteriores renuncia,
na medida máxima permitida pela lei aplicável, toda e qualquer responsabilidade decorrente de ato ilícito, contrato ou de outra forma em relação a este livro branco.
Nem este livro branco nem qualquer coisa aqui contida devem constituir a base ou ser invocados em conexão com ou agir como um incentivo para celebrar qualquer contrato ou compromisso de qualquer natureza.
Nada neste livro branco constitui uma oferta de venda ou uma solicitação para comprar quaisquer tokens aqui discutidos.
Em qualquer caso, se este livro branco for considerado como tal oferta ou solicitação, nenhuma oferta ou solicitação é pretendida ou transmitida por este livro branco em qualquer jurisdição onde seja ilegal fazê-lo,
quando tal oferta ou solicitação exigir uma licença ou registro, ou quando tal oferta ou solicitação estiver sujeita a restrições.
Em particular, quaisquer tokens discutidos neste documento não foram, e, até a data de emissão deste livro branco, não têm a intenção de serem registrados sob as leis de valores mobiliários ou similares de qualquer jurisdição, independentemente de essa jurisdição considerar tais tokens como um valor mobiliário ou instrumento similar, e podem não ser oferecidos ou vendidos em qualquer jurisdição onde fazê-lo constituiria uma violação das leis relevantes de tal jurisdição.
# Licença
O código-fonte[^src] deste documento está disponível sob a licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional[^cc].
[^src]: Veja: @sources
[^cc]: Veja: @cc
# Introdução
A internet é predominantemente composta por projetos de código aberto e tem sido assim desde o seu início.
Com o tempo, muitos desses projetos se tornaram peças fundamentais sobre as quais toda inovação futura é construída.
E embora fortunas tenham sido feitas a partir disso, o código aberto é principalmente criado e mantido sem compensação.
Nós acreditamos que a totalidade do empreendimento humano moderno foi prejudicada ao depender do menor percentual de engenheiros do mundo para escolher entre um salário ou manter a Internet funcionando.
O código aberto é um trabalho de amor frequentemente prejudicado pela falta de incentivos econômicos significativos, resultando em projetos genuinamente valiosos nunca alcançarem seu potencial, enquanto outros sofrem com problemas de segurança devido à falta de incentivos para manter o software ao longo de seu ciclo de vida.
Para realizar plenamente nosso potencial, precisamos de um sistema de remuneração justo para o ecossistema de código aberto que não mude fundamentalmente como ele é construído ou utilizado.
Empresas frequentemente criam modelos de negócios em torno do código aberto, gerando receita diretamente a partir do trabalho dos desenvolvedores benevolentes, enquanto também dependem deles para corrigir bugs conforme surgem problemas.
Um ótimo exemplo é um incidente recente envolvendo uma vulnerabilidade crítica de segurança no Log4j, um pacote da Apache Software Foundation que se espalhou por muitos softwares comerciais e serviços usados por empresas e governos.
Em novembro de 2021, um pesquisador de segurança que trabalhava para a Alibaba Group Holding Ltd. reportou a vulnerabilidade CVE-2021-44228[^1], que recebeu a pontuação base mais alta possível da Apache Software Foundation. Amit Yoran, CEO da Tenable e diretor fundador do United States Computer Emergency Readiness Team (US-CERT), descreveu essa vulnerabilidade como 'a maior e mais crítica vulnerabilidade da última década'[^2].
O pânico se instaurou e os poucos voluntários que mantinham esse pacote foram publicamente criticados pelo fracasso.
Após abordar a indignação com um humilde pedido de Justiça, os sistemas foram corrigidos.
Empresas e governos eventualmente perceberam que o Log4j, um pacote usado por uma ampla gama de sistemas críticos por duas décadas, era mantido por alguns voluntários não remunerados, os mesmos heróis desconhecidos que entraram em ação apesar do abuso da indústria[^3] e trabalharam incansavelmente para resolver a vulnerabilidade.
Infelizmente, o Log4j está longe de ser o único exemplo.
O core-js é baixado 30 milhões de vezes por semana como base de cada aplicativo Node.js, mas também recebe pouquíssimo financiamento.
Recentemente, vários desenvolvedores principais do Bitcoin Core renunciaram, citando, entre outras razões, a *falta de compensação financeira* por suas decisões.
Houveram múltiplas tentativas de fornecer estruturas de incentivo, geralmente envolvendo patrocínio e sistemas de recompensa.
O patrocínio torna possível para consumidores de código aberto doarem para os projetos que favorecem.
No entanto, imagine o código aberto como uma torre de tijolos onde as camadas inferiores são há muito esquecidas, mas ainda mantidas por engenheiros dedicados e utilizadas por ainda mais desenvolvedores.
Apenas projetos no topo da torre são normalmente conhecidos e recebem patrocínio.
Essa seleção tendenciosa leva a tijolos essenciais que sustentam a torre não receberem doações, enquanto os favoritos recebem mais do que precisam.
Recompensas permitem que consumidores de projetos proponham pagamento para desenvolvedores construírem recursos específicos, assim remunerando apenas projetos por fazer coisas não necessariamente no seu melhor interesse.
E novamente, apenas recompensando os favoritos.
Neste documento, propomos o tea — um sistema descentralizado para remunerar justamente os desenvolvedores de código aberto com base em suas contribuições para todo o ecossistema e implementado através do algoritmo de incentivo tea aplicado a todas as entradas no registro do tea.
$\parskip=0pt plus 1pt$
[^1]: Fonte: @nist
[^2]: Fonte: @reuters
[^3]: Fonte: @twitter
# Componentes
Um desenvolvedor de software construindo uma aplicação precisa de quatro coisas: um navegador, um terminal, um editor e um gerenciador de pacotes.
Destes quatro, o gerenciador de pacotes é o que controla as ferramentas e estruturas que um desenvolvedor precisa para construir seu produto.
Esta camada é onde vemos o potencial de mudar como o código aberto é remunerado.
## O Gerenciador de Pacotes
O gerenciador de pacotes conhece o software de código aberto no qual uma aplicação depende para funcionar, desde o topo da torre até sua base.
Cada componente e versão essencial para a aplicação são conhecidos e registrados.
Ele sabe que o topo da torre seleciona cuidadosamente suas dependências e que essa seleção cuidadosa continua descendendo.
O gerenciador de pacotes está posicionado de forma única na pilha de ferramentas do desenvolvedor para permitir a distribuição automatizada e precisa de valor com base no uso real e prático.
Nós propomos um registro descentralizado imutável projetado para distribuir valor com base em um algoritmo que determina a contribuição de cada entrada para a utilidade e saúde do sistema.
O valor pode entrar no gráfico nos pontos de ápice — aplicativos e bibliotecas essenciais — e ser distribuído para as dependências desses pontos de ápice e suas dependências recursivamente, já que o registro conhece todo o gráfico de código aberto.
Além disso, acreditamos que informações materiais devem estar disponíveis via gerenciador de pacotes para que os desenvolvedores possam avaliar se podem confiar em um pacote e em seu autor.
Essas informações podem se basear em reputação, reconhecimento da comunidade, dados obtidos de sistemas de identidade descentralizados (DID[^4]) outros gerenciadores de pacotes ou mecanismos de incentivo que potencialmente dependem dos participantes da rede colocando valor econômico em risco.
Prevemos que a combinação de ferramentas, informações e recompensas do tea incentivará justamente os desenvolvedores, ajudando a estimular o crescimento do software de código aberto e fomentar a inovação.
[^4]: See: @w3
## O Registro Descentralizado
Cada gerenciador de pacotes possui seu próprio registro de pacotes duplicando os mesmos metadados repetidamente.
Está na hora de haver um registro único, abrangente e definitivo projetado e governado pelas comunidades que dependem dele.
Este registro descentralizado e imutável poderia fornecer segurança, estabilidade e impedir intenções maliciosas.
A internet opera com dezenas de milhares de componentes vitais de código aberto.
É notável que, até agora, incidentes causados pela remoção de infraestrutura de código aberto essencial tenham sido mínimos.
O mais famoso foi a remoção de uma dependência do NPM chamada left-pad[^5] em 2016, que causou problemas em sistemas de integração contínua e implantação contínua, deixando os desenvolvedores em situação delicada por dias.
Esse evento demonstrou que a própria internet é baseada em sistemas frágeis de desenvolvimento.
Outros exemplos envolveram participação ativa ou intencional dos mantenedores de pacotes sabotando seus pacotes populares (Veja colors.js, faker.js[^6], e node-ipc[^7]),
ou malfeitores tentando lucrar fingindo ajudar a manter pacotes e corrompendo-os para roubar, por exemplo, chaves privadas de Bitcoin (Veja event-stream[^8]),
ou pacotes maliciosos com erros de grafia intencionais, também conhecidos como typosquatting,
na esperança de enganar os usuários para que os instalem, por exemplo, os pacotes NPM crossenv vs. cross-env[^npmjsCrossenv].
A integridade do software precisa ser garantida à medida que a indústria avança para um futuro onde os ativos digitais fazem parte do software.
Não podemos continuar vulneráveis a malfeitores modificando o software.
A maioria das ferramentas que chamamos de gerenciadores de pacotes não pode garantir que esses pacotes integrados nos aplicativos e dApps sejam o código de código aberto não adulterado publicado por seus autores originais.
O GitHub da Microsoft descobriu que 17% das vulnerabilidades de software foram implantadas com propósitos maliciosos[^9], sendo que algumas permaneceram não detectadas por longos períodos (Veja Webmin 1.890[^10]).
Um registro descentralizado, complementado por um sistema de reputação e apoiado por incentivos econômicos projetados para expor malfeitores e recompensar benfeitores, pode oferecer as garantias que as comunidades de desenvolvedores têm procurado.
[^5]: Fonte: @theregister
[^6]: Fonte: @fossa
[^7]: Fonte: @lunasec
[^8]: Fonte: @github
[^npmjsCrossenv]: Fonte: @npmjsCrossenv
[^9]: Fonte: @zdnet
[^10]: Fonte: @threatpost
## O sistema de Amarzenamento
Pacotes de código aberto oferecem uma ampla gama de funcionalidades, algumas das quais podem ser restritas ou indesejadas.
A criptografia é um excelente exemplo disso.
Um caso de uso crítico para a criptografia é o suporte à privacidade das pessoas em todo o mundo.
No entanto, a criptografia também pode ser usada para fins nefastos (Veja Phantom Secure, desmantelada por agências de aplicação da lei em março de 2018[^11]) ou pode ser comprometida para apoiar atividades de aplicação da lei (Veja Operação Ironside (AFP), Operação Greenlight (Europol),
e Operação Trojan Shield (FBI)[^12] onde o FBI operava uma plataforma de comunicação "criptografada", AN0M, e convenceu criminosos a usar seus telefones "criptografados" para comunicação segura.
As amplas aplicações da criptografia a tornaram um caso de uso perfeito para software de código aberto e um ótimo exemplo de que qualquer solução que armazene pacotes deve ser à prova de manipulações e resistente à censura.
O tea é um protocolo descentralizado que não tem a intenção de filtrar ou sancionar pacotes com base em sua funcionalidade.
Embora a governança do tea possa optar por remover pacotes comprovadamente maliciosos (consulte a seção de governança para mais informações), é fundamental para o sistema tea se conectar a vários sistemas de armazenamento, incluindo sistemas descentralizados que demonstrem que um pacote não foi alterado e está corretamente replicado.
Os mantenedores de pacotes podem escolher o sistema de armazenamento mais adequado às suas necessidades para armazenar e distribuir seus pacotes de forma segura.
[^11]: Fonte: @fbi
[^12]: Fonte: @europol
# Participantes da Rede
A missão do tea é capacitar comunidades de código aberto e garantir que seus contribuintes sejam apoiados enquanto criam as ferramentas que constroem a Internet.
Neste livro branco, distinguimos os participantes por meio de suas contribuições.
Alguns podem contribuir com código ou verificar o código contribuído.
Outros podem fornecer valor econômico para apoiar os desenvolvedores e sua reputação.
## Package Maintainers
Os mantenedores de pacotes devem garantir que seu software continue entregando valor crescente à medida que a indústria evolui.
O tea assume que os criadores de pacotes mantêm seu trabalho.
Os mantenedores de pacotes são pilares das comunidades de código aberto que precisam ser capacitados e recompensados por suas contribuições contínuas.
Um mantenedor de pacote pode decidir interromper seus esforços de manutenção ou perceber que não pode operar no mesmo ritmo das expectativas dos usuários do pacote.
Os mantenedores de pacotes recebem um token não fungível (NFT) quando concluem uma submissão de pacote (consulte a seção de NFT do mantenedor para detalhes adicionais).
Este NFT é usado para comprovar seu trabalho e é a chave que direciona as recompensas do tea.
O detentor do NFT de um pacote pode transferir sua propriedade para outro desenvolvedor (ou grupo de desenvolvedores), tornando-os assim mantenedores do pacote e receptores de quaisquer recompensas futuras.
Da mesma forma, um desenvolvedor pode decidir assumir o papel de mantenedor de pacote ao bifurcar o pacote existente e submeter um novo pacote que eles manterão no futuro, tornando-se assim tanto criador quanto mantenedor do pacote.
É essencial fornecer às comunidades de desenvolvedores as ferramentas adequadas para determinar quais pacotes estão sendo mantidos, bem como a reputação passada e presente dos mantenedores e a qualidade do trabalho.
Com frequência, vimos trabalhos de código aberto sendo adulterados e os esforços de muitos arruinados por malfeitores.
Embora o trabalho desses malfeitores seja em grande parte descoberto e remediado, muitas vezes isso só ocorre depois que danos significativos foram causados, seja por perda financeira ou de dados.
Veja, por exemplo, o pacote npm EventStream[^13] que foi baixado mais de 1,5 milhão de vezes por semana e era utilizado por mais de 1.500 pacotes, quando um hacker conseguiu penetrar no projeto de código aberto, ganhar a confiança de seu autor original e modificar o EventStream para depender de um pacote malicioso que exfiltraria credenciais de carteiras de bitcoin para um servidor de terceiros.
Embora ferramentas possam ajudar a detectar alguns desses ataques, nem sempre se pode depender delas, o que cria uma comunidade inteira dependente da diligência e vontade de compartilhar descobertas uns dos outros.
Propomos a introdução de incentivos por meio do token tea descrito na seção do token tea, incentivando comunidades de código aberto a relatar construtivamente suas descobertas, para que os mantenedores de pacotes possam abordá-las antes que sejam exploradas.
[^13]: Fonte: @medium
## Usuários de Pacotes
Os usuários de pacotes são desenvolvedores de software focados em resolver um problema específico.
Muitas vezes, eles buscam na comunidade de código aberto as ferramentas de que precisam para experimentar rapidamente e iterar com custo mínimo ou nenhum, beneficiando-se diretamente do trabalho dos criadores e mantenedores de pacotes.
Tradicionalmente, um subconjunto pode ter optado por apoiar os mantenedores de pacotes por meio de doações ou outras formas de remuneração; no entanto, isso raramente foi o caso.
O patrocínio pode ser um sistema eficaz para apoiar o desenvolvimento de código aberto; no entanto, a remuneração geralmente não se estende a todas as dependências.
Essa limitação beneficia os favoritos e atrapalha a inovação e a construção de software.
Para prosperar como a base do desenvolvimento de software, o código aberto deve capacitar todos os desenvolvedores, sejam iniciantes ou especialistas, em todas as camadas da torre.
O objetivo do tea é manter os valores fundamentais do software de código aberto enquanto fornece um sistema descentralizado para remunerar os mantenedores de pacotes por seu trabalho.
Para cumprir essa missão, o tea pretende desenvolver — e incentivar outros a desenvolver — mecanismos para que os usuários de pacotes apoiem os mantenedores de pacotes por meio de casos de uso únicos do token tea, conforme descrito nas seções do token tea, trabalho futuro e esforço potencial da comunidade.
## Package Supporters and Sponsors
Na Web 2.0 e na web3, os apoiadores de pacotes frequentemente foram chamados de 'patrocinadores'. Eles são organizações ou usuários de pacotes que usam software de código aberto para construir seus produtos comerciais, filantropos que desejam apoiar o ecossistema ou empreendedores que procuram financiar equipes para desenvolver componentes de um sistema maior.
O tea propõe ampliar as comunidades de apoiadores de pacotes para toda a comunidade do tea, sejam organizações, desenvolvedores, usuários ou entusiastas da tecnologia.
O objetivo do tea é implementar mecanismos de incentivo descentralizados por meio de casos de uso exclusivos do token tea para que qualquer membro da comunidade do tea contribua para a sustentabilidade perpétua e o crescimento contínuo do código aberto.
Apoiadores de pacotes e patrocinadores são livres para decidir quais pacotes ou mantenedores de pacotes desejam apoiar com base em seu trabalho, crenças ou qualquer critério e métrica que influenciaria sua decisão.
Além disso, o apoio fornecido pelos apoiadores de pacotes e patrocinadores fluirá para as dependências de cada pacote, confiando implicitamente no mantenedor do pacote para fazer boas escolhas sobre sua pilha de tecnologia e usando essas informações para contribuir para sua reputação.
Desde que o mantenedor do pacote ofereça esse serviço, um apoiador de pacote e patrocinador pode receber um NFT de nível de suporte premium em troca, beneficiando-se de SLAs acelerados ou licenciamento mais flexível.
Além disso, apoiadores de pacotes e patrocinadores podem decidir apoiar pacotes ou mantenedores de pacotes e redirecionar automaticamente todas ou parte de suas recompensas para incentivar equipes a construir novo software de código aberto.
Em outras palavras, os pacotes não precisam existir para que o tea comece a contribuir.
Projetos incipientes podem ser apoiados da mesma forma que os mais maduros, incentivando ainda mais um cenário de código aberto em constante evolução.
## tea Tasters
À medida que novos pacotes ou novas versões de pacotes existentes são lançados, a validade do trabalho precisa ser demonstrada de forma comprovável.
Essas informações são essenciais para os usuários de pacotes decidirem se confiam ou não tanto no pacote quanto em seus mantenedores.
Com o protocolo tea, essa função é fornecida pelos tea tasters.
Os tea tasters, geralmente, são desenvolvedores de software experientes dispostos a dedicar parte do seu tempo para verificar as reivindicações associadas a um pacote (funcionalidade, segurança, versionamento semântico[^14], precisão da licença, etc.) e apostar tanto sua reputação quanto valor econômico para demonstrar o resultado de suas pesquisas e análises e apoiar suas avaliações.
Os tea Tasters recebem recompensas por sua diligência e esforços.
No tea, chamamos de 'infusão do seu tea' a ação de bloquear tokens tea para apoiar suas análises e receber recompensas (ou penalidades) com base no consenso sobre a validade de suas avaliações.
Assim como os apoiadores de pacotes, os tea Tasters podem influenciar a reputação de um pacote e de um mantenedor de pacote; no entanto, seu impacto é mais significativo devido ao papel na validação da segurança, funcionalidade e qualidade de um pacote.
Os tea Tasters também precisarão construir sua reputação para apoiar suas alegações.
A qualidade de seu trabalho e o valor econômico que arriscam ao fazer suas análises, combinados com outras fontes externas de dados, construirão a reputação de cada tea Taster, agregando mais valor ao seu trabalho.
Consulte a seção de reputação de pacotes para mais detalhes sobre os mecanismos usados para influenciar a reputação de um pacote e de um mantenedor de pacote.
[^14]: Veja: @semver
# Visão Geral do Protocolo
O design de um protocolo para recompensar contribuições de código aberto é repleto de desafios.
O software de código aberto, por definição, está aberto a todos e, como resultado, pode ser alvo de má atribuição, apropriação ou manipulação maliciosa.
No entanto, a comunidade de código aberto consistentemente demonstrou disposição para destacar benfeitores e expor os maus.
Historicamente, o tempo gasto revisando e comentando as contribuições de outros desenvolvedores tem sido estritamente voluntário, apesar de quão demoradas e cruciais podem ser as atividades de relatar e defender descobertas.
Nossa intenção é criar uma plataforma de distribuição sem confiança para aplicativos protegidos por reputação e incentivos financeiros, pois acreditamos que recompensas adequadas para contribuições de código aberto não podem ter sucesso sem um sistema de reputação e a capacidade dos membros da comunidade de comunicar suas descobertas e apoiar (ou discordar) de um pacote ou do trabalho de um desenvolvedor.
Devemos fornecer aos desenvolvedores ferramentas para acessar e contribuir para esse sistema de reputação.
Ferramentas que incluam acesso visual e programável à versão e reputação de todas as dependências em seus pacotes.
Um entendimento claro de quais membros da comunidade apoiam cada pacote e quantos tokens tea estão sendo utilizados contribuirá para a reputação de cada pacote, assim como quanto um mantenedor de pacote está investindo em seu trabalho comunica o quanto eles o apoiam.
Esses pontos de dados combinados ajudarão a informar um sistema de reputação para todos os membros da comunidade e facilitarão a escolha.
Como o hack do pacote EventStream não foi conduzido pelo pacote em si, mas por meio de uma de suas dependências, a visibilidade em todas as camadas de dependências será vital para construir esse sistema sem confiança.
No entanto, considerações como custos de computação e transação ("gas") precisarão ter prioridade à medida que o sistema for projetado e construído.
Nosso objetivo é recompensar tanto os desenvolvedores da Web 2.0 quanto da web3.
As complexidades e especificidades de cada pilha tecnológica tornam possível que o rastreamento de instalações e desinstalações de pacotes possa facilmente ser vítima de um ou mais malfeitores, incluindo a "compra" de instalações para inflar artificialmente os números.
Um cenário ainda pior seria introduzir mudanças fundamentais na natureza do software de código aberto, criando fricção desnecessária com chaves de licença ou outros mecanismos de rastreamento de implantação.
Para oferecer a maior cobertura possível, acreditamos que as recompensas não devem depender de uma noção simplista de rastreamento de instalações ou desinstalações, mas sim de mecanismos de incentivo que incentivem a submissão de pacotes de qualidade e a denúncia de pacotes maliciosos ou de alto risco.
Por fim, muitos pacotes dependem de dependências comuns.
Por exemplo, o Lodash tem 151.209 dependentes[^15] enquanto o chalk tem 78.854 dependentes[^16] e o Log4js tem 3.343 dependentes[^17].
À medida que mais pacotes são criados usando as mesmas dependências, como garantimos que os incentivos sejam distribuídos de forma justa e equitativa?
Como garantimos que as dependências mais utilizadas sejam recompensadas sem prejudicar os novos ou emergentes pacotes e desenvolvedores?
Como garantimos que o sistema de incentivo não acabe direcionando os desenvolvedores longe de linguagens de nicho para centralizá-los onde os incentivos são melhores?
Mas também, como desenvolvedores, como identificamos pacotes com o maior número de dependentes para construir alternativas - versões mais enxutas, mais eficientes e melhor codificadas desses pacotes?
No tea, acreditamos que a falta de incentivo tem impedido a evolução do software de código aberto.
Com os incentivos econômicos e recompensas certas, mais desenvolvedores estarão em posição de construir, melhorar e ampliar o software de código aberto para o benefício do mundo.
Somente então o token tea será capaz de representar o valor total do software de código aberto.
[^15]: Fonte: @npmjsLodash
[^16]: Fonte: @npmjsChalk
[^17]: Fonte: @npmjsLogFourjs
## Submissão de Pacote
A submissão de um lançamento de pacote requer múltiplas transações para ocorrerem atomicamente.
Especificamente, o mantenedor do pacote deve:
* Registrar o pacote (e sua versão semântica) no registro descentralizado.
* Fazer upload do pacote no sistema de armazenamento descentralizado para resiliência, resitência à censura e facilidade de distribuição.
* Contribuir para a reputação e confiabilidade do pacote 'infundindo' tokens tea.
O fracasso de qualquer uma das três operações resultará no protocolo revertendo para seu estado anterior, eliminando assim qualquer evidência da submissão.
Quando um pacote é submetido com sucesso, o mantenedor do pacote receberá um NFT de mantenedor para evidenciar seu trabalho e contribuição para o código aberto.
O mantenedor do pacote pode transferir as recompensas de 'infusão' associadas ao NFT do mantenedor para um terceiro.
No entanto, a reputação associada à criação e manutenção do ativo permanecerá com o mantenedor do pacote, de modo que sua reputação possa ser afetada ao longo do tempo.
Conforme a reputação de qualquer membro da comunidade do tea atinge marcos importantes, eles podem receber acesso a partes elevadas do protocolo ou receber recompensas aceleradas, conforme decidido pela governança do tea.
Para mais detalhes sobre o NFT do mantenedor, consulte a seção do NFT do mantenedor.
### Análise de Dependências
As dependências de pacotes podem ser extensas, já que cada pacote frequentemente possui dependentes e dependências.
Para fornecer uma metodologia simples que recompense todos os desenvolvedores que contribuíram para o software de código aberto, mantendo a criação da árvore de dependências rápida e computacionalmente eficiente, propomos verificar apenas as dependências de primeiro nível ao submeter um pacote.
Este design é baseado na hipótese de que cada dependência é, por si só, um pacote que foi submetido independentemente para a árvore do tea.
Ao fazer isso, cada uma de suas dependências pode ser mapeada e, se suas dependências também tiverem dependências, essas serão mapeadas no momento em que o pacote de dependência for submetido
{#fig:dep-analysis}
Na @fig:dep-analysis, a submissão do pacote A aciona uma análise das dependências de tempo de execução 1 até n e das dependências de compilação 1 até n, enquanto as dependências de tempo de execução 1.1 até 1.n e as dependências de compilação 1.1 até 1.n foram analisadas quando o pacote B foi submetido.
Aplicaremos a mesma metodologia para a distribuição de incentivos, já que os tokens infundidos são distribuídos entre todas as dependências, infundindo recursivamente os pacotes listados como dependências (ver @fig:steeping-rewards).
{#fig:steeping-rewards}
Versionamento e dependências conflitantes são desafios significativos, e solucioná-los pode se tornar uma enorme perda de tempo.
Para lidar com isso, propomos que cada pacote seja submetido a uma varredura abrangente de dependências ao ser enviado, para garantir que o pacote esteja em conformidade com as seguintes regras para intervalos de versão semântica.
* Pacotes podem apenas restringir suas dependências para uma versão principal, embora o início do intervalo possa ser qualquer versão semântica válida (por exemplo, >=5.2.1 <6).
* Se uma dependência for atualizada para uma versão principal mais recente, o tea pode exigir que a versão principal do pacote seja aumentada.
* Da mesma forma, se uma dependência for atualizada para uma versão secundária mais recente, o tea pode exigir que a versão secundária do pacote seja aumentada.
* Se uma nova dependência for adicionada, o tea pode exigir que a versão secundária do pacote seja aumentada.
Considerando o esforço desnecessário imposto a qualquer usuário de pacote quando as regras acima são desrespeitadas, propomos que uma parte dos tokens tea infundidos pelo mantenedor do pacote seja reduzida para refletir a falta de diligência adequada.
Se um desenvolvedor obriga todos a malabarismar com suas xícaras, alguém vai derramar chá.
Como espera-se que a varredura de dependências ocorra na submissão, devemos observar que nenhuma infusão dos apoiadores de pacotes e patrocinadores, ou dos tea Tasters, terá ocorrido.
## A reputação do Pacote e do Mantenedor do Pacote
Os mantenedores de pacotes devem contribuir para a reputação e confiabilidade de seus pacotes infundindo tokens tea.
No entanto, um sistema de reputação que depende exclusivamente da contribuição econômica do autor não oferece proteção suficiente ao usuário e pode estar sujeito a ataques Sybil, nos quais um único indivíduo cria várias representações de si mesmo para deixar um grande volume de avaliações positivas sobre seu trabalho, enganando os usuários a acreditarem que seu trabalho foi revisado e aprovado por muitos.
Várias metodologias estão disponíveis para evitar ataques Sybil, algumas das quais são descritas por Nitish Balachandran e Sugata Sanyal em "A Review of Techniques to Mitigate Sybil Attacks"[^18].
Como o tea é um protocolo descentralizado, o uso de um sistema de certificação de confiança que depende de uma autoridade centralizada de emissão de certificados seria contrário ao seu cerne.
Propomos focar em abordagens descentralizadas para mitigação de ataques Sybil e, mais especificamente, em metodologias que dependem de um grande grupo de participantes da rede incentivados a avaliar e representar publicamente a reputação de cada pacote e seu mantenedor.
Similar à produção de blocos em uma blockchain de prova-de-participação, onde nós não produtores podem validar o trabalho de outros e, quando necessário, destacar uma violação das regras da rede, o que leva à penalização do malfeitor por meio de redução (destruição de uma parte de sua participação),
propomos um sistema no qual terceiros (também conhecidos como tea Tasters) seriam capazes de revisar pacotes produzidos por mantenedores de pacotes e seriam economicamente incentivados a agir no melhor interesse da comunidade de software de código aberto e de seus usuários, reconhecendo comportamentos bons e penalizando os ruins.
Este sistema deve ser resistente a ataques Sybil e impedir que grandes detentores de tokens influenciem materialmente o protocolo ou a reputação de pacotes específicos.
Acreditamos que essa abordagem está mais alinhada com o código aberto, fornecendo um substrato mais fértil para promover adoção e confiança e, por fim, facilitar o crescimento do tea.
[^18]: Fonte: @arxiv
## Revisão de Pacotes por Terceiros
A revisão de pacotes por terceiros é um componente essencial na construção de reputação, no entanto, a revisão de terceiros possui seu próprio conjunto de ameaças exclusivas, incluindo os ataques Sybil mencionados anteriormente.
A tecnologia blockchain, e mais explicitamente o staking, oferece uma oportunidade única para o tea lidar com esse desafio.
Embora os endereços de carteira possam estar disponíveis em quantidades infinitas, esse não é o caso dos tokens tea, cujo fornecimento inicial é esperado para ser de 10 bilhões.
Além disso, cada ação realizada pelos desenvolvedores, como submeter pacotes, verificar pacotes ou infundi-los, contribuirá para sua reputação, criando assim um perfil único para cada desenvolvedor usar tanto para contribuir para a comunidade do tea quanto para participar da governança do tea.
Ao exigir que os revisores de terceiros infundam tokens tea e incorram no risco de perder uma parte dos tokens infundidos caso se comportem contra o interesse da rede ou sejam malfeitores, os terceiros podem fornecer credibilidade adicional a um pacote e receber uma recompensa na forma de tokens tea.
Também propomos estender o sistema de reputação para os terceiros que realizam a verificação independente de pacotes - os tea Tasters.
A conclusão de uma revisão positiva exigirá que duas operações ocorram de forma atômica:
* A submissão da revisão de código, assinada pelo tea Taster e acessível publicamente a todos os membros da comunidade, juntamente com
* O ato de infundir "para" o pacote (em vez de "contra" o pacote), para substantiar sua revisão.
A conclusão de uma revisão negativa que inclui uma ou mais vulnerabilidades críticas exigirá que os tea Tasters primeiro entrem em contato com o mantenedor do pacote usando um protocolo de mensagens para notificá-los da vulnerabilidade e permitir que eles abordem o problema de forma oportuna.
Após o vencimento do período definido pela governança atribuído ao mantenedor do pacote para abordar sua vulnerabilidade ou quando o pacote corrigido estiver disponível, o mesmo protocolo de mensagens será usado para notificar todos os usuários e testadores deste pacote (incluindo dependentes) que uma vulnerabilidade foi identificada,
e esperançosamente resolvida, para que saibam atualizar sua aplicação ou dependências.
Para desincentivar o desperdício de tempo dos desenvolvedores, a comunicação entre os tea Tasters e os mantenedores de pacotes exigirá que os tea Tasters infundam tokens tea.
Ao concluir ambas as operações, os tea Tasters receberão um NFT como prova de seu trabalho no pacote específico e na versão do pacote. O acúmulo de NFTs combinado com a taxa de infusão de cada um dos pacotes revisados e informações extraídas de sistemas externos informarão a reputação de um tea Taster.
Conforme sua reputação atinge marcos-chave, os tea Tasters podem ter acesso a partes elevadas do protocolo ou a recompensas aceleradas, conforme decidido pela governança do tea.
## Pacotes Desatualizados ou Corrompidos
A missão do tea é recompensar os contribuidores e participantes das comunidades de código aberto; no entanto, as recompensas devem ser proporcionais aos esforços empreendidos pelos mantenedores de pacotes e tea Tasters.
Pacotes mal mantidos, desatualizados ou corrompidos são indicações claras de que os mantenedores de pacotes não estão atendendo às expectativas da comunidade ou não estão cumprindo a confiança e o apoio depositados neles por meio da infusão de pacotes.
Outra manifestação de pacotes desatualizados pode ser o uso contínuo de uma linguagem antiga ou de uma versão antiga de linguagens multiversão.
Pacotes permanecendo desatualizados ou corrompidos por muito tempo indicam que os tea Tasters precisam revisar regular e consistentemente o trabalho dos mantenedores de pacotes.
Os tea Tasters são membros críticos das comunidades de código aberto, pois suas revisões e reivindicações associadas podem orientar os usuários de pacotes na direção ou para longe de pacotes.
Para garantir que as revisões possam ser confiáveis continuamente, propomos um mecanismo pelo qual pacotes desatualizados ou corrompidos possam ter uma parte de seus tokens infundidos enviados aos tea Tasters que foram os primeiros a reconhecer a falta de manutenção de qualquer pacote.
Qualquer revisão negativa que destaque uma falha, como uma vulnerabilidade zero-day ou o uso de uma dependência desatualizada e permaneça aberta após um período de carência definido pela governança, deve ser considerada uma falha por parte do mantenedor do pacote.
Eles não completaram a tarefa com a qual foram incumbidos e recompensados.
O mesmo vale para os apoiadores e patrocinadores do pacote que apostaram sua reputação no trabalho dos mantenedores de pacotes negligentes e receberam recompensas por isso, mas não identificaram a falta de manutenção ou optaram por continuar a apoiar o pacote, independentemente.
À medida que os pacotes ganham popularidade e uso, com mais aplicativos e sistemas potencialmente críticos dependendo deles, precisamos incentivar os desenvolvedores a relatar discreta e rapidamente falhas ao mantenedor do pacote e os mantenedores de pacotes a resolverem tais falhas antes que possam ser exploradas.
Consequentemente, propomos que qualquer pacote desatualizado ou corrompido que seja objeto de uma ou mais revisões negativas comprovadas e permaneça nesse estado após o período de carência definido pela governança tenha uma parte de seus tokens infundidos destruída, independentemente de sua origem (mantenedor do pacote, apoiadores e patrocinadores do pacote ou revisores anteriores de tea),
enquanto outra parte é enviada aos tea Tasters que enviaram as revisões negativas. A distribuição para todos os tea Tasters pode ser baseada na idade de suas revisões e na quantidade de tokens de tea que infundiram para suas revisões.
## Maintainer NFT
Após a submissão bem-sucedida de um pacote, o mantenedor do pacote receberá um NFT como prova de seu trabalho e contribuição.
O detentor deste NFT receberá automaticamente todas as recompensas associadas ao pacote.
Os mantenedores de pacotes podem transferir a propriedade da manutenção de um pacote para outro mantenedor de pacote simplesmente transferindo o NFT do pacote.
A transferência bem-sucedida do NFT levará o novo proprietário a receber automaticamente as futuras recompensas do pacote.
Uma parte importante da construção de reputação depende da frequência e quantidade de submissões de pacotes de qualidade.
O NFT entregue aos mantenedores de pacotes como evidência de seu trabalho pode ser usado pelo sistema de reputação para atualizar a reputação de um mantenedor de pacotes e dar a eles acesso a partes elevadas do protocolo, conforme decidido pela governança do tea.
No entanto, para prevenir vetores de ataque, como membros da comunidade comprando sua reputação, a transferência do NFT do mantenedor não resultará na transferência de reputação.
A reputação deve permanecer diretamente associada ao trabalho de um desenvolvedor específico e não pode ser transferida.
# Token tea
## Garantindo a Rede
Embora muitas blockchains possam parecer soluções de infraestrutura eficazes e seguras para apoiar os objetivos do tea, acreditamos que uma consideração cuidadosa deve ser dada à pilha de tecnologia sobre a qual o sistema tea é construído.
Escalabilidade, eficiência de custos, ESG e extensibilidade de terceiros são considerações importantes de design que um sistema de prova-de-participação soberano por meio do tea poderia melhor servir.
No modelo de prova-de-participação, os operadores de nós e os participantes da rede apostam valor econômico na forma do token nativo da cadeia para aumentar a segurança do sistema.
Os operadores de nós e os participantes da rede recebem recompensas pela produção bem-sucedida de blocos que estejam em conformidade com as regras da rede e incluam informações precisas de transações.
Inatividade (também conhecida como *node down*) ou atividade maliciosa/incorreta são penalizadas pela destruição de uma fração dos tokens apostados por meio de Slashing.
Um sistema de prova-de-participação alimentado pelo token tea permitirá que os detentores do token tea contribuam para a segurança do sistema apostando tea e apoiem os desenvolvedores de código aberto deixando tea.
Estamos totalmente cientes de que fatores econômicos podem impedir alguns desenvolvedores de apostar ou deixar tea; como tal, a aposta e o ato de deixar estarão disponíveis por tão pouco quanto uma folha, a menor denominação de tea, representando um centésimo de um bilionésimo ($10^{-8}$) de um tea.
Ambos os usos do token tea têm funções vitais no suporte e crescimento do ecossistema de código aberto.
O staking de tea garantirá que o sistema tea continue a operar de forma segura, para que todos os participantes da rede possam enviar e acessar pacotes para revisá-los, integrá-los em suas aplicações, etc.
Por outro lado, o ato de infusão tea apoiará o objetivo do tea de fornecer ferramentas para todos os participantes da rede apoiarem e usarem pacotes que atendam aos requisitos de qualidade e confiabilidade, conforme formulado pela comunidade tea por meio de seu apoio e objeção a cada pacote.
Será tomado cuidado ao definir e implementar os parâmetros de aposta e de deixar para que um não se torne parasitário do outro.
## Incentivos e Penalidades
Como discutido anteriormente, há fortes incentivos para malfeitores comprometerem o software de código aberto.
A maioria da infraestrutura crítica da internet está rodando em código aberto, e a corrida para encontrar exploits e outras vulnerabilidades está em curso.
No tea, acreditamos que os mantenedores de pacotes não devem ser culpados (embora muitas vezes o sejam).
Os incentivos do protocolo tea corrigem isso por meio de uma distribuição justa e equitativa de incentivos.
Um pacote como o Lodash, com mais de 151 mil dependentes, é um pilar do desenvolvimento de código aberto, e seu mantenedor merece ser recompensado proporcionalmente.
No entanto, um sistema de recompensa baseado unicamente no número de dependentes impediria inovadores de interromper esses monopólios, a menos que sejam financiados suficientemente por terceiros ou já tenham acumulado recursos suficientes para se autofinanciar.
Essa abordagem provavelmente levaria a uma redução no número de contribuintes, resultando no oposto do que o tea pretende.
O objetivo do tea é representar o valor do software de código aberto e, ao fazê-lo, promover seu crescimento capacitando seus participantes com os recursos necessários para perseguir sua paixão sem obstáculos.
O sistema de distribuição de incentivos do tea precisa considerar cuidadosamente a taxa de "deixar" de cada pacote e ajustar os incentivos de cada pacote de acordo.
Para reduzir o risco de um pequeno número de pacotes, usados como dependências em muitos aplicativos, coletarem a maioria das recompensas de "deixar", vamos aproveitar a pesquisa produzida pela Fundação Web3[^19] para o mecanismo de recompensas baseado em prova-de-participação do Polkadot.
Podemos ajustar ainda mais a implementação e suas variáveis com base nos resultados de experimentos práticos.
À medida que um pacote se aproxima de uma taxa de "infusão" ideal definida pela governança, sua proporção de recompensas de "infusão" diminuirá progressivamente.
Quando um pacote excede sua taxa de "infusão" ideal, a proporção de recompensas de "infusão" diminuirá acentuadamente para desincentivar os apoiadores do pacote e os tasters de deixar ainda mais pacotes altamente infundidos.
Esse design poderia tornar pacotes menos infundidos mais atraentes tanto para apoiadores quanto para tasters.
Também pode incentivar desenvolvedores experientes a criar alternativas para pacotes altamente infundidos, criando uma oportunidade para a comunidade tea equilibrar o suporte ao software existente e promover a inovação.
A taxa de "infusão" será calculada usando o suprimento circulante em seu design inicial.
A comunidade tea pode alterar esse design para aprimorar ainda mais a escalabilidade do sistema.
Seja $\chi$ a taxa de "deixar" em todos os pacotes.
Ela representa o número total de tokens de tea infundidos pelos mantenedores de pacotes, usuários de pacotes, apoiadores e patrocinadores de pacotes, e tasters de tea dividido pelo suprimento total de tokens de tea.
Dado quantos pacotes de código aberto estão disponíveis hoje e seu crescimento esperado, $\chi$ será sempre um valor muito pequeno entre $0$ e $1$.
Considere $\psi$ como a taxa de staking.
Ela representa o número total de tokens de ea apostados por qualquer participante da rede para garantir a segurança da rede.
Considere $\chi_{ideal}$ como a taxa de infusão que gostaríamos que cada pacote alcançasse para uma distribuição justa de recompensas entre todos os pacotes e suas dependências.
O valor de $\chi_{ideal}$ deve ser atualizado à medida que novos pacotes são adicionados ao registro descentralizado e dependências são criadas.
Para determinar o melhor valor para $\chi_{ideal}$, usaremos uma curva de popularidade atualizada no início de cada ciclo de recompensas.
Considere $\tau = \tau(\chi)$ como a taxa de juros anual de infusão distribuída a todos os membros da comunidade de tea que infundem tokens de tea para apoiar desenvolvedores de código aberto.
Em outras palavras, $\tau(\chi)$ corresponde à recompensa de infusão recebida ao longo de um ano por um membro da comunidade que infunde tokens de tea durante todo o ano.
Considere $\gamma = \gamma(\psi)$ como a taxa de juros anual de staking distribuída a todos os operadores de *nodes* e participantes da rede que apostam tokens de tea para garantir a rede.
Em outras palavras, $\gamma(\psi)$ corresponde à recompensa de staking recebida ao longo de um ano por um membro da comunidade que aposta tokens de tea durante todo o ano.
Considere $\delta$ como a inflação anual direcionada ao tesouro da rede.
$\delta$ pode variar à medida que fatores externos afetam o fornecimento de tokens.
Consideramos a taxa de recompensa anual de infusão como uma função de $\chi$ e a taxa de recompensa anual de staking como uma função de $\psi$.
* $\tau(\chi)$ corresponde ao incentivo para as pessoas infundirem um pacote.
Conforme $\chi$ aumenta, são necessárias menos recompensas $\tau(\chi)$.
* $\gamma(\psi)$ corresponde ao incentivo para as pessoas apostarem na rede.
Conforme $\psi$ aumenta, são necessárias menos recompensas $\gamma(\psi)$ para garantir a rede
A inflação anual $I$ será equivalente a $(\tau + \gamma + \delta)$ e calculada da seguinte forma
$$
I = \frac{\textrm{oferta de tokens no final do ano} - \textrm{oferta de tokens no início do ano}}{\textrm{oferta de tokens no início do ano}} = (\tau + \gamma + \delta)
$$
A contribuição para a inflação de $\tau_{\textsc{all}}$ (incentivo distribuído a todos os infusores de pacotes) e $\gamma_{\textsc{all}}$ (incentivo distribuído entre todos os contribuidores para a segurança da rede) deve ser ponderada para garantir que o sistema incentive a proporção ideal de infusão/aposta.
Enquanto focamos nos incentivos distribuídos a todos os infusores de pacotes, determinamos que
$\tau_{\textsc{all}}$
é uma função da taxa de infusão $\chi$ e, portanto,
$\tau_{\textsc{all}}(\chi) = \chi \cdot \tau(\chi)$.
A partir de nossa análise anterior, podemos ver que
$\tau_{\textsc{all}}(\chi_{ideal}) = \chi_{ideal} \cdot \tau_{ideal}$.
Uma vez que o objetivo é atingir um estado onde
$\chi = \chi_{ideal}$
, as recompensas
$\tau_{ideal}(\chi)$
devem ser máximas nesse valor.
Considere $\tau_{ideal} = \tau(\chi_{ideal})$
como a taxa de recompensa entregue pela rede no cenário ideal onde
$\chi = \chi_{ideal}$.
Considere $\tau_{0}$ como o limite de $\tau_{\textsc{all}}(\chi)$ quando $\chi$ tende a zero, quando nenhum membro da comunidade de tea infunde pacotes.
O valor de $\tau_{0}$ deve ser próximo de zero, mas não zero, para incentivar os primeiros adotantes.
Conforme sugerido pela pesquisa da Web3 Foundation, propomos que:
* a função de inflação cresça linearmente entre $\chi = 0$ e $\chi = \chi_{ideal}$, e
* decaia exponencialmente entre $\chi = \chi_{ideal}$ e $\chi = 1$.
Escolhemos um decaimento exponencial semelhante para $\tau_{\textsc{all}}(\chi)$ porque implica um decaimento exponencial de $\tau(\chi)$, e queremos que as recompensas caiam abruptamente além de $\chi_{ideal}$ para evitar que um único pacote receba todas as recompensas.
O decaimento é definido para que a taxa de inflação diminua no máximo em 50% quando $\chi$ se desloca $d$ unidades à direita de $\chi_{ideal}$ – ou seja,
$\tau_{\textsc{all}}(\chi_{ideal} + d) \geq \tau_{\textsc{all}} \cdot 0.5$.
Propomos as seguintes funções de taxa de juros e inflação, que dependem dos parâmetros $\chi_{ideal}$, $\tau_{ideal}$, $\tau_{0}$ e $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*}
Assim como os benfeitores precisam ser recompensados, os malfeitores precisam ser identificados e penalizados.
O software de código aberto oferece muitas oportunidades para malfeitores criarem pontos de dor e riscos reputacionais para toda uma comunidade de desenvolvedores.
Desde a apropriação indébita de trabalho até a alteração e redistribuição de pacotes de software, ou a inserção de código malicioso, a guerra entre bons e malfeitores continua, muitas vezes com malfeitores bem financiados que veem a contaminação de pacotes de código aberto como uma oportunidade de lucrar financeiramente.
As consequências têm sido relativamente mínimas, com pacotes potencialmente banidos das prateleiras digitais ou sujeitos a uma má reputação.
Propomos a introdução de um mecanismo de corte para estabelecer uma desvantagem mais significativa que afete diretamente o valor econômico dos malfeitores.
Conforme os tea tasters avaliam e analisam o código nos pacotes recém-submetidos, sugerimos que recebam ferramentas e incentivos para identificar e destacar códigos maliciosos, de forma que os usuários dos pacotes possam ser alertados sobre os riscos, e os mantenedores do pacote, apoiadores do pacote e patrocinadores sejam penalizados por submeter ou apoiar código malicioso.
Nesse sentido, para todas as avaliações negativas evidenciadas conforme as regras da rede e que foram tratadas pelo mantenedor do pacote dentro do período definido pelo governo, o mantenedor do pacote não deve incorrer em nenhuma penalidade contrária aos apoiadores do pacote e patrocinadores, ou dos tea tasters que forneceram uma avaliação positiva do pacote em questão.
Para avaliações negativas realizadas de acordo com as regras da rede e que o mantenedor do pacote não tenha abordado dentro do período definido pela governança, uma fração dos tokens infundidos pelo mantenedor do pacote, pelos apoiadores do pacote e patrocinadores, e pelos tea tasters anteriores será cortada.
Outra fração será bloqueada em um pool de seguro controlado pela governança do tea.
A governança do tea estabelecerá políticas e regras em estreita colaboração com a comunidade para distribuir o conteúdo do pool para aqueles afetados por vulnerabilidades.
O protocolo distribuirá uma terceira fração dos tokens infundidos entre todos os tea tasters que contribuíram para a avaliação negativa e infundiram "contra" o pacote, com base no número de tokens de tea que infundiram "contra" o pacote e quanto tempo esses tokens foram infundidos.
Em outras palavras, quanto mais cedo um ou mais tea tasters identificarem e relatarem a falha de acordo com as regras da rede, maior será a recompensa que receberão por apoiar o desenvolvimento de código aberto seguro e produtivo.
Para evitar que os membros da comunidade votem aleatoriamente "contra" pacotes altamente infundidos na esperança de receber a maioria de qualquer penalidade, todos os tokens de tea infundidos "contra" não serão recompensados com inflação e podem estar sujeitos a um mecanismo de decaimento, reduzindo assim seu valor ao longo do tempo.
[^19]: Fonte: @web3
# Governança
A governança é fundamental para o desenvolvimento, sustentabilidade e adoção de qualquer sistema distribuído.
Propomos que o tea inclua uma governança on-chain, onde todos os detentores de tokens de tea possam sugerir e votar em mudanças nos parâmetros críticos ponderados pela posse de tokens e reputação.
Esses parâmetros podem incluir inflação, taxas de transação, recompensas de staking, recompensas de infusão ou a proporção ideal de infusão.
Essa funcionalidade garantirá que os parâmetros críticos possam evoluir e ser otimizados ao longo do tempo pelos membros da comunidade de tea.
Antecipamos que a governança será lançada com uma estrutura simples e se expandirá progressivamente à medida que o sistema tea amadureça, facilitando a adoção e garantindo uma descentralização progressiva.
Alguns parâmetros do sistema podem não estar sujeitos à governança ou apoiar mudanças de alta frequência para reduzir a superfície de ataque representada pela governança.
Uma transição progressiva dos parâmetros para uma governança aberta e descentralizada garantirá a estabilidade e previsibilidade do sistema.
# Extensibilidade de Terceiros
Enquanto construímos as ferramentas iniciais para impulsionar o suporte há muito esperado das comunidades de código aberto, acreditamos que parte de nossa missão é garantir que terceiros possam expandir o conjunto de ferramentas como um todo.
Além de fornecer a infraestrutura para os desenvolvedores criarem extensões para o protocolo, incluindo novas formas de inovar e ampliar o apoio aos desenvolvedores de código aberto, nossos planos incluem o potencial para outros gerenciadores de pacotes contribuírem para o protocolo.
Os sonhos e esforços dos desenvolvedores de código aberto construíram a inovação que sustenta nossa vida cotidiana.
Estamos ansiosos para descobrir os novos usos e extensões para o tea propostos pela comunidade tea.
# Trabalho Futuro e Possíveis Esforços Comunitários
À medida que o sistema tea amadurece, prevemos que a comunidade decida e contribua para alterações e extensões do sistema tea por meio da governança.
Abaixo estão algumas ideias que acreditamos que possam inspirar alguns.
## Atacadistas de tea
As comunidades de software de código aberto são vibrantes e estão sempre em busca de inovação e entrega de valor.
Esta dedicação e altruísmo levam à constante construção de novos softwares e pacotes, cada um puxando dependências. Como resultado, antecipamos que o mapa de dependências evolua constantemente, levando a mudanças frequentes na proporção de infusão e recompensas.
No futuro, a comunidade tea pode propor o desenvolvimento de um sistema projetado para monitorar dinamicamente a proporção de infusão para cada pacote e reequilibrar como os apoiadores de pacotes infundem seus tokens com base em seus próprios critérios.
## Royalties em Transferência de Pacotes
Reconhecemos que os mantenedores de pacotes podem decidir transferir sua fonte de recompensas de infusão para um ou mais desenvolvedores.
A governança dessa transferência deve permanecer na decisão do mantenedor do pacote e de seus parceiros, sem interferência do tea.
Ferramentas serão necessárias para que essa transferência seja total ou parcial (talvez através de apenas uma parte das recompensas de infusão sendo redirecionada para um ou mais desenvolvedores, enquanto as recompensas restantes continuam a fluir para o mantenedor original do pacote)
e para que as recompensas de infusão fluam por meio de uma única conta controlada por um único participante da rede, vários participantes da rede ou sejam distribuídas automaticamente entre várias contas usando proporções estáticas ou dinâmicas.
## Distribuição de Recompensas Entre Múltiplos Mantenedores
A manutenção de um pacote pode depender do trabalho de uma ou mais equipes de desenvolvedores.
Antes que as recompensas de infusão comecem a fluir, as equipes devem considerar automatizar a distribuição das recompensas de infusão entre si.
Como a distribuição ocorre deve ser decidido pelos mantenedores, já que estão na melhor posição para avaliar quem contribuiu e como devem ser recompensados.
Para realizar isso, cada equipe (ou equipes) poderia criar sua própria organização autônoma descentralizada (DAO) e automatizar a distribuição de recompensas ou implementar sistemas mais complexos para determinar a distribuição adequada de recompensas com base em fatores externos, como um voto de todos os membros da DAO, ou distribuições baseadas no tempo com base em contribuições contínuas, conclusão bem-sucedida de recompensas, etc.
## Tratamento de "Forks" de Pacotes
Acreditamos que "forks" são essenciais e amplamente subutilizados.
"Forks" podem ser uma ferramenta eficaz para desenvolver pacotes que competem em funcionalidade, desempenho, segurança e até mesmo atenção.
Por mais úteis que possam ser, os "forks" devem reconhecer os esforços originais.
Através de trabalho futuro ou contribuições potenciais, a comunidade tea pode aprimorar o sistema para exigir que os "forks" sejam declarados, talvez até detectados quando um pacote é submetido.
"Forks" não declarados revelados por tea tasters podem resultar em uma parte dos tokens infundidos sendo cortados, transferidos para o mantenedor original do pacote e enviados aos tea tasters que revelaram o "fork"
## Dependências de Tempo de Compilação vs. Dependências de Tempo de Execução
O tea pode não distinguir as dependências de tempo de compilação das dependências de tempo de execução ao distribuir recompensas de infusão no lançamento.
No entanto, desde que a comunidade tea sinta fortemente a necessidade de fazer essa distinção, a comunidade tea pode propor melhorias ao algoritmo de distribuição de recompensas de infusão para considerar a criticidade de cada dependência e sua contribuição para o valor dos pacotes que dependem delas.
Essas propostas seriam votadas e implementadas com base na decisão da comunidade.
## Remuneração Baseada em Uso
À medida que mais aplicações são construídas usando pacotes registrados com o tea, a comunidade pode aprimorar o algoritmo de recompensa para que a alocação possa ser influenciada por conjuntos de dados externos atestados, como o uso.
Essa atualização do mecanismo de recompensas poderia permitir uma alocação maior de recompensas em tokens de tea para pacotes com o maior uso, ao mesmo tempo em que respeita as restrições da proporção de infusão descritas na seção de tokens de tea.
Os mantenedores de pacotes poderiam usar uma abordagem semelhante para distribuir recompensas de infusão entre suas dependências com base na lógica transparente de sua escolha.
Observe que todas as informações usadas para afetar a distribuição de recompensas entre pacotes e dependências no sistema tea precisarão ser comprovadamente confiáveis.
# Agradecimentos
Este white paper não existiria sem o apoio e dedicação de muitos entusiastas do tea.
Os autores gostariam de agradecer a Josh Kruger, Jadid Khan e Jacob Heider por sua contribuição para a economia dos tokens e aos muitos indivíduos discretos que voluntariamente dedicaram seu tempo para fornecer feedback sobre o conteúdo deste documento.
$\parskip=0pt plus 1pt$
# Glossário de Termos
| Termo | Definição |
|------|------------|
| Folha | A menor denominação do token de tea. Uma folha corresponde a uma centésima milionésima ($10^{-8}$) parte de um tea. |
| Slashing | A ação de penalizar infusores ou stakers em resposta a comportamentos contrários às regras da rede. |
| Staking | A ação de travar tokens de tea para garantir a rede de prova-de-participação na qual o sistema de tea é construído. |
| Infusão | A ação de travar tokens de tea para apoiar sua reivindicação e receber recompensas (ou penalidades) com base no consenso sobre a validade de sua reivindicação. |
# Referências
================================================
FILE: i18n/vi/metadata.yml
================================================
title: Giao thức trả thưởng phi tập trung cho hệ sinh thái mã nguồn mở
abstract: |-
Việc tạo một sổ đăng ký mở, công khai và có tính ổn định cho tất cả phần mềm
mã nguồn mở sẽ cấp quyền cho các dự án tự xuất bản các bản phát hành một cách
độc lập thay vì dựa vào các bên thứ ba, những người tập hợp dữ liệu phức tạp
này thành hàng trăm hệ thống riêng biệt (và trùng lặp). Những người bảo trì
gói sẽ xuất bản các bản phát hành của họ lên một sổ đăng ký phi tập trung
được cung cấp bởi chuỗi khối có khả năng chịu lỗi Byzantine để loại bỏ các
nguồn lỗi độc lập, cung cấp các bản phát hành bất biến và cho phép các cộng
đồng quản lý các khu vực của họ trong hệ sinh thái nguồn mở, độc lập với các
chương trình nghị sự bên ngoài.
Tea khuyến khích việc duy trì nguồn mở bằng cách cho phép những người tham
gia mạng stake giá trị vào các gói mà họ phụ thuộc và muốn bảo mật. Biểu đồ
của giao thức Tea cung cấp việc đăng ký các gói bất biến, các yêu cầu phụ
thuộc, tính xác thực của gói và các nguồn dữ liệu được sử dụng để truyền cho
thuật toán trả thưởng Tea. Lạm phát có hệ thống được phân phối cho tất cả các
gói dựa trên thuật toán đó. Nếu các vấn đề về bảo mật hoặc phát triển được
phát hiện, nhà phát triển có thể đưa ra yêu cầu được hỗ trợ bởi bằng chứng đó
và việc loại bỏ có thể xảy ra. Các thành viên của cộng đồng nguồn mở có thể
xem xét các vấn đề chất lượng của gói và giao thức có thể phản hồi các đánh
giá này bằng cách tạo các sự kiện sửa lỗi liên quan.
author:
- Max Howell
- Timothy Lewis
- Thomas Borrel
references:
- id: sources
url: https://github.com/teaxyz/white-paper
- id: cc
url: https://creativecommons.org/licenses/by-sa/4.0/
- id: nist
url: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- id: reuters
url: https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA
- id: twitter
url: https://twitter.com/yazicivo/status/1469349956880408583
- id: w3
url: https://www.w3.org/TR/did-core/
- id: theregister
url: https://www.theregister.com/2016/03/23/npm_left_pad_chaos/
- id: fossa
url: https://fossa.com/blog/npm-packages-colors-faker-corrupted/
- id: lunasec
url: https://www.lunasec.io/docs/blog/node-ipc-protestware/
- id: github
url: https://github.com/dominictarr/event-stream/issues/116
- id: zdnet
url: https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/
- id: threatpost
url: https://threatpost.com/backdoor-found-in-utility-for-linux/147581/
- id: fbi
url: https://www.fbi.gov/news/stories/phantom-secure-takedown-031618
- id: europol
url: https://www.europol.europa.eu/media-press/newsroom/news/800-criminals-arrested-in-biggest-ever-law-enforcement-operation-against-encrypted-communication
- id: medium
url: https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502
- id: semver
url: https://semver.org/
- id: npmjsCrossenv
url: https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html
- id: npmjsLodash
url: https://www.npmjs.com/package/lodash
- id: npmjsChalk
url: https://www.npmjs.com/package/chalk
- id: npmjsLogFourjs
url: https://www.npmjs.com/package/log4js/
- id: arxiv
url: https://arxiv.org/abs/1207.2617/
- id: web3
url: https://research.web3.foundation/en/latest/polkadot/overview/2-token-economics.html
header-includes:
- \usepackage{fancyhdr,ragged2e}
- \lhead{\parbox[t]{0.5\textwidth}{\RaggedRight\rightmark\strut}}
- \rhead{\parbox[t]{0.5\textwidth}{\RaggedLeft\leftmark\strut}}
- \setlength{\headheight}{5\baselineskip}
- \pagestyle{fancy}
- \fancyfoot[LE,RO]{© 2022 tea.inc.}
- \fancyfoot[L]{v1.0.5+vi}
lang: vi # https://pandoc.org/MANUAL.html#language-variables
dir: ltr # language direction; ltr:left-to-right or rtl:right-to-left
translator:
- Le Phuoc Can
================================================
FILE: i18n/vi/white-paper.md
================================================
# Tuyên bố miễn trừ trách nhiệm
Thông tin nêu trong sách trắng này là thông tin sơ bộ. Do đó, cả tác giả cũng như bất kỳ nhánh tương ứng nào của họ đều không chịu bất kỳ trách nhiệm nào rằng thông tin nêu ở đây là cuối cùng hoặc chính xác và mỗi tuyên bố từ chối trách nhiệm nêu trên, trong phạm vi tối đa được luật hiện hành cho phép, bất kỳ và tất cả trách nhiệm pháp lý cho dù phát sinh trong hợp đồng, hoặc mặt khác liên quan đến sách trắng này.
Sách trắng này cũng như bất kỳ nội dung nào trong tài liệu này sẽ không tạo thành cơ sở hoặc được dựa vào có liên quan đến hoặc hành động như một sự xúi giục kêu gọi để ký kết bất kỳ hợp đồng hay cam kết nào.
Không có nội dung nào trong sách trắng này cấu thành một đề nghị bán hoặc chào mời mua bất kỳ mã thông báo nào được thảo luận ở đây.
Trong bất kỳ trường hợp nào, liệu sách trắng này có được coi là một lời đề nghị hoặc lời chào mời như vậy không, không có lời đề nghị hoặc lời chào mời nào như vậy được dự định hoặc chuyển tải bởi sách trắng này ở bất kỳ khu vực tài phán nào nếu làm như vậy là bất hợp pháp,
khi lời đề nghị hoặc lời chào mời đó sẽ yêu cầu giấy phép hoặc đăng ký, hoặc khi đề nghị hoặc chào mời như vậy bị hạn chế. Đặc biệt, bất kỳ mã thông báo nào được thảo luận ở đây đều chưa được đăng ký theo chứng khoán hoặc luật tương tự của bất kỳ khu vực tài phán nào,
kể từ ngày phát hành sách trắng này, cho dù khu vực tài phán đó có coi các mã thông báo đó là là chứng khoán hoặc công cụ tương tự và không được cung cấp hoặc bán ở bất kỳ khu vực tài phán nào nếu làm như vậy sẽ cấu thành vi phạm luật liên quan của khu vực tài phán đó.
# Giấy phép
Mã nguồn[^src] của sách trắng này có sẵn theo giấy phép Creative Commons Attribution-ShareAlike 4.0 International[^cc].
[^src]: Xem thêm: @sources
[^cc]: Xem thêm: @cc
# Lời nói đầu
Internet chủ yếu bao gồm các dự án nguồn mở và chúng đã được thành lập.
Theo thời gian, nhiều dự án này đã trở thành những phần nền tảng mà tất cả các đổi mới trong tương lai được xây dựng.
Và trong khi vận may đã được tạo ra từ nó, nguồn mở chủ yếu được tạo ra và duy trì mà không cần trả phí.
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.
Chúng tôi tin rằng toàn bộ nỗ lực của con người hiện đại đã bị cản trở khi dựa vào phẩn ít các kỹ sư trên thế giới để lựa chọn giữa tiền lương hoặc duy trì hoạt động trên Internet.
Nguồn mở là lao động phi lợi nhuận thường bị cản trở do thiếu các động cơ về kinh tế dẫn đến các dự án thực sự đáng giá không bao giờ đạt được tiềm năng của chúng trong khi các dự án khác gặp vấn đề về bảo mật do thiếu các động lực để duy trì phần mềm trong suốt vòng đời của nó.
Để nhận ra đầy đủ tiềm năng của chúng tôi, chúng tôi cần một hệ thống trả thù lao công bằng cho hệ sinh thái nguồn mở mà không thay đổi về cơ bản cách nó được xây dựng hoặc sử dụng.
Các doanh nghiệp thường bao bọc các mô hình kinh doanh xung quanh mã nguồn mở, tạo doanh thu trực tiếp từ công việc của các nhà phát triển cốt lõi từ trong khi cũng dựa vào chúng để khắc phục lỗi khi xảy ra vấn đề.
Một ví dụ tuyệt vời là một sự cố gần đây liên quan đến lỗ hổng bảo mật quan trọng trong Log4j, một gói từ Quỹ phần mềm Apache đã tìm thấy trên nhiều phần mềm và dịch vụ thương mại được sử dụng bởi các doanh nghiệp và chính phủ.
Vào tháng 11 năm 2021, một nhà nghiên cứu bảo mật làm việc cho Alibaba Group Holding Ltd. đã báo cáo lỗ hổng CVE-2021-44228[^1], nhận được điểm cơ bản cao nhất có thể từ Quỹ phần mềm Apache. Amit Yoran, giám đốc điều hành của Tenable và Giám đốc sáng lập của đội ngũ sẵn sàng khẩn cấp máy tính Hoa Kỳ (US-CERT), đã mô tả lỗ hổng này là một lỗ hổng lớn nhất trong thập kỷ qua[^2].
Panic xảy ra sau đó và một vài tình nguyện viên duy trì gói này đã công khai bị sa thải vì thất bại.
Sau khi giải quyết sự phẫn nộ với một lời cầu xin khiêm tốn cho sự công bằng, các hệ thống đã được vá lại.
Các doanh nghiệp và chính phủ cuối cùng đã nhận ra rằng Log4j, một gói được sử dụng bởi một loạt các hệ thống quan trọng trong hai thập kỷ, được duy trì bởi một vài tình nguyện viên không được trả lương, cùng một anh hùng vô danh đã hành động bất chấp sự lạm dụng của ngành công nghiệp[^3] và làm việc không mệt mỏi để giải quyết lỗ hổng.
Đáng buồn thay, Log4j không phải là ví dụ duy nhất.
core-js được tải xuống 30 triệu lần mỗi tuần dưới dạng cơ sở của mọi ứng dụng Node.js, nhưng nó cũng hầu như không được tài trợ.
Gần đây, một số nhà phát triển Bitcoin Core đã từ chức, trích dẫn, trong số các lý do khác, *thiếu lợi ích tài chính* cho quyết định của họ.
Đã có nhiều nỗ lực cung cấp các cấu trúc khuyến khích, thường liên quan đến các hệ thống tài trợ và tiền thưởng.
Khoản tài trợ giúp người tiêu dùng có thể quyên góp cho các dự án mà họ ủng hộ.
Tuy nhiên, bức tranh mã nguồn mở như một tòa tháp bằng gạch nơi các lớp thấp hơn bị lãng quên từ lâu, nhưng vẫn được duy trì bởi các kỹ sư chuyên dụng và dựa vào nhiều nhà phát triển hơn nữa.
Chỉ các dự án ở đầu tháp thường được biết đến và nhận tài trợ. Lựa chọn thiên vị này dẫn đến những viên gạch thiết yếu giữ tòa tháp không thu hút được sự đóng góp, trong khi các mục yêu thích nhận được nhiều hơn họ cần.
Bounties cho phép người tiêu dùng các dự án đề xuất thanh toán cho các nhà phát triển để xây dựng các tính năng cụ thể, do đó chỉ các dự án trả thù lao để làm những việc không nhất thiết là lợi ích tốt nhất của họ.
Và một lần nữa, chỉ có yêu thích bổ ích.
Trong bài báo này, chúng tôi đề xuất Tea — một hệ thống phi tập trung cho các nhà phát triển mã nguồn mở nhận thù lao một cách công bằng dựa trên sự đóng góp của họ cho toàn bộ hệ sinh thái và được ban hành thông qua thuật toán khuyến khích Tean được áp dụng trên tất cả các mục trong đăng ký Tea.
$\parskip=0pt plus 1pt$
[^1]: Nguồn: @nist
[^2]: Nguồn: @reuters
[^3]: Nguồn: @twitter
# Các thành phần
Một nhà phát triển phần mềm xây dựng một ứng dụng cần bốn điều: trình duyệt, thiết bị đầu cuối, trình soạn thảo và người quản lý gói.
Trong số bốn người này, trình quản lý gói là thứ kiểm soát công cụ và khung mà nhà phát triển cần xây dựng sản phẩm của họ.
Lớp này là nơi chúng ta thấy tiềm năng để thay đổi cách thức nguồn mở được trả thù lao.
## Người quản lý gói
Người quản lý gói biết phần mềm mã nguồn mở mà một ứng dụng phụ thuộc vào chức năng, từ ngọn ngành đến gốc rể của nó.
Mỗi thành phần và phiên bản cần thiết cho ứng dụng được biết và ghi lại.
Nó biết rằng đỉnh của tòa tháp cẩn thận chọn các đối tượng phụ thuộc của nó và sự lựa chọn cẩn thận đó tiếp tục xuống.
Trình quản lý gói được đặt duy nhất trong ngăn xếp công cụ nhà phát triển để cho phép phân phối giá trị chính xác và tự động dựa trên việc sử dụng trong thế giới thực thực tế.
Chúng tôi đề xuất một cơ quan đăng ký phi tập trung bất biến được thiết kế để phân phối giá trị dựa trên một thuật toán xác định mỗi đóng góp của mục nhập vào tiện ích và sức khỏe của hệ thống.
Giá trị có thể nhập biểu đồ tại các điểm ứng dụng Apex và các thư viện thiết yếu và được phân phối cho các đối tượng phụ thuộc của các điểm Apex đó và các đối tượng phụ thuộc của chúng một cách đệ quy vì Cơ quan đăng ký biết toàn bộ biểu đồ nguồn mở.
Ngoài ra, chúng tôi tin rằng thông tin vật liệu phải có sẵn thông qua trình quản lý gói cho các nhà phát triển để đánh giá xem họ có thể tin tưởng một gói và tác giả của nó hay không.
Thông tin này có thể dựa trên danh tiếng, danh tiếng cộng đồng, dữ liệu được lấy từ các hệ thống nhận dạng phi tập trung (DID[^4]), các nhà quản lý gói khác hoặc các cơ chế khuyến khích có khả năng dựa vào những người tham gia mạng gây rủi ro cho giá trị kinh tế.
Chúng tôi dự đoán rằng sự kết hợp các công cụ của Tea, thông tin và phần thưởng sẽ khuyến khích các nhà phát triển, giúp kích thích sự phát triển của phần mềm nguồn mở và thúc đẩy đổi mới.
[^4]: Xem thêm: @w3
## Cơ quan đăng ký phi tập trung
Mỗi người quản lý gói đều có sổ đăng ký gói riêng lặp lại cùng một siêu dữ liệu.
Đó là thời gian có một cơ quan đăng ký duy nhất, toàn diện và dứt khoát được thiết kế và chi phối bởi các cộng đồng phụ thuộc vào nó.
Cơ quan đăng ký bất biến, phi tập trung này có thể cung cấp bảo mật, ổn định và ngăn chặn ý định xấu xa.
Internet chạy trên hàng chục ngàn thành phần mã nguồn mở quan trọng.
Điều đáng chú ý là cho đến nay, các sự cố gây ra bởi việc loại bỏ cơ sở hạ tầng mã nguồn mở thiết yếu là tối thiểu.
Nổi tiếng nhất là việc loại bỏ sự phụ thuộc pad[^5]-trái NPM vào năm 2016, được xếp vào các hệ thống tích hợp liên tục và triển khai liên tục khiến các nhà phát triển bỏ mặt trong nhiều ngày.
Sự kiện này đã chứng minh rằng bản thân Internet dựa trên các hệ thống phát triển mong manh.
Các ví dụ khác liên quan đến sự tham gia tích cực hoặc có chủ ý từ người bảo trì gói độc hại phổ biến của họ (Xem colors.js, faker.js[^6], and node-ipc[^7]) hoặc các tác nhân xấu đang tìm kiếm lợi nhuận bằng cách giả vờ duy trì các gói và làm hỏng chúng để đánh cắp, cho ví dụ, các khóa riêng Bitcoin (xem luồng sự kiện[^8]) hoặc các gói độc hại có lỗi chính tả có chủ ý, còn được gọi là lỗi chính tả, với hy vọng lừa người dùng cài đặt chúng, ví dụ như các gói NPM crossenv vs. cross-env [^npmjsCrossenv].
Tính toàn vẹn của phần mềm cần được đảm bảo khi ngành công nghiệp tiến tới một tương lai nơi tài sản kỹ thuật số là một phần của phần mềm.
Chúng ta không thể tiếp tục khiến bản thân dễ bị tổn thương trước các diễn viên độc hại sửa đổi phần mềm.
Hầu hết các công cụ mà chúng tôi gọi là trình quản lý gói không thể đảm bảo rằng các gói này được tích hợp trong các apps và dApps là mã nguồn mở không thay đổi được xuất bản bởi các tác giả ban đầu của chúng.
Github của Microsoft đã phát hiện ra rằng 17% lỗ hổng trong phần mềm được nuôi cấy cho mục đích độc hại[^9], với một số còn lại không bị phát hiện trong thời gian dài (xem Webmin 1.890[^10]).
Một cơ quan đăng ký phi tập trung được tăng cường bởi một hệ thống danh tiếng và được hỗ trợ bởi các ưu đãi kinh tế được thiết kế để phơi bày các tác nhân xấu và phần thưởng cho các diễn viên giỏi có thể cung cấp cho các cộng đồng phát triển bảo đảm.
[^5]: Nguồn: @theregister
[^6]: Nguồn: @fossa
[^7]: Nguồn: @lunasec
[^8]: Nguồn: @github
[^npmjsCrossenv]: Nguồn: @npmjsCrossenv
[^9]: Nguồn: @zdnet
[^10]: Nguồn: @threatpost
## Hệ thống lưu trữ
Các gói nguồn mở cung cấp một loạt các chức năng, một số trong đó có thể bị hạn chế hoặc không mong muốn.
Mã hóa là một ví dụ tuyệt vời về điều đó. Một trường hợp sử dụng quan trọng để mã hóa là sự hỗ trợ của sự riêng tư của cá nhân trên toàn cầu.
Tuy nhiên, mã hóa cũng có thể được sử dụng cho các mục đích bất chính (xem bảo mật Phantom, bị dỡ bỏ bởi các cơ quan thực thi pháp luật vào tháng 3 năm 2018[^11]) hoặc có thể bị xâm phạm để hỗ trợ các hoạt động thực thi pháp luật (xem Chiến dịch Ironside (AFP), Chiến dịch Greenlight (Europol),
và hoạt động Trojan Shield (FBI)[^12] nơi mà FBI vận hành một nền tảng truyền thông “được mã hóa”, AN0M, và đã thuyết phục tội phạm sử dụng điện thoại được mã hóa trên mạng của họ để giao tiếp an toàn).
Các ứng dụng rộng rãi của mã hóa đã làm cho nó trở thành một trường hợp sử dụng hoàn hảo cho phần mềm nguồn mở và một ví dụ tuyệt vời cho thấy bất kỳ giải pháp nào lưu trữ các gói phải chống giả mạo và chống kiểm duyệt.
Tea là một giao thức phi tập trung không có ý định lọc hoặc xử phạt các gói dựa trên chức năng của chúng.
Mặc dù quản trị Tea có thể chọn loại bỏ các gói độc hại đã được chứng minh (xem phần Quản trị để biết thêm thông tin), nhưng điều quan trọng đối với hệ thống Tea là kết nối với nhiều hệ thống lưu trữ, bao gồm các hệ thống phi tập trung chứng minh rằng một gói không được thay đổi và sao chép chính xác.
Người bảo trì gói có thể chọn hệ thống lưu trữ phù hợp nhất với nhu cầu lưu trữ và phân phối các gói của họ một cách an toàn.
[^11]: Nguồn: @fbi
[^12]: Nguồn: @europol
# Những người tham gia mạng lưới
Nhiệm vụ của Tea là trao quyền cho các cộng đồng nguồn mở và đảm bảo những người đóng góp của họ được hỗ trợ khi họ tạo ra các công cụ xây dựng Internet.
Trong sách trắng này, chúng tôi phân biệt người tham gia thông qua những đóng góp của họ.
Một số có thể đóng góp mã hoặc xác minh mã đóng góp.
Những người khác có thể cung cấp giá trị kinh tế để hỗ trợ các nhà phát triển và danh tiếng của họ.
## Người bảo trì gói
Người bảo trì gói phải đảm bảo phần mềm của họ tiếp tục mang lại giá trị ngày càng tăng khi ngành công nghiệp phát triển.
Tea giả định rằng những người sáng tạo gói duy trì công việc của họ.
Người bảo trì gói là trụ cột của các cộng đồng nguồn mở, những người cần được trao quyền và thưởng cho những đóng góp liên tục của họ.
Người bảo trì gói có thể quyết định ngừng nỗ lực bảo trì của họ hoặc nhận ra rằng họ không thể hoạt động với tốc độ phù hợp với mong đợi của người dùng gói.
Các nhà bảo trì gói nhận được Token không thể thay thế (NFT) khi họ hoàn thành việc gửi gói (xem phần NFT duy trì để biết thêm chi tiết).
NFT này được sử dụng để chứng minh công việc của họ và là chìa khóa chỉ đạo phần thưởng Tea. Người nắm giữ NFT của gói có thể chuyển quyền sở hữu của mình cho một nhà phát triển khác (hoặc nhóm nhà phát triển), do đó họ trở thành bảo trì gói và người nhận bất kỳ phần thưởng nào trong tương lai.
Tương tự, một nhà phát triển có thể quyết định đảm nhận vai trò bảo trì gói bằng cách lấy gói hiện tại và gửi một gói mới mà họ sẽ duy trì tiến về phía trước, do đó tự trở thành người tạo và bảo trì gói.
Điều cần thiết là cung cấp cho các cộng đồng nhà phát triển các công cụ phù hợp để xác định các gói nào đang được duy trì và những người bảo trì trong quá khứ và hiện tại của họ danh tiếng và chất lượng công việc.
Chúng tôi thường thấy công việc mã nguồn mở bị giả mạo và những nỗ lực của nhiều người bị hủy hoại bởi các thành phần xấu.
Mặc dù công việc của các tác nhân xấu này phần lớn được phát hiện và khắc phục, nhưng thường phải phát sinh ra thiệt hại đáng kể thông qua mất tài chính hoặc dữ liệu.
Lấy ví dụ, gói NPM EventStream[^13] đã được tải xuống hơn 1,5 triệu lần mỗi tuần và dựa vào hơn 1.500 gói khi một hacker quản lý để thâm nhập dự án nguồn mở, hãy lấy sự tin tưởng của tác giả ban đầu và sửa đổi EventStream để phụ thuộc vào một điều độc hại Gói sẽ vượt qua thông tin về ví Bitcoin cho máy chủ của bên thứ ba\.
Mặc dù các công cụ có thể giúp phát hiện một số cuộc tấn công này, nhưng chúng không thể luôn luôn dựa vào, điều này tạo ra toàn bộ cộng đồng phụ thuộc vào sự siêng năng và sẵn sàng chia sẻ phát hiện của họ.
Chúng tôi đề xuất giới thiệu các ưu đãi thông qua mã thông báo Tea được mô tả trong phần mã thông báo Tea, khuyến khích các cộng đồng nguồn mở báo cáo phát hiện của họ một cách xây dựng, vì vậy các nhà bảo trì gói có thể giải quyết chúng trước khi chúng bị khai thác.
[^13]: Nguồn: @medium
## Người sử dụng gói
Người dùng gói là các nhà phát triển phần mềm tập trung vào việc giải quyết một vấn đề cụ thể.
Họ thường tìm kiếm trong cộng đồng nguồn mở cho các công cụ họ cần thử nghiệm một cách nhanh chóng và lặp đi lặp lại với rất ít chi phí, được hưởng lợi trực tiếp từ công việc của người tạo và bảo trì gói.
Theo truyền thống, một tập hợp con có thể đã chọn để hỗ trợ người bảo trì gói thông qua quyên góp hoặc các hình thức thù lao khác; Tuy nhiên, trường hợp này hiếm khi xảy ra.
Tài trợ có thể là một hệ thống hiệu quả để hỗ trợ phát triển nguồn mở; Tuy nhiên, thù lao thường không mở rộng cho tất cả các phụ thuộc.
Hạn chế này có lợi cho mục yêu thích và cản trở sự đổi mới và xây dựng phần mềm.
Để phấn đấu làm nền tảng phát triển phần mềm, nguồn mở phải trao quyền cho tất cả các nhà phát triển, cho dù là người mới bắt đầu hay chuyên gia, trên tất cả các lớp trong tháp.
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.
Mục đích của Tea là để duy trì các giá trị cốt lõi của phần mềm mã nguồn mở trong khi cung cấp một hệ thống phi tập trung cho các nhà bảo trì gói thù lao cho công việc của họ. Để thực hiện nhiệm vụ này, Tea dự định phát triển — và khuyến khích những người khác phát triển — các cơ chế cho người dùng gói để hỗ trợ người bảo trì gói thông qua các trường hợp sử dụng độc đáo của mã thông báo Tea, như được mô tả trong mã thông báo Tea và các phần nỗ lực cộng đồng tiềm năng và trong tương lai.
## Những người ủng hộ và nhà tài trợ gói
Trong Web 2.0 và Web3, những người ủng hộ gói thường được gọi là “nhà tài trợ”. Họ là các tổ chức hoặc người dùng gói sử dụng phần mềm nguồn mở để xây dựng các sản phẩm thương mại của họ, các nhà từ thiện tìm cách hỗ trợ hệ sinh thái hoặc các doanh nhân muốn tài trợ cho các nhóm để phát triển các thành phần của một hệ thống lớn hơn.
Tea đề xuất mở rộng cộng đồng của những người ủng hộ gói cho toàn bộ cộng đồng Tea, cho dù các tổ chức, nhà phát triển, người dùng hoặc những người đam mê công nghệ.
Mục tiêu của Tea là thực hiện các cơ chế khuyến khích phi tập trung thông qua các trường hợp sử dụng độc đáo của mã thông báo Tea cho bất kỳ thành viên nào của cộng đồng Tea để đóng góp cho sự bền vững vĩnh viễn và tăng trưởng liên tục của mã nguồn mở.
Những người ủng hộ và nhà tài trợ gói có thể tự do quyết định các gói hoặc người bảo trì gói mà họ muốn hỗ trợ dựa trên công việc, niềm tin hoặc bất kỳ tiêu chí và số liệu nào sẽ ảnh hưởng đến quyết định của họ.
Ngoài ra, sự hỗ trợ được cung cấp bởi những người ủng hộ và tài trợ của gói sẽ chảy vào từng phụ thuộc của gói, do đó hoàn toàn tin tưởng vào người bảo trì gói để đưa ra lựa chọn tốt về ngăn xếp của họ và sử dụng thông tin này để đóng góp cho danh tiếng của họ.
Với điều kiện là người bảo trì gói cung cấp dịch vụ đó, người hỗ trợ và tài trợ gói có thể nhận lại được mức hỗ trợ cao cấp NFT, do đó được hưởng lợi từ SLAs được tăng tốc hoặc cấp phép linh hoạt hơn.
Ngoài ra, những người ủng hộ và tài trợ gói có thể quyết định hỗ trợ các gói hoặc người bảo trì gói và tự động chuyển hướng tất cả hoặc tỷ lệ phần trăm phần thưởng của họ để khuyến khích các nhóm xây dựng phần mềm nguồn mở mới. Nói cách khác, các gói don don cần tồn tại để Tea để bắt đầu đổ vào.
Các dự án mới sinh có thể được hỗ trợ cũng như những dự án trưởng thành hơn, khuyến khích thêm một cảnh quan nguồn mở liên tục.
## Người thử nghiệm Tea
Khi các gói mới hoặc phiên bản mới của các gói hiện tại được phát hành, tính hợp lệ của công việc cần phải được chứng minh một cách chắc chắn.
Thông tin này rất quan trọng đối với người dùng gói để quyết định có tin tưởng cả gói và người bảo trì của nó hay không.
Với giao thức Tea, chức năng này được cung cấp bởi người thử nghiệm Tea.
Những người thử nghiệm Tea, thông thường, là những nhà phát triển phần mềm có kinh nghiệm sẵn sàng dành một phần thời gian của họ để kiểm tra các khiếu nại liên quan đến gói (chức năng, bảo mật, phiên bản ngữ nghĩa[^14], độ chính xác của giấy phép, v.v.)
và đặt ra cả danh tiếng và giá trị kinh tế của họ để chứng minh kết quả nghiên cứu và phân tích của họ và hỗ trợ đánh giá của họ.
Những người thử nghiệm Tea nhận được phần thưởng cho sự siêng năng và nỗ lực của họ.
Tại Tea, chúng tôi gọi là “dựa vào Tea của bạn” hành động khóa các mã thông báo Tea để hỗ trợ đánh giá của bạn và nhận phần thưởng (hoặc hình phạt) dựa trên sự đồng thuận về tính hợp lệ của các đánh giá của bạn.
Giống như những người ủng hộ gói, người thử nghiệm Tea có thể ảnh hưởng đến một gói và gói danh tiếng của người bảo trì gói; Tuy nhiên, tác động của chúng có ý nghĩa hơn với vai trò của họ trong việc xác nhận bảo mật, chức năng và chất lượng của gói.
người thử nghiệm Tea cũng sẽ cần xây dựng danh tiếng của họ để hỗ trợ cho các yêu cầu của họ.
Chất lượng công việc của họ và giá trị kinh tế mà họ gặp rủi ro khi họ nhấn mạnh các đánh giá của họ kết hợp với các nguồn dữ liệu bên ngoài khác sẽ xây dựng từng danh tiếng của mỗi người khai thác Tea, mang lại nhiều giá trị hơn cho công việc của họ.
Xem phần Danh tiếng của gói để biết thêm chi tiết về các cơ chế được sử dụng để ảnh hưởng đến một gói và danh tiếng của người bảo trì gói.
[^14]: Xem thêm: @semver
# Tổng quan về giao thức
Thiết kế của một giao thức để thưởng cho các đóng góp nguồn mở được sa lầy với những thách thức.
Phần mềm nguồn mở theo định nghĩa mở cho tất cả mọi người và có thể, như kết quả, có thể phải chịu sự phân phối sai, chiếm đoạt hoặc giả mạo độc hại.
Tuy nhiên, cộng đồng nguồn mở đã liên tục thể hiện sự sẵn sàng làm nổi bật các diễn viên giỏi và phơi bày các diễn viên xấu.
Trong lịch sử, năng lượng dành cho việc xem xét và bình luận về các nhà phát triển khác đóng góp của các nhà phát triển khác đã được tự nguyện hoàn toàn, mặc dù có thể báo cáo và bảo vệ quan trọng như thế nào.
Chúng tôi dự định tạo ra một nền tảng phân phối không đáng tin cậy cho các ứng dụng được bảo đảm bởi danh tiếng và ưu đãi tài chính, vì chúng tôi tin rằng phần thưởng đầy đủ cho các đóng góp nguồn mở không thể thành công mà không có cả hệ thống danh tiếng và khả năng của các thành viên trong cộng đồng để truyền đạt phát hiện và hỗ trợ của họ (hoặc bất đồng chính kiến) cho một gói hoặc công việc của một nhà phát triển.
Chúng tôi phải cung cấp cho các nhà phát triển các công cụ để truy cập và đóng góp cho hệ thống danh tiếng này.
Các công cụ bao gồm quyền truy cập trực quan và lập trình đơn giản vào phiên bản và danh tiếng của tất cả các phụ thuộc trong các gói của họ.
Một sự hiểu biết rõ ràng về những thành viên cộng đồng nào hỗ trợ từng gói và số lượng mã thông báo Tea họ sẽ đóng góp vào danh tiếng của mỗi gói, giống như một người bảo trì gói đang giảm bao nhiêu công việc của họ giao tiếp với công việc của họ bao nhiêu.
Những điểm dữ liệu kết hợp này sẽ giúp thông báo cho một hệ thống danh tiếng cho tất cả các thành viên cộng đồng và tạo điều kiện cho sự lựa chọn. Vì gói EventStream không được thực hiện thông qua chính gói, nhưng thông qua một trong những phụ thuộc của nó, khả năng hiển thị trên tất cả các lớp phụ thuộc sẽ rất quan trọng để xây dựng hệ thống không đáng tin cậy này.
Tuy nhiên, các cân nhắc như chi phí tính toán và giao dịch (“gas”) sẽ cần được ưu tiên vì hệ thống được thiết kế và xây dựng.
Mục tiêu của chúng tôi là thưởng cho cả các nhà phát triển Web 2.0 và Web3.
Sự phức tạp và chi tiết cụ thể của mỗi ngăn xếp làm cho nó để theo dõi các cài đặt và gỡ bỏ các gói có thể dễ dàng trở thành nạn nhân của một hoặc nhiều tác nhân xấu.
Điều đó bao gồm các cài đặt mua hàng của người Viking để làm tăng số lượng nhân tạo.
Một kịch bản thậm chí còn tồi tệ hơn sẽ giới thiệu những thay đổi cơ bản về bản chất của phần mềm nguồn mở bằng cách tạo ra ma sát không cần thiết với các khóa cấp phép hoặc các cơ chế theo dõi triển khai khác.
Để cung cấp phạm vi bảo hiểm rộng nhất, chúng tôi tin rằng phần thưởng phải dựa vào một khái niệm đơn giản về việc theo dõi cài đặt hoặc gỡ cài đặt, mà là các cơ chế khuyến khích khuyến khích việc gửi các gói chất lượng và báo cáo các gói có rủi ro cao hoặc có rủi ro cao.
Cuối cùng, nhiều gói dựa vào các phụ thuộc chung.
Ví dụ, Lodash có 151.209 người phụ thuộc[^15] trong khi thật sự có 78.854 người phụ thuộc[^16] hoặc Log4js có 3.343 người phụ thuộc[^17].
Khi nhiều gói được tạo ra bằng cách sử dụng cùng một phụ thuộc, làm thế nào để chúng tôi đảm bảo rằng các ưu đãi được phân phối công bằng và công bằng?
Làm thế nào để chúng tôi đảm bảo rằng các phụ thuộc được sử dụng nhiều nhất được thưởng mà không bỏ đói các gói và nhà phát triển mới hoặc mới nổi?
Làm thế nào để chúng tôi đảm bảo rằng hệ thống khuyến khích không kết thúc các nhà phát triển lái ra khỏi các ngôn ngữ thích hợp để tập trung chúng nơi các ưu đãi tốt hơn?
Nhưng cũng là nhà phát triển, làm thế nào để chúng tôi xác định các gói có nhiều người phụ thuộc nhất để xây dựng các lựa chọn thay thế - các phiên bản được mã hóa tốt hơn, hiệu quả hơn, được mã hóa tốt hơn của các gói này?
Tại Tea, chúng tôi tin rằng việc thiếu khuyến khích đã cản trở sự phát triển của phần mềm nguồn mở.
Được hỗ trợ bởi các ưu đãi và phần thưởng kinh tế phù hợp, nhiều nhà phát triển sẽ ở vị trí để xây dựng, cải thiện và tăng cường phần mềm nguồn mở để cải thiện thế giới.
Chỉ sau đó, mã thông báo Tea mới có thể đại diện cho tổng giá trị của phần mềm nguồn mở.
[^15]: Nguồn: @npmjsLodash
[^16]: Nguồn: @npmjsChalk
[^17]: Nguồn: @npmjsLogFourjs
## Đóng gói
Việc gửi bản phát hành gói đòi hỏi nhiều giao dịch độc quyền diễn ra.
Cụ thể, người bảo trì gói phải:
* Đăng ký gói (và phiên bản ngữ nghĩa của nó) với sổ đăng ký phi tập trung.
* Tải gói vào hệ thống lưu trữ phi tập trung để có khả năng phục hồi, kháng kiểm duyệt và dễ phân phối.
* Đóng góp cho danh tiếng của gói và sự đáng tin cậy bằng cách *nhúng* token Tea.
Thất bại của bất kỳ một trong ba hoạt động sẽ dẫn đến giao thức trở lại trạng thái trước đó, do đó loại bỏ bất kỳ bằng chứng nào về việc xác nhận.
Khi một gói được gửi thành công, người bảo trì gói sẽ nhận được NFT duy trì để chứng minh công việc và đóng góp của họ cho nguồn mở.
Người bảo trì gói có thể chuyển phần thưởng liên quan đến người bảo trì NFT sang bên thứ ba.
Tuy nhiên, danh tiếng liên quan đến việc tạo và bảo trì tài sản sẽ vẫn còn với người bảo trì gói, vì vậy danh tiếng của họ có thể bị ảnh hưởng theo thời gian.
Vì danh tiếng của bất kỳ thành viên nào của cộng đồng Tea đạt được các cột mốc quan trọng, họ có thể được cấp quyền truy cập vào các phần nâng cao của giao thức hoặc nhận phần thưởng được tăng tốc, theo quyết định của quản trị Tea.
Để biết thêm chi tiết về NFT bảo trì, hãy xem phần NFT duy trì.
### Phân tích phụ thuộc
Gói phụ thuộc có thể chạy sâu, vì mỗi gói thường có cả người phụ thuộc và phần phụ thuộc.
Để cung cấp một phương pháp đơn giản thưởng cho tất cả các nhà phát triển đã đóng góp cho phần mềm nguồn mở trong khi vẫn giữ cho việc tạo ra cây phụ thuộc nhanh chóng và tính toán hiệu quả, chúng tôi đề xuất chỉ xác minh các phụ thuộc cấp một khi gửi gói.
Thiết kế này được thúc đẩy bởi giả thuyết rằng mỗi phụ thuộc là một gói được gửi độc lập cho cây Tea.
Khi làm như vậy, mỗi phụ thuộc của nó có thể được ánh xạ và nếu chính phụ thuộc của nó có sự phụ thuộc, chúng sẽ được ánh xạ tại thời điểm gói phụ thuộc được gửi.
{#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).
Trong @fig:dep-analysis, việc gửi gói A kích hoạt phân tích các phụ thuộc thời gian chạy 1 đến N và xây dựng phụ thuộc 1 đến N, trong khi các phụ thuộc thời gian chạy 1.1 đến 1.n và xây dựng phụ thuộc 1.1 đến 1.n được phân tích khi gói B đã được gửi.
Chúng tôi sẽ áp dụng phương pháp tương tự cho phân phối khuyến khích khi các mã thông báo được phân phối trên tất cả các phụ thuộc, do đó đệ quy các gói được liệt kê là phụ thuộc (xem @fig:steeping-rewards).
{#fig:steeping-rewards}
Phiên bản và phụ thuộc mâu thuẫn là những thách thức đáng kể, và việc khắc phục chúng có thể biến thành cống lớn thời gian.
Để giải quyết vấn đề này, chúng tôi đề xuất mỗi gói phải tuân theo quét phụ thuộc toàn diện khi gửi để chúng tôi có thể đảm bảo rằng gói tuân thủ các quy tắc sau cho phạm vi phiên bản ngữ nghĩa.
* Các gói chỉ có thể ràng buộc các phụ thuộc của chúng vào một phiên bản chính, mặc dù việc bắt đầu phạm vi có thể là bất kỳ phiên bản ngữ nghĩa hợp lệ nào (ví dụ, >= 5.2.1 <6).
* Nếu một sự phụ thuộc được nâng cấp lên một phiên bản chính gần đây hơn, TEA có thể yêu cầu phiên bản chính của gói phải tăng lên.
* Tương tự, nếu một phụ thuộc được nâng cấp lên một phiên bản nhỏ gần đây hơn, TEA có thể yêu cầu phiên bản nhỏ của gói được tăng lên.
* Nếu một phụ thuộc mới được thêm vào, TEA có thể yêu cầu tăng phiên bản nhỏ của gói.
Xem xét nỗ lực không cần thiết áp đặt cho bất kỳ người dùng gói nào khi các quy tắc trên bị vi phạm, chúng tôi đề xuất rằng một phần của mã thông báo Tea bị cắt giảm bởi người bảo trì gói bị cắt để phản ánh sự thiếu siêng năng của họ.
Nếu một nhà phát triển buộc mọi người phải tung hứng cúp của họ, ai đó sẽ bỏ một ít Tea. Vì việc quét phụ thuộc dự kiến sẽ xảy ra khi nộp, chúng ta nên lưu ý rằng không có việc giảm giá từ những người ủng hộ và tài trợ gói hoặc người nếm Tea sẽ xảy ra.
## Gói và gói danh tiếng của người đóng gói
Người duy trì gói phải đóng góp vào danh tiếng và sự đáng tin cậy của họ bằng cách giảm token Tea.
Tuy nhiên, một hệ thống danh tiếng chỉ dựa vào sự đóng góp kinh tế của tác giả không cung cấp đủ bảo vệ người dùng và có thể phải chịu các cuộc tấn công của Sybil, trong đó một cá nhân duy nhất tạo ra nhiều đại diện của chính họ để để lại một khối lượng lớn các đánh giá tích cực về công việc của họ, lừa người dùng tin rằng công việc của họ đã được nhiều người xem xét và phê duyệt.
Một số phương pháp có sẵn để ngăn chặn các cuộc tấn công Sybil, một số trong đó được mô tả bởi Nitish Balachandran và Sugata Sanyal trong “một đánh giá về các kỹ thuật để giảm thiểu các cuộc tấn công của Sybil”[^18].
Vì Tea là một giao thức phi tập trung, sử dụng hệ thống chứng nhận ủy thác dựa trên cơ quan cấp giấy chứng nhận tập trung sẽ trái với cốt lõi của nó.
Chúng tôi đề xuất tập trung vào các phương pháp phi tập trung để giảm thiểu tấn công SYBIL và cụ thể hơn là các phương pháp dựa vào một nhóm lớn những người tham gia mạng được khuyến khích đánh giá và đại diện công khai danh tiếng của từng gói và người bảo trì.
Tương tự như việc sản xuất các khối trên blockchain bằng chứng, trong đó các nút không sản xuất có thể xác nhận công việc của người khác và khi cần thiết, làm nổi bật sự vi phạm các quy tắc của mạng, dẫn đến việc phạt thông qua việc loại bỏ (phá hủy một phần cổ phần của họ),
chúng tôi đề xuất một hệ thống theo đó các bên thứ ba (aka người thử nghiệm Tea) sẽ có thể xem xét các gói được sản xuất bởi người bảo trì gói và được khuyến khích kinh tế để hành xử vì lợi ích tốt nhất của nguồn mở của nguồn mở Cộng đồng phần mềm và người dùng cũng như nhận ra hành vi tốt và phạt hành vi xấu.
Hệ thống này phải có cả khả năng kháng Sybil và ngăn chặn các giá đỡ mã thông báo lớn ảnh hưởng đến giao thức hoặc danh tiếng của các gói cụ thể.
Chúng tôi tin rằng cách tiếp cận này phù hợp hơn với nguồn mở, cung cấp chất nền màu mỡ hơn để thúc đẩy việc áp dụng và tin tưởng, và cuối cùng tạo điều kiện cho sự phát triển của Tea.
[^18]: Nguồn: @arxiv
## Đánh giá gói của các bên thứ ba
Việc xem xét các gói của các bên thứ ba là một thành phần thiết yếu của việc xây dựng danh tiếng, tuy nhiên, đánh giá của bên thứ ba có các mối đe dọa độc đáo của riêng mình bao gồm các cuộc tấn công SYBIL đã nói ở trên.
Công nghệ blockchain, và đặt cược rõ ràng hơn, cung cấp một cơ hội duy nhất cho Tea để giải quyết thách thức này.
Mặc dù địa chỉ ví có thể có sẵn với số lượng vô hạn, nhưng đây không phải là trường hợp với mã thông báo Tea, có nguồn cung ban đầu dự kiến là 10 tỷ.
Ngoài ra, mỗi hành động được thực hiện bởi các nhà phát triển, chẳng hạn như gửi các gói, xác minh các gói hoặc dốc chúng, sẽ đóng góp cho danh tiếng của họ, do đó tạo ra một hồ sơ duy nhất mà mỗi nhà phát triển có thể sử dụng để cả đóng góp cho cộng đồng Tea và tham gia quản trị Tea.
Bằng cách yêu cầu các nhà đánh giá của bên thứ ba phải tăng mã thông báo Tea và chịu nguy cơ mất một phần mã thông báo dốc của họ nếu họ hành xử chống lại sự quan tâm của mạng hoặc là một diễn viên xấu, các bên thứ ba có thể cung cấp thêm sự tin cậy cho gói và Nhận một phần thưởng, dưới dạng mã thông báo Tea.
Chúng tôi cũng đề xuất mở rộng hệ thống danh tiếng cho các bên thứ ba thực hiện xác minh độc lập các gói - Những người thử nghiệm Tea.
Việc hoàn thành đánh giá tích cực sẽ yêu cầu hai hoạt động xảy ra gồm:
* Việc gửi đánh giá mã, được ký bởi người bán Tea và có thể truy cập công khai cho tất cả các thành viên của cộng đồng, cùng với đó
* Hành động dốc “cho” các gói (so với gói “đối lập”), để chứng minh đánh giá của họ.
Việc hoàn thành một đánh giá tiêu cực bao gồm một hoặc nhiều lỗ hổng quan trọng sẽ yêu cầu các máy chứa Tea trước tiên liên hệ với người bảo trì gói bằng giao thức nhắn tin để thông báo cho họ về lỗ hổng và cho phép họ giải quyết vấn đề một cách kịp thời.
Khi hết thời hạn được phân bổ cho người bảo trì gói để giải quyết lỗ hổng của họ hoặc khi gói được sửa chữa, cùng một giao thức nhắn tin sẽ được sử dụng để thông báo cho tất cả người dùng và người thử nghiệm gói này (bao gồm cả người phụ thuộc) rằng lỗ hổng đã được được xác định và hy vọng được giải quyết, vì vậy họ biết để cập nhật ứng dụng hoặc phụ thuộc của họ.
Để không tôn trọng sự lãng phí của các nhà phát triển Thời gian, giao tiếp giữa các người thử Tea và người bảo trì gói sẽ yêu cầu các thử Tea để tăng mã thông báo Tea.
Sau khi hoàn thành cả hai hoạt động, Tasters Tea sẽ nhận được NFT làm bằng chứng về công việc của họ trên gói cụ thể và phiên bản gói.
Sự tích lũy của các NFT kết hợp với tỷ lệ của mỗi gói được xem xét và thông tin được trích xuất từ các hệ thống bên ngoài sẽ thông báo cho danh tiếng của Taster Taster.
Khi danh tiếng của họ đạt đến các cột mốc quan trọng, những người thử nghiệm Tea có thể kiếm được quyền truy cập vào các phần nâng cao của giao thức hoặc phần thưởng tăng tốc, theo quyết định của quản trị Tea.
## Các gói lỗi thời hoặc hư hỏng
Nhiệm vụ của Tea là thưởng cho những người đóng góp và người tham gia vào các cộng đồng nguồn mở; Tuy nhiên, phần thưởng phải tương xứng với những nỗ lực được triển khai bởi người bảo trì gói và thử nghiệm Tea.
Các gói được duy trì, lỗi thời hoặc bị hỏng là dấu hiệu rõ ràng của những người bảo trì gói không sống theo mong đợi của cộng đồng hoặc không mang lại sự tin tưởng và hỗ trợ ấn tượng với họ thông qua việc nhúng các gói.
Một biểu hiện khác của các gói lỗi thời có thể là việc tiếp tục sử dụng ngôn ngữ kế thừa hoặc phiên bản di sản của các ngôn ngữ đa phiên bản. Các gói còn lại lỗi thời hoặc tham nhũng trong quá dài cho thấy những người thử nghiệm Tea cần xem xét các gói bảo trì của gói làm việc thường xuyên và nhất quán.
Những người thử nghiệm Tea là thành viên quan trọng của các cộng đồng nguồn mở trong đó đánh giá và khiếu nại liên quan của họ có thể hướng người dùng gói hướng tới hoặc tránh xa các gói.
Để đảm bảo rằng các đánh giá có thể được tin cậy trên cơ sở liên tục, chúng tôi đề xuất một cơ chế theo đó các gói lỗi thời hoặc bị hỏng có thể thấy một phần của các token dốc của họ được gửi đến các người thử nghiệm Tea trước tiên để nhận ra việc thiếu bảo trì bất kỳ gói nào.
Bất kỳ đánh giá tiêu cực nào phác thảo một lỗ hổng như lỗ hổng không ngày hoặc sử dụng sự phụ thuộc lỗi thời và vẫn mở qua thời kỳ ân sủng được xác định bởi quản trị nên được coi là thất bại của người bảo trì gói.
Họ đã không hoàn thành nhiệm vụ mà họ được giao phó và thưởng cho.
Điều tương tự cũng có thể nói đối với những người ủng hộ và tài trợ gói hàng đã đặt ra danh tiếng của họ về công việc của những người bảo trì gói quá hạn và nhận được phần thưởng cho nó, nhưng không xác định được việc thiếu bảo trì hoặc được bầu để tiếp tục hỗ trợ gói bất kể.
Khi các gói trở nên phổ biến và sử dụng, với nhiều ứng dụng và hệ thống quan trọng có khả năng phụ thuộc vào chúng, chúng tôi phải khuyến khích các nhà phát triển báo cáo lại các lỗ hổng cho người bảo trì gói và bảo trì gói để giải quyết các lỗ hổng đó trước khi chúng có thể bị khai thác.
Do đó, chúng tôi đề xuất rằng bất kỳ gói lỗi thời hoặc bị hỏng nào phải tuân theo một hoặc nhiều đánh giá tiêu cực được chứng minh và vẫn ở trạng thái đó trong thời kỳ ân sủng do quản trị xác định Những người ủng hộ, và các nhà tài trợ hoặc người thử nghiệm Tea trước đó), trong khi một phần khác được gửi đến Tasters Tea đã gửi các đánh giá tiêu cực.
Phân phối cho tất cả các nhà thử nghiệm Tea có thể dựa trên tuổi của đánh giá của họ và số lượng mã thông báo Tead mà họ đã đưa ra để xem xét.
## Người duy trì NFT
Sau khi gửi thành công một gói, người bảo trì gói sẽ nhận được NFT để chứng minh công việc và đóng góp của họ.
Chủ sở hữu của NFT này sẽ tự động nhận tất cả các phần thưởng được liên kết với gói.
Người bảo trì gói có thể chuyển quyền sở hữu bảo trì qua một gói cho người bảo trì gói khác bằng cách chuyển gói NFT gói. Chuyển thành công NFT sẽ dẫn đến chủ sở hữu mới tự động nhận phần thưởng gói trong tương lai.
Một phần quan trọng của việc xây dựng danh tiếng phụ thuộc vào tần suất và số lượng bài nộp gói chất lượng.
NFT được giao cho các nhà bảo trì gói làm bằng chứng về công việc của họ có thể được sử dụng bởi hệ thống danh tiếng để cập nhật danh tiếng của người bảo trì gói và cho phép họ truy cập vào các phần nâng cao của giao thức, theo quyết định của quản trị Tea.
Tuy nhiên, để ngăn chặn các vectơ tấn công, chẳng hạn như các thành viên cộng đồng mua danh tiếng của họ, việc chuyển giao NFT bảo trì sẽ không dẫn đến việc chuyển giao danh tiếng. Danh tiếng phải duy trì liên kết trực tiếp với một công việc của nhà phát triển cụ thể và không được chuyển nhượng.
# Mã thông bá Tea
## Bảo hiểm mạng lưới
Mặc dù nhiều blockchain có thể xuất hiện dưới dạng các giải pháp cơ sở hạ tầng hiệu quả và an toàn để hỗ trợ các mục tiêu của Tea, nhưng chúng tôi tin rằng phải xem xét cẩn thận cho ngăn xếp công nghệ mà hệ thống Tea được xây dựng.
Khả năng mở rộng, hiệu quả chi phí, ESG và khả năng mở rộng của bên thứ ba là những cân nhắc thiết kế quan trọng mà một hệ thống chứng minh cổ phần có chủ quyền của Tea có thể phục vụ tốt hơn.
Để có bằng chứng, các nhà khai thác nút và những người tham gia mạng đã đóng góp giá trị kinh tế dưới dạng mã thông báo gốc chuỗi để tăng bảo mật hệ thống.
Các nhà khai thác nút và người tham gia mạng nhận được phần thưởng cho việc sản xuất thành công các khối tuân thủ các quy tắc của mạng và bao gồm thông tin giao dịch chính xác.
Không hoạt động (AKA Node Down) hoặc hoạt động độc hại/không chính xác bị phạt bằng cách phá hủy một phần của các mã thông báo đặt cược thông qua việc loại bỏ.
Một hệ thống PoS cung cấp bởi mã thông báo Tea sẽ cho phép những người giữ mã thông báo Tea đóng góp vào hệ thống bảo mật bằng cách đặt *staking* Tea và hỗ trợ các nhà phát triển nguồn mở bằng cách *nhúng* Tea.
Chúng tôi nhận thức đầy đủ các yếu tố kinh tế có thể ngăn chặn một số nhà phát triển stake hoặc nhúng Tea; Như vậy, việc đặt cược và dốc sẽ có sẵn ít như một chiếc lá, mệnh giá nhỏ nhất của Tea đại diện cho một trăm triệu ($10^{-8}$) của một loại Tea.
Cả hai ứng dụng của mã thông báo Tea đều phục vụ các chức năng quan trọng trong sự hỗ trợ và tăng trưởng của hệ sinh thái nguồn mở.
Tea Staking sẽ đảm bảo rằng hệ thống Tea tiếp tục hoạt động an toàn, vì vậy tất cả những người tham gia mạng có thể gửi và truy cập các gói để xem xét chúng, tích hợp chúng vào ứng dụng của họ, v.v.
Những người tham gia mạng để hỗ trợ và sử dụng các gói đáp ứng các yêu cầu về chất lượng và độ tin cậy, như được xây dựng bởi cộng đồng Tea thông qua sự hỗ trợ và bất đồng của mỗi gói.
Sẽ được thực hiện khi xác định và thực hiện các tham số cổ phần và độ dốc để người ta không trở thành ký sinh ở bên kia.
## Khuyến khích và Hình phạt
Như đã thảo luận trước đó, có thể có những khuyến khích mạnh mẽ cho những kẻ xấu thỏa hiệp phần mềm nguồn mở.
Phần lớn cơ sở hạ tầng quan trọng của Internet đang chạy trên nguồn mở và cuộc đua tìm kiếm các lỗ hổng khai thác cũng như các lỗ hổng khác đang diễn ra.
Tại Tea, chúng tôi tin rằng những người duy trì gói không phải là những người đáng bị đổ lỗi (mặc dù họ thường như vậy).
Các khuyến khích giao thức Tea khắc phục điều này thông qua phân phối khuyến khích công bằng và hợp lý.
Một gói như Lodash với hơn 151 nghìn người phụ thuộc là trụ cột của sự phát triển nguồn mở và người bảo trì của nó xứng đáng được khen thưởng tương xứng.
Tuy nhiên, một hệ thống phần thưởng được xây dựng chỉ dựa trên số lượng người phụ thuộc sẽ ngăn cản các nhà đổi mới phá vỡ các thế độc quyền này trừ khi họ được các bên thứ ba cấp vốn đầy đủ hoặc đã tích lũy đủ nguồn lực để tự tài trợ.
Cách tiếp cận này có thể dẫn đến số lượng người đóng góp bị thu hẹp lại, dẫn đến kết quả ngược lại với ý nghĩa của Tea.
Mục tiêu của tea là đại diện cho giá trị của phần mềm mã nguồn mở và, khi làm như vậy, thúc đẩy sự phát triển của nó bằng cách trao quyền cho những người tham gia bằng các tài nguyên họ cần để theo đuổi niềm đam mê của mình mà không bị cản trở.
Hệ thống phân phối ưu đãi Tea cần xem xét cẩn thận tỷ lệ dốc của từng gói và điều chỉnh ưu đãi của từng gói cho phù hợp.
Để giảm rủi ro của một số lượng nhỏ các gói được sử dụng làm phụ thuộc trên nhiều ứng dụng thu phần lớn phần thưởng dốc, chúng tôi sẽ tận dụng nghiên cứu do nhà sáng lập[^19] web3 sản xuất cho cơ chế phần thưởng dựa trên bằng chứng cổ phần của Polkadot.
Chúng tôi có thể điều chỉnh thêm việc triển khai và các biến của nó dựa trên kết quả của các thử nghiệm thực tế.
Khi một gói steep tiếp cận tỷ lệ dốc tối ưu do quản trị xác định, tỷ lệ phần thưởng dốc của nó sẽ giảm dần.
Khi một gói vượt quá tỷ lệ dốc tối ưu của nó, tỷ lệ phần thưởng dốc sẽ giảm mạnh để không khuyến khích những người ủng hộ gói và những người thưởng thức tea từ các gói có độ dốc cao hơn nữa.
Thiết kế này có thể cho phép các gói ít dốc hơn trở nên hấp dẫn hơn đối với cả những người ủng hộ gói và những người thưởng thức tea.
Nó cũng có thể khuyến khích các nhà phát triển có kinh nghiệm xây dựng các giải pháp thay thế cho các gói có độ dốc cao, tạo cơ hội cho cộng đồng tea cân bằng giữa việc hỗ trợ phần mềm hiện có và thúc đẩy đổi mới.
Tỷ lệ dốc sẽ được tính toán bằng cách sử dụng nguồn cung cấp tuần hoàn trong thiết kế ban đầu của nó.
Cộng đồng tea có thể thay đổi thiết kế này để cải thiện khả năng mở rộng của hệ thống hơn nữa.
Hãy để $\chi$ là tỷ lệ dốc trên tất cả các gói.
Nó đại diện cho tổng số mã thông báo tea được người bảo trì gói, người dùng gói, người ủng hộ gói và nhà tài trợ cũng như người nếm tea chia cho tổng nguồn cung cấp mã thông báo tea.
Dựa vào số lượng gói nguồn mở hiện có và mức tăng trưởng dự kiến của chúng,$\chi$ sẽ luôn là một giá trị rất nhỏ giữa $0$ và $1$.
Đặt $\psi$ là tỷ lệ staking.
Nó đại diện cho tổng số mã thông báo Tea được đặt bởi bất kỳ người tham gia mạng nào để bảo mật mạng.
Đặt $\chi_{ideal}$ là tỷ lệ dốc mà chúng tôi muốn mỗi gói đạt được để phân phối phần thưởng công bằng trên tất cả các gói và phần phụ thuộc của chúng.
Giá trị của $\chi_{ideal}$ phải được cập nhật khi các gói mới được thêm vào sổ đăng ký phi tập trung và các phần phụ thuộc được tạo.
Để xác định giá trị tốt nhất cho $\chi_{ideal}$, chúng tôi sẽ sử dụng đường cong hình chuông phổ biến được cập nhật khi bắt đầu mỗi chu kỳ phần thưởng.
Hãy để $\tau = \tau(\chi)$ lãi suất dốc hàng năm được phân phối cho tất cả các thành viên cộng đồng Tea, những người dốc mã thông báo Tea để hỗ trợ các nhà phát triển nguồn mở.
Nói cách khác, $\tau(\chi)$ tương ứng với phần thưởng dốc nhận được trong hơn một năm bởi một thành viên cộng đồng đã dốc mã thông báo Tea trong cả năm.
Đặt $\gamma = \gamma(\psi)$ là lãi suất đặt cược hàng năm được phân phối cho tất cả các nhà khai thác nút và những người tham gia mạng, những người đặt cược mã thông báo Tea để bảo mật mạng.
Nói cách khác, $\gamma(\psi)$ tương ứng với phần thưởng đặt cược nhận được trong hơn một năm bởi một thành viên cộng đồng đặt cược mã thông báo Tea trong cả năm.
Đặt $\delta$ là lạm phát hàng năm hướng vào kho bạc mạng lưới.
$\delta$ có thể thay đổi do các yếu tố bên ngoài ảnh hưởng đến việc cung cấp mã thông báo.
Chúng tôi coi tỷ lệ phần thưởng dốc hàng năm là một hàm của $\chi$ và tỷ lệ phần thưởng đặt cược hàng năm là một hàm của $\psi$.
* $\tau(\chi)$ tương ứng với việc khuyến khích mọi người dốc một gói. Khi $\chi$ tăng lên, cần ít phần thưởng $\tau(\chi)$ hơn.
* $\gamma(\psi)$ tương ứng với động cơ khuyến khích mọi người đặt cược vào mạng. Khi $\psi$ tăng lên, cần ít phần thưởng $\gamma(\psi)$ hơn để bảo mật mạng.
Lạm phát hàng năm $I$ sẽ tương đương $(\tau + \gamma + \delta)$ và được tính như sau:
$$
I = \frac{\textrm{tổng cung của token cuối năm} - \textrm{tổng cung của token đầu năm}}{\textrm{tổng cung của token đầu năm}} = (\tau + \gamma + \delta)
$$
Đóng góp vào lạm phát của $\tau_{\textsc{al
gitextract_8v2qfkg5/ ├── .github/ │ ├── mk-pantry-accessible.sh │ └── workflows/ │ ├── cd.yml │ ├── ci.yml │ ├── make.yml │ └── release.yml ├── .gitignore ├── .markdownlint.json ├── Makefile ├── README.md ├── SUMMARY.md ├── i18n/ │ ├── es/ │ │ ├── metadata.yml │ │ └── white-paper.md │ ├── pt-br/ │ │ ├── metadata.yml │ │ └── white-paper.md │ └── vi/ │ ├── metadata.yml │ └── white-paper.md ├── metadata.yml ├── tea.csl └── white-paper.md
Condensed preview — 19 files, each showing path, character count, and a content snippet. Download the .json file or copy for the full structured content (371K chars).
[
{
"path": ".github/mk-pantry-accessible.sh",
"chars": 125,
"preview": "#!/bin/sh\n\ngit config --global url.\"https://teaxyz:$1@github.com/teaxyz/pantry\".insteadOf \"https://github.com/teaxyz/pan"
},
{
"path": ".github/workflows/cd.yml",
"chars": 214,
"preview": "name: CD\n\non:\n push:\n branches: [main]\n paths: ['i18n/**']\n\nenv:\n TEA_SECRET: ${{ secrets.TEA_SECRET }}\n\njobs:\n "
},
{
"path": ".github/workflows/ci.yml",
"chars": 316,
"preview": "name: CI\n\non:\n pull_request:\n paths:\n - white-paper.md\n - metadata.yml\n - 'i18n/**'\n - 'img/**'\n"
},
{
"path": ".github/workflows/make.yml",
"chars": 2912,
"preview": "name: make\n\non:\n workflow_call:\n inputs:\n release:\n default: false\n required: false\n type:"
},
{
"path": ".github/workflows/release.yml",
"chars": 1310,
"preview": "name: Release\n\npermissions:\n contents: write\n\non:\n push:\n branches: [main]\n paths: [README.md]\n\nenv:\n TEA_SECRE"
},
{
"path": ".gitignore",
"chars": 6,
"preview": "*.pdf\n"
},
{
"path": ".markdownlint.json",
"chars": 56,
"preview": "{\n \"MD012\": false,\n \"MD013\": false,\n \"MD025\": false\n}"
},
{
"path": "Makefile",
"chars": 741,
"preview": ".PHONY: all\n.PHONY: i18n\n.PHONY: clean\n\ntranslations := $(patsubst i18n/%/white-paper.md,tea.white-paper_%.pdf,$(wildcar"
},
{
"path": "README.md",
"chars": 284,
"preview": "# README\n\nThe tea white paper is a [semantically versioned](https://semver.org), [Markdown](https://daringfireball.net/p"
},
{
"path": "SUMMARY.md",
"chars": 75,
"preview": "# Table of contents\n\n* [README](README.md)\n* [white-paper](white-paper.md)\n"
},
{
"path": "i18n/es/metadata.yml",
"chars": 3932,
"preview": "title: Un Protocolo Descentralizado para Remunerar el Ecosistema de Código Abierto\nabstract: >\n Crear un registro públi"
},
{
"path": "i18n/es/white-paper.md",
"chars": 76082,
"preview": "---\ndescripción: Versión 2.1.0\n---\n\n# white-paper\n\n## Un Protocolo Descentralizado para que Desarrolladores de Código Ab"
},
{
"path": "i18n/pt-br/metadata.yml",
"chars": 3765,
"preview": "title: Um Protocolo Descentralizado Para Remunerar o Ecossistema de Código Aberto\nabstract: |-\n A criação de um registr"
},
{
"path": "i18n/pt-br/white-paper.md",
"chars": 59650,
"preview": "# Isenção de responsabilidade\n\nAs informações apresentadas no presente livro branco são de caráter preliminar.\nConsequen"
},
{
"path": "i18n/vi/metadata.yml",
"chars": 3819,
"preview": "title: Giao thức trả thưởng phi tập trung cho hệ sinh thái mã nguồn mở\nabstract: |-\n Việc tạo một sổ đăng ký mở, công k"
},
{
"path": "i18n/vi/white-paper.md",
"chars": 57455,
"preview": "# Tuyên bố miễn trừ trách nhiệm\n\nThông tin nêu trong sách trắng này là thông tin sơ bộ. Do đó, cả tác giả cũng như bất k"
},
{
"path": "metadata.yml",
"chars": 3503,
"preview": "title: A Decentralized Protocol for Remunerating the Open-Source Ecosystem\nabstract: >\n Creating an open, public and st"
},
{
"path": "tea.csl",
"chars": 770,
"preview": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<style xmlns=\"http://purl.org/net/xbiblio/csl\" version=\"1.0\" default-locale=\"en-U"
},
{
"path": "white-paper.md",
"chars": 151210,
"preview": "---\ndescription: Version 1.9\n---\n\n# white-paper\n\n## **Tea Network White Paper: From dApp to OP Stack Layer 2**\n\n* Max Ho"
}
]
About this extraction
This page contains the full source code of the teaxyz/white-paper GitHub repository, extracted and formatted as plain text for AI agents and large language models (LLMs). The extraction includes 19 files (357.6 KB), approximately 80.9k tokens. Use this with OpenClaw, Claude, ChatGPT, Cursor, Windsurf, or any other AI tool that accepts text input. You can copy the full output to your clipboard or download it as a .txt file.
Extracted by GitExtract — free GitHub repo to text converter for AI. Built by Nikandr Surkov.