Vì sao hạn chót tải trọng thay đổi chỉ giúp ích khoảng 6%
Tóm lại: Thời hạn tải trọng thay đổi mang lại lợi ích lý thuyết khoảng 6% về Gas Limit dự phòng, và điều đó đã giả định chúng ta dựa trên Block Size nén. Trên thực tế, đề xuất này dựa trên kích thước không nén, và kết hợp với sự phân bố kích thước Block phải mạnh, phép nội suy tuyến tính không thể mở rộng thời gian lan truyền một cách hiệu quả. Chúng ta thậm chí có thể có thời gian lan truyền ngắn hơn hiện nay.
Theo Đề xuất cải tiến Ethereum (EIP)-7732 , người xây dựng gửi một tải trọng, tải trọng này lan truyền qua mạng, PTC bỏ phiếu về tính khả dụng và các trình xác thực thực thi nó trước khi đến lượt tiếp theo.
Thời hạn tải trọng thay đổi đề xuất việc dành nhiều thời gian hơn cho việc truyền tải các khối dữ liệu lớn, trong khi các khối dữ liệu nhỏ hơn sẽ đến sớm hơn và được hưởng lợi từ nhiều thời gian thực thi hơn. Về lý thuyết, điều này nghe có vẻ hợp lý. Tuy nhiên, trên thực tế, lợi ích thu được là rất nhỏ và phương pháp này có những vấn đề cơ bản.
Bối cảnh: Đề xuất cải tiến Ethereum (EIP)-7976 và định giá dữ liệu cuộc gọi
Theo Đề xuất cải tiến Ethereum (EIP)-7976 , phí sàn dữ liệu cuộc gọi là 64 gas mỗi byte. Giá tiêu chuẩn chỉ tính 4 gas mỗi byte 0 và 16 gas mỗi byte khác 0. Sự khác biệt (lên đến 60 gas mỗi byte) là gas thực thi mà giao dịch nhận được "miễn phí".
Đề xuất cải tiến Ethereum (EIP)-7976 được cải tiến từ Đề xuất cải tiến Ethereum (EIP)-7623 , phiên bản được tích hợp trong Pectra và thiết lập chi phí dữ liệu cuộc gọi là 10/40 cho cả byte bằng 0 và khác 0. Đề xuất cải tiến Ethereum (EIP)-7976 tiến xa hơn bằng cách thống nhất chi phí cho cả byte bằng 0 và khác 0 , vì sự khác biệt này không quan trọng khi xử lý các kích thước Block trong trường hợp xấu nhất.
Hai khối trường hợp xấu nhất
Khi nói về kích thước dữ liệu, chúng ta thường tập trung vào kích thước đã được nén bằng Snappy. Vì giao thức này không quy định thuật toán nén cụ thể nào, nên nó phải xử lý cả kích thước chưa được nén. Điều này rất quan trọng, vì nó làm phức tạp vấn đề đáng kể.
Khi thiết lập Gas Limit, mọi Block có thể phải nằm gọn trong một ô. Có hai trường hợp cực đoan:
- Block tính toán thuần túy : không có dữ liệu gọi hàm, toàn bộ phí gas được dùng cho việc thực thi. Cần thời gian lan truyền bằng không nhưng thời gian thực thi tối đa.
- Block dữ liệu cuộc gọi tối đa : được điền đầy dữ liệu cuộc gọi, kích hoạt mức sàn. Cần thời gian lan truyền tối đa, nhưng cũng nhận được 93,75% gas của nó dưới dạng thực thi "được dành riêng".
Quan sát quan trọng: Block max-calldata có mức độ xử lý gần như tương đương với Block pure-compute. Trong mỗi 64 gas được tính phí ở mức sàn, chỉ có 4 gas đủ để trang trải chi phí calldata thực tế. 60 gas còn lại là thời gian xử lý "dành riêng". Vì vậy, Block dữ liệu sử dụng 93,75% thời gian xử lý so với Block tính toán. Để biết thêm chi tiết về lý do, hãy xem phân tích này về Đề xuất cải tiến Ethereum (EIP)-7623 .
Phương pháp Đề xuất cải tiến Ethereum (EIP)-7623 duy trì hiệu quả khả năng tương thích ngược cho hầu hết các giao dịch trong khi giới hạn Block Size trong trường hợp xấu nhất . Nó cũng hoạt động tốt với ePBS vì nó "dành riêng" thời gian thực thi sau thời hạn quan sát tải trọng (PTC), ngay cả đối với các khối trong trường hợp xấu nhất. Nhưng chính "thời gian thực thi dành riêng" này lại hạn chế tính hữu ích của thời hạn biến đổi.
Hãy xem trang này để biết Block Size trường hợp xấu nhất hiện nay so với sau EIP-7976: với 60M gas, kích thước hiện nay là 2,24 MB và sau EIP-7976 là 938 KB. Kích Block Size trường hợp xấu nhất tỷ lệ thuận tuyến tính với Gas Limit.
Hạn chót cố định so với hạn chót thay đổi
Với thời hạn cố định , một thời hạn duy nhất phải xử lý tất cả các khối. Nó dành đủ thời gian lan truyền cho Block lớn nhất VÀ đủ thời gian thực thi cho Block đòi hỏi nhiều tài nguyên tính toán nhất. Đây là những khối khác nhau, nhưng thời hạn cố định không thể phân biệt được chúng. Nó cộng cả hai trường hợp xấu nhất lại với nhau, mặc dù không có Block nào là trường hợp xấu nhất ở cả hai khía cạnh.
Với thời hạn thay đổi , mỗi Block được đánh giá riêng lẻ. Block lớn nhất sẽ có nhiều thời gian lan truyền hơn. Block đòi hỏi nhiều tài nguyên tính toán nhất sẽ có nhiều thời gian thực thi hơn. Đó là lý thuyết.
Vậy lợi ích là gì?
Lợi ích thu được tỷ lệ thuận với mức độ khác biệt giữa hai khối trường hợp xấu nhất. Nếu chúng rất khác nhau, thời hạn cố định sẽ lãng phí rất nhiều do phải cộng dồn các trường hợp xấu nhất không liên quan. Nếu chúng gần như giống hệt nhau, hầu như không có gì để tiết kiệm.
Với Đề xuất cải tiến Ethereum (EIP)-7976:
| Sự lan truyền | Thực thi | |
|---|---|---|
| Block tính toán thuần túy | không có (đơn giản hóa) | 100% gas |
| Block dữ liệu gọi tối đa | một số | 93,75% gas |
Hai khối lệnh chỉ khác nhau 6,25% về nhu cầu thực thi. Đó là toàn bộ lượng dự trữ vượt mức của thời hạn cố định, và thời hạn biến đổi sẽ thu hồi chính xác lượng dự trữ này.
6,25% đến từ đâu? Đó là \frac{C}{4F} = \frac{4}{64} C 4 F = 4 64 : phần chi phí sàn (floor cost) thể hiện chi phí dữ liệu cuộc gọi thực tế chứ không phải chi phí thực thi "đã được dành riêng". Đó là phần chi phí gas trong một Block max-calldata thực sự được dùng để trả cho dữ liệu cuộc gọi .
Việc xem xét một thời hạn linh hoạt vẫn có thể mang lại thêm khoảng 6% dung lượng dự phòng Gas Limit . Nhưng điều này giả định rằng chúng ta dựa trên Block Size nén. Thực tế thì không phải vậy.
Vì sao lợi ích thực tế lại càng ít hơn
Con số ~6% là mức tối đa về mặt lý thuyết. Trên thực tế, đề xuất này dựa trên kích thước Block chưa nén, chứ không phải kích thước khối đã nén. Điều này làm suy yếu toàn bộ phương pháp tiếp cận.
Điều quan trọng đối với quá trình lan truyền là kích thước dữ liệu truyền qua đường truyền, nơi các khối dữ liệu được nén. Hai khối dữ liệu có thể cùng có kích thước 1 MB khi chưa nén, nhưng một khối khi nén xuống còn 100 KB trong khi khối kia không bị nén chút nào. Mặc dù hoạt động rất khác nhau trong quá trình lan truyền, cả hai đều nhận được cùng một thời hạn chót:
Tệ hơn nữa, sự phân bố kích thước Block bị lệch mạnh về phía bên phải:
Bằng cách nội suy tuyến tính giữa 3,6 giây và 9 giây trên phân bố này, hầu hết các khối sẽ có thời hạn chỉ cao hơn mức tối thiểu một chút. Về cơ bản, chúng ta sẽ không mở rộng thời gian lan truyền chút nào, và thậm chí có thể có thời gian lan truyền ngắn hơn hiện nay.
Nếu giữ nguyên yêu cầu PR như hiện tại, thời hạn quan sát dữ liệu sẽ tập trung gần thời hạn xác nhận, làm mất đi phần lớn thời gian truyền tín hiệu mà ePBS ban đầu cung cấp:
Ngay cả khi giả sử yêu cầu mua hàng (PR) được cập nhật để sử dụng Block Size tối đa động dựa trên Gas Limit và giá Đề xuất cải tiến Ethereum (EIP)-7976, tình hình cũng không cải thiện nhiều:
Nói rõ hơn, điều này không có nghĩa là thời hạn của khối dữ liệu phải bằng thời hạn của dữ liệu tải trọng. Chúng có thể vẫn riêng biệt, nhưng thời hạn dữ liệu tải trọng thay đổi cần phải dựa trên kích thước đã nén để có ý nghĩa.
Liệu chúng ta có thể cải thiện được lợi ích lý thuyết không?
Để đạt được lợi ích lý thuyết lớn hơn, hai khối trường hợp xấu nhất cần phải khác biệt nhiều hơn. Điều đó có nghĩa là giảm tỷ lệ thực thi "dành riêng" a = 1 - \frac{C}{4F} a = 1 − C 4 F trong đó C là chi phí Token tiêu chuẩn và 4F là chi phí sàn trên mỗi byte .
Có hai đòn bẩy rõ ràng , nhưng cả hai đều có những đánh đổi nghiêm trọng.
Giảm chi phí sàn (ví dụ: 64/64 → 32/32). Điều này làm giảm tỷ lệ xuống còn 87,5%, tăng gấp đôi lợi ích từ thời hạn biến đổi lên 12,5%. Giá tiêu chuẩn vẫn ở mức 4/16, duy trì khả năng tương thích ngược. Nhưng mức sàn thấp hơn có nghĩa là kích thước khối tối đa lớn hơn: ở gas 150M, Block Size tối đa tăng gấp đôi từ ~2,25 MiB lên ~4,5 MiB. Điều này phản tác dụng nếu chúng ta muốn tăng Gas Limit.
Tăng chi phí tiêu chuẩn (ví dụ: 4/16 → 8/32). Điều này trực tiếp làm giảm tỷ lệ xuống còn 87,5% và tăng gấp đôi lợi nhuận lên 12,5%. Nhưng điều này phá vỡ tính tương thích ngược: mọi giao dịch đều phải trả nhiều hơn cho dữ liệu cuộc gọi, chứ không chỉ những giao dịch có nhiều dữ liệu. Mục tiêu thiết kế của Đề xuất cải tiến Ethereum (EIP)-7976 là khoảng 98% giao dịch vẫn giữ nguyên mức giá 4/16 hiện tại. Việc tăng chi phí tiêu chuẩn sẽ làm suy yếu mục tiêu đó.
Mâu thuẫn nằm ở chỗ: mức sàn cao giới hạn Block Size (mục tiêu chính của Đề xuất cải tiến Ethereum (EIP)-7623) nhưng tối đa hóa khả năng thực thi "miễn phí". Chi phí tiêu chuẩn thấp duy trì khả năng tương thích ngược nhưng cũng tối đa hóa khả năng thực thi "miễn phí". Cả hai mục tiêu đều đẩy tỷ lệ thực thi dành riêng lên gần 100%, hầu như không còn gì để thời hạn biến đổi có thể thu hồi.
Liệu việc đó vẫn còn đáng để cân nhắc?
Mặc dù vậy, thời hạn tải trọng thay đổi vẫn có một số ưu điểm:
- Độ phức tạp triển khai thấp. Đây là một thay đổi tương đối đơn giản đối với thông số kỹ thuật của trình xác thực trung thực, chỉ ảnh hưởng đến PTC. Về lý thuyết, nó sẽ không yêu cầu hardfork.
- Lợi ích trung bình chỉ ở mức nhỏ. Các khối trung bình khác xa so với trường hợp xấu nhất, vì vậy thời hạn động có thể mang lại những cải thiện hiệu quả nhỏ trong điều kiện thông thường, mặc dù liệu giao thức có thực sự tận dụng được những cải thiện này hay không vẫn còn là điều đáng nghi ngờ do cơ chế neo kích thước không nén.
- Lợi thế thông tin của nhà thầu bị giảm sút. Hiện nay, nhà thầu có giá thầu được chọn là bên duy nhất nắm rõ tình trạng dự án từ giai đoạn đầu. Thời hạn hoàn thành có thể thay đổi phần nào giúp giảm bớt sự bất đối xứng này.
Đây là những lợi ích có thật nhưng khá khiêm tốn. Vì phương pháp này dựa trên chỉ số sai (kích thước chưa nén), nên lợi ích thực tế chỉ là một phần nhỏ trong tổng số 6% vốn đã rất nhỏ, và chúng ta có nguy cơ làm giảm thời gian lan truyền so với hiện nay, nên rất khó để chứng minh tính hiệu quả của nó.
Giải pháp thực sự
Tuy phức tạp hơn đáng kể, nhưng phương án tốt nhất là tách dữ liệu ra thành một chiều chi phí riêng. Đề xuất cải tiến Ethereum (EIP)-7999 đề xuất thị trường phí đa chiều. Điều này sẽ phá vỡ khả năng tương thích ngược, nhưng nó sẽ cho phép chúng ta xác định chính xác các khối trường hợp xấu nhất mà chúng ta sẵn sàng chấp nhận, tách biệt hoàn toàn dữ liệu và tính toán thay vì cố gắng che đậy sự liên kết của chúng bằng các thời hạn động.
