*Chuyển tiếp tiêu đề gốc: Khám phá hệ thống chứng minh và cầu nối Ethereum Canonical của Eclipse

Tổng quan về cây cầu Canonical của chúng tôi

Eclipse bao gồm ba lớp:

1. Thực thi: Một nhánh của ứng dụng khách Solana Labs (v1.17) để thực hiện giao dịch SVM
2. Giải quyết: Cầu nối kinh điển của chúng tôi xác định quy tắc lựa chọn phân nhánh của Eclipse tồn tại trên Ethereum, nơi các bằng chứng gian lận cũng sẽ được gửi
3. Tính sẵn có của Dữ liệu: Eclipse xuất bản dữ liệu cần thiết để tạo ra bằng chứng gian lận dưới dạng các đốm màu dữ liệu trên Celestia

Sơ đồ bên dưới minh họa cách các mô-đun này tương tác:

Phần còn lại của bài viết này sẽ tập trung vào cầu Ethereum của Eclipse, như thể hiện trong sơ đồ. Blobstream sẽ chuyển tiếp các chứng thực được ký bởi bộ xác thực của Celestia để chứng nhận với Ethereum rằng dữ liệu cho một loạt vị trí của Eclipse đã được xuất bản chính xác. Điều này cho phép cầu nối của Eclipse xác minh dữ liệu được cung cấp để chống gian lận đối với các gốc dữ liệu đã được ký từ Celestia. Trong phần còn lại của phần này, chúng tôi sẽ phác thảo các quy trình trong đó:

1. tiền được gửi qua cầu của chúng tôi,
2. các khối dữ liệu của các khối của Eclipse được đăng trên Celestia,
3. việc rút tiền qua cầu được xử lý và
4. bằng chứng gian lận được tạo ra trong trường hợp xấu nhất.

Gửi tiền qua Cầu Ethereum gốc của Eclipse

Quy trình khi người dùng gửi tiền vào Eclipse thông qua cầu nối Ethereum gốc được tóm tắt như sau:

1. Một người dùng gọi hợp đồng Deposit Bridge của Eclipse trên Ethereum
2. Từ bên trong trình thực thi SVM của Eclipse [1], trình chuyển tiếp [2] quan sát địa chỉ đích và tiền gửi của người dùng
3. Tiếp theo, người chuyển tiếp gọi chương trình cầu nối SVM, chương trình này chịu trách nhiệm chuyển tiền gửi của người dùng đến địa chỉ đích áp dụng
4. Người chuyển tiếp xác minh giao dịch gửi tiền thông qua ứng dụng khách zk-light (sẽ được triển khai)
5. Cuối cùng, khối chứa giao dịch chuyển tiền sau khi gửi tiền tiếp theo được hoàn tất và xuất bản thông qua Plugin Solana Geyser

Sơ đồ bên dưới hiển thị các tương tác giữa Ethereum, Celestia và SVM Executor trong luồng tiền gửi được mô tả ở trên:

Xuất bản các khe cắm của Eclipse lên Celestia dưới dạng các đốm dữ liệu

Quy trình xuất bản các lô vị trí của Eclipse lên Celestia dưới dạng các đốm màu dữ liệu được tóm tắt bên dưới:

1. Trình thực thi SVM xuất bản từng vị trí Eclipse vào hàng đợi tin nhắn thông qua Geyser
2. Trình thực thi SVM đăng các lô vị trí của Eclipse lên Celestia dưới dạng các đốm màu dữ liệu
3. Bộ trình xác thực Celestia tạo ra các cam kết đối với các đốm màu dữ liệu được gửi, có thể được sử dụng để chứng minh sự bao gồm một giao dịch trên chuỗi của Eclipse đối với gốc dữ liệu
4. Các gốc dữ liệu chứa trong mỗi tiêu đề khối Celestia được chuyển tiếp tới hợp đồng cầu nối của Eclipse trên Ethereum thông qua Blobstream

Sơ đồ bên dưới của Celestia giải thích cách cam kết dữ liệu trong một khối Celestia nhất định được lưu trữ trong tiêu đề khối:

Rút và gửi bằng chứng gian lận tới cầu Ethereum của Eclipse

Tương tự như các L2 khác sử dụng bằng chứng gian lận (Arbitrum, Fuel và nhiều loại khác), việc rút tiền từ Eclipse yêu cầu một khoảng thời gian thử thách trong đó người xác minh có thể gửi bằng chứng gian lận trong trường hợp chuyển đổi trạng thái không hợp lệ:

1. Theo một nhịp độ đều đặn, người thực thi SVM đăng một cam kết về một kỷ nguyên (một số lô được xác định trước) các vị trí của Eclipse cho Ethereum, cùng với tài sản thế chấp
2. Hợp đồng cầu nối của Eclipse tiến hành một số kiểm tra cơ bản để đảm bảo rằng dữ liệu được đăng được định dạng đúng (được mô tả trong phần Thiết kế chống gian lận)
3. Nếu lô được gửi vượt qua các bước kiểm tra cơ bản này thì sẽ có một khoảng thời gian được xác định trước trong đó người xác minh có thể đăng bằng chứng gian lận trong trường hợp cam kết lô ngụ ý chuyển đổi trạng thái không hợp lệ
4. Nếu người xác minh đăng bằng chứng gian lận thành công, họ sẽ giành được tài sản thế chấp của người thực thi, lô đã đăng sẽ bị từ chối và trạng thái chuẩn của Eclipse L2 được khôi phục về cam kết lô hợp lệ cuối cùng. Ở đây, ban quản trị của Eclipse sẽ có khả năng bầu ra một người thực thi mới
5. Nếu thời gian thử thách trôi qua mà không có bằng chứng gian lận thành công, người thi hành sẽ thu hồi tài sản thế chấp cùng với phần thưởng
6. Do đó, hợp đồng cầu nối Eclipse hiện sẽ hoàn thành mọi giao dịch rút tiền đã được đưa vào đợt cuối cùng

Thiết kế chống gian lận

Trong phần cuối cùng này, chúng tôi sẽ trình bày chi tiết về thiết kế hệ thống chống gian lận của Eclipse, lấy cảm hứng từ Anatoly Ykovenko và John Adler. Nói chung, đối với bất kỳ bằng chứng gian lận nào, người xác minh phải:

1. Xác định giao dịch có chuyển đổi trạng thái không hợp lệ
2. Cung cấp đầu vào cho giao dịch nói trên với quá trình chuyển đổi trạng thái không hợp lệ
3. Chứng minh rằng việc thực hiện lại giao dịch đã nói với đầu vào đã cho sẽ dẫn đến đầu ra không bằng với những gì đã cam kết trên chuỗi

Trong trường hợp của Eclipse, (1) Celestia kết hợp các khối khối mà người thực thi SVM của Eclipse đăng, cho phép bằng chứng bao gồm giao dịch thông qua nhân chứng Merkle. Đối với (2), không giống như các L2 dựa trên EVM, đăng gốc Merkle lên cây trạng thái toàn cầu, vì lý do hiệu suất, Eclipse không cập nhật cây trạng thái toàn cầu trên cơ sở từng giao dịch, nhưng chúng tôi sẽ giải thích cách chúng tôi đảm bảo tính chính xác của đầu vào chi tiết hơn dưới đây. Cuối cùng, trong trường hợp (3), trình xác minh của Eclipse tạo ra bằng chứng zk về (các) đầu ra cho một giao dịch nhất định, không giống như cách tiếp cận trò chơi xác minh tương tác phổ biến trên các L2 dựa trên EVM.

Tất cả các giao dịch Eclipse có thể được biểu diễn dưới dạng lấy danh sách các tài khoản đầu vào, thực hiện giao dịch và tạo danh sách các tài khoản đầu ra tổng hợp:

Quan sát quan trọng đối với thiết kế chống gian lận của chúng tôi là để thực hiện giao dịch, mọi S_InputAccount luôn phải là S_OutputAccount của một số giao dịch trước đó. Điều này cho phép chúng tôi tham chiếu giao dịch cuối cùng trong chuỗi tạo ra một tài khoản đầu vào nhất định thay vì cung cấp nhân chứng Merkle cho cây trạng thái toàn cầu. Do thiết kế của chúng tôi, chúng tôi đưa ra các loại cáo buộc gian lận bổ sung, chẳng hạn như tham chiếu đến giao dịch trước đó không hợp lệ hoặc tài khoản đầu vào đã được "chi tiêu" bởi một số giao dịch sau đó. Chúng tôi mô tả quá trình này chi tiết hơn dưới đây:

Đầu vào giao dịch được đăng lên Celestia

