Tác giả: Vitalik, người sáng lập Ethereum; Bản dịch: Golden Finance xiaozhou
Ngoài những lo ngại về bảo mật mạng, lời chỉ trích phổ biến nhất về việc tăng giới hạn L1 Gas là việc này sẽ khiến việc chạy một nút đầy đủ trở nên khó khăn hơn. Đặc biệt trong bối cảnh lộ trình tập trung vào "gỡ bỏ liên kết các nút đầy đủ", để giải quyết vấn đề này trước tiên cần phải hiểu được tầm quan trọng của các nút đầy đủ.
Quan điểm truyền thống là các nút đầy đủ được sử dụng để xác minh dữ liệu trên chuỗi. Nếu đây là vấn đề duy nhất, thì ZK-EVM sẽ mở khóa khả năng mở rộng L1: hạn chế duy nhất là giữ chi phí xây dựng khối và chứng minh ở mức đủ thấp để vừa duy trì khả năng chống kiểm duyệt 1 trong n vừa cho phép thị trường cạnh tranh.
Nhưng thực tế đây không phải là lý do duy nhất. Một yếu tố quan trọng khác là việc chạy một nút đầy đủ sẽ cung cấp cho bạn một máy chủ RPC cục bộ cho phép bạn đọc dữ liệu trên chuỗi theo cách không cần tin cậy, chống kiểm duyệt và bảo vệ quyền riêng tư. Bài viết này sẽ thảo luận về cách điều chỉnh lộ trình mở rộng L1 hiện tại để đạt được mục tiêu này.
1. Tại sao bạn không hài lòng với tính phi tập trung và quyền riêng tư đạt được của ZK-EVM+PIR?
Lộ trình bảo mật mà tôi công bố vào tháng trước ủng hộ: áp dụng giải pháp TEE+ORAM trong ngắn hạn và chuyển sang công nghệ PIR trong dài hạn. Bằng cách kết hợp xác minh Helios và ZK-EVM, người dùng có thể hoàn toàn tự tin khi kết nối với RPC bên ngoài rằng: (i) dữ liệu chuỗi thu được là chính xác và (ii) quyền riêng tư dữ liệu được bảo vệ. Điều này đặt ra câu hỏi: Tại sao không dừng lại ở đó? Liệu các chương trình mã hóa tiên tiến này có khiến các nút tự lưu trữ trở nên lỗi thời không?
Tôi có một vài phản hồi cho vấn đề này:
--Các chương trình mã hóa hoàn toàn không cần tin cậy (như PIR máy chủ đơn) rất tốn kém. Chi phí hiện tại cao một cách phi thực tế và có khả năng vẫn cao ngay cả sau nhiều lần tối ưu hóa hiệu quả.
--Vấn đề về quyền riêng tư siêu dữ liệu. Siêu dữ liệu như thời gian yêu cầu và mẫu yêu cầu của chính địa chỉ IP sẽ tiết lộ rất nhiều thông tin của người dùng.
--Lỗ hổng kiểm duyệt: Cấu trúc thị trường do một số ít nhà cung cấp RPC thống trị sẽ phải đối mặt với áp lực mạnh mẽ trong việc cấm người dùng hoặc kiểm duyệt. Nhiều nhà cung cấp RPC đã bắt đầu chặn hoàn toàn một số quốc gia.
Do đó, việc tiếp tục đảm bảo sự thuận tiện cho hoạt động của nút cá nhân vẫn có giá trị.
2. Ưu tiên ngắn hạn
Ưu tiên triển khai đầy đủ EIP-4444 và cuối cùng đạt được mục tiêu là mỗi nút chỉ lưu trữ dữ liệu trong khoảng 36 ngày. Điều này sẽ làm giảm đáng kể yêu cầu về dung lượng ổ cứng - rào cản lớn nhất hiện nay ngăn cản mọi người chạy một nút. Sau đó, các yêu cầu lưu trữ nút sẽ chỉ bao gồm: (i) dữ liệu trạng thái, (ii) nhánh Merkle trạng thái và (iii) 36 ngày dữ liệu lịch sử.
Xây dựng giải pháp lưu trữ lịch sử phân tán để mỗi nút lưu trữ một lượng nhỏ dữ liệu lịch sử quá hạn. Tối đa hóa độ tin cậy thông qua công nghệ mã hóa xóa. Điều này đảm bảo tính năng "bảo tồn vĩnh viễn blockchain" mà không cần dựa vào các nhà cung cấp tập trung hoặc tạo gánh nặng cho các nhà điều hành nút.
Điều chỉnh chiến lược giá Gas, tăng chi phí lưu trữ và giảm chi phí thực hiện. Tập trung vào việc tăng chi phí gas của các hoạt động sau: (i) thực hiện SSTORE cho một khe lưu trữ mới, (ii) tạo mã hợp đồng và (iii) chuyển ETH sang tài khoản có số dư bằng 0/không có nonce.
3. Mục tiêu trung hạn: xác minh không trạng thái
Sau khi triển khai xác minh không trạng thái, các nút đang chạy hỗ trợ RPC (tức là các nút lưu trữ trạng thái) sẽ không còn cần phải lưu nhánh Merkel trạng thái nữa. Điều này có thể giảm nhu cầu lưu trữ thêm khoảng 50%.
4. Kiểu nút mới: nút không có trạng thái một phần
Khái niệm sáng tạo này sẽ là chìa khóa để duy trì hoạt động của các nút cá nhân sau khi giới hạn L1 Gas tăng lên 10-100 lần.
Chúng tôi đã thêm một loại nút mới: xác minh các khối theo cách không có trạng thái, xác minh toàn bộ chuỗi thông qua xác minh không có trạng thái hoặc ZK-EVM, nhưng chỉ duy trì một phần dữ liệu trạng thái. Miễn là dữ liệu mà yêu cầu RPC yêu cầu nằm trong tập hợp con trạng thái này thì nút sẽ có thể phản hồi; các yêu cầu khác sẽ không thành công (hoặc cần phải chuyển sang giải pháp mã hóa được lưu trữ bên ngoài - việc có chuyển sang giải pháp khác hay không tùy thuộc vào lựa chọn của người dùng).

Cụ thể, trạng thái nào được duy trì phụ thuộc vào cấu hình của người dùng, ví dụ:
-- Loại trừ tất cả các trạng thái ngoại trừ các hợp đồng rác đã biết.
--Trạng thái liên quan đến tất cả các tài khoản EOA, SCW và các mã thông báo và ứng dụng ERC20/ERC721 thường dùng.
--Trạng thái tài khoản EOA/SCW đang hoạt động trong hai năm qua + trạng thái của một số token ERC20 thường dùng + trạng thái của các ứng dụng hoán đổi/DeFi/quyền riêng tư đã chọn.
Cấu hình có thể được quản lý thông qua hợp đồng trên chuỗi: người dùng sử dụng tham số "--save_state_by_config 0x12345...67890" khi chạy một nút. Địa chỉ này sẽ xác định danh sách địa chỉ, khe lưu trữ hoặc quy tắc lọc trạng thái mà nút cần lưu và cập nhật theo thời gian thực bằng một ngôn ngữ cụ thể. Lưu ý rằng người dùng không cần phải lưu nhánh Merkle, chỉ cần lưu giá trị ban đầu.
Các nút như vậy mang lại lợi thế là có thể truy cập trực tiếp cục bộ vào các trạng thái quan trọng đồng thời đảm bảo quyền riêng tư khi truy cập hoàn toàn.