Bitlayer: BitVM và những suy nghĩ tối ưu hóa của nó

Tác giả: lynndell, mutourend; Nguồn: Nhóm nghiên cứu Bitlayer

1. Giới thiệu

Bitcoin là tài sản kỹ thuật số phi tập trung, an toàn và đáng tin cậy. Tuy nhiên, nó có những hạn chế đáng kể khiến nó không thể trở thành một mạng có thể mở rộng cho các khoản thanh toán và các ứng dụng khác. Vấn đề mở rộng quy mô của Bitcoin đã là mối lo ngại kể từ khi thành lập. Mô hình Bitcoin UTXO coi mỗi giao dịch là một sự kiện độc lập, dẫn đến một hệ thống không trạng thái thiếu khả năng thực hiện các phép tính phức tạp, phụ thuộc vào trạng thái. Do đó, mặc dù Bitcoin có thể thực hiện các tập lệnh đơn giản và giao dịch đa chữ ký nhưng nó gặp khó khăn trong việc tạo điều kiện thuận lợi cho các tương tác hợp đồng phức tạp và năng động phổ biến trên các nền tảng blockchain có trạng thái. Vấn đề này hạn chế đáng kể phạm vi của các ứng dụng phi tập trung (dApps) và các công cụ tài chính phức tạp có thể được xây dựng trên Bitcoin, trong khi nền tảng mô hình trạng thái cung cấp môi trường đa dạng hơn để triển khai và thực hiện các hợp đồng thông minh giàu tính năng.

Để mở rộng Bitcoin, chủ yếu có các công nghệ như kênh trạng thái, chuỗi bên và xác minh khách hàng. Trong số đó, các kênh nhà nước cung cấp giải pháp thanh toán an toàn và đa dạng nhưng bị hạn chế ở khả năng xác minh các phép tính phức tạp tùy ý. Hạn chế này làm giảm việc sử dụng nó trong nhiều tình huống đòi hỏi logic và tương tác phức tạp, có điều kiện. Sidechains, mặc dù hỗ trợ nhiều loại ứng dụng và cung cấp nhiều chức năng khác nhau ngoài Bitcoin, nhưng lại có độ bảo mật thấp hơn. Sự khác biệt về bảo mật này bắt nguồn từ thực tế là sidechain sử dụng các cơ chế đồng thuận độc lập, kém mạnh mẽ hơn nhiều so với cơ chế đồng thuận Bitcoin. Xác minh phía khách hàng, sử dụng mô hình Bitcoin UTXO, có thể xử lý các giao dịch phức tạp hơn, nhưng nó không có khả năng ràng buộc tổng kiểm tra hai chiều với Bitcoin, dẫn đến tính bảo mật thấp hơn Bitcoin. Thiết kế ngoài chuỗi của các giao thức xác minh khách hàng dựa trên cơ sở hạ tầng máy chủ hoặc đám mây, điều này có thể dẫn đến việc tập trung hóa hoặc kiểm duyệt tiềm năng thông qua các máy chủ bị xâm nhập. Thiết kế xác thực phía khách hàng ngoài chuỗi cũng gây ra sự phức tạp hơn cho cơ sở hạ tầng blockchain, có khả năng dẫn đến các vấn đề về khả năng mở rộng.

