• Chuyển tiếp Tiêu đề gốc：Bản tổng hợp phân cấp: Phân tích Giải pháp trình tự phân cấp của Aztec

Giới thiệu: Kể từ khi Rollup trở nên nổi bật, việc phân quyền của Sequencer luôn là trọng tâm của cộng đồng Ethereum/Celestia và đây cũng là một ngọn núi khó vượt qua trong công việc phát triển Layer2. Về vấn đề này, các kế hoạch tổng hợp khác nhau đã đề xuất các ý tưởng về phân cấp nút, mang lại khả năng tưởng tượng cực kỳ rộng rãi 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 được Aztec Labs đề xuất gần đây làm điểm đầu vào, để phân tích cho độc giả cách ZKR thực hiện phân cấp của các nút trình tự sắp xếp .

Đề xuất B52: Sơ đồ tuần tự không được phép

Đề xuất B52 nhằm đạt được các mục tiêu sau (lý tưởng nhất):

1. Mạng tuần tự phi tập trung, với các nút L2 bầu ra những người đề xuất cho mỗi vòng.

2. Mạng trình chứng minh phi tập trung, với yêu cầu phần cứng thấp cho các nút trình chứng minh.

3. Rollup sở hữu khả năng chống kiểm duyệt tuyệt vời nói chung.

4. Giá trị MEV được tạo trên L2 được các nút L2 thu được.

5. Khi các khối L2 được gửi đến lớp DA, có thể đạt được kết quả cuối cùng tương đối hiệu quả. Tính hữu hạn không thể đảo ngược đòi hỏi phải hoàn thành việc nộp Bằng chứng Hiệu lực.

6. Mã thông báo L2 có thể có mô hình mã thông báo phù hợp.

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

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

(Đề xuất B52 giả định cấu trúc Tổng hợp, Người đề xuất về cơ bản là Trình sắp xếp chuỗi)

Kế hoạch này chia toàn bộ quy trình sản xuất khối L2 thành ba giai đoạn:

Cửa sổ đề xuất khối (BPW) Cửa sổ chấp nhận khối (BAW) Tiến bộ trạng thái

Trong số đó, giai đoạn BPW (Đề xuất khối) là quá trình trong đó nhiều Người sắp xếp chuỗi đề 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 đó Prover xây dựng Bằng chứng hợp lệ cho khối và gửi nó. Cửa sổ đề xuất chặn (Giai đoạn đề xuất khối): BPW có thể được chia nhỏ thành ba giai đoạn – Đề xuất chặn, Bỏ phiếu chặn, Tổng hợp.

(Sơ đồ quy trình Cửa sổ đề xuất khối)

Giai đoạn Đề xuất chặn (BP): bất kỳ ai trong giai đoạn này đề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: hàm băm đơn hàng txs, tỷ lệ phần thưởng của người chứng minh, số lượng mã thông báo đốt.

Hàm băm đơn hàng txs: Người đề xuất chọn lô giao dịch có giá trị nhất từ nhóm giao dịch L2 (mempool), sắp xếp chúng và sau đó đặt giá trị băm của các giao dịch này vào khối mà họ đang 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 mà Trình sắp xếp chuỗi chia sẻ với Người chứng minh. số lượng mã thông báo đốt: Số lượng Mã thông báo gốc L2 mà Người đề xuất đề xuất đốt, sau đó họ gửi BP của mình đến mạng L2 p2p.

Giai đoạn bỏ phiếu chặn:

Sau khi Nhà cung cấp nhận được BP do những Người đề xuất khác nhau trong mạng p2p đề xuất, họ sẽ bỏ phiếu cho BP cho phép họ nhận được nhiều phần thưởng nhất. Tuy nhiên, thành phần của phiếu bầu rất đặc biệt:

Bình chọn={BlockHash, Index of Proof Tree}

BlockHash là hash của Proposal mà Prover muốn bình chọn, còn Index of Proof Tree là giá trị chỉ số lá của Proof Tree mà Prover muốn tham gia xây dựng (sẽ giải thích sau)

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

