EIP-8361 là gì? Giải thích về Ethereum validity proofs

Cập nhật lần cuối 2026-08-06 08:34:57
Thời gian đọc: 16m
EIP-8361 là một bản dự thảo Đề xuất cải tiến Ethereum, cho phép đính kèm bằng chứng tính hợp lệ dựa trên STARK vào một số giao dịch trước khi chúng vào mempool công khai. Bằng chứng này giúp các node tham gia xác minh logic ủy quyền phức tạp mà không cần tự thực thi lại. Đề xuất này chủ yếu dành cho nhà phát triển ví, tài khoản thông minh, node và giao thức, nhưng hiện mới chỉ là thiết kế mạng ở giai đoạn đầu, chưa phải là tính năng chính thức của giao thức Ethereum.

EIP-8361 tập trung vào xác thực mang bằng chứng cho các giao dịch khung của EIP-8141, không thay thế thực thi Ethereum, không tạo loại giao dịch mới, không triển khai hợp đồng thông minh, không cung cấp quyền riêng tư giao dịch, không thay đổi phần thưởng trình xác thực, cũng không quy định thời gian triển khai mười tám tháng. Mục đích thực tế của đề xuất là giảm tính toán dư thừa trong xác thực giao dịch, đồng thời vẫn đảm bảo cơ chế bảo vệ chống lại các giao dịch không hợp lệ hoặc tiêu tốn tài nguyên.

Các phần dưới đây trình bày quy trình mang bằng chứng, cách node xác minh, sự khác biệt giữa EIP-8361 với bằng chứng hợp lệ rollup và mô phỏng giao dịch, cũng như các hạn chế kỹ thuật chưa giải quyết.

Những điểm chính

  • EIP-8361 chuẩn hóa dữ liệu bằng chứng hợp lệ giao dịch để truyền ngang hàng. Giao dịch khung có thể mang STARK chứng minh tiền tố xác thực đạt trạng thái phê duyệt.

  • Node xác minh bằng chứng thay vì lặp lại logic xác thực tốn kém. Việc tách biệt giữa chứng minh và xác minh giúp giảm tính toán lặp lại trên các node Ethereum.

  • Bằng chứng nằm ngoài đồng thuận. Được vận chuyển cùng giao dịch, dùng cho mempool và sẽ loại bỏ khi không cần thiết.

  • Thiết kế hỗ trợ xác thực tài khoản thông minh phức tạp. Ví dụ gồm đa chữ ký, hệ thống chữ ký thay thế, paymaster, và ủy quyền dựa trên bằng chứng.

  • EIP-8361 vẫn là bản nháp. Chưa kích hoạt nâng cấp, không nên nhầm lẫn với EIP-7701, EIP-7702, bằng chứng hợp lệ rollup hoặc các đề xuất phần thưởng staking.

EIP-8361 là gì?

EIP-8361, với tiêu đề Transaction Validity Proofs, đề xuất cơ chế mạng cho phép giao dịch Ethereum đi kèm bằng chứng mật mã xác nhận logic xác thực được phê duyệt. Đây là đối tác mạng cho các thay đổi cấp giao thức của EIP-8141, định nghĩa giao dịch khung và các giai đoạn xác thực lập trình được.

Ethereum Improvement Proposal là tài liệu thiết kế kỹ thuật, mô tả tiêu chuẩn, tính năng giao thức, giao diện hoặc quy trình tiềm năng cho Ethereum. Việc công bố dưới dạng EIP không đồng nghĩa với việc đề xuất đã được chấp nhận hoặc triển khai. EIP-8361 vẫn là bản nháp đang phát triển, thông số kỹ thuật, phụ thuộc và trạng thái có thể thay đổi.

Đề xuất này trả lời câu hỏi:

Làm thế nào để node nhận vào giao dịch mà xác thực tốn kém mà không cần mọi node đều phải lặp lại tính toán đó?

Theo EIP-8361, người chứng minh chạy logic xác thực giao dịch ngoài chuỗi và tạo STARK. Node nhận xác minh bằng chứng đó, kiểm tra giả định khai báo với trạng thái Ethereum hiện tại và quyết định có đưa giao dịch vào mempool công khai hay không.