Vào tháng 12 năm 2023, trưởng dự án ZeroSync Robin Linus đã xuất bản một bài viết có tiêu đề "Sách trắng BitVM: Tính toán mọi thứ trên Bitcoin" đã khơi dậy suy nghĩ của mọi người về việc cải thiện khả năng lập trình của Bitcoin. Bài viết này đề xuất một giải pháp hợp đồng Bitcoin có thể đạt được tính hoàn thiện Turing mà không làm thay đổi sự đồng thuận của mạng Bitcoin, do đó mọi tính toán phức tạp đều có thể được xác minh trên Bitcoin mà không thay đổi các quy tắc cơ bản của Bitcoin. BitVM tận dụng tối đa Bitcoin Script và Taproot để đạt được kết quả khả quan. Dựa trên chữ ký Lamport (còn được gọi là cam kết bit), một kết nối được thiết lập giữa hai UTXO Bitcoin để triển khai các tập lệnh Bitcoin có trạng thái. Bằng cách cam kết thực hiện một chương trình lớn trong địa chỉ Taproot, người vận hành và người xác thực sẽ tham gia vào các tương tác ngoài chuỗi rộng rãi, dẫn đến dấu chân nhỏ trên chuỗi. Nếu cả hai bên hợp tác, các tính toán ngoài chuỗi có trạng thái, phức tạp tùy ý có thể được thực hiện mà không để lại bất kỳ dấu vết nào trên chuỗi. Nếu cả hai bên không hợp tác thì khi xảy ra tranh chấp, việc thực hiện trên chuỗi là bắt buộc. Do đó, BitVM mở rộng đáng kể các trường hợp sử dụng tiềm năng của Bitcoin, cho phép Bitcoin không chỉ đóng vai trò là tiền tệ mà còn là nền tảng xác minh cho các ứng dụng phi tập trung khác nhau và các tác vụ tính toán phức tạp.

Tuy nhiên, mặc dù công nghệ BitVM có những lợi thế lớn trong việc mở rộng Bitcoin nhưng nó vẫn đang ở giai đoạn đầu và vẫn còn một số vấn đề về hiệu quả và bảo mật. Ví dụ: (1) Các thách thức và phản hồi yêu cầu nhiều tương tác, dẫn đến phí xử lý đắt đỏ và chu kỳ thử thách dài; (2) Dữ liệu chữ ký một lần của Lamport dài và cần giảm độ dài dữ liệu; (3) Hàm băm là phức tạp và yêu cầu hàm băm thân thiện với Bitcoin giúp giảm chi phí (4) Hợp đồng BitVM hiện tại rất lớn và dung lượng khối Bitcoin bị hạn chế. Các tập lệnh không có tập lệnh có thể được sử dụng để triển khai Tập lệnh không có tập lệnh BitVM, tiết kiệm không gian khối Bitcoin đồng thời cải thiện hiệu quả của BitVM; (5) BitVM hiện tại áp dụng mô hình cấp phép. Chỉ các thành viên liên minh mới có thể bắt đầu các thử thách và chỉ giới hạn ở hai bên. Nó nên được mở rộng sang mô hình thử thách nhiều bên không được phép để giảm hơn nữa giả định về niềm tin. Để đạt được mục tiêu này, bài viết này đề xuất một số ý tưởng tối ưu hóa để nâng cao hơn nữa hiệu quả và tính bảo mật của BitVM.

2. Nguyên tắc BitVM

BitVM được định vị là một hợp đồng ngoài chuỗi của Bitcoin và cam kết thúc đẩy các chức năng của hợp đồng Bitcoin. Hiện tại các tập lệnh Bitcoin hoàn toàn không có trạng thái, vì vậy khi tập lệnh Bitcoin được thực thi, môi trường thực thi của nó sẽ được đặt lại sau mỗi tập lệnh. Không có cách riêng nào để tập lệnh 1 và tập lệnh 2 có cùng giá trị x và Tập lệnh Bitcoin không hỗ trợ điều này một cách tự nhiên. Tuy nhiên, bạn vẫn có thể sử dụng các opcode hiện có để làm cho tập lệnh Bitcoin có trạng thái thông qua chữ ký một lần của Lamport. Ví dụ: bạn có thể buộc x trong script1 và script2 có cùng giá trị. Người tham gia có thể bị phạt nếu họ ký các giá trị x xung đột. Việc tính toán chương trình BitVM diễn ra ngoài chuỗi, trong khi việc xác minh kết quả tính toán diễn ra trên chuỗi. Khối Bitcoin hiện tại có giới hạn 1 MB. Khi tính toán xác minh quá phức tạp, công nghệ OP có thể được sử dụng để áp dụng chế độ phản hồi thử thách nhằm hỗ trợ xác minh tính toán có độ phức tạp cao hơn.

