Giới thiệu

Đối mặt với MEV (Giá trị rút tối đa) đã là thách thức liên tục đối với Ethereum; chuỗi cung cấp giá trị khuyến khích hoạt động liên tục từ các nhà giao dịch chênh lệch giá với các chiến lược đa dạng và mức độ phức tạp khác nhau, thường là tại sự thiệt hại của người dùng bán lẻ. Trong khi nhiều nhà nghiên cứu đã cố gắng giải quyết MEV thông qua các thay đổi cấp giao thức, những nỗ lực này vẫn chưa đưa ra một giải pháp đáng hài lòng. Cơ sở hạ tầng và cơ chế đấu giá hiện đang được sử dụng có thể thu được MEV tổng hợp trong một khối một cách cạnh tranh, nhưng việc thu được mà không có sự phân phối công bằng là không đủ: tại sao giá trị MEV phải tích lũy cho các bộ xử lý mạng khi nó có thể được thu được và hấp thụ một cách hiệu quả hơn dựa trên từng ứng dụng?

Nhập chuỗi ứng dụng cụ thể (ASS). Thay vì cố gắng viết lại các quy tắc ở cấp độ giao thức, ASS mang lại sức mạnh cho các ứng dụng cá nhân để kiểm soát cách giao dịch của họ được sắp xếp. Bằng cách làm như vậy, ASS cho phép các ứng dụng trên chuỗi bảo vệ người dùng và thanh khoản khỏi các tác động có hại của MEV trong khi cũng cho họ cơ hội thu được giá trị mà nếu không sẽ bị mất cho các nhà xác nhận Ethereum.

Hãy tưởng tượng tiềm năng: thay vì các nhà giao dịch tần suất cao cạnh tranh nhằm tối đa hóa cơ hội cắt lỗ của mỗi người dùng (với hầu hết giá trị cắt lỗ chảy vào các nhà xác minh và do đó các chuỗi cơ bản), mỗi ứng dụng có thể xác định luật riêng của mình cho việc sắp xếp giao dịch, tạo ra một hệ thống phù hợp, hiệu quả và công bằng hơn cho người dùng của chính nó. Điều này đánh dấu một sự chuyển đổi từ việc cố gắng giải quyết MEV ở cấp mạng sang việc giải quyết nó ở nơi quan trọng nhất - ứng dụng chính nó.

Nền tảng

Khái niệm đằng sau chuỗi đặc thù ứng dụng (ASS) bắt nguồn từ công việc của Matheus vềQuy tắc xếp hàng có thể xác minh (VSR) cho các sàn giao dịch phi tập trung (DEXes). Matheus đã chứng minh rằng VSR có thể cải thiện việc thực hiện giao dịch và giảm thiểu MEV bằng cách giảm ảnh hưởng của thợ mỏ đối với việc đặt hàng giao dịch. Tarun sau này mở rộng ý tưởng này Bằng cách hiển thị cách các quy tắc trình tự dành riêng cho ứng dụng có thể ảnh hưởng đáng kể đến các chức năng thanh toán cho những người tham gia giao thức, chẳng hạn như người dùng, trình xác thực và trình sắp xếp.

Ở đây, hàm payoff đại diện cho giá trị kinh tế của một thứ tự giao dịch cụ thể. Giá trị này phản ánh lợi nhuận hoặc tiện ích mà các thành viên giao thức đạt được, cho thấy cách thứ tự giao dịch ảnh hưởng đến kết quả tài chính của họ. Có hai đặc điểm quan trọng của các hàm payoff:

1. Thanh toán không trơn tru: Những thay đổi nhỏ trong thứ tự có thể gây ra những thay đổi lớn trong MEV.
2. Thanh toán không đơn điệu: Những thay đổi nhỏ trong thứ tự có thể tăng hoặc giảm giá trị MEV, nhưng không nhất quán theo một hướng.

Khi các hàm thanh toán thể hiện cả hai đặc tính này, việc tối ưu hóa chiến lược xếp hàng trở nên rất phức tạp. Trong những trường hợp như vậy, cần áp dụng các phương pháp tùy chỉnh và tinh vi hơn ở mức ứng dụng, để đảm bảo kết quả công bằng cho người dùng và một hệ sinh thái DeFi bền vững.

