Trong Ethereum, đôi khi một thay đổi nghe rất kỹ thuật lại kéo theo một cuộc tranh luận kiến trúc lớn. EIP-8250 là ví dụ như vậy. Trọng tâm của đề xuất chỉ là cách đánh số nonce cho một loại giao dịch cụ thể, nhưng phía sau là câu hỏi lớn hơn: Ethereum nên quản lý dữ liệu quyền riêng tư và trạng thái dài hạn như thế nào để không làm mạng lưới phình to quá mức?

Nói ngắn gọn, EIP-8250 đề xuất thay một nonce tuyến tính của người gửi trong giao dịch frame theo EIP-8141 bằng cặp

(nonce_key, nonce_seq)

nonce_key == 0

[1]

[12]

EIP-8250 thay đổi điều gì?

Nonce trong blockchain có thể hiểu là số thứ tự chống phát lại: nó giúp đảm bảo một giao dịch đã dùng rồi không thể bị gửi lại như mới. Trong bối cảnh EIP-8250 nhắm tới, mô hình giao dịch frame hiện tiêu thụ một nonce tuyến tính theo từng người gửi ^[1].

EIP-8250 thay mô hình đó bằng hai trường:

• nonce_key: khóa chọn miền chống phát lại.
• nonce_seq: số thứ tự bên trong miền đó.

Theo thảo luận trên Ethereum Magicians, các khóa khác 0 được lưu trong một hợp đồng hệ thống NONCE_MANAGER, và giao dịch nằm trên các khóa khác 0 khác nhau sẽ độc lập về chống phát lại ^[1]. Nói nôm na, thay vì một hàng đợi duy nhất cho cả tài khoản, EIP-8250 tạo ra nhiều làn có khóa.

Điểm cần nhấn mạnh: điều này không có nghĩa mọi giao dịch Ethereum sẽ trở nên không thứ tự hoặc được xử lý song song. Phạm vi của đề xuất là giao dịch frame theo EIP-8141; khóa 0 vẫn giữ hành vi nonce tài khoản truyền thống ^[1].

Vì sao một nonce duy nhất có thể gây nghẽn cho giao thức quyền riêng tư?

Nút thắt dễ thấy nhất xuất hiện khi nhiều người dùng không liên quan được định tuyến qua một địa chỉ gửi chung. ETH Daily mô tả EIP-8250 là đặc biệt hữu ích với các giao thức quyền riêng tư, vì các giao thức này có thể đưa nhiều luồng người dùng độc lập qua cùng một địa chỉ ^[12]. Nếu địa chỉ đó chỉ có một nonce tuyến tính, một giao dịch frame bị chậm có thể chặn mọi giao dịch frame phía sau cùng người gửi ^[1][12].

Nonce theo khóa chia hàng đợi chống phát lại đó thành nhiều miền độc lập. Một giao thức quyền riêng tư có thể phân các luồng không liên quan vào các khóa nonce khác nhau, để chúng không phải tranh nhau cùng một số thứ tự của người gửi ^[1]. Đây trước hết là cải thiện về chống phát lại và thông lượng, không phải một hệ thống ẩn danh hoàn chỉnh.

Liên hệ với quyền riêng tư: nullifier là gì?

Nonce theo khóa không tự che giấu số dư, người nhận hay số tiền giao dịch. Một đề xuất riêng về chuyển ETH và ERC-20 ở chế độ riêng tư, EIP-8182, mô tả rằng chuyển tiền riêng tư cần thêm nhiều thành phần: hợp đồng hệ thống, precompile xác minh bằng chứng, note, cơ chế nạp, chuyển riêng tư và rút tiền ^[9].

Mối liên hệ của EIP-8250 với mở rộng quyền riêng tư hẹp hơn nhưng quan trọng. Các báo cáo quanh EIP-8250 thường dùng nullifier làm ví dụ chính cho loại dữ liệu trạng thái quyền riêng tư tăng dần theo thời gian và không thể cắt bỏ sau khi đã vào hệ thống ^[3][4]. Trong các hệ thống quyền riêng tư, bản ghi kiểu nullifier được dùng để ngăn trạng thái riêng tư đã tiêu bị dùng lại; vì chúng phải luôn có thể được kiểm tra, chúng có thể trở thành gánh nặng trạng thái dài hạn ^[3][4].

Nhìn theo cách này, EIP-8250 không phải là giao thức quyền riêng tư zero-knowledge. Nó giống một primitive ở tầng giao thức để quản lý nhiều chuỗi dùng một lần độc lập; vì vậy, các nhà quan sát liên hệ nó với kho nullifier chuyên dụng và những thiết kế trạng thái phục vụ mục đích hẹp ^[1][4][10].

