Delphi Digital: Hướng dẫn nâng cao toàn diện nhất về Ethereum trong ngành

Tiêu đề gốc: "Hướng dẫn về Ethereum cho người đi nhờ xe"

Điểm cốt lõi:

Ethereum là giao thức chính duy nhất nhằm thiết lập một hệ thống giải quyết và dữ liệu thống nhất có thể mở rộng lớp khả dụng

Trong khi tận dụng tính bảo mật của Ethereum, các bản tổng hợp sẽ tăng quy mô tính toán

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

Những đổi mới như sự 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 lực (xây dựng và xác minh) để đạt được khả năng mở rộng mà không phải hy sinh các mục tiêu về an ninh hoặc phân cấp

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

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

Tôi đồng ý mong đợi Danksharding sẽ được triển khai trong đời chúng ta

Mục lục

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

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

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

Cam kết KZG (Cam kết KZG)

Cam kết của KZG so với bằng chứng gian lận

Sự tách biệt trong giao thức giữa người khởi xướng và người xây dựng

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

Chiến lược KZG 2D

Danksharding

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

Danksharding – Tái thiết

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

Danksharding – Tóm tắt chính

Danksharding – Về các ràng buộc mở rộng quy mô Blockchain

Danksharding gốc (EIP) -4844)

EIP-1559 đa chiều

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

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

Giới hạn dữ liệu lịch sử trong ứng dụng thực thi (EIP-4444)

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

Tình trạng không quốc tịch yếu

Verkle Tries (Verkle Try)

Trạng thái đã hết hạn

Phần 3 Mọi chuyện đều là lỗi của MEV

Chuỗi cung ứng MEV ngày nay

MEV -Boost

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

Bể đơn Một khe cuối cùng

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

Phần 4 Bí mật của sự sáp nhập

Khách hàng được sáp nhập

Tóm tắt khoảnh khắc

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 những người sinh ngày hôm nay có 50-75% cơ hội sống cho đến năm 3000 sau Công nguyên và hy vọng sẽ trở thành bất tử. Nhưng, cái quái gì thế, tại sao không tận hưởng niềm vui?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.

(1000 năm sau)

Điều này Bài viết này không thể được đọc một cách nhanh chóng. Nếu bạn muốn hiểu biết rộng rãi và chi tiết 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 điều cần theo dõi trong nghiên cứu Ethereum, nhưng mọi thứ cuối cùng đều đan xen vào nhau thành một tổng thể picture Mục tiêu – tăng quy mô tính toán mà không phải hy sinh quá trình xác minh phi tập trung.

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

Các chuyên gia sẽ đóng góp cho L1 và hơn thế nữa. Ethereum duy trì tính bảo mật đáng kinh ngạc thông qua xác minh phi tập trung đơn giản và quá trình tổng hợp 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à tính khả dụng của dữ liệu, cho phé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 toàn bộ chuỗi khối trở nên dễ dàng hơn bao giờ hết.

Các thuật ngữ sau sẽ xuất hiện khoảng bảy mươi tám năm mươi chín lần:

DA – Tính sẵn có của dữ liệu Tính sẵn có của dữ liệu

DAS – Lấy mẫu tính sẵn có của dữ liệu Lấy mẫu tính sẵn có của dữ liệu

PBS – Người khởi tạo sự phân tách giữa người đề xuất-người xây dựng và Sự tách biệt của người xây dựng

PDS – Danksharding nguyên bản

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

PoW – Bằng chứng công việc

PoS – Bằng chứng of Stake

Phần 1 của Đường đến Danksharding

Hy vọng bạn đã biết rằng Ethereum đã chuyển sang hình ảnh lộ trình tập trung vào tổng hợp. Không còn phân đoạn thực thi nữa – Thay vào đó, Ethereum sẽ tối ưu hóa cho các lần tổng hợp ngốn nhiều dữ liệu. Điều này đạt được thông qua việc phân chia dữ liệu (loại 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 chia. Nó chỉ có một công việc - đảm bảo dữ liệu có sẵn.

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

Thiết kế phân chia dữ liệu gốc - đề xuất phân chia độc lập

Thiết kế được mô tả ở đây không còn được dùng nữa nhưng vẫn đáng để biết về thông tin cơ bản. Để đơn giản, tôi sẽ gọi nó là “Sharding 1.0”.

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

Thiết kế này gây 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à tấn công Carrier. Việc tổ chức lại trình xác thực giữa các phân đoạn có thể mang lại rủi ro.

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

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

DS (Danksharding) hoàn toàn khác. Người xác thực thực hiện 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ào nữa). Một trình tạo chuyên dụng sử dụng khối Beacon và dữ liệu của tất cả các phân đoạn để tạo một khối lớn và xác nhận nó. Do đó, PBS (tách biệt đề xuất và nhà 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 sẽ tốn nhiều tài nguyên).

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

Rollups xuất bản lượng lớn dữ liệu, nhưng chúng tôi Bạn không muốn tạo gánh nặng cho các nút bằng việc 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, ảnh hưởng đến sự phân cấp.

Ngược lại, DAS cho phép các nút (ngay cả các máy khách hạng nhẹ) một cách dễ dàng và xác minh một cách 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 đơn giản - chỉ 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ý là xong. Nhưng điều gì sẽ xảy ra nếu bạn bỏ lỡ một giao dịch khiến toàn bộ ETH của bạn bị xóa sạch vào tay kẻ xấu? Điều này có an toàn không?

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 thành đ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 chia nhỏ nó ra.

Đừng lo lắng về môn toán của bạn, đây là khóa học cấp tốc. (Tôi hứa rằng phép toán ở đây không đáng sợ đến thế - 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ờ tôi cũng hiểu rồi).

Đa thức là một biểu thức là tổng của một số hữu hạn các biểu thức có dạng   ; Số lượng thuật ngữ đại diện cho chỉ số cao nhất. Ví dụ: +  +  - 4 là đ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ằm trên đa thức đó.

Bây giờ chúng ta 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 giá trị của đa thức tại một điểm nhất định. Ví dụ: =. Sau đó, bạn tìm thấy đa thức bậc tối thiểu thỏa mãn các giá trị này. Vì đây là bốn khối dữ liệu nên chúng ta có thể tìm được đa thức bậc ba. Sau đó chúng ta có thể mở rộng dữ liệu này bằng cách cộng bốn giá trị (to) nằm trên cùng một đa thức.

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

Quay lại DAS của chúng tôi. Bây giờ chúng ta 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 dữ liệu.

Do đó, kẻ tấn công phải ẩn hơn 50% khối dữ liệu để giả mạo thành công DAS node , làm cho nó nghĩ rằng dữ liệu có sẵn (không phải vậy).

Sau nhiều mẫu ngẫu nhiên thành công, <xác suất có được 50% dữ liệu 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ì có xác suất sử dụng được là <50%.

Cam kết của KZG

Được rồi, chúng tôi đã tạo ra một loạt mẫu ngẫu nhiên và tất cả đề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ể người tạo khối chỉ thêm 50% rác khi mở rộng khối và các mẫu của chúng tôi đều vô ích. Trong trường hợp này, chúng tôi thực sự không thể xây dựng lại dữ liệu.

