Nguồn gốc: Delphi Digital

Tổng hợp văn bản gốc: The Way of DeFi

những điểm chính

• Nguồn gốc: Delphi Digital

• Tổng hợp văn bản gốc: The Way of DeFi

• những điểm chính

• Ethereum là giao thức chính duy nhất 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

• Tính toán quy mô tổng số trong khi tận dụng bảo mật của Ethereum

• Mọi con đường đều dẫn đến sản xuất khối tập trung, xác thực khối không tin cậy phi tập trung và kết thúc chống kiểm duyệt

• MEV hiện đang ở phía trước và trung tâm - rất nhiều 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ó

Giới thiệu

Danksharding kết hợp nhiều con đường 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 Rollup của Ethereum

Tôi hy vọng sẽ đạt được danksharding trong cuộc đời của chúng ta

Giới thiệu

Phần I – Con đường đến Danksharding

1) Thiết kế phân đoạn dữ liệu thô – người đề xuất phân đoạn độc lập

2) Lấy mẫu dữ liệu sẵn có

3) Cam kết của KZG

4) Lời hứa và bằng chứng gian lận của KZG

8) Danksharding

5) Tách người đề xuất-xây dựng trong giao thức

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

7) Sơ đồ KZG hai chiều

9) Danksharding – xác minh đa số trung thực

10) Danksharding – xây dựng lại

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

12) Danksharding – Những điểm chính

13) Danksharding – Hạn chế về khả năng mở rộng chuỗi khối

14) Đúc thô (EIP-4844)

15) Đa chiều EIP-1559

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

1) Giảm dung lượng dữ liệu cuộc gọi bằng tổng giới hạn dữ liệu cuộc gọi (EIP-4488)

5) Verkle Tries

2) Giới hạn thực thi dữ liệu lịch sử trong máy khách (EIP-4444)

3) Khôi phục dữ liệu lịch sử

4) Không quốc tịch yếu

2) MEV-Boost

6) Nhà nước hết hạn

Phần III – Tất cả là MEV

1) Chuỗi cung ứng MEV hiện tại

3) Làm mịn MEV do ủy ban điều hành

4) Tính xác định một khe

5) Bầu cử lãnh đạo bí mật duy nhất

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

Giới thiệu

2) Đồng thuận hợp nhất

suy nghĩ kết luận

Giới thiệu

Tôi đã hoài nghi về dòng thời gian của The Merge kể từ khi Vitalik nói rằng những người sinh ra ngày nay có 50-75% cơ hội sống đến 3000 năm và anh ấy hy vọng sẽ sống mãi mãi. Tuy nhiên, hãy coi đây như một trò đùa, dù sao thì chúng ta vẫn phải trông chờ vào lộ trình đầy tham vọng của Ethereum.Đây không phải là một bài đọc nhanh. 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ờ tập trung 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 hướng nghiên cứu về Ethereum để theo dõi trong thời gian dài, nhưng mọi thứ cuối cùng đều phù hợp với một mục tiêu bao quát — mở rộng quy mô tính toán mà không phải hy sinh xác thực phi tập trung.

Hy vọng bạn đã quen với câu nói nổi tiếng của Vitalik "

tàn cuộc

• “Một bài báo. Trong bài viết của mình, ông thừa nhận rằng cần phải tập trung hóa để đạt được quy mô. Từ "C" này thật đáng sợ trong blockchain, nhưng đó là sự thật. Chúng ta chỉ cần duy trì sức mạnh này thông qua xác minh phi tập trung và không tin cậy. Không có sự thỏa hiệp ở đây.

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

• Đây là bảng thuật ngữ để viết tắt một số từ sẽ xuất hiện ~43531756765713534 lần:

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

• DS–Danksharding

• DAS – Lấy mẫu dữ liệu sẵn có

• PBS – phân tách người đề xuất-người xây dựng

PDS – darksharding thô

PoW - Bằng chứng Công việc

PoS – Bằng chứng cổ phần

Phần I: Con đường đến Danksharding

Hy vọng rằng bây giờ bạn đã biết rằng Ethereum đã chuyển sang lộ trình tập trung vào Rollup. Không còn sharding nữa - Thay vào đó, Ethereum sẽ được 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 (kế hoạch của Ethereum) hoặc các khối lớ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ó có một công việc phải làm - đả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ư Rollup, Fraud và ZK Proofs cũng như lý do tại sao DA lại quan trọng. Nếu bạn chưa quen hoặc chỉ cần xem lại, báo cáo được xuất bản gần đây của Can về Celestia sẽ đề cập đến chúng.

Thiết kế phân đoạn dữ liệu thô - người đề xuất phân đoạn độc lập

Thiết kế được mô tả ở đây đã lỗi thời, nhưng nó là một kịch bản có giá trị. Để đơn giản, tôi sẽ gọi đây là "sharding 1.0".

Mỗi khối trong số 64 khối phân đoạn đều có những người đề xuất và ủy ban độc lập, luân phiên từ tập hợp các 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, đây không phải là DAS - nó dựa vào phần lớn 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 kém hơn và các vectơ tấn công. Xáo trộn các trình xác thực giữa các phân đoạn là một việc khó.

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

DS hoàn toàn khác. Trình xác nhận thực thi 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). Trình tạo chuyên dụng tạo một khối lớn với khối đèn hiệu và tất cả dữ liệu phân đoạn được xác nhận cùng nhau. Do đó, PBS là cần thiết để DS duy trì tính phi tập trung (xây dựng các khối lớn cùng nhau cần nhiều tài nguyên).

• Lấy mẫu dữ liệu sẵn có

• Tổng số xuất bản rất nhiều dữ liệu, nhưng chúng tôi không muốn các nút tải xuống tất cả dữ liệu này. Điều này có nghĩa là yêu cầu tài nguyên 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ả ứng dụng khách nhẹ) xác minh dễ dàng và an toàn rằng mọi thứ đều khả dụng mà không cần tải xuống mọi thứ.

Giải pháp đơn giản - chỉ cần kiểm tra một loạt các khối ngẫu nhiên trong khối đó. Nếu họ đều ký thì tôi ký. Nhưng nếu bạn bỏ lỡ một giao dịch đưa tất cả ETH của bạn cho Sifu thì sao? Các quỹ không còn an toàn.

Giải pháp thông minh - xóa sạch dữ liệu trước. Mở rộng dữ liệu 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 tôi sẽ đánh giá ở nhiều nơi khác. Điều này được thực hiện trong một lần, vì vậy hãy phá vỡ nó.

Đối với những người gặp khó khăn trong việc hiểu toán học, hãy nhanh chóng giải thích. (Tôi hứa rằng nó sẽ không phải là một môn toán thực sự khủng khiếp - tôi đã phải xem một số video của Khan Academy để viết các phần, nhưng giờ thì tôi hiểu rồi).

Đa thức là một biểu thức tính tổng bất kỳ số lượng hữu hạn các số hạng có dạng cxk. Độ là số mũ cao nhất. Ví dụ, 2 x3+6 x2+2 x-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 d nào từ bất kỳ tọa độ d+1 nào nằm trên đa thức đó.

Bây giờ hãy đưa ra một ví dụ cụ thể. Dưới đây chúng tôi có bốn khối dữ liệu (d0 đến d3). Những khối dữ liệu này có thể được ánh xạ tới một đánh giá của đa thức f(X) tại một điểm nhất định. Ví dụ: f(0) = d0. Bây giờ bạn đã tìm được đa thức bậc nhỏ nhất chạy qua các đánh giá này. Vì đây là bốn khối, nên chúng ta có thể tìm được một đa thức bậc ba. Sau đó, chúng tôi có thể mở rộng dữ liệu này để thêm bốn đánh giá (e0 đến e3) dọc theo cùng một đa thức.