ASS hoạt động như thế nào?

Để hiểu về ASS, trước tiên hãy xem xét lại chuỗi cung ứng giao dịch hiện có.

Trong hệ thống hiện tại:

1. Các giao dịch được gửi đến bể nhớ công cộng hoặc riêng tư.
2. Các nhà xây dựng thu thập các giao dịch này và đóng gói chúng thành các khối.
3. Sau đó, các nhà xây dựng cạnh tranh trong một cuộc đấu giá khối.
4. Khối xây dựng chiến thắng được bao gồm trong blockchain và giá trị mà họ đặt cược được trả cho người đề xuất được chọn cho khối đã cho.

Hình dưới đây minh họa quá trình này, cho thấy cách giao dịch được chuyển từ mempools vào blockchain thông qua builders và trusted relays.

Sơ đồ chuỗi cung ứng giao dịch hiện tại

Các ứng dụng được kích hoạt bởi ASS, ånhå còn lại, có các tính chất sau:

1. Quyền xếp hàng hạn chế: Hạn chế này đảm bảo chỉ có sequencer được chỉ định hoặc các validator đã đặt cược mới có thể tương tác với hợp đồng ứng dụng trên chuỗi mà nó giải quyết, ngăn chặn việc lạm dụng logic ứng dụng để phân phối giá trị nội bộ.
2. Mempools Cụ thể cho Ứng dụng: Thay vì gửi giao dịch vào một mempool công cộng, người dùng gửi các tin nhắn đã ký biểu thị ý định của họ đến một mempool cụ thể cho ứng dụng. Những ý định này sau đó được thu thập và xử lý bởi bộ sắp xếp cụ thể cho ứng dụng.
3. Kết quả Đa dạng Thứ tự: Để áp dụng quy tắc sắp xếp và cung cấp lợi ích kinh tế tối ưu cho người dùng mục tiêu, các giao dịch ASS cần phải đa dạng thứ tự đối với việc sắp xếp giao dịch của người xây dựng cho phần còn lại của khối. Điều này được đạt được bằng cách đảm bảo trạng thái của ứng dụng được Gated bởi cơ chế đồng thuận của nó. Các đơn đặt hàng ASS sau đó được hợp nhất thành một gói duy nhất được gửi đến người xây dựng để bao gồm. Với việc gói này không gây tranh cãi với trạng thái được truy cập bởi các ứng dụng khác, nó là đa dạng thứ tự đối với vị trí của nó trong khối.

ASS cho phép các ứng dụng trên bất kỳ chuỗi nào đạt lại chủ quyền đối với việc thực thi và trạng thái hợp đồng của nó, từ đó tạo điều kiện cho các ứng dụng chủ quyền.

Với những nguyên lý cơ bản này, hãy sử dụng Angstrom như một ví dụ thực tế về ứng dụng có chủ quyền. Angstrom là một móc UniswapV4 bảo vệ các nhà cung cấp thanh khoản của mình khỏi sự lựa chọn bất lợi của các nhà kinh doanh chênh lệch giá CEX-DEX, đồng thời bảo vệ người hoán đổi khỏi các cuộc tấn công bánh sandwich. Một mạng lưới các nút Angstrom đi đến sự đồng thuận, song song với Ethereum, về tập hợp các giao dịch sẽ được thực hiện trong khối tiếp theo. Quy trình chung như sau:

1. Các nhà môi giới CEX-DEX đấu giá để có quyền là giao dịch đầu tiên được hoán đổi thông qua AMM (không tốn phí). Trong khi đó, người dùng gửi các giao dịch hoán đổi dự định của họ dưới dạng lệnh giới hạn đã ký vào Angstrom mempool.
2. Mạng Angstrom chạy giao thức đồng thuận của mình và tạo thành một gói hàng trong đó giao dịch giao hoán đầu tiên là giao dịch giao hoán với giá cao nhất. Số tiền đặt cược sau đó được phân phối, tỷ lệ thuận, cho các LP cơ bản trong phạm vi của giao hoán. Tất cả các lệnh giới hạn hợp lệ khác, cùng với tính thanh khoản AMM cơ bản, được thực hiện với cùng một giá thanh toán đồng đều.
3. Bunle này sau đó được gửi đến các nhà xây dựng Ethereum và bộ nhớ tạm công cộng bởi nút Angstrom đề xuất cho khe cắm.
4. Builders bao gồm gói Angstrom ở bất kỳ vị trí nào trong khối. Gói chỉ cần trả phí cơ bản cho việc bao gồm do cấu trúc không phụ thuộc vào thứ tự.