Tương tự như Optimistic Rollup và đề xuất MATT (Merkelize All The Things), hệ thống BitVM dựa trên các giao thức chống gian lận và phản hồi thách thức, nhưng không yêu cầu sửa đổi Bitcoin quy tắc đồng thuận. Nguyên tắc cơ bản của BitVM rất đơn giản, chủ yếu dựa trên khóa băm, khóa thời gian và cây Taproot lớn.

Người chứng minh cam kết từng byte, nhưng việc xác minh tất cả các tính toán trên chuỗi sẽ quá tốn kém. Vì vậy, người xác minh thực hiện một loạt các thử thách được thiết kế cẩn thận để bác bỏ một cách ngắn gọn những tuyên bố sai lầm của người chứng minh. Người chứng minh và người xác nhận cùng ký trước một loạt các giao dịch thử thách và phản hồi được sử dụng để giải quyết tranh chấp, cho phép xác minh tính toán phổ quát trên Bitcoin.

Các thành phần chính của BitVM là:

• Cam kết mạch: người chứng minh và người trình xác minh sẽ Các chương trình được biên dịch thành các mạch nhị phân lớn. Bộ chứng minh cam kết với mạch theo địa chỉ Taproot và mỗi tập lệnh lá bên dưới địa chỉ đó tương ứng với từng cổng logic trong mạch. Cốt lõi là thực hiện cam kết cổng logic dựa trên cam kết bit và thực hiện cam kết mạch.

• Thử thách và phản hồi: Người chứng minh và người xác minh ký trước một loạt giao dịch để thực hiện trò chơi phản hồi thách thức. Lý tưởng nhất là sự tương tác này được thực hiện ngoài chuỗi, nhưng cũng có thể được thực hiện trên chuỗi khi người chứng minh không hợp tác.

• Hình phạt mơ hồ: Nếu người chứng minh đưa ra bất kỳ tuyên bố sai nào, người xác minh có thể lấy đi tiền đặt cọc của người chứng minh sau khi thử thách thành công nhằm ngăn chặn hành vi xấu xa của người chứng minh.

3.BitVM tối ưu hóa

3.1 Giảm số lượng tương tác OP dựa trên ZK

Hiện tại có 2 Bản tổng hợp chính thống chính: Bản tổng hợp ZK và Bản tổng hợp OP. Trong số đó, ZK Rollups dựa vào xác minh tính hợp lệ của Bằng chứng ZK, nghĩa là bằng chứng mật mã về việc thực thi chính xác và tính bảo mật của nó dựa trên giả định về độ phức tạp tính toán; OP Rollups dựa vào Bằng chứng gian lận, giả định rằng các trạng thái được gửi là chính xác, cài đặt Thời gian thử thách thường là 7 ngày và tính bảo mật của nó giả định rằng ít nhất một bên trung thực trong hệ thống có thể phát hiện trạng thái không chính xác và gửi bằng chứng gian lận. Giả sử rằng số bước tối đa của chương trình thử thách BitVM là 2^{32} và bộ nhớ cần thiết là 2^{32}*4 byte, tức là khoảng 17GB. Trong trường hợp xấu nhất, phải mất khoảng 40 vòng thử thách và phản hồi, mất khoảng nửa năm và tổng dung lượng kịch bản là khoảng 150KB. Tình trạng này thiếu động lực trầm trọng nhưng hầu như không bao giờ xảy ra trên thực tế.

