Tác giả: Jon Charbonneau

Tên gốc: The Hitchhiker's Guide to Ethereum

Điểm cốt lõi:

• Ethereum là giao thức chính duy nhất nhằm mục đích xây dựng một lớp tính sẵn có của dữ liệu và thanh toán thống nhất có thể mở rộng

• Rollup mở rộng quy mô tính toán trong khi tận dụng bảo mật của Ethereum

• Tất cả các con đường đều dẫn đến một kết thúc trò chơi sản xuất khối tập trung, xác minh khối không tin cậy phi tập trung và khả năng chống kiểm duyệt.

• Những đổi mới như tách biệt giữa người khởi xướng và người xây dựng và tình trạng không quốc tịch yếu, mang lại sự phân chia quyền hạn (xây dựng và xác nhận) có thể đạt được khả năng mở rộng mà không phải hy sinh các mục tiêu bảo mật hoặc phân cấp

• MEV hiện đang ở phía trước và trung tâm - phần lớn thiết kế được lên kế hoạch để giảm thiểu tác hại của nó và ngăn chặn xu hướng tập trung hóa của nó

• Danksharding kết hợp nhiều cách tiếp cận với nghiên cứu tiên tiến để cung cấp lớp cơ sở có thể mở rộng cần thiết cho lộ trình tập trung vào tổng số của Ethereum

• Mục lục

Mục lục

Phần 1 Con đường đến Danksharding

Thiết kế chia sẻ dữ liệu gốc - Đề xuất chia sẻ độc lập

Lấy mẫu tính khả dụng của dữ liệu (DAS)

Cam kết KZG

Lời hứa của KZG so với bằng chứng gian lận

Tách người khởi xướng và người xây dựng trong giao thức

Danh sách kháng kiểm duyệt (crList)

Chiến lược KZG 2D

Danksharding

Danksharding - xác minh đa số trung thực

Danksharding - xây dựng lại

Danksharding - Bảo mật đa số độc hại với lấy mẫu ngẫu nhiên riêng tư

Danksharding - Tóm tắt chính

Danksharding——Hạn chế đối với việc mở rộng chuỗi khối

Bản địa danksharding (EIP-4844)

Đa chiều EIP-1559

Phần 2 Lịch sử và Quản lý Nhà nước

Giảm chi phí gas cuộc gọi và tổng giới hạn dữ liệu cuộc gọi (EIP-4488)

Định tính dữ liệu lịch sử trong máy khách thực thi (EIP-4444)

khôi phục dữ liệu lịch sử

yếu quốc tịch

Verkle Tries (Verkle Tries)

trạng thái hết hạn

Phần 3 Tất cả là lỗi của MEV

Chuỗi cung ứng MEV ngày nay

MEV-Boost

Làm mịn MEV do Ủy ban thúc đẩy

Độ hoàn thiện một khe

Bầu cử thủ lĩnh bí mật duy nhất

Phần 4 Bí Mật Sáp Nhập

Khách hàng hợp nhất

Giới thiệu

Giới thiệu

Tôi đã khá nghi ngờ về thời điểm sáp nhập kể từ khi Vitalik nói rằng ai đó sinh ra ngày nay có 50-75% cơ hội sống đến năm 3000 sau Công nguyên và anh ta hy vọng sẽ sống mãi mãi. Nhưng, cái quái gì vậy, hãy vui vẻ một chút, hãy tận dụng cơ hội này để xem xét kỹ hơn về lộ trình đầy tham vọng của Ethereum.

Bài viết này không được coi là đương nhiên. Nếu bạn muốn có một cái nhìn bao quát và sắc thái về lộ trình đầy tham vọng của Ethereum, hãy cho tôi một giờ và tôi sẽ giúp bạn tiết kiệm hàng tháng trời làm việc.

Bài viết này không được coi là đương nhiên. Nếu bạn muốn có một cái nhìn bao quát và sắc thái về lộ trình đầy tham vọng của Ethereum, hãy cho tôi một giờ và tôi sẽ giúp bạn tiết kiệm hàng tháng trời làm việc.

Có rất nhiều thứ để theo dõi trong nghiên cứu Ethereum, nhưng tất cả đều liên kết với nhau thành một mục tiêu bao trùm — mở rộng quy mô tính toán mà không phải hy sinh xác thực phi tập trung.

Vitalik có một câu nói nổi tiếng về "trò chơi kết thúc", tôi không biết bạn đã nghe chưa. Ông thừa nhận rằng quy mô ethereum đòi hỏi một số tập trung. Trong chuỗi khối, chữ C để chỉ sự tập trung thật đáng sợ, nhưng đó là thực tế. Chúng ta chỉ cần kiểm soát sức mạnh này bằng xác minh phi tập trung và không tin cậy. Không có thỏa hiệp ở đây.

Các chuyên gia sẽ thêm vào L1 và hơn thế nữa. Ethereum vẫn cực kỳ an toàn với xác thực phi tập trung đơn giản, trong khi rollup kế thừa tính bảo mật của nó từ L1. Ethereum sau đó cung cấp khả năng thanh toán và dữ liệu, cho phép các bản tổng hợp mở rộng quy mô. Tất cả các nghiên cứu ở đây cuối cùng đều nhằm mục đích tối ưu hóa hai vai trò này, đồng thời, giúp việc xác minh đầy đủ các chuỗi khối trở nên dễ dàng hơn bao giờ hết.

Các thuật ngữ sau đây được lặp lại khoảng bảy hoặc tám năm mươi chín lần:

• DA – Tính khả dụng của dữ liệu Tính khả dụng của dữ liệu

• DAS – Lấy mẫu tính khả dụng của dữ liệu Lấy mẫu tính khả dụng của dữ liệu

• PBS – Trình khởi tạo tách người đề xuất-người xây dựng và tách người xây dựng

• PDS – proto-danksharding bản địa darksharding

• DS – Danksharding một thiết kế bảo vệ Ethereum

• PoW – Bằng chứng khối lượng công việc Proof of Work

• PoS – Proof of Stake bằng chứng cam kết

Phần 1 Con đường đến Danksharding

Hy vọng rằng bạn đã nghe nói rằng Ethereum đã chuyển sang lộ trình tập trung vào tổng số. Không còn phân đoạn thực thi - Thay vào đó, Ethereum sẽ tối ưu hóa cho các bản tổng hợp ngốn dữ liệu. Điều này đạt được thông qua phân đoạn dữ liệu (một chút kế hoạch của Ethereum) hoặc các khối lớn hơn (kế hoạch của Celestia).

Lớp đồng thuận không diễn giải dữ liệu được phân đoạn. Nó chỉ có một công việc - đảm bảo dữ liệu có sẵn.

Tôi cho rằng bạn đã quen thuộc với các khái niệm cơ bản như tổng số, gian lận và bằng chứng ZK cũng như lý do tại sao DA (Tính khả dụng của dữ liệu) lại quan trọng. Nếu bạn chưa quen hoặc chỉ cần ôn lại, hãy xem báo cáo Celestia gần đây của Can.

Thiết kế chia sẻ dữ liệu gốc - Đề xuất chia sẻ độc lập

Thiết kế được mô tả ở đây đã lỗi thời, nhưng đáng để xem xét về nền tảng. Để đơn giản, tôi sẽ gọi nó là "sharding 1.0".

Mỗi trong số 64 phân đoạn có các đề xuất và ủy ban riêng lẻ được luân chuyển từ bộ trình xác nhận. Họ độc lập xác minh rằng dữ liệu phân đoạn của họ có sẵn. Ban đầu, nó sẽ không phải là DAS (Lấy mẫu khả dụng của dữ liệu) - nó dựa vào phần lớn trung thực của bộ xác thực của mỗi phân đoạn để tải xuống đầy đủ dữ liệu.

Thiết kế này tạo ra sự phức tạp không cần thiết, trải nghiệm người dùng tồi tệ hơn và là phương tiện tấn công. Tổ chức lại trình xác nhận giữa các phân đoạn có thể gặp rủi ro.

Cũng khó đảm bảo rằng việc bỏ phiếu sẽ được thực hiện trong một khe duy nhất trừ khi bạn đưa ra các giả định đồng bộ hóa rất nghiêm ngặt. Các đề xuất khối Beacon yêu cầu thu thập tất cả phiếu bầu của từng ủy ban, việc này có thể bị trì hoãn.

(Trong thiết kế phân đoạn dữ liệu ban đầu, mỗi phân đoạn được xác nhận bằng một phiếu bầu của ủy ban. Việc bỏ phiếu không phải lúc nào cũng được thực hiện trong một vị trí duy nhất và một phân đoạn có thể được xác nhận tối đa hai kỷ nguyên)

DS (Danksharding) thì hoàn toàn khác. Người xác thực tiến hành DAS, xác nhận rằng tất cả dữ liệu đều có sẵn (không còn ủy ban phân đoạn riêng biệt nữa). Một nhà xây dựng chuyên dụng (Builder) sử dụng khối Beacon và tất cả dữ liệu bị phân mảnh để tạo ra một khối lớn và xác nhận nó. Do đó, PBS (tách biệt các đề xuất và người xây dựng) là cần thiết để DS duy trì tính phi tập trung (việc xây dựng khối lớn đó cùng nhau cần nhiều tài nguyên).

Lấy mẫu tính khả dụng của dữ liệu (DAS)

Tổng số xuất bản rất nhiều dữ liệu, nhưng chúng tôi không muốn tạo gánh nặng cho các nút tải xuống tất cả dữ liệu. Điều này có nghĩa là phân bổ nguồn lực cao, do đó ảnh hưởng đến sự phân cấp.

Thay vào đó, DAS cho phép các nút (thậm chí cả máy khách nhẹ) xác minh dễ dàng và an toàn rằng tất cả dữ liệu đều có sẵn mà không cần tải xuống tất cả.