Thông thường chúng ta chỉ sử dụng root Merkle) để commit lượng lớn dữ liệu. Điều này hợp lệ để chứng minh rằng một số dữ liệu được chứa trong một bộ sưu tập.

Tuy nhiên, chúng ta cũng cần biết rằng tất cả dữ liệu gốc và dữ liệu mở rộng đều được đặt trong cùng một mức độ đa thức thấp. Bà Merkel đơn giản là không thể chứng minh được điều này. Do đó, nếu bạn áp dụng tùy chọn này, bạn cũng sẽ cần bằng chứng gian lận để ngăn ngừa những sai sót có thể xảy ra.

(Các gốc Merkle cho phép chúng ta cam kết với dữ liệu và các phần mở rộng của dữ liệu, nhưng nó không thể cho chúng ta biết liệu chúng có nằm trên 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 con đường chống gian lận. Kế hoạch này yêu cầu ai đó quan sát và nếu một khối bị xóa nhầm, họ sẽ gửi bằng chứng gian lận để cảnh báo cho mọi người. Điều này đòi hỏi các giả định đồng bộ hóa và thiểu số trung thực tiêu chuẩn (tức 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 đã kết nối và sẽ nhận được nó trong một khoảng thời gian giới hạn).

- Ethereum và Polygon Avail đang đi theo một con đường mới - Cam kết KZG (hay còn gọi là cam kết Kate). Điều này loại bỏ giả định thiểu số trung thực và giả định đồng bộ hóa để 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 trong quá trình tái thiết mà chúng ta sẽ đề cập ngay sau đây).

Có nhiều lựa chọn khác nhưng ít người theo đuổi chúng 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 được kỳ vọng sẽ cải thiện trong những 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 có khả năng kháng lượng tử.

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

Quay lại KZG cam kết - đây là một sơ đồ cam kết đa thức.

Lược đồ cam kết chỉ đơn giản là một phương pháp mã hóa giúp thực hiện cam kết đối với một số giá trị số có thể chứng minh được. Phép ẩn dụ hay nhất là đặt một lá thư vào một chiếc hộp có khóa và đưa nó cho người khác. Bức thư không thể thay đổi sau khi được đưa vào, nhưng nó có thể được mở và chứng minh bằng chìa khóa. Bạn cam kết với lá 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, rồi tìm đa thức bậc tối thiểu thỏa mãn chúng (quá trình này được gọi là nội suy Lagrangian). Đa thức này là những gì người tục ngữ cam kết.

（ Cam kết của KZG cho phép chúng tôi cam kết với dữ liệu và phần mở rộng dữ liệu và chứng minh rằng chúng thuộc cùng một đa thức bậc thấp)

Một số điểm chính:

- Đầu tiên có đa thức

- Người chứng minh đúng về Cam kết đa thức này sự hình thành

- Điều này dựa vào 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ó, đây là một mẹo hay 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 bằng chứng

- Theo cách nói của con người: người chứng minh đưa những phầ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 một điểm nhất định. (trong đó giá trị biểu thị dữ liệu cơ bản) nằm chính xác trên đa thức được gửi.

- Điều này chứng tỏ việc mở rộng dữ liệu gốc của chúng ta là đúng, vì tất cả các giá trị đều nằm trên cùng một đa thức

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

- Đặc tính quan trọng - tuân thủ quy mô cam kết, quy mô bằng chứng và thời gian xác minh. 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  , trong đó  là bậc của đa thức.

- Về mặt con người: ngay cả khi (số lượng giá trị của) tăng (tức là tập dữ liệu tăng khi kích thước phân đoạn tăng) - quy mô của các cam kết và bằng chứng vẫn giữ nguyên, công việc cần thiết để xác minh Số lượng không đổi.

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

- Vì vậy, 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) sẽ 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: khả năng mở rộng khá tốt

Ở đây, nghiệm KZG (một cam kết đa thức) tương tự như nghiệm Merkle (một cam kết vectơ).

Dữ liệu gốc là giá trị của đa thức at để  đánh giá đa thức nhằm mở rộng nó. Tất cả các điểm  đến  được đảm bảo nằm trên cùng một đa thức.

Một câu tóm tắt: DAS cho phép chúng tôi kiểm tra xem dữ liệu được mã hóa xóa có sẵn hay không. KZG cam kết chứng minh cho chúng tôi thấy dữ liệu gốc đã được mở rộng chính xác và cam kết toàn bộ dữ liệu.

Được rồi, thế là xong cho tất cả môn đại số.

Cam kết của KZG so với bằng chứng gian lận

Bây giờ chúng ta đã hiểu cách hoạt động của KZG, hãy quay lại và so sánh hai phương pháp.

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

Tuy nhiên, vì Ethereum vẫn sẽ đưa ra lại những giả định này trong quá trình tái thiết 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 khối ban đầu có sẵn, nhưng sau đó các nút cần liên lạc với nhau để đặt nó lại với nhau. Việc tái cấu trúc này yêu cầu hai giả định:

Bạn có đủ nút (nhẹ hoặc nặng) lấy mẫu dữ liệu sao cho chúng đủ mạnh để dữ liệu được kết hợp. Đâ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 quá nhiều.

Giả định về tính đồng bộ được đưa ra lại - các nút cần liên lạc trong một khoảng thời gian nhất định để được tập hợp lại.

Người xác thực Ethereum tải xuống đầy đủ dữ liệu phân đoạn trong PDS (danksharding gốc), trong khi đối 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 người 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 các giả định về đồng bộ hóa để tái thiết. Trong trường hợp một khối chỉ có sẵn một phần, nút đầy đủ phải liên lạc với các nút khác để ghép nó lại với nhau.

Nếu Celestia muốn chuyển từ yêu cầu người xác nhận 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ẽ rõ ràng (mặc dù quá trình chuyển đổi này hiện chưa được lên kế hoạch).

Sau đó, họ cũng cần phải thực hiện cam kết của KZG - chờ đợi bằng chứng gian lận đồng nghĩa với việc tăng đáng kể khoảng thời gian chặn 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 Tình dục cũng sẽ cao.

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

Cơ bản (tương đối dễ hiểu) về mật mã đường cong elip

Khám phá các cặp đường cong elip 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

Giao thức tách biệt giữa người khởi tạo và người xây dựng

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

PBS (Tách Nhà tài trợ và Người xây dựng) chia tách Kai Lai này - Nó rõ ràng tạo ra một vai trò xây dựng trong giao thức mới. Những người xây dựng chuyên dụng sẽ ghép các khối lại với nhau và đấu thầu để người khởi xướng (người xác thực) chọn các khối của họ. Điều này phản ánh sức mạnh tập trung của MEV.

Xem lại “cuộc chơi cuối cùng” của Vitalik – mọi con đường đều dẫn đến các khối tập trung Sản xuất, với sự tin cậy và phi tập trung xác minh. PBS được xây dựng dựa trên điều này. Chúng tôi cần một người xây dựng trung thực để phục vụ tính hiệu quả của mạng và khả năng chống kiểm duyệt (hai người sẽ hiệu quả hơn), nhưng nhóm người 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 quyền của người xác nhận.