Hãy cân nhắc sử dụng bằng chứng không có kiến ​​thức để giảm số lượng thách thức của BitVM, từ đó nâng cao hiệu quả của BitVM. Theo lý thuyết chứng minh không có kiến ​​thức, nếu dữ liệu Dữ liệu thỏa mãn thuật toán F thì chứng minh rằng bằng chứng thỏa mãn thuật toán xác minh Verify, tức là thuật toán xác minh xuất ra True; nếu dữ liệu Data không thỏa mãn thuật toán F, nó được chứng minh rằng bằng chứng không thỏa mãn thuật toán xác minh Xác minh, nghĩa là thuật toán xác minh xuất ra Sai. . Trong hệ thống BitVM, nếu người thách thức không nhận ra dữ liệu do người chứng minh gửi thì một thử thách sẽ được bắt đầu.

Đối với thuật toán F thì dùng phương pháp phân đôi để phân tách, giả sử thực hiện 2^n lần thì có thể tìm ra điểm lỗi, nếu độ phức tạp của thuật toán quá cao thì n sẽ lớn hơn và cần nhiều thời gian để hoàn thành. Tuy nhiên, độ phức tạp của thuật toán xác minh Xác minh bằng chứng không có kiến ​​thức đã được khắc phục. Toàn bộ quá trình chứng minh và thuật toán xác minh Xác minh là công khai và kết quả đầu ra được phát hiện là Sai. Ưu điểm của bằng chứng không có kiến ​​thức là độ phức tạp tính toán cần thiết để mở thuật toán xác minh Xác minh thấp hơn nhiều so với phương pháp nhị phân để mở thuật toán gốc F. Do đó, với sự trợ giúp của bằng chứng không kiến ​​thức, BitVM không còn thách thức thuật toán F ban đầu nữa mà là thuật toán xác minh Verify, giảm số vòng thử thách và rút ngắn chu kỳ thử thách.

Cuối cùng, mặc dù tính hợp lệ của bằng chứng không có kiến ​​thức và bằng chứng gian lận phụ thuộc vào các giả định bảo mật khác nhau, nhưng chúng có thể được kết hợp để xây dựng Bằng chứng gian lận ZK và triển khai Bằng chứng ZK theo yêu cầu. Không giống như ZK Rollup đầy đủ, không còn cần tạo bằng chứng ZK cho mỗi lần chuyển đổi trạng thái riêng lẻ, mô hình Theo yêu cầu khiến ZK Proof chỉ được yêu cầu khi có thách thức, trong khi toàn bộ thiết kế Rollup vẫn lạc quan. Do đó, trạng thái kết quả vẫn có hiệu lực theo mặc định cho đến khi có người thách thức nó. Nếu không có thử thách ở một trạng thái nhất định thì không cần tạo bất kỳ Bằng chứng ZK nào. Tuy nhiên, nếu người tham gia bắt đầu thử thách, ZK Proof cần được tạo để đảm bảo tính chính xác của tất cả các giao dịch trong khối thử thách. Trong tương lai, chúng ta có thể khám phá việc tạo Bằng chứng gian lận ZK cho một lệnh gây tranh cãi duy nhất để tránh chi phí tính toán khi luôn tạo Bằng chứng ZK.

3.2 Chữ ký một lần thân thiện với Bitcoin

Trong mạng Bitcoin, các giao dịch tuân theo quy tắc đồng thuận là giao dịch hợp lệ, nhưng ngoài quy tắc đồng thuận, quy tắc tiêu chuẩn cũng được đưa ra. Các nút bitcoin chỉ chuyển tiếp các giao dịch tiêu chuẩn phát sóng, cách duy nhất để đóng gói các giao dịch hợp lệ nhưng không chuẩn là làm việc trực tiếp với các thợ mỏ.

Theo quy tắc đồng thuận, kích thước tối đa của các giao dịch kế thừa (không phải Segwit) là 1MB, chiếm toàn bộ khối. Nhưng giới hạn tiêu chuẩn của các giao dịch kế thừa là 100kB. Theo quy tắc đồng thuận, kích thước tối đa của giao dịch Segwit là 4 MB, đây là giới hạn trọng lượng. Nhưng tiêu chuẩn của các giao dịch Segwit bị giới hạn ở mức 400kB.

