Nếu bạn muốn truyền bá thông tin về bài viết này, hãy thoải mái tương tác với chủ đề này
Đã có nhiều cuộc thảo luận và sự phấn khích xung quanh các bản tổng hợp dựa trên. Lý do cho điều này khá đơn giản, các bản tổng hợp dựa trên là dựa trên. Cụ thể, chúng cho phép các ứng dụng bám sát vào lớp cơ bản của chúng (+ duy trì tính đồng bộ) - trong khi có được một số siêu năng lực thường được dành riêng cho các bản tổng hợp và chuỗi ứng dụng (trong khi vẫn đảm bảo tính bảo mật). Đây là những thứ như tùy chỉnh, nội bộ hóa MEV và chuyên môn hóa. Lý do tại sao chúng ta thường không nói nhiều về các bản tổng hợp dựa trên trong quá khứ là vì các ý tưởng triển khai trong quá khứ thường tập trung vào việc quá tải những người đề xuất và biến mọi thứ thành các chuỗi đơn lẻ - điều không thể mở rộng quy mô trong các hệ thống siêu phi tập trung này. Hơn nữa, UX của các thiết lập này (khi không có xác nhận trước hoặc đảm bảo mềm) không đáp ứng được những gì các ứng dụng mong muốn.
Theo quan điểm của chúng tôi, giáo điều hiện tại xung quanh các rollup dựa trên đã thay đổi theo hướng tốt hơn. Tuy nhiên, vẫn còn những giả định quan trọng, những điều gì sẽ xảy ra nếu và những lo ngại về tập trung hóa. Dưới đây, chúng tôi sẽ cung cấp một cái nhìn tổng quan đơn giản về cách các rollup dựa trên được lên kế hoạch hoạt động trong quá khứ, cách triển khai hiện tại hoạt động và cách triển khai lý tưởng ngoài giao thức cuối cùng sẽ trông như thế nào (và trò chơi kết thúc trong giao thức).
Trước đây, cách thức rollup dựa trên cách thức thường được cho là được triển khai theo cách có khả năng tốn kém, gây áp lực đáng kể cho những người đề xuất hiện tại (và cung cấp UX tệ hại) hoặc phụ thuộc vào các tác nhân và trung gian nằm ngoài phạm vi của những người tham gia Ethereum thông thường. Điều này là do có rất nhiều cuộc thảo luận cụ thể xoay quanh việc để các trình xác thực L1 cũng chủ động sắp xếp và thực hiện các giao dịch rollup dựa trên (về cơ bản là biến nó thành một chuỗi duy nhất, mặc dù việc nén diễn ra ngoài chuỗi). Các ý tưởng khác tập trung vào việc chọn tham gia/không tham gia nhưng bên ngoài MEV-Boost, mà như chúng ta đã biết, chịu trách nhiệm cho hầu hết các khối Ethereum đã xây dựng - khiến việc tích hợp chủ động ngoài giao thức trở nên khó quản lý và khó thu hút sự chú ý hơn nhiều. Như bạn sẽ thấy sau, chúng tôi tin rằng ít nhất một lần triển khai đầu tiên của rollup dựa trên "hiệu quả" có khả năng sẽ diễn ra trong phạm vi ảnh hưởng của MEV-Boost, vì nó giúp tích hợp và tuân thủ dễ dàng hơn nhiều.
Trong bất kỳ ví dụ và đề cập nào bên dưới về rollup, hãy nhớ rằng nén xảy ra ngoài chuỗi (và dữ liệu được đăng lên L1 được thực hiện ở dạng nén). Chúng tôi khá quen với điều này từ các L2 hiện có với trình sắp xếp của chúng xử lý công việc này (và các nút đầy đủ giữ trạng thái đầy đủ). Trong một rollup dựa trên, công việc nén là một câu hỏi lớn hơn vì, trong ví dụ Taiko bên dưới, bất kỳ ai cũng có thể thực hiện nén này. Trong ví dụ MEV-Boost, điều này có thể được thực hiện bởi những người tìm kiếm và xây dựng cũng đang chạy các nút đầy đủ trên các rollup dựa trên. Một cảnh báo cần đưa ra ở đây là tương tự như bất kỳ blockchain nào khác, động lực để chạy một nút đầy đủ phải được tạo ra bằng cách có lực kéo đáng kể trên rollup dựa trên. Hoặc là lượng hoạt động trên rollup phải đủ lớn để ai đó thực hiện công việc nén hoặc để những người tìm kiếm và xây dựng trở nên tích cực ở đó. Hoặc trong các giai đoạn khởi động ban đầu, họ phải được khuyến khích bổ sung.
Về mặt triển khai trực tiếp các rollup dựa trên Ethereum cho đến nay, ví dụ rõ ràng nhất về điều này là Taiko, hoạt động khá khác so với mô tả ở trên. Nó cũng hoạt động theo cách khá khác so với giải pháp tích hợp hơn (trước endgame). Chúng tôi cung cấp tổng quan về cách Taiko hoạt động bên dưới:
Điều rất rõ ràng từ trạng thái hiện tại của Ethereum (và các chuỗi khối đơn khối khác) là có rất nhiều ứng dụng mong muốn tùy chỉnh, chuyên môn hóa và duy trì MEV trong khi vẫn đảm bảo tính bảo mật (và đồng bộ) của Ethereum. Trước đây, chúng tôi đã đề cập khá sâu về lý do thiết lập mô-đun trong các bài viết tại đây và tại đây cũng như hai bài thuyết trình gần đây mà chúng tôi đã thực hiện về lý do tại sao các nhà phát triển ứng dụng sẽ xây dựng mô-đun tại đây và tại đây .
Tích hợp sidecar MEV-Boost có thể sẽ trông giống như thế này, hãy nhớ rằng điều này yêu cầu các nhà xây dựng tích hợp với các rollup được hỗ trợ (trừ khi chúng ta chuyển thẳng sang thiết lập giống như rơle MEV-Boost, mặc dù điều này làm mất đi nhiều sức mạnh ở trên). Các nhà xây dựng có thể sẽ trở thành các thực thể ngày càng mạnh mẽ hơn, điều mà chúng ta sẽ tìm hiểu sau. Những người đề xuất cũng được yêu cầu lựa chọn tham gia (như họ hiện đang làm với MEV-Boost), mặc dù nếu lợi nhuận cao hơn cho những người đề xuất chạy một sidecar rollup dựa trên như vậy, thì những người khác cũng có khả năng tham gia (vì hầu hết đều tìm kiếm lợi nhuận).
Để xác nhận trước:
Tuy nhiên, vẫn chưa có quan điểm rõ ràng về cách thức triển khai đầy đủ (như trong tất cả các trình xác thực và trình xây dựng MEV-Boost tham gia), nhưng rất rõ ràng là những điều này sắp diễn ra và trước tiên chúng sẽ nằm ngoài giao thức cốt lõi.
Cũng có một mong muốn rõ ràng là hỗ trợ tốt hơn dựa trên các đợt rollup từ bên trong cộng đồng Ethereum cốt lõi. Ở đây chúng tôi đặc biệt đề cập đến việc muốn có tính cuối cùng của một khe cắm duy nhất nhưng cũng muốn có thời gian chặn nhanh hơn - điều này giúp ích nhiều hơn cho các đợt rollup dựa trên. Những điều này, giống như hầu hết các bản nâng cấp trên Ethereum - khá xa vời. Mặt khác, các cam kết xác nhận trước/người đề xuất đã được đưa vào sản xuất trên cả mạng chính và mạng thử nghiệm - mặc dù chúng đang gặp phải một số phản ứng dữ dội đáng kể từ các thành viên trong cộng đồng (một lần nữa, mối quan tâm về sự tập trung hóa - chúng ta sẽ tìm hiểu thêm về những điều này khi tiếp tục).
Ngoài ra còn có một số ý tưởng thú vị khác (để cung cấp xác nhận trước) sử dụng việc xây dựng khối một phần trong một phiên đấu giá MEV-Boost duy nhất, bằng cách chạy nhiều phiên đấu giá trong khoảng thời gian thông thường của một phiên. Trong Xác nhận trước dựa trên MEV-Boost nhiều vòng của Linoscope (Nethermind), ý tưởng là bạn có một số vòng nhanh hơn cố định trong phiên đấu giá MEV-Boost, nơi bạn xây dựng (và ký) một phần tải trọng (của một khối), việc ký này (từ người đề xuất) hoạt động như một xác nhận trước. Toàn bộ khối (với một phần tải trọng) sau đó được truyền bá như bình thường vào cuối khe bình thường. XGA ở trên cũng sử dụng các ý tưởng tương tự. Tuy nhiên, thay vì chia một phiên đấu giá thành nhiều phiên đấu giá hơn, họ chia không gian khối thành hai làn - ưu tiên và không ưu tiên. Điều này được thực hiện để cung cấp khả năng (mà không kích hoạt quá nhiều MEV) bán không gian khối trong tương lai ít bị rò rỉ hơn - nghĩa là trình xác thực sẽ bán quyền truy cập vào không gian khối không ưu tiên (để xác nhận trước).
Hãy nhớ rằng những thứ như cắt giảm, đăng ký và định giá được giữ lại để đơn giản hóa
Giao thức xác nhận trước, như được nêu trong sơ đồ ở trên, có thể tương tự như những gì nhóm Spire đề xuất trong Cổng xác nhận trước của họ; xem tại đây . Người đề xuất/người tiền hội nghị (có khả năng đã ủy quyền vai trò trình tự) được biết trước thông qua Ethereum proposaler lookahead. Trong trường hợp không có người tham gia sidecar đang hoạt động trong lookahead, một cuộn dựa trên có khả năng sử dụng cơ chế dự phòng để bầu một trình tự. Các trường hợp sử dụng khác cho cơ chế dự phòng ( h/t mteam ) cũng có thể là nếu một người tham gia trong sidecar preconf đã bị cắt (hoặc hết tài sản thế chấp)
Trong khi phần lớn những điều trên tập trung vào sự phức tạp của Ethereum và con đường của nó hướng tới việc cung cấp một nền tảng cho các rollup dựa trên tỏa sáng, thì cũng có những mạng khác có thể hỗ trợ chúng. Dưới đây, chúng tôi sẽ đề cập đến một số nơi có thể xây dựng các rollup dựa trên và các mạng được xây dựng cụ thể để hỗ trợ chúng.
Về mặt mạng lưới có thể hỗ trợ (và được xây dựng để hỗ trợ các rollup dựa trên), có khá nhiều. Đặc biệt đáng chú ý là các trình tự được chia sẻ, về cơ bản là các mạng lưới để sắp xếp các rollup (dựa trên):
Bộ sắp xếp chia sẻ
Châu Á
Cà phê espresso
Bán kính
Bộ nút
Các lớp dữ liệu khả dụng (có sự đồng thuận)
Cây thiên lý
Có sẵn
Monolith nhanh
Solana (hệ sinh thái lớn + các thuộc tính cho phép triển khai hiệu quả)
Tóm lại, các bản tổng hợp dựa trên:
Yêu cầu và Thuộc tính
Đối với Ethereum , các yêu cầu (để có UX phù hợp và đạt được các thuộc tính được nêu ở trên):
Không làm quá tải sự đồng thuận của Ethereum (do đó có phổ ở trên)
Người chạy nút đầy đủ không phải là người xây dựng + tiếp sức
Tích hợp vào đường ống xây dựng khối đang phát triển trong Jito
Không làm quá tải trình xác thực Solana (yêu cầu đã quá nặng)
Thời gian chặn nhanh hơn để có UX tốt hơn khi không có xác nhận trước
Tiêu chuẩn cho khả năng tương tác chéo dựa trên rollup (tốt nhất là nguyên tử)
ZK tính đến tốc độ tài sản lớp cơ sở (tốt nhất là kết hợp với việc chứng minh thời gian thực)
Có trình tự hay không có trình tự
Hứa với tôi, tôi chỉ cần sự xác nhận
Hơn nữa, như chúng ta cũng đã thấy, ít nhất là các khối trước nhanh hơn, cần phải có các xác nhận trước. Vẫn còn nhiều tranh luận về cách thức triển khai điều này, nhưng chắc chắn là đáng để xem xét ngay từ bây giờ. Để ôn lại, các xác nhận trước là các cam kết về việc đưa vào hoặc thực hiện trong tương lai do những người đề xuất hoặc các tác nhân được ủy quyền cung cấp, những người có khả năng khóa hoặc cung cấp quyền truy cập vào trạng thái tại các thời điểm được chỉ định. Trong các bản tổng hợp dựa trên, điều này rất quan trọng vì những người đề xuất có thể cung cấp đảm bảo rằng một khối tổng hợp cuối cùng sẽ được thực hiện/bao gồm. Rõ ràng là có khả năng sẽ có sự cắt giảm đáng kể các trái phiếu được áp đặt cho các tác nhân trong các chương trình như vậy để đảm bảo rằng các cam kết được tôn trọng. Đây là trong một thế giới lý tưởng trong giao thức vì ngoài giao thức sẽ quay trở lại việc cắt giảm xã hội của một nhóm nhỏ người thay vì sự đồng thuận xã hội của toàn bộ giao thức.
Đảm bảo bao gồm
Phân công thực hiện, xây dựng khối và sắp xếp trình tự
Đảm bảo rằng các khối/giao dịch sẽ được bao gồm trong một khối (nhưng không đảm bảo rằng chúng sẽ được thực hiện bởi các máy khách thực hiện) hoặc được sắp xếp theo thứ tự cụ thể
Không có khả năng đảm bảo khả năng kết hợp giữa các ứng dụng
Dễ định giá hơn
Sự hợp tác giữa trình sắp xếp bên ngoài (người xây dựng) và người đề xuất (các rơle có thể đóng vai trò thông thường, mặc dù căng thẳng ở đây cũng có khả năng xảy ra)
Đảm bảo thực hiện
Chứng minh tính hợp lệ hoặc thế chấp theo thời gian thực.
Đặt ra một áp lực lớn cho người đề xuất
Khó định giá hơn
Điều quan trọng nếu chúng ta xem xét rằng các bản tổng hợp dựa trên có thể đồng bộ chạm vào trạng thái Ethereum L1 - trong đó khả năng kết hợp ứng dụng yêu cầu đảm bảo thực hiện
Mặc dù việc sử dụng preconfirmation khá hạn chế tại thời điểm này, phạm vi rộng hơn thì cực kỳ rộng và có thể cung cấp một lớp cơ sở khá linh hoạt cho các cam kết của người đề xuất. Các thuộc tính hiện tại của các cam kết của người đề xuất (ngoài các sidecar preconfirmation/commitment) bị giới hạn ở các xác nhận trạng thái tại quá trình xây dựng khối (tức là cứ sau 12 giây). Tuy nhiên, đã có một số chương trình cam kết ngoài giao thức (như Chainbound) có thể cho phép người đề xuất đưa ra các cam kết cho những người khác về khối cụ thể của họ trong khi hỗ trợ thuộc tính tổng hợp dựa trên khóa trong các preconfirmation bao gồm. Như đã nêu ở trên, đây là điều mà chúng tôi cực kỳ mong muốn có. Nếu bạn quan tâm đến các preconfirmation ngoài giao thức, chúng tôi thực sự khuyên bạn nên xem bài nói chuyện này của nhóm Chainbound.
Cam kết của người đề xuất, vé và người chứng thực
Về các cam kết trong giao thức và quyền đề xuất khối, có một số đề xuất và triển khai đang được thảo luận, chẳng hạn như Cam kết của người đề xuất được thực thi theo giao thức (PEPC) và Phiếu thực hiện (ET) (+ tách biệt người chứng thực-người đề xuất (APS) ). ET đang nhận được sự chú ý đáng kể vì chúng sẽ cho phép có một thị trường trong giao thức (xổ số) để mua quyền đề xuất khối. Ý tưởng xung quanh APS là bạn chia các vai trò của trình xác thực L1 thành hai vai trò riêng biệt - một người thực hiện và một người đề xuất Beacon (đồng thuận). Người trước sẽ được giao nhiệm vụ đề xuất tải trọng khối (việc xây dựng này có thể được thuê ngoài cho những người xây dựng hoặc chúng tôi để những người xây dựng thực hiện phần này). Người sau (beacon hoặc người chứng thực) sẽ được giao nhiệm vụ bỏ phiếu cho các quy tắc hợp lệ của khối đã đặt (đặc biệt quan trọng với các khối tổng hợp dựa trên vì có khả năng sẽ có nhiều quy tắc hơn được phác thảo) và hạn chế quyền thực hiện thông qua danh sách bao gồm. Điều này có khả năng (đặc biệt là trong thế giới của những người xây dựng siêu hạng và mối quan tâm tập trung xung quanh các xác nhận trước và tổng hợp dựa trên) cung cấp khả năng chống kiểm duyệt cao hơn. Nếu bạn quan tâm đến lịch sử trước khi hội nghị ( hãy xem tại đây ).
Họ đang trở nên to lớn
Siêu Xây Dựng
Như bạn có thể đã nhận thấy trong suốt bài viết này, có rất nhiều sự ủy quyền và thuê ngoài công việc cho các bên chuyên biệt hơn nhằm mục đích tránh quá tải hoặc để đảm bảo hiệu quả thị trường tốt hơn. Điều này có nghĩa là, và những gì nó dẫn đến đã diễn ra trong một thời gian trên Ethereum - một con đường rõ ràng hướng đến việc đưa hầu hết công việc nặng nhọc vào tay những người xây dựng (các thực thể cực kỳ tinh vi). Điều này dẫn đến cái được gọi là "siêu xây dựng". Nhóm những người xây dựng hiện tại trong đường ống MEV-Boost có khả năng cũng sẽ đóng vai trò quan trọng trong cả giao thức (và bên ngoài) cho các đợt tổng hợp dựa trên, xác nhận trước và cam kết.
Lý do tại sao thì khá rõ ràng, chúng tôi không muốn làm quá tải sự đồng thuận của Ethereum. Chúng tôi không thể yêu cầu mọi người đề xuất đều phải chuyên môn hóa, và họ cũng không thể làm như vậy. Đó là lực lượng thị trường chung, nhưng nó dẫn đến sự tập trung hóa, và đi kèm với đó là nhiều rủi ro. Điều này đã có hiệu lực ngày hôm nay, với 3 nhà xây dựng đang xây dựng phần lớn các khối Ethereum ngày hôm nay (với hai trong số họ, Titan và Beaverbuild, xây dựng gần 80%!). Những người đề xuất ngày nay cũng có mối quan hệ cực kỳ đáng tin cậy với các rơle (hy vọng sẽ giảm bớt nhờ sự tiến bộ của ePBS, mặc dù điều này vẫn chưa rõ ràng)
Các nhà xây dựng có khả năng (trong trường hợp tổng hợp dựa trên) sẽ chạy các nút đầy đủ trên các tổng hợp để sắp xếp theo trình tự, đảm bảo thực hiện và lý do xây dựng khối. Đồng thời, họ cần có khả năng (trong trường hợp trước khi hội nghị) định giá các khối/gói này một cách chính xác (một số nhà xây dựng có thể thuê ngoài việc định giá trước khi hội nghị này cho những người tìm kiếm). Xác nhận trước về đảm bảo bao gồm dễ định giá hơn nhiều, trong khi đảm bảo thực hiện đòi hỏi sự tinh vi đáng kể và vẫn là một câu hỏi chưa có lời giải.
Về chủ đề rollup dựa trên, một super-builder thường có thể được coi là một tác nhân chuyên biệt không xây dựng cho một chuỗi duy nhất (Ethereum) mà là một nhóm trong số chúng (Ethereum+Rollups). Điều này là cần thiết, đặc biệt nếu chúng ta muốn đồng bộ hóa trong khối và khả năng tương tác rollup giữa các miền. Ở một mức độ nào đó, bạn cũng có thể xem trình sắp xếp/xây dựng Superchain của Optimism như một super-builder của các chuỗi OP-Stack. Cũng như các mạng trình sắp xếp phi tập trung của Astria/Espresso (nhưng nhiều đồng thời hơn, nếu không có người lãnh đạo duy nhất). Một khía cạnh thú vị của việc ủy quyền cho các builder là người giữ vé của nhiều rollup có thể cung cấp các đảm bảo bao gồm cho khả năng hợp nhất đồng bộ trên các miền này.
Thuật ngữ siêu xây dựng cũng có thể được dùng để chỉ các hoạt động ngoại khóa mà họ có thể tham gia bên ngoài nhiệm vụ ban đầu của mình (những yếu tố xây dựng!), chẳng hạn như cam kết và xác nhận trước.
Trong tất cả các trường hợp này, chúng ta có thể cần các trái phiếu (cổ phần) đáng kể cho các nhà xây dựng, đặc biệt là với khối lượng công việc ngày càng tăng được giao cho họ. Tốt nhất là nhiều chức năng trong số này được thuê ngoài cho họ cũng phải có thể chứng minh được trên chuỗi (trong giao thức) để đảm bảo việc cắt giảm công bằng, mạnh mẽ và chính xác. Điều này báo hiệu sự gia tăng trong việc mở rộng theo chiều ngang ở phía nhà xây dựng (mà Justin Drake đã nói một cách hời hợt rằng họ ổn với điều đó?). Có một số lo lắng ở đây, chẳng hạn như MEV nhiều khối, một nhà xây dựng xây dựng cho nhiều lần cuộn hơn tất cả những người khác (hoặc tốt hơn trong việc trích xuất MEV) và có thể trả giá cao hơn tất cả các nhà xây dựng khác một cách nhất quán. Sự tinh vi và tối ưu hóa hơn nữa này cũng sẽ dẫn đến sự tập trung hóa hơn nữa và rào cản gia nhập cao hơn đối với những người tham gia mới (trừ khi họ là Citadel). Một điều có vẻ khá rõ ràng là ít nhất Danh sách Bao gồm (IL) rất cần thiết trong một thế giới mà các nhà xây dựng được trao quyền nhiều hơn nữa.
Tất cả những điều này đều nằm ngoài thực tế là luồng lệnh ngày càng di chuyển ra khỏi chuỗi/hướng tới luồng lệnh riêng. Các nhà xây dựng có nhà cung cấp độc quyền (và những nhà xây dựng được tích hợp) hoạt động tốt hơn nhiều so với những nhà xây dựng không có nhà cung cấp độc quyền và một số ít nhà xây dựng này cũng có khả năng hưởng lợi nhiều nhất từ bất kỳ tích hợp rollup dựa trên nào. Điều này cũng có thể đáng lo ngại trong trường hợp một số ứng dụng (hoặc bot Telegram) có thể có rollup và cũng có luồng lệnh độc quyền hướng tới một nhà xây dựng. Burak Öz , Danning Sui , Thomas Thiery , Florian Matthes nêu bật những vấn đề này trong bài báo gần đây của họ Ai thắng trong các cuộc đấu giá xây dựng khối Ethereum và tại sao?, đặc biệt là xung quanh các vấn đề về rào cản gia nhập cao được trình bày ở trên.
Một lưu ý thú vị đối với việc tăng cường công việc này đặt lên những người xây dựng là về mặt phân phối lợi nhuận, họ (ít nhất là trên chuỗi) là những người nhận được ít nhất. Mặc dù vì hai trong số ba người xây dựng chính cũng là cửa hàng đạo cụ nên lợi nhuận của người tìm kiếm rõ ràng cũng nằm trong nhóm của họ. Ngay cả những người xây dựng không giao dịch cũng có khả năng có thỏa thuận với người tìm kiếm để chia sẻ doanh thu vì họ không giao dịch trên luồng của họ. Hiện tại, như Yuki (Sorella/Fenbushi) chỉ ra, lợi nhuận từ MEV đến không phải MEV được chia đều, có một lượng lớn lợi nhuận được giữ lại để nộp đơn, thường nằm trong tay người đề xuất.
Một điều mà nó làm rõ ràng là có một cơ hội lớn cho các ứng dụng (hoặc dự án) cho phép/có thể nắm bắt (tức là nội bộ hóa) MEV của chính họ/của người khác. Rõ ràng, trong thời đại ngày nay, với lượng hoạt động kinh tế trên chuỗi, điều đó có nghĩa là họ có thể cạnh tranh tốt hơn những người không thể. Những biên độ còn lại trên bàn là cơ hội cho các giao thức cho phép các ứng dụng trở nên tốt hơn và hiệu quả hơn.
Một ứng dụng sẽ xây dựng ứng dụng của mình trên một bản tổng hợp như thế nào?
Như đã đề cập trước đó, có khá nhiều lý do tại sao bạn nên xây dựng một ứng dụng dưới dạng một bản tổng hợp dựa trên—đặc biệt là nếu bạn đã cố thủ và triển khai trên lớp cơ bản. Hãy lấy một ví dụ về cách một ứng dụng có thể khởi chạy dưới dạng một bản tổng hợp dựa trên trong khi vẫn giữ các hợp đồng hiện có trên L1.
Trong trường hợp của Uniswap, bạn có thể để Uniswap Router hoạt động trong bản tổng hợp dựa trên và để các ứng dụng thực hiện cuộc gọi thông qua bản tổng hợp (có nghĩa là Uniswap sẽ có thể nội bộ hóa một phần luồng chạy qua chúng thông qua một cuộc đấu giá). Ví dụ, một giao thức ý định muốn chạm vào tính thanh khoản L1 của Uniswap sẽ phải thực hiện cuộc gọi thông qua bộ định tuyến trên bản tổng hợp dựa trên.
Nghiên cứu trong tương lai và suy nghĩ kết thúc
Trình tự giải trình tự không phụ thuộc vào thứ tự cho các ứng dụng cụ thể (ví dụ: xem bài viết về thứ tự của chúng tôi ) - không chỉ nội bộ hóa MEV mà còn cả các quy tắc giải trình tự có thể xác minh, đấu giá theo lô thường xuyên, thứ tự công bằng, v.v.
Quy tắc lựa chọn fork cụ thể (ví dụ: chỉ các khối hợp lệ nếu cập nhật giá của Oracle)
Tính hợp lệ của khối tối ưu (vượt quá mức phí cao nhất) có thể khá tùy ý (khác với => giá trị tối đa chẳng hạn)
Sự tinh vi của trình xây dựng khối và khả năng mở rộng theo chiều ngang cần được nghiên cứu thêm về mối nguy hiểm (+ mev đa khối, giá thầu khối); điều này thay đổi như thế nào với sự chuyên môn hóa về quy tắc lựa chọn nhánh/mã lệnh/giới hạn gas/VM.
Xây dựng khối một phần + Nhiều người đề xuất đồng thời
Hạn chế các trình xây dựng khối với Danh sách bao gồm trong và ngoài giao thức
Giá cho các nhà xây dựng không tích hợp nếu được ủy quyền cho (hoặc ủy quyền cho người tìm kiếm?)
Thanh toán cuộn cho orderflow
Xây dựng khối liên tục ( giống như Shreds trên Solana )
Trò chơi tính giờ và hiệu ứng (+ người kiểm tra bỏ phiếu sai )
Nếu ứng dụng của bạn hiện đang hoạt động trên một chuỗi đơn khối và bạn muốn khám phá cách bạn có thể bắt đầu tận dụng các khía cạnh của tính mô-đun (như chúng tôi đã đề cập nhiều lần trong năm qua) trong khi vẫn duy trì khả năng cấu hình và liên kết với lớp bên dưới, hãy liên hệ với chúng tôi.
Đọc thêm:
https://research.chainbound.io/examining-the-based-sequencing-spectrum
https://mteam.space/eth-sequencing-preconfs-resources/based_rollups.html
https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016
https://blog.20squares.xyz/preconfirmations-splitting-the-block/
https://mirror.xyz/preconf.eth/3SXageNPpcQMz8L2YfW5ipvthNl-InPzaPAfb3LxwqA
Cảm ơn Mathijs van Esch (Maven11) và mteam (Spire) đã đánh giá.
