Phân tích cú pháp đề xuất B52 của Phòng thí nghiệm Aztec: ZK-Rollup nhận ra sự phân cấp của các nút trình tự như thế nào?

Tác giả: 0xhhh, EthStorage

Biên tập viên: Faust, Geek web3

Giới thiệu: Kể từ khi Rollup trở nên phổ biến, tính phi tập trung của Sequencer luôn là tâm điểm của cộng đồng Ethereum/Celestia và nó cũng là ngọn núi không thể vượt qua trong quá trình nghiên cứu và phát triển Layer2. Về vấn đề này, các lược đồ Rollup khác nhau đã đề xuất các ý tưởng về phân cấp nút, mang lại không gian tưởng tượng cực kỳ rộng cho chủ đề này.

Tác giả của bài viết này lấy dự án ZKRollup nổi tiếng Aztec làm ví dụ và sử dụng hai đề xuất có tên B52 và Fernet do Aztec Labs đề xuất gần đây làm điểm khởi đầu để phân tích cách ZKR thực hiện việc phân cấp các nút trình tự cho người đọc.

Đề xuất B52: Sơ đồ trình sắp xếp thứ tự không được phép

Đề xuất B52 dự định đạt được những điều sau (lý tưởng):

  1. Mạng giải trình tự phi tập trung, các nút L2 tự bầu chọn từng vòng đề xuất

  2. Mạng chuẩn hóa phi tập trung, yêu cầu phần cứng thấp đối với các nút chuẩn

  3. Rollup nói chung có khả năng chống lại sự kiểm duyệt tốt.

  4. Giá trị MEV do L2 tạo ra được các nút L2 thu nhận

  5. Khi khối L2 được gửi tới lớp DA, có thể thu được kết quả cuối cùng hiệu quả hơn và kết quả cuối cùng không thể đảo ngược phải chờ ValidityProof (bằng chứng hợp lệ) được gửi

  6. Mã thông báo L2 có thể có một mô hình kinh tế tốt

  7. Cả khối L2 và dữ liệu giao dịch đều được lan truyền trong mạng L2 p2p

  8. L2 kế thừa tính bảo mật của L1

Phân tích đề xuất B52 của Phòng thí nghiệm Aztec: Làm thế nào để ZK-Rollup nhận ra sự phân cấp của các nút trình tự sắp xếp?

Sơ đồ này chia toàn bộ quy trình sản xuất khối L2 thành ba giai đoạn:

  1. Cửa sổ đề xuất khối (BPW)
  2. Cửa sổ chấp nhận khối (BAW)
  3. Tạm ứng của Nhà nước

Trong số đó, giai đoạn BPW (đề xuất khối) là một quá trình trong đó nhiều trình sắp xếp thứ tự Seuqnecer đề xuất các khối khác nhau và cạnh tranh, và Prover chọn một khối ứng cử viên để bỏ phiếu.

BAW (Chấp nhận khối) là quá trình trong đó Nhà cung cấp xây dựng Bằng chứng về tính hợp lệ cho một khối và gửi khối đó.

Cửa sổ đề xuất khối (giai đoạn đề xuất khối):

BPW có thể được chia thành ba giai đoạn: Đề xuất khối, Biểu quyết khối, Tổng hợp.

Phân tích đề xuất B52 của Phòng thí nghiệm Aztec: Làm thế nào để ZK-Rollup nhận ra sự phân cấp của các nút trình tự sắp xếp?

Phân tích đề xuất B52 của Phòng thí nghiệm Aztec: Làm thế nào để ZK-Rollup nhận ra sự phân cấp của các nút trình tự sắp xếp?

Bất kỳ ai trong giai đoạn Đề xuất khối (BP) đều có thể thu thập các giao dịch và phát nội dung BP của riêng họ. Nội dung BP sẽ bao gồm ba phần: băm đơn hàng txs, tỷ lệ phần thưởng chứng minh, đốt số lượng mã thông báo

Phân tích đề xuất B52 của Phòng thí nghiệm Aztec: Làm thế nào để ZK-Rollup nhận ra sự phân cấp của các nút trình tự sắp xếp?

băm đơn hàng txs: Người đề xuất chọn và sắp xếp lô giao dịch có giá trị nhất từ nhóm giao dịch L2 (mempool), sau đó đặt giá trị băm của lô giao dịch này vào khối mà nó xây dựng.