Chữ ký Lamport là thành phần cơ bản của BitVM, việc giảm độ dài chữ ký và khóa công khai giúp giảm dữ liệu giao dịch, từ đó giảm phí xử lý. Chữ ký một lần của Lamport yêu cầu sử dụng hàm băm (chẳng hạn như hàm hoán vị một chiều f). Trong sơ đồ chữ ký một lần của Lamport, độ dài tin nhắn là v bit, độ dài khóa chung là 2v bit và độ dài chữ ký cũng là 2v bit. Chữ ký và khóa công khai dài và cần một lượng lớn gas lưu trữ. Vì vậy, cần phải tìm ra các sơ đồ chữ ký có chức năng tương tự để giảm độ dài chữ ký và khóa công khai. So với chữ ký một lần của Lamport, chữ ký một lần của Winternitz đã giảm đáng kể độ dài chữ ký và khóa công khai, nhưng làm tăng độ phức tạp tính toán của việc xác minh chữ ký và chữ ký.

Trong sơ đồ chữ ký một lần của Winternitz, một hàm đặc biệt P được sử dụng để ánh xạ thông điệp v-bit thành một vectơ s có độ dài n. Giá trị của mỗi phần tử trong s là {0,...,d}. Sơ đồ chữ ký một lần Lamport là sơ đồ chữ ký một lần Winternitz trong trường hợp đặc biệt d=1. Trong sơ đồ chữ ký một lần của Winternitz, mối quan hệ giữa n, d và v thỏa mãn: n≈v/log2(d+1). Khi d=15, có n≈(v/4)+1. Đối với chữ ký Winternitz chứa n phần tử, độ dài khóa công khai và độ dài chữ ký ngắn hơn 4 lần so với sơ đồ chữ ký một lần của Lamport. Tuy nhiên, độ phức tạp của việc xác minh chữ ký tăng lên gấp 4 lần. Việc sử dụng d=15, v=160, f=ripemd160(x) trong BitVM để triển khai chữ ký một lần của Winternitz có thể giảm 50% kích thước cam kết bit, do đó giảm ít nhất 50% phí giao dịch của BitVM. Trong tương lai, trong khi tối ưu hóa việc triển khai Winternitz Bitcoin Script hiện tại, có thể khám phá các sơ đồ chữ ký một lần nhỏ gọn hơn được thể hiện trong Bitcoin Script.

3.3 Hàm băm thân thiện với Bitcoin

Theo quy tắc đồng thuận, kích thước tối đa của tập lệnh P2TR là 10kB và kích thước tối đa của nhân chứng tập lệnh P2TR giống như giao dịch Segwit tối đa kích thước là 4 MB. Tuy nhiên, giới hạn trên của độ chuẩn của chứng kiến ​​tập lệnh P2TR là 400kB.

Mạng Bitcoin hiện tại không hỗ trợ OP_CAT và không thể ghép các chuỗi để xác minh đường dẫn Merkle. Do đó, cần sử dụng các tập lệnh Bitcoin hiện có để triển khai hàm băm thân thiện với Bitcoin với kích thước tập lệnh và kích thước chứng thực tập lệnh tối ưu để hỗ trợ chức năng xác minh bằng chứng đưa vào merkle.

BLAKE3 là phiên bản tối ưu của hàm băm BLAKE2 và giới thiệu chế độ cây Bao. So với BLAKE2 dựa trên, số vòng chức năng nén của nó giảm từ 10 xuống 7. Hàm băm BLAKE3 sẽ chia đầu vào của nó thành các khối liên tiếp có kích thước 1024 byte, đoạn cuối cùng có thể ngắn hơn nhưng không được trống. Khi chỉ có một đoạn thì đoạn đó là nút gốc và là nút duy nhất của cây. Sắp xếp các khối này thành các nút lá của cây nhị phân, sau đó nén từng khối một cách độc lập.