1. Dữ liệu giao dịch (được đăng bởi trình sắp xếp thứ tự)
2. Dữ liệu giao dịch (được đăng bởi người thực thi SVM) bao gồm các thông tin sau:
   1. Số lượng giao dịch [3]
   2. Vị trí không gian tên Celestia của dữ liệu giao dịch
   3. Hàm băm tài khoản [4] cho mỗi đầu vào, với số lượng giao dịch dẫn đến mỗi đầu vào
   4. Danh sách các sysvar được sử dụng và giá trị của mỗi sysvar, cùng với số lượng giao dịch dẫn đến mỗi sysvar (nếu có) [5]
   5. Đầu ra giao dịch, nếu giao dịch thành công; mặt khác, một chỉ báo cho thấy giao dịch không thành công (vì không thể phân tích cú pháp hoặc vì không thể thực thi)

Cam kết hàng loạt được đăng lên cầu Ethereum

Ngoài ra, các lô dữ liệu giao dịch được đăng lên Celestia có các cam kết được chuyển tiếp sang hợp đồng Ethereum. Các cam kết bao gồm:

1. Vị trí không gian tên Celestia của dữ liệu giao dịch của giao dịch cuối cùng được bao gồm trong lô
2. Vị trí không gian tên Celestia của dữ liệu thực thi [6] của tất cả các giao dịch được bao gồm
3. Danh sách gửi tiền, rút tiền và ghi đè, mỗi danh sách đều đi kèm với số lượng giao dịch của giao dịch Eclipse liên quan

Tiêu chí cho một lô không hợp lệ

Như đã giải thích ở trên, có một số cách có thể phát hiện ra một lô là không chính xác:

1. Một trong các vị trí không gian tên Celestia được liên kết không đúng định dạng hoặc không trỏ đến dữ liệu thuộc loại được yêu cầu
2. Có một giao dịch trên Celestia không có dữ liệu thực thi liên quan, có thể do hai lý do:
   1. Giao dịch được cho là giao dịch gần đây nhất trong lô không có dữ liệu thực thi liên quan.
      1. Trong trường hợp như vậy, người xác minh sẽ xác minh rằng đây là trường hợp và hợp đồng cầu nối Ethereum sẽ kiểm tra xem mục nhập mới nhất trong danh sách dữ liệu thực thi không tương ứng với dữ liệu giao dịch chính xác
   2. Thiếu dữ liệu thực hiện của một giao dịch khác
      1. Người xác minh đăng vị trí không gian tên Celestia của dữ liệu giao dịch của giao dịch vi phạm cũng như các giao dịch trước và sau theo thứ tự được thực hiện thành công. Sau đó, hợp đồng bridge sẽ kiểm tra xem giao dịch này có bị bỏ qua không
3. Có một giao dịch có dữ liệu thực hiện không chính xác, có thể do nguyên nhân sau:
   1. Số lượng giao dịch được liên kết với hàm băm tài khoản hoặc sysvar không tạo ra kết quả được xác nhận quyền sở hữu.
      1. Trong trường hợp này, người xác minh đăng vị trí không gian tên Celestia của dữ liệu thực thi cho giao dịch đã cho với số lượng tương ứng và hợp đồng cầu nối sẽ kiểm tra xem giá trị đã cho là không chính xác.
   2. Số lượng giao dịch được liên kết với hàm băm tài khoản hoặc sysvar đã lỗi thời
      1. Người xác minh đăng vị trí không gian tên Celestia của dữ liệu thực thi cho một giao dịch mới hơn, sửa đổi giá trị được đề cập và hợp đồng cầu nối sẽ kiểm tra xem giao dịch này có thực sự mới hơn không.
   3. Đầu ra giao dịch không chính xác hoặc giao dịch sử dụng đầu vào không được liệt kê:
      1. Trong trường hợp này, cần có bằng chứng zk về việc thực hiện đúng giao dịch hoặc bằng chứng zk rằng giao dịch sử dụng đầu vào không được liệt kê. Điều này có thể đạt được bằng hai cách:
         1. Người xác minh đăng bằng chứng, hoặc
         2. Một người xác minh đăng chỉ mục của giao dịch được cho là gian lận và hợp đồng cầu nối Eclipse sử dụng điều này để thu thập bằng chứng zk từ Bonsai của RISC Zero
   4. Đã có khoản tiền gửi từ Ethereum hơn N đợt trước, nhưng không có khoản tiền gửi tương ứng trong danh sách giao dịch (có trong cam kết lô được đăng trong hợp đồng bắc cầu) cho N đợt trước. Ngoài ra, có một khoản tiền gửi trong danh sách giao dịch không có giao dịch tiền gửi Ethereum liên quan hoặc giao dịch tồn tại nhưng đã được đưa vào một đợt Eclipse khác
      1. Hợp đồng bắc cầu trong tất cả các trường hợp này có thể xác định rằng điều này đã xảy ra và coi lô hàng đó là không hợp lệ.
   5. Có một khoản tiền gửi hoặc rút tiền được thực hiện mà không có mục tương ứng trong danh sách giao dịch
      1. Trong trường hợp như vậy, người xác minh đăng vị trí không gian tên Celestia của dữ liệu thực thi đã cho và hợp đồng cầu nối sẽ kiểm tra thực tế này để đánh giá giao dịch là không hợp lệ
   6. Có một khoản tiền gửi hoặc rút tiền trong danh sách giao dịch mà giao dịch Eclipse được liên kết của nó không thực hiện hành động dự kiến hoặc số lượng giao dịch không nằm trong phạm vi số lượng giao dịch dự kiến. Trong trường hợp như vậy, một trong những điều sau đây sẽ xảy ra:
      1. Cây cầu sẽ tự động xác định trường hợp này và từ chối lô tương ứng
      2. Người xác minh nhận thấy việc chuyển đổi trạng thái không hợp lệ và đăng bằng chứng về giao dịch vi phạm, sau đó được xác minh bằng hợp đồng bắc cầu