• Giải pháp ngây thơ - chỉ cần kiểm tra một phần ngẫu nhiên từ khối. Nếu không có vấn đề gì thì chỉ cần ký vào là xong. Nhưng nếu bạn bỏ lỡ một giao dịch sẽ rút hết ETH của bạn cho một kẻ xấu nào đó thì sao? Điều này có thể được an toàn (safu).

• Giải pháp thông minh - xóa mã dữ liệu trước. Dữ liệu được mở rộng bằng mã Reed-Solomon. Điều này có nghĩa là dữ liệu được nội suy dưới dạng đa thức, sau đó chúng ta có thể đánh giá ở nơi khác. Điều này hơi phức tạp, vì vậy hãy phá vỡ nó.

Đừng lo lắng về môn toán của bạn, đây là một khóa học cấp tốc. (Tôi hứa rằng toán học không đáng sợ ở đây - tôi đã phải xem một số video của Khan Academy để viết những phần này, nhưng bây giờ thậm chí tôi đã hiểu rồi).

Đa thức là một biểu thức là phép cộng của một số hữu hạn các số hạng có dạng . Số lượng thuật ngữ đại diện cho chỉ số cao nhất. Ví dụ, + + - 4 là một đa thức bậc ba. Bạn có thể xây dựng lại bất kỳ đa thức bậc nào từ bất kỳ tọa độ nào nằm trên đa thức.

Bây giờ hãy xem một ví dụ cụ thể. Dưới đây chúng tôi có bốn khối dữ liệu (đến). Các khối dữ liệu này có thể được ánh xạ tới các giá trị của đa thức tại một điểm nhất định. Ví dụ, =. Sau đó, bạn tìm đa thức bậc nhỏ nhất thỏa mãn các giá trị này. Vì đây là bốn khối dữ liệu, chúng ta có thể tìm thấy một đa thức bậc ba. Sau đó, chúng ta có thể mở rộng dữ liệu này bằng cách thêm bốn giá trị ( vào ) nằm trên cùng một đa thức.

Hãy nhớ rằng thuộc tính đa thức chính - chúng ta có thể xây dựng lại nó từ bốn điểm bất kỳ, không chỉ bốn khối ban đầu của chúng ta.

Quay lại với DAS của chúng tôi. Bây giờ, chúng tôi chỉ cần đảm bảo rằng bất kỳ 50% (4/8) dữ liệu được mã hóa xóa nào đều có thể sử dụng được. Từ đó, chúng ta có thể xây dựng lại toàn bộ khối dữ liệu.

Do đó, kẻ tấn công phải ẩn hơn 50% khối dữ liệu để đánh lừa thành công các nút DAS nghĩ rằng dữ liệu có sẵn trong khi thực tế không phải vậy.

Sau nhiều lần lấy mẫu ngẫu nhiên thành công, xác suất có sẵn <50% dữ liệu là rất nhỏ. Nếu chúng tôi lấy mẫu thành công dữ liệu đã mã hóa xóa 30 lần, thì có <50% xác suất là dữ liệu đó có thể sử dụng được.

Cam kết KZG

OK, vì vậy chúng tôi đã tạo một loạt các mẫu ngẫu nhiên và tất cả chúng đều có sẵn. Nhưng chúng tôi vẫn có một câu hỏi - việc xóa dữ liệu có được mã hóa chính xác không? Mặt khác, có thể các nhà sản xuất khối chỉ thêm 50% rác khi mở rộng khối và việc lấy mẫu của chúng tôi rất lãng phí thời gian. Trong trường hợp này, chúng tôi sẽ không thực sự có thể xây dựng lại dữ liệu.

Thông thường, chúng tôi chỉ cam kết một lượng lớn dữ liệu bằng cách sử dụng gốc Merkle. Điều này hữu ích để chứng minh việc bao gồm một số dữ liệu trong một tập hợp.

Tuy nhiên, chúng ta cũng cần biết rằng tất cả dữ liệu ban đầu và dữ liệu mở rộng đều nằm trên cùng một đa thức bậc thấp. Merkel không thể chứng minh điều đó. Do đó, nếu bạn thực hiện theo phương án này, bạn cũng cần có bằng chứng gian lận để ngăn chặn những sai lầm có thể xảy ra.

(Gốc Merkle cho phép chúng tôi thực hiện các cam kết về dữ liệu và phần mở rộng của dữ liệu, nhưng nó không thể cho chúng tôi biết liệu chúng có thuộc cùng một đa thức bậc thấp hay không)

Các nhà phát triển có thể giải quyết vấn đề này theo hai hướng:

• Celestia đang đi theo con đường chứng minh gian lận. Kế hoạch này yêu cầu ai đó xem và nếu một khối được mã hóa xóa không chính xác, họ sẽ gửi bằng chứng gian lận để cảnh báo mọi người. Điều này yêu cầu các giả định thiểu số trung thực tiêu chuẩn và các giả định đồng bộ (nghĩa là ngoài việc ai đó gửi cho tôi bằng chứng gian lận, tôi cũng cần giả định rằng tôi đang trực tuyến và sẽ nhận được bằng chứng đó trong một khoảng thời gian hữu hạn).

• Ethereum và Polygon Avail đang đi theo một con đường mới - cam kết KZG (còn gọi là cam kết Kate). Điều này loại bỏ các giả định thiểu số trung thực và tính đồng bộ để giữ an toàn cho bằng chứng gian lận (mặc dù chúng vẫn tồn tại và được sử dụng để tái thiết, như chúng ta sẽ sớm đề cập).

Các giải pháp khác không phải là không có, nhưng ít được tìm kiếm hơn. Ví dụ: bạn có thể sử dụng bằng chứng ZK. Thật không may, chúng không thực tế về mặt tính toán (hiện tại). Tuy nhiên, chúng dự kiến ​​sẽ được cải thiện trong vài năm tới, vì vậy có khả năng Ethereum sẽ chuyển sang STARK trong tương lai, vì KZG hứa hẹn sẽ không kháng lượng tử.

(Tôi không nghĩ các bạn đã sẵn sàng cho các STARK hậu lượng tử, nhưng thế hệ tiếp theo của các bạn sẽ thích nó)

Quay lại các cam kết KZG - đây là một kế hoạch cam kết đa thức.

Sơ đồ cam kết chỉ là một cách mã hóa để thực hiện cam kết đối với một số giá trị có thể chứng minh được. Phép loại suy tốt nhất là đặt một lá thư trong một chiếc hộp có khóa và chuyển nó cho người khác. Bức thư không thể thay đổi khi đã được nhập vào, nhưng nó có thể được mở bằng chìa khóa và được chứng thực. Bạn cam kết với bức thư, và chìa khóa là bằng chứng.

Trong trường hợp của chúng tôi, chúng tôi ánh xạ tất cả dữ liệu gốc và dữ liệu mở rộng vào lưới X, Y, sau đó tìm đa thức bậc nhỏ nhất phù hợp với chúng (quá trình này được gọi là phép nội suy Lagrangian). Đa thức này là những gì người tục ngữ hứa hẹn.

(Các cam kết của KZG cho phép chúng tôi thực hiện các cam kết về dữ liệu và phần mở rộng dữ liệu và chứng minh rằng chúng nằm trên cùng một đa thức bậc thấp)

Một vài điểm chính:

• Đầu tiên có một đa thức

• Cam kết của người chứng minh đối với các dạng đa thức này

• Điều này dựa trên một thiết lập đáng tin cậy của mật mã đường cong elip. Về cách thức hoạt động của nó, có một chủ đề tuyệt vời từ Bartek.

• Đối với bất kỳ giá trị nào của đa thức này, người chứng minh có thể tính toán một chứng minh

• Nói theo lời người: người chứng minh đưa những đoạn này cho bất kỳ người kiểm chứng nào, sau đó người kiểm chứng có thể xác nhận rằng giá trị của một điểm nào đó (giá trị ở đây đại diện cho dữ liệu đằng sau) có nằm đúng trên đa thức đã cho hay không.

• Điều này biện minh cho phần mở rộng của chúng tôi đối với dữ liệu gốc vì tất cả các giá trị nằm trên cùng một đa thức

• Lưu ý: người kiểm tra không cần sử dụng đa thức

• Các thuộc tính quan trọng — quy mô của cam kết tuân thủ , kích thước bằng chứng đối với và thời gian xác minh đối với . Ngay cả đối với người chứng minh, việc tạo ra các cam kết và bằng chứng chỉ có độ phức tạp là , ở đâu là bậc của đa thức.

• Nói một cách thẳng thắn: ngay cả khi (số lượng giá trị) tăng (nghĩa là tập dữ liệu tăng theo kích thước phân đoạn) - kích thước của các cam kết và bằng chứng không đổi và lượng công việc cần thiết để xác minh là không đổi.

• Cả lời hứa và bằng chứng chỉ là một thành phần đường cong elip trên Đường cong thân thiện với ghép nối (ở đây BLS12-381 được sử dụng). Trong trường hợp này, chúng chỉ có 48 byte mỗi cái (rất nhỏ).

• Do đó, cam kết của người chứng minh đối với một lượng lớn dữ liệu gốc và dữ liệu mở rộng (được biểu thị bằng nhiều giá trị trên một đa thức) vẫn chỉ là 48 byte và bằng chứng cũng sẽ chỉ là 48 byte

• Nói một cách đơn giản hơn: Quy mô khá tốt

Ở đây, các gốc KZG (một cam kết đa thức) tương tự như các gốc Merkle (một cam kết véc tơ).

Dữ liệu ban đầu là các giá trị của đa thức tại to , sau đó chúng ta mở rộng nó bằng cách đánh giá đa thức tại to . Tất cả các điểm cần đảm bảo nằm trên cùng một đa thức.

Tóm lại: DAS cho phép chúng tôi kiểm tra xem có sẵn dữ liệu bị xóa mã hóa hay không. KZG hứa sẽ chứng minh cho chúng tôi thấy rằng dữ liệu gốc được chia tỷ lệ chính xác và hứa hẹn tất cả dữ liệu.

Vâng, tất cả các đại số kết thúc ở đây.

Lời hứa của KZG so với bằng chứng gian lận

Bây giờ chúng ta đã hiểu cách thức hoạt động của KZG, hãy lùi lại và so sánh hai cách tiếp cận.

Nhược điểm của KZG là nó sẽ không an toàn sau lượng tử và nó yêu cầu khởi tạo đáng tin cậy. Đây không phải là một nguyên nhân cho mối quan tâm. STARK cung cấp giải pháp thay thế hậu lượng tử, trong khi quá trình khởi tạo đáng tin cậy (tham gia mở) chỉ yêu cầu một người tham gia trung thực.

Ưu điểm của KZG là nó có độ trễ thấp hơn so với thiết lập chống gian lận (mặc dù, như đã đề cập trước đó, GASPER dù sao cũng sẽ không có kết quả cuối cùng nhanh) và nó đảm bảo xóa mã đúng cách mà không bị đưa vào bằng chứng gian lận. Tính đồng bộ và trung thực vốn có là một vài giả định.

Tuy nhiên, do Ethereum vẫn giới thiệu lại các giả định này trong quá trình tái cấu trúc khối, nên bạn không thực sự loại bỏ chúng. Lớp DA luôn cần giả định rằng các khối ban đầu có sẵn, nhưng sau đó các nút cần giao tiếp với nhau để đặt chúng lại với nhau. Sự tái cấu trúc này đòi hỏi hai giả định:

• Bạn có đủ các nút (nhẹ hoặc nặng) lấy mẫu dữ liệu mà chúng có đủ sức mạnh để kết hợp dữ liệu. Đây là một giả định thiểu số trung thực khá yếu, không thể tránh khỏi và không có gì phải lo lắng.

• Giả định về tính đồng bộ được giới thiệu lại - các nút cần giao tiếp trong một khoảng thời gian nhất định trước khi có thể tập hợp lại.

Trình xác nhận Ethereum tải xuống đầy đủ dữ liệu phân đoạn trong PDS (darksharding gốc), trong khi với DS, họ sẽ chỉ thực hiện DAS (tải xuống các hàng và cột được chỉ định). Celestia sẽ yêu cầu trình xác thực tải xuống toàn bộ khối.

Lưu ý rằng trong cả hai trường hợp, chúng tôi cần các giả định đồng bộ hóa để tái thiết. Trong trường hợp các khối chỉ có sẵn một phần, các nút đầy đủ phải giao tiếp với các nút khác để đặt chúng lại với nhau.

Nếu Celestia muốn chuyển từ yêu cầu trình xác thực tải xuống toàn bộ dữ liệu sang chỉ thực hiện DAS, thì lợi thế về độ trễ của KZG sẽ phát huy tác dụng (mặc dù sự thay đổi này hiện chưa được lên kế hoạch). Sau đó, họ cũng cần thực hiện cam kết KZG - chờ đợi bằng chứng gian lận đồng nghĩa với việc tăng khoảng thời gian khối lên rất nhiều và nguy cơ người xác thực bỏ phiếu cho các khối được mã hóa không chính xác cũng sẽ rất cao.

Tôi khuyên bạn nên đọc các bài viết sau để hiểu sâu hơn về cách hoạt động của các cam kết KZG:

• Khái niệm cơ bản (tương đối dễ hiểu) về mật mã đường cong elliptic

• Khám phá các cặp đường cong Elliptic của Vitalik

• Cam kết đa thức KZG của Dankrad

• Nguyên tắc khởi tạo đáng tin cậy của Vitalik

Tách người khởi xướng và người xây dựng trong giao thức

Các nút đồng thuận ngày nay (thợ mỏ) và các nút đồng thuận hợp nhất (người xác minh) đóng các vai trò khác nhau. Họ xây dựng các khối thực tế, sau đó các khối này sẽ được gửi tới các nút đồng thuận khác để xác thực. Những người khai thác "bỏ phiếu" cho khối trước đó và sau khi hợp nhất, những người xác thực sẽ trực tiếp bỏ phiếu xem khối đó hợp lệ hay không hợp lệ.

PBS (Tách biệt người khởi xướng và người xây dựng) tách biệt những điều này - nó rõ ràng tạo ra một vai trò trình xây dựng trong giao thức mới. Các nhà xây dựng chuyên dụng sẽ đặt các khối lại với nhau và đặt giá thầu để người khởi tạo (người xác nhận) chọn khối của họ. Điều này chống lại sức mạnh tập trung của MEV.

Nhìn lại "trò chơi kết thúc" của Vitalik - tất cả các con đường đều dẫn đến sản xuất khối tập trung với xác minh phi tập trung và đáng tin cậy. PBS tiến thêm một bước nữa. Chúng tôi cần một trình xây dựng trung thực để phục vụ tính hợp lệ và khả năng chống kiểm duyệt của mạng (hai sẽ hiệu quả hơn), nhưng bộ trình xác thực cần đa số trung thực. PBS làm cho vai trò của người khởi xướng trở nên đơn giản nhất có thể để hỗ trợ việc phân cấp người xác thực.

Người xây dựng nhận được một khoản phí ưu tiên, cộng với bất kỳ MEV nào họ có thể rút. Trong một thị trường hiệu quả, các nhà xây dựng cạnh tranh sẽ đặt giá thầu cho toàn bộ giá trị mà họ có thể trích xuất từ ​​một khối (trừ đi chi phí khấu hao của họ, chẳng hạn như phần cứng đắt tiền, v.v.). Tất cả giá trị sẽ chảy xuống tập hợp các trình xác thực phi tập trung - đó chính xác là những gì chúng tôi muốn.

Việc triển khai PBS chính xác vẫn đang được thảo luận, nhưng PBS hai khe có thể trông giống như sau:

• Các nhà xây dựng cam kết chặn các tiêu đề trong khi đặt giá thầu

• Người khởi tạo khối đèn hiệu chọn tiêu đề và giá thầu khối chiến thắng. Người khởi tạo được trả tiền vô điều kiện khi thắng thầu, ngay cả khi người xây dựng không sản xuất được thân khối.

• Ủy ban chứng thực xác nhận tiêu đề khối chiến thắng

• Chủ thầu tiết lộ đối tượng trúng thầu

• Một ủy ban nhân chứng khác bầu chọn cơ quan chiến thắng (nếu người xây dựng chiến thắng không trình bày cơ thể, hãy bỏ phiếu để chứng minh sự không tồn tại của nó).

Trình khởi tạo được chọn từ nhóm trình xác thực bằng cơ chế RANDAO tiêu chuẩn. Sau đó, chúng tôi sử dụng chiến lược tiết lộ cam kết trong đó toàn bộ nội dung không được tiết lộ cho đến khi tiêu đề khối được ủy ban xác nhận.

Tiết lộ lời hứa hiệu quả hơn (gửi hàng trăm khối đầy đủ có thể áp đảo băng thông của lớp p2p) và nó cũng ngăn chặn hành vi trộm cắp MEV. Nếu một người xây dựng gửi khối đầy đủ của họ, thì người xây dựng khác có thể nhìn thấy nó, tìm ra chiến lược của nó, kết hợp nó và nhanh chóng xuất bản một khối tốt hơn. Hơn nữa, những người khởi xướng tinh vi có thể phát hiện chiến lược MEV được sử dụng, sao chép nó mà không cần bồi thường cho người xây dựng. Nếu việc đánh cắp MEV này trở thành một lực lượng cân bằng, thì nó sẽ khuyến khích sự hợp nhất của những người xây dựng và người khởi tạo, vì vậy chúng tôi sử dụng chiến lược tiết lộ cam kết để tránh điều này.

Sau khi người khởi xướng chọn tiêu đề khối chiến thắng, nó sẽ được xác nhận bởi ủy ban và được củng cố trong các quy tắc lựa chọn ngã ba. Sau đó, các nhà xây dựng chiến thắng sẽ xuất bản phần nội dung đầy đủ về "khối nhà xây dựng" chiến thắng của họ. Nếu được xuất bản kịp thời, ủy ban tiếp theo sẽ chứng nhận nó. Nếu họ không xuất bản kịp thời, họ vẫn phải thanh toán đầy đủ cho người khởi tạo (và mất tất cả MEV và phí). Khoản thanh toán vô điều kiện này khiến người khởi xướng không cần tin tưởng vào người xây dựng.

Nhược điểm của thiết kế "hai khe cắm" này là độ trễ. Các khối được hợp nhất sẽ là 12 giây cố định, do đó, không đưa ra bất kỳ giả định mới nào, chúng tôi cần 24 giây cho toàn bộ thời gian khối (hai vị trí 12 giây). Vị trí 8 giây (thời gian khối 16 giây) có vẻ như là một sự thỏa hiệp về bảo mật, nhưng nghiên cứu vẫn đang được tiến hành.

Danh sách kháng kiểm duyệt (crList)

Thật không may, PBS đã cung cấp cho các nhà xây dựng rất nhiều khả năng để xem xét các giao dịch. Có thể người xây dựng không thích bạn nên họ bỏ qua thỏa thuận của bạn. Có thể họ làm việc tốt đến mức các nhà xây dựng khác bỏ cuộc, hoặc có thể họ đặt giá cao cho các khối vì họ thực sự không thích bạn.

crLists ngăn chặn điều này. Việc triển khai cụ thể lại là một không gian thiết kế mở, nhưng "PBS lai" dường như là phổ biến nhất. Các nhà xây dựng chỉ định một danh sách tất cả các giao dịch đủ điều kiện mà họ nhìn thấy trong mempool và các nhà xây dựng sẽ buộc phải chấp nhận các giao dịch chung chung (trừ khi khối đầy).

• Người khởi tạo xuất bản crList và thông báo crList với tất cả các giao dịch đủ điều kiện.

• Các nhà xây dựng tạo phần thân khối được đề xuất, sau đó gửi giá thầu bao gồm hàm băm của thông báo crList làm bằng chứng họ đã thấy.

• Người khởi tạo chấp nhận giá thầu và tiêu đề khối của người đặt giá thầu chiến thắng (họ chưa nhìn thấy nội dung khối).

• Các nhà xây dựng xuất bản các khối của họ, bao gồm bằng chứng rằng họ đã bao gồm tất cả các giao dịch trong crList hoặc khối đó đã đầy. Nếu không, khối sẽ không được chấp nhận bởi các quy tắc lựa chọn ngã ba.

• Người làm chứng (attestors) kiểm tra tính hợp lệ của các nguyên tắc đã công bố

Vẫn còn một số vấn đề quan trọng cần được giải quyết ở đây. Ví dụ, một chiến lược kinh tế vượt trội là dành cho người khởi xướng gửi một danh sách trống. Bằng cách đó, ngay cả những nhà xây dựng lẽ ra phải được xem xét kỹ càng cũng có thể thắng cuộc đấu giá miễn là họ trả giá cao nhất. Có nhiều cách giải quyết vấn đề này (hoặc có những cách khác), tôi chỉ nhấn mạnh rằng thiết kế ở đây không vững chắc.

Chiến lược KZG 2D

Chúng tôi đã thấy cách các cam kết của KZG cho phép chúng tôi cam kết với dữ liệu và chứng minh rằng dữ liệu được chia tỷ lệ chính xác. Tuy nhiên, đây là sự đơn giản hóa những gì Ethereum thực sự làm. Nó sẽ không cam kết tất cả dữ liệu trong một cam kết KZG - một khối sẽ sử dụng nhiều cam kết KZG.

Chúng tôi đã có những nhà xây dựng chuyên dụng, vậy tại sao không để họ tạo ra một cam kết KZG khổng lồ? Vấn đề là, điều này đòi hỏi một siêu nút mạnh mẽ để tái cấu trúc. Chúng ta có thể chấp nhận các yêu cầu siêu nút đối với các bản dựng ban đầu, nhưng chúng ta cần tránh đưa ra các giả định về các bản dựng lại. Chúng tôi cần các thực thể chung để có thể xử lý việc xây dựng lại, vì vậy việc chia cam kết KZG thành nhiều phần là tốt. Với lượng dữ liệu có sẵn, việc tái cấu trúc thậm chí có thể khá phổ biến hoặc là một giả định cơ bản trong thiết kế này.

Để giúp việc tái thiết dễ dàng hơn, mỗi khối sẽ bao gồm m dữ liệu phân đoạn được mã hóa thành m cam kết KZG. Nếu bạn không thông minh, việc này sẽ dẫn đến rất nhiều mẫu - bạn sẽ thực hiện DAS trên mỗi đoạn phân đoạn để đảm bảo rằng nó có sẵn (yêu cầu m*k mẫu, trong đó k là số lượng mẫu trên mỗi đoạn).

Do đó, Ethereum sẽ sử dụng chiến lược KZG 2D. Chúng tôi lại sử dụng mã Reed-Solomon để chia tỷ lệ m cam kết thành 2 triệu cam kết.

Chúng tôi biến nó thành chính sách 2D bằng cách mở rộng các cam kết KZG bổ sung (ở đây là 256-511) nằm trên cùng một đa thức như 0-255. Bây giờ chúng ta chỉ cần thực hiện DAS trên bảng trên để đảm bảo có sẵn tất cả dữ liệu shard.

Lấy mẫu 2D yêu cầu 75% dữ liệu có sẵn (so với 50% đã đề cập trước đó), điều đó có nghĩa là chúng tôi cần lấy một số lượng mẫu cố định hơn. Phiên bản đơn giản trước đây của chiến lược 1D yêu cầu 30 mẫu và ở đây, nó sẽ yêu cầu 75 mẫu để đảm bảo rằng xác suất tái tạo lại một khối có thể sử dụng được là nhất quán.

Sharding 1.0 (tương ứng với chiến lược cam kết 1D KZG) chỉ cần 30 mẫu, nhưng bạn cần lấy mẫu 64 phân đoạn và kiểm tra đầy đủ cần 1920 mẫu. Mỗi mẫu là 512 B nên là:

(512 B x 64 lát x 30 mẫu) / 16 giây = băng thông 60 KB/s

Trên thực tế, người xác minh được chọn ngẫu nhiên thay vì kiểm tra tất cả các phân đoạn riêng lẻ.

Hợp nhất các khối với chiến lược 2D KZG giúp xác minh DA đầy đủ cực kỳ dễ dàng. Chỉ cần chọn 75 mẫu từ một khối hợp nhất duy nhất:

(512 B x 1 khối x 75 mẫu) / 16 giây = băng thông 2,5 KB/s

Danksharding

PBS was initially designed to blunt the centralizing forces of MEV on the validator set. However, Dankrad recently took advantage of that design realizing that it unlocked a far better sharding construct – DS.

DS leverages the specialized builder to create a tighter integration of the Beacon Chain execution block and shards. We now have one builder creating the entire block together, one proposer, and one committee voting on it at a time. DS would be infeasible without PBS – regular validators couldn’t handle the massive bandwidth of a block full of rollups’ data blobs:

PBS ban đầu được thiết kế để bảo vệ sức mạnh tập trung của MEV trong nhóm trình xác nhận. Tuy nhiên, Dankrad gần đây đã tận dụng lợi thế của thiết kế này và đưa ra một sơ đồ bảo vệ tốt hơn - DS (Danksharding).

DS sử dụng các trình tạo chuyên dụng để đạt được sự tích hợp chặt chẽ hơn giữa các khối và phân đoạn thực thi Chuỗi Beacon. Bây giờ chúng ta có một người xây dựng tạo ra toàn bộ khối; một người đề xuất; và một ủy ban bỏ phiếu. DS không khả thi nếu không có PBS - các nhà xây dựng thông thường không thể có băng thông khổng lồ để đáp ứng các khối chứa vô số khối cuộn lên.

Sharding 1.0 bao gồm 64 ủy ban độc lập và những người khởi xướng, cho phép mỗi shard đưa ra các vấn đề một cách độc lập. Sự tích hợp chặt chẽ hơn này cho phép chúng tôi đảm bảo tất cả Dữ liệu có sẵn (DA) hoàn chỉnh cùng một lúc. Dữ liệu vẫn được "phân mảnh" trong hộp đen, nhưng từ quan điểm thực tế, các phân đoạn bắt đầu giống như các khối dữ liệu hơn, điều này thật tuyệt.

Danksharding - xác minh đa số trung thực

Chúng ta hãy xem cách người xác minh chứng minh rằng dữ liệu đáng tin cậy:

Điều này đòi hỏi phải dựa vào phần lớn các trình xác thực trung thực - với tư cách là một trình xác thực duy nhất, các cột và hàng của tôi có sẵn, không đủ để mang lại cho tôi sự tin cậy thống kê rằng toàn bộ khối có sẵn. Chúng tôi cần đa số trung thực để đưa ra kết luận này. Xác minh phi tập trung là rất quan trọng.

Lưu ý rằng điều này khác với 75 mẫu ngẫu nhiên mà chúng ta đã thảo luận trước đó. Lấy mẫu ngẫu nhiên riêng tư có nghĩa là các cá nhân có dự phòng thấp sẽ có thể kiểm tra tính khả dụng một cách dễ dàng (ví dụ: tôi có thể chạy nút ánh sáng DAS và biết các khối có sẵn). Tuy nhiên, trình xác thực sẽ tiếp tục sử dụng cách tiếp cận hàng và cột để kiểm tra tính khả dụng và hướng dẫn tái cấu trúc khối.

Danksharding - xây dựng lại

Miễn là 50% của một hàng hoặc cột có sẵn, nó có thể dễ dàng được xây dựng lại hoàn toàn bằng trình xác minh được lấy mẫu. Khi họ xây dựng lại bất kỳ khối nào bị thiếu trong một hàng/cột nhất định, họ sẽ phân phối lại các khối đó thành các đường trực giao. Điều này giúp các trình xác thực khác xây dựng lại bất kỳ khối nào bị thiếu từ các hàng và cột mà chúng giao nhau khi cần.

Các giả định an toàn để xây dựng lại một khối có thể sử dụng ở đây là:

• Có đủ nút thực hiện yêu cầu mẫu để chúng có đủ dữ liệu để xây dựng lại khối

• Giả định đồng bộ hóa giữa các nút đang phát các phân đoạn khối tương ứng của chúng

Vì vậy, bao nhiêu nút là đủ? Ước tính sơ bộ cần 64.000 phiên bản riêng lẻ (hơn 380.000 cho đến nay). Đây cũng là một tính toán rất thận trọng, giả định rằng không có sự giao thoa giữa các nút được điều hành bởi cùng một trình xác thực (điều này khác xa với trường hợp các nút bị giới hạn ở 32 phiên bản ETH). Nếu bạn lấy mẫu nhiều hơn 2 hàng và 2 cột, bạn sẽ tăng cơ hội truy xuất chung do chéo. Điều này bắt đầu mở rộng quy mô bậc hai - nếu trình xác thực đang chạy với 10 hoặc 100 trình xác thực, thì yêu cầu 64.000 có thể giảm theo cấp độ.

DS có thể được đặt để tự động giảm số lượng khối phân đoạn nếu số lượng trình xác thực trực tuyến bắt đầu xuống rất thấp. Do đó, giả định bảo mật sẽ được giảm xuống mức an toàn.

Danksharding - Bảo mật đa số độc hại với lấy mẫu ngẫu nhiên riêng tư

Chúng tôi thấy rằng việc xác minh DS dựa vào đa số trung thực để chứng minh khối. Tôi, với tư cách cá nhân, không thể chứng minh rằng một khối có thể sử dụng được bằng cách tải xuống một số cấp bậc. Tuy nhiên, lấy mẫu ngẫu nhiên riêng tư có thể đảm bảo điều này mà không cần tin tưởng bất kỳ ai. Đây là điều xảy ra khi nút được thảo luận trước đó kiểm tra 75 mẫu ngẫu nhiên.

DS ban đầu sẽ không bao gồm lấy mẫu ngẫu nhiên riêng tư, vì đây là một vấn đề rất khó giải quyết về mặt kết nối mạng (PSA: có thể bạn có thể giúp họ!).

Lưu ý rằng "riêng tư" rất quan trọng vì nếu kẻ tấn công hủy ẩn danh bạn, họ sẽ có thể giả mạo một số lượng nhỏ các nút được lấy mẫu. Họ chỉ có thể trả lại chính xác đoạn dữ liệu mà bạn yêu cầu và giữ lại phần còn lại. Vì vậy, bạn không biết tất cả dữ liệu được cung cấp chỉ từ việc lấy mẫu của riêng bạn.

Danksharding - Tóm tắt chính

DS rất thú vị, không chỉ là một cái tên hay. Cuối cùng nó cũng nhận ra tầm nhìn của Ethereum về một khu định cư thống nhất và lớp DA. Sự kết hợp chặt chẽ giữa các khối đèn hiệu và mảnh vỡ này có thể đạt được hiệu quả không làm vỡ khối thật.

Trên thực tế, hãy xác định lý do tại sao nó thậm chí còn được coi là "phân mảnh". Phân đoạn duy nhất ở đây chỉ đơn giản là thực tế là trình xác thực không chịu trách nhiệm tải xuống tất cả dữ liệu. Không có gì khác.

Vì vậy, nếu bây giờ bạn đang đặt câu hỏi liệu đây có phải là sharding thực sự hay không, thì bạn không điên đâu. Đây là lý do tại sao PDS (chúng ta sẽ sớm nói về điều đó) không được coi là "phân đoạn" (mặc dù nó có "phân đoạn" trong tên của nó, vâng, tôi biết điều đó thật khó hiểu). PDS yêu cầu mỗi trình xác thực tải xuống đầy đủ tất cả các khối để chứng minh tính khả dụng của chúng. DS sau đó đã giới thiệu lấy mẫu, vì vậy những người xác minh riêng lẻ chỉ tải xuống một số phần nhất định của nó.

Phân đoạn tối thiểu có nghĩa là một thiết kế đơn giản hơn so với phân đoạn 1.0 (vì vậy việc phân phối sẽ nhanh hơn, phải không?). Nội dung đơn giản hóa bao gồm:

• So với thông số sharding 1.0, thông số DS có thể ít hơn hàng trăm dòng mã (và ít hơn hàng nghìn dòng mã ở phía máy khách).

• Không còn ủy ban phân đoạn làm cơ sở hạ tầng, các ủy ban chỉ cần bỏ phiếu trên chuỗi chính

• Không cần phải theo dõi các xác nhận shard blob riêng lẻ, giờ đây tất cả chúng đều được xác nhận trong chuỗi chính hoặc không.

Một hệ quả tốt đẹp của điều này là một thị trường phí hợp nhất cho dữ liệu. Sharding 1.0 sẽ làm cho tất cả những thứ này bị phân mảnh với những người khởi tạo khác nhau tạo ra các khối khác nhau.

Các ủy ban chống chia rẽ cũng đã chống hối lộ một cách hiệu quả. Trình xác thực DS bỏ phiếu cho toàn bộ khối một lần trong mỗi kỷ nguyên, vì vậy dữ liệu sẽ được xác nhận ngay lập tức bởi 1/32 của toàn bộ nhóm trình xác thực (32 vị trí trong mỗi kỷ nguyên). Trình xác nhận phân đoạn 1.0 cũng bỏ phiếu một lần mỗi kỷ nguyên, nhưng mỗi phân đoạn có ủy ban riêng cần được tổ chức lại. Do đó, mỗi phân đoạn chỉ được xác nhận bởi 1/2048 nhóm trình xác thực (1/32 được chia cho 64 phân đoạn).

Như đã thảo luận, các khối kết hợp với sơ đồ cam kết 2D KZG cũng làm cho DAS hiệu quả hơn nhiều. Sharding 1.0 yêu cầu băng thông 60KB/giây để kiểm tra tất cả các DA của tất cả các phân đoạn và DS chỉ cần 2,5KB/giây.

Ngoài ra còn có một khả năng thú vị cho DS - các cuộc gọi đồng bộ giữa ZK-rollup và L1 Ethereum thực thi. Các giao dịch từ các khối phân đoạn có thể được xác nhận và ghi vào L1 ngay lập tức, vì mọi thứ được tạo ra trong cùng một khối chuỗi báo hiệu. Sharding 1.0 loại bỏ khả năng này do xác nhận phân đoạn riêng biệt. Điều này để lại một không gian thiết kế thú vị có thể rất có giá trị cho những thứ như tính thanh khoản được chia sẻ (ví dụ: dAMM).

Danksharding——Hạn chế đối với việc mở rộng chuỗi khối

Các lớp mô-đun mở rộng quy mô một cách duyên dáng — phân cấp nhiều hơn dẫn đến mở rộng quy mô hơn. Điều này về cơ bản khác với những gì chúng ta thấy ngày nay. Thêm nhiều nút hơn vào lớp DA có thể tăng thông lượng dữ liệu một cách an toàn (nghĩa là có nhiều chỗ hơn để cho phép tổng số).

Khả năng mở rộng của chuỗi khối vẫn còn hạn chế, nhưng chúng tôi có thể cải thiện nó bằng các đơn đặt hàng lớn hơn so với ngày nay. Một lớp cơ sở an toàn và có thể mở rộng cho phép việc triển khai được mở rộng nhanh chóng. Những cải tiến về lưu trữ dữ liệu và băng thông cũng sẽ tăng thông lượng dữ liệu theo thời gian.

Chắc chắn có thể vượt quá thông lượng DA dự kiến ​​trong bài viết này, nhưng rất khó để nói mức tối đa này sẽ giảm ở đâu. Chúng tôi không có một đường màu đỏ rõ ràng, nhưng có thể liệt kê các khoảng thời gian mà việc hỗ trợ các giả định nhất định bắt đầu trở nên khó khăn.

• Lưu trữ dữ liệu - Đây là về DA và khả năng truy xuất dữ liệu. Vai trò của lớp đồng thuận không phải là đảm bảo rằng dữ liệu có thể được truy xuất vô thời hạn, vai trò của nó là cung cấp dữ liệu đủ lâu để bất kỳ ai sẵn sàng tải xuống đều có thể đáp ứng các giả định bảo mật của chúng tôi. Sau đó, nó sẽ bị bán phá giá ở khắp mọi nơi - điều này thật thoải mái, bởi vì lịch sử là 1 trong số N giả định đáng tin cậy và chúng tôi không thực sự nói về nhiều dữ liệu đó, kế hoạch lớn đó. Tuy nhiên, khi thông lượng tăng lên, nó có thể đi vào lãnh thổ không thoải mái.

• Trình xác nhận - DAS cần đủ các nút để cùng xây dựng lại khối. Nếu không, những kẻ tấn công có thể ngồi đó và chỉ trả lời các truy vấn mà chúng nhận được. Nếu những truy vấn được cung cấp này không đủ để xây dựng lại khối, kẻ tấn công có thể giữ lại phần còn lại và chúng tôi đã chết. Để tăng thông lượng một cách an toàn, chúng tôi cần thêm nhiều nút DAS hơn hoặc tăng yêu cầu băng thông dữ liệu của chúng. Đối với thông lượng được thảo luận ở đây, đây không phải là vấn đề. Tuy nhiên, có thể không thoải mái nếu thông lượng tăng theo vài bậc độ lớn so với thiết kế này.

Lưu ý rằng trình xây dựng không phải là nút cổ chai. Bạn cần nhanh chóng tạo bằng chứng KZG cho 32 MB dữ liệu, vì vậy sẽ cần có GPU hoặc CPU mạnh vừa phải với băng thông ít nhất 2,5 GBit/giây. Dù sao thì đó cũng là một vai trò chuyên biệt và đó là chi phí kinh doanh không đáng kể đối với họ.

Bản địa danksharding (EIP-4844)

DS rất tuyệt, nhưng chúng ta phải kiên nhẫn. PDS ở đây để giúp chúng tôi vượt qua - nó đã thực hiện các bước tương thích chuyển tiếp cần thiết theo một lịch trình chặt chẽ (nhắm mục tiêu vào hard fork Thượng Hải) để cung cấp các đơn đặt hàng có quy mô lớn trong quá trình chuyển đổi. Tuy nhiên, nó không thực sự triển khai bảo vệ dữ liệu (tức là trình xác thực cần tải xuống tất cả dữ liệu riêng lẻ).

Bản cập nhật hôm nay sử dụng dữ liệu lệnh gọi L1 để lưu trữ, dữ liệu này có thể tồn tại vĩnh viễn trên chuỗi. Tuy nhiên, bản tổng hợp chỉ yêu cầu DA trong một số khoảng thời gian ngắn, vì vậy sẽ có nhiều thời gian để bất kỳ ai quan tâm tải xuống.

EIP-4844 giới thiệu một định dạng giao dịch mang blob mới, trong đó tổng số sẽ được sử dụng để lưu trữ dữ liệu trong tương lai. Các đốm màu mang một lượng lớn dữ liệu (khoảng 125KB) và chúng rẻ hơn nhiều so với một lượng dữ liệu cuộc gọi tương tự. Các đốm màu dữ liệu được loại bỏ khỏi các nút sau một tháng, giảm yêu cầu lưu trữ. Điều này cho phép đủ thời gian để đáp ứng các giả định bảo mật DA của chúng tôi.

Đối với bối cảnh mở rộng, các khối Ethereum hiện tại thường trung bình khoảng 90 KB (calldata là khoảng 10 KB trong số đó). PDS giải phóng thêm băng thông DA (mục tiêu ~1MB, tối đa ~2MB) cho các đốm màu khi chúng bị cắt bớt sau một tháng. Họ không gánh nặng các nút mọi lúc.

Một đốm màu là một vectơ gồm 4096 phần tử trường, mỗi phần tử 32 byte. PDS cho phép tối đa 16 đốm màu trên mỗi khối, trong khi DS sẽ tăng con số này lên 256.

Băng thông PDS DA = 4096 x 32 x 16 = 2 MiB mỗi khối, mục tiêu là 1 MiB

Băng thông DS DA = 4096 x 32 x 256 = 32 MiB mỗi khối, mục tiêu là 16 MiB

Mỗi bước là một thứ tự mở rộng cường độ. PDS vẫn yêu cầu các nút đồng thuận để tải xuống đầy đủ dữ liệu, do đó, nó mang tính bảo thủ. DS phân phối tải lưu trữ và truyền dữ liệu giữa các trình xác thực.

Dưới đây là một số tính năng được giới thiệu bởi EIP-4844 trên đường đến DS:

• Dữ liệu định dạng giao dịch mang các đốm màu

• KZG cam kết với blob

• Tất cả logic lớp thực thi theo yêu cầu của DS

• Tất cả logic xác thực chéo thực thi/đồng thuận theo yêu cầu của DS

• Tách lớp giữa xác thực khối đèn hiệu và đốm màu DAS

• Hầu hết logic khối đèn hiệu theo yêu cầu của DS

• Giá gas độc lập tự điều chỉnh cho blobs (EIP-1559 đa chiều với quy tắc định giá theo chỉ số)

DS cũng sẽ bổ sung trong thời gian tới:

• PBS

• DAS

• Chiến lược KZG 2D

• Proof-of-custody hoặc yêu cầu tương tự trong giao thức cho phép mỗi trình xác thực xác minh tính khả dụng của một phần dữ liệu phân đoạn cụ thể trên mỗi khối (khoảng một tháng)

Lưu ý rằng các đốm màu dữ liệu này được giới thiệu dưới dạng một loại giao dịch mới trên chuỗi người thực thi, nhưng chúng không tạo thêm gánh nặng cho người thực thi. EVM chỉ xem xét các cam kết gắn liền với khối dữ liệu. Các thay đổi lớp triển khai được giới thiệu bởi EIP-4844 cũng tương thích chuyển tiếp với DS, không cần thay đổi thêm ở đây. Việc nâng cấp từ PDS lên DS chỉ yêu cầu thay đổi lớp đồng thuận.

Trong PDS, các khối dữ liệu được tải xuống hoàn toàn bởi các máy khách đồng thuận. Các khối dữ liệu hiện được tham chiếu, nhưng không được mã hóa đầy đủ trong phần thân khối báo hiệu. Thay vì nhúng toàn bộ nội dung vào phần thân, nội dung của blob được lan truyền riêng biệt dưới dạng "sidecar". Mỗi khối có một sidecar blob, được tải xuống đầy đủ trong PDS và sau đó là DAS (Lấy mẫu tính khả dụng của dữ liệu) bởi trình xác thực DS.

Chúng tôi đã thảo luận trước đó về cách cam kết với các đốm màu bằng cách sử dụng các cam kết đa thức KZG. Tuy nhiên, thay vì sử dụng KZG trực tiếp, EIP-4844 thực hiện những gì chúng tôi thực sự sử dụng - hàm băm được phiên bản của nó. Đây là một byte 0x01 duy nhất (đại diện cho phiên bản) theo sau là 31 byte cuối cùng của hàm băm SHA256 của KZG.

Chúng tôi làm điều này để tương thích với EVM và tương thích về phía trước:

• Khả năng tương thích EVM - Lời hứa KZG là 48 byte, trong khi EVM sử dụng các giá trị 32 byte một cách tự nhiên hơn

• Khả năng tương thích chuyển tiếp - nếu chúng tôi chuyển từ KZG sang thứ khác (như STARK cho điện trở lượng tử), lời hứa có thể tiếp tục là 32 byte

Đa chiều EIP-1559

Cuối cùng, PDS tạo ra một lớp dữ liệu được thiết kế riêng - các khối dữ liệu sẽ có thị trường phí duy nhất của riêng chúng, với các giới hạn và giá gas thả nổi độc lập. Vì vậy, ngay cả khi một số dự án NFT bán một loạt đất khỉ trên L1, chi phí dữ liệu tổng số của bạn sẽ không tăng (mặc dù chi phí giải quyết bằng chứng sẽ tăng). Điều này cho thấy chi phí chính của bất kỳ dự án tổng số nào hiện nay là xuất bản dữ liệu của nó lên L1 (chứ không phải bằng chứng).

Thị trường phí gas không thay đổi và các khối dữ liệu đã được thêm vào như một thị trường mới:

Phí blob được tính bằng gas, nhưng nó là một khoản thay đổi được điều chỉnh theo cơ chế EIP-1559 của chính nó. Số đốm màu trung bình dài hạn trên mỗi khối phải bằng với mục tiêu đã nêu.

Thực tế có hai phiên đấu giá song song ở đây - một cho tính toán và một cho DA. Đây là một bước tiến lớn để định giá tài nguyên hiệu quả.

Một số thiết kế thú vị có thể được nhìn thấy. Ví dụ: có thể hợp lý khi thay đổi cơ chế định giá gas và blob hiện tại từ EIP-1559 tuyến tính sang cơ chế EIP-1559 theo cấp số nhân mới. Việc triển khai hiện tại không tính trung bình cho kích thước khối mục tiêu của chúng tôi. Tính ổn định của phí cơ sở ngày nay kém, dẫn đến việc sử dụng gas được quan sát trên mỗi khối trung bình cao hơn mục tiêu khoảng 3%.

Phần 2 Lịch sử và Quản lý Nhà nước

Tóm tắt nhanh các khái niệm cơ bản:

• Lịch sử - mọi thứ đã từng xảy ra trên chuỗi. Bạn có thể đặt nó trực tiếp trên ổ cứng vì nó không cần truy cập nhanh. Đây là 1 trong N giả định trung thực về lâu dài.

• Trạng thái - ảnh chụp nhanh tất cả số dư tài khoản hiện tại, hợp đồng thông minh, v.v. Các nút đầy đủ (hiện tại) cần có dữ liệu này để xác thực các giao dịch. Nó quá lớn so với RAM và ổ cứng quá chậm - nó vừa vặn với ổ SSD. Chuỗi khối thông lượng cao cho phép trạng thái này phát triển nhanh chóng, nhanh hơn nhiều so với những gì người bình thường có thể duy trì trên máy tính xách tay của họ. Nếu người dùng hàng ngày không thể giữ trạng thái đó, thì họ không thể xác minh đầy đủ trạng thái đó và việc phân cấp là điều không cần bàn cãi.

Nói tóm lại, những thứ này có thể trở nên rất lớn, vì vậy rất khó để bạn chạy một nút, nếu được yêu cầu, nút phải duy trì dữ liệu này. Nếu quá khó để chạy một nút, những người bình thường chúng ta sẽ không làm điều đó. Điều này thật tệ, vì vậy chúng ta cần đảm bảo điều này không xảy ra.

Giảm chi phí gas cuộc gọi và tổng giới hạn dữ liệu cuộc gọi (EIP-4488)

PDS là một bước tiến tốt đối với DS và nó đáp ứng nhiều yêu cầu cuối cùng. Việc triển khai PDS trong một khung thời gian hợp lý sẽ cho phép đưa ra lịch trình DS.

Một cách khắc phục dễ thực hiện hơn là EIP-4488. Nó ít thanh lịch hơn, nhưng nó vẫn giải quyết được sự cấp bách của phí hiện tại. Rất tiếc là nó không cung cấp các bước cho DS nên chắc chắn sẽ bổ sung sau. Nếu bắt đầu có cảm giác PDS chậm hơn chúng ta mong muốn, thì có thể nhanh chóng vượt qua EIP-4488 (chỉ là một vài dòng sửa đổi mã), rồi truy cập PDS sáu tháng sau đó. Chúng tôi được tự do để dành thời gian của chúng tôi.

EIP-4488 có hai thành phần chính:

• Giảm chi phí dữ liệu cuộc gọi từ 16 gas mỗi byte xuống 3 gas mỗi byte

• Tăng giới hạn Calldata lên 1 MB cho mỗi khối, cộng thêm 300 byte cho mỗi giao dịch (tối đa theo lý thuyết là tổng cộng khoảng 1,4 MB)

Giới hạn cần phải được tăng lên để ngăn chặn điều tồi tệ nhất - một khối chứa đầy calldata sẽ đạt tới 18 MB, vượt xa khả năng xử lý của Ethereum. EIP-4488 tăng dung lượng dữ liệu trung bình của Ethereum, nhưng do giới hạn dữ liệu cuộc gọi này (30 triệu gas/16 gas trên mỗi byte dữ liệu cuộc gọi = 1,875 MB), dung lượng dữ liệu bùng nổ của nó thực sự sẽ giảm nhẹ.

Tải duy trì cho EIP-4488 cao hơn nhiều so với PDS, vì đây vẫn là khối dữ liệu so với khối dữ liệu (có thể được cắt bớt sau một tháng). Với EIP-4488, tốc độ tăng trưởng sẽ tăng lên một cách có ý nghĩa, nhưng cũng sẽ tạo ra nút thắt cổ chai cho các nút đang chạy. Ngay cả khi EIP-4444 được triển khai đồng thời với EIP-4488, nó sẽ chỉ làm giảm lịch sử tải trọng thực thi một năm sau đó. Tải trọng duy trì thấp hơn của PDS rõ ràng là tốt hơn.

Định tính dữ liệu lịch sử trong máy khách thực thi (EIP-4444)

EIP-4444 cho phép khách hàng chọn cắt cục bộ dữ liệu lịch sử (bao gồm tiêu đề, nội dung và biên nhận) cũ hơn một năm. Nó quy định rằng khách hàng ngừng cung cấp dữ liệu lịch sử đã được cắt tỉa như vậy ở lớp p2p. Cắt bớt dữ liệu lịch sử cho phép khách hàng giảm yêu cầu lưu trữ trên đĩa của người dùng (hiện tại là hàng trăm gigabyte và đang tiếp tục tăng).

Điều này vốn đã quan trọng, nhưng nếu EIP-4488 được triển khai, về cơ bản nó sẽ là bắt buộc (vì nó làm tăng đáng kể dữ liệu lịch sử). Chúng tôi hy vọng điều này có thể được thực hiện trong một khoảng thời gian tương đối ngắn. Cuối cùng, một số hình thức hết hạn lịch sử sẽ cần thiết, vì vậy bây giờ là thời điểm tốt để giải quyết nó.

Lịch sử là cần thiết để đồng bộ hóa hoàn toàn chuỗi, nhưng không phải để xác thực các khối mới (chỉ trạng thái). Do đó, khi một máy khách đã đồng bộ hóa với đầu chuỗi, dữ liệu lịch sử sẽ chỉ được truy xuất nếu được yêu cầu rõ ràng qua JSON-RPC hoặc khi một đồng nghiệp cố gắng đồng bộ hóa chuỗi. Với việc triển khai EIP-4444, chúng tôi cần tìm các giải pháp thay thế cho những vấn đề này.

Khách hàng sẽ không thể thực hiện "đồng bộ hóa hoàn toàn" với devp2p như hiện nay - thay vào đó, họ sẽ "đồng bộ hóa điểm kiểm tra" từ một điểm kiểm tra chủ quan yếu, mà họ sẽ coi là khối gốc.

Lưu ý rằng tính chủ quan yếu sẽ không phải là một giả định bổ sung - đó là điều không thể tránh khỏi khi chuyển sang PoS. Do khả năng bị tấn công từ xa, điều này đòi hỏi phải sử dụng các điểm kiểm tra chủ quan yếu hiệu quả để đồng bộ hóa. Giả định ở đây là các máy khách sẽ không đồng bộ hóa từ một điểm kiểm tra chủ quan yếu kém hoặc không hợp lệ. Điểm kiểm tra này phải nằm trong khoảng thời gian chúng tôi bắt đầu cắt xén dữ liệu lịch sử (ở đây trong vòng một năm), nếu không, lớp p2p sẽ không thể cung cấp dữ liệu cần thiết.

Điều này cũng sẽ giảm mức sử dụng băng thông trên mạng khi ngày càng có nhiều khách hàng áp dụng chiến lược đồng bộ hóa nhẹ.

khôi phục dữ liệu lịch sử

EIP-4444 sẽ cắt bớt dữ liệu lịch sử sau một năm nghe có vẻ tốt, trong khi PDS sẽ cắt bớt các đốm màu nhanh hơn (sau khoảng một tháng). Đây là những hành động cần thiết vì chúng tôi không thể yêu cầu các nút lưu trữ tất cả dữ liệu và duy trì tính phi tập trung.

• EIP-4488 - có thể cần khoảng 1 MB cho mỗi ổ cắm trong thời gian dài, thêm khoảng 2,5 TB dung lượng lưu trữ mỗi năm

• PDS - Mục tiêu ~1MB mỗi ổ cắm, thêm ~2,5TB dung lượng lưu trữ mỗi năm

• DS - Mục tiêu ~16MB mỗi ổ cắm, thêm ~40TB dung lượng lưu trữ mỗi năm

Nhưng dữ liệu đã đi đâu? Chúng ta vẫn cần chúng chứ? Có, nhưng lưu ý rằng việc mất dữ liệu lịch sử không phải là rủi ro đối với giao thức - chỉ đối với ứng dụng riêng lẻ. Do đó, công việc của giao thức lõi Ethereum không nên bao gồm việc duy trì vĩnh viễn tất cả các dữ liệu đồng thuận này.

Vì vậy, ai sẽ lưu trữ dữ liệu này? Dưới đây là một số người đóng góp tiềm năng:

• Tình nguyện viên cá nhân và tổ chức

• Trình khám phá khối (như etherscan.io), nhà cung cấp API và các dịch vụ dữ liệu khác

• Các giao thức lập chỉ mục của bên thứ ba như TheGraph có thể tạo ra các thị trường được khuyến khích nơi khách hàng trả tiền cho máy chủ để có dữ liệu lịch sử với bằng chứng Merkle

• Khách hàng trong Mạng cổng thông tin (hiện đang được phát triển) có thể lưu trữ các phần ngẫu nhiên của lịch sử chuỗi và Mạng cổng thông tin sẽ tự động hướng các yêu cầu dữ liệu đến các nút sở hữu dữ liệu

• Ví dụ: BitTorrent tự động tạo và phân phối tệp 7GB chứa dữ liệu blob cho các khối mỗi ngày

• Một số giao thức ứng dụng (chẳng hạn như tổng số) có thể yêu cầu các nút của chúng lưu trữ các phần lịch sử liên quan đến ứng dụng của chúng

Bài toán lưu trữ dữ liệu dài hạn là một bài toán tương đối dễ vì nó là một trong N giả định về độ tin cậy, như chúng ta đã thảo luận trước đó. Vấn đề này còn nhiều năm nữa mới trở thành giới hạn cuối cùng đối với khả năng mở rộng của chuỗi khối.

yếu quốc tịch

Ok, chúng tôi đã xử lý tốt việc quản lý lịch sử, nhưng còn trạng thái thì sao? Đây thực sự là nút cổ chai chính trong việc cải thiện TPS của Ethereum hiện tại.

Các nút đầy đủ lấy gốc trạng thái trước, thực hiện tất cả các giao dịch trong một khối và kiểm tra xem gốc sau trạng thái có khớp với những gì chúng đã cung cấp trong khối hay không. Để biết liệu các giao dịch này có hợp lệ hay không, hiện tại họ cần xác minh trạng thái trên tay.

Chuyển sang trạng thái không trạng thái - không cần trạng thái có sẵn để thực hiện vai trò của nó. Ethereum đang hướng tới trạng thái "không trạng thái yếu", nghĩa là trạng thái đó không cần thiết để xác thực các khối, nhưng cần thiết để xây dựng các khối. Xác thực trở thành một chức năng thuần túy - hãy cho tôi một khối hoàn toàn biệt lập và tôi có thể cho bạn biết liệu nó có hoạt động hay không. Về cơ bản như thế này:

Các nhà xây dựng vẫn cần trạng thái do PBS, điều này có thể chấp nhận được - dù sao thì chúng cũng sẽ là các thực thể cấu hình cao tập trung hơn. Trọng tâm của chúng tôi là phân cấp trình xác nhận. Tình trạng không quốc tịch yếu tạo ra nhiều công việc hơn cho người xây dựng và ít công việc hơn cho người xác minh. Thỏa thuận tuyệt vời.

Chúng tôi sử dụng các nhân chứng để thực hiện cuộc hành quyết không quốc tịch kỳ diệu này. Nhân chứng là bằng chứng về quyền truy cập trạng thái chính xác và những người xây dựng sẽ bắt đầu đưa những bằng chứng này vào mỗi khối. Bạn thực sự không cần toàn bộ trạng thái để xác thực một khối - bạn chỉ cần trạng thái đã được đọc hoặc bị ảnh hưởng bởi các giao dịch trong khối đó. Các nhà xây dựng sẽ bắt đầu bao gồm các phần trạng thái bị ảnh hưởng bởi các giao dịch trong một khối nhất định và họ sẽ sử dụng các nhân chứng để chứng thực rằng họ đã truy cập chính xác các trạng thái đó.

Hãy lấy một ví dụ. Alice muốn gửi 1 ETH cho Bob. Để xác thực khối cho giao dịch này, tôi cần biết:

• Trước giao dịch - Alice có 1 ETH

• Khóa công khai của Alice - để tôi có thể biết chữ ký là chính xác

• Alice's nonce - để tôi có thể biết các giao dịch đã được gửi theo đúng thứ tự

• Sau khi thực hiện giao dịch, Bob kiếm được 1 ETH và Alice mất 1 ETH

Trong một thế giới không có trạng thái yếu, các nhà xây dựng thêm dữ liệu nhân chứng nói trên vào các khối và chứng thực tính chính xác của nó. Trình xác thực nhận khối, thực thi khối và quyết định xem khối đó có hợp lệ hay không. Vậy là được rồi.

Từ góc độ trình xác thực, đây là một số hàm ý:

• Yêu cầu SSD khổng lồ cần thiết để duy trì trạng thái đã không còn nữa - một nút cổ chai quan trọng đối với việc mở rộng quy mô ngày nay.

• Yêu cầu về băng thông sẽ tăng lên một chút vì bạn hiện cũng đang tải xuống dữ liệu nhân chứng và bằng chứng. Đây là một nút cổ chai đối với cây Merkle-Patricia, nhưng không phải là một vấn đề lớn, không phải là loại nút cổ chai mà Verkle Tries gặp phải.

• Bạn vẫn thực hiện các giao dịch để xác thực đầy đủ. Tình trạng không quốc tịch thừa nhận thực tế rằng đây hiện không phải là nút cổ chai trong việc mở rộng quy mô Ethereum.

Tình trạng không trạng thái yếu cũng cho phép Ethereum nới lỏng các ràng buộc tự đặt ra đối với thông lượng thực thi và tình trạng phình to trạng thái không còn là mối quan tâm cấp bách. Có thể hợp lý để tăng giới hạn gas lên 3 lần.

Tại thời điểm này, hầu hết việc thực thi của người dùng sẽ ở trên L2, nhưng thông lượng L1 cao hơn thậm chí có lợi cho họ. Rollup dựa trên Ethereum cho DA (xuất bản lên các phân đoạn) và thanh toán (yêu cầu thực thi L1). Khi Ethereum mở rộng lớp DA của nó, chi phí khấu hao của việc phát hành bằng chứng có thể chiếm một phần lớn hơn trong chi phí tổng hợp (đặc biệt là đối với ZK-rollup).

Verkle Tries (Verkle Tries)

Chúng tôi đã cố ý bỏ qua cách những nhân chứng này làm việc. Ethereum hiện đang sử dụng cây Merkle-Patricia để lưu trữ trạng thái, nhưng các bằng chứng Merkle cần thiết là quá lớn để những bằng chứng này trở nên khả thi.

Ethereum sẽ chuyển sang trạng thái cố gắng lưu trữ của Verkle. Bằng chứng Verkle hiệu quả hơn nhiều, vì vậy chúng có thể được sử dụng làm nhân chứng khả thi để đạt được tình trạng không quốc tịch yếu.

Trước tiên, hãy xem lại cây Merkle trông như thế nào. Mọi giao dịch đều bắt đầu bằng một hàm băm - những hàm băm này ở dưới cùng được gọi là "lá". Tất cả các giá trị băm được gọi là "nút", là giá trị băm của hai nút con bên dưới. Kết quả băm là "Merkle root".

Cấu trúc dữ liệu này rất hữu ích trong việc chứng minh tính toàn vẹn của các giao dịch mà không cần tải xuống toàn bộ cây. Ví dụ: nếu bạn muốn xác minh rằng giao dịch H4 đã được đưa vào, bạn cần có H12, H3 và H5678 từ bằng chứng Merkle. Chúng tôi có H12345678 từ tiêu đề khối. Vì vậy, một máy khách hạng nhẹ có thể yêu cầu một nút đầy đủ cho các giá trị băm này và băm chúng lại với nhau theo tuyến đường trong cây. Nếu kết quả là H12345678, thì chúng ta đã chứng minh thành công rằng H4 có trên cây.

Nhưng cây càng sâu thì đường xuống phía dưới càng dài, vì vậy bạn cần nhiều vật phẩm hơn để biện minh. Do đó, các cây nông và rộng phù hợp hơn để chứng minh hiệu quả.

Vấn đề là nếu bạn cố gắng làm cho cây Merkle rộng hơn bằng cách thêm nhiều nút con hơn dưới mỗi nút thì sẽ rất kém hiệu quả. Bạn cần băm giá trị băm của tất cả các nút ngang hàng với nhau để chạm vào toàn bộ cây, vì vậy bạn cần chấp nhận nhiều giá trị băm hơn của các nút ngang hàng cho các bằng chứng Merkle. Điều này sẽ làm cho kích thước của bằng chứng rất lớn.

Đây là những gì lời hứa vector hiệu quả làm. Lưu ý rằng các giá trị băm được sử dụng trong cây Merkle thực sự là các cam kết vectơ - chúng chỉ là các cam kết xấu chỉ có thể cam kết hiệu quả với hai phần tử. Vì vậy, chúng tôi muốn các cam kết vectơ mà chúng tôi không cần nhận tất cả các đồng nghiệp để xác minh. Khi chúng ta có cái này, chúng ta có thể làm cho cái cây rộng hơn và giảm độ sâu của nó. Đây là cách chúng tôi đạt được kích thước bằng chứng hiệu quả - giảm lượng thông tin cần cung cấp.

Một bộ ba Verkle tương tự như cây Merkle, nhưng nó cam kết các con của nó bằng cách sử dụng các cam kết vectơ hiệu quả (do đó có tên là "Verkle") thay vì các giá trị băm đơn giản. Vì vậy, ý tưởng cơ bản là mỗi nút có thể có nhiều nút con, nhưng tôi không cần tất cả chúng để xác minh bằng chứng. Đây là một bằng chứng về kích thước không đổi bất kể chiều rộng.

Trên thực tế, chúng tôi đã đề cập đến một ví dụ điển hình về khả năng này trước đây - cam kết KZG cũng có thể được sử dụng làm cam kết vectơ. Trên thực tế, đây là những gì các nhà phát triển ethereum ban đầu dự định sử dụng ở đây. Sau đó, họ chuyển sang cam kết của Pedersen để hoàn thành một vai trò tương tự. Nó sẽ dựa trên một đường cong elip (ở đây đề cập đến Bandersnatch), hứa hẹn 256 giá trị (tốt hơn nhiều so với hai!).

Vậy tại sao không xây dựng cây có độ sâu 1, càng rộng càng tốt? Điều này rất tốt cho người xác minh vì giờ đây anh ta có một bằng chứng siêu nhỏ gọn. Nhưng có một sự đánh đổi thực tế là người xác minh cần có khả năng tính toán bằng chứng này và càng rộng thì càng khó. Do đó, các lần thử của Verkle sẽ nằm giữa hai cực trị của chiều rộng giá trị 1~256.

trạng thái hết hạn

Tình trạng không trạng thái yếu sẽ loại bỏ các ràng buộc lạm phát trạng thái khỏi trình xác thực, nhưng trạng thái không biến mất một cách kỳ diệu. Chi phí giao dịch được giới hạn, nhưng chúng áp đặt thuế vĩnh viễn đối với mạng bằng cách tăng trạng thái. Tăng trưởng nhà nước vẫn là một lực cản vĩnh viễn trên mạng. Chúng ta cần phải làm gì đó để khắc phục vấn đề cơ bản này.

Đó là lý do tại sao chúng ta cần hết hạn trạng thái. Thời gian dài không hoạt động (chẳng hạn như một hoặc hai năm) sẽ bị hạn chế, ngay cả những thứ mà các nhà xây dựng khối sẽ đưa vào. Người dùng đang hoạt động sẽ không nhận thấy bất kỳ thay đổi nào và chúng tôi có thể loại bỏ trạng thái nặng không còn cần thiết.

Nếu bạn cần khôi phục trạng thái hết hạn, bạn chỉ cần xuất trình bằng chứng và kích hoạt lại. Điều này rơi trở lại một trong N giả định lưu trữ. Miễn là ai đó vẫn có toàn bộ lịch sử (trình khám phá khối, v.v.), bạn có thể nhận được thứ mình cần từ họ.

Tình trạng không trạng thái yếu sẽ làm suy yếu nhu cầu hết hạn trạng thái ngay lập tức trong lớp cơ sở, nhưng lại tốt về lâu dài, đặc biệt là khi thông lượng L1 tăng lên. Đối với các bản tổng hợp thông lượng cao, đây sẽ là một công cụ hữu ích hơn. Trạng thái L2 sẽ phát triển với tốc độ cao hơn đến mức nó sẽ kéo cả những nhà xây dựng cấu hình cao xuống.

Phần 3 Tất cả là lỗi của MEV

PBS là điều kiện cần thiết để triển khai an toàn DS (Danksharding), nhưng hãy nhớ rằng thiết kế ban đầu của nó thực sự là để chống lại sức mạnh tập trung của MEV. Bạn sẽ nhận thấy một xu hướng định kỳ trong nghiên cứu Ethereum ngày nay - MEV hiện đang dẫn đầu và là trung tâm trong kinh tế học tiền điện tử.

Khi thiết kế một chuỗi khối, việc xem xét MEV là chìa khóa để duy trì bảo mật và phân cấp. Các phương thức cấp giao thức cơ bản là:

• Giảm thiểu các MEV có hại càng nhiều càng tốt (ví dụ: thời hạn cuối cùng của một vị trí, lựa chọn thủ lĩnh bí mật duy nhất)

• Dân chủ hóa phần còn lại (ví dụ: MEV-Boost, PBS, MEV smoothing)

Phần còn lại phải được nắm bắt và phổ biến dễ dàng giữa các trình xác nhận. Nếu không, nó sẽ tập trung hóa nhóm trình xác thực bằng cách không thể cạnh tranh với những người tìm kiếm tinh vi. Điều này càng trở nên trầm trọng hơn bởi MEV có tỷ lệ phần thưởng cho người xác thực cao hơn nhiều sau khi sáp nhập (việc phát hành cổ phần thấp hơn nhiều so với lạm phát dành cho người khai thác). Điều này không thể bỏ qua.

Chuỗi cung ứng MEV ngày nay

Chuỗi sự kiện hôm nay trông như thế này:

Các nhóm khai thác đóng vai trò của những người xây dựng ở đây. MEV Seekers chuyển tiếp các gói giao dịch (cùng với giá thầu tương ứng của chúng) tới các nhóm khai thác thông qua Flashbot. Người điều hành nhóm khai thác tổng hợp một khối hoàn chỉnh và chuyển tiêu đề khối cho từng người khai thác. Những người khai thác sử dụng PoW để chứng minh khối và cho nó trọng lượng trong quy tắc lựa chọn ngã ba.

Flashbots ở đây để ngăn chặn sự tích hợp theo chiều dọc của toàn bộ ngăn xếp - điều này sẽ mở ra cơ hội cho sự kiểm duyệt và những kẻ bên ngoài khó chịu khác. Khi Flashbot ra đời,