Giao dịch vẫn phải hợp lệ theo quy tắc thực thi Ethereum khi được đưa vào block. Bằng chứng hỗ trợ chính sách nhận vào, không thay thế thực thi giao thức hoặc xác thực đồng thuận.

Vì sao xác thực giao dịch Ethereum phức tạp

Tài khoản sở hữu bên ngoài (EOA) kiểm soát bằng khóa riêng và khóa công khai. Tài khoản xác thực giao dịch bằng chữ ký ECDSA, còn giao dịch xác định nonce người gửi, địa chỉ nhận, giá trị, chain ID, giới hạn gas và giá gas hoặc tham số phí EIP-1559.

Các kiểm tra này khá dự đoán được. Node xác minh chữ ký, xác nhận tài khoản đủ tiền, kiểm tra nonce và loại bỏ giao dịch sai hoặc lặp lại.

Tài khoản thông minh tạo ra bề mặt xác thực rộng hơn. Thay vì chỉ dựa vào một khóa riêng, tài khoản thông minh có thể dùng:

  • nhiều khóa công khai;
  • giới hạn chi tiêu;
  • khóa phiên;
  • hợp đồng được ủy quyền;
  • quy tắc paymaster;
  • chữ ký hậu lượng tử;
  • điều kiện khôi phục;
  • bằng chứng zero-knowledge;
  • mã ủy quyền chuyên biệt ứng dụng.

Logic này có thể nằm trong hợp đồng đã triển khai hoặc hợp đồng mới khi triển khai tài khoản. Việc tạo và triển khai hợp đồng cũng có thể yêu cầu xác thực nhà máy, mã khởi tạo hoặc địa chỉ hợp đồng mới.

Node Ethereum không thể thực hiện an toàn mã xác thực không giới hạn cho mọi giao dịch chưa xác nhận. Kẻ tấn công có thể gửi giao dịch gian lận gọi hợp đồng tốn kém, hàm băm, đọc lưu trữ hoặc hệ thống bằng chứng nhưng không cho phép thực thi. Dù giao dịch không hợp lệ, việc xác minh vẫn tiêu tốn tài nguyên node.

Bằng chứng hợp lệ giao dịch EIP-8361 chuyển công việc tốn kém sang người chứng minh, đồng thời giữ việc xác minh bằng chứng ở mức giới hạn.

Cách giao dịch mang bằng chứng EIP-8361 hoạt động

EIP-8361 đề xuất hai cách nhận vào giao dịch khung EIP-8141:

  1. Nhận vào mô phỏng: node thực thi trực tiếp tiền tố xác thực.
  2. Nhận vào mang bằng chứng: node xác minh STARK chứng minh tiền tố xác thực được phê duyệt.

Cách thứ hai dành cho trường hợp xác thực vượt quá ngân sách xác minh của node.

  1. Giao dịch xác định logic xác thực

Giao dịch khung EIP-8141 chia công việc thành các frame với mục đích khác nhau. Một số frame xác lập ủy quyền, xác định người trả, hoặc chuẩn bị thực thi. Tiền tố xác thực chạy trước các frame thực thi thông thường.

Tiền tố xác thực có thể gọi hợp đồng liên kết với người gửi hoặc hợp đồng ủy quyền khác. Hợp đồng kiểm tra chữ ký, quyền hạn, số dư, điều kiện hết hạn hoặc quy tắc khác trước khi gọi thao tác APPROVE.

EIP-8141 khác với giao dịch thông thường mà chữ ký ECDSA trực tiếp xác định người gửi. Mô hình xác thực lập trình được là một phần của trừu tượng hóa tài khoản bản địa Ethereum. EIP-8141 cũng tránh dựa vào danh sách ủy quyền ECDSA của EIP-7702 vì giao dịch khung hướng đến linh hoạt mật mã cao hơn.

  1. Người chứng minh thực thi tiền tố xác thực

Người chứng minh chạy tiền tố xác thực giao dịch với đầu vào và giả định trạng thái khai báo. Quy trình có thể gồm xác minh:

  • chữ ký khớp với khóa công khai;
  • tài khoản đủ tiền;
  • số dư paymaster trên mức yêu cầu;
  • slot lưu trữ hợp đồng chứa quyền hạn kỳ vọng;
  • chain ID khớp mạng Ethereum;
  • nonce ngăn tấn công lặp lại;
  • mã xác thực kết thúc với phê duyệt.

