Buterin diễn giải EIP-4844 như thế nào, yếu tố có tác động chính đến Lớp 2?

Tiêu đề gốc: " Câu hỏi thường gặp về Proto-Danksharding 》

Tác giả gốc: Vitalik Buterin

Bản tổng hợp gốc: Kyle, Babbitt

Người sáng lập Ethereum Vitalik Buterin gần đây đã đưa ra câu trả lời cho các câu hỏi liên quan đến Proto-danksharding (còn được gọi là EIP-4844). Thiết kế shending mới của Danksharding dành cho Ethereum, chính xác thì công nghệ này có thể mang lại điều gì?

Daksharding là gì?

Danksharding là một thiết kế sharding mới được đề xuất cho Ethereum nhằm 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 chia sẻ 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 chia sẻ không phải Ethereum. Điều này nằm ở lộ trình tập trung vào tổng hợp của Ethereum : Phân mảnh Ethereum không cung cấp nhiều không gian hơn cho các giao dịch mà dành cho dữ liệu, điều mà bản thân giao thức Ethereum không cố gắng giải thích. Việc xác thực một 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 đốm màu này dự kiến sẽ được sử dụng bởi giao thức Rollup Lớp 2 (Layer2) hỗ trợ các giao dịch thông lượng cao.

Sự đổi mới chính được Danksharding giới thiệu là thị trường phí kết hợp: không còn số lượng phân đoạn cố định nữa, mỗi phân đoạn có các khối và khu vực khác nhau. ở Danksharding, chỉ có một người đề xuất chọn tất cả các giao dịch và tất cả dữ liệu được đưa vào vị trí.

Để tránh thiết kế này đặt ra yêu cầu cao đối với người xác nhận. Là yêu cầu hệ thống, chúng tôi đã giới thiệu Người đề xuất /Tách người xây dựng (PBS): một lớp người tham gia đặc biệt được gọi là người xây dựng khối đấu thầu để có quyền chọn một vị trí và người đề xuất chỉ cần chọn tiêu đề hợp lệ với giá thầu cao nhất. Chỉ người xây dựng khối mới cần xử lý toàn bộ khối (ở đây, cũng có thể sử dụng giao thức oracle phi tập trung của bên thứ ba để triển khai các trình tạo khối phân tán và tất cả người dùng và trình xác thực khác có thể lấy mẫu dữ liệu sẵn có rất hiệu quả. Xác thực khối (hãy nhớ). : 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) triển khai hầu hết logic và "giàn giáo" tạo nên đặc tả Danksharding hoàn chỉnh (như định dạng giao dịch, quy tắc xác thực), nhưng chưa có chưa được triển khai Thực hiện bất kỳ sharding 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 dữ liệu hoàn chỉnh.

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 có blob. Giao dịch với các đốm màu tương tự như các giao dịch thông thường, ngoại trừ việc chúng còn mang theo dữ liệu bổ sung được gọi là các đốm màu. Các đốm màu rất lớn (~125 kB) và rẻ hơn nhiều so với lượng dữ liệu cuộc gọi 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ể xem cam kết đối với blob.

Vì người xác thực và khách hàng vẫn cần tải xuống nội dung blob đầy đủ nên mục tiêu băng thông dữ liệu trong proto-danksharding là 1 MB mỗi khe thay vì Hoàn thành 16 MB. Tuy nhiên, vì những số liệu này không cạnh tranh với mức sử dụng gas của các giao dịch Ethereum hiện tại nên vẫn có những lợi ích đáng kể 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 mà mọi người phải tải xuống, thay vì làm cho calldata rẻ hơn gấp 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 ta đang trải qua kích thước khối trung bình khoảng 90 kB, nhưng kích thước khối tối đa có thể theo lý thuyết (nếu tất cả 30M gas trong khối được sử dụng để gọi dữ liệu) là khoảng 1,8 MB. Mạng Ethereum đã xử lý các khối gần mức tối đa trong quá khứ. Tuy nhiên, nếu chúng ta chỉ giảm chi phí gas calldata xuống 10 lần thì trong khi kích thước khối trung bình sẽ tăng đến mức vẫn có thể chấp nhận được, trường hợp xấu nhất sẽ trở thành 18 MB, đơn giản là quá lớn đối với mạng Ethereum. .

Các cơ chế định giá khí đốt 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 việc người dùng sử dụng dữ liệu cuộc gọi và các tài nguyên khác. về lượng gas cần sử dụng có nghĩa là giá gas phải được đặt dựa trên khả năng xảy ra trường hợp xấu nhất, khiến tải trung bình thấp hơn một cách không cần thiết so với tải mà hệ thống có thể xử lý. Tuy nhiên, nếu chúng tôi thay đổi giá gas để tạo ra thị trường phí đa chiều một cách rõ ràng hơn, chúng tôi có thể tránh được tình trạng tải không khớp 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 thực hiện được đ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 vấn đề không khớp tải trường hợp trung bình/trường hợp xấu nhất tương tự. EIP-4488 sử dụng hai quy tắc đơn giản để thực hiện việc này:

Chi phí gas Calldata giảm từ 16 gas mỗi byte xuống còn 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)

A giới hạn cứng là cách đơn giản nhất để đảm bảo rằng mức tăng lớn của tải trong 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. Chi phí gas giảm 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 trong trường hợp xấu nhất là một khối 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 biệt chứa 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 có thể được bao gồm trong mỗi khối. Các đốm màu này không thể truy cập được từ EVM (chỉ có các cam kết đối với blob) và các đốm màu được lưu trữ bởi lớp đồng thuận (chuỗi đèn 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 ngày nay, trong khi proto-danksharding khiến ngày nay có rất nhiều thay đổi nên các nâng cấp trong tương lai lên sharding đầy đủ sẽ yêu cầu một số thay đổi. Mặc dù việc 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 quá trình phân chia sơ bộ, nhưng sự phức tạp này được chứa trong lớp đồng thuận. Sau khi triển khai proto-danksharding, nhóm khách hàng điều hành, nhà phát triển tổng hợp và người dùng sẽ 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 shending hoàn chỉnh.

Xin lưu ý rằng lựa chọn giữa hai lựa chọn này không phải là/hoặc: chúng tôi có thể triển khai EIP-4488 càng sớm càng tốt và sau đó sử dụng proto-danksharding để theo dõi nửa năm sau Tham gia vào nó.

Những phần nào của quá trình danksharding hoàn chỉnh sẽ được triển khai và những phần nào khác cần được triển khai?

Trích dẫn EIP-4844:

Công việc được hoàn thành trong EIP này bao gồm: · Loại giao dịch mới có định dạng tương tự như "full sharding" Có cùng nhu cầu tồn tại trong . ·Tất cả logic lớp thực thi cần thiết để phân chia đầy đủ. · Cần có tất cả logic thực thi/xác thực chéo đồng thuận để phân chia toàn bộ. ·Tách lớp BeaconBlock giữa các đốm màu lấy mẫu xác thực và sẵn có của dữ liệu. ·Hầu hết logic BeaconBlock cần thiết để phân chia hoàn toàn. ·Tự điều chỉnh gasprice độc lập cho các đốm màu. Công việc còn lại để đạt được phân đoạn hoàn chỉnh 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. · Triển khai thực tế việc 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 người xác thực duy nhất xử lý 32 MB dữ liệu trong một khe. Bằng chứng ký quỹ hoặc yêu cầu tương tự trong giao thức đối với 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.

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

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

EIP-4488 và proto-danksharding đều mang lại mức sử dụng tối đa trong thời gian dài khoảng 1 MB mỗi khe cắm (12 giây). Con số này tương đương với khoảng 2,5 terabyte 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 EIP-4488, cần có sơ đồ hết hạn lịch sử (EIP-4444‌) để giải quyết vấn đề này, trong đó khách hàng không còn cần phải lưu trữ nhiều hơn một Lịch sử khoảng thời gian nhất định (thời gian từ 1 tháng đến 1 năm đã được đề xuất).

Trong trường hợp proto-danksharding, bất kể EIP-4444 có được triển khai hay không, lớp đồng thuận có thể triển khai logic riêng để Tự động xóa dữ liệu blob. Tuy nhiên, bất kể giải pháp mở rộng dữ liệu ngắn hạn là gì, chúng tôi đặc biệt khuyên bạn nên triển khai EIP-4444 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 ở mức tối đa vài trăm GB. Về lâu dài, việc áp dụng một số cơ chế hết hạn lịch sử về cơ bản là bắt buộc: việc phân chia toàn bộ sẽ bổ sung thêm 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 nhỏ 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.

Nếu dữ liệu bị xóa sau 30 ngày, người dùng sẽ truy cập vào các đốm màu 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 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ó độ an toàn cao và chừa chỗ cho các giao thức phi tập trung khác thực hiện lưu trữ lâu dài hơn. Bảng thông báo tồn tại để đảm bảo rằng dữ liệu được đăng trên bảng thông báo 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 lâu dài nào để sao lưu dữ liệu đều có đủ thời gian để lấy dữ liệu và nhập dữ liệu vào máy tính bảng khác của họ. ứng dụng hoặc giao thức.

Nói chung, việc 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à quá nhiều để yêu cầu 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, điều này hoàn toàn phù hợp với những người có sở thích. Không giống như sự đồng thuận, có mô hình tin cậy N/2-of-N, lưu trữ lịch sử có mô hình tin cậy 1-of-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 hoàn chỉnh đ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ử của bạn và làm cho nó có thể truy cập dễ dàng bao gồm:

Cụ thể Các giao thức dành riêng cho ứng dụng (chẳng hạn như Rollup) có thể yêu cầu các nút lưu trữ các phần lịch sử có 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 mà chỉ gây rủi ro cho ứng dụng riêng lẻ, do đó, việc ứng dụng chịu gánh nặng lưu trữ dữ liệu liên quan đến chính nó là điều hợp lý.

Ví dụ: Lưu trữ dữ liệu lịch sử trong BitTorrent. Tệp 7 GB chứa dữ liệu blob từ các khối được tạo và phân phối tự động mỗi 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 cá nhân có sở thích và học giả tham gia phân tích dữ liệu có thể lưu trữ các hồ sơ lịch sử đầy đủ. Trong trường hợp sau, việc lưu trữ lịch sử cục bộ mang lại cho chúng giá trị đáng kể vì nó giúp việc tính toán trực tiếp 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ẽ trở nên cao hơn (ngoài ra, hệ thống xác minh tính sẵn có của dữ liệu sẽ trở nên căng thẳng hơn). Đây có thể là giới hạn thực sự về 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 rất xa so với điều này.

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

Một blob là một vectơ chứa 4096 phần tử trường, các số trong phạm vi:

Blob nằm trong Về mặt toán học được coi là biểu diễn đ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 ở vị trí i trong blob là đánh giá của đa thức tại wi. w là một hằng số sao cho w=1.

Cam kết đối với blob là cam kết KZG đối với hàm băm của đa thức đó. Tuy nhiên, từ góc độ triển khai, việc tập trung vào 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 (cài đặt tin cậy dựa trên Lagrange) và cam kết của KZG đối với blob sẽ chỉ là một sự kết hợp tuyến tính. Trích dẫn code của EIP-4844:

BLS_MODULUS là như trên modulus và KZG_SETUP_LAGRANGE là vectơ của các điểm đường cong elip, là cài đặt đáng tin cậy dựa trên Lagrangian. Hiện tại, thật hợp lý khi những người triển khai coi đây đơn giản như một hàm băm chuyên dụng cho hộp đen.

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

EIP-4844 không sử dụng KZG để biểu diễn trực tiếp blob mà sử dụng hàm băm được phiên bản: một byte 0x01 (đại diện cho phiên bản này) theo sau là hàm băm SHA256 của KZG 31 byte cuối cùng.

Điều này được thực hiện để đảm bảo khả năng tương thích EVM và khả năng tương thích trong tương lai: cam kết KZG là 48 byte và EVM sử dụng giá trị 32 byte một cách tự nhiên hơn nếu chúng ta bắt đầu với KZG chuyển sang thứ gì khác (ví dụ: vì lý do kháng lượng tử) và cam kết KZG có thể tiếp tục là 32 byte.

Hai phần biên dịch trước đượ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á điểm.

Việc biên dịch trước xác thực Blob là dễ hiểu: nó lấy một hàm băm có phiên bản và một Blob làm đầu vào, đồ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à một hàm băm có phiên bản Blob hợp lệ . Quá trình biên dịch trước này nhằm mục đích sử dụng bởi Optimistic Rollup. Trích dẫn EIP-4844:

Optimistic Rollup chỉ yêu cầu dữ liệu cơ bản phải được cung cấp thực tế 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 phải gửi toàn bộ nội dung của đốm màu gian lận như một phần của dữ liệu cuộc gọi. Nó sẽ sử dụng chức năng xác thực blob để xác thực dữ liệu dựa trên hàm băm được phiên bản đã 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.

Quá trình 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 biểu thị bằng một blob với hàm băm được phiên bản nhất định. Quá trình biên dịch trước này được thiết kế để ZK Rollup sử dụng. Trích dẫn EIP-4844:

Bản tổng hợp ZK sẽ cung cấp hai lời hứa cho dữ liệu giao dịch hoặc trạng thái delta của nó: KZG trong blob và bất kỳ việc sử dụng nội bộ nào của bản tổng hợp ZK Thể hiện một số lời hứa của hệ thống. Họ sẽ sử dụng bằng chứng 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 được đảm bảo trỏ đến dữ liệu có sẵn) và các cam kết riêng của bản tổng hợp ZK đề 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 hợp lạc quan chính đều sử dụng nhiều vòng kế hoạch ngăn chặn gian lận, trong đó vòng cuối cùng chỉ yêu cầu một lượng nhỏ dữ liệu. Do đó, có thể hình dung rằng Optimistic Rollup cũng có thể sử dụng tính năng biên dịch trước được đánh giá theo điểm thay vì biên dịch trước được xác minh bằng 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?

Xem:

https://vitalik.ca/general/2022/03/ 14/trustedsetup.html 

Mô tả chung về cách thức hoạt động của thiết lập tin cậy power-of-tau

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

Tất cả các cài đặt đáng tin cậy quan trọng có liên quan Ví dụ triển khai phép tính

Cụ thể trong trường hợp của chúng tôi, kế hoạch hiện tại là chạy bốn kích cỡ (n1=4096, n2=16), (n1 =8192,n2=16) , (n1=16834,n2=16) và (n1=32768,n2=16) nghi lễ (với những bí mật khác nhau). Về lý thuyết, chỉ cần cái đầu tiên, nhưng việc chạy nhiều 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 blob. Chúng tôi không thể có cài đặt lớn hơn vì chúng tôi muốn có giới hạn cứng về mức độ đa thức có thể được gửi một cách hiệu quả, giới hạn bằng kích thước blob.

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

Chúng ta 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 sao?

Thật không may, việc sử dụng bất kỳ thứ gì ngoài KZG (chẳng hạn như IPA hoặc SHA256) khiến lộ trình sharding trở nên khó khăn hơn nhiều. Có một số lý do giải thích cho điều này:

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 việc 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, khi chúng ta chuyển sang Khi đã phân mảnh hoàn toàn, chúng ta vẫn phải đổi sang KZG.

IPA có thể tương thích với việc lấy mẫu tính khả dụng của dữ liệu, nhưng nó 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ụ: các biến xây dựng khối phân tán và tự phục hồi. khó khăn)

Cả băm lẫn IPA đều không tương thích với việc triển khai đánh giá điểm biên dịch trước một cách rẻ tiền. 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 ZK Rollup một cách hiệu quả hoặc hỗ trợ các bằng chứng gian lận rẻ tiền 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à sự phức tạp gia tăng khi sử dụng bất kỳ thứ gì khác ngoài KZG lớn hơn nhiều so với 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 dựa 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” 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 loại PLONK kể từ năm 2019. Tuy nhiên, toán học cơ bản mà KZG hứa hẹn là một phép tính số học tương đối đơn giản dựa trên toán học cơ bản của các phép tính và ghép cặp đường cong elip.

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

Từ góc độ độ phức tạp khi triển khai, KZG không khó triển khai hơn IPA: hàm tính toán lời hứa (xem ở trên) hoàn toàn giống như trong IPA , Chỉ cần sử dụng một tập hợp các hằng số điểm đường cong elip khác nhau. Quá trình 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á theo cặp, nhưng phép toán giống như những gì đã được thực hiện trong quá trình triển khai EIP-2537 (biên dịch trước BLS12-381) và rất giống với quá trình biên dịch trước theo cặp bn128 (xem thêm: Python được tối ưu hóa hoàn thành). Vì vậy, việc triển khai xác minh KZG không yêu cầu "công việc mới" phức tạp

Các phần mềm khác nhau được triển khai bởi proto-danksharding là gì?

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

1. Những thay đổi trong sự đồng thuận của lớp thực thi (chi tiết) Xem EIP):

Loại giao dịch mới chứa blob

Xuất số thứ i trong Giao dịch hiện tại Opcode cho băm được phiên bản blob

Biên dịch trước xác minh blob

Biên dịch trước đánh giá điểm

Biên dịch trước đánh giá điểm

p>

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

Danh sách Blob KZG trong BeaconBlockBody

Cơ chế "sidecar" trong đó nội dung blob hoàn chỉnh đượ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à blob KZG trong lớp đồng thuận

3. p>

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

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

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

Chấp nhận dữ liệu từ vùng bộ nhớ Trình bao bọc giao dịch, đặt giao dịch vào ExecutionPayload, đưa KZG vào khối beacon và chủ đề trong sidecar

Đối phó với thị trường phí xử lý hai chiều

Lưu ý rằng để triển khai ở mức 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 các khối Xây dựng logic. Chỉ những thay đổi đồng thuận ở 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 việc triển khai tối thiểu như vậy và triển khai "đầy đủ" với tất cả các máy khách hỗ trợ sản xuất khối và bộ nhớ đều có thể thực hiện được.

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 nguồn tài nguyên là gas và blob, với giá gas thả nổi và giới hạn riêng biệt.

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ượng gas có thể thay đổi sẽ điều chỉnh sao cho về lâu dài số lượng blob trung bình trên mỗi khối thực sự bằng với số 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 chúng hết giao dịch hoặc bị tấn công. giới hạn gas khối, họ sẽ phải tránh chạm vào hai giới hạn khác nhau cùng một lúc.

Đây là một ví dụ. Giả sử giới hạn khí là 70 và giới hạn blob 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 gas, 4 blobs , tổng 4 gas

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

Một người khai thác tuân 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 thuộc loại đầu tiên (40 gas) và nhận được doanh thu 5 * 40 = 200 gas. Vì 10 giao dịch này đã lấp đầy giới hạn của blob nên chúng sẽ không thể bao gồm thêm giao dịch nữa. Nhưng chiến lược tối ưu là thực hiện 3 giao dịch thuộc loại thứ nhất và 28 giao dịch thuộc loại thứ hai. Điều này mang lại cho bạn một khối gồm 40 đốm màu và 68 khí và thu nhập là 5 * 12 + 3 * 56 = 228.

Liệu máy khách đang thực thi có phải là bây giờ Phải thực hiện các thuật toán giải bài toán ba lô đa chiều phức tạp để tối ưu hóa việc sản xuất khối của họ? Không, vì một số 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 đó chỉ một số khối thực sự 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 (đủ 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 được thu nhập tốt nhất bằng cách bao gồm mọi giao dịch mà họ thấy.

Trong thực tế, những phương pháp phỏng đoán khá đơn giản có thể đạt đến mức tối ưu. Trong bối cảnh 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ề vấn đề này.

Định giá đa chiều thậm chí không phải là nguồn doanh thu lớn nhất từ việc chuyên môn hóa - MEV thì có. Doanh thu MEV chuyên dụng được trích từ hoạt động chênh lệch giá DEX trên chuỗi, thanh lý, bán NFT chạy trước, v.v. thông qua các thuật toán chuyên dụng chiếm một phần lớn trong tổng "doanh thu có thể rú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 cho mỗi khối vùng, tổng phí ưu tiên thường vào khoảng 0,1 ETH cho mỗi khối.

Sự phân chia của người đề xuất/người xây dựng‌ được thiết kế xoay quanh việc sản xuất khối có tính chuyên môn 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 có thể đấu giá để có được đặc quyền tạo khối. Người 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 nhằm ngăn chặn tính kinh tế theo quy mô do MEV thúc đẩy xâm nhập vào việc 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ể 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 Rủi ro tấn công DoS!

Cơ chế điều chỉnh phí blob EIP-1559 theo cấp số nhân hoạt động như thế nào?

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

Trong đó b(n) là phí cơ bản của 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.

Vấn đề lớn với cơ chế này là nó không thực sự nhắm tới t. Giả sử chúng ta có hai khối, khối đầu tiên u=0 và khối tiếp theo u=2t. Chúng tôi nhận được:

Mặc dù Mức sử dụng trung bình bằng t, nhưng phí cơ bản giảm 63/64. Vì vậy, phí cơ sở sẽ chỉ ổn định nếu mức sử dụng cao hơn t một chút; trên thực tế, nó có vẻ 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 đó e2.71828. Đối với các giá trị nhỏ của x, exp(x)1+x. Tuy nhiên, nó có một tính năng tiện lợi độc lập với việc thay thế giao dịch: điều chỉnh nhiều bước

Chỉ phụ thuộc vào tổng u1+... + u/n, không phụ thuộc vào phân phối. Để biết lý do tại sao, chúng ta có thể làm phép toán:

Do đó, các giao dịch được bao gồm giống nhau 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 bổ như thế nào trên các khối khác nhau.

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

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

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

Cơ chế điều chỉnh hoạt động chính xác theo các điều khoản sau: nó theo dõi tổng thực tế (u1+u2+...+u/n) và tính toán tổng mục tiêu (nt ) và Tính giá dưới dạng chỉ số chênh lệch. Để phép tính đơn giản hơn, thay vì sử dụng 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. Số mũ sai hầu như luôn nằm trong khoảng 0,3% giá trị thực.

Để ngăn chặn tình trạng sử dụng không đúng mức trong thời gian dài dẫn đến khối đầy đủ gấp 2 lần trong thời gian dài, chúng tôi đã thêm một tính năng bổ sung: chúng tôi sẽ không để các khu vực thừa bị chặn dưới 0. Nếu tổng_tổng thực tế thấp hơn tổng_tổng mục tiêu, chúng tôi chỉ cần đặt tổng_tổng thực tế bằng tổng_tổng mục tiêu. Trong những trường hợp cực đoan (khí blob giảm xuống bằng 0), điều này sẽ phá vỡ tính bất biến của lệnh giao dịch, nhưng tính bảo mật 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 được giới thiệu lần đầu tiên, ban đầu có thể sẽ có rất ít người dùng, vì vậy trong một khoảng thời gian, chi phí của một blob gần như chắc chắn sẽ rất rẻ, ngay cả đối với "thông thường" Hoạt động của 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 phương pháp hiện tại nên cuối cùng tất cả các bộ phận của thị trường phí EIP-1559 sẽ chuyển sang sử dụng nó.

Để có lời 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:

Đây là cơ chế cốt lõi được biểu diễn lại bằng toán học, trừ việc làm tròn:

Mục tiêu là ghép nhiều phiên bản của (QX lại với nhau), mỗi phiên bản cho mỗi [2^k,2^( k+ 1)] được dịch chuyển và mở rộng một cách thích hợp. Bản thân Q(x) là một xấp xỉ từ 2^x đến 0x1, được chọn cho các thuộc tính sau:

- Tính đơn giản (nó là phương trình bậc hai)

p>

- Độ 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 tru (chúng tôi đảm bảo Q』(1)=2Q』( 0), do đó, mỗi bản sao được dịch chuyển+tỷ lệ của Q có cùng độ dốc ở cạnh phải với bản sao tiếp theo ở cạnh trái của nó)

Ba phương trình tuyến tính cuối cùng cần có ba hệ số chưa biết Q(x) nêu trên là nghiệm duy nhất.

Kết quả gần đúng tốt đến mức đáng ngạc nhiên; đối với tất cả ngoại trừ dữ liệu đầu vào nhỏ nhất, fake_exponential đưa ra câu trả lời trong phạm vi 0,3% của 2^x giá trị thực:

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

Lưu ý: Phần này có thể dễ dàng trở nên lỗi thời. Đừng tin tưởng nó sẽ đưa ra những suy nghĩ cập nhật 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 tính năng biên dịch trước đánh giá điểm (rẻ hơn nhiều) thay vì biên dịch trước xác minh blob. Bất kỳ ai thực sự cần xác thực blob đều có thể tự thực hiện: lấy đầu vào là blob D và hàm băm h được phiên bản, chọn x=hash(D,h), sử dụng đánh giá centroid ‌ tính toán y=D(x) và sử dụng đánh giá điểm Pre- quá trình biên dịch 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ể loại bỏ nó và chỉ sử dụng đánh giá điểm?

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

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

Loại giao dịch mới nên được coi là đối tượng blob hay SSZ, trong trường hợp sau, việc thay đổi ExecutionPayload thành loại kết hợp? (Đây là sự cân bằng giữa "làm thêm bây giờ" và "làm thêm sau")

Chi tiết chính xác về 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 EIP chính nó, vì cài đặt nà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).

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

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