Khi xem xét tầm nhìn và lộ trình của các giải pháp tổng hợp khác nhau, chúng ta sẽ thấy rằng hầu hết tất cả các giải pháp tổng hợp đều có một mục tiêu cuối cùng. Nếu mục tiêu này được cô đọng trong một câu: xây dựng kho công nghệ, cung cấp cho cộng đồng, giải quyết việc mở rộng chuỗi khối, và cuối cùng là sự phân cấp của nhóm công nghệ vận hành và quản trị. Điều này dẫn đến thuật ngữ rollup phi tập trung.
Vậy chính xác thì phi tập trung là gì? Sự phân công lao động giữa các bộ phận khác nhau của hệ thống Rollup là gì? Phân quyền có nghĩa là tối đa hóa người tham gia vận hành hệ thống? Máy phân loại tập trung sẽ có tác động gì? Trình đặt hàng được chia sẻ và sự đồng thuận cục bộ L2 nên được thiết kế như thế nào? Chức năng của câu tục ngữ độc đáo trong ZK-Rollup là gì? Một mạng lưới chứng thực phi tập trung mở sẽ trông như thế nào? Tại sao chúng ta cần tăng tốc phần cứng zk? Giải pháp cho vấn đề sẵn có dữ liệu là gì? ....
Có vô số cuộc thảo luận xung quanh Rollup phi tập trung trong cộng đồng, vì vậy ECN đã tuyển chọn một loạt các cuộc phỏng vấn podcast với chủ đề "Rollup phi tập trung" và mời những người sáng lập và nhà nghiên cứu xuất sắc trong lĩnh vực này nói về hiểu biết của họ về Rollup phi tập trung.
Khi ngày càng có nhiều thanh khoản đổ vào nền tảng Lớp 2, ngày càng có nhiều nhà cung cấp dịch vụ tổng số xuất hiện, không chỉ các giải pháp tổng số cho mục đích chung, chuỗi tổng số dành riêng cho ứng dụng mà còn cả các nền tảng tổng số như một dịch vụ. Do đó, ngày càng có nhiều người lo ngại rằng "trình sắp xếp thứ tự" có vai trò rất quan trọng trong hầu hết tất cả các bản tổng hợp vẫn được tập trung. Những rủi ro của một máy phân loại tập trung là gì? Là một máy phân loại phi tập trung một công việc cấp bách?
** Trong tập thứ hai, chúng tôi đã mời Yaoqi Jia, người sáng lập Mạng AltLayer, Toghrul Maharramov, nhà nghiên cứu của Scroll và Abdelhamid Bakhta, Trưởng nhóm khám phá Starknet, tiến hành một cuộc thảo luận bàn tròn về chủ đề máy phân loại phi tập trung, để khán giả và độc giả có thể hiểu được một số tiến bộ và tình huống khó xử hiện tại của máy phân loại phi tập trung. **
Khách trong vấn đề này:
Yaoqi Jia, người sáng lập AltLayer Network, twitter @jiayaoqi
Nhà nghiên cứu cuộn Toghrul Maharramov, twitter @toghrulmaharram
Vấn đề 4: Tính khả dụng của dữ liệu và lưu trữ phi tập trung
Qi Zhou, người sáng lập EthStorage
Nghe
Nhấp để đăng ký podcast để tìm hiểu thêm:
Youtube：
Thế giới vi mô:
dấu ấn thời gian
00:49 Yaoqi tự giới thiệu
01:37 Abdelhamid tự giới thiệu
02:50 Toghrul tự giới thiệu
04:03 Vai trò của máy phân loại trong rollup
08:37 Trình đặt hàng phi tập trung: Cải thiện trải nghiệm người dùng và giải quyết các vấn đề về tính sống động và kiểm duyệt
19:43Starknet sẽ phân cấp máy phân loại như thế nào
22:59 Scroll sẽ phân cấp bộ sắp xếp như thế nào
26:34 Sự khác biệt giữa đồng thuận L2 trong ngữ cảnh của Optimistic rollup và zkRollup
32:28 zkRollup phân cấp bộ sắp xếp cũng cần xem xét câu tục ngữ
36:01 Tổng số dựa trên cơ sở là gì?
40:53 Nhược điểm của trình sắp xếp theo thứ tự được chia sẻ và tổng số dựa trên và các tình huống ứng dụng của chúng
49:02 Người đặt hàng phi tập trung sẽ có tác động gì đối với MEV?
Giới thiệu khách mời
Diêu Khởi
Tôi là người sáng lập AltLayer. AltLayer đang xây dựng nền tảng "Rollup as a Service" nơi các nhà phát triển chỉ cần nhấp vào một số nút và định cấu hình tham số. Bằng cách sử dụng bảng khởi chạy hoặc bảng điều khiển của chúng tôi, họ có thể nhanh chóng khởi chạy các bản tổng hợp dành riêng cho ứng dụng trong vài phút. Vì vậy, đó là những gì chúng tôi đang cố gắng thực hiện bây giờ, để cung cấp cho các nhà phát triển một môi trường và chức năng thực thi chung. Chúng tôi cũng cung cấp nhiều bộ giải trình tự, nhiều hệ thống máy ảo và nhiều hệ thống bằng chứng khác nhau để các nhà phát triển lựa chọn.
Abdel Hamid
Tôi làm việc tại Starkware và tôi là trưởng nhóm thám hiểm. Mục tiêu của nhóm này về cơ bản là khởi chạy các dự án nguồn mở giống như nghiên cứu nhưng tập trung vào kỹ thuật. Mục tiêu của chúng tôi là làm việc trên các dự án nguồn mở với sự hợp tác chặt chẽ với cộng đồng và với những người từ các hệ sinh thái khác. Một dự án như vậy là Madara, thực chất là một bộ phân loại Starknet. Nó không chỉ là ứng cử viên cho mạng công cộng Starknet mà còn là trình sắp xếp chuỗi cho chuỗi ứng dụng Starknet và Lớp 3. Điều này cũng liên quan đến những gì vị khách trước đó đã nói, chúng tôi cũng đang nghĩ đến việc cung cấp tính năng tổng hợp như một chức năng dịch vụ, mọi người có thể triển khai chuỗi ứng dụng Starknet của họ và chọn các giải pháp khả dụng dữ liệu khác nhau theo cách hơi mô-đun. Trước đó, tôi đã làm việc với tư cách là nhà phát triển lõi Ethereum trong bốn năm, chịu trách nhiệm chính về công việc của EIP-1559.
Sự lựa chọn
Tôi là nhà nghiên cứu tại Scroll, và trách nhiệm chính của tôi tại Scroll là thiết kế giao thức, thiết kế cầu nối, phân cấp, khuyến khích, đại loại như vậy. Vì vậy, khi tôi không tweet xung quanh, hầu hết thời gian tôi chỉ nghiên cứu cách phân cấp giao thức hoặc trình đặt hàng, chứng minh, những thứ tương tự. Giống như Starkware, một trong những thứ chúng tôi đang nghiên cứu là SDK tổng hợp. Do đó, bạn có thể phát hành một tổng số dựa trên Scroll và sử dụng theo mô-đun các tùy chọn sẵn có của dữ liệu khác nhau, v.v. Chúng tôi vẫn đang xem xét một tùy chọn mà các bản tổng hợp dựa trên SDK Scroll có thể sử dụng trình sắp xếp của Scroll để giúp chúng đạt được sự phân cấp mà không yêu cầu mỗi bản tổng hợp phải tự xử lý việc phân cấp. Tất nhiên, kế hoạch vẫn chưa được hoàn thành. Tuy nhiên, đây cũng là hướng chúng tôi đang thực hiện.
Phần phỏng vấn
chủ đề một
Giải thích trình sắp xếp của cuộn lên?
Abdel Hamid
Bộ sắp xếp là một thành phần rất quan trọng trong kiến trúc layer2, thành phần này nhận các giao dịch từ người dùng, sau đó đóng gói và bó chúng thành các khối, thực hiện các giao dịch, v.v. Nó rất quan trọng vì đây là thành phần chịu trách nhiệm tạo khối, vì layer2 cũng là một chuỗi khối với các khối giao dịch. Người đặt hàng tạo ra các khối này và người chứng thực chứng thực các khối này.
Diêu Khởi
Như Abdel đã đề cập, trình đặt hàng là sự kết hợp của nhiều chức năng trong chuỗi khối. Vì vậy, chúng tôi thực sự có thể giao cho người đặt hàng quá nhiều trách nhiệm so với một chuỗi khối công khai điển hình. Trước tiên, nó cần tổng hợp tất cả các giao dịch từ người dùng, sau đó sắp xếp các giao dịch đó, dựa trên giá xăng hoặc trên cơ sở ai đến trước được phục vụ trước. Sau đó, trình sắp xếp thứ tự cần thực hiện các giao dịch này. Giống như bây giờ, một số Layer2 sử dụng EVM (Starware có một máy ảo khác), nhưng về cơ bản, trình sắp xếp chuỗi cần sử dụng một máy ảo chuyên dụng để thực hiện các giao dịch và tạo trạng thái. Sau đó, giao dịch đạt đến giai đoạn xác nhận trước, có nghĩa là nếu bạn thấy thời gian xác nhận là một hoặc hai giây hoặc thậm chí là dưới giây, thì về cơ bản, đó là trạng thái xác nhận trước được hoàn thành bởi trình sắp xếp thứ tự. Sau đó, đối với hầu hết các bộ sắp xếp, chúng cũng cần tải lên hoặc xuất bản các điểm kiểm tra hoặc hàm băm trạng thái lên L1. Đây là xác nhận ở cấp độ L1, mà chúng tôi gọi là tính khả dụng của dữ liệu. Vì vậy, bộ sắp xếp thực sự có nhiều vai trò trong hệ thống tổng số. Nhưng nói chung, tôi nghĩ đó là thành phần quan trọng nhất của hệ thống tổng số.
** Chủ đề 2 **
Tại sao máy phân loại phi tập trung lại quan trọng? Nếu chúng ta sử dụng máy phân loại tập trung, những nguy cơ tiềm ẩn đối với người dùng và hệ thống là gì?
Sự lựa chọn
Trước hết, chúng ta cần biết rằng ngoại trừ Fuel V1 ở giai đoạn hiện tại, không có bản giới thiệu thực sự nào, bởi vì các bản giới thiệu khác vẫn có bánh xe huấn luyện.
Tuy nhiên, chúng tôi có thể nói rằng một khi nó được phân loại là cuộn lên, điều đó có nghĩa là đa chữ ký bị xóa, v.v. Sau đó, vấn đề phân cấp máy sắp xếp trở thành vấn đề trải nghiệm người dùng, không phải vấn đề bảo mật. Vì vậy, khi mọi người nói về việc phi tập trung hóa L1, thì vấn đề lại hoàn toàn khác. Bởi vì L1 phải đảm bảo cho các khách hàng đặt hàng và ánh sáng. Vì vậy, nếu một ứng dụng khách nhẹ muốn xác minh rằng trạng thái là chính xác, thì nó phải tin tưởng vào trình xác thực L1. Đối với rollup, đây không phải là trường hợp. Bởi vì bộ sắp xếp chỉ cung cấp khả năng sắp xếp tạm thời, sau đó được hoàn thiện bởi L1. Và, bởi vì các bản tổng hợp cũng được đảm bảo chống lại sự kiểm duyệt, chúng tôi không cần phân cấp để thực hiện điều này.
Vì vậy, có một số lý do tại sao bạn cần một máy phân loại phi tập trung. Đầu tiên, nếu nói rằng quá trình hoàn tất L1 chậm (do bằng chứng hợp lệ đã gửi của bạn quá chậm hoặc do cơ chế giai đoạn thử thách của bằng chứng gian lận tổng số lạc quan), thì bạn phải dựa vào điều gì đó để đạt được xác nhận giao dịch nhanh. Ở giai đoạn xác nhận nhanh này, mặc dù bạn có thể tin tưởng rằng Starkware hoặc Scroll sẽ không lừa dối bạn, nhưng chúng chỉ ra rằng sau khi một khối được xác nhận, sẽ không có sự sắp xếp lại. Đây là một giả định về sự tin tưởng. Và phân cấp có thể thêm một số bảo đảm kinh tế, v.v.
Nhưng dựa trên điều này, tổng số cũng không có bảo đảm về thời gian thực. Về cơ bản, bạn có thể buộc đóng gói giao dịch thông qua L1, nhưng phải mất hàng giờ để đóng gói giao dịch đó. Vì vậy, ví dụ: nếu có một nhà tiên tri chịu trách nhiệm cập nhật và thời gian dao động, thì về cơ bản nếu nhà tiên tri được cập nhật trong một giờ trở lên, các ứng dụng trong danh sách sẽ không khả dụng. Về cơ bản, tính phi tập trung cho phép chúng tôi cung cấp một số đảm bảo chống kiểm duyệt theo thời gian thực mạnh mẽ hơn, bởi vì khi đó, kẻ thù sẽ cần phải thỏa hiệp không chỉ một thực thể hoặc một số thực thể, mà là toàn bộ mạng lưới người đặt hàng.
Vì vậy, đối với chúng tôi, phi tập trung hóa là một giải pháp để cải thiện trải nghiệm người dùng hoặc khắc phục trường hợp góc của các bản cập nhật tiên tri, v.v. Thay vì cung cấp các đảm bảo an ninh cơ bản, đây là điều mà L1 thực hiện.
Abdel Hamid
Vâng, câu hỏi về bộ sắp xếp phi tập trung mà bạn đã đề cập không hoàn toàn giống với L1 phi tập trung, điều mà tôi nghĩ là rất quan trọng. Bởi vì khi chúng tôi thấy một số L1 chỉ trích các máy phân loại tập trung, họ đã không xem xét chính xác những đánh đổi mà các máy phân loại tập trung tạo ra.
Trên cơ sở này, tôi muốn thêm một số thứ liên quan đến trải nghiệm người dùng, liên quan đến hoạt động. Bởi vì khi bạn chỉ có một máy phân loại duy nhất, bạn sẽ có nguy cơ máy phân loại gặp sự cố cao hơn. Do đó, một người đặt hàng phi tập trung cũng làm tăng khả năng phục hồi và sự sống động trên mạng. Nhưng ngay cả trong bối cảnh tập trung, chúng tôi có bảo mật tốt khi nói đến bảo mật. Bởi vì khi bạn có thể buộc các giao dịch gói thông qua L1, sự khác biệt giữa hai giao dịch này chỉ là dòng thời gian. Và việc có một bộ phân loại phi tập trung cho phép bạn có được các đảm bảo chống kiểm duyệt nhanh chóng, như Toghrul đã đề cập. Vì vậy, tôi chỉ muốn nói thêm rằng điều quan trọng đối với sự sống là phải có một mạng lưới người đặt hàng phi tập trung.
Diêu Khởi
Tôi muốn thêm một cái gì đó. Hoạt động có lẽ là điều quan trọng nhất chúng ta cần xem xét ở giai đoạn này. Các trường hợp airdrop gần đây nhất trên các L2 phổ biến nhất, chẳng hạn như Optimism và Arbitrum, đã có một khoảng thời gian ngừng hoạt động. Do đó, tôi nghĩ điều chúng ta cần giải quyết là làm thế nào để xử lý hàng nghìn yêu cầu giao dịch mỗi giây khi chúng ta chỉ có một bộ sắp xếp. Ngay cả về lý thuyết, nếu bạn chỉ có một nút, thì nó thực sự không thể xử lý nhiều yêu cầu như vậy cùng một lúc. Vì vậy, liên quan đến sự sống động, chúng tôi chắc chắn cần nhiều máy phân loại. Một điểm thất bại là một trở ngại thực sự, không chỉ đối với Web3, ngay cả Web2 cũng là một vấn đề lớn.
Ngoài ra, còn có vấn đề kiểm duyệt. Nếu chúng tôi chỉ có một điều phối viên, ngay cả khi chúng tôi thấy nó có thể được điều hành bởi nhóm, bạn vẫn cần chứng minh rằng nhóm sẽ không thực sự xem xét các giao dịch. Đôi khi các bên độc hại có thể và có khả năng đưa vào danh sách đen các giao dịch nhất định. Đó là một hệ thống đặt hàng phi tập trung, họ cũng có thể thử gửi giao dịch thông qua những người đặt hàng khác. Vì vậy, đó là lý do tại sao gần đây chúng tôi nhận được rất nhiều lời chỉ trích xung quanh các máy phân loại đơn lẻ.
Ngoài ra, có một số vấn đề khác như MEV và chạy sớm. Trong một hệ thống có bộ sắp xếp tập trung, đặc biệt là đối với các giao thức DeFi, họ có thể dễ dàng kiểm tra mempool. Có lẽ không phải ở dạng người đi trước, nhưng họ có cơ hội tốt hơn để theo dõi giao dịch và phân xử nó.
Rất nhiều vấn đề này, vì nhiều lý do, mặc dù chúng tôi thấy rằng L2 rất khác với L1. Nhưng cuối cùng, chúng ta vẫn cần làm cho nó trở nên phi tập trung nhất có thể. Vì vậy, chúng tôi phải đối mặt với một số vấn đề tương tự mà chúng tôi gặp phải với các chuỗi khối công khai hoặc L1.
Abdel Hamid
Vâng, tôi đồng ý rằng một máy phân loại phi tập trung là quan trọng. Nhưng tôi cũng muốn nói rằng, như chúng ta đều biết, đây không phải là một câu hỏi dễ.
Ngoài ra, **vì các bản tổng hợp có kiến trúc rất cụ thể, với nhiều thực thể. Chúng ta đang nói về một người đặt hàng duy nhất, nhưng cũng có một người chứng minh và chúng ta cần phân cấp cả hai. **Sẽ có một số sự đánh đổi và một số khó khăn trong cách định giá giao dịch vì cần có các yếu tố khác nhau để vận hành mạng. Vì vậy, làm thế nào để bạn định giá thỏa thuận? Máy phân loại và máy chuẩn có các yêu cầu phần cứng khác nhau, máy chuẩn cần một cỗ máy siêu mạnh, v.v. Do đó, định giá các giao dịch trong một thế giới phi tập trung cũng là một vấn đề rất khó khăn, đó là lý do tại sao chúng ta cần thời gian để từ từ tiến lên phía trước.
Vì vậy, tất cả chúng ta sẽ phải đối mặt với sự đánh đổi như vậy, nếu chúng ta muốn phân cấp nhanh chóng, chúng ta có thể cần phải mất một số bánh xe đào tạo và phân cấp dần dần, bởi vì nếu chúng ta trực tiếp muốn có một kiến trúc hoàn hảo, sẽ mất vài năm. Vì vậy, tôi nghĩ rằng chúng ta sẽ thực hiện một cách tiếp cận thực tế và cố gắng phân cấp dần dần. Ít nhất đó là kế hoạch hiện tại của chúng tôi, chẳng hạn như có thể bắt đầu với một cơ chế đồng thuận BFT đơn giản và sau đó thêm một cơ chế đồng thuận khác trong thời gian ngắn hoặc đại loại như vậy. Vì vậy, tôi chỉ muốn nói rằng, đó không phải là một câu hỏi dễ dàng. Bởi vì rõ ràng là có sự đánh đổi giữa tốc độ phát triển và mức độ áp dụng của kiến trúc đối với môi trường phi tập trung.
Chủ đề 3
Làm thế nào để phân cấp máy phân loại?
Abdel Hamid
Có nhiều tính năng mà chúng tôi muốn phân cấp và tất cả chúng đều có sự đánh đổi khác nhau.
Ví dụ: khi phân cấp, bạn muốn giới thiệu một số loại cơ chế đồng thuận. Tuy nhiên, trong cơ chế đồng thuận, có nhiều phần. Đầu tiên là bầu chọn người lãnh đạo, tức là cách chọn ai sẽ tạo khối, ai sẽ là người đặt hàng chịu trách nhiệm tạo khối trong một vị trí nhất định hoặc trong một thời gian nhất định. **Những gì nhóm Starknet dự định làm là tận dụng layer1 càng nhiều càng tốt. Điều đó có nghĩa là, trong thuật toán bầu chọn nhà lãnh đạo của chúng tôi, chúng tôi muốn đặt cược vào lớp 1. Ví dụ: chúng tôi có mã thông báo và cam kết sẽ diễn ra trên hợp đồng thông minh của lớp 1 Ethereum, được sử dụng để xác định cơ chế bầu chọn người lãnh đạo. **Điều này có nghĩa là chúng ta cần có một số tương tác trong đó người đặt hàng L2 sẽ truy vấn hợp đồng thông minh Ethereum để biết ai sẽ là người lãnh đạo tiếp theo hoặc điều gì đó tương tự. Vì vậy, rõ ràng là một số loại ngẫu nhiên và những thứ khác là cần thiết. Vì vậy, nó không phải là một câu hỏi đơn giản. Nhưng đó là phần đầu tiên. Sau đó, bạn cần phải có một cơ chế cho chính sự đồng thuận. Có nhiều tùy chọn: cơ chế chuỗi dài nhất hoặc BFT hoặc kết hợp cả hai. Giống như Ethereum, nó có LMG Ghost và Casper FFG về mặt tài chính.
Vì vậy, chúng tôi có thể thực hiện một cách tiếp cận thực tế và bắt đầu với BFT trước. Tại sao? Khi layer2 xem xét phân quyền, mục tiêu của chúng tôi không phải là có quy mô phân loại lớn như layer1. Ví dụ: trên Ethereum, mục tiêu là có hàng triệu trình xác thực tham gia. Trong trường hợp này, bạn không thể chỉ sử dụng cơ chế BFT, vì nó sẽ rất kém hiệu quả và sẽ gây ra những vấn đề rất lớn. Ví dụ: nếu có sự cố trên mạng Bitcoin, nếu đó là cơ chế BFT, chuỗi sẽ dừng hoàn toàn. Nhưng đây không phải là trường hợp, mạng Bitcoin tiếp tục tạo khối, chỉ có cơ chế cuối cùng bị tấn công.
Nhưng ở lớp 2, nếu mục tiêu là vài trăm đến 1000 máy phân loại, thì có thể tốt hơn nếu bắt đầu với cơ chế BFT. Như vậy là chúng ta đã có cơ chế bầu thủ lĩnh, rồi đến cơ chế đồng thuận, rồi còn hai phần nữa, nhưng tôi sẽ để dành cho các vị khách mời tiếp tục bổ sung. Nhưng hai phần còn lại là cập nhật trạng thái và tạo bằng chứng.
Sự lựa chọn
Đầu tiên, trong L2, phi tập trung hóa là một vấn đề nhiều mặt, như Abdel đã mô tả. Đặc biệt trong zkRollup, vì có prover và orderer nên bạn phải phối hợp giữa chúng, bạn phải phân quyền cho cả hai. Vấn đề này hoàn toàn khác với L1.
Một điểm khác biệt nữa là trong L2, tất cả thiết kế của bạn là để thuyết phục cây cầu cơ bản rằng sự đồng thuận là chính xác, chứ không phải để thuyết phục bất kỳ nút nào khác. Rõ ràng là bạn cũng nên làm như vậy, nhưng trọng tâm chính của bạn phải là chính cây cầu.
Hiện tại, chúng tôi đang làm việc theo hai hướng khác nhau. Thứ nhất, tôi nghĩ, giống như những người khác, chúng tôi đang làm việc trên một giao thức BFT. Điều này không hiệu quả lắm và có một số nút thắt cần được giải quyết. Chúng tôi đã đưa ra một giải pháp sơ bộ, nhưng nó vẫn chưa tối ưu. Ví dụ, một trong những câu hỏi là, làm thế nào để bạn cân bằng các ưu đãi giữa người sắp xếp và người chứng minh? Bởi vì người đặt hàng kiểm soát MEV và người chứng minh không có quyền truy cập vào MEV, nên có động cơ khuyến khích mọi người chạy người đặt hàng thay vì người chứng minh. Nhưng trên thực tế, chúng ta cần nhiều người chứng minh hơn là người đặt hàng, vậy làm thế nào để bạn cân bằng các ưu đãi giữa hai bên? Đây là một trong những vấn đề đó.
Giải pháp thứ hai mà chúng tôi đang thực hiện là một hướng đi khác. Hãy nhớ rằng, mọi thứ có thể thay đổi. Đề xuất mới xuất hiện mỗi ngày. Ví dụ: gần đây đã có nhiều cuộc thảo luận về tổng số dựa trên cơ sở và cách bạn có thể thuê ngoài hoàn toàn việc phân loại cho L1. Hướng thứ hai về cơ bản là loại bỏ hoàn toàn bộ sắp xếp và sử dụng một số trình tạo bên ngoài. Ví dụ: các nhà xây dựng ethereum hoặc Flashbots SUAVE, v.v. đề xuất các khối được sắp xếp theo thứ tự và sau đó chạy sự đồng thuận bên trong chứng minh. Ưu điểm ở đây là bạn không phải xử lý các ưu đãi vì về cơ bản, bạn có thể sử dụng PBS bên trong giao thức và nó tạo ra một giao thức đơn giản hơn. Nhưng nhược điểm là vì chúng tôi cần một số lượng lớn người chứng minh (vì chúng tôi có thể chứng minh song song), nên rất khó để chạy một giao thức BFT cổ điển với họ. Vì vậy, câu hỏi đặt ra là làm thế nào để bạn tối ưu hóa một giao thức BFT hiện có để chạy với hàng trăm, thậm chí hàng nghìn chứng minh? Và đó không phải là một câu hỏi dễ trả lời.
Việc giới thiệu sự đồng thuận L2 có cần thiết cho một người đặt hàng phi tập trung không?
Diêu Khởi
Tôi có thể trả lời đại khái câu hỏi này bởi vì chúng tôi vừa mới triển khai một sản phẩm tương tự.
Vì vậy, việc đưa ra sự đồng thuận hay không không phụ thuộc vào việc chúng ta có muốn hay không. Một khi bạn có nhiều người đặt hàng hoặc thậm chí chỉ là các nút, bạn phải khiến họ đồng ý. Nó thực sự phụ thuộc vào các giả định của bạn. Nếu đó là giả định của Byzantine, chúng tôi có thể sử dụng BFT hoặc bất kỳ giao thức đồng thuận Byzantine hiện có nào. Ví dụ: nếu đó là một thiết lập không phải của Byzantine, nếu chúng tôi chỉ cho rằng một nút chỉ có thể trực tuyến và ngoại tuyến và nút đó không thể hành động ác ý, thì chúng tôi có thể sử dụng giao thức Raft hoặc một số giao thức đồng thuận nhanh hơn khác. Nhưng dù sao đi nữa, nếu chúng ta có một nhóm người đặt hàng hoặc người chứng minh, nếu chúng ta muốn tổ chức họ lại với nhau để tạo ra các khối trong một khoảng thời gian, thì bạn phải có một giao thức đồng thuận xung quanh họ.
Vì vậy, như Toghrul và Abdel vừa đề cập, tôi tin rằng có rất nhiều đề xuất và chủ đề nghiên cứu về cách chúng ta có thể đạt được một hệ thống chứng minh hoặc đặt hàng phi tập trung. Vì vậy, vì chúng tôi vừa ra mắt mạng thử nghiệm cho hệ thống tổng số đa phân loại (hiện chỉ hỗ trợ bằng chứng gian lận cho tổng số Lạc quan), dựa trên kinh nghiệm thiết kế và triển khai của chúng tôi, tôi có thể chia sẻ một số điều về những khó khăn. Như Toghrul vừa đề cập, khó khăn không nằm ở bản thân giao thức đồng thuận, mà khó khăn thực sự nằm ở những thứ khác ngoài điều này, chẳng hạn như phần bằng chứng. Bởi vì nếu đó là một bộ sắp xếp đơn lẻ, bạn không cần nhiều nút. Chúng ta có thể coi nó như một EVM, một máy ảo. Vì vậy, chỉ cần tìm nạp các giao dịch và thực hiện, thực hiện chuyển đổi trạng thái. Prover chịu trách nhiệm tạo ra bằng chứng cho sự chuyển đổi trạng thái của tập hợp các giao dịch trước đó. Tuy nhiên, nếu chúng tôi chạy giao thức đồng thuận cho trình đối chiếu và trình chứng thực trong bản cập nhật, thì chúng tôi cần giới thiệu logic đồng thuận bổ sung ở đó. Trên hết, bạn cũng cần một hệ thống bằng chứng cho giao thức đồng thuận. Do đó, điều này sẽ giới thiệu rất nhiều công việc cho hệ thống bằng chứng để tạo ra. Sau đó, khi bạn tạo bằng chứng, bạn có thể dễ dàng xác minh nó trên L1 Ethereum.
Vì vậy, đó là lý do tại sao theo một cách nào đó, khi chúng tôi khởi chạy mạng thử nghiệm nhiều đơn đặt hàng đầu tiên, bản tổng hợp lạc quan có một số lợi thế về mặt đó. Nói chung, bạn có thể đơn giản hóa rất nhiều thứ, chẳng hạn như không xem xét phần chứng minh tính hợp lệ. Giống như chúng tôi, về cơ bản chúng tôi so sánh mọi thứ với WASM. Vì vậy, cuối cùng, đó là hướng dẫn WASM. Vì vậy, bằng cách xác minh các hướng dẫn WASM này, việc xác minh bằng mã Solidity tương đối dễ dàng. Nếu chúng tôi vừa triển khai lại tất cả các diễn giải hướng dẫn WASM trên Ethereum.
Nhưng nói chung, vấn đề không phải là cá biệt. Nếu chúng ta có một giải pháp cho vấn đề, tương ứng, sẽ có một số công việc tiếp theo khác cần được giải quyết cùng một lúc. Tất nhiên, sẽ có các vấn đề về MEV, chẳng hạn như cách chúng tôi phân phối MEV một cách công bằng. Bạn có thể chỉ định tất cả người đặt hàng và người chứng minh dựa trên việc họ đã tạo khối hay xác thực khối. Nhưng cuối cùng, nó thực sự là sự kết hợp của nhiều vấn đề, không chỉ là vấn đề kỹ thuật mà còn cả các động lực kinh tế.
Và chúng ta cần nhớ rằng L2 được đề xuất vì chúng ta muốn giảm đáng kể chi phí gas. Vì vậy, chúng tôi không thể có quá nhiều nút. Ngay cả khi tạo bằng chứng, L2 có thể đắt hơn L1. Vì vậy, chúng ta thực sự cần đưa ra một cách tiếp cận cân bằng cho loại vấn đề này.
Abdel Hamid
Tôi muốn thêm một điểm nữa. Đầu tiên, hiện tại không có bằng chứng gian lận thực sự không được phép đối với các bản tổng hợp lạc quan. Và tôi tiếp tục nhấn mạnh điều này mỗi khi có cơ hội, bởi vì điều quan trọng là phải trung thực về điều này khi so sánh. Vì vậy, chúng hoàn toàn không phải là L2. Đó là điều đầu tiên.
Sau đó, tôi muốn thêm một số điều về sự không đồng bộ giữa phân loại và bằng chứng, bởi vì nó rất quan trọng. Như bạn đã nói, chúng tôi muốn tối ưu hóa việc sắp xếp, bởi vì hiện tại đây là nút cổ chai cho tất cả các giải pháp. Nhưng điều đó tốt trong bối cảnh sắp xếp tập trung, bởi vì chúng tôi biết bộ sắp xếp sẽ chỉ tạo ra các chuyển đổi giá trị và chúng tôi sẽ có thể xác minh chúng. Nhưng sẽ khó hơn trong bối cảnh sắp xếp phi tập trung, bởi vì có thể máy sắp xếp của bạn sẽ có thể tạo ra thứ gì đó không thể xác minh được. Sau đó, bạn sẽ cần phải đối phó với điều đó sau.
Trong bối cảnh sắp xếp tập trung, để tối ưu hóa việc sắp xếp, vì chúng tôi không phải tạo bằng chứng trong quá trình sắp xếp, chúng tôi có thể thử thực hiện ở tốc độ cục bộ, đó là điều chúng tôi muốn làm. Dịch Cairo sang ngôn ngữ máy cấp thấp như LLVM và chạy siêu nhanh trên bộ sắp xếp. Sau đó, bạn có thể chứng minh không đồng bộ. Và điều thú vị nhất về bằng chứng là bạn có thể thực hiện chúng song song. Khả năng song song lớn đạt được bằng cách chứng minh rằng đệ quy là có thể. Đó là lý do tại sao chúng ta sẽ có thể bắt kịp tốc độ của máy phân loại. Nhưng rất khó khi phân cấp, vì chúng ta cần đảm bảo rằng người đặt hàng chỉ tạo ra các chuyển đổi trạng thái hợp lệ.
Sự lựa chọn
Tôi sẽ nói thêm rằng tôi không chắc Starknet đang làm gì ở đây. Nhưng đối với chúng tôi, tôi đoán rằng giả định chung của mọi zkRollup là nếu bạn phân cấp bộ sắp xếp, hệ thống bằng chứng của bạn phải có khả năng xử lý các lô không hợp lệ. Vì vậy, về cơ bản, giả sử, nếu bạn gửi một lô có chữ ký không hợp lệ, thì bạn phải có khả năng chứng minh rằng trạng thái kết quả tương đương với trạng thái bắt đầu. Vì vậy, sẽ có một số chi phí cả hai cách. Đó là về cách bạn giảm thiểu xác suất xảy ra điều này.
Abdel Hamid
Vâng đúng vậy. Đó là lý do tại sao chúng tôi giới thiệu Sierra ở Cairo 1 để làm cho mọi thứ có thể kiểm chứng được. Đại diện trung gian này sẽ đảm bảo rằng mọi chương trình Cairo 1 đều có thể xác minh được để chúng tôi có thể đưa vào giao dịch hoàn nguyên.
Tổng số dựa trên là gì?
Diêu Khởi
Bản tổng hợp dựa trên ban đầu đến từ một bài đăng trên blog của Justin Drake trên các diễn đàn Ethereum. Một trong những ý tưởng của anh ấy là chúng tôi có thể sử dụng lại một số trình xác minh Ethereum để xác minh các giao dịch tổng số, do đó chúng tôi không cần một nhóm nút riêng biệt để xác minh các giao dịch tổng số khác nhau. Đặc biệt, chúng tôi sẽ có nhiều bản tổng hợp trong tương lai, bao gồm cả bản tổng hợp cho mục đích chung và nhiều bản tổng hợp dành riêng cho ứng dụng. Vì vậy, trong trường hợp này, sẽ thật tuyệt nếu chúng ta có thể tìm thấy một nơi chung như nhóm trình xác thực Ethereum để xác thực các giao dịch này.
Tất nhiên, đây chỉ là một ý tưởng, vì nó cũng gây ra rất nhiều khó khăn về kỹ thuật. Ví dụ: về lý thuyết, chúng tôi có thể yêu cầu trình xác thực Ethereum xác minh các giao dịch tổng số, nhưng rất khó để có được logic xác minh các bản tổng số được gói hoặc nhúng vào chính giao thức Ethereum. Chúng tôi gọi đây là xác minh trong giao thức, yêu cầu một nhánh cứng của các nút Ethereum. Tất nhiên, trong trường hợp này, chúng tôi có thể xác minh một số giao dịch tổng số. Nhưng nếu chúng tôi làm, bạn sẽ thấy vấn đề. Có vẻ như chúng tôi muốn bản tổng hợp của L2 chia sẻ áp lực của Ethereum, nhưng cuối cùng, chúng tôi vẫn yêu cầu những người xác thực Ethereum đảm nhận một số công việc đã giảm tải cho L2. Vì vậy, rất nhiều người nói về cách chúng ta có thể làm điều này.
Sau đó, chúng tôi đã nói chuyện với Barnabe, một nhà nghiên cứu tại Ethereum Foundation hiện đang làm việc trên PBS. Đây là một đề xuất của Ethereum, nhằm phân chia nhiệm vụ của trình xác nhận thành nhiều vai trò, người xây dựng và người đề xuất. Bây giờ chúng ta có Flashbots để đảm nhận vai trò của người xây dựng trong PBS, họ soạn tất cả các khối và gửi chúng cho những người đề xuất Ethereum. Vì vậy, một khi các khối này được đóng gói vào mạng Ethereum, những người xây dựng cũng sẽ nhận được một số phần thưởng. Sau đó, trong trường hợp này, làm cách nào để thưởng cho những người xác thực này từ mạng Ethereum? Họ cũng chịu trách nhiệm xác thực tổng số.
Một trong những giải pháp là "retaking", mà có thể bạn đã nghe nhiều từ EigenLayer hoặc một số giao thức khác. Người dùng có thể đặt lại ETH trên các mạng phân loại khác. Hoặc thưởng cho trình xác thực Ethereum vì đã thực sự chạy phần mềm để thực hiện công việc xác thực cho bản tổng hợp. Trong trường hợp này, họ có thể được thưởng cả từ L2 và thông qua giao thức đặt cược lại. Cho đến nay đã có nhiều đề xuất cho điều này, nhưng nói chung đó là ý tưởng về cách có thể tái sử dụng các trình xác thực Ethereum hiện có. Làm cách nào chúng tôi có thể tái sử dụng ETH hiện có để giúp mở ra một kỷ nguyên mới của hệ thống tổng số hoặc hệ thống L2? Vì vậy, về cơ bản, nó đang cố gắng đơn giản hóa rất nhiều thứ cho dự án tổng số. Nếu một tổng số muốn một số bộ sắp xếp mới, nếu họ muốn một số nguồn tài sản thế chấp mới, họ có thể sử dụng lại cơ sở hạ tầng hiện có hoặc tài sản thế chấp hiện có. Vì vậy, đó là lý do tại sao nó được xây dựng dựa trên Ethereum, sau đó cơ sở hạ tầng và đặt cược bổ sung có thể được sử dụng lại cho rollup và cả L2.
Nhược điểm của trình sắp xếp thứ tự được chia sẻ và tổng số dựa trên cũng như các tình huống ứng dụng của chúng.
Sự lựa chọn
Tôi muốn khiếu nại về đề xuất này, tôi không bị thuyết phục bởi đề xuất liên quan đến trình sắp xếp thứ tự được chia sẻ. Tất nhiên, chúng vẫn còn sơ khai và nếu những thiết kế này được cải thiện trong tương lai, tôi hoàn toàn có thể ủng hộ chúng. Chỉ là phong độ hiện tại không thuyết phục được tôi. Có nhiều lý do.
Đầu tiên, đối với tôi, đề xuất giá trị chính của bộ sắp xếp dùng chung là cho phép người dùng có được khả năng kết hợp nguyên tử giữa các bản tổng hợp có mục đích chung như Scroll hoặc Starknet. Nhưng vấn đề là nếu bạn có khả năng tổng hợp nguyên tử, thì bản tổng hợp của bạn sẽ là bản cuối cùng giống như bản tổng hợp chậm nhất mà bạn kết hợp. Vì vậy, giả sử Scroll được kết hợp với Optimistic Rollup, thời hạn cuối cùng của Scroll sẽ là bảy ngày. Mặc dù đề xuất giá trị chính của ZKRollup là đạt được kết quả cuối cùng tương đối nhanh, nhưng người dùng có thể rút về L1 trong vòng vài phút. Và trong trường hợp này, về cơ bản hãy từ bỏ điều đó.
Một nhược điểm khác là nếu bạn muốn tính hữu hạn ngoài chuỗi, bạn cần chạy một nút L2 và miễn là dữ liệu được gửi tới chuỗi được hoàn thiện bởi L1, bạn sẽ có được tính hữu hạn cục bộ trong L2. Nếu mỗi L2 kết hợp không chạy một nút đầy đủ, thì thực tế là không thể hoàn thành cục bộ. Điều này có nghĩa là việc chạy hệ thống này có thể tốn kém hơn so với việc chạy một hệ thống như Solana, bởi vì bạn có nhiều nút đầy đủ chạy cùng lúc, với chi phí hoạt động riêng, v.v.
Vì vậy, vì những lý do đó, tôi không nghĩ nó có ý nghĩa đối với L2. Nó hơi khác một chút đối với L3, bởi vì nếu ai đó muốn xây dựng một chuỗi dành riêng cho ứng dụng và không muốn giải quyết vấn đề phân quyền. Giả sử tôi đang xây dựng một trò chơi và tôi chỉ muốn xử lý việc xây dựng trò chơi, sau đó tôi có thể thuê ngoài công việc phi tập trung. Nhưng tôi không nghĩ nó có ý nghĩa với L2 vào lúc này.
Đối với tổng số dựa trên, tôi cũng có mối quan tâm của mình. Ví dụ: làm thế nào để bạn chia sẻ lợi nhuận MEV với người chứng minh? Bởi vì nếu vấn đề phân bổ không được xem xét, về cơ bản L1 có thể thu được tất cả lợi nhuận MEV. Một điều nhỏ nữa là thời gian xác nhận của nó bằng với thời gian xác nhận của L1 là 12 phút, không thể nhanh hơn. Một vấn đề khác là vì nó không được phép, nhiều Người tìm kiếm có thể gửi các lô giao dịch cùng một lúc, điều đó có nghĩa là nó có thể dẫn đến kết quả tập trung. Bởi vì các nhà xây dựng được khuyến khích bao gồm các giao dịch của họ nếu một người tìm kiếm kết nối dễ dàng hơn những người khác. Do đó, cuối cùng có thể chỉ có một Người tìm kiếm đề xuất các lô cho L2, đây không phải là một giải pháp tốt, bởi vì nếu điều này xảy ra, về cơ bản, chúng tôi sẽ quay lại hình vuông.
Diêu Khởi
Thật thú vị, tôi vừa có một cuộc gọi với Ben, người sáng lập Espresso, vào tuần trước. Chúng tôi thảo luận về điều này rất nhiều trong chủ đề của bộ sắp xếp được chia sẻ. Như Toghrul đã đề cập, tôi nghĩ rằng có một số điều không chắc chắn về các tình huống sử dụng đối với hệ thống đặt hàng dùng chung. Điều này chủ yếu là do đối với L2 có mục đích chung, chúng tôi thường không có nhiều máy phân loại do tính hiệu quả, độ phức tạp và tính kinh tế. Và tôi vẫn cảm thấy rằng cho dù đó là trình sắp xếp thứ tự được chia sẻ, tổng số dựa trên hoặc khôi phục lại, thì trường hợp sử dụng tốt nhất chủ yếu là dành cho RAS (Rollup as a Service) hoặc các nền tảng như vậy mà chúng tôi có thể triển khai nhiều bản tổng hợp. Thành thật mà nói, chúng tôi không thực sự cần một mạng phân loại lớn nếu không có nhiều bản tổng hợp. Các tổng số này đã có hệ thống sắp xếp riêng và đã có cộng đồng hoặc đối tác riêng, khi chỉ có một số L2 chung. Họ không thực sự cần phải có một mạng bên thứ ba và riêng biệt. Ngoài ra, đây là một gánh nặng đối với mạng của bên thứ ba, vì bạn phải tùy chỉnh cho từng L2 và mỗi L2 có một ngăn xếp thử nghiệm khác nhau. Điều này đòi hỏi rất nhiều thay đổi đối với mạng của riêng bạn.
Nhưng đồng thời, như Toghrul đã đề cập, đối với một số trường hợp sử dụng đặc biệt. Ví dụ: nếu chúng tôi muốn có một số khả năng tương tác ở cấp bộ sắp xếp, thì bộ sắp xếp dùng chung có thể là một cách khả thi. Ví dụ: cùng một bộ sắp xếp được sử dụng cho nhiều lần tổng số. Trong trường hợp này, bộ sắp xếp này về cơ bản có thể xử lý một số giao dịch tổng số chéo để đảm bảo tính nguyên tử của chuỗi chéo giữa tổng số A, B và C.
Nhưng bạn cũng có thể thấy vấn đề ở đây khi tôi mô tả tình huống. Nếu chúng ta thực sự có nhiều trình sắp xếp chung này, chúng sẽ lại trở thành nút cổ chai và một điểm thất bại mới. Chúng ta đang trao quá nhiều quyền lực cho những người được gọi là người đặt hàng chung này. Chúng đang trở nên giống một mạng lưới hơn, kiểm soát nhiều bản tổng hợp. Cuối cùng, một lần nữa chúng ta cần nghĩ ra một cách để phân cấp bộ sắp xếp dùng chung này.
Nhưng dù sao đi nữa, tôi nghĩ thật tốt khi mọi người đang dần dần phát hiện ra nhiều vấn đề hơn và ngày càng đưa ra nhiều giải pháp hơn. Nói chung, thật thú vị khi thấy những gì mới trong lĩnh vực này mỗi ngày. Với tất cả các giải pháp mới này, ít nhất chúng tôi đang đi đúng hướng để thực sự phi tập trung hóa toàn bộ không gian tổng số.
Abdel
Vâng, tôi đồng ý với cả hai bạn. Tôi nghĩ điều đó hợp lý hơn đối với Layer3 và Lisk vì họ không muốn nhận trách nhiệm khuyến khích mạng phi tập trung nữa và cần tìm đối tác để bắt đầu những thứ như máy phân loại. Vì vậy, tôi nghĩ đối với Lisk, nó có ý nghĩa. Nhưng giống như Toghrul, tôi không nghĩ nó có nhiều ý nghĩa đối với Layer2.
Chủ đề 4
Người đặt hàng phi tập trung sẽ có tác động gì đối với MEV?
Abdel
Đối với Starknet, trong bối cảnh tập trung hóa, chúng tôi không thực hiện bất kỳ loại MEV nào và chúng tôi áp dụng mô hình ai đến trước được phục vụ trước. Điều đó có nghĩa là, trong bối cảnh phi tập trung hóa, tất nhiên, sẽ có nhiều MEV hơn được đưa vào sau này. Nhưng còn quá sớm để nói tỷ lệ nào, vì nó còn phụ thuộc vào thiết kế của cơ chế đồng thuận và các khía cạnh khác.
Sự lựa chọn
Nhưng vấn đề là, ngay cả khi bạn không thực hiện MEV, vẫn có thể có một số MEV vẫn xảy ra trong Starknet. Bản thân việc phân cấp không thực sự làm giảm MEV hay tăng MEV. Tất nhiên, nếu bạn áp dụng một số loại giao thức đặt hàng hợp lý hoặc mã hóa ngưỡng chẳng hạn, thì vâng, bạn giảm thiểu MEV. Nhưng bạn không thể loại bỏ nó hoàn toàn. Triết lý của tôi là: MEV không thể bị loại bỏ. Nhưng giả sử bạn chỉ đang tạo sự đồng thuận BFT hoặc xây dựng thứ gì đó dựa trên sự đồng thuận BFT. Điều này thực sự không ảnh hưởng đến MEV. MEV vẫn tồn tại, vấn đề là cách người tìm kiếm làm việc với bộ sắp xếp để trích xuất MEV đó.
Diêu Khởi
Vấn đề là, ngay cả mô hình ai đến trước được phục vụ trước cũng có những phần phức tạp. Sau khi chúng tôi hiển thị mempool cho một số người tìm kiếm, họ vẫn có lợi thế để chơi nhiều hơn. Ví dụ, đối với trình tự, chúng tương đương với việc đợi ở cửa văn phòng của bạn. Vì vậy, trong trường hợp này, một khi họ nhìn thấy một loại cơ hội chênh lệch giá nào đó, không chỉ về tấn công chạy trước hoặc tấn công kiểu bánh sandwich, ngay khi người dùng gửi một giao dịch, họ có thể thấy ngay giao dịch đó trong mempool. Vì vậy, họ có thể nhanh chóng đặt giao dịch của mình trước những người khác. Vì vậy, họ có lợi thế hơn những người tìm kiếm khác.
Nhưng quay trở lại vấn đề phân cấp, tôi nghĩ chủ yếu là về khả năng chống kiểm duyệt, như chúng ta đã thảo luận lúc đầu. Trình tự được quản lý bởi nhóm. Nhóm có thể nói rằng họ đang công bằng với mọi người. Nhưng điều này không bị ngăn chặn trong mã. Vì vậy, nếu chúng tôi có thể có mạng P2P, sẽ thật tuyệt nếu chúng tôi cảm thấy các nút này kiểm tra các giao dịch của tôi và sau đó chúng tôi có thể gửi đến các nút khác. Vì vậy, đó thực sự là về tính công bằng của việc xử lý các giao dịch tại L2.
Đối với MEV, bởi vì gần đây, ngoài các MEV được tạo trong một lần tổng hợp, còn có một số MEV được tạo qua các cầu nối. Trong mạng phân loại tương đối phi tập trung này, bạn sẽ có nhiều cơ hội hơn để trích xuất MEV. Giả sử chúng ta có một mạng đặt hàng dùng chung, nếu bạn có thể bằng cách nào đó tác động đến người đặt hàng dùng chung để sắp xếp lại các giao dịch, thì về cơ bản, bạn có lợi thế lớn so với những người khác.
Có những ưu điểm và nhược điểm đối với mạng trình sắp xếp chung. Về mặt tích cực, chúng ta có thể phân cấp hơn nữa hệ thống xếp hạng. Nhưng mặt khác, mọi người đều có cơ hội trở thành người phân loại. Vì vậy, về cơ bản họ có thể làm bất cứ điều gì họ muốn, và đó lại là một khu rừng tối. Vì vậy, chúng tôi đã giới thiệu tính năng phân quyền và sau đó chúng tôi phải đối mặt với những vấn đề tương tự mà chúng tôi gặp phải trong Ethereum. Đó là lý do tại sao các thành viên của Flashbots và Ethereum Foundation muốn tiếp tục với PBS, tách biệt người đề xuất và người xây dựng, sau đó cố gắng có một giải pháp duy nhất về phía người xây dựng.
Vì vậy, khi chúng ta xem xét vấn đề, nó không chỉ là một vấn đề đơn lẻ. Nó không còn là vấn đề một đối một, mà là một đối sáu, và hơn thế nữa.
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Đối thoại với các nhóm AltLayer, Scroll, Starknet: Shared Sequencer và L2 Consensus
Giới thiệu
Khi xem xét tầm nhìn và lộ trình của các giải pháp tổng hợp khác nhau, chúng ta sẽ thấy rằng hầu hết tất cả các giải pháp tổng hợp đều có một mục tiêu cuối cùng. Nếu mục tiêu này được cô đọng trong một câu: xây dựng kho công nghệ, cung cấp cho cộng đồng, giải quyết việc mở rộng chuỗi khối, và cuối cùng là sự phân cấp của nhóm công nghệ vận hành và quản trị. Điều này dẫn đến thuật ngữ rollup phi tập trung.
Vậy chính xác thì phi tập trung là gì? Sự phân công lao động giữa các bộ phận khác nhau của hệ thống Rollup là gì? Phân quyền có nghĩa là tối đa hóa người tham gia vận hành hệ thống? Máy phân loại tập trung sẽ có tác động gì? Trình đặt hàng được chia sẻ và sự đồng thuận cục bộ L2 nên được thiết kế như thế nào? Chức năng của câu tục ngữ độc đáo trong ZK-Rollup là gì? Một mạng lưới chứng thực phi tập trung mở sẽ trông như thế nào? Tại sao chúng ta cần tăng tốc phần cứng zk? Giải pháp cho vấn đề sẵn có dữ liệu là gì? ....
Có vô số cuộc thảo luận xung quanh Rollup phi tập trung trong cộng đồng, vì vậy ECN đã tuyển chọn một loạt các cuộc phỏng vấn podcast với chủ đề "Rollup phi tập trung" và mời những người sáng lập và nhà nghiên cứu xuất sắc trong lĩnh vực này nói về hiểu biết của họ về Rollup phi tập trung.
Khi ngày càng có nhiều thanh khoản đổ vào nền tảng Lớp 2, ngày càng có nhiều nhà cung cấp dịch vụ tổng số xuất hiện, không chỉ các giải pháp tổng số cho mục đích chung, chuỗi tổng số dành riêng cho ứng dụng mà còn cả các nền tảng tổng số như một dịch vụ. Do đó, ngày càng có nhiều người lo ngại rằng "trình sắp xếp thứ tự" có vai trò rất quan trọng trong hầu hết tất cả các bản tổng hợp vẫn được tập trung. Những rủi ro của một máy phân loại tập trung là gì? Là một máy phân loại phi tập trung một công việc cấp bách?
** Trong tập thứ hai, chúng tôi đã mời Yaoqi Jia, người sáng lập Mạng AltLayer, Toghrul Maharramov, nhà nghiên cứu của Scroll và Abdelhamid Bakhta, Trưởng nhóm khám phá Starknet, tiến hành một cuộc thảo luận bàn tròn về chủ đề máy phân loại phi tập trung, để khán giả và độc giả có thể hiểu được một số tiến bộ và tình huống khó xử hiện tại của máy phân loại phi tập trung. **
Khách trong vấn đề này:
Quá khứ
Vấn đề 1: Làm cách nào để phân cấp Rollup?
Xem trước
Vấn đề 3: Mạng Prover và tăng tốc phần cứng zk
Vấn đề 4: Tính khả dụng của dữ liệu và lưu trữ phi tập trung
Nghe
Nhấp để đăng ký podcast để tìm hiểu thêm:
Youtube：
Thế giới vi mô:
dấu ấn thời gian
00:49 Yaoqi tự giới thiệu
01:37 Abdelhamid tự giới thiệu
02:50 Toghrul tự giới thiệu
04:03 Vai trò của máy phân loại trong rollup
08:37 Trình đặt hàng phi tập trung: Cải thiện trải nghiệm người dùng và giải quyết các vấn đề về tính sống động và kiểm duyệt
19:43Starknet sẽ phân cấp máy phân loại như thế nào
22:59 Scroll sẽ phân cấp bộ sắp xếp như thế nào
26:34 Sự khác biệt giữa đồng thuận L2 trong ngữ cảnh của Optimistic rollup và zkRollup
32:28 zkRollup phân cấp bộ sắp xếp cũng cần xem xét câu tục ngữ
36:01 Tổng số dựa trên cơ sở là gì?
40:53 Nhược điểm của trình sắp xếp theo thứ tự được chia sẻ và tổng số dựa trên và các tình huống ứng dụng của chúng
49:02 Người đặt hàng phi tập trung sẽ có tác động gì đối với MEV?
Giới thiệu khách mời
Diêu Khởi
Tôi là người sáng lập AltLayer. AltLayer đang xây dựng nền tảng "Rollup as a Service" nơi các nhà phát triển chỉ cần nhấp vào một số nút và định cấu hình tham số. Bằng cách sử dụng bảng khởi chạy hoặc bảng điều khiển của chúng tôi, họ có thể nhanh chóng khởi chạy các bản tổng hợp dành riêng cho ứng dụng trong vài phút. Vì vậy, đó là những gì chúng tôi đang cố gắng thực hiện bây giờ, để cung cấp cho các nhà phát triển một môi trường và chức năng thực thi chung. Chúng tôi cũng cung cấp nhiều bộ giải trình tự, nhiều hệ thống máy ảo và nhiều hệ thống bằng chứng khác nhau để các nhà phát triển lựa chọn.
Abdel Hamid
Tôi làm việc tại Starkware và tôi là trưởng nhóm thám hiểm. Mục tiêu của nhóm này về cơ bản là khởi chạy các dự án nguồn mở giống như nghiên cứu nhưng tập trung vào kỹ thuật. Mục tiêu của chúng tôi là làm việc trên các dự án nguồn mở với sự hợp tác chặt chẽ với cộng đồng và với những người từ các hệ sinh thái khác. Một dự án như vậy là Madara, thực chất là một bộ phân loại Starknet. Nó không chỉ là ứng cử viên cho mạng công cộng Starknet mà còn là trình sắp xếp chuỗi cho chuỗi ứng dụng Starknet và Lớp 3. Điều này cũng liên quan đến những gì vị khách trước đó đã nói, chúng tôi cũng đang nghĩ đến việc cung cấp tính năng tổng hợp như một chức năng dịch vụ, mọi người có thể triển khai chuỗi ứng dụng Starknet của họ và chọn các giải pháp khả dụng dữ liệu khác nhau theo cách hơi mô-đun. Trước đó, tôi đã làm việc với tư cách là nhà phát triển lõi Ethereum trong bốn năm, chịu trách nhiệm chính về công việc của EIP-1559.
Sự lựa chọn
Tôi là nhà nghiên cứu tại Scroll, và trách nhiệm chính của tôi tại Scroll là thiết kế giao thức, thiết kế cầu nối, phân cấp, khuyến khích, đại loại như vậy. Vì vậy, khi tôi không tweet xung quanh, hầu hết thời gian tôi chỉ nghiên cứu cách phân cấp giao thức hoặc trình đặt hàng, chứng minh, những thứ tương tự. Giống như Starkware, một trong những thứ chúng tôi đang nghiên cứu là SDK tổng hợp. Do đó, bạn có thể phát hành một tổng số dựa trên Scroll và sử dụng theo mô-đun các tùy chọn sẵn có của dữ liệu khác nhau, v.v. Chúng tôi vẫn đang xem xét một tùy chọn mà các bản tổng hợp dựa trên SDK Scroll có thể sử dụng trình sắp xếp của Scroll để giúp chúng đạt được sự phân cấp mà không yêu cầu mỗi bản tổng hợp phải tự xử lý việc phân cấp. Tất nhiên, kế hoạch vẫn chưa được hoàn thành. Tuy nhiên, đây cũng là hướng chúng tôi đang thực hiện.
Phần phỏng vấn
chủ đề một
Giải thích trình sắp xếp của cuộn lên?
Abdel Hamid
Bộ sắp xếp là một thành phần rất quan trọng trong kiến trúc layer2, thành phần này nhận các giao dịch từ người dùng, sau đó đóng gói và bó chúng thành các khối, thực hiện các giao dịch, v.v. Nó rất quan trọng vì đây là thành phần chịu trách nhiệm tạo khối, vì layer2 cũng là một chuỗi khối với các khối giao dịch. Người đặt hàng tạo ra các khối này và người chứng thực chứng thực các khối này.
Diêu Khởi
Như Abdel đã đề cập, trình đặt hàng là sự kết hợp của nhiều chức năng trong chuỗi khối. Vì vậy, chúng tôi thực sự có thể giao cho người đặt hàng quá nhiều trách nhiệm so với một chuỗi khối công khai điển hình. Trước tiên, nó cần tổng hợp tất cả các giao dịch từ người dùng, sau đó sắp xếp các giao dịch đó, dựa trên giá xăng hoặc trên cơ sở ai đến trước được phục vụ trước. Sau đó, trình sắp xếp thứ tự cần thực hiện các giao dịch này. Giống như bây giờ, một số Layer2 sử dụng EVM (Starware có một máy ảo khác), nhưng về cơ bản, trình sắp xếp chuỗi cần sử dụng một máy ảo chuyên dụng để thực hiện các giao dịch và tạo trạng thái. Sau đó, giao dịch đạt đến giai đoạn xác nhận trước, có nghĩa là nếu bạn thấy thời gian xác nhận là một hoặc hai giây hoặc thậm chí là dưới giây, thì về cơ bản, đó là trạng thái xác nhận trước được hoàn thành bởi trình sắp xếp thứ tự. Sau đó, đối với hầu hết các bộ sắp xếp, chúng cũng cần tải lên hoặc xuất bản các điểm kiểm tra hoặc hàm băm trạng thái lên L1. Đây là xác nhận ở cấp độ L1, mà chúng tôi gọi là tính khả dụng của dữ liệu. Vì vậy, bộ sắp xếp thực sự có nhiều vai trò trong hệ thống tổng số. Nhưng nói chung, tôi nghĩ đó là thành phần quan trọng nhất của hệ thống tổng số.
** Chủ đề 2 **
Tại sao máy phân loại phi tập trung lại quan trọng? Nếu chúng ta sử dụng máy phân loại tập trung, những nguy cơ tiềm ẩn đối với người dùng và hệ thống là gì?
Sự lựa chọn
Trước hết, chúng ta cần biết rằng ngoại trừ Fuel V1 ở giai đoạn hiện tại, không có bản giới thiệu thực sự nào, bởi vì các bản giới thiệu khác vẫn có bánh xe huấn luyện.
Tuy nhiên, chúng tôi có thể nói rằng một khi nó được phân loại là cuộn lên, điều đó có nghĩa là đa chữ ký bị xóa, v.v. Sau đó, vấn đề phân cấp máy sắp xếp trở thành vấn đề trải nghiệm người dùng, không phải vấn đề bảo mật. Vì vậy, khi mọi người nói về việc phi tập trung hóa L1, thì vấn đề lại hoàn toàn khác. Bởi vì L1 phải đảm bảo cho các khách hàng đặt hàng và ánh sáng. Vì vậy, nếu một ứng dụng khách nhẹ muốn xác minh rằng trạng thái là chính xác, thì nó phải tin tưởng vào trình xác thực L1. Đối với rollup, đây không phải là trường hợp. Bởi vì bộ sắp xếp chỉ cung cấp khả năng sắp xếp tạm thời, sau đó được hoàn thiện bởi L1. Và, bởi vì các bản tổng hợp cũng được đảm bảo chống lại sự kiểm duyệt, chúng tôi không cần phân cấp để thực hiện điều này.
Vì vậy, có một số lý do tại sao bạn cần một máy phân loại phi tập trung. Đầu tiên, nếu nói rằng quá trình hoàn tất L1 chậm (do bằng chứng hợp lệ đã gửi của bạn quá chậm hoặc do cơ chế giai đoạn thử thách của bằng chứng gian lận tổng số lạc quan), thì bạn phải dựa vào điều gì đó để đạt được xác nhận giao dịch nhanh. Ở giai đoạn xác nhận nhanh này, mặc dù bạn có thể tin tưởng rằng Starkware hoặc Scroll sẽ không lừa dối bạn, nhưng chúng chỉ ra rằng sau khi một khối được xác nhận, sẽ không có sự sắp xếp lại. Đây là một giả định về sự tin tưởng. Và phân cấp có thể thêm một số bảo đảm kinh tế, v.v.
Nhưng dựa trên điều này, tổng số cũng không có bảo đảm về thời gian thực. Về cơ bản, bạn có thể buộc đóng gói giao dịch thông qua L1, nhưng phải mất hàng giờ để đóng gói giao dịch đó. Vì vậy, ví dụ: nếu có một nhà tiên tri chịu trách nhiệm cập nhật và thời gian dao động, thì về cơ bản nếu nhà tiên tri được cập nhật trong một giờ trở lên, các ứng dụng trong danh sách sẽ không khả dụng. Về cơ bản, tính phi tập trung cho phép chúng tôi cung cấp một số đảm bảo chống kiểm duyệt theo thời gian thực mạnh mẽ hơn, bởi vì khi đó, kẻ thù sẽ cần phải thỏa hiệp không chỉ một thực thể hoặc một số thực thể, mà là toàn bộ mạng lưới người đặt hàng.
Vì vậy, đối với chúng tôi, phi tập trung hóa là một giải pháp để cải thiện trải nghiệm người dùng hoặc khắc phục trường hợp góc của các bản cập nhật tiên tri, v.v. Thay vì cung cấp các đảm bảo an ninh cơ bản, đây là điều mà L1 thực hiện.
Abdel Hamid
Vâng, câu hỏi về bộ sắp xếp phi tập trung mà bạn đã đề cập không hoàn toàn giống với L1 phi tập trung, điều mà tôi nghĩ là rất quan trọng. Bởi vì khi chúng tôi thấy một số L1 chỉ trích các máy phân loại tập trung, họ đã không xem xét chính xác những đánh đổi mà các máy phân loại tập trung tạo ra.
Trên cơ sở này, tôi muốn thêm một số thứ liên quan đến trải nghiệm người dùng, liên quan đến hoạt động. Bởi vì khi bạn chỉ có một máy phân loại duy nhất, bạn sẽ có nguy cơ máy phân loại gặp sự cố cao hơn. Do đó, một người đặt hàng phi tập trung cũng làm tăng khả năng phục hồi và sự sống động trên mạng. Nhưng ngay cả trong bối cảnh tập trung, chúng tôi có bảo mật tốt khi nói đến bảo mật. Bởi vì khi bạn có thể buộc các giao dịch gói thông qua L1, sự khác biệt giữa hai giao dịch này chỉ là dòng thời gian. Và việc có một bộ phân loại phi tập trung cho phép bạn có được các đảm bảo chống kiểm duyệt nhanh chóng, như Toghrul đã đề cập. Vì vậy, tôi chỉ muốn nói thêm rằng điều quan trọng đối với sự sống là phải có một mạng lưới người đặt hàng phi tập trung.
Diêu Khởi
Tôi muốn thêm một cái gì đó. Hoạt động có lẽ là điều quan trọng nhất chúng ta cần xem xét ở giai đoạn này. Các trường hợp airdrop gần đây nhất trên các L2 phổ biến nhất, chẳng hạn như Optimism và Arbitrum, đã có một khoảng thời gian ngừng hoạt động. Do đó, tôi nghĩ điều chúng ta cần giải quyết là làm thế nào để xử lý hàng nghìn yêu cầu giao dịch mỗi giây khi chúng ta chỉ có một bộ sắp xếp. Ngay cả về lý thuyết, nếu bạn chỉ có một nút, thì nó thực sự không thể xử lý nhiều yêu cầu như vậy cùng một lúc. Vì vậy, liên quan đến sự sống động, chúng tôi chắc chắn cần nhiều máy phân loại. Một điểm thất bại là một trở ngại thực sự, không chỉ đối với Web3, ngay cả Web2 cũng là một vấn đề lớn.
Ngoài ra, còn có vấn đề kiểm duyệt. Nếu chúng tôi chỉ có một điều phối viên, ngay cả khi chúng tôi thấy nó có thể được điều hành bởi nhóm, bạn vẫn cần chứng minh rằng nhóm sẽ không thực sự xem xét các giao dịch. Đôi khi các bên độc hại có thể và có khả năng đưa vào danh sách đen các giao dịch nhất định. Đó là một hệ thống đặt hàng phi tập trung, họ cũng có thể thử gửi giao dịch thông qua những người đặt hàng khác. Vì vậy, đó là lý do tại sao gần đây chúng tôi nhận được rất nhiều lời chỉ trích xung quanh các máy phân loại đơn lẻ.
Ngoài ra, có một số vấn đề khác như MEV và chạy sớm. Trong một hệ thống có bộ sắp xếp tập trung, đặc biệt là đối với các giao thức DeFi, họ có thể dễ dàng kiểm tra mempool. Có lẽ không phải ở dạng người đi trước, nhưng họ có cơ hội tốt hơn để theo dõi giao dịch và phân xử nó.
Rất nhiều vấn đề này, vì nhiều lý do, mặc dù chúng tôi thấy rằng L2 rất khác với L1. Nhưng cuối cùng, chúng ta vẫn cần làm cho nó trở nên phi tập trung nhất có thể. Vì vậy, chúng tôi phải đối mặt với một số vấn đề tương tự mà chúng tôi gặp phải với các chuỗi khối công khai hoặc L1.
Abdel Hamid
Vâng, tôi đồng ý rằng một máy phân loại phi tập trung là quan trọng. Nhưng tôi cũng muốn nói rằng, như chúng ta đều biết, đây không phải là một câu hỏi dễ.
Ngoài ra, **vì các bản tổng hợp có kiến trúc rất cụ thể, với nhiều thực thể. Chúng ta đang nói về một người đặt hàng duy nhất, nhưng cũng có một người chứng minh và chúng ta cần phân cấp cả hai. **Sẽ có một số sự đánh đổi và một số khó khăn trong cách định giá giao dịch vì cần có các yếu tố khác nhau để vận hành mạng. Vì vậy, làm thế nào để bạn định giá thỏa thuận? Máy phân loại và máy chuẩn có các yêu cầu phần cứng khác nhau, máy chuẩn cần một cỗ máy siêu mạnh, v.v. Do đó, định giá các giao dịch trong một thế giới phi tập trung cũng là một vấn đề rất khó khăn, đó là lý do tại sao chúng ta cần thời gian để từ từ tiến lên phía trước.
Vì vậy, tất cả chúng ta sẽ phải đối mặt với sự đánh đổi như vậy, nếu chúng ta muốn phân cấp nhanh chóng, chúng ta có thể cần phải mất một số bánh xe đào tạo và phân cấp dần dần, bởi vì nếu chúng ta trực tiếp muốn có một kiến trúc hoàn hảo, sẽ mất vài năm. Vì vậy, tôi nghĩ rằng chúng ta sẽ thực hiện một cách tiếp cận thực tế và cố gắng phân cấp dần dần. Ít nhất đó là kế hoạch hiện tại của chúng tôi, chẳng hạn như có thể bắt đầu với một cơ chế đồng thuận BFT đơn giản và sau đó thêm một cơ chế đồng thuận khác trong thời gian ngắn hoặc đại loại như vậy. Vì vậy, tôi chỉ muốn nói rằng, đó không phải là một câu hỏi dễ dàng. Bởi vì rõ ràng là có sự đánh đổi giữa tốc độ phát triển và mức độ áp dụng của kiến trúc đối với môi trường phi tập trung.
Chủ đề 3
Làm thế nào để phân cấp máy phân loại?
Abdel Hamid
Có nhiều tính năng mà chúng tôi muốn phân cấp và tất cả chúng đều có sự đánh đổi khác nhau.
Ví dụ: khi phân cấp, bạn muốn giới thiệu một số loại cơ chế đồng thuận. Tuy nhiên, trong cơ chế đồng thuận, có nhiều phần. Đầu tiên là bầu chọn người lãnh đạo, tức là cách chọn ai sẽ tạo khối, ai sẽ là người đặt hàng chịu trách nhiệm tạo khối trong một vị trí nhất định hoặc trong một thời gian nhất định. **Những gì nhóm Starknet dự định làm là tận dụng layer1 càng nhiều càng tốt. Điều đó có nghĩa là, trong thuật toán bầu chọn nhà lãnh đạo của chúng tôi, chúng tôi muốn đặt cược vào lớp 1. Ví dụ: chúng tôi có mã thông báo và cam kết sẽ diễn ra trên hợp đồng thông minh của lớp 1 Ethereum, được sử dụng để xác định cơ chế bầu chọn người lãnh đạo. **Điều này có nghĩa là chúng ta cần có một số tương tác trong đó người đặt hàng L2 sẽ truy vấn hợp đồng thông minh Ethereum để biết ai sẽ là người lãnh đạo tiếp theo hoặc điều gì đó tương tự. Vì vậy, rõ ràng là một số loại ngẫu nhiên và những thứ khác là cần thiết. Vì vậy, nó không phải là một câu hỏi đơn giản. Nhưng đó là phần đầu tiên. Sau đó, bạn cần phải có một cơ chế cho chính sự đồng thuận. Có nhiều tùy chọn: cơ chế chuỗi dài nhất hoặc BFT hoặc kết hợp cả hai. Giống như Ethereum, nó có LMG Ghost và Casper FFG về mặt tài chính.
Vì vậy, chúng tôi có thể thực hiện một cách tiếp cận thực tế và bắt đầu với BFT trước. Tại sao? Khi layer2 xem xét phân quyền, mục tiêu của chúng tôi không phải là có quy mô phân loại lớn như layer1. Ví dụ: trên Ethereum, mục tiêu là có hàng triệu trình xác thực tham gia. Trong trường hợp này, bạn không thể chỉ sử dụng cơ chế BFT, vì nó sẽ rất kém hiệu quả và sẽ gây ra những vấn đề rất lớn. Ví dụ: nếu có sự cố trên mạng Bitcoin, nếu đó là cơ chế BFT, chuỗi sẽ dừng hoàn toàn. Nhưng đây không phải là trường hợp, mạng Bitcoin tiếp tục tạo khối, chỉ có cơ chế cuối cùng bị tấn công.
Nhưng ở lớp 2, nếu mục tiêu là vài trăm đến 1000 máy phân loại, thì có thể tốt hơn nếu bắt đầu với cơ chế BFT. Như vậy là chúng ta đã có cơ chế bầu thủ lĩnh, rồi đến cơ chế đồng thuận, rồi còn hai phần nữa, nhưng tôi sẽ để dành cho các vị khách mời tiếp tục bổ sung. Nhưng hai phần còn lại là cập nhật trạng thái và tạo bằng chứng.
Sự lựa chọn
Đầu tiên, trong L2, phi tập trung hóa là một vấn đề nhiều mặt, như Abdel đã mô tả. Đặc biệt trong zkRollup, vì có prover và orderer nên bạn phải phối hợp giữa chúng, bạn phải phân quyền cho cả hai. Vấn đề này hoàn toàn khác với L1.
Một điểm khác biệt nữa là trong L2, tất cả thiết kế của bạn là để thuyết phục cây cầu cơ bản rằng sự đồng thuận là chính xác, chứ không phải để thuyết phục bất kỳ nút nào khác. Rõ ràng là bạn cũng nên làm như vậy, nhưng trọng tâm chính của bạn phải là chính cây cầu.
Hiện tại, chúng tôi đang làm việc theo hai hướng khác nhau. Thứ nhất, tôi nghĩ, giống như những người khác, chúng tôi đang làm việc trên một giao thức BFT. Điều này không hiệu quả lắm và có một số nút thắt cần được giải quyết. Chúng tôi đã đưa ra một giải pháp sơ bộ, nhưng nó vẫn chưa tối ưu. Ví dụ, một trong những câu hỏi là, làm thế nào để bạn cân bằng các ưu đãi giữa người sắp xếp và người chứng minh? Bởi vì người đặt hàng kiểm soát MEV và người chứng minh không có quyền truy cập vào MEV, nên có động cơ khuyến khích mọi người chạy người đặt hàng thay vì người chứng minh. Nhưng trên thực tế, chúng ta cần nhiều người chứng minh hơn là người đặt hàng, vậy làm thế nào để bạn cân bằng các ưu đãi giữa hai bên? Đây là một trong những vấn đề đó.
Giải pháp thứ hai mà chúng tôi đang thực hiện là một hướng đi khác. Hãy nhớ rằng, mọi thứ có thể thay đổi. Đề xuất mới xuất hiện mỗi ngày. Ví dụ: gần đây đã có nhiều cuộc thảo luận về tổng số dựa trên cơ sở và cách bạn có thể thuê ngoài hoàn toàn việc phân loại cho L1. Hướng thứ hai về cơ bản là loại bỏ hoàn toàn bộ sắp xếp và sử dụng một số trình tạo bên ngoài. Ví dụ: các nhà xây dựng ethereum hoặc Flashbots SUAVE, v.v. đề xuất các khối được sắp xếp theo thứ tự và sau đó chạy sự đồng thuận bên trong chứng minh. Ưu điểm ở đây là bạn không phải xử lý các ưu đãi vì về cơ bản, bạn có thể sử dụng PBS bên trong giao thức và nó tạo ra một giao thức đơn giản hơn. Nhưng nhược điểm là vì chúng tôi cần một số lượng lớn người chứng minh (vì chúng tôi có thể chứng minh song song), nên rất khó để chạy một giao thức BFT cổ điển với họ. Vì vậy, câu hỏi đặt ra là làm thế nào để bạn tối ưu hóa một giao thức BFT hiện có để chạy với hàng trăm, thậm chí hàng nghìn chứng minh? Và đó không phải là một câu hỏi dễ trả lời.
Việc giới thiệu sự đồng thuận L2 có cần thiết cho một người đặt hàng phi tập trung không?
Diêu Khởi
Tôi có thể trả lời đại khái câu hỏi này bởi vì chúng tôi vừa mới triển khai một sản phẩm tương tự.
Vì vậy, việc đưa ra sự đồng thuận hay không không phụ thuộc vào việc chúng ta có muốn hay không. Một khi bạn có nhiều người đặt hàng hoặc thậm chí chỉ là các nút, bạn phải khiến họ đồng ý. Nó thực sự phụ thuộc vào các giả định của bạn. Nếu đó là giả định của Byzantine, chúng tôi có thể sử dụng BFT hoặc bất kỳ giao thức đồng thuận Byzantine hiện có nào. Ví dụ: nếu đó là một thiết lập không phải của Byzantine, nếu chúng tôi chỉ cho rằng một nút chỉ có thể trực tuyến và ngoại tuyến và nút đó không thể hành động ác ý, thì chúng tôi có thể sử dụng giao thức Raft hoặc một số giao thức đồng thuận nhanh hơn khác. Nhưng dù sao đi nữa, nếu chúng ta có một nhóm người đặt hàng hoặc người chứng minh, nếu chúng ta muốn tổ chức họ lại với nhau để tạo ra các khối trong một khoảng thời gian, thì bạn phải có một giao thức đồng thuận xung quanh họ.
Vì vậy, như Toghrul và Abdel vừa đề cập, tôi tin rằng có rất nhiều đề xuất và chủ đề nghiên cứu về cách chúng ta có thể đạt được một hệ thống chứng minh hoặc đặt hàng phi tập trung. Vì vậy, vì chúng tôi vừa ra mắt mạng thử nghiệm cho hệ thống tổng số đa phân loại (hiện chỉ hỗ trợ bằng chứng gian lận cho tổng số Lạc quan), dựa trên kinh nghiệm thiết kế và triển khai của chúng tôi, tôi có thể chia sẻ một số điều về những khó khăn. Như Toghrul vừa đề cập, khó khăn không nằm ở bản thân giao thức đồng thuận, mà khó khăn thực sự nằm ở những thứ khác ngoài điều này, chẳng hạn như phần bằng chứng. Bởi vì nếu đó là một bộ sắp xếp đơn lẻ, bạn không cần nhiều nút. Chúng ta có thể coi nó như một EVM, một máy ảo. Vì vậy, chỉ cần tìm nạp các giao dịch và thực hiện, thực hiện chuyển đổi trạng thái. Prover chịu trách nhiệm tạo ra bằng chứng cho sự chuyển đổi trạng thái của tập hợp các giao dịch trước đó. Tuy nhiên, nếu chúng tôi chạy giao thức đồng thuận cho trình đối chiếu và trình chứng thực trong bản cập nhật, thì chúng tôi cần giới thiệu logic đồng thuận bổ sung ở đó. Trên hết, bạn cũng cần một hệ thống bằng chứng cho giao thức đồng thuận. Do đó, điều này sẽ giới thiệu rất nhiều công việc cho hệ thống bằng chứng để tạo ra. Sau đó, khi bạn tạo bằng chứng, bạn có thể dễ dàng xác minh nó trên L1 Ethereum.
Vì vậy, đó là lý do tại sao theo một cách nào đó, khi chúng tôi khởi chạy mạng thử nghiệm nhiều đơn đặt hàng đầu tiên, bản tổng hợp lạc quan có một số lợi thế về mặt đó. Nói chung, bạn có thể đơn giản hóa rất nhiều thứ, chẳng hạn như không xem xét phần chứng minh tính hợp lệ. Giống như chúng tôi, về cơ bản chúng tôi so sánh mọi thứ với WASM. Vì vậy, cuối cùng, đó là hướng dẫn WASM. Vì vậy, bằng cách xác minh các hướng dẫn WASM này, việc xác minh bằng mã Solidity tương đối dễ dàng. Nếu chúng tôi vừa triển khai lại tất cả các diễn giải hướng dẫn WASM trên Ethereum.
Nhưng nói chung, vấn đề không phải là cá biệt. Nếu chúng ta có một giải pháp cho vấn đề, tương ứng, sẽ có một số công việc tiếp theo khác cần được giải quyết cùng một lúc. Tất nhiên, sẽ có các vấn đề về MEV, chẳng hạn như cách chúng tôi phân phối MEV một cách công bằng. Bạn có thể chỉ định tất cả người đặt hàng và người chứng minh dựa trên việc họ đã tạo khối hay xác thực khối. Nhưng cuối cùng, nó thực sự là sự kết hợp của nhiều vấn đề, không chỉ là vấn đề kỹ thuật mà còn cả các động lực kinh tế.
Và chúng ta cần nhớ rằng L2 được đề xuất vì chúng ta muốn giảm đáng kể chi phí gas. Vì vậy, chúng tôi không thể có quá nhiều nút. Ngay cả khi tạo bằng chứng, L2 có thể đắt hơn L1. Vì vậy, chúng ta thực sự cần đưa ra một cách tiếp cận cân bằng cho loại vấn đề này.
Abdel Hamid
Tôi muốn thêm một điểm nữa. Đầu tiên, hiện tại không có bằng chứng gian lận thực sự không được phép đối với các bản tổng hợp lạc quan. Và tôi tiếp tục nhấn mạnh điều này mỗi khi có cơ hội, bởi vì điều quan trọng là phải trung thực về điều này khi so sánh. Vì vậy, chúng hoàn toàn không phải là L2. Đó là điều đầu tiên.
Sau đó, tôi muốn thêm một số điều về sự không đồng bộ giữa phân loại và bằng chứng, bởi vì nó rất quan trọng. Như bạn đã nói, chúng tôi muốn tối ưu hóa việc sắp xếp, bởi vì hiện tại đây là nút cổ chai cho tất cả các giải pháp. Nhưng điều đó tốt trong bối cảnh sắp xếp tập trung, bởi vì chúng tôi biết bộ sắp xếp sẽ chỉ tạo ra các chuyển đổi giá trị và chúng tôi sẽ có thể xác minh chúng. Nhưng sẽ khó hơn trong bối cảnh sắp xếp phi tập trung, bởi vì có thể máy sắp xếp của bạn sẽ có thể tạo ra thứ gì đó không thể xác minh được. Sau đó, bạn sẽ cần phải đối phó với điều đó sau.
Trong bối cảnh sắp xếp tập trung, để tối ưu hóa việc sắp xếp, vì chúng tôi không phải tạo bằng chứng trong quá trình sắp xếp, chúng tôi có thể thử thực hiện ở tốc độ cục bộ, đó là điều chúng tôi muốn làm. Dịch Cairo sang ngôn ngữ máy cấp thấp như LLVM và chạy siêu nhanh trên bộ sắp xếp. Sau đó, bạn có thể chứng minh không đồng bộ. Và điều thú vị nhất về bằng chứng là bạn có thể thực hiện chúng song song. Khả năng song song lớn đạt được bằng cách chứng minh rằng đệ quy là có thể. Đó là lý do tại sao chúng ta sẽ có thể bắt kịp tốc độ của máy phân loại. Nhưng rất khó khi phân cấp, vì chúng ta cần đảm bảo rằng người đặt hàng chỉ tạo ra các chuyển đổi trạng thái hợp lệ.
Sự lựa chọn
Tôi sẽ nói thêm rằng tôi không chắc Starknet đang làm gì ở đây. Nhưng đối với chúng tôi, tôi đoán rằng giả định chung của mọi zkRollup là nếu bạn phân cấp bộ sắp xếp, hệ thống bằng chứng của bạn phải có khả năng xử lý các lô không hợp lệ. Vì vậy, về cơ bản, giả sử, nếu bạn gửi một lô có chữ ký không hợp lệ, thì bạn phải có khả năng chứng minh rằng trạng thái kết quả tương đương với trạng thái bắt đầu. Vì vậy, sẽ có một số chi phí cả hai cách. Đó là về cách bạn giảm thiểu xác suất xảy ra điều này.
Abdel Hamid
Vâng đúng vậy. Đó là lý do tại sao chúng tôi giới thiệu Sierra ở Cairo 1 để làm cho mọi thứ có thể kiểm chứng được. Đại diện trung gian này sẽ đảm bảo rằng mọi chương trình Cairo 1 đều có thể xác minh được để chúng tôi có thể đưa vào giao dịch hoàn nguyên.
Tổng số dựa trên là gì?
Diêu Khởi
Bản tổng hợp dựa trên ban đầu đến từ một bài đăng trên blog của Justin Drake trên các diễn đàn Ethereum. Một trong những ý tưởng của anh ấy là chúng tôi có thể sử dụng lại một số trình xác minh Ethereum để xác minh các giao dịch tổng số, do đó chúng tôi không cần một nhóm nút riêng biệt để xác minh các giao dịch tổng số khác nhau. Đặc biệt, chúng tôi sẽ có nhiều bản tổng hợp trong tương lai, bao gồm cả bản tổng hợp cho mục đích chung và nhiều bản tổng hợp dành riêng cho ứng dụng. Vì vậy, trong trường hợp này, sẽ thật tuyệt nếu chúng ta có thể tìm thấy một nơi chung như nhóm trình xác thực Ethereum để xác thực các giao dịch này.
Tất nhiên, đây chỉ là một ý tưởng, vì nó cũng gây ra rất nhiều khó khăn về kỹ thuật. Ví dụ: về lý thuyết, chúng tôi có thể yêu cầu trình xác thực Ethereum xác minh các giao dịch tổng số, nhưng rất khó để có được logic xác minh các bản tổng số được gói hoặc nhúng vào chính giao thức Ethereum. Chúng tôi gọi đây là xác minh trong giao thức, yêu cầu một nhánh cứng của các nút Ethereum. Tất nhiên, trong trường hợp này, chúng tôi có thể xác minh một số giao dịch tổng số. Nhưng nếu chúng tôi làm, bạn sẽ thấy vấn đề. Có vẻ như chúng tôi muốn bản tổng hợp của L2 chia sẻ áp lực của Ethereum, nhưng cuối cùng, chúng tôi vẫn yêu cầu những người xác thực Ethereum đảm nhận một số công việc đã giảm tải cho L2. Vì vậy, rất nhiều người nói về cách chúng ta có thể làm điều này.
Sau đó, chúng tôi đã nói chuyện với Barnabe, một nhà nghiên cứu tại Ethereum Foundation hiện đang làm việc trên PBS. Đây là một đề xuất của Ethereum, nhằm phân chia nhiệm vụ của trình xác nhận thành nhiều vai trò, người xây dựng và người đề xuất. Bây giờ chúng ta có Flashbots để đảm nhận vai trò của người xây dựng trong PBS, họ soạn tất cả các khối và gửi chúng cho những người đề xuất Ethereum. Vì vậy, một khi các khối này được đóng gói vào mạng Ethereum, những người xây dựng cũng sẽ nhận được một số phần thưởng. Sau đó, trong trường hợp này, làm cách nào để thưởng cho những người xác thực này từ mạng Ethereum? Họ cũng chịu trách nhiệm xác thực tổng số.
Một trong những giải pháp là "retaking", mà có thể bạn đã nghe nhiều từ EigenLayer hoặc một số giao thức khác. Người dùng có thể đặt lại ETH trên các mạng phân loại khác. Hoặc thưởng cho trình xác thực Ethereum vì đã thực sự chạy phần mềm để thực hiện công việc xác thực cho bản tổng hợp. Trong trường hợp này, họ có thể được thưởng cả từ L2 và thông qua giao thức đặt cược lại. Cho đến nay đã có nhiều đề xuất cho điều này, nhưng nói chung đó là ý tưởng về cách có thể tái sử dụng các trình xác thực Ethereum hiện có. Làm cách nào chúng tôi có thể tái sử dụng ETH hiện có để giúp mở ra một kỷ nguyên mới của hệ thống tổng số hoặc hệ thống L2? Vì vậy, về cơ bản, nó đang cố gắng đơn giản hóa rất nhiều thứ cho dự án tổng số. Nếu một tổng số muốn một số bộ sắp xếp mới, nếu họ muốn một số nguồn tài sản thế chấp mới, họ có thể sử dụng lại cơ sở hạ tầng hiện có hoặc tài sản thế chấp hiện có. Vì vậy, đó là lý do tại sao nó được xây dựng dựa trên Ethereum, sau đó cơ sở hạ tầng và đặt cược bổ sung có thể được sử dụng lại cho rollup và cả L2.
Nhược điểm của trình sắp xếp thứ tự được chia sẻ và tổng số dựa trên cũng như các tình huống ứng dụng của chúng.
Sự lựa chọn
Tôi muốn khiếu nại về đề xuất này, tôi không bị thuyết phục bởi đề xuất liên quan đến trình sắp xếp thứ tự được chia sẻ. Tất nhiên, chúng vẫn còn sơ khai và nếu những thiết kế này được cải thiện trong tương lai, tôi hoàn toàn có thể ủng hộ chúng. Chỉ là phong độ hiện tại không thuyết phục được tôi. Có nhiều lý do.
Đầu tiên, đối với tôi, đề xuất giá trị chính của bộ sắp xếp dùng chung là cho phép người dùng có được khả năng kết hợp nguyên tử giữa các bản tổng hợp có mục đích chung như Scroll hoặc Starknet. Nhưng vấn đề là nếu bạn có khả năng tổng hợp nguyên tử, thì bản tổng hợp của bạn sẽ là bản cuối cùng giống như bản tổng hợp chậm nhất mà bạn kết hợp. Vì vậy, giả sử Scroll được kết hợp với Optimistic Rollup, thời hạn cuối cùng của Scroll sẽ là bảy ngày. Mặc dù đề xuất giá trị chính của ZKRollup là đạt được kết quả cuối cùng tương đối nhanh, nhưng người dùng có thể rút về L1 trong vòng vài phút. Và trong trường hợp này, về cơ bản hãy từ bỏ điều đó.
Một nhược điểm khác là nếu bạn muốn tính hữu hạn ngoài chuỗi, bạn cần chạy một nút L2 và miễn là dữ liệu được gửi tới chuỗi được hoàn thiện bởi L1, bạn sẽ có được tính hữu hạn cục bộ trong L2. Nếu mỗi L2 kết hợp không chạy một nút đầy đủ, thì thực tế là không thể hoàn thành cục bộ. Điều này có nghĩa là việc chạy hệ thống này có thể tốn kém hơn so với việc chạy một hệ thống như Solana, bởi vì bạn có nhiều nút đầy đủ chạy cùng lúc, với chi phí hoạt động riêng, v.v.
Vì vậy, vì những lý do đó, tôi không nghĩ nó có ý nghĩa đối với L2. Nó hơi khác một chút đối với L3, bởi vì nếu ai đó muốn xây dựng một chuỗi dành riêng cho ứng dụng và không muốn giải quyết vấn đề phân quyền. Giả sử tôi đang xây dựng một trò chơi và tôi chỉ muốn xử lý việc xây dựng trò chơi, sau đó tôi có thể thuê ngoài công việc phi tập trung. Nhưng tôi không nghĩ nó có ý nghĩa với L2 vào lúc này.
Đối với tổng số dựa trên, tôi cũng có mối quan tâm của mình. Ví dụ: làm thế nào để bạn chia sẻ lợi nhuận MEV với người chứng minh? Bởi vì nếu vấn đề phân bổ không được xem xét, về cơ bản L1 có thể thu được tất cả lợi nhuận MEV. Một điều nhỏ nữa là thời gian xác nhận của nó bằng với thời gian xác nhận của L1 là 12 phút, không thể nhanh hơn. Một vấn đề khác là vì nó không được phép, nhiều Người tìm kiếm có thể gửi các lô giao dịch cùng một lúc, điều đó có nghĩa là nó có thể dẫn đến kết quả tập trung. Bởi vì các nhà xây dựng được khuyến khích bao gồm các giao dịch của họ nếu một người tìm kiếm kết nối dễ dàng hơn những người khác. Do đó, cuối cùng có thể chỉ có một Người tìm kiếm đề xuất các lô cho L2, đây không phải là một giải pháp tốt, bởi vì nếu điều này xảy ra, về cơ bản, chúng tôi sẽ quay lại hình vuông.
Diêu Khởi
Thật thú vị, tôi vừa có một cuộc gọi với Ben, người sáng lập Espresso, vào tuần trước. Chúng tôi thảo luận về điều này rất nhiều trong chủ đề của bộ sắp xếp được chia sẻ. Như Toghrul đã đề cập, tôi nghĩ rằng có một số điều không chắc chắn về các tình huống sử dụng đối với hệ thống đặt hàng dùng chung. Điều này chủ yếu là do đối với L2 có mục đích chung, chúng tôi thường không có nhiều máy phân loại do tính hiệu quả, độ phức tạp và tính kinh tế. Và tôi vẫn cảm thấy rằng cho dù đó là trình sắp xếp thứ tự được chia sẻ, tổng số dựa trên hoặc khôi phục lại, thì trường hợp sử dụng tốt nhất chủ yếu là dành cho RAS (Rollup as a Service) hoặc các nền tảng như vậy mà chúng tôi có thể triển khai nhiều bản tổng hợp. Thành thật mà nói, chúng tôi không thực sự cần một mạng phân loại lớn nếu không có nhiều bản tổng hợp. Các tổng số này đã có hệ thống sắp xếp riêng và đã có cộng đồng hoặc đối tác riêng, khi chỉ có một số L2 chung. Họ không thực sự cần phải có một mạng bên thứ ba và riêng biệt. Ngoài ra, đây là một gánh nặng đối với mạng của bên thứ ba, vì bạn phải tùy chỉnh cho từng L2 và mỗi L2 có một ngăn xếp thử nghiệm khác nhau. Điều này đòi hỏi rất nhiều thay đổi đối với mạng của riêng bạn.
Nhưng đồng thời, như Toghrul đã đề cập, đối với một số trường hợp sử dụng đặc biệt. Ví dụ: nếu chúng tôi muốn có một số khả năng tương tác ở cấp bộ sắp xếp, thì bộ sắp xếp dùng chung có thể là một cách khả thi. Ví dụ: cùng một bộ sắp xếp được sử dụng cho nhiều lần tổng số. Trong trường hợp này, bộ sắp xếp này về cơ bản có thể xử lý một số giao dịch tổng số chéo để đảm bảo tính nguyên tử của chuỗi chéo giữa tổng số A, B và C.
Nhưng bạn cũng có thể thấy vấn đề ở đây khi tôi mô tả tình huống. Nếu chúng ta thực sự có nhiều trình sắp xếp chung này, chúng sẽ lại trở thành nút cổ chai và một điểm thất bại mới. Chúng ta đang trao quá nhiều quyền lực cho những người được gọi là người đặt hàng chung này. Chúng đang trở nên giống một mạng lưới hơn, kiểm soát nhiều bản tổng hợp. Cuối cùng, một lần nữa chúng ta cần nghĩ ra một cách để phân cấp bộ sắp xếp dùng chung này.
Nhưng dù sao đi nữa, tôi nghĩ thật tốt khi mọi người đang dần dần phát hiện ra nhiều vấn đề hơn và ngày càng đưa ra nhiều giải pháp hơn. Nói chung, thật thú vị khi thấy những gì mới trong lĩnh vực này mỗi ngày. Với tất cả các giải pháp mới này, ít nhất chúng tôi đang đi đúng hướng để thực sự phi tập trung hóa toàn bộ không gian tổng số.
Abdel
Vâng, tôi đồng ý với cả hai bạn. Tôi nghĩ điều đó hợp lý hơn đối với Layer3 và Lisk vì họ không muốn nhận trách nhiệm khuyến khích mạng phi tập trung nữa và cần tìm đối tác để bắt đầu những thứ như máy phân loại. Vì vậy, tôi nghĩ đối với Lisk, nó có ý nghĩa. Nhưng giống như Toghrul, tôi không nghĩ nó có nhiều ý nghĩa đối với Layer2.
Chủ đề 4
Người đặt hàng phi tập trung sẽ có tác động gì đối với MEV?
Abdel
Đối với Starknet, trong bối cảnh tập trung hóa, chúng tôi không thực hiện bất kỳ loại MEV nào và chúng tôi áp dụng mô hình ai đến trước được phục vụ trước. Điều đó có nghĩa là, trong bối cảnh phi tập trung hóa, tất nhiên, sẽ có nhiều MEV hơn được đưa vào sau này. Nhưng còn quá sớm để nói tỷ lệ nào, vì nó còn phụ thuộc vào thiết kế của cơ chế đồng thuận và các khía cạnh khác.
Sự lựa chọn
Nhưng vấn đề là, ngay cả khi bạn không thực hiện MEV, vẫn có thể có một số MEV vẫn xảy ra trong Starknet. Bản thân việc phân cấp không thực sự làm giảm MEV hay tăng MEV. Tất nhiên, nếu bạn áp dụng một số loại giao thức đặt hàng hợp lý hoặc mã hóa ngưỡng chẳng hạn, thì vâng, bạn giảm thiểu MEV. Nhưng bạn không thể loại bỏ nó hoàn toàn. Triết lý của tôi là: MEV không thể bị loại bỏ. Nhưng giả sử bạn chỉ đang tạo sự đồng thuận BFT hoặc xây dựng thứ gì đó dựa trên sự đồng thuận BFT. Điều này thực sự không ảnh hưởng đến MEV. MEV vẫn tồn tại, vấn đề là cách người tìm kiếm làm việc với bộ sắp xếp để trích xuất MEV đó.
Diêu Khởi
Vấn đề là, ngay cả mô hình ai đến trước được phục vụ trước cũng có những phần phức tạp. Sau khi chúng tôi hiển thị mempool cho một số người tìm kiếm, họ vẫn có lợi thế để chơi nhiều hơn. Ví dụ, đối với trình tự, chúng tương đương với việc đợi ở cửa văn phòng của bạn. Vì vậy, trong trường hợp này, một khi họ nhìn thấy một loại cơ hội chênh lệch giá nào đó, không chỉ về tấn công chạy trước hoặc tấn công kiểu bánh sandwich, ngay khi người dùng gửi một giao dịch, họ có thể thấy ngay giao dịch đó trong mempool. Vì vậy, họ có thể nhanh chóng đặt giao dịch của mình trước những người khác. Vì vậy, họ có lợi thế hơn những người tìm kiếm khác.
Nhưng quay trở lại vấn đề phân cấp, tôi nghĩ chủ yếu là về khả năng chống kiểm duyệt, như chúng ta đã thảo luận lúc đầu. Trình tự được quản lý bởi nhóm. Nhóm có thể nói rằng họ đang công bằng với mọi người. Nhưng điều này không bị ngăn chặn trong mã. Vì vậy, nếu chúng tôi có thể có mạng P2P, sẽ thật tuyệt nếu chúng tôi cảm thấy các nút này kiểm tra các giao dịch của tôi và sau đó chúng tôi có thể gửi đến các nút khác. Vì vậy, đó thực sự là về tính công bằng của việc xử lý các giao dịch tại L2.
Đối với MEV, bởi vì gần đây, ngoài các MEV được tạo trong một lần tổng hợp, còn có một số MEV được tạo qua các cầu nối. Trong mạng phân loại tương đối phi tập trung này, bạn sẽ có nhiều cơ hội hơn để trích xuất MEV. Giả sử chúng ta có một mạng đặt hàng dùng chung, nếu bạn có thể bằng cách nào đó tác động đến người đặt hàng dùng chung để sắp xếp lại các giao dịch, thì về cơ bản, bạn có lợi thế lớn so với những người khác.
Có những ưu điểm và nhược điểm đối với mạng trình sắp xếp chung. Về mặt tích cực, chúng ta có thể phân cấp hơn nữa hệ thống xếp hạng. Nhưng mặt khác, mọi người đều có cơ hội trở thành người phân loại. Vì vậy, về cơ bản họ có thể làm bất cứ điều gì họ muốn, và đó lại là một khu rừng tối. Vì vậy, chúng tôi đã giới thiệu tính năng phân quyền và sau đó chúng tôi phải đối mặt với những vấn đề tương tự mà chúng tôi gặp phải trong Ethereum. Đó là lý do tại sao các thành viên của Flashbots và Ethereum Foundation muốn tiếp tục với PBS, tách biệt người đề xuất và người xây dựng, sau đó cố gắng có một giải pháp duy nhất về phía người xây dựng.
Vì vậy, khi chúng ta xem xét vấn đề, nó không chỉ là một vấn đề đơn lẻ. Nó không còn là vấn đề một đối một, mà là một đối sáu, và hơn thế nữa.