Ở đâ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 Prover mà BP này đã nhận được và BURN_BID là số lượng Token L2 được đề xuất đốt bởi BP này. Bởi vì BURN_BID càng cao thì phần thưởng cuối cùng mà người đề xuất BP sẽ nhận được càng ít, vì vậy giá trị này phải được đặt một cách thích hợp.

Đồng thời, BP này cần phải được gửi đến L1 trước khi kết thúc Cửa sổ đề xuất khối và Bằng chứng chứng minh tính hợp lệ tương ứng cần 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 của BP, số phiếu bầu chiếm trọng số lớn nhất, tiếp theo là số lượng burn token. Đồng thời, sơ đồ B52 cho phép nhiều người đề xuất (thực tế là người sắp xếp thứ tự) cạnh tranh để giành được hạn ngạch BP hợp lệ.

Lược đồ B52 chỉ yêu cầu Người đề xuất (trình tự sắp xếp) chỉ định số lượng mã thông báo ghi trong BP của riêng họ (tương tự như phương pháp EIP1559) mà không cần phải đặ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 hơn (không có quyền truy cập) và cũng có lợi cho việc giảm phát Token gốc của L2.

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, tương tự như sơ đồ PBS của Ethereum, nhằm mục đích tránh MEV bị những Người đề xuất khác nhìn trộm và chiếm trước.

Giải thích chi tiết về Cửa sổ chấp nhận khối:

(Sơ đồ của Cửa sổ chấp nhận khối, được viết dưới dạng Bằng chứng chấp nhận trong hình)

Sau khi Cửa sổ đề xuất chặn kết thúc, Nhà cung cấp cần tiết lộ dữ liệu giao dịch hoàn chỉnh tương ứng với BP của họ. Nếu BP mà Prover bình chọn được chọn (có số điểm cao nhất, có thể truy vấn thông qua hợp đồng L1) thì họ cần xây dựng Sub Proof Tree tương ứng với Index of Proof Tree đưa ra khi biểu quyết.

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

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

Giải thích chi tiết về Tiến bộ của Nhà nước:

Sau khi Cửa sổ chấp nhận khối kết thúc, hợp đồng Rollup sẽ chọn khối có số điểm cao nhất để đưa vào sổ cái Rollup và phần thưởng khối sẽ được gửi đến Người đề xuất (Sequencer) và Prover theo tỷ lệ mà Người đề xuất đã khai báo trước đó .

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

Vấn đề thứ nhất: Giả sử bằng chứng hợp lệ của khối có điểm cao nhất là 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, qua đó đả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ể trực tiếp nộp bằng chứng cho hợp đồng.

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

Nếu bằng chứng tổng hợp mà người đề xuất cuối cùng gửi tới L1 thiếu bằng chứng của một giao dịch nhất định thì rõ ràng bằng chứng chuyển 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 theo trình tự và có sự phụ thuộc trạng thái) và chúng tôi 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ý nhất là vào Cửa sổ chấp nhận khối chờ vô hạn cho đến khi tất cả bằng chứng giao dịch được gửi.

Vấn đề 2: Giả sử khối có điểm cao nhất là khối bất hợp pháp (điểm này không được giải thích trong phương án B52). BP chỉ chứa hàm băm của chuỗi giao dịch, do đó, kẻ đề xuất độc hại có thể cố tình tạo ra các giao dịch có vấn đề, chẳng hạn như giao dịch chi tiêu gấp đôi. Tại thời điểm này, thực sự cần phải thêm một chức năng vào hợp đồng L1 cho phép bất kỳ ai 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 đạt điểm cao nhất là một khối bất hợp pháp.

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

Ý nghĩ thú vị: Về các khối chú và Công việc Prover dư thừa: Kế hoạch B52 trên thực tế, sau mỗi vòng BP cao nhất và hợp lệ xuất hiện, sẽ coi các BP khác (những người đã gửi bằng chứng đầy đủ) trong vòng này là các khối chú và phân phối một lượng nhất định chú khối thưởng.

