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 nó không có khả năng ràng buộc tổng kiểm tra hai chiều với Bitcoin, khiến tính bảo mật của nó 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 sách trắng có tên “BitVM: Tính toán mọi thứ trên Bitcoin”, khiến mọi người suy nghĩ 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 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ả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ó thể sử dụng ít s hơn để triển khai BitVM ít hơn, tiết kiệm không gian khối Bitcoin và cải thiện hiệu quả 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à nó 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 ở 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 1 và 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 về 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. 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ỉ này 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.
- 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 để 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 không rõ ràng: 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ách thức thành công nó nhằm ngăn chặn hành vi xấu xa của người chứng minh.
3.Tối ưu hóa 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ệ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ử phải mất 2^n lần mới tìm được đ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, độ 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ù hiệu quả 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à nhận ra 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, 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. Nhưng giới hạn tiêu chuẩn cho các giao dịch kế thừa là 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. Tuy nhiên, giới hạn tiêu chuẩn của giao dịch Segwit là 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, một hàm đặc biệt P được sử dụng để ánh xạ thông điệp v-bit vào 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 của 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 thỏa mãn: n≈v/log 2(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. Sử dụng d= 15, v= 160, f=ripemd 160(x) trong BitVM để 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 quy tắc đồng thuận, kích thước tối đa của P 2 TR là 10 kB và kích thước tối đa của nhân chứng P 2 TR 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 trên của độ chuẩn của nhân chứng P 2 TR là 400 kB.
Hiện tại, mạng Bitcoin không hỗ trợ OP_CAT và không thể ghép các chuỗi 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 và kích thước chứng kiến tối ưu để hỗ trợ chức năng xác minh bằng chứng bao gồm 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 đoạn liên tiếp có kích thước 1024 byte, đoạn cuối 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ỉ cần áp dụng chức năng nén một lần cho đoạn đơn. Trong hàm nén của BLAKE 3 cần chạy hàm vòng 7 lần và hàm hoán vị 6 lần.
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 trên chuỗi được yêu cầu 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.
Giảm 3,4 giây BitVM
less s là một phương pháp thực hiện hợp đồng thông minh ngoài chuỗi bằng cách sử dụng chữ ký Schnorr. Khái niệm Scripless s được sinh ra từ Mimblewimble, nó không lưu trữ dữ liệu cố định ngoại trừ kernel và chữ ký của nó.
Ưu điểm của less s là chức năng, quyền riêng tư và hiệu quả.
- **Tính năng: **ít hơn 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à less s sẽ 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 sự phân nhánh của mạng Bitcoin kích hoạt Mã hoạt động mới.
- **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 giúp 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 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 giây hơn giúp 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.
less s 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 nhu cầu thực hiện 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 less s. Sử dụng ít s hơn, bạn có thể đạt được các giao dịch nhỏ hơn so với giao dịch thông thường và giảm phí giao dịch.
Với sự trợ giúp của less s, có thể sử dụng chữ ký đa chữ ký và 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, từ đó tiết kiệm BitVM không gian tập lệnh và cải thiện hiệu quả của BitVM. . Mặc dù sơ đồ less s hiện có có thể giảm không gian tập lệnh BitVM, nhưng nó đòi hỏi một 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 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 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. Một người chứng minh cố gắng làm điều ác có thể đồng thời tung ra lời thách thức với người xác minh mà anh ta 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 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 ác ý “lãng phí” hợp đồng. Cuối cùng là triển khai giao thức BitVM với ít sự 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 giao dịch 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:
- 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 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. Trong bài báo Giải đấu có trọng tài không được phép, một thuật toán giải quyết tranh chấp có thể thay đổi trò chơi đã được đề xuất. Chi phí để một người tham gia trung thực giành chiến thắng trong tranh chấp sẽ tăng theo logarit theo số lượng đối thủ, thay vì tuyến tính.
- Tấn công trì hoãn: Một bên độc hại hoặc một nhóm các 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 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. Thuật toán được đề xuất trong bài báo BoLD: Độ trễ thanh khoản bị giới hạn trong Giao thức thử thách tổng hợp 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ể gây ra một giới hạn trễ 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
- BitVM: Tính toán mọi thứ trên Bitcoin
- BitVM: Hợp đồng Bitcoin ngoài chuỗi
- Robin Linus trên BitVM
- [bitcoin-dev] BitVM: Tính toán mọi thứ trên Bitcoin
- 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
- Giao dịch và giới hạn của Bitcoin là gì?
- BIP-342: Xác thực Taproot s
- _linus/trạng thái/1765337186222686347
- Khóa học sau đại học về Mật mã ứng dụng
- BLAKE 3: một chức năng, nhanh chóng ở mọi nơi
- [bitcoin-dev] Triển khai Blake 3 bằng Bitcoin
- Giới thiệu về less s
- BitVM sử dụng ít s hơn
- Giải pháp trì hoãn các cuộc tấn công vào Rollups
- Giới thiệu DAVE. Bằng chứng lỗi không được phép của Cartesi.
- Trì hoãn các cuộc tấn công vào Rollup
- Giải pháp trì hoãn các cuộc tấn công vào Rollup - Nghiên cứu của Arbitrum
- Trò chơi tính toán tương tác nhiều người chơi Ghi chú
- BoLD: Độ trễ thanh khoản có giới hạn trong Giao thức thử thách cuộn lên
- Giải đấu có trọng tài không được phép
Liên kết gốc
