Account Abstraction (AA) là một hướng quan trọng cho việc khám phá hệ sinh thái Ethereum trong dài hạn, nhằm phá vỡ ranh giới giữa các tài khoản bên ngoài (EOA) và các tài khoản hợp đồng, giúp ví có thể lập trình, bảo mật và nâng cấp hơn. Là giải pháp triển khai AA phổ biến nhất, EIP-4337 đã được sử dụng rộng rãi trong một số ví hợp đồng thông minh dựa trên EntryPoint (như Safe, Stacks, Argent). Tuy nhiên, EIP-4337 vẫn có một số hạn chế nhất định về tính bản địa trên chuỗi, độ phức tạp về mặt vận hành và khả năng tương thích sinh thái vì nó giới thiệu một nhóm giao dịch độc lập và cơ chế hợp đồng nhập cảnh.
Để hạ thấp hơn nữa ngưỡng sử dụng trừu tượng hóa tài khoản và tăng cường hỗ trợ gốc, Vitalik đã đề xuất EIP-7702 vào năm 2024 và đưa đề xuất này vào bản nâng cấp Pectra. Ý tưởng cốt lõi của EIP-7702 là cho phép EOA gốc thực thi mã hợp đồng (contract_code) của địa chỉ được chỉ định 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 về tiêm mã cấp giao dịch, cho phép tài khoản người dùng chỉ định động 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 truyền thống dựa trên mã tĩnh, mang lại tính linh hoạt cao hơn và cũng đưa ra những thách thức bảo mật mới : các hợp đồng ban đầu 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 cho rằng người gọi là EOA thuần túy cũng có thể bị bỏ qua. Đối với các kiểm toán viên, không chỉ cần xác minh tính bảo mật của chính mã được tiêm mà còn phải đá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 EIP-7702 có thể gặp phải trong quá trình kiểm tra và đề xuất các quy trình kiểm tra cũng như các gợi ý từ góc độ thực tế để giúp các nhà nghiên cứu bảo mật ứng 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-7702
1. Tổng quan kỹ thuật EIP-7702
EIP-7702 giới thiệu loại giao dịch mới 0x 04 (SetCode), cho phép EOA ủy quyền cho mã hợp đồng được thực hiện thông qua giao dịch này. Cấu trúc giao dịch như sau:
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit,
đích, giá trị, dữ liệu, danh sách truy cập, danh sách ủy quyền, chữ ký_y_parity, chữ ký_r, chữ ký_s])
authorization_list chứa nhiều danh sách ủy quyền và cũng có thể chứa các hành vi ủy quyền của những người khởi tạo không phải giao dịch. Cấu trúc bên trong là:
authorization_list = [[chain_id, địa chỉ, nonce, y_parity, r, s]]
Trong số đó, chain_id chỉ ra chuỗi mà quyền hạ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, điều đó có nghĩa là quyền hạn có hiệu lực đối với tất cả các chuỗi EVM hỗ trợ EIP-7702, nhưng tiền đề là các tham số khác (như nonce) phải khớp. Địa chỉ chỉ ra đị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 || address, trong đó address là địa chỉ hợp đồng được ủy quyền. Nếu bạn muốn hủy ủy quyền, chỉ cần khởi tạo giao dịch SetCode để đặt address thành 0 address.
2. Ưu điểm của EIP 7702
(1) Tính linh hoạt và tùy biến
Abstract accounts có thể tùy chỉnh linh hoạt các chức năng theo nhu cầu bằng cách viết logic tài khoản vào hợp đồng thông minh. Ví dụ, người dùng có thể cấu hình đa chữ ký, phục hồi xã hội, kiểm soát giới hạn, v.v. để đáp ứng nhu cầu của các tình huống khác nhau cho cá nhân hoặc doanh nghiệp. 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à phá vỡ các hạn chế của tài khoản bên ngoài truyền thống (EOA).
(2) Tăng cường an ninh
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, họ vẫn 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ố, do đó tránh mất tài sản cố định do mất khóa riêng trong các 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 việc đánh cắp số tiền lớn một cách ác ý.
(3) Tối ưu hóa khí
Tài khoản trừu tượng 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 hoặc thậm chí trực tiếp sử dụng các mã thông báo khác để thanh toán phí giao dịch. Cơ chế này không chỉ giảm chi phí vận hành của người dùng mà còn đơn giản hóa hơn nữa quy trình sử dụng blockchain, đặc biệt là đối với người dùng mới hoặc các tình huống giao dịch nhiều bước phức tạp.
(4) Thúc đẩy sự phổ biến của Web3
Bằ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 ẩn đi sự phức tạp của blockchain khỏi người dùng, cung cấp các hoạt động thuận tiện gần hơn với Web2. Thiết kế này giúp giảm chi phí học tập cho người dùng thông thường , cho phép nhiều người tham gia vào các ứng dụng Web3 mà không có 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 thực hành EIP-7702
Mặc dù EIP-7702 đã tạo ra động lực mới cho hệ sinh thái Ethereum và mở rộng các kịch bản ứng dụng, nhưng nó cũng không tránh khỏi việc gây 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 đặt trường chain_id trong ủy quyền thành 0, điều đó có nghĩa là ủy quyền có hiệu lực trên nhiều chuỗi. Mặc dù thiết kế ủy quyền phổ quát xuyên chuỗi này cải thiện tính linh hoạt trong một số trường hợp, nhưng nó cũng gây ra những rủi ro bảo mật rõ ràng.
Điều quan trọng cần lưu ý là ngay cả khi ID tài khoản của cùng một địa chỉ trên các chuỗi khác nhau là giống nhau, thì việc triển khai hợp đồng cơ bản có thể hoàn toàn khác nhau. Điều này có nghĩa là kẻ tấn công có thể triển khai phiên bản hợp đồng độc hại trên một chuỗi khác và sử dụng hành vi ủy quyền của cùng một địa chỉ trên chuỗi để thực hiện các hoạt động bất ngờ, do đó gây ra 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 hoạt động ủy quyền như vậy, họ phải xác minh rõ ràng xem chainId được khai báo trong ủy quyền của người dùng có nhất quán với mạng hiện đang được kết nối hay không; nếu phát hiện người dùng đặ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 xác thực với chainId 0 theo mặc định ở lớp UI hay không để giảm nguy cơ thao tác sai hoặc tấn công lừa đảo.
2. Các vấn đề về 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
Khi chuyển tiền đến địa chỉ hợp đồng, các hợp đồng ERC-721, ERC-777, ERC 1155 và các hợp đồng token khác hiện tại sẽ gọi giao diện gọi lại tiêu chuẩn (như onERC 721 Received, tokensReceived) để hoàn tất thao tác chuyển tiền. Nếu địa chỉ nhận không triển khai 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 gán mã hợp đồng thông qua thao tác set_code, do đó trở thành tài khoản hợp đồng. Tại thời điểm 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, việc chuyển mã thông báo sẽ không thành công;
Người dùng có thể không nhận được token chính thống nếu không biết điều đó.
Do đó, các nhà phát triển phải đảm bảo rằng hợp đồng mục tiêu được người dùng ủy quyền sẽ triển khai giao diện gọi lại có liên quan để đảm bảo khả năng tương thích với các mã thông báo chính thống.
(2) lỗi xác minh tx.origin
Trong 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 khởi tạo 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.
Nhưng trong trường hợp EIP-7702:
Người dùng ký giao dịch ủy quyền, thực tế được phát sóng bởi relayer hoặc bundler. Khi 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à hợp đồng ví đại diện cho danh tính người dùng.
Do đó, xác minh quyền dựa trên tx.origin == msg.sender sẽ dẫn đến việc từ chối các hoạt động hợp lệ của người dùng và mất độ tin cậy. Tương tự, các hạn chế đối với các lệnh gọi hợp đồng như tx.origin == user cũng sẽ không thành công. Nên từ bỏ tx.origin làm cơ sở cho phán đoán bảo mật và thay vào đó sử dụng cơ chế xác minh chữ ký hoặc ủy quyền.
(3) phán đoán sai lầm isContract
Nhiều hợp đồng sử dụng isContract(address) (kiểm tra độ dài mã địa chỉ) để 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, snap-up, v.v.:
require(!isContract(msg.sender), Không được phép ký hợp đồng)
Theo cơ chế EIP-7702, địa chỉ 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ề true. Hợp đồng sẽ nhầm lẫn xác định người dùng hợp pháp là tài khoản hợp đồng và từ chối cho phép người dùng tham gia vào hoạt động, khiến người dùng không thể sử dụng một số dịch vụ nhất định và có trải nghiệm bị cản trở.
Khi ví hợp đồng trở nên phổ biến hơn, thiết kế dựa vào isContract để xác định xem đó có phải là người dùng hay không không còn an toàn nữa. 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 đảo
Sau khi triển khai cơ chế ủy quyền 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. Khi người dùng ủy quyền cho một hợp đồng độc hại, kẻ tấn công có thể sử dụng nó để giành quyền kiểm soát hoàn toàn đối với tài sản của tài khoản, khiến tiền nhanh chóng bị chuyển hoặc đánh cắp, gây ra rủi ro bảo mật rất cao.
Do đó, điều quan trọng đối với các nhà cung cấp dịch vụ ví là hỗ trợ phân tích giao dịch loại EIP-7702 và các cơ chế xác định rủi ro càng sớm càng tốt . Khi người dùng ký một giao dịch được ủy quyền, giao diện người dùng phải hiển thị rõ ràng và nổi bật địa chỉ hợp đồng mục tiêu và kết hợp thông tin bổ trợ như nguồn hợp đồng và thông tin triển khai để giúp người dùng xác định hành vi lừa đảo hoặc gian lận tiềm ẩn, do đó giảm nguy cơ ký nhầm. Hơn nữa, các dịch vụ ví phải tích hợp các khả năng phân tích bảo mật tự động cho các hợp đồng mục tiêu, chẳng hạn như kiểm tra trạng thái mã nguồn mở của hợp đồng, phân tích mô hình cấp phép và xác định hoạt động nguy hiểm tiềm ẩn, để hỗ trợ người dùng đưa ra phán đoán an toàn hơn trước khi ủy quyền.
Điều đặc biệt quan trọng cần lưu ý là định dạng chữ ký được ủy quyền do EIP-7702 giới thiệu 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ác cảnh báo chữ ký gốc và lời nhắc tương tác của ví, làm tăng thêm nguy cơ người dùng bị lừa ký các hoạt động độc hại. Do đó, việc đưa cơ chế nhận dạng và xử lý cấu trúc chữ ký này vào quá trình triển khai ví sẽ là mắt xích quan trọng trong việc đảm bảo an ninh cho người dùng.
4. Rủi ro hợp đồng ví
(1) Quản lý quyền hợp đồng ví
Nhiều hợp đồng ví EIP-7702 sử 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 mang lại rủi ro quản lý quyền cao hơn. Nếu quyền nâng cấp 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 người dùng bị giả mạo hoặc tiền bị đánh cắp.
Mẹo an toàn:
Sử dụng cơ chế xác thực đa chữ ký, đa yếu tố hoặc khóa thời gian để kiểm soát quyền nâng cấp.
Việc thay đổi mã và quyền phải trải qua quá trình kiểm tra và xác minh bảo mật nghiêm ngặt.
Quá trình nâng cấp được thực hiện công khai và 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ô lập dữ liệu
Các 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ẽ dẫn đến xung đột biến trạng thái , ghi đè dữ liệu, bất thường khi đọc và các vấn đề khác. Điều này không chỉ có thể phá hủy chức năng bình thường của ví mà còn gây ra mất tiền hoặc bất thường về quyền.
Mẹo an toàn:
Sử dụng giải pháp cô lập lưu trữ chuyên dụng (như tiêu chuẩn EIP-1967) hoặc sử 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 để tránh tình trạng chồng chéo.
Kiểm tra chặt chẽ tính hợp lý của trạng thái lưu trữ trong quá trình nâng cấp.
(3) Quản lý nonce trong ví
Hợp đồng ví thường thiết lập nonce nội bộ 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, các hoạt động của người dùng sẽ không được thực hiện bình thường.
Mẹo an toàn:
Nonce phải được kiểm tra nghiêm ngặt về tính bằng nhau (hoặc tăng dần) và không thể bỏ qua.
Các hàm bị cấm sửa đổi trực tiếp nonce. Nonce sẽ chỉ được cập nhật đồng bộ khi người dùng thực hiện các thao tác.
Thiết kế cơ chế chịu lỗi và phục hồi cho các bất thường nonce để tránh tình trạng bế tắc nonce.
(4) Kiểm tra quyền của người gọi hàm
Để đảm bảo an ninh, hợp đồng ví phải đảm bảo rằng người gọi các 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:
Xác thực chữ ký ngoài chuỗi
Người dùng ký một tập hợp các hoạt động bằng khóa riêng và hợp đồng ví sẽ xác minh trên chuỗi xem chữ ký có hợp lệ, đã hết hạn và đáp ứng nonce tương ứng hay không. Phương pháp này phù hợp với chế độ giao dịch chuyển tiếp được EIP-7702 ủng hộ (chữ ký ngoại tuyến của người dùng + giao dịch của tác nhân chuyển tiếp).
Ràng buộc cuộc gọi (msg.sender == address(this))
Các chức năng hoạt động của người dùng chỉ được phép kích hoạt bởi chính hợp đồng, về cơ bản là 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 là EOA gốc, vì địa chỉ hợp đồng tại thời điểm này là địa chỉ EOA.
3. Outlook: EIP-7702 và tiêu chuẩn ví AA trong tương lai
Việc giới thiệu EIP-7702 không chỉ là một cải tiến 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 cho hệ sinh thái Account Abstraction. Khả năng người dùng tải mã hợp đồng được giới thiệu bởi nó mang lại không gian rộng lớn để khám phá 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 cho các tiêu chuẩn kiểm toán bảo mật.
1. Đồng tiến hóa với EIP-4337: hướng tới khả năng tương thích chế độ kép
Mặc dù EIP-7702 và EIP-4337 có mục tiêu thiết kế khác nhau, mục tiêu trước tái cấu trúc cơ chế tải mã tài khoản, trong khi mục tiêu sau xây dựng hệ sinh thái đóng gói và nhập giao dịch hoàn chỉnh. Tuy nhiên, cả hai không xung đột mà bổ sung cho nhau rất nhiều:
● 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 cấp quyền logic hợp đồng một cách linh hoạt mà không cần thay đổi địa chỉ;
Do đó, ví có thể áp dụng kiến trúc hỗ trợ chế độ kép trong tương lai: sử dụng EIP-7702 như một giải pháp thay thế nhẹ trên các chuỗi không hỗ trợ EIP-4337 và tiếp tục dựa vào toàn bộ ngăn xếp giao thức của EIP-4337 trong các trường hợp 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ác cơ chế hạ cấp và các giải pháp 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
Cơ chế hợp đồng tài khoản được EIP-7702 ủng hộ có tiềm năng tích hợp tự nhiên với các kiến trúc mới phổ biến hiện nay như ví MPC, ví ZK và ví mô-đun:
● Ở chế độ MPC, hành vi ký không còn dựa vào một khóa riêng duy nhất nữa mà dựa vào quyết định hợp tác của nhiều bên. Chữ ký được tạo ra bởi sự kết hợp của EIP-7702 và MPC có thể kiểm soát logic hợp đồng được tải động, do đó đạt được chiến lược thực hiện linh hoạt hơn.
● Ví ZK xác minh danh tính hoặc quyền hạn của người dùng 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 đưa vào các hợp đồng logic cụ thể sau khi xác minh hoàn tất, do đó thực hiện triển khai 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 một số điều kiện riêng tư nhất định.
● Ví mô-đun có thể sử dụng EIP-7702 để chia nhỏ logic tài khoản thành nhiều mô-đun và tải chúng một cách linh hoạt khi cần.
Do đó, EIP-7702 cung cấp bộ chứa thực thi gốc hơn cho các ví tiên tiến được đề cập ở trên: có thể đưa vào các logic hợp đồng khác nhau trong khi vẫn giữ nguyên địa chỉ người dùng, tránh các vấn đề phụ thuộc địa chỉ trong quy 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à khả năng 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à kiểm toán viên
EIP-7702 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 chỉ coi người gọi là EOA truyền thống hoặc tài khoản hợp đồng cố định nữa mà phải thích ứng với một cơ chế mới: danh tính 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ố định tĩnh nữa mà có thể thay đổi linh hoạt theo nhu cầu. Điều này đòi hỏi các nhà phát triển và kiểm toán viên phải có:
Giới thiệu logic xác minh người gọi và phán đoán quyền hạn chặt chẽ 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õ sự phụ thuộc vào 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 nhiệm;
Hỗ trợ phân tích mô phỏng và phục hồi các kịch bản setCode ở cấp độ chuỗi công cụ.
Nói cách khác, bảo mật mã không còn chỉ là vấn đề trước khi triển khai mà đã trở thành quy trình động phải được xác minh trong quá trình gọi điện và giao dịch.
IV. Kết luận
EIP-7702 giới thiệu một triển khai nhẹ hơn, gốc và linh hoạt hơn cho trừu tượng hóa tài khoản (AA), cho phép EOA thông thường mang và thực thi logic hợp đồng trong một giao dịch duy nhất. Cơ chế này phá vỡ giả định tĩnh truyền thống về hành vi tài khoản. Các nhà phát triển không còn có thể chỉ dựa vào trạng thái mã của địa chỉ tài khoản để xác định mô hình hành vi của nó nữa mà cần phải tái cấu trúc lại sự hiểu biết về danh tính và ranh giới quyền của người gọi.
Sau đây là sự thay đổi mô hình trong phân tích bảo mật. Trọng tâm của việc kiểm toán không còn giới hạn ở một địa chỉ nhất định có được cấp phép hay không, mà chuyển sang 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 hành vi độc lập, cung cấp cho tài khoản các chức năng mạnh hơn và cũng đặt ra các yêu cầu cao hơn đối với kiểm toán bảo mật.