Điều này thực sự tuân theo cơ chế đồng thuận ETH POW. Để tránh sự tập trung quá mức vào sức mạnh tính toán, cần 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ỏ riêng lẻ và để ngăn chặn sức mạnh khai thác khỏi bị độc quyền bởi các nhóm khai thác lớn. Vì vậy, việc áp dụng cơ chế block chú hoạt động tốt của Ethereum 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ề mặt phân cấp Rollup: Người đề xuất được phân cấp và không yêu cầu thế chấp, rào cản gia nhập thấp. Tuy nhiên, vì nó yêu cầu tự mình xây dựng khối có giá trị nhất, cũng như thu thập phiếu bầu từ các Provers khác và tổng hợp tất cả các Proofs nên ngưỡng phần cứng của Người đề xuất không thấp như mô tả trong đề xuất (ví dụ: băng thông có thể không rất thấp).

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

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

Tính sống động: Mạng tổng thể Độ sống động tốt vì L2 có mạng p2p riêng để phát sóng các giao dịch và biểu quyết/BP, đồng thời cả Sequencer và Prover đều tương đối phi tập trung. Nhưng chúng ta cần giải quyết hai vấn đề nêu trên, một là khối có điểm cao nhất phải là khối hợp pháp, và thứ hai là chúng ta cần đợi bằng chứng khối hoàn chỉnh được gửi đến L1 trước khi vào trạng thái mới. Do đó, cần có cơ chế khuyến khích hiệu quả hơn để tránh trường hợp toàn bộ mạng Rollup không hoạt động bình thường (dừng) do thiếu một số 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 các đề xuất chặn BP và đảm bảo rằng không chỉ Người đề xuất mới 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 hữu hạn của L2 có liên quan chặt chẽ đến sự tồn tại của mạng, bởi vì tính hữu hạn được xác minh cuối cùng vẫn cần chờ gửi Block Proof, nhưng trên thực tế, bạn cũng có thể tin cậy vào nội dung khối tương ứng với BP đạt điểm cao nhất (miễn là có không chứa các giao dịch độc hại).

Khối này sẽ được hiển thị ở đầ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 trong khoảng thời gian Cửa sổ đề xuất khối và khối nơi giao dịch của bạn được đặt có thể được thông qua.

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

Đề xuất Fernet: Giới thiệu VDF cho việc lựa chọn người đề xuất

Tổng quan về Sơ đồ Fernet: Sử dụng VDF trong mỗi chu kỳ tạo khối, điểm dự kiến sẽ được gán cho các nút khác nhau trong Ủy ban (tập hợp các nút Trình sắp xếp chuỗi) và khối được Trình sắp xếp chuỗi đề xuất có điểm cuối cùng cao nhất sẽ trở thành khối hợp lệ.

Thứ nhất, làm thế nào để tham gia Ủy ban? Về cơ bản, nó yêu cầu đặt cược 16 ETH trên L1 và sau đó, sau khi quá trình đặt cược hoàn tất, chờ 4 khối L1 trước khi tham gia Ủy ban tuần tự. Đối với việc thoát khỏi Ủy ban tuần tự, người ta cần gọi hàm Unstake trong hợp đồng L1, sau đó phải mất 3 ngày để lấy lại số tiền đặt cược còn lại.

Tiếp theo, VDF là gì? Hàm trễ có thể xác minh là một hàm toán học tuân thủ các đặc điểm thực thi nối tiếp nghiêm ngặt. Nó thực hiện các bước tính toán nhất định và tiêu tốn một lượng thời gian có thể dự đoán được. Chúng tôi biểu thị giá trị được VDF tính toán là Điểm, tuân theo phân phối chuẩn thống nhất. Do đó, sau khi Người sắp xếp thứ tự tính toán Điểm VDF, họ có thể xác định xác suất được chọn làm Người đề xuất hợp pháp.

Việc tính toán VDF cho Sequencer như sau:

Điểm = VDF(khóa riêng, đầu vào công khai)

đầu vào công khai = { current block number , randao }

randao là một số ngẫu nhiên được sử dụng để ngăn Trình sắp xếp chuỗi tính toán sớm Điểm VDF của nó cho tất cả các chiều cao khối trong tương lai

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

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

Giai đoạn đề xuất: PROPOSAL_PHASE_L1_BLOCKS = 2 khối Ethereum (Giai đoạn này sẽ kéo dài trong thời gian 2 khối L1)