Biểu đồ dưới đây minh họa ứng dụng chủ quyền đang hoạt động.

Dây chuyền cung ứng giao dịch trong Angstrom

Sự sống còn và Giả định tin cậy

Ở cốt lõi, ASS là một hình thức xây dựng khối một phần trong đó một Ứng dụng chủ quyền ủy quyền quyền sắp xếp cho một mạng phi tập trung của các nhà điều hành theo một quy tắc sắp xếp được quy định. Do đó, ASS tất yếu liên quan đến các bên bên ngoài đưa ra giả định về sự sống còn và tin cậy bổ sung.

Giả định tính sống động

Ứng dụng chủ quyền phụ thuộc vào các bộ xử lý cụ thể của ứng dụng để tuân theo giao thức một cách chính xác và cung cấp cập nhật trạng thái kịp thời. Trong trường hợp vi phạm tính liveness, như là mộtPhân vùng mạng, người dùng có thể không tương tác với các phần của ứng dụng cho đến khi sự đồng thuận hợp lệ được khôi phục.

Ứng dụng chủ quyền cũng có thể giới hạn phạm vi trạng thái hợp đồng mà cập nhật của nó phụ thuộc vào sequencer của chúng. Điều này giúp giảm thiểu sự phụ thuộc bên ngoài của hợp đồng sao cho các trạng thái quan trọng, như tính thanh khoản đã gửi, vẫn có thể truy cập ngay cả khi sequencer gặp sự cố.

Giả định tin cậy

Để đảm bảo các sequencer tuân thủ theo các quy tắc xếp theo quy định, các ứng dụng chủ quyền có thể tận dụng các giải pháp cryptoeconomic (như PoS) hoặc các phương pháp mật mã (như TEE hoặc MPC). Cách tiếp cận cụ thể có thể thay đổi đáng kể tùy thuộc vào nhu cầu của ứng dụng; một số có thể yêu cầu sự đồng thuận về tính tối ưu trong thực thi, trong khi những ứng dụng khác có thể tập trung vào việc đảm bảo quyền riêng tư trước thực thi thông qua cơ chế mật mã. Có rất nhiều công cụ có sẵn để giảm thiểu chi phí tín nhiệm của sequencers và đáp ứng các mục tiêu duy nhất của mỗi ứng dụng chủ quyền.

Kháng cự kiểm duyệt

Có nhiều loại kiểm duyệt đang gây vấn đề trong hệ sinh thái Ethereum:

1. Kiểm duyệt theo quy định: Các nhà xây dựng và chuyển tiếp các giao dịch kiểm duyệt dựa trên danh sách xử phạt của OFAC. Đây là một trong những hình thức kiểm duyệt nổi bật nhất hiện nay trên Ethereum, chủ yếu được thực thi bởi rơle.
2. Kiểm duyệt kinh tế: Một kẻ tấn công có động cơ có thể hối lộ người đề xuất khối để kiểm duyệt các giao dịch của nạn nhân.
3. Censorship cấp node: Các node trong mạng P2P có thể từ chối lan truyền giao dịch đến. Điều này có thể là một vấn đề lớn nếu giao thức hoạt động tối ưu dưới giả định rằng đa số các node chia sẻ cùng quan điểm về giao dịch đến. Ngoài ra, trong các giao thức như vậy, kẻ thù có thể được khuyến khích để phân chia quan điểm cục bộ của các node trung thực (bằng cách gửi giao dịch chỉ đến một nửa số node vào cuối slot) và dừng giao thức lại như một kết quả.

Nhiều nhà nghiên cứu đã đề xuất nhu cầu về một cơ chế chống kiểm duyệt tốt hơn trên Ethereum. Một số đề xuất, như Nhiều người đề xuất đồng thời (MCP) và Danh sách bao gồm thực thi Fork-Choice (FOCIL), đã xuất hiện và trở thành trung tâm của một cuộc thảo luận đang diễn ra.

