Dịch và hiệu đính: "Cộng đồng Trung Quốc StarkNet"
Bản tóm tắt
Các chức năng tích hợp tối ưu hóa quy trình kiểm chứng. Tuy nhiên, mỗi bằng chứng được tính toán từ bố cục. Đối với một số công việc chứng minh, lợi thế của các chức năng tích hợp sẽ giảm đi rất nhiều nếu bố cục không hiệu quả. Hiện tại, có một danh sách bố cục tĩnh nhỏ và mỗi bằng chứng được tính toán dựa trên bố cục phù hợp nhất từ danh sách đó. Cách bố trí danh sách tĩnh này có hai nhược điểm. Đầu tiên, có rất nhiều bố cục hạn chế. Điều này không hiệu quả đối với hầu hết các công việc chứng minh và tạo ra các cơ chế phí phức tạp khiến người dùng phải trả những chi phí không cần thiết. Thứ hai, việc duy trì danh sách theo cách thủ công là khó khăn. Khi số lượng nội trang tăng quá cao, việc bảo trì thủ công trở nên khó khăn và thực sự có thể cản trở quá trình chứng minh nội trang hiệu quả hỗ trợ một số lượng lớn sắc thái. Để giải quyết những vấn đề này, nhóm StarkWare đang phát triển một hệ thống bố cục động trong đó các bố cục được tùy chỉnh cho từng bằng chứng công việc.
Ngăn xếp Cairo hỗ trợ tính toán cho mục đích chung có thể chứng minh được bằng cách biên dịch mã Cairo thành hướng dẫn dành cho kiến trúc CPU thân thiện với STARK: Máy ảo Cairo (sau đây gọi là CVM). Nhiều ưu điểm của CPU đa năng có chi phí vốn có và CVM không được tối ưu hóa cho một số hoạt động phổ biến. Các hàm băm Keccak, Pedersen, Poseidon là các phép toán phổ biến như vậy, cũng như các phép toán đường cong elip, kiểm tra phạm vi (nghĩa là kiểm tra xem một số cụ thể có nằm trong một phạm vi giá trị cụ thể hay không) và các phép toán khác.
Để giải quyết tình trạng kém hiệu quả tương đối của CVM, ngăn xếp Cairo giới thiệu khái niệm tích hợp sẵn cho các hoạt động quan trọng: các plugin tối ưu hóa các hoạt động đó để chứng minh độ phức tạp. Các chức năng tích hợp có thể được so sánh với ASIC: ASIC là các mạch tích hợp dành riêng cho ứng dụng và các chức năng tích hợp sẵn là các ràng buộc đại số dành riêng cho ứng dụng (AIR). Nếu bạn không biết hoặc không nhớ AIR là gì, nó sẽ được đề cập ngắn gọn ở phần sau của bài viết này; hãy đọc bài viết này để biết thêm chi tiết.
Nói tóm lại, độ phức tạp của bằng chứng có liên quan (gần như tuyến tính) với các tài nguyên được gọi là đơn vị theo dõi và các chức năng tích hợp sẵn giúp đơn giản hóa bằng chứng về các hoạt động cụ thể bằng cách sử dụng ít đơn vị theo dõi hơn nhiều so với Cairo VM.
Giờ đây, khi các lợi ích của các hàm tích hợp đã được giải thích, bạn sẽ hiểu rõ tại sao các hàm tích hợp sẵn được phát triển cho nhiều hoạt động phổ biến. Nói thì dễ hơn là làm. Quy trình hiện tại để giới thiệu các tính năng tích hợp mới vào Starknet bao gồm các bước sau:
Viết KHÍ
Tích hợp với tục ngữ bằng cách tạo bố cục mới (mô tả bên dưới)
Tích hợp vào Starknet, tức là sửa đổi cơ sở mã và các công cụ dành cho nhà phát triển của nó để sử dụng các chức năng tích hợp mới
Ngoài những thách thức khi viết AIR, còn rất nhiều điều cần cải thiện trong hai giai đoạn còn lại. Bài viết nâng cao này sẽ mô tả chi tiết hơn các chức năng tích hợp của AIR như ứng dụng cụ thể, các vấn đề nêu trên và các kế hoạch trong tương lai.
Các chức năng tích hợp: AIR dành riêng cho ứng dụng
AIR là từ viết tắt của Biểu diễn trung gian đại số. Trong bài viết này và các bài viết khác của StarkWare, AIR là một hệ thống đa thức để biểu diễn các máy ảo. Ví dụ: Cairo lấy tên từ CPU AIR: một hệ thống đa thức đại diện cho một kiến trúc CPU cụ thể. Các giải pháp của hệ thống đa thức này đại diện cho các chuyển đổi trạng thái hiệu quả, được gọi là quỹ đạo thực hiện đại số hiệu quả (AET).
STARK chứng minh rằng hoạt động của máy ảo là chính xác bằng cách chứng minh quỹ đạo thực thi tương ứng với một AIR nhất định là hợp lệ. Nói một cách đại khái, quỹ đạo thực thi là một bảng số và giao thức STARK chứng minh rằng những con số này cùng nhau giải được một hệ đa thức.
Hoạt động tương tự có thể được tính theo nhiều cách, một số cách hiệu quả hơn. Trong bài báo này, độ phức tạp của bằng chứng về cơ bản phụ thuộc vào kích thước bản nhạc, tức là số lượng ô bản nhạc trong bảng. Vì các dấu vết được tạo cho AIR, AIR được thiết kế cho các ứng dụng để giảm đáng kể dấu vết thực thi cho các tính toán cụ thể. Các chức năng tích hợp là AIR chuyên dụng được tối ưu hóa cho ứng dụng.
Bảng dưới đây cho thấy các cải tiến hiệu quả cho các chức năng tích hợp cụ thể (tất cả đều được sản xuất).
Bố cục quỹ đạo: hiện tại và tương lai
Như đã đề cập trước đó, AET đại khái là một bảng số biểu thị trình tự các bước trong máy ảo được mã hóa (nghĩa là quá trình thực thi chương trình). Để tính toán bằng chứng, người quảng cáo chạy giao thức STARK trên đường thực thi của AIR liên quan.
Ở trên, chúng tôi đã giới thiệu các hàm tích hợp dưới dạng AIR dành riêng cho ứng dụng được thiết kế để giảm thiểu độ phức tạp của bằng chứng bằng cách giảm số lượng đơn vị theo dõi cần thiết để mã hóa tính toán. Tuy nhiên, nếu các chức năng tích hợp sẵn được tích hợp ngẫu nhiên trong Starknet, nhiều đơn vị quỹ đạo có thể bị lãng phí và lợi ích mong đợi sẽ giảm đi. Hãy giải thích chi tiết dưới đây.
Nói tóm lại, bố cục đường đua là việc gán các ô đường đua cho các "thành phần" khác nhau. Trong bài viết này, các thành phần này là CVM và các hàm tích hợp sẵn. Cụ thể, bố cục chỉ định số lượng ô theo dõi tương đối mà mỗi thành phần nhận được. (Các cấu trúc bố cục luôn được sử dụng để đơn giản hóa việc xác thực. Để tìm hiểu thêm, hãy đọc phần "Tính đơn giản" của bài đăng này).
Điểm mấu chốt là độ phức tạp của bằng chứng phụ thuộc vào tổng số ô theo dõi được phân bổ bởi bố cục và phân bổ ô theo dõi có thể lớn hơn mức thực sự cần thiết. Ví dụ: để minh họa thứ tự bước của CVM, bố cục chỉ gán các ô theo dõi cho các thành phần CVM hiệu quả gần gấp đôi so với bố cục chỉ định một nửa số ô theo dõi cho các hàm tích hợp Poseidon. Tóm lại, một bố cục phù hợp có thể làm giảm đáng kể độ phức tạp của việc chứng minh một tính toán cụ thể.
Hiện tại có một danh sách các bố cục được duy trì thủ công phát triển theo thời gian vì hai lý do chính:
Các chức năng tích hợp chỉ có thể được sử dụng cho bố cục của đơn vị rãnh được gán cho chúng. Do đó, việc thêm phần dựng sẵn yêu cầu ít nhất một bố cục mới.
Bố cục được điều chỉnh để thực thi mã Cairo tối ưu hóa việc phân bổ ô. Do đó, việc tối ưu hóa các trường hợp sử dụng trong ô thường yêu cầu bố cục mới.
Mã cho trình chứng minh và trình xác thực (trình xác thực Solidity và Cairo) được định cấu hình theo danh sách bố cục.
Khi các nội trang Keccak và Poseidon được thêm vào, việc giữ các danh sách bố cục đủ nhỏ để chứa nhiều nội trang và giữ cho hầu hết các khối Starknet thực thi hiệu quả ngày càng trở nên khó khăn. Hơn nữa, hiệu quả dự kiến sẽ giảm đáng kể khi các phần mềm tích hợp sẵn bổ sung được giới thiệu, do bố cục phải tính đến nhiều kết hợp và tỷ lệ có thể có giữa các phần mềm tích hợp sẵn.
Nhóm StarkWare hiện đang làm việc để cải thiện hệ thống bằng cách loại bỏ các danh sách bố cục được tạo sẵn để chuyển sang "bố cục động", là các tùy chỉnh tức thời cho mỗi lần thực thi mã Cairo. Bố cục động sẽ luôn thực hiện phân bổ theo tỷ lệ tốt nhất cho công việc xác minh hiện tại. Từ quan điểm kỹ thuật, việc hỗ trợ gõ động sẽ yêu cầu những thay đổi đáng kể đối với cơ sở mã. Tuy nhiên, nhóm StarkWare hy vọng sẽ đơn giản hóa lớp chứng minh của Starknet bằng cách tận dụng bố cục động, cải thiện việc sử dụng đơn vị theo dõi và sử dụng tốt hơn các trình chứng thực.
Với bố cục động, rắc rối của việc duy trì thủ công nhiều tiện ích tích hợp sẵn sẽ biến mất, đơn giản hóa quy trình tích hợp nhiều tiện ích tích hợp mới hơn vào Starknet.
Giao diện động và phí
Một mục đích của phí giao dịch là tính phí cho người dùng chi phí giao thức cận biên phát sinh từ các giao dịch. Vì đơn vị tính phí giao dịch là tiền tệ nên cơ chế tính phí liên quan đến việc chuyển đổi từ tài nguyên (ví dụ: bước máy ảo, chức năng tích hợp, calldata, Ethereum gas) sang mã thông báo (ví dụ: STRK, ETH).
Hiện tại, do người dùng tính phí dựa trên tổng dấu vết chứ không phải tỷ lệ sử dụng, tài nguyên lãng phí do người dùng gánh chịu. Bố cục động sẽ cải thiện việc sử dụng đơn vị theo dõi, do đó giảm việc tính phí giao dịch "không cần thiết" (bao gồm cả mức tiêu thụ tài nguyên không phải do giao dịch của người dùng gây ra trực tiếp).
Tích hợp chức năng tích hợp trong Starknet
Tại thời điểm này, việc tích hợp các chức năng tích hợp còn thiếu bước cuối cùng, đó là sửa đổi cơ sở mã Starknet để nhận ra việc sử dụng thực tế. Phạm vi sửa đổi mã có liên quan đến ứng dụng bố cục và cần phải sửa đổi mã để đảm bảo rằng hệ điều hành Starknet gọi các chức năng tích hợp sẵn khi có thể. Ví dụ: hệ điều hành Starknet gọi hàm băm Poseidon trong quá trình thực thi mã Cairo, đồng thời gọi hàm tích hợp Poseidon.
Tương tự như bố cục, các nội dung dựng sẵn của Starknet hiện có thể được hỗ trợ theo cách thủ công. Tuy nhiên, không giống như trường hợp bố trí, hỗ trợ thủ công này không phải là rào cản đối với việc tích hợp mặc dù có nhiều chức năng được tích hợp sẵn. Nói cách khác, hỗ trợ nội trang của Starknet không phải là rào cản đối với việc tích hợp, bố cục động sẽ thực sự mở đường cho việc tạo và tích hợp nội trang bổ sung.
Tóm tắt
Trong bài viết này, chúng tôi giải thích chức năng tích hợp sẵn là gì, lợi ích của chúng, những thách thức liên quan và kế hoạch của StarkWare. Trọng tâm hiện tại là bố cục động, điều này sẽ không chỉ cải thiện hiệu quả của quy trình kiểm chứng mà còn tạo điều kiện thuận lợi cho việc tích hợp các nội dung tích hợp mới.
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Lợi ích và thách thức của các chức năng tích hợp trong Starknet
Bản gốc: Nội trang và bố cục động
Dịch và hiệu đính: "Cộng đồng Trung Quốc StarkNet"
Bản tóm tắt
Các chức năng tích hợp tối ưu hóa quy trình kiểm chứng. Tuy nhiên, mỗi bằng chứng được tính toán từ bố cục. Đối với một số công việc chứng minh, lợi thế của các chức năng tích hợp sẽ giảm đi rất nhiều nếu bố cục không hiệu quả. Hiện tại, có một danh sách bố cục tĩnh nhỏ và mỗi bằng chứng được tính toán dựa trên bố cục phù hợp nhất từ danh sách đó. Cách bố trí danh sách tĩnh này có hai nhược điểm. Đầu tiên, có rất nhiều bố cục hạn chế. Điều này không hiệu quả đối với hầu hết các công việc chứng minh và tạo ra các cơ chế phí phức tạp khiến người dùng phải trả những chi phí không cần thiết. Thứ hai, việc duy trì danh sách theo cách thủ công là khó khăn. Khi số lượng nội trang tăng quá cao, việc bảo trì thủ công trở nên khó khăn và thực sự có thể cản trở quá trình chứng minh nội trang hiệu quả hỗ trợ một số lượng lớn sắc thái. Để giải quyết những vấn đề này, nhóm StarkWare đang phát triển một hệ thống bố cục động trong đó các bố cục được tùy chỉnh cho từng bằng chứng công việc.
Ngăn xếp Cairo hỗ trợ tính toán cho mục đích chung có thể chứng minh được bằng cách biên dịch mã Cairo thành hướng dẫn dành cho kiến trúc CPU thân thiện với STARK: Máy ảo Cairo (sau đây gọi là CVM). Nhiều ưu điểm của CPU đa năng có chi phí vốn có và CVM không được tối ưu hóa cho một số hoạt động phổ biến. Các hàm băm Keccak, Pedersen, Poseidon là các phép toán phổ biến như vậy, cũng như các phép toán đường cong elip, kiểm tra phạm vi (nghĩa là kiểm tra xem một số cụ thể có nằm trong một phạm vi giá trị cụ thể hay không) và các phép toán khác.
Để giải quyết tình trạng kém hiệu quả tương đối của CVM, ngăn xếp Cairo giới thiệu khái niệm tích hợp sẵn cho các hoạt động quan trọng: các plugin tối ưu hóa các hoạt động đó để chứng minh độ phức tạp. Các chức năng tích hợp có thể được so sánh với ASIC: ASIC là các mạch tích hợp dành riêng cho ứng dụng và các chức năng tích hợp sẵn là các ràng buộc đại số dành riêng cho ứng dụng (AIR). Nếu bạn không biết hoặc không nhớ AIR là gì, nó sẽ được đề cập ngắn gọn ở phần sau của bài viết này; hãy đọc bài viết này để biết thêm chi tiết.
Nói tóm lại, độ phức tạp của bằng chứng có liên quan (gần như tuyến tính) với các tài nguyên được gọi là đơn vị theo dõi và các chức năng tích hợp sẵn giúp đơn giản hóa bằng chứng về các hoạt động cụ thể bằng cách sử dụng ít đơn vị theo dõi hơn nhiều so với Cairo VM.
Giờ đây, khi các lợi ích của các hàm tích hợp đã được giải thích, bạn sẽ hiểu rõ tại sao các hàm tích hợp sẵn được phát triển cho nhiều hoạt động phổ biến. Nói thì dễ hơn là làm. Quy trình hiện tại để giới thiệu các tính năng tích hợp mới vào Starknet bao gồm các bước sau:
Viết KHÍ
Tích hợp với tục ngữ bằng cách tạo bố cục mới (mô tả bên dưới)
Tích hợp vào Starknet, tức là sửa đổi cơ sở mã và các công cụ dành cho nhà phát triển của nó để sử dụng các chức năng tích hợp mới
Ngoài những thách thức khi viết AIR, còn rất nhiều điều cần cải thiện trong hai giai đoạn còn lại. Bài viết nâng cao này sẽ mô tả chi tiết hơn các chức năng tích hợp của AIR như ứng dụng cụ thể, các vấn đề nêu trên và các kế hoạch trong tương lai.
Các chức năng tích hợp: AIR dành riêng cho ứng dụng
AIR là từ viết tắt của Biểu diễn trung gian đại số. Trong bài viết này và các bài viết khác của StarkWare, AIR là một hệ thống đa thức để biểu diễn các máy ảo. Ví dụ: Cairo lấy tên từ CPU AIR: một hệ thống đa thức đại diện cho một kiến trúc CPU cụ thể. Các giải pháp của hệ thống đa thức này đại diện cho các chuyển đổi trạng thái hiệu quả, được gọi là quỹ đạo thực hiện đại số hiệu quả (AET).
STARK chứng minh rằng hoạt động của máy ảo là chính xác bằng cách chứng minh quỹ đạo thực thi tương ứng với một AIR nhất định là hợp lệ. Nói một cách đại khái, quỹ đạo thực thi là một bảng số và giao thức STARK chứng minh rằng những con số này cùng nhau giải được một hệ đa thức.
Hoạt động tương tự có thể được tính theo nhiều cách, một số cách hiệu quả hơn. Trong bài báo này, độ phức tạp của bằng chứng về cơ bản phụ thuộc vào kích thước bản nhạc, tức là số lượng ô bản nhạc trong bảng. Vì các dấu vết được tạo cho AIR, AIR được thiết kế cho các ứng dụng để giảm đáng kể dấu vết thực thi cho các tính toán cụ thể. Các chức năng tích hợp là AIR chuyên dụng được tối ưu hóa cho ứng dụng.
Bảng dưới đây cho thấy các cải tiến hiệu quả cho các chức năng tích hợp cụ thể (tất cả đều được sản xuất).
Bố cục quỹ đạo: hiện tại và tương lai
Như đã đề cập trước đó, AET đại khái là một bảng số biểu thị trình tự các bước trong máy ảo được mã hóa (nghĩa là quá trình thực thi chương trình). Để tính toán bằng chứng, người quảng cáo chạy giao thức STARK trên đường thực thi của AIR liên quan.
Ở trên, chúng tôi đã giới thiệu các hàm tích hợp dưới dạng AIR dành riêng cho ứng dụng được thiết kế để giảm thiểu độ phức tạp của bằng chứng bằng cách giảm số lượng đơn vị theo dõi cần thiết để mã hóa tính toán. Tuy nhiên, nếu các chức năng tích hợp sẵn được tích hợp ngẫu nhiên trong Starknet, nhiều đơn vị quỹ đạo có thể bị lãng phí và lợi ích mong đợi sẽ giảm đi. Hãy giải thích chi tiết dưới đây.
Nói tóm lại, bố cục đường đua là việc gán các ô đường đua cho các "thành phần" khác nhau. Trong bài viết này, các thành phần này là CVM và các hàm tích hợp sẵn. Cụ thể, bố cục chỉ định số lượng ô theo dõi tương đối mà mỗi thành phần nhận được. (Các cấu trúc bố cục luôn được sử dụng để đơn giản hóa việc xác thực. Để tìm hiểu thêm, hãy đọc phần "Tính đơn giản" của bài đăng này).
Điểm mấu chốt là độ phức tạp của bằng chứng phụ thuộc vào tổng số ô theo dõi được phân bổ bởi bố cục và phân bổ ô theo dõi có thể lớn hơn mức thực sự cần thiết. Ví dụ: để minh họa thứ tự bước của CVM, bố cục chỉ gán các ô theo dõi cho các thành phần CVM hiệu quả gần gấp đôi so với bố cục chỉ định một nửa số ô theo dõi cho các hàm tích hợp Poseidon. Tóm lại, một bố cục phù hợp có thể làm giảm đáng kể độ phức tạp của việc chứng minh một tính toán cụ thể.
Hiện tại có một danh sách các bố cục được duy trì thủ công phát triển theo thời gian vì hai lý do chính:
Các chức năng tích hợp chỉ có thể được sử dụng cho bố cục của đơn vị rãnh được gán cho chúng. Do đó, việc thêm phần dựng sẵn yêu cầu ít nhất một bố cục mới.
Bố cục được điều chỉnh để thực thi mã Cairo tối ưu hóa việc phân bổ ô. Do đó, việc tối ưu hóa các trường hợp sử dụng trong ô thường yêu cầu bố cục mới.
Mã cho trình chứng minh và trình xác thực (trình xác thực Solidity và Cairo) được định cấu hình theo danh sách bố cục.
Khi các nội trang Keccak và Poseidon được thêm vào, việc giữ các danh sách bố cục đủ nhỏ để chứa nhiều nội trang và giữ cho hầu hết các khối Starknet thực thi hiệu quả ngày càng trở nên khó khăn. Hơn nữa, hiệu quả dự kiến sẽ giảm đáng kể khi các phần mềm tích hợp sẵn bổ sung được giới thiệu, do bố cục phải tính đến nhiều kết hợp và tỷ lệ có thể có giữa các phần mềm tích hợp sẵn.
Nhóm StarkWare hiện đang làm việc để cải thiện hệ thống bằng cách loại bỏ các danh sách bố cục được tạo sẵn để chuyển sang "bố cục động", là các tùy chỉnh tức thời cho mỗi lần thực thi mã Cairo. Bố cục động sẽ luôn thực hiện phân bổ theo tỷ lệ tốt nhất cho công việc xác minh hiện tại. Từ quan điểm kỹ thuật, việc hỗ trợ gõ động sẽ yêu cầu những thay đổi đáng kể đối với cơ sở mã. Tuy nhiên, nhóm StarkWare hy vọng sẽ đơn giản hóa lớp chứng minh của Starknet bằng cách tận dụng bố cục động, cải thiện việc sử dụng đơn vị theo dõi và sử dụng tốt hơn các trình chứng thực.
Với bố cục động, rắc rối của việc duy trì thủ công nhiều tiện ích tích hợp sẵn sẽ biến mất, đơn giản hóa quy trình tích hợp nhiều tiện ích tích hợp mới hơn vào Starknet.
Giao diện động và phí
Một mục đích của phí giao dịch là tính phí cho người dùng chi phí giao thức cận biên phát sinh từ các giao dịch. Vì đơn vị tính phí giao dịch là tiền tệ nên cơ chế tính phí liên quan đến việc chuyển đổi từ tài nguyên (ví dụ: bước máy ảo, chức năng tích hợp, calldata, Ethereum gas) sang mã thông báo (ví dụ: STRK, ETH).
Hiện tại, do người dùng tính phí dựa trên tổng dấu vết chứ không phải tỷ lệ sử dụng, tài nguyên lãng phí do người dùng gánh chịu. Bố cục động sẽ cải thiện việc sử dụng đơn vị theo dõi, do đó giảm việc tính phí giao dịch "không cần thiết" (bao gồm cả mức tiêu thụ tài nguyên không phải do giao dịch của người dùng gây ra trực tiếp).
Tích hợp chức năng tích hợp trong Starknet
Tại thời điểm này, việc tích hợp các chức năng tích hợp còn thiếu bước cuối cùng, đó là sửa đổi cơ sở mã Starknet để nhận ra việc sử dụng thực tế. Phạm vi sửa đổi mã có liên quan đến ứng dụng bố cục và cần phải sửa đổi mã để đảm bảo rằng hệ điều hành Starknet gọi các chức năng tích hợp sẵn khi có thể. Ví dụ: hệ điều hành Starknet gọi hàm băm Poseidon trong quá trình thực thi mã Cairo, đồng thời gọi hàm tích hợp Poseidon.
Tương tự như bố cục, các nội dung dựng sẵn của Starknet hiện có thể được hỗ trợ theo cách thủ công. Tuy nhiên, không giống như trường hợp bố trí, hỗ trợ thủ công này không phải là rào cản đối với việc tích hợp mặc dù có nhiều chức năng được tích hợp sẵn. Nói cách khác, hỗ trợ nội trang của Starknet không phải là rào cản đối với việc tích hợp, bố cục động sẽ thực sự mở đường cho việc tạo và tích hợp nội trang bổ sung.
Tóm tắt
Trong bài viết này, chúng tôi giải thích chức năng tích hợp sẵn là gì, lợi ích của chúng, những thách thức liên quan và kế hoạch của StarkWare. Trọng tâm hiện tại là bố cục động, điều này sẽ không chỉ cải thiện hiệu quả của quy trình kiểm chứng mà còn tạo điều kiện thuận lợi cho việc tích hợp các nội dung tích hợp mới.