Phê bình phổ biến nhất về việc nâng cao giới hạn Gas L1, ngoài mối lo ngại về an ninh mạng, chính là điều này sẽ khiến việc vận hành nút đầy đủ trở nên khó khăn hơn. Đặc biệt trong bối cảnh lộ trình với trọng tâm là "gỡ bỏ nút đầy đủ", để giải quyết vấn đề này cần hiểu rõ ý nghĩa của việc tồn tại nút đầy đủ.
Quan điểm truyền thống cho rằng nút đầy đủ được sử dụng để xác thực dữ liệu trên chuỗi. Nếu đây là vấn đề duy nhất, thì ZK-EVM có thể mở khóa khả năng mở rộng L1: giới hạn duy nhất là giữ cho chi phí xây dựng khối và chứng minh đủ thấp, để cả hai vừa duy trì được khả năng chống kiểm duyệt 1 trong n, vừa hình thành thị trường cạnh tranh.
Nhưng trên thực tế, đây không phải là yếu tố duy nhất cần xem xét. Một yếu tố quan trọng khác là: việc chạy nút đầy đủ sẽ cho phép bạn có máy chủ RPC cục bộ, từ đó đọc dữ liệu trên chuỗi một cách không cần tin tưởng, 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 không hài lòng với việc phi tập trung và quyền riêng tư do ZK-EVM+PIR mang lại?
Lộ trình bảo mật mà tôi đã công bố vào tháng trước ủng hộ việc áp dụng TEE + ORAM trong ngắn hạn và chuyển sang công nghệ PIR trong dài hạn. Kết hợp với xác thực Helios và ZK-EVM, người dùng có thể kết nối với RPC bên ngoài với sự tự tin hoàn toàn rằng (i) đang nhận được dữ liệu chuỗi chính xác và quyền riêng tư dữ liệu (ii) được bảo vệ. Điều này đặt ra câu hỏi: tại sao không dừng lại ở đó? Các sơ đồ mật mã nâng cao này có làm cho các nút tự lưu trữ trở nên lỗi thời không?
Đối với điều này, tôi có một vài phản hồi:
Các giải pháp mật mã hoàn toàn không cần tin cậy (như PIR trên một máy chủ) có chi phí rất cao. Chi phí hiện tại cao đến mức không thực tế, ngay cả khi đã qua nhiều lần tối ưu hóa hiệu suất vẫn có thể duy trì giá cao.
Vấn đề quyền riêng tư của siêu dữ liệu. Thời gian yêu cầu địa chỉ IP, mô hình yêu cầu và các siêu dữ liệu khác sẽ tiết lộ một lượng lớn thông tin người dùng.
Kiểm tra lỗ hổng: Cấu trúc thị trường do một số nhà cung cấp RPC chi phối sẽ phải đối mặt với áp lực mạnh mẽ từ việc cấm hoặc kiểm duyệt người dùng. Nhiều nhà cung cấp RPC đã bắt đầu hoàn toàn chặn một số quốc gia.
Do đó, việc tiếp tục đảm bảo tính tiện lợi cho việc vận hành các nút cá nhân vẫn có giá trị.
2、ưu tiên ngắn hạn
Ưu tiên triển khai toàn diện EIP-4444, cuối cùng đạt được mỗi nút chỉ lưu trữ khoảng 36 ngày dữ liệu. Điều này sẽ giảm đáng kể nhu cầu về dung lượng ổ cứng - rào cản chính hiện nay ngăn cản mọi người vận hành nút. Sau đó, nhu cầu lưu trữ của nút sẽ chỉ bao gồm: (i) dữ liệu trạng thái, (ii) nhánh Merkle trạng thái, (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, cho phép 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ã sửa lỗi. Điều này không chỉ đảm bảo đặc tính "lưu trữ vĩnh viễn của blockchain" mà còn không cần phụ thuộc vào nhà cung cấp tập trung hoặc tạo gánh nặng nặng nề cho người điều hành nút.
Điều chỉnh chiến lược định giá Gas, tăng cường chi phí lưu trữ, giảm chi phí thực thi. Tập trung vào việc tăng chi phí Gas cho các thao tác sau: (i) thực hiện SSTORE cho ô lưu trữ mới (storage slot), (ii) tạo mã hợp đồng, (iii) chuyển ETH cho tài khoản có số dư bằng 0 / nonce bằng 0.
3, Mục tiêu trung hạn: Xác thực không trạng thái
Sau khi thực hiện xác thực không trạng thái, các nút hỗ trợ RPC (tức là các nút lưu trữ trạng thái) sẽ không cần lưu trữ nhánh merkle trạng thái. Điều này có thể giảm nhu cầu lưu trữ thêm khoảng 50%.
4, Node mới: Một số nút không trạng thái
Ý tưởng đổi mới này sẽ trở thành chìa khóa để duy trì hoạt động của các nút cá nhân ngay cả khi giới hạn gas L1 tăng từ 10-100 lần.
Chúng tôi đã thêm một loại nút mới: xác thực khối theo cách không trạng thái, xác thực toàn bộ chuỗi thông qua xác thực không trạng thái hoặc ZK-EVM, nhưng chỉ duy trì một phần dữ liệu trạng thái. Chỉ cần dữ liệu cần thiết cho yêu cầu RPC nằm trong tập hợp trạng thái này, nút có thể phản hồi; các yêu cầu khác sẽ thất bại (hoặc cần quay lại giải pháp mật mã lưu trữ bên ngoài - việc quay lại này do người dùng quyết định).
Cụ thể duy trì trạng thái nào phụ thuộc vào cấu hình của người dùng, ví dụ:
Loại bỏ tất cả trạng thái ngoài 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 token và ứng dụng ERC20/ERC721 thường dùng.
Trạng thái tài khoản EOA/SCW hoạt động trong hai năm gần đây + Trạng thái một số mã thông báo ERC20 thông dụng + Trạng thái các ứng dụng swap/DeFi/riêng tư được chọn lọc.
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 nút, địa chỉ này sẽ định nghĩa danh sách địa chỉ mà nút cần lưu và cập nhật theo thời gian thực bằng ngôn ngữ cụ thể, các khe lưu trữ (storage slot) hoặc quy tắc lọc trạng thái. Lưu ý rằng người dùng không cần lưu nhánh Merkle, chỉ cần lưu giá trị gốc.
Các nút loại này không chỉ cung cấp lợi thế truy cập trực tiếp cục bộ đến trạng thái quan trọng mà còn đảm bảo tính riêng tư hoàn toàn trong việc truy cập.
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Vitalik: Một kế hoạch tối ưu hóa lộ trình mở rộng tập trung vào các Nút địa phương
Tác giả: Vitalik, người sáng lập Ethereum
Biên dịch: Jinse Finance xiaozhou
Phê bình phổ biến nhất về việc nâng cao giới hạn Gas L1, ngoài mối lo ngại về an ninh mạng, chính là điều này sẽ khiến việc vận hành nút đầy đủ trở nên khó khăn hơn. Đặc biệt trong bối cảnh lộ trình với trọng tâm là "gỡ bỏ nút đầy đủ", để giải quyết vấn đề này cần hiểu rõ ý nghĩa của việc tồn tại nút đầy đủ.
Quan điểm truyền thống cho rằng nút đầy đủ được sử dụng để xác thực dữ liệu trên chuỗi. Nếu đây là vấn đề duy nhất, thì ZK-EVM có thể mở khóa khả năng mở rộng L1: giới hạn duy nhất là giữ cho chi phí xây dựng khối và chứng minh đủ thấp, để cả hai vừa duy trì được khả năng chống kiểm duyệt 1 trong n, vừa hình thành thị trường cạnh tranh.
Nhưng trên thực tế, đây không phải là yếu tố duy nhất cần xem xét. Một yếu tố quan trọng khác là: việc chạy nút đầy đủ sẽ cho phép bạn có máy chủ RPC cục bộ, từ đó đọc dữ liệu trên chuỗi một cách không cần tin tưởng, 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 không hài lòng với việc phi tập trung và quyền riêng tư do ZK-EVM+PIR mang lại?
Lộ trình bảo mật mà tôi đã công bố vào tháng trước ủng hộ việc áp dụng TEE + ORAM trong ngắn hạn và chuyển sang công nghệ PIR trong dài hạn. Kết hợp với xác thực Helios và ZK-EVM, người dùng có thể kết nối với RPC bên ngoài với sự tự tin hoàn toàn rằng (i) đang nhận được dữ liệu chuỗi chính xác và quyền riêng tư dữ liệu (ii) được bảo vệ. Điều này đặt ra câu hỏi: tại sao không dừng lại ở đó? Các sơ đồ mật mã nâng cao này có làm cho các nút tự lưu trữ trở nên lỗi thời không?
Đối với điều này, tôi có một vài phản hồi:
Các giải pháp mật mã hoàn toàn không cần tin cậy (như PIR trên một máy chủ) có chi phí rất cao. Chi phí hiện tại cao đến mức không thực tế, ngay cả khi đã qua nhiều lần tối ưu hóa hiệu suất vẫn có thể duy trì giá cao.
Vấn đề quyền riêng tư của siêu dữ liệu. Thời gian yêu cầu địa chỉ IP, mô hình yêu cầu và các siêu dữ liệu khác sẽ tiết lộ một lượng lớn thông tin người dùng.
Kiểm tra lỗ hổng: Cấu trúc thị trường do một số nhà cung cấp RPC chi phối sẽ phải đối mặt với áp lực mạnh mẽ từ việc cấm hoặc kiểm duyệt người dùng. Nhiều nhà cung cấp RPC đã bắt đầu hoàn toàn chặn một số quốc gia.
Do đó, việc tiếp tục đảm bảo tính tiện lợi cho việc vận hành các nút cá nhân vẫn có giá trị.
2、ưu tiên ngắn hạn
Ưu tiên triển khai toàn diện EIP-4444, cuối cùng đạt được mỗi nút chỉ lưu trữ khoảng 36 ngày dữ liệu. Điều này sẽ giảm đáng kể nhu cầu về dung lượng ổ cứng - rào cản chính hiện nay ngăn cản mọi người vận hành nút. Sau đó, nhu cầu lưu trữ của nút sẽ chỉ bao gồm: (i) dữ liệu trạng thái, (ii) nhánh Merkle trạng thái, (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, cho phép 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ã sửa lỗi. Điều này không chỉ đảm bảo đặc tính "lưu trữ vĩnh viễn của blockchain" mà còn không cần phụ thuộc vào nhà cung cấp tập trung hoặc tạo gánh nặng nặng nề cho người điều hành nút.
Điều chỉnh chiến lược định giá Gas, tăng cường chi phí lưu trữ, giảm chi phí thực thi. Tập trung vào việc tăng chi phí Gas cho các thao tác sau: (i) thực hiện SSTORE cho ô lưu trữ mới (storage slot), (ii) tạo mã hợp đồng, (iii) chuyển ETH cho tài khoản có số dư bằng 0 / nonce bằng 0.
3, Mục tiêu trung hạn: Xác thực không trạng thái
Sau khi thực hiện xác thực không trạng thái, các nút hỗ trợ RPC (tức là các nút lưu trữ trạng thái) sẽ không cần lưu trữ nhánh merkle trạng thái. Điều này có thể giảm nhu cầu lưu trữ thêm khoảng 50%.
4, Node mới: Một số nút không trạng thái
Ý tưởng đổi mới này sẽ trở thành chìa khóa để duy trì hoạt động của các nút cá nhân ngay cả khi giới hạn gas L1 tăng từ 10-100 lần.
Chúng tôi đã thêm một loại nút mới: xác thực khối theo cách không trạng thái, xác thực toàn bộ chuỗi thông qua xác thực không trạng thái hoặc ZK-EVM, nhưng chỉ duy trì một phần dữ liệu trạng thái. Chỉ cần dữ liệu cần thiết cho yêu cầu RPC nằm trong tập hợp trạng thái này, nút có thể phản hồi; các yêu cầu khác sẽ thất bại (hoặc cần quay lại giải pháp mật mã lưu trữ bên ngoài - việc quay lại này do người dùng quyết định).
Cụ thể duy trì trạng thái nào phụ thuộc vào cấu hình của người dùng, ví dụ:
Loại bỏ tất cả trạng thái ngoài 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 token và ứng dụng ERC20/ERC721 thường dùng.
Trạng thái tài khoản EOA/SCW hoạt động trong hai năm gần đây + Trạng thái một số mã thông báo ERC20 thông dụng + Trạng thái các ứng dụng swap/DeFi/riêng tư được chọn lọc.
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 nút, địa chỉ này sẽ định nghĩa danh sách địa chỉ mà nút cần lưu và cập nhật theo thời gian thực bằng ngôn ngữ cụ thể, các khe lưu trữ (storage slot) hoặc quy tắc lọc trạng thái. Lưu ý rằng người dùng không cần lưu nhánh Merkle, chỉ cần lưu giá trị gốc.
Các nút loại này không chỉ cung cấp lợi thế truy cập trực tiếp cục bộ đến trạng thái quan trọng mà còn đảm bảo tính riêng tư hoàn toàn trong việc truy cập.