Khi BitVM được sử dụng để xác minh kịch bản chứng minh bao gồm Merkle, đầu vào của hoạt động băm bao gồm hai giá trị băm 256 bit, nghĩa là đầu vào của hàm băm hoạt động là 64 byte. Khi sử dụng hàm băm BLAKE3, 64 byte này có thể được phân bổ trong một đoạn duy nhất và toàn bộ hoạt động băm BLAKE3 chỉ cần áp dụng hàm nén một lần cho một đoạn duy nhất. Trong hàm nén của BLAKE3 cần chạy hàm tròn 7 lần và hàm dịch chuyển 6 lần.

Hiện tại, BitVM đã hoàn thiện các thao tác cơ bản như XOR, cộng module, dịch bit phải dựa trên giá trị u32, dễ dàng lắp ráp hàm băm BLAKE3 được thực hiện bởi các tập lệnh Bitcoin . Sử dụng 4 byte riêng biệt trong ngăn xếp để biểu thị các từ u32 nhằm triển khai phép cộng u32, phép quay XOR theo bit XOR và u32 theo bit theo yêu cầu của BLAKE3. Tập lệnh Bitcoin của hàm băm BLAKE3 hiện tại có tổng dung lượng khoảng 100kB, đủ để xây dựng một phiên bản đồ chơi của BitVM.

Ngoài ra, các mã BLAKE3 này có thể được phân chia, cho phép Verifier và Prover giảm đáng kể chi phí thực thi bằng cách chia đôi quá trình thực thi trong trò chơi phản hồi thử thách thay vì thực hiện nó hoàn toàn.Dữ liệu trên chuỗi bắt buộc. Cuối cùng, sử dụng tập lệnh Bitcoin để triển khai các hàm băm như Keccak-256 và Grøstl, chọn hàm băm thân thiện với Bitcoin nhất và khám phá các hàm băm mới thân thiện với Bitcoin khác.

3.4 Tập lệnh không có tập lệnh BitVM

Tập lệnh không có tập lệnh là một phương pháp thực thi hợp đồng thông minh ngoài chuỗi bằng cách sử dụng chữ ký Schnorr. Khái niệm Tập lệnh không có tập lệnh được sinh ra từ Mimblewimble và không lưu trữ dữ liệu cố định ngoại trừ hạt nhân và chữ ký của nó.

Ưu điểm của Tập lệnh không có tập lệnh là chức năng, quyền riêng tư và hiệu quả.

• Chức năng: Tập lệnh không có tập lệnh có thể tăng phạm vi và độ phức tạp của hợp đồng thông minh. Khả năng tạo tập lệnh bitcoin bị giới hạn bởi số lượng OP_CODES được kích hoạt trong mạng và Tập lệnh không có tập lệnh chuyển thông số kỹ thuật và thực thi hợp đồng thông minh từ chuỗi sang chỉ thảo luận giữa những người tham gia hợp đồng thiết kế mà không cần đợi một nhánh của mạng Bitcoin kích hoạt các mạng mới . opcode.

• Quyền riêng tư: Việc chuyển thông số kỹ thuật và thực thi hợp đồng thông minh từ trên chuỗi sang ngoài chuỗi có thể tăng cường quyền riêng tư. Trên chuỗi, nhiều chi tiết của hợp đồng sẽ được chia sẻ trên toàn mạng, bao gồm số lượng, địa chỉ của người tham gia và số tiền chuyển. Bằng cách chuyển các hợp đồng thông minh ra khỏi chuỗi, mạng chỉ biết rằng những người tham gia đồng ý rằng các điều khoản trong hợp đồng của họ đã được đáp ứng và các giao dịch cơ bản là hợp lệ.

• Hiệu quả: Tập lệnh không có tập lệnh giảm thiểu lượng dữ liệu được xác minh và lưu trữ trên chuỗi. Bằng cách chuyển các hợp đồng thông minh ra khỏi chuỗi, phí quản lý cho các nút đầy đủ sẽ giảm và phí giao dịch cho người dùng cũng sẽ giảm.

