Khả năng kết hợp đồng bộ giữa các Rollup thông qua xác thực thời gian thực

1. Tổng hợp dựa trên dữ liệu và xác minh thời gian thực

Rollup dựa trên cơ sở là một rollup mà bất kỳ ai cũng có thể đề xuất một Block mới, không có người điều phối đặc quyền. Bất kỳ người tham gia nào cũng có thể lấy trạng thái hiện tại của rollup, áp dụng một tập hợp các giao dịch và tạo ra một Block mới.

Một lợi thế thiết kế quan trọng xuất hiện khi chúng ta yêu cầu dữ liệu về tính khả dụng và bằng chứng xác thực phải được gửi cùng nhau, như một đơn vị nguyên tử duy nhất. Trong các thiết kế tổng hợp truyền thống, dữ liệu được đăng tải trước và bằng chứng được gửi sau, điều này tạo ra một khoảng trống làm phức tạp thiết kế cơ chế khuyến khích: ai sẽ tạo ra bằng chứng? Khi nào? Làm thế nào để đảm bảo họ được đền bù một cách công bằng và kịp thời?

Bằng cách đăng tải dữ liệu và bằng chứng đồng thời, chúng ta hoàn toàn thu hẹp khoảng cách này. Người đề xuất Block chịu trách nhiệm cả việc thực thi và chứng minh. Nếu bằng chứng không hợp lệ hoặc bị thiếu, Block đơn giản là không tồn tại. Điều này đơn giản hóa đáng kể cơ chế khuyến khích, người đề xuất Block là người chứng minh, và phần thưởng của họ đến từ cùng một nguồn (ví dụ: phí giao dịch) mà không cần đến các thị trường chứng minh riêng biệt hoặc các giai đoạn thách thức.

Điều này được thực hiện nhờ vào việc chứng minh theo thời gian thực , khả năng tạo ra các bằng chứng về tính hợp lệ đủ nhanh để chúng có thể được tạo ra song song với việc xây dựng Block , thay vì là một quá trình bổ sung không đồng bộ.

Việc chứng minh thời gian thực đang nhanh chóng trở nên khả thi. Tính đến thời điểm hiện tại, việc chứng minh một Block Ethereum hoàn chỉnh yêu cầu khoảng 12 GPU với thời gian chứng minh trung bình khoảng 7 giây. Vẫn còn nhiều dư địa để cải thiện và giảm độ trễ, cả thông qua cải tiến phần cứng và tối ưu hóa hệ thống chứng minh, mặc dù khó có thể dự đoán chính xác giới hạn sẽ ở đâu. Sự tập trung hóa người chứng minh là một mối lo ngại chính đáng: yêu cầu phần cứng không hề đơn giản, và không phải mọi người xây dựng Block đều có quyền truy cập vào cùng một cơ sở hạ tầng chứng minh. Tuy nhiên, việc chứng minh vốn dĩ có thể song song hóa và trở nên phổ biến, và xu hướng rõ ràng là hướng tới việc chứng minh nhanh hơn trên phần cứng rẻ hơn.

2. Khả năng kết hợp đồng bộ là gì?

Khả năng kết hợp đồng bộ có nghĩa là trong một giao dịch duy nhất, một hợp đồng thông minh trên một chuỗi (L1 hoặc một rollup) có thể GỌI một hợp đồng thông minh trên một chuỗi khác (L1 hoặc một rollup khác) và nhận lại kết quả trong cùng một ngữ cảnh thực thi, giống như thể cả hai hợp đồng cùng tồn tại trên một chuỗi.

Hiện nay, tương tác giữa các chuỗi diễn ra không đồng bộ: bạn gửi một tin nhắn trên chuỗi A, chờ nó được chuyển tiếp đến chuỗi B, và sau đó xử lý kết quả một cách riêng biệt. Điều này phá vỡ mô hình khả năng kết hợp vốn làm cho hệ sinh thái DeFi của Ethereum trở nên mạnh mẽ. Các giao thức không thể kết hợp một cách nguyên tử qua các ranh giới rollup.

