Các bằng chứng hợp lệ giao dịch theo EIP-8361 hoạt động như thế nào?

EIP-8361 cho phép giao dịch khung EIP-8141 gửi kèm một STARK súc tích với payload ngang hàng, giúp node xác nhận tiền tố xác thực đã phê duyệt giao dịch dựa trên giả định trạng thái đã khai báo. Thay vì phải thực thi lặp lại cùng một cơ chế, node chỉ kiểm tra một bằng chứng duy nhất, các phụ thuộc và điều kiện trạng thái liên quan, từ đó giảm chi phí xác minh cho logic tài khoản phức tạp. Các phần dưới đây trình bày cách giao dịch hợp lệ nhận bằng chứng, node phát hiện giao dịch lỗi thời hoặc gian lận, lý do bằng chứng tham chiếu trạng thái hợp lệ trước nhưng không trở thành gốc Merkle, và vì sao nó bị loại bỏ sau khi vào block.

Phần giải thích này cũng phân biệt EIP-8361 với hai loại bảo mật rollup chính: ZK proof xác lập tính đúng đắn trước khi chấp nhận, và fraud proof cần quy trình khiếu nại để chứng minh chuyển đổi không hợp lệ. Phần này cũng làm rõ các giới hạn liên quan chữ ký ECDSA, an toàn lượng tử, rủi ro máy tính lượng tử, và vai trò hẹp hơn của đề xuất so với các giải pháp mở rộng quy mô. Bản phân tích kỹ thuật này dành cho đội ví, nhà phát triển client, nhà vận hành prover và người dùng đánh giá cách giao dịch mang bằng chứng có thể mở rộng xác thực Ethereum, trong khi EIP-8361 vẫn là đề xuất mạng nháp thay vì quy tắc đồng thuận.

Những điểm chính

• EIP-8361 cho phép giao dịch khung EIP-8141 mang bằng chứng chấp nhận như metadata ngoài chuỗi.
• Prover ngoài chuỗi thực thi tiền tố xác thực dựa trên giả định đã khai báo và tạo STARK liên kết với giao dịch, người trả phí, phụ thuộc và điều kiện hợp lệ.
• Node nhận thực hiện kiểm tra không trạng thái, xác minh bằng chứng và phụ thuộc, so sánh giả định với trạng thái Ethereum hiện tại.
• Bằng chứng hợp lệ cho phép nhận vào mempool mà không cần mô phỏng lại toàn bộ tiền tố xác thực.
• Bằng chứng không quyết định tính hợp lệ block, không thay đổi thực thi, không là một phần trạng thái vĩnh viễn Ethereum. Nó bị loại bỏ sau khi được đưa vào hoặc loại khỏi mempool.

Bằng chứng tính hợp lệ giao dịch EIP-8361 là gì?

EIP-8361 định nghĩa phương thức nhận giao dịch đề xuất cho EIP-8141. Mục đích hẹp: làm cho giao dịch tốn kém về tính toán đủ rẻ để node đánh giá trước khi chuyển tiếp qua mempool công khai.

Giao dịch khung EIP-8141 có thể chứa logic lập trình xác định người gửi có cho phép giao dịch, ai trả phí thực thi, và điều kiện chỉ định có được đáp ứng. Logic này nằm trong tiền tố xác thực chạy trước các frame thực thi thông thường.

Theo nhận mô phỏng thông thường, mỗi node nhận có thể cần thực thi tiền tố đó để xác định giao dịch có nên vào mempool. EIP-8361 bổ sung lựa chọn khác: prover thực thi tiền tố ngoài chuỗi một lần và tạo bằng chứng mật mã chứng minh nó kết thúc với kết quả APPROVE và xác định người trả phí.

Giao dịch và bằng chứng đi cùng nhau. Node xác minh bằng chứng thay vì tái tạo toàn bộ quá trình xác thực.

Khung EIP-8361 framework tập trung vào nhận mempool dựa trên bằng chứng, còn quy trình xác thực mempool EIP-8361 quyết định node nhận chấp nhận, giữ lại, tạm dừng hay loại bỏ các giao dịch này.

Tính đến ngày 6 tháng 8 năm 2026, EIP-8361 là pull request nháp #12075 thuộc đề xuất chuẩn hóa mạng. Nó không tạo loại giao dịch mới hoặc tự thay đổi đồng thuận Ethereum.