Tập lệnh không có tập lệnh là một phương pháp thiết kế các giao thức mã hóa trên Bitcoin nhằm tránh việc thực thi các hợp đồng thông minh rõ ràng. Ý tưởng cốt lõi là sử dụng các thuật toán mã hóa để đạt được chức năng mong muốn thay vì sử dụng các tập lệnh để đạt được chức năng đó. Chữ ký bộ điều hợp và chữ ký đa chữ ký là các khối xây dựng ban đầu của tập lệnh không có tập lệnh. Bằng cách sử dụng tập lệnh không có tập lệnh, bạn có thể đạt được các giao dịch nhỏ hơn giao dịch thông thường và giảm phí giao dịch.

Với sự trợ giúp của Tập lệnh không có tập lệnh, chữ ký đa chữ ký và bộ điều hợp Schnorr có thể được sử dụng, không còn cung cấp giá trị băm và tiền tố băm như giải pháp BitVM, đồng thời cũng có thể hiện thực hóa cam kết cổng logic trong mạch BitVM, do đó tiết kiệm tiền. Không gian tập lệnh BitVM để cải thiện hiệu quả của BitVM. Mặc dù giải pháp Tập lệnh không tập lệnh hiện tại có thể giảm không gian tập lệnh BitVM nhưng nó đòi hỏi lượng tương tác lớn giữa người chứng minh và người thách thức để kết hợp khóa chung. Trong tương lai, chúng tôi sẽ cải thiện giải pháp này và cố gắng đưa Scripless Script vào các mô-đun chức năng BitVM cụ thể.

3.5 Thử thách nhiều bên không được phép

Lý do tại sao các thử thách BitVM hiện tại mặc định yêu cầu sự cho phép là vì UTXO của Bitcoin chỉ có thể được thực thi một lần, khiến những người xác minh độc hại phải "lãng phí" bằng cách thách thức sự trung thực những lời chứng minh. "Hợp đồng. Hiện tại BitVM bị giới hạn ở chế độ thử thách hai bên. Người chứng minh cố gắng làm điều ác có thể thách thức hợp đồng với người xác minh mà nó kiểm soát cùng lúc, từ đó "lãng phí" hợp đồng và khiến hành động xấu xa thành công, trong khi những người xác minh khác không thể ngăn chặn hành vi đó. Do đó, dựa trên Bitcoin, cần phải nghiên cứu giao thức thử thách OP đa bên không được phép để có thể mở rộng mô hình tin cậy 1 trên n hiện có của BitVM thành 1 trên N. Trong đó, N lớn hơn n rất nhiều. Ngoài ra, cần nghiên cứu, giải quyết tình trạng người thách thức cấu kết với người chứng minh hoặc thách thức ác ý “lãng phí” hợp đồng. Cuối cùng triển khai giao thức BitVM với ít độ tin cậy hơn.

Thử thách nhiều bên không cần cấp phép, cho phép mọi người tham gia mà không cần có danh sách cấp phép. Điều này có nghĩa là người dùng có thể rút tiền từ L2 mà không cần sự tham gia của bất kỳ bên thứ ba đáng tin cậy nào. Ngoài ra, bất kỳ người dùng nào muốn tham gia giao thức thử thách OP đều có thể thử thách và xóa các giao dịch rút tiền không hợp lệ.

Việc mở rộng BitVM thành mô hình thách thức nhiều bên không được phép đòi hỏi phải giải quyết các cuộc tấn công sau:

• < p >Tấn công Sybil: Ngay cả khi kẻ tấn công giả mạo nhiều danh tính để tham gia vào một thử thách tranh chấp, một người tham gia trung thực duy nhất vẫn có thể thắng cuộc tranh chấp. Nếu cái giá mà một bên trung thực phải trả để bảo vệ kết quả đúng có quan hệ tuyến tính với số lượng kẻ tấn công, thì khi có một số lượng lớn kẻ tấn công tham gia, cái giá để thắng trong một cuộc tranh chấp sẽ trở nên phi thực tế và dễ bị Phù thủy tấn công. Giấy Giải đấu có trọng tài không được phép  Đề xuất một thuật toán giải quyết tranh chấp có thể thay đổi trò chơi trong đó chi phí để một bên trung thực giành chiến thắng trong tranh chấp tăng theo hàm logarit theo số lượng đối thủ, thay vì tuyến tính.

