SPIRAL: Lớp tin cậy dựa trên BFT cho khả năng tương tác L2

Bài viết này được dịch máy
Xem bản gốc

Tóm tắt

SPIRAL đề xuất một lớp tin cậy sử dụng Consensus Byzantine Fault Tolerance (BFT) (BFT hoặc một cái gì đó tương tự) để cho phép khả năng kết hợp đồng bộ giữa các bản tổng hợp Ethereum Layer 1 (L1) và Layer 2 (L2). Bằng cách ưu tiên triển khai nhanh chóng và chuyển tiếp trạng thái có độ trễ thấp, SPIRAL cung cấp một giải pháp thay thế thực tế cho các giải pháp mật mã như Fabric/Signal-Boost. Bài đăng này phác thảo thiết kế của SPIRAL, đánh giá các đánh đổi của nó so với các phương pháp Không cần tin cậy và đặt ra các câu hỏi nghiên cứu mở để tích hợp các lớp tin cậy dựa trên BFT với hệ sinh thái tổng hợp của Ethereum, đặc biệt là các bản tổng hợp dựa trên.

1. Giới thiệu

Các rollup Layer 2 đóng vai trò trung tâm trong lộ trình mở rộng quy mô của Ethereum, nhưng khả năng tương tác giữa các chuỗi vẫn là một thách thức. Khả năng kết hợp không đồng bộ giữa L1 ​​và L2 gây ra độ trễ, làm giảm trải nghiệm người dùng (UX) và hạn chế các ứng dụng DeFi . SPIRAL giải quyết vấn đề này bằng cách triển khai mạng xác thực dựa trên BFT để chuyển tiếp các thay đổi trạng thái L2 trong vài giây, tận dụng các giao thức Consensus hiện có để áp dụng ngay lập tức. Trong khi đưa ra các giả định về độ tin cậy, SPIRAL phù hợp với thực tế hoạt động của nhiều L2 (ví dụ: trình sắp xếp tập trung) và bổ sung cho các thiết kế rollup dựa trên.

Bài đăng này trình bày chi tiết về kiến ​​trúc của SPIRAL, so sánh với Signal-Boost và thảo luận về ý nghĩa của nó đối với lộ trình mở rộng quy mô của Ethereum. Chúng tôi mong nhận được phản hồi về quản trị trình xác thực, xử lý tổ chức lại và tích hợp lâu dài với các hệ thống Không cần tin cậy .

2. Thiết kế SPIRAL

2.1 Cơ chế cốt lõi

SPIRAL hoạt động như một lớp tin cậy giữa L1 ​​và L2:

  • Mạng xác thực : Một tập hợp các trình xác thực được cấp phép chạy giao thức Consensus BFT (ví dụ: Tendermint hoặc HotStuff) để thống nhất về các cập nhật trạng thái L2.
  • Chuyển tiếp trạng thái : Trình xác thực chuyển tiếp các thay đổi trạng thái L2 (ví dụ: kết quả giao dịch) tới các L2 hoặc L1 khác theo thời gian thực, đạt được Tính chất cuối cùng trong vòng 2-5 giây.
  • Mô hình tích hợp : L2 tích hợp thông qua API nhẹ, đăng ký dịch vụ của SPIRAL mà không cần sửa đổi kiến ​​trúc cốt lõi của chúng.
  • Staking : Người xác thực đặt cược Stake sản để đảm bảo an ninh kinh tế, đồng thời Slashing hành vi độc hại.

2.2 Các tính năng chính

  • Triển khai ngay lập tức : Sử dụng các giao thức BFT trưởng thành, bỏ qua nhu cầu nâng cấp L1 hoặc các nguyên hàm mật mã mới.
  • Độ tin cậy có thể cấu hình : L2 có thể sử dụng SPIRAL một cách có chọn lọc cho các giao dịch có giá trị thấp, dành các đường dẫn Không cần tin cậy cho các giao dịch có giá trị cao.
  • Độc lập L1 : Hoạt động mà không cần sửa đổi Consensus của Ethereum, khiến nó tương thích với các bản cập nhật hiện có.

3. So sánh với Fabric/Signal-Boost

SPIRAL trái ngược với Fabric/Signal-Boost, một phương pháp tiếp cận mật mã sử dụng hợp đồng SignalBoost và thứ tự giao dịch (ToB) của Ethereum. Những điểm khác biệt chính bao gồm:

Tính năng XOẮN ỐC Tăng cường tín hiệu
Mô hình tin cậy Trình xác thực BFT Trình xác thực đáng tin cậy Bằng chứng mật mã thông qua hợp đồng SignalBoost
Độ trễ 2-5 giây ( Tính chất cuối cùng BFT) ~10-20 giây (phụ thuộc L1 ToB)
Độ phức tạp Thấp (BFT chuẩn) Cao (bằng chứng Merkle, thực hiện ToB)
Khả năng mở rộng ~100-200 người xác thực Giới hạn bởi Xuất lượng L1
Xử lý tổ chức lại Yêu cầu cơ chế dự phòng Liên quan đến Tính chất cuối cùng L1

Tính đơn giản của SPIRAL cho phép triển khai nhanh hơn, nhưng thiết kế Không cần tin cậy của Signal-Boost lại phù hợp với tầm nhìn dài hạn của Ethereum.

4. Tích hợp với Based Rollup

SPIRAL có thể bổ sung các bản tổng hợp dựa trên, sử dụng các trình đề xuất L1 cho trình tự L2:

  • Đường dẫn nhanh : SPIRAL có thể chuyển tiếp các giao dịch có giá trị thấp, giảm sự phụ thuộc vào L1.
  • Vai trò chuyển tiếp : Hỗ trợ quá trình chuyển đổi sang kiến ​​trúc cơ bản.
  • Dịch vụ chuyên biệt : Cung cấp dịch vụ chuyển tiếp trạng thái theo thời gian thực cho các trường hợp sử dụng cụ thể (ví dụ: khả năng kết hợp DeFi ).

Không giống như Signal-Boost tích hợp chặt chẽ với Consensus L1, tính linh hoạt của SPIRAL phù hợp với các hệ sinh thái L2 không đồng nhất.

5. Sự đánh đổi và câu hỏi nghiên cứu

5.1 Giả định về sự tin cậy

  • Validator Capture : Một bộ xác thực nhỏ có nguy cơ thông đồng hoặc bị bắt giữ bên ngoài (ví dụ, bởi các quốc gia). Các giao thức lựa chọn và luân chuyển xác thực có thể giảm thiểu điều này như thế nào? Các xác thực nên Không cần cho phép hay được quản lý?
  • Niềm tin so với sự không tin tưởng : Sự phụ thuộc của SPIRAL vào trình xác thực khác với bản chất của Ethereum. Các mô hình lai (ví dụ: BFT với xác minh mật mã cuối cùng) có thể hòa giải điều này không?

5.2 Thách thức kỹ thuật

  • Tổ chức lại L1 : Chuyển tiếp thời gian thực của SPIRAL có thể xung đột với tổ chức lại L1, gây ra nguy cơ trạng thái không nhất quán. Cơ chế kiểm tra điểm hoặc khôi phục nào có thể đảm bảo tính mạnh mẽ?
  • Khả năng mở rộng : Hệ thống BFT mở rộng kém hơn ~200 trình xác thực. Phân mảnh hoặc Consensus phân cấp có thể mở rộng khả năng của SPIRAL lên hàng nghìn nút không?
  • Bề mặt tấn công : Các thành phần bổ sung làm tăng lỗ hổng. Các vectơ tấn công của SPIRAL có thể được mô hình hóa và giảm thiểu chính thức như thế nào?

5.3 Cân nhắc về kinh tế

  • Cấu trúc phí : L2 trả phí đăng ký, có khả năng tập trung khai thác giá trị. Mức phí giới hạn hoặc việc tích hợp trình xác thực mở có thể đảm bảo tính công bằng không?
  • MEV Dynamics : Không giống như sự phụ thuộc vào MEV của Signal-Boost, phí của SPIRAL có thể dự đoán được nhưng có thể gây gánh nặng cho các L2 nhỏ hơn. Các mô hình này tác động đến lợi nhuận của L2 như thế nào?

6. Hướng nghiên cứu mở

Chúng tôi đề xuất những nội dung sau để cộng đồng thảo luận:

  1. Quản trị trình xác thực : Thiết kế các giao thức lựa chọn trình xác thực minh bạch, chống Sybil để ngăn chặn việc chiếm đoạt.
  2. Xử lý tổ chức lại : Mô hình hóa hành vi của SPIRAL trong quá trình tổ chức lại L1 và thử nghiệm các cơ chế dự phòng (ví dụ: điểm kiểm tra trạng thái).
  3. Hệ thống lai : Khám phá quá trình tích hợp theo từng giai đoạn của BFT và xác minh mật mã để cân bằng giữa tốc độ và tính không cần tin cậy.
  4. Khả năng mở rộng : Nghiên cứu BFT phân mảnh hoặc Consensus giữa các lớp để hỗ trợ các bộ xác thực lớn hơn.
  5. Phân tích kinh tế : Định lượng tác động của phí SPIRAL lên hệ sinh thái L2 so với các mô hình dựa trên MEV.

7. Kết luận

SPIRAL cung cấp giải pháp thực dụng, có thể triển khai cho khả năng tương tác L2, tận dụng Consensus BFT để đạt được khả năng hợp nhất độ trễ thấp. Mặc dù các giả định về độ tin cậy và thách thức kỹ thuật của nó đảm bảo sự giám sát chặt chẽ, khả năng tương thích của nó với các bản tổng hợp hiện có và kiến ​​trúc dựa trên khiến nó trở thành cầu nối có giá trị cho tương lai mở rộng quy mô của Ethereum. Chúng tôi tin rằng thiết kế của SPIRAL có thể thúc đẩy nghiên cứu hiệu quả về các mô hình tin cậy lai, quản trị xác thực và xử lý tổ chức lại mạnh mẽ, thúc đẩy khả năng mở rộng quy mô và UX của hệ sinh thái Ethereum.

Chúng tôi hoan nghênh phản hồi về thiết kế của SPIRAL và vai trò của nó trong lộ trình của Ethereum. Làm thế nào chúng ta có thể cân bằng giữa chủ nghĩa thực dụng và sự thiếu tin cậy? Những thí nghiệm hoặc mô phỏng nào có thể xác thực các giả định của SPIRAL? Chúng ta hãy thảo luận bên dưới.


Khu vực:
Nguồn
Tuyên bố từ chối trách nhiệm: Nội dung trên chỉ là ý kiến của tác giả, không đại diện cho bất kỳ lập trường nào của Followin, không nhằm mục đích và sẽ không được hiểu hay hiểu là lời khuyên đầu tư từ Followin.
Thích
1
Thêm vào Yêu thích
1
Bình luận