Xin chân thành cảm ơn Micah Zoltu, Toni Wahrstätter, Justin Traglia và pcaversaccio đã thảo luận
Lời chỉ trích phổ biến nhất về việc tăng Gas Limit L1, ngoài những lo ngại về an toàn mạng, là việc này 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 việc tách rời toàn bộ nút, việc giải quyết vấn đề này đòi hỏi phải hiểu toàn bộ nút dùng để làm gì .
Theo truyền thống, suy nghĩ cho rằng các nút đầy đủ là để xác thực chuỗi ; xem tại đây để biết bài trình bày của riêng tôi về những gì có thể xảy ra nếu người dùng thông thường không thể xác minh. Nếu đây là vấn đề duy nhất, thì khả năng mở rộng L1 được mở khóa bằng ZK-EVM: giới hạn duy nhất là giữ cho chi phí xây dựng Block và chứng minh đủ thấp để cả hai đều có thể duy trì khả năng chống kiểm duyệt 1-trong-n và là một thị trường cạnh tranh.
Tuy nhiên, trên thực tế, đây không phải là mối quan tâm duy nhất. Mối quan tâm lớn khác là: có một nút đầy đủ là rất có giá trị để bạn có thể có một máy chủ RPC cục bộ mà bạn có thể sử dụng để đọc chuỗi theo cách Không cần tin cậy, chống kiểm duyệt và thân thiện với quyền riêng tư . Tài liệu này sẽ thảo luận về các điều chỉnh đối với lộ trình mở rộng L1 hiện tại giúp điều này xảy ra.
Tại sao không dừng lại ở sự tin cậy và riêng tư thông qua ZK-EVM + PIR?
Lộ trình bảo mật mà tôi đã công bố vào tháng trước tập trung vào TEE + ORAM như một bản vá ngắn hạn cộng với PIR như một giải pháp dài hạn. Điều này, cùng với Helios và xác minh ZK-EVM, sẽ cho phép bất kỳ người dùng nào kết nối với RPC bên ngoài và hoàn toàn tự tin rằng (i) chuỗi họ đang nhận được là chính xác và (ii) quyền riêng tư dữ liệu của họ được bảo vệ. Vì vậy, câu hỏi đáng để đặt ra là: tại sao không dừng lại ở đây? Những giải pháp mật mã tiên tiến như thế này không khiến các nút tự lưu trữ trở thành di tích lỗi thời sao?
Sau đây tôi có thể đưa ra một vài câu trả lời:
- Các giải pháp mã hóa hoàn toàn Không cần tin cậy (ví dụ: PIR 1 máy chủ) sẽ tốn kém . Hiện tại, chi phí chung cao đến mức không thực tế và thậm chí sau nhiều cải tiến về hiệu quả, chi phí này vẫn có khả năng cao.
- Quyền riêng tư của siêu dữ liệu . Dữ liệu về địa chỉ IP nào thực hiện yêu cầu vào thời điểm nào và mẫu yêu cầu tự nó đã đủ để tiết lộ rất nhiều thông tin về người dùng.
- Lỗ hổng kiểm duyệt : mộ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ẽ để loại bỏ nền tảng hoặc kiểm duyệt người dùng. Nhiều nhà cung cấp RPC đã loại trừ toàn bộ các quốc gia.
Vì những lý do này, việc tiếp tục đảm bảo việc chạy một nút cá nhân dễ dàng hơn là rất có giá trị.
Ưu tiên ngắn hạn
- Ưu tiên triển khai toàn bộ Đề xuất cải tiến Ethereum (EIP)-4444 , cho đến trạng thái cuối cùng khi mỗi nút chỉ lưu trữ dữ liệu trong khoảng ~36 ngày. Điều này làm giảm đáng kể yêu cầu về dung lượng đĩa, đây là vấn đề chính ngăn cản nhiều người chạy các nút hơn. Sau đó, yêu cầu về dung lượng đĩa cho một nút sẽ là (i) kích thước trạng thái, (ii) nhánh Merkle trạng thái, (iii) 36 ngày lịch sử.
- Xây dựng giải pháp lưu trữ lịch sử phân tán , theo đó mỗi nút có thể lưu trữ một tỷ lệ nhỏ dữ liệu lịch sử cũ hơn ngưỡng. Sử dụng mã hóa xóa để tối đa hóa tính mạnh mẽ. Điều này đảm bảo tính chất "chuỗi khối tồn tại mãi mãi" mà không phụ thuộc 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 giá gas để làm cho việc lưu trữ đắt hơn và việc thực hiện ít tốn kém hơn . Một ưu tiên đặc biệt cao là tăng chi phí gas khi tạo trạng thái mới : (i) SSTORE cho các khe lưu trữ mới, (ii) tạo mã hợp đồng, (iii) gửi ETH đến các tài khoản chưa có số dư hoặc Nonce.
Ưu tiên trung hạn: xác minh không quốc tịch
Khi chúng tôi kích hoạt xác minh không trạng thái, có thể chạy một nút có khả năng RPC (tức là nút lưu trữ trạng thái) mà không cần lưu trữ các nhánh Merkle trạng thái. Điều này làm giảm thêm yêu cầu lưu trữ khoảng 2 lần.
Một loại nút mới: nút không có trạng thái một phần
Đây là ý tưởng mới và sẽ là chìa khóa cho phép vận hành nút cá nhân ngay cả trong bối cảnh Gas Limit L1 tăng từ 10-100 lần.
Chúng tôi thêm một loại nút xác minh khối không có trạng thái và xác minh toàn bộ chuỗi (thông qua xác thực không có trạng thái hoặc ZK-EVM) và cập nhật một phần trạng thái. Nút có khả năng phản hồi các yêu cầu RPC miễn là dữ liệu được yêu cầu nằm trong tập hợp con đó của trạng thái; các yêu cầu khác sẽ không thành công (hoặc phải chuyển sang giải pháp mật mã được lưu trữ bên ngoài; việc có thực hiện điều này hay không là tùy thuộc vào lựa chọn của người dùng).
Phần chính xác của trạng thái được giữ sẽ phụ thuộc vào cấu hình do người dùng chọn. Một số ví dụ có thể là:
- Tất cả các tiểu bang ngoại trừ các hợp đồng được biết là thư rác
- Trạng thái liên quan đến tất cả các EOA và SCW và tất cả các mã thông báo và ứng dụng ERC20 và ERC721 thường được sử dụng
- Trạng thái liên quan đến tất cả các EOA và SCW đã được truy cập trong hai năm qua, một số mã thông báo ERC20 thường được sử dụng, cùng với một bộ ứng dụng hoán đổi, DeFi và quyền riêng tư được quản lý hạn chế
Cấu hình có thể được quản lý bằng hợp đồng onchain: người dùng sẽ chạy nút của họ với --save_state_by_config 0x12345...67890 và địa chỉ sẽ chỉ định bằng một số ngôn ngữ danh sách các địa chỉ, khe lưu trữ hoặc các vùng được lọc khác của trạng thái mà nút sẽ lưu và cập nhật. Lưu ý rằng người dùng không cần lưu các nhánh Merkle; họ chỉ cần lưu các giá trị thô.
Loại nút này sẽ mang lại lợi ích là truy cập cục bộ trực tiếp vào trạng thái mà người dùng cần quan tâm, cũng như quyền riêng tư tối đa khi truy cập vào trạng thái đó.
