TEE-as-Verifier cho các cầu nối kiểu BitVM: thu gọn mô hình chuẩn
vấn đề phân phối nhãn
Bối cảnh. Chúng tôi đang xây dựng Stax, một lớp L2 BTC với cầu nối kiểu BitVM. Cơ chế bảo vệ chỉ dựa trên sự mơ hồ đã được triển khai trên Signet từ lâu.
Ngày 23/04/2026, chúng tôi đang thiết kế hệ thống phòng thủ cố định cho Giai đoạn 3. Trong quá trình thiết kế, chúng tôi đã đi đến một khung kết luận như sau:
— nếu được kiểm chứng kỹ lưỡng — sẽ loại bỏ toàn bộ một nhóm các cơ chế on-chain (lá Taproot bị ép buộc tiết lộ, phản hồi Σ, nhãn).
(kênh phân phối). Chúng tôi muốn các chuyên gia mật mã xem xét bảy câu hỏi trong §6 trước khi chúng tôi cam kết.
Bài viết này tóm tắt vấn đề, sự thay đổi cách nhìn nhận và bảy câu hỏi mà chúng tôi muốn có ý kiến thứ hai. Tài liệu thiết kế đầy đủ có tại [đường dẫn].
Liên kết ở cuối bài.
- Vấn đề nằm trong mô hình cầu nối tiêu chuẩn của lớp BitVM.
Quy trình rút tiền tiêu chuẩn theo kiểu BitVM:
Nhà mạng công bố AssertTx, khẳng định trạng thái L2 tại thời điểm rút tiền, tiết lộ ảnh ngược Lamport từng bit một.
Bộ đếm thời gian CSV.
Trong khoảng thời gian cửa sổ CSV, các trạm theo dõi có thể phát hành DisprovalTx để cắt giảm tiền bảo đảm. Có hai loại tấn công cần lưu ý ở đây:
(a) Sự mơ hồ — nhà mạng phát hành hai AssertTx với Bits xung đột tại cùng một vị trí Lamport.
(b) Lời nói dối cố định — toán tử công bố một AssertTx có trạng thái được khai báo không khớp với lịch sử L2 chuẩn.
Sự lập lờ nước đôi rất đơn giản và đó chính là điều mà BitVM2 / Citrea / Bitlayer đang cung cấp hiện nay: bất kỳ hai thông tin trái chiều nào tại cùng một vị trí đều dẫn đến kết quả như nhau.
Tháp canh, cả hai đều là hình ảnh tiền định của Lamport, điều này làm đứt gãy mối liên kết.
Lỗi cố định (fixed-lie) vẫn là vấn đề chưa được giải quyết. Không có cầu nối kiểu BitVM nào được triển khai có đường dẫn bác bỏ on-chain cho lỗi này — giả định tiêu chuẩn là “nếu
"Người điều hành chỉ công bố một AssertTx duy nhất và đó là lời nói dối, các cơ chế Ngoài chuỗi (cảnh báo, mạng xã hội) sẽ xử lý nó". Bài đăng này nhằm mục đích chấm dứt điều đó.
khoảng trống. Luồng cặp khóa tại thời điểm gửi tiền đơn giản có
s_i^b = SHA256(“op-secret” || withdrawal_id || i || b)
Tức là, người vận hành tự tạo ra ảnh ngược Lamport của riêng họ. Họ biết cả hai ảnh ngược ở mỗi vị trí Bit . Do đó, họ có thể
Tạo một AssertTx tuyên bố bất kỳ mẫu Bit nào — đúng hoặc sai — và trình xác minh Script sẽ chấp nhận nó. Cơ chế on-chain không có gì để can thiệp.
Nguồn tham khảo độc lập về Bits chuẩn mực nên là gì.
Các tài liệu hiện có về việc ép buộc các lá (ví dụ: các lá phản hồi thách thức theo kiểu giao thức Σ ràng buộc toán tử với một đường truyền chuẩn công khai)
(bảng nhãn) đều giả định rằng các nhãn chuẩn đến từ một nguồn nào đó bên ngoài toán tử. Đề xuất tiêu chuẩn là một bên thứ ba.
Buổi lễ DKG hoặc thiết lập đáng tin cậy. Trong phân tích của chúng tôi, không có biến thể ép buộc on-chain mà chúng tôi đã kiểm tra (mở rộng khóa công khai, tách biệt) phù hợp.
RevealTx (phương pháp tìm ảnh ngược được điều khiển bằng CSV) thực sự giải quyết vấn đề mà không cần đến trình tạo nhãn bên ngoài đó. Chúng tôi đã ghi lại điều này trong một tài liệu.
Tài liệu thiết kế riêng biệt; xem §10.6 của forcing_mechanism_design.md.
Vậy câu hỏi đặt ra là: các nhãn chuẩn đến từ đâu và ai có thể nhìn thấy chúng?
2. Hai cách tiếp cận của TEE với vai trò là trình tạo nhãn.
Chúng tôi đã chọn TEE (AWS Nitro Enclaves làm nền tảng mặc định) thay vì một buổi lễ có nhiều bên tham gia vì lý do tính khả thi đối với nhóm làm việc độc lập. Một khi bạn
Nếu cam kết sử dụng TEE, sẽ có hai thiết kế API khả thi. Việc lựa chọn API sẽ quyết định toàn bộ dấu ấn on-chain .
2.1 TEE-như-bộ-ngắt-âm-thoại (khung lý thuyết ban đầu)
TEE.generate_circuit(vk) → (commitment_C, label_table T = {(L_i^0, L_i^1)})
TEE.attest() → AttestedCommitment(C, code_hash, public_seed, …)
Sau đó, các nhãn mác phải được chuyển đến một nơi nào đó — đến các tháp canh, để chúng có thể sử dụng các lá Taproot (lá rễ chính) để buộc phải lộ diện khi phát hiện ra sự nói dối.
AssertTx. Điều này đặt ra một vấn đề phụ khó khăn: làm thế nào để phân phối nhãn cho các trạm quan sát mà không làm rò rỉ chúng cho người vận hành? Trong một
Bộ tháp canh Không cần cho phép , bất cứ ai cũng có thể vận hành tháp canh, vì vậy bất cứ ai cũng có thể giữ các nhãn — kể cả người điều hành thông qua một chiếc tất.
Tháp canh bù nhìn. Chúng ta không có câu trả lời rõ ràng.
Trong TEE-as-Garbler, bạn cũng cần: các lá bắt buộc phải hiển thị trong cây Taproot, tạo phản hồi Σ trong chứng cứ AssertTx, watchtower
Mã tranh chấp tiêu tốn những chiếc lá đó, hệ thống đường ống dẫn tín hiệu và chính kênh phân phối nhãn. Đó là phần lớn của vấn đề.
forcing_mechanism_design.md Các mốc B và C.
2.2 TEE-như-một-công-tố-kiểm-thử (khung lý thuyết mà chúng tôi đề xuất)
TEE.generate_keypair_for_withdrawal(withdrawal_id)-> Khóa công khai Lamport (47 KB), chứng thực
TEE.release_preimages(withdrawal_id, claimed_state s, claimed_proof π)
→ { s_i^{bit_i(public_inputs(s))} } nếu Groth16Verify(vk, ., π) là HỢP LỆ
→ lỗi “INVALID” nếu không thì
TEE vừa là bộ mã hóa vừa là bộ xác minh. API duy nhất của nhà điều hành là "xác minh bằng chứng này và cung cấp cho tôi ảnh gốc của các đầu vào công khai của nó".
Điều quan trọng là:
TEE chỉ phát hành một ảnh ngược cho mỗi vị trí Bit — ảnh ngược khớp với giá trị Bit của các đầu vào công khai của trạng thái được yêu cầu.
TEE không bao giờ xuất ảnh ngược kia ở bất kỳ vị trí nào.
TEE không bao giờ xuất các tiền ảnh gắn liền với một trạng thái chưa bao giờ được khẳng định.
Cuộc tấn công bằng lời nói dối cố định được rút gọn thành: Đường dẫn Điều gì xảy ra A: Người vận hành gửi (state_lie, garbage_proof) TEE Groth16Verify → KHÔNG HỢP LỆ → từ chối → người vận hành không có ảnh ngược B: Người vận hành gửi (state_truthful, valid_proof) TEE trả về ảnh ngược đúng sự thật → AssertTx khẳng định tính đúng đắn, không có lời nói dối nào xảy ra C: Người vận hành làm giả bằng chứng Groth16 cho state_lie Rút gọn thành tính đúng đắn của Groth16 — cùng một giả định mà L2 đã tin tưởng
Lời nói dối không thể lan đến Bitcoin ngay từ đầu. Không có gì on-chain để bắt giữ và cắt đứt bằng cách ép buộc loại bỏ các lá cây.
2.3 Những gì sụp đổ trên chuỗi Thành phần TEE-as-Garbler TEE-as-Verifier Forced-reveal Taproot cần được loại bỏ AssertTx Σ-response cần được loại bỏ Watchtower forced-reveal disputer cần được loại bỏ Canonical-label distribution channel cần thiết (vấn đề chưa được giải quyết) đã được loại bỏ Beacon plumbing cho biến thể giao thức Σ của chúng ta cần được loại bỏ Equivocation Lamport không thay đổi không thay đổi Cơ sở hạ tầng chứng thực TEE cần thiết registerGarblerAttestation trên hợp đồng cầu nối cần thiết
Các trạm giám sát (Watchtower) hoạt động theo mô hình TEE-as-Verifier chỉ cần: khớp bản tóm tắt chứng thực TEE, phát hiện AssertTx, phát hiện sự mơ hồ (hiện có).
và một đường dẫn cảnh báo Ngoài chuỗi cho kịch bản thỏa hiệp TEE còn sót lại mà không có sự mơ hồ.
3. Tại sao chúng tôi cho rằng các lá cây bị ép buộc tiết lộ là tàn dư dưới mô hình TEE-as-Verifier
Ngay cả khi bạn giữ nguyên các lá tiết lộ bắt buộc từ thiết kế giao thức Σ ban đầu (theo phase3_tee_secrecy.md §3.1), trong TEE
Trong kịch bản không thỏa hiệp, không mơ hồ, tháp canh vẫn không thể sử dụng chúng. Script trên lá là...
OP_SHA256 <expected_hash[i]> OP_EQUALVERIFY OP_TRUE
Để chi tiêu, tháp canh cần ảnh ngược của expected_hash[i]. Trong mô hình TEE, ảnh ngược là nội bộ của TEE. Tháp canh
Tôi chưa từng có chúng. Lá bài này không thể được sử dụng bởi bất kỳ bên nào ngoại trừ TEE và bất kỳ ai mà TEE đã phát hành ảnh trước (người điều hành).
Kết quả tương tự như lý do trì hoãn được ghi trong forcing_mechanism_design.md §10.6, nhưng do bên khác thực hiện. Biện pháp phòng vệ-trong
Lý lẽ về độ sâu để giữ lại các lá không còn đúng vì tác nhân có ảnh ngược là cùng một tác nhân trong cả hai trường hợp (the
(người đã nộp hồ sơ cho TEE).
4. Tuyên bố về sự tin tưởng, một cách trung thực
Cầu nối Stax trong Giai đoạn 3 với các quỹ ủy thác mã hóa TEE-as-Verifier:
(a) Đa số trung thực của Bitcoin, (b) Celestia DA (việc giữ lại của nhà điều hành đã bị đóng từ ngày 22/04/2026), © ≥1 tháp canh trung thực cho
phát hiện sự mơ hồ, (d) độ tin cậy Groth16 cho biện pháp phòng thủ nói dối cố định, (e) chuỗi chứng thực của nhà cung cấp TEE (AWS Nitro bởi
mặc định; việc xác thực chéo nhiều nhà cung cấp được hoãn lại đến Giai đoạn 3.2c).
Giả định (e) yếu hơn hẳn so với nghi lễ N-of-N của BitVM2. Chúng tôi chấp nhận nó để đảm bảo tính khả thi của mạng chính do một nhóm duy nhất thực hiện, với sự rõ ràng
có ý định ngừng hoạt động nó sau khi triển khai mạng chính thức khi buổi lễ trở nên khả thi.
5. Phương án dự phòng phòng thủ nhiều lớp (nếu bạn phản đối điều khoản §3)
Nếu người đánh giá cho rằng "lỗi cố định trong quá trình xây dựng" không phải là lý do bào chữa thỏa đáng, thì phương án dự phòng là GIỮ LẠI các trang bị buộc phải tiết lộ VÀ phân phối chúng.
Các nhãn chuẩn được gửi đến các tháp canh thông qua một kênh phụ được chứng thực (mã hóa TEE bằng các khóa riêng cho từng tháp canh, được công bố qua Celestia DA).
Chi phí: ~85 KB khóa công khai, +phản hồi Σ trong chứng cứ AssertTx (~3-5 KB), thêm một lá Taproot cho mỗi vị trí thách thức cắt và chọn (được chọn cho độ chính xác mong muốn; c=64 đặt ≈1 trên 264 khả năng nói dối không bị phát hiện), bộ tranh luận giao thức Σ đầy đủ + phân phối nhãn
Việc triển khai kênh, cộng với một hệ thống đăng ký khóa của trạm canh gác.
Chúng tôi cho rằng điều này không thể kết hợp một cách mạch lạc vì "bất cứ ai cũng có thể điều hành một tháp canh" đồng nghĩa với "bất cứ ai cũng có thể giữ nhãn mác", điều này dẫn đến sự sụp đổ trở lại.
đến người điều hành thông qua tài khoản giả mạo có gắn nhãn — nhưng chúng tôi muốn phản đối sự từ chối này.
6. Những câu hỏi mở mà chúng ta cần ý kiến của các chuyên gia mật mã.
Đây là những trở ngại trước khi cam kết triển khai. Chúng tôi chưa bắt đầu viết mã Giai đoạn 3.2b ngoài cơ sở hạ tầng chứng thực.
(điều này đúng trong cả hai cách diễn đạt).
Câu 1 — Độ vững chắc Groth16 là biện pháp phòng thủ duy nhất cho các tình huống bóng chết cố định. Liệu việc giảm biện pháp phòng thủ bóng chết cố định theo TEE xuống còn “Độ vững chắc Groth16 + TEE” có hiệu quả không?
"Tính toàn vẹn của chứng thực" có thể chấp nhận được đối với một cầu nối mạng chính không? Cả Zcash Sapling và Filecoin đều dựa vào tính ổn định của Groth16 để hoạt động.
các triển khai có giá trị hàng tỷ đô la, và giả định này đã được chứng minh là đúng trong quá trình kiểm tra nghiêm ngặt. Chúng tôi không giới thiệu một cái mới
giả định mật mã — chúng tôi muốn điều này được xác nhận trong bối cảnh cầu nối, nơi khẳng định này là Bitcoin on-chain , chứ không phải on-chain.
Ethereum.
Q2 — Trạng thái TEE để ngăn ngừa sự mơ hồ. Liệu TEE có nên tự động theo dõi "Tôi đã phát hành các tiền ảnh cho..."
"rút tiền theo ID X với mẫu Bit P" và từ chối cấp mẫu thứ hai cho cùng một lần rút tiền? Nếu vậy, đây là hành vi ngăn chặn
sự lập lờ thay vì phát hiện, và sự lập lờ mà Lamport để lại có thể bị bác bỏ hoàn toàn — thu gọn Giai đoạn 3 thành “TEE”
chứng thực, không có gì khác”. Chi phí: TEE phải duy trì trạng thái bền vững (Nitro KMS hoặc AMD SEV-SNP tương đương). Điều kiện cạnh tranh trên nhiều
Cần xử lý các trường hợp TEE (xem Câu hỏi 4).
Câu 3 — Mã hóa kênh truyền từ TEE đến nhà mạng. Khi TEE trả về ảnh ngược, kênh truyền đến nhà mạng phải được mã hóa.
(nếu không, kẻ nghe trộm thụ động sẽ có khả năng công bố AssertTx). Câu trả lời tiêu chuẩn: TLS được chứng thực bởi vùng bảo mật — cặp khóa tạm thời
Được tạo bên trong vùng bảo mật, tài liệu chứng thực liên kết khóa công khai TLS với code_hash, nhà điều hành xác thực chứng thực đó.
trước khi gửi bằng chứng. Có những điểm tinh tế nào đặc thù trong ngữ cảnh BitVM mà chúng ta đang bỏ sót không — ví dụ như việc phát lại phiên giữa các lần khởi động lại TEE,
Xoay khóa trong quá trình nâng cấp TEE, một người vận hành nói dối về việc phiên nào đã nhận được ảnh trước nào?
Q4 — Sao chép TEE để Liveness. Một TEE duy nhất là điểm lỗi duy nhất (SPOF) đối với Liveness của cầu nối. Nhiều phiên bản TEE (cùng code_hash, cùng...)
(master_seed) cần một giao thức phối hợp để chúng không giải phóng các tiền ảnh cho các trạng thái xung đột. Liệu "master seed xác định" có phải là
Trên N TEE + nhật ký trạng thái trên mỗi phiên bản + "lấy phản hồi đầu tiên" có an toàn không, hay nó tạo ra một lỗ hổng mà kẻ tấn công có thể khai thác? Cụ thể: nếu
Trường hợp A giải phóng ảnh ngược của trạng thái P tại thời điểm t, và trường hợp B giải phóng ảnh ngược của trạng thái P' (P' ≠ P) tại thời điểm t+ε trước trạng thái của A.
Nhật ký sao chép, liệu người vận hành có vừa nhận được cả hai nửa dữ liệu ở một số vị trí Bit định không?
Q5 — Nâng cấp TEE với các khoản tiền gửi đang hoạt động. Nếu chúng tôi phát hành một tệp nhị phân mã hóa mới (mã băm khác), các khoản tiền gửi hiện có sẽ được cam kết.
Khóa công khai cũ sẽ bị kẹt trừ khi (a) tệp nhị phân TEE cũ vẫn hoạt động được vô thời hạn, hoặc (b) chúng tôi cung cấp một lộ trình chuyển đổi.
(ví dụ: luồng hoàn tiền hợp tác, sau đó gửi lại tiền dưới mã băm mới). Mô hình tiêu chuẩn trong thiết kế cầu sử dụng TEE là gì? (a)
Có thể chấp nhận được với thời hạn gửi tiền từ 6-12 tháng không? (b) có cơ chế hoạt động rõ ràng hơn so với “cửa sổ chuyển đổi do chủ sở hữu kích hoạt” không?
Q6 — Chu kỳ xác thực từng lần rút tiền so với chu kỳ xác thực theo lô. Bản tóm tắt xác thực on-chain (code_hash, public_seed,
(output_hash). Nếu output_hash là cam kết khóa công khai cho MỘT lần rút tiền, thì mỗi lần rút tiền cần có bản tóm tắt on-chain riêng.
Đăng ký — việc này sẽ tốn kém khi thực hiện trên quy mô lớn. Đăng ký theo lô sẽ tổng hợp dữ liệu nhưng mất đi một số chi tiết. Đăng ký theo kỷ nguyên là phương án rẻ nhất nhưng lại làm tăng chi phí.
Các câu hỏi về việc khoản rút tiền nào thuộc loại giấy tờ xác nhận nào. Độ chi tiết phù hợp ở đây là bao nhiêu, và đâu là phương thức thất bại của nó?
Có phải bạn đang làm sai?
Câu 7 — Liệu những chiếc lá bị ép buộc phải lộ ra có bao giờ hữu ích không? Mục 3 của bài viết này lập luận rằng không, bởi vì các tháp canh có nhãn mác nghĩa là
Người điều hành thông qua con rối giả mạo sở hữu các nhãn (trong một tập hợp tháp canh Không cần cho phép ). Nếu bạn có thể xây dựng một mô hình mối đe dọa trong đó bị ép buộc
Việc tiết lộ thông tin về các lá cây cung cấp khả năng phòng thủ nhiều lớp đáng kể mà cảnh báo Ngoài chuỗi và việc thu hồi chứng thực không thể làm được, chúng tôi muốn được nghe ý kiến đó — rằng
sẽ đẩy chúng ta vào tình huống bất khả kháng theo Điều 5.
7. Điều chúng tôi đang yêu cầu
Không phải là một cuộc kiểm toán toàn diện (đó là khoản chi tiêu cấp 4 sau này). Hiện tại chúng tôi muốn:
Kiểm tra thực tế câu hỏi 1 — liệu tuyên bố về sự tin tưởng trong §4 có trung thực hay chúng ta đang cố tình bỏ qua điều gì đó?
Ý kiến thứ hai về câu hỏi 2 — liệu trạng thái TEE có thực sự bao hàm việc phát hiện sự mơ hồ hay không, hay trường hợp ngoại lệ của TEE
Tham nhũng nhà nước / đảo ngược chính sách, mở lại cánh cửa?
Bất kỳ ai có kinh nghiệm thực tế với AWS Nitro Enclaves cho Q4/Q5 — những vấn đề nào phát sinh trong quá trình vận hành mà không được thể hiện trong giai đoạn thiết kế.
Tài liệu?
Nếu tất cả các câu trả lời đều nhất trí "ổn rồi", chúng ta sẽ phát hành Giai đoạn 3.2b trong khoảng 1 tuần. Nếu họ trả lời với một trong những câu hỏi sau...
Khi phát hiện ra một lỗ hổng, chúng ta sẽ thực hiện phương án dự phòng theo Điều 5 hoặc thiết kế lại kiến trúc.
8. Liên kết
Tài liệu thiết kế đầy đủ mà bài đăng này tóm tắt: docs/phase3_tee_secrecy.md (~530 dòng)
Liên quan: docs/phase3_tee_design.md (Lựa chọn nền tảng TEE, mô hình mối đe dọa)
Bài toán gốc: docs/forcing_mechanism_design.md §10.6
Bridge hoạt động trên Bitcoin signet (đã hoạt động từ ngày 22/04/2026). TESTNET.md ghi lại luồng giao dịch gây hiểu nhầm + DisprovalTx, Celestia.
Từ chối chế độ nghiêm ngặt DA và gửi/ Mint trung thực, với mã băm giao dịch chữ ký cụ thể cho mỗi giao dịch.
Mọi ý kiến đóng góp và tin nhắn riêng đều được hoan nghênh. Chủ đề trên Ethresearch là nơi thích hợp nhất để trả lời các câu hỏi kỹ thuật; chúng tôi sẽ phản hồi lại những ý kiến mang tính chuyên môn.
vào tài liệu kèm theo ghi nguồn