Khả năng kết hợp đồng bộ khôi phục điều này. Từ góc nhìn của nhà phát triển, việc gọi một hợp đồng trên một rollup khác trông và hoạt động chính xác như việc gọi một hợp đồng trên cùng một chuỗi. Giao dịch hoặc thành công một cách nguyên tử trên tất cả các chuỗi liên quan, hoặc bị hoàn tác hoàn toàn.

3. Trường hợp đơn giản: Khả năng kết hợp giữa L2 và L2

Trước khi giải quyết vấn đề khó hơn về tương tác L1↔L2, cần lưu ý rằng khả năng kết hợp giữa các rollup L2 riêng lẻ tương đối đơn giản.

Nếu chúng ta chỉ xử lý các trạng thái L2, chúng ta có thể gộp thông tin về tính khả dụng dữ liệu cho tất cả các trạng thái tổng hợp bị ảnh hưởng vào một khối dữ liệu duy nhất. Trình xây dựng Block sẽ tạo ra một quá trình thực thi kết hợp, tác động đến nhiều trạng thái tổng hợp, chứng minh tất cả chúng cùng nhau và đăng kết quả dưới dạng một lần gửi thông tin về tính khả dụng dữ liệu nguyên tử. Vì tất cả các chuyển đổi trạng thái bị ảnh hưởng đều được chứng minh và đăng cùng nhau, nên khả năng kết hợp sẽ diễn ra một cách tự nhiên, các chuyển đổi hoặc đều xảy ra hoặc không có chuyển đổi nào xảy ra.

Quan sát này là nền tảng. Vấn đề khó hơn là làm sao để nó hoạt động hiệu quả khi các hợp đồng thông minh L1 tham gia vào quá trình tương tác.

4. Hợp đồng thông minh ủy quyền

Cơ chế cốt lõi cho phép thực hiện các cuộc gọi xuyên chuỗi là hợp đồng thông minh proxy . Proxy là một hợp đồng thông minh được triển khai trên một chuỗi , đại diện cho một hợp đồng thông minh nằm trên một chuỗi khác.

Khi một hợp đồng trên L1 muốn gọi một hợp đồng trên rollup R, nó không trực tiếp thực thi mã trên R. Thay vào đó, nó gọi đến hợp đồng proxy của hợp đồng R đó, vốn tồn tại trên L1. Hợp đồng proxy bao hàm cuộc gọi xuyên chuỗi: nó biết hợp đồng mục tiêu là gì, xử lý cuộc gọi, áp dụng các thay đổi trạng thái tương ứng trên rollup và trả về kết quả, tất cả trong cùng một lần thực thi giao dịch.

Từ góc nhìn của người gọi, việc tương tác với máy chủ proxy không khác gì việc tương tác với hợp đồng thực sự. Máy chủ proxy là giao diện cục bộ cho một hợp đồng từ xa.

5. Mô hình tương tác L1 ↔ L2

Khi một giao dịch liên quan đến cả hợp đồng thông minh L1 và L2, quá trình thực thi sẽ tuân theo một quy trình có cấu trúc:

Bước 1: Đảm bảo có hợp đồng ủy quyền

Trước khi thực thi, tất cả các hợp đồng thông minh proxy cho các hợp đồng L2 sẽ tương tác với L1 phải được triển khai. Nếu một hợp đồng trên rollup R được gọi từ L1, thì proxy của nó phải đã tồn tại trên L1.

Bước 2: Xây dựng và gửi bảng thực thi

Một bảng thực thi được xây dựng và lưu trữ tạm thời trong trạng thái L1. Bảng này là một chuỗi các mục, trong đó mỗi mục mô tả một hành động và hậu quả của nó. Mỗi mục chứa:

• Hành động : Chủ yếu là một CALL hoặc một RESULT .
• Một tập hợp các chuyển đổi trạng thái L2 : Các rollup nào bị ảnh hưởng và các gốc trạng thái của chúng chuyển đổi từ/đến đâu.
• nextAction : Hành động tiếp theo là gì, có thể là KẾT QUẢ (với dữ liệu trả về) hoặc một LỆNH GỌI khác (đến một hợp đồng thông minh L1 khác).

Bảng này ghi lại toàn bộ quá trình tương tác giữa các chuỗi. Ví dụ, hãy xem xét kịch bản gọi hàm lồng nhau:

 A ( on L1) calls B ( on Rollup 2 )→ B ( on Rollup 2 ) calls C ( on L1 )→ C ( on L1 ) returns→ B ( on Rollup 2 ) returns A ( on L1 ) continues execution

Trong trường hợp này, bảng thực thi sẽ chứa hai mục:

 | # | Action | L2 State Transitions | nextAction | | ---|-----------------------|-------------------------------|---------------------| | 1 | CALL B ( on Rollup 2 ) - | Rup2: stateRoot₀ → stateRoot₁ | CALL C ( on L1) | | 2 | RETURN from C ( on L1) | Rup2: stateRoot₁ → stateRoot₂ | RETURN to A ( on L1) |

Mục đầu tiên ghi: “Khi A gọi B trên Rollup 2, quá trình chuyển đổi của Rollup diễn ra từ stateRoot₀ sang stateRoot₁, và điều tiếp theo cần làm là gọi C trên L1.” Mục thứ hai ghi: “Sau khi C trả về, Rollup 2 chuyển đổi từ stateRoot₁ sang stateRoot₂, và kết quả cuối cùng được trả về cho A.”

Bảng thực thi mã hóa toàn bộ chuỗi gọi/trả về này, cùng với tất cả các chuyển đổi trạng thái tổng hợp xảy ra ở mỗi bước. Điều quan trọng là, bảng này đi kèm với một bằng chứng xác thực duy nhất đảm bảo tính chính xác của mọi bước thực thi trong bảng. Bằng chứng này được xác minh một lần khi bảng được gửi đi.

Bước 3: Thực thi L1 với phân giải Proxy

Hiện tại, các giao dịch L1 được thực thi bình thường. Khi quá trình thực thi đạt đến điểm mà hợp đồng L1 gọi hợp đồng proxy, proxy sẽ thực hiện các bước sau:

1. Tra cứu hành động CALL tương ứng trong bảng thực thi.
2. Xác minh và áp dụng các thay đổi trạng thái gốc cho các bản cập nhật tổng hợp bị ảnh hưởng.
3. Nếu có các lệnh gọi L1 lồng nhau trong chuỗi, nó sẽ thực thi chúng.
4. Xóa các mục đã được sử dụng khỏi bảng thực thi (để tránh lãng phí bộ nhớ L1).
5. Trả về RESULT cho hợp đồng L1 gọi nó.

Từ góc nhìn của môi trường thực thi L1, lệnh gọi diễn ra bình thường và trả về kết quả. Độ phức tạp của tương tác giữa các chuỗi được trừu tượng hóa hoàn toàn bởi proxy và bảng thực thi.

Bước 4: Giao dịch do L2 khởi xướng

Một giao dịch bắt nguồn từ L2 tương tác với L1 tuân theo mô hình tương tự, nhưng hành động đầu tiên trong bảng thực thi là L2TX thay vì CALL . Giao dịch L2 khởi động quá trình thực thi, và bất kỳ lệnh gọi nào đến các hợp đồng L1 đều trở thành các mục lồng nhau trong bảng, được giải quyết theo cùng một cách.

Bước 5: Xử lý các lần hoàn tác

Hai thao tác đặc biệt: REVERT và REVERT_CONTINUE xử lý việc hoàn tác qua ranh giới chuỗi theo cách tương tự như cách hoạt động của việc hoàn tác trong một chuỗi duy nhất.

