Beosin: EIP-7702 và phân tích kiểm tra bảo mật ví AA thế hệ tiếp theo

Abstraction (AA) là một hướng quan trọng của việc khám phá dài hạn trong hệ sinh thái Ethereum, nhằm phá vỡ ranh giới giữa tài khoản bên ngoài (EOA) và tài khoản hợp đồng, để ví có khả năng lập trình, bảo mật và khả năng nâng cấp mạnh mẽ hơn. EIP-4337 hiện là giải pháp triển khai AA chính thống nhất và đã được sử dụng rộng rãi trong một số ví hợp đồng thông minh dựa trên EntryPoint (chẳng hạn như Safe, Stacks và Argent). Tuy nhiên, EIP-4337 vẫn có những hạn chế nhất định về tính gốc trên chuỗi, độ phức tạp hoạt động và khả năng tương thích sinh thái do giới thiệu một nhóm giao dịch độc lập và cơ chế hợp đồng trên đường dốc.

Để giảm hơn nữa rào cản gia nhập và tăng cường hỗ trợ bản địa cho các trừu tượng tài khoản, Vitalik đã đề xuất EIP-7702 vào năm 2024 và đưa nó vào bản nâng cấp Pectra. Ý tưởng cốt lõi của EIP-7702 là cho phép EOA ban đầu thực thi mã hợp đồng (contract_code) của một địa chỉ cụ thể khi bắt đầu giao dịch và sử dụng mã này để xác định logic thực thi của giao dịch.

EIP-7702 giới thiệu một cơ chế mới cho "chèn mã cấp giao dịch", cho phép tài khoản người dùng tự động chỉ định logic thực thi trong mỗi giao dịch, thay vì dựa vào mã hợp đồng được triển khai trước. Điều này phá vỡ mô hình cấp phép dựa trên mã tĩnh truyền thống, mang lại tính linh hoạt cao hơn và đưa ra những thách thức bảo mật mới: các hợp đồng dựa trên logic phán đoán như isContract và extcodehash có thể trở nên không hợp lệ và một số hệ thống giả định rằng người gọi là EOA thuần túy cũng có thể bị bỏ qua. Đối với kiểm toán viên, điều quan trọng không chỉ là xác minh tính bảo mật của chính mã được chèn mà còn đánh giá tác động tiềm ẩn của nó đối với các hệ thống hợp đồng khác trong bối cảnh động.

Trong bài viết này, nhóm bảo mật Beosin sẽ tập trung vào các nguyên tắc thiết kế và các tính năng chính của EIP-7702, phân loại một cách có hệ thống các rủi ro bảo mật mà ví AA được xây dựng dựa trên nó có thể gặp phải trong quá trình kiểm toán, đồng thời đưa ra quy trình kiểm toán và đề xuất từ góc độ thực tế để giúp các nhà nghiên cứu bảo mật đối phó tốt hơn với các thách thức kỹ thuật theo mô hình mới này.

1. Giới thiệu về EIP-77021

. Tổng quan kỹ thuật EIP-7702EIP-7702

giới thiệu một loại giao dịch mới, 0x 04 (SetCode), cho phép EOA ủy quyền mã hợp đồng cần được thực hiện thông qua giao dịch này, với cấu trúc giao dịch sau:

1. rlp([chain_id, nonce, max_priority_fee_per_gas, max_ fee_per_gas, gas_limit, đích

2. , giá trị, dữ liệu, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Trong trường hợp authorization_list chứa nhiều danh sách ủy quyền và cũng có thể chứa các hành động ủy quyền của những người khởi tạo không phải giao dịch, cấu trúc nội bộ là:

1. authorization_list = [[chain_id, address, nonce, y_parity, r, s]].

trong đó chain_id đại diện cho chuỗi mà ủy quyền của người dùng có hiệu lực và giá trị của nó phải bằng ID chuỗi của chuỗi thực thi hoặc 0. Khi chain_id bằng 0, ủy quyền có hiệu lực đối với tất cả các chuỗi EVM hỗ trợ EIP-7702, nhưng chỉ khi các tham số khác (chẳng hạn như nonce) khớp nhau. địa chỉ cho biết địa chỉ hợp đồng mục tiêu được người dùng ủy quyền.

Sau khi ủy quyền hoàn tất, hệ thống sẽ sửa đổi trường mã của người dùng được ủy quyền thành 0x ef 0100 || địa chỉ, trong đó địa chỉ là địa chỉ hợp đồng được ủy quyền. Nếu bạn muốn hủy ủy quyền, chỉ cần bắt đầu giao dịch SetCode với địa chỉ được đặt thành 0.

2. Ưu điểm của EIP 7702

(1) Tính linh hoạt và tùy chỉnh

tài khoản trừu tượngBằng cách viết logic tài khoản vào hợp đồng thông minh, bạn có thể linh hoạt tùy chỉnh các chức năng theo nhu cầu của mình. Ví dụ: người dùng có thể định cấu hình đa chữ ký, phục hồi xã hội và kiểm soát hạn ngạch để đáp ứng nhu cầu của cá nhân hoặc doanh nghiệp trong các tình huống khác nhau. Thiết kế này cải thiện đáng kể khả năng mở rộng chức năng của tài khoản và vượt qua những hạn chế của tài khoản bên ngoài (EOA) truyền thống.

(2)

Bảo mật nâng cao Tài khoản trừu tượng cung cấp cơ chế bảo mật nhiều lớp, bao gồm xác thực đa yếu tố, giới hạn giao dịch và phục hồi xã hội. Ngay cả khi người dùng mất khóa riêng tư, họ có thể khôi phục tài khoản của mình thông qua các liên hệ đáng tin cậy hoặc xác thực đa yếu tố, tránh mất tài sản vĩnh viễn do mất khóa riêng trong tài khoản truyền thống. Đồng thời, các chức năng như kiểm soát giới hạn cũng có thể ngăn chặn số lượng lớn tiền bị đánh cắp một cách ác ý.

(3) Tài

khoản trừu tượng hóa Gas hỗ trợ cơ chế trừu tượng hóa gas linh hoạt, cho phép người dùng thanh toán Gas thông qua bên thứ ba và thậm chí trực tiếp sử dụng các token khác để thanh toán phí giao dịch. Cơ chế này không chỉ giảm chi phí hoạt động của người dùng mà còn đơn giản hóa hơn nữa việc sử dụng blockchain, đặc biệt phù hợp với người dùng mới làm quen hoặc các kịch bản giao dịch nhiều bước phức tạp.

(4) Thúc đẩy phổ biến Web3Bằng cách

tối ưu hóa trải nghiệm và bảo mật, các tài khoản trừu tượng che giấu sự phức tạp của blockchain ở những nơi mà người dùng không thể nhìn thấy, cung cấp các hoạt động thuận tiện gần hơn với Web2. Thiết kế này làm giảm chi phí học tập của người dùng bình thường, cho phép nhiều người tham gia vào các ứng dụng Web3 mà không gặp rào cản và thúc đẩy sự phổ biến của công nghệ phi tập trung.

2. Phân tích rủi ro bảo mật trong EIP-7702 trong thực tế

Mặc dù EIP-7702 đã tạo động lực mới cho hệ sinh thái Ethereum và mở rộng vô số kịch bản ứng dụng, nhưng đồng thời, nó chắc chắn đã đưa ra một số rủi ro bảo mật mới:

1. Tấn công phát lại ủy quyền

Theo mô hình EIP-7702, nếu người dùng ủy quyền chain_ Nếu trường id được đặt thành 0, ủy quyền có thể có hiệu lực trên nhiều chuỗi. Mặc dù thiết kế "ủy quyền phổ quát chuỗi chéo" này cải thiện tính linh hoạt trong một số tình huống, nhưng nó cũng gây ra rủi ro bảo mật rõ ràng.

Điều quan trọng cần lưu ý là ngay cả khi danh tính tài khoản của cùng một địa chỉ giống nhau trên các chuỗi khác nhau, việc triển khai hợp đồng đằng sau nó có thể hoàn toàn khác. Điều này có nghĩa là kẻ tấn công có thể triển khai phiên bản độc hại của hợp đồng trên một chuỗi khác và thực hiện các hành động ngoài ý muốn bằng cách sử dụng sự ủy quyền của cùng một địa chỉ trên chuỗi, do đó gây rủi ro cho tài sản của người dùng.

Do đó, đối với các nhà cung cấp dịch vụ ví hoặc nền tảng tương tác front-end, khi người dùng thực hiện các thao tác ủy quyền như vậy, họ cần xác minh rõ ràng liệu chainId được khai báo trong ủy quyền của người dùng có phù hợp với mạng kết nối hiện tại hay không; Nếu người dùng được phát hiện đặt chainId thành 0, cần đưa ra cảnh báo rủi ro rõ ràng để nhắc nhở người dùng rằng ủy quyền sẽ có hiệu lực trên tất cả các chuỗi tương thích với EVM và có thể bị lạm dụng bởi các hợp đồng độc hại.

Ngoài ra, nhà cung cấp dịch vụ cũng nên đánh giá xem có nên hạn chế hay cấm ủy quyền với chainId 0 theo mặc định tại lớp giao diện người dùng để giảm nguy cơ hoạt động sai hoặc tấn công lừa đảo.

2. Khả năng tương thích hợp đồng

1) Khả năng tương thích gọi lại hợp đồng

chuyển tiền đến địa chỉ hợp đồng cho các hợp đồng token hiện có như ERC-721, ERC-777 và ERC 1155, họ sẽ gọi các giao diện callback tiêu chuẩn (chẳng hạn như onERC 721 Received, tokensReceived) để hoàn tất thao tác chuyển. Nếu địa chỉ nhận không thực hiện giao diện tương ứng, việc chuyển tiền sẽ không thành công hoặc thậm chí khiến tài sản bị khóa.

Trong EIP-7702, địa chỉ người dùng có thể được chuyển đổi thành tài khoản hợp đồng bằng cách được cung cấp mã hợp đồng thông qua thao tác "set_code". Trong trường hợp này:

• Địa chỉ người dùng được coi là hợp đồng;

• Nếu hợp đồng không triển khai giao diện gọi lại cần thiết, quá trình chuyển token sẽ không thành công;

• Người dùng có thể không nhận được token chính thống mà họ không biết.

Do đó, các nhà phát triển nên đảm bảo rằng hợp đồng mục tiêu do người dùng ủy quyền thực hiện giao diện callback có liên quan để đảm bảo khả năng tương thích với token chính thống.

(2) Xác minh "tx.origin" không thành côngTrong các

hợp đồng truyền thống, "tx.origin" thường được sử dụng để xác định xem giao dịch có được người dùng trực tiếp bắt đầu hay không và được sử dụng để ngăn chặn các biện pháp kiểm soát bảo mật như lệnh gọi hợp đồng.

Tuy nhiên, trong kịch bản EIP-7702,

• người dùng ký một giao dịch ủy quyền và người chuyển đổi hoặc người đóng gói phát giao dịch đó thay mặt cho người dùng. Khi một giao dịch được thực hiện, "tx.origin" là địa chỉ relayer, không phải địa chỉ người dùng.

• "msg.sender" là một hợp đồng ví đại diện cho danh tính của người dùng.

Do đó, việc xác minh quyền dựa trên "tx.origin == msg.sender" sẽ khiến các hoạt động hợp pháp của người dùng bị từ chối và mất độ tin cậy, đồng thời các lệnh gọi hợp đồng bị hạn chế tương tự như "tx.origin == user" cũng sẽ bị vô hiệu. Bạn nên từ bỏ "tx.origin" làm cơ sở để đánh giá bảo mật và thay vào đó sử dụng cơ chế xác minh hoặc ủy quyền chữ ký.

(3) "isContract" đánh giá saiNhiều

hợp đồng ngăn tài khoản hợp đồng tham gia vào một số hoạt động nhất định, chẳng hạn như airdrop, flash sale, v.v., thông qua "isContract(address)":

require(!isContract(msg.sender), "Hợp đồng không được phép"

). Theo cơ chế EIP-7702, địa chỉ của người dùng có thể được thay đổi thành tài khoản hợp đồng thông qua giao dịch "set_code" và "isContract" trả về đúng và hợp đồng sẽ xác định nhầm người dùng hợp pháp là tài khoản hợp đồng và từ chối tham gia hoạt động, dẫn đến người dùng không thể sử dụng một số dịch vụ nhất định và trải nghiệm bị chặn.

Với sự phổ biến dần dần của ví hợp đồng, thiết kế dựa vào "isContract" để xác định xem "người dùng con người" có còn an toàn hay không và nên sử dụng các phương pháp nhận dạng người dùng chính xác hơn như xác minh chữ ký.

3. Tấn công lừa đảoSau khi

triển khai cơ chế ủy quyền của EIP-7702, tài sản trong tài khoản của người dùng sẽ được kiểm soát hoàn toàn bởi hợp đồng thông minh được ủy quyền. Một khi người dùng ủy quyền một hợp đồng độc hại, kẻ tấn công có thể giành được toàn quyền kiểm soát tài sản tài khoản, dẫn đến việc chuyển tiền hoặc đánh cắp tiền nhanh chóng, điều này cực kỳ rủi ro.

Do đó, đối với các nhà cung cấp dịch vụ ví, cần hỗ trợ cơ chế giải quyết giao dịch và nhận diện rủi ro EIP-7702 càng sớm càng tốtChủ yếu. Khi người dùng ký giao dịch ủy thác, giao diện người dùng nên hiển thị rõ ràng và nổi bật địa chỉ hợp đồng mục tiêu, đồng thời kết hợp các thông tin hỗ trợ như nguồn hợp đồng và thông tin triển khai để giúp người dùng xác định các hành vi lừa đảo hoặc gian lận tiềm ẩn, từ đó giảm nguy cơ ký sai. Hơn nữa, dịch vụ ví nên tích hợp khả năng phân tích bảo mật tự động cho hợp đồng mục tiêu, chẳng hạn như kiểm tra trạng thái mã nguồn mở mã hợp đồng, phân tích mô hình quyền và xác định hoạt động nguy hiểm tiềm ẩn, để giúp người dùng đưa ra phán đoán an toàn hơn trước khi ủy quyền.

Đặc biệt, EIP-7702 giới thiệu định dạng chữ ký được ủy quyền không tương thích với các tiêu chuẩn chữ ký EIP-191 và EIP-712 hiện có. Chữ ký của nó có thể dễ dàng bỏ qua cảnh báo chữ ký ban đầu và lời nhắc tương tác của ví, điều này càng làm tăng nguy cơ người dùng bị lừa ký các hoạt động độc hại. Do đó, việc giới thiệu cơ chế nhận dạng và xử lý cấu trúc chữ ký trong việc triển khai ví sẽ là mắt xích quan trọng để đảm bảo tính bảo mật cho người dùng.

4. Rủi ro hợp đồng ví(

1) Quản lý thẩm quyền hợp đồng ví Nhiều

hợp đồng ví EIP-7702 áp dụng kiến trúc proxy (hoặc quyền quản lý tích hợp) để hỗ trợ nâng cấp logic. Tuy nhiên, điều này cũng gây ra rủi ro cao hơn về quản lý quyền. Nếu các đặc quyền leo thang không bị hạn chế nghiêm ngặt, kẻ tấn công có thể thay thế hợp đồng triển khai và chèn mã độc, dẫn đến tài khoản của người dùng bị giả mạo hoặc tiền bị đánh cắp.

Khuyến nghị bảo mật

• : Sử dụng cơ chế đa chữ ký, xác thực đa yếu tố hoặc khóa thời gian để kiểm soát đặc quyền leo thang.

• Các thay đổi về mã và quyền phải được kiểm tra nghiêm ngặt và xác thực bảo mật.

• Quá trình nâng cấp được công khai, minh bạch để đảm bảo quyền được biết và tham gia của người dùng.

(2) Rủi ro xung đột lưu trữ và cách ly dữ liệu,

phiên bản hợp đồng ví hoặc các nhà cung cấp dịch vụ ví khác nhau có thể sử dụng lại cùng một khe lưu trữ. Nếu người dùng thay đổi nhà cung cấp dịch vụ ví hoặc nâng cấp logic ví, việc sử dụng lại khe lưu trữ sẽ gây ra xung đột biến trạng thái, ghi đè dữ liệu, đọc ngoại lệ và các vấn đề khác. Điều này không chỉ có thể làm gián đoạn hoạt động bình thường của ví mà còn có thể dẫn đến mất tiền hoặc các quyền bất thường.

Khuyến nghị bảo mật:

• Sử dụng sơ đồ cách ly lưu trữ chuyên dụng, chẳng hạn như tiêu chuẩn EIP-1967 hoặc tận dụng không gian tên duy nhất để quản lý các khe lưu trữ.

• Khi nâng cấp hợp đồng, hãy đảm bảo rằng bố cục lưu trữ tương thích và tránh chồng chéo các biến.

• Kiểm tra nghiêm ngặt tính hợp lý của trạng thái được lưu trữ trong quá trình nâng cấp.

(3) Quản lý nonce bên trong ví

Hợp đồng ví thường thiết lập một nonce bên trong và tự quản lý để đảm bảo thứ tự thực hiện các hoạt động của người dùng và ngăn chặn các cuộc tấn công phát lại. Nếu nonce được sử dụng không đúng cách, thao tác của người dùng sẽ không được thực hiện đúng cách.

Khuyến nghị bảo mật:

• Nonce phải được kiểm tra cưỡng bức để tìm giá trị tương đương (hoặc gia tăng) và không thể bỏ qua.

Các

• chức năng không được trực tiếp sửa đổi nonce và nonce sẽ chỉ được cập nhật khi thao tác của người dùng được thực hiện.

• Thiết kế cơ chế phục hồi và khả năng chịu lỗi cho các ngoại lệ nonce để tránh bế tắc nonce.

(4) Kiểm tra quyền gọi chức năngĐể

đảm bảo tính bảo mật, hợp đồng ví phải đảm bảo rằng người gọi chức năng chính là tài khoản chủ sở hữu của ví. Hai phương pháp phổ biến bao gồm:

• ký ngoài chuỗi cho phép

người dùng ký một tập hợp các hoạt động thông qua khóa riêng tư và hợp đồng ví xác minh xem chữ ký có hợp pháp, hết hạn và thỏa mãn nonce tương ứng trên chuỗi hay không. Phương pháp này có thể áp dụng cho chế độ giao dịch chuyển tiếp do EIP-7702 ủng hộ (chữ ký ngoại tuyến của người dùng + người chuyển giao thay cho người dùng).

• ràng buộc cuộc gọi (msg.sender == address(this))

chỉ được phép kích hoạt bởi chính hợp đồng, về cơ bản là một cơ chế kiểm soát đường dẫn cuộc gọi đảm bảo rằng người khởi tạo bên ngoài phải là chính tài khoản. Điều này thực sự tương đương với việc yêu cầu người gọi phải là EOA ban đầu, vì địa chỉ hợp đồng là địa chỉ EOA.

3. Triển vọng: Đề xuất EIP-7702 và tiêu chuẩn ví AA trong tương lai

EIP-7702 không chỉ là một sự đổi mới của mô hình tài khoản truyền thống mà còn là một sự thúc đẩy lớn của hệ sinh thái trừu tượng tài khoản. Khả năng tải mã hợp đồng do nó giới thiệu mang lại một không gian rộng lớn để khám phá cho thiết kế ví và hệ thống hợp đồng trong tương lai, đồng thời đưa ra các yêu cầu mới đối với các tiêu chuẩn kiểm toán bảo mật.

1. Đồng phát triển với EIP-4337: Hướng tới khả năng tương thích chế độ képMặc dù

EIP-7702 và EIP-4337 có mục tiêu thiết kế khác nhau, nhưng EIP-7702 và EIP-4337 xây dựng lại cơ chế tải mã của tài khoản và sau xây dựng một hệ sinh thái đóng gói và nhập giao dịch hoàn chỉnh. Tuy nhiên, cả hai không mâu thuẫn mà có tính bổ sung mạnh mẽ:

● EIP-4337 cung cấp "kênh giao dịch chung" và "giao diện thực hiện tài khoản trừu tượng";

● EIP-7702 cho phép tài khoản người dùng tự động cấp khả năng logic hợp đồng mà không cần thay đổi địa chỉ;

Do đó, trong tương lai, ví có thể áp dụng "kiến trúc hỗ trợ chế độ kép": sử dụng EIP-7702 như một sự thay thế nhẹ trên các chuỗi không hỗ trợ EIP-4337 và tiếp tục dựa vào ngăn xếp giao thức đầy đủ của EIP-4337 trong các tình huống yêu cầu đóng gói ngoài chuỗi và tổng hợp nhiều người dùng.

Cơ chế chế độ kép này cũng sẽ cho phép ví hỗ trợ các mô hình cấp phép tài khoản linh hoạt hơn, cơ chế hạ cấp và sơ đồ khôi phục ở lớp nhân.

2. Hỗ trợ và truyền cảm hứng cho logic ví mới như MPC và ZK, và

cơ chế hợp đồng tài khoản do EIP-7702 ủng hộ có tiềm năng tích hợp tự nhiên với ví MPC phổ biến hiện nay, ví ZK, ví mô-đun và các kiến trúc mới khác:

● Trong mô hình MPC, hành vi chữ ký không còn dựa vào một khóa riêng duy nhất mà là việc ra quyết định hợp tác nhiều bên. Chữ ký được tạo ra thông qua sự hội tụ của EIP-7702 và MPC kiểm soát logic hợp đồng được tải động, cho phép các chiến lược thực hiện linh hoạt hơn.

● Ví ZK xác minh danh tính người dùng hoặc ủy quyền thông qua bằng chứng không kiến thức mà không tiết lộ thông tin khóa riêng tư. Kết hợp với EIP-7702, ví ZK có thể tạm thời chèn các hợp đồng logic cụ thể sau khi xác minh xong, để thực hiện việc triển khai các hành vi được cá nhân hóa sau khi tính toán quyền riêng tư, chẳng hạn như tự động thực hiện một logic nhất định chỉ sau khi đáp ứng các điều kiện bảo mật nhất định.

● Ví mô-đun có thể sử dụng EIP-7702 để tháo rời logic tài khoản thành nhiều mô-đun và tự động tải chúng khi cần.

Do đó, EIP-7702 cung cấp một "vùng chứa thực thi" gốc hơn cho các ví nâng cao nêu trên: logic hợp đồng khác nhau có thể được đưa vào cùng một địa chỉ người dùng, tránh vấn đề phụ thuộc địa chỉ trong quá trình triển khai hợp đồng truyền thống và loại bỏ nhu cầu triển khai trước, cải thiện đáng kể tính linh hoạt và kết hợp của hành vi tài khoản.

3. Ý nghĩa đối với các nhà phát triển hợp đồng và

sẽ thúc đẩy một sự thay đổi sâu sắc trong mô hình phát triển. Các nhà phát triển hợp đồng không còn đơn giản coi người gọi như một EOA truyền thống hoặc một tài khoản hợp đồng cố định, mà phải thích ứng với một cơ chế mới: danh tính của người gọi có thể được chuyển đổi động giữa EOA và trạng thái hợp đồng trong quá trình giao dịch và logic hành vi tài khoản không còn được củng cố tĩnh mà có thể được thay đổi linh hoạt theo nhu cầu. Điều này yêu cầu các nhà phát triển và kiểm toán viên:

• giới thiệu xác minh người gọi và logic đánh giá quyền nghiêm ngặt hơn;

• Kiểm tra xem đường dẫn cuộc gọi có bị ảnh hưởng bởi logic hợp đồng động hay không;

• xác định các lỗ hổng tiềm ẩn dựa trên các hành vi như msg.sender.code.length == 0, isContract(), v.v.;

• Làm rõ "phụ thuộc ngữ cảnh" của logic hợp đồng, chẳng hạn như kiểm soát ranh giới của các cuộc gọi tĩnh và các cuộc gọi ủy quyền;

• Ở cấp độ chuỗi công cụ, mô phỏng và phân tích hoàn nguyên các kịch bản setCode được hỗ trợ.

Nói cách khác, bảo mật mã không còn chỉ là một "vấn đề trước khi triển khai" mà là một "quá trình động phải được xác minh trong quá trình gọi và giao dịch".

4.

giới thiệu việc triển khai Trừu tượng tài khoản (AA) nhẹ hơn, nguyên bản và linh hoạt, để EOA thông thường có thể mang logic hợp đồng và thực hiện nó trong một giao dịch duy nhất. Cơ chế này phá vỡ các giả định tĩnh truyền thống về hành vi tài khoản và các nhà phát triển không còn có thể chỉ đơn giản dựa vào trạng thái mã của địa chỉ tài khoản để đánh giá mô hình hành vi của nó, mà cần xây dựng lại sự hiểu biết về ranh giới danh tính và thẩm quyền của người gọi.

Cùng với đó là sự thay đổi mô hình trong phân tích bảo mật. Trọng tâm của kiểm toán không còn giới hạn ở "liệu một địa chỉ có quyền hay không", mà là "logic hợp đồng được thực hiện trong giao dịch có thể làm gì trong bối cảnh hiện tại". Mỗi giao dịch có thể mang một định nghĩa độc lập về hành vi, điều này mang lại cho tài khoản chức năng lớn hơn và đưa ra các yêu cầu cao hơn đối với kiểm tra bảo mật.