Khi bắt đầu giai đoạn này, mỗi Bộ sắp xếp thứ tự sẽ tính Điểm VDF của riêng mình ở độ cao khối hiện tại. Nếu Trình sắp xếp chuỗi tin rằng Điểm VDF của nó có khả năng giành được quyền sản xuất khối của khối này (giả sử Điểm thỏa mãn phân phối chuẩn), nó sẽ gửi Đề xuất cho hợp đồng Tổng hợp L1. Đề xuất bao gồm: 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: Khối chỉ gửi Đề xuất cho nội dung khối hợp đồng tổng hợp. Sau đó, Bộ sắp xếp chuỗi cần gửi nội dung khối tương ứng với khối chưa được chứng minh và bằng chứng của 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ẽ kéo dài trong 50 khối L1, khoảng 10 phút)

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

Do đó, Trình sắp xếp chuỗi cuối cùng cần tổng hợp Bằng chứng của nhiều giao dịch khác nhau thành Bằng chứng khối (bao gồm Bằng chứng VDF) và gửi nó đến hợp đồng Tổng hợp L1. Bất kỳ ai cũng có thể gửi Nội dung chặn đã gửi Bằng chứng khối cho hợp đồng tổng hợp.

Quyết toán: Nó cần gửi giao dịch L1 để Hoàn thiện khối, một khối cuối cùng có thể được Hoàn thiện cần phải đáp ứng: Đã gửi Nội dung khối và Bằng chứng khối, khối trước đó mà nó trỏ đến phải được Hoàn thiện. Trên cơ sở này, nó cũng cần phải có Điểm cao nhất.

(Quy trình chặn theo kiểu đường ống, ngay khi giai đoạn đề xuất của khối trước kết thúc, giai đoạn đề xuất của khối tiếp theo sẽ bắt đầu mà không cần đợi giai đoạn Chứng minh của khối trước đó kết thúc.)

Cơ chế tạo khối đường ống: Điều đáng chú ý là Fernet áp dụng cơ chế tạo khối đường ống. Khi giai đoạn Đề xuất của khối N kết thúc, Đề xuất cho khối N+1 sẽ bắt đầu (tương tự như những gì Aptos và các chuỗi công khai khác làm). Tuy nhiên, đối với khối N+1, nó cần đợi khối N hoàn tất trước khi có thể gửi giao dịch Khối cuối cùng của L1 và được xác thực để trở thành Khối cuối cùng.

Các vectơ tấn công tiềm ẩn: Nếu Bộ sắp xếp thứ tự 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 tổ chức lại khối (reorg).

Tính số lượng khối L2 cho reorg: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 khối

Giải pháp: Áp dụng cơ chế khối chú để tránh chỉ có một khối ứng cử 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 việc phân cấp trong Fernet: Người sắp xếp chuỗi tham gia Ủy ban sắp xếp chuỗi bằng cách đặt cọc 16 ETH và ngưỡng đầu vào không cao (nhưng cũng không thấp). Nhà cung cấp không cần bất kỳ khoản đặt cọc nào, nhưng nếu Nhà cung cấp không tạo ra Bằng chứng thì sẽ không bị phạt. Điều này về cơ bản trái ngược với sơ đồ B52.

Tính sống động: Tính sống động của mạng tổng thể có thể được đảm bảo 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: Việc xem xét MEV là đặc biệt độc đáo. Kế hoạch này có kế hoạch giới thiệu PBS, do đó, sau khi Bộ sắp xếp thứ tự tính toán Điểm VDF đạt điểm cao, nó có thể trực tiếp tiếp cận Trình tạo khối để xây dựng một 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 phù hợp với Ethereum, vì vậy về cơ bản, vấn đề chống kiểm duyệt của Fernet tương đương với vấn đề chống kiểm duyệt PBS của Ethereum.

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [Geek Web3], Forward the Original Title'ollup Decentralization: Phân tích Giải pháp tuần tự phi tập trung của Aztec',Tất cả bản quyền thuộc về tác giả gốc [xhhh，EthStorage]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến 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. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.