• Tấn công trì hoãn: Một bên hoặc nhóm bên độc hại thực hiện một chiến lược nhất định để ngăn chặn hoặc trì hoãn việc xác nhận kết quả chính xác (chẳng hạn như rút tài sản về L1) trên L1, và buộc Một người chứng minh trung thực phải trả phí xử lý L1. Vấn đề này có thể được giảm bớt bằng cách yêu cầu những người thách đấu đặt cược trước. Nếu người thách thức thực hiện một cuộc tấn công bị trì hoãn, tiền cược của họ sẽ bị mất. Tuy nhiên, nếu kẻ tấn công sẵn sàng hy sinh việc đặt cọc trong một số giới hạn nhất định để theo đuổi cuộc tấn công trì hoãn thì cần có biện pháp đối phó để giảm tác động của cuộc tấn công trì hoãn. Giấy Táo bạo: Độ trễ thanh khoản bị giới hạn trong Giao thức thử thách tổng hợp Thuật toán được đề xuất khiến cho dù kẻ tấn công có sẵn sàng mất bao nhiêu cam kết, thì cuộc tấn công trong trường hợp xấu nhất chỉ có thể dẫn đến một giới hạn trên nhất định.

Trong tương lai, chúng ta sẽ khám phá mô hình thử thách đa bên không được phép của BitVM phù hợp với đặc điểm của Bitcoin và có thể chống lại các vấn đề tấn công nêu trên.

4. Kết luận

Việc khám phá công nghệ BitVM chỉ mới bắt đầu. Trong tương lai, nhiều hướng tối ưu hóa hơn sẽ được khám phá và thực hành để đạt được sự mở rộng của Bitcoin và phát triển hệ sinh thái Bitcoin.

Tài liệu tham khảo

1. BitVM: Tính toán mọi thứ trên Bitcoin

2. BitVM: Hợp đồng Bitcoin ngoài chuỗi

3. Robin Linus trên BitVM

4. [bitcoin-dev] BitVM: Tính toán mọi thứ trên Bitcoin

   < / li>

5. Cặp đôi kỳ lạ: ZK và các bản tổng hợp lạc quan vào ngày có khả năng mở rộng

6. < p >Giới hạn tập lệnh và giao dịch của Bitcoin là gì?

7. BIP-342: Xác thực tập lệnh Taproot

8. https://twitter.com / robin_linus/status/1765337186222686347

9. Khóa học sau đại học về Mật mã ứng dụng

10. BLAKE3: một chức năng, nhanh chóng ở mọi nơi

11. < span style="font-size: 18px;">[bitcoin-dev] Triển khai Blake3 trong Tập lệnh Bitcoin

12. https://github.com/BlockstreamResearch/scriptless-scripts

13. Giới thiệu về Tập lệnh không có chữ viết

14. BitVM sử dụng tập lệnh không có tập lệnh

15. Giải pháp trì hoãn các cuộc tấn công khi cuộn lên

16. Giới thiệu DAVE. Hệ thống chống lỗi không được phép của Cartesi.

17. Trì hoãn các cuộc tấn công vào các bản tổng hợp

18. Trì hoãn các cuộc tấn công vào các bản cuộn span>

19. Giải pháp trì hoãn các cuộc tấn công khi cuộn lên - Nghiên cứu của Arbitrum

20. Ghi chú về trò chơi tính toán tương tác nhiều người chơi

21. Đậm: Độ trễ thanh khoản bị giới hạn trong Giao thức thử thách cuộn lên

22. Các giải đấu có trọng tài không được cấp phép < /span>