Vitalik: Danksharding thực sự là gì?
Tuyển chọn TechFlowTuyển chọn TechFlow
Vitalik: Danksharding thực sự là gì?
Danksharding là thiết kế phân mảnh mới được đề xuất cho Ethereum, vậy công nghệ này thực sự mang lại điều gì?
Chuyên sâu báo cáo Web3Tác giả: Vitalik Buterin
Danksharding là gì?
Danksharding là một thiết kế phân mảnh mới được đề xuất cho Ethereum, mang lại một số đơn giản hóa đáng kể so với các thiết kế trước đó.
Tất cả các đề xuất phân mảnh Ethereum gần đây nhất kể từ năm 2020 (bao gồm cả Danksharding và các phiên bản trước của nó) khác biệt chính với hầu hết các đề xuất phân mảnh phi-Ethereum ở chỗ Ethereum theo lộ trình tập trung vào Rollup: thay vì cung cấp thêm không gian cho giao dịch, phân mảnh Ethereum cung cấp dữ liệu mà giao thức Ethereum sẽ không cố gắng diễn giải. Việc xác thực blob chỉ cần kiểm tra xem blob có sẵn hay không, tức là có thể tải xuống từ mạng hay không. Không gian dữ liệu trong các blob này dự kiến sẽ được sử dụng bởi các giao thức Layer 2 Rollup hỗ trợ thông lượng giao dịch cao.
Đổi mới chính mà Danksharding giới thiệu là việc hợp nhất thị trường phí: thay vì có một số lượng cố định các phân mảnh, mỗi phân mảnh có khối riêng và người đề xuất khối riêng, thì trong Danksharding chỉ có một người đề xuất chọn tất cả các giao dịch và toàn bộ dữ liệu đi vào khe thời gian đó.
Để tránh yêu cầu hệ thống quá cao đối với các trình xác thực trong thiết kế này, chúng ta giới thiệu sự tách biệt giữa người đề xuất và người xây dựng (PBS): một nhóm đặc biệt các thực thể gọi là "người xây dựng khối" cạnh tranh để giành quyền chọn khe thời gian, trong khi người đề xuất chỉ cần chọn tiêu đề hợp lệ có mức giá thầu cao nhất. Chỉ những người xây dựng khối mới cần xử lý toàn bộ khối (ở đây cũng có thể dùng các giao thức oracles phi tập trung bên thứ ba để thực hiện người xây dựng phân tán); tất cả các trình xác thực và người dùng khác đều có thể xác minh hiệu quả khối thông qua lấy mẫu khả năng sẵn sàng dữ liệu (lưu ý rằng phần "lớn" của khối chỉ là dữ liệu).
Proto-danksharding (còn gọi là EIP-4844) là gì?
Proto-danksharding (còn gọi là EIP-4844) là một đề xuất cải tiến Ethereum (EIP), nhằm triển khai phần lớn logic và "khung sườn" cấu thành quy chuẩn đầy đủ của Danksharding (ví dụ như định dạng giao dịch, quy tắc xác thực), nhưng chưa thực sự triển khai bất kỳ phân mảnh nào. Trong triển khai proto-danksharding, tất cả các trình xác thực và người dùng vẫn phải trực tiếp xác minh tính sẵn sàng đầy đủ của dữ liệu.
Tính năng chính mà proto-danksharding giới thiệu là loại giao dịch mới, gọi là giao dịch kèm blob. Giao dịch kèm blob giống như giao dịch thông thường, ngoại trừ việc nó còn mang theo dữ liệu bổ sung gọi là blob. Blob rất lớn (~125 kB) và rẻ hơn nhiều so với lượng calldata tương đương. Tuy nhiên, việc thực thi EVM không thể truy cập dữ liệu blob; EVM chỉ có thể xem cam kết về blob.
Vì các trình xác thực và khách hàng vẫn cần tải xuống toàn bộ nội dung blob, mục tiêu băng thông dữ liệu trong proto-danksharding là 1 MB mỗi khe, thay vì 16 MB đầy đủ. Tuy nhiên, do dữ liệu này không cạnh tranh với việc sử dụng gas của các giao dịch Ethereum hiện tại, nên vẫn có lợi ích mở rộng đáng kể.
Tại sao việc thêm 1 MB dữ liệu vào khối mà mọi người đều phải tải xuống lại chấp nhận được, trong khi làm giảm chi phí calldata 10 lần thì không?
Điều này liên quan đến sự khác biệt giữa tải trung bình và tải trường hợp xấu nhất. Hiện nay, chúng ta đã thấy khối trung bình khoảng 90 kB, nhưng kích thước khối tối đa lý thuyết (nếu toàn bộ 30 triệu gas trong khối đều dùng cho dữ liệu gọi) là khoảng 1,8 MB. Mạng Ethereum từng xử lý các khối gần mức tối đa. Tuy nhiên, nếu đơn giản giảm chi phí gas calldata xuống 10 lần, thì dù kích thước khối trung bình tăng lên mức vẫn chấp nhận được, nhưng trường hợp xấu nhất sẽ trở thành 18 MB — điều này quá lớn đối với mạng Ethereum.
Cơ chế định giá gas hiện tại không thể tách biệt hai yếu tố này: tỷ lệ giữa tải trung bình và tải trường hợp xấu nhất phụ thuộc vào quyết định của người dùng về việc chi bao nhiêu gas cho calldata so với tài nguyên khác, nghĩa là giá gas phải được đặt theo khả năng trường hợp xấu nhất, dẫn đến tải trung bình thấp hơn không cần thiết so với khả năng xử lý của hệ thống. Tuy nhiên, nếu chúng ta thay đổi cơ chế định giá gas để tạo ra một thị trường phí đa chiều rõ ràng hơn, chúng ta có thể tránh tình trạng lệch pha giữa tải trung bình và tải xấu nhất, và đưa vào mỗi khối lượng dữ liệu gần sát với mức tối đa mà chúng ta có thể xử lý an toàn. Proto-danksharding và EIP-4488 là hai đề xuất làm điều này.
So sánh proto-danksharding với EIP-4488 như thế nào?
EIP-4488 là một nỗ lực sớm hơn và đơn giản hơn nhằm giải quyết vấn đề lệch pha giữa tải trung bình và tải xấu nhất. EIP-4488 sử dụng hai quy tắc đơn giản:
Chi phí gas calldata giảm từ 16 gas mỗi byte xuống 3 gas mỗi byte
Giới hạn 1 MB mỗi khối cộng thêm 300 byte cho mỗi giao dịch (giá trị lý thuyết tối đa: ~1,4 MB)
Giới hạn cứng là cách đơn giản nhất để đảm bảo rằng sự gia tăng lớn về tải trung bình sẽ không kéo theo sự gia tăng tải trường hợp xấu nhất. Việc giảm chi phí gas sẽ làm tăng mạnh việc sử dụng rollup, có thể đẩy kích thước khối trung bình lên vài trăm KB, nhưng giới hạn cứng sẽ trực tiếp ngăn chặn khả năng xuất hiện khối đơn lẻ 10 MB trong trường hợp xấu nhất. Thực tế, kích thước khối xấu nhất sẽ nhỏ hơn hiện nay (1,4 MB so với 1,8 MB).
Ngược lại, proto-danksharding tạo ra một loại giao dịch riêng biệt có thể chứa dữ liệu rẻ hơn trong blob có kích thước cố định lớn, và giới hạn số lượng blob có thể được đưa vào mỗi khối. Các blob này không thể truy cập từ EVM (chỉ có cam kết về blob), và blob được lưu trữ bởi lớp đồng thuận (chuỗi beacon) chứ không phải lớp thực thi.
Sự khác biệt thực tế chính giữa EIP-4488 và proto-danksharding là EIP-4488 cố gắng tối thiểu hóa các thay đổi cần thiết ngay hôm nay, trong khi proto-danksharding thực hiện nhiều thay đổi lớn ngày nay để việc nâng cấp lên phân mảnh hoàn chỉnh sau này chỉ cần rất ít thay đổi. Mặc dù việc triển khai phân mảnh đầy đủ (với lấy mẫu khả năng sẵn sàng dữ liệu, v.v.) là một nhiệm vụ phức tạp và vẫn sẽ là một nhiệm vụ phức tạp sau proto-danksharding, nhưng độ phức tạp này được gói gọn trong lớp đồng thuận. Một khi proto-danksharding được triển khai, các đội phát triển client lớp thực thi, nhà phát triển rollup và người dùng sẽ không cần làm thêm công việc nào để hoàn tất quá trình chuyển đổi sang phân mảnh đầy đủ.
Lưu ý rằng lựa chọn giữa hai cái này không phải kiểu "hoặc cái này hoặc cái kia": chúng ta có thể triển khai EIP-4488 càng sớm càng tốt, rồi sau đó nửa năm nữa triển khai proto-danksharding.
Proto-danksharding đã thực hiện những phần nào của danksharding đầy đủ, và còn thiếu những gì cần triển khai?
Trích dẫn EIP-4844:
Những công việc đã hoàn thành trong EIP này bao gồm:
· Một loại giao dịch mới, có định dạng hoàn toàn giống với loại cần tồn tại trong "phân mảnh đầy đủ".
· Toàn bộ logic lớp thực thi cần thiết cho phân mảnh đầy đủ.
· Toàn bộ logic kiểm chứng chéo giữa thực thi và đồng thuận cần thiết cho phân mảnh đầy đủ.
· Sự tách biệt giữa lớp BeaconBlock và lấy mẫu khả năng sẵn sàng dữ liệu blob.
· Phần lớn logic BeaconBlock cần thiết cho phân mảnh đầy đủ.
· Giá gas độc lập tự điều chỉnh cho blob.
Những công việc còn lại để đạt được phân mảnh đầy đủ bao gồm:
· Mở rộng bậc thấp của blob_kzgs ở lớp đồng thuận để cho phép lấy mẫu 2D.
· Triển khai thực tế của lấy mẫu khả năng sẵn sàng dữ liệu.
· PBS (tách biệt người đề xuất/người xây dựng), để tránh yêu cầu một trình xác thực xử lý 32 MB dữ liệu trong một khe.
· Bằng chứng lưu trữ hoặc yêu cầu nội bộ giao thức tương tự cho mỗi trình xác thực, để xác minh phần dữ liệu phân mảnh cụ thể trong mỗi khối.
Lưu ý rằng tất cả các công việc còn lại đều là thay đổi ở lớp đồng thuận, không yêu cầu thêm công việc nào từ các đội client thực thi, người dùng hay nhà phát triển Rollup.
Tất cả những khối rất lớn này sẽ làm tăng nhu cầu về dung lượng đĩa, vậy phải xử lý thế nào?
Cả EIP-4488 và proto-danksharding đều dẫn đến mức sử dụng dài hạn khoảng 1 MB mỗi khe (12 giây). Điều này tương đương khoảng 2,5 TB mỗi năm, cao hơn nhiều so với tốc độ tăng trưởng hiện tại của Ethereum.
Trong trường hợp EIP-4488, cần có một cơ chế hết hạn lịch sử (EIP-4444), nơi các client không còn cần lưu trữ lịch sử vượt quá một khoảng thời gian nhất định (đề xuất từ 1 tháng đến 1 năm).
Trong trường hợp proto-danksharding, lớp đồng thuận có thể triển khai logic riêng biệt để tự động xóa dữ liệu blob sau một khoảng thời gian (ví dụ 30 ngày), bất kể EIP-4444 có được triển khai hay không. Tuy nhiên, bất kể giải pháp mở rộng dữ liệu ngắn hạn nào được áp dụng, đều rất khuyến khích triển khai EIP-4444 càng sớm càng tốt.
Cả hai chiến lược này đều giới hạn tải đĩa bổ sung cho client đồng thuận ở mức vài trăm GB. Về lâu dài, việc áp dụng một cơ chế hết hạn lịch sử là bắt buộc: phân mảnh đầy đủ sẽ thêm khoảng 40 TB dữ liệu blob lịch sử mỗi năm, do đó người dùng thực tế chỉ có thể lưu trữ một phần nhỏ trong một khoảng thời gian. Vì vậy, nên thiết lập kỳ vọng này sớm.
Nếu dữ liệu bị xóa sau 30 ngày, người dùng sẽ truy cập blob cũ bằng cách nào?
Mục đích của giao thức đồng thuận Ethereum không phải là đảm bảo lưu trữ vĩnh viễn cho mọi dữ liệu lịch sử. Thay vào đó, mục tiêu là cung cấp một bảng thông báo an toàn cao, và dành chỗ cho các giao thức phi tập trung khác thực hiện lưu trữ dài hạn. Sự tồn tại của bảng thông báo nhằm đảm bảo rằng dữ liệu đăng trên đó sẽ sẵn sàng đủ lâu để bất kỳ người dùng nào muốn dữ liệu đó hoặc bất kỳ giao thức lưu trữ dự phòng dài hạn nào đều có đủ thời gian để thu thập dữ liệu và nhập vào các ứng dụng hoặc giao thức khác của họ.
Nói chung, việc lưu trữ lịch sử dài hạn khá dễ dàng. Dù 2,5 TB mỗi năm quá lớn đối với các nút thông thường, nhưng lại rất dễ quản lý đối với người dùng chuyên dụng: bạn có thể mua ổ cứng cực lớn với giá khoảng 20 USD mỗi TB, điều này hoàn toàn phù hợp với người nghiệp dư. Khác với đồng thuận N/2-trên-N, lưu trữ lịch sử có mô hình tin cậy 1-trên-N: bạn chỉ cần một trong những người lưu trữ là trung thực. Do đó, mỗi dữ liệu lịch sử chỉ cần được lưu trữ vài trăm lần, thay vì đầy đủ hàng nghìn nút đang thực hiện xác thực đồng thuận thời gian thực.
Một số phương pháp thực tế để lưu trữ đầy đủ lịch sử và giúp truy cập dễ dàng bao gồm:
Các giao thức ứng dụng cụ thể (ví dụ như Rollup) có thể yêu cầu các nút của mình lưu trữ phần lịch sử liên quan đến ứng dụng đó. Dữ liệu lịch sử bị mất không gây rủi ro cho giao thức, chỉ gây rủi ro cho ứng dụng riêng lẻ, vì vậy việc ứng dụng tự chịu trách nhiệm lưu trữ dữ liệu liên quan đến mình là hợp lý.
Lưu trữ dữ liệu lịch sử trên BitTorrent, ví dụ: tự động tạo và phân phối hàng ngày một tệp 7 GB chứa dữ liệu blob từ khối.
Mạng cổng Ethereum (hiện đang phát triển) có thể dễ dàng mở rộng để lưu trữ lịch sử.
Các trình duyệt khối, nhà cung cấp API và các dịch vụ dữ liệu khác có thể lưu trữ đầy đủ lịch sử.
Các cá nhân đam mê và học giả làm phân tích dữ liệu có thể lưu trữ đầy đủ lịch sử. Trong trường hợp sau, lưu trữ lịch sử cục bộ mang lại giá trị quan trọng vì nó giúp việc tính toán trực tiếp trên dữ liệu dễ dàng hơn.
Các giao thức lập chỉ mục bên thứ ba như TheGraph có thể lưu trữ đầy đủ lịch sử.
Ở mức lưu trữ lịch sử cao hơn (ví dụ 500 TB mỗi năm), nguy cơ một số dữ liệu bị quên đi sẽ cao hơn (thêm vào đó, hệ thống xác minh khả năng sẵn sàng dữ liệu sẽ căng thẳng hơn). Đây có thể là giới hạn thực sự về khả năng mở rộng của blockchain phân mảnh. Tuy nhiên, hiện tại tất cả các tham số được đề xuất đều còn rất xa điểm này.
Định dạng dữ liệu blob là gì, và nó được cam kết như thế nào?
Một blob là một vector chứa 4096 phần tử trường, là các số trong phạm vi:
Về mặt toán học, blob được coi là biểu diễn đa thức bậc dưới 4096 trên trường hữu hạn với modulo nói trên.
Cam kết về blob là cam kết KZG — một hàm băm của đa thức đó. Tuy nhiên, từ góc nhìn triển khai, không cần thiết phải quan tâm đến chi tiết toán học của đa thức. Thay vào đó, sẽ chỉ có một vector các điểm đường cong elliptic (dựa trên thiết lập đáng tin cậy kiểu Lagrange), và cam kết KZG về blob sẽ chỉ là một tổ hợp tuyến tính. Trích dẫn mã trong EIP-4844:
BLS_MODULUS là modulo nói trên, còn KZG_SETUP_LAGRANGE là vector các điểm đường cong elliptic, là thiết lập đáng tin cậy kiểu Lagrange. Đối với người triển khai, giờ đây hợp lý khi coi nó đơn giản như một hàm băm chuyên dụng hộp đen.
Tại sao dùng hàm băm của KZG thay vì dùng trực tiếp KZG?
EIP-4844 không dùng trực tiếp KZG để biểu diễn blob, mà dùng phiên bản băm: một byte 0x01 duy nhất (biểu thị 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.
Việc này nhằm đảm bảo tương thích với EVM và tương lai: cam kết KZG dài 48 byte, trong khi EVM xử lý tự nhiên hơn với giá trị 32 byte, và nếu chúng ta chuyển từ KZG sang thứ khác (ví dụ vì lý do kháng lượng tử), cam kết KZG có thể vẫn giữ ở 32 byte.
Hai tiền biên dịch được giới thiệu trong proto-danksharding là gì?
Proto-danksharding giới thiệu hai tiền biên dịch: tiền biên dịch xác minh blob và tiền biên dịch đánh giá điểm.
Tiền biên dịch xác minh blob là tự miêu tả: nó nhận phiên bản băm và blob làm đầu vào, và xác minh rằng phiên bản băm được cung cấp thực sự là phiên bản băm hợp lệ của blob. Tiền biên dịch này nhằm phục vụ cho Optimistic Rollup. Trích dẫn EIP-4844:
Optimistic Rollup chỉ cần cung cấp dữ liệu gốc khi nộp bằng chứng gian lận. Hàm nộp bằng chứng gian lận sẽ yêu cầu toàn bộ nội dung blob gian lận được gửi như một phần của calldata. Nó sẽ dùng chức năng xác minh blob để kiểm tra dữ liệu theo phiên bản băm đã nộp trước đó, rồi sau đó thực hiện xác minh bằng chứng gian lận trên dữ liệu đó như hiện nay.
Tiền biên dịch đánh giá điểm nhận phiên bản băm, tọa độ x, tọa độ y và bằng chứng (cam kết KZG của blob và bằng chứng đánh giá KZG) làm đầu vào. Nó xác minh bằng chứng để kiểm tra P(x) = y, trong đó P là đa thức được biểu diễn bởi blob có phiên bản băm đã cho. Tiền biên dịch này nhằm phục vụ cho ZK Rollup. Trích dẫn EIP-4844:
ZK rollup sẽ cung cấp hai cam kết cho giao dịch hoặc dữ liệu tăng lượng trạng thái của họ: KZG trong blob và một cam kết khác dùng hệ thống chứng minh nội bộ của ZK rollup. Họ sẽ dùng bằng chứng cam kết đẳng cấu, dùng tiền biên dịch đánh giá điểm, để chứng minh rằng KZG (bảo đảm trỏ tới dữ liệu sẵn sàng) và cam kết riêng của ZK rollup tham chiếu đến cùng một dữ liệu.
Lưu ý rằng hầu hết các thiết kế Optimistic Rollup chính đều dùng sơ đồ chống gian lận nhiều vòng, trong đó vòng cuối cùng chỉ cần một lượng nhỏ dữ liệu. Vì vậy, có thể hình dung Optimistic Rollup cũng có thể dùng tiền biên dịch đánh giá điểm thay vì tiền biên dịch xác minh blob, và làm vậy sẽ rẻ hơn.
Thiết lập đáng tin cậy KZG trông như thế nào?
Xem:
https://vitalik.ca/general/2022/03/14/trustedsetup.html
Mô tả tổng quát về cách hoạt động của thiết lập đáng tin cậy powers-of-tau
https://github.com/ethereum/research/blob/master/trusted_setup/trusted_setup.py
Triển khai mẫu cho tất cả các phép tính quan trọng liên quan đến thiết lập đáng tin cậy
Đặc biệt trong trường hợp của chúng ta, kế hoạch hiện tại là chạy song song bốn nghi lễ có kích thước khác nhau (n1=4096,n2=16), (n1=8192,n2=16), (n1=16834,n2=16) và (n1=32768,n2=16) (với các bí mật khác nhau). Về lý thuyết, chỉ cần cái đầu tiên, nhưng việc chạy thêm các kích thước lớn hơn sẽ nâng cao tính linh hoạt trong tương lai bằng cách cho phép tăng kích thước blob. Chúng ta không thể chỉ có một thiết lập lớn hơn vì chúng ta cần có giới hạn cứng về bậc đa thức có thể cam kết một cách hiệu quả, giới hạn này bằng với kích thước blob.
Phương pháp thực tế khả dĩ là bắt đầu từ thiết lập Filecoin, rồi chạy một nghi lễ để mở rộng nó. Nhiều triển khai khác nhau, bao gồm cả trong trình duyệt, sẽ cho phép nhiều người tham gia.
Chúng ta không thể dùng một số cam kết khác mà không cần thiết lập đáng tin cậy?
Thật không may, việc dùng bất cứ thứ gì ngoài KZG (ví dụ như IPA hoặc SHA256) sẽ khiến lộ trình phân mảnh trở nên khó khăn hơn. Có một vài lý do:
Các cam kết phi số học (ví dụ như hàm băm) không tương thích với lấy mẫu khả năng sẵn sàng dữ liệu, vì vậy nếu dùng sơ đồ như vậy, dù sao chúng ta cũng phải chuyển sang KZG khi chuyển sang phân mảnh đầy đủ.
IPA có thể tương thích với lấy mẫu khả năng sẵn sàng dữ liệu, nhưng sẽ dẫn đến các sơ đồ phức tạp hơn với các thuộc tính yếu hơn (ví dụ, tự sửa chữa và xây dựng khối phân tán trở nên khó khăn hơn).
Cả hàm băm và IPA đều không tương thích với việc triển khai rẻ tiền cho tiền biên dịch đánh giá điểm. Do đó, triển khai dựa trên hàm băm hoặc IPA sẽ không thể hiệu quả trong việc hỗ trợ ZK Rollup hoặc hỗ trợ bằng chứng gian lận rẻ tiền trong các vòng nhiều lần của Optimistic Rollup.
Vì vậy, thật không may, tổn thất chức năng và tăng độ phức tạp khi dùng bất cứ thứ gì ngoài KZG lớn hơn nhiều so với rủi ro của bản thân KZG. Hơn nữa, mọi rủi ro liên quan đến KZG đều được giới hạn: một lỗi KZG chỉ ảnh hưởng đến Rollup và các ứng dụng khác phụ thuộc vào dữ liệu blob, chứ không ảnh hưởng đến phần còn lại của hệ thống.
KZG "phức tạp" và "mới" đến mức nào?
Cam kết KZG được giới thiệu trong một bài báo năm 2010 và đã được sử dụng rộng rãi trong các giao thức ZK-SNARK kiểu PLONK kể từ năm 2019. Tuy nhiên, toán học cơ bản của cam kết KZG là một phép toán số học tương đối đơn giản nằm trên các phép toán đường cong elliptic và ghép đôi.
Đường cong cụ thể được dùng là BLS12-381, được Barreto-Lynn-Scott phát minh năm 2002. Ghép đôi đường cong elliptic, cần thiết để xác minh cam kết KZG, là toán học rất phức tạp, nhưng chúng được phát minh vào những năm 1940 và được áp dụng trong mật mã từ những năm 1990. Đến năm 2001, nhiều thuật toán mật mã dùng ghép đôi đã được đề xuất.
Về độ phức tạp triển khai, KZG không khó hơn IPA: hàm tính cam kết (xem trên) hoàn toàn giống với trường hợp IPA, chỉ khác ở bộ hằng số điểm đường cong elliptic. Tiền biên dịch đánh giá điểm phức tạp hơn một chút vì nó liên quan đến đánh giá ghép đôi, nhưng toán học giống với phần đã thực hiện trong triển khai EIP-2537 (tiền biên dịch BLS12-381) và rất giống với tiền biên dịch ghép đôi bn128 (xem thêm: triển khai Python tối ưu). Do đó, triển khai xác minh KZG không yêu cầu "công việc mới" phức tạp nào.
Các phần mềm khác nhau trong triển khai proto-danksharding là gì?
Có bốn thành phần chính:
1. Thay đổi đồng thuận ở lớp thực thi (xem chi tiết trong EIP):
Loại giao dịch mới chứa blob
Opcode xuất ra phiên bản băm blob thứ i trong giao dịch hiện tại
Tiền biên dịch xác minh blob
Tiền biên dịch đánh giá điểm
2. Thay đổi đồng thuận ở lớp đồng thuận (xem thư mục này trong kho):
Danh sách blob KZG trong BeaconBlockBody
Cơ chế "sidecar", nơi nội dung blob đầy đủ được truyền cùng một đối tượng riêng biệt từ BeaconBlock
Kiểm tra chéo giữa phiên bản băm blob ở lớp thực thi và blob KZG ở lớp đồng thuận
3. Mempool
BlobTransactionNetworkWrapper (xem phần mạng trong EIP)
Bảo vệ chống DoS mạnh hơn để bù đắp kích thước blob lớn
4. Logic xây dựng khối
Chấp nhận các trình bao giao dịch từ mempool, đưa giao dịch vào ExecutionPayload, đưa KZG vào phần thân của khối beacon và sidecar
Xử lý thị trường phí hai chiều
Lưu ý rằng đối với triển khai tối thiểu, chúng ta thậm chí không cần mempool (có thể dựa vào thị trường gom gói giao dịch lớp 2), và chúng ta chỉ cần một client triển khai logic xây dựng khối. Chỉ các thay đổi đồng thuận ở lớp thực thi và lớp đồng thuận cần được thử nghiệm đồng thuận rộng rãi, tương đối nhẹ nhàng. Mọi thứ nằm giữa triển khai tối thiểu như vậy và triển khai "đầy đủ" mà mọi client đều hỗ trợ sản xuất khối và mempool đều là khả thi.
Thị trường phí đa chiều của proto-danksharding trông như thế nào?
Proto-danksharding giới thiệu một thị trường phí EIP-1559 đa chiều, với hai tài nguyên, gas và blob, có giá gas nổi riêng và giới hạn riêng.
Nói cách khác, có hai biến và bốn hằng số:
Phí blob được tính bằng gas, nhưng là lượng gas biến đổi, sẽ được điều chỉnh để về lâu dài, số lượng blob trung bình mỗi khối thực sự bằng với số lượng mục tiêu.
Tính chất hai chiều có nghĩa là người xây dựng khối sẽ đối mặt với bài toán khó hơn: thay vì đơn giản chấp nhận các giao dịch có phí ưu tiên cao nhất cho đến khi hết giao dịch hoặc đạt giới hạn gas khối, họ sẽ phải đồng thời tránh đạt đến hai giới hạn khác nhau.
Đây là một ví dụ. Giả sử giới hạn gas là 70, giới hạn blob là 40. Mempool có rất nhiều giao dịch, đủ để lấp đầy khối, với hai loại (gas giao dịch bao gồm gas mỗi blob):
Phí ưu tiên 5 mỗi gas, 4 blob, tổng cộng 4 gas
Phí ưu tiên 3 mỗi gas, 1 blob, tổng cộng 2 gas
Thợ đào theo thuật toán "giảm phí ưu tiên" ngây thơ sẽ lấp đầy toàn bộ khối bằng 10 giao dịch loại đầu tiên (40 gas) và thu được doanh thu 5 * 40 = 200 gas. Vì 10 giao dịch này đã lấp đầy hoàn toàn giới hạn blob, họ sẽ không thể đưa thêm giao dịch nào. Nhưng chiến lược tối ưu là lấy 3 giao dịch loại đầu tiên và 28 giao dịch loại thứ hai. Điều này cho bạn một khối với 40 blob và 68 gas, và doanh thu 5 * 12 + 3 * 56 = 228.
Liệu các client thực thi bây giờ phải triển khai thuật toán ba lô đa chiều phức tạp để tối ưu hóa sản xuất khối? Không, vì một vài lý do:
EIP-1559 đảm bảo rằng hầu hết các khối sẽ không đạt đến giới hạn nào, do đó thực tế chỉ một số ít khối phải đối mặt với vấn đề tối ưu hóa đa chiều. Trong trường hợp thông thường khi mempool không có đủ (giao dịch trả phí đủ) để đạt đến bất kỳ giới hạn nào, bất kỳ thợ đào nào cũng có thể thu được doanh thu tối đa bằng cách đưa vào mọi giao dịch họ thấy.
Trong thực tế, các phương pháp heuristic khá đơn giản có thể gần đạt tối ưu. Trong trường hợp tương tự, hãy xem phân tích EIP-4488 của Ansgar để biết thêm dữ liệu về điều này.
Định giá đa chiều thậm chí không phải là nguồn thu nhập lớn nhất đến từ chuyên môn hóa — MEV mới là. Thu nhập MEV chuyên dụng từ việc rút ra từ arbitrage DEX trên chuỗi, thanh lý,抢先 bán NFT, v.v. chiếm phần lớn "thu nhập có thể rút ra" (tức là phí ưu tiên): thu nhập MEV chuyên dụng dường như trung bình khoảng 0,025 ETH mỗi khối, trong khi tổng phí ưu tiên thường vào khoảng 0,1 ETH mỗi khối.
Sự tách biệt người đề xuất/người xây dựng (PBS) được thiết kế xung quanh việc sản xuất khối chuyên sâu. PBS biến quá trình xây dựng khối thành một cuộc đấu giá, nơi các thực thể chuyên dụng có thể đấu giá đặc quyền tạo khối. Các trình xác thực thông thường chỉ cần chấp nhận mức giá thầu cao nhất. Điều này nhằm ngăn chặn kinh tế quy mô do MEV thúc đẩy lan rộng đến sự tập trung hóa trình xác thực, nhưng nó xử lý tất cả các vấn đề có thể làm cho việc tối ưu hóa xây dựng khối trở nên khó khăn hơn.
Do những lý do này, động lực thị trường phí phức tạp hơn sẽ không làm tăng đáng kể sự tập trung hóa hay rủi ro; thực tế, việc áp dụng rộng rãi hơn các nguyên tắc có thể thực sự làm giảm rủi ro tấn công DoS!
Cơ chế điều chỉnh phí blob EIP-1559 hàm mũ hoạt động như thế nào?
EIP-1559 hiện tại điều chỉnh phí cơ sở b để đạt được mức sử dụng gas mục tiêu t như sau:
Trong đó b(n) là phí cơ sở khối hiện tại, b(n+1) là phí cơ sở khối tiếp theo, t là mục tiêu, u là lượng gas sử dụng.
Một vấn đề lớn của cơ chế này là nó thực tế không nhắm đúng vào t. Giả sử chúng ta có hai khối, khối đầu tiên u=0, khối tiếp theo u=2t. Chúng ta có:
Mặc dù mức sử dụng trung bình bằng t, phí cơ sở lại giảm 63/64. Vì vậy phí cơ sở chỉ ổn định khi mức sử dụng hơi cao hơn t; trong thực tế rõ ràng cao hơn khoảng 3%, mặc dù con số chính xác phụ thuộc vào phương sai.
Một công thức tốt hơn là điều chỉnh hàm mũ:
exp(x) là hàm mũ e^x, với e≈2,71828. Với giá trị x nhỏ, exp(x)≈1+x. Tuy nhiên, nó có tính chất tiện lợi là độc lập với hoán vị giao dịch: điều chỉnh nhiều bước
chỉ phụ thuộc vào tổng u1+...+u/n, chứ không phụ thuộc vào phân bố. Để hiểu lý do, chúng ta có thể làm toán:
Do đó, cùng một tập giao dịch được đưa vào sẽ dẫn đến cùng một phí cơ sở cuối cùng, bất kể chúng được phân bổ giữa các khối khác nhau như thế nào.
Công thức cuối cùng ở trên cũng có một giải thích toán học tự nhiên: thuật ngữ (u1+u2+...+u/n - nt) có thể được coi là phần dư: sự khác biệt giữa tổng gas thực tế sử dụng và tổng gas dự định sử dụng.
Sự kiện phí cơ sở hiện tại bằng
rõ ràng cho thấy phần dư không thể vượt ra khỏi một phạm vi rất hẹp: nếu vượt quá 8t*60, phí cơ sở sẽ thành e^60, cao đến mức không ai có thể trả; nếu thấp hơn 0, tài nguyên về cơ bản là miễn phí và chuỗi sẽ bị spam cho đến khi phần dư trở lại trên 0.
Cơ chế điều chỉnh hoạt động hoàn toàn theo các thuật ngữ này: nó theo dõi tổng thực tế (u1+u2+...+u/n) và tính tổng mục tiêu (nt), rồi tính giá theo hàm mũ của sự khác biệt. Để tính toán đơn giản hơn, chúng ta không dùng e^x mà dùng 2^x; thực tế, chúng ta dùng một xấp xỉ của 2^x: hàm fake_exponential trong EIP. Fake_exponential gần như luôn nằm trong 0,3% giá trị thực tế.
Để ngăn việc sử dụng thiếu kéo dài gây ra các khối đầy đủ gấp đôi trong thời gian dài, chúng ta thêm một tính năng bổ sung: chúng ta sẽ không để phần dư dưới 0. Nếu tổng thực tế thấp hơn tổng mục tiêu, chúng ta chỉ cần đặt tổng thực tế bằng tổng mục tiêu. Trong trường hợp cực đoan (blob gas giảm xuống 0), điều này thực sự phá vỡ tính bất biến thứ tự giao dịch, nhưng sự an toàn tăng thêm khiến đây là một thỏa hiệp chấp nhận được. Cũng lưu ý một kết quả thú vị của thị trường đa chiều này: khi ban đầu giới thiệu proto-danksharding, ban đầu có thể chỉ có rất ít người dùng, vì vậy trong một thời gian, chi phí cho một blob gần như chắc chắn sẽ rất rẻ, ngay cả khi hoạt động blockchain Ethereum "thông thường" vẫn còn đắt.
Tác giả cho rằng cơ chế điều chỉnh phí này tốt hơn phương pháp hiện tại, do đó cuối cùng tất cả các phần của thị trường phí EIP-1559 nên chuyển sang dùng nó.
Để biết giải thích dài và chi tiết hơn, xem bài đăng của Dankrad.
fake_exponential hoạt động như thế nào?
Để tiện lợi, đây là mã của fake_exponential:
Dưới đây là cơ chế cốt lõi được diễn đạt lại bằng toán học, bỏ qua làm tròn:
Mục tiêu là nối nhiều phiên bản (QX), mỗi phiên bản được dịch chuyển và phóng to phù hợp cho từng phạm vi [2^k,2^(k+1)]. Bản thân Q(x) là xấp xỉ của 2^x trong 0≤x≤1, được chọn vì các thuộc tính sau:
Đơn giản (đây là một phương trình bậc hai)
Độ chính xác ở mép trái (Q(0)=2^0=1)
Độ chính xác ở mép phải (Q(1)=2^1=2)
Độ dốc mượt (chúng ta đảm bảo Q’(1)=2*Q’(0), do đó độ dốc của mỗi bản sao dịch chuyển+phóng to của Q ở mép phải bằng độ dốc của bản sao tiếp theo ở mép trái)
Ba yêu cầu cuối cùng đưa ra ba phương trình tuyến tính cho ba hệ số chưa biết, và Q(x) được đưa ra ở trên là nghiệm duy nhất.
Sự xấp xỉ này đáng ngạc nhiên là rất tốt; với mọi đầu vào ngoại trừ nhỏ nhất, fake_exponential cho đáp án nằm trong 0,3% giá trị thực tế của 2^x:
Những vấn đề nào trong proto-danksharding vẫn đang được tranh luận?
Lưu ý: Phần này dễ trở nên lỗi thời. Đừng tin tưởng nó sẽ đưa ra suy nghĩ cập nhật nhất về bất kỳ vấn đề cụ thể nào.
Tất cả các Optimistic Rollup chính đều dùng chứng minh nhiều vòng, do đó chúng có thể dùng tiền biên dịch đánh giá điểm (rẻ hơn nhiều) thay vì tiền biên dịch xác minh blob. Bất kỳ ai thực sự cần xác minh blob đều có thể tự triển khai: lấy blob D và phiên bản băm h làm đầu vào, chọn x=hash(D,h), dùng đánh giá trọng tâm để tính y=D(x) và dùng tiền biên dịch đánh giá điểm để xác minh h(x)=y. Vậy chúng ta thực sự cần tiền biên dịch xác minh blob, hay có thể xóa nó và chỉ dùng đánh giá điểm?
Khả năng của chuỗi trong việc xử lý các khối dài hạn 1 MB+ như thế nào? Nếu rủi ro quá lớn, liệu có nên giảm số lượng blob mục tiêu ngay từ đầu?
Blob nên được định giá bằng gas hay ETH (bị đốt)? Có nên điều chỉnh thị trường phí theo cách khác không?
Nên coi loại giao dịch mới này là blob hay đối tượng SSZ, trong trường hợp thứ hai thay đổi ExecutionPayload thành kiểu hợp? (Đây là sự đánh đổi giữa "làm nhiều công việc hơn ngay bây giờ" và "làm nhiều công việc hơn sau này")
Chi tiết triển khai cụ thể của thiết lập đáng tin cậy (về mặt kỹ thuật nằm ngoài phạm vi EIP, vì đối với người triển khai, thiết lập này "chỉ là một hằng số", nhưng vẫn cần hoàn thành).
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@VitalikButerin