Hãy nhớ thuộc tính đa thức khóa - 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 dữ liệu 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 có sẵn 50% (4/8) dữ liệu được mã hóa xóa. Từ đó, chúng ta có thể xây dựng lại toàn bộ khối.

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

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

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 có một câu hỏi khác - mã xóa dữ liệu có đúng 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à chúng tôi đã lấy mẫu rác. 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 có hiệu quả để chứng minh rằng một bộ sưu tập chứa dữ liệu nhất định.

• 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. Rễ Merkle không biện minh cho điều này. Vì vậy, nếu bạn sử dụng kế hoạch này, bạn cũng cần có bằng chứng gian lận, đề phòng trường hợp có điều gì đó sai trái xảy ra.

Các nhà phát triển đang làm việc theo hai hướng:

Celestia đang đi theo con đường phòng chống gian lận. Ai đó cần lưu ý rằng 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 một vài giả định trung thực tiêu chuẩn và giả định về tí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 mình đã kết nối 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 thực hiện một lộ trình 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 bảo mật đồng bộ và thiểu số trung thực về bằng chứng gian lận (mặc dù chúng vẫn ở đó để xây dựng lại, như chúng ta sẽ sớm đề cập).

Các giải pháp khác tồn tại nhưng không được tích cực theo đuổi. 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ải thiện trong vài năm tới, vì vậy Ethereum có thể chuyển sang STARK trong tương lai, vì KZG hứa hẹn sẽ không kháng lượng tử.

Quay lại cam kết KZG - đây là một chương trình cam kết đa thức.

• Một sơ đồ cam kết chỉ đơn giản là một cách mã hóa để chứng minh cam kết với một số giá trị. 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à đưa nó cho người khác. Không thể thay đổi chữ cái khi đã ở bên trong, nhưng nó có thể được mở bằng chìa khóa và được chứng thực. Những gì bạn cam kết là lời hứa, và điều quan trọng 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 đi qua 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ữ sẽ hứa:

Đây là điểm mấu chốt:

• Ta có một "đa thức" f(X)

• Người tục ngữ “dấn thân” vào đa thức C(f)

• Điều này dựa trên mật mã đường cong elip với thiết lập đáng tin cậy. Để biết thêm chi tiết về cách thức hoạt động của tính năng này, hãy xem một bài đăng tuyệt vời của Bartek

• Đối với bất kỳ "đánh giá" nào của đa thức y = f(z) này, người chứng minh có thể tính toán "chứng minh" π(f,z)

• Đưa ra cam kết C(f), bằng chứng π(f,z), vị trí z bất kỳ và đánh giá y của đa thức tại z, người xác minh có thể xác nhận rằng f(z) = y

• Giải thích: Người xác minh cung cấp những phần này cho bất kỳ người xác minh nào, người sau đó có thể xác nhận rằng đánh giá tại một số điểm (trong đó đánh giá đại diện cho dữ liệu cơ bản) nằm chính xác trên đa thức đã cam kết

• Điều này chứng tỏ rằng dữ liệu gốc được chia tỷ lệ chính xác, vì tất cả các đánh giá đều nằm trên cùng một đa thức

• Lưu ý rằng trình xác minh không cần đa thức f(X)

• Các thuộc tính quan trọng - Điều này có kích thước cam kết O(1), kích thước bằng chứng O(1) và thời gian xác minh O(1). Cam kết và quy mô tạo bằng chứng chỉ trong O(d) ngay cả đối với câu tục ngữ, trong đó d là bậc của đa thức

• Giải thích: Ngay cả khi n (số giá trị trong X) tăng (tức là khi tập dữ liệu tăng với các đốm màu lớn hơn) - lời hứa và bằng chứng vẫn giữ nguyên kích thước và việc xác minh đòi hỏi nỗ lực liên tục

Cả hai đều cam kết với C(f) và chứng minh rằng π(f,z) chỉ là một phần tử đường cong elip trên đường cong thân thiện với cặp (điều này sẽ sử dụng BL12-381). Trong trường hợp này, chúng chỉ có 48 byte mỗi cái (rất nhỏ)

Do đó, người chứng minh gửi một lượng lớn dữ liệu gốc và dữ liệu mở rộng (đại diện cho nhiều đánh giá của đa thức) vẫn chỉ là 48 byte và bằng chứng cũng chỉ là 48 byte

TLDR – đây là khả năng mở rộng cao

Sau đó, gốc KZG (cam kết đa thức) tương tự như gốc Merkle (là cam kết vectơ):

Dữ liệu ban đầu là một đa thức f(X) được tính tại các vị trí f(0) tới f(3), sau đó chúng ta mở rộng bằng cách tính đa thức tại f(4) tới f(7). Tất cả các điểm f(0) đến f(7) đảm bảo cùng nằm trên một đa thức.

Điểm mấu chốt: 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. Cam kết của KZG chứng minh cho chúng tôi thấy rằng dữ liệu gốc được thu nhỏ đúng cách và hứa hẹn tất cả chúng.

Làm tốt lắm, đó là những gì đại số cho ngày hôm nay.

Lời hứa của KZG và 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 một bước và so sánh hai cách tiếp cận.

• Nhược điểm của KZG - nó không an toàn sau lượng tử, nó yêu cầu thiết lập đáng tin cậy. Những điều này không đáng lo ngại. STARK cung cấp giải pháp thay thế hậu lượng tử, trong khi thiết lập đá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 - độ trễ thấp hơn so với thiết lập bằng chứng gian lận (mặc dù, như đã nêu trước đó, GASPER dù sao cũng sẽ không hoàn thiện nhanh) và nó đảm bảo mã hóa xóa chính xác mà không đưa ra một số giả định vốn có về tính đồng bộ và trung thực.

Tuy nhiên, do Ethereum vẫn giới thiệu lại các giả định này để 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 lập kế hoạch cho kịch bản mà khối được cung cấp ban đầu, nhưng sau đó các nút cần giao tiếp với nhau để đặt nó trở 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 đầy đủ) lấy mẫu dữ liệu để chúng đủ tốt để ghép chúng lại với nhau. Đây là một giả định thiểu số trung thực khá yếu và không thể tránh khỏi, vì vậy không phải là một vấn đề lớn.

Giới thiệu lại giả định về tính đồng bộ - các nút cần có khả năng giao tiếp trong một khoảng thời gian để liên kết lại với nhau.

Trình xác thực Ethereum tải xuống đầy đủ các đốm màu phân đoạn trong PDS và với DS, chúng sẽ chỉ thực hiện DAS (tải xuống các hàng và cột được phân bổ). 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 ta cần giả định về tính đồng bộ để tái thiết. Nếu 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 nó trở lại với nhau.

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

• Tôi đề xuất những điều sau đây để khám phá sâu hơn về cách thức hoạt động của những lời hứa KZG:–Dankrad

• Một mồi (tương đối dễ hiểu) về mật mã đường cong elliptic–Vitalik

Khám phá các cặp đường cong Elliptic

Cam kết đa thức KZG

Cài đặt đáng tin cậy hoạt động như thế nào?

Tách người đề xuất-người xây dựng nội giao thức

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

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

1. Nhớ lại bài báo "Endgame" 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 thực phi tập trung và không tin cậy. PBS biên soạn này. Chúng tôi cần một nhà xây dựng trung thực để phục vụ mạng sống động và chống kiểm duyệt (hai là cần thiết cho một thị trường hiệu quả), nhưng đa số trung thực là cần thiết cho bộ trình xác thực. PBS làm cho vai trò người đề xuất trở nên đơn giản nhất có thể để hỗ trợ phân cấp trình xác thực.

2. Các nhà 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ọ như phần cứng mạnh mẽ, v.v.). Tất cả giá trị thấm vào bộ xác thực phi tập trung - chính xác là những gì chúng tôi muốn.

3. 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:

4. Nhà xây dựng cam kết tiêu đề khối với giá thầu của họ

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

Ủy ban chứng minh xác nhận tiêu đề chiến thắng

Thợ xây công bố thi thể trúng giải

Ủy ban nhân chứng độc lập bầu ra cơ quan chiến thắng (nếu người xây dựng chiến thắng không đồng ý, nó sẽ bị bỏ phiếu vắng mặt)

Những người đề xuất được chọn từ tập hợp các trình xác nhận bằng cách sử dụng cơ chế RANDAO tiêu chuẩn. Sau đó, chúng tôi sử dụng sơ đồ cam kết tiết lộ trong đó toàn bộ khối không được tiết lộ cho đến khi ủy ban xác nhận tiêu đề khối.

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

Sau khi người đề xuất chọn tiêu đề khối chiến thắng, ủy ban sẽ xác nhận và sửa các quy tắc lựa chọn fork. 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 phát hành kịp thời, ủy ban tiếp theo sẽ làm chứng. Nếu họ không xuất bản kịp thời, họ vẫn trả toàn bộ giá thầu cho người đề xuất (và mất tất cả MEV và phí). Khoản thanh toán vô điều kiện này loại bỏ nhu cầu người đề xuất phải tin tưởng người xây dựng.

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

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

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

3. crLists kiểm tra khả năng này. Việc triển khai chính xác lại là một không gian thiết kế mở, nhưng "PBS lai" dường như được yêu thích hơn. Những người đề xuất 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à những người xây dựng sẽ buộc phải đưa chúng vào (trừ khi khối đầy):

4. Người đề xuất xuất bản danh sách crList và bản tóm tắt danh sách crList bao gồm tất cả các giao dịch đủ điều kiện

5. Người 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 chứng minh rằng họ đã nhìn thấy nó

Người đề xuất chấp nhận giá thầu và tiêu đề khối của người xây dựng chiến thắng (họ chưa nhìn thấy phần thân)

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

Prover kiểm tra tính hợp lệ của cơ quan công bố

Vẫn còn những vấn đề quan trọng cần được giải quyết ở đây. Ví dụ, chiến lược kinh tế chi phối ở đây là yêu cầu những người đề xuất nộp một danh sách trống. Ngay cả người xây dựng đánh giá cũng có thể giành chiến thắng trong phiên đấu giá miễn là trả giá cao nhất. Có một số ý tưởng để giải quyết vấn đề này và các vấn đề khác, nhưng chỉ cần nhấn mạnh rằng thiết kế ở đây không cố định.

Sơ đồ KZG hai chiều

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

Chúng tôi đã có một công cụ 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ẽ để xây dựng lại. Chúng ta có thể chấp nhận các yêu cầu siêu nút cho lần xây dựng ban đầu, nhưng chúng ta cần tránh xây dựng lại các giả định ở đây. Chúng tôi cần các thực thể ít tài nguyên hơn để xử lý việc xây dựng lại và việc chia nhỏ nó thành nhiều cam kết KZG giúp điều này trở nên khả thi. 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 giả định trường hợp cơ bản trong thiết kế này.

Để giúp quá trình tái tạo dễ dàng hơn, mỗi khối sẽ chứa m đốm màu phân mảnh được mã hóa trong m cam kết KZG. Làm điều này một cách ngây thơ sẽ dẫn đến rất nhiều mẫu - bạn sẽ thực hiện DAS trên từng đốm màu phân mảnh cho đến khi tất cả đều có sẵn (m*k mẫu, trong đó k là số lượng mẫu trên mỗi đốm màu).

Thay vào đó, Ethereum sẽ sử dụng sơ đồ 2D KZG. Một lần nữa, chúng tôi sử dụng mã Reed-Solomon để chia tỷ lệ m cam kết thành 2 m cam kết:

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

Yêu cầu lấy mẫu 2D ≥75% dữ liệu có sẵn (so với 50% trước đây) có nghĩa là chúng tôi thực hiện kích thước mẫu cố định hơn một chút. Trước đây tôi đã đề cập đến 30 mẫu cho DAS trong lược đồ 1D đơn giản, nhưng điều này sẽ yêu cầu 75 mẫu để đảm bảo cùng một tỷ lệ xác suất tái tạo các khối có thể sử dụng được.

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

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

Danksharding

Thực tế, trình xác thực chỉ đơn giản là xáo trộn mà không cần kiểm tra tất cả các phân đoạn riêng lẻ.

Các khối tổng hợp sử dụng sơ đồ cam kết 2D KZG giờ đây khiến việc kiểm tra toàn bộ DA trở nên đơn giản. Nó chỉ yêu cầu 75 mẫu của một khối thống 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

PBS ban đầu được thiết kế để giảm nồng độ của MEV trên bộ xác thực. Tuy nhiên, Dankrad gần đây đã tận dụng lợi thế của thiết kế này, nhận ra rằng nó đã mở ra một cấu trúc phân mảnh tốt hơn nhiều - DS.

DS tận dụng các nhà xây dựng chuyên dụng để tạo ra một chuỗi đèn hiệu thực thi sự tích hợp chặt chẽ hơn giữa các khối và phân đoạn. Bây giờ chúng tôi có một người xây dựng cùng nhau tạo ra toàn bộ khối, một người đề xuất và một ủy ban. DS sẽ không khả thi nếu không có PBS - trình xác thực thông thường không thể xử lý băng thông khổng lồ của các khối chứa đầy các đốm màu dữ liệu Rollup:

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

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

Dữ liệu bằng chứng xác minh có sẵn như sau:

Điều này phụ thuộc 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, tính khả dụng của cột và hàng của tôi không đủ để tôi tin tưởng về mặt thống kê rằng toàn bộ khối khả dụng. Nó phụ thuộc vào điều mà hầu hết mọi người nói một cách trung thực. Xác nhận phi tập trung là 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ư là cách các cá nhân nghèo tài nguyên có thể dễ dàng kiểm tra tính khả dụng (ví dụ: tôi có thể chạy nút ánh sáng DAS và biết 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 tạo khối.

• Danksharding - tái cấu trúc

• Miễn là 50% của một hàng hoặc cột có sẵn, trình xác thực lấy mẫu có thể dễ dàng tái tạo lại hoàn toàn. Khi họ xây dựng lại bất kỳ khối nào bị mất trong một hàng/cột, họ sẽ gán 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 giao nhau khi cần.

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

Đủ các nút để thực hiện các 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 phát các khối tương ứng của chúng

Vì vậy, bao nhiêu nút là đủ? Ước tính sơ bộ là khoảng 64.000 trường hợp riêng lẻ (hơn 380.000 cho đến nay). Đây cũng là một phép tính rất bi quan, 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 so với 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à cột, thì khả năng bạn có thể truy xuất chúng cùng nhau sẽ tăng lên do tính chéo. Điều này bắt đầu mở rộng quy mô bậc hai - 64.000 có thể là đơn đặt hàng có cường độ nhỏ hơn nếu trình xác thực đang chạy 10 hoặc 100 trình xác thực.

Nếu số lượng trình xác thực trực tuyến bắt đầu trở nên thấp bất thường, DS có thể được thiết lập để tự động giảm số lượng đốm dữ liệu phân đoạn. Do đó, giả định an toàn 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 thực DS dựa vào đa số trung thực để chứng thực các khối. Với tư cách cá nhân, tôi không thể chứng minh với bản thân rằng một khối có sẵn bằng cách chỉ tải xuống một vài hàng và cột. Tuy nhiên, lấy mẫu ngẫu nhiên riêng tư có thể mang lại cho tôi sự đảm bảo đó mà không cần tin tưởng bất kỳ ai. Như đã đề cập trước đó, đây là nơi nút 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ể họ thực sự cần sự trợ giúp của bạn ở đây!).

Lưu ý rằng "riêng tư" rất quan trọng vì nếu kẻ tấn công hủy đặt tên cho 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 khối chính xác mà bạn yêu cầu và giữ phần còn lại. Do đó, bạn không biết rằng tất cả dữ liệu có sẵn chỉ từ việc lấy mẫu của riêng bạn.

Danksharding – điểm mấu chốt

Bên cạnh cái tên ngọt ngào, DS cũng rất thú vị. Cuối cùng nó cũng nhận ra tầm nhìn về lớp DA và dàn xếp hợp nhất của Ethereum. Sự kết hợp chặt chẽ giữa các khối đèn hiệu và phân mảnh về cơ bản giả vờ như không bị phân mảnh.

• Trên thực tế, hãy xác định lý do tại sao nó thậm chí còn được coi là "sharding". Phần còn lại duy nhất của "sharding" 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. Đó là tất cả.

• Vì vậy, nếu bây giờ bạn đang đặt câu hỏi liệu điều này có thực sự vẫn còn sharding hay không, thì bạn không điên đâu. Sự khác biệt này là lý do tại sao một PDS (mà chúng ta sẽ sớm đề cập) 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 đó gây nhầm lẫn). PDS yêu cầu mỗi trình xác thực tải xuống đầy đủ tất cả các đốm màu phân đoạn để chứng minh tính khả dụng của chúng. DS sau đó giới thiệu việc lấy mẫu, vì vậy mỗi trình xác thực chỉ tải xuống một phần của nó.

• May mắn thay, sharding tối thiểu có nghĩa là một thiết kế đơn giản hơn sharding 1.0 (phân phối quá nhanh, phải không?). Tóm lại, nó bao gồm:

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

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

Các xác nhận shard blob riêng lẻ không được theo dõi, tất cả chúng hiện được xác nhận trong chuỗi chính hoặc chúng 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 với các khối khác nhau được tạo bởi những người đề xuất khác nhau sẽ lan rộng điều này.dAMMViệc loại bỏ các ủy ban phân đoạn cũng tăng cường chống hối lộ. Trình xác thực DS bỏ phiếu trên toàn bộ khối một lần trong mỗi kỷ nguyên, vì vậy dữ liệu được xác nhận ngay lập tức bởi 1/32 của toàn bộ bộ trình xác thực (32 vị trí trên 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 cải tổ lại. Do đó, mỗi phân đoạn chỉ được xác nhận bởi 1/2048 của bộ xác thực (1/32 được chia thành 64 phân đoạn).

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

Một khả năng thú vị khác tồn tại trong DS - các cuộc gọi đồng bộ giữa ZK-rollup và thực thi L1 Ethereum. Các giao dịch từ shard blobs có thể được xác nhận và ghi vào L1 ngay lập tức, vì mọi thứ được tạo trong cùng một khối chuỗi beacon. Sharding 1.0 sẽ loại bỏ khả năng này do các xác nhận phân đoạn riêng biệt. Điều này cho phép tạo ra một không gian thiết kế thú vị, hữu ích cho việc di chuyển chung (ví dụ:

) và những thứ tương tự có thể rất có giá trị.

• Lớp cơ sở mô-đun chia tỷ lệ 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. Việc thêm nhiều nút hơn vào lớp DA cho phép bạn 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 các bản tổng số tồn tại ở trên cùng).

• Vẫn còn những giới hạn đối với khả năng mở rộng chuỗi khối, nhưng chúng tôi có thể cải thiện các đơn đặt hàng có cường độ cao hơn bất kỳ thứ gì chúng tôi đã thấy ngày nay. Các lớp cơ sở an toàn và có thể mở rộng cho phép thực thi sinh sôi nảy nở trên chúng. Những cải tiến về lưu trữ dữ liệu và băng thông cũng sẽ cho phép thông lượng dữ liệu cao hơn theo thời gian.

Chắc chắn có thể vượt quá thông lượng DA dự kiến ​​ở đây, nhưng rất khó để nói mức tối đa này sẽ kết thúc ở đâu. Không có đường màu đỏ rõ ràng, nhưng các khu vực mà một số giả định bắt đầu cảm thấy không thoải mái:

Proto-danksharding (EIP-4844)

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 khả năng truy xuất dữ liệu vô thời hạn. Những gì nó làm là làm cho nó có sẵn đủ lâu cho bất kỳ ai muốn tải xuống, đáp ứng các giả định về bảo mật của chúng tôi. Sau đó, nó bị đổ ở khắp mọi nơi - điều này thật thoải mái vì lịch sử là 1 trong giả định về độ tin cậy N và chúng tôi không thực sự nói nhiều dữ liệu như vậy trong sơ đồ tổng thể của mọi thứ. Điều này có thể đi vào lãnh thổ đáng lo ngại trong một vài năm khi thông lượng tăng theo một số bậc độ lớn.

Trình xác minh - DAS cần có đủ 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ể đợ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 đủ để tái tạo lại khối, thì kẻ tấn công có thể giữ phần còn lại và chúng tôi không gặp may. Để 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. Đây không phải là vấn đề thông lượng như đã thảo luận ở đây. Tuy nhiên, điều này có thể không thoải mái nếu thông lượng tăng thêm vài bậc 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, do đó, 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. Bất kể, đó là một vai trò chuyên biệt và đó là chi phí kinh doanh không đáng kể đối với họ.

DS rất tuyệt, nhưng chúng ta phải kiên nhẫn. PDS được thiết kế để 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 cho DS theo dòng thời gian được tăng tốc (đối với hard fork Thượng Hải) để cung cấp các đơn đặt hàng có quy mô lớn trong thời gian chờ đợ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ẻ).

Các bản tổng hợp ngày nay sử dụng "calldata" L1 để lưu trữ, tồn tại vĩnh viễn trên chuỗi. Tuy nhiên, Rollup chỉ yêu cầu DA trong một khoảng thời gian hợp lý để bất kỳ ai quan tâm đều có đủ thời gian để tải xuống.

EIP-4844 giới thiệu một định dạng giao dịch mới hỗ trợ blobs và Rollup 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 (~125 KB) 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ự. Sau đó, các đốm màu dữ liệu sẽ bị xóa khỏi các nút sau một tháng, giúp giảm yêu cầu lưu trữ. Đây là thời gian đủ để đáp ứng giả định bảo mật DA của chúng tôi.

Các khối Ethereum hiện tại thường có kích thước trung bình khoảng 90 KB (trong đó dữ liệu cuộc gọi là khoảng 10 KB). PDS mở rộng thêm băng thông DA cho các đốm màu (mục tiêu ~1 MB và tối đa ~2 MB) khi chúng bị cắt bớt sau một tháng. Chúng không trở thành lực cản vĩnh viễn trên nút.

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

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

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

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

• 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

• KZG cam kết với các đốm màu

• 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 BeaconBlock và các đốm màu DAS