Chống kiểm duyệt cũng là một mối quan tâm lớn đối với ứng dụng có chủ quyền. Các trình tự dành riêng cho ứng dụng có khả năng là các thực thể bên ngoài có nhiều lợi ích khác nhau trong việc nhận thêm các giao dịch riêng tư và luồng đặt hàng. Ví dụ: người xác thực dành riêng cho ứng dụng là nhà tạo lập thị trường có động cơ kiểm duyệt các giao dịch được gửi bởi các nhà tạo lập thị trường cạnh tranh. Do đó, ứng dụng có chủ quyền trên đầu trang có thể bị kiểm duyệt cục bộ ngay cả khi giao thức cơ sở không kiểm duyệt.

Một ví dụ về cơ chế chống kiểm duyệt đối với ASS là Angstrom. Để đảm bảo rằng tất cả các đơn đặt hàng hợp lệ được bao gồm trong vị trí sắp tới, các nút Angstrom phải phát bất kỳ đơn đặt hàng đến nào đã được xác minh và đạt được sự đồng thuận về việc đưa chúng vào gói giao dịch được đề xuất. Nếu gói bị thiếu đơn đặt hàng được quan sát bởi phần lớn mạng lưới, người đề xuất sẽ bị phạt. Dưới đây là một minh họa về cơ chế chống kiểm duyệt cho Angstrom.

Khả năng chống kiểm duyệt trong một ứng dụng chủ quyền phi tập trung

Dilemma về tính tương tác

Một trong những thách thức lớn mà các ứng dụng có chủ quyền phải đối mặt là đảm bảo khả năng kết hợp với các giao dịch tương tác với các trạng thái hợp đồng bên ngoài. Chỉ cần kết hợp các giao dịch dành riêng cho ứng dụng với các giao dịch bên ngoài tùy ý sẽ làm suy yếu thuộc tính bất khả tri về thứ tự cần thiết để bảo vệ ứng dụng có chủ quyền và người dùng của nó. Một giao dịch không phải ASS không hợp lệ, khi được soạn với một giao dịch dành riêng cho ứng dụng, có thể có tác dụng bậc hai là hoàn nguyên toàn bộ gói. Khi điều này xảy ra, ứng dụng có chủ quyền không thể thực hiện các lệnh của người dùng trong thời gian được phân bổ (mặc dù đã đạt được sự đồng thuận hợp lệ), do đó làm tổn hại đến trải nghiệm người dùng và phúc lợi tổng thể.

Tuy nhiên, có những giải pháp tiềm năng cho vấn đề về khả năng kết hợp, mà một số trong số đó đang được các nhóm nghiên cứu khám phá. Các giải pháp này bao gồm các khái niệm như xác nhận trước khi bao gồm, trình tự chung cho các ứng dụng cụ thể và cam kết của người xây dựng, mỗi giải pháp đều mang lại sự cân nhắc giữa khả năng kết hợp và chi phí độ tin cậy.

Xác nhận trước khi bao gồm

Để giải thích việc xác nhận trước sự bao gồm, điều quan trọng là hiểu cách xác nhận trước dựa trên cơ sở hoạt động. Xác nhận trước dựa trên cơ sở tận dụng bảo mật cryptoeconomic bằng cách đảm bảo những người đề xuất đã đặt cọc để đảm bảo việc bao gồm một tập hợp cụ thể các giao dịch trước một khe trong epoch hiện tại. Sự đảm bảo này được giới hạn bởi kích thước của tiền đặt cọc được đăng bởi những người đề xuất tham gia.

Xác nhận trước bao gồm là một hình thức xác nhận trước dựa trên chuyên biệt, trong đó bao gồm giao dịch độc lập với bất kỳ trạng thái hợp đồng nào. Các giao dịch yêu cầu xác nhận trước bao gồm phải là trạng thái bất khả tri và không gây tranh cãi, có nghĩa là việc thực hiện chúng không bị ảnh hưởng bởi vị trí của chúng trong khối. Bằng cách sử dụng các xác nhận trước bao gồm, người đề xuất có thể cam kết bao gồm một giao dịch không phải ASS chỉ khi gói ASS được bao gồm trong cùng một khối. Cách tiếp cận này cung cấp khả năng kết hợp được thực thi bằng tiền điện tử giữa các giao dịch không gây tranh cãi và các gói ASS.