Bằng chứng mật mã EIP-8361 hoạt động thế nào?

Bằng chứng bao phủ một phát biểu cụ thể, không khẳng định biết trước mọi kết quả thực thi tương lai.

Ở dạng đơn giản, prover phải chứng minh rằng:

Tiền tố xác thực của giao dịch T, khi đánh giá dưới các giả định và phụ thuộc đã khai báo, tuân theo quy tắc trace EIP-8141 và kết thúc với APPROVE và người trả phí P, tuân thủ điều kiện đã khai báo.

Đầu vào công khai liên kết bằng chứng với năm yếu tố:

Sự liên kết này đảm bảo một bằng chứng hợp lệ cho một giao dịch không thể gán cho giao dịch khác với dữ liệu, phụ thuộc, điều kiện hoặc người trả phí khác.

Bằng chứng riêng tư gồm thông tin cần thiết để đánh giá tiền tố, gồm nội dung danh sách phụ thuộc đã khai báo. Bằng chứng kết quả chứng minh tính đúng đắn phép tính đó mà không bắt buộc mọi node nhận phải lặp lại.

EIP-8361 đề xuất tái sử dụng định dạng bằng chứng và cơ chế xác minh đầu vào của EIP-8288. EIP này nhắc đến STARK vì chúng đại diện phép tính lớn với bằng chứng súc tích và không yêu cầu mọi verifier tái tạo toàn bộ khối lượng công việc gốc.

Vector giả định dùng thế nào trong xác thực giao dịch?

Bằng chứng mật mã có thể chứng minh phép tính đúng với đầu vào cụ thể, nhưng node mempool vẫn phải xác định đầu vào đó có khớp với trạng thái Ethereum hiện tại không.

EIP-8361 giải quyết bằng vector giả định A, liệt kê mọi giá trị trạng thái tiền tố xác thực đọc đến. Các mục gồm địa chỉ, khóa lưu trữ hoặc tham chiếu số dư, loại so sánh và giá trị.

Hai loại so sánh:

• EQ yêu cầu giá trị trạng thái hiện tại bằng giá trị khai báo trong bằng chứng.
• GEQ yêu cầu giá trị trạng thái hiện tại lớn hơn hoặc bằng ngưỡng khai báo.

EQ phù hợp cho băm mã, nonce hoặc nhánh lưu trữ có ý nghĩa thay đổi khi giá trị nền thay đổi. GEQ hữu ích cho yêu cầu đơn điệu như kiểm tra người trả phí có đủ số dư trả trước.

Ví dụ, nếu tiền tố xác thực của smart account chỉ phê duyệt giao dịch khi số dư paymaster ít nhất 0,2 ETH, prover ghi nhận giả định GEQ với ngưỡng 0,2 ETH. Node tiếp tục coi bằng chứng hợp lệ khi số dư từ 0,2 ETH trở lên. Không cần bằng chứng mới mỗi lần số dư tăng hoặc thay đổi trên ngưỡng đó.

Thiết kế này tránh gắn bằng chứng với toàn bộ gốc trạng thái hoặc yêu cầu bằng chứng Merkle lớn cho toàn bộ trạng thái Ethereum. Mạch điện đánh giá tiền tố xác thực với giá trị khai báo, còn node kiểm tra các giá trị đó với trạng thái hiện tại của mình.

Bằng chứng tính hợp lệ giao dịch hoạt động thế nào dưới EIP-8361?

Quy trình xác thực giao dịch theo chuỗi kiểm tra có thứ tự:

1. Kiểm tra không trạng thái. Node kiểm tra tính hợp lệ nội tại giao dịch và xác nhận danh sách phụ thuộc hoặc chữ ký đúng định dạng. Giao dịch sai định dạng bị từ chối trước khi xác minh bằng chứng tốn kém.
2. Xác minh bằng chứng chấp nhận. Node xác minh STARK theo khóa xác minh chỉ định. Nếu thất bại, phép tính xác thực chưa được thiết lập.
3. Xác minh phụ thuộc ngoài. Bằng chứng có thể giả định chữ ký hoặc phụ thuộc đã khai báo hợp lệ. Node xác minh riêng các phụ thuộc này và xác nhận danh sách khớp với băm phụ thuộc đã cam kết.
4. Kiểm tra điều kiện hợp lệ. Node đánh giá điều kiện khai báo, có thể gồm thời hạn, slot hoặc epoch, phạm vi hết hạn hoặc yêu cầu nonce.
5. So sánh giả định với trạng thái trực tiếp. Mỗi EQ kiểm tra bằng nhau, mỗi GEQ kiểm tra với ngưỡng.
6. Nhận giao dịch. Khi mọi kiểm tra thành công, node chấp nhận và lan truyền giao dịch mà không cần mô phỏng toàn bộ tiền tố xác thực.

