Bài viết này được hoàn thành sau thời gian thực tập Tiến sĩ tại Nethermind . Xin chân thành cảm ơn nhóm Nghiên cứu Nethermind , đặc biệt là Conor McMenamin và Lin Oshitani , vì đã cung cấp phản hồi hữu ích cho nhiều bản thảo.
I. Khóa trạng thái: Giới thiệu.
Khi người đề xuất phát hành khóa trạng thái, họ hứa rằng giao dịch của người dùng sẽ có quyền truy cập vào một hoặc nhiều khe lưu trữ ở các giá trị chính xác mà người dùng chỉ định. Thông thường, đây sẽ là các giá trị mà các khe lưu trữ giữ ở cuối khối trước đó. Sau đó, người đề xuất sắp xếp trình tự các giao dịch để đảm bảo rằng giao dịch của người dùng nhìn thấy các giá trị khe lưu trữ đã hứa. Theo trực giác, khóa trạng thái có thể được so sánh với giao dịch Top-of-Block. Giao dịch đầu tiên nhìn thấy các trạng thái chưa bị bất kỳ giao dịch nào khác trong khối chạm tới. Khóa trạng thái cấp một đặc quyền tương tự bằng cách cho phép người dùng yêu cầu giao dịch của họ nhìn thấy các giá trị mà một số khe lưu trữ nhất định giữ ở cuối khối trước đó, về cơ bản đảm bảo quyền truy cập quyền đầu tiên vào trạng thái chưa bị chạm tới. Tuy nhiên, không giống như giao dịch ToB, khóa trạng thái cho phép nhiều giao dịch có quyền truy cập quyền đầu tiên vào các phần trạng thái không giao nhau trong cùng một khối.
II. Tiến trình logic dự kiến của Khóa trạng thái.
Bước 1) Người dùng gửi yêu cầu khóa trạng thái tới người đề xuất, chỉ định ảnh chụp nhanh trạng thái, S.
- S được chỉ định là một tập hợp các vị trí lưu trữ, L1…LN, và các giá trị tương ứng của chúng, V1…VN.
- Yêu cầu sẽ chỉ định cả khoản Tiền boa trước và khoản Tiền thanh toán sau.
Bước 2) Người đề xuất ký yêu cầu và trả lại cho người dùng, qua đó cam kết rằng giao dịch trong tương lai từ người dùng sẽ được thực hiện đối với S.
- Người đề xuất bây giờ sẽ nhận được ít nhất là tiền boa.
Bước 3) Người dùng nhận được xác nhận rằng S đã bị khóa.
Bước 4) Người dùng gửi giao dịch tiếp theo, T, vào một thời điểm nào đó trước thời hạn (hết hạn).
Bước 5) Người đề xuất nhận được T và sắp xếp danh sách các giao dịch sao cho T là giao dịch đầu tiên chạm vào S.
- Trước khi công bố khối, người đề xuất sẽ mô phỏng giao dịch của người dùng để đảm bảo rằng nó chỉ chạm đến S. Nếu giao dịch "vượt quá giới hạn" bằng cách ghi vào vị trí lưu trữ bên ngoài S, người đề xuất sẽ gửi bằng chứng cho người dùng và một NullificationContract (xem Phụ lục A) và không còn phải chịu sự cắt giảm vì không bao gồm T.
Bước 6) Người đề xuất nhận được khoản thanh toán sau khi thực hiện T đối với S.
- Và vẫn nhận được postPayment nếu T hoàn nguyên. Việc thực hiện thành công không phải là một phần của lời hứa.
III. Hình dung.
IV. Làm rõ.
1. Đề xuất này giả định theo phương pháp thử nghiệm rằng người đề xuất khối L1 hiện tại là người xử lý duy nhất các yêu cầu/cấp khóa trạng thái, nhưng nó cho phép người đề xuất có thể ủy quyền cho bên thứ ba phức tạp như cổng hoặc rơle.
2. Vì người đề xuất có thể cấp nhiều khóa trạng thái cho cùng một khối, nên có nguy cơ các giao dịch tiếp theo có thể bất ngờ "vượt quá giới hạn" và vô tình chồng chéo. Phụ lục A thảo luận về vấn đề chồng chéo vô tình cùng với một số chiến lược giảm thiểu.
3. Việc thực thi khóa trạng thái dự kiến sẽ bao gồm việc cắt giảm hành vi sai trái (ví dụ, người đề xuất nhận được giao dịch tiếp theo nhưng không bao gồm giao dịch đó).
4. Khóa trạng thái không bao gồm các đảm bảo sau khi thực hiện.
5. Người đề xuất chỉ nhận được một trong hai khoản Tiền boa trước (nếu không nhận được phản hồi) hoặc Khoản Tiền boa sau (postPayment), chứ không phải cả hai. Việc loại trừ lẫn nhau có thể được thực hiện bằng cách, ví dụ, ký khoản Tiền boa trước và Khoản Tiền boa sau bằng cùng một nonce.
6. Người dùng không cần phải gửi giao dịch tiếp theo.
V. Các trường hợp sử dụng.
1. Trường hợp sử dụng cốt lõi: dân chủ hóa quyền truy cập Top-of-Block.
Mục đích sử dụng cốt lõi của khóa trạng thái là cho phép nhiều người dùng được đảm bảo quyền truy cập vào trạng thái chưa được chạm đến trong cùng một khối. Hiện tại, việc truy cập vào trạng thái chưa được chạm đến đồng nghĩa với việc đấu thầu để được đưa vào Top-of-Block (ToB). Nhờ được xếp hạng đầu tiên, một giao dịch ToB được hưởng khóa trạng thái thực tế trên toàn bộ chuỗi trạng thái. Định dạng "người chiến thắng được tất cả" này không tối ưu vì một số lý do, một trong số đó đã được chúng tôi lưu ý: chỉ một giao dịch trên mỗi khối được đảm bảo quyền truy cập vào trạng thái chưa được chạm đến.
Một điều nữa là bất kỳ ai thắng thầu ToB có thể phải trả nhiều hơn số tiền họ thực sự cần. Một giao dịch có thể chỉ cần truy cập vào một nhóm cụ thể, nhưng người dùng lại phải trả tiền để khóa gốc trạng thái. Và với tất cả những khoản trả quá cao đó, họ vẫn không nhận được sự đảm bảo chắc chắn về việc được đưa vào ToB. Người đấu giá thắng thầu sẽ trả tiền và chờ đợi như mọi người khác để xem giao dịch của họ sẽ được chuyển đến đâu.
Khóa trạng thái về cơ bản thay đổi các động lực này: người dùng có nhiều lựa chọn hơn là chỉ bao gồm ToB, bất kỳ số lượng người dùng nào cũng có thể có quyền truy cập đầu tiên, mỗi người dùng chỉ có thể đấu giá những phần trạng thái mà họ quan tâm và người dùng nhận được lời hứa có thể cắt giảm rằng các phần trạng thái có liên quan đã bị khóa.
2. Hai ví dụ cụ thể bắt nguồn từ trường hợp sử dụng cốt lõi.
Vì khóa trạng thái hoạt động để bảo mật quyền truy cập vào trạng thái chưa bị tác động, nên các trường hợp sử dụng của chúng phần lớn sẽ trùng lặp với lý do người dùng muốn đưa giao dịch của họ lên đầu khối. Mặc dù có nhiều lý do hoặc trường hợp sử dụng như vậy, nhưng có hai lý do đặc biệt đáng được nêu bật.
2.1 Chiến lược kinh doanh chênh lệch giá mới.
Một trong những lý do chính khiến người dùng muốn giao dịch ở đầu khối là để đảm bảo cơ hội chênh lệch giá. Mặc dù mục đích sử dụng cốt lõi của khóa trạng thái là để phổ biến rộng rãi hơn các cơ hội như vậy, nhưng khóa trạng thái cũng mở ra các chiến lược giao dịch mới. Một lý do cho điều này là giao dịch tiếp theo mang lại cho người dùng quyền lựa chọn tối đa. Trong trường hợp chênh lệch giá tiêu chuẩn trên CEX-DEX, người dùng có thể khóa giá DEX và đợi đến gần ngày hết hạn mới gửi lệnh tiếp theo, điều chỉnh giao dịch khi cần thiết để tối đa hóa giá trị từ độ lệch giá. Ngoài ra, nếu giá hội tụ bất ngờ, họ có thể đơn giản chọn không tham gia bằng cách giữ lại lệnh tiếp theo (mặc dù họ vẫn phải trả tiền tip trước), do đó có khả năng tránh được thua lỗ.
2.2 Đảm bảo các giao dịch quan trọng cho người dùng tần suất thấp.
Mặc dù khóa trạng thái có thể chủ yếu được quan tâm bởi những người dùng lão luyện, chẳng hạn như các nhà giao dịch chuyên nghiệp thiết kế bot giao dịch, nhưng chúng cũng có một trường hợp sử dụng độc đáo cho người dùng tần suất thấp điển hình, những người đang gửi những gì họ cho là một giao dịch đặc biệt quan trọng. Đối với người dùng đang thực hiện một giao dịch lớn (đối với họ) trên DEX hoặc đang tìm kiếm quyền truy cập ưu tiên vào một đợt đúc NFT, khóa trạng thái có thể cung cấp sự đảm bảo vô giá rằng giao dịch của họ sẽ không thất bại hoặc bị kẻ gian lợi dụng.
3. Các trường hợp sử dụng xác nhận trước.
Việc cấp quyền khóa trạng thái có thể được coi như một xác nhận trước bao hàm đối với giao dịch tiếp theo. Nhìn chung, trường hợp sử dụng chính của xác nhận trước là cải thiện trải nghiệm người dùng, đặc biệt là trong bối cảnh tổng hợp dựa trên . Được coi là một loại xác nhận trước, khóa trạng thái phù hợp với trường hợp sử dụng này: khóa trạng thái đảm bảo cho người dùng rằng giao dịch của họ sẽ được thực hiện theo các điều kiện được chỉ định trong ảnh chụp nhanh. Tuy nhiên, chúng cũng có những trường hợp sử dụng bắt nguồn từ những ưu điểm của chúng so với các loại xác nhận trước khác.
3.1. Xác nhận trước với sự đảm bảo chặt chẽ hơn so với xác nhận trước bao gồm.
Với xác nhận trước bao gồm, người dùng chỉ biết giao dịch của họ sẽ được đưa vào khối. Với khóa trạng thái, người dùng biết giao dịch của họ sẽ được bao gồm và họ biết chính xác trạng thái mà giao dịch sẽ thấy.
3.2. Khóa trạng thái mang lại ít rủi ro hơn cho người đề xuất/người hội nghị trước so với xác nhận thực hiện trước.
Ở dạng nghiêm ngặt nhất, xác nhận trước khi thực thi bao gồm cam kết với một gốc trạng thái hậu thực thi cụ thể. Các biến thể ít nghiêm ngặt hơn liên quan đến các cam kết yếu hơn đối với các khác biệt trạng thái hoặc ý định của người dùng. Vì preconfer chịu trách nhiệm về kết quả sau khi thực thi, chúng nhất thiết phải chịu rủi ro ex ante bắt nguồn từ các dự báo mô hình/mô phỏng không hoàn hảo (ví dụ: giả định ấm/lạnh bị lỗi, cập nhật oracle bị bỏ lỡ, đường dẫn mã bị bỏ lỡ), đặc biệt nếu preconfer không có quyền xây dựng khối độc quyền. Ngược lại, khóa trạng thái tránh được những rủi ro này bằng cách chỉ cam kết với các điều kiện tiền thực thi, về cơ bản biến tất cả rủi ro ex ante thành rủi ro ngoài giới hạn.
Thoạt nhìn, việc giảm rủi ro của bên đề xuất có vẻ như làm tăng rủi ro của người dùng. Tuy nhiên, sự đánh đổi lại tinh tế hơn: bên đề xuất hứa hẹn các điều kiện tiền trạng thái và thực thi chúng bằng sàng lọc ngoài giới hạn, trong khi người dùng mô phỏng quá trình theo dõi dựa trên các giá trị được chỉ định trong ảnh chụp nhanh. Với công cụ đủ tinh vi, người dùng có thể mô phỏng kết quả thực thi dựa trên ảnh chụp nhanh chính xác như bên đề xuất/bên tiền hội nghị. Tuy nhiên, không giống như bên tiền hội nghị, người dùng không phải chịu các hình phạt cắt giảm cho kết quả chưa mô phỏng, mà chỉ phải chịu rủi ro giao dịch và phí gas. Do đó, bằng cách chuyển trách nhiệm giải trình từ kết quả hậu trạng thái sang các điều kiện tiền trạng thái, khóa trạng thái có thể giảm rủi ro của bên đề xuất mà không làm tăng đáng kể rủi ro của người dùng.
3.3. Xác nhận trước cung cấp khả năng bảo vệ mạnh mẽ cho người dùng.
Bằng cách khóa trạng thái tại giá trị mà nó giữ ở cuối khối trước đó, người dùng được đảm bảo rằng giao dịch của họ sẽ là giao dịch đầu tiên trong khối hiện tại chạm đến trạng thái đã khóa. Điều này khiến việc chạy trước trở nên bất khả thi, vì không có giao dịch nào khác có thể chiếm quyền trước giao dịch tiếp theo mà không vi phạm khóa trạng thái.
4. Giúp giao dịch tiết kiệm gas hơn.
Về mặt trực quan, việc khóa chính xác trạng thái trước khi thực thi giúp hành vi giao dịch dễ dự đoán hơn. Kết quả là, các giao dịch dễ được tối ưu hóa hơn. Một minh họa cụ thể về cách thức hoạt động của điều này đến từ một nghiên cứu về giao dịch danh sách truy cập EIP-2930 .
Giao dịch EIP-2930 bao gồm một danh sách truy cập địa chỉ và khóa lưu trữ được "làm ấm" khi bắt đầu thực thi, do đó các truy cập được tính phí theo chi phí truy cập ấm như được quy định trong EIP-2929 . Theo các tác giả của nghiên cứu, tiềm năng tiết kiệm gas của danh sách truy cập giao dịch (TAL) chủ yếu bị cản trở bởi sự không chắc chắn về trạng thái nội khối:
“Phân tích của chúng tôi cho thấy rằng đối với khoảng 71% tổng số giao dịch [có thể] được hưởng lợi từ việc bao gồm một TAL lý tưởng, TAL lý tưởng này không thể được tính toán chính xác dựa trên trạng thái của khối cuối cùng. Thay vào đó, nó đòi hỏi kiến thức về trạng thái nội khối mà giao dịch được thực thi, điều này không thể biết trước — khiến việc tính toán TAL đúng cách trong những trường hợp này gần như không thể.” (tr. 2)
Bằng cách khóa trạng thái chính xác trước khi thực thi, khóa trạng thái cho phép tính toán một TAL lý tưởng, bao gồm tất cả và chỉ các khóa lưu trữ mà giao dịch sẽ truy cập. Mặc dù TAL vẫn có thể không hoàn hảo do các loại lỗi khác, chẳng hạn như bao gồm các địa chỉ mặc định ấm (ví dụ: người nhận) một cách không cần thiết, một TAL hoàn hảo, tối ưu hóa tối đa việc sử dụng gas, đòi hỏi phải biết chính xác trạng thái trước khi thực thi.
5. Lợi ích bổ sung: giảm tranh chấp mempool, tỷ lệ hồi quy thấp hơn.
Mặc dù MEV-Boost đã giảm đáng kể nhiều tác động tiêu cực bên ngoài liên quan đến các cuộc đấu giá khí ưu tiên , chẳng hạn như cuộc chiến đấu thầu, mempool tràn ngập thư rác và các khối bị tắc nghẽn do các giao dịch không thành công, nhưng khóa trạng thái vẫn có thể giúp quá trình sản xuất khối diễn ra có trật tự và hiệu quả hơn bằng cách giảm tranh chấp mempool và giảm tỷ lệ hoàn nguyên.
5.1 Giảm thiểu sự tranh chấp bộ nhớ đệm.
Flashbots hiện cho phép các trình xây dựng khối hiển thị các điểm cuối API như mev_simBundle, cho phép người tìm kiếm mô phỏng các gói dựa trên mẫu khối gần đây nhất của họ. Bằng cách hiển thị điểm cuối proposal_getLockedStates mới, người đề xuất có thể chia sẻ danh sách trạng thái bị khóa theo thời gian thực, cho phép người dùng có lý trí tự kiểm duyệt, do đó giảm thiểu tranh chấp trong bộ nhớ công khai. Tuy nhiên, lựa chọn thiết kế này có thể đi kèm với các vấn đề về quyền riêng tư, vì nó yêu cầu phải hiển thị thông tin (ví dụ: các mục tiêu chênh lệch giá tiềm năng) liên quan đến các giao dịch chưa được công bố.
5.2 Giảm tỷ lệ hồi quy.
Bằng cách biết trạng thái chính xác trước khi thực hiện, ví, dApp và người dùng thành thạo sẽ có thể mô phỏng các giao dịch với độ chính xác cao hơn, giúp ngăn chặn việc giao dịch bị đảo ngược do các nguyên nhân như giới hạn gas không đủ, giá trị dự trữ cũ và lỗi lệnh gọi bên ngoài.
VI. Các thuật ngữ chính.
Trùng lặp ngẫu nhiên: trùng lặp ngẫu nhiên xảy ra khi một giao dịch có quyền truy cập trái phép vào một phần trạng thái được dành riêng bởi lệnh cấp khóa trạng thái.
- Xem Phụ lục A để thảo luận.
Miền : Vị trí lưu trữ có thể định địa chỉ trong trạng thái liên tục của EVM, được chỉ định là tập {A, K} trong đó A là địa chỉ hợp đồng và K là khe lưu trữ 32 byte (khóa).
Cặp miền-giá trị : cặp miền {A, K} và giá trị V, được chỉ định là {{A, K}, V}}.
- Minh họa cụ thể sử dụng nhóm WETH/USDC trên Uniswap V2:
- Chiều cao khối: 22385280
- Miền: {0xB4e16d0168e52d35CaCD2c6185b44281Ec28C9Dc, 0x…03}
- Giá trị: {0x66304740000000000000000008d9350c2aac000000000124394c1432cced5400}
- Cặp miền-giá trị: {{0xB4e16d0168e52d35CaCD2c6185b44281Ec28C9Dc,0x…03}, 0x663047400000000000000000008d9350c2aac000000000124394c1432cced5400}
Ngày hết hạn : thời hạn cuối cùng để thực thi việc đưa giao dịch tiếp theo vào.
- Ngày hết hạn đặt ra thời hạn chót để bên đề xuất phải nhận được giao dịch tiếp theo để bên đó có thể bị trừ điểm vì không bao gồm giao dịch đó. Nếu giao dịch tiếp theo đến sau ngày hết hạn, bên đề xuất sẽ không bị trừ điểm vì không bao gồm giao dịch đó.
Giao dịch theo dõi : giao dịch được gửi theo lệnh khóa trạng thái.
- Nếu người dùng gửi nhiều giao dịch để đưa vào cùng một khối và một trong số đó là giao dịch tiếp theo để khóa trạng thái, thì giao dịch tiếp theo sẽ được xác định bằng cách khớp giữa nonce của giao dịch và nonce được chỉ định trong yêu cầu khóa trạng thái.
Truy cập ngoài giới hạn : khi giao dịch tiếp theo ghi vào miền không được chỉ định trong yêu cầu khóa trạng thái.
Bộ quyền : tập hợp các miền mà giao dịch tiếp theo yêu cầu quyền truy cập, lấy từ ảnh chụp nhanh.
Ví dụ trong đó A là địa chỉ hợp đồng, K là khe lưu trữ và V là giá trị mà K được dành riêng:
- Ảnh chụp nhanh: {{{A1, K1}, V1}}, {{A2, K2}, V2}}}
- Bộ quyền: {{A1, K1}, {A2, K2}}
Theo trực giác, số lượng phần tử trong quyền có thể được sử dụng để đếm hoặc đo lường "mức độ" trạng thái bị khóa.
postPayment : phí ưu tiên để thực hiện khóa trạng thái.
Giá trị của khoản thanh toán sau được tính toán để bao gồm cả khoản tiền boa trước. Khoản thanh toán sau thực chất là khoản phí ưu tiên “đầy đủ”:
postPayment = preTip + tiền bồi thường cho việc bao gồm giao dịch tiếp theo
Giao dịch tiếp theo cho phép người đề xuất thu tiền sau thanh toán.
preTip : khoản thanh toán dự phòng cho người đề xuất được bao gồm trong yêu cầu khóa trạng thái.
Tiền boa sẽ bồi thường cho người đề xuất trong trường hợp (a) người dùng không gửi giao dịch tiếp theo hoặc (b) giao dịch tiếp theo vượt quá giới hạn bằng cách ghi vào miền bên ngoài ảnh chụp nhanh của miền đó (xem Phụ lục A).
Yêu cầu khóa trạng thái cho phép người đề xuất thu thập tiền boa trước.
Tiền boa trước và tiền thanh toán sau phải được thực hiện loại trừ lẫn nhau bằng cách, ví dụ, ký mỗi lần bằng cùng một nonce.
Ảnh chụp nhanh : tập hợp tất cả các cặp giá trị miền được chỉ định bởi yêu cầu khóa trạng thái.
- Ví dụ minh họa:
- Địa chỉ đơn, khe lưu trữ đơn: {{A, K}, V}
- Địa chỉ đơn, nhiều khe lưu trữ: {{{A1, K1}, V1}, {{A1, K2}, V2}}}
- Nhiều địa chỉ, một khe lưu trữ cho mỗi địa chỉ: {{{A1, K1}, V1}, {{A2, K2}, V2}}}
Khóa trạng thái : cam kết có thể cắt để đảm bảo rằng giao dịch được thực hiện theo một tập hợp các trạng thái được chỉ định bởi ảnh chụp nhanh.
- Lưu ý: Bản thân khái niệm trạng thái khóa không bao hàm khái niệm thực hiện giao dịch với trạng thái khóa. Người dùng có thể yêu cầu khóa trạng thái cho mục đích bất chính, chẳng hạn như ngăn người khác giao dịch. Tuy nhiên, cách sử dụng của chúng tôi mang tính quy định: theo nghĩa của chúng tôi, "khóa trạng thái" ngụ ý cam kết thực hiện giao dịch với trạng thái khóa.
Yêu cầu khóa trạng thái : một thông báo đã ký yêu cầu khóa trạng thái.
- Yêu cầu khóa trạng thái sẽ chỉ định (i) ảnh chụp nhanh, (ii) preTip, (iii) postPayment, (iv) nonce của giao dịch tiếp theo (v) khối chứa giao dịch tiếp theo, và (vi) ngày hết hạn. Người dùng sẽ ký bằng tiêu chuẩn như EIP-712.
{
blockNumber:…,
snapShot:[(A1, K), (V1)…],
preTip:…,
postPayment:…,
expiry:…,
nonce:…,
}
Cấp khóa trạng thái : một thông báo đã ký phát hành khóa trạng thái.
VII. Trao đổi công bằng.
Vấn đề tiếp theo.
Cốt lõi của Vấn đề theo dõi là người đề xuất có thể chấp nhận yêu cầu khóa trạng thái của người dùng và tiếp tục bỏ qua giao dịch theo dõi của họ, do đó không tôn trọng cam kết của họ. Điều quan trọng là phải làm rõ rằng Vấn đề theo dõi không giống với vấn đề trao đổi công bằng kịp thời cho các xác nhận trước. Xác nhận trước cải thiện UX bằng cách yêu cầu người trao đổi trước gửi xác nhận trước có ràng buộc, kịp thời cho người dùng. Do đó, trao đổi công bằng sẽ bị vi phạm nếu xác nhận trước không được đưa ra kịp thời. Câu hỏi hậu cần cốt lõi là đảm bảo việc phát hành kịp thời khi có các động cơ kinh tế để trì hoãn. Ngược lại, Vấn đề theo dõi không phải là về việc đảm bảo tính kịp thời. Thay vào đó, thách thức hậu cần cốt lõi là đảm bảo rằng người đề xuất tôn trọng cam kết của họ trong việc bao gồm giao dịch theo dõi của người dùng (giả sử họ nhận được nó kịp thời).
H: Tại sao người đề xuất lại bỏ qua các giao dịch tiếp theo và mất quyền thanh toán sau?
(A1) Họ có thể đã nhận được giá thầu cao hơn cho một giao dịch va chạm.
(A2) Họ có thể cấp các yêu cầu khóa trạng thái một cách bừa bãi để thu thập càng nhiều preTip càng tốt.
Chiến lược này tự nhiên chỉ bao gồm những hoạt động theo dõi cung cấp khoản thanh toán sau lớn nhất.
(A3) Người đề xuất có thể chỉ đang kiểm duyệt người dùng.
Chiến lược giảm thiểu.
(S-1) Việc chia tiền boa thành tiền trả trước và tiền trả sau đã mang lại một số bảo vệ cho người dùng. (Ý tưởng sử dụng tiền boa hai phần được mượn từ giải pháp của Luban cho Bài toán Trao đổi Công bằng trong hệ thống cam kết của người đề xuất .)
Tiền boa trước càng nhỏ thì rủi ro cho người dùng càng thấp. Tuy nhiên, rủi ro cho người đề xuất cũng tăng lên tương ứng. Người dùng có thể hứa hẹn các khoản thanh toán sau lớn nhưng lại không gửi các giao dịch tiếp theo, điều này có thể dẫn đến chi phí cơ hội cho người đề xuất. Trao đổi công bằng vẫn là một con đường hai chiều.
(S-2) Người đề xuất chỉ được phép cấp một khóa trạng thái cho mỗi miền, tức là cho mỗi cặp {A, S}. Người đề xuất vẫn có thể tự do đưa vào các giao dịch khóa không phải trạng thái (bao gồm cả xác nhận trước) được thực thi trên một miền bị khóa miễn là chúng được thực hiện sau khi miền không còn bị khóa nữa, tức là sau giao dịch tiếp theo.
Việc thực thi có thể được thực hiện dưới hình thức hợp đồng thông minh, cắt giảm quyền của người đề xuất khi cấp nhiều hơn một khóa trạng thái cho mỗi tên miền.
Ưu điểm: Vì người đề xuất không thể cấp thêm khóa cho tên miền nên không có động lực để đưa ra giá thầu bừa bãi hoặc chấp nhận yêu cầu khóa trạng thái cạnh tranh với mức tiền boa cao hơn.
Nhược điểm: Vẫn có khả năng người đề xuất sẽ bỏ qua các giao dịch tiếp theo của người dùng để (a) kiểm duyệt người dùng hoặc (b) đưa ra giá thầu cao hơn cho giao dịch không khóa trạng thái.
(S-3) Xử lý khóa trạng thái như quyền truy cập độc quyền : chỉ giao dịch tiếp theo của người dùng mới có quyền sửa đổi các miền trong tập quyền của mình, P. Không có giao dịch nào khác trong khối có thể ghi vào bất kỳ miền nào (như cặp địa chỉ và khóa lưu trữ {A, K}) nằm trong P.
Ưu điểm: Bảo vệ người dùng khỏi (i) bị trả giá cao hơn và (ii) việc phát hành bừa bãi để tối đa hóa tiền boa trước.
Nhược điểm 1: Sự bảo vệ này có nhược điểm là hạn chế khả năng của bên đề xuất trong việc đưa thêm các giao dịch thực hiện đối với P.
Nhược điểm 2: Quyền truy cập độc quyền có thể khiến yêu cầu trở nên tốn kém hơn đáng kể.
Nhược điểm 3: Người đề xuất vẫn có thể tham gia kiểm duyệt bằng cách bỏ qua các giao dịch tiếp theo.
Đây là một chủ đề nhất quán: việc bảo vệ chống lại sự kiểm duyệt thuần túy là rất khó khăn.
(S-4) Ủy ban chứng thực giao dịch.
Một lựa chọn khác là gửi giao dịch tiếp theo cho cả người đề xuất và ủy ban chứng thực. Mỗi thành viên ủy ban sẽ ghi lại thời điểm họ nhận được giao dịch tiếp theo và thông báo cho các thành viên khác. Nếu một tỷ lệ phần trăm đủ lớn trong ủy ban chứng thực việc quan sát giao dịch tiếp theo trước khi hết hạn, người đề xuất có thể bị xóa vì không bao gồm giao dịch đó.
(S-5) Định tuyến thông qua trung gian đáng tin cậy.
Lợi ích chính của việc sử dụng một bên trung gian đáng tin cậy thay vì một ủy ban là không cần phải truyền tải chứng thực trên toàn mạng. Điều này sẽ cho phép người dùng có thêm thời gian để trì hoãn trước khi gửi giao dịch tiếp theo. Nhược điểm chính là tính tập trung và việc bổ sung thêm yếu tố tin cậy.
(S-6) Điểm uy tín (giảm uy tín) cho những người đề xuất được ghi lại trong sổ đăng ký trên chuỗi.
Trong trường hợp đơn giản nhất, một sổ đăng ký có thể được sử dụng để ghi lại dữ liệu thô về hiệu suất của bên đề xuất, chẳng hạn như số lượng/tỷ lệ phần trăm các giao dịch theo dõi bị bỏ lỡ, điều này không hoàn toàn ngụ ý hành vi độc hại. Bất chấp hạn chế này, sổ đăng ký ít nhất cũng sẽ cung cấp một số cơ sở để đánh giá rủi ro. Người dùng có thể muốn tránh các bên đề xuất (hoặc cổng) có xu hướng bỏ lỡ các giao dịch theo dõi cao hơn, bất kể lỗi. Sổ đăng ký cũng có thể được sử dụng để áp đặt các yêu cầu về độ tin cậy tối thiểu.
Tính kịp thời.
Khóa trạng thái khuyến khích trao đổi công bằng kịp thời bằng cách chia phí ưu tiên thành preTip và postPayment và điều kiện sau này dựa trên việc bao gồm giao dịch tiếp theo. Ceteris paribus , người dùng nhận được quyền khóa trạng thái đã ký càng sớm thì giá trị tiềm năng của giao dịch tiếp theo càng lớn. Do đó, việc trì hoãn cấp quyền khóa trạng thái có nguy cơ mất giá trị cho người dùng. Nếu giao dịch tiếp theo mất đủ giá trị, người dùng có thể quyết định không gửi và người đề xuất có thể mất postPayment. Ngược lại, người dùng nhận được quyền khóa trạng thái càng sớm thì khả năng họ gửi giao dịch tiếp theo càng cao do giá trị tiềm năng lớn hơn. Do đó, việc cấp quyền khóa trạng thái kịp thời sẽ tối đa hóa giá trị cho cả người dùng và người đề xuất.
Ghost Grants.
Trong trường hợp (a) người dùng không gửi giao dịch tiếp theo hoặc (b) giao dịch tiếp theo vượt quá giới hạn (xem Phụ lục A), yêu cầu khóa trạng thái sẽ cho phép người đề xuất thu thập preTip (mặc dù thiết kế dự định là preTip sẽ được thay thế/thanh toán bằng postPayment). Mặc dù điều này làm giảm rủi ro cho người đề xuất, nhưng nó lại mở ra một con đường mới để từ chối trao đổi công bằng với người dùng. Vì yêu cầu khóa trạng thái cho phép thanh toán preTip, nên người đề xuất có ác ý có thể thu thập preTip mà không cần cấp quyền khóa trạng thái cam kết họ sẽ bao gồm giao dịch tiếp theo của người dùng. Vì trao đổi công bằng bị vi phạm nếu người dùng trả tiền cho một khoản trợ cấp "ma" chưa bao giờ được gửi, nên thách thức hậu cần cốt lõi là đảm bảo rằng người đề xuất không thu thập preTip cho các khoản trợ cấp "ma".
Người dùng có thể chọn mạo hiểm gửi giao dịch tiếp theo mà không cần nhận quyền truy cập trước, nhưng làm như vậy vừa rủi ro vừa không công bằng, vì ngay cả trong trường hợp tốt nhất, họ vẫn phải trả tiền sau khi thanh toán cho một khóa trạng thái chưa bao giờ được cấp. Lựa chọn hợp lý hơn là giữ lại giao dịch tiếp theo hoặc gửi một giao dịch thông thường. Do đó, mặc dù về mặt kỹ thuật, việc gửi giao dịch tiếp theo mà không có quyền truy cập khóa trạng thái là một lựa chọn, nhưng làm như vậy không giúp đảm bảo trao đổi công bằng.
Một lựa chọn tốt hơn là sử dụng chứng thực của bên thứ ba bằng cách yêu cầu người đề xuất gửi khoản trợ cấp khóa trạng thái cho cả người dùng và ủy ban chứng thực hoặc một trung gian đáng tin cậy. Sau đó, người dùng có thể chứng minh rằng trao đổi công bằng đã bị vi phạm bằng cách gửi GrantWitness bị thiếu do bên thứ ba ký vào Hợp đồng hoàn tiền cho phép họ thu hồi preTip và trừ vào người đề xuất. Một thiết kế thay thế là yêu cầu người đề xuất chứng minh việc gửi khoản trợ cấp khóa trạng thái kịp thời để thu preTip. Việc thu thập sẽ cần bao gồm cả khoản trợ cấp và sentGrantWitness đã ký từ bên thứ ba chứng thực việc phát hành kịp thời. Vì yêu cầu khóa trạng thái sẽ không còn cho phép thu preTip nữa, nên nó phải được thanh toán theo một cách khác. Một khả năng là yêu cầu người dùng gửi tiền vào hợp đồng preTipPayment. Sau đó, người đề xuất có thể thu preTip bằng cách gửi khoản trợ cấp và sentGrantWitness vào hợp đồng preTipPayment.
Phụ lục.
Các phụ lục sau đây tiếp tục giả định rằng: (i) người đề xuất L1 hiện tại (hoặc người được ủy quyền của họ, chẳng hạn như cổng) là người xử lý duy nhất các yêu cầu/cấp khóa trạng thái và (ii) việc cấp khóa trạng thái liên quan đến một tập hợp các miền được xác định trên các cặp khe địa chỉ/lưu trữ trong bộ nhớ trạng thái L1 cho khối hiện tại. Đây là một giả định về phạm vi được đưa ra để ưu tiên sự đơn giản và rõ ràng, đồng thời phải chấp nhận hy sinh phạm vi. Do đó, mặc dù khóa trạng thái có thể được coi là một loại xác nhận trước, nhiều chi tiết có thể không được chuyển trực tiếp sang biến thể L2 (ví dụ: định nghĩa của chúng tôi về "trùng lặp ngẫu nhiên" dựa trên ngữ nghĩa mã lệnh EVM).
Phụ lục A: Vấn đề chồng chéo ngẫu nhiên
Khóa trạng thái cho phép nhiều giao dịch có quyền truy cập ưu tiên vào các phần trạng thái không chồng chéo. Tuy nhiên, chức năng mới này lại mang đến thêm rủi ro cho bên đề xuất. Vì người dùng không bao gồm giao dịch tiếp theo với yêu cầu khóa trạng thái, bên đề xuất không thể sàng lọc các giao dịch chuyển vùng. Họ phải cấp khóa trạng thái một cách "mù quáng". Nếu một giao dịch tiếp theo bất ngờ chạm vào một phần trạng thái được dành riêng cho một giao dịch khác (tức là vô tình chồng chéo lên nó), bên đề xuất có thể phải đối mặt với các hình phạt cắt giảm.
Làm rõ “Vượt quá giới hạn” và “Trùng lặp vô tình”.
Truy cập ngoài giới hạn được định nghĩa tốt nhất là bất kỳ thao tác ghi (SSTORE) nào vào một miền không nằm trong tập quyền của giao dịch. Các thao tác đọc chồng chéo (SLOAD, BALANCE, CALL bên ngoài để xem các hàm) không làm thay đổi trạng thái và do đó có thể được coi là chồng chéo vô hại. Bằng cách định nghĩa các truy cập "ngoài giới hạn" theo cách này, những thứ như tra cứu oracle chồng chéo sẽ không được tính là ngoài giới hạn.
Truy cập ngoài giới hạn: Truy cập ngoài giới hạn xảy ra khi giao dịch khóa trạng thái, T, ghi vào một số miền, {A, K}, không nằm trong tập quyền của nó, P.
Trùng lặp ngẫu nhiên: Một giao dịch T1 vô tình trùng lặp với một giao dịch khác, T2, khi T1 thực thi trước khi T2 và T1 ghi vào một miền nào đó, {A, K}, trong tập quyền của T2.
Ngăn ngừa sự chồng chéo ngẫu nhiên.
Các giao dịch thông thường có thể vô tình chồng chéo với các giao dịch khóa trạng thái. Cách đơn giản nhất để ngăn chặn điều này xảy ra là ưu tiên sắp xếp thứ tự cho các giao dịch khóa trạng thái. Tuy nhiên, việc chồng chéo vô tình giữa các khóa trạng thái không dễ giải quyết. Phần còn lại của phụ lục này sẽ thảo luận một số chiến lược để giảm thiểu tình trạng này.
Chiến lược giảm thiểu 1: Bảo vệ quyền dựa trên EVM.
Một cách để giảm thiểu tình trạng chồng chéo vô tình là sử dụng cơ chế bảo vệ quyền trong EVM, cơ chế này "buộc" các thao tác theo dõi phải giữ đúng làn đường bằng cách hoàn nguyên các thao tác ghi vượt quá giới hạn. Mặc dù một thứ gì đó như tiền biên dịch gốc có thể được sử dụng để thực thi bộ quyền trực tiếp trong EVM, nhưng điều này hiện không khả thi trên mạng chính. Việc giới thiệu một địa chỉ tiền biên dịch mới sẽ yêu cầu một EIP chính thức, một hard fork cấp giao thức, các triển khai máy khách Eth được phối hợp, kiểm tra và công cụ hệ sinh thái. Nhìn chung, chi phí phát triển, thử nghiệm và điều phối xã hội khiến phương pháp tiếp cận dựa trên EVM trở nên bất khả thi trong tương lai gần.
Chiến lược giảm thiểu 2: Mô phỏng ngoài chuỗi.
Một lựa chọn khác là để người đề xuất mô phỏng các giao dịch tiếp theo ngoài chuỗi. Nếu người đề xuất phát hiện sự trùng lặp ngẫu nhiên, họ có thể tạo một bằng chứng ngoài giới hạn và gửi cho người dùng, lý tưởng nhất là để đủ thời gian để chỉnh sửa lại. Người đề xuất cũng cần thời gian để mô phỏng lại. Để phù hợp với việc trao đổi qua lại, ngày hết hạn nên được đặt sớm hơn trong khe và sẽ cần một lần hết hạn thứ hai. Nếu người dùng không trả về một giao dịch tiếp theo "đã sửa" trước lần hết hạn thứ hai, bằng chứng ngoài giới hạn có thể được gửi đến một NullificationContract.
Các vấn đề với mô phỏng ngoài chuỗi.
Mặc dù khả thi hơn so với tiền biên dịch gốc, phương pháp này không phải là không có thách thức. Thứ nhất, bên đề xuất phải có khả năng tạo ra một bằng chứng out-of-bounds thỏa đáng mà không tiết lộ danh sách giao dịch cho người dùng. Có những trường hợp khả thi, chẳng hạn như hoán đổi với một nhánh không cần thiết, nhưng những trường hợp này thường là ngoại lệ hơn là quy tắc. Thứ hai, sẽ khó đảm bảo việc trao đổi công bằng cho giao dịch tiếp theo đã sửa đổi do khung thời gian hạn chế. Thứ ba, NullificationContract sẽ cần xử lý các tranh chấp giữa bên đề xuất và người dùng về bằng chứng out-of-bounds.
Một số giải pháp tiềm năng/một phần.
Những thách thức mà chiến lược mô phỏng ngoài chuỗi phải đối mặt không phải là không đáng kể, nhưng chúng có thể trở nên dễ dàng hơn khi áp dụng những điều sau:
1. Hoàn tất các giao dịch tiếp theo.
Việc xem xét giao dịch tiếp theo là hoàn tất và không thể sửa đổi sẽ loại bỏ các vấn đề về thời gian liên quan đến việc sửa đổi và mô phỏng lại. Không cần phải sửa đổi/mô phỏng lại, một bằng chứng ngoại biên có thể được gửi sau khi khối được công bố, giúp loại bỏ nhu cầu hết hạn lần thứ hai cùng với bất kỳ lo ngại nào về quyền riêng tư khi tiết lộ các giao dịch chưa công bố. Nhược điểm chính là giảm tính tùy chọn cho người dùng.
2. Xác định các phương pháp tốt nhất.
Một bộ hướng dẫn "thực hành tốt nhất" dành cho người dùng và người đề xuất có thể đóng vai trò quan trọng trong việc giảm thiểu tình trạng chồng chéo vô tình. Một khả năng có thể là cung cấp số lượng miền được khuyến nghị trong các tập quyền cho các loại giao dịch phổ biến. Lấy một ví dụ đơn giản, giả sử phần lớn các giao dịch hoán đổi đơn giản yêu cầu các tập quyền với 2-4 miền. Khi đó, người dùng có thể suy ra rằng việc có nhiều hơn bốn miền cho một giao dịch hoán đổi đơn giản sẽ làm tăng nguy cơ chồng chéo vô tình (hoặc, nhiều khả năng hơn, công cụ sẽ được thiết kế dựa trên các khuyến nghị thực hành tốt nhất).
Phụ lục B: Mô hình trước mắt.
Giao dịch theo dõi tối đa hóa tính tùy chọn cho người dùng, nhưng lại gây ra những thách thức về thiết kế liên quan đến Bài toán Theo dõi và ngăn ngừa sự chồng chéo ngẫu nhiên. Tuy nhiên, những thách thức này phần lớn có thể được khắc phục bằng cách yêu cầu người dùng đưa giao dịch của họ vào yêu cầu khóa trạng thái và coi giao dịch là cuối cùng và không thể sửa đổi. Nhược điểm chính của thiết kế này bao gồm tính tùy chọn thấp hơn và dễ bị trích xuất MEV hơn. Nhìn chung, đây là một mô hình thân thiện hơn với người đề xuất. Tuy nhiên, những lợi ích về tính đơn giản trong thiết kế khiến nó đáng để tìm hiểu sơ qua.
Tiến trình logic dự kiến trong Mô hình trước.
Bước 1) Người dùng gửi yêu cầu khóa trạng thái bao gồm (i) ảnh chụp nhanh, (ii) giao dịch và (iii) phí ưu tiên.
Bước 2) Người đề xuất nhận được yêu cầu và nếu phí ưu tiên được định giá hợp lý, sẽ mô phỏng giao dịch.
Bước 3) Người đề xuất trả về tin nhắn xác nhận đã ký yêu cầu của người dùng.
Bước 4) Người đề xuất khóa giao dịch vào mẫu khối của họ/phát sóng trạng thái đã cập nhật tới mạng.
Bước 5) Người dùng nhận được tin nhắn xác nhận, có thể được sử dụng để gạch bỏ người đề xuất trong trường hợp, ví dụ, giao dịch của người dùng được thực hiện với ảnh chụp nhanh không đúng.
Thêm giao dịch vào yêu cầu khóa trạng thái.
Quyền cấp khóa trạng thái hiện chỉ sử dụng một trường Tip duy nhất, không có ngày hết hạn và phải bao gồm một trường txPayload bổ sung:
{
blockNumber:…,
snapShot:[(address, storage slot), (value)…],
Tip:…,
nonce:…,
txPayload:…,
}
Ưu điểm chung của mô hình Up-Front.
1. Thiết kế đơn giản hơn với ít bộ phận chuyển động hơn.
Các vấn đề về trao đổi công bằng liên quan đến giao dịch tiếp theo sẽ được loại bỏ cùng với các cơ chế cần thiết để giải quyết chúng, chẳng hạn như ủy ban chứng thực và thời hạn hết hạn.
2. Người đề xuất có thể sàng lọc các truy cập ngoài giới hạn trước khi cấp khóa trạng thái.
Lợi ích cho người đề xuất.
1. Khi ý định của người dùng được nêu rõ, người đề xuất có thể lập bản đồ tốt hơn về không gian cơ hội MEV.
2. Người đề xuất có thể dễ dàng cung cấp khóa trạng thái tuần tự cho cùng một miền trong cùng một khối.
3. Một khoản tiền boa duy nhất có nghĩa là người dùng không thể tránh khỏi việc phải trả phí sau thanh toán/phí ưu tiên đầy đủ bằng cách giữ lại khoản tiền theo dõi.
4. Chỉ có một mẹo có thể có nghĩa là mô hình định giá đơn giản hơn.
Nhược điểm đối với người đề xuất.
1. Việc giảm tính tùy chọn có thể làm giảm giá trị của khóa trạng thái đối với người dùng và dẫn đến mức phí ưu tiên thấp hơn cho người đề xuất.
Lợi ích cho người dùng.
1. Giá tiền boa tốt hơn: giả sử rằng việc giảm tính tùy chọn và tăng mức độ tiếp xúc với MEV làm giảm giá trị của khóa trạng thái, thì hệ quả dự kiến là phí ưu tiên thấp hơn.
2. Loại bỏ những phức tạp liên quan đến giao dịch tiếp theo: thời gian, tranh chấp, v.v.
3. Nếu khóa trạng thái tuần tự có thể hoạt động, người dùng sẽ có nhiều lựa chọn hơn.
Nhược điểm đối với người dùng.
1. Không có giao dịch tiếp theo có nghĩa là ít tùy chọn hơn.
2. Người dùng dễ bị khai thác MEV hơn.
3. Bước 4 liên quan đến việc tiết lộ thông tin về các giao dịch chưa được công bố, điều này có thể gây ra lo ngại về quyền riêng tư.
Phụ lục C: Gian lận khóa nhà nước và nghiên cứu L1 ZK
Một trong những khác biệt chính giữa khóa trạng thái và các loại cam kết đề xuất khác là khóa trạng thái tập trung vào các điều kiện trước khi thực hiện hơn là kết quả sau khi thực hiện. Điều này có nghĩa là, hơi ngược đời, gian lận khóa trạng thái hoàn toàn là vấn đề xảy ra trước khi giao dịch tiếp theo được thực hiện. Do đó, nửa đầu của phụ lục này cố gắng làm rõ bản chất của gian lận khóa trạng thái bằng cách xem xét một vài định nghĩa sơ bộ. Nửa sau tiếp tục xem xét một số cách mà nghiên cứu zkEVM L1 hiện tại có thể được phục vụ bằng cách tiến hành nghiên cứu sâu hơn về bằng chứng gian lận khóa trạng thái.
Hai định nghĩa về gian lận khóa trạng thái.
Về cơ bản, có hai cách khác nhau để hiểu về gian lận khóa trạng thái. Cách thứ nhất là nghĩ theo hướng "gian lận ảnh chụp nhanh". Cách thứ hai là tập trung vào "gian lận truy cập đầu tiên". Hai loại gian lận này phản ánh hai cách hiểu khác nhau về việc cấp khóa trạng thái.
Theo cách diễn giải thứ hai, chặt chẽ hơn, lệnh cấp khóa trạng thái hứa hẹn rằng giao dịch tiếp theo của người dùng, T, sẽ là giao dịch đầu tiên được ghi vào bất kỳ miền nào được chỉ định trong tập quyền của T, P. Để rõ ràng hơn, T được gọi là "giao dịch đầu tiên" hoặc có "quyền truy cập đầu tiên". Nếu T khôi phục và một giao dịch sau là giao dịch đầu tiên được ghi vào một miền nào đó trong P, thì lời hứa "giao dịch đầu tiên" vẫn được tôn trọng miễn là không có giao dịch nào trước đó ghi vào một trong các miền của T. Nói một cách ngắn gọn, định nghĩa sơ bộ của chúng tôi như sau:
Gian lận truy cập đầu tiên. Gian lận truy cập đầu tiên xảy ra nếu bất kỳ giao dịch nào ghi trước vào miền được dành riêng bởi giao dịch khóa trạng thái.
Theo cách diễn giải đầu tiên, ít nghiêm ngặt hơn một chút, về việc cấp khóa trạng thái, không có lời hứa truy cập đầu tiên. Lời hứa là T sẽ thực thi trên một tập hợp các cặp giá trị miền được chỉ định bởi ảnh chụp nhanh của T, S. Gian lận ảnh chụp nhanh xảy ra nếu T thực thi trên gốc trạng thái tiền T, Rpre, và Rpre không chứa S (tức là không bao gồm một số cặp giá trị miền được chỉ định bởi S).
Sự khác biệt giữa gian lận truy cập đầu tiên và gian lận ảnh chụp nhanh không chỉ mang tính khái niệm. Nó còn có những hệ quả thực tế khi chứng minh gian lận. Định nghĩa sơ bộ như sau:
Gian lận ảnh chụp nhanh. Gian lận ảnh chụp nhanh xảy ra nếu đối với một số giao dịch khóa trạng thái, T, miền, D và giá trị 32 byte, V, ảnh chụp nhanh cho T chỉ định rằng D ánh xạ tới V trong gốc trạng thái tiền T, Rpre, và Rpre sao cho D ánh xạ tới một số giá trị, V*, trong đó V* ≠ V.
Để chứng minh gian lận ảnh chụp nhanh, trước tiên chúng ta phải suy ra gốc pre-T mà T đã thực thi, Rpre. Sau đó, có thể sử dụng chứng minh bao hàm Merkle để chứng minh D ánh xạ tới V* trong Rpre (ví dụ: bằng cách sử dụng đường dẫn MPT cấp tài khoản đến storageRoot và sau đó là đường dẫn MPT tới D(V*) trong storageRoot). Việc chứng minh D ánh xạ tới V* trong Rpre xác lập rằng T thực sự đã nhìn thấy D(V*). Bước cuối cùng là chứng minh V* ≠ V, trong đó V được lấy từ lệnh cấp khóa trạng thái đã ký.
Để chứng minh gian lận truy cập đầu tiên, điều cần phải chứng minh là một số giao dịch khác, T*, đã được thực hiện trước T và ghi vào một trong các miền của T. Điều này có thể được thực hiện bằng cách chứng minh vị trí tương đối của T* và T trong khối transactionsRoot trie và bằng cách thực hiện lại đến bước trong dấu vết thực thi mà T* đã ghi vào một miền nào đó trong tập quyền của T. Ngược lại với gian lận ảnh chụp nhanh, không cần phải suy ra Rpre mà T đã thực hiện. Nếu T là giao dịch thứ 10 và T* là giao dịch thứ 2, bằng chứng về gian lận truy cập đầu tiên sẽ yêu cầu ít bước hơn bằng chứng về gian lận ảnh chụp nhanh – bằng chứng này phải suy ra kết quả của mọi giao dịch trước T.
Thảo luận ngắn gọn của chúng tôi về gian lận khóa trạng thái chắc chắn sẽ bỏ sót nhiều chi tiết. Ví dụ, nếu T* ghi cùng một giá trị (không có thao tác SSTORE) vào một trong các miền của T, thì gian lận truy cập đầu tiên sẽ xảy ra nhưng gian lận ảnh chụp nhanh thì không. Đó có thể là lý do để yêu cầu cả hai hình thức gian lận phải xảy ra trước khi hình phạt được áp dụng (hoặc để định nghĩa gian lận truy cập đầu tiên theo nghĩa "sửa đổi" thay vì "ghi vào" một miền được bảo lưu). Dù sao đi nữa, mục đích của chúng tôi chỉ đơn giản là làm rõ mô hình khái niệm cơ bản của gian lận khóa trạng thái.
Bằng chứng gian lận khóa trạng thái có thể phục vụ cho nghiên cứu L1 ZK như thế nào.
Quỹ Ethereum tin rằng con đường tốt nhất để Ethereum phát triển là cuối cùng trở thành nền tảng ZK “ ở mọi cấp độ của ngăn xếp ”. Trong bối cảnh đó, cần lưu ý cách nghiên cứu về khóa trạng thái có thể hỗ trợ các mục tiêu đó. Trong phần còn lại, chúng ta sẽ xem xét cách giải quyết tranh chấp khóa trạng thái thông qua thiết kế dựa trên ZK, trong đó dấu vết thực thi được thực hiện lại ngoài chuỗi và bằng chứng ngắn gọn được xác minh trên chuỗi, do đó tránh được chi phí quá cao của việc thực thi lại trong giao thức (mặc dù BAL có tiềm năng giúp việc xử lý tranh chấp trên chuỗi hiệu quả hơn đáng kể về mặt chi phí).
Bằng chứng gian lận khóa trạng thái có tiềm năng tạo ra các cơ hội nghiên cứu độc đáo. Theo giả thuyết , bằng chứng gian lận khóa trạng thái sẽ không bao giờ cần phải thực hiện lại bất cứ điều gì ngoài giao dịch khóa trạng thái cuối cùng. Với giả định hợp lý rằng những người đề xuất ưu tiên sắp xếp theo trình tự cho các giao dịch khóa trạng thái (tức là những người đề xuất đặt chúng ở đầu khối), một bằng chứng gian lận sẽ chỉ cần xử lý một phần của toàn bộ khối. Ngược lại, các hệ thống như SP1 Hypercube của Succinct Labs nhắm mục tiêu vào toàn bộ các khối L1, thường bằng cách tạo ra các bằng chứng khối con và sau đó tổng hợp chúng. Nếu những người đề xuất đặt các giao dịch khóa trạng thái ở đầu khối, các tranh chấp sẽ chỉ cần chứng minh một lát cắt hoặc "tiền tố" sớm thay vì toàn bộ khối, làm cho các mạch chống gian lận nhỏ hơn đáng kể so với bằng chứng zkEVM L1 đầy đủ.
Để minh họa, hãy xem xét ví dụ về gian lận truy cập đầu tiên từ trước đó. Nếu giao dịch ngoài giới hạn, T*, là giao dịch thứ hai trong khối, thì mạch chỉ thực hiện lại hai giao dịch và tái tạo gốc trung gian trước T* bên trong bằng chứng. Tổng quát hơn, nếu T* là giao dịch thứ *i-*, thì mạch chống gian lận truy cập đầu tiên thực hiện lại i giao dịch và tái tạo gốc trung gian i-1 . Đặt trong điều khoản zkEVM toàn khối, bằng chứng gian lận truy cập đầu tiên sẽ tương đương với việc chứng minh một tiền tố nhỏ thay vì toàn bộ khối, vì không cần tổng hợp/hợp thành đệ quy trên nhiều tiền tố. Tương tự như vậy, trong khi bằng chứng gian lận chụp nhanh thường yêu cầu nhiều ràng buộc hơn bằng chứng gian lận truy cập đầu tiên, thì kích thước của mạch vẫn theo thứ tự của bằng chứng tiền tố đơn.
Nhờ các mạch nhỏ và tập trung, bằng chứng gian lận khóa trạng thái có thể mang đến cơ hội thực tế để nghiên cứu các tối ưu hóa cấp độ tiện ích mới. Một ý tưởng là tạo nguyên mẫu một mạch xử lý cùng một vòng Keccak trên nhiều băm độc lập (ví dụ: các nút MPT được mã hóa RLP, dẫn xuất khóa lưu trữ) để trình chứng minh thực hiện một bước "rộng hơn" thay vì nhiều bước "hẹp hơn". Khóa trạng thái là một sự phù hợp tự nhiên cho loại "hợp nhất" vòng hoặc xử lý vòng này: vì sàng lọc ngoài giới hạn loại bỏ các phụ thuộc, khóa trạng thái đã thực thi tính độc lập cần thiết để chạy nhiều băm song song mà không vi phạm thứ tự EVM. Phần thưởng là ít hàng/bước mạch hơn, có thể giảm thời gian chứng minh và cũng có thể cắt giảm kích thước bằng chứng. Mặc dù được thừa nhận là mang tính suy đoán, "hợp nhất" vòng băm là một ví dụ về tối ưu hóa cụ thể mà các mạch khóa trạng thái có thể kiểm tra/xác thực bằng các kết quả được chuyển sang các điểm nóng băm L1.
Bằng chứng gian lận khóa trạng thái cũng có thể được sử dụng như một loại "phòng thí nghiệm thử nghiệm" để đo lường hiệu quả chứng minh và tạo ra dữ liệu thực nghiệm hữu ích. Do "tiền tố" ngắn và một tập hợp tương đối nhỏ các khe được chạm, mạch đủ đơn giản để hiển thị các chi phí thành phần như thời gian cho mỗi khe được mở, byte chứng kiến trên mỗi đường dẫn MPT, v.v. Trong chứng minh toàn khối, các tín hiệu này có xu hướng bị trộn lẫn với các dữ liệu khác (ví dụ: toán học EC/KZG, I/O chứng kiến và tổng hợp), khiến việc khôi phục các số sạch cho từng thành phần trở nên khó khăn hơn. Ngoài ra, bằng chứng gian lận khóa trạng thái có thể đủ nhỏ để chạy trên phần cứng chứng minh "tại nhà" và cho phép thu thập dữ liệu thực nghiệm có giá trị về, ví dụ, các cấu hình năng lượng/RAM/GPU cho các chứng minh "tại nhà". Theo cách này, nghiên cứu bằng chứng gian lận khóa trạng thái có thể bổ sung cho việc đánh giá chuẩn toàn khối bằng cách cung cấp các phép đo chi tiết ở cấp độ thành phần, có thể được ước tính bằng cách sử dụng các bằng chứng nhỏ và ngoại suy trở lại các phân phối khối lượng công việc toàn khối có liên quan (ví dụ: các lần mở SSTORE/SLOAD).
Một lưu ý ở đây là rủi ro cắt giảm sẽ khiến gian lận khóa trạng thái cực kỳ hiếm. Mặc dù vậy, không nhất thiết theo đó bằng chứng gian lận sẽ hiếm khi được yêu cầu. Theo quan điểm của người dùng, hành vi giao dịch bất ngờ là tác nhân chính gây ra yêu cầu gian lận. Vì khóa trạng thái chỉ hứa hẹn các điều kiện trước khi thực hiện, chứ không phải kết quả, nên hành vi bất ngờ có thể không phải là hiếm. Giả sử rằng gian lận thực tế ít phổ biến hơn nhiều so với gian lận bị nghi ngờ, hầu hết các bằng chứng gian lận sẽ phục vụ ngược lại với mục đích danh nghĩa của chúng: chúng sẽ đóng vai trò là bằng chứng "trung thực" xác nhận rằng không có gian lận nào được thực hiện. Trên thực tế, những người đề xuất sẽ có động lực cung cấp các bằng chứng "trung thực" như vậy khi được yêu cầu, đặc biệt nếu chúng có thể được xác minh không chính thức ngoài chuỗi bởi bên thứ ba. Nhu cầu cung cấp bằng chứng "trung thực" kịp thời và hiệu quả tự nhiên sẽ tạo ra động lực cho nghiên cứu và tối ưu hóa.
Cuối cùng, cần lưu ý rằng những lợi ích tiềm năng đối với nghiên cứu L1 ZK được đề xuất ở đây không chỉ giới hạn ở khóa trạng thái. Bất kỳ giao thức xác nhận trước thực thi nào yêu cầu bằng chứng gian lận chứng minh bối cảnh/kết quả thực thi đều có thể tận dụng và thúc đẩy tiến độ nghiên cứu L1 ZK.
