Tác giả: Vitalik, người sáng lập Ethereum; Biên dịch: Jinse Finance xiaozhou
Sự phê bình phổ biến nhất đối với việc nâng cao giới hạn Gas L1, ngoài lo ngại về an ninh mạng, là điều này sẽ làm cho việc vận hành các nút đầy đủ trở nên khó khăn hơn. Đặc biệt trong bối cảnh lộ trình lấy "gỡ liên kết nút đầy đủ" làm trung tâm, để giải quyết vấn đề này cần phải hiểu rõ ý nghĩa của việc tồn tại các nút đầy đủ.
Quan điểm truyền thống cho rằng 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 có thể mở khóa khả năng mở rộng L1: hạn chế duy nhất là giữ cho chi phí xây dựng khối và chứng minh đủ thấp, để cả hai có thể duy trì tính kháng kiểm duyệt 1 trong n và hình thành thị trường cạnh tranh.
Nhưng trong 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 vận hành nút đầy đủ 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à bảo mật được thực hiện bởi ZK-EVM+PIR?
Lộ trình bảo mật mà tôi công bố vào tháng trước đề xuất: trong ngắn hạn áp dụng giải pháp TEE + ORAM, còn trong dài hạn thì chuyển sang công nghệ PIR. Kết hợp giữa Helios và xác minh 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 nhận được là chính xác, (ii) quyền riêng tư dữ liệu được bảo vệ. Điều này đặt ra một câu hỏi: Tại sao không dừng lại ở đây? Những giải pháp mật mã tiên tiến này có khiến cho các nút tự quản trở nên lỗi thời không?
Về vấn đề 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 máy chủ đơn) có chi phí rất cao. Chi phí hiện tại quá cao đến mức không thực tế, ngay cả khi đã trải qua nhiều tối ưu hóa hiệu suất vẫn có thể duy trì mức 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ẽ tự nó tiết lộ một lượng lớn thông tin người dùng.
--**Kiểm tra điểm yếu: ** 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 kiểm duyệt hoặc cấm người dùng mạnh mẽ. 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、các ư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ục tiêu 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ề không gian ổ cứng - rào cản chính hiện tại cản trở 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) dữ liệu lịch sử 36 ngày.
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ã sửa lỗi. Như vậy vừa đảm bảo đặc tính "lưu trữ vĩnh viễn của blockchain", vừa không cần dựa 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 chi phí lưu trữ và 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 một khe 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ư/nonce bằng 0.
3.Mục tiêu trung hạn: Xác minh không trạng thái
Sau khi thực hiện xác minh 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 phải 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ố node 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 đến 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 yêu cầu RPC nằm trong tập con 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ã được lưu trữ bên ngoài—việc quay lại hay không do người dùng chọn).
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, chẳng hạn như:
--Loại trừ tất cả cá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ả EOA, tài khoản 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 2 năm qua + Trạng thái một số token ERC20 thường dùng + Trạng thái các ứng dụng swap/DeFi/bảo mật được 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 khi chạy nút sử dụng tham số "--save_state_by_config 0x12345...67890", địa chỉ này sẽ định nghĩa danh sách địa chỉ cần lưu và cập nhật theo thời gian thực bằng ngôn ngữ cụ thể, khe lưu trữ (storage slot) hoặc quy tắc lọc trạng thái. Lưu ý 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 vừa cung cấp lợi thế truy cập trực tiếp tại chỗ vào trạng thái quan trọng, vừa đảm bảo tính riêng tư truy cập hoàn toàn.
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
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
Sự phê bình phổ biến nhất đối với việc nâng cao giới hạn Gas L1, ngoài lo ngại về an ninh mạng, là điều này sẽ làm cho việc vận hành các nút đầy đủ trở nên khó khăn hơn. Đặc biệt trong bối cảnh lộ trình lấy "gỡ liên kết nút đầy đủ" làm trung tâm, để giải quyết vấn đề này cần phải hiểu rõ ý nghĩa của việc tồn tại các nút đầy đủ.
Quan điểm truyền thống cho rằng 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 có thể mở khóa khả năng mở rộng L1: hạn chế duy nhất là giữ cho chi phí xây dựng khối và chứng minh đủ thấp, để cả hai có thể duy trì tính kháng kiểm duyệt 1 trong n và hình thành thị trường cạnh tranh.
Nhưng trong 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 vận hành nút đầy đủ 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à bảo mật được thực hiện bởi ZK-EVM+PIR?
Lộ trình bảo mật mà tôi công bố vào tháng trước đề xuất: trong ngắn hạn áp dụng giải pháp TEE + ORAM, còn trong dài hạn thì chuyển sang công nghệ PIR. Kết hợp giữa Helios và xác minh 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 nhận được là chính xác, (ii) quyền riêng tư dữ liệu được bảo vệ. Điều này đặt ra một câu hỏi: Tại sao không dừng lại ở đây? Những giải pháp mật mã tiên tiến này có khiến cho các nút tự quản trở nên lỗi thời không?
Về vấn đề 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 máy chủ đơn) có chi phí rất cao. Chi phí hiện tại quá cao đến mức không thực tế, ngay cả khi đã trải qua nhiều tối ưu hóa hiệu suất vẫn có thể duy trì mức 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ẽ tự nó tiết lộ một lượng lớn thông tin người dùng.
--**Kiểm tra điểm yếu: ** 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 kiểm duyệt hoặc cấm người dùng mạnh mẽ. 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、các ư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ục tiêu 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ề không gian ổ cứng - rào cản chính hiện tại cản trở 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) dữ liệu lịch sử 36 ngày.
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ã sửa lỗi. Như vậy vừa đảm bảo đặc tính "lưu trữ vĩnh viễn của blockchain", vừa không cần dựa 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 chi phí lưu trữ và 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 một khe 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ư/nonce bằng 0.
3.Mục tiêu trung hạn: Xác minh không trạng thái
Sau khi thực hiện xác minh 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 phải 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ố node 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 đến 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 yêu cầu RPC nằm trong tập con 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ã được lưu trữ bên ngoài—việc quay lại hay không do người dùng chọn).
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, chẳng hạn như:
--Loại trừ tất cả cá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ả EOA, tài khoản 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 2 năm qua + Trạng thái một số token ERC20 thường dùng + Trạng thái các ứng dụng swap/DeFi/bảo mật được 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 khi chạy nút sử dụng tham số "--save_state_by_config 0x12345...67890", địa chỉ này sẽ định nghĩa danh sách địa chỉ cần lưu và cập nhật theo thời gian thực bằng ngôn ngữ cụ thể, khe lưu trữ (storage slot) hoặc quy tắc lọc trạng thái. Lưu ý 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 vừa cung cấp lợi thế truy cập trực tiếp tại chỗ vào trạng thái quan trọng, vừa đảm bảo tính riêng tư truy cập hoàn toàn.