Tranh luận lớn hơn: mở rộng trạng thái Ethereum

Vitalik Buterin và các bản tóm lược thứ cấp nhìn nonce theo khóa như một bước đầu hướng tới trạng thái chuyên dụng: thay vì đưa mọi loại dữ liệu vào trạng thái động tổng quát của Ethereum, một số loại dữ liệu hẹp có thể có cơ chế lưu trữ tối ưu cho cách chúng được truy cập ^[4][5][10].

Trường hợp gây áp lực là nullifier của giao dịch riêng tư. Nhiều báo cáo nhắc lại ví dụ: nếu giao dịch riêng tư on-chain duy trì 2.000 giao dịch mỗi giây trong 8 năm, hệ thống có thể tạo ra khoảng 500 tỷ nullifier ^[2][5][7]. Con số này nên được hiểu là minh họa về quy mô, không phải bằng chứng rằng một lộ trình triển khai đã được kích hoạt, vì cơ chế EIP-8250 hiện được mô tả trong thảo luận Ethereum Magicians gắn với một pull request EIP ^[1].

Một số báo cáo mô tả kho nullifier chuyên dụng, có thể dùng sharding và Bloom filter, như một cách giúp node quản lý dữ liệu khối lượng lớn dễ hơn so với việc đặt tất cả vào trạng thái động tổng quát ^[2][14]. Ý tưởng rộng hơn là: với các workload hẹp và có quy luật truy cập rõ ràng, lưu trữ chuyên biệt có thể mở rộng tốt hơn mà vẫn hướng tới mục tiêu giữ Ethereum phi tập trung ^[5][10].

EIP-8250 có thể cải thiện những gì?

• Thông lượng khi dùng địa chỉ gửi chung: nếu một giao thức quyền riêng tư định tuyến nhiều người dùng qua cùng một địa chỉ, các khóa độc lập có thể giảm khả năng những luồng không liên quan phải chờ cùng một nonce của người gửi ^[1][12].
• Tách miền chống phát lại: EIP-8250 nêu rõ giao dịch trên các khóa khác 0 khác nhau là độc lập về chống phát lại ^[1].
• Hỗ trợ quyền riêng tư ở tầng giao thức rõ hơn: các báo cáo mô tả nonce theo khóa là cách tăng hỗ trợ cấp giao thức cho quyền riêng tư on-chain, thay vì để mọi logic kiểu replay/nullifier nằm hoàn toàn trong hợp đồng ứng dụng ^[4][5].
• Mở đường cho trạng thái chuyên dụng: lập luận lớn hơn là Ethereum có thể dùng cấu trúc lưu trữ được thiết kế riêng cho một số nhu cầu, thay vì coi mọi dữ liệu trạng thái như một chiếc thùng tổng quát duy nhất ^[4][10].

Không nên hiểu quá đà

• EIP-8250 không thay thế mọi nonce trên Ethereum. Đề xuất chỉ nhắm tới giao dịch frame theo EIP-8141, trong đó

  nonce_key == 0

  vẫn ánh xạ về nonce tài khoản truyền thống ^[1].
• Nó không tự biến giao dịch thành riêng tư. Chuyển tiền riêng tư cần thêm các thành phần như note, xác minh bằng chứng, quy tắc nạp, chuyển và rút, như EIP-8182 minh họa ^[9].
• Nó không bảo đảm Ethereum sẽ lưu 500 tỷ bản ghi. Con số 500 tỷ đến từ kịch bản giả định 2.000 giao dịch mỗi giây trong 8 năm, dùng để giải thích thách thức mở rộng nullifier ^[2][5][7].
• Đây chưa phải hành vi giao thức đang chạy. Cơ chế hiện được mô tả trong thảo luận Ethereum Magicians liên kết với một pull request EIP, nên chi tiết triển khai và thời điểm có thể thay đổi ^[1].

Kết luận

Cách hiểu hợp lý nhất về EIP-8250 là: đây là một nâng cấp chống phát lại có hệ quả đáng chú ý đối với mở rộng quyền riêng tư. Cơ chế trực tiếp khá gọn: chia thứ tự nonce của giao dịch frame thành nhiều làn theo khóa. Nhưng ý nghĩa lớn hơn nằm ở kiến trúc: nếu Ethereum có thể dành cấu trúc do giao thức quản lý cho những workload hẹp nhưng khối lượng lớn, các hệ thống quyền riêng tư có thể mở rộng mà không buộc mọi bản ghi khó cắt bỏ phải nằm trong trạng thái tổng quát ^[1][4][5].