Tài khoản thông minh được mã hóa Mempool
Được viết bởi Marc Harvey-Hill @ Nethermind . Xin chân thành cảm ơn phản hồi từ Ahmad Bitar , Aikaterini-Panagiota Stouka , Stefano De Angelis , Conor McMenamin , Lin Oshitani và Julie Bettens . Phản hồi không nhất thiết là sự xác nhận.
Bài đăng này khám phá khái niệm sử dụng tài khoản thông minh để xác thực rằng các quy tắc mempool được mã hóa được tuân thủ. Điều này có thể tăng cường bảo đảm bảo vệ tiên phong và khả năng chống kiểm duyệt cho các trường hợp người đề xuất Block cố gắng vi phạm các quy tắc mempool được mã hóa.
Trong một mempool được mã hóa, người dùng gửi các giao dịch được mã hóa được đăng trên chuỗi trong một ràng buộc công khai. Đây là một ràng buộc đối với người đề xuất tiếp theo để bao gồm các giao dịch này theo thứ tự được xác định trước (chẳng hạn như được sắp xếp theo phí ưu tiên). Ngay trước khe tiếp theo, các khóa giải mã được tiết lộ để người đề xuất có thể giải mã và bao gồm các giao dịch từ ràng buộc công khai. Họ nên bao gồm tất cả các giao dịch hợp lệ nằm trong ràng buộc ở đầu Block của họ theo thứ tự được xác định trước, không chèn bất kỳ giao dịch nào trước đó có thể chạy trước các giao dịch đã giải mã. Chúng tôi quan tâm đến việc thực thi rằng những người đề xuất tuân theo các quy tắc này.
Tài khoản thông minh có thể được sử dụng để ngăn chặn việc chạy trước của người đề xuất có ác ý. Thay vì mã hóa các giao dịch thông thường, người dùng có thể mã hóa các giao dịch tài khoản thông minh Yêu cầu bình luận Ethereum (ERC)-4337 (UserOps) thực hiện kiểm tra xem chúng đã được đưa vào đúng thứ tự tại đúng chỉ mục trong Block (tức là ở đầu). Nếu kiểm tra không thành công thì phần chính của UserOp (ví dụ hoán đổi) sẽ không chạy, do đó không thể chạy trước được.
Chúng cũng có thể cung cấp khả năng bảo vệ nếu người đề xuất không có ác ý nhưng ngoại tuyến. Trong những trường hợp này, khóa giải mã vẫn sẽ được tiết lộ, vì vậy bây giờ mọi người đều có thể thấy các giao dịch đã giải mã. Điều này có nghĩa là người đề xuất tiếp theo có thể bao gồm các giao dịch đã giải mã này và chèn các giao dịch chạy trước của riêng họ trước. Một lần nữa, các tài khoản thông minh có thể cung cấp khả năng bảo vệ; như một phần của các kiểm tra được thực hiện khi bắt đầu UserOp, chúng ta có thể xác minh rằng UserOp đang được thực thi trong khe mà nó được dự định. Nếu kiểm tra không thành công thì phần thân của UserOp sẽ không chạy, vì vậy cuộc tấn công không còn khả thi nữa.
Để có các đặc tính chính của chúng, khả năng bảo vệ tiên phong và khả năng chống kiểm duyệt, các mempool được mã hóa phải thực thi hai quy tắc tương ứng: sắp xếp và bao gồm. Như đã nêu, các tài khoản thông minh có thể được sử dụng để thực thi việc sắp xếp, nghĩa là các giao dịch phải được thực hiện trong đúng vị trí, theo đúng thứ tự, tại đúng chỉ mục trong Block (đầu Block). Chúng tôi cũng sẽ khám phá cách bao gồm có thể được thực thi thông qua một trò chơi chống gian lận, nghĩa là nếu người đề xuất không bao gồm các giao dịch nằm trong ràng buộc công khai, họ sẽ mất phần thưởng và có khả năng bị cắt giảm.
Mempool được mã hóa bằng tài khoản thông minh có một số lợi ích:
- Bảo vệ chạy trước vô điều kiện: Người đề xuất không thể chạy trước các giao dịch trong bất kỳ trường hợp nào. Ngay cả khi chúng ngoại tuyến và các giao dịch được giải mã bị rò rỉ, người đề xuất trong tương lai không thể bao gồm và chạy trước chúng vì nội dung chính của giao dịch sẽ không được thực hiện trong các khe trong tương lai.
- An toàn khi tổ chức lại: Trong trường hợp tổ chức lại, vẫn không thể chạy trước.
- Sự liên kết khuyến khích: Người đề xuất sẽ bỏ lỡ tất cả các mẹo nếu họ kiểm duyệt bất kỳ giao dịch mempool được mã hóa nào.
Lý lịch
Để biết thêm thông tin, tôi muốn giới thiệu bài nói chuyện dài 5 phút của tôi về không gian thiết kế của mempool được mã hóa.
Tóm lại:
- Người dùng mã hóa giao dịch của họ.
- Các giao dịch được mã hóa được đăng trên chuỗi trong một ràng buộc công khai. Người đề xuất cho vị trí tiếp theo nên bao gồm tất cả các giao dịch này theo thứ tự được xác định trước ở đầu Block của họ.
- Ngay trước khi bắt đầu khe tiếp theo, các 'người mở khóa' sẽ tiết lộ khóa giải mã.
- Nếu người đề xuất trực tuyến, họ sẽ xây dựng Block của mình. Tài khoản thông minh và trò chơi chống gian lận có thể được sử dụng để đảm bảo người đề xuất tuân thủ các quy tắc, tôn trọng ràng buộc công khai.
Thiết kế này tập trung vào điểm 4: cách thực thi để tất cả các giao dịch từ ràng buộc được đưa vào đúng thứ tự. Chúng ta sẽ khám phá phương pháp tiếp cận tài khoản thông minh giúp giảm thiểu vấn đề của những người đề xuất độc hại và ngoại tuyến bằng cách thực thi các quy tắc sắp xếp và bao gồm.
Có những khía cạnh quan trọng khác của thiết kế như cơ chế mã hóa, bản chất của người khóa, nơi đăng ràng buộc công khai chính xác; tôi sẽ không đề cập đến những điều này trong bài đăng này.
Phân loại Mempool được mã hóa
Chúng ta có thể phân loại các thiết kế mempool được mã hóa theo mức độ thực thi chặt chẽ các quy tắc sắp xếp và bao gồm đối với người đề xuất.
Giai đoạn 0 - Tin cậy
- Người đề xuất hoàn toàn đáng tin cậy.
- Việc sắp xếp và đưa vào không được thực thi, do đó có thể chạy trước và kiểm duyệt mà không bị hậu quả.
Giai đoạn 1 - Staking
- Người đề xuất có Stake có thể bị cắt giảm. Họ có thể đưa ra cam kết của người đề xuất.
- Nếu người đề xuất sắp xếp lại hoặc kiểm duyệt, Stake của họ có thể bị cắt giảm. Yêu cầu đăng bằng chứng về việc người đề xuất vi phạm quy tắc.
- Lệnh chỉ được thực hiện có hiệu lực hồi tố nên vẫn có thể chạy trước. Có thể xảy ra nếu tiền thưởng vượt quá Stake.
- Thay vì Slashing, Stake có thể được dùng để bồi thường cho người dùng.
- Vấn đề: phải cắt bỏ người đề xuất ngoại tuyến cho phép các giao dịch được giải mã bị rò rỉ, ngay cả khi họ không nhận được khóa kịp thời.
- Mempool giai đoạn 1 được khám phá trong Sách trắng này . Nó sử dụng cam kết Slashing và đề xuất.
Giai đoạn 2 - Tài khoản thông minh
- Đặt hàng được thực hiện bằng tài khoản thông minh.
- Người đề xuất chứng minh lệnh được sắp xếp đúng trên chuỗi trước khi thực hiện.
- Không thể chạy trước, nội dung UserOp sẽ không thực thi nếu thứ tự không chính xác.
- Người đề xuất sẽ mất tất cả phần thưởng mempool được mã hóa nếu không đáp ứng được việc bao gồm. Cũng có thể bị cắt giảm như trong giai đoạn 1.
Giai đoạn 3 - Được tôn thờ
- Được thực thi bởi các điều kiện hợp lệ Block .
- Người đề xuất không thể xây dựng một Block hợp lệ nếu thứ tự và tính bao gồm không được thỏa mãn; điều này có nghĩa là họ sẽ bỏ lỡ phần thưởng Block .
- Sẽ phải được ghi vào giao thức thông qua một Hard fork.
- Sẽ mất nhiều thời gian hơn để phối hợp thiết kế phù hợp cho việc thờ cúng.
Giai đoạn 2 có lợi thế hơn giai đoạn 1 là bảo vệ chạy trước vô điều kiện. Với giai đoạn 1, chạy trước vẫn có thể thực hiện được vì nó chỉ bị phạt sau khi thực tế xảy ra; điều này có thể xảy ra nếu giá trị thu được vượt quá tổn thất từ Slashing. Điều này cũng có thể xảy ra trong trường hợp người đề xuất chỉ cần ngoại tuyến và các giao dịch được giải mã từ vị trí của họ bị rò rỉ. Với giai đoạn 1, người đề xuất có thể bị cắt giảm vì điều này (điều này có thể không công bằng nếu họ không nhận được khóa giải mã kịp thời), trong khi với giai đoạn 2 thì đây không phải là vấn đề vì các giao dịch bị rò rỉ không thể được thực hiện bên ngoài vị trí dự định của chúng.
Cuối cùng, giai đoạn 3 sẽ cung cấp sự đảm bảo an ninh mạnh mẽ nhất trong dài hạn, nhưng thực tế sẽ mất nhiều thời gian để đạt được Consensus về một thiết kế phù hợp để đưa vào giao thức. Đối với giai đoạn Short đến Trung bình , giai đoạn 2 sẽ cung cấp đủ khả năng bảo vệ.
Các cơ chế thực thi khác nhau của các giai đoạn khác nhau của mempool được mã hóa được tóm tắt trong bảng sau:
| Sân khấu | Đặt hàng | Bao gồm |
|---|---|---|
| 0 | Không có | Không có |
| 1 | Slashing | Slashing |
| 2 | Tài khoản thông minh | Slashing |
| 3 | Consensus | Consensus |
Lưu ý rằng giai đoạn của mempool được mã hóa không phải là yếu tố duy nhất quyết định mức độ bảo mật, điều này còn phụ thuộc vào các khía cạnh khác như cơ chế khóa.
Thiết kế
Tôi sẽ trình bày một thiết kế thực thi các quy tắc sắp xếp và bao gồm đối với những người đề xuất sử dụng tài khoản thông minh và trò chơi chống gian lận. Chúng ta sẽ bắt đầu với tổng quan cấp cao về cách thức hoạt động của nó trước khi khám phá các chi tiết:
- Người dùng tạo và mã hóa UserOps. Các UserOps này chỉ định vị trí nào chúng sẽ được thực thi (tức là vị trí tiếp theo).
- UserOps được mã hóa được đưa vào chuỗi theo ràng buộc công khai.
- Khi bắt đầu khe tiếp theo, các khóa giải mã được phát sóng và người đề xuất giải mã UserOps cho khe của họ. Họ bắt đầu xây dựng Block của họ (họ có thể sử dụng MEV-boost, điều này được thảo luận trong phần PBS ).
- Người đề xuất tạo ra một “tuyên bố sắp xếp”. Tuyên bố này là người đề xuất tuyên bố những giao dịch nào nằm trong ràng buộc công khai và cách chúng nên được sắp xếp theo các quy tắc của mempool. Họ cũng có thể tuyên bố rằng một số UserOps được giải mã là không hợp lệ và không bao gồm chúng.
- Người đề xuất gom tất cả các UserOps đã giải mã (hợp lệ) lại với nhau thành một giao dịch Yêu cầu bình luận Ethereum (ERC)-4337 duy nhất. Khai báo thứ tự phải được chuyển vào giao dịch này dưới dạng calldata.
- Người đề xuất nên đưa giao dịch được đóng gói này vào đầu Block của họ.
- Kiểm tra xác thực được thực hiện trên chuỗi như một phần của giao dịch được đóng gói này. Tuyên bố thứ tự có thể được xác minh để đáp ứng ràng buộc công khai và sau đó mỗi UserOp có thể được xác minh để tuân theo tuyên bố thứ tự.
- Nếu kiểm tra thành công thì các phần UserOp sẽ được thực thi, nếu không thì chúng sẽ dừng lại sau khi kiểm tra hoàn tất và phần chính sẽ không được thực thi.
- Người đề xuất có thể đã tuyên bố sai rằng một số giao dịch hợp lệ là không hợp lệ; đây là nơi trò chơi chống gian lận được sử dụng. Các mẹo giao dịch bị khóa trong một thời gian thử thách trong đó bất kỳ ai cũng có thể cung cấp bằng chứng cho thấy người đề xuất đã nói dối về một giao dịch nào đó là không hợp lệ. Sau đó, người đề xuất sẽ không thể nhận được phần thưởng của mình và có thể bị cắt giảm.
Luồng được minh họa trong hình này:
Bây giờ chúng ta sẽ xem xét một ví dụ để thấy thiết kế này hoạt động như thế nào trong thực tế, trước khi khám phá chi tiết hơn các phần khác nhau của quy trình.
Ví dụ
Ba người dùng có UserOps mà họ muốn thực hiện thông qua mempool được mã hóa. Các UserOps này có các giá trị băm 0xa, 0xb, 0xc. Người dùng mã hóa UserOps của họ và gửi chúng đến mempool được mã hóa.
UserOps được mã hóa được bao gồm trong một ràng buộc công khai được đăng trên chuỗi trong blob hoặc calldata. Cùng với văn bản mã hóa, các hàm băm của UserOps cơ bản được tiết lộ, cũng như bằng chứng cho thấy các hàm băm này là của UserOps dạng văn bản thuần túy.
Trước khi bắt đầu khe tiếp theo, người giải mã sẽ tiết lộ khóa giải mã cho UserOps; người đề xuất bây giờ phải xây dựng một khai báo thứ tự.
Trong ví dụ này, mempool được mã hóa sắp xếp theo phí ưu tiên. Người đề xuất cung cấp bằng chứng về phí ưu tiên cho mỗi UserOp và sắp xếp chúng theo đó. Người đề xuất cũng tuyên bố rằng UserOp có Hash 0xa không hợp lệ so với trạng thái trước. Bây giờ, người đề xuất phải xây dựng Block của họ.
Người đề xuất đã đóng gói UserOps hợp lệ thành một giao dịch duy nhất mà họ đã bao gồm ở đầu Block. Trong giao dịch này, khai báo thứ tự được xác minh trước. Tiếp theo, UserOps hợp lệ 0xb và 0xc được thực hiện theo đúng thứ tự. Đối với mỗi giao dịch này, các kiểm tra xác thực được thực hiện trước khi phần thân chính được thực hiện.
Vì người đề xuất tuyên bố rằng UserOp với Hash 0xa là không hợp lệ nên họ không đưa nó vào. Tuy nhiên, bây giờ bất kỳ ai cũng có thể gửi bằng chứng chứng minh rằng 0xa thực sự hợp lệ và yêu cầu tiền boa của người đề xuất cho vị trí này.
Tuyên bố đặt hàng
Sau khi giải mã UserOps, người đề xuất trước tiên phải đăng "tuyên bố sắp xếp" trong calldata. Đây là danh sách các hàm băm UserOp mà người đề xuất đang tuyên bố là thứ tự đúng. Sau khi danh sách này được chứng minh là đúng theo ràng buộc công khai, thì mỗi UserOp có thể sử dụng danh sách này để kiểm tra xem nó đã được đưa vào đúng thứ tự chưa.
Tuyên bố đặt hàng phải:
(1) Tôn trọng các quy tắc sắp xếp của mempool, ví dụ: sắp xếp theo phí ưu tiên hoặc FCFS.
(2) Không chứa bất kỳ UserOps nào không có trong ràng buộc ban đầu.
(3) Khai báo UserOps nào từ ràng buộc là không hợp lệ so với trạng thái trước.
Chúng ta có thể xác minh (2) ngay lập tức bằng cách so sánh khai báo với ràng buộc công khai đã được đăng trong blobs hoặc calldata; người đề xuất có thể chứng minh nội dung của ràng buộc đối với cam kết KZG của blob. Ràng buộc công khai phải phơi bày các băm của UserOps (người dùng có thể chứng minh Hash khi họ gửi); sau đó, các băm này có thể được so sánh với khai báo sắp xếp để đảm bảo không có băm nào hiện diện mà không được bao gồm trong ràng buộc ban đầu.
Chúng ta cũng có thể xác minh (1) ngay lập tức bằng cách so sánh khai báo sắp xếp với danh sách Hash từ ràng buộc công khai. Trong trường hợp FCFS, các danh sách phải giống hệt nhau. Với việc sắp xếp phí ưu tiên, người đề xuất phải cung cấp bằng chứng bổ sung về phí ưu tiên cho mỗi UserOp.
Tuyên bố (3) cho phép người đề xuất tuyên bố rằng một số UserOps không hợp lệ nên không cần phải đưa vào. Sẽ rất tốn kém để chứng minh điều này ngay từ đầu để có thể xác minh sau trong trò chơi chống gian lận. Chúng tôi sẽ trình bày thêm về điều này trong phần đưa vào .
Sau khi (1) và (2) được chứng minh trên chuỗi, khai báo thứ tự hiện có thể được sử dụng trong các kiểm tra thứ tự UserOp.
Đặt hàng
Trước khi phần thân của UserOp được thực thi, phải tiến hành kiểm tra để xác minh rằng:
- UserOp đang được thực thi ở đúng vị trí, khớp với khai báo thứ tự.
- Khe hiện tại khớp với khe được bao gồm trong UserOp. Điều này có thể được kiểm tra bằng biên dịch trước SLOT.
- Giao dịch được đóng gói được thực hiện ở đầu Block. Điều này có thể được kiểm tra bằng biên dịch trước TXINDEX.
- Không có UserOp nào trước đó không vượt qua được kiểm tra xác thực.
Chỉ sau khi những điều này được xác minh thì phần thân chính của UserOp mới được thực hiện. Nếu bất kỳ kiểm tra nào không thành công thì phần thân UserOp và phần thân của UserOps tiếp theo không thể được thực hiện; người đề xuất sẽ không thể yêu cầu bất kỳ phần thưởng nào và chúng có thể bị cắt giảm.
Bao gồm
Một trò chơi chống gian lận được sử dụng để xác minh rằng người đề xuất không kiểm duyệt bất kỳ giao dịch nào từ ràng buộc công khai là hợp lệ. Mẹo của người đề xuất được tích lũy trong hợp đồng thông minh và được giữ trong một thời gian thử thách. Trong thời gian này, bất kỳ ai cũng có thể gửi bằng chứng zk rằng UserOp mà người đề xuất tuyên bố là không hợp lệ thực sự hợp lệ đối với trạng thái trước. Bất kỳ ai gửi bằng chứng này đều có thể yêu cầu mẹo của người đề xuất từ vị trí đó và người đề xuất cũng có thể bị cắt giảm. Một số phần trăm phần thưởng có thể bị đốt cháy để ngăn cản người đề xuất tự gửi bằng chứng gian lận (nếu không có Slashing). Nếu không có thách thức nào được gửi trong thời gian thử thách thì người đề xuất có thể yêu cầu tất cả các mẹo.
Một thiết kế thay thế có thể thực thi rằng người đề xuất cung cấp bằng chứng về các giao dịch không hợp lệ ngay từ đầu. Vì việc tạo ra các bằng chứng này sẽ tốn kém nên điều này có thể dẫn đến các cuộc tấn công phá hoại đối với người đề xuất, vì vậy tôi đề xuất trò chơi chống gian lận thay thế.
Những cân nhắc
Phụ thuộc
Đề xuất này phụ thuộc vào Đề xuất cải tiến Ethereum (EIP)-7793 , TXINDEX biên dịch trước; không yêu cầu thay đổi mức độ Consensus nào khác. Cần phải có chỉ mục giao dịch để kiểm tra xem giao dịch được đóng gói có được thực hiện ở đầu Block hay không.
Đề xuất cải tiến Ethereum (EIP)-7843 , biên dịch trước SLOT, là một phụ thuộc mềm. Với biên dịch trước này, chúng ta có thể xác minh rằng khe hiện tại khớp với khe được chỉ định trong UserOp. Đây không phải là một phụ thuộc nghiêm ngặt vì UserOp có thể chứa dấu thời gian được kiểm tra theo mã lệnh TIMESTAMP. Cách tiếp cận này hiệu quả nhưng ít khả thi trong tương lai vì nó cần được cập nhật trong trường hợp độ dài khe thay đổi.
Tài khoản thông minh mô-đun Yêu cầu bình luận Ethereum (ERC)-6900 có thể được ưa chuộng hơn tài khoản Yêu cầu bình luận Ethereum (ERC)-4337 tiêu chuẩn. Những tài khoản này hỗ trợ việc triển khai các hook trước khi thực hiện có thể được sử dụng để chạy kiểm tra trước khi thân UserOp chính được thực thi.
An toàn tổ chức lại
Để đảm bảo an toàn khi tổ chức lại, UserOps đã giải mã phải được thực thi trong khe ngay sau khe mà ràng buộc công khai được đăng. Để hiểu điều này, hãy xem xét điều gì có thể xảy ra nếu chúng ta đăng một ràng buộc trên chuỗi trong khe x và bao gồm UserOps đã giải mã trong khe x+2. Kẻ tấn công có thể đợi cho đến khi UserOps được giải mã trong khe x+2, sau đó tổ chức lại chuỗi để bao gồm một Block tại khe x+1 chứa các giao dịch chạy trước.
Yêu cầu này có thể được loại bỏ khi Tính chất cuối cùng khe cắm đơn được triển khai.
Ý định rò rỉ
Hãy tưởng tượng một người dùng đang thực hiện một hoán đổi lớn từ Token X sang Y thông qua mempool được mã hóa. Người đề xuất cho slot đang ngoại tuyến nên UserOp đã giải mã được tiết lộ cho mọi người. Như đã thảo luận, swap không thể được đưa vào một slot trong tương lai nơi nó có thể được chạy trước, vì phần thân của UserOp sẽ không thực thi trong các slot trong tương lai. Tuy nhiên, ý định thực hiện swap của người dùng đã bị rò rỉ, vì vậy người khác có thể mua Token Y để dự đoán người dùng sẽ gửi lại swap của họ, về cơ bản là chạy trước người dùng.
Không rõ liệu cuộc tấn công này có thể được thực hiện một cách đáng tin cậy hay không. Có thể giao dịch bị rò rỉ một cách cố ý nhằm mục đích thao túng thị trường và tăng giá Token Y chẳng hạn.
Trong một số trường hợp, đây có thể là vấn đề lớn hơn, ví dụ nếu mempool được mã hóa được sử dụng để gửi giao dịch đăng ký tên ENS . Mặc dù về mặt kỹ thuật, giao dịch không thể chạy trước, nhưng việc rò rỉ ý định đăng ký tên có thể không phải là rủi ro có thể chấp nhận được.
Băm hoặc cam kết
Để đơn giản, tôi đề xuất rằng ràng buộc công khai nên tiết lộ các hàm băm của UserOps dạng plaintext để chúng có thể được so sánh trên chuỗi với khai báo thứ tự. Cách tiếp cận này sẽ làm suy yếu tính bảo mật của cơ chế mã hóa, vì Hash là xác định, điều này sẽ khiến lược đồ mã hóa không an toàn trước một cuộc tấn công plaintext đã chọn.
Thay vì Hash, chúng ta có thể sử dụng một cam kết sẽ không làm rò rỉ thông tin về văn bản thuần túy. Có thể sử dụng các kỹ thuật từ Lee và cộng sự, 2019 và Campanelli và cộng sự, 2019 kết hợp các lược đồ mã hóa với các cam kết.
Hỗ trợ EOA
Với Đề xuất cải tiến Ethereum (EIP)-7702, chức năng tương tự có thể được đưa tới EOA bằng cách triển khai mã Yêu cầu bình luận Ethereum (ERC)-6900 tới địa chỉ của họ.
Tách biệt nhà thầu xây dựng
Cho đến nay, chúng tôi đã giả định rằng người đề xuất sẽ xây dựng Block bộ, nhưng thiết kế vẫn có thể hoạt động với MEV-boost hoặc ePBS . Người đề xuất có thể xây dựng giao dịch được đóng gói như bình thường và yêu cầu trình xây dựng bao gồm ở đầu Block thông qua API ràng buộc .
Phần kết luận
Tôi đã phác thảo một thiết kế cho một cơ chế thực thi Không cần tin cậy tối đa cho các mempool được mã hóa, yêu cầu thay đổi mức độ đồng thuận tối thiểu. Điều này cung cấp sự đảm bảo mạnh mẽ chống lại việc chạy trước và kiểm duyệt. Các bài đăng trong tương lai sẽ khám phá chi tiết hơn các phần khác của thiết kế như ràng buộc công khai.
