Tác giả: Vitalik Buterin

Người sáng lập Ethereum Vitalik Buterin gần đây đã trả lời các câu hỏi liên quan đến Proto-danksharding (còn gọi là EIP-4844). Danksharding là một thiết kế sharding mới được đề xuất cho Ethereum. Công nghệ này có thể mang lại điều gì?

Danksharding là gì?

Danksharding là một thiết kế sharding mới được đề xuất cho Ethereum, giới thiệu một số đơn giản hóa đáng kể so với các thiết kế trước đó.

Sự khác biệt chính giữa tất cả các đề xuất sharding Ethereum gần đây kể từ năm 2020 (bao gồm cả Danksharding và Danksharding trước đó) và hầu hết các đề xuất sharding không phải Ethereum là lộ trình tập trung vào rollup của Ethereum: Các phân đoạn Ethereum Sharding không cung cấp thêm không gian cho các giao dịch, mà dành cho dữ liệu, mà Ethereum bản thân giao thức không cố gắng giải thích.

Việc xác thực một đốm màu chỉ đơn giản là kiểm tra xem blob đó có sẵn hay không, nghĩa là có thể tải xuống từ mạng. Không gian dữ liệu trong các đốm màu này dự kiến ​​sẽ được sử dụng bởi giao thức Tổng hợp Lớp 2 (Lớp 2) hỗ trợ các giao dịch thông lượng cao.

Cải tiến chính được giới thiệu bởi Danksharding là thị trường phí hợp nhất: thay vì số lượng phân đoạn cố định, mỗi phân đoạn có một khối khác nhau và một người đề xuất khối khác nhau, trong Danksharding, chỉ một người đề xuất chọn tham gia vào vị trí Tất cả giao dịch và tất cả dữ liệu.

Để tránh các yêu cầu hệ thống cao đối với người xác minh trong thiết kế này, chúng tôi giới thiệu sự tách biệt giữa người đề xuất/người xây dựng (PBS): một loại người tham gia đặc biệt được gọi là người xây dựng khối đặt giá thầu để có quyền chọn vị trí và người đề xuất chỉ cần chọn giá thầu Tiêu đề hợp lệ cao nhất là đủ .

Chỉ những trình tạo khối mới cần xử lý toàn bộ khối (ở đây, một giao thức tiên tri phi tập trung của bên thứ ba cũng có thể được sử dụng để triển khai các trình tạo khối phân tán); tất cả những trình xác thực và người dùng khác có thể lấy mẫu tính khả dụng của dữ liệu một cách rất hiệu quả Xác thực khối (hãy nhớ: khối "lớn" một phầ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) triển khai hầu hết logic và "giàn giáo" (ví dụ: định dạng giao dịch, quy tắc xác thực) tạo nên đặc điểm kỹ thuật Danksharding đầy đủ, nhưng chưa thực sự triển khai bất kỳ phần nào . Trong quá trình triển khai proto-danksharding, tất cả người xác thực và người dùng vẫn phải trực tiếp xác minh tính khả dụng của toàn bộ dữ liệu.

Tính năng chính được giới thiệu bởi proto-danksharding là một loại giao dịch mới, mà chúng tôi gọi là giao dịch với blob. Giao dịch với blob tương tự như giao dịch thông thường, ngoại trừ việc nó cũng mang dữ liệu bổ sung được gọi là blob. Các đốm màu rất lớn (~125 kB) và rẻ hơn nhiều so với một lượng calldata tương tự. Tuy nhiên, việc thực thi EVM không thể truy cập dữ liệu blob; EVM chỉ có thể nhìn thấy những lời hứa đối với blob.

Vì trình xác thực và ứng dụng khách vẫn cần tải xuống toàn bộ nội dung blob nên mục tiêu băng thông dữ liệu trong proto-danksharding là 1 MB trên mỗi ổ cắm thay vì 16 MB đầy đủ. Tuy nhiên, vì 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 có, nên vẫn có lợi ích lớn về khả năng mở rộng.

Tại sao có thể thêm 1 MB dữ liệu vào một đoạn dữ liệu mà mọi người phải tải xuống, thay vì làm cho calldata rẻ hơn 10 lần?

Điều này liên quan đến sự khác biệt giữa tải trung bình và tải trong trường hợp xấu nhất. Ngày nay, chúng tôi gặp phải các tình huống trong đó kích thước khối trung bình là khoảng 90 kB, nhưng kích thước khối tối đa có thể về mặt lý thuyết (nếu tất cả 30M gas trong một khối được sử dụng để gọi dữ liệu) là khoảng 1,8 MB. Mạng Ethereum được sử dụng để xử lý gần với số khối tối đa.

