Đây là một hướng dẫn về thực thi bất đồng bộ: cách chúng tôi làm cho nó hoạt động trong Monad, lý do EIP-7702 đã phá vỡ nó, và cách khắc phục. Để có bối cảnh, thực thi bất đồng bộ đã có trong Monad kể từ khi các khách hàng đồng thuận và thực thi được kết nối với nhau. Thực thi bất đồng bộ cho phép thực thi chậm hơn đồng thuận một số khối cố định từ góc độ tương tác. Hầu hết các blockchain có đồng thuận xen kẽ. Nghĩa là, thực thi xảy ra trước đồng thuận, điều này có nghĩa là phải nhồi nhét thực thi vào một ngân sách thời gian mà chỉ là một phần nhỏ của thời gian khối (phần còn lại được chiếm bởi việc truyền thông toàn cầu, hay còn gọi là đồng thuận). Điều này giới hạn lượng gas mỗi giây của hệ thống. Các L2 vượt qua điều này bằng cách không có đồng thuận. Nhưng chúng tôi muốn hành vi của một L1 phân tán, phi tập trung mà vẫn duy trì hiệu suất cao. Thực thi bất đồng bộ cho phép chúng tôi tránh vấn đề này bằng cách di chuyển thực thi ra khỏi con đường nóng của đồng thuận. Thay vào đó, đồng thuận và thực thi diễn ra trong các làn bơi song song. Đồng thuận trên khối 2 xảy ra trong khi thực thi khối 1 đang chạy song song. Tuy nhiên, vẫn cần có sự đồng thuận giữa đồng thuận và thực thi. Cụ thể, sự đồng thuận đó là: thực thi chỉ được phép chậm hơn đồng thuận tối đa k khối, vì các đề xuất khối chứa một gốc merkle bị trì hoãn. Ngoài ra, đồng thuận đang xây dựng các khối với một cái nhìn về trạng thái bị trì hoãn (bị trì hoãn bởi k khối). Điều này có nghĩa là có nguy cơ rằng đồng thuận sẽ bao gồm một giao dịch từ một người gửi mà, vào thời điểm chúng tôi thực thi, hóa ra lại có số dư rỗng. Sẽ rất tệ nếu giao thức cho phép điều này xảy ra, vì nó sẽ mở ra một vector Từ chối dịch vụ (DOS). Do đó, để giải quyết vấn đề này và an toàn cho phép thực thi bất đồng bộ, khách hàng đồng thuận Monad tính toán số MON tối đa mà mỗi giao dịch có thể chi tiêu như sau: MON_spent = gas_bid * gas_limit + value. Khách hàng đồng thuận giữ một danh sách liên tục về số dư tài khoản khả dụng cho mỗi người gửi sau khi trừ MON_spent cho mỗi giao dịch mà họ đã gửi. Dựa trên số dư đang chạy đó, khách hàng đồng thuận chỉ bao gồm các giao dịch nếu họ có thể chắc chắn rằng giao dịch có thể được thanh toán. Đây là một cách tiếp cận bi quan để xây dựng khối vì nó không tính đến khả năng bất kỳ tài khoản nào tăng số dư từ một chuyển khoản vào. Hãy để tôi giải thích điều tôi muốn nói bằng một ví dụ. Giả sử tài khoản của Alice có 100 MON. Sau đó, 3 giao dịch sau được bao gồm trong khối 1000: Tx 1: Alice gửi 20 MON cho Bob, tốn 1 MON phí Tx 2: Alice chi 70 MON để mua một memecoin, tốn 1 MON phí...