Trình tự này ngăn bằng chứng vượt qua kiểm tra cấu trúc, chữ ký, trạng thái hoặc thời gian thông thường. Nó chỉ thay đổi phương pháp tính toán để quyết định nhận vào, không thay đổi yêu cầu hợp lệ cơ bản của giao dịch.

Khi trạng thái Ethereum thay đổi thì sao?

Nhận vào mempool không đảm bảo vĩnh viễn vì trạng thái Ethereum tiếp tục thay đổi sau khi giao dịch vào pool.

Theo EIP-8361, node kiểm tra lại điều kiện hợp lệ và vector giả định khi block mới đổi chain head. Không cần tạo lại bằng chứng, chạy lại tiền tố xác thực hoặc xác minh lại cùng bằng chứng. Bằng chứng đã xác minh trước vẫn là kết quả cache về hàm xác thực dưới đầu vào khai báo.

Lỗi EQ thường làm bằng chứng mất hiệu lực vì đầu vào chính xác đã thay đổi. Node phải loại bỏ giao dịch trừ khi người gửi tạo bằng chứng mới hoặc giao dịch đủ điều kiện nhận vào mô phỏng thông thường.

Điều kiện GEQ thất bại có thể được xử lý khác. Node có thể tạm dừng giao dịch thay vì loại bỏ hoàn toàn. Nếu người trả phí hoặc paymaster sau đó nhận đủ tiền, node có thể kích hoạt lại giao dịch bằng cách kiểm tra lại ngưỡng.

Sự phân biệt này khiến vector giả định không chỉ là cam kết kiểu Merkle với một trạng thái lịch sử. Nó xác định thay đổi trạng thái nào làm mất hiệu lực phê duyệt và thay đổi nào vẫn hợp lệ.

Vì sao bằng chứng bị loại bỏ sau khi vào block?

Bằng chứng EIP-8361 chỉ cần cho nhận và lan truyền qua mempool công khai. Nó không phải bằng chứng quyết định giao dịch đã đưa vào tạo ra chuyển đổi trạng thái đúng.

Khi validator đưa giao dịch vào block, Ethereum xử lý qua thực thi giao thức chuẩn. EVM chạy tiền tố xác thực và các frame còn lại theo trạng thái block chuẩn. Client đồng thuận xác định block hợp lệ theo quy tắc Ethereum.

Vì vậy, bằng chứng chấp nhận:

• không được đưa vào block;
• không thêm vào calldata giao dịch;
• không xuất hiện trong biên nhận;
• không là một phần của cây Merkle hay gốc trạng thái;
• không tạo thay đổi trạng thái trên chuỗi vĩnh viễn;
• không cần giữ lại sau khi giao dịch được đưa vào hoặc loại bỏ.

Việc loại bỏ này tránh chi phí calldata vĩnh viễn và tăng trưởng trạng thái cho thông tin đã hoàn thành mục đích mạng. Giao dịch vẫn trên chuỗi, nhưng phong bì bằng chứng tạm thời thì không.

So sánh hệ thống bằng chứng EIP-8361 với bằng chứng hợp lệ ZK-Rollup

EIP-8361 dùng công nghệ bằng chứng mật mã, nhưng bằng chứng chấp nhận không nên nhầm với bằng chứng hợp lệ ZK rollup.

ZK rollup thường dùng ZK-SNARK hoặc ZK-STARK để chứng minh tính đúng đắn của batch giao dịch. Khi bằng chứng được hợp đồng Layer 1 chấp nhận, rollup có thể hoàn tất chuyển đổi trạng thái liên quan mà không đợi thời gian khiếu nại fraud-proof như optimistic rollup.