Khi xảy ra lỗi hoàn tác trong quá trình thực thi trên L2, một hành động REVERT được gửi đến L1. L1 sau đó xử lý lỗi hoàn tác bằng cách hủy bỏ bất kỳ lệnh gọi L1 lồng nhau nào là một phần của đường dẫn thực thi bị hoàn tác và cập nhật các gốc trạng thái tổng hợp bị ảnh hưởng tương ứng. Sau khi L1 hoàn tất việc hủy bỏ các lệnh gọi bị hoàn tác, một hành động REVERT_CONTINUE được gửi lại cho L2, cho phép quá trình thực thi tiếp tục. Kết quả cuối cùng là các lỗi hoàn tác hoạt động theo cùng một cách như hiện tại trong một chuỗi duy nhất.

6. Ghi chú bổ sung

Account Abstraction và sự phù hợp về động lực

Việc đảm bảo các hợp đồng ủy quyền được triển khai và các động lực giữa người dùng và người xây dựng Block được điều chỉnh phù hợp có thể được xử lý bằng cách sử dụng các tiêu chuẩn Ethereum hiện có — cụ thể là Đề xuất cải tiến Ethereum (EIP)-7702 (thiết lập mã tài khoản EOA) và Đề xuất cải tiến Ethereum (EIP)-4337 (Account Abstraction). Các tiêu chuẩn này cung cấp sự linh hoạt cần thiết để phối hợp giai đoạn thiết lập mà không cần thay đổi giao thức cốt lõi.

Tổng hợp dữ liệu không chỉ giới hạn ở Máy ảo Ethereum (EVM).

Các rollup tham gia vào hệ thống này không nhất thiết phải là EVM gốc. Bất kỳ rollup nào có thể chấp nhận và tạo ra các lệnh `CALL` đến các rollup khác đều có thể tham gia. Mỗi rollup định nghĩa hàm chuyển đổi trạng thái riêng của nó thông qua khóa zkVerification . Một rollup thậm chí có thể có một chủ sở hữu với toàn quyền kiểm soát gốc trạng thái của nó.

Hạn chế duy nhất mà hệ thống chính đặt ra là trách nhiệm giải trình về Ether : hệ thống phải theo dõi lượng Ether mà mỗi rollup nắm giữ và không được phép cho phép một rollup thực hiện lệnh `CALL` với giá trị cao hơn tổng số dư Ether của nó.

Mã thông báo gốc và chuyển giao giá trị

Các rollup có thể định nghĩa Token gốc riêng của chúng. Hạn chế duy nhất là hàm chuyển đổi trạng thái không được chấp nhận hoặc thực hiện các lệnh CALL với giá trị Ether khác 0 từ hoặc đến một rollup bên ngoài nếu rollup đó sử dụng Token gốc khác. Điều này ngăn ngừa sự không khớp trong việc hạch toán giữa Token nội bộ của rollup và Ether được hệ thống L1 theo dõi.

Không Fork nĩa L1

Toàn bộ cơ chế này có thể được triển khai mà không cần tạo nhánh riêng cho L1 . Mọi thứ hoạt động thông qua các hợp đồng thông minh được triển khai trên mạng Ethereum hiện có.

Vuông góc với các xác nhận trước đó

Đề xuất này hoàn toàn độc lập với các cơ chế tiền xác nhận. Nó không phụ thuộc vào cũng không mâu thuẫn với các cơ chế tiền xác nhận. Trên thực tế, nó có thể hưởng lợi từ các cơ chế tiền xác nhận L1 một khi chúng khả dụng, vì Tính chất cuối cùng L1 nhanh hơn sẽ làm giảm độ trễ của các tương tác giữa các chuỗi.

Triển khai tham chiếu

Bản thảo đầu tiên về cách thức hoạt động của các hợp đồng thông minh này có sẵn tại: https://github.com/jbaylina/sync-rollups