Người chứng minh tạo STARK cam kết với giao dịch, phụ thuộc, giả định, người trả và điều kiện hợp lệ.

  1. Bằng chứng khai báo giả định trạng thái

Bằng chứng mật mã không còn hữu ích nếu dựa vào trạng thái đã thay đổi. EIP-8361 đề xuất vector giả định mô tả các sự kiện trạng thái khi chứng minh.

Điều kiện bằng nhau yêu cầu mã băm hợp đồng, nonce hoặc giá trị lưu trữ trùng khớp với giá trị khai báo. Điều kiện lớn hơn hoặc bằng yêu cầu số dư tài khoản trên mức tối thiểu.

Các giả định này liên kết bằng chứng với trạng thái hợp lệ trước đó mà không cần nhúng toàn bộ trạng thái Ethereum. Khi block mới thay đổi dữ liệu, node kiểm tra lại vector giả định.

Cơ chế này là trung tâm của xác thực mempool EIP-8361: node không tin bằng chứng cũ chỉ vì mật mã vẫn hợp lệ.

  1. Node xác minh STARK

Node nhận thực hiện kiểm tra cấu trúc chi phí thấp trước khi xác minh bằng chứng. Sau đó, node xác minh STARK với khóa xác minh và kiểm tra phụ thuộc, giả định với trạng thái Ethereum hiện tại.

Hệ thống bằng chứng hiện đại có thể tạo bằng chứng nhanh hơn thực thi lại tính toán gốc. Một bằng chứng có thể thay thế mô phỏng lặp lại bởi nhiều node, giảm tính toán dư thừa trên mạng ngang hàng.

Việc tạo bằng chứng không rẻ. Tạo STARK có thể yêu cầu xử lý, bộ nhớ, phần mềm chuyên dụng. Đề xuất chuyển tính toán chứ không loại bỏ nó.

  1. Giao dịch vào mempool

Khi bằng chứng và kiểm tra trạng thái thành công, node nhận và truyền giao dịch mà không cần chạy lại tiền tố xác thực tốn kém.

Bằng chứng chỉ là metadata ngang hàng. Không thêm vào calldata giao dịch, không lưu trữ bởi hợp đồng triển khai, không ghi vào trạng thái tài khoản, không đưa vào Merkle root của block.

Khi giao dịch được đưa vào block, Ethereum thực thi theo quy tắc giao thức. Nếu bằng chứng lỗi thời hoặc giao dịch bị loại bỏ, metadata mạng có thể bị loại bỏ.

Cách giao dịch mang bằng chứng EIP-8361 hoạt động

Bằng chứng hợp lệ EIP-8361 chứng minh điều gì?

Bằng chứng hợp lệ EIP-8361 là bằng chứng mật mã rằng một tính toán xác thực cụ thể đã được thực thi đúng theo giả định khai báo và đạt trạng thái phê duyệt.

Bằng chứng có thể chứng minh logic xác thực đã kiểm tra chữ ký hợp lệ, số dư đủ, nonce đúng, người trả cho phép hoặc ủy quyền hợp đồng. Tuy nhiên, nó không chứng minh tính đúng đắn của mọi chuyển đổi trạng thái EVM tiếp theo do giao dịch tạo ra.

Sự phân biệt này quan trọng:

  • EIP-8361 chứng minh xác thực liên quan đến nhận vào.
  • Bằng chứng hợp lệ rollup chứng minh chuyển đổi trạng thái ngoài chuỗi.
  • Bằng chứng Merkle chứng minh sự xuất hiện trong cấu trúc dữ liệu xác thực.
  • Bằng chứng zero-knowledge có thể che giấu thông tin, nhưng hợp lệ không đảm bảo quyền riêng tư.

Bằng chứng Merkle chứng minh giao dịch thuộc batch, block hoặc cây trạng thái cụ thể bằng cách liên kết lá với Merkle root đã biết. Trong ZK rollup, bằng chứng Merkle xác lập tài khoản người gửi và người nhận tồn tại ở trạng thái hợp lệ trước đó và số dư cập nhật tạo ra root trạng thái mới.

EIP-8361 dùng STARK như bằng chứng đúng đắn hiệu quả, nhưng mục tiêu không phải là thực thi bảo mật. Giao dịch và phụ thuộc vẫn hiển thị cho các node tham gia.

EIP-8361 vs bằng chứng hợp lệ ZK-Rollup

Layer 2 dùng bằng chứng hợp lệ rộng hơn. ZK rollup thực thi batch giao dịch ngoài chuỗi và gửi bằng chứng súc tích đến hợp đồng xác minh Ethereum. Bằng chứng chứng minh batch đã chuyển trạng thái hợp lệ thành trạng thái mới đúng theo quy tắc rollup.

Thay vì thực thi lại mọi giao dịch trên Ethereum, hợp đồng xác minh kiểm tra bằng chứng và đầu vào công khai. Điều này giảm tiêu thụ tài nguyên trên chuỗi và phân bổ phí gas cho nhiều giao dịch. Hệ thống bằng chứng đệ quy tổng hợp nhiều bằng chứng thành một.

Bằng chứng hợp lệ ngăn rollup ZK hoàn tất chuyển đổi trạng thái không hợp lệ, giả sử hệ thống bằng chứng, circuit, hợp đồng xác minh và mô hình dữ liệu đều an toàn. Nó cho phép hoàn tất L2-to-L1 nhanh hơn hệ thống cần cửa sổ tranh chấp.

EIP-8361 không chứng minh batch tính toán, không cập nhật Merkle root L2, không kích hoạt rút tiền. Nó chứng minh một giao dịch khung đáp ứng yêu cầu nhận vào của node.

Khía cạnh EIP-8361 Bằng chứng hợp lệ ZK-Rollup
Mục đích chính Nhận vào mempool công khai Xác minh chuyển đổi trạng thái L2
Tính toán được chứng minh Tiền tố xác thực Batch giao dịch hoặc chuyển đổi trạng thái
Vị trí xác minh Node Ethereum Hợp đồng xác minh L1
Lưu trữ trên chuỗi Không Bằng chứng hoặc cam kết từ bằng chứng
Lợi ích chính Tránh mô phỏng xác thực lặp lại Tránh thực thi lại giao dịch L2 trên L1
Đảm bảo quyền riêng tư Không Không nhất thiết
Vai trò đồng thuận Không trực tiếp Hỗ trợ hoàn tất L2

Bằng chứng hợp lệ EIP-8361 vs bằng chứng gian lận

Optimistic rollup giả định cập nhật trạng thái gửi lên hợp lệ trừ khi bị khiếu nại. Bằng chứng gian lận yêu cầu người quan sát phát hiện chuyển đổi tranh chấp và cung cấp bằng chứng trong thời gian khiếu nại. Yêu cầu không hợp lệ có thể được chấp nhận tạm thời cho đến khi khiếu nại giải quyết.

Hệ thống bằng chứng hợp lệ đi theo hướng ngược lại: cam kết trạng thái mới chỉ được chấp nhận sau khi hợp đồng xác minh xác nhận bằng chứng mật mã về thực thi đúng. Điều này cho phép rút tiền nhanh hơn vì người dùng không cần chờ qua thời gian khiếu nại bằng chứng gian lận.

Không thể nói bằng chứng hợp lệ luôn “an toàn hơn” bằng chứng gian lận. Các khác biệt gồm độ phức tạp của người chứng minh, độ an toàn của người xác minh, khả dụng dữ liệu, thiết lập tin cậy, giả định khiếu nại và độ trưởng thành triển khai.

EIP-8361 không phải mô hình bảo mật rollup. Bằng chứng được kiểm tra trước khi nhận vào mempool, còn bằng chứng gian lận và hợp lệ rollup bảo vệ hệ thống mở rộng ngoài chuỗi.

EIP-8361 vs ủy quyền tài khoản EIP-7702

EIP-7702 cho phép EOA đặt chỉ báo ủy quyền trong trường mã để gọi đến tài khoản thực thi mã từ hợp đồng thông minh chỉ định. Nó giới thiệu giao dịch loại 4 chứa authorization_list.

Mỗi tuple ủy quyền gồm:

  • chain_id;
  • địa chỉ hợp đồng ủy quyền;
  • nonce tài khoản;
  • trường chữ ký.

Ủy quyền được ký bởi khóa riêng của EOA. Người ký có thể khác tx.origin và một giao dịch có thể mang ủy quyền từ nhiều EOA. Mỗi ủy quyền cập nhật chỉ báo ủy quyền của tài khoản trước khi thực thi giao dịch.

Người dùng ủy quyền thực thi cho hợp đồng thông minh bằng ủy quyền đã ký mà không cần chuyển tài khoản thành hợp đồng triển khai. Mã ủy quyền hỗ trợ batch, tài trợ gas, quyền hạn hoặc hành vi tài khoản thông minh khác.

EIP-7702 tạo ra các vấn đề bảo mật. Chain ID bằng không làm ủy quyền hợp lệ trên nhiều chuỗi, nonce và trường ký giúp hạn chế tấn công lặp lại. Mã ủy quyền ảnh hưởng giả định liên quan đến tx.origin, giao dịch chờ, lưu trữ và số dư tài khoản.

EIP-8361 không thay thế hoặc mở rộng authorization_list. Đề xuất này giải quyết cách node nhận vào giao dịch chứa logic xác thực phức tạp. Khác biệt giữa bằng chứng hợp lệ EIP-8361 và mô phỏng giao dịch liên quan đến tính toán mempool, không phải ủy quyền mã EOA.

EIP-8361 vs trừu tượng hóa tài khoản bản địa EIP-7701

EIP-7701 được tạo ngày 1 tháng 5 năm 2024 như đề xuất trừu tượng hóa tài khoản bản địa. Nó chia xử lý giao dịch thành xác thực, thực thi và hậu thao tác, đồng thời đề xuất loại giao dịch mới EIP-2718.

Thiết kế dùng địa chỉ entry-point bản địa 0x7701, opcode dựa trên vai trò, xác thực riêng người gửi và paymaster, cùng thanh toán gas do hợp đồng kiểm soát. Đề xuất không yêu cầu luồng bundler ERC-4337 cho loại giao dịch bản địa.

EIP-7701 bị rút lại vì bị thay thế bởi EIP-8141, không chỉ bị đánh dấu “Stagnant”. Thông số kỹ thuật công bố liệt kê lý do rút trực tiếp. Khẳng định EIP-7701 yêu cầu hợp đồng EOF cũng không nằm trong thông số cuối cùng.

EIP-8361 xây dựng dựa trên mô hình giao dịch khung mới của EIP-8141. Theo đó, nó hỗ trợ lộ trình trừu tượng hóa tài khoản cấp giao thức bằng cách làm cho xác thực lập trình tốn kém dễ truyền tải an toàn hơn.

EIP-2718 cung cấp phong bì giao dịch kiểu cho các đề xuất như EIP-7701, EIP-7702 và EIP-8141. Định nghĩa giao dịch là TransactionType || TransactionPayload, với loại giao dịch xác định cách payload được diễn giải. Đưa loại vào dữ liệu ký giảm rủi ro lặp lại chữ ký cross-type.

Tác động thực tế đến Ví, Node và Nhà phát triển

Nhà phát triển ví có thể dùng nhận vào mang bằng chứng khi ủy quyền tài khoản thông minh quá tốn kém cho mô phỏng mempool. Ví có thể yêu cầu bằng chứng từ người chứng minh cục bộ, dịch vụ ví hoặc mạng chứng minh phân tán trước khi gửi giao dịch.

Nhà phát triển node cần triển khai:

  • truyền bằng chứng qua kết nối ngang hàng;
  • khóa xác minh phiên bản;
  • giới hạn kích thước bằng chứng;
  • kiểm tra giả định và phụ thuộc;
  • giới hạn tốc độ peer;
  • loại bỏ bằng chứng lỗi thời;
  • mô phỏng dự phòng.

Nhà phát triển hợp đồng thông minh có thể giữ xác thực chuyên biệt ứng dụng mà không yêu cầu node thực thi toàn bộ chi phí. Điều này hỗ trợ chữ ký hậu lượng tử, chính sách đa khóa, paymaster phức tạp hoặc quyền hạn dựa trên bằng chứng.

Tác động đến ví, node và nhà phát triển của EIP-8361 phụ thuộc vào độ trễ chứng minh, mức độ chấp nhận client, khả năng tương tác và thông số cuối cùng của EIP-8141.

Ví dụ, nhà giao dịch đánh giá phản ứng thị trường trên sàn như Gate với nâng cấp Ethereum tương lai có thể so sánh thông báo mạng với biểu đồ ETH/USDT. Giá thị trường, khối lượng giao dịch hoặc phí gas không thể xác lập liệu một EIP nháp đã được chấp nhận kỹ thuật hoặc kích hoạt.

Vấn đề bảo mật và hạn chế

EIP-8361 giới thiệu một số vấn đề bảo mật.

Đầu tiên, độ đúng đắn của bằng chứng phụ thuộc vào độ chính xác của circuit STARK và khóa xác minh. Lỗi circuit có thể chứng minh phát biểu không phản ánh đúng quy tắc xác thực.

Thứ hai, xác minh bằng chứng vẫn tiêu tốn tính toán và băng thông. Kẻ tấn công có thể gửi bằng chứng sai hoặc quá lớn, khiến kiểm tra sơ bộ, giới hạn kích thước và ghi nhận peer trở nên cần thiết.

Thứ ba, giả định có thể lỗi thời. Bằng chứng hợp lệ tạo ra dựa trên số dư tài khoản, giá trị lưu trữ, mã băm hợp đồng hoặc nonce có thể không còn áp dụng sau khi block mới thay đổi trạng thái.

Thứ tư, chính sách node không nhất quán có thể phân mảnh truyền giao dịch. Client khác nhau có thể chọn giới hạn kích thước bằng chứng, giới hạn xác thực hoặc mặc định nhận vào khác nhau.

Thứ năm, việc tạo bằng chứng có thể gây tập trung nếu chỉ một số dịch vụ sở hữu phần cứng hoặc phần mềm tối ưu.

EIP-8361 không loại bỏ chi phí giao dịch thông thường. Nếu giao dịch đạt thực thi block, người gửi hoặc người trả chịu chi phí gas. Bằng chứng hợp lệ giảm tính toán dư thừa ngoài chuỗi của node, nhưng không loại bỏ phí gas Ethereum.

EIP-8361 không đề xuất điều gì

Một số khẳng định thuộc về đề xuất khác và không nên gán cho EIP-8361.

EIP-8361 không:

  • quy định thời gian chuyển đổi mười tám tháng;
  • loại bỏ sàn lợi suất staking;
  • giới hạn phần thưởng trình xác thực;
  • trừ phần thưởng khi staking đạt 50%;
  • tạo cân bằng staking theo thị trường;
  • giới thiệu danh sách ủy quyền của EIP-7702;
  • giới thiệu entry point bản địa của EIP-7701;
  • tạo loại giao dịch mới EIP-2718;
  • đảm bảo quyền riêng tư;
  • hoàn tất batch ZK-rollup;
  • thay thế bằng chứng gian lận;
  • miễn quyền hợp đồng hoặc quyền liên quan của người dùng.

Phần bản quyền của bản nháp có thể quy định bản quyền và quyền liên quan được miễn theo CC0, như thông lệ của EIP. Thông báo pháp lý này chỉ liên quan đến tài liệu đề xuất, không phải quỹ người dùng, quyền giao dịch hoặc quyền hạn hợp đồng thông minh.

Kết luận

EIP-8361 đề xuất nhận vào giao dịch mang bằng chứng cho mempool công khai Ethereum. Người chứng minh thực thi tiền tố xác thực phức tạp EIP-8141 một lần, tạo STARK và cho phép nhiều node xác minh kết quả mà không cần lặp lại tính toán tốn kém.

Ứng dụng mạnh nhất là ủy quyền lập trình vượt quá giới hạn xác thực mempool, gồm tài khoản thông minh nâng cao, hệ thống chữ ký thay thế, paymaster và hợp đồng nặng bằng chứng. Thiết kế giảm tính toán dư thừa của node, đồng thời giữ giả định trạng thái hiện tại luôn hiển thị và kiểm tra lại được.

EIP-8361 không nên nhầm lẫn với hoàn tất ZK-rollup, tranh chấp bằng chứng gian lận, ủy quyền tài khoản EIP-7702 hoặc thiết kế EIP-7701 đã rút lại. Đây vẫn là đề xuất mạng bản nháp, các vấn đề bảo mật, kinh tế chứng minh, khả năng tương tác và phụ thuộc cần phát triển thêm trước khi có thể triển khai trên Ethereum.

Câu hỏi thường gặp

EIP-8361 có tạo loại giao dịch mới không?

Không. Đề xuất áp dụng nhận vào mang bằng chứng cho giao dịch khung EIP-8141. EIP-2718 cung cấp khung giao dịch kiểu chung, nhưng EIP-8361 không giới thiệu phong bì giao dịch khác.

Bằng chứng EIP-8361 có phải bằng chứng zero-knowledge không?

Bản nháp đề xuất bằng chứng hợp lệ dựa trên STARK, nhưng hợp lệ không đồng nghĩa với quyền riêng tư. Bằng chứng xác lập xác thực đúng theo giả định khai báo, không che giấu toàn bộ dữ liệu giao dịch.

Một bằng chứng có thể bao phủ nhiều giao dịch không?

Hệ thống bằng chứng có thể tổng hợp tính toán hoặc dùng bằng chứng đệ quy, rollup cũng có thể nén nhiều bằng chứng giao dịch thành một bằng chứng. Thiết kế hiện tại của EIP-8361 tập trung vào nhận vào cho giao dịch khung cụ thể, không chuẩn hóa tổng hợp batch giao dịch tùy ý.

EIP-8361 có giảm phí gas không?

Không trực tiếp. Đề xuất có thể giảm tính toán lặp lại ngoài chuỗi của node, nhưng giao dịch được đưa vào vẫn phải trả phí gas thực thi Ethereum.

EIP-8361 khác gì với EIP-7702?

EIP-7702 cho phép EOA ủy quyền thực thi mã qua tuple ủy quyền đã ký. EIP-8361 đề xuất cách dựa trên bằng chứng để node nhận vào giao dịch với xác thực lập trình tốn kém.

Tuyên bố từ chối trách nhiệm

Nội dung này mang tính giáo dục và mô tả đề xuất kỹ thuật bản nháp, không phải nâng cấp Ethereum đảm bảo. Thông số kỹ thuật, kế hoạch triển khai, giả định bảo mật và hỗ trợ mạng có thể thay đổi. Diễn biến giao thức và dữ liệu thị trường lịch sử không dự đoán hiệu suất ETH trong tương lai.

Tác giả:  Jared
Tuyên bố từ chối trách nhiệm
* Đầu tư có rủi ro, phải thận trọng khi tham gia thị trường. Thông tin không nhằm mục đích và không cấu thành lời khuyên tài chính hay bất kỳ đề xuất nào khác thuộc bất kỳ hình thức nào được cung cấp hoặc xác nhận bởi Gate.
* Không được phép sao chép, truyền tải hoặc đạo nhái bài viết này mà không có sự cho phép của Gate. Vi phạm là hành vi vi phạm Luật Bản quyền và có thể phải chịu sự xử lý theo pháp luật.

Bài viết liên quan

Falcon Finance và Ethena: Phân tích chuyên sâu về thị trường stablecoin tổng hợp
Người mới bắt đầu

Falcon Finance và Ethena: Phân tích chuyên sâu về thị trường stablecoin tổng hợp

Falcon Finance và Ethena là hai dự án nổi bật trong lĩnh vực stablecoin tổng hợp, thể hiện hai xu hướng phát triển chính của stablecoin tổng hợp trong tương lai. Bài viết này phân tích sự khác biệt trong thiết kế của hai dự án về cơ chế sinh lợi, cấu trúc tài sản thế chấp và quản lý rủi ro, giúp độc giả nắm bắt rõ hơn các cơ hội và xu hướng dài hạn trong lĩnh vực stablecoin tổng hợp.
2026-03-25 08:14:36
Phân tích chuyên sâu về tokenomics của Morpho: tiện ích, phân phối và khung giá trị của MORPHO
Người mới bắt đầu

Phân tích chuyên sâu về tokenomics của Morpho: tiện ích, phân phối và khung giá trị của MORPHO

