Custard - Cải thiện UX cho Super TX

Công việc chung với Kubi. Cảm ơn Drew, Justin, Ladislaus, Conor, Lin về việc xem xét và phản hồi của họ. Phản hồi không nhất thiết là một sự ủng hộ.

Custard (Constraining User State To Avoid Reneging Downstream) là một kỹ thuật cho phép các giao dịch siêu có thể kết hợp được một cách nguyên tử trên các rollup dựa trên thông qua quản lý trạng thái cẩn thận. Hiểu biết chính yếu là bằng cách hạn chế các phần cụ thể của trạng thái L1 mà một giao dịch siêu phụ thuộc vào, chúng ta có thể cho phép các bộ xác nhận phát hành các tiền xác nhận thực hiện L1 trước khi cần mà không yêu cầu kiểm soát toàn bộ khối L1. Điều này giảm sự phối hợp của bộ xác nhận cần thiết để khởi động các giao thức tiền xác nhận và cho phép các rollup dựa trên cung cấp các giao dịch siêu sớm hơn với ít bộ xác nhận tham gia hơn. Bài đăng này khám phá ba cách để thực hiện Custard: thông qua EIP-7702, hợp đồng thông minh và tiền xác nhận loại trừ.

Tại sao điều này lại quan trọng?

Một lợi ích chính của việc sắp xếp dựa trên là nó cho phép đồng bộ hóa và tính nguyên tử giữa L1 và các rollup dựa trên (BRU). Điều này có nghĩa là các hoạt động trên cả hai lớp có thể được kết hợp thành những gì chúng ta gọi là "giao dịch siêu", một bó các giao dịch hoạt động trên cả hai lớp như thể chúng là một.

Một ví dụ thực tế

Hãy xem xét một ví dụ thực tế: L1→L2→L1 arbitrage. Hãy tưởng tượng rằng Alice muốn thực hiện nguyên tử:

1. Di chuyển các token của cô ấy từ L1 đến một BRU
2. Thực hiện một giao dịch trên BRU
3. Di chuyển các token và lợi nhuận của cô ấy trở lại L1

Hiện tại, đây sẽ là các bước riêng biệt với các khoảng trễ giữa chúng (ví dụ: thông thường là 7 ngày giữa các bước 2-3 đối với các rollup lạc quan). Áp dụng Custard, Alice có thể gói tất cả các hành động này thành một giao dịch siêu hoàn thành trong một khối Ethereum duy nhất.

Để các giao dịch siêu được áp dụng rộng rãi, chúng ta cần giải quyết ba thách thức chính:

1. Chứng minh thời gian thực: Chúng ta cần một cách để thanh toán trạng thái của BRU nhanh đủ để rút ra trong một khối L1 duy nhất
2. Đảm bảo tính nguyên tử: Chúng ta cần các cơ chế để đảm bảo rằng hoặc tất cả các phần của giao dịch siêu hoàn thành thành công hoặc không có gì xảy ra
3. Sẵn có của bộ xác nhận: Chúng ta cần sự tham gia của bộ xác nhận đủ để làm cho các giao dịch siêu đáng tin cậy và sẵn có cho người dùng

Phần còn lại của bài đăng này sẽ xem xét từng thách thức này và các phương pháp hiện có để giải quyúng chúng, trước khi giới thiệu Custard như một cách để kết hợp chúng lại.

Thách thức #1: Chứng minh thời gian thực

Phương pháp truyền thống và những hạn chế của nó

Cho đến nay, người ta thường tin rằng các rút tiền không cần tin cậy ngay lập tức từ các rollup yêu cầu "chứng minh thời gian thực" - về cơ bản, trạng thái của rollup phải được thanh toán thông qua bằng chứng hợp lệ. Để giao dịch siêu của Alice hoàn thành trong một khối L1 (12 giây), bằng chứng hợp lệ sẽ cần được tạo ra nhanh hơn. Tuy nhiên, công nghệ để tạo ra những bằng chứng này nhanh như vậy (SNARKs thời gian thực) chưa được triển khai trên thị trường nhưng có rất nhiều nỗ lực tuyệt vời đang diễn ra ().

Các giải pháp hiện tại

Một số dự án (UniFi, Gwyneth, T1) đã chuyển sang Trusted Execution Environments (TEEs) như một giải pháp thay thế cho SNARKs để chứng minh chức năng chuyển trạng thái của rollup. Mặc dù TEEs có thể tạo ra các bằng chứng nhanh hơn nhiều so với SNARKs, làm cho chứng minh thời gian thực trở nên khả thi, nhưng chúng cũng có một nhược điểm đáng kể: chúng yêu cầu tin tưởng vào nhà sản xuất phần cứng và người chứng minh. Giả định tin cậy bổ sung này đưa vào các rủi ro mới cho các rollup dựa trà mà các hệ thống dựa trên SNARK truyền thống không có.

Một giải pháp mới: Phương pháp Solver

