# EVM ++

> Ritual EVM ++ là gì?

**Published by:** [Saint Lee](https://paragraph.com/@saintlee/)
**Published on:** 2025-11-25
**URL:** https://paragraph.com/@saintlee/ritual-evm

## Content

Tổng quanEVM++ là một phần mở rộng tương thích ngược của Ethereum Virtual Machine (EVM), với các pre-compile hỗ trợ tính toán mở rộng để xây dựng smart contract thực sự thông minh, cùng lập lịch gốc, trừu tượng hóa tài khoản tích hợp sẵn và các EIP được mong muốn nhất. Các thành phần của EVM++ EVM++ cho phép các nhà phát triển smart contract tiến dần đến áp dụng các chức năng nâng cao của Ritual Foundation Chain, trong khi vẫn sử dụng bộ công cụ họ đã biết và yêu thích:Scheduled Transactions: thực thi giao dịch lặp lại hoặc có điều kiện mà không cần keeper bên ngoài. Account Abstraction: tài khoản smart contract gốc thông qua EIP-7702. EIP Extensions: hỗ trợ liên tục và tích hợp các EIP được yêu cầu nhiều nhất, giúp cải thiện trải nghiệm người dùng và nhà phát triển. Expressive compute: pre-compile tính toán dị thể để cung cấp năng lượng cho các ứng dụng hoàn toàn mới. Account AbstractionBối cảnh (Background)Ngày nay, các blockchain dựa trên Ethereum hỗ trợ hai loại tài khoản:Externally-owned accounts (EOAs): các tài khoản được kiểm soát thông qua quyền sở hữu một khóa riêng tưSmart contract accounts: các tài khoản được kiểm soát bởi mã (code) được triển khai lên mạngTrong lịch sử, các tài khoản EOA bị hạn chế về mặt chức năng: người dùng có thể gửi và nhận các giao dịch blockchain được ký bởi khóa riêng tư của họ và không có gì hơn. Ngược lại, các tài khoản smart contract cho phép khả năng gần như vô hạn, bao gồm:Batch calls: gửi nhiều giao dịch cùng một lúcGas fee sponsorship: giao dịch không phí cho người dùngArbitrary signing keys: sử dụng nhiều cơ chế chữ ký khác nhau (P256, BLS, v.v.)Advanced ACLs: gán quyền sử dụng chi tiết và kiểm soát thời hạn truy cậpAccount Abstraction tìm cách xóa nhòa ranh giới giữa EOA và smart contract account bằng cách cho phép người dùng thay thế tài khoản EOA của họ bằng các chức năng có thể lập trình được.EIP-7702Ritual Chain là một trong những blockchain đầu tiên hỗ trợ EIP-7702: Set EOA account code, một phương pháp triển khai account abstraction hàng đầu, ban đầu được đề xuất bởi Vitalik Buterin. EIP-7702 bổ sung một loại giao dịch mới, SetCodeTx, cho phép tài khoản EOA ủy quyền một smart contract làm implementation của nó. Nhờ vậy, ngoài các chức năng EOA thông thường, người dùng cũng có thể sử dụng các chức năng lập trình của smart contract giống như thể một hợp đồng được triển khai tại chính địa chỉ EOA của họ. Điều này được thực hiện bằng cách ký và gửi một giao dịch đến address(self).Tài liệu tham khảo (Reading links)ERC-4337: Account Abstraction EIP-7702: Set EOA account codeEXP-0001: Account Delegation with EIP-7702GitHub: Example P256Delegation 7702 contract Scheduled TransactionsCác giao dịch theo lịch cho phép việc gọi lặp lại hoặc có điều kiện các hàm của smart contract, được thực thi ở đầu một block, mà không cần các keeper bên ngoài. Để đọc chi tiết về cách triển khai giao dịch theo lịch, hãy tham khảo trang kiến trúc. /BackgroundCác nhà phát triển muốn khả năng thực thi định kỳ các hàm trong smart contract của họ (ví dụ: cập nhật tham số hoặc duy trì hoạt động thường xuyên của một giao thức). Hiện nay, chức năng này phải được thực hiện bằng cách thuê ngoài cho các bot keeper off-chain được vận hành bởi:Chính các nhà phát triểnCác dịch vụ bên thứ ba như Gelato và Chainlink AutomationCác MEV searchers được khuyến khích bởi các khoản trợ cấp từ giao thứcDù do ai vận hành, điều này vẫn buộc các giao thức phải dựa vào các thực thể off-chain để vận hành an toàn các ứng dụng on-chain của họ, và thường không có bất kỳ SLA hay cam kết thực thi nào.Native schedulingRitual là một trong những blockchain EVM đầu tiên đưa tính năng lập lịch giao dịch vào ngay trong giao thức. Các nhà phát triển có thể lập lịch và thanh toán on-chain cho các lần gọi hàm smart contract định kỳ. Thay vì phải dựa vào các keeper tập trung của bên thứ ba, giao dịch theo lịch cho phép các nhà phát triển tận dụng những đặc tính mạnh mẽ và kiến trúc của Ritual Chain, khi block proposers đưa các giao dịch theo lịch vào đầu block một cách tự nhiên. Ngoài ra, các nhà phát triển còn có thể công khai những view function tùy chỉnh để xác định theo thời gian thực liệu contract có nên được kích hoạt hay không, từ đó cho phép xây dựng các trường hợp sử dụng tự động hoàn toàn.Key benefitsTop-of-Block PriorityĐảm bảo thực thi ưu tiên ở đầu mỗi block cho các hoạt động quan trọng như cập nhật oracle và cơ chế tái cân bằng.Keeper-Free AutomationTự động thực thi các hàm smart contract lặp lại mà không cần mạng keeper bên ngoài hay các dịch vụ tập trung.Predictable ExecutionThiết lập chính xác tần suất và khoảng thời gian thực thi cho các hàm smart contract với sự đảm bảo về mặt thời gian.Optimized costTrả mức phí tối ưu cho mỗi lần thực thi giao dịch theo lịch, kể cả trong thời kỳ nhu cầu cao, thông qua Resonance.Conditional LogicHỗ trợ các hàm thực thi có điều kiện tùy chọn, giúp giao dịch tự động trở nên linh hoạt và phụ thuộc vào trạng thái.Dedicated Fee MarketsThị trường phí riêng cho giao dịch theo lịch đảm bảo mức giá thực thi ổn định, độc lập với mức phí giao dịch thông thường.Smart Contract NativeTích hợp trực tiếp với smart contract thông qua giao diện đơn giản, giúp automation có thể được sử dụng bởi bất kỳ contract nào.Build Autonomous ApplicationsXây dựng các ứng dụng hoàn toàn tự trị có khả năng quan sát, cập nhật và tự đưa ra hành động, giống như các smart agents.EIP ExtensionsOverviewTrong lịch sử, Ethereum và các blockchain dựa trên EVM đã chậm trễ trong việc hỗ trợ tích hợp các Ethereum Improvement Proposals (EIPs) mới, thường là do chi phí phát triển hoặc do mô hình định giá gas đơn giản cho các precompile. EIP Extensions là nỗ lực của chúng tôi nhằm ưu tiên hỗ trợ liên tục và tích hợp các EIP được yêu cầu nhiều, nhằm cải thiện trải nghiệm người dùng và nhà phát triển.Thông qua công trình tiên phong với Resonance và Symphony, kiến trúc nền tảng của Ritual Chain được thiết kế đặc biệt để định giá, điều phối và cung cấp các EIP mới, cho phép chúng tôi bổ sung các extension trước bất kỳ chain nào khác.Current extensionsEIP-665Bổ sung hỗ trợ xác minh chữ ký Ed25519.EIP-5027Gỡ bỏ giới hạn kích thước mã smart contract thông qua mô hình đo gas động mới.EIP-5920Thêm opcode mới PAY để gửi ether mà không truyền execution context.EIP-7212Bổ sung hỗ trợ xác minh chữ ký secp256r1.EIP-665Bổ sung hỗ trợ cho việc xác minh chữ ký Ed25519 thông qua một precompile contract mới. Ed25519 là một trong những sơ đồ chữ ký khóa công khai phổ biến nhất, được sử dụng bởi các giao thức như TLS 1.3, Signal, Tor, và thường được các công ty như GitHub khuyến nghị làm cơ chế xác thực SSH mặc định. EIP-665 (ban đầu được đề xuất vào năm 2018) thêm một precompile mới ED25519VFY tại address(0x9), cho phép xác minh chữ ký với chi phí 2000 gas.EIP SpecificationNếu block.number >= CONSTANTINOPLE_FORK_BLKNUM, thêm một precompile contract Ed25519 để xác minh chữ ký (ED25519VFY). Đề xuất này bổ sung một hàm precompile mới ED25519VFY với đầu vào và đầu ra như sau: Đầu vào của ED25519VFY (128 octets):message: thông điệp 32-octet đã được kýpublic key: khóa công khai Ed25519 32-octet của người kýsignature: chữ ký Ed25519 64-octetĐầu ra của ED25519VFY (4 octets):0x00000000 nếu chữ ký hợp lệBất kỳ giá trị khác 0 nào cho biết việc xác minh chữ ký thất bạiEIP-5027Gỡ bỏ giới hạn kích thước mã smart contract với cơ chế đo gas động mới. Năm 2016, thông qua EIP-170, Ethereum đã áp đặt giới hạn 24.576 byte cho kích thước mã smart contract (được tham chiếu dưới tên MAX_CODE_SIZE và tính bằng 0x6000 = 2**14 + 2**13). Lý do của quyết định này chủ yếu nhằm ngăn chặn các cuộc tấn công từ chối dịch vụ (DoS) xuất hiện khi các smart contract ngày càng lớn và phức tạp. Kể từ đó, các ứng dụng smart contract chỉ trở nên phức tạp hơn, và các nhà phát triển phải sử dụng những mẫu thiết kế phức tạp để lách giới hạn kích thước code, dẫn đến việc lãng phí vô số giờ làm việc vào những tối ưu hóa không cần thiết. EIP-5027 loại bỏ hoàn toàn giới hạn kích thước mã hợp đồng, thay vào đó tính thêm 2600 gas cho mỗi khối 24.576 byte bổ sung của mã hợp đồng được nạp.EIP SpecificationConstantValueFORK_BLKNUM0CODE_SIZE_UNIT24576COLD_ACCOUNT_CODE_ACCESS_COST_PER_UNIT2600CREATE_DATA_GAS200Nếu block.number >= FORK_BLKNUM, quá trình khởi tạo khi tạo hợp đồng (contract creation initialization) có thể trả về dữ liệu với bất kỳ độ dài nào, nhưng các opcode liên quan đến hợp đồng sẽ tiêu tốn thêm gas theo các quy định dưới đây: Với các opcode CODESIZE / CODECOPY / EXTCODESIZE / EXTCODEHASH, mức gas không thay đổi.Với CREATE / CREATE2, nếu kích thước hợp đồng mới > CODE_SIZE_UNIT, các opcode này sẽ tiêu tốn thêm write gas theo công thức:(CODE_SIZE - CODE_SIZE_UNIT) × CREATE_DATA_GASVới EXTCODECOPY / CALL / CALLCODE / DELEGATECALL / STATICCALL, nếu kích thước mã hợp đồng > CODE_SIZE_UNIT, các opcode sẽ tiêu tốn thêm gas:(CODE_SIZE - 1) // CODE_SIZE_UNIT × COLD_ACCOUNT_CODE_ACCESS_COST_PER_UNIT Nếu hợp đồng không nằm trong accessed_code_in_addresses hoặc 0 gas bổ sung nếu hợp đồng đã nằm trong accessed_code_in_addresses, ký hiệu // là phép chia lấy phần nguyên. accessed_code_in_addresses: Set[Address] là một tập hợp ở phạm vi transaction context, tương tự access_addresses và accessed_storage_keys.Quy tắc cập nhật accessed_code_in_addressesKhi giao dịch bắt đầu, accessed_code_in_addresses bao gồm:tx.sendertx.totất cả precompile contractsKhi bất kỳ opcode nào sau đây được gọi:CREATECREATE2EXTCODECOPYCALLCALLCODEDELEGATECALLSTATICCALL→ Địa chỉ của contract được truy cập sẽ được thêm vào accessed_code_in_addresses ngay lập tức.EIP-5920Bổ sung một opcode mới PAY để gửi ether mà không truyền execution context. Hiện nay, khi sử dụng Solidity để viết smart contract cho EVM, có ba cách để chuyển một lượng ether giữa các tài khoản:<address>.send<address>.transfer<address>.call{value} thông qua opcode CALLKể từ năm 2019, người ta khuyến nghị tránh sử dụng <address>.send và <address>.transfer, vì chúng chỉ chuyển tiếp cố định 2300 gas (và chi phí gas cho các thao tác phổ biến thay đổi định kỳ, gây ra sự không tương thích ngược).Ở cả ba phương thức trên, execution context và luồng điều khiển (control flow) đều được chuyển sang <address>, mở ra khả năng reentrancy và các vector tấn công từ chối dịch vụ (DoS) nếu nhà phát triển không cẩn trọng. Trong lịch sử, điều này đã dẫn đến thiệt hại hàng tỷ đô la từ các vụ khai thác smart contract.EIP-5920 giới thiệu opcode mới PAY, nhận hai tham số từ stack: addr và val, và chuyển val wei đến addr mà không gọi bất kỳ hàm nào của địa chỉ đó. Bằng cách này, nhà phát triển có thể dễ dàng chuyển ether mà không truyền execution context.EIP SpecificationConstantsConstantDefinitionWARM_STORAGE_READ_COSTEIP-2929COLD_ACCOUNT_ACCESS_COSTEIP-2929GAS_NEW_ACCOUNTEELSGAS_CALL_VALUEEELSBehaviorMột opcode mới được giới thiệu: PAY (0xf9), hoạt động như sau:Lấy hai giá trị từ stack: addr trước, rồi valChuyển val wei từ địa chỉ hiện tại đến địa chỉ addrĐánh dấu addr là warm (thêm addr vào accessed_addresses)Gas CostChi phí gas của PAY là tổng của các yếu tố sau:addr có nằm trong accessed_addresses không?Nếu có → WARM_STORAGE_READ_COSTNếu không → COLD_ACCOUNT_ACCESS_COSTĐịa chỉ addr đã tồn tại hoặc val bằng 0 hay chưa?Nếu một trong hai điều kiện đúng → thêm 0Ngược lại → thêm GAS_NEW_ACCOUNTval có bằng 0 không?Nếu có → thêm 0Nếu không → thêm GAS_CALL_VALUEEIP lưu ý rằng PAY không thể được triển khai trên các mạng có khái niệm “empty accounts” (xem EIP-7523).EIP-7212Bổ sung hỗ trợ xác minh chữ ký secp256r1 thông qua một precompile contract mới. secp256r1 (hay P-256) là một đường cong elliptic phổ biến được sử dụng trong các cơ chế chữ ký, bao gồm Apple’s Secure Enclave, WebAuthn, Android Keystore và Passkeys. EIP-7212/RIP-7212 thêm một precompile mới P256VERIFY tạ address(0x100), cho phép xác minh chữ ký với chi phí 3450 gas. EIP-7212 cho phép hỗ trợ ký giao dịch bằng Passkeys và các keystore khác, khóa ký phần cứng, và cải thiện trải nghiệm người dùng.EIP SpecificationCác từ khóa “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, “OPTIONAL” trong tài liệu này được hiểu theo định nghĩa trong RFC 2119 và RFC 8174. Kể từ FORK_TIMESTAMP trên chain EVM tích hợp, thêm precompile contract P256VERIFY để xác minh chữ ký trên đường cong elliptic “secp256r1” tại địa chỉ PRECOMPILED_ADDRESS = 0x100 (tương ứng với địa chỉ 0x0000000000000000000000000000000000000100).Elliptic Curve Information“secp256r1” là một đường cong elliptic cụ thể, còn được gọi là P-256 hoặc prime256v1. Đường cong được định nghĩa bằng phương trình và các tham số miền như sau:# curve: short weierstrass form y^2 ≡ x^3 + a x + b # p: curve prime field modulus 0xffffffff00000001000000000000000000000000ffffffffffffffffffffffff # a: elliptic curve short weierstrass first coefficient 0xffffffff00000001000000000000000000000000fffffffffffffffffffffffc # b: elliptic curve short weierstrass second coefficient 0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b # G: base point of the subgroup (0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296, 0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5) # n: subgroup order (number of points) 0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551 # h: cofactor of the subgroup 0x1 Elliptic Curve Signature Verification StepsThuật toán xác minh chữ ký nhận vào:hash của thông điệp đã kýcác thành phần chữ ký được tạo bởi thuật toán secp256r1khóa công khai được suy ra từ khóa riêng của người kýQuy trình xác minh được thực hiện theo các bước sau:# h (message hash) # pubKey = (public key of the signer private key) # 1. Tính nghịch đảo modular của s: s1 = s^(−1) (mod n) # 2. Khôi phục điểm ngẫu nhiên được dùng trong quá trình ký: R' = (h * s1) * G + (r * s1) * pubKey # 3. Lấy tọa độ x của R': r' = R'.x # 4. Chữ ký hợp lệ nếu: r' == r Required Checks in VerificationPrecompile contract phải kiểm tra:r và s nằm trong khoảng (0, n) (không bao gồm 0 và n), nơi n là bậc của subgroup.Điểm (x, y) nằm trên đường cong, và cả x và y đều nằm trong khoảng [0, p) (0 bao gồm, p không bao gồm), nơi p là mô-đun trường nguyên thủy. Lưu ý: Nhiều implementation sử dụng điểm (0, 0) làm “điểm vô cực”, nhưng điểm này không nằm trên đường cong nên phải bị từ chối.Precompiled Contract SpecificationPrecompile P256VERIFY có đầu vào và đầu ra như sau (big-endian):Input (160 bytes)32 bytes: hash của dữ liệu đã ký32 bytes: thành phần r của chữ ký32 bytes: thành phần s của chữ ký32 bytes: tọa độ x của khóa công khai32 bytes: tọa độ y của khóa công khaiOutputTrả về 1 (32 bytes) nếu việc xác minh chữ ký thành côngNếu thất bại, không trả về dữ liệuPrecompiled Contract Gas UsageChi phí sử dụng precompile P256VERIFY cho việc xác minh chữ ký là: 3450 gas Nguồn: https://www.ritualfoundation.org/docs/whats-new/evm++

## Publication Information

- [Saint Lee](https://paragraph.com/@saintlee/): Publication homepage
- [All Posts](https://paragraph.com/@saintlee/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@saintlee): Subscribe to updates
- [Twitter](https://twitter.com/SaintLee04): Follow on Twitter