tỷ lệ phần thưởng của người chứng minh: Phần trăm phần thưởng khối được Sequencer chia sẻ cho Người chứng minh

số lượng mã thông báo ghi: Số lượng Mã thông báo gốc L2 do Người đề xuất đề xuất sẽ bị hủy, sau đó nó sẽ gửi BP được đề xuất tới mạng L2 p2p

Giai đoạn bỏ phiếu khối:

Phân tích đề xuất B52 của Phòng thí nghiệm Aztec: Làm thế nào để ZK-Rollup nhận ra sự phân cấp của các nút trình tự sắp xếp?

Sau khi Người đề xuất nhận được BP do những Người đề xuất khác nhau đề xuất trong mạng p2p, anh ấy sẽ bỏ phiếu cho BP có thể mang lại cho anh ấy nhiều phần thưởng nhất. Tuy nhiên, thành phần bình chọn rất đặc biệt:

Bình chọn={BlockHash, Index của Proof Tree}

BlockHash là hàm băm của Đề xuất mà Nhà cung cấp sẽ bỏ phiếu và Chỉ mục của Cây Bằng chứng là giá trị chỉ số lá của Cây Bằng chứng mà Nhà cung cấp sẽ tham gia xây dựng (giải thích sau)

Phân tích đề xuất B52 của Phòng thí nghiệm Aztec: Làm thế nào để ZK-Rollup nhận ra sự phân cấp của các nút trình tự sắp xếp?

Tổng hợp tổng hợp: Người đề xuất thu thập phiếu bầu của Người đề xuất cho BP trong mạng L2 p2p, tổng hợp và đưa vào BP, đồng thời gửi chúng tới L1 (mỗi BP thường chỉ chứa các bản ghi biểu quyết liên quan đến chính nó).

Phân tích đề xuất B52 của Phòng thí nghiệm Aztec: Làm thế nào để ZK-Rollup nhận ra sự phân cấp của các nút trình tự sắp xếp?

Ở đây cần nhấn mạnh điều kiện tiên quyết để BP được chọn và đưa vào sổ cái Rollp:

Có số điểm cao nhất:

ĐIỂM(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2

NUM_PROVERS (x) là số phiếu bầu của Người chứng minh mà BP đã nhận được và BURN_BID là số lượng Mã thông báo L2 được đề xuất hủy bởi BP. Vì BURN_BID càng cao thì cuối cùng phần thưởng mà người đề xuất BP nhận được càng ít, vì vậy giá trị này phải được đặt đúng cách.

Đồng thời, BP cần được gửi tới L1 trước khi kết thúc Cửa sổ đề xuất khối và bằng chứng về tính hợp lệ tương ứng phải được tải lên L1 trước khi kết thúc Cửa sổ chấp nhận khối.

Lưu ý: Trong cách tính điểm BP, số phiếu bầu chiếm tỷ lệ lớn nhất, tiếp theo là số lượng token được đốt. Đồng thời, sơ đồ B52 cho phép nhiều người đề xuất (thực chất là người giải trình tự) cạnh tranh để giành được hạn ngạch BP hiệu quả

Lược đồ B52 chỉ yêu cầu Người đề xuất (trình sắp xếp thứ tự) chỉ định số lượng mã thông báo ghi trong BP của chính họ (tương tự như phương pháp của EIP1559) mà không cần đặt trước mã thông báo, điều này có thể khiến mạng trở nên không được phép (không có quyền truy cập) và là cũng có lợi cho Mã thông báo bản địa L2 tạo ra giảm phát.

Ngoài ra, BP không chứa dữ liệu giao dịch hoàn chỉnh mà chỉ chứa hàm băm của chuỗi giao dịch, lý do tương tự như sơ đồ Ethereum PBS, nhằm mục đích ngăn MEV bị theo dõi bởi những Người đề xuất khác.

Cửa sổ chấp nhận khối (giai đoạn chấp nhận khối) giải thích chi tiết:

Phân tích đề xuất B52 của Phòng thí nghiệm Aztec: Làm thế nào để ZK-Rollup nhận ra sự phân cấp của các nút trình tự sắp xếp?

Phân tích đề xuất B52 của Phòng thí nghiệm Aztec: Làm thế nào để ZK-Rollup nhận ra sự phân cấp của các nút trình tự sắp xếp?

Sau khi Cửa sổ đề xuất khối kết thúc, Nhà cung cấp cần tiết lộ dữ liệu giao dịch đầy đủ tương ứng với BP của họ. Nếu BP do Người chứng minh bình chọn được chọn (điểm cao nhất có thể được truy vấn thông qua hợp đồng L1), họ cần xây dựng Cây bằng chứng phụ tương ứng với Chỉ mục của Cây bằng chứng được đưa ra trong quá trình bỏ phiếu.

Phân tích đề xuất B52 của Phòng thí nghiệm Aztec: Làm thế nào để ZK-Rollup nhận ra sự phân cấp của các nút trình tự sắp xếp?

Giả sử rằng khối của Aztec chứa 2^13=16384 giao dịch và có 2048 trình chứng minh, sau đó mỗi trình chứng minh xây dựng một cây chứng minh phụ gồm 2^3 = 8 giao dịch. mạng. Sau khi người đề xuất nhận được nó, nó sẽ tổng hợp tất cả các cây bằng chứng phụ thành một bằng chứng khối.

Phân tích đề xuất B52 của Phòng thí nghiệm Aztec: Làm thế nào để ZK-Rollup nhận ra sự phân cấp của các nút trình tự sắp xếp?

Sau đó, Propsoer gửi bằng chứng tổng hợp cho hợp đồng L1 Rollup và hợp đồng sẽ xác minh tính chính xác của bằng chứng cũng như kết quả chuyển đổi trạng thái tương ứng. Cần lưu ý ở đây rằng nếu Người đề xuất cố tình không gửi bằng chứng, thì anh ta không những không thể nhận được cổ tức phần thưởng khối mà Người đề xuất đã hứa, mà còn bị chém, bởi vì để trở thành Người chứng minh, anh ta cần phải cầm cố Token trước. Do đó, không giống như Proposer (Sequencer), Prover không phải là Permissionless.

Giải thích chi tiết về thăng cấp bang (giai đoạn thăng cấp bang):

Phân tích đề xuất B52 của Phòng thí nghiệm Aztec: Làm thế nào để ZK-Rollup nhận ra sự phân cấp của các nút trình tự sắp xếp?

Sau khi Cửa sổ chấp nhận khối kết thúc, hợp đồng Rollup sẽ chọn một khối có điểm cao nhất để đưa vào sổ cái Rollup và gửi phần thưởng khối Phần thưởng cho Người đề xuất và Người chứng minh tương ứng theo tỷ lệ được Người đề xuất (Người sắp xếp thứ tự) tuyên bố trong nâng cao.

** Trên đây là giải pháp B52 của Aztec. Tuy nhiên, tác giả bài viết này cho rằng có một số vấn đề tiềm ẩn với đề xuất B52:**

Câu hỏi 1: Nếu bằng chứng hợp lệ của khối có số điểm cao nhất không đầy đủ. Giải pháp được đưa ra trong đề xuất là nếu Người đề xuất chỉ cung cấp 50% bằng chứng, thì anh ta chỉ có thể nhận được 50% phần thưởng khối, để đảm bảo rằng Người đề xuất không có động cơ cố tình không gửi bằng chứng hoàn chỉnh. Đồng thời, Prover cũng có thể gửi bằng chứng trực tiếp cho hợp đồng.

Theo mô tả của đề xuất, có thể chấp nhận một khối mà không có bằng chứng hợp lệ về các giao dịch hoàn chỉnh. Điều này thực sự không hợp lý: bởi vì: zkrollup chỉ tuyên bố rằng trạng thái mới tương ứng với khối này là hợp lệ khi bằng chứng hợp lệ được đưa ra.

Nếu bằng chứng tổng hợp do người đề xuất gửi tới L1 thiếu bằng chứng về một giao dịch nhất định, rõ ràng là bằng chứng chuyển đổi trạng thái của tất cả các giao dịch xảy ra sau giao dịch này là không hợp lệ (vì các giao dịch được thực hiện tuần tự và có các trạng thái phụ thuộc), chúng ta Cũng không thể xác nhận rằng trạng thái mới tương ứng với khối này là hợp lệ.

Do đó, tại thời điểm này, cách hợp lý là vào Cửa sổ chấp nhận khối chờ vô tận cho đến khi tất cả các bằng chứng giao dịch được gửi.

Câu 2: **Nếu khối có điểm cao nhất là khối không hợp lệ (điều này không được giải thích trong sơ đồ B52). **BP chỉ chứa hàm băm của chuỗi giao dịch, do đó, người đề xuất ác ý thực sự có thể cố tình xây dựng các giao dịch có vấn đề, chẳng hạn như giao dịch chi tiêu gấp đôi. Vì vậy, tại thời điểm này, thực sự cần thiết phải thêm một chức năng trong hợp đồng L1 để bất kỳ ai cũng có thể gửi bằng chứng bất hợp pháp. Bằng chứng bất hợp pháp này được sử dụng để chứng minh rằng BP có điểm cao nhất là một khối bất hợp pháp.

Và loại báo cáo này nên được khen thưởng, chúng tôi có thể thưởng mã thông báo ghi được gửi bởi người đề xuất hợp đồng cho nút báo cáo đã gửi bằng chứng bất hợp pháp.

**Suy nghĩ thú vị:**Về khối chú và Công việc chứng minh dư thừa: Kế hoạch B52 sẽ thực sự sử dụng các BP khác (những người đã gửi bằng chứng đầy đủ) xuất hiện trong vòng này với tư cách là chú sau khi BP có số điểm cao nhất trong mỗi vòng xuất hiện. chỉ định một phần thưởng khối chú nhất định.

Điều này thực sự tuân theo cách tiếp cận của cơ chế đồng thuận ETH POW. Để tránh tập trung quá mức sức mạnh tính toán, cần phải phân bổ một phần phần thưởng khối cho những người đề xuất khối không được chấp nhận (thợ mỏ) để bảo vệ lợi ích của các nhóm khai thác nhỏ/thợ mỏ cá nhân và tránh Sức mạnh tính toán bị độc quyền bởi các nhóm khai thác lớn. Do đó, việc áp dụng cơ chế khối chú mà Ethereum hoạt động tốt cũng là một lựa chọn rất thông minh.

Tầm quan trọng của đề xuất B52 về phân cấp Rollup: Người đề xuất được phân cấp và không yêu cầu cam kết, và ngưỡng tham gia thấp; nhưng vì bạn cần tự xây dựng các khối có giá trị nhất và bạn cần thu thập phiếu bầu từ những Người đề xuất khác và tổng hợp tất cả Bằng chứng. Trên thực tế, ngưỡng phần cứng của Người đề xuất không thấp như đã nêu trong đề xuất (ví dụ: băng thông có thể không quá thấp).

Do đó, cuối cùng nó sẽ trở thành một mạng tương đối tập trung, tương tự như Mev-Boost Builder, bởi vì người đề xuất cuối cùng có thể tạo khối thường là Trình tạo khối giỏi nhất trong việc nắm bắt MEV.

Đồng thời, Prover trong sơ đồ B52 cần thế chấp tài sản, nhưng vì chỉ cần tạo bằng chứng cây con, so với các sơ đồ cần tạo hoàn toàn toàn bộ bằng chứng khối, ** Mức độ phân cấp của Prover sẽ tốt hơn (yêu cầu phần cứng có thể được hạ xuống). **

Active Liveness: Nhìn chung, Liveness của mạng là tốt, vì L2 có mạng p2p riêng để phát các giao dịch và phiếu bầu/BP, đồng thời Sequencer và Prover tương đối phi tập trung. Nhưng chúng ta cần giải quyết hai vấn đề mà chúng ta đã đề cập ở trên, một là khối có điểm cao nhất phải là khối hợp pháp, thứ hai là nó cần đợi bằng chứng khối hoàn chỉnh được gửi tới L1 trước khi vào một khối mới. tình trạng. Do đó, cần có một cơ chế khuyến khích hiệu quả hơn để ngăn chặn toàn bộ mạng Rollup bị trục trặc (thời gian chết) do thiếu một phần nào đó của bằng chứng tx.

**Khả năng chống kiểm duyệt: **Nếu chúng tôi có thể đảm bảo rằng bất kỳ ai cũng có thể xuất bản BP đề xuất chặn và đảm bảo rằng không chỉ Người đề xuất có thể gửi bằng chứng chặn, thì mạng sẽ có khả năng chống kiểm duyệt tốt.

**Tính cuối cùng: **Tính cuối cùng của L2 có liên quan chặt chẽ đến tính sống động của mạng, bởi vì tính cuối cùng được xác minh cuối cùng vẫn cần chờ gửi Bằng chứng khối, nhưng trên thực tế, bạn cũng có thể tin tưởng vào nội dung khối tương ứng với một BP với số điểm cao nhất (miễn là nó không chứa các giao dịch độc hại).

Khối này sẽ được tiết lộ khi bắt đầu Cửa sổ chấp nhận khối, có nghĩa là với tư cách là người dùng, bạn chỉ cần đợi Cửa sổ đề xuất khối và khối mà giao dịch bạn gửi có thể được chấp nhận.

Kế thừa tính bảo mật của L1: Là một L2 cập nhật trạng thái của mình bằng cách gửi bằng chứng hợp lệ, nó có thể kế thừa tính bảo mật của L1.

Proposal Fernet: Giới thiệu VDF để lựa chọn Proposal hợp pháp

Giới thiệu sơ đồ Fernet: Thông qua VDF, trong mỗi vòng của chu kỳ tạo khối, điểm số ước tính được đặt cho các nút khác nhau trong Ủy ban (nghĩa là tập hợp các nút Trình tạo chuỗi) và khối do Trình sắp xếp chuỗi đề xuất với điểm cuối cùng cao nhất sẽ trở thành quân cờ hợp lệ.

**Đầu tiên, làm thế nào để tham gia Ủy ban? Trên thực tế, bạn cần cam kết 16 ETH trong L1, **và đợi 4 khối L1 sau khi hoạt động cam kết hoàn tất, sau đó tham gia Ủy ban Sequencer. Đối với việc thoát khỏi Ủy ban Sequencer, bạn cần gọi chức năng Unstake trong hợp đồng L1, sau đó bạn có thể lấy lại số tiền cam kết còn lại sau 3 ngày nữa.

Sau đó, một VDF là gì? Verifiable Delay Function là một hàm trì hoãn có thể kiểm chứng. Hàm toán học này đáp ứng các đặc điểm thực thi nối tiếp nghiêm ngặt. Nó sẽ thực hiện một số bước tính toán và tiêu tốn ít nhất một khoảng thời gian có thể dự đoán được. Chúng tôi ghi lại giá trị do VDF tính toán dưới dạng Điểm, thỏa mãn phân phối chuẩn thống nhất. Do đó, sau khi Sequencer tính toán Điểm VDF, nó có thể đánh giá xác suất được chọn làm người đề xuất hợp pháp. **

VDF của Sequencer được tính như sau:

Điểm = VDF( privatekey , public input )

đầu vào công khai = {số khối hiện tại, randao}

randao là một số ngẫu nhiên được sử dụng để ngăn Sequencer tính toán trước Điểm VDF của chính nó ở tất cả các độ cao khối trong tương lai

Toàn bộ quá trình Fernet chủ yếu được chia thành 3 giai đoạn:

  1. Giai đoạn đề xuất 2. Giai đoạn chứng minh 3. Hoàn thiện

Phân tích đề xuất B52 của Phòng thí nghiệm Aztec: Làm thế nào để ZK-Rollup nhận ra sự phân cấp của các nút trình tự sắp xếp?

**Giai đoạn đề xuất:**PROPOSAL_PHASE_L1_BLOCKS = 2 khối Ethereum (giai đoạn này sẽ kéo dài cho 2 khối L1)

Khi bắt đầu giai đoạn này, mỗi Sequencer sẽ sử dụng VDF để tính Điểm VDF tương ứng của nó ở độ cao khối hiện tại. Nếu Sequencer cho rằng Điểm VDF của anh ấy có khả năng giành được quyền tạo khối lần này (giả sử Điểm thỏa mãn phân phối chuẩn), thì anh ấy sẽ gửi hợp đồng Tổng số từ Đề xuất tới L1. Đề xuất chứa: hàm băm của chuỗi giao dịch, trỏ đến khối L2 trước đó.

khối chưa được chứng minh: Chỉ nội dung khối của Đề xuất cho hợp đồng Rollup được gửi. Tiếp theo, **Sequencer cần gửi nội dung khối tương ứng với khối chưa được kiểm chứng và bằng chứng về VDF tới mạng L2 p2p. **

Giai đoạn chứng minh: PROVING_PHASE_L1_BLOCKS= 50 khối L1 (giai đoạn này sẽ duy trì 50 khối L1, khoảng 10 phút)

Prover nhận tất cả các giao dịch tương ứng trong Nội dung khối từ mạng L2 p2p và sẽ tạo Bằng chứng cho các khối có Điểm VDF cao hơn. Việc xây dựng Proof cũng áp dụng phương pháp nhiều Prover cộng tác song song (tương tự như sơ đồ B52).

Do đó, Sequencer cần tổng hợp các Proof tương ứng với nhiều giao dịch khác nhau thành một Block Proof (bao gồm cả VDF Proof) ở cuối và gửi nó cho hợp đồng Rollup của L1. Bất kỳ ai cũng có thể gửi Nội dung khối đã gửi Bằng chứng khối cho hợp đồng Rollup.

Hoàn thiện: Cần phải gửi giao dịch L1 để Hoàn tất khối. Một khối có thể được hoàn thiện cần phải đáp ứng: Nội dung khối và Bằng chứng khối được gửi và khối trước đó được trỏ tới phải được Hoàn thiện. Trên cơ sở đáp ứng các điều kiện trên, bạn cũng phải có Điểm cao nhất.

Phân tích đề xuất B52 của Phòng thí nghiệm Aztec: Làm thế nào để ZK-Rollup nhận ra sự phân cấp của các nút trình tự sắp xếp?

Cơ chế sản xuất khối đường ống: Cần lưu ý rằng Fernet áp dụng cơ chế sản xuất khối đường ống.Khi giai đoạn Đề xuất của khối thứ N kết thúc, Đề xuất của khối thứ N+1 bắt đầu (Aptos và các chuỗi công khai khác cũng có cách làm tương tự) . Nhưng đối với khối thứ N+1, nó cần đợi khối thứ N được Hoàn thiện trước khi có thể gửi giao dịch Khối cuối cùng L1 và vượt qua xác minh để trở thành Khối cuối cùng.

Các khía cạnh tấn công tiềm ẩn: Nếu Trình tạo chuỗi có Điểm VDF cao nhất cố tình không phát Nội dung khối trong L2 p2p, điều đó có thể dẫn đến việc sắp xếp lại khối.

Tính toán số khối L2 trong tổ chức lại: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 khối

Giải pháp: Tăng cơ chế khối chú thích để tránh chỉ có một khối ứng viên hoàn chỉnh cho mỗi khe L2 (khe thời gian tạo khối).

Tầm quan trọng của Fernet về mặt phân cấp: Sequencer tham gia Ủy ban Sequencer bằng cách cam kết 16 ETH và ngưỡng tham gia không cao (nhưng không thấp). Prover không yêu cầu bất kỳ cam kết nào, nhưng không có hình phạt nào nếu Prover không tạo Proof. Điều này về cơ bản là ngược lại với kế hoạch B52.

**Tính hoạt động tích cực: **Tính hoạt động của mạng tổng thể có thể được đảm bảo, bởi vì cơ chế khối chú VDF+có thể đảm bảo rằng có nhiều hơn một nhà sản xuất khối trong mỗi vòng.

**MEV: **Cân nhắc MEV là đặc biệt nhất, kế hoạch có kế hoạch giới thiệu PBS, để sau khi tính toán Điểm VDF cao với tư cách là Trình tạo chuỗi, bạn có thể trực tiếp tìm Trình tạo khối để tạo khối có giá trị hơn.

**Khả năng chống kiểm duyệt: **Fernet cũng sẽ áp dụng cơ chế PBS giống như Ethereum, vì vậy về bản chất, vấn đề chống kiểm duyệt của Fernet tương đương với vấn đề PBS của Ethereum.

Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
  • Phần thưởng
  • Bình luận
  • Chia sẻ
Bình luận
0/400
Không có bình luận
  • Ghim
Giao dịch tiền điện tử mọi lúc mọi nơi
qrCode
Quét để tải xuống ứng dụng Gate
Cộng đồng
Tiếng Việt
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)