Nethermind gần đây đã đề xuất một giải pháp đạt được trải nghiệm người dùng của các rút tiền ngay lập tức mà không cần chứng minh thời gian thực. Phương pháp của họ:

• Sử dụng các bộ giải quyết để ngay lập tức cung cấp cho người dùng thanh khoản rút tiền trên L1 trước khi trạng thái BRU được thanh toán
• Duy trì tính nguyên tử (các bộ giải quyết và cầu BRU được bảo vệ khỏi các reorg)
• Duy trì tính không cần tin cậy (không cần tin tưởng vào bộ giải quyết hoặc TEEs)
• Cung cấp một con đường thực tế trong khi chúng ta chờ đợi công nghệ chứng minh thời gian thực trưởng thành (với chi phí hiệu quả vốn)

Thách thức #2: Đảm bảo tính nguyên tử

Để giao dịch siêu của Alice hoạt động một cách suôn sẻ, chúng ta cần đảm bảo rằng hoặc tất cả các giao dịch con hoàn thành thành công hoặc không có gì xảy ra cả. Đây là nơi tiền xác nhận thực hiện (EPs) đến.

Vai trò của tiền xác nhận thực hiện

Để đảm bảo thành công của giao dịch siêu, chúng ta cần các bộ xác nhận Ethereum cung cấp bốn đảm bảo cụ thể:

1. Đảm bảo tiền gửi L1: Xác nhận rằng tiền của Alice sẽ chuyển thành công từ L1 → BRU
2. Đảm bảo trao đổi L2: Đảm bảo rằng giao dịch của Alice trên rollup sẽ được thực hiện như mong đợi
3. Đảm bảo rút tiền L2: Xác nhận yêu cầu của Alice để chuyển tiền từ BRU → L1 sẽ được xử lý
4. Đảm bảo bộ giải quyết L1: Đảm bảo rằng một bộ giải quyết sẽ chuyển tiền của Alice trên L1

Tại sao các bộ xác nhận Ethereum lại quan trọng

Một hiểu biết quan trọng là những đảm bảo này phải đến từ chính các bộ xác nhận Ethereum. Họ được định vị duy nhất để đưa ra những đảm bảo này vì họ có thể là người đề xuất cho cả hai lớp:

• Trên Ethereum, họ có quyền ghi trên L1 vì họ có thẩm quyền duy nhất để đề xuất khối tiếp theo
• Trên BRU, họ có thể được cấu hình để là những người duy nhất có quyền sắp xếp các giao dịch trong khoảng thời gian của họ

Khóa ghi kép này là điều làm cho việc sắp xếp dựa trên đặc biệt - chỉ có các bộ xác nhận Ethereum mới có thể cam kết một cách đáng tin cậy rằng một giao dịch siêu sẽ được thực hiện chính xác như kế hoạch. Tiền xác nhận dựa trên là cơ chế mà qua đó các bộ xác nhận đưa ra những lời hứa ràng buộc này - bằng cách đặt cọc vốn, các bộ xác nhận trở thành những người tiền xác nhận và phải chịu hình phạt kinh tế nếu họ không thể thực hiện các cam kết của mình.

Thách thức #3: Sẵn có của bộ xác nhận

Các ràng buộc EP L1

Một hạn chế quan trọng của các EP L1 là tính "just-in-time" của chúng. Các bộ xác nhận chỉ có thể an toàn phát hành các EP L1 này khi họ là người đề xuất khối hiện tại. Tại sao? Bởi vì một bộ xác nhận trong tương lai không có quyền ghi trên L1 và các bộ xác nhận trước đó có thể thay đổi trạng thái L1 theo cách làm cho các EP L1 của họ bị phá vỡ.

Điều này khác với các EP L2 trên roll

1. Khóa ban đầu (Slot S)
   • Alice khóa nonce của tài khoản của cô ấy cho đến một slot S' trong tương lai
   • Điều này ngăn chặn bất kỳ thay đổi nào đối với tài khoản của cô ấy cho đến khi đến slot được chỉ định
2. Thiết lập (Slot S + 1)
   • Alice yêu cầu giao dịch siêu của cô ấy từ một preconfer sẽ đề xuất tại một slot S' trong tương lai
   • Giao dịch bao gồm:
     • Gửi B ETH vào rollup
     • Thực hiện giao dịch arbitrage
     • Rút B + ε - f ETH (số tiền gốc cộng với lợi nhuận trừ phí)
     • Có một solver hoàn thành việc rút tiền trên L1
3. Xác minh (Slot S + 1)
   • Preconfer kiểm tra xem tài khoản của Alice có được khóa đúng cách hay không
   • Nếu được xác minh, preconfer sẽ cấp tất cả các preconf cần thiết
