Mục đích của giao thức đồng thuận Ethereum không phải để đả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 bảo mật cao và để lại chỗ cho các giao thức phi tập trung khác để lưu trữ lâu dài hơn.
Người sáng lập Ethereum, Vitalik Buterin gần đây đã trả lời một câu hỏi liên quan đến Proto-danksharding (hay còn gọi là EIP-4844). Thiết kế sharding mới của Danksharding cho Ethereum, chính xác thì công nghệ này có thể mang lại những 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ự đổi mới chính được Danksharding giới thiệu là thị trường phí hợp nhất: không còn số lượng phân đoạn cố định nữa, 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ỉ có một người đề xuất chọn để vào khe tất cả các giao dịch và tất cả dữ liệu.
Để tránh thiết kế này đặt ra các yêu cầu hệ thống cao đối với trình xác thực, chúng tôi giới thiệu phân tách người đề xuất / người xây dựng (PBS): một nhóm người tham gia đặc biệt được gọi là người xây dựng khối đặt giá thầu cho quyền chọn vị trí và người đề xuất chỉ cần chọn giá thầu hợp lệ cao nhất tiêu đề là đủ. Chỉ trình tạo khối mới cần xử lý toàn bộ khối (ở đây, giao thức oracle phân quyền 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ả các trình xác thực và người dùng khác có thể được lấy mẫu rất hiệu quả bởi tính khả dụng của dữ liệu Xác thực khối (hãy nhớ: phần "lớn" của khối chỉ là dữ liệu).
Proto-danksharding (hay còn gọi là EIP-4844) là gì?
Proto-danksharding (hay 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 các logic “scaffolding” (ví dụ: định dạng giao dịch, quy tắc xác thực) tạo nên thông số kỹ thuật Danksharding đầy đủ, nhưng vẫn chưa thực sự triển khai bất kỳ mảnh nào của mạng lưới. Trong 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 proto-danksharding giới thiệu là một loại giao dịch mới, 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 thêm dữ liệu được gọi là blob. Blobs 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 vào dữ liệu blob; EVM chỉ có thể xem các thoả thuận 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 cho mỗi vị trí 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 tại, nên vẫn có nhiều khoảng trống 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 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 xuống trung bình và tải xuống trong trường hợp xấu nhất. Hôm nay, chúng ta đã 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 theo lý thuyết (nếu tất cả 30M gas trong khối được sử dụng cho dữ liệu cuộc gọi) là khoảng 1,8 MB. Mạng Ethereum đã xử lý các khối gần với mức tối đa trong quá khứ. Tuy nhiên, nếu chúng ta chỉ đơn giản là giảm chi phí gas calldata xuống hệ số 10, thì trong khi 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 trong trường hợp xấu nhất là 18 MB, sẽ gây quá tải xuống đối với mạng Ethereum.
Các trình xác đinh 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 xuống trung bình và tải xuống trong trường hợp xấu nhất phụ thuộc vào sự 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 Khả năng xảy ra trong trường hợp xấu nhất của cài đặt, khiến tải xuống trung bình thấp hơn một cách không cần thiết mà hệ thống có thể xử lý. 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 rõ ràng hơn, chúng tôi có thể tránh được sự không khớp phụ tải xuống trong trường hợp trung bình / trường hợp xấu nhất và bao gồm dữ liệu trong 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 đ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 sự không khớp giữa tải xuống 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 cách sử dụng hai quy tắc đơn giản:
- Chi phí gas Calldata giảm từ 16 gas / byte xuống 3 gas / byte
- Giới hạn 1 MB cho mỗi khối cộng thêm 300byte 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ễ nhất để đảm bảo rằng sự gia tăng lớn trong tải xuống trường hợp trung bình không dẫn đến việc tăng tải xuống 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 cuộn giấy, 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ẽ ngăn chặn trực tiếp khả năng xấu nhất của 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 biệt có thể chứa dữ liệu rẻ hơn trong các blob lớn có kích thước cố định và giới hạn số lượng blob mà mỗi khối có thể chứa. Các blob này không thể truy cập được từ EVM (chỉ cam kết với các blob) và các blob được lưu trữ bởi lớp đồng thuận (chuỗi báo hiệu) 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 giảm thiểu những thay đổi cần thiết ngày nay, trong khi proto-danksharding có rất nhiều thay đổi hiện nay, do đó, các bản nâng cấp trong tương lai lên toàn bộ sharding yêu cầu rất ít thay đổi. Mặc dù việc triển khai sharding đầy đủ (sử dụng lấy mẫu tính sẵn có 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, sự phức tạp này được chứa trong lớp đồng thuận. Sau khi proto-danksharding ra mắt, nhóm khách hàng của lớp thực thi, nhà phát triển cuộn lên và người dùng không cần phải làm thêm công việc để hoàn thành quá trình chuyển đổi sang sharding đầy đủ.
Lưu ý rằng sự lựa chọn giữa cả hai đều không phải là: chúng tôi có thể triển khai EIP-4488 càng sớm càng tốt và sau đó nửa năm sau sẽ theo dõi nó với proto-danksharding.
Proto-danksharding triển khai những phần nào của danksharding đầy đủ và những gì khác cần được triển khai?
Trích dẫn EIP-4844:
Công việc đã được thực hiện trong EIP này bao gồm: • Một loại giao dịch mới với cùng một định dạng cần tồn tại trong "phân đoạn đầy đủ". Tất cả logic của lớp thực thi được yêu cầu để có đủ độ sắc nét. Tất cả logic xác thực chéo thực thi / đồng thuận cần thiết cho quá trình phân bổ đầy đủ. · Phân tách lớp giữa xác thực BeaconBlock và các blob lấy mẫu dữ liệu sẵn có. · Hầu hết logic BeaconBlock cần thiết cho việc phân tích đầy đủ. · Gasprice độc lập tự điều chỉnh cho các blob. Công việc vẫn phải thực hiện để đạt được độ sắc nét đầy đủ bao gồm:
- Tỷ lệ 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ế lấy mẫu tính khả dụng của dữ liệu, PBS (Phân 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ị trí.
- Bằng chứng về Ký quỹ hoặc yêu cầu giao thức nội bộ tương tự đối với mỗi trình xác thực để xác minh một phần cụ thể của dữ liệu được 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à 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 của nhóm khách hàng, người dùng hoặc nhà phát triển tổng hợp.
Đ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 ?
Cả EIP-4488 và proto-danksharding đều dẫn đến việc sử dụng tối đa trong thời gian dài khoảng 1 MB trên mỗi ổ cắm (12 giây). Con số 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 kế hoạch hết hạn lịch sử (EIP-4444) trong đó khách hàng không còn phải lưu trữ lịch sử sau một 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, có hoặc không triển khai EIP-4444, 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, việc triển khai EIP-4444 càng sớm càng tốt được khuyến khích mạnh mẽ bất kể giải pháp mở rộng dữ liệu ngắn hạn là gì.
Cả hai chiến lược đều giới hạn tải xuống thêm đĩa của ứng dụng khách đồng thuận ở mức tối đa là vài trăm GB. Về lâu dài, việc có một số cơ chế hết hạn lịch sử vốn dĩ là bắt buộc: một phân đoạn đầy đủ thêm khoảng 40 TB dữ liệu blob lịch sử mỗi năm, vì vậy người dùng chỉ có thể thực sự lưu trữ một phần nhỏ trong số đó trong một thời gian. Vì vậy, bạn nên đặt kỳ vọng sớm cho điều này.
Người dùng sẽ truy cập các blob 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 để đả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 bảo mật cao và để lại chỗ cho các giao thức phi tập trung khác để 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 để tìm nạp dữ liệu và nhập dữ liệu đó vào người khác của họ trong ứng dụng hoặc giao thức.
Nhìn chung, việc lưu trữ lịch sử dài hạn rất dễ dàng. Mặc dù 2,5 TB mỗi năm là quá nhiều yêu cầu đố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 đô la mỗi TB, quá đủ cho một người sử dụng. Không giống như sự đồng thuận có mô hình tin cậy N / 2 / 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 các kho dữ liệu là 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 thực hiện xác minh đồng thuận theo thời gian thực.
Một số cách hữu ích để lưu trữ toàn bộ lịch sử và giúp bạn dễ dàng truy cập bao gồm:
- 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 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ỉ đối với một ứng dụng duy nhất, do đó, việc ứng dụng gánh vác gánh nặng lưu trữ dữ liệu liên quan đến chính nó là điều hoàn toàn hợp lý.
- Lưu trữ dữ liệu lịch sử trong BitTorrent, ví dụ: Tệp 7 GB chứa dữ liệu khối từ các khối được tạo và phân phối tự động hàng ngày.
- Mạng cổng thông tin Ethereum (hiện đang được phát triển) có thể dễ dàng được 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à học giả tham gia vào 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, lưu trữ cục bộ lịch sử cung cấp cho chúng một 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 trở nên 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ự về khả năng mở rộng cho các blockchains được chia nhỏ. Tuy nhiên, tất cả các thông số đề xuất hiện tại đều ở rất xa so với thời đ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 blob là một vectơ gồm 4096 phần tử trường, các số trong phạm vi:
0 <= x <52435875175126190479447740508185965837690552500527637822603658699938581184513
Về mặt toán học, một blob được coi là đại diện cho đ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à hằng số thỏa mãn w = 1.
Cam kết với blob là cam kết KZG đối với một hash của đa thức đó. Tuy nhiên, từ quan điểm thực hiện, 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ơ gồm các điểm của đường cong elliptic (dựa trên thiết lập hợp lý của Lagrangian) và cam kết của KZG đối với blob sẽ chỉ là một tổ hợp tuyến tính. Mã trích dẫn EIP-4844:
def blob_to_kzg (blob: Vector [BLSFieldElement, 4096]) -> KZGCommitment: computed_kzg = bls.Z1 cho giá trị, point_kzg trong zip (tx.blob, KZG_SETUP_LAGRANGE): xác nhận giá trị <BLS_MODULUS computed_kzgulti (point_kzg, value)) trả về computed_kzg
BLS_MODULUS là mô-đun ở trên và KZG_SETUP_LAGRANGE là vectơ của các điểm đường cong elliptic, là cài đặt tin cậy dựa trên Lagrangian. Đối với những người triển khai, bây giờ hợp lý khi nghĩ về nó đơn giản là một hàm hash chuyên dụng trong hộp đen.
Tại sao sử dụng hàm hash của KZG thay vì KZG trực tiếp?
Thay vì sử dụng KZG để đại diện trực tiếp cho blob, EIP-4844 sử dụng hàm hash được tạo phiên bản: một byte 0x01 (đại diện cho phiên bản này) theo sau là 31 byte cuối cùng của hash SHA256 của KZG.
Điều này được thực hiện để tương thích EVM và tương thích trong tương lai: KZG hứa hẹn là 48 byte, trong khi EVM sử dụng các giá trị 32 byte một cách tự nhiên hơn, nếu chúng ta chuyển từ KZG sang thứ khác (ví dụ: vì lý do kháng lượng tử), KZG hứa hẹn có thể tiếp tục là 32 byte.
Hai 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 .
Quá trình biên dịch trước xác thực của Blob là tự giải thích: nó lấy một mã hash được tạo phiên bản và một blob làm đầu vào và xác minh rằng mã hash được tạo phiên bản được cung cấp thực sự là một mã hash được tạo phiên bản hợp lệ của blob. Bản biên dịch trước này được thiết kế để
Optimistic Rollup sử dụng. Trích dẫn EIP-4844:
Optimistic Rollup 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 toàn bộ nội dung của blob gian lận được gửi như một phần của calldata. Nó sẽ sử dụng xác minh blob để xác minh dữ liệu so với các hàm hash phiên bản đã gửi trước đó và sau đó thực hiện xác minh 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à một hàm hash được tạo phiên bản, một tọa độ x, một tọa độ y và một 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 rằng P (x) = y, trong đó P là đa thức được đại diện bởi blob với hàm hash được phiên bản đã cho. Bản biên dịch trước này dành cho ZK Rollup sử dụng.
Trích dẫn EIP-4844:
Một bản tổng hợp ZK sẽ có hai cam kết cho dữ liệu giao dịch hoặc trạng thái đồng bằng của nó: KZG trong khối và một số lời hứa sử dụng bất kỳ hệ thống bằng chứng nào mà bản tổng hợp ZK sử dụng trong nội bộ. Họ sẽ sử dụng bằng chứng về lời hứa của giao thức tương đương, được biên dịch trước bằng cách sử dụng đá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à lời hứa 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 hợp Lạc quan chính sử dụng các kế hoạch ngăn chặn gian lận nhiều vòng, trong đó chỉ cần một lượng nhỏ dữ liệu cho vòng cuối cùng. Vì vậy, có thể hình dung rằng Optimistic Rollup cũng có thể sử dụng biên dịch trước đánh giá điểm thay vì biên dịch trước xác minh blob và làm như vậy sẽ rẻ hơn.
Thiết lập đáng tin cậy KZG trông như thế nào?
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. Về lý thuyết, chỉ cái đầu tiên là cần thiết, nhưng chạy nhiều kích thước lớn hơn sẽ tăng 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ể chỉ có một cài đặt lớn hơn, bởi vì chúng tôi muốn có thể có một giới hạn cứng về mức độ đ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 và sau đó chạy một nghi thức để mở rộng nó. 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 ta không thể sử dụng một số chương trình hứa hẹn 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) làm cho lộ trình sharding 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 hash) không tương thích với lấy mẫu tính sẵn có của dữ liệu, vì vậy nếu chúng tôi sử dụng sơ đồ như vậy, khi chuyển sang phân bổ hoàn toàn, chúng tôi sẽ phải thay đổi thành KZG.
IPA có thể tương thích với lấy mẫu tính sẵn có của dữ liệu, nhưng nó dẫn đến các kế hoạch 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ó khăn hơn)
Cả hàm hash và IPA đều không tương thích với các triển khai giá rẻ được biên dịch trước được đánh giá bằng điểm. Do đó, việc triển khai dựa trên hash hoặc IPA sẽ không thể kích hoạt Hiệu quả ZK Rollups hoặc hỗ trợ bằng chứng gian lận giá rẻ trong các Bản Rollups Optimistic nhiều vòng.
Vì vậy, thật không may, việc mất chức năng và tăng thêm độ phức tạp khi sử dụng bất kỳ thứ gì khác ngoài KZG còn 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 phụ thuộc vào dữ liệu blob, 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 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 dựa trên phép toán cơ bản của các phép toán và ghép nối đường cong elliptic.
Đườ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 là cần thiết để xác minh các cam kết KZG và là một phép toán 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 cho 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ừ quan điểm về độ phức tạp khi triển khai, KZG không khó triển khai hơn IPA: chức năng tính toán các cam kết (xem ở trên) giống hệt như đối với IPA, chỉ sử dụng một tập hợp các hằng số điểm đường cong elliptic khác. Biên dịch trước xác thực điểm phức tạp hơn vì nó liên quan đến đánh giá từng cặp, nhưng phép toán 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 ghép nối bn128 (xem thêm: Tối ưu hóa Python đạt được). Do đó, không cần "công việc mới" phức tạp nào để thực hiện xác minh KZG
Các phần 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:
- Sự đồng thuận của lớp thực thi đã thay đổi (xem EIP để biết thêm chi tiết):
- Loại giao dịch mới với các blob
- Xuất mã opcode của mã hash được tạo phiên bản của khối thứ i trong giao dịch hiện tại
- Xác thực Blob được biên dịch trước
- biên dịch trước đánh giá điểm
- Các thay đổi về sự đồng thuận của lớp đồng thuận (xem thư mục này trong repo):
- Danh sách các blob KZG trong BeaconBlockBody
- cơ chế "sidecar" trong đó nội dung blob đầy đủ được chuyể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 hash được tạo phiên bản blob trong lớp thực thi và blob KZG trong lớp đồng thuận
- Nhóm bộ nhớ
- 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
- 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 ExecutionPayload, đặt KZG vào khối beacon và phần thân chính trong sidecar
- Đáp ứng thị trường phí hai chiều
Lưu ý rằng đối với việc triển khai nhỏ nhất, chúng ta không cần mempool (chúng ta có thể dựa vào thị trường đóng gói giao dịch lớp thứ hai), chúng ta chỉ cần một ứng dụng khách để triển khai logic xây dựng khối. Chỉ những thay đổi đồng thuận ở các lớp thực thi và đồng thuận mới yêu cầu thử nghiệm đồng thuận rộng rãi và tương đối nhẹ. Bất cứ điều gì đều có thể xảy ra giữa triển khai tối thiểu như vậy và triển khai "đầy đủ" trong đó tất cả các khách hàng đều hỗ trợ sản xuất khối và mempools.
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í đa chiều EIP-1559 với hai nguồn 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.
Đó là, có hai biến và bốn hằng số:
Phí blob được tính bằng gas, nhưng nó là một lượng gas có thể thay đổi được điều chỉnh để về lâu dài, số lượng blob trung bình trên mỗi khối thực tế bằng số lượng mục tiêu.
Bản chất hai chiều có nghĩa là các nhà 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 giao dịch với mức phí ưu tiên cao nhất cho đến khi họ hết giao dịch hoặc đạt đến giới hạn gas khối, họ sẽ phải tránh chạm vào cả hai hạn chế khác nhau.
Đây là một ví dụ. Giả sử giới hạn gas là 70 và giới hạn blob là 40. Mempool có nhiều giao dịch, đủ để lấp đầy các khối và có hai loại (tx gas bao gồm per-blob gas):
- Phí ưu tiên 5 cho mỗi gas, 4 blob, 4 tổng số gas
- Phí ưu tiên 3 cho mỗi gas, 1 blob, 2 tổng số gas
Một người khai thác theo thuật toán "phí ưu tiên thấp hơn" ngây thơ sẽ lấp đầy toàn bộ khối với 10 giao dịch thuộc loại đầu tiên (40 gas) và kiếm được 5 * 40 = 200 gas. Bởi vì 10 giao dịch này lấp đầy giới hạn đầy đủ của blob, chúng sẽ không thể chứa thêm giao dịch. Nhưng chiến lược tối ưu là thực hiện 3 giao dịch thuộc loại đầu tiên 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 blob và 68 gas, và doanh thu là 5 * 12 + 3 * 56 = 228.
Các khách hàng đang thực thi hiện có phải triển khai các thuật toán vấn đề phức tạp đa chiều để 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, do đó, chỉ một số khối thực sự phải đối mặt với các vấn đề tối ưu hóa đa chiều. Trong trường hợp thông thường khi mempool không có đủ (đủ thanh toán) giao dịch để đạt đến một trong hai giới hạn, bất kỳ người khai thác nào cũng có thể nhận đượ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ế, các phương pháp heuristics khá đơn giản có thể gần đến mức tối ưu. Trong tình huống tương tự, hãy xem phân tích EIP-4488 của Ansgar để 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à như vậy. Doanh thu MEV chuyên dụng được trích từ chênh lệch giá DEX trên chuỗi, thanh lý, bán NFT trước, v.v. thông qua các thuật toán chuyên dụng chiếm một phần đáng kể trong tổng "doanh thu có thể truy xuất" (tức là phí ưu tiên): Doanh thu MEV chuyên dụng có vẻ trung bình khoảng 0,025 ETH mỗi khối khối, tổng phí ưu tiên thường là khoảng 0,1 ETH cho mỗi khối.
Phân tách Proposer / Builder được thiết kế xoay quanh quá trình sản xuất khối chuyên biệt 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ể đặt giá thầu để 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 là để ngăn lợi thế kinh tế theo quy mô do MEV lây lan sang tập trung vào trình xác nhận, nhưng nó sẽ 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, các độ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ơ bị 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ơ sở 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ơ sở cho khối tiếp theo, t là mục tiêu và u là gas được sử dụng.
Một vấn đề lớn với cơ chế này là nó không thực sự nhắm mục tiêu t. Giả sử chúng ta nhận được hai khối, u = 0 đầu tiên và u = 2t tiếp theo. chúng tôi có:
Mặc dù mức sử dụng trung bình bằng t, phí cơ sở vẫn giảm 63/64. Vì vậy basefee chỉ ổn định khi mức sử dụng cao hơn một chút so với t; dường như cao hơn khoảng 3% trong thực tế, 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 số mũ e ^ x, trong đó e≈2.71828. Khi giá trị của x nhỏ thì exp (x) ≈1 + x. Tuy nhiên, nó có một tính năng tiện lợi không liên quan đến 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, không phụ thuộc vào phân phối. Để xem tại sao, chúng ta có thể thực hiện phép toán:
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 trên các khối khác nhau.
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à dư thừa: sự khác biệt giữa tổng lượng gas thực sự được sử dụng và tổng lượng gas dự định. đã sử dụng.
Phí cơ sở hiện tại bằng
Thực tế cho thấy rõ ràng rằng phần vượt quá không thể vượt ra ngoài một phạm vi rất hẹp: nếu nó vượt quá 8t ∗ 60, thì basefee trở thành e ^ 60, cao đến mức không ai có thể trả tiền cho nó, và nếu nó dưới 0, 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á mức không.
Cơ chế điều chỉnh hoạt động chính xác theo những điều khoản 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), đồng thời tính giá dưới dạng chỉ số chênh lệch. Để làm cho việc tính toán dễ dàng hơn, chúng tôi không sử dụng e ^ x mà là 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 thời gian dài sử dụng không đầy đủ dẫn đến các khối dài gấp 2 lần đầ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 real_total thấp hơn target_total, chúng tôi chỉ cần đặt real_total bằng target_total. Trong trường hợp cực đoan (blob gas giảm xuống 0) điều này phá vỡ sự bất biến của trật tự giao dịch, nhưng bảo mật bổ sung làm cho điều này trở thành một thỏa hiệp có thể 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 proto-danksharding lần đầu tiên được giới thiệu, ban đầu có lẽ rất ít người dùng, vì vậy giá của một blob gần như chắc chắn sẽ rất rẻ, thậm chí là "bình thường", trong một khoảng thời gian Ethereum hoạt động blockchain vẫn còn tốn kém.
Các tác giả cho 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 bộ phận của thị trường phí EIP-1559 nên 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:
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)
Đây là cơ chế cốt lõi được diễn đạt lại bằng toán học, với việc làm tròn bị loại bỏ:
Mục tiêu là kết hợp nhiều bản sao của (QX), một bản được dịch chuyển và chia tỷ lệ thích hợp cho mỗi phạm vi [2 ^ k, 2 ^ (k + 1)]. Bản thân Q (x) là một xấp xỉ của 2 ^ x đối với 0≤x≤1, được chọn cho các thuộc tính sau:
- Tính đơn giản (đây là một phương trình bậc hai)
- Độ đúng của cạnh trái (Q (0) = 2 ^ 0 = 1)
- Tính đúng của cạnh bên phải (Q (1) = 2 ^ 1 = 2)
- độ dốc nhẵn (chúng tôi đảm bảo rằng Q '(1) = 2 ∗ Q' (0), vì vậy mỗi bản sao được dịch chuyển + tỷ lệ của Q có cùng độ dốc ở cạnh bên phải của bản sao tiếp theo ở cạnh bên 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) đã cho ở trên cho một nghiệm duy nhất.
Con số gần đúng là tốt một cách đáng ngạc nhiên; fake_exponential đưa ra câu trả lời trong khoảng 0,3% giá trị thực của 2 ^ x cho tất cả trừ đầu vào nhỏ nhất:
Những vấn đề nào trong proto-danksharding vẫn đang được tranh luận?
- Tất cả các Optimistic Rollups đều sử dụng các multi-round proofs, vì vậy họ có thể sử dụng các biên dịch trước đánh giá điểm (rẻ hơn nhiều) thay vì các 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ự thực hiện: lấy blob D và hash h đã được tạo phiên bản làm đầu vào, chọn x = hash (D, h), tính y = D (x) bằng cách sử dụng đánh giá trung tâm và sử dụng đánh giá điểm Biên dịch trước xác minh rằng h ( x) = y. Vì vậy, chúng ta có thực sự cần quá trình 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á chấm?
- Làm thế nào để dây chuyền xử lý lâu dài bền lâu dài 1 MB + khối? Có nên giảm số lượng blob mục tiêu ngay từ đầu nếu rủi ro quá lớn?
- Nên sử dụng các blob bằng gas hay ETH (burned)? Có nên có những điều chỉnh khác đối với thị trường phí?
- Loại giao dịch mới có nên được coi là một blob hay một đối tượng SSZ, trong trường hợp sau là thay đổi ExecutionPayload thành loại liên hợp? (Đó 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")
- 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 này "chỉ là một hằng số" đối với người triển khai, nhưng vẫn cần được thực hiện).
