EVM++ 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.

Ngày nay, các blockchain dựa trên Ethereum hỗ trợ hai loại tài khoản:

1. 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ư

2. 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ạng

Trong 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:

1. Batch calls: gửi nhiều giao dịch cùng một lúc

2. Gas fee sponsorship: giao dịch không phí cho người dùng

3. Arbitrary signing keys: sử dụng nhiều cơ chế chữ ký khác nhau (P256, BLS, v.v.)

4. Advanced ACLs: gán quyền sử dụng chi tiết và kiểm soát thời hạn truy cập

Account 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.

Ritual 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).

• ERC-4337: Account Abstraction

• EIP-7702: Set EOA account code

• EXP-0001: Account Delegation with EIP-7702

• GitHub: Example P256Delegation 7702 contract

Cá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.

/

Cá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:

1. Chính các nhà phát triển

2. Các dịch vụ bên thứ ba như Gelato và Chainlink Automation

3. Các MEV searchers được khuyến khích bởi các khoản trợ cấp từ giao thức

Dù 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.

Ritual 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.

• Top-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 Automation

Tự độ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 Execution

Thiế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 cost

Trả 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 Logic

Hỗ 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 Markets

Thị 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 Native

Tí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 Applications

Xâ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.

Trong 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.

Bổ sung hỗ trợ xác minh chữ ký Ed25519.

Gỡ bỏ giới hạn kích thước mã smart contract thông qua mô hình đo gas động mới.

Thêm opcode mới PAY để gửi ether mà không truyền execution context.

Bổ sung hỗ trợ xác minh chữ ký secp256r1.

Bổ 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.

Nế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

• 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ại

Gỡ 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.

Nế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_GAS

• Vớ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_addresses

• Khi giao dịch bắt đầu, accessed_code_in_addresses bao gồm:

  • tx.sender

  • tx.to

  • tất cả precompile contracts

• Khi bất kỳ opcode nào sau đây được gọi:

  • CREATE

  • CREATE2

  • EXTCODECOPY

  • CALL

  • CALLCODE

  • DELEGATECALL

  • STATICCALL

→ Địa chỉ của contract được truy cập sẽ được thêm vào accessed_code_in_addresses ngay lập tức.

Bổ 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:

1. <address>.send

2. <address>.transfer

3. <address>.call{value} thông qua opcode CALL

Kể 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.

• Constants

• Behavior

Mộ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 val

• Chuyể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 Cost

Chi phí gas của PAY là tổng của các yếu tố sau:

1. addr có nằm trong accessed_addresses không?

   • Nếu có → WARM_STORAGE_READ_COST

   • Nếu không → COLD_ACCOUNT_ACCESS_COST

2. Đị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 0

   • Ngược lại → thêm GAS_NEW_ACCOUNT

3. val có bằng 0 không?

   • Nếu có → thêm 0

   • Nếu không → thêm GAS_CALL_VALUE

EIP 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).

Bổ 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.

Cá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).

“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

Thuậ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 secp256r1

• khó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

Precompile contract phải kiểm tra:

1. 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.

2. Đ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.

Precompile P256VERIFY có đầu vào và đầu ra như sau (big-endian):

• 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 khai

• 32 bytes: tọa độ y của khóa công khai

• Trả về 1 (32 bytes) nếu việc xác minh chữ ký thành công

• Nếu thất bại, không trả về dữ liệu

Chi phí sử dụng precompile P256VERIFY cho việc xác minh chữ ký là: 3450 gas

EVM++ 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.

Ngày nay, các blockchain dựa trên Ethereum hỗ trợ hai loại tài khoản:

1. 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ư

2. 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ạng

Trong 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:

1. Batch calls: gửi nhiều giao dịch cùng một lúc

2. Gas fee sponsorship: giao dịch không phí cho người dùng

3. Arbitrary signing keys: sử dụng nhiều cơ chế chữ ký khác nhau (P256, BLS, v.v.)

4. Advanced ACLs: gán quyền sử dụng chi tiết và kiểm soát thời hạn truy cập

Account 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.

Ritual 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).

• ERC-4337: Account Abstraction

• EIP-7702: Set EOA account code

• EXP-0001: Account Delegation with EIP-7702

• GitHub: Example P256Delegation 7702 contract

Cá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.

/

Cá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:

1. Chính các nhà phát triển

2. Các dịch vụ bên thứ ba như Gelato và Chainlink Automation

3. Các MEV searchers được khuyến khích bởi các khoản trợ cấp từ giao thức

Dù 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.

Ritual 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.

• Top-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 Automation

Tự độ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 Execution

Thiế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 cost

Trả 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 Logic

Hỗ 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 Markets

Thị 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 Native

Tí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 Applications

Xâ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.

Trong 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.

Bổ sung hỗ trợ xác minh chữ ký Ed25519.

Gỡ bỏ giới hạn kích thước mã smart contract thông qua mô hình đo gas động mới.

Thêm opcode mới PAY để gửi ether mà không truyền execution context.

Bổ sung hỗ trợ xác minh chữ ký secp256r1.

Bổ 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.

Nế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

• 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ại

Gỡ 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.

Nế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_GAS

• Vớ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_addresses

• Khi giao dịch bắt đầu, accessed_code_in_addresses bao gồm:

  • tx.sender

  • tx.to

  • tất cả precompile contracts

• Khi bất kỳ opcode nào sau đây được gọi:

  • CREATE

  • CREATE2

  • EXTCODECOPY

  • CALL

  • CALLCODE

  • DELEGATECALL

  • STATICCALL

→ Địa chỉ của contract được truy cập sẽ được thêm vào accessed_code_in_addresses ngay lập tức.

Bổ 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:

1. <address>.send

2. <address>.transfer

3. <address>.call{value} thông qua opcode CALL

Kể 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.

• Constants

• Behavior

Mộ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 val

• Chuyể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 Cost

Chi phí gas của PAY là tổng của các yếu tố sau:

1. addr có nằm trong accessed_addresses không?

   • Nếu có → WARM_STORAGE_READ_COST

   • Nếu không → COLD_ACCOUNT_ACCESS_COST

2. Đị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 0

   • Ngược lại → thêm GAS_NEW_ACCOUNT

3. val có bằng 0 không?

   • Nếu có → thêm 0

   • Nếu không → thêm GAS_CALL_VALUE

EIP 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).

Bổ 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.

Cá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).

“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

Thuậ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 secp256r1

• khó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

Precompile contract phải kiểm tra:

1. 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.

2. Đ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.

Precompile P256VERIFY có đầu vào và đầu ra như sau (big-endian):

• 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 khai

• 32 bytes: tọa độ y của khóa công khai

• Trả về 1 (32 bytes) nếu việc xác minh chữ ký thành công

• Nếu thất bại, không trả về dữ liệu

Chi phí sử dụng precompile P256VERIFY cho việc xác minh chữ ký là: 3450 gas