4. Thực hiện (Slot S')
   • Preconfer thực hiện toàn bộ giao dịch:
     • Gửi B ETH của Alice vào BRU
     • Cam kết blob BRU vào L1 chứa giao dịch của Alice
     • Hoàn thành việc chuyển B + ε - f ETH cho Alice trên L1
5. Thanh toán (Slot S' + Δ)
   • Sau Δ khối, trạng thái BRU được chứng minh
   • Solver có thể thu hồi B + ε + f ETH bằng cách rút tiền từ BRU

Nhận xét chính

Bằng cách khóa tài khoản của mình, Alice đảm bảo rằng cô ấy sẽ có đủ tiền (B ETH) khi giao dịch siêu được thực hiện. Preconfers có thể an toàn cấp EPs trên L1 trước thời gian nếu họ yêu cầu tài khoản phải được khóa trước, giải quyết được vấn đề về thời gian của chúng ta.

Custard với Smart Contracts

Trong khi chờ đợi EIP-7702 được phát hành, chúng ta có thể đạt được kết quả tương tự bằng cách sử dụng smart contract. Điểm khác biệt chính là thay vì sửa đổi hành vi tài khoản trực tiếp, người dùng phải trước tiên gửi tài sản của họ vào một hợp đồng ký quỹ thực thi cùng những đảm bảo tương tự:

• Tài sản bị khóa cho đến slot mục tiêu
• Các khoản tiền chỉ có thể được gửi vào rollup
• Không được phép giảm số dư tài sản cho đến khi đến thời điểm đó

image1920×916 86.9 KB

Quy trình thực hiện phản ánh cách tiếp cận EIP-7702, nhưng với một lợi thế đáng kể: hợp đồng ký quỹ tự nhiên tích lũy một pool các tài sản bị khóa, cho phép các tối ưu hóa hiệu quả vốn tiềm năng trong thiết kế giao thức.

Custard với Exclusion Preconfs

Exclusion preconfs đại diện cho một loại lời hứa của validator khác: thay vì đảm bảo những gì họ sẽ làm, các validator cam kết những gì họ sẽ không làm. Cụ thể, họ hứa sẽ ngăn chặn một số thay đổi trạng thái bằng cách không cho phép một số hành động tài khoản cụ thể diễn ra. Mặc dù exclusion thường đi ngược lại với các giá trị của Ethereum, khi được sử dụng cẩn thận trong bối cảnh này, nó phục vụ một mục đích xây dựng: khóa các trạng thái tài khoản cụ thể để bảo tồn tính hợp lệ của EP L1 trước thời gian. Quan trọng là những loại preconf này chỉ được phép nếu được chủ tài khoản ủy quyền rõ ràng để tránh bị kiểm duyệt.

Cách thức hoạt động

Hãy cùng xem Alice có thể thực hiện giao dịch siêu của cô ấy bằng cách sử dụng exclusion preconfs như thế nào:

1. Cấp Execution Preconfs
   • Alice nhận được exclusion preconfs từ các validator trước khi đến slot siêu giao dịch mục tiêu của cô ấy
   • Mỗi exclusion preconf hứa sẽ không:
     • Bao gồm các giao dịch sẽ tăng nonce của Alice
     • Bao gồm các giao dịch sẽ giảm số dư ETH của Alice
2. Thực hiện
   • Khi đến slot mục tiêu, EOA của Alice được đảm bảo sẽ có ETH cần thiết
   • Giao dịch siêu có thể tiếp tục an toàn

image1920×881 88.7 KB

Một lợi thế của cách tiếp cận này là tất cả các execution preconfs được cấp ngoài chuỗi, giảm chi phí gas. Tuy nhiên, nó giới thiệu một số phức tạp. Các giao dịch siêu vẫn yêu cầu tất cả các validator slot sớm hơn phải là L1 exclusion preconfers - mặc dù dễ hơn so với các cách tiếp cận trước, đây vẫn là một thách thức BD đáng kể. Ngoài ra, việc thanh toán cho exclusion preconfs trở nên phức tạp vì không có gì được đưa lên chuỗi trong trường hợp tốt nhất và các yêu cầu về tài sản thế chấp và điều kiện slashing cần được xem xét cẩn thận khi đánh giá rủi ro của việc không tuân thủ.

Hạn chế của cách tiếp cận này

Một phân biệt chính trong cách tiếp cận của Nethermind là yêu cầu rút tiền chỉ có một "điều kiện đầu ra L1" đơn giản - chúng chỉ cần xác minh rằng token đến được một địa chỉ L1 cụ thể. Sự đơn giản này là điều cho phép các rút tiền nguyên tử mà không cần chứng minh thời gian thực. Tuy nhiên, các giao dịch siêu phức tạp hơn có thể yêu cầu điều kiện đầu ra L1 phụ thuộc vào các thay đổi trạng thái L2 phức tạp, trong trường hợp này chúng ta có thể cần chứng minh trạng thái L2 theo thời gian thực. Mặc dù các nguyên tắc của Custard để quản lý các phụ thuộc trạng thái L1 vẫn áp dụng, các triển khai sẽ hoặc phải chờ đợi các SNARK thời gian thực trưởng thành hoặc chấp nhận các rủi ro bổ sung của các giải pháp chứng minh dựa trên TEE.