Tuy nhiên, nếu chúng ta chỉ đơn giản giảm chi phí gas calldata xuống 10 lần, thì mặc dù kích thước khối trung bình tăng lên mức vẫn có thể chấp nhận được, nhưng trường hợp xấu nhất sẽ trở thành 18 MB, quá nhiều đối với mạng Ethereum.

Cơ chế định giá gas hiện tại không thể tách rời hai yếu tố này: tỷ lệ giữa tải trung bình và tải trong trường hợp xấu nhất phụ thuộc vào lựa chọn của người dùng về lượng gas chi tiêu cho calldata so với các tài nguyên khác, có nghĩa là giá gas phải dựa trên trường hợp xấu nhất Cài đặt khả năng của , khiến trung bình tải thấp hơn mức hệ thống có thể xử lý một cách không cần thiết.

Tuy nhiên, nếu chúng tôi thay đổi giá gas để tạo ra một thị trường phí đa chiều một cách rõ ràng hơn, thì chúng tôi có thể tránh được sự không phù hợp về tải trong trường hợp trung bình/trường hợp xấu nhất và đưa vào mỗi khối gần với lượng dữ liệu tối đa mà chúng tôi có thể xử lý một cách an toàn. Proto-danksharding và EIP-4488 là hai đề xuất để làm điều này.

Proto-danksharding so 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 để giải quyết cùng một vấn đề tải không khớp trong trường hợp trung bình/trường hợp xấu nhất. EIP-4488 thực hiện điều này bằng hai quy tắc đơn giản:

• Chi phí gas cuộc gọidata 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 (tối đa lý thuyết: ~1,4 MB)

Giới hạn cứng là cách dễ dàng nhất để đảm bảo rằng mức tăng lớn trong tải trường hợp trung bình không dẫn đến tăng tải trong trường hợp xấu nhất. Việc giảm chi phí gas sẽ làm tăng đáng kể việc sử dụng các bản tổng hợp, có khả năng tăng kích thước khối trung bình lên hàng trăm KB, nhưng giới hạn cứng sẽ trực tiếp ngăn chặn khả năng xảy ra trường hợp xấu nhất là một khối duy nhất chứa 10 MB. Trên thực tế, kích thước khối trong trường hợp xấu nhất sẽ nhỏ hơn hiện tại (1,4 MB so với 1,8 MB).

Thay vào đó, proto-danksharding tạo ra một loại giao dịch riêng giúp tiết kiệm dữ liệu rẻ hơn trong các đốm màu có kích thước cố định lớn và giới hạn số lượng đốm màu mà mỗi khối có thể chứa. Các đốm màu này không thể truy cập được từ EVM (chỉ các cam kết đối với các đốm màu) và các đốm màu được lưu trữ bởi lớp đồng thuận (chuỗi báo hiệu) thay vì 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 giảm thiểu những thay đổi cần thiết hiện nay, trong khi proto-danksharding có rất nhiều thay đổi hiện nay, vì vậy việc nâng cấp lên full sharding trong tương lai cần rất ít thay đổi.

Mặc dù triển khai phân đoạn đầy đủ (sử dụng lấy mẫu tính khả dụng của dữ liệu, v.v.) là một nhiệm vụ phức tạp và vẫn là một nhiệm vụ phức tạp sau khi proto-danksharding, nhưng sự phức tạp này được chứa trong lớp đồng thuận. Sau khi khởi chạy proto-danksharding, nhóm khách hàng lớp điều hành, nhà phát triển tổng số và người dùng không cần thực hiện thêm công việc nào để hoàn tất quá trình chuyển đổi sang phân đoạn đầy đủ.

Lưu ý rằng sự lựa chọn giữa hai không phải là/hoặc: chúng ta có thể triển khai EIP-4488 càng sớm càng tốt, sau đó nửa năm sau sẽ tiếp tục với proto-danksharding.

proto-danksharding thực hiện những phần nào của darksharding hoàn chỉnh? Những gì khác cần phải được thực hiện?

Trích dẫn EIP-4844, công việc đã được thực hiện trong EIP này bao gồm:

• Loại giao dịch mới có cùng định dạng chính xác cần tồn tại trong "phân đoạn đầy đủ".

• Tất cả logic lớp thực thi cần thiết cho phân đoạn đầy đủ.

• Cần có tất cả logic xác thực chéo thực thi/đồng thuận để phân đoạn đầy đủ.

• Tách lớp giữa xác thực BeaconBlock và các đốm lấy mẫu tính khả dụng của dữ liệu.

• Hầu hết logic BeaconBlock cần thiết để bảo vệ hoàn toàn.

• Gasprice độc ​​lập tự điều chỉnh cho đốm màu.

• Công việc phải làm để đạt được sharding đầy đủ bao gồm:

• Phần mở rộng cấp thấp của blob_kzgs trong lớp đồng thuận để cho phép lấy mẫu 2D.

• Một triển khai thực tế của lấy mẫu dữ liệu sẵn có,

• PBS (tách người đề xuất/người xây dựng) để tránh yêu cầu một trình xác thực duy nhất xử lý 32 MB dữ liệu trong một vùng.

• Bằng chứng ký quỹ hoặc các yêu cầu trong giao thức tương tự cho mỗi trình xác thực để xác thực các phần cụ thể của dữ liệu phân đoạn trong mỗi khối.

Lưu ý rằng tất cả công việc còn lại là các thay đổi của lớp đồng thuận và không yêu cầu bất kỳ công việc bổ sung nào do nhóm khách hàng, người dùng hoặc nhà phát triển Rollup thực hiện.

Điều gì sẽ xảy ra nếu tất cả những khối rất lớn này làm tăng yêu cầu về dung lượng đĩa?

Cả EIP-4488 và proto-danksharding đều dẫn đến mức sử dụng tối đa trong thời gian dài là khoảng 1 MB trên mỗi ổ cắm (12 giây). Điều này tương đương với khoảng 2,5 TB mỗi năm, cao hơn nhiều so với tốc độ tăng trưởng mà Ethereum cần hiện nay.

Trong trường hợp của EIP-4488, việc giải quyết vấn đề này yêu cầu sơ đồ hết hạn lịch sử (EIP-4444), trong đó khách hàng không còn bắt buộc phải lưu trữ lịch sử sau một khoảng thời gian nhất định (thời gian đề xuất kéo dài từ 1 tháng đến 1 năm) .

Trong trường hợp proto-danksharding, cho dù EIP-4444 có được triển khai hay không, 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). Tuy nhiên, bất kể giải pháp mở rộng dữ liệu ngắn hạn là gì, EIP-4444 được khuyến nghị thực hiện càng sớm càng tốt.

Cả hai chiến lược đều giới hạn tải ổ đĩa bổ sung trên máy khách đồng thuận tối đa là vài trăm GB. Về lâu dài, việc sử dụng một số cơ chế hết hạn lịch sử về cơ bản là bắt buộc: phân đoạn hoàn toàn bổ sung khoảng 40 TB dữ liệu blob lịch sử mỗi năm, vì vậy người dùng thực sự chỉ có thể lưu trữ một phần dữ liệu đó trong một thời gian. Vì vậy, bạn nên sớm đặt kỳ vọng cho điều này.

Người dùng sẽ truy cập các đốm màu cũ như thế nào nếu dữ liệu bị xóa sau 30 ngày?

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 tất cả dữ liệu lịch sử. Thay vào đó, mục đích là cung cấp một bảng thông báo thời gian thực có độ bảo mật cao và dành chỗ cho các giao thức phi tập trung khác để lưu trữ lâu dài hơn.

Bảng tin tồn tại để đảm bảo rằng dữ liệu được đăng trên Bảng tin có sẵn đủ lâu để bất kỳ người dùng nào muốn dữ liệu đó hoặc bất kỳ thỏa thuận dài hạn nào để sao lưu dữ liệu đều có đủ thời gian để lấy và nhập dữ liệu đó vào ứng dụng khác của họ hoặc giao thức.

Nói chung, lưu trữ lịch sử lâu dài là dễ dàng. Mặc dù 2,5 TB mỗi năm là yêu cầu quá lớn đối với một nút thông thường, nhưng nó rất dễ quản lý đối với người dùng chuyên dụng: bạn có thể mua ổ cứng rất lớn với giá khoảng 20 USD mỗi TB, quá đủ cho người có sở thích.

Không giống như sự đồng thuận có mô hình tin cậy 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ữ dữ liệu trung thực. Do đó, mỗi phần dữ liệu lịch sử chỉ cần được lưu trữ hàng trăm lần, thay vì hàng nghìn nút đang thực hiện xác minh đồng thuận theo thời gian thực.

Một số cách thiết thực để lưu trữ toàn bộ lịch sử và giúp truy cập dễ dàng bao gồm:

• Các giao thức dành riêng cho ứng dụng như Rollup có thể yêu cầu các nút của chúng lưu trữ các phần lịch sử liên quan đến ứng dụng của chúng. Dữ liệu lịch sử bị mất không gây rủi ro cho giao thức, chỉ cho các ứng dụng riêng lẻ, do đó, các ứng dụng sẽ chịu trách nhiệm lưu trữ dữ liệu liên quan đến chính chúng.

• Lưu trữ dữ liệu lịch sử trong BitTorrent, vd. Tệp 7 GB chứa dữ liệu blob từ khối được tạo và phân phối tự động hàng ngày.

