Cảm ơn Toni và Ladislaus đã thảo luận và phản hồi.
Đề xuất cải tiến Ethereum (EIP)-7928 giới thiệu Danh sách Truy cập Cấp Khối (BAL) để cải thiện khả năng thực thi song song trên L1. Ngoài khả năng mở rộng, BAL còn mở ra một nền tảng đơn giản hơn cho các giao thức cam kết của bên đề xuất, đặc biệt là các preconf thực thi . Thay vì dựa vào các bằng chứng phân mảnh trên nhiều Merkle Patricia Trie, BAL cung cấp một bản ghi chuẩn về tất cả các giá trị sau giao dịch mà các cam kết có thể được gắn vào.
Tuy nhiên, đặc tả Đề xuất cải tiến Ethereum (EIP)-7928 hiện tại không trực tiếp hỗ trợ các bằng chứng hiệu quả ở cấp độ EVM. Bài viết này nhằm mục đích khuyến khích sử dụng BAL cho các preconf, nêu bật các thay đổi đặc tả được đề xuất để làm cho chúng thân thiện với bằng chứng, và phác thảo những đánh đổi về độ phức tạp đang được thảo luận trong Discord .
Động lực
Tiền hội nghị thực thi cho phép người đề xuất (hoặc người ủy quyền) đưa ra cam kết sớm cho người dùng về kết quả giao dịch trước khi chúng được đưa on-chain. Điều này giúp giảm thời gian xác nhận trước xuống chỉ còn một "ping" duy nhất từ người hội nghị trước đến người dùng, mang lại trải nghiệm người dùng nhanh hơn so với giao thức Consensus . Thay vì chờ đợi xác nhận Block , người dùng có thể tự tin hành động ngay khi nhận được tiền hội nghị thực thi đáng tin cậy .
Ngày nay, các cam kết đáng tin cậy đòi hỏi khả năng chứng minh không cần tin cậy khi một cam kết bị phá vỡ để thực thi các điều kiện Slashing on-chain đối với các giao ước trước ràng buộc (ví dụ: sử dụng URC ). Các bằng chứng này được phân tán qua nhiều lần thử: thử giao dịch để bao gồm/sắp xếp, thử biên lai để thực hiện thành công, thử tài khoản để thay đổi Nonce hoặc số dư, và thử trạng thái để lưu trữ. Cách này hiệu quả, nhưng bị phân mảnh, yêu cầu logic chứng minh riêng và bị hạn chế về độ chi tiết.
phân mảnh : Để có phạm vi bao phủ hoàn chỉnh, cần phải cam kết các giá trị trong nhiều lần thử cho từng phần trạng thái đã sửa đổi.
logic: Mỗi cam kết đưa ra những lời hứa khác nhau và ảnh hưởng đến trạng thái khác nhau, đòi hỏi logic tùy chỉnh.
độ chi tiết: Các lần thử chỉ ghi lại trạng thái sau khi áp dụng tất cả các giao dịch, nghĩa là các bản cập nhật trạng thái trung gian (ví dụ: số dư của Alice sau giao dịch thứ tư) không thể chứng minh trực tiếp.
Một số thiết kế được đề xuất xoay quanh 1) và 3) hoàn nguyên giao dịch nếu trạng thái sau khi xử lý khác với mong đợi của người dùng, ví dụ: "bán 1000 USDC với giá ít nhất 0,98 ETH" . Mặc dù thực tế, điều này chuyển gánh nặng sang các nhà phát triển hợp đồng, những người phải mã hóa các điều kiện này theo cách thủ công. Trên thực tế, nó giống với lập trình theo kiểu ý định, trong đó mỗi hành động đều mang các điều kiện xác thực riêng.
Bằng cách cung cấp một bản ghi chuẩn về các chênh lệch trạng thái ở cấp độ giao dịch, BAL cung cấp một nguyên mẫu đơn giản hơn để xây dựng các giao thức cam kết của bên đề xuất. Một preconf thực thi có thể được biểu thị dưới dạng một cam kết đối với một tập hợp con của BAL, và các cam kết bị phá vỡ có thể được chứng minh dựa trên BAL chuẩn. Điều này giúp việc lập luận, thực thi và chuẩn hóa các cam kết trở nên dễ dàng hơn, giảm thiểu sự bất tiện cho cả người thiết kế giao thức và người dùng. Kết quả là, một giao thức cam kết chung duy nhất của bên đề xuất tận dụng hiệu quả BAL có thể bao quát tất cả các trường hợp sử dụng preconf hiện nay.
BALs Ngày nay
BAL là List[AccountChanges] được mã hóa RLP, trong đó đối tượng AccountChanges ghi lại các thay đổi trạng thái trên mỗi giao dịch đối với Nonce, số dư, lưu trữ và/hoặc mã của địa chỉ. Bằng cách áp dụng lặp lại tất cả AccountChanges , máy khách có thể xác định và song song tái tạo cách mọi tài khoản bị ảnh hưởng phát triển trong suốt Block.
Điều này đủ để giải quyết những thách thức của chúng ta với các cấu hình thực thi trước:
phân mảnh: Chỉ cần BAL thực hiện cam kết so với nhiều lần thửlogic: Một giao thức chung duy nhất là đủ để nắm bắt tất cả các trường hợp sử dụng preconf hiện nay mà không cần lập trình theo kiểu ý định.độ chi tiết: Đối tượngAccountChangescho phép cam kết với các khác biệt về trạng thái của mỗi giao dịch.
Giới hạn hiện tại
Rõ ràng BAL có thể cải thiện các giao thức tiền cấu hình; tuy nhiên, thách thức nằm ở cách BAL được mã hóa. Theo thông số kỹ thuật Đề xuất cải tiến Ethereum (EIP)-7928 hiện tại, BAL được mã hóa RLP và Block Header chứa Hash BAL .
Điều này khiến việc chứng minh với Máy ảo Ethereum (EVM) rằng một cam kết đã bị phá vỡ trở nên phức tạp. Người dùng sẽ cần phải truyền toàn bộ BAL dưới dạng calldata, xác minh Hash của nó với Hash Block cha, rồi giải mã RLP thủ công để xác định giá trị xung đột. Hiện tại, một BAL chưa nén có dung lượng khoảng 100KB, nằm trong giới hạn calldata. Vì việc cam kết bị phá vỡ hiếm khi xảy ra, nên điều này không phải là không hợp lý.
Đề xuất thay đổi Đề xuất cải tiến Ethereum (EIP) (khó hơn)
Khi các khối và BAL ngày càng lớn, việc truyền BAL dưới dạng calldata sẽ càng tốn kém hơn. Thay đổi được đề xuất sẽ giúp việc chứng minh tư cách thành viên BAL từ Máy ảo Ethereum (EVM) dễ dàng hơn.
Vì các máy khách thực thi khó có thể sử dụng SSZ để mã hóa BAL, một phương pháp thay thế là mã hóa BAL thành MPT riêng của nó như Toni đề xuất. Block Header sẽ chứa gốc BAL thay vì Hash , cho phép chứng minh MPT hiệu quả dựa trên Hash gốc Đề xuất cải tiến Ethereum (EIP) -2935.
Một mã hóa lý tưởng cho preconf sẽ có hai cấp độ thử. Trie bên ngoài ánh xạ khóa bal_index (còn gọi là chỉ mục giao dịch) thành một giá trị subTrieRoot , trong đó mỗi bal_index đại diện cho một chỉ mục giao dịch duy nhất. subTrie bên trong chứa các khóa duy nhất bao gồm tất cả các thay đổi tài khoản khác nhau:
RLP(["balance_change", address])RLP(["storage_change", address, slot])RLP(["nonce_change", address])RLP([“code_change”, address])
với các giá trị chứa dữ liệu sau giao dịch được mã hóa RLP (tức là RLP([uint256]) ).
Điều này sẽ cho phép preconfer đưa ra các cam kết ngắn gọn về sự khác biệt trạng thái sau giao dịch, tức là một chữ ký trên subTrieRoot cho một bal_index nhất định. Việc chứng minh rằng một cam kết đã bị phá vỡ sau đó sẽ được rút gọn thành việc chỉ ra rằng subTrieRoot thực tế tại bal_index đó khác với subTrieRoot đã được ký. Các thay đổi tài khoản riêng lẻ trong subTrie được tách biệt khỏi giao thức cam kết.
Điều này đơn giản hơn nhiều so với tình huống hiện tại, khi một preconfer cần phải cam kết thực hiện các phép so sánh trạng thái sau nhiều lần thử cho mỗi vị trí mà giao dịch chạm đến. Thay vào đó, mỗi giao dịch giờ đây được thu gọn thành một subTrieRoot duy nhất, được đóng gói gọn gàng.
Tuy nhiên, cách tiếp cận này đòi hỏi phải đưa ra một phương pháp khác làm tăng thêm độ phức tạp của EIP.
Đề xuất thay đổi Đề xuất cải tiến Ethereum (EIP) (dễ dàng hơn)
Giả sử Block Header vẫn cam kết với Hash BAL được mã hóa RLP, việc tái cấu trúc nhẹ bố cục BAL có thể đơn giản hóa đáng kể việc cam kết. Đề xuất này là lập chỉ mục BAL theo bal_index thay vì accounts, sao cho BAL được mã hóa dưới dạng List[TransactionDiff] được mã hóa RLP.
TransactionDiff sẽ chứa tất cả các thay đổi Nonce, số dư, lưu trữ và mã từ giao dịch đã cho. Điều này sẽ thu gọn cam kết từ nhiều giá trị AccountChanges thành một TransactionDiff , hoạt động giống như subTrieRoot trong đề xuất trước đó.
Cam kết ngắn gọn với TransactionDiff sẽ khiến việc xây dựng Block liên tục trở nên khả thi hơn vì ví và phần còn lại của đường ống PBS có thể cập nhật trạng thái mới nhất sau khi áp dụng các cấu hình thực thi trước.
Những lợi ích khác của BAL
Các gói tổng hợp lớn hiện đang thử nghiệm xác nhận nhanh hơn để cải thiện trải nghiệm người dùng (UX) thông qua các cơ chế cam kết như shred , flashblock và frag . Ngày nay, các cơ chế này phụ thuộc vào các triển khai của bên thứ ba và các cam kết yêu cầu hoàn toàn tin tưởng vào trình sắp xếp.
BAL chuẩn hóa mô hình này: các gói tích lũy sử dụng BAL không còn cần phải duy trì các chương trình cam kết tùy chỉnh của riêng mình nữa, và người dùng có thể dễ dàng hưởng lợi từ các cam kết đáng tin cậy. Trên thực tế, BAL đã thể hiện những gì đã bắt đầu diễn ra trong thực tế.
Vitalik đã chỉ ra rằng BAL là một phương pháp MPT cho phép các nút không trạng thái một phần xác minh bằng chứng về chỉ các phần BAL mà chúng quan tâm, tức là số dư của tôi đã thay đổi như thế nào trong suốt Block.
Preconf thực thi là tiền thân ngoài giao thức của những ý tưởng như phân đoạn tải trọng .
