Phân tích nguyên tắc BitVM và cân nhắc tối ưu hóa
Nguồn gốc: Nhóm nghiên cứu Bitlayer
Tác giả gốc: lynndell, mutourend.

1. Giới thiệu
Bitcoin là một 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 không có khả năng ràng buộc tổng kiểm tra hai chiều của 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 báo có tiêu đề BitVM:Compute Anything On Bitcoin“Sách trắng đã 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 Bitcoin Script và Taproot để triển khai các bản tổng hợp lạc 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 nhiều ứng dụng phi tập trung 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.
Nguyên tắc 2.BitVM
BitVM được định vị là một hợp đồng ngoài chuỗi cho 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 nào để tập lệnh 1 và tập lệnh 2 có cùng giá trị x, nó không được hỗ trợ bởi các tập lệnh Bitcoin. 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 tập lệnh 1 và tập lệnh 2 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 các quy tắc đồng thuận của Bitcoin. 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 của mạch:Người chứng minh và người xác minh biên dịch chương trình thành các mạch nhị phân lớn. Người chứng minh cam kết với mạch tại một địa chỉ Taproot, cho mỗi tập lệnh lá dưới địa chỉ đó, tương ứng với từng cổng logic trong mạch. Cốt lõi dựa trên cam kết bit để thực hiện cam kết cổng logic và cam kết mạch.
Những thách thức 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 để triển khai trò chơi phản hồi thử thách. 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ố không chính xác 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.
Tối ưu hóa 3.BitVM
3.1 Giảm số lượng tương tác OP dựa trên ZK
Hiện tại có 2 Rollup chính: ZK Rollups và OP Rollups. 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 17 GB. 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 150 KB. 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 việc sử dụng các bằng chứng không có kiến thức để giảm số lượng thách thức của BitVM, từ đó cải thiện hiệu quả của BitVM. Theo lý thuyết chứng minh không có kiến thức, nếu dữ liệuDataThỏa mãn thuật toánF, chứng tỏ chứng minh thỏa mãn thuật toán xác minhVerify, nghĩa là thuật toán xác minh xuất ra True; nếu dữ liệuDatakhông thỏa mãn thuật toánF, chứng tỏ chứng minh đó cũng không thỏa mãn thuật toán xác minhVerify, nghĩa là thuật toán xác minh đưa 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ánF, phân chia bằng phương pháp phân đôi, giả sử rằng điều đó là cần thiết2 ^nnhiều lần 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 và mất nhiều thời gian để hoàn thành. Tuy nhiên, thuật toán xác minh bằng chứng không có kiến thứcVerifyĐộ phức tạp là cố định và các thuật toán chứng minh và xác minh được công khaiVerifyTrong suốt quá trình, 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à nó mở ra thuật toán xác minhVerifyĐộ phức tạp tính toán cần thiết, so với thuật toán gốc mở chia đôiF, thấp hơn nhiều. Do đó, với bằng chứng không có kiến thức, BitVM không còn thách thức thuật toán ban đầu nữaF, nhưng thuật toán xác minhVerify, giảm số vòng thử thách và rút ngắn thời gian 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 dựa trên 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 từng chuyển đổi trạng thái riêng lẻ, mô hình Theo yêu cầu chỉ yêu cầu ZK Proof 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 một trạng thái không bị thách thức 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, các 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à 1 MB, chiếm toàn bộ khối. Tuy nhiên, tiêu chuẩn của các giao dịch kế thừa được giới hạn ở mức 100 kB. 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 400 kB.
Chữ ký Lamport là thành phần cơ bản của BitVM, nó giúp giảm độ dài của chữ ký và khóa chung, giúp giảm dữ liệu giao dịch và 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à 2 v bit và độ dài chữ ký cũng là 2 v 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, hãy sử dụng các hàm đặc biệtPSẽvMột thông điệp bit được ánh xạ tới độ dàinvectơ củas。sGiá trị của mỗi phần tử trong là {0,...,d}. Lược đồ chữ ký một lần của Lamport làd= 1 Trường hợp đặc biệt của sơ đồ chữ ký một lần Winternitz. Trong sơ đồ chữ ký một lần của Winternitz,n, d, vMối quan hệ giữa thỏa mãn:n≈v/log 2(d+ 1). Khi d=15 thì cón≈(v/4)+ 1 . Vì chứanChữ ký của các phần tử Winternitz ngắn hơn 4 lần so với độ dài khóa công khai và độ dài chữ ký trong 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. Được sử dụng trong BitVMd= 15, v= 160, f=ripemd 160(x) triển khai chữ ký một lần 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 các quy tắc đồng thuận, kích thước tối đa của tập lệnh P 2 TR là 10 kB và kích thước tối đa của tập lệnh P 2 TR bằng chứng giống với kích thước giao dịch Segwit tối đa là 4 MB. Tuy nhiên, giới hạn độ chuẩn của chứng kiến tập lệnh P 2 TR là 400 kB.
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.
BLAKE 3 là phiên bản tối ưu hóa của hàm băm BLAKE 2 và giới thiệu chế độ cây Bao. So với BLAKE 2 dựa trên s, số vòng chức năng nén của nó giảm từ 10 xuống 7. Hàm băm BLAKE 3 sẽ chia đầu vào của nó thành các khối liền kề có kích thước 1024 byte, đoạn cuối cùng có thể ngắn hơn nhưng không 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 hoạt động băm là 64 byte. Khi sử dụng hàm băm BLAKE 3, 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 BLAKE 3 chỉ yêu cầu chức năng nén được áp dụng một lần cho đoạn đơn. Trong hàm nén của BLAKE 3, cần chạy 7 hàm tròn và 6 hàm hoán vị.
Hiện tại, các hoạt động cơ bản như XOR, bổ sung mô-đun và dịch chuyển bit phải dựa trên giá trị u 32 đã được hoàn thành trong BitVM và hàm băm BLAKE 3 do tập lệnh Bitcoin triển khai có thể dễ dàng được lắp ráp. Sử dụng 4 byte riêng biệt trong ngăn xếp để biểu thị u 32 từ để thực hiện phép cộng u 32, u 32 XOR theo bit và u 32 phép quay theo bit theo yêu cầu của BLAKE 3. Tập lệnh Bitcoin của hàm băm BLAKE 3 hiện tại có tổng dung lượng khoảng 100 kB, đủ để xây dựng một phiên bản đồ chơi của BitVM.
Ngoài ra, các mã BLAKE 3 này có thể được phân tách, cho phép Người xác minh và Nhà cung cấp giảm đáng kể dữ liệu cần thiết trên chuỗi 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 toàn bộ. 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 Scriptless Scripts BitVM
Tập lệnh không có tập lệnh là một cách để thực hiện các 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 nào 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 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 các cuộc thảo luận chỉ giữa những người tham gia hợp đồng thiết kế mà không cần đợi sự phân nhánh của mạng Bitcoin kích hoạt những cái mới . opcode.
sự riêng tư:Việc chuyển đặc điểm kỹ thuật và thực thi các hợp đồng thông minh từ trên chuỗi sang ngoài chuỗi sẽ tăng tính 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 những người tham gia và số tiền chuyển khoả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 cách tiếp cận để thiết kế các giao thức mã hóa trên Bitcoin nhằm tránh 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.
Tập lệnh không có tập lệnh có thể được sử dụng để sử dụng chữ ký đa chữ ký và chữ ký bộ điều hợp Schnorr, không còn cung cấp giá trị băm và tiền đề băm như giải pháp BitVM, đồng thời cũng có thể thực hiện cam kết cổng logic trong mạch BitVM, do đó tiết kiệm không gian tập lệnh BitVM và cải thiện hiệu quả BitVM. . Mặc dù sơ đồ Tập lệnh không có tập lệnh hiện có có thể giảm không gian tập lệnh BitVM nhưng nó đòi hỏi rất nhiều tương tác 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 đa bên không được phép
Lý do tại sao các thử thách BitVM hiện yêu cầu sự cho phép theo mặc định là vì UTXO của Bitcoin chỉ có thể được thực thi một lần, cho phép người xác minh độc hại lãng phí hợp đồng bằng cách thách thức người chứng minh trung thực. BitVM hiện 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ể đồng thời thách thức người xác minh mà nó kiểm soát, từ đó lãng phí hợp đồng, khiến hành vi xấu xa thành công và 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 có nghiên cứu để giải quyết vấn đề người thách thức thông đồng với người chứng minh hoặc thách thức hợp đồng “lãng phí” một cách ác ý. Cuối cùng là triển khai một giao thức BitVM kém tin cậy hơn.
Thử thách nhiều bên không được phép, cho phép bất cứ ai tham gia mà không cần danh sách cho 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 khoản rút tiền không hợp lệ.
Việc mở rộng BitVM sang mô hình thử thách nhiều bên không được phép yêu cầu giải quyết các cuộc tấn công sau:
Cuộc tấn công của phù thủy: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 bên 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 Permissionless Refereed Tournaments, đề 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í của một bên trung thực duy nhất giành chiến thắng trong tranh chấp tăng theo hàm logarit với số lượng đối thủ, thay vì tuyến tính.
Trì hoãn tấn công:Một bên hoặc nhóm các bên độc hại thực hiện chiến lược 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 những người chứng minh trung thực phải chi phí 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 BoLD: Bounded Liquidity Delay in a Rollup Challenge ProtocolThuật toán được đề xuất làm 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ể gây ra một giới hạn trễ 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à triển khai để đạt được sự mở rộng của Bitcoin và phát triển hệ sinh thái Bitcoin.
người giới thiệu