• Mạng cổng Ethereum (hiện đang được phát triển) có thể dễ dàng mở rộng để lưu trữ lịch sử.

• Trình khám phá khối, nhà cung cấp API và các dịch vụ dữ liệu khác có thể lưu trữ toàn bộ lịch sử.

• Những người có sở thích cá nhân và các học giả tham gia phân tích dữ liệu có thể lưu trữ hồ sơ lịch sử hoàn chỉnh. Trong trường hợp thứ hai, việc lưu trữ cục bộ lịch sử mang lại cho chúng giá trị đáng kể, vì nó giúp tính toán trực tiếp trên đó dễ dàng hơn.

• Các giao thức lập chỉ mục của bên thứ ba như TheGraph có thể lưu trữ toàn bộ 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ị lãng quên sẽ cao hơn (ngoài ra, hệ thống xác minh tính khả dụng của dữ liệu trở nên căng thẳng hơn). Đây có thể là giới hạn thực sự của khả năng mở rộng đối với các chuỗi khối phân mảnh. Tuy nhiên, tất cả các thông số được đề xuất hiện nay đều cách rất xa điểm này.

Định dạng của dữ liệu blob là gì và nó được gửi như thế nào?

Một đốm màu là một vectơ gồm 4096 phần tử trường, các số trong phạm vi:

0 <= x < 52435875175126190479447740508185965837690552500527637822603658699938581184513

Một đốm màu được xem về mặt toán học là đại diện cho một đa thức bậc < 4096 trên một trường hữu hạn với mô đun trên, trong đó phần tử trường tại vị trí i trong đốm màu là đánh giá của đa thức đó tại wi. w là hằng số thỏa mãn w=1.

Cam kết với blob là một hàm băm của cam kết KZG với đa thức. Tuy nhiên, từ quan điểm triển khai, việc quan tâm đến các chi tiết toán học của đa thức là không quan trọng. Thay vào đó, sẽ chỉ có một vectơ các điểm đường cong elip (dựa trên thiết lập Lagrangian đáng tin cậy) và cam kết của KZG đối với đốm màu sẽ chỉ đơn giản là một sự kết hợp tuyến tính. Trích dẫn mã từ EIP-4844:

def blob_to_kzg(blob: Vector[BLSFieldElement, 4096]) -> KZGCommitment: computed_kzg = bls.Z1 for value, point_kzg in zip(tx.blob, KZG_SETUP_LAGRANGE): assert value < BLS_MODULUS computed_kzg = bls.add( computed_kzg, bls.multiply(point_kzg, value) ) return computed_kzg

BLS_MODULUS là mô-đun ở trên và KZG_SETUP_LAGRANGE là một véc tơ của các điểm đường cong elip, đây là một thiết lập đáng tin cậy dựa trên Lagrange. Giờ đây, hợp lý là những người triển khai nghĩ về nó đơn giản như một hàm băm chuyên dụng hộp đen.

Tại sao sử dụng hàm băm của KZG thay vì KZG trực tiếp?

Thay vì sử dụng KZG để biểu thị trực tiếp một đốm màu, EIP-4844 sử dụng hàm băm theo phiên bản: 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.

Điều này được thực hiện để tương thích với EVM và khả năng tương thích trong tương lai: các lời hứa KZG là 48 byte, trong khi EVM sử dụng các giá trị 32 byte một cách tự nhiên hơn và nếu chúng tôi chuyển từ KZG sang một thứ khác (ví dụ: vì lý do kháng lượng tử), các cam kết KZG có thể tiếp tục là 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 loại biên dịch trước: biên dịch trước xác minh blob và biên dịch trước đánh giá dấu chấm.

Quá trình biên dịch trước xác thực blob có thể tự giải thích được: nó lấy đầu vào là hàm băm có phiên bản và blob, đồng thời xác minh rằng hàm băm có phiên bản được cung cấp thực sự là hàm băm có phiên bản hợp lệ cho blob. Biên dịch trước này dự định sẽ được sử dụng bởi Optimistic Rollup. Trích dẫn EIP-4844:

Bản tổng hợp lạc quan chỉ cần thực sự cung cấp dữ liệu cơ bản khi gửi bằng chứng gian lận. Tính năng gửi bằng chứng gian lận sẽ yêu cầu gửi toàn bộ nội dung của đốm gian lận như một phần của calldata. Nó sẽ sử dụng xác thực blob để xác thực dữ liệu dựa trên hàm băm đã cam kết trước đó, sau đó thực hiện xác thực bằng chứng gian lận trên dữ liệu đó như hiện nay.

Biên dịch trước đánh giá điểm lấy đầu vào là hàm băm được phiên bản, 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). Nó xác minh bằng chứng để kiểm tra xem P(x) = y, trong đó P là đa thức được đại diện bởi blob với hàm băm được phiên bản nhất định. Phần biên dịch trước này dự định sẽ được sử dụng bởi 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 delta trạng thái của nó: KZG trong blob và một số cam kết sử dụng bất kỳ hệ thống bằng chứng nào mà ZK rollup sử dụng nội bộ. Họ sẽ sử dụng Bằng chứng về Cam kết của Giao thức Tương đương, sử dụng tính năng biên dịch trước đánh giá điểm, để chứng minh rằng kzg (giao thức đảm bảo trỏ đến dữ liệu có sẵn) và cam kết của chính ZK rollup đề cập đến cùng một dữ liệu.

Lưu ý rằng hầu hết các thiết kế Tổng số lạc quan chính đều sử dụng sơ đồ chống gian lận nhiều vòng, trong đó vòng cuối cùng chỉ yêu cầu một lượng nhỏ dữ liệu. Vì vậy, có thể hiểu được rằng, Optimistic Rollup cũng có thể sử 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à sẽ rẻ hơn nếu làm như vậy.

Thiết lập đáng tin cậy của KZG trông như thế nào?

Nhìn:

Mô tả chung về cách hoạt động của cài đặt đáng tin cậy

https://vitalik.ca/General/2022/03/14/trustedsetup.html để biết quyền hạn của tau 

Ví dụ triển khai tất cả các tính toán quan trọng liên quan đến thiết lập đáng tin cậy

https://github.com/ethereum/research/blob/master/trusted_setup/trusted_setup.py

Cụ thể trong trường hợp của chúng tôi, kế hoạch hiện tại là chạy song song bốn kích thước (n1=4096, n2=16), (n1=8192, n2=16), (n1=16834, n2=16) và (n1= 32768, n2=16) nghi lễ (với một bí mật khác). Về lý thuyết, chỉ cái đầu tiên là cần thiết, nhưng việc chạy thêm kích thước lớn hơn sẽ cải thiện khả năng ứng dụng trong tương lai bằng cách cho phép chúng tôi tăng kích thước đốm màu. Chúng tôi không thể có một thiết lập lớn hơn, bởi vì chúng tôi muốn có thể có giới hạn cứng đối với số lượng đa thức có thể được cam kết một cách hiệu quả, bằng với kích thước blob.

Một cách tiếp cận thực tế khả thi là bắt đầu với thiết lập Filecoin, sau đó tổ chức một buổi lễ để mở rộng quy mô. Nhiều triển khai bao gồm triển khai trình duyệt sẽ cho phép nhiều người tham gia.

Chúng tôi không thể sử dụng một số chương trình cam kết khác mà không có thiết lập đáng tin cậy?

Thật không may, việc sử dụng bất kỳ thứ gì khác ngoài KZG (chẳng hạn như IPA hoặc SHA256) khiến lộ trình phân đoạn trở nên khó khăn hơn. Cái này có một vài nguyên nhân:

Các cam kết phi số học (chẳng hạn như hàm băm) không tương thích với lấy mẫu tính khả dụng của dữ liệu, vì vậy nếu chúng tôi sử dụng sơ đồ như vậy, thì khi chúng tôi chuyển sang phân đoạn đầy đủ, chúng tôi vẫn phải đổi sang KZG.

IPA có thể tương thích với lấy mẫu tính khả dụng của dữ liệu, nhưng nó dẫn đến các lược đồ phức tạp hơn với các thuộc tính yếu hơn (ví dụ: tự phục hồi và xây dựng khối phân tán trở nên khó hơn)

Cả hàm băm và IPA đều không tương thích với việc triển khai tiền biên dịch đánh giá điểm giá rẻ. Do đó, việc triển khai dựa trên hàm băm hoặc IPA sẽ không thể kích hoạt hiệu quả ZK Rollup hoặc hỗ trợ bằng chứng gian lận giá rẻ trong nhiều vòng của Optimistic Rollup.

Vì vậy, thật không may, việc mất chức năng và tăng độ phức tạp khi sử dụng bất kỳ thứ gì khác ngoài KZG vượt xa rủi ro của chính KZG. Ngoài ra, mọi rủi ro liên quan đến KZG đều được bảo hiểm: lỗi KZG sẽ chỉ ảnh hưởng đến Rollup và các ứng dụng khác phụ thuộc vào dữ liệu blob, không phải phần còn lại của hệ thống.

KZG "phức tạp" và "mới" như thế nào?

Các 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, phép toán cơ bản mà KZG hứa hẹn là một phép toán tương đối đơn giản trên nền toán cơ bản của các phép toán và ghép nối đường cong elip.

Đường cong cụ thể được sử dụng là BLS12-381, được phát minh bởi Barreto-Lynn-Scott vào năm 2002. Các cặp đường cong elip, cần thiết để xác minh lời hứa 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 sử dụng trong mật mã từ những năm 1990. Đến năm 2001, một số thuật toán mã hóa sử dụng ghép cặp đã được đề xuất.

Từ góc độ phức tạp triển khai, KZG không khó triển khai hơn IPA: chức năng tính toán cam kết (xem ở trên) hoàn toàn giống như trong trường hợp IPA, chỉ sử dụng một bộ hằng số điểm đường cong elip khác. Biên dịch trước xác minh điểm phức tạp hơn vì nó liên quan đến đánh giá cặp, nhưng toán học giống như những gì đã được thực hiện trong triển khai EIP-2537 (biên dịch trước BLS12-381) và rất giống với biên dịch trước cặp bn128 (xem thêm: Tối ưu hóa hoàn thành Python). Do đó, không cần "công việc mới" phức tạp để thực hiện xác minh KZG.

Các phần mềm khác nhau của quá trình triển khai proto-danksharding là gì?

Có bốn thành phần chính:

1. Sự đồng thuận của lớp thực thi đã thay đổi (xem EIP để biết chi tiết):

• Loại giao dịch mới bao gồm các đốm màu

• Opcode xuất ra hàm băm được phiên bản của blob thứ i trong giao dịch hiện tại

• Biên dịch trước xác thực Blob

• biên dịch trước đánh giá chấm

2. Thay đổi đồng thuận lớp đồng thuận (xem thư mục này trong repo):

• Danh sách blob KZG trong BeaconBlockBody

• cơ chế "sidecar" trong đó toàn bộ nội dung blob được truyền cùng với một đối tượng riêng biệt từ BeaconBlock

• Kiểm tra chéo giữa các hàm băm được phiên bản blob trong lớp thực thi và KZG blob trong lớp đồng thuận

3. Nhóm bộ nhớ

• BlobTransactionNetworkWrapper (xem phần mạng của EIP)

• Bảo vệ chống DoS mạnh hơn để bù cho kích thước blob lớn

4. Logic xây dựng khối

• Chấp nhận trình bao bọc giao dịch từ mempool, đặt giao dịch vào ExecutPayload, đặt KZG vào khối đèn hiệu và phần thân trong sidecar

• Ứng phó với thị trường phí hai chiều

Lưu ý rằng để triển khai tối thiểu, chúng tôi hoàn toàn không cần mempool (chúng tôi có thể dựa vào thị trường gói giao dịch lớp thứ hai), chúng tôi chỉ cần một khách hàng để triển khai logic xây dựng khối. Chỉ những thay đổi đồng thuận trong lớp thực thi và lớp đồng thuận mới yêu cầu thử nghiệm đồng thuận rộng rãi, tương đối nhẹ. Bất cứ điều gì giữa triển khai tối thiểu như vậy và triển khai "đầy đủ" trong đó tất cả các máy khách hỗ trợ sản xuất khối và mempool đều có thể.

Thị trường phí đa chiều proto-danksharding trông như thế nào?

Proto-danksharding giới thiệu thị trường phí EIP-1559 đa chiều với hai tài nguyên, gas và blob, với giá gas thả nổi riêng biệt và các giới hạn riêng biệt.

Ethereum

Phí blob được tính bằng gas, nhưng đó là một lượng gas thay đổi có thể điều chỉnh sao cho về lâu dài, số lượng đốm màu trung bình trên mỗi khối thực sự bằng với số lượng mục tiêu.

Bản chất hai chiều có nghĩa là những người xây dựng khối sẽ phải đối mặt với một vấn đề khó khăn hơn: thay vì chỉ chấp nhận các giao dịch với mức phí ưu tiên cao nhất cho đến khi hết giao dịch hoặc đạt đến giới hạn gas khối, họ sẽ phải tránh đạt được cả hai hạn chế khác nhau.

Đây là một ví dụ. Giả sử gas limit là 70 và blob limit là 40. Mempool có nhiều giao dịch, đủ để lấp đầy một khối và có hai loại (tx gas bao gồm per-blob gas):

• Phí ưu tiên 5 mỗi khí, 4 đốm màu, 4 tổng khí

• Phí ưu tiên 3 mỗi gas, 1 blob, 2 tổng gas

Ethereum

Hiện tại, các khách hàng đang thực thi có phải triển khai các thuật toán ba lô đa chiều phức tạp để tối ưu hóa quá trình sản xuất khối của họ không? Không, có một số lý do:

• EIP-1559 đảm bảo rằng hầu hết các khối không đạt đến một trong hai giới hạn, vì vậy chỉ một số lượng nhỏ các khối thực sự gặp phả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 (đủ thanh toán) để đạt đến một trong hai giới hạn, bất kỳ người khai thác nào cũng có thể kiếm tiền tối ưu bằng cách bao gồm mọi giao dịch họ thấy.

• Trong thực tế, các phương pháp phỏng đoán khá đơn giản có thể đạt đến mức tối ưu. Trong tình huống tương tự, hãy xem phân tích của Ansgar về EIP-4488 để biết một số dữ liệu về điều này.

• Định giá đa chiều thậm chí không phải là nguồn doanh thu lớn nhất từ ​​chuyên môn hóa - MEV là vậy. Doanh thu MEV chuyên dụng được trích xuất thông qua các thuật toán chuyên dụng từ chênh lệch giá DEX trên chuỗi, thanh lý, bán NFT chạy trước, v.v. chiếm một phần đáng kể trong tổng "doanh thu có thể trích xuất" (tức là phí ưu tiên): doanh thu MEV chuyên dụng dường như trung bình khoảng 0,025 ETH mỗi khối vùng, tổng phí ưu tiên thường vào khoảng 0,1 ETH mỗi khối.

• Sự phân tách người đề xuất/người xây dựng được thiết kế xung quanh việc sản xuất khối chuyên môn hóa cao. PBS biến quá trình xây dựng khối thành một cuộc đấu giá nơi những người tham gia chuyên nghiệp đấu giá để có được đặc quyền tạo khối. Trình xác nhận thông thường chỉ cần chấp nhận giá thầu cao nhất. Điều này là để ngăn nền kinh tế quy mô do MEV điều khiển len lỏi vào tập trung trình xác thực, nhưng nó xử lý tất cả các vấn đề có thể khiến việc tối ưu hóa việc xây dựng khối trở nên khó khăn hơn.

Vì những lý do này, động lực thị trường phí phức tạp hơn không làm tăng đáng kể mức độ tập trung hoặc rủi ro; trên thực tế, các nguyên tắc được áp dụng rộng rãi hơn thực sự có thể làm giảm nguy cơ tấn công DoS!

Cơ chế điều chỉnh phí blob Exponential EIP-1559 hoạt động như thế nào?

EIP-1559 của ngày hôm nay điều chỉnh phí cơ bản b để đạt được mức sử dụng gas mục tiêu cụ thể t, như sau:

trong đó b(n) là phí cơ sở cho khối hiện tại, b(n+1) là phí cơ bản cho khối tiếp theo, t là mục tiêu và u là gas được sử dụng.

Ethereum

Mặc dù mức sử dụng trung bình bằng t, phí cơ sở giảm 63/64. Vì vậy, phí cơ sở chỉ ổn định nếu mức sử dụng cao hơn t một chút; trong thực tế, nó 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 theo cấp số nhân:

exp(x) là hàm mũ e^x, trong đó e≈2,71828. Khi giá trị của x nhỏ, exp(x)≈1+x. Tuy nhiên, nó có một thuộc tính tiện lợi không liên quan đến hoán vị giao dịch: điều chỉnh nhiều bước

Ethereum

Do đó, các giao dịch giống nhau được bao gồm sẽ dẫn đến cùng một khoản phí cơ bản cuối cùng, bất kể chúng được phân phối như thế nào giữa các khối khác nhau.

Công thức cuối cùng ở trên cũng có một cách giải thích toán học tự nhiên: thuật ngữ (u1+u2+...+u/n-nt) có thể được coi là dư thừa: sự khác biệt giữa tổng lượng khí thực sự được sử dụng và tổng lượng khí dự định sẽ sử dụng.

Phí cơ sở hiện tại bằng

Thực tế là phần vượt quá không thể vượt quá một phạm vi rất hẹp: nếu vượt quá 8t∗60, thì phí cơ sở sẽ trở thành e^60, cao đến mức không ai có thể trả được và nếu nó giảm xuống dưới 0, thì về cơ bản tài nguyên là miễn phí, và chuỗi sẽ bị gửi thư rác cho đến khi phần vượt quá trả về trên 0.

Cơ chế điều chỉnh hoạt động chính xác theo các thuật ngữ này: nó theo dõi tổng số thực tế (u1+u2+...+u/n) và tính toán tổng số mục tiêu (nt), đồng thời tính toán giá dưới dạng chỉ số chênh lệch. Để thực hiện phép tính dễ dàng hơn, thay vì e^x, chúng tôi sử dụng 2^x; trên thực tế, chúng tôi sử dụng xấp xỉ 2^x: hàm fake_exponential trong EIP. Chỉ số sai hầu như luôn nằm trong khoảng 0,3% so với giá trị thực.

Để ngăn chặn việc sử dụng không đúng mức trong thời gian dài gây ra thời gian dài gấp đôi số khối đầy đủ, chúng tôi đã thêm một tính năng bổ sung: chúng tôi không để các khối dư thừa xuống dưới 0. Nếu fact_total thấp hơn target_total, chúng tôi chỉ cần đặt fact_total bằng với target_total. Trong các trường hợp cực đoan (blob gas hoàn toàn giảm xuống 0), điều này sẽ phá vỡ tính bất biến của lệnh giao dịch, nhưng sự an toàn được bổ sung khiến đây là một sự đánh đổi có thể chấp nhận được.

Cũng lưu ý một hệ quả thú vị của thị trường đa chiều này: khi proto-danksharding lần đầu tiên được giới thiệu, ban đầu có thể có rất ít người dùng, do đó, trong một thời gian, chi phí của một đốm màu gần như chắc chắn sẽ rất rẻ, ngay cả đối với "thông thường" Hoạt động chuỗi khối Ethereum vẫn còn đắt đỏ.

Các tác giả tin rằng cơ chế điều chỉnh phí này tốt hơn so với cách tiếp cận hiện tại, vì vậy cuối cùng tất cả các phân khúc của thị trường phí EIP-1559 nên chuyển sang sử dụng nó.

Để có giải thích dài hơn và chi tiết hơn, hãy xem bài đăng của Dankrad.

Fake_exponential hoạt động như thế nào?

Để thuận tiện, đây là mã cho fake_exponential:

def fake_exponential(numerator: int, denominator: int) -> int: cofactor = 2 ** (numerator // denominator) fractional = numerator % denominator return cofactor + ( fractional * cofactor * 2 + (fractional ** 2 * cofactor) // denominator ) // (denominator * 3)

Ethereum

Mục tiêu là ghép nhiều phiên bản của (QX) lại với nhau, một trong số đó được dịch chuyển và chia tỷ lệ thích 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 cho 0≤x≤1, được chọn cho các thuộc tính sau:

• Đơn giản (đó là một phương trình bậc hai)

• Độ chính xác của cạnh trái (Q(0)=2^0=1)

• Độ chính xác của cạnh phải (Q(1)=2^1=2)

• Độ dốc trơn (chúng tôi đảm bảo rằng Q'(1)=2∗Q'(0), do đó, mỗi ca+bản sao được chia tỷ lệ của Q có cùng độ dốc trên cạnh phải của nó giống như bản sao tiếp theo có trên cạnh trái của nó)

Ba phương trình cuối cùng yêu cầu ba phương trình tuyến tính với ba hệ số chưa biết và Q(x) đưa ra ở trên đưa ra giải pháp duy nhất.

Ethereum

Những vấn đề nào vẫn đang được tranh luận trong proto-danksharding?

LƯU Ý: Phần này dễ bị lỗi thời. Đừng tin nó sẽ đưa ra suy nghĩ mới nhất về bất kỳ vấn đề cụ thể nào.

• Tất cả các Bản tổng hợp lạc quan chính đều sử dụng bằng chứng nhiều vòng, vì vậy chúng có thể sử dụng các phần biên dịch trước đánh giá điểm (rẻ hơn nhiều) thay vì các phần biên dịch trước 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 đầu vào là blob D và hàm băm được phiên bản h, chọn x=hash(D,h), tính toán y=D(x) bằng cách sử dụng đánh giá barycentric và dự đoán Biên dịch và xác minh rằng h (x)=y. Vì vậy, chúng ta có thực sự cần biên dịch trước xác thực blob hay chúng ta có thể xóa nó và chỉ sử dụng đánh giá điểm?

• Chuỗi có khả năng xử lý các khối 1 MB+ lâu dài như thế nào? Nếu rủi ro quá lớn, liệu số đốm màu mục tiêu có nên giảm ngay từ đầu không?

• Các đốm màu nên được mệnh giá bằng gas hay ETH (đốt)? Có nên có những điều chỉnh khác cho thị trường phí?

• Loại giao dịch mới có nên được coi là một đốm màu hoặc là một đối tượng SSZ, trong trường hợp sau, hãy thay đổi ExecutPayload thành một loại liên kết? (Đó là sự đánh đổi giữa "làm nhiều việc hơn bây giờ" và "làm nhiều việc hơn sau này")

• Các chi tiết chính xác của việc triển khai thiết lập đáng tin cậy (về mặt kỹ thuật nằm ngoài phạm vi của chính EIP, vì thiết lập như vậy "chỉ là một hằng số" đối với người triển khai, nhưng vẫn cần phải được thực hiện).