Các nhà xây dựng nhận được tiền boa 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ẽ đấu thầu toàn bộ giá trị mà họ có thể trích xuất 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ẽ nhỏ giọt 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 cụ thể vẫn đang được thảo luận, nhưng PBS hai khe có thể trông như thế này :

- Người xây dựng cam kết chặn tiêu đề trong khi đặt giá thầu

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

- Hội đồng nhân chứng (hội đồng chứng thực) xác nhận tiêu đề khối trúng thầu

- Nhà thầu công bố người trúng thầu

- Các hội đồng nhân chứng khác nhau chọn ra người trúng thầu (nếu trúng thầu) Người xây dựng không trình bày phần thân, sau đó bỏ phiếu để chứng minh nó không tồn tại).

Người khởi tạo được chọn từ nhóm người 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.

Phương pháp tiết lộ cam kết hiệu quả hơn (gửi hàng trăm khối hoàn chỉnh có thể sẽ lấn át băng thông của lớp p2p) và nó cũng có thể ngăn chặn hành vi trộm cắp MEV. Nếu một nhà xây dựng gửi khối hoàn chỉnh của họ, một nhà xây dựng khác có thể nhìn thấy nó, tìm ra chiến lược của họ, kết hợp nó và nhanh chóng xuất bản một khối tốt hơn. Ngoài ra, những người khởi tạo phức tạp có thể phát hiện chiến lược MEV đang được sử dụng và sao chép nó mà không phải bồi thường cho người xây dựng. Nếu hành vi trộm MEV này trở thành một lực cân bằng, nó sẽ khuyến khích các nhà xây dựng và người khởi tạo hợp nhất, vì vậy chúng tôi sử dụng chiến lược công bố 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, ủy ban xác nhận và củng cố nó trong fork quy tắc lựa chọn. Sau đó, người xây dựng chiến thắng sẽ xuất bản nội dung “Khối xây dựng” hoàn chỉnh giành chiến thắng của họ. Nếu được công bố kịp thời, ủy ban tiếp theo sẽ chứng nhận. Nếu không công bố kịp thời, họ vẫn phải trả toàn bộ số tiền cho người khởi tạo (và mất toàn bộ MEV và phí). Khoản thanh toán vô điều kiện này giúp loại bỏ nhu cầu nhà tài trợ phải tin tưởng vào người xây dựng.

Nhược điểm của thiết kế "khe kép" này là độ trễ. Khối được hợp nhất sẽ có thời lượng cố định là 12 giây, do đó, nếu 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 của khối (hai khe 12 giây). 8 giây cho mỗi vị trí (thời gian khối 16 giây) có vẻ là một sự thỏa hiệp an toàn, nhưng nghiên cứu vẫn đang tiếp tục.

Danh sách phản đối 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 tốt công việc của mình đến mức những người xây dựng khác phải 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. Phương pháp triển khai cụ thể là không gian thiết kế mở, nhưng "PBS lai" dường như là phổ biến nhất. Người xây dựng chỉ định danh sách tất cả các giao dịch đủ điều kiện mà họ thấy trong mempool và người xây dựng sẽ buộc phải chấp nhận gói giao dịch (trừ khi khối đã đầy).

- Người khởi xướng xuất bản tóm tắt crList và crList, trong đó chứa tất cả các giao dịch đủ điều kiện.

- Người xây dựng tạo nội dung khối được đề xuất và 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 khởi xướng chấp nhận giá thầu và tiêu đề khối của người trúng thầu (họ chưa nhìn thấy nội dung khối).

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

- Người chứng thực kiểm tra tính hợp lệ của các chủ đề đã 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ế nổi trội là người khởi xướng đưa ra một danh sách trống. Bằng cách này, ngay cả những người xây dựng được cho là đã được xem xét kỹ lưỡ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ó thể còn có những vấn đề khác nữa), 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ác cam kết của KZG cho phép chúng tôi cam kết dữ liệu và chứng minh rằng dữ liệu được chia tỷ lệ chính xác như thế nào. Tuy nhiên, đây là sự đơn giản hóa những gì Ethereum thực sự làm. Nó 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 người xây dựng tận tâm, vậy tại sao không để họ tạo ra một cam kết lớn về KZG? 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 về siêu nút cho quá trình xây dựng ban đầu, nhưng chúng ta cần tránh đưa ra các giả định về việc xây dựng lại. Chúng tôi cần các thực thể bình thường để 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 sẽ tốt hơn. Với lượng dữ liệu có trong tay, việc tái thiết 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.

Để 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. Làm điều này một cách thiếu thông minh có thể dẫn đến việc lấy mẫu nhiều - bạn sẽ thực hiện DAS trên từng đoạn được phân đoạn để có thể sử dụng được (yêu cầu m*k mẫu, trong đó k là số lượng mẫu trên mỗi đoạn).

Vì vậy, 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ệ từ m lời hứa thành 2 triệu lời hứa.

Chúng tôi biến chính sách này 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 đa thức như 0-255. Bây giờ chúng ta chỉ cần DAS trên bảng trên để đảm bảo có sẵn tất cả dữ liệu phân đoạn.

Lấy mẫu 2D yêu cầu phải có sẵn 75% dữ liệu (trái ngược với 50% được đề cập trước đó), điều đó có nghĩa là chúng ta cần rút ra số lượng mẫu cố định lớn 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, ở đây chúng tôi sẽ cần 75 mẫu để đảm bảo xác suất nhất quán trong việc xây dựng lại một khối có thể sử dụng được.

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 Sáu mươi bốn lát đã được lấy mẫu và một cuộc kiểm tra hoàn chỉnh cần 1920 mẫu. Mỗi mẫu là 512 B, nên đây là:

(512 B x 64 miếng x 30 mẫu )/16 giây = Băng thông 60 KB/s

Trên thực tế, người xác thực sẽ được chọn ngẫu nhiên , Thay vì một người kiểm tra tất cả các khu vực.

Hợp nhất các khối bằng chiến lược 2D KZG giúp việc xác minh DA hoàn chỉnh trở nên cực kỳ dễ dàng. Chỉ cần chọn 75 mẫu từ một khối được hợp nhất:

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

Danksharding

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

DS tận dụng trình xây dựng chuyên biệt để tạo ra sự tích hợp chặt chẽ hơn giữa khối thực thi Beacon Chain và các phân đoạn. Hiện tại, chúng tôi có một trình tạo tạo toàn bộ khối cùng nhau, một người đề xuất và một ủy ban bỏ phiếu cho khối đó tại một thời điểm. DS sẽ là không thể thực hiện được 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 một khối chứa đầy các đốm dữ liệu tổng hợp:

PBS ban đầu được thiết kế để bảo vệ quyền lực tập trung của MEV trong nhóm xác nhận. Tuy nhiên, Dankrad gần đây đã biết được ưu điểm của thiết kế này và đưa ra giải pháp sharding tốt hơn - DS (Danksharding).

DS sử dụng các công cụ xây dựng chuyên dụng để triển khai Beacon Chain nhằm thực thi các khối và tích hợp chặt chẽ hơn giữa các phân đoạn. Bây giờ chúng ta có một người xây dựng, người tạo ra toàn bộ các khối; một người đề xuất; và một ủy ban thực hiện việc bỏ phiếu. Không có PBS, DS không khả thi - những người 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 dữ liệu tổng hợp.

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

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