EIP-8361 không chứng minh batch L2, không cho phép rút rollup ngay, không đảm bảo chuỗi L2 không vào trạng thái không hợp lệ. Bằng chứng chỉ là hiện vật mạng tạm thời về xác thực trước khi vào.

Tương tự, dù bằng chứng zero-knowledge có thể xác minh phát biểu mà không tiết lộ toàn bộ dữ liệu nhân chứng, EIP-8361 không chủ yếu là đề xuất về quyền riêng tư. “Bằng chứng súc tích” và “zero knowledge” là thuộc tính liên quan nhưng không đồng nhất.

Rút từ Layer 2 về Layer 1 có thể nhanh hơn với bằng chứng hợp lệ vì ZK rollup không cần thời gian khiếu nại fraud-proof như optimistic rollup. Thời gian rút cuối cùng vẫn phụ thuộc tạo bằng chứng, xác minh Layer 1, quy tắc cầu nối và tính cuối cùng Ethereum. EIP-8361 không cung cấp cơ chế rút này; bằng chứng chỉ hỗ trợ nhận vào mempool cho từng giao dịch khung EIP-8141, không phải quyết toán batch giao dịch Layer 2.

Fraud proof hoạt động thế nào trong Optimistic Rollup?

Fraud proof dựa vào cơ chế bảo mật khác. Optimistic rollup ban đầu chấp nhận chuyển đổi trạng thái đề xuất và cho phép bên khiếu nại chứng minh gian lận trong thời gian tranh chấp. Tùy triển khai, giải quyết tranh chấp có thể cần nhiều vòng hoặc bằng chứng thực thi thu hẹp.

EIP-8361 cố gắng xác lập phát biểu nhận vào trước khi giao dịch được chấp nhận vào lớp mempool liên quan. Không có thời gian khiếu nại sau nhận vào để bên khác chứng minh kết quả tiền tố là gian lận.

Khác biệt chính là về thời điểm và phạm vi:

• Bằng chứng hợp lệ chứng minh phát biểu chỉ định trước khi chấp nhận.
• Fraud proof cho phép phát biểu lạc quan trừ khi bị khiếu nại thành công.
• Bằng chứng chấp nhận EIP-8361 liên quan đến chính sách mempool.
• Fraud proof rollup liên quan đến tính đúng đắn chuyển đổi trạng thái L2.

Các đánh đổi kỹ thuật giữa thực thi EVM lặp lại và xác minh súc tích được trình bày trong EIP-8361 versus transaction simulation, gồm nơi chi phí tạo bằng chứng thay thế chi phí mô phỏng node.

EIP-8361, xác thực tài khoản phức tạp và bảo mật hậu lượng tử

Tài khoản lập trình có thể dùng đa chữ ký, luân chuyển khóa, quy tắc khôi phục, lược đồ chữ ký phi chuẩn, ứng viên chữ ký hậu lượng tử, chính sách chi tiêu hoặc kiểm tra zero-knowledge tốn gas. Một số logic này hợp lệ nhưng quá tốn kém để mọi node mempool mô phỏng an toàn.

EIP-8361 duy trì lan truyền giao dịch công khai cho các tài khoản này bằng cách làm xác thực tốn kém với prover nhưng rẻ hơn với mỗi verifier. Nó cũng giảm áp lực phải chuyển logic ủy quyền phức tạp sang giai đoạn thực thi, nơi kiểm tra thất bại có thể dẫn đến giao dịch revert đã trả phí và ghi lại công khai.

Cơ chế này không làm mọi hợp đồng thông minh đều an toàn hoặc thiết lập bảo mật hậu lượng tử hoàn chỉnh. STARK có thể tránh một số giả định liên quan hệ thống bằng chứng dựa trên đường cong elliptic, nhưng giao dịch vẫn có thể phụ thuộc vào khóa công khai, lược đồ chữ ký, triển khai client, mã ví hoặc khóa xác minh với thuộc tính bảo mật riêng.

Trách nhiệm với người tạo giao dịch, ví, prover và client khác biệt đáng kể, như tóm tắt trong tác động EIP-8361 với ví, node và nhà phát triển.

Ví dụ, nhà giao dịch đánh giá liệu phát triển account abstraction Ethereum ảnh hưởng tâm lý thị trường có thể so sánh các cột mốc đề xuất với biểu đồ ETH/USDT, dù biến động giá không xác nhận một EIP nháp đã triển khai hoặc chấp nhận.

