From bf017522c7b3077cece64cc4f2c7ca7b1d57ecae Mon Sep 17 00:00:00 2001 From: lephuoccan Date: Sat, 10 Dec 2022 17:51:05 +0700 Subject: [PATCH] add vi translation --- i18n/vi/metadata.yml | 83 ++++++ i18n/vi/white-paper.md | 562 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 645 insertions(+) create mode 100644 i18n/vi/metadata.yml create mode 100644 i18n/vi/white-paper.md diff --git a/i18n/vi/metadata.yml b/i18n/vi/metadata.yml new file mode 100644 index 0000000..8466a8d --- /dev/null +++ b/i18n/vi/metadata.yml @@ -0,0 +1,83 @@ +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 \ No newline at end of file diff --git a/i18n/vi/white-paper.md b/i18n/vi/white-paper.md new file mode 100644 index 0000000..d49094e --- /dev/null +++ b/i18n/vi/white-paper.md @@ -0,0 +1,562 @@ +# 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. + +![Góc nhìn đơn giản của hệ thống phần thưởng Tea.](img/figure-1.svg) + +$\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. + +![Sơ đồ phân tích phụ thuộc.](img/figure-3.svg){#fig:dep-analysis} + + +In @fig:dep-analysis, the submission of package A triggers an analysis of runtime dependencies 1 through n and build dependencies 1 through n, while runtime dependencies 1.1 through 1.n and build dependencies 1.1 through 1.n were analyzed when package B was submitted. +We will apply the same methodology for incentive distribution as the steeped tokens are distributed across all dependencies, thus recursively steeping the packages listed as dependencies (see @fig:steeping-rewards). +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). + +![Phân phối phần thưởng dốc trên các phụ thuộc.](img/figure-2.svg){#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{all}}$ (khuyến khích được phân phối cho tất cả các gói dốc) và $\gamma_{\textsc{all}}$ (khuyến khích được phân phối cho tất cả những người đóng góp cho an ninh mạng) phải được cân nhắc để đảm bảo rằng hệ thống khuyến khích tỷ lệ đặt cược/đặt cược tối ưu. + +Khi chúng tôi tập trung vào các ưu đãi được phân phối trên tất cả các gói dốc, chúng tôi xác định rằng +$\tau_{\textsc{all}}$ +là một hàm của tỷ lệ dốc $\chi$ và do đó +$\tau_{\textsc{all}}(\chi) = \chi \cdot \tau(\chi)$. +Từ phân tích trước đây của chúng tôi, chúng ta có thể thấy rằng +$\tau_{\textsc{all}}(\chi_{ideal}) = \chi_{ideal} \cdot \tau_{ideal}$. +Vì mục tiêu là đạt đến một trạng thái mà +$\chi = \chi_{ideal}$ +, phần thưởng +$\tau_{ideal}(\chi)$ +Có thể đạt cực đại tại giá trị đó. + +Đặt $\tau_{ideal} = \tau(\chi_{ideal})$ +là tỷ lệ phần thưởng do mạng phân phối ở kịch bản lý tưởng trong đó +$\chi = \chi_{ideal}$. + +Đặt $\tau_{0}$ là giới hạn của $\tau_{\textsc{all}}(\chi)$ vì $\chi$ tiến tới 0 khi không có thành viên nào trong cộng đồng Tea dốc bất kỳ gói nào. +Giá trị của $\tau_{0}$ phải gần bằng 0 nhưng không bằng 0 để khuyến khích những người dùng sớm. +Theo đề xuất từ nghiên cứu của nhà sáng lập web3, chúng tôi đề xuất rằng: + +* hàm lạm phát tăng tuyến tính giữa $\chi = 0$ và $\chi = \chi_{ideal}$, và +* nó phân rã theo cấp số nhân giữa $\chi = \chi_{ideal}$ và $\chi = 1$. + +Chúng tôi đã chọn mức giảm theo cấp số nhân tương tự cho $\tau_{\textsc{all}}(\chi)$ vì nó hàm ý mức giảm theo cấp số nhân của $\tau(\chi)$ và chúng tôi muốn phần thưởng giảm mạnh hơn $\chi_{ideal}$ để ngăn một gói duy nhất nhận được tất cả phần thưởng. + +Sự phân rã được xác định sao cho tỷ lệ lạm phát giảm nhiều nhất là 50% khi $\chi$ dịch chuyển $d$ đơn vị sang bên phải của $\chi_{ideal}$ – tức là +$\tau_{\textsc{all}}(\chi_{ideal} + d) \geq \tau_{\textsc{all}} \cdot 0,5$. + + +Chúng tôi đề xuất các hàm tỷ lệ lãi suất và tỷ lệ lạm phát sau, các hàm này phụ thuộc vào các tham số $\chi_{ideal}$, $\tau_{ideal}$, $\tau_{0}$ và $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*} + +Cũng như những diễn viên giỏi cần được khen thưởng; các tác nhân xấu cần phải được xác định và trừng phạt. +Phần mềm nguồn mở cung cấp nhiều cơ hội cho những kẻ xấu tạo ra các điểm yếu và rủi ro về uy tín cho toàn bộ cộng đồng các nhà phát triển. +Từ việc chiếm đoạt công việc đến thay đổi và phân phối lại các gói phần mềm, hoặc tiêm mã bất chính, cuộc chiến giữa những kẻ tốt và kẻ xấu vẫn tiếp diễn, thường là với những kẻ xấu được tài trợ tốt, những người coi việc làm ô nhiễm các gói nguồn mở là một cơ hội để hưởng lợi về mặt tài chính. +Nhược điểm là tương đối nhỏ, với các gói có khả năng bị cấm trên kệ kỹ thuật số hoặc bị mang tiếng xấu. + +Chúng tôi đề xuất giới thiệu một cơ chế cắt giảm để thiết lập một nhược điểm quan trọng hơn ảnh hưởng trực tiếp đến giá trị kinh tế của các tác nhân xấu. +Khi những người thử nghiệm Tea đánh giá và phân tích mã trong các gói mới được gửi, chúng tôi khuyên những người thử nghiệm Tea nhận được các công cụ và khuyến khích để xác định và làm nổi bật mã bất chính để người dùng gói có thể nhận thức được các rủi ro và những người duy trì gói, người hỗ trợ gói và nhà tài trợ sẽ bị phạt để gửi hoặc hỗ trợ mã bất chính. +Trong phạm vi đó, đối với tất cả các đánh giá tiêu cực đã được chứng minh được thực hiện theo quy tắc mạng và đã được người duy trì gói giải quyết trong khoảng thời gian do quản trị xác định, người duy trì gói sẽ không phải chịu bất kỳ hình phạt nào trái với những người ủng hộ và tài trợ gói hoặc người thử nghiệm Tea đã cung cấp một đánh giá tích cực về gói trong câu hỏi. +Đối với các đánh giá tiêu cực được thực hiện theo quy tắc mạng và người duy trì gói không giải quyết trong khoảng thời gian do quản trị xác định, một phần mã thông báo do người duy trì gói, người ủng hộ và tài trợ gói cũng như người thử nghiệm Tea trước đó nhận được sẽ bị cắt giảm. Một phần khác sẽ được khóa vào một nhóm bảo hiểm do ban quản lý Tea kiểm soát. +Ban quản lý tea sẽ thiết lập các chính sách và quy tắc phối hợp chặt chẽ với cộng đồng để phân phối nội dung của nhóm cho những người bị ảnh hưởng bởi các lỗ hổng. +Giao thức sẽ phân phối một phần ba số mã thông báo đã giảm giá cho tất cả những người thử nghiệm Tea đã góp phần vào đánh giá tiêu cực và giảm giá đối với gói, dựa trên số lượng mã thông báo Tea mà họ đã giảm giá “chống lại” gói và khoảng thời gian mã thông báo của họ đã giảm giá. +Nói cách khác, một hoặc nhiều người thử nghiệm Tea xác định và báo cáo lỗ hổng theo các quy tắc của mạng càng sớm thì phần thưởng họ nhận được càng cao vì đã hỗ trợ phát triển mã nguồn mở an toàn và hiệu quả. + +Để ngăn các thành viên cộng đồng bỏ phiếu ngẫu nhiên “chống lại” các gói có giá trị cao với hy vọng nhận được phần lớn hình phạt, tất cả các mã thông báo Tea được “chống lại” sẽ không được thưởng theo lạm phát và có thể phải tuân theo cơ chế phân rã, do đó làm giảm giá trị của chúng theo thời gian. + +[^19]: Nguồn: @web3 + + +# Quản trị + +Quản trị là rất quan trọng đối với sự phát triển, tính bền vững và việc áp dụng bất kỳ hệ thống phân tán nào. + +Chúng tôi đề xuất rằng Tea bao gồm quản trị trên chuỗi nơi tất cả những người nắm giữ mã thông báo chè có thể đề xuất và bỏ phiếu về các thay đổi đối với các thông số quan trọng được đánh giá bằng quyền sở hữu mã thông báo và danh tiếng. +Các thông số này có thể bao gồm lạm phát, phí giao dịch, phần thưởng đặt cược, phần thưởng dốc hoặc tỷ lệ dốc tối ưu. +Chức năng này sẽ đảm bảo rằng các thông số quan trọng có thể phát triển và được tối ưu hóa theo thời gian bởi các thành viên của cộng đồng Tea. +Chúng tôi dự đoán quản trị sẽ ra mắt với một cấu trúc đơn giản và dần dần mở rộng khi hệ thống Tea trưởng thành, tạo điều kiện thuận lợi cho việc áp dụng và đảm bảo phân cấp dần dần. + +Một số tham số hệ thống có thể không chịu sự quản trị hoặc hỗ trợ thay đổi tần suất cao để giảm bề mặt tấn công do quản trị thể hiện. +Quá trình chuyển đổi dần dần các tham số sang quản trị mở, phi tập trung sẽ đảm bảo tính ổn định và khả năng dự đoán của hệ thống. + +# Khả năng mở rộng của bên thứ ba + +Khi chúng tôi xây dựng các công cụ ban đầu để thu hút sự hỗ trợ lâu dài của các cộng đồng nguồn mở, chúng tôi tin rằng một phần nhiệm vụ của chúng tôi là đảm bảo rằng các bên thứ ba có thể mở rộng bộ công cụ tổng thể. +Ngoài việc cung cấp cơ sở hạ tầng cho các nhà phát triển để xây dựng các tiện ích mở rộng cho giao thức, bao gồm các cách mới để đổi mới và hỗ trợ thêm cho các nhà phát triển nguồn mở, các kế hoạch của chúng tôi bao gồm tiềm năng cho các nhà quản lý gói khác đóng góp cho giao thức. +Ước mơ và nỗ lực của các nhà phát triển nguồn mở đã tạo nên sự đổi mới hỗ trợ cuộc sống hàng ngày của chúng ta. +Chúng tôi mong muốn được khám phá những cách sử dụng và mở rộng mới cho Tea do cộng đồng Tea đề xuất. + + +# Công việc trong tương lai và những nỗ lực cộng đồng tiềm năng + +Khi hệ thống Tea trưởng thành, chúng tôi dự đoán cộng đồng sẽ quyết định và góp phần thay đổi và mở rộng hệ thống Tea thông qua quản trị. +Dưới đây là một số ý tưởng mà chúng tôi tin rằng có thể truyền cảm hứng cho một số người. + +## Người buôn bán Tea + +Các cộng đồng phần mềm nguồn mở rất sôi động và không ngừng tìm cách đổi mới và mang lại giá trị. +Sự cống hiến và lòng vị tha này dẫn đến việc liên tục xây dựng các phần mềm và gói mới, mỗi phần mềm đều kéo theo sự phụ thuộc. +Do đó, chúng tôi dự đoán bản đồ phụ thuộc sẽ phát triển liên tục, dẫn đến những thay đổi thường xuyên đối với tỷ lệ dốc và phần thưởng. +Trong tương lai, cộng đồng Tea có thể đề xuất phát triển một hệ thống được thiết kế để theo dõi linh hoạt tỷ lệ dốc cho từng gói và cân bằng lại cách những người ủng hộ gói dốc mã thông báo của họ dựa trên tiêu chí của riêng họ. + +## Bản quyền chuyển nhượng trọn gói + +Chúng tôi nhận thấy rằng những người duy trì gói có thể quyết định chuyển luồng phần thưởng tăng vọt của họ cho một hoặc nhiều nhà phát triển. +Việc quản lý việc chuyển giao như vậy phải là quyết định của người duy trì gói và các đối tác của họ, không có sự can thiệp từ Tea. +Các công cụ sẽ cần được cung cấp để chuyển toàn bộ hoặc một phần như vậy (có lẽ thông qua chỉ một phần phần thưởng tăng dần được chuyển hướng đến một hoặc nhiều nhà phát triển, trong khi phần thưởng còn lại tiếp tục chuyển đến người duy trì gói ban đầu) +và cho phần thưởng tăng dần để chuyển qua một tài khoản được kiểm soát bởi một người tham gia mạng, nhiều người tham gia mạng hoặc được phân phối tự động trên nhiều tài khoản bằng cách sử dụng tỷ lệ tĩnh hoặc động. + +## Phân phối phần thưởng cho những người bảo trì + +Việc duy trì một gói có thể dựa vào công việc của một nhóm các nhà phát triển khác. +Trước khi phần thưởng tăng đột biến bắt đầu chảy, các nhóm nên cân nhắc tự động hóa việc phân phối phần thưởng tăng đột biến giữa các nhóm với nhau. +Việc phân phối xảy ra như thế nào phải do chính những người bảo trì quyết định, vì họ ở vị trí tốt nhất để đánh giá ai đã đóng góp và họ nên được khen thưởng như thế nào. + +Để thực hiện điều đó, mỗi nhóm (hoặc các nhóm) có thể thành lập tổ chức tự trị phi tập trung (DAO) của riêng họ và tự động phân phối phần thưởng hoặc triển khai các hệ thống phức tạp hơn để xác định phân phối phần thưởng phù hợp dựa trên các yếu tố bên ngoài, chẳng hạn như phiếu bầu từ tất cả các DAO thành viên, +hoặc phân phối theo thời gian dựa trên đóng góp liên tục, hoàn thành thành công tiền thưởng, v.v. + +## Xử lý gói “phân nhánh phần mềm” + +Chúng tôi tin rằng các nhánh là cần thiết và phần lớn không được sử dụng đúng mức. +Các nhánh có thể là một công cụ hiệu quả để phát triển các gói cạnh tranh về chức năng, hiệu suất, bảo mật và thậm chí cả sự chú ý. +Hữu ích nhất có thể, các nhánh phải công nhận những nỗ lực ban đầu. Thông qua công việc trong tương lai hoặc những đóng góp tiềm năng, cộng đồng Tea có thể nâng cao hệ thống để yêu cầu các nhánh được khai báo, thậm chí có thể được phát hiện khi một gói được gửi. +Những phân nhánh phần mềm không được khai báo do những người thử nghiệm Tea tiết lộ có thể dẫn đến việc một phần mã thông báo đã ngâm bị cắt giảm, được chuyển cho người bảo trì gói ban đầu và được gửi đến những người thử nghiệm Tea đã tiết lộ phân nhánh phần mềm. + +## Thời gian chạy so với Phụ thuộc bản dựng + +Tea có thể không phân biệt được phần phụ thuộc bản dựng với phần phụ thuộc thời gian chạy khi phân phối phần thưởng dốc khi khởi chạy. +Tuy nhiên, với điều kiện cộng đồng Tea cảm thấy mạnh mẽ về việc tạo ra sự khác biệt như vậy, cộng đồng Tea có thể đề xuất các cải tiến đối với thuật toán phân phối phần thưởng tăng dần để tính đến mức độ quan trọng của từng phụ thuộc và đóng góp của chúng vào giá trị của các gói phụ thuộc vào chúng. +Những đề xuất này sẽ được bỏ phiếu và thực hiện dựa trên quyết định của cộng đồng. + +## Thù lao dựa trên việc sử dụng + +Khi nhiều ứng dụng được xây dựng bằng cách sử dụng các gói đã đăng ký với Tea, cộng đồng có thể tăng cường thuật toán phần thưởng để việc phân bổ có thể bị ảnh hưởng bởi các bộ dữ liệu được chứng thực bên ngoài, chẳng hạn như mức sử dụng. +Bản cập nhật này đối với cơ chế phần thưởng có thể cho phép phân bổ phần thưởng mã thông báo Tea cao hơn cho các gói có mức sử dụng cao nhất trong khi vẫn tôn trọng các ràng buộc của tỷ lệ dốc được mô tả trong phần mã thông báo Tea. +Những người bảo trì gói có thể sử dụng một cách tiếp cận tương tự để phân phối phần thưởng dốc trên các phần phụ thuộc của họ dựa trên logic minh bạch mà họ lựa chọn. +Lưu ý rằng tất cả thông tin được sử dụng để ảnh hưởng đến việc phân phối phần thưởng trên các gói và phần phụ thuộc trong hệ thống Tea sẽ cần phải đáng tin cậy. + + +# Lời kết + +Sách trắng này sẽ không tồn tại nếu không có sự hỗ trợ và cống hiến của nhiều người yêu Tea. +Các tác giả Josh Kruger, Jadid Khan và Jacob Heider vì những đóng góp của họ cho hệ thống mã thông báo và nhiều cá nhân kín đáo đã tình nguyện dành thời gian để cung cấp phản hồi về nội dung của tài liệu này. + +$\parskip=0pt plus 1pt$ + +# Bảng thuật ngữ + +| Tựa đề | Định nghĩa | +|------|------------| +| Leaf | Mệnh giá nhỏ nhất của mã thông báo Tea. Một chiếc lá tương ứng với một phần trăm triệu ($10^{-8}$) của một loại Tea. | +| Slashing | Hành động trừng phạt những người đặt cược hoặc người đặt cược để đáp lại hành vi trái với các quy tắc của mạng. | +| Staking | Hành động khóa mã thông báo Tea để bảo mật mạng bằng chứng cổ phần mà hệ thống Tea được xây dựng. | +| Steeping | Hành động khóa mã thông báo Tea để hỗ trợ yêu cầu 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 yêu cầu của bạn. | + + +# Tài liệu tham khảo