Minh họa bao gồm preconf với ASS

Tuy nhiên, do khả năng kết hợp hạn chế được cung cấp bởi giải pháp này, sự phức tạp và chi phí tin cậy bổ sung có thể lớn hơn lợi ích của nó đối với một số ứng dụng có chủ quyền nhất định. Do đó, điều quan trọng là khám phá các phương pháp thay thế có thể mang lại sự cân bằng hiệu quả hơn giữa sự đơn giản và chức năng.

Cam kết trình tự & trình tạo cụ thể của ứng dụng được chia sẻ

Thay vì phụ thuộc vào cam kết của người đề xuất, các ứng dụng chủ quyền có thể sử dụng các bộ sắp xếp cụ thể của ứng dụng để quản lý việc sắp xếp giao dịch trên nhiều ứng dụng. Ví dụ, một bộ sắp xếp xử lý các giao dịch cho một số ứng dụng chủ quyền có thể tạo điều kiện cho tính toàn vẹn nguyên tử giữa chúng, miễn là nó tuân thủ các quy tắc sắp xếp của mỗi ứng dụng. Phương pháp sắp xếp ứng dụng cụ thể được chia sẻ này cho phép tính toàn vẹn và phối hợp mượt mà trên các ứng dụng chủ quyền.

Tuy nhiên, đối với các ứng dụng không có chủ quyền, cần có một giải pháp khác. Các cam kết bao gồm giao dịch từ các nhà xây dựng khối tham gia vào trình tự cho các ứng dụng có chủ quyền có thể tạo ra khả năng kết hợp nguyên tử giữa các ứng dụng không có chủ quyền và có chủ quyền. Builder đảm bảo thứ tự giao dịch được chỉ định trên cả hai loại ứng dụng. Cam kết xây dựng như vậy có thể thu hẹp khoảng cách khả năng kết hợp cho ASS.

Minh họa cam kết của nhà xây dựng về khả năng kết hợp nguyên tử giữa dApps có chủ quyền và không có chủ quyền (phải) và trình tự dành riêng cho ứng dụng dùng chung cho khả năng kết hợp nguyên tử giữa các Ứng dụng có chủ quyền (trái)

Mặc dù vẫn còn những câu hỏi về động lực kinh tế của cam kết của người xây dựng, khả năng bao gồm xác nhận trước và các tác động cấp hai tiềm năng, nhưng chúng tôi tự tin rằng các thách thức về tính kết hợp của ASS sẽ được giải quyết trong thời gian tới. Những nhóm như Astria và Nguyên thủyđang tích cực nghiên cứu và phát triển các khung việc chia sẻ trình tự và cam kết của builder được cải tiến. Khi những tiến bộ này tiến triển, tính kết hợp sẽ không còn là vấn đề đối với các ứng dụng chủ quyền nữa.

ASS vs Ứng dụng cụ thể L2 và L1

Hiện tại, dApps phải xây dựng các chuỗi ứng dụng cụ thể nếu muốn kiểm soát thứ tự của giao dịch của mình. Các khái niệm như Protocol Owned Builder (PoB) cho phép Cosmos L1 có nhiều quy tắc giải trình tự biểu cảm hơn giúp nắm bắt và phân phối lại MEV cho ứng dụng của chúng. Tương tự, một bộ sắp xếp chuỗi L2 với VSR cũng có thể thực hiện các hoạt động như vậy. Mặc dù cả hai giải pháp đều cho phép giải trình tự biểu cảm hơn và nắm bắt MEV bằng các ứng dụng của nó, ASS là duy nhất do các đặc điểm sau.

