Chuyển tiêu đề gốc 'Chúng ta đang xây dựng cùng một thứ'

giới thiệu

bài viết này phân tích các điều sau

• thực thi không đồng bộ - tại sao các blockchain tích hợp hiệu suất cao (ví dụ: Solana và Monad) sẽ tách khỏi việc thực thi từ sự đồng thuận về thứ tự (thứ tự).
• chuỗi lười biếng - cách họ sẽ phản ánh thiết kế của một bộ lười biếng (ví dụ,@astriaorg/hj6ccpp9t">astria).
• Xác nhận trước - preconfs trên Ethereum L1 và các rollups dựa trên.
• dựa trên so với không dựa trên - so sánh based rollups + preconfs so với non-based rollups + base layer fallback.
• tính đồng bộ toàn cầu - thông qua việc bao gồm nguyên tử (từ các trình tự chia sẻ) + an toàn mật mã (ví dụ, AggLayervà/hoặc chứng minh thời gian thực).
• Rollups dựa trên tầng cơ sở nhanh - Rollups dựa trên tầng cơ sở nên chỉ cần có một tầng cơ sở nhanh.
• trò chơi về thời gian - Thời gian là tiền bạcvà cách điều đó là cơ sở cho những chiến lược kết thúc khác nhau giữa solana và ethereum.
• phân cấp để chống lại sự kiểm duyệt - như thế nàophân tách người xác nhận - người đề xuấtquaĐấu giá thi hành áncó thể bảo tồn các thẩm phán phi tập trung có thể thực thi tính chống kiểm duyệtdanh sách bao gồm.

Cuối cùng, và quan trọng nhất, chúng ta sẽ thấy tại saochúng ta đều đang xây dựng cùng một thứ chết tiệtvậy thì chúng ta có lẽ nên chỉ...

tối ưu hóa sao chép máy trạng thái (smr)

Chúng ta sẽ xây dựng từ những cơ bản để xem kết cục cho các blockchain hiệu suất cao (ví dụ: Solana, Monad, @patrickogradyCác phương pháp tiếp cận của HyperSDK gần như tương đương với chiến lược giảm thiểu rủi ro: cho phép các nhà xây dựng tối đa hóa lợi nhuận để giảm thiểu số lượng giao dịch không hợp lệ (/rys8mdl5p#mitigation-strategy-enable-profit-maximizing-builders-to-minimize-invalidtps).trình tự lười biếng(ví dụ như, @astriaorgTrước tiên, chúng ta sẽ tìm hiểu về quy trình của mạng Polygon (trước đây được gọi là Matic) so với các giao thức rollups và preconfs dựa trên Ethereum. Sau đó, chúng ta sẽ so sánh chúng để có cái nhìn tổng quan.

Thứ tự thực hiện so với thực hiện

các chuỗi khối là máy sao chép trạng thái. Các nút phi tập trung giữ và cập nhật bản sao của trạng thái hệ thống của riêng mình. Để tiến triển chuỗi, các nút chạy chức năng chuyển đổi trạng thái (stf) trên trạng thái hiện tại + đầu vào mới (ví dụ: giao dịch mới). Điều này tạo ra trạng thái mới.

Chúng tôi sẽ sử dụng các thuật ngữ sau trong phần này:

• hợp lệ cú pháp - giao dịch được hình thành đúng cách với cấu trúc giao dịch và chữ ký đúng.
• hợp lệ về mặt ngữ nghĩa - giao dịch thực hiện một chuyển trạng thái hợp lệ (ví dụ: thanh toán các khoản phí cần thiết).
• chuỗi - xác định thứ tự và sự bao gồm của dữ liệu.
• thực hiện - diễn giải và hành động dựa trên dữ liệu theo đúng theo stf.
• xây dựng - tạo một khối (hoặc phần khối/chip/shred) từ các giao dịch được lưu trữ địa phương.
• xác minh - thực hiện xác minh cú pháp và/hoặc ngữ nghĩa cần thiết của một khối (hoặc một phần khối/chunk/shred).
• Nhân bản - phân phối một khối (hoặc phần khối / mảnh khối) cho các bộ xử lý khác.

hãy phóng to vào chuỗi và thực hiện, vì đây là những công việc con cốt lõi cần thiết để tính toán trạng thái của chuỗi:

Ngoài ra, các nút xác minh và nhân bản dữ liệu trên toàn mạng. Các nút đạt đồng thuận để duy trì một cái nhìn nhất quán về chuỗi.

tuy nhiên, các kiến trúc chuỗi khác nhau phân tán ý nghĩ rõ rữa trong việc ai chệu trách nhiệm cho các nhiệm vụ này và khi họ làm như thế nào (điểm ví dẫ, xây dựng và xác minh khởi động có thể bao gồm hay không bao gồm việc thực hiện). thời gian tối đa tối thiệu của tất cả nhân bản máy trạng thái (smr)vòng lặp quy định giới hạn thấp nhất về độ trễ hệ thống. các cấu trúc khác nhau có thể tạo ra thời gian biến đổi cao, vì vậy quy trình smr hoạt động hiệu quảđường ốngViệc thực hiện những nhiệm vụ này là cần thiết để đạt hiệu suất thấp độ trễ và cao thông lượng.

trong các phần tiếp theo, chúng ta sẽ thấy rằng một hiểu biết cốt lõi về việc tạo ra ống dẫn hiệu quả là tập trung vào việc đạt được sự đồng thuận về đầu vào thực hiện thay vì kết quả thực hiện. điều này đòi hỏi nới lỏng một số ràng buộc cụ thể về giao dịch có thể được bao gồm. sau đó, chúng ta sẽ cần phải giới thiệu lại một số ràng buộc yếu hơn để đảm bảo rằng hệ thống vẫn hữu ích và kháng cự lại các cuộc tấn công (ví dụ, tránh các vector dos từ các giao dịch không trả phí).

SMR truyền thống

Các SMR truyền thống (ví dụ: Ethereum) mật thiết kết hợp trình tự và thực thi. Các nút đầy đủ liên tục trình tự và thực thi tất cả giao dịch tầng cơ bản - cả hai đều là điều kiện tiên quyết để các nút đạt được sự đồng thuận. Ngoài việc xác minh rằng tất cả dữ liệu khối có sẵn (và đã được trình tự), các nút cũng phải thực thi khối để xác minh rằng:

• tất cả các giao dịch đều hợp lệ về cú pháp và ngữ nghĩa
• trạng thái mới tính toán khớp với trạng thái được cung cấp bởi người điều hành

các người xác minh chỉ sẽ bỏ phiếu cho một khối và xây dựng trên nó sau khi họ đã xác minh trạng thái của nó một cách độc lập. điều này có nghĩa là việc thực thi xảy ra ít nhất hai lần trước khi đạt đồng thuận (tức là, nhà sản xuất khối thực thi trong quá trình xây dựng + các người xác minh nhận lại thực thi lần nữa để xác minh).

Trong mô hình truyền thống này, việc xây dựng và xác minh đều bao gồm thực thi.

nguồn:@patrickogrady/rys8mdl5p#Making-the-case-for-decoupled-state-machine-replication-dsmr">vryx: tăng cường sao chép máy trạng thái không liên kết

streaming smr

streaming smr (e.g., solana) là một hình thức pipelining hiệu quả màcác nhà sản xuất khối liên tục “truyền” các phần khối (gọi là shredshoặc các mảnh) khi chúng được xây dựng. các nút khác nhận và xác minh (bao gồm cả thực thi) những mảnh này liên tục, ngay cả khi phần còn lại của khối vẫn đang được xây dựng. điều này cho phép người lãnh đạo tiếp theo bắt đầu xây dựng khối của họ sớm hơn.

nguồn:@patrickogrady/rys8mdl5p#Đưa ra lập luận cho việc tách rời sao chép máy trạng thái (DSMR)">vryx: củng cố sao chép máy trạng thái tách rời

Trong mô hình phát trực tuyến này, việc xây dựng và xác minh vẫn bao gồm sắp xếp và thực thi. Điều này tăng hiệu suất SMR so với SMR truyền thống mà không giảm bớt bất kỳ ràng buộc nào về việc tất cả các giao dịch được bao gồm đều có tính ngữ nghĩa và cú pháp hợp lệ.

thực thi bất đồng bộ

phương pháp tổng hợp

Bây giờ, chúng ta có thể có hiệu suất tốt hơn nếu chúng ta nới lỏng những ràng buộc đó không?

việc thực hiện không đồng bộ loại bỏ việc thực hiện khỏi đường đi nóng của sự đồng thuận - các nút chỉ đơn giản đạt đồng thuận về thứ tự của dữ liệu mà không thực thi dữ liệu đó trước. Điều này hiệu quả hơn, đó là lý do tại sao SolanavàMonadcả hai kế hoạch triển khai thực hiện bất đồng bộ.

người đứng đầu sẽ xây dựng và nhân bản một khối (hoặc xé) mà không cần thực thi nó. sau đó, các bộ xác nhận khác sẽ bỏ phiếu về nó mà không thực thi nó. các nút chỉ đạt được sự nhất trí về thứ tự và tính sẵn có của giao dịch. điều này đủ vì với một stf xác định được, mọi người sẽ cuối cùng tính toán ra cùng một trạng thái. việc thực thi không cần phải kéo dài quá trình nhất trí - nó có thể chạy bất đồng bộ. điều này có thể mở rộng ngân sách thực thi cho các nút (cho phép họ có nhiều thời gian để chi tiêu cho thực thi) trong khi giảm số bước cần thiết (và do đó là thời gian) để đạt được sự nhất trí.

Thứ tự sắp xếp quyết định sự thật. Thực hiện chỉ đơn giản là tiết lộ nó. Bất cứ ai cũng có thể thực hiện dữ liệu để tiết lộ sự thật một khi thứ tự của nó được hoàn thành.

đó chính là lý do tại saoKeone tin rằng cuối cùng mọi chuỗi khối đều sử dụng việc thực hiện không đồng bộvà đó là một phần quan trọng của Tầm nhìn cuối cùng của Toly cho Solana:

“thực thi đồng bộ yêu cầu tất cả các nút bỏ phiếu và tạo khối được cung cấp quá nhiều thời gian thực thi xấu nhất trong bất kỳ khối nào ... các nút đồng thuận có thể thực hiện ít công việc hơn trước khi bỏ phiếu. công việc có thể được cộng gộp và được phân lô, làm cho nó được thực thi một cách hiệu quả mà không có bất kỳ cache misses nào. nó có thể được thực thi trên một máy tính khác hoàn toàn từ các nút đồng thuận hoặc các nhà lãnh đạo. người dùng mong muốn thực thi đồng bộ có thể cấp đủ tài nguyên phần cứng để thực thi mọi chuyển đổi trạng thái trong thời gian thực mà không cần đợi đến khi mạng còn lại.

Hiện tại, các trình xác thực phát lại tất cả các giao dịch càng nhanh càng tốt trên mỗi khối và chỉ bỏ phiếu khi toàn bộ trạng thái được tính toán cho khối đó. Mục tiêu của đề xuất này là tách quyết định bỏ phiếu trên một nhánh khỏi quá trình chuyển tiếp trạng thái đầy đủ cho khối.

Đáng chú ý rằng chúng tôi cũng muốn đảm bảo rằng sự thật được tiết lộ dễ dàng đối với người dùng, và điều đó có nghĩa là hỗ trợ mạnh mẽ cho các ứng dụng nhẹ. Một số thiết kế này có thể làm trễ thực hiện một cách đáng kể và điều này sẽ làm cho việc này trở nên thách thức (ví dụ,Solana đang xem xét chỉ yêu cầu nó một lần mỗi epoch) so với những người khác cung cấp một gốc trạng thái trên một độ trễ ngắn hơn (ví dụ, như trong hypersdk).

phương pháp mô-đun

việc tách riêng quá trình xếp hàng và thực thi có thể nghe có vẻ rất quen thuộc vì đây cũng là cách tiếp cận “modular”! kết hợp và kết hợp các lớp khác nhau chuyên về các nhiệm vụ khác nhau. việc tách riêng quá trình xếp hàng và thực thi là nguyên tắc thiết kế chính của các bộ xếp hàng lười biếng (ví dụ như astria):

• điều chỉnh thứ tự - các nút điều chỉnh chỉ đạt được sự nhất quán về thứ tự và sẵn có của dữ liệu rollup (tức là họ điều chỉnh nhưng không thực thi).
• Thực thi - Các nút tổng hợp thực thi dữ liệu tương ứng của chúng sau khi trình sắp xếp chuỗi đã cam kết với nó.

Sự khác biệt chính ở đây là các nút chuỗi tích hợp thực hiện sau khi xếp hàng trong khi người xếp hàng lười biếng đẩy nó đến một tập hợp hoàn toàn khác biệt và đa dạng các nhân vật. Người xếp hàng lười biếng hoàn toàn không hiểu về máy trạng thái của các rollup. Họ không bao giờ thực hiện các giao dịch này. Rollup xử lý việc thực hiện không đồng bộ.

phương pháp tích hợp cung cấp tính tương tác mượt mà hơn giữa người dùng của môi trường thực thi, nhưng giảm tính linh hoạt theo hướng cho các nhà phát triển ứng dụng (ví dụ, máy ảo tùy chỉnh, thời gian khe khác nhau, Quy tắc giá cả và sắp xếp các giao dịch được áp đặt bởi sự đồng thuận và đặc thù của ứng dụng, v.v.. phương pháp tiếp cận theo mô-đun cung cấp tính linh hoạt và chủ quyền hơn cho nhà phát triển sở hữu tên miền tùy chỉnh của mình, nhưng khó để thống nhất trải nghiệm trên tất cả chúng.

Trong cả hai trường hợp, một ống dẫn thực sự lớn và nhanh để đặt dữ liệu là nguyên tắc chúng ta cần:

Tuy nhiên, bạn nên lưu ý rằng kỹ thuật, bạn có thể sử dụng gần như bất kỳ chuỗi nào như một trình tự lười biếng. Sau cùng, nó chỉ là một ống dữ liệu lớn. Một rollup có thể ngây thơ ném dữ liệu tùy ý của nó vào lớp cơ sở mà nó chọn (dù đó là ethereum, bitcoin, monad, vv.) để sử dụng một cách ngầm định như trình tự của họ. Các nút rollup sau đó có thể thực thi dữ liệu bất đồng bộ sau khi hoàn tất.

Sự khác biệt trong thực tế là các chuỗi mà chúng ta thực sự gọi là “các bộ xử lý lười biếng” được chuyên biệt hóa cho nhiệm vụ này, điều này dễ nói hơn làm (ví dụ, hỗ trợ các loại giao dịch cần thiết, mở giao diện dễ dàng, triển khai cơ sở hạ tầng mev, thời gian khe nhanh, bao gồm việc bao gồm giao dịch đáng tin cậy, băng thông cao, v.v.). Kết quả là, các nút cho chuỗi tích hợp cuối cùng sẽ thực hiện hầu hết dữ liệu mà họ bao gồm, trong khi các bộ xử lý lười biếng để lại việc đó cho rollups chủ yếu.

Đó là lý do tại sao điều đó không đơn giản như 'tại sao chúng ta không sử dụng solana (hoặc bất kỳ chuỗi nào khác khi đó không phải là mục tiêu thiết kế) như một bộ xếp hàng cuộn?':

• thiếu cơ sở hạ tầng mev cần thiết được thiết kế đặc biệt cho rollups (ví dụ, cơ sở hạ tầng pbs cần thiết, cơ chế tương thích qua chuỗi cho nhau, người soạn nhạc để trừu tượng hóa việc thanh toán phí cho người dùng rollup trong gas token tầng cơ sở, v.v.)
• thiếu các loại giao dịch gốc được thiết kế để tổng hợp đăng dữ liệu.
• cạnh tranh với môi trường thực thi nguyên bản (ví dụ: nó được thiết kế một cách rõ ràng để tiêu thụ tất cả hoặc càng nhiều dữ liệu được cung cấp càng tốt, để lại ít không gian và sự bao gồm giao dịch đáng tin cậy, v.v.)
• cạnh tranh để được hỗ trợ từ người phát triển chung và ưu tiên nâng cấp. Bạn có thể có xu hướng tìm đến giao thức và nhóm chuyên biệt hỗ trợ bạn khởi động rollups và thiết kế giao thức của họ dành riêng cho bạn, thay vì nhóm mà hầu hết cộng đồng coi rollups là hơi ngớ ngẩn.

tăng cường smr tách rời

Bây giờ, chúng ta có thể giải quyết những vấn đề mà chúng ta gặp phải bằng cách nới lỏng những ràng buộc này không? Tóm lại, có, các cài đặt ngây thơ đúng sự giới thiệu vấn đề như cho phép giao dịch không hợp lệ không thể thanh toán phí (điều này sẽ là vector dos nếu thực hiện một cách ngây thơ), nhưng chúng có thể được giải quyết sao cho chúng không phải là vấn đề nghiêm trọng.

chúng tôi sẽ không mắc kẹt quá nhiều trong chi tiết ở đây, nhưng bạn có thể tham khảoPatrick o’grady’scông việc tuyệt vời trên@patrickogrady/rys8mdl5p#making-the-case-for-decoupled-state-machine-replication-dsmr">vryx để củng cố smr tách rời, toly’s kết thúc thực thi không đồng bộ, vàViệc thực hiện chi phí vận chuyển của Monadvề cách giải quyết những vấn đề này. một lần nữa, các giải pháp cho những vấn đề này không ngạc nhiên trông gần như giống nhau trên cả phía modular và phía tích hợp.

Tldr là bạn có thể đưa ra một số ràng buộc yếu hơn nhiều (so với thực hiện đồng bộ với xác minh đầy đủ) giúp giữ lại hầu hết lợi ích về hiệu suất mà không để lại một loạt các cuộc tấn công.

những diễn viên trong giao thức so với những diễn viên ngoài giao thức

Đáng chú ý, chúng ta cần nhận ra rằng các quy trình trên chỉ đơn giản tính đến các nhà hoạt động trong giao thức. Trong thực tế, các nhà hoạt động ngoài giao thức đóng một vai trò quan trọng trong chuỗi cung ứng giao dịch này. Điều này là điều chúng ta đã thấy trước đây đối với các nhà hoạt động (trong giao thức) trong SMR truyền thống:

nguồn:@patrickogrady/rys8mdl5p#making-the-case-for-decoupled-state-machine-replication-dsmr">vryx: củng cố sao chép máy trạng thái tách rời

thực tế, Hầu hết các nhà xác thực Ethereum đều tạo khối thông qua mev-boostvới ba nhà xây dựng hàng đầu (beaver, titan và rsync) xây gần hết các khối này. lưu ý rằng beaver và rsync kiểm duyệt các giao dịch ofac trong khi titan không.

nguồn:mevboost.pics

Các relay xử lý việc sao chép các khối này đến phần còn lại của mạng. Họ cũng tương đối nặng đầu, với bốn nhà điều hành hàng đầu (âm thanh siêu, bloxroute, bất khả tri, và flashbots) chuyển tiếp phần lớn khối. Bloxroute và flashbots kiểm duyệt các giao dịch OFAC, trong khi bất khả tri và âm thanh siêu không.

nguồn:mevboost.pics

cũng không ngạc nhiên khi chúng ta thấy những xu hướng tối ưu hóa độ trễ tương tự ở đây như chúng ta đã thảo luận trước đó. Xu hướng đó đang hướng đếnchuỗi truyền lạc quanvới việc không còn thực hiện xác minh khối trước khi sao chép vì nó đơn giản nhanh hơn. các trình tự lười biếng có thể được coi là các mạng truyền tải có động lực.

Những ví dụ này nêu bật cách MEV làm sai lệch các ưu đãi lợi nhuận trong các hệ thống này. Trình xác thực thuê ngoài sản xuất khối vì các nhà xây dựng tinh vi có thể thu được nhiều giá trị hơn so với các khối được sắp xếp theo trình tự ngây thơ.

Ngay cả khi thực hiện không đồng bộ, thường sẽ có các nhà sản xuất khối ngoài giao thức thực hiện các giao dịch trong quá trình xây dựng để tối đa hóa giá trị. Ví dụ: rất có khả năng các trình sắp xếp lười biếng sẽ có các trình tạo tối đa hóa lợi nhuận dưới một số dạng PBS. Thực tế là một nhà sản xuất khối bên ngoài luôn được khuyến khích để vẫn thực thi đầy đủ và tối ưu hóa giá trị của một khối thực sự có thể hữu ích trong các cài đặt nơi chúng tôi nới lỏng các ràng buộc trong thực thi không đồng bộ. Tuy nhiên, các trình xác thực khác sẽ không cần phải thực thi lại trước khi bỏ phiếu.

tính tổng quát đồng bộ

Định nghĩa

Bây giờ, chúng ta có thể đạt được chủ quyền và tính linh hoạt mà các chuỗi tương thích cung cấp, nhưng có thể tái hợp nhất chúng để cảm thấy như một chuỗi tích hợp không? Liệu chúng ta có thể có bánh mà cũng không phải trả giá, hay chỉ đơn giản là xây dựng Solana với những bước đi phụ?

khi nghe mọi người nói về việc sửa đổi tình trạng phân mảnh rollup, bạn có thể đã nghe những từ ngữ lớn xung quanhtính đồng bộ toàn cầu (usc). Tuy nhiên, có lẽ đây là phản ứng của bạn:

Những thuật ngữ này thường được sử dụng với nhiều ý nghĩa khác nhau, và một số thuật ngữ thường được sử dụng sai lẫn nhau. Chúng ta cần đặt một số định nghĩa cụ thể. Chúng tôi định nghĩa các thuật ngữ cần thiết dưới đây trong bối cảnh của khả năng tương tác giữa các chuỗi.

lưu ý rằng chúng tôi sẽ thảo luận về "rollups" trong phần còn lại của báo cáo này, nhưng nhiều khái niệm này cũng áp dụng cho các loại "l2s" khác như validiums.Tôi chỉ không muốn tranh cãi về cái gì là l2 nữa.

trong các ví dụ sau:

• r_một = rollup a
• r_b = rollup b
• t_A1 = giao dịch 1 trên r_một
• t_b1 = Giao dịch 1 trên R_b
• b_a1 = khối 1 trên r_một
• b_b1 = khối 1 trên r_b
  

Lưu ý rằng chúng tôi định nghĩa "thời gian" là "chiều cao khe" ở đây. Thời gian hoàn toàn tương đối với người quan sát. Khái niệm khách quan duy nhất về thời gian chúng ta có là một trật tự tương đối bởi một người quan sát chung, tức là một sự đồng thuận chung (trong đó "sự đồng thuận" đó có thể là một tác nhân duy nhất hoặc một cơ chế phi tập trung).

nếu cả hai rollups đều có cơ chế đồng thuận cung cấp thứ tự, chúng ta có thể khẳng định:

• b_a1 is trước b_a2
• b_b1là trước b_b2

tuy nhiên, cách duy nhất để xác định:

• b_a1đồng thời ở cùng một thời điểm tại b_b1, và do đó
• t_a1và t_b1 xảy ra đồng bộ, là nếu
• Họ chia sẻ một thứ tự được cung cấp bởi sự đồng thuận chung cho khe cắm đã cho.

Do đó, định nghĩa về tính đồng bộ qua chuỗi liên kết đòi hỏi một loại trình tự chia sẻ cho chiều cao khe đó theo cách định nghĩa. Các chuỗi không có trình tự chỉ có thể có tính kết hợp không đồng bộ.

Tuy nhiên, chú ý rằng chúng ta có thể có tính đồng nhất bất đồng bộ. Rất tiếc, tôi thường thấy mọi người sử dụng thuật ngữ “atomic” và “synchronous” một cách thay thế, nhưng thực sự chúng là các thuật ngữ khác nhau.

với việc đóng cửa, hãy xem xem chúng ta có thể tái giới thiệu tính tương hòa vào các chuỗi modul. nếu có thể, thì điều đó có thể dường như làm tăng giá trị của các chuỗi tích hợp. Đây là tldr mà chúng ta sẽ đi sâu vào:

• Chia sẻ chuỗi có thể cung cấp sự bao gồm nguyên tử đồng bộ trên chính nó (điều này yếu hơn rất nhiều so với tính ghép nối).
• ghép cặp một trình xếp chung với một số cơ chế đảm bảo mật mã (ví dụ, agglayer) có thể tăng cường bảo đảm này thành tính kết hợp thực tế.
• Các đảm bảo an toàn do agglayer cung cấp cho an toàn xuyên chuỗi cũng có thể được sử dụng mà không cần có một sequencer chung (tức là trong cài đặt không đồng bộ).
• Chúng ta sẽ xem cách chúng ta cũng có thể mô phỏng các hiệu ứng của tính kết hợp đồng bộ, mặc dù theo cách hiệu quả vốn ít hơn, bằng cách sử dụng cryptoeconomics (cầm cố trực tiếp giao dịch qua chuỗi).

Bao gồm nguyên tử - Trình tự chia sẻ

Phương pháp sequencing chia sẻ có nghĩa là với một độ cao khe cắm cụ thể, một thực thể duy nhất (người “sequencer” hay “proposer”) có quyền độc quyền để sequencing (tức là đề xuất khối cho) nhiều chuỗi. Để làm rõ, những sequencer chia sẻ này chúng ta thường nói đến là công cụ lập trình lười biếng. họ đạt được sự nhất trí về thứ tự và tính sẵn có của dữ liệu rollup, nhưng họ không thực thi nó. họ hoàn toàn không biết về các máy trạng thái của rollup.

Như tôi đã viết trước đâyĐiều này có nghĩa là các bộ xếp hàng được chia sẻ lười biếng có thể cung cấp cam kết đáng tin cậy để bao gồm các gói chéo chuỗi (tức là, một tập hợp các giao dịch):

• từng phần tử - hoặc tất cả các giao dịch sẽ được bao gồm hoặc không có giao dịch nào
• đồng thời - cùng một lúc (độ cao khe)

điều này cho phép trích xuất MEV hiệu quả hơn bằng cáchSiêu nhà xây dựng(tức là, những người xây dựng chuỗi chéo) khi thực hiện các hành động chuỗi chéo, vì họ không còn phải định giá rủi ro mà một chân của gói chuỗi chéo có thể thất bại. tính đồng bộ ở đây có thể ngầm cung cấp cho họ tính nguyên tử.

giải phóng xích

bây giờ, làm thế nào chúng ta có thể làm điều này mà không hoàn toàn tin tưởng vào người xây dựng và/hoặc người đề xuất hoạt động cho bộ định thứ tự chung? nếu chúng ta chỉ gửi hai giao dịch được ký độc lập (t₁và t₂Đối với mỗi cuộn, bảng điều khiển chia sẻ vẫn có thể quyết định chỉ bao gồm một hoặc một trong hai.

Ví dụ, hiện tại không có khái niệm về định dạng gói cục bộ trong evm, đó là lý do tại sao người tìm kiếm hoàn toàn tin tưởng vào người xây dựng/relay để không giải nén chúng. Bất kỳ ai nhìn thấy một gói gồm các giao dịch được ký độc lập trước khi chúng được cam kết bởi người dẫn đầu hiện tại đều có thể giải nén chúng. Điều này thường là tốt, vì người xây dựng và relay được động viên để duy trì uy tín của họ và bảo vệ các gói tìm kiếm, nhưng khi sự tin tưởng đó bị phá vỡ (hoặc họ bị lừa bởi các bên tham gia không trung thực để tiết lộ các giao dịch),Tách ra có thể mang lại lợi nhuận khổng lồ.

chúng ta cần một sự đảm bảo an toàn mạnh hơn ở đây nếu chúng ta muốn có khả năng tương tác qua chuỗi thực sự. chúng ta không chỉ đang nói về việc lấy một số tiền từ người tìm kiếm. nếu các hợp đồng cross-chain defi được xây dựng dựa trên giả định rằng các gói cross-chain sẽ được tôn trọng, nhưng sau đó niềm tin này bị phá vỡ, kết quả sẽ là thảm họa cho những giao thức đó (ví dụ, trong một gói cầu nối cross-chain burn-and-mint, bạn có thể bỏ qua việc đốt cháy nhưng bù đắp quỹ bên phía khác).

Chúng ta cần đảm bảo an toàn vững chắc để triển khai tính tương thích giữa chuỗi. Điều đó có nghĩa là chúng ta phải xác định một định dạng giao dịch đảm bảo rằng nhiều giao dịch trong một gói tương thích chuỗi được bao gồm cùng nhau. Nếu một giao dịch được bao gồm mà không có giao dịch khác, chúng ta cần một đảm bảo về an toàn rằng giao dịch đó là không hợp lệ.

Điều này có nghĩa là chúng ta cần tạo một cấu trúc giao dịch mới cho các gói chuỗi chéo không thể unbundled. Giải pháp ngây thơ là "hãy tạo một loại giao dịch mới cho những cú đấm này", nhưng điều đó không dễ dàng. Điều đó sẽ đòi hỏi thay đổi vm cho những cú đấm này, mất tính tương thích ngược. Bạn cũng sẽ liên kết chặt chẽ những cú đấm bằng cách sửa đổi máy trạng thái của chúng sao cho mỗi giao dịch chỉ hợp lệ kèm theo giao dịch khác được bao gồm.

Tuy nhiên, có một cách làm sạch hơn để thực hiện điều này. bạn có thể làm cho mỗi giao dịch trong bó cũng ký vào bó băm, sau đó thêm băm tiêu hóa vào trường giao dịch miễn phí (ví dụ, calldata trong evm). rollup phải sửa đổi luồng dẫn xuất của họ để kiểm tra những điều này, nhưng vm có thể vẫn không thay đổi. với việc này, người dùng rollup có thể gửi các bó liên kết chéo mà họ chắc chắn không thể giải bóc. cố gắng làm điều đó sẽ làm cho chúng không hợp lệ.

nguồn: Ben fisch

sự đảm bảo bao gồm so với sự đảm bảo của nhà nước

với những điều trên đã được thiết lập, chúng tôi hiện đã xác định cách một bộ sắp xếp chia sẻ lười biếng:

• có thể cung cấp cam kết đáng tin cậy về sự bao gồm đồng bộ nguyên tử cho các gói chéo chuỗi (tức là tất cả các giao dịch sẽ được bao gồm hoặc không có giao dịch nào)
• không thể cung cấp cam kết đáng tin cậy về trạng thái kết quả từ các giao dịch như vậy được bao gồm (ví dụ: có thể cả hai giao dịch đều được bao gồm, nhưng một giao dịch khác đến trước và gây ra nó bị lùi lại)

Thật không may, việc bao gồm nguyên tử một mình là một cam kết yếu hơn nhiều. Cam kết này đối với việc bao gồm nguyên tử là đủ để người xây dựng có niềm tin cao rằng khối cross-rollup họ xây dựng sẽ tạo ra trạng thái kết quả họ muốn nếu nó được xác nhận. Người xây dựng nhất thiết biết trạng thái kết quả của khối, vì họ thực thi nó để xây dựng nó.

Tuy nhiên, chúng ta vẫn còn một vấn đề - làm sao mọi người khác biết chắc chắn trạng thái sẽ như thế nào?

Hãy xem xét một ví dụ:

• Chúng tôi có hai rollups (ra và rb) chia sẻ cùng một bộ xử lý lười biếng
• Tôi muốn sử dụng cầu đốt và đúc giữa ra → rb đồng thời đốt trên ra và đúc trên rb
• Hợp đồng minting bridge trên rb cần một đảm bảo về trạng thái chuyển tiếp trên ra (đốt) để mint trên rb, nhưng hợp đồng không thể biết liệu token thực sự đã bị đốt trên ra vào thời điểm thực thi vì nó không có quyền truy cập vào trạng thái của ra.

nếu chúng ta đã gửi một gói đúng, thì trình tự lười biếng có thể đảm bảo rằng giao dịch đốt đã được bao gồm trong luồng giao dịch cho ra, nhưng bạn không biết ví dụ nếu có một giao dịch khác đến trước đó làm cho nó không có giá trị (nghĩa là token thực sự không được đốt).

Chia sẻ một trình tự biếm hoạ lười biếng đơn giản là không đủ để cho phép các chuỗi truy cập vào trạng thái của nhau trong quá trình thực thi gói. Tính kết hợp đồng bộ yêu cầu khả năng máy trạng thái của mỗi chuỗi truy cập vào trạng thái của chuỗi khác (ví dụ: hợp đồng cầu nối trên rb cần biết trạng thái của ra) vào thời điểm thực thi. Khả năng đó chính là điều cho phép tính kết hợp đầy đủ trong một chuỗi tích hợp duy nhất.

người xây dựng không thể nói với hợp đồng "tin tôi đi, nó sẽ hoạt động tốt." Chúng ta nhận thấy rằng sự bao gồm nguyên tử là một công cụ tốt cho những người tìm kiếm tin tưởng xây dựng để thực hiện đúng gói của họ, nhưng nó không đủ để trừu tượng hóa khả năng tương tác giữa các chuỗi.

Để sửa điều này, chúng ta cần thêm một cơ chế khác ngoài việc sắp xếp chia sẻ:

như chúng tôi đã đề cập, người xây dựng biết cá nhân về trạng thái kết quả sẽ như thế nào nếu gói được bao gồm theo nguyên tử. vậy họ có thể cung cấp cam kết đáng tin cậy để thuyết phục mọi người khác về trạng thái kết quả sẽ như thế nào nếu giao dịch của họ được bao gồm hay không?

họ có nhiều lựa chọn:

• cryptoeconomic - người xây dựng có thể đặt cược một số lượng vốn lớn để đảm bảo hoàn toàn các hoạt động qua chuỗi.Điều này thường không hiệu quả và có thể được mô phỏng về tính kết hợpnhưng đó là một ví dụ hữu ích để minh họa chức năng.
• mật mã - chúng ta có thể có một cơ chế cung cấp các bảo đảm mật mã rằng các giao dịch sẽ tạo ra trạng thái mong muốn.

an toàn kinh tế mã hóa - trải phiếu xây dựng

Hãy đi qua một ví dụ để xem cách cryptoeconomics có thể mô phỏng các hiệu ứng của synchronous composability. Ví dụ cổ điển được sử dụng là của mộtvay nhanh qua chuỗi. Tôi muốn vay một khoản flash trên ra, sử dụng nó để thực hiện một giao dịch chênh lệch giá trên rb và trả nó trên ra trong cùng một khoảng thời gian. Điều này có thể xảy ra nếu các giao thức DeFi ở đây triển khai chức năng chuyển chuỗi tùy chỉnh với những gì chúng tôi gọi là “hợp đồng ngân hàng” ở mỗi bên:

Bây giờ đối với vấn đề an toàn đó - hợp đồng về RA và RB cần biết các trạng thái chuỗi của nhau để làm điều này một cách an toàn, nhưng chúng tôi đã không làm gì để giải quyết vấn đề này. Chà, "giải pháp" kinh tế tiền điện tử ở đây thực sự khá vũ phu - bạn có Super Builder hoạt động như một nhà cung cấp thanh khoản và đưa ra toàn bộ giá trị của khoản vay flash. Nếu các giao dịch thất bại, thì giao thức cho vay vẫn giữ cổ phần của họ. Bạn có thể thấy tại sao đây không phải là "giải pháp" thỏa mãn nhất.

an toàn mật mã - agglayer

đó là gì

cáiAggLayer là một giao thức phi tập trung cung cấp ba lợi ích chính:

1. an toàn cho khả năng kết hợp xuyên chuỗi nhanh chóng - nó tạo ra các chứng minh zk cung cấp an toàn mật mã cho khả năng tương tác xuyên chuỗi tự động với tốc độ thấp (tức là nhanh hơn các khối ethereum) khi hoạt động không đồng bộ hoặc đồng bộ. thiết kế đặc biệt cô lập các lỗi chuỗi để có thể hỗ trợ bất kỳ môi trường thực thi và bằng chứng nào.
2. tính tương đồng của tài sản qua chuỗi - nó có một cầu nối chung để đảm bảo tính tương đồng của tài sản trên các aggchain (tức là các chuỗi sử dụng nó) để người dùng không kết thúc với một số lượng tài sản được bọc. hợp đồng cầu nối nằm trên ethereum, đó là lớp thanh toán. (lưu ý rằng các chuỗi khác nhau vẫn có thể có các giả định bảo mật khác nhau do việc triển khai, điều này sẽ được bàn luận kỹ hơn ở dưới.)
3. tối ưu hóa gas - nó aggreGate.io chứng minh cho aggchains để phân chia chi phí cố định trên nhiều chuỗi. hợp đồng tiền gửi chung cũng tối ưu hóa chi phí gas bằng cách cho phép chuyển tiền l2-to-l2 trực tiếp mà không cần chạm vào l1.

nguồn:Nông dân Brendan, Các chuỗi khối tổng hợp

để làm rõ hai quan niệm sai lầm phổ biến về những gì mà agglayer không phải là:

• Agglayer không chỉ là một dịch vụ để chứng minh aggreGate.io - điều này làm cho việc này trở nên khó hiểu vì thực tế là nó tổng hợp chứng minh của Gate.io, và họ đặt “tổng hợp” vào tên của thứ đó. Tuy nhiên, mục đích của agglayer là tổng hợp chuỗi. Sự phân biệt quan trọng đối với mục đích của bài đăng này là rằng việc tổng hợp chứng minh một mình không làm được điều gì để đảm bảo an toàn mà chúng ta cần ở đây.
• Các lớp kết tủa và bộ xếp chia sẻ không phải là những thiết kế đối lập - trong khi chúng không cần phải được sử dụng cùng nhau, Trên thực tế, chúng là những bổ sung hoàn hảocung cấp các cam kết khác nhau. agglayer hoàn toàn không quan tâm đến cách aggchains được xếp hàng. nó không xử lý bất kỳ thông điệp nào giữa các chuỗi, vì vậy nó thực sự phụ thuộc vào cơ sở hạ tầng phối hợp tự do trên thị trường (ví dụ: trạm chuyển tiếp, người xây dựng, bộ đếm đơn độc, bộ đếm chia sẻ, v.v.) để xây dựng các chuỗi.

Bây giờ chúng ta hãy đi qua cách nó hoạt động.

cầu nối rất tệ

cầu nối giữa các rollup ngày nay rất khó khăn. Giả sử bạn muốn cầu nối eth giữa hai rollup lạc quan của Ethereum oru_avà oru_b:

• qua cầu native - bạn sẽ phải trả phí gas ethereum l1 đắt đỏ (tức là cầu từ oru_một → ethereum + ethereum → oru_b) và chuyến đi ngược lại sẽ mất hơn một tuần (do cửa sổ chứng minh lỗi).
• direct rollup → rollup - số ETH được bọc mà bạn nhận được trên oru_bthực tế không thể thay thế được với eth bản địa cho oru_một. sự phụ thuộc vào con đường khi đi qua các cầu khác nhau làm mất tính linh hoạt. ví dụ, nếu cái hoặc_một Cầu đã bị rút cạn, sau đó ETH được bọc mà bạn bắc cầu đến Orub sẽ không được hỗ trợ, trong khi ETH bản địa trên Oru_bsẽ tốt. sự phân tán thanh khoản thực sự khó chịu, đây không phải là điều người dùng mong muốn. Trong thực tế, người dùng trực tiếp kết nối thông qua các nhà cung cấp thanh khoản. Ai đó sẽ cung cấp cho bạn eth trên oru_bvà giữ khoản tiền của bạn trên oru_một họ có thể rút tiền thông qua cầu gỗ bản địa và đợi, nhưng họ sẽ tính phí đắt đỏ vì rủi ro và chi phí vốn cao mà họ phải chịu.

Bạn có thể nghĩ rằng zk rollups giải quyết vấn đề này một cách dễ dàng, nhưng thực tế thì không phải vậy. Các phiên bản ngây thơ vẫn yêu cầu bạn gửi giao dịch l1, điều này lại tốn kém và thường khá chậm (ví dụ, do thời gian xác nhận của ethereum, thời gian tạo chứng minh, tần suất đăng tải chứng minh trong thực tế, v.v.).

Người dùng không muốn đối mặt với việc này. Họ chỉ muốn có quỹ và sử dụng ứng dụng. Việc kết nối nên được hoàn toàn trừu tượng hóa - tài sản nên được đồng nhất và di chuyển nhanh chóng, rẻ tiền và an toàn.

Đây là lúc chia sẻ hợp đồng cầu nối. Một hợp đồng cầu nối chung mở ra cánh cửa cho các chuỗi sử dụng nó để cầu nối trực tiếp với nhau mà không cần thông qua L1.

các token cũng có thể được thay thế trên các aggchain và kết quả là. cầu nối eth từ r_một → r_bhoặc r_c→ r_b đốt và đúc cùng một mã thông báo. Nó không phải là một tài sản bọc khóa và đúc. Đó là ETH bản địa. Điều này là có thể bởi vì tất cả các tài sản được ký quỹ với nhau và giải quyết thông qua cây cầu thống nhất. Đây là một điểm đau lớn đối với L2S ngày nay cần được giải quyết.

Tuy nhiên, lưu ý rằng người dùng giữ ETH trên R_mộtvs. r_bCó thể có một hồ sơ rủi ro khác nhau nếu các chuỗi khác nhau sử dụng các bộ xác minh khác nhau (ví dụ, có thể bạn đã chuyển từ một chuỗi an toàn sang một chuỗi có lỗi mạch). Các hồ sơ rủi ro không thay đổi giữa các chuỗi sử dụng các tiêu chuẩn chung ở đây (trong thực tế là thường xuyên hiện nay). Tiêu chuẩn đồng nhất hơn và xác minh hình thức chỉ sẽ cải thiện điều này theo thời gian, ngay cả khi các lĩnh vực đa dạng được thêm vào.

chứng cớ bi quan

Aggchains gửi các bản cập nhật trạng thái và bằng chứng của chúng cho các nút được đặt cọc Agglayer, những người sắp xếp chúng, tạo cam kết cho tất cả các tin nhắn và tạo bằng chứng đệ quy. agglayer sau đó tạo ra một bằng chứng aggreGate.iod zk duy nhất (mà họ gọi là "chứng minh bi quan”) để thanh toán cho tất cả các aggchains. Vì việc tổng hợp chứng minh ở đây phân phối chi phí trên bất kỳ số lượng chuỗi nào, nên từ quan điểm chi phí, việc đăng chúng lên ethereum để thanh toán nhanh chóng là khả thi. Chương trình chứng minh bi quan được viết bằng mã code rust thông thường, sử dụngzkvm sp1 của Succinctđể dễ dàng phát triển và đạt hiệu suất cao.

những bằng chứng bi quan này càng cố thể hiện:

• Kế toán liên chuỗi - chứng minh rằng tất cả các bất biến cầu nối đều được tôn trọng (tức là, không có chuỗi nào có thể rút nhiều mã thông báo hơn số tiền đã được gửi vào nó).
• Sự hợp lệ của aggchains - chứng minh rằng mỗi chuỗi đã cập nhật trạng thái của mình một cách chân thật, không có sự phân định chuỗi hoặc các khối không hợp lệ.
• An toàn Cross-chain - Chứng minh rằng các cập nhật trạng thái là kết quả của giao dịch cross-chain ở thời gian chậm hơn Ethereum là nhất quán và có thể được giải quyết an toàn trên Ethereum L1. Điều này bao gồm việc thực thi nguyên tử thành công của các gói Cross-chain cả đồng bộ và không đồng bộ.

Với điều này, Agglayer đảm bảo rằng việc thanh toán xảy ra trên Ethereum nếu và chỉ khi các điều kiện trên được đáp ứng. Nếu chúng không được đáp ứng, thì các chuỗi tương ứng không thể giải quyết. Như vậy, Agglayer có thể cho phép một điều phối viên (ví dụ: trình sắp xếp hoặc trình tạo được chia sẻ) truyền tin nhắn giữa các chuỗi ở độ trễ thấp mà không cần họ tin tưởng điều phối viên đó để đảm bảo an toàn.

tính nhanh và an toàn của tương tác qua chuỗi

aggchains có thể sử dụng các cam kết được cung cấp ở đây trong cả các cài đặt tương tác bất đồng bộ và đồng bộ để biểu thị ràng buộc về tính hợp lệ khối liên quan đến các rollup khác.

Điều này sẽ cho phép người dùng gửi gói liên chuỗi mà phải được thực hiện một cách nguyên tử thành công trên cả hai bên. không chỉ là sự bao gồm nguyên tử. bạn thực sự đang áp đặt trạng thái kết quả của chúng phải thành công. Điều này là sự kết hợp hoàn hảo để bổ sung chính xác những gì chúng tôi mô tả là thiếu trong việc đảm bảo bao gồm nguyên tử của một trình điều khiển chia sẻ duy nhất.

nguồn:Nông dân Brendan, Các blockchain đã được tổng hợp

lấy ví dụ của chúng tôi từ trước đây:

• Chúng tôi có hai rollup (r_mộtvà r_b) chia sẻ cùng một bộ phân loại lười và lớp tụ
• Tôi gửi một gói cross-chain để đốt eth đồng thời trên r_mộtvà đào eth trên r_b
• Một Super Builder xây dựng một khối cho cả hai chuỗi thực hiện việc này, mà trình sắp xếp chuỗi được chia sẻ cam kết
• Hợp đồng cầu nối đúc tiền trên r_bcó thể đúng mực mạnh mẽ mở khóa eth tùy thuộc vào tình hình của r_a (trong trường hợp này, tiêu hủy eth thành công)
• Những khối và chứng minh này được gửi đến lớp kết hợp, chứng minh rằng cả hai chuỗi hoạt động theo cách hợp lệ (cả độc lập và đối với nhau) và cầu nối chung đã được sử dụng an toàn.

Để điều này được giải quyết thành công với Ethereum, cả hai chân của gói phải được thực thi đúng. Nếu một trong hai bên thất bại, thì các khối sẽ không hợp lệ và không thể giải quyết được. Điều đó có nghĩa là nếu giả sử trình sắp xếp được chia sẻ đã ký vào một khối mà ETH không bị đốt trên R_mộtnhưng đã tạo ra eth trên r_b, sau đó khối đó sẽ bị reorged. điều này đảm bảo an toàn của tất cả các chuỗi và ngăn chặn các hành động không trung thực giữa các chuỗi khỏi được giải quyết.

Có hai điểm cần nhớ liên quan đến các reorgs này:

• Chúng sẽ cực kỳ ngắn vì chúng sẽ được phát hiện và chứng minh ngay lập tức.
• Chúng chỉ có thể xảy ra nếu người phối hợp (ví dụ, người sắp xếp và/hoặc người xây dựng) của chuỗi mà bạn đang kết nối đang hoạt động một cách ác ý.

Những reorgs này phải cực kỳ hiếm và tối thiểu do các điểm trên, nhưng vì điều này, các chuỗi tổng hợp sẽ có toàn quyền kiểm soát chuỗi nào họ muốn sáng tác theo nguyên tử và theo giả định tin cậy nào. Ví dụ: R_acó thể chấp nhận trạng thái chuỗi từ r_b để sáng tác dựa trên sự đồng thuận của người sắp xếp thứ tự của họ, nhưng đối với r_cnó có thể yêu cầu cung cấp một bằng chứng, và đối với r_dCó lẽ họ muốn đảm bảo an toàn kinh tế tiền điện tử cho tất cả các phụ thuộc nguyên tử liên chuỗi. Mỗi chuỗi có thể tùy chỉnh các thương mại đổi mới của riêng mình ở đây cho độ trễ thấp và độ sống còn. Agglayer chỉ cung cấp nền tảng linh hoạt nhất và ít chủ quan nhất cho các chuỗi để có tương tác an toàn giữa chuỗi.

Bạn cũng có thể nhìn thấy tại sao một thiết kế như vậy trong thực tế không tương thích với một thiết kế dựa trên khả năng chống lỗi. Lý thuyết họ có thể làm điều này, nhưng trong trường hợp đó, có thể trải qua các vụ tái cấu trúc sâu đậm. Việc chứng minh và giải quyết tất cả các chuỗi nhanh giúp giới hạn trường hợp tồi nhất rất ngắn, đồng thời cũng là một rào cản tự nhiên đối với bất kỳ nỗ lực xấu xa nào.

cách ly lỗi cho các provers không đồng nhất

Quan trọng nhất, agglayer cho phép duy nhất kết hợp các chuỗi hoàn toàn không đồng nhất. Bạn có thể có một aggchain với bất kỳ vm tùy chỉnh, prover, da layers, vv. trong khi an toàn chia sẻ một cầu nối với mọi người.

nhưng điều này làm sao có thể thực hiện được? Lý do mà điều này thường không được chấp nhận là vì một người tham gia bị lỗi (ví dụ, với một lỗi mạch) thông thường chỉ có thể lừa đảo một cầu và làm cạn kiệt tất cả các quỹ. Nhưng đó là lúc bằng chứng kế toán liên mạch được đề cập ở trên đến. Những bằng chứng này đảm bảo rằng các nguyên tắc cầu được tôn trọng, để ngay cả trong trường hợp một bằng chứng không đáng tin, chỉ có thể rút tiền từ các quỹ đã gửi vào chuỗi bị ảnh hưởng. Lỗi hoàn toàn được cô lập.

độc lập đáng tin cậy

loại hạ tầng này được hưởng lợi rất nhiều từ tính trung lập đáng tin cậy, đó là lý do tại sao Mã nguồn hoàn toàn mã nguồn mở của Agglayer là lãnh thổ trung lập. Trong một tinh thần tương tự, Agglayer sẽ sử dụng ETH làm mã thông báo gas duy nhất để trả phí cho việc tổng hợp bằng chứng.

Nó chắc chắn không hoàn hảo mặc dù. Đặc biệt là khi bắt đầu, nó sẽ không hoàn toàn trung lập một cách đáng tin cậy. Có khả năng nâng cấp hợp đồng trên con đường dẫn đến bất biến cuối cùng và được coi là hàng hóa công cộng.

Nói như vậy, nó không cần phải hoàn toàn trung lập đáng tin cậy, không có gì là hoàn hảo. (chúng ta sẽ thấy điều này một lần nữa dưới đây với based rollups.) Trong thực tế, nó cung cấp có lẽ là tầm nhìn cạnh tranh kỹ thuật hấp dẫn nhất và nó có một thái độ tối giản có chủ ý đối với việc đóng băng và khai thác thuê. Mục tiêu là cho phép aggchains duy trì nhiều chủ quyền nhất có thể, trong khi vẫn có khả năng trừu tượng hóa khả năng sáng tạo giữa các chuỗi đảm bảo tối thiểu niềm tin.

aggchains không cần bất kỳ vm cụ thể nào, môi trường thực thi, bộ xử lý tuần tự, lớp da, token staking, token gas hoặc quản trị chung. Các chuỗi có thể rời đi khi muốn. Không có yêu cầu chia sẻ doanh thu. Bạn không cần triển khai như một l3 trên chuỗi của người khác.

Lý do để khởi chạy L3 trên L2 nói chung chủ yếu theo quan điểm của tôi là hỗ trợ băng tần trong khi các kiến trúc tương tự như Agglayer đang được xây dựng. Tuy nhiên, để rõ ràng, đó là một lý do hoàn toàn hợp lệ để khởi chạy chúng ngày hôm nay. V1 Agglayer chỉ là một hợp đồng cầu nối chia sẻ đơn giản. Phiên bản 2 với tổng hợp bằng chứng và khả năng có được Interop độ trễ thấp an toàn thậm chí không hoạt động. Bạn không thể mong đợi mọi người chờ đợi trong nhiều năm khi họ có một sự khẩn cấp để vận chuyển một thứ ngày hôm nay sẽ giúp họ phân phối nhanh nhất.

Chứng minh thời gian thực

Mặc dù vài năm nữa không thực tế trong bất kỳ cài đặt độ trễ thấp nào, chúng ta nên lưu ý rằng chứng minh thời gian thực cũng có thể được sử dụng cùng với trình tự được chia sẻ để đảm bảo an toàn chuỗi chéo. Nó cũng rất tuyệt, vì vậy chúng tôi sẽ đề cập ngắn gọn. Cụ thể hơn, chứng minh "thời gian thực" đề cập đến việc chứng minh thời gian ngắn hơn thời gian khe cắm của chuỗi được đề cập. Hãy xem xét lại ví dụ về cầu đúc và đốt chuỗi chéo:

• chúng tôi có hai rollup (r_mộtvà r_b) chia sẻ cùng một bộ đếm lười
• Tôi muốn sử dụng cầu đốt và đúc giữa ra → rb đồng thời đốt trên ra và đúc trên rb
• người xây dựng siêu hạng tạo ra một khối chéo chuỗi bao gồm một bó giao dịch chéo chuỗi này. bên trong các khối, người xây dựng bao gồm một chứng minh về việc chuyển đổi trạng thái đang được bao gồm trên rollup khác.

chúng ta đã có sự đảm bảo của bộ xử lý chia sẻ về việc bao gồm gói tổ hợp nguyên tử đồng bộ, và bây giờ mỗi hợp đồng có thể xác minh bằng chứng về trạng thái của chuỗi khác để biết rằng nó sẽ được thực thi thành công.

Để chứng minh thời gian thực, lý tưởng nhất là chúng tôi muốn thời gian chứng minh chỉ là một phần nhỏ trong tổng thời gian khe cắm, do đó tối đa hóa "cửa sổ đồng bộ". Đây là phần thời gian khe mà bạn có thể xử lý các giao dịch sẽ hoạt động đồng bộ chuỗi chéo, vì bạn cần ngân sách đủ thời gian trong khe để tạo bằng chứng và đưa nó vào khối.

nguồn:Justin drake, chứng minh thời gian thực

lưu ý rằng chúng ta sẽ kết hợp hoặc kết hợp nhà xây dựng và nhà chứng minh một cách ngầm định ở đây. có một động cơ rõ ràng cho nhà xây dựng tối ưu hóa tốc độ chứng minh để họ có thể xây dựng đến phút cuối cùng và đưa nhiều thứ nhất có thể vào khối của họ.

nguồn:Justin drake, chứng minh thời gian thực

nếu khuyến nghị cao này cho chứng minh thời gian thực trở thành hiện thực trong những năm tới, chúng ta cũng cần lưu ý rằng điều này tất nhiên không thân thiện với việc chứng minh phi tập trung. những người chứng minh sẽ cần tập trung tương đối khi họ hợp nhất hoặc đặt chung với những người xây dựng.

Tóm tắt

Sự tương thích đồng bộ toàn cầu thực sự rất tuyệt vời, nhưng không rõ ràng lắm về giá trị thực sự của nó. Internet hoạt động theo cách không đồng bộ và bạn sẽ không bao giờ biết điều đó. Điều đó bởi vì nó nhanh chóng và sự phức tạp đã được trừu tượng hóa. Đó là tất cả những gì người dùng muốn.

Tôi hy vọng rằng hầu hết các giá trị của việc sử dụng một cái gì đó như Agglayer sẽ không chỉ nằm trong cài đặt đồng bộ. Thay vào đó, thực tế là nó có thể hoạt động như một hình thức trừu tượng hóa chuỗi cuộn chéo. Làm cho nhiều chuỗi cảm thấy giống như một với các khía cạnh đối mặt với người dùng quan trọng hơn (ví dụ: nhiều tài sản gốc có thể thay thế hơn, chức năng ứng dụng chuỗi chéo nguyên bản, khả năng tương tác nhanh, v.v.).

Tính kết hợp đồng bộ rõ ràng có giá trị tài chính (ví dụ, cho phép thanh lý, cơ hội arbitrarge hiệu quả hơn, tái cấu trúc hiệu quả hơn bằng cách sử dụng các khoản vay flash). Tuy nhiên, tương tự như cách Internet là không đồng bộ và vẫn hoạt động tốt, tradfi tất nhiên cũng là không đồng bộ. Chúng ta có lý do muốn trở nên tốt hơn cả tradfi, nhưng chúng ta cần phải rõ ràng rằng sự đồng bộ toàn cầu không phải là yêu cầu cho việc thực hiện tốt. Việc xây dựng và cung cấp cơ sở hạ tầng đồng bộ cũng mang lại chi phí thực tế.

Cá nhân tôi nghĩ rằng lập luận tốt nhất ủng hộ việc cần USC là trong thực tế, nó dẫn đến UX và Devex tốt hơn. Không thể phủ nhận lợi ích to lớn mà điều này mang lại cho các hệ sinh thái như Solana. Tuy nhiên, đây hy vọng là một vấn đề ngày nay chứ không phải là một vấn đề mãi mãi.

Thực tế đơn giản của vấn đề là nó cũng hơi khó để bất cứ ai lý luận ở giai đoạn này. Đây không phải là nhị phân "Mọi thứ trong tiền điện tử đều đồng bộ" hoặc "Mọi thứ đều không đồng bộ". Tôi nghĩ về cơ bản chúng ta sẽ cần phải giải quyết và hướng tới cái sau, nhưng cả hai đều có thể tồn tại trên cơ sở đặc biệt.

Bản tổng hợp dựa trên Ethereum

OK, vì vậy bây giờ chúng ta nên có một ý tưởng tốt về không gian giải pháp để giải quyết sự phân mảnh trong các bản tổng hợp. Câu hỏi tiếp theo là làm thế nào chúng ta nên liên quan đến lớp cơ sở trong tất cả những điều này? Vai trò của Ethereum ở đây là gì?

Chúng tôi sẽ sử dụng các viết tắt sau đây trong suốt quá trình:

• bl - tầng cơ sở
• dựa trên br - rollup
• preconfs - xác nhận trước

Trừ khi có ghi chú khác, bl trong câu hỏi mà chúng ta sẽ thảo luận là ethereum, và brs là ethereum brs. Tuy nhiên, các khái niệm cơ bản áp dụng rộng rãi vì bạn có thể triển khai brs ở bất kỳ đâu.

cuộn dựa trên vanilla

các phiên bản ban đầu của rollup đã được triển khai vài năm trước đây thực sựdự định được brsnhưng đãbị bỏ bê để chọn lọc các trình tự trung tâm cho độ trễ thấp và hiệu quả cao. những gì chúng ta gọi ngày nay là chuỗi dựa trên, vitalik đã đề cập đến như là “hỗn loạn tuyệt đối“vào thời điểm đó, trước khi cơ sở hạ tầng pbs tiên tiến của ethereum phát triển (với các nhà xây dựng tinh vi), nó khá không thực tế và không hiệu quả.

Sau đó, vào tháng 3 năm 2023, brs đã trở lại tầm với của công chúng.nơi chúng được xác định như sau:

"một rollup được cho là dựa trên, hoặc có thứ tự l1, khi sự xếp hàng của nó được điều khiển bởi l1 cơ bản. Cụ thể hơn, một rollup dựa trên là một nơi mà người đề xuất l1 tiếp theo có thể, phối hợp với người tìm kiếm và xây dựng l1, một cách không cần sự cho phép, bao gồm khối rollup tiếp theo như một phần của khối l1 tiếp theo."

họ nên cung cấp những lợi ích sau đây:

“sự xếp hàng của những rollup như vậy - sự xếp hàng dựa trên - là tối đa đơn giản và kế thừa sự sống và phân tán l1. Hơn nữa, rollup dựa trên đặt dựa đặc biệt kinh tế phù hợp với l1 cơ sở của chúng.

Cụ thể, bạn nhận được tính an toàn thời gian thực của ethereum:

“Bạn thừa hưởng tính kháng kiểm duyệt và tính sống còn của Ethereum. Vì vậy, bạn không chỉ có đảm bảo thanh toán của Ethereum mà còn có tính kháng kiểm duyệt, tính kháng kiểm duyệt thời gian thực, không phải là phần trốn thoát trễ hẹn mà bạn biết, mà là kháng kiểm duyệt thời gian thực.”

Là một dạng rollup dựa trên thiết kế logic khi bạn đã chọn một lớp cơ sở:

"ethereum đang tối đa hóa cho hai tính chất này, an ninh và tính trung lập đáng tin cậy, nó gần như là định nghĩa của một rollup đúng không... một rollup là cái đã chấp nhận giả định an ninh của ethereum. Bạn không thêm vào một giả định an ninh mới. Bạn không rơi vào một điểm yếu. Bạn chỉ đang tái sử dụng giả định an ninh hiện có. Và hai là bạn đã chấp nhận ethereum là một nền tảng trung lập đáng tin cậy nếu không bạn đã chọn một chuỗi khác. và bây giờ bạn có thể tự hỏi tại sao mọi người không chỉ sử dụng việc xếp chồng lớp một?"

ở dạng đơn giản nhất, brs chắc chắn có thể đạt được các mục tiêu thiết kế trên. nếu rollup không thực hiện bộ liên tục của riêng mình, thì ngầm hiểu người đề xuất ethereum hiện tại sẽ quyết định những gì sẽ được bao gồm mỗi 12s (thời gian slot của ethereum).

tuy nhiên, việc sắp xếp dựa trên vẫn đi kèm với những sự đánh đổi, đó chính xác là tại sao rollups thường thực hiện bộ định thứ riêng của họ:

• Người dùng rollup không muốn đợi 12s+ cho các khối Ethereum - fast preconfs.
• preconfs an toàn - đôi khi các khối ethereum có thể bị reorg, vì vậy người dùng phải chờ thêm thời gian để an toàn, điều này người dùng cũng không thích. sequencers có thể cung cấp preconfs không phụ thuộc vào các khối ethereum chưa hoàn thành và do đó không cần phải reorg ngay cả khi ethereum chính nó gặp phải một reorg ngắn.
• Đăng hàng loạt hiệu quả - Trình sắp xếp chuỗi có thể phân lô rất nhiều dữ liệu, nén nó và định kỳ đăng nó lên BL theo cách tối ưu hóa chi phí (ví dụ: đảm bảo sử dụng đầy đủ blob).

dựa trên rollups + preconfs

Vậy, chúng ta có thể có bánh của mình và ăn nó luôn chứ?dựa trên preconfs.

Chúng tôi sẽ giải thích ý nghĩa đằng sau việc dựa trên preconfs ở đây một cách tương đối ngắn gọn để chúng ta có thể so sánh brs + preconfs với rollups truyền thống. Sau này, chúng ta sẽ quay lại để phân tích preconfs một cách chi tiết hơn nữa (nghĩa là cả br preconfs và bl preconfs trên giao dịch ethereum l1).

Ý tưởng cốt lõi là các preconfs BR phải đến từ những người đề xuất BL. Để cung cấp preconfs, những người đề xuất này phải đưa ra một số tài sản thế chấp (ví dụ: restaking) và chọn các điều kiện cắt giảm bổ sung (tức là, các preconfs mà họ cung cấp thực sự sẽ làm cho nó onchain như đã hứa). Bất kỳ người đề xuất nào sẵn sàng làm như vậy đều có thể hoạt động như một trình tự BR và cung cấp các tiền đề xuất.

chúng ta nên lưu ý rằng các người đề xuất (tức là các nhà xác thực) thực sự được mong đợi để giaoDelegGate.io vai trò này của việc cung cấp preconfs cho các thực thể chuyên biệt hơn được biết đến là "Gate.ioways". việc phát ra preconfs sẽ đòi hỏi một thực thể tương đối phức tạp, và ethereum muốn giữ cho các người đề xuất không tinh vi.

Tuy nhiên, dự kiến các relay hiện có sẽ tiếp quản vai trò này. Cổng Gate.io chỉ giao tiếp giữa người dùng và relay, vì vậy thêm một thực thể độc lập chỉ làm tăng độ phức tạp và độ trễ (tuy nhiên độ trễ cũng có thể được giải quyết với việc đặt cùng chỗ). Relay đã được xây dựng và đề xuất, nên chúng ta sẽ thêm yêu cầu tin cậy khác đối với người dùng ở đây.

lưu ý rằng trong khi các trình xác thực hiện tại đóng vai trò nhà cung cấp khối ethereum, có sự xem xét cho một bản nâng cấp mà giao thức chính nó sẽ trực tiếp đấu giá quyền đề xuất quađấu giá thực hiện. Điều này sẽ cho phép các thực thể tinh vi mua trực tiếp quyền đề xuất, do đó tránh cần phải ủy quyền lại cho các validator (những người đề xuất hiện tại) đến Gate.io như được xem xét ở đây.

Trong mọi trường hợp, điểm quan trọng là bất kỳ preconf nào nhanh hơn sự đồng thuận của Ethereum (12 giây) đều yêu cầu một bên thứ ba tin cậy (ttp). Cho dù ttp của bạn là một nhà xác minh đã đặt cược lại, đã đặt cược Đấu giá thi hành ánNgười chiến thắng, người đại biểu.iod Cổng.ioway, hoặc bất cứ điều gì khác - điều này về cơ bản không thể cung cấp bảo mật Ethereum thời gian thực. Cho dù coinbase đang cung cấp cho bạn một “tiền đề dựa trên” như một người đề xuất Ethereum hoặc một “tiền đề truyền thống” như một người trình tự Rollup - bạn đang tin tưởng vào coinbase. Họ cũng có thể đặt một khoản ký quỹ của một số eth, nhưng trong cả hai trường hợp này đều độc lập với bảo mật của sự đồng thuận của Ethereum.

Chúng ta nên nhận thấy rằng bất kỳ thiết kế trước đó nào cũng nhất thiết phải làm giảm đi từ mục tiêu được nêu ra của brs mà chúng ta bắt đầu với (sự đơn giản và an ninh bl).Các tiền xử lý dựa trên nguồn ngày càng phức tạp hơn, và họ không thể cung cấp các cam kết bảo mật thời gian thực của ethereum.

tuy nhiên, bạn nên giữ được khả năng buộc một giao dịch trực tiếp thông qua một giao dịch bl nếu những người tiền xử lý này tắt máy hoặc bắt đầu kiểm duyệt. những cam kết từ ethereum nên trở nên mạnh mẽ hơn khi danh sách bao gồmđược thực hiện.

Đối với brs - ttps cung cấp preconf nhanh chóng, và bl cung cấp bảo mật cuối cùng.

non-based rollups + based fallback

Bây giờ hãy xem xét một rollup truyền thống (tức là không phụ thuộc). Sequencer riêng của nó (dù là tập trung hoặc phi tập trung) cung cấp các giao dịch xác nhận trước nhanh chóng. Sau đó, người dùng của họ nhận được bảo mật đầy đủ của Ethereum theo một khoảng thời gian trễ. Điều này bao gồm tính sống còn (tăng trưởng sổ cái + kháng cáo cấm) được đảm bảo từ một loại hệ thống nào đó. bắt buộc bao gồmhoặcBL fallbackcơ chế.

như tôi đã ghi chú trong Các rollup có kế thừa tính bảo mật không?:

Rollups có khả năng tiết lộ các quy tắc xác nhận với các thuộc tính bảo mật tương đương như chuỗi chủ. Họ có thể nhận các thuộc tính này tốt nhất ở tốc độ của sự đồng thuận của chuỗi chủ của họ (và trong thực tế thì thường chậm hơn một chút tùy thuộc vào tần suất mà rollup đăng lên chuỗi chủ).

Rollups cũng có thể cung cấp một quy tắc xác nhận lỏng lẻo hơn (tức là, các máy tính thứ tự) để cải thiện trải nghiệm người dùng tốt hơn, nhưng vẫn giữ lại phương án dự phòng trong trường hợp xảy ra sự cố. Nếu máy tính thứ tự của bạn dừng lại, bạn vẫn có thể tiếp tục di chuyển.

lưu ý rằngthời gian đến an ninh cuối cùnglà biến số quan trọng để tối ưu ở đây:

Giả định rằng người dùng rollup có thể quay trở lại tính sống động tương đương với chuỗi máy chủ cho rằng bạn có thể bắt buộc bao gồm chính xác tốc độ các khối của chuỗi máy chủ (ví dụ, nếu người xếp hạng rollup đang kiểm duyệt bạn, bạn có thể bắt buộc bao gồm giao dịch trong khối ethereum tiếp theo).

Trong thực tế, thường có một khoảng thời gian chờ ngắn. Nếu bạn cho phép việc bao gồm bắt buộc ngay lập tức, bạn có thể tiết lộcensorship MEV sinh lợitrong số những phức tạp khácTuy nhiên, có các thiết kế có thể cung cấp cam kết sống thời gian thực gần nhưtừ chuỗi máy chủ (ví dụ, có thể ở tốc độ của vài khối chuỗi máy chủ thay vì một khối).

theo tinh thần này, Sovereign labs có một thiết kế làm những việc sau đây:

• xếp hàng có quyền - rollups thiết lập một người lập lịch có quyền hạn, giao dịch của họ được xử lý ngay khi được bao gồm trong khối. vì họ có khóa ghi trên trạng thái của rollup, họ có thể cung cấp các giao dịch xác nhận trước đáng tin cậy nhanh hơn thời gian khối bl.
• dựa trên chuỗi - người dùng cũng có thể gửi giao dịch trực tiếp vào bl của họ, nhưng chúng được xử lý với độ trễ n block (trong đó n đủ nhỏ). Điều này giúp giảm đáng kể "thời gian để đảm bảo bảo mật cuối cùng", và thực tế họ còn gọi thiết kế đó là "dựa trên chuỗi với xác nhận mềm" vì vậy! (lưu ý rằng định nghĩa này của brs sẽ xung đột với định nghĩa chúng tôi đã cung cấp trước đó, tức là người đề xuất bl phải có quyền sắp xếp br hoặc được ủy quyền bởi họ.)

Đối với người không sử dụng BRS - TTPS cung cấp preconfs nhanh chóng và bl cung cấp an ninh dần dần.

Ý Thọ?

như chúng ta có thể thấy, cả hai con đường được mô tả ở trên sau đó tạo ra cùng một kết quả hiệu quả:

Những brs này với preconfs không còn cung cấp tính đơn giản hoặc bảo mật thời gian thực của ethereum. Vậy điều này còn đáng để làm gì nữa? Tại sao chúng ta không chỉ tập trung vào việc cải thiện fallbacks trên “traditional” rollups? Wtf thậm chí là một “based rollup” tại thời điểm này?

điều này thực sự quay trở lại với tôiBằng chứng của quản trị Bài đăng từ năm ngoái, nơi tôi đã thảo luận về các trường hợp sử dụng cơ bản để chuyển đổi dành riêng cho Ethereum:

1) kỹ thuật (cam kết của người đề xuất) - không có cách nào khác - nếu bạn muốn một cam kết đáng tin cậy đối với việc sắp xếp một khối ethereum, nó phải đến từ các nhà xác minh ethereum.MEV-Boost++là một ví dụ về một ứng dụng giả thuyết có thể rơi vào hạng mục này.

2) Xã hội - Tôi xem sự liên kết Ethereum là trường hợp sử dụng chính cho hầu hết các ứng dụng tái sử dụng hiện nay, không phải là tổng hợp bảo mật kinh tế hoặc phân cấp. Nó đang được nói "Hãy nhìn xem, chúng tôi là một dự án Ethereum!” Đó là lý do tương tự vì sao các chuỗi tiếp tục gọi chính họ là ethereum l2sbất kể kiến trúc.

Chúng ta có thể hiện đại hóa điều này trong bối cảnh đặt câu hỏi giá trị của "br + preconfs" so với "rollup truyền thống + dự phòng nhanh" là gì?

1) Kỹ thuật (Cam kết của người đề xuất) - Ethereum BRS với preconfs có một lợi ích kỹ thuật cơ bản - họ có thể nhận được cam kết đáng tin cậy từ người đề xuất Ethereum hiện tại về việc bao gồm và sắp xếp thứ tự nội dung của khối Ethereum. Điều này có khả năng có giá trị vì những lý do chính xác tương tự mà chúng tôi có thể muốn một loạt các bản tổng hợp để chia sẻ một trình sắp xếp. Nếu người đề xuất BL cũng là người đề xuất BR (tức là bộ sắp xếp), thì họ có thể cung cấp các đảm bảo bao gồm nguyên tử tương tự với BL như bạn có thể nhận được giữa bất kỳ bản tổng hợp nào chia sẻ bộ sắp xếp. Họ có độc quyền trên cả hai chuỗi. Bây giờ, điều này có giá trị như thế nào? Chúng ta sẽ quay lại vấn đề đó một chút.

2) xã hội (căn chỉnh / tính trung lập đáng tin cậy) - yêu hay ghét nó, Căn chỉnh Ethereum là một điểm bán hàng để trở thành một br. Thành thật mà nói, tôi không biết nhiều về Taiko ngoài "Họ là những người BR", và có lẽ tôi sẽ không biết họ là ai nếu họ không phải là BR. Mọi người đều muốn một số đồng tiếp thị tốt. Có giá trị để trở thành những người di chuyển đầu tiên ở đây, nhưng tôi nghi ngờ đây không phải là một chỗ dựa giá trị lâu dài và không mang lại cho nhiều BRS tiềm năng trong tương lai. Tương tự, tất cả chúng ta đều nghe nói về số ít AVS đầu tiên, nhưng bạn có thể kể tên tất cả những cái hiện tại không? Tôi không thể.

Ở cấp độ cao hơn, bạn sẽ không nhận được tất cả các bản tổng hợp Ethereum để chọn tham gia (giả thuyết) "Trình sắp xếp chia sẻ lạc quan" hoặc "Trình sắp xếp chia sẻ tùy ý". Mặc dù vậy, bạn có một cơ hội tốt hơn để khiến tất cả họ chọn tham gia vào "Trình sắp xếp chia sẻ Ethereum". Không có mã thông báo mới, không có thương hiệu mới, không có sự đồng thuận mới. Nếu bạn nghĩ rằng nó có giá trị đối với tất cả các Ethereum L2 để hợp nhất về trình tự, thì tính trung lập đáng tin cậy này có khả năng là điểm mạnh nhất để đạt được mục tiêu đó.

Sự trung lập đáng tin cậy này có lẽ quan trọng nhất đối với những nhà phát triển rollups cố gắng thu hút người dùng qua các hệ sinh thái (ví dụ, ứng dụng với cơ sở hạ tầng cơ bản như ens). họ có thể do dự khi sử dụng trình xếp hàng optimism nếu nó làm xa lánh người dùng arbitrum, hoặc ngược lại.

chúng tôi sẽ bao quát từng phần trong chi tiết hơn ở dưới đây.

tính trung lập đáng tin cậy

Đi sâu hơn vào điểm xã hội đó, BRS thường được xem là tùy chọn "Ethereum Aligned" tối đa. Bỏ qua đánh giá của bất kỳ ai về giá trị của điều này, điểm quan trọng là điều này giả định mức độ trung lập đáng tin cậy cao cho bất kỳ thiết kế BR nào.

Một br trung lập đáng tin cậy dễ thiết kế trong trường hợp nguyên chất, nhưng như chúng ta đã lưu ý, không ai thực sự muốn những thứ đó. Do đó, preconfs bắt buộc người đề xuất phải chọn vào các điều kiện cắt giảm bổ sung. Các điều kiện cắt giảm bổ sung này yêu cầu người đề xuất sử dụng một hệ thống bổ sung nào đó (ví dụ, có thể là eigenlayer restaking,Symbiotic, hoặc một tiêu chuẩn khác) để cam kết. Một rollup có thể tự hào lựa chọn vào “ethereum sequencer” có uy tín trong trừu tượng, nhưng uy tín có thể bị mất nếu bạn sử dụng các dự án được tài trợ riêng, có thể thậm chí còn có token riêng của chúng.

Có một số câu hỏi mở về tài sản đảm bảo ở đây:

kích thước tài sản đảm bảo

các thiết kế sớm đã cho rằng người đề xuất sẽ phải đặt một số tiền đặt cọc rất cao khoảng 1000 eth. vấn đề là ở chỗ một cách cơ bản, người đề xuất luôn có thể từ bỏ lời hứa với DeleGate.io và tự xây dựng một khối, mâu thuẫn với các preconfs. điều này có thể rất có giá trị, và 1000 eth thoải mái vượt trội so với các khoản thanh toán cao nhất từng được quan sát thông qua mev-boost kể từ khi nó ra đời. Hạn chế là điều này tất nhiên tạo ra một rào cản cao đối với người đề xuất nhỏ hơn, trong khi người đề xuất lớn hơn (ví dụ, coinbase) có thể đặt ra 1000 eth một cách hợp lý hơn trong khi kiếm được phần thưởng trên tất cả trọng lượng cổ phần của họ>13% tổng số eth được đặt cược) bởi vì người đăng ký có thể đặt một liên kết duy nhất cho tất cả các trình xác thực của họ. có Những ý tưởng khác để cho phép người đề xuất với khoản tiền đặt cọc nhỏ hơn nhiều.Tuy nhiên, đương nhiên đi kèm với những điều đổi đái. không gian thiết kế ở đây chỉ là không chắc chắn.

Đáng chú ý rằngđấu giá thực hiệnđiều này sẽ giảm bớt lo ngại này, vì chúng ta có thể giả định rằng tất cả những người đề xuất sau đó sẽ là những người chơi giàu kinh nghiệm dễ dàng có khả năng này.

nguồn:Barnabé monnot, từ mev-boost đến epbs đến aps

Tuy nhiên, ngay cả các nhà điều hành lớn cũng do dự để đặt số lượng lớn, vì nguy cơ vấn đề liveness dẫn đến slashing (một vấn đề liveness xảy ra với một nhà điều hành, gây ra sự thất bại của preconfs của chúng tôi rồi sau đó họ bị mất trước khi được bao gồm vào một khối, là một sự thất bại về an toàn đối với người dùng và cần phải bị phạt nặng).

loại tài sản đảm bảo

ETH vanilla có lẽ là tài sản thế chấp trung lập đáng tin cậy duy nhất trong tình huống này. Tuy nhiên, tự nhiên sẽ có mong muốn sử dụng tài sản hiệu quả vốn hơn (ví dụ, steth). Có một số ý tưởng để một người bảo lãnh xử lý việc chuyển đổi này, như mô tả bởi MTEAMở đây.

nền tảng

nếu các “preconfs dựa trên ethereum” giống hơn với các “preconfs dựa trên eigenlayer” hoặc “preconfs dựa trên symbiotic” thì điều này sẽ không được coi là “trung lập đáng tin cậy”. Có những đội đang lên kế hoạch đi theo hướng này, nhưng không phải là yêu cầu nghiêm ngặt để sử dụng nền tảng như vậy. Có thể tạo ra một tiêu chuẩn chung và trung lập cho mọi người sử dụng, và hệ thống như vậy sẽ có vị trí tốt hơn để được chấp nhận chung nhất.

Việc áp dụng tiêu chuẩn hàng hóa công cộng sẽ cần thiết để các thiết kế trước khi hội đủ điều kiện để trở nên “đáng tin cậy và trung lập.”

preconfirmations

sự bao gồm so với tiền cài đặt trạng thái

bây giờ chúng tôi sẽ nói chi tiết về preconfs. trong khi chúng tôi đã thảo luận về một loại cụ thể của preconf trước đó (br preconfs trên trạng thái), chúng tôi phải lưu ý rằng chúng là một khái niệm hoàn toàn chung. bạn có thể cung cấp preconfs trên các giao dịch bl ngoài brs và bạn có thể cung cấp các mức độ preconfs khác nhau:

• Bao gồm tiền xử lý trước - một cam kết yếu hơn rằng giao dịch sẽ cuối cùng được bao gồm trên chuỗi.
• state preconfs - cam kết mạnh nhất rằng giao dịch sẽ được bao gồm trên chuỗi và đảm bảo trạng thái kết quả.

điều sau (trạng thái preconfs) chính là điều mà người dùng muốn ví của họ hiển thị cho họ:

Tôi đã đổi 1 eth thành $4000 usdc và trả 0.0001 eth cho phí

Không bao gồm preconfs:

Giao dịch của tôi cố gắng trao đổi 1 eth thành $4000 usdc và trả tối đa 0.0001 eth cho phí sẽ cuối cùng được thực hiện trên chuỗi, nhưng có thể thành công, có thể thất bại, chúng ta sẽ thấy

Tuy nhiên, chúng ta nên lưu ý rằng inclusion preconfs có thể thay thế được bằng state preconfs trong trường hợp các hoạt động của người dùng được thực hiện trên trạng thái không gây tranh cãi (ví dụ: các giao dịch đơn giản nơi chỉ có người dùng chính họ có thể vô hiệu hóa giao dịch). Trong trường hợp này, lời hứa rằng ví dụ như “việc chuyển usdc của Alice đến Bob sẽ được bao gồm trong vài khối tiếp theo” là đủ tốt để ví tiền chỉ cho người dùng “bạn đã gửi usdc của mình đến Bob”.

Không ngạc nhiên rằng, các cam kết mạnh hơn (preconfs nhà nước) khó có được. Thực sự, chúng yêu cầu một cam kết đáng tin cậytừ thực thể hiện tại đang độc quyền đề xuất các khối (tức là, một khóa ghi trên trạng thái chuỗi). trong trường hợp của ethereum l1 preconfs, đây luôn là người đề xuất ethereum l1 hiện tại. trong trường hợp của br preconfs, đây có lẽ là người đề xuất ethereum l1 tiếp theo trong tương lai của br (do đó làm cho họ trở thành người đề xuất hiện tại cho br), như chúng ta sẽ thấy ở dưới. người đề xuất và sequencer thường là các thuật ngữ có thể thay thế, với thuật ngữ đầu tiên thường được sử dụng nhiều hơn trong ngữ cảnh l1 và thuật ngữ thứ hai trong ngữ cảnh l2.

định giá trước

một sự phân biệt quan trọng khác chúng ta cần phải làm là loại trạng thái mà những preconfs này đang chạm đến:

• trạng thái không gây tranh cãi - không ai khác cần truy cập vào trạng thái này (ví dụ, alice muốn chuyển usdc cho bob)
• trạng thái tranh cãi - người khác muốn truy cập vào trạng thái này (ví dụ: trao đổi trong một hồ bơi eth/usdc amm)

preconfs là ràng buộc về việc khối có thể cuối cùng được tạo ra. tất cả những điều còn lại bằng nhau, việc hạn chế không gian tìm kiếm cho người xây dựng một cách bẩm sinh chỉ có thể giảm giá trị tiềm năng mà họ có thể thu được từ việc sắp xếp nó. điều đó có nghĩa là giá trị ít hơn sẽ được trả cho người đề xuất. để làm cho nó phù hợp với động cơ, cổng.ioway cần thu phí preconf ≥ giá trị mev tiềm năng bị mất từ việc hạn chế kết quả.

Điều này đơn giản đủ khi mất MEV là ~0 (ví dụ, như trong một giao dịch USDC). Trong tình huống này, việc tính phí cố định nhỏ có thể hợp lý. Nhưng chúng ta có một vấn đề lớn - làm thế nào chúng ta định giá trước các trạng thái có tranh chấp? Định giá trước các trạng thái hay định giá theo thời gian thực dường như ít có lợi hơn. Các điều kiện còn lại như nhau, việc chờ đến phút cuối cùng để chiếm và định giá chính xác MEV là lợi nhuận nhất cho một nhà xây dựng.

Mặc dù vậy, hãy giả sử rằng có đủ nhu cầu của người dùng đối với các preconfs nhanh về trạng thái gây tranh cãi (xem xét cả người tìm kiếm tinh vi và người dùng normie), sao cho đôi khi sẽ có một mức giá thanh toán bù trừ có lợi cho tất cả mọi người. Bây giờ, làm thế nào để bạn định giá chính xác một preconf cho một giao dịch trên một phần trạng thái gây tranh cãi mà bạn có thể đưa vào bất kỳ thời điểm nào trong 12 giây tới, có khả năng bỏ qua các cơ hội sinh lời cao hơn mà sẽ không còn khả thi nữa?

việc phát trực tiếp các preconfs về trạng thái bị tranh chấp trong toàn bộ khối sẽ gây xung đột với cách các nhà xây dựng tạo khối. việc xác định giá trị chính xác của preconfs yêu cầu ước lượng tác động mev theo thời gian thực khi bao gồm nó ngay bây giờ thay vì trì hoãn, điều đó có nghĩa là thực hiện và mô phỏng các kết quả có thể có. điều đó có nghĩa là Gate.ioway bây giờ cần phải trở thành một công cụ tìm kiếm/xây dựng cực kỳ tinh vi.

chúng tôi đã giả định rằng Gate.ioway và relay sẽ sáp nhập. nếu họ cần liên tục định giá preconfs, thì họ cũng sẽ sáp nhập với builder. chúng tôi cũng chấp nhận rằng usc sẽ tăng tốc quá trình sáp nhập giữa builder và prover. có vẻ nhưĐấu giá thi hành ánsẽ bán quyền đề xuất trực tiếp cho các nhà hoạt động tinh vi (có thể là những người xây dựng) có khả năng định giá chúng.

Điều này đặt toàn bộ chuỗi cung ứng giao dịch Ethereum L1 và BR vào một hộp có khóa ghi độc quyền về trạng thái của tất cả các chuỗi trong khoảng thời gian đó.

Các chính sách đặt hàng của dịch vụ preconf không rõ ràng (ví dụ: họ luôn chạy FCF hay đặt hàng theo cách khác). nó cũng có khả năng cho Gate.ioway để chạy một cuộc đấu giá trên tất cả các preconfs (ví dụ: cho phép người tìm kiếm đặt giá thầu trên preconfs), mặc dù không rõ thiết kế như vậy sẽ trông như thế nào và nó nhất thiết có nghĩa là độ trễ cao hơn.

vấn đề trao đổi công bằng

Có vấn đề trao đổi công bằng với preconfs khi mà Gate.ioway không được khuyến khích trực tiếp để phát hành preconf.

xem xét ví dụ sau đây:

• cổng chuyển tiền hiện tại có độc quyền trong 12s
• một người dùng gửi một yêu cầu giao dịch trước khi xác nhận ngay từ đầu của khe (t = 0)
• Gate.ioway đợi cho đến t = 11.5 để phát hành tất cả các preconf họ đã tạo trong khe của họ, để lại một bộ đệm 500ms để có được tất cả chúng trong khối của họ. Tại thời điểm đó, họ có thể quyết định bao gồm những preconfs nào nếu chúng có lợi và những preconfs nào để loại trừ.

Trong trường hợp này, người dùng có thể kết thúc việc trả tiền cho preconf mặc dù họ không thực sự nhận được nó cho đến khi kết thúc khe. Gate.ioway cũng có thể bỏ nó ở cuối vị trí nếu họ quyết định đưa vào không có lãi. sự giữ lại này của Gate.ioway không phải là lỗi quy kết khách quan (nhưng có thể được gắn liền với chủ thể tương đối).

Trên thực tế, thực tế là có một động lực để Gate.io trì hoãn các giao dịch chờ xác nhận cho đến cuối cùng.Nơi nào có sự bất đối xứng thông tin, ở đó có mev. việc giữ giao dịch riêng tư sẽ cho phép người xây dựng có cái nhìn cập nhật hơn về tình hình thế giới, giúp họ định giá rủi ro tốt hơn và bắt giữ mev. không có sự đồng thuận về bộ preconfs được cung cấp cho người dùng, vì vậy Gate.ioway không thể chịu trách nhiệm ở đây.

Cần phải thiết lập tiêu chuẩn và kỳ vọng cho người xác nhận trước ngay lập tức công khai tin đồn tất cả các preconfs. điều này sẽ cung cấp cho người dùng những gì họ muốn ngay lập tức và cho phép những người khác thấy rằng Gate.ioway đang cung cấp các dịch vụ mong đợi. Nếu họ không làm như vậy trong tương lai, thì người dùng sẽ không tin tưởng họ và trả tiền cho họ cho preconfs. danh tiếng của Gate.ioway có giá trị. Điều đó đang được nói, nó cũng có thể là rất quý giáđể không trung thực ở đây và quay lại chống lại preconfs.

l1 cấp độ cơ sở preconfs

với những điểm chung được đề cập ở trên, chúng tôi sẽ bây giờ thảo luận về sự tinh tế của l1 preconfs. mặc dù chúng tôi không đề cập đến chúng trước đó, có các dự án xây dựng chúng, và sự tương tác của chúng với br preconfs sẽ quan trọng.

ví dụ,Boltlà một trong những giao thức nhằm cho phép các người đề xuất ethereum thực hiện các cam kết đáng tin cậy về nội dung khối của họ. Những người đề xuất đã đăng ký có thể chạy bolt sidecar để nhận yêu cầu trước từ người dùng, xác nhận chúng, sau đó gửi thông tin này cho các relay và builders có thể trả về các khối phù hợp với những ràng buộc này (tức là, để trả về một khối bao gồm các giao dịch mà người đề xuất đã cung cấp các yêu cầu trước).

điều quan trọng cần lưu ý ở đây là Bolt v1Mô tả ở đây chỉ hỗ trợ các giao dịch đơn giản được bao gồm sẵn trước cho trạng thái không gây tranh cãi nơi chỉ người dùng có thể vô hiệu hóa trước. Như chúng ta đã thảo luận trước đây, đây là những cam kết đơn giản nhất và yếu nhất để cung cấp.

Tất cả các nhóm trước đó đều có tham vọng lớn hơn (ví dụ như các preconfs của nhà nước, đấu giá khối một phần, đấu giá khe hoặc khe một phần), vậy điều gì đang cản trở họ?

• Trách nhiệm - vi phạm cam kết phải được chứng minh trên chuỗi để cắt giảm một cách khách quan. Việc chứng minh sự bao gồm giao dịch khá dễ dàng, nhưng không rõ ràng làm thế nào để thực thi các cam kết khác như đấu giá slot.
• yêu cầu vốn - việc cung cấp cam kết tùy ý có nghĩa là giá trị vi phạm cam kết có thể là vô cùng cao. Gate.ioways có thể sẽ cần đặt cược số lượng lớn (ví dụ: hàng ngàn eth) để cung cấp chúng. Các mức này có thể cuối cùng sẽ được hợp nhất, mang lại lợi ích cho các thực thể lớn nhất (ví dụ: các công ty giao dịch lớn hoặc coinbase) và bỏ qua các thực thể nhỏ hơn.
• giá cả - có rất nhiều câu hỏi mở về cách định giá một cái gì đó như trạng thái trước trực tuyến liên tục ngay cả khi chúng ta quyết định nó khả thi và có giá trị.
• Tham gia mạng - đây có lẽ là điểm quan trọng và cơ bản nhất. Như chúng tôi đã đề cập, chỉ có người đề xuất hiện tại có khóa ghi về nhà nước mới có thể cung cấp các cam kết như tiền đề nhà nước. Về lý thuyết, 100% người đề xuất có thể chọn tham gia vào hệ thống này và bắt chước điều này. Trong thực tế, điều đó sẽ không xảy ra.

MEV-Boost, một sản phẩm đơn giản hơn với nhiều năm theo dõi mang lại lợi nhuận đáng kinh ngạc để chạy, đã >92% sự tham giacho bối cảnh (có thể cao hơn một chút vì điều này không tính đếnmức chào thấp nhất). một dịch vụ preconf mới chắc chắn sẽ có tỷ lệ tham gia thấp hơn nhiều. nhưng ngay cả khi nó có thể đạt vào khoảng ~90%, điều này không có vẻ là một sản phẩm hữu ích cho người dùng thông thường. bạn không thể nói với người dùng 10% thời gian 'xin lỗi không có preconfs khả dụng ngay bây giờ, hãy quay lại sau.'

Ở mức tốt nhất, điều này cảm giác như trạng thái preconfs chỉ là một công cụ tùy chọn cho những người tìm kiếm và giao dịch viên tinh vi có thể muốn có cam kết sớm hơn trong khối khi khe đó có người đề xuất tham gia. điều đó có thể có giá trị, nhưng không có sự phân mảnh hoặc mở khóa ux ở đây.

preconfs dựa trên l2 rollup

br preconfs phải đến từ những người đề xuất bl (đó là lý do họ được gọi là "dựa vào"). điều này yêu cầu họ đặt cọc một số tài sản và chọn thêm các điều kiện trừ cắt (tức là, các preconfs họ cung cấp sẽ thực sự được đưa vào chuỗi như đã hứa). bất kỳ người đề xuất nào sẵn lòng làm như vậy đều có thể làm một br sequencer và cung cấp preconfs.

Điều quan trọng, những preconfs BR này là preconfs nhà nước không chỉ bao gồm peconfs. điều này là có thể bởi vì BRS đang chọn tham gia vào một thiết kế nơi họ trao độc quyền trình tự xoay vòng cho những người đề xuất BL đăng ký trở thành Gate.ioways.

hiện nay, mỗi nhà xác minh ethereum chỉ đóng vai trò người đề xuất cho mỗi khe, và lịch trình của người đề xuất luôn được biết đến cho epoch hiện tại và epoch tiếp theo. một epoch có 32 khe, vì vậy chúng ta luôn biết các người đề xuất 32-64 tiếp theo tại một thời điểm nhất định. thiết kế hoạt động bằng cách cấp quyền cho sequencer hoạt động tiếp theo (tức là sequencer tiếp theo trong quá trình nhìn trước) quyền độc quyền để xếp hạng các giao dịch cho brs tham gia hệ thống tiền tệ trước đó này. Gate.ioways phải ký để đẩy tiến trạng thái của các chuỗi br.

lưu ý rằng mỗi người đề xuất (kể cả những người chưa chọn tham gia Gate.ioway) có quyền nhưng không bắt buộc phải bao gồm giao dịch đã được xác nhận trước đó bởi các trình tự (tức là những người đề xuất đã chọn tham gia Gate.ioway). họ có thể hoạt động như một người bao gồm miễn là họ có danh sách đầy đủ các giao dịch đã được xác nhận trước đó cho đến thời điểm đó (trình tự có thể tạo một khối bl có các giao dịch br và truyền đồn chúng).

nguồn: Ethereum sequencing, justin drake

Luồng giao dịch hoạt động như sau:

1. Người dùng br gửi giao dịch của họ cho sequencer tiếp theo trong tầm nhìn (nhà đề xuất khe n+1 trong hình ảnh dưới đây)
2. Trình sắp xếp trình tự ngay lập tức cung cấp xác nhận trước cho trạng thái kết quả (ví dụ: người dùng đã hoán đổi 1 ETH lấy 4000 đô la USDC trên BR và trả 0,0001 ETH phí)
3. Tại thời điểm này, bất kỳ người bao gồm nào đều có thể bao gồm giao dịch được sắp xếp (người đề xuất khe n đó làm như vậy trong hình ảnh bên dưới)

nguồn: Trình tự Ethereum, Justin Drake

nếu những người tham gia khác không bao gồm các preconfs, thì sequencer đã cung cấp chúng có thể đơn giản là bao gồm chúng trên chuỗi khi đến lượt của họ như là người đề xuất bl. ví dụ, trong hình ảnh trên, hãy nói rằng người tham gia khe n đã quyết định không bao gồm các preconfs mà sequencer khe n+1 đã cung cấp. sau đó, sequencer khe n+1 sẽ chịu trách nhiệm bao gồm tất cả các preconfs mà nó đã cung cấp trong khe n và khe n+1 khi nó gửi khối bl cho n+1. điều này cho phép sequencer tự tin cung cấp preconfs cho toàn bộ khoảng thời gian giữa họ và người cuối cùng là sequencer.

Để đơn giản hóa các giải thích ở trên, chúng tôi chỉ giả định rằng người đề xuất L1 sẽ thực hiện vai trò này. Tuy nhiên, như đã mô tả ở trên, điều này không có khả năng xảy ra. Điều này sẽ đòi hỏi một thực thể tinh vi để định giá các preconf, chạy các nút đầy đủ cho tất cả brs, có bảo vệ khỏi tấn công từ chối dịch vụ và đủ băng thông cho tất cả các giao dịch br, v.v. Ethereum muốn giữ cho các nhà xác thực không tinh vi lắm, vì vậy người đề xuất có thể giao việc preconf cho một thực thể khác theo cách tương tự như họ giao việc sản xuất khối L1 đầy đủ qua mev-boost hôm nay.

Người đề xuất có thể ủy quyền Gate.io cho Gate.ioways thông qua cơ chế trên chuỗi hoặc ngoài chuỗi, và điều này có thể được thực hiện cho đến gần thời điểm khe của họ. Như đã đề cập trước đó, vai trò này có thể được thay thế bởi các relay trong thực tế. Cũng có khả năng họ sẽ cần phải hợp nhất với các nhà xây dựng.

nguồn:Dựa trên việc xếp hàng, justin drake

Như đã mô tả trước đó, chỉ có một thực thể được uỷ quyền để trở thành cổng vào của Gate.io tại một thời điểm nhất định. Điều này là cần thiết để cung cấp các tiền điện tử đáng tin cậy. Các giao diện người dùng (ví như metamask) sẽ tìm kiếm ai là cổng vào tiếp theo của Gate.io, và họ sẽ gửi các giao dịch người dùng đến đó.

Ethereum rollups - Chúng sẽ dựa trên như thế nào?

với đủ kiến thức cơ bản hiện có - liệu ethereum rollups nên được dựa trên? thực sự có hai câu hỏi được nhúng ở đây:

1. nên nhiều Ethereum rollups chia sẻ một sequencer không?
2. nếu có, liệu nó có nên là một trình tự dựa trên (tức là liên quan đến các nhà đề xuất ethereum bl và cơ sở hạ tầng mev xung quanh)?

Đầu tiên, điều quan trọng cần lưu ý là bạn có thể chia sẻ một trình tự với các chuỗi khác theo cách tạm thời. Ví dụ, người đề xuất Ethereum có thể sắp xếp một khối cho bạn nếu họ đấu giá cao nhất, sau đó một sự đồng thuận BFT khác có thể sắp xếp khối tiếp theo của bạn nếu họ đấu giá cao nhất. Tuy nhiên, điều này vẫn yêu cầu một chuỗi tham gia hoàn toàn vào đấu giá chia sẻ đồng nhất này có thể chạy đồng bộ với các chuỗi khác, vì vậy vẫn tồn tại các sự đánh đổi liên quan đến kiểm soát và linh hoạt (ví dụ, thời gian khối chia sẻ). Chỉ là công ty trình tự chiến thắng có thể thay đổi.

Bất kể, chúng ta hãy giả sử điều kiện 1 được đáp ứng. Tôi nghĩ rằng chúng tôi có bằng chứng thuyết phục tại thời điểm này rằng tồn tại đủ nhu cầu để sử dụng một trình tự chia sẻ phi tập trung. Ngay cả khi họ ít quan tâm đến "khía cạnh được chia sẻ", tôi nghĩ rằng có một giá trị cực kỳ cao trong việc có thể mua một trình tự phi tập trung như một dịch vụ (trên thực tế tôi nghĩ đây là giá trị lớn nhất ở đây).

Bây giờ, liệu bộ sắp xếp được chia sẻ này có phải là bộ sắp xếp dựa trên Ethereum không?

kỹ thuật (cam kết của người đề xuất)

Tôi không thấy một lập luận kỹ thuật mạnh mẽ để sử dụng một trình tự dựa trên ethereum. Bất kỳ tích hợp nào giữa brs và ethereum l1 cũng sẽ bị hạn chế vô cùng do không thể thực hiện đáng tin cậy trên l1 (tức là không có khả năng ghi khóa trạng thái l1 một cách nhất quán), thời gian khối dài (12 giây) và sự thực rằng các giao dịch br mà muốn tương tác với l1 sau đó cũng phải theo kế hoạch cùng với nó. Không có bữa trưa miễn phí ở đây. Điều này không mở khóa bất kỳ sản phẩm hướng người dùng có giá trị nào so với bất kỳ trình tự chia sẻ ngoại vi nào khác.

Giá trị chính mà tôi thấy là việc thêm Ethereum L1 vào phiên đấu giá kết hợp lớn này có thể dẫn đến tăng giá trị tổng cộng của Gate.io tạo ra vàcho phép L1 thu được nhiều giá trị hơn. đưa logic này đến cực độ, chúng ta có lẽ nên đưa mọi thứ trên thế giới vào cùng một phiên đấu giá. phiên đấu giá toàn cầu này cũng nên sắp xếp vé concert của Taylor Swift. Tôi chưa đến đó.

Đây chỉ là để nhấn mạnh rằng việc tạo ra và tham gia vào phiên đấu giá chung này có tính phức tạp thực sự về mặt kỹ thuật và xã hội, điều này đòi hỏi một chi phí thực tế, mà theo quan điểm của tôi có lẽ nặng hơn bất kỳ giá trị bổ sung lý thuyết tạo ra ở đây. Bạn có thể dễ dàng xây dựng một thiết kế kỹ thuật tốt hơn nhiều để chạy từ nguyên tắc cơ bản nếu chúng ta không cố gắng đặt nó lên trên ethereum l1 (ví dụ, chỉ cần có một cơ chế đồng thuận nhanh đơn giản được xây dựng cho mục đích này). Đừng bỏ qua thực tế rằng một phiên đấu giá tổ hợp như vậy sẽ tạo ra một sự tăng phức tạp mũi nhọn.

Trong thực tế, có một số rủi ro ý nghĩa đối với tôi rằng điều này có thể thực sự gây hại nghiêm trọng cho Ethereum, vì kiến trúc trước đó dựa trên tiềm năng tăng tốc có vẻ như tăng tốc về cơ sở hạ tầng MEV khi chuỗi cung ứng của Ethereum đã khá mong manh. Điều này có nguy cơ đe dọa sự phân quyền và sự chống kiểm duyệt của mạng - những điều làm cho nó có giá trị từ đầu.

xã hội (sự trung lập đáng tin cậy)

Tôi thấy có một lập luận xã hội hợp lý cho một bộ xử lý dựa trên Ethereum.

như đã ghi chú trước đó, không nghi ngờ gì rằng “sự cân đối” là một điểm bán hàng quan trọng cho các brs ban đầu. điều đó tốt, nhưng tôi nghĩ rằng điều này không kéo dài. Việc trở thành br đầu tiên là tuyệt vời, nhưng không tuyệt vời khi trở thành br thứ 8. cần phải có một giá trị bổ sung khác.

Tôi nghĩ rằng tính trung lập đáng tin cậy của một trình tự dựa trên Ethereum có khả năng là giá trị đó. Nó có thể là lập luận mạnh mẽ nhất ủng hộ một thiết kế như vậy ít nhất. Có rất nhiều chuỗi muốn có được một trình tự phi tập trung ra khỏi kệ. Nếu cuối cùng chúng ta có thể thiết kế đủ cơ sở hạ tầng trên đầu trang này để cải thiện UX chuỗi chéo, thì thậm chí còn tốt hơn. Tuy nhiên, trong số các dự án muốn có một thiết kế như vậy, tôi tưởng tượng rất nhiều người trong số họ do dự khi "chọn bên" với bất kỳ giao thức của bên thứ ba nào. Như đã lưu ý trước đó, hãy tưởng tượng bạn là một chuỗi ứng dụng với một số cơ sở hạ tầng chung cơ bản như ENS và bạn muốn tổng hợp. Bạn không muốn chọn trình tự chia sẻ (giả thuyết) Arbitrum và tắt đám đông lạc quan, hoặc ngược lại.

Có thể là giải pháp duy nhất cho vấn đề phối hợp xã hội ở đây là có một bộ sắp xếp chia sẻ có tính trung lập đáng tin cậy, mà ethereum rõ ràng là ứng cử viên mạnh nhất. Lưu ý rằng điều này đặt một mức độ nhấn mạnh hơn ngay cả về các điểm mà tôi đã đề cập trước đó về tính trung lập đáng tin cậy - nếu đây là giá trị chính của dịch vụ như vậy, thì đó phải là mục tiêu thiết kế có độ ưu tiên cao vô cùng trong việc tạo ra nó. Nó sẽ không hoạt động nếu nó có vẻ như là dự án cá nhân của một giao thức bên thứ ba với động cơ lợi nhuận riêng. Nó phải thực sự là bộ sắp xếp chia sẻ của ethereum.

Đáng lưu ý rằng cũng có những chỉ trích hợp lý rằng "trung lập" ở đây là mã cho "ethereum." Nghĩa là, động lực chính của nó là để hỗ trợ ethereum và hạ tầng xung quanh gốc của nó. Và tất nhiên, một hệ thống như vậy sẽ có lợi cho những bên này. Nó sẽ có nghĩa là có nhiều giá trị được giữ lại cho tài sản eth và có nhiều lợi nhuận hơn cho các nhà xây dựng, truyền tải và tìm kiếm ethereum.

gói cuộn dựa trên tốc độ

lớp nền nhanh

Bây giờ chúng ta nên hiểu rằng bạn có thể có brs trên một bl chậm như ethereum, bạn có thể thêm các preconfs đáng tin cậy để có trải nghiệm người dùng nhanh hơn, và bạn thậm chí có thể đảm bảo an toàn khi di chuyển qua các chuỗi thông qua các cam kết cryptoeconomic hoặc cryptographic.

như đã ghi chú, nhưng nếu chúng ta chỉ thiết kế lại thứ này từ đầu. không phải đối mặt với công nợ công nghệ và quyết định của một chuỗi hiện có. cách rõ ràng nhất để xây dựng thứ này là gì...

Trước đó, chúng ta đã thảo luận về việc lý do kỹ thuật duy nhất để trở thành một br với preconfs cho một bl cụ thể (ví dụ, ethereum) là để người đề xuất có thể cung cấp cam kết đáng tin cậy vào thời điểm đồng bộ hóa nguyên tử với bl.

Tuy nhiên, chúng tôi không thảo luận một cách nghiêm túc về khả năng trở thành một BR mà không cần xác nhận trước. Chúng tôi về cơ bản đã từ bỏ điều này vì Ethereum chậm và người dùng không kiên nhẫn.

Vì sao chúng ta không sử dụng một bản BL nhanh cho BRs?

Điều này giải quyết hầu hết tất cả các trường hợp biên và quan tâm phức tạp mà chúng ta từng có trước đây. Chúng tôi không muốn có các trường hợp biên kỳ lạ nơi các cổng Gate.io gặp sự cố về liveness (mà có cùng kết quả như sự cố về an toàn ở đây), chúng tôi không muốn họ rút lui khỏi các preconf đã hứa (tức là sự cố về an toàn), và chúng tôi không muốn ethereum reorgs. Đây chính xác là lý do tại sao sự nhất trí tồn tại.

da layers đã chết, hãy sống lớp sequencing!

hầu hết cuộc trò chuyện về các bộ xử lý lười biếng đều xem xét chúng như một bộ xử lý cuộn trang rồi đổ dữ liệu của nó lên một tầng dữ liệu khác. ví dụ, hai cuộn trang đầu tiên của astria ( FormavàNgọn lửa) sẽ sử dụng Celestia như lớp DA của họ. Sự nhất trí của Astria sẽ sắp xếp các rollup này, sau đó nó sẽ truyền dữ liệu của chúng tới Celestia.

Sự kết hợp này đặc biệt tốt vì chúng hoàn toàn bổ trợ lẫn nhau - astria cung cấp toàn bộ cơ sở hạ tầng chuỗi và celestia cung cấp xác minh tối thiểu hóa tin cậy qua mẫu lấy sẵn dữ liệu (das).

Tuy nhiên, Astria cũng có thể được sử dụng để lập trình một rollup native trên Ethereum, Bitcoin, Solana hoặc bất cứ thứ gì bạn muốn. Ví dụ, nó có thể được thiết lập để sử dụng như một preconfer cho Ethereum "brs with preconfs" (ví dụ: thay vì một Gate.ioway tập trung, một sequencer lười biếng thực chất chỉ là một relay được khuyến khích và phi tập trung).

Tuy nhiên, để rõ ràng, mỗi chuỗi đều là một lớp dữ liệu phân phối. Các nút đầy đủ luôn có thể kiểm tra dữ liệu phân phối. Điều này luôn là một phần của điều kiện hợp lệ của bất kỳ chuỗi nào rằng dữ liệu có sẵn, vì vậy sự đồng thuận luôn ký off rằng dữ liệu có sẵn. Các nút nhẹ kiểm tra cho chữ ký tín nhiệm của họ dựa trên giả định đa số trung thực. Sự khác biệt duy nhất là nếu chuỗi cung cấp một lựa chọn khác cho các client nhẹ để trực tiếp lấy mẫu cho dữ liệu phân phối thay vì yêu cầu sự đồng thuận.

Tuy nhiên, như tôi đã chú ý trong Các rollup kế thừa bảo mật không?, các chuỗi nhanh như astria có thể kỹ thuật thêm một đường dẫn chậm cho das (để cải thiện khả năng xác minh), và chuỗi chậm như celestia có thể thêm một đường dẫn nhanh cho sequencing (với giả định đa số tin cậy và không có das), còn được gọi là “khối nhanh hình vuông chậm.”

Di chuyển để tích hợp dọc các lớp chuyên môn như xếp chuỗi hoặc das sẽ làm giảm sự khác biệt giữa các blockchain modul và tích hợp. Điều này cũng áp dụng tương tự cho tích hợp dọc củatầng giải quyếtthông qua việc thêm vàoTài khoản ZK verifier đến lớp cơ sở của Celestia.

Tuy nhiên, có giá trị ý nghĩa trong việc giữ các dịch vụ này riêng biệt thay vì gói chúng lại. Đây là phương pháp modul được cho phép các rollup lựa chọn các tính năng mà họ muốn (ví dụ: tôi muốn mua việc xếp hàng phi tập trung với các khối nhanh, nhưng tôi không muốn trả tiền cho das, hoặc ngược lại). Các nhà nghiên cứu đã chỉ ra họ muốn das, nhưng người dùng cho đến nay đã chỉ muốn các khối nhanh.

gói dịch vụ như trong “các khối nhanh hơn các ô chậm“sẽ rất có quan điểm và tích hợp. điều này sẽ tăng sự phức tạp và chi phí. ảnh hưởng của độ dài khe trêntrò chơi về thời gian(và do đó có thể phân quyền) mà hiện nay lan truyền trên ethereum cũng là một yếu tố cần xem xét.

lớp cơ sở nhanh vs chậm + tiền xác nhận trước

nhưng bạn cũng có thể chỉ sử dụng astria như là bl cho rollups. các bộ xếp chung có thể được coi là bls được tối ưu hóa cho brs của riêng họ.

Khi BL của bạn nhanh, BR của bạn không cần preconfs vì nó chỉ cần xác nhận nhanh chóng ngay từ đầu! Sau đó, rollup của bạn thực sự đạt được sự an toàn theo thời gian thực từ BL của bạn, khác với BRs + preconfs mà bắt buộc phải mất điều này.

brs không cần xác nhận trước thực tế là cách hợp lý nhất để xây dựng một rollup. Đó là lý do tại sao các rollup hiện nay đều bắt đầu từ đó:

Rõ ràng rằng một khối blockchain nhanh giải quyết hầu hết vấn đề của chúng ta trong “các rollup dựa trên + preconfs”. Sequencer chia sẻ được xây dựng tự nhiên hơn từ một phương pháp nguyên tắc đầu tiên của “hey các nhà phát triển ứng dụng chỉ muốn ra mắt một chuỗi nhanh, đáng tin cậy và phi tập trung - làm sao để tôi cung cấp cho họ? ”Cố gắng thêm preconfs sau khi đã có một lớp cơ sở chậm như ethereum dẫn đến những rắc rối chúng ta đã mô tả ở trên.

Chúng ta đang xây dựng cùng một điều

tính linh hoạt là không thể tránh khỏi

Vậy, chúng ta đã thấy cách chúng ta có thể tổng hợp lại các chuỗi modular của Gate.io lại với nhau, cung cấp tính kết hợp đồng bộ toàn cầu (usc). Tất nhiên có những sự cân nhắc, nhưng chúng thực sự giúp tái giới thiệu một mức độ đồng nhất ý nghĩa trong khi vẫn giữ được tính linh hoạt hơn rất nhiều so với việc sử dụng một máy trạng thái duy nhất. Đồng thời, có một lập luận rất thuyết phục đối với tôi rằng tính kết hợp không đồng bộ là tất cả những gì chúng ta cần cho phần lớn các trường hợp sử dụng. Chúng ta cần độ trễ thấp, hiệu suất và trải nghiệm người dùng tốt. Internet là không đồng bộ và nó hoạt động rất tốt khi trừu tượng hóa tất cả những điều đó. Tính kết hợp là một giá trị lớn của tiền điện tử, nhưng tính kết hợp ≠ đồng bộ.

Bên cạnh những lợi ích về tính linh hoạt và chủ quyền, hầu hết mọi người đều đồng意 rằng cuối cùng chúng ta sẽ cần nhiều chuỗi cho quy mô. Điều này có nghĩa là chúng ta sẽ kết thúc với nhiều hệ thống mà chúng ta cần phải thống nhất, vì vậy hướng đi modul là không thể tránh khỏi ở đây.

ethereum + preconfs → solana?

Bây giờ, hãy so sánh các ván cuối ở đây. Đặc biệt, chúng ta sẽ so sánh ván cuối Solana so với ván cuối Ethereum nếu nó đi theo con đường tối đa hóa sự thống nhất và trải nghiệm người dùng với based rollups + preconfs.

Trong tầm nhìn này, chúng tôi có một đám brs sử dụng sequencer dựa trên Ethereum. Các cách thức của Gate.io liên tục truyền tải proposer-promised (tức là, không có trọng số đồng thuận) preconfs đến người dùng ở độ trễ thấp, sau đó các proposer của Ethereum cam kết chúng vào một khối đầy đủ một thời gian nào đó. Điều này có vẻ quen thuộc vì đó chính là những gì chúng tôi mô tả cho Solana trước đó với shred streaming!

Vậy, đây chỉ là một phiên bản Solana phức tạp hơn? Sự khác biệt lớn ở đây là thời gian khe.

ethereum cố gắng thêm điều này lên một chuỗi chậm rõ ràng đặt ra vấn đề ngay từ cái nhìn đầu tiên:

• Sự đồng thuận của Ethereum là quá chậm đối với người dùng, vì vậy cách duy nhất để có được một UX nhanh trung lập đáng tin cậy là với các preconfs được hứa hẹn bởi người đề xuất trên cơ sở chọn tham gia. Nút cổ chai chính của nó ngày nay là tổng hợp chữ ký do kích thước bộ xác thực khổng lồ của nó (MaxEBvà việc tổng hợp chữ ký được cải thiện có thể giúp cho việc này.
• Điều này dẫn đến sự độc quyền người đề xuất lâu dài hơn, cung cấp động lực cao hơn và tự do hơn để chiếm đoạt nhiều MEV hơn bằng cách hành động không trung thực (ví dụ, giữ lại preconfs).
• nếu Gate.ioways bắt đầu trì hoãn hoặc giữ lại preconfs, thì trường hợp tồi tệ nhất cho người dùng sẽ phụ thuộc vào thời gian khe cắm ethereum. ngay cả khi các nhà sản xuất khối solana ngừng xây dựng khối liên tục và truyền dữ liệu trong các độc quyền được phân bổ của họvì có lý do tương tự, điều này có thể hợp lý với họ một phần), sau đó trường hợp tồi tệ nhất rơi vào sự phụ thuộc vào một sự đồng thuận quay nhanh. Sự độc quyền bốn khe cắm ngày nay là cần thiết mặc dù độ tin cậy của mạng.
• Trong thực tế, có thể sẽ có rất ít các cổng vào của Gate.io, ít nhất là ban đầu, dẫn đến một tập hợp các nhà điều hành tập trung hơn so với các chuỗi như Solana.
• yêu cầu tài sản đảm bảo có thể rất cao đối với người đề xuất (lưu ý rằng không gian thiết kế vẫn đang trong quá trình phát triển).
• Lo ngại về vấn đề liveness ở đây rất tốn kém (vì các vấn đề liveness của nhà khai thác dẫn đến số lượng preconfs bị loại bỏ, gây ra các vấn đề an toàn cho người dùng, và do đó phải bị cắt giảm nặng nề).

Tất cả những vấn đề này đều được giải quyết bằng một sự thống nhất nhanh chóng. Tất cả những hệ thống này chính là lý do tại sao chúng ta tạo ra các hệ thống BFT ban đầu. Vậy tại sao Ethereum không nên làm cho sự thống nhất của mình nhanh hơn? Liệu có những sự đánh đổi ít rõ ràng khi có thời gian chặn cơ bản cực kỳ thấp không?

May mắn thay, tôi không có việc gì tốt hơn là viết một bài luận về việc liệu thời gian khối ngắn có tốt không. Mối quan ngại lớn với thời gian khe cắt ngắn liên quan đến sự tập trung của người xác minh và người vận hành. Cụ thể, có những lo ngại liên quan đến sự tương tác của thời gian khe cắt ngắn với trò chơi thời gian:

Chúng tôi thấy trò chơi về thời gian đang tiến triển trên Ethereum rồi. Người đề xuất đề xuất khối sau vào khe cắm của họ, kiếm nhiều tiền hơn tại sự mất mát của người khác. Các máy trạm cũng đang cung cấp thời gian chơi dưới dạng dịch vụ" theo đó họ tương tự trì hoãn các khối sau đó trong khe:

nguồn:Dữ liệu luôn

Trò chơi về thời gian là chủ đề lớn được thảo luận trên mạng.Justin vs. toly podcast không ngân hàngtừ vài tuần trước:

ví dụ, hãy nói rằng bạn nhanh hơn 100ms so với tất cả mọi người

Nếu bạn có khe cắm 1s, bạn có thể kiếm được 10% nhiều hơn những người khác

Nếu bạn có khe cắm 10 giây, bạn có thể kiếm được 1% nhiều hơn những người khác

— jon charbonneau (@jon_charb) 4 tháng 6 năm 2024

Justin chủ yếu tranh luận rằng việc chọn thời điểm của trò chơi sẽ là vấn đề, và phần thưởng tăng dần sẽ luôn có ý nghĩa. Toly chủ yếu tranh luận rằng việc chọn thời điểm của trò chơi sẽ không phải là vấn đề, và phần thưởng tăng dần từ việc trích xuất MEV bổ sung không đủ để quan tâm.

theo cá nhân tôi, tôi thấy khó để bỏ qua sự quan trọng của việc định giờ trong trò chơi ở đây:

• chúng ta đã thấy chúng trong thực tế trên ethereum ngày nay.Đối lập về Solanađiều này chỉ xảy ra vì mev trở nên thông thường xã hội trong ethereum trước đó, nhưng điều này không thuyết phục khi cóSự phản đối kịch liệt của công chúng đối với các trò chơi thời gian sớmđiều đó đã trở thành sự chấp nhận từ sau đócủa hiện thực mới này được thiết kế xung quanh.
• Phần thưởng mev rất quan trọng - chúng ta đã đang nói vềhàng tỷ đô la trong các khoản thanh toán mev ở đây, không phải đồng xu dưới đệm đi văng. Ngay cả việc kiếm được "chỉ thêm vài phần trăm" về điều này cũng là một khoản tiền khổng lồ.
• Thậm chí nếu bạn không tin vào việc các nhà staking có độ nhạy cảm với lợi suất đủ trên biên, các nhà điều hành thực tế đang vận hành kinh doanhvà đi thẳng vào lợi nhuận của họ.
• Nó dễ dàng hơn cho solana để dựa vào các bên liên quan lớn vị tha(ví dụ, cơ sở và các nhà đầu tư lớn) sớm hơn trong vòng đời của nó, nhưngĐiều đó không bền vững khi mạng phân tán hơn..

Tôi rõ ràng nghĩ rằng có một lượng lớn giá trị trong hướng mà cả Solana và Ethereum đang theo đuổi. Nếu không có gì khác, chúng ta sẽ được thấy tất cả những gì diễn ra trong thực tế. Chiến lược, tôi cũng nghĩ rằng Ethereum nên tận dụng những điểm khác biệt của nó ở đây. Tối đa hóa sự phi tập trung như một phương tiện để đạt được khả năng chống kiểm duyệt dưới hoàn cảnh đối lập. Ethereum đã hy sinh rất nhiều để giữ một giao thức phi tập trung đáng kinh ngạc vì điều đó là cần thiết cho trò chơi dài. Nó có sự đa dạng vượt trội của khách hàng, phân phối sở hữu mạng lưới, các bên liên quan trong hệ sinh thái, phi tập trung của các nhà điều hành và nhiều hơn nữa. Nếu (và có thể khi) Solana phải đối mặt với áp lực kiểm duyệt nghiêm trọng trong tương lai, sẽ trở nên ngày càng rõ ràng vì sao Ethereum đã đưa ra những quyết định như vậy.

preconf.wtf vừa mới diễn ra ở zuberlin tuần trước, và có lẽ không ngạc nhiên khi mọi người đang nói về các preconfs và các rollups dựa trên. Và điều đó thật sự rất tuyệt. Nhưng cá nhân tôi đã tìm thấy,Bài nói của Vitalikvềdanh sách bao gồm một bit cho mỗi người chứng thựcvà cuộc nói chuyện của Barnabé vềQuá tải người đề xuất thay vì (từ mev-boost thành epbs thành aps)để trở thành quan trọng nhất đối với tương lai của Ethereum.

nguồn:Barnabé monnot, Từ mev-boost đến epbs đến aps

các cuộc trò chuyện về preconf và dựa trên rollup đã bắt đầu nhận được động lực gần đây, và tôi chắc chắn vẫn còn ở phía cẩn trọng hơn. Vitalik đã nổi tiếng với việc đề ra như sau Cuối cùng:

Tuy nhiên, chúng tôi đã đi khá sâu vào "sản xuất tập trung" mà chưa thực hiện các biện pháp bảo vệ chống kiểm duyệt mạnh mẽ hơn như danh sách đưa vào. Về cơ bản, Ethereum nằm ở một nửa hàng dưới cùng của hình dưới đây. (Tôi nói một nửa vì kiểm duyệt không thực sự là đen trắng và Ethereum chỉ có "kiểm duyệt yếu", tức là, hầu hết nhưng không phải tất cả các khối đều bị kiểm duyệt, vì vậy bạn có thể đợi một chút, nhưng sau đó bạn sẽ được đưa vào):

nguồn:Bằng chứng về quản trị

Theo kinh nghiệm, chuỗi cung ứng Ethereum L1 MEV hiện đang kiểm duyệt thời gian thực nhiều khối hơn bất kỳ L2 nào trong số này với các trình tự tập trung.

l2s đã có thể nhận được cr cuối cùng của l1 (điều này vẫn rất tốt) mà không cần dựa vào. các preconfs dựa vào không nhận được sự an toàn thời gian thực của giao thức ethereum, họ chỉ nhận được sự an toàn thời gian thực từ một số ít nhà cung cấp cơ sở hạ tầng tương đối tập trung xung quanh nó. để có cr thời gian thực tốt hơn, tùy chọn tốt nhất có lẽ là outsourcing sequencing cho một loại sequencer phi tập trung chạy một loại bft consensus đơn giản. điều này sẽ mạnh mẽ hơn nhiều so với việc tập trung nhiều chuỗi vào một bottleneck tương đối tập trung hiện tại. tình hình này có thể cải thiện với những thay đổi như đấu giá thực thi và danh sách inclusion, nhưng điều đó không chính xác nằm ngay góc đường.

Với tất cả những điều này được xem xét, tôi không thấy rõ ràng rằng mở rộng sự phụ thuộc vào cơ sở hạ tầng mev của ethereum l1 và sau đó làm cho nó cố định cho l2 là một ý tưởng tuyệt vời ở giai đoạn này khi chỉ có một số ít người xây dựng và truyền tải tất cả các khối ethereum, hầu hết các khối không kiểm duyệt của ethereum hiện nay phụ thuộc vào một người xây dựng duy nhất (titan), và không có công cụ cr nào đã được triển khai trong giao thức. Điều này cảm thấy tích cực gia tăng tại một vị trí mong manh. Ethereum chắc chắn nên làm việc để cải thiện trải nghiệm người dùng của l2, nhưng không phải bằng việc hy sinh tất cả những thuộc tính cơ bản mà chúng ta muốn từ đầu.

kết thúc

Chúng ta đang xây dựng cùng một thứ.

Vâng, đại loại. Rõ ràng những điều này không phải là tất cả những điều chính xác theo nghĩa đen. Sẽ luôn có sự khác biệt thực tế giữa các hệ thống này. Tuy nhiên, xu hướng lớn bao trùm trong tiền điện tử rõ ràng là tất cả chúng ta đều hội tụ trên các kiến trúc ngày càng giống nhau.

Sự khác biệt kỹ thuật tinh tế giữa chúng trong thực tế có thể có tác động đáng kể đến nơi chúng kết thúc, và chúng ta không thể đánh giá thấp vai trò quan trọng của sự phụ thuộc vào đường đi trong những hệ thống này ngay cả khi chúng hội tụ đến các mục tiêu tương tự.

Ngoài ra, việc suy luận về một số thứ này khá khó khăn đến đáng kinh ngạc.Như vitalik đã nói::

“Một lưu ý cần cẩn trọng mà tôi muốn nhắc đến với aps là tôi nghĩ rằng từ một góc độ kỹ thuật, tôi thực sự nghĩ rằng nó khá nhẹ nhàng và chúng ta hoàn toàn có thể thực hiện nó mà không có nhiều cơ hội lỗi kỹ thuật... nhưng từ góc độ kinh tế, có rất nhiều cơ hội để mọi thứ có thể đi sai lạc...

Giống như eip-1559, chúng tôi đã có thể tìm hiểu với lý thuyết. Chúng tôi đã tham dự một số hội nghị kinh tế tuyệt vời và tìm hiểu về những nguy hiểm của đấu giá giá đầu tiên và cách chúng thất bại, và nhận ra rằng đấu giá giá thứ hai không đáng tin cậy, sau đó phát hiện ra rằng hãy sử dụng cơ chế giá cố định được cục bộ hóa trong mỗi khối, và chúng tôi đã có thể làm rất nhiều với kinh tế vi mô.

Nhưng aps không phải như vậy đúng không. Và câu hỏi liệu aps sẽ dẫn đến citadel hay jane street hay justin sun hay bất kỳ ai sản xuất 1% tất cả các khối ethereum hay 99% là rất rất khó, có lẽ không thể tìm ra từ nguyên tắc đầu tiên.

Và điều tôi muốn thấy ở thời điểm này là thực nghiệm trực tiếp... đối với tôi cá nhân, khoảng cách giữa hôm nay và khi tôi cảm thấy thật sự thoải mái với APS là APS hoạt động thành công trên một Ethereum L2 có một lượng giá trị, hoạt động, cộng đồng và tranh chấp thực tế xảy ra trong một năm, có thể lâu hơn một năm, và chúng ta thực sự có thể nhìn thấy một số hậu quả thực tế.

Vâng, tôi cũng không biết điều gì sẽ xảy ra. Chúng ta chỉ có thể chờ xem. Dù sao, trong bất kỳ trường hợp nào, trong khi chúng ta đang hội tụ vào cuối cùng này, chúng ta có nhiều điểm chung hơn là khác biệt, vì vậy hãy đảm bảo...

miễn trách nhiệm：

1. bài viết này được sao chép từ [cơ sở dữ liệu].chuyển tiếp tiêu đề gốc 'chúng ta đang xây dựng cùng một thứ'. tất cả các bản quyền thuộc về tác giả gốc [jon charbonneau]. nếu có ý kiến ​​phản đối với việc tái in này, vui lòng liên hệ với Gate.io học và họ sẽ xử lý kịp thời.
2. Miễn trừ trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm học tập của Gate.io. Trừ khi có đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã được dịch là cấm.