Tác giả: John Otander, nhà phát triển lõi Ethereum; Bản dịch: Golden Finance xiaozou
Bài đăng này được lấy cảm hứng từ câu trả lời của nhà truyền giáo Ethereum Vitalik trong Reddit AMA gần đây.
p> p>
Vitalik chỉ ra rằng việc Gas Limit tăng vừa phải là hợp lý. Gas Limit đã không được tăng trong gần ba năm, đây là khoảng thời gian dài nhất trong lịch sử của giao thức. Vitalik cũng thực hiện một số tính toán đơn giản để tăng Giới hạn Gas Ethereum lên 40 triệu.
Bài viết này giải thích tại sao việc tăng Gas Limit của Ethereum lại khó khăn? Rủi ro do tăng Giới hạn Gas Ethereum và các giải pháp liên quan.
1, Giới hạn gas (Giới hạn gas)
Giới hạn gas xác định số lượng công việc được hoàn thành trong một khối và do đó xác định số lượng giao dịch có thể được thực hiện trên mỗi khối. Việc tăng giới hạn gas sẽ cho phép Ethereum xử lý thông lượng giao dịch cao hơn hoặc các giao dịch phức tạp hơn. Trong lịch sử, cài đặt giới hạn gas cụ thể đã bị ảnh hưởng bởi các thợ mỏ/người đặt cược và giới hạn này đã được tăng lên qua nhiều năm. Hình ảnh bên dưới là từ etherscan.io và hiển thị mức sử dụng gas trong lịch sử (rất gần với giới hạn gas, tất cả các mức tăng giới hạn đã được thị trường hấp thụ).
p> p>
2, rủi ro
Bây giờ việc tăng giới hạn gas liên quan đến nhiều rủi ro.
(1) Thiếu tỷ lệ chặn
Tôi đã ở trước đây Như đã đề cập trong bài viết, tỷ lệ chú là chỉ số được thảo luận nhiều nhất khi đánh giá việc tăng gas limit. Bây giờ, sau khi hợp nhất Ethereum, không còn khối chú nào nữa. Cách duy nhất để chúng tôi muốn biết liệu một nút có xử lý tốt giới hạn gas hiện tại hay không là xem xét tốc độ chặn rò rỉ. Nhưng số liệu này có sai sót vì nó chỉ hiển thị các nút hiện đang được cung cấp dưới mức. Nó không cung cấp cho chúng tôi chỉ báo tốt về mức độ tăng giới hạn gas và nó chỉ hiển thị trường hợp trung bình chứ không phải trường hợp xấu nhất có thể xảy ra trong một cuộc tấn công.
(2) kích thước trạng thái
Khối 18418786 ( The ảnh chụp nhanh tài khoản vào ngày 24 tháng 10 năm 2023 là 10,33GB và ảnh chụp nhanh bộ nhớ là 76,59GB, do đó trạng thái tổng thể là khoảng 87GB. Trạng thái của khối 17419840 (ngày 6 tháng 6 năm 2023) nhỏ hơn 80GB một chút. Điều này có nghĩa là tiểu bang đã tăng khoảng 7GB trong 4 tháng, tức là khoảng 2GB mỗi tháng.
Nếu chúng ta sử dụng 87+(2*12*# năm) để ngoại suy thì trạng thái sau một năm sẽ là 111GB và sau 5 năm sẽ là 207GB. Vấn đề ở đây không phải là kích thước. Mọi người đều có thể lưu trữ rất nhiều dữ liệu, nhưng việc truy cập và sửa đổi dữ liệu đó ngày càng chậm hơn.
Đây chỉ là ảnh chụp nhanh, trạng thái chung. Geth cũng cần lưu trữ trạng thái này ở một dạng khác để xác minh trạng thái gốc. Một dạng lưu trữ trạng thái khác (nút trie) cho khối 18418786 yêu cầu khoảng 180GB.
Do đó, tổng kích thước dung lượng hiện chỉ được sử dụng cho bộ nhớ trạng thái là khoảng 267GB. Nếu chúng ta tăng giới hạn gas, kích thước trạng thái sẽ tăng nhanh hơn.
Vấn đề với việc tăng trưởng trạng thái là, không giống như trước đây, chúng ta không có cách rõ ràng để loại bỏ trạng thái. Không có khuyến nghị về thời hạn cụ thể theo từng tiểu bang mà chúng tôi có thể thực hiện nhanh chóng để đưa chúng tôi thoát khỏi trạng thái đang phát triển.
(3) Quy mô lịch sử
Trong năm 2021 của tôi Nó đã được đề cập trong một bài viết rằng một nút geth đầy đủ có dung lượng khoảng 350GB (mới được cắt bớt). Sau khoảng ba năm, một nút geth đầy đủ (trên pbss) vượt quá 900GB. Biểu đồ bên dưới hiển thị tổng khối lượng giao dịch tích lũy. Dễ dàng nhận thấy khối lượng giao dịch đã tăng hơn gấp đôi trong vòng 3 năm, từ xấp xỉ 980 triệu giao dịch lên hơn 2,2 tỷ giao dịch.
p> p>
Với sự gia tăng của L2, quy mô lịch sử đã trở thành một vấn đề lớn hơn vì cách họ lưu trữ dữ liệu hiện nay (trước khi 4844 xuất hiện trực tuyến) là calldata. Khối 18418786 có kích thước khối trên 427GB và khối 17419840 (cũng 4 tháng trước) có kích thước khối là 339GB, nghĩa là tăng trưởng 28GB trong 4 tháng, tức là khoảng 9GB mỗi tháng. Chúng ta có thể ngoại suy mức tăng trưởng này là 427+(9*12*# năm), tức là 535GB sau một năm và 967GB sau 5 năm (một lần nữa giả định tăng trưởng tuyến tính).
Hy vọng mức tăng trưởng này sẽ chậm lại sau khi EIP-4844 đi vào hoạt động, lúc đó L2 sẽ ngừng sử dụng CALLDATA để đảm bảo tính khả dụng của dữ liệu và chuyển sang sử dụng CALLDATA sau vài tuần nữa Blob hết hạn.
EIP-4444 sẽ giải quyết vấn đề tăng trưởng lịch sử vì các nút đầy đủ không còn cần lưu trữ tất cả lịch sử nữa. Việc triển khai EIP-4444 yêu cầu một mạng đáng tin cậy để truy xuất lịch sử trước khi chúng tôi có thể cho phép các nút đầy đủ ngừng cung cấp dữ liệu lịch sử.
(4) Thời gian đồng bộ hóa
Giới hạn gas ở nhiều nơi Các khía cạnh có thể ảnh hưởng đến thời gian đồng bộ hóa:
· Đồng bộ hóa hoàn toàn trở nên rất chậm, nút geth mất hơn một tuần để đồng bộ hóa hoàn toàn chuỗi và các ứng dụng khách khác Tốt hơn chế độ đồng bộ hóa đầy đủ đã được tối ưu hóa.
· Việc đồng bộ hóa dữ liệu lịch sử tương đối chậm. Vì chúng ta cần tải thêm dữ liệu nên phần đồng bộ dữ liệu lịch sử sẽ chậm hơn.
· Trạng thái đồng bộ hóa ảnh chụp nhanh chậm hơn vì chúng tôi cần tải xuống nhiều trạng thái hơn.
· Khôi phục ảnh chụp nhanh chậm. Do điểm xoay chuyển động trong quá trình đồng bộ hóa ảnh chụp nhanh nên chúng tôi có nhiều trạng thái chưa hoàn thiện trên đĩa cần được sửa chữa. Nếu trục di chuyển thường xuyên hơn và có nhiều thay đổi hơn trên mỗi khối thì giai đoạn sửa chữa này sẽ chậm hơn.
· Vì các nút cần trải qua nhiều thay đổi hơn để tạo thành tiêu đề khối nên việc đồng bộ hóa với chuỗi sẽ chậm hơn.
(5) Sự đa dạng của khách hàng
Xây dựng một cái mới Bản thân khách hàng EL là một công việc rất lớn. Việc tăng giới hạn gas còn có thêm nhược điểm là gây khó khăn hơn cho việc xây dựng ứng dụng khách và tối ưu hóa chúng để sử dụng mạng chính. Geth đã được phát triển trong hơn 10 năm với những tối ưu hóa sâu rộng. Có thể có lập luận phản bác rằng khách hàng mới có thể học hỏi từ khách hàng hiện tại và không mắc lại những sai lầm tương tự.
Tuy nhiên, chúng tôi đã thấy các vấn đề trên mạng chính với hai ứng dụng khách (Thông số thực thi được viết bằng python và EthereumJ được viết bằng javascript). Điều này cũng có nghĩa là các ứng dụng khách được viết bằng một số ngôn ngữ nhất định hiện sẽ không hoạt động. Bị giới hạn bởi chi phí ngôn ngữ và độ hoàn thiện của cơ sở mã, việc tăng giới hạn gas sẽ khiến một số khách hàng bị bỏ lại phía sau.
Chúng tôi cũng thấy điều này với KZG, để đạt được hiệu suất cần thiết, hầu hết khách hàng dựa vào việc gọi C-KZG (một mã được viết bằng cơ sở mã C) thay vì hơn là sử dụng thư viện được viết bằng ngôn ngữ họ đã chọn.
(6) Trường hợp xấu nhất
Xem xét khí Khi hạn chế, chúng ta không thể chỉ nhìn vào tình hình chung. Chúng ta luôn phải tính đến trường hợp xấu nhất. Chắc chắn, các nút có thể chạy tốt khi chuỗi ở mức tải trung bình, nhưng điều gì sẽ xảy ra nếu I/O của đĩa đột ngột tăng gấp đôi đối với 5 khối liên tiếp?
Thời gian chạy không phải là số liệu duy nhất chúng ta cần xem xét. Nếu kẻ tấn công có thể chiếm các tài nguyên khác, chẳng hạn như I/O đĩa, thời gian CPU hoặc bộ nhớ, chúng sẽ có thể buộc máy cấu hình thấp hơn nhé. Đặc biệt sau khi sáp nhập Ethereum, việc chạy hai client trên cùng một máy, tấn công một client cũng có thể khiến client kia không ổn định. Trong những ngày đầu thử nghiệm hợp nhất Ethereum, chúng tôi đã chứng kiến một số tình huống rò rỉ bộ nhớ ở một máy khách sẽ làm hỏng toàn bộ hệ thống.
Một trường hợp xấu nhất khác cần xem xét là kích thước bằng chứng. Khi giới hạn gas tăng lên, những thay đổi trạng thái tiềm năng có thể xảy ra giữa hai khối cũng tăng lên. Điều này có tác động đến việc đồng bộ hóa ảnh chụp nhanh đã thảo luận trước đó, nhưng nó cũng ảnh hưởng đến kích thước chứng thực của máy khách hạng nhẹ lớp thực thi. Bây giờ đây không phải là vấn đề lớn, bằng chứng của cây merkle-patricia quá lớn để có thể gửi qua mạng. Tuy nhiên, nếu chúng ta muốn triển khai ý tưởng xác thực chéo chạy nhiều máy khách nhẹ trên cùng một máy thì kích thước bằng chứng sẽ rất quan trọng.
3, giải pháp
Chúng ta xong chưa? ? Chúng ta sẽ luôn giữ giới hạn 30MGas chứ? KHÔNG!
Trong một bài viết năm 2021 của mình, tôi đã đề xuất một giải pháp cho tình thế tiến thoái lưỡng nan mà chúng tôi phải đối mặt vào thời điểm đó. Đối với các vấn đề đồng bộ hóa đầy đủ mà chúng tôi gặp phải trong năm 2021, geth triển khai tính năng đồng bộ hóa nhanh và ảnh chụp nhanh. Đối với các vấn đề về cắt tỉa và bố trí cơ sở dữ liệu, geth triển khai PBSS. Txpool trở nên đáng tin cậy hơn trong việc xử lý lượng giao dịch cao và hầu hết các giao dịch chạy trước MEV đã được chuyển cho các nhà xây dựng. Nhiều giao dịch cũng đã được chuyển sang L2, điều này đã làm tăng quy mô trung bình của các giao dịch trên mạng chính.
Giải pháp duy nhất chưa được triển khai là tái tạo. Các ý kiến đã thay đổi một chút trong những năm qua và hầu hết mọi người dường như đang nghiêng về giai đoạn lịch sử EIP-4444 như một giải pháp ngắn hạn cho sự phát triển dữ liệu lịch sử. Để phát hành EIP-4444, chúng tôi cần một mạng lưới các nút phục vụ dữ liệu lịch sử mạnh mẽ để lịch sử không bị mất ngay cả khi nó không còn được lưu trữ bởi tất cả các nút đầy đủ (BTW, hầu hết các nút Bitcoin hoàn toàn không lưu trữ dữ liệu lịch sử).
Chúng tôi vẫn chưa tìm ra cách thực tế, phù hợp để hạn chế địa vị.
Như bạn đã thấy trong cuộc tấn công trước khi nâng cấp Thượng Hải, có một số cuộc tấn công đã biết khiến chúng tôi không thể tăng gaslimit. Tất cả các lỗi (theo hiểu biết của tôi) đã được giải quyết.
Tại thời điểm viết bài, EIP-4844 đang được phát hành trên testnet. EIP này sẽ tăng các yêu cầu về lưu trữ và I/O của nút. Theo tôi, chờ xem tác động của thay đổi này trên mạng chính là điều an toàn nhất nên làm trước khi thử bất kỳ hình thức tăng giới hạn gas nào. Khi L2 chuyển sang giao dịch blob, chúng ta nên tăng chi phí calldata (vì theo ý kiến của tôi, calldata được định giá thấp hơn so với những thứ khác mà dữ liệu cần được lưu trữ). Đây cũng là chức năng bắt buộc để L2 sử dụng blobspace.
Tóm lại, tôi muốn nhắc mọi người hãy cẩn thận khi xem xét việc tăng giới hạn gas, vì nó sẽ ảnh hưởng đến nhiều khía cạnh của nút và một số ảnh hưởng sẽ được tương đối rõ ràng. Trong các cuộc thảo luận liên quan, điều quan trọng là phải xem xét tác động dài hạn và ngắn hạn của việc thay đổi giới hạn khí.