1. Không có chi phí tin cậy từ việc thực hiện giao dịch - ASS không thực hiện hoặc giải quyết giao dịch theo trình tự. Chỉ có việc sắp xếp được ủy quyền. Giả định tin cậy cơ bản mở rộng từ môi trường thực thi nguyên thuỷ, chẳng hạn như Ethereum hoặc các L2 khác.
2. Truy cập vào thanh khoản và luồng lệnh - Người dùng không cần phải cầu nối. Ứng dụng phi tập trung có thể trực tiếp tận dụng luồng và thanh khoản trên chuỗi.
3. Tài sản ở lại trong môi trường thực thi bản địa và không thể bị đóng băng - Không giống như L2, hầu hết ASS không đòi hỏi người dùng phải khóa quỹ của họ trong hợp đồng cầu nối. Lựa chọn thiết kế này cung cấp an ninh tốt hơn: nếu một sequencer cụ thể của ứng dụng gặp sự cố, thiệt hại tiềm năng bị giới hạn vì sequencer chỉ có thể kiểm soát giao dịch trong phạm vi được đặt bởi hợp đồng thông minh. Mặc dù một số giải pháp L2 có thực hiện các tính năng an toàn - như lỗ thoát vàthêm bắt buộcNhững biện pháp này thường khó sử dụng trong thực tế. Người dùng có thể cần phải chờ đợi vài ngày trước khi họ có thể kích hoạt cửa thoát hiểm sau khi mất kết nối với cập nhật L2. Tương tự, việc bắt buộc bao gồm ít nhất là qua L1.một ngàyđộ trễ. Có lẽ quan trọng nhất, những biện pháp an toàn này thường đòi hỏi kiến thức kỹ thuật mà hầu hết người dùng không có, khiến chúng trở nên không thực tiễn đối với người thông thường.
4. Giả định về tính sống động mạnh mẽ - Tính sống động của L2 phụ thuộc vào các nút thực thi, thường là trình tự rollup, trừ khi có dựa trên thứ tự. Tính sống động của L1 phụ thuộc vào số đa số trung thực của các nút thực hiện lại các chức năng chuyển đổi trạng thái tương ứng. Tính sống động của một ứng dụng chủ quyền chủ yếu phụ thuộc vào môi trường thực thi cơ bản, và hợp đồng thông minh có thể chỉ định các phần cần phụ thuộc vào trình tự cụ thể của ứng dụng.

Bảng so sánh các ứng dụng chủ quyền, L2, Dựa trên L2 và L1

Kết luận

ASS trao quyền cho các ứng dụng có toàn quyền đối với trình tự giao dịch, cho phép chúng xác định các quy tắc tùy chỉnh mà không phức tạp trong việc quản lý thực thi. Chủ quyền này cho phép các ứng dụng kiểm soát việc thực thi nó để tối ưu hóa kết quả cho người dùng của họ. Ví dụ, trên Angstrom, LP và swapper được coi là những người tham gia hạng nhất, với lợi ích kinh tế của họ được tăng cường trực tiếp thông qua các quy tắc trình tự tùy chỉnh.

Ngoài ra, ASS có thể tận dụng một loạt các công cụ kinh tế mật mã và mật mã để thực thi tính tối ưu của các khoản thanh toán của người dùng và thực hiện các cơ chế chống kiểm duyệt mạnh mẽ. Các giải pháp kinh tế mật mã, chẳng hạn như đặt cọc và chém, có thể khuyến khích hành vi trung thực giữa các trình tự, trong khi các phương pháp mật mã như TEE và MPC tăng cường quyền riêng tư và bảo mật. Với những công cụ này, tiềm năng thiết kế của ASS là rất lớn, cho phép tạo ra các ứng dụng có chủ quyền an toàn, hiệu quả và lấy người dùng làm trung tâm hơn.

Mặc dù cung cấp cơ hội, thách thức như thiếu khả năng tương thích cấu trúc tự nhiên vẫn tồn tại. Tuy nhiên, các giải pháp như xác nhận trước sự bao gồm, chia sẻ ASS và cam kết của người xây dựng đưa ra các cách tiếp cận hứa hẹn để vượt qua những rào cản này. Mặc dù vẫn còn một số câu hỏi, chúng tôi cam kết hoàn thiện các phương pháp này để mang đến một trải nghiệm ASS mượt mà hơn, có thể tương thích hơn.

Chúng tôi ở đây để làm cho DeFi bền vững hơn, một ASS một lần.

Thông báo miễn trừ trách nhiệm:

1. Bài viết này được sao chép từ [ sorella]. Tất cả các bản quyền thuộc về tác giả gốc [ Yuki Yuminaga]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ Gate Họcđội ngũ và họ sẽ xử lý ngay lập tức.
2. Tuyên bố từ chối trách nhiệm: Các quan điểm và ý kiến được trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi đội ngũ Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn bản dịch là không được phép.