Hãy xem cách người xác minh chứng minh rằng dữ liệu là đáng tin cậy:

Điều này đòi hỏi phải dựa vào đa số những người xác nhận 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 tôi có sẵn không đủ để mang lại cho tôi sự tin cậy về mặt thống kê rằng toàn bộ khối đều có sẵn. Chúng ta cần đa số trung thực để đi đến kết luận này. Xác minh 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ư có nghĩa là những cá nhân có cấu hình thấp sẽ 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 rằng các khối có sẵn). Tuy nhiên, người xác nhận 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à tái tạo khối bootstrap.

Danksharding - Tái thiết

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

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

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

Giả định về tính đồng bộ 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ậy, bao nhiêu nút là đủ? Một ước tính sơ bộ yêu cầu 64.000 trường hợp riêng lẻ (cho đến nay có hơn 380.000). Đâ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 tập thể do trùng lặp. Điều này bắt đầu mở rộng theo tỷ lệ bậc hai - nếu trình xác thực đang chạy, chẳng hạn như 10 hoặc 100 trình xác thực, thì yêu cầu 64.000 có thể giảm đi vài bậc độ lớn.

DS có thể được thiết lập để tự động giảm khối phân đoạn nếu số lượng trình xác thực trực tuyến bắt đầu đạt số lượng rất thấp. Vì vậy, các giả định về 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 việc 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ó sẵn bằng cách tải xuống một số hàng. 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 việc 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 mạng lưới (PSA: có thể bạn có thể giúp họ!).

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

Danksharding - Tóm tắt chính

DS rất thú vị và không chỉ vì cái tên hay. Cuối cùng nó đã hiện thực hóa 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à sharding này có thể đạt được hiệu ứng không phân mảnh giả và thật.

Trên thực tế, hãy cùng 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 được phản ánh đơn giản ở chỗ người 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òn gì nữa.

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

Sharding tối thiểu có nghĩa là thiết kế đơn giản hơn sharding 1.0 (vì vậy phân phối nhanh hơn, phải không? ). Các đơn giản hóa bao gồm:

- Đặc tả DS có thể có ít tính năng hơn so với đặc tả Sharding 1.0 Hàng trăm dòng mã (ít hơn hàng nghìn dòng ở phía máy khách).

- Không còn các ủ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 theo dõi các xác nhận khối dữ liệu phân đoạn (blob) riêng lẻ, giờ đây tất cả đều đã được xác nhận trong chuỗi chính hay không.

Kết quả tốt của việc này là một thị trường tính phí dữ liệu hợp nhất. Sharding 1.0 sẽ phân mảnh mọi thứ bằng cách có các khối khác nhau được tạo bởi những người khởi xướng khác nhau.

