Ghi chú này xem xét hai chế độ lỗi cân bằng phát sinh trong Đề xuất cải tiến Ethereum (EIP)-8037 khi người dùng không muốn chi 50% ngân sách của họ cho việc tạo trạng thái, và trình bày các biện pháp điều chỉnh quy mô gas trạng thái có thể được triển khai sau đó. Trong trường hợp cực đoan, nếu người dùng tiếp tục tạo ra nhiều byte trạng thái trên mỗi đơn vị gas thông thường được tiêu thụ như hiện nay và Ethereum tăng Gas Limit lên 10 lần, thì khoảng 6,2% không gian khối thông thường sẽ được sử dụng trong trạng thái cân bằng. Điều này sẽ làm mất đi phần lớn lợi ích về khả năng mở rộng đạt được thông qua ePBS và BAL. Có thể thực hiện hai điều chỉnh trực tiếp nếu hóa ra nhu cầu không tạo ra sự phân bổ chi tiêu 50/50: (1) áp dụng giá Đề xuất cải tiến Ethereum (EIP)-8075 tự động mở rộng và thu hẹp Gas Limit trạng thái; hoặc (2) mở rộng/thu hẹp Gas Limit trạng thái theo cách thủ công, trong một Hard fork thông thường hoặc trong một hardfork "chỉ tham số gas trạng thái" (SGPO).
Các chế độ hỏng hóc
Ethereum đang tập trung vào việc mở rộng Layer 1, với các tính năng nổi bật như Đề xuất cải tiến Ethereum (EIP)-7732 (ePBS) và Đề xuất cải tiến Ethereum (EIP)-7928 (BAL) dự kiến sẽ được đưa vào Glamsterdam. Nếu chi phí gas cho việc tạo trạng thái không được điều chỉnh, trạng thái có thể sẽ tăng lên gần như tương ứng với Gas Limit đang mở rộng. Do đó, Đề xuất cải tiến Ethereum (EIP)-8037 làm tăng đáng kể chi phí gas cho việc tạo trạng thái. Một mối lo ngại ( 1 , 2 , 3 ) liên quan đến sự thay đổi này là tỷ lệ gas tổng cộng được chi cho việc tạo trạng thái có thể tăng lên, do đó làm giảm gas thông thường. Ví dụ, giả sử rằng ePBS và BAL cùng với việc định giá lại tính toán cho phép Gas Limit là 600M, một điểm giữa của các con số được thảo luận ở đây . Với đặc tả Đề xuất cải tiến Ethereum (EIP)-8037 hiện tại dựa trên quy tắc đo lường Đề xuất cải tiến Ethereum (EIP)-8011 , nếu người dùng không nhạy cảm với việc tăng giá gas trạng thái và tạo ra lượng trạng thái tương ứng với gas thông thường tiêu thụ như hiện nay, thì chỉ khoảng 6,2% dung lượng khối thông thường sẽ được sử dụng trong trạng thái cân bằng. Khi đó, những lợi ích về khả năng mở rộng từ ePBS, BAL và việc định giá lại điện toán sẽ bị mất đi phần lớn.
Tất nhiên, chúng ta có thể hy vọng rằng người dùng sẽ tạo ra ít byte trạng thái hơn trên mỗi đơn vị gas thông thường khi chi phí tạo trạng thái tăng lên, nhưng độ co giãn của cầu theo giá đối với việc tạo trạng thái là không xác định và dường như không thể dự đoán một cách đáng tin cậy. Ví dụ, nếu người dùng bắt đầu tiêu thụ ít hơn một nửa số byte trạng thái trên mỗi đơn vị gas thông thường so với hiện nay, thì tình hình sẽ được cải thiện phần nào, và 12,3% Gas Limit Block có thể được sử dụng. Kịch bản lý tưởng là nếu người dùng tiêu thụ ít hơn 8,1 lần số byte trạng thái trên mỗi đơn vị gas thông thường so với hiện nay. Trong trường hợp này, cả gas trạng thái và gas thông thường có thể được sử dụng ở mức công suất 50/50 (hoặc thực tế hơn, có lẽ gần hơn 40/40 , nếu giá Đề xuất cải tiến Ethereum (EIP)-8011 sử dụng toán tử tối đa). Nếu mức tiêu thụ tương đối của việc tạo trạng thái giảm nhiều hơn mức đó, thì hiệu ứng ngược lại sẽ xảy ra, và người dùng sẽ tạo ra ít hơn 100 GiB trạng thái mong muốn mỗi năm.
Hình 1 phác thảo hai chế độ lỗi cân bằng có thể xảy ra theo cơ chế định giá Đề xuất cải tiến Ethereum (EIP)-8011: quá ít byte trạng thái được tạo ra, hoặc quá ít gas thông thường được tiêu thụ. Thiết kế hiện tại hoạt động tối ưu nếu người dùng sẵn sàng chi 50% ngân sách của họ cho gas thông thường và 50% ngân sách cho gas trạng thái, bất kể giá tương đối giữa hai loại này. Nếu không phải vậy, một bên sẽ lấn át bên kia trong trạng thái cân bằng.
Hình 1. Hai chế độ lỗi của cơ chế định giá Đề xuất cải tiến Ethereum (EIP)-8011 được áp dụng trong Đề xuất cải tiến Ethereum (EIP)-8037. Nếu nhu cầu tạo lập quốc gia thấp hơn so với dự đoán của các nhà nghiên cứu, thì lượng quốc gia được tạo ra ở trạng thái cân bằng sẽ quá ít (giá của nó quá cao so với nhu cầu). Nếu nhu cầu tạo lập quốc gia cao hơn so với dự đoán của các nhà nghiên cứu, thì gas thông thường được tiêu thụ ở trạng thái cân bằng sẽ quá ít (giá của nó quá cao so với nhu cầu).
Ngăn ngừa thất bại
Vấn đề cốt lõi hơn là cơ chế định giá Đề xuất cải tiến Ethereum (EIP)-8011 không theo dõi việc tạo lập các tiểu bang theo thời gian (hay nói một cách tổng quát hơn, bất kỳ giá trị nào phản ánh sự cân bằng về nhu cầu giữa các hoạt động của tiểu bang và phi tiểu bang). Do đó, nó không thể điều chỉnh chi phí gas của tiểu bang sao cho cả nguồn tài nguyên của tiểu bang và nguồn tài nguyên thông thường đều đạt mức nhu cầu mục tiêu. Chúng ta có thể sẽ rơi vào tình trạng một trong hai nguồn tài nguyên, hoặc tất cả các nguồn tài nguyên khác, bị sử dụng dưới mức tối ưu đáng kể trong trạng thái cân bằng. Có hai lựa chọn để giảm thiểu điều này:
- để theo dõi việc tạo trạng thái theo thời gian bằng cách sử dụng biến tiêu đề và tự động điều chỉnh sự cân bằng giữa gas trạng thái và gas thông thường, như đề xuất trong Đề xuất cải tiến Ethereum (EIP)-8075; hoặc
- Điều chỉnh thủ công sự cân bằng giữa gas trạng thái và gas thông thường sau khi quan sát thấy sự phân bố không cân đối, có thể sử dụng các hardfork chỉ dựa trên tham số khí trạng thái (hoặc tăng trưởng trạng thái).
(1) Ngăn ngừa các chế độ lỗi thông qua Đề xuất cải tiến Ethereum (EIP)-8075
Việc áp dụng cơ chế định giá Đề xuất cải tiến Ethereum (EIP)-8075 cho Đề xuất cải tiến Ethereum (EIP)-8037 giải quyết vấn đề một cách có nguyên tắc. Theo Đề xuất cải tiến Ethereum (EIP)-8075, việc tạo trạng thái có chi phí gas thay đổi tùy thuộc vào nhu cầu, sao cho số lượng byte trạng thái mong muốn được tạo ra theo thời gian. Mục tiêu và giới hạn gas trạng thái tự động mở rộng và thu hẹp theo chi phí gas (vì cơ chế định giá hoạt động trên các byte trạng thái). Gas được đo lường được tính bằng trung bình của gas thông thường và một thước đo chuẩn hóa của gas trạng thái. Điều này cho phép gas thông thường được tiêu thụ ở mức mục tiêu theo thời gian, đồng thời giao thức cũng đảm bảo rằng số lượng byte trạng thái mục tiêu được tạo ra.
Hình 2. Đề xuất cải tiến Ethereum (EIP)-8075 tự động điều chỉnh chi phí gas theo nhu cầu để đảm bảo tạo ra số lượng byte trạng thái mục tiêu trong dài hạn. Để đạt được điều này, Đề xuất cải tiến Ethereum (EIP) mở rộng và thu hẹp mục tiêu và giới hạn gas đồng thời điều chỉnh chi phí gas sao cho số lượng byte trạng thái mục tiêu được tiêu thụ.
(2) Ngăn chặn các chế độ lỗi thủ công trong các nhánh cứng thông thường/SGPO
Phương án thứ hai là mô phỏng ý tưởng của Đề xuất cải tiến Ethereum (EIP)-8075, nhưng thực hiện các điều chỉnh thủ công. Trong trường hợp này, mục tiêu và giới hạn gas nhà nước lý tưởng có thể được phép mở rộng và thu hẹp như trong Đề xuất cải tiến Ethereum (EIP)-8075 (Hình 2), sao cho phương trình đo lường vẫn đáp ứng được cả khí thông thường và gas nhà nước. Nếu được triển khai dưới dạng hardfork SGPO, một stateSchedule có thể được giới thiệu và khởi tạo như sau:
{ "stateSchedule" : { "gloas" : { "target" : 107374182400 , "scale" : 100 } } , "gloasTime" : "TBD" } Tham số scale cho phép mở rộng hoặc thu hẹp Gas Limit của trạng thái so với Gas Limit Block , và tham số target thiết lập mức tăng trưởng hàng năm của trạng thái khi sử dụng tối đa. state_gas_limit được tính bằng state_gas_limit = gas_limit * stateSchedule.scale // 100 , và cost_per_state_byte được tính bằng cách thay thế gas_limit bằng state_gas_limit trong biểu thức sau:
cost_per_state_byte = state_gas_limit * 7200 * 365 // (stateSchedule.target * 2 ) Khi hàm đo F cuối cùng được áp dụng (trong đó F có thể là max hoặc bất kỳ hàm nào khác được thảo luận ở đây ), nó cũng giống như trong Đề xuất cải tiến Ethereum (EIP)-8075 được áp dụng cho một thước đo chuẩn hóa của gas trạng thái: F(regular_gas, state_gas * 100 // stateSchedule.scale) . Vì độ co giãn theo nhu cầu chưa được biết, một lần điều chỉnh thủ công có thể không hoàn toàn chính xác. Do đó, có vẻ hợp lý khi vượt quá một chút nếu gas thông thường tiêu thụ ở trạng thái cân bằng quá ít, để duy trì tỷ lệ. Cũng có thể "vượt quá" một cách tổng quát hơn bằng cách nhắm mục tiêu tỷ lệ gas trạng thái cao hơn so với giới hạn là 0,5, như đã nêu ở đây .
Lưu ý rằng tham số scale sẽ là lý do chính để bổ sung các hardfork SGPO. Nếu không có tham số scale , Ethereum có nguy cơ rơi vào Chế độ Thất bại 2 trong Hình 1, bỏ lỡ một phần lợi ích về khả năng mở rộng của ePBS và BAL. Khả năng điều chỉnh target tăng trưởng cũng được hoan nghênh, nhưng riêng điều đó sẽ không đủ để biện minh cho sự phức tạp trong triển khai. Nói cách khác, cả target và scale đều có thể được thiết lập và điều chỉnh trong một hardfork thông thường, nhưng chỉ việc thiếu tham số scale có thể biện minh cho các hardfork SGPO.
Cân bằng cách điệu
Kết quả cân bằng theo định giá Đề xuất cải tiến Ethereum (EIP)-8011 trong Đề xuất cải tiến Ethereum (EIP)-8037 có thể được phân tích sơ bộ bằng cách tập trung vào độ co giãn cầu tương đối giữa hai nguồn lực (như ở đây và ở đây , với một bài viết tổng quan về độ co giãn cầu cũng có sẵn ở đây ).
Có một chi phí gas cố định và cả hai nguồn tài nguyên đều có cùng mức phí cơ bản. Ban đầu, trước khi triển khai Đề xuất cải tiến Ethereum (EIP)-8037, 70% tổng gas được sử dụng cho các hoạt động sẽ được tính phí theo gas thông thường, G1 = 0.7 , và 30% lượng gas được sử dụng cho việc tạo trạng thái, G2 = 0.3 . Nếu nhu cầu được cân bằng giữa gas thông thường và khí đốt trạng thái theo chi phí gas đốt cố định mà Đề xuất cải tiến Ethereum (EIP)-8037 quy định ở bất kỳ Gas Limit nào, sao cho người dùng sử dụng một lượng gas bằng nhau cho cả hai, thì cơ chế sẽ hoạt động hoàn hảo như dự định. Tỷ lệ r /r của lượng gas được sử dụng cho hai nguồn tài nguyên khi đó là 1:
Giả sử chi phí gas để tạo trạng thái tăng lên một hệ số p và d biểu thị số byte trạng thái mà người dùng sẵn sàng tạo ra ít hơn bao nhiêu lần cho mỗi đơn vị gas thông thường tiêu thụ, với mức tăng chi phí đã cho. Tỷ lệ mới giữa gas thông thường và gas trạng thái tiêu thụ sẽ là:
Trong điều kiện cân bằng khi sử dụng hàm max (như trong Đề xuất cải tiến Ethereum (EIP)-8037) và bỏ qua ảnh hưởng của sự biến Block đến tỷ lệ cân bằng, kích thước đo được (lớn hơn giữa khí thông thường và gas trạng thái) sẽ ở mức mục tiêu. Khi đó, người dùng sẽ tiêu thụ gas thông thường với tỷ lệ G^*_1 = \min(0,5, 0,5r) G ∗ 1 = min ( 0,5 , 0,5 r ) của Gas Limit, và gas trạng thái với tỷ lệ G^*_2 = \min(0,5, 0,5/r) G ∗ 2 = min ( 0,5 , 0,5 / r ) .
Mức tăng chi phí cơ bản Đề xuất cải tiến Ethereum (EIP)-8037 ở mức 60 triệu gas là 1,17 lần đối với khe lưu trữ, 3,29 lần đối với tài khoản và 3,67 lần đối với mã. Mức tăng chi phí gas trung bình có trọng số trên ba chỉ số này dựa trên quỹ đạo tăng trưởng hiện tại ( Snapshot lưu trữ, Snapshot tài khoản, mã hợp đồng) giữa Block 17.165.429 và Block 21.000.000 là khoảng 1,89 lần. Sự không chắc chắn trong mức trung bình có trọng số hiện tại được thừa nhận một cách đầy đủ.
Khi nghiên cứu khả năng mở rộng gấp 10 lần được hỗ trợ bởi BAL, ePBS và định giá lại, mức tăng chi phí gas trung bình có trọng số theo tiêu chuẩn Đề xuất cải tiến Ethereum (EIP)-8037 sẽ là 18,9 lần. Do đó, nếu đặt p=18,9 và giả sử người dùng không thay đổi mô hình sử dụng hiện tại của họ ( d= 1 ) , tỷ lệ sẽ trở thành
Khi đó, người dùng sẽ chỉ tiêu thụ gas thông thường với tỷ lệ nhất định.
của Gas Limit ở trạng thái cân bằng. Nếu người dùng giảm một nửa lượng tạo trạng thái trên mỗi đơn vị gas thông thường, thì trạng thái cân bằng trở thành G^*_1 = 0,123 G ∗ 1 = 0,123 . Mức giảm tối ưu trong mức tiêu thụ byte trạng thái trên mỗi đơn vị gas thông thường đạt được bằng cách khôi phục trạng thái cân bằng ( r=1 r = 1 ), điều này ngụ ý:
Nhìn về phía trước
Khi Ethereum tiếp tục mở rộng quy mô, độ khó trong việc dự đoán chi phí gas trạng thái để cân bằng chi phí gas ngày càng tăng, cũng như mức độ nghiêm trọng của các chế độ lỗi tồi tệ nhất. Ví dụ, ở mức mở rộng L1 30x, chỉ 2,1% không gian khối dành cho gas thông thường được sử dụng ở trạng thái cân bằng, nếu người dùng không thay đổi việc tạo byte trạng thái trên mỗi lần sử dụng gas thông thường (nhưng chi phí gas cao ở thời điểm này sẽ khuyến khích người dùng thực hiện những điều chỉnh đáng kể về lượng trạng thái mà họ tạo ra). Đến khi đạt mức mở rộng 30x, một giải pháp toàn diện hơn cho vấn đề này lý tưởng nhất sẽ được triển khai. Giải pháp như vậy bao gồm một thị trường phí đa chiều hoàn chỉnh như trong Đề xuất cải tiến Ethereum (EIP)-7999 , và các nỗ lực kỹ thuật để xử lý tốt hơn sự tăng trưởng trạng thái (có thể làm hết hạn một phần trạng thái).