MORPHO là token gốc của giao thức Morpho, đảm nhận vai trò trọng tâm trong quản trị và thúc đẩy các hoạt động của hệ sinh thái. Bằng cách kết hợp phân phối token với các cơ chế khuyến khích, Morpho gắn kết sự tham gia của người dùng, quá trình phát triển giao thức và quyền lực quản trị, từ đó xây dựng nền tảng vững chắc cho giá trị lâu dài trong hệ sinh thái cho vay phi tập trung.
2026-04-03 13:14:14
0x Protocol và Uniswap: Giao thức Sổ lệnh khác gì so với mô hình AMM?
Trung cấp

0x Protocol và Uniswap: Giao thức Sổ lệnh khác gì so với mô hình AMM?

Cả 0x Protocol và Uniswap đều được xây dựng nhằm mục đích giao dịch tài sản phi tập trung, nhưng mỗi bên sử dụng cơ chế giao dịch khác biệt. 0x Protocol dựa vào kiến trúc sổ lệnh ngoài chuỗi kết hợp thanh toán trên chuỗi, tổng hợp thanh khoản từ nhiều nguồn để cung cấp hạ tầng giao dịch cho ví và DEX. Uniswap lại áp dụng mô hình Nhà tạo lập thị trường tự động (AMM), hỗ trợ hoán đổi tài sản trên chuỗi thông qua pool thanh khoản. Điểm khác biệt chủ yếu giữa hai bên là cách tổ chức thanh khoản. 0x Protocol tập trung vào tổng hợp lệnh và định tuyến giao dịch hiệu quả, phù hợp để cung cấp hỗ trợ thanh khoản nền tảng cho các ứng dụng. Uniswap sử dụng pool thanh khoản để cung cấp dịch vụ hoán đổi trực tiếp cho người dùng, trở thành nền tảng thực hiện giao dịch trên chuỗi mạnh mẽ.
2026-04-29 03:48:20
Falcon Finance Tokenomics: Phân tích cơ chế nắm bắt giá trị của FF
Người mới bắt đầu

Falcon Finance Tokenomics: Phân tích cơ chế nắm bắt giá trị của FF

Falcon Finance là giao thức thế chấp đa chuỗi trong lĩnh vực DeFi. Bài viết này phân tích khả năng thu giá trị của token FF, các chỉ số chủ chốt và lộ trình phát triển đến năm 2026 để đánh giá triển vọng tăng trưởng sắp tới.
2026-03-25 09:50:18
Jito và Marinade: Phân tích so sánh các giao thức Staking thanh khoản trên Solana
Người mới bắt đầu

Jito và Marinade: Phân tích so sánh các giao thức Staking thanh khoản trên Solana

Jito và Marinade là hai giao thức staking thanh khoản chủ đạo trên Solana. Jito tối ưu hóa lợi nhuận thông qua việc tận dụng MEV (Maximum Extractable Value), hấp dẫn đối với người dùng mong muốn đạt lợi suất cao hơn. Marinade lại cung cấp lựa chọn staking ổn định và phi tập trung, thích hợp cho những người dùng ưu tiên rủi ro thấp. Khác biệt cốt lõi giữa hai giao thức này chính là nguồn lợi nhuận và cấu trúc rủi ro đi kèm.
2026-04-03 14:06:30
Các thành phần cốt lõi của Giao thức 0x gồm những gì? Cụ thể là phân tích về Relayer, Mesh và kiến trúc API
Người mới bắt đầu

Các thành phần cốt lõi của Giao thức 0x gồm những gì? Cụ thể là phân tích về Relayer, Mesh và kiến trúc API

Giao thức 0x xây dựng hạ tầng giao dịch phi tập trung bằng các thành phần chủ chốt như Relayer, Mesh Network, 0x API và Exchange Proxy. Relayer chịu trách nhiệm phát sóng lệnh ngoài chuỗi, Mesh Network đảm nhiệm chia sẻ lệnh, 0x API cung cấp giao diện báo giá thanh khoản thống nhất, còn Exchange Proxy quản lý thực thi giao dịch trên chuỗi và điều phối thanh khoản. Nhờ sự phối hợp này, kiến trúc tổng thể cho phép kết hợp việc truyền lệnh ngoài chuỗi với thanh toán giao dịch trên chuỗi, giúp Ví, DEX và các Ứng dụng DeFi tiếp cận thanh khoản đa nguồn chỉ qua một giao diện duy nhất.
2026-04-29 03:06:50