Việc bãi bỏ ủy ban phân đoạn 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, do đó dữ liệu đượ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 điểm trên mỗi kỷ nguyên). Trình xác thực Sharding 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 xác thực (1/32 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 cho phép DAS Hiệu quả được cải thiện đáng kể . Sharding 1.0 yêu cầu băng thông 60KB/s để kiểm tra tất cả DA của tất cả các phân đoạn, DS chỉ yêu cầu 2,5KB/s.

DS cũng có một khả năng thú vị - ZK-rollup và L1 ether Lệnh gọi đồng bộ giữa các lần thực thi. Các giao dịch từ các khối được phân chia có thể được xác nhận và ghi vào L1 ngay lập tức vì mọi thứ đều được tạo trong cùng một khối chuỗi đèn hiệu. 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 mở ra 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 - những hạn chế đối với việc mở rộng blockchain

Các lớp mô-đun có quy mô linh hoạt - phân cấp nhiều hơn sẽ mang lại nhiều 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 có thể tăng thông lượng dữ liệu một cách an toàn (tức là có nhiều chỗ hơn để cho phép cuộn lại).

Vẫn còn những giới hạn đối với khả năng mở rộng của chuỗi khối, nhưng chúng ta có thể cải thiện nó theo cấp độ lớn so với ngày nay. Lớp cơ sở an toàn và có thể mở rộng cho phép thực thi được mở rộng quy mô một cách 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ơi giá trị sẽ giảm. Chúng tôi không có ranh giới rõ ràng, nhưng chúng tôi có thể liệt kê các khoảng thời gian mà việc hỗ trợ các giả thuyết nhất định bắt đầu trở nên khó khăn.

Lưu trữ dữ liệu – Đây là về DA và 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 cho bất kỳ ai sẵn sàng tải xuống để đáp ứng các giả định bảo mật của chúng tôi. Sau đó, nó sẽ được chuyển đến bất cứ nơi nào - điều này thật thoải mái vì lịch sử là 1 trong 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 đó, một kế hoạch lớn như vậy. Tuy nhiên, khi thông lượng tăng lên, nó có thể đi vào vùng không thoải mái.

Trình xác thực - DAS yêu cầu có đủ nút để cùng nhau xây dựng lại các khối. Nếu không, kẻ tấn công có thể chờ đợi và chỉ trả lời các truy vấn chúng nhận được. Nếu các 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 các truy vấ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. Đối với thông lượng được thảo luận ở đây, đây không phải là vấn đề. Tuy nhiên, điều này có thể trở nên khó chịu nếu thông lượng tăng lên vài bậc so với thiết kế này.

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

Danksharding bản địa (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 cần thiết về phía trước theo một dòng thời gian 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 về quy mô quy mô trong quá trình chuyển đổi. Tuy nhiên, nó không thực sự triển khai việc phân chia dữ liệu (tức là người xác thực cần tải xuống tất cả dữ liệu riêng lẻ).

Bản tổng hợp ngày 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 mãi mãi trên chuỗi. Tuy nhiên, bản tổng hợp chỉ yêu cầu sử dụng DA trong một khoảng thời gian ngắn nên bất kỳ ai quan tâm đều có nhiều thời gian để tải xuống.

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

Đối với bối cảnh mở rộng quy mô, các khối Ethereum hiện tại thường có kích thước 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 cho các đốm màu (mục tiêu ~1MB, tối đa ~2MB) khi chúng được cắt bớt sau một tháng. Họ không phải lúc nào cũng tạo gánh nặng cho các nút.

Một blob là một vectơ gồm 4096 phần tử trường, mỗi phần tử có 32 byte phần tử trường. PDS cho phép tối đa 16 đốm màu trên mỗi khối, trong khi DS 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 bậc mở rộng về cường độ. PDS vẫn yêu cầu các nút đồng thuận để tải xuống đầy đủ dữ liệu, vì vậy nó thận trọng hơn. 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ố điều hay mà EIP-4844 đã giới thiệu trên đường đến với DS Toy :

Dữ liệu định dạng giao dịch mang blob

Cam kết KZG với blob

Tất cả logic lớp thực thi được yêu cầu bởi DS

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

Tách lớp giữa xác thực khối báo hiệu và blob DAS

Hầu hết khu vực báo hiệu được yêu cầu bởi logic Khối DS

Tự điều chỉnh giá gas độc lập cho các đốm màu (EIP-1559 đa chiều và quy tắc định giá chỉ số)

DS cũng sẽ tham gia trong tương lai:

PBS

DAS

Chiến lược KZG 2D

Các yêu cầu về bằng chứng giám sát hoặc các yêu cầu tương tự trong giao thức cho phép mỗi người 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ể cho mỗi khối (khoảng một tháng)

Xin lưu ý rằng các đốm màu dữ liệu này được giới thiệu như một loại giao dịch mới trên chuỗi thực thi, nhưng chúng sẽ không tạo thêm gánh nặng cho các bên thực hiện. EVM chỉ xem xét các lời hứa gắn liền với các khối dữ liệu. Các thay đổi về lớp triển khai do EIP-4844 mang lại cũng tương thích về phía trước với DS và không cần thay đổi gì thêm ở phần này. 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 ứng dụng khách đồng thuận. 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 nội dung, nội dung của blob được truyền bá 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 sẵn có dữ liệu) trên đó bởi trình xác thực DS.

Trước đó chúng ta đã thảo luận về cách cam kết với các đốm màu bằng cách sử dụng lời hứa đa thức KZG. Tuy nhiên, EIP-4844 không sử dụng trực tiếp KZG mà triển khai 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 đơn (đạ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 để hỗ trợ khả năng tương thích EVM và khả năng tương thích về sau:

Khả năng tương thích EVM - KZG cam kết 48 byte, trong khi EVM sử dụng giá trị 32 byte một cách tự nhiên hơn

Khả năng tương thích về phía trước - nếu chúng ta chuyển từ KZG sang một thứ khác (chẳng hạn như STARK cho kháng lượng tử), thì cam kết có thể tiếp tục duy trì ở mức 32 byte

EIP-1559 đa chiều

PDS cuối cùng đã tạo ra một lớp dữ liệu được thiết kế riêng—— Các khối dữ liệu sẽ nhận được thị trường tính phí độc đáo của riêng họ, với giá và giới hạn khí 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 hợp 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 hợp nào hiện nay là xuất bản dữ liệu của nó lên L1 (không phải bằng chứng).

Thị trường phí gas không thay đổi và khối dữ liệu là một sự tham gia thị trường mới:

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

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

Bạn có thể thấy 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 mức trung bình so với kích thước khối mục tiêu của chúng tôi. Tính ổn định của phí cơ bản ngày nay kém, khiến mức sử dụng gas quan sát được trên mỗi khối vượt quá mục tiêu trung bình khoảng 3%.

Phần 2 Quản lý lịch sử và trạng thái

Đánh giá nhanh các khái niệm cơ bản:

Lịch sử - những gì đã xảy ra trên thế giới xâu chuỗi mọi thứ của. Bạn có thể đặt nó trực tiếp vào ổ cứng vì nó không yêu cầu 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 minh giao dịch. Nó quá lớn so với RAM và ổ cứng quá chậm - nó vừa với ổ SSD. Chuỗi khối thông lượng cao cho phép trạng thái này mở rộng nhanh chóng, phát triển nhanh hơn mức mà người bình thường có thể duy trì 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ữ lại trạng thái đó, họ không thể xác minh đầy đủ và không thể phân quyền.

Tóm lại, những thứ này có thể trở nên thực sự lớn, vì vậy bạn sẽ gặp khó khăn khi chạy một nút nếu được yêu cầu Các nút phải duy trì dữ liệu này. Nếu việc chạy một nút quá khó, những người bình thường như chúng tôi 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 Calldata và giới hạn tổng số lượng calldata (EIP-4488)

PDS là bước đệm tốt hướng tới DS và nó đáp ứng được nhiều yêu cầu cuối cùng. Bằng cách triển khai PDS trong khung thời gian hợp lý, mốc thời gian dành cho DS có thể được đưa ra sớm hơn.

Một bản vá dễ triển khai hơn là EIP-4488. Nó không quá sang trọng nhưng vẫn giải quyết được tình huống khẩn cấp về chi phí hiện tại. Thật không may, nó không cung cấp các bước cho DS, vì vậy chắc chắn điều đó sẽ phải được thực hiện sau này. Nếu bắt đầu có cảm giác như PDS chậm hơn một chút so với mong muốn của chúng tôi, thì có thể hợp lý hơn nếu chuyển nhanh qua EIP-4488 (chỉ là thay đổi một vài dòng mã) trước khi chuyển sang PDS sáu tháng sau. Chúng ta được tự do nắm bắt khoảnh khắc.

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 còn 3 gas mỗi byte

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

Cần tăng giới hạn để ngăn chặn trường hợp xấu nhất - Một khối chứa đầy calldata sẽ là 18 MB, rất xa 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 dung lượng dữ liệu bùng nổ của nó thực sự sẽ giảm nhẹ 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,875MB).

Tải duy trì của EIP-4488 cao hơn nhiều so với PDS, vì đây vẫn là calldata 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 đáng kể nhưng cũng sẽ tạo ra tình trạng tắc nghẽn trong 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ỉ giảm lịch sử tải trọng thực thi sau một năm. Tải trọng duy trì thấp hơn của PDS rõ ràng là thích hợp hơn.

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

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

Vấn đề này vốn đã quan trọng nhưng nếu EIP-4488 được triển khai thì về cơ bản điều này 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 hoàn thành 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ó.

Đồng bộ hóa toàn bộ chuỗi yêu cầu lịch sử, nhưng không bắt buộc để xác thực các khối mới (chỉ trạng thái yêu cầu). Do đó, khi khách hàng đồng bộ hóa lên đầ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 nếu một số điểm cố gắng đồng bộ hóa chuỗi. Với việc triển khai EIP-4444, chúng ta cần tìm giải pháp thay thế cho những vấn đề này.

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

Xin lưu ý rằng tính chủ quan yếu không phải là một giả định bổ sung - Điều này là tất yếu 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à máy khách sẽ không đồng bộ hóa từ một điểm kiểm tra chủ quan cũ yếu 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ử (trong trường hợp này là 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.

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

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, điều này nghe có vẻ ổn, trong khi PDS 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à vẫn được phân cấp.

EIP-4488 - Về lâu dài có thể cần ~1MB mỗi ổ cắm, tăng ~2,5 mỗi năm TB dung lượng lưu trữ

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

DS – Mục tiêu khoảng 16 MB mỗi ổ cắm, mỗi năm Thêm khoảng 40 TB dung lượng lưu trữ

Nhưng dữ liệu này sẽ đi đâu? Chúng ta có còn cần chúng không? Có, nhưng xin 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 các ứng dụng riêng lẻ. Vì vậy, 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ả dữ liệu đồng thuận này.

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 (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 trả tiền cho máy chủ để lấy dữ liệu lịch sử bằng bằng chứng Merkle

Mạng cổng thông tin ( 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 tự động chuyển các yêu cầu dữ liệu đến các nút sở hữu dữ liệu

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

Các giao thức ứng dụng cụ thể (chẳng hạn như cuộn lên) có thể yêu cầu các nút 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 dễ dàng vì đây là một trong N giả định đáng tin cậy, như chúng ta đã thảo luận trước đó. Vấn đề này vẫn 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 blockchain.

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

Được rồi, chúng ta có khả năng quản lý lịch sử tốt, nhưng còn trạng thái thì sao? Đây thực sự là nút thắt chính trong việc cải thiện TPS Ethereum vào lúc này.

Một nút hoàn chỉnh lấy gốc trạng thái trước, thực hiện tất cả giao dịch trong một khối và kiểm tra gốc trạng thái sau) khớp với những gì chúng đã cung cấp trong khối. Để biết 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 hiện có.

Trở thành tình trạng không quốc tịch - không cần nhà nước hiện có để thực hiện vai trò của mình. Ethereum đang hướng tới "tình trạng không trạng thái yếu", nghĩa là trạng thái đó không bắt buộc phải xác minh 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 tính năng thuần túy - hãy cung cấp 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ó hợp lệ hay không. Về cơ bản như thế này:

Các nhà xây dựng vẫn cần có trạng thái do PBS, điều đó có thể chấp nhận được - họ dù sao cũng sẽ là các thực thể có 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 các 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 một chút cho các nhà xây dựng và ít công việc hơn đáng kể cho người xác nhận. Thỏa thuận rất tốt.

Chúng tôi sử dụng nhân chứng (nhân chứng) để đạt được vụ 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 chính xác của trạng thái và các nhà xây dựng sẽ bắt đầu đưa những bằng chứng này vào mỗi khối. Việc xác thực một khối không thực sự yêu cầu toàn bộ trạng thái - bạn chỉ cần trạng thái mà nền tảng giao dịch trong khối đó đọc hoặc ảnh hưởng. 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 minh rằng họ đã truy cập các trạng thái này một cách chính xác.

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

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

Khóa công khai của Alice - Như vậy tôi có thể biết chữ ký là đúng

Mã nonce của Alice - nhờ đó tôi có thể biết giao dịch đã được gửi đúng thứ tự

Sau khi thực hiện giao dịch, Bob còn 1 giao dịch nữa ETH, Alice mất 1 ETH

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

Từ góc độ của người xác thực, đây là một số hàm ý:

Các yêu cầu khổng lồ về SSD cần có để duy trì trạng thái đã không còn nữa - một điểm nghẽn nghiêm trọng trong 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ì hiện tại bạ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 trong cây Merkle-Patricia, nhưng nó không phải là 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 giao dịch để xác minh đầy đủ. Stateless thừa nhận thực tế rằng đây hiện không phải là nút thắt cổ chai trong việc mở rộng quy mô Ethereum.

Tình trạng không quốc tịch yếu cũng cho phép Ethereum nới lỏng khả năng tự giới hạn về thông lượng thực thi và lạm phát trạng thái không còn là vấn đề cấp bách nữa. Có thể hợp lý nếu tăng giới hạn gas lên gấp 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ẽ ở L2, nhưng cao hơn Thông lượng L1 thậm chí còn có lợi cho họ. Rollup dựa vào Ethereum để thực hiện DA (xuất bản lên phân đoạn) và thanh toán (yêu cầu thực thi L1). Khi Ethereum mở rộng quy mô 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 các đợt tổng hợp ZK).

Verkle Tries (Verkle nỗ lực)

Chúng tôi cố tình bỏ qua cách thức hoạt động của những nhân chứng này. Ethereum hiện đang sử dụng cây Merkle-Patricia để lưu trữ trạng thái, nhưng bằng chứng Merkle cần thiết quá lớn nên những nhân chứng này không thể thực hiện được.

Ethereum sẽ chuyển sang Verkle cố gắng 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ể đóng vai trò là nhân chứng khả thi để thực hiện tình trạng không quốc tịch yếu.

Trước tiên hãy xem 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 ở phía dưới cùng được gọi là “lá”. Tất cả các giá trị băm được gọi là "nút" và chúng là giá trị băm của hai nút con bên dưới. Giá trị băm cuối cùng là "gốc Merkle".

Cấu trúc dữ liệu này rất hữu ích ở chỗ nó có thể 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 bao gồm, bạn cần có H12, H3 và H5678 trong bằng chứng Merkle. Chúng tôi có H12345678 từ tiêu đề khối. Do đó, 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à sau đó băm chúng lại với nhau theo lộ trình trong cây. Nếu kết quả là H12345678 thì chúng ta đã chứng minh thành công H4 có trong cây.

Nhưng cây càng sâu thì đường đi xuống đáy càng dài nên cần nhiều vật phẩm để chứng minh. Vì vậy, những cây nông và rộng sẽ phù hợp hơn cho việc chứng minh hiệu quả.

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

Đây chính là điều mà các cam kết về vectơ hiệu quả sẽ thực hiện. Lưu ý rằng các hàm băm được sử dụng trong cây Merkle thực sự là các lời hứa vectơ - chúng chỉ là những lời hứa xấu chỉ có thể hứa hẹn hai yếu tố một cách hiệu quả. 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 nó. Khi đã có được điều này, chúng ta có thể làm cho 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.

Bộ ba Verkle tương tự như cây Merkle, nhưng nó sử dụng các cam kết vectơ hiệu quả (do đó tên "Verkle") thay vì một hàm băm đơn giản để xác nhận các 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. Bất kể chiều rộng, đây là một bằng chứng về kích thước không đổi.

Trên thực tế, chúng tôi đã giới thiệu điều này trước đây Một ví dụ tuyệt vời về các khả năng - 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 Pedersen để thực hiện vai trò tương tự. Nó sẽ dựa trên một đường cong elip (trong trường hợp này 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 một cây có độ sâu bằng 1 và càng rộng càng tốt? Đây là một điều 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 chứng minh này, càng rộng thì càng khó.Do đó, Verkle sẽ cố gắng rơi vào giữa hai cực trị có chiều rộng giá trị 1~256.

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

Tính không trạng thái yếu sẽ loại bỏ trạng thái khỏi các ràng buộc phình to của 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. số lượng giao dịch bị giới hạn nhưng họ áp thuế vĩnh viễn lên mạng bằng cách tăng trạng thái. Sự phát triển của trạng thái vẫn là lực cản vĩnh viễn trên mạng. Chúng ta cần làm gì đó để giải quyết vấn đề cơ bản này.

Đây là lý do tại sao chúng ta cần trạng thái hết hạn. Trạng thái không hoạt động trong một thời gian dài (chẳng hạn như một hoặc hai năm) sẽ bị cắt, ngay cả khi đó là trạng thái mà người xây dựng khối lẽ ra đã đư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ữa.

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 chứng chỉ và kích hoạt lại nó . Điều này quay trở lại một trong những giả định về N bộ nhớ. 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 những gì bạn cần từ họ.

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

Phần 3 Mọi chuyện đều là lỗi của MEV

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

Việc xem xét MEV khi thiết kế chuỗi khối là chìa khóa để duy trì tính bảo mật và phân cấp. Cách tiếp cận ở 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ụ: tính hữu hạn của một khe, lựa chọn chỉ huy một bí mật)

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

The phần còn lại phải dễ dàng được nắm bắt và phổ biến giữa những người xác nhận. Nếu không, nó sẽ tập trung hóa nhóm xác thực do không thể cạnh tranh với những người tìm kiếm phức tạp. Tình hình này càng trở nên trầm trọng hơn bởi thực tế là MEV sẽ chiếm tỷ lệ phần trăm phần thưởng cho người xác thực cao hơn nhiều sau khi sáp nhập (phát hành đặt cược 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 như sau:

Các nhóm khai thác đóng vai trò là người xây dựng ở đây. Người tìm kiếm MEV chuyển các gói giao dịch (cùng với giá thầu tương ứng của họ) tới các nhóm khai thác thông qua Flashbots. Người điều hành nhóm tập 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. Thợ mỏ sử dụng PoW để chứng minh các khối, mang lại cho chúng trọng lượng trong các quy tắc lựa chọn ngã ba.

Flashbot được tạo ra để ngăn chặn sự tích hợp theo chiều dọc của toàn bộ hệ thống - điều này sẽ mở ra cơ hội kiểm duyệt và các yếu tố bên ngoài khó chịu khác mở cửa. Vào thời điểm Flashbots ra đời, các nhóm khai thác đã ký kết các thỏa thuận độc quyền với các công ty thương mại để khai thác MEV. Tuy nhiên, Flashbots cung cấp cho họ một cách dễ dàng để tổng hợp giá thầu MEV và tránh tích hợp dọc (bằng cách triển khai MEV-geth).

Sau khi sáp nhập, nhóm khai thác sẽ biến mất. Chúng tôi giúp những người xác thực nhà thường xuyên tham gia tương đối dễ dàng. Điều này đòi hỏi phải có người đảm nhận vai trò của một người xây dựng chuyên nghiệp. Những người xác nhận nhà có thể không giỏi nắm bắt MEV như các quỹ phòng hộ có mức lương cao. Nếu không được kiểm soát, những người bình thường không thể sống sót trong cuộc cạnh tranh, điều này sẽ thúc đẩy nhóm xác thực hướng tới sự tập trung hóa. Nếu được cấu trúc đúng cách, giao thức có thể chuyển doanh thu MEV thành thu nhập đặt cược cho người xác thực hàng ngày.

MEV-Boost

Thật không may, PBS trong giao thức vẫn chưa sẵn sàng vào thời điểm sáp nhập. Flashbots một lần nữa đưa ra giải pháp cứu hộ – MEV-Boost.

Theo mặc định, trình xác thực đã hợp nhất nhận các giao dịch trực tiếp từ mempool công cộng cho khách hàng thực thi của họ. Họ có thể đóng gói các giao dịch này, giao 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 xem lại 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, tôi đã đề cập đến vấn đề đó trong Phần 4).

Nhưng mẹ bạn và những người xác nhận công khai không biết cách trích xuất MEV, như chúng ta đã thảo luận Vậy nên Flashbots đang đưa ra một giải pháp thay thế. MEV-boost sẽ kết nối với ứ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ó quyền sử dụng ứng dụng khách thực thi của riêng mình.

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

MEV-Boost yêu cầu người xác nhận phải tin cậy vào chuyển tiếp, nghĩa là khách hàng đồng thuận nhận được thông tin tiêu đề và ký tên trước khi nội dung khối được tiết lộ. Mục đích của chuyển tiếp là để chứng minh cho người khởi xướng rằng nguyên tắc chính là hợp lệ và tồn tại để người xác minh không cần 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ẽ sử dụng MEV-Boost trong giai đoạn này. Tóm tắt những gì được cung cấp. PBS cung cấp sự phân chia quyền lực tương tự, giúp các nhà xây dựng dễ dàng phân cấp hơn và loại bỏ nhu cầu những người khởi xướng phải tin tưởng bất kỳ ai.

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

PBS cũng biến một ý tưởng thú vị thành hiện thực ——Ủy ban -điều khiển MEV làm mịn.

Chúng tôi thấy rằng khả năng tách MEV là rất quan trọng đối với nhóm xác minh là một lực lượng tập trung, nhưng sự phân phối cũng vậy. Sự biến đổi cao về phần thưởng MEV trên mỗi khối khuyến khích việc hợp tác với những người xác thực để tạo ra phần thưởng mượt mà theo thời gian (như chúng ta thấy với các nhóm khai thác ngày nay, mặc dù ở một mức độ khác).

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

Điều này cũng giải quyết được một vấn đề khác - hối lộ ngoài quy định. Những người khởi xướng có thể được khuyến khích gửi một khối dưới mức tối ưu và nhận hối lộ trực tiếp ngoài phạm vi để che giấu khoản thanh toán mà họ nhận được từ ai đó. Chứng nhận này ràng buộc nhà tài trợ.

PBS nội giao thức là điều kiện tiên quyết để làm trơn MEV. Bạn cần có hiểu biết về thị trường nhà xây dựng và những lời đề nghị rõ ràng đang được 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ị và rất quan trọng để đảm bảo các trình xác thực phi tập trung.

Tính cuối cùng của một khe cắm

Có được kết quả cuối cùng nhanh chóng là điều tốt. Chờ 15 phút là không lý tưởng cho trải nghiệm người dùng hoặc giao tiếp xuyên chuỗi. Quan trọng hơn, đây là vấn đề tái cơ cấu MEV.

Trong kỷ nguyên hậu sáp nhập Ethereum, sẽ có điều gì đó thậm chí còn mạnh mẽ hơn Xác nhận hiện nay - Hàng nghìn người xác thực chứng nhận từng khối, thay vì ngày nay nơi những người khai thác cạnh tranh với nhau và có thể khai thác ở cùng độ cao khối mà không cần bỏ phiếu. Điều này sẽ khiến việc tái cơ cấu trở nên khá khó khăn. Tuy nhiên, đây vẫn chưa thực sự là quyết định cuối cùng. Nếu khối cuối cùng có một số MEV hấp dẫn, nó có thể cám dỗ người xác thực cố gắng tổ chức lại chuỗi và ăn phần thưởng.

Cái kẹp có rãnh đơn giúp loại bỏ mối đe dọa này. Việc đảo ngược một khối đã hoàn thành yêu cầu ít nhất một phần ba số người xác thực và số cổ phần của họ ngay lập tức bị cắt giảm (hàng triệu ETH).

Tôi sẽ không thảo luận quá nhiều về cơ chế cơ bản ở đây. Clappers một khe cắm là một phần rất xa trong lộ trình của Ethereum và đó là một không gian thiết kế mở.

Trong giao thức đồng thuận ngày nay (không có việc ra quyết định trên một khe duy nhất), Ethereum chỉ yêu cầu 1/ 32 người xác thực chứng nhận từng vị trí (hiện có 12.000 trong số hơn 380.000 người xác nhận). Việc mở rộng quy mô bỏ phiếu này thành tập hợp đầy đủ các trình xác thực có tính năng tổng hợp chữ ký BLS trong một vị trí duy nhất đòi hỏi nhiều công việc hơn. Điều này nén hàng trăm nghìn phiếu bầu vào một lần xác thực duy nhất.

Vitalik Một số giải pháp thú vị được liệt kê, hãy xem chúng tại đây.

Cuộc bầu cử Thủ lĩnh bí mật duy nhất

SSLE được thiết kế để khắc phục một MEV khác mà chúng ta sẽ phải đối mặt sau khi sáp nhập Vector tấn công.

Danh sách trình xác thực chuỗi Beacon và lựa chọn người lãnh đạo sắp tới Danh sách này được công khai và việc hủy ẩn danh cũng như ánh xạ địa chỉ IP của chúng khá dễ dàng. Bạn có thể dễ dàng nhận ra vấn đề ở đây.

Những người xác thực tinh vi hơn có thể sử dụng một số thủ thuật để che giấu bản thân tốt hơn, nhưng những người xác nhận thông thường sẽ đặc biệt dễ bị khai thác và sau đó là DDOSd. MEV có thể dễ dàng khai thác điều này.

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

Tóm lại, người xác minh tại nhà có thể đơn giản từ bỏ việc xác minh vì họ sẽ bị tấn công. SSLE sẽ ngăn chặn cuộc tấn công này bằng cách làm cho nó không ai ngoài người khởi xướng biết khi nào đến lượt họ. Điều này sẽ không có hiệu lực khi hợp nhất, nhưng hy vọng nó sẽ được triển khai sớm hơn.

Phần 4 Bí mật sáp nhập

Được rồi, thực ra tôi đang nói đùa ở trên. Tôi thực sự nghĩ (hy vọng) việc sáp nhập sẽ diễn ra tương đối sớm.

Sự việc thú vị đến mức tôi nghĩ mình phải đứng dậy hét lên vài lời. Điều này kết thúc khóa học cấp tốc của bạn về Ethereum.

Khách hàng được hợp nhất

Ngày nay, bạn điều hành một ứng dụng khách duy nhất (chẳng hạn như Go Ethereum, Nethermind, v.v.) để xử lý mọi thứ. Cụ thể, nút đầy đủ thực hiện hai việc sau:

Thực thi - Thực hiện từng giao dịch trong khối để đảm bảo tính hợp lệ. Sử dụng gốc trạng thái trước, thực hiện nhiều thao tác khác nhau và kiểm tra xem gốc trạng thái sau được tạo có chính xác hay không

Đồng thuận - xác minh rằng bạn đã hoàn thành nhiều công việc nhất (tức là Nakamoto) trong thời gian dài nhất (PoW cao nhất) chuỗi đồng thuận Satoshi).

Cả hai không thể tách rời, bởi vì nút hoàn chỉnh không chỉ đi theo chuỗi dài nhất mà còn theo dõi chuỗi hợp lệ dài 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 bị tấn công 51%, các nút đầy đủ sẽ không chấp nhận các giao dịch không hợp lệ.

Beaconchain hiện chỉ chạy đồng thuận và chạy thử PoS, nhưng nó đã chưa được thực hiện. . Cuối cùng, tổng độ khó của thiết bị đầu cuối sẽ được xác định, lúc đó các khối thực thi Ethereum hiện tại sẽ được hợp nhất thành các khối chuỗi beacon và hợp nhất thành một chuỗi:

Tuy nhiên, một nút đầy đủ sẽ chạy hai máy khách độc lập trong một hộp đen và tương tác với nhau.

Máy khách thực thi (f.k.a. 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ì các mempool cũng như quản lý và đồng bộ hóa trạng thái. PoW không được dùng nữa.

Ứng dụng đồng thuận (f.k.a. Eth2 Client) - Ứng dụng khách Beacon Chain hiện tại tiếp tục xử lý sự đồng thuận PoS. Họ theo dõi tiêu đề chuỗi, giao tiếp và chứng minh các khối cũng như nhận phần thưởng của người xác nhận.

Khách hàng nhận được khối của beacon chain, thực hiện giao dịch do khách hàng thực hiện và sau đó đạt được sự đồng thuận Khách hàng sẽ tuân theo chuỗi nếu mọi thứ đều ổn. Bạn sẽ có thể kết hợp các ứng dụng khách thực thi và đồng thuận mà bạn chọn, đồng thời tất cả các ứng dụng khách đều hỗ trợ tương tác. API công cụ mới sẽ được giới thiệu để liên lạc giữa các khách hàng:

Hoặc như thế này:

Sự đồng thuận hợp nhất

Sự đồng thuận của Satoshi ngày nay rất đơn giản. Người khai thác tạo các khối mới và thêm chúng vào chuỗi hợp lệ được quan sát lâu nhất.

Sau khi sáp nhập, Ethereum chuyển sang GASPER - kết hợp với Casper FFG (công cụ quyết định) cộng với LMD GHOST (Quy tắc lựa chọn ngã ba) để đạt được sự đồng thuận. Nói một cách dễ hiểu - đây là một sự sống động ủng hộ sự đồng thuận, không phải bảo mật.

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

Tuy nhiên, Ethereum cũng sẽ thực hiện điều này thông qua các trạm kiểm soát thường xuyên nếu có đủ phiếu bầu Quyết định cuối cùng. Mỗi phiên bản của 32 ETH là một trình xác thực độc lập và hiện có hơn 380.000 trình xác thực Beacon Chain. Tổng cộng một kỷ nguyên bao gồm 32 vị trí, với tất cả trình xác thực được phân chia để xác thực một vị trí trong một kỷ nguyên nhất định (nghĩa là ~12.000 trình xác thực trên mỗi vị trí). Quy tắc lựa chọn ngã ba LMD Ghost sau đó xác định đầ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 sau mỗi vị trí (12 giây), do đó tổng thời gian là 6,4 phút. Thông thường sau hai kỷ nguyên, kết quả cuối cùng sẽ đạt được với số phiếu bầu cần thiết (tức là cứ 64 vị trí, mặc dù có thể mất tới 95).

Tóm tắt

Tất cả các con đường đều dẫn đến sự kết thúc của việc sản xuất khối tập trung, xác minh khối không cần sự tin cậy phi tập trung và khả năng chống kiểm duyệt. Lộ trình của Ethereum nêu bật tầm nhìn này.

Mục tiêu của Ethereum là trở thành DA và Lớp thanh toán thống nhất cuối cùng - Phân quyền và bảo mật lớn được xây dựng dựa trên khả năng mở rộng điện toán. Đây là sự cô đọng các giả định về mật mã thành một lớp mạnh mẽ. Một lớp cơ sở mô-đun thống nhất (hoặc hiện đã được phân cấp?) Bao gồm việc thực thi đồng thời thu được giá trị cao nhất của toàn bộ thiết kế L1 - dẫn đến phí bảo hiểm tiền tệ và an ninh kinh tế, như tôi đã báo cáo gần đây (hiện đã có sẵn công khai).

Tôi hy vọng bạn hiểu rõ hơn về mối liên hệ giữa nghiên cứu về Ethereum. Nó rất tiên tiến, mọi phần đều đang thay đổi và không dễ để hình dung ra bức tranh tổng thể. Bạn cần phải luôn theo dõi.

Cuối cùng, tất cả đều quay trở lại tầm nhìn duy nhất đó. Ethereum mang đến cho chúng tôi một con đường hấp dẫn để đạt được khả năng mở rộng quy mô lớn trong khi vẫn tuân thủ các giá trị mà chúng tôi quan tâm sâu sắc trong không gian này.

Đặc biệt cảm ơn Dankrad Feist Đánh giá và hiểu biết sâu sắc.

Liên kết gốc

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia