Cảm ơn Conor, Lin và Swapnil từ nhóm Switchboard, Cecilia và Brecht từ nhóm Taiko, Alex Obadia, Justin Drake, Artem Kotelskiy và nhóm Chainbound đã đánh giá.
Tóm tắt
Việc thống nhất về thời gian trong một môi trường phi tập trung có thể là một thách thức: đồng hồ treo tường có thể sai lệch giữa các máy, các tác nhân có thể nói dối về múi giờ địa phương của họ và nhìn chung rất khó để phân biệt giữa mục đích xấu và đồng hồ không đồng bộ hoặc độ trễ mạng.
Ethereum có thể được coi như một chiếc đồng hồ toàn cầu tích tắc với tốc độ 1 tích tắc trong khoảng 12 giây. Tốc độ tích tắc này được thực thi mềm bởi giao thức đồng thuận: các khối và chứng thực được tạo ra quá sớm hoặc quá muộn sẽ không được coi là hợp lệ. Nhưng chúng ta nên làm gì để đạt được độ chi tiết thấp hơn 12 giây? Chúng ta có luôn cần một giao thức đồng thuận để theo dõi thời gian không?
Chúng tôi muốn khám phá những câu hỏi này trong bối cảnh các trình tự L2 không đáng tin cậy, những trình tự này không có động lực để tuân theo lịch trình khối L2 hiện đang được duy trì bởi các trình tự L2 đáng tin cậy và có thể sẽ chơi nhiều trò chơi tính thời gian khác nhau để tối đa hóa doanh thu của mình.
Trong bài viết này, chúng tôi giới thiệu các cơ chế để thực thi tính kịp thời, an toàn và sắp xếp không khai thác của trình tự trong một rollup phi tập trung có cơ chế lãnh đạo luân phiên , mà không dựa vào sự đồng thuận bổ sung, các giả định đa số trung thực hoặc lòng vị tha. Để làm như vậy, chúng tôi sử dụng ba nguyên hàm chính:
- Tùy chọn đặt hàng của khách hàng,
- Ethereum như một chiếc đồng hồ toàn cầu 12 giây,
- Chức năng trì hoãn có thể xác minh.
Cuối cùng, chúng tôi trình bày nghiên cứu điển hình về MR-MEV-Boost, một sửa đổi của MEV-Boost cho phép thay đổi các xác nhận trước dựa trên cơ sở, trong đó cùng một cấu trúc được khám phá có thể được áp dụng để giảm trò chơi thời gian của người đề xuất.
Cơ sở lý luận
Trình sắp xếp Rollup là các thực thể chịu trách nhiệm sắp xếp (và trong hầu hết các trường hợp, thực hiện) các giao dịch L2 và thỉnh thoảng cập nhật gốc trạng thái L2 trên L1. Hiện tại, trình sắp xếp tập trung được hưởng lợi từ thế chấp uy tín của các nhóm xây dựng chúng để duy trì năm thuộc tính:
- Khả năng phản hồi : phản hồi giao dịch của người dùng bằng các cam kết mềm/xác nhận trước một cách kịp thời . Chúng tôi muốn nhấn mạnh rằng định nghĩa này bao gồm việc phát sóng kịp thời các đầu không an toàn trên mạng ngang hàng rollup.
- Không mơ hồ (an toàn) : tuân thủ các cam kết xác nhận trước khi gửi lô lệnh trên L1, đây chính là yếu tố cuối cùng quyết định tổng số lệnh của các giao dịch.
- Đặt hàng không khai thác : không khai thác MEV từ người dùng bằng cách chạy trước hoặc xen kẽ, hoặc bằng cách nhận hối lộ để được hưởng đặc quyền chạy trước.
- Độ sống động : đăng các đợt lên L1 và cập nhật trạng thái tổng hợp chuẩn thường xuyên.
- Chống kiểm duyệt: đảm bảo rằng không có giao dịch hợp lệ nào bị trình sắp xếp loại trừ một cách cố ý bất kể người gửi, nội dung hoặc bất kỳ yếu tố bên ngoài nào.
Trong bài viết này, chúng tôi quan tâm đến cách bốn thuộc tính đầu tiên có thể được duy trì trong một môi trường không được cấp phép và không đáng tin cậy. Lưu ý rằng khả năng chống kiểm duyệt được đảm bảo bằng cách xây dựng: bằng cách giới thiệu nhiều trình tự sắp xếp riêng biệt về mặt tổ chức ở các khu vực địa lý và thẩm quyền khác nhau, chúng tôi có sự đảm bảo mạnh mẽ rằng bất kỳ giao dịch nào cuối cùng cũng sẽ được chấp nhận.
Hãy xem xét một tập trình tự phân cấp S := \{S_1,\dots,S_n\} S : = { S 1 , … , S n } với cơ chế xoay vòng dẫn đầu có thể dự đoán được và một cửa sổ trình tự tương ứng với một lượng khe L1 đã biết. Để đơn giản, chúng ta hãy giả sử S_{i} S i là dẫn đầu hiện tại và S_{i+1} S i + 1 là dẫn đầu tiếp theo. Tại bất kỳ thời điểm nào, chỉ có một trình tự hoạt động và có khóa trên trạng thái cuộn lên.
Sau đây là hai chiến lược mà trình sắp xếp S_i S i có thể khám phá để tối đa hóa giá trị mong đợi của nó:
1. Trì hoãn việc đưa vào các giao dịch
Giả sử người dùng gửi một giao dịch đến S_i S i tại một khe L2 nhất định. Sau đó, trình sắp xếp có thể đợi một thời gian trước khi chèn giao dịch vào một khối để trích xuất thêm MEV bằng các cuộc tấn công sandwich kết hợp với các trình tìm kiếm hoặc bằng cách chạy trước trực tiếp người dùng. Đặc biệt, vì MEV tăng theo siêu tuyến tính theo thời gian , nên việc cam kết sớm cho một giao dịch không phải là lợi ích tốt nhất của trình sắp xếp. Trường hợp xấu nhất sẽ là trình sắp xếp trì hoãn việc đưa vào cho đến khi trình sắp xếp xoay $^1$.
2. Không công bố các đầu không an toàn trong mạng ngang hàng rollup
Trong cài đặt này, trình sắp xếp có động cơ thấp để công bố các đầu không an toàn trong mạng cuộn: vì các khối L2 được trình sắp xếp ký (ví dụ trong Optimism ), chúng hoạt động như một cam kết ràng buộc mà người dùng có thể sử dụng để cắt bỏ trong trường hợp có sự nhầm lẫn.
Điều này có hậu quả hạ lưu lớn đối với UX của rollup: cả trình sắp xếp tiếp theo và người dùng đều cần phải đợi cho đến khi một lô được đưa vào để xem các giao dịch mới nhất. Đối với người dùng, điều này có nghĩa là họ sẽ không biết trạng thái giao dịch của mình một cách kịp thời, trong khi trình sắp xếp tiếp theo có nguy cơ xây dựng các khối trên trạng thái không hợp lệ.
Bây giờ chúng ta sẽ khám phá các cơ chế để giảm thiểu những hành vi này và đưa ra các điều kiện cắt giảm cho trình sắp xếp chuỗi.
Nguyên thủy 1: Thời hạn giao dịch
Chúng tôi giới thiệu loại giao dịch EIP-2718 mới với một trường bổ sung:
-
deadline-uint256biểu thị số khối L2 cuối cùng mà giao dịch được coi là hợp lệ.
Ý tưởng này không hoàn toàn mới. Ví dụ, nhóm LimeChain đã khám phá điều này trong bài viết Vanilla Based Sequencing của họ. Tuy nhiên, trong biến thể của chúng tôi, trường deadline được ký như một phần của tải trọng giao dịch và không được thể hiện trong các khe L1.
Lý do đằng sau điều này là trình sắp xếp không thể can thiệp vào trường deadline hoặc block.number (vì đây là bộ đếm tăng đơn điệu) và do đó, có thể dễ dàng sửa đổi đường ống dẫn xuất L2 để quy lỗi trong trường hợp trình sắp xếp chèn giao dịch của người dùng vào khối có block.number > deadline .
Cách tiếp cận này làm giảm vấn đề số 1. Tuy nhiên, nó không giải quyết được vấn đề về khả năng phản hồi theo bất kỳ cách nào, vì trình tự vẫn có thể trì hoãn việc đề xuất khối để trích xuất thêm MEV.
Nguyên thủy 2: Ethereum như một chiếc đồng hồ toàn cầu
Một thiết kế trình tự tuần tự xoay đơn giản sẽ là thiết kế mà S_i S i mất khả năng giải quyết các lô sau khi kết thúc cửa sổ trình tự W_i W i của nó, được quyết định bởi hợp đồng thông minh L1. Tuy nhiên, trình tự tuần tự vẫn cần một khoảng thời gian để đăng lô với các khối L2 mới nhất. Do đó, chúng tôi giới thiệu một cửa sổ bao gồm được dịch chuyển n \geq 1 n ≥ 1 khe trước W_i W i , trong đó S_i S i vẫn có thời gian để đưa các lô cuộn lên L1 với các khối L2 cuối cùng, ngay cả khi trách nhiệm giải trình tự đã chuyển sang S_{i+1} S i + 1 .
Trong trường hợp có bất kỳ lỗi an toàn nào, trình sắp xếp chuỗi nên bị cắt. Nếu trình sắp xếp chuỗi không thể đăng tất cả các khối L2 được chỉ định của chúng vào cuối cửa sổ bao gồm của nó, nó sẽ từ bỏ tất cả các phần thưởng liên quan. Tùy chọn, cũng có thể có các hình phạt cho các lỗi về tính sống động. Điều này cũng giúp giải quyết vấn đề cộng tác với trình sắp xếp chuỗi tiếp theo, bằng cách đảm bảo rằng các khối mới nhất sẽ được trình sắp xếp chuỗi biết đến trong vòng n\cdot12 n ⋅ 12 giây. Lý tưởng nhất là chúng ta muốn giữ n n càng nhỏ càng tốt với giá trị là 1 1 .
Vẫn còn một số vấn đề tiềm ẩn ở đây: việc đưa một giao dịch vào Ethereum là xác suất, nghĩa là bạn không thể chắc chắn rằng giao dịch bạn gửi thực sự sẽ được đưa vào đúng thời điểm. Trong bối cảnh này, điều đó có nghĩa là lô cuối cùng do một nhà lãnh đạo trung thực gửi có thể không được đưa vào L1 vào cuối cửa sổ đưa vào của nó. Có thể khắc phục điều này bằng hai cách:
- Thiết lập “dựa trên”, trong đó trình tự cũng là người đề xuất khối L1 và có thể bao gồm bất kỳ giao dịch nào cho đến thời điểm họ phải đề xuất hoặc
- Sử dụng cam kết của người đề xuất với giao thức như Bolt . Chúng tôi sẽ trình bày thêm về điều này trong phần "Công việc tiếp theo" bên dưới.
Lưu ý rằng chúng tôi cho rằng có một hợp đồng thông minh đăng ký có thể được tham khảo cho trình sắp xếp hiện đang hoạt động, tức là nó triển khai một số cơ chế bầu cử người dẫn đầu và xử lý các trái phiếu trình sắp xếp cùng với phần thưởng và hình phạt. Quản trị rollup quyết định xem sổ đăng ký có thể hoàn toàn không cần cấp phép hay nên sử dụng danh sách cho phép. Trong trường hợp có bất kỳ hành vi sai trái nào, quản trị sẽ được sử dụng để xóa tạm thời hoặc vĩnh viễn trình sắp xếp khỏi danh sách cho phép.
Nguyên thủy 3: Các hàm trì hoãn có thể xác minh
Hàm trì hoãn có thể xác minh (gọi tắt là VDF) là một nguyên hàm mật mã cho phép người chứng minh cho người xác minh biết rằng đã dành một khoảng thời gian nhất định để chạy một hàm và thực hiện theo cách mà người xác minh có thể kiểm tra kết quả một cách nhanh chóng.
Ví dụ, hãy xem xét một hàm băm mật mã h h và xác định ứng dụng
trong đó s s là một mảng byte và n n là một số tự nhiên.
Việc biên soạn (hoặc nối) các hàm băm như SHA-256 không thể được tăng tốc một cách dễ dàng bằng cách sử dụng các phép tính song song, nhưng giải pháp này thiếu sự xác minh hiệu quả$^2$ vì cách duy nhất để xác minh kết quả là tính toán lại thành phần của các hàm. Giải pháp này xuất hiện như một VDF ngây thơ trong bài báo của Boneh và vì lý do này, nó được gọi là yếu .
Một ví dụ khác về VDF là phép lặp bình phương trên một nhóm thứ tự ẩn , với phép này có thể xây dựng các câu đố khóa thời gian. Chúng ta sẽ khám phá cách sử dụng phép sau trong các phần tiếp theo.
Nhưng tại sao lại là VDF?
VDF rất hữu ích trong bối cảnh sắp xếp vì chúng có thể hoạt động như bằng chứng về thời gian đã trôi qua trong suốt thời gian của khối (cụ thể là block_time / max_adversary_speedup , xem “Cân nhắc về bảo mật” ). Hãy xem xét thuật toán sau cho đường ống sản xuất khối:
- Khi bắt đầu khối L2 N N , trình sắp xếp bắt đầu tính toán VDF mất thời gian khối L2 (hoặc ít hơn một chút) để tính toán cho những người chơi trung thực, sử dụng hàm băm khối trước đó làm đầu vào.
- Sau khi kết thúc khe L2, trình sắp xếp sẽ xây dựng một khối B_N B N trong đó tiêu đề chứa kết quả của VDF, được ký hiệu là V_N V N. Chúng tôi gọi việc niêm phong này là một khối. Điều này có nghĩa là bản tóm tắt băm khối chứa V_N V N.
Thuật toán này có đặc tính tuyệt vời là tạo ra một chuỗi các phép tính VDF, theo một nghĩa nào đó tương tự như Proof of History của Solana mà chúng ta thừa hưởng các đảm bảo an toàn. Điều này mang lại cho chúng ta điều gì trong bối cảnh trình sắp xếp chuỗi? Nếu chúng ta nhớ rằng trình sắp xếp chuỗi có một thời hạn nhất định mà nó phải đăng các lô được đặt theo lịch trình khe L1, chúng ta có thể yêu cầu L1 thực thi rằng ít nhất một số khối L2 cần được giải quyết. Điều này có hai kết quả hạ lưu:
- Trình sắp xếp phải bắt đầu tạo và niêm phong các khối ngay khi cửa sổ sắp xếp của chúng bắt đầu. Ghép nối điều này với thuộc tính thời hạn giao dịch sẽ tạo ra giới hạn thời gian trên khi giao dịch có thể được xác nhận. Nếu chúng không tuân theo lịch trình khối do VDF và L1 đặt ra, chúng có nguy cơ không thể đăng bất kỳ lô nào.
- Chúng tôi giảm thiểu vấn đề số 2 bằng cách loại bỏ động cơ giữ lại dữ liệu (không tính đến các cuộc tấn công phá hoại thuần túy): điều này là do trình sắp xếp không thể can thiệp vào chuỗi VDF hiện có, điều này sẽ yêu cầu tính toán lại tất cả các VDF tiếp theo và tạo ra một lô không hợp lệ.
Nhìn chung, vì mục đích của bài đăng này, chúng ta sẽ xem xét một VDF chung, được cung cấp dưới dạng "hộp đen" trong khi vẫn lưu ý đến ví dụ về chuỗi băm hiện có bảo đảm mạnh hơn đối với phần cứng ad-hoc như ASIC. Xem "Cân nhắc về bảo mật" bên dưới để biết thêm thông tin chi tiết.
Chứng minh VDF đúng
Nếu một trình sắp xếp cung cấp VDF không hợp lệ trong tiêu đề khối L2, nó phải bị cắt và lý tưởng nhất là chúng tôi muốn đảm bảo điều này tại thời điểm thanh toán. Tuy nhiên, việc tính toán lại chuỗi băm dài trên EVM là không khả thi do chi phí gas.
Vậy thì làm sao để chứng minh rằng số lần lặp lại của VDF là không hợp lệ? Một cách có thể là thực thi nó một cách lạc quan (hoặc tại thời điểm thanh toán, trong trường hợp ZK-rollups) bằng cách yêu cầu đầu ra chuỗi VDF hợp lệ trong đường ống dẫn xuất của rollup. Trong trường hợp có sự mơ hồ trong rollup lạc quan, trình sắp xếp có thể bị thách thức bằng cách sử dụng bằng chứng gian lận.
Yêu cầu phần cứng
Vì theo định nghĩa, VDF không thể tăng tốc bằng cách sử dụng tính song song, nên việc tính toán VDF chỉ có thể được thực hiện bằng cách sử dụng một lõi CPU, và thuật toán sản xuất khối của chúng tôi cũng vậy.
Điều này làm cho nó khác biệt và nhẹ hơn nhiều so với hầu hết các thuật toán đồng thuận Proof-of-Work như Bitcoin, vốn yêu cầu quét giá trị sao cho khi băm bằng SHA-256, giá trị băm sẽ bắt đầu bằng một số bit số 0 nhất định.
Cũng đáng lưu ý rằng CPU hiện đại được tối ưu hóa để tính toán hàm băm SHA-256. Kể từ năm 2016, Intel, bắt đầu với dòng chip Goldmount , đã cung cấp SHA Extensions trong dòng Core và Xeon trên các mẫu máy được chọn, giới thiệu ba lệnh mới chuyên tính toán các bước khác nhau của thuật toán hàm băm hiệu quả hơn.
Cuối cùng, hiệu suất lõi đơn đã trì trệ trong những năm qua, cho thấy việc đầu tư vào thế hệ CPU mới nhất mang lại một lợi ích nhỏ, do đó làm giảm yêu cầu của hệ thống.
Nghiên cứu tình huống: MR-MEV-Boost
Multi-Round-MEV-Boost , là một sửa đổi của MEV-Boost cho phép xác nhận trước dựa trên việc chạy nhiều vòng đấu giá MEV-Boost trong một khe L1 duy nhất. Việc sử dụng nguyên thủy này là để xuất ra sau mỗi vòng một khối tổng hợp dựa trên được xây dựng bởi các trình xây dựng khối L2. Như đã trình bày trong bài viết, cách tiếp cận này kế thừa đường ống PBS L1 và giảm thiểu một số tác động tiêu cực của các xác nhận trước dựa trên kết quả.
Giống như MEV-Boost, fork này dựa vào người đề xuất được chọn là người đấu giá kết thúc phiên đấu giá kín bằng cách gọi điểm cuối getHeader ( Builder-API ) của các rơle. Sau khi đã ký giá thầu kín, getPayload ( Builder-API ) được người đề xuất gọi để nhận nội dung thực tế của giá thầu thắng và để xuất bản khối trong mạng lưới rollup dựa trên.
Trong giao thức gốc, thời điểm kết thúc phiên đấu giá thường trùng với thời điểm kết thúc của khe L1 (chính xác hơn là gần một giây sau đó ); việc trì hoãn thời điểm kết thúc sẽ dẫn đến rủi ro cao là không thể phát khối kịp thời để thu thập tất cả các xác nhận cần thiết và từ bỏ tất cả các phần thưởng liên quan. Do đó, thời gian khối được đề xuất sau mỗi mười hai giây với tính nhất quán, được thực thi bởi sự đồng thuận của Ethereum.
Ngược lại, vì nó bao gồm nhiều vòng diễn ra trong suốt thời gian diễn ra, trong MR-MEV-Boost, một người đề xuất không đáng tin cậy sẽ được khuyến khích kết thúc phiên đấu giá sớm hơn hoặc muộn hơn vài giây ^{3} 3 theo giá thầu đến, để trích xuất nhiều MEV hơn. Trong trường hợp xấu nhất, MR-MEV-Boost sẽ phản ánh thời gian khối L1. Một hậu quả khác của điều này là thời gian khe không nhất quán cho cuộn dựa trên. Điều này có thể được coi là một hình thức trò chơi thời gian nghiêm trọng hơn nhiều.
Trong bài viết, các giải pháp khả thi được thảo luận cho vấn đề này như sau:
- Giới thiệu các ưu đãi cho người dùng: nếu người dùng xác định rằng người đề xuất có hành vi không đúng, họ sẽ ngừng gửi giao dịch cho người đề xuất đó.
- Thành lập một ủy ban (đồng thuận) để chứng thực tính kịp thời và duy trì thời lượng.
Bây giờ chúng tôi lập luận rằng một giải pháp không cần tin cậy, hạn chế mạnh mẽ người đề xuất mà không yêu cầu người dùng thực hiện hành động, thực sự tồn tại và nó tận dụng cùng một cấu trúc mà chúng tôi đã sử dụng cho thuật toán sản xuất khối do VDF cung cấp trong bối cảnh giải trình tự phi tập trung.
Cấu trúc này khá đơn giản và bao gồm việc tính toán VDF kéo dài x := 12/r x : = 12 / r giây, trong đó r r là số vòng trong một khe L1 (thời gian khối L2). Người đề xuất phải tính toán VDF này bằng cách sử dụng hàm băm khối rollup dựa trên trước đó làm đầu vào công khai và, khi kết thúc vòng, gửi nó cùng với phần thân của lệnh gọi getPayload đã sửa đổi. Đầu ra của VDF sau đó được lưu trữ trong tiêu đề khối rollup và nếu không hợp lệ có thể dẫn đến việc cắt bỏ người đề xuất sau khi chứng minh gian lận thành công.
Với cách tiếp cận này, lượng thời gian mà người đề xuất có thể trì hoãn kết thúc một vòng bị giới hạn: ví dụ, nếu phiên đấu giá đầu tiên kết thúc muộn hơn một giây thì trong vòng đấu giá cuối cùng, nó sẽ không thể cung cấp ba giây tính toán cho VDF mà là hai giây, dẫn đến một khối không hợp lệ và do đó cắt giảm $^4$. Điều này là do để bắt đầu tính toán một VDF hợp lệ, nó yêu cầu băm khối trước đó làm đầu vào, ngụ ý một khối đã niêm phong.
Cân nhắc về bảo mật
Liệu VDF có thực sự an toàn cho mục đích này không?
Giả sử một đối thủ sở hữu phần cứng có khả năng tính toán VDF nhanh hơn so với đường cơ sở của những người chơi trung thực mà không bị phát hiện (nếu không, số lần lặp lại cho VDF sẽ được điều chỉnh theo giao thức). Khi đó, kẻ tấn công càng nhanh ( max_adversary_speedup ), thì cấu trúc của chúng ta sẽ càng ít hạn chế không gian cho các hành động có thể xảy ra của nó. Đặc biệt, trình sắp xếp sẽ có thể cam kết một chút sau đó với các khối và có thể sắp xếp lại một số khối để trích xuất nhiều giá trị hơn.
Tuy nhiên, vì chúng ta không cần thuộc tính "chứng minh nhanh", chuỗi băm đã chứng minh được tính mạnh mẽ với Proof of History của Solana và sẽ tiếp tục như vậy ít nhất là trong ngắn hạn. Ngoài ra, các yêu cầu bảo mật của chúng ta sẽ không nghiêm ngặt như thứ cần được ghi nhận mãi mãi trong Ethereum .
Một số giải pháp và hướng dẫn để có được sự đảm bảo an toàn chặt chẽ hơn có thể được tìm thấy trong phần “Công việc tiếp theo” bên dưới.
Những hạn chế hiện tại
Độ tin cậy của trình sắp xếp
Giống như nhiều dịch vụ mới tận dụng việc (tái) đặt cược, độ tin cậy của trình sắp xếp có giới hạn trên là số tiền mà nó đã đặt cược: nếu cơ hội MEV vượt quá mức đó, thì một tác nhân không đáng tin cậy và lý trí sẽ thích bị cắt giảm và nhận phần thưởng MEV.
Sự luân chuyển lãnh đạo có thể là một thời điểm quan trọng
Như đã thảo luận trong phần hợp đồng thông minh về batcher và registry, cửa sổ bao gồm được dịch chuyển tối thiểu một khe về phía trước so với cửa sổ sắp xếp. Điều này là cần thiết vì thời gian cần thiết để giải quyết batch cuối cùng trước khi xoay vòng leader, nhưng để lại thêm một khe thời gian ít nhất là 12 giây trong đó sequencer có chỗ để sắp xếp lại các khối L2 cuối cùng trước khi xuất bản chúng trên mạng ngang hàng rollup. Do đó, tính sống tạm thời bị ảnh hưởng vì S_{i+1} S i + 1 có thể đang xây dựng các khối trên trạng thái không hợp lệ nếu nó bắt đầu sắp xếp ngay lập tức.
Cuối cùng, một khe cắm bổ sung có thể không đủ để giải quyết một lô theo dữ liệu gần đây về tỷ lệ bao gồm khe cắm cho các blob . Điều này có thể được giảm thiểu bằng cách tận dụng các giao thức xác nhận trước bao gồm mới, như được giải thích bên dưới.
Trình sắp xếp nhìn lần cuối
Cấu trúc của chúng tôi khiến cho trình sắp xếp rất khó tổ chức lại một khối sau khi nó đã được cam kết, tuy nhiên nó không giải quyết được hoàn toàn việc chạy trước. Cụ thể, trình sắp xếp có thể trích xuất giá trị từ các giao dịch của người dùng trong khi xây dựng khối với trường deadline liên quan. Một giải pháp khả thi cùng với các hạn chế của nó được khám phá trong phần bên dưới.
Phần kết luận
Trong bài viết này, chúng tôi khám phá các cơ chế để thực thi tính kịp thời, an toàn và sắp xếp không trích xuất của các trình tự L2 không đáng tin cậy trong môi trường tổng hợp phi tập trung.
Các nguyên mẫu được thảo luận đảm bảo rằng các trình sắp xếp có thể hoạt động theo cách có thể dự đoán và công bằng hơn, giảm thiểu các vấn đề như sự chậm trễ trong giao dịch và giữ lại dữ liệu. Hơn nữa, các kỹ thuật này có thể giảm các giả định về độ tin cậy đối với các rollup trình sắp xếp đơn hiện có, phù hợp với khái niệm rollup hoạt động như "máy chủ có giàn giáo blockchain" . Những phát hiện này cung cấp một khuôn khổ vững chắc cho sự phát triển trong tương lai của các kiến trúc rollup phi tập trung, an toàn.
Công việc tiếp theo
Môi trường thực thi đáng tin cậy (TEE) để đảm bảo trình sắp xếp không chạy ASIC
Môi trường thực thi tin cậy là một khu vực an toàn của CPU, thường được gọi là enclave , giúp mã và dữ liệu được tải bên trong được bảo vệ về mặt tính bảo mật và toàn vẹn.
Việc sử dụng nó trong các giao thức blockchain là một lĩnh vực nghiên cứu đang được quan tâm, với mối quan tâm chính là việc tin tưởng nhà sản xuất phần cứng và các lỗ hổng khác nhau được tìm thấy trong quá khứ của một số triển khai (sau đây là thông tin mới nhất ).
Tùy thuộc vào trường hợp sử dụng, các giả định và lỗ hổng tin cậy này có thể là một sự phá vỡ thỏa thuận. Tuy nhiên, trong bối cảnh của chúng tôi, chúng tôi chỉ cần đảm bảo rằng trình sắp xếp không sử dụng phần cứng chuyên dụng để tính toán VDF, mà không quan tâm đến khả năng rò rỉ dữ liệu bí mật từ vùng an toàn hoặc thao túng đồng hồ treo tường / đồng hồ đơn điệu.
Thích ứng với các thuật toán Proof-of-Work chống ASIC hiện có
Blockchain Monero , ra mắt vào năm 2014 như một giải pháp thay thế cho Bitcoin tập trung vào quyền riêng tư và không thể theo dõi, sử dụng thuật toán Proof-of-Work chống ASIC có tên là RandomX . Trích dẫn README của họ:
RandomX là thuật toán bằng chứng công việc (PoW) được tối ưu hóa cho CPU mục đích chung. RandomX sử dụng thực thi mã ngẫu nhiên (do đó có tên như vậy) cùng với một số kỹ thuật khó nhớ để giảm thiểu lợi thế về hiệu quả của phần cứng chuyên dụng.
Tuy nhiên, thuật toán này tận dụng một số mức độ song song ; đây là một hướng nghiên cứu thú vị liệu nó có thể được chuyển thể thành phiên bản lõi đơn, dẫn đến một VDF yếu mới hay không.
Cách tiếp cận này, mặc dù trái ngược với việc sử dụng TEE, nhưng có khả năng đạt được cùng một kết quả là đảm bảo rằng máy giải trình tự không sử dụng phần cứng phức tạp.
Câu đố khóa thời gian để ngăn chặn chạy trước
Như đã đề cập trong phần “Những hạn chế hiện tại” , cấu trúc của chúng tôi không hạn chế vấn đề chạy trước trình sắp xếp người dùng. May mắn thay, vấn đề này có thể được giải quyết bằng cách yêu cầu người dùng mã hóa các giao dịch nhạy cảm bằng các câu đố khóa thời gian , như chúng tôi sẽ trình bày chi tiết hơn trong một bài viết riêng. Tuy nhiên, giải pháp này không miễn phí: các giao dịch được mã hóa hoặc mempool được mã hóa có thể khuyến khích spam và chênh lệch thống kê, đặc biệt là khi phí giao thức không quá cao .
Bao gồm các lớp Xác nhận trước và Tính khả dụng của dữ liệu
Việc gửi hàng loạt cho hợp đồng L1 có thể hiệu quả hơn bằng cách tận dụng một số giao thức xác nhận trước mới như Bolt của Chainbound hoặc MEV-Commit của Primev để đảm bảo đưa vào cùng một vị trí. Đặc biệt, các cửa sổ sắp xếp phải kết thúc chính xác trong vị trí trước vị trí mà người đề xuất đang chạy các giao thức đã đề cập ở trên để tận dụng các cam kết đưa vào.
Ngoài ra, lô hàng có thể được đưa vào lớp Khả dụng dữ liệu nhẹ và hiệu quả do người đề xuất chạy để áp dụng thời hạn là một lượng giây có thể cấu hình vào đầu khe, nếu không, trình sắp xếp sẽ bị cắt.
Chú thích
- Chính xác hơn, nếu người vận hành kiểm soát nhiều máy giải trình tự liên tiếp, họ có thể trì hoãn việc đưa vào cho đến lần xoay máy giải trình tự cuối cùng.
- Trong Solana, việc xác minh chuỗi SHA-256 thực sự được song song hóa nhưng yêu cầu chia một khối liên quan đến phép tính ~400ms thành 32 mảnh được chuyển tiếp đến các trình xác thực còn lại ngay khi chúng được tính toán. Do đó, việc xác minh được đẩy nhanh bằng cách tính toán các bước trung gian của chuỗi băm song song.
- Nhìn chung, người đề xuất sẽ kết thúc một số vòng sớm hơn như một tác dụng phụ của việc trì hoãn các vòng khác. Ví dụ, họ có thể buộc phải thực hiện một vòng cuối dài hơn để tận dụng các cơ hội chênh lệch giá L1 <> L2 có thể xảy ra.
- Có một trường hợp ngoại lệ mà người đề xuất có thể không tính toán được tất cả các VDF ngay cả khi trung thực, và điều này là do cơ chế xoay vòng: vì đầu vào công khai của VDF phải là băm khối rollup trước đó, trong quá trình xoay vòng, người dẫn đầu tiếp theo sẽ cần một khoảng thời gian trước khi nghe khối từ mạng rollup, có khả năng là hơn 1 giây. Điều này có thể khiến người đề xuất tiếp theo tính toán VDF chậm.
Để giảm thiểu rủi ro này, người đề xuất tiếp theo có thể dựa vào nhiều bên khác nhau để nhận thông tin này như dịch vụ phát trực tuyến và/hoặc rơle đáng tin cậy.