Rủi ro và giới hạn

EIP-8361 vẫn là bản nháp sớm, nên định dạng bằng chứng, giới hạn, phụ thuộc, thuật ngữ và chi tiết triển khai có thể thay đổi trước chuẩn hóa.

Cơ chế này cũng có một số rủi ro kỹ thuật:

Tập trung tạo bằng chứng: Việc tạo STARK có thể cần phần mềm chuyên biệt và tính toán lớn. Nếu chỉ một số dịch vụ tạo bằng chứng hiệu quả, ví có thể phụ thuộc vào hạ tầng prover tập trung.

Áp lực tấn công từ chối dịch vụ: Xác minh bằng chứng rẻ hơn lặp lại phép tính gốc, nhưng không miễn phí. Client cần giới hạn kích thước bằng chứng, giới hạn tốc độ peer và quy tắc quy trách nhiệm thất bại để ngăn kẻ tấn công làm ngập node bằng bằng chứng sai hoặc quá lớn.

Đầy đủ giả định: Bằng chứng chỉ có ý nghĩa khi vector giả định chứa mọi trạng thái được tiền tố xác thực đọc tới. Lỗi mạch điện hoặc client bỏ sót phụ thuộc có thể dẫn đến quyết định nhận vào sai.

Trạng thái lỗi thời: Bằng chứng có thể vẫn đúng về mặt mật mã trong khi điều kiện khai báo không còn khớp trạng thái hiện tại. Node phải kiểm tra lại A và C khi giao dịch còn trong pool.

Không đảm bảo thực thi: Nhận vào mempool không đảm bảo được đưa vào block hoặc thực thi cuối cùng thành công. Giao dịch khác có thể thay đổi nonce, số dư, mã, lưu trữ hoặc trạng thái liên quan của người gửi trước khi được đưa vào.

Độ phức tạp triển khai: Client, ví và hệ thống prover phải thống nhất về mã hóa bằng chứng, khóa xác minh, xử lý phụ thuộc, hành vi peer và quy tắc xác minh lại. Triển khai không nhất quán có thể làm phân mảnh lan truyền giao dịch.

EIP-8361 có phải là đề xuất Tapered Issuance Burn không?

Một số thảo luận ban đầu gắn số EIP-8361 với đề xuất chính sách tiền tệ Ethereum khác tên Tapered Issuance Burn. Đề xuất đó sau này là EIP-8363, còn EIP-8361 nói về Transaction Validity Proofs trong danh mục mạng. Hai đề xuất này không liên quan: EIP-8361 giải quyết nhận vào mempool dựa trên bằng chứng, Tapered Issuance Burn thay đổi kinh tế phần thưởng lớp đồng thuận dựa trên số dư staking hoạt động.

Kết luận

Bằng chứng tính hợp lệ giao dịch EIP-8361 chuyển phần xác thực giao dịch lập trình tốn kém khỏi mỗi node nhận sang prover ngoài chuỗi. STARK kết quả liên kết giao dịch EIP-8141 với kết quả phê duyệt, người trả phí, phụ thuộc, điều kiện và giả định trạng thái, cho phép node xác minh phát biểu súc tích trước khi nhận vào mempool.

Cơ chế này hữu ích nhất khi smart account có logic xác thực hợp lệ vượt giới hạn mô phỏng thực tế. Giới hạn chính: bằng chứng chỉ áp dụng cho nhận vào lớp mạng. Ethereum vẫn thực thi giao dịch bình thường khi đưa vào, và bằng chứng tạm thời bị loại bỏ vì không có vai trò đồng thuận hoặc trên chuỗi sau đó.

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

ZK rollup sử dụng bằng chứng hợp lệ như thế nào?

ZK rollup xử lý giao dịch ngoài chuỗi, gom thành batch và tính bằng chứng hợp lệ cho mỗi batch. Bằng chứng, thường dùng ZK-SNARK, ZK-STARK hoặc cam kết đa thức, cho phép hợp đồng Ethereum xác minh chuyển đổi trạng thái là đúng mà không cần chạy lại mọi giao dịch.

Bằng chứng hợp lệ có đảm bảo chuỗi L2 không thể bị vô hiệu không?

Bằng chứng hợp lệ ngăn verifier L1 chấp nhận chuyển đổi trạng thái không hợp lệ khi mạch điện, hợp đồng verifier, mật mã và triển khai đúng. Không loại bỏ rủi ro liên quan lỗi mã, tính sẵn có dữ liệu, cầu nối, sequencer, quản trị hoặc kiểm soát nâng cấp.

Vì sao rút tiền ZK-rollup thường nhanh hơn?

ZK rollup có thể hoàn tất rút tiền sau khi bằng chứng hợp lệ được gửi và xác minh, không cần đợi thời gian khiếu nại fraud-proof như optimistic rollup. Việc rút vẫn phụ thuộc tạo bằng chứng, gửi batch, quy tắc cầu nối và tính cuối cùng Ethereum, nên “ngay lập tức” không phải luôn là tức thì.

Bằng chứng hợp lệ khác gì fraud proof?

Bằng chứng hợp lệ xác lập tính đúng đắn giao dịch trước khi chuyển đổi trạng thái được chấp nhận. Fraud proof hoạt động theo mô hình lạc quan, chuyển đổi có thể được chấp nhận tạm thời và bị khiếu nại sau; nhiều optimistic rollup dùng thời gian khiếu nại khoảng bảy ngày, nhưng thời lượng cụ thể khác nhau.

Bằng chứng zero-knowledge có luôn ẩn dữ liệu giao dịch không?

Không. Bằng chứng zero-knowledge có thể xác minh phát biểu mà không tiết lộ nhân chứng riêng tư, nhưng quyền riêng tư phụ thuộc vào đầu vào nào được ẩn. Nhiều ZK rollup chủ yếu dùng ZK proof cho xác minh giao dịch quy mô lớn, không phải cho giao dịch hoàn toàn riêng tư.

Sự khác biệt giữa ZK-SNARK và ZK-STARK là gì?

ZK-SNARK thường cho bằng chứng nhỏ với chi phí xác minh thấp, dù nhiều thiết kế cần thiết lập tin cậy. ZK-STARK không cần thiết lập tin cậy và thường được coi là chống tấn công máy tính lượng tử tốt hơn, nhưng bằng chứng thường lớn hơn.

Bằng chứng Merkle xác minh điều gì?

Bằng chứng Merkle xác nhận dữ liệu cụ thể thuộc về tập dữ liệu đại diện bởi gốc Merkle mà không tiết lộ hoặc tải về toàn bộ tập dữ liệu. Nó chứng minh bao gồm hoặc loại trừ, không phải tính đúng đắn của batch giao dịch hoặc chuyển đổi trạng thái.

Bằng chứng hợp lệ có giảm tiêu thụ tài nguyên trên chuỗi không?

Có, chúng có thể nén phép tính ngoài chuỗi lớn thành một bằng chứng duy nhất rẻ hơn để xác minh trên chuỗi so với chạy lại mọi giao dịch. Tiết kiệm thực tế phụ thuộc chi phí xác minh bằng chứng, kích thước batch, sử dụng calldata hoặc blob, và cách triển khai rollup.

Bằng chứng hợp lệ có giảm rủi ro tấn công 51% không?

Không trực tiếp. Bằng chứng hợp lệ bảo vệ tính đúng đắn chuyển đổi trạng thái Layer 2 đã xác minh, còn tấn công 51% liên quan kiểm soát đồng thuận Ethereum và lựa chọn fork. Hai cơ chế này giải quyết rủi ro bảo mật khác nhau.

Bằng chứng EIP-8361 có giống bằng chứng ZK-rollup không?

Không. Bằng chứng ZK-rollup xác minh batch giao dịch Layer 2 và hỗ trợ tính cuối cùng trạng thái cùng rút tiền. Bằng chứng EIP-8361 hỗ trợ nhận vào mempool cho từng giao dịch khung EIP-8141, không nằm trong block và bị loại bỏ sau khi được đưa vào hoặc loại khỏi mempool.

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

Nội dung này nhằm mục đích giáo dục và mô tả một đề xuất Ethereum nháp có thể thay đổi thông số kỹ thuật và trạng thái triển khai. Không cung cấp lời khuyên tài chính, bảo mật hoặc triển khai phần mềm. Nhà phát triển cần xác minh văn bản EIP mới nhất và yêu cầu client trước khi xây dựng hệ thống sản xuất.