Nếu bất kỳ lô cam kết nào được phát hiện là không chính xác, hợp đồng cầu nối Eclipse sẽ khôi phục cầu nối về cam kết lô cuối cùng được chứng minh là đúng. Lưu ý rằng các giao dịch không bao giờ bị xóa khỏi chuỗi, ngay cả trong trường hợp gian lận, do đó chỉ cần tính lại cam kết.

Ý Tưởng Chia Tay

Bài viết này nhằm mục đích cung cấp hướng dẫn cấp cao về cầu nối giảm thiểu độ tin cậy của Eclipse trên Ethereum và giải thích một số chi tiết về thiết kế chống gian lận của chúng tôi. Do tính chất mô-đun của L2 và sự non trẻ của hệ thống công nghệ của chúng tôi, chúng tôi sẽ tiếp tục phát hành các bài viết và tài liệu về các khía cạnh khác nhau của Eclipse trong những tuần tới.

Để tham gia vào Eclipse Testnet, vui lòng làm theo hướng dẫn của chúng tôi tại đây. Bạn có thể liên hệ với chúng tôi trên Twitter hoặc Discord nếu có thắc mắc cụ thể về Testnet, cầu nối hoặc các câu hỏi kỹ thuật của chúng tôi.

Chú thích cuối trang

[1]: Nút tính toán kết quả của các giao dịch SVM và áp dụng đầu ra cuối cùng cho trạng thái mới của Eclipse

[2]: Một nhà điều hành chuyển các sự kiện trên chuỗi giữa Ethereum và Eclipse

[3]: Lưu ý rằng người thực thi, không phải người sắp xếp chuỗi, đăng nội dung này. Nếu nó được đưa vào dữ liệu được đăng bởi trình sắp xếp chuỗi, điều đó sẽ gây thêm sự phức tạp là trình sắp xếp chuỗi có thể bỏ qua một số đếm, khiến người thực thi không thể thực hiện công việc của họ một cách chính xác. Điều này có thể được bù đắp trong thiết kế chống gian lận, nhưng nó sẽ làm tăng thêm độ phức tạp. Ưu điểm thứ hai của việc chỉ có người thực thi đăng số đếm là nó giúp dễ dàng cho phép đăng ghi đè giao dịch lên Celestia, nếu muốn.

[4]: Tài khoản SVM có thể được biểu diễn bằng một hàm băm duy nhất. Cách duy nhất để sửa đổi hàm băm này là thông qua một giao dịch.

[5]: Để thực hiện việc này mà không cần băm quá nhiều, chúng tôi sẽ chạy theo dõi trên từng chương trình đã thực thi để xem phần nào của mỗi sysvar đã sử dụng thực sự được truy cập. Điều này có thể thực hiện được nhưng sẽ yêu cầu sửa đổi trình thông dịch BPF của Solana.

[6]: Điều này bao gồm dữ liệu về các giao dịch đã thử nhưng không thực hiện được.

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

1. Bài viết này được in lại từ [[mirror], Mọi bản quyền thuộc về tác giả gốc [Eclipse]. 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.