• PBS

• Hầu hết logic BeaconBlock 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 cấp số nhân)

• DS sau đó nói thêm:

hệ thống thu thập dữ liệu

sơ đồ 2D KZG

Bằng chứng ký quỹ hoặc yêu cầu trong giao thức tương tự đối với 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 cụ thể của phân đoạn trong mỗi khối (có thể theo thứ tự 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 thực thi, nhưng chúng không áp đặt các yêu cầu bổ sung nào đối với phía thực thi. EVM chỉ xem xét các cam kết gắn liền với các đốm màu. Các thay đổi lớp triển khai được thực hiện bằng EIP-4844 cũng tương thích chuyển tiếp với DS và không cần thay đổi thêm về vấn đề này. Sau đó, việc nâng cấp từ PDS lên DS chỉ yêu cầu thay đổi lớp đồng thuận.

• Các đốm màu dữ liệu được tải xuống đầy đủ bởi các máy khách đồng thuận trong PDS. Bây giờ, blob được tham chiếu trong phần thân khối Beacon, nhưng không được mã hóa đầy đủ. Thay vì nhúng toàn bộ nội dung vào phần thân, nội dung của đốm màu được lan truyền một cách riêng biệt, dưới dạng "xe phụ". Mỗi khối có một sidecar blob được tải xuống đầy đủ trong PDS và sau đó sử dụng trình xác thực DS sẽ thực thi DAS trên khối đó.

• Trước đây chúng ta đã thảo luận về cách cam kết 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à byte 0x01 (đại diện cho phiên bản này) 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 dễ dàng hơn:

Khả năng tương thích EVM – Các cam kết củ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 (STARK có thể được sử dụng để kháng lượng tử), những lời hứa này có thể tiếp tục là 32 byte

PDS cuối cùng tạo ra một lớp dữ liệu tùy chỉnh - các đốm màu 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 riêng. 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 thừa nhận rằng chi phí chính của bất kỳ Rollup nào hiện nay là xuất bản dữ liệu của họ lên L1 (không phải bằng chứng).Thị trường phí gas vẫn giữ nguyên, các đốm màu 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 đây là khoản điều chỉnh có thể thay đổi dựa trên 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.

Bạn thực sự có hai phiên đấu giá chạy song song - một cho tính toán và một cho DA. cái này hợp lệ

định giá tài nguyên

bước nhảy vọt khổng lồ.

• Dưới đây là một số thiết kế thú vị. 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 trong thực tế. Ngày nay, phí cơ bản vẫn chưa hoàn toàn ổn định, khiến lượng gas trung bình được quan sát được sử dụng trên mỗi khối vượt quá mục tiêu trung bình ~3%.

• Phần II: Lịch sử & Quản lý Nhà nước

Một bản tóm tắt nhanh về một số điều cơ bản ở đây:

Lịch sử — mọi thứ xảy ra trên chuỗi. Bạn có thể dán nó vào ổ cứng của mình vì nó không cần truy cập nhanh. Về lâu dài, 1 trong số N sự trung thực giả định.

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) đều cần điều này để xác thực giao dịch. Nó quá lớn so với RAM và ổ cứng quá chậm - đó là ở ổ SSD của bạn. Các chuỗi khối thông lượng cao thổi phồng trạng thái của chúng vượt xa những gì một người bình thường của chúng ta có thể giữ trên máy tính xách tay của mình. Nếu người dùng hàng ngày không thể giữ trạng thái, họ không thể xác minh đầy đủ, vì vậy hãy tạm biệt phân quyền.

Giảm chi phí Calldata Gas và tổng giới hạn Calldata (EIP-4488)

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

• PDS là một bước đệm quan trọng đối với DS và nó kiểm tra nhiều yêu cầu cuối cùng. Việc triển khai PDS trong một khoảng thời gian hợp lý có thể thúc đẩy dòng thời gian trên DS.

• Một cách triển khai băng cá nhân dễ dàng hơn là EIP-4488. Nó không thanh lịch bằng, nhưng nó vẫn giải quyết được trường hợp khẩn cấp về phí. Thật không may, nó không thực hiện các bước trong quá trình thực hiện DS, vì vậy tất cả những thay đổi không thể tránh khỏi sẽ vẫn được yêu cầu sau này. Nếu bắt đầu có cảm giác PDS sẽ chậm hơn một chút so với mong muốn của chúng tôi, thì có thể nhanh chóng vượt qua EIP-4488 (chỉ là một vài dòng thay đổi mã) rồi triển khai PDS khoảng 6 tháng sau. Một thời gian biểu cụ thể vẫn chưa được xác định.

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

Thêm giới hạn 1 MB dữ liệu cuộc gọi cho mỗi khối và thêm 300 byte cho mỗi giao dịch (tối đa theo lý thuyết là khoảng 1,4 MB)

Các giới hạn cần được thêm vào để đề phòng trường hợp xấu nhất - một khối chứa đầy calldata sẽ đạt tới 18 MB, vượt xa những gì Ethereum có thể xử lý. 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 trọng duy trì của EIP-4488 cao hơn nhiều so với PDS, bởi vì đây vẫn là calldata và blob, dữ liệu có thể được cắt bớt sau một tháng. EIP-4488 sẽ tăng tốc đáng kể tốc độ tăng trưởng lịch sử, khiến nó trở thành nút cổ chai cho các nút đang chạy. Ngay cả khi EIP-4444 được triển khai cùng với EIP-4488, điều này sẽ chỉ xóa lịch sử tải thực thi sau một năm. Tải trọng duy trì thấp hơn trên PDS rõ ràng là mong muốn.

Liên kết 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 bớt cục bộ dữ liệu lịch sử (tiêu đề, nội dung và biên lai) cũ hơn một năm. Nó yêu cầu khách hàng ngừng cung cấp dữ liệu lịch sử đã được cắt bớt này trên lớp p2p. Cắt bớt 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 tăng lên).devp2pĐiều này vốn đã quan trọng, nhưng nếu EIP-4488 được triển khai (vì nó đã phát triển đáng kể trong lịch sử), thì phần lớn nó sẽ là bắt buộc. Bất kể, hy vọng điều này sẽ được thực hiện tương đối sớm. Cuối cùng, một số hình thức hết hạn lịch sử sẽ được yêu cầu, vì vậy đây là thời điểm tốt để giải quyết nó.

Đồng bộ hóa hoàn toàn chuỗi yêu cầu lịch sử, nhưng việc xác thực các khối mới thì không yêu cầu (điều này chỉ yêu cầu trạng thái). Do đó, sau khi khách hàng đã đồ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ể sử dụng hiện tại

Thực hiện "đồng bộ hóa hoàn toàn" - thay vào đó, họ sẽ "đồng bộ hóa điểm kiểm tra" từ điểm kiểm tra chủ quan yếu mà họ 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 - dù sao thì đó cũng là điều cố hữu khi chuyển sang PoS. Do khả năng bị tấn công từ xa, điều này cần được đồng bộ hóa bằng cách sử dụng các điểm kiểm tra chủ quan yếu một cách hiệu quả. Giả định ở đây là các máy khách sẽ không đồng bộ hóa từ các điểm kiểm tra chủ quan yếu cũ 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 bớt dữ liệu lịch sử (tức là trong vòng một năm ở đây), 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ẹ.

• Truy xuất dữ liệu lịch sử

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

EIP-4488 – dài hạn có khả năng bao gồm khoảng 1 MB mỗi khe thêm khoảng 2,5 TB dung lượng lưu trữ mỗi năm

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

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

• Nhưng dữ liệu đã đi đâu? Chúng ta không cần nó nữa sao? 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 một ứng dụng duy nhất. Do đó, công việc của giao thức lõi Ethereum không phải là duy trì tất cả dữ liệu đồng thuận mãi mãi.

• Vì vậy, ai sẽ lưu trữ nó? 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 (ví dụ: 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 có thể trả tiền cho máy chủ để có dữ liệu lịch sử cũng như 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 nút sở hữu nó

BitTorrent chẳng hạn. Tệp 7 GB được tự động tạo và phân phối hàng ngày có chứa dữ liệu blob từ khối

Các giao thức dành riêng cho ứng dụng như Rollup 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

Vấn đề lưu trữ dữ liệu dài hạn là một vấn đề tương đối đơn giản vì giả định độ tin cậy 1 trên N mà chúng ta đã thảo luận trước đó. Chúng ta vẫn còn nhiều năm nữa mới đạt được 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 không quốc tịch

Ok, vậy là chúng ta đã xử lý việc quản lý lịch sử khá tốt, nhưng còn trạng thái thì sao? Vấn đề trạng thái 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 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 chúng cần có trạng thái - xác minh có trạng thái.

Bước vào kỷ nguyên phi trạng thái - chúng ta sẽ không cần trạng thái để hoạt động. Ethereum đang phấn đấu để "không trạng thái yếu", nghĩa là không cần trạng thái để xác thực các khối, nhưng cần có trạng thái để 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 một cái gì đó như thế này:

• Vì PBS, các nhà xây dựng vẫn cần trạng thái có thể chấp nhận được - dù sao thì họ cũng sẽ là các thực thể có tài nguyên cao tập trung hơn. Tập trung vào các trình xác nhận phi tập trung. Tình trạng không trạng thái 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 thực. Đây là một sự đánh đổi lớn.

• Bạn đạt được cuộc hành quyết không quốc tịch kỳ diệu này với các nhân chứng. Đây là những bằng chứng về quyền truy cập trạng thái chính xác mà các nhà xây dựng sẽ bắt đầu đưa 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 phần trạng thái bị ảnh hưởng bởi giao dịch trong một khối nhất định và họ sẽ chứng minh rằng họ đã truy cập chính xác trạng thái đó thông qua một nhân chứng.

• Hãy lấy một ví dụ. Alice muốn gửi 1 ETH cho Bob. Để xác thực một khối với 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, 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. Đó là tất cả!

• Đây là ý nghĩa của nó từ quan điểm của người xác thực:

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

Vì bạn hiện cũng đang tải xuống dữ liệu nhân chứng và chứng thực, nên yêu cầu về băng thông sẽ tăng lên. Đây là nút cổ chai của cây Merkle-Patricia, nhưng nó ở mức độ vừa phải, không phải là nút cổ chai trong nỗ lực của Verkle.

Verkle Tries

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 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 khoảng 3 lần.

Dù sao thì 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 vẫn có lợi ngay cả đối với họ. Các bản tổng hợp 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ể sẽ trở thành một phần lớn hơn trong chi phí Rollup (đặc biệt là đối với ZK-rollup).

Chúng tôi đề cập đến cách những lời khai này thực sự hoạt động. Ethereum hiện đang sử dụng cây Merkle-Patricia để biểu diễn trạng thái, nhưng các bằng chứng Merkle cần thiết quá lớn để có thể thực tế đối với những nhân chứng này.

Ethereum sẽ chuyển sang Verkle để thử lưu trữ trạng thái. Bằng chứng Verkle hiệu quả hơn nhiều, vì vậy chúng có thể không có trạng thái yếu như những nhân chứng khả thi.

Trước tiên, hãy xem lại cây Merkle trông như thế nào. Mọi giao dịch đều được băm - những giá trị 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 chúng. Kết quả băm cuối cùng là "Merkle root".

Đây là một cấu trúc dữ liệu hữu ích để chứng minh các giao dịch được chứa 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 bao gồm, bạn chỉ cần H12, H3 và H5678 từ bằng chứng Merkle. Chúng tôi có H12345678 từ tiêu đề khối. Do đó, một ứng dụng khách nhẹ có thể yêu cầu một nút đầy đủ cho các giá trị băm này, sau đó chúng được băm cùng nhau dựa trên 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ó trong cây.

Tuy nhiên, cây càng sâu thì đường xuống phía dưới càng dài, vì vậy bạn sẽ cần nhiều vật phẩm hơn để chứng minh điều đó. Vì vậy, cây nông và cây rộng dường như thuận lợi cho việc 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 phải băm tất cả anh chị em cùng nhau để leo lên cây, vì vậy bạn cần nhận được nhiều băm anh chị em hơn cho bằng chứng Merkle. Điều này sẽ làm cho kích thước bằng chứng rất lớn.

Đây là nơi mà các lời hứa vector hiệu quả xuất hiện. 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 thực sự chỉ cam kết với hai phần tử. Vì vậy, chúng tôi muốn các cam kết vectơ, chúng tôi không cần phải nhận tất cả các anh chị em để xác minh nó. Khi chúng ta có điều đó, chúng ta có thể làm cho cây rộng hơn và giảm độ sâu của chúng. Đây là cách chúng tôi có được kích thước bằng chứng hiệu quả - giảm lượng thông tin cần cung cấp.

Verkle trie tương tự như cây Merkle, nhưng nó sử dụng các cam kết vectơ hiệu quả (do đó có tên là "Verkle") thay vì các hàm băm đơn giản để cam kết với các phần tử con của 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. Đó 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ề một trong những 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. Kể từ đó, họ đã chuyển sang Pedersen để thực hiện các nhiệm vụ tương tự. Chúng sẽ dựa trên các đường cong elip (trong trường hợp này là Bandersnatch) và mỗi giá trị sẽ gửi 256 giá trị (tốt hơn nhiều so với hai giá trị!).

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

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

Tình trạng không trạng thái yếu loại bỏ giới hạn lạm phát trạng thái đối vớ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 bị hạn chế, nhưng chúng áp thuế vĩnh viễn lên 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. Một cái gì đó cần phải được thực hiện để khắc phục vấn đề cơ bản.

Đây là nơi nhà nước hết hạn. Thời gian dài không hoạt động (chẳng hạn như một hoặc hai năm) thậm chí còn bị cắt khỏi những gì người xây dựng khối cần mang theo. Người dùng đang hoạt động sẽ không nhận thấy bất cứ điều gì và trạng thái vô dụng không còn cần thiết có thể bị loại bỏ.

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 quay trở lại giả định lưu trữ 1 trên N ở đây. 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 làm suy yếu nhu cầu hết hạn trạng thái ngay lập tức ở lớp cơ sở, nhưng lại là một điều tốt về lâu dài, đặc biệt là khi thông lượng L1 tăng lên. Đây sẽ là một công cụ hữu ích hơn cho các bản tổng hợp thông lượng cao. Trạng thái L2 sẽ phát triển với tốc độ cao hơn, kéo theo cả những trình tạo hiệu suất cao đi xuống.

• Phần III - MEV

• PBS là cần thiết để triển khai DS một cách an toàn, nhưng hãy nhớ lại rằng ban đầu nó thực sự được thiết kế để 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ử.

Thiết kế một chuỗi khối với MEV là rất quan trọng để 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 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í, bầu 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. Mặt khác, nó tập trung vào bộ trình xác thực vì nó không thể cạnh tranh với những người tìm kiếm phức tạp. Điều này trở nên trầm trọng hơn bởi thực tế là MEV kết hợp sẽ có tỷ lệ phần thưởng cho người xác thực cao hơn (việc phát hành cổ phần thấp hơn nhiều so với tỷ lệ lạm phát dành cho người khai thác). Không thể bỏ qua.

Chuỗi cung ứng MEV ngày nay

Chuỗi sự kiện hôm nay như sau:

MEV-Boost

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 (và giá thầu tương ứng của chúng) tới các nhóm 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 chứng minh điều này bằng cách cho họ trọng số trong các quy tắc lựa chọn fork thông qua PoW.

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à các yếu tố bên ngoài khó chịu khác. Khi Flashbots ra mắt, các nhóm khai thác đã bắt đầu thực hiện các thỏa thuận độc quyền với các công ty thương mại để trích xuất MEV. Thay vào đó, Flashbots cung cấp cho họ một cách dễ dàng để tổng hợp các giá thầu MEV và tránh tích hợp theo chiều dọc (bằng cách triển khai MEV-geth).

Sau khi hợp nhất Ethereum, nhóm khai thác sẽ biến mất. Chúng tôi muốn mở ra cánh cửa cho các nút trình xác thực có thể hoạt động hợp lý tại nhà. Điều này đòi hỏi phải tìm một người nào đó đảm nhận vai trò xây dựng chuyên dụng. Nút trình xác thực tại nhà của bạn có thể không thu được MEV tốt như một quỹ phòng hộ với mức lương được lượng tử hóa. Không được chọn, điều này sẽ tập trung hóa bộ trình xác nhận nếu những người bình thường không thể cạnh tranh. Nếu được cấu trúc đúng cách, giao thức có thể chuyển doanh thu MEV sang phần thưởng đặt cược hàng ngày của người xác thực.

Thật không may, PBS trong thỏa thuận đơn giản là chưa sẵn sàng cho việc sáp nhập. Flashbots một lần nữa đưa ra giải pháp bước đệm - MEV-Boost.

Theo mặc định, trình xác nhận hợp nhất sẽ nhận các giao dịch mempool công khai trực tiếp vào ứng dụng khách thực thi của chúng. Họ có thể đóng gói những thứ này, đưa chúng cho các khách hàng đồng thuận và phát chúng lên mạng. (Nếu bạn cần hiểu cách các ứng dụng khách đồng thuận và thực thi của Ethereum phối hợp với nhau như thế nào, tôi sẽ đề cập đến điều đó trong Phần IV).

Nhưng như chúng ta đã thảo luận, trình xác thực của bạn không biết cách trích xuất MEV, vì vậy Flashbot đưa ra một tùy chọn khác. MEV-boost sẽ tích hợp vào ứng dụng khách đồng thuận của bạn, cho phép bạn thuê ngoài việc xây dựng khối chuyên dụng. Điều quan trọng là bạn vẫn có tùy chọn sử dụng ứng dụng khách thực thi của riêng mình làm phương án dự phòng.

MEV Seekers sẽ tiếp tục hoạt động theo cách họ làm hiện nay. Họ sẽ chạy các chiến lược cụ thể (chênh lệch thống kê, chênh lệch giá nguyên tử, bánh sandwich, v.v.) và đặt giá thầu cho các gói của họ. Sau đó, các nhà xây dựng sẽ tổng hợp tất cả các gói mà họ thấy, cũng như mọi luồng đơn đặt hàng riêng tư (ví dụ: từ Flashbots Protect) thành một khối đầy đủ tốt nhất. Người xây dựng chỉ chuyển tiêu đề khối cho trình xác nhận thông qua chuyển tiếp chạy tới MEV-Boost. Flashbots dự định chạy các trình chuyển tiếp và trình tạo, đồng thời có kế hoạch phân cấp theo thời gian, nhưng việc đưa các trình tạo khác vào danh sách trắng có thể chậm.

MEV-Boost yêu cầu các trình xác thực phải tin tưởng các trình chuyển tiếp - ứng dụng khách đồng thuận nhận tiêu đề khối, ký vào đó và chỉ sau đó mới hiển thị phần thân khối. Mục đích của người chuyển tiếp là để chứng minh cho người đề xuất rằng cơ thể hợp lệ và tồn tại, để người xác minh không phải tin tưởng trực tiếp vào người xây dựng.Khi PBS trong giao thức đã sẵn sàng, nó sẽ kết hợp nội dung do MEV-Boost cung cấp trong thời gian đó. PBS cung cấp sự phân chia quyền lực giống nhau, cho phép phân cấp người xây dựng dễ dàng hơn và loại bỏ nhu cầu người đề xuất phải tin tưởng bất kỳ ai.。

Làm mịn MEV do ủy ban điều hành

PBS cũng mở ra cánh cửa cho một ý tưởng hay ho khác --

Làm mịn MEV do ủy ban điều hành

Chúng tôi thấy rằng khả năng trích xuất MEV là lực lượng tập trung cho bộ trình xác thực, nhưng việc phân phối cũng vậy. Sự thay đổi cao về phần thưởng MEV từ khối này sang khối khác thúc đẩy việc tổng hợp nhiều trình xác nhận để làm mịn phần thưởng của bạn (như chúng ta thấy với các nhóm khai thác ngày nay, mặc dù ở mức độ thấp hơn ở đây).

Mặc định là cung cấp cho người đề xuất khối thực tế khoản thanh toán đầy đủ của người xây dựng. Thay vào đó, MEV smoothing sẽ phân phối khoản thanh toán giữa nhiều trình xác thực. Một ủy ban gồm những người xác thực sẽ kiểm tra khối được đề xuất và xác nhận xem đây có thực sự là khối có giá thầu cao nhất hay không. Nếu mọi việc suôn sẻ, khối sẽ được tiến hành và phần thưởng được phân chia giữa ủy ban và người đề xuất.

Điều này cũng giải quyết một vấn đề khác - hối lộ bên ngoài. Ví dụ: những người đề xuất có thể được khuyến khích gửi các khối dưới mức tối ưu và trực tiếp nhận hối lộ bên ngoài để che giấu các khoản thanh toán của họ với những người được ủy quyền. Bằng chứng này có thể kiểm tra người đề xuất.

PBS trong giao thức là điều kiện tiên quyết để làm mịn MEV. Bạn cần hiểu thị trường nhà xây dựng và các hồ sơ dự thầu rõ ràng đã gửi. Có một số câu hỏi nghiên cứu mở ở đây, nhưng đây là một đề xuất thú vị một lần nữa rất quan trọng để đảm bảo các trình xác thực phi tập trung.

Kết thúc giao dịch một khe

Kết thúc nhanh là tuyệt vời. Chờ ~15 phút không phải là tối ưu cho trải nghiệm người dùng hoặc giao tiếp xuyên chuỗi. Quan trọng hơn, điều này tạo ra vấn đề lắp ráp lại MEV.

Ethereum được hợp nhất đã cung cấp xác nhận mạnh mẽ hơn hiện nay - hàng nghìn trình xác thực chứng thực cho từng khối cạnh tranh với các công cụ khai thác và có thể khai thác ở cùng độ cao khối mà không cần bỏ phiếu. Điều này sẽ làm cho việc tổ chức lại rất khó xảy ra. Tuy nhiên, đây vẫn chưa phải là giao dịch cuối cùng thực sự. Nếu khối cuối cùng có một số MEV béo, bạn có thể lừa những người xác thực cố gắng tổ chức lại chuỗi và đánh cắp nó cho chính họ.

Tôi sẽ không tập trung quá nhiều vào các cơ chế cơ bản ở đây. Tính hữu hạn của một vị trí duy nhất đã được phát triển rất xa trong lộ trình của Ethereum và đó là một không gian thiết kế rất mở.đâyTrong giao thức đồng thuận ngày nay (không có thời hạn cuối cùng của vị trí), Ethereum chỉ cần 1/32 trình xác thực để chứng thực cho mỗi vị trí (khoảng 12.000 trong số khoảng 380.000 hiện tại). Việc mở rộng loại biểu quyết này thành bộ trình xác thực đầy đủ được tổng hợp với chữ ký BLS trong một vị trí sẽ cần nhiều công việc hơn. Điều này cô đọng hàng trăm nghìn phiếu bầu thành một lần xác thực:

Vitalik đang ở

đây

Phá vỡ một số giải pháp thú vị.

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

SSLE cố gắng vá một vectơ tấn công MEV khác mà chúng ta sẽ phải đối mặt sau khi sáp nhập.

Danh sách các trình xác thực chuỗi đèn hiệu và danh sách các cuộc bầu cử lãnh đạo sắp tới được công khai, đồng thời có thể dễ dàng hủy bỏ ẩn danh cho chúng và lập bản đồ địa chỉ IP của chúng. Bạn có thể thấy vấn đề ở đây.

Trình xác nhận tinh vi hơn có thể sử dụng các thủ thuật để ẩn mình tốt hơn, nhưng trình xác thực nhỏ đặc biệt dễ bị tấn công doxxed và DDOSd sau đó. Điều này có thể dễ dàng sử dụng cho MEV.

Giả sử bạn là người đề xuất khối n và tôi là người đề xuất khối n+1. Nếu tôi biết địa chỉ IP của bạn, tôi có thể DDOS bạn với giá rẻ để bạn hết thời gian chờ và không thể tạo các khối của mình. Bây giờ tôi có thể nắm bắt MEV của vị trí của chúng tôi và nhân đôi phần thưởng của mình. Điều này càng trở nên trầm trọng hơn bởi kích thước khối đàn hồi của EIP-1559 (khí tối đa trên mỗi khối gấp đôi kích thước mục tiêu), vì vậy tôi có thể nhồi nhét các giao dịch lẽ ra phải dài hai khối vào một khối dài gấp đôi hiện tại của tôi.

Phần IV - Sáp nhập

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

Vâng, chỉ để rõ ràng tôi đã nói đùa. Tôi thực sự nghĩ (hy vọng) rằng việc sáp nhập Ethereum diễn ra tương đối nhanh chóng.

• Tất cả chúng ta đang nói về chủ đề này, vì vậy tôi cảm thấy bắt buộc ít nhất phải giới thiệu ngắn gọn về nó.

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

Ngày nay, bạn chạy một ứng dụng khách nguyên khối xử lý mọi thứ (ví dụ: Go Ethereum, Nethermind, v.v.). Cụ thể, các nút đầy đủ đồng thời thực hiện các hoạt động sau:

Thực thi - Mọi giao dịch trong khối được thực hiện để đảm bảo tính hợp lệ. Nhận gốc trạng thái trước, thực hiện tất cả các thao tác và kiểm tra xem gốc trạng thái sau kết quả có đúng không

Đồng thuận - Xác minh rằng bạn đang ở trong chuỗi nặng nhất (PoW cao nhất) để hoàn thành nhiều công việc nhất (tức là Đồng thuận Satoshi)

• Chúng không thể chia cắt được vì các nút đầy đủ không chỉ tuân theo chuỗi nặng nhất mà còn theo chuỗi hợp lệ nặng nhất. Đó là lý do tại sao chúng là nút đầy đủ chứ không phải nút nhẹ. Ngay cả khi một cuộc tấn công 51% xảy ra, nút đầy đủ sẽ không chấp nhận các giao dịch không hợp lệ.

• Beacon chain hiện chỉ chạy đồng thuận để chạy thử nghiệm PoS. Thực hiện không được bao gồm. Tổng độ khó cuối cùng cuối cùng sẽ được xác định, tại thời điểm đó, khối thực thi Ethereum hiện tại sẽ được hợp nhất vào khối chuỗi đèn hiệu để tạo thành một chuỗi:

Tuy nhiên, một nút đầy đủ sẽ chạy hai máy khách riêng biệt trong nền, có thể tương tác với nhau:

Máy khách thực thi (còn gọi là "Máy khách ETH1") - Máy khách Eth 1.0 hiện tại tiếp tục xử lý việc thực thi. Họ xử lý các khối, duy trì nhóm bộ nhớ, quản lý và đồng bộ hóa trạng thái. Phần PoW đã bị xé toạc.

Ứng dụng khách đồng thuận (còn gọi là "Ứng dụng ETH2") - Ứng dụng khách chuỗi đèn hiệu hiện tại tiếp tục xử lý sự đồng thuận PoS. Họ theo dõi người đứng đầu chuỗi, buôn chuyện và chứng thực các khối, đồng thời kiếm phần thưởng cho người xác thực.

Khách hàng nhận các khối chuỗi đèn hiệu, thực hiện các giao dịch do khách hàng điều hành và nếu mọi việc suôn sẻ, các khách hàng đồng thuận sẽ tuân theo chuỗi. Bạn sẽ có thể kết hợp và kết hợp các ứng dụng khách thực thi và đồng thuận mà bạn chọn, tất cả đều có thể tương tác với nhau. API công cụ mới sẽ được giới thiệu để khách hàng giao tiếp với nhau:

hoặc:

đồng thuận hậu sáp nhập

Ethereum được hợp nhất đã chuyển sang GASPER - sự kết hợp giữa Casper FFG (công cụ cuối cùng) và LMD GHOST (quy tắc lựa chọn ngã ba) để đạt được sự đồng thuận. TLDR ở đây - đó là sự sống động ủng hộ sự đồng thuận, không phải bảo mật.

Tóm lại là

Sự khác biệt là các thuật toán đồng thuận thân thiện với bảo mật (ví dụ: Tendermint) dừng khi chúng không đạt được số phiếu bầu cần thiết (ở đây được đặt thành 2/3 số người xác thực). Sự sống động của chuỗi thuận lợi (ví dụ: sự đồng thuận của PoW + Nakamoto) sẽ tiếp tục xây dựng một sổ cái lạc quan, nhưng chúng không thể đạt được mục đích cuối cùng nếu không có đủ phiếu bầu. Bitcoin và Ethereum ngày nay không bao giờ được hoàn thiện - bạn cứ cho rằng việc tổ chức lại sẽ không xảy ra sau khi có đủ số lượng khối.

Tuy nhiên, Ethereum cũng sẽ đạt được tính hữu hạn thông qua các điểm kiểm tra thông thường với đủ số phiếu bầu. Mỗi phiên bản 32 ETH là một trình xác thực duy nhất và đã có hơn 380.000 trình xác thực chuỗi đèn hiệu. Các kỷ nguyên bao gồm 32 vị trí trong đó tất cả các trình xác thực phân tách và chứng thực một vị trí trong một kỷ nguyên nhất định (có nghĩa là ~12.000 bằng chứng cho mỗi vị trí). Sau đó, quy tắc lựa chọn ngã ba LMD Ghost sẽ xác định người đứng đầu chuỗi hiện tại dựa trên những bằng chứng này. Một khối mới được thêm vào mỗi vị trí (12 giây), do đó, kỷ nguyên là 6,4 phút. Tính cuối cùng thường đạt được sau hai kỷ nguyên (nghĩa là 64 vị trí, mặc dù có thể cần tới 95 vị trí) với số phiếu bầu cần thiết.