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ó đối mặt với những hạn chế đáng kể ngăn chặn nó trở thành một mạng có khả năng mở rộng cho thanh toán và các ứng dụng khác. Vấn đề về việc mở rộng của Bitcoin đã là một mối quan tâm kể từ khi nó ra đời. Mô hình UTXO (Unspent Transaction Output) của Bitcoin xử lý mỗi giao dịch như một sự kiện độc lập, dẫn đến một hệ thống không có trạng thái thiếu khả năng thực hiện các tính toán phức tạp phụ thuộc vào trạng thái. Kết quả là, trong khi Bitcoin có thể thực hiện các kịch bản đơn giản và các giao dịch đa chữ ký, nó gặp khó khăn trong việc tạo điều kiện để thực hiện các tương tác hợp đồng phức tạp và động thường gặp trên các nền tảng blockchain có trạng thái. Hạn chế 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ể xây dựng trên Bitcoin, trong khi các mô hình nền tảng có trạng thái cung cấp một 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 đầy đủ tính năng.

Để mở rộng quy mô Bitcoin, các công nghệ chính bao gồm các kênh trạng thái, sidechain và xác thực phía máy khách. Các kênh nhà nước cung cấp một giải pháp thanh toán an toàn và đa dạng nhưng có khả năng hạn chế để xác minh các tính toán phức tạp tùy ý. Hạn chế này làm giảm khả năng áp dụng của chúng trong các tình huống khác nhau đòi hỏi logic và tương tác phức tạp, có điều kiện. Sidechains hỗ trợ một loạt các ứng dụng và cung cấp sự đa dạng ngoài khả năng của Bitcoin, nhưng chúng có bảo mật thấp hơn. Sự khác biệt bảo mật này bắt nguồn từ các 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 của Bitcoin. Xác thực phía máy khách, 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ó thiếu kiểm tra hai chiều và các ràng buộc với Bitcoin, dẫn đến bảo mật thấp hơn. Thiết kế ngoài chuỗi của các giao thức xác thực phía máy khách phụ thuộc vào máy chủ hoặc cơ sở hạ tầng đám mây, điều này có thể dẫn đến 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ế off-chain của xác thực phía máy khách cũng giới thiệu sự phức tạp hơn vào cơ sở hạ tầng blockchain, có thể dẫn đến các vấn đề về khả năng mở rộng.

Vào tháng 12 năm 2023, Robin Linus, người đứng đầu dự án ZeroSync, đã xuất bản một bản sách trắng có tiêu đề “BitVM: Tính Toán Mọi Thứ Trên Bitcoin”, mà đã gây ra nhiều suy nghĩ về việc tăng cường tính có thể lập trình của Bitcoin. Bài báo đề xuất một giải pháp hợp đồng Bitcoin hoàn toàn Turing có thể thực thi bất kỳ tính toán phức tạp nào trên Bitcoin mà không thay đổi quy tắc thống nhất của mạng hoặc thay đổi các nguyên tắc cơ bản của Bitcoin. BitVM tận dụng các script Bitcoin và Taproot để triển khai Optimistic Rollups. Nó sử dụng chữ ký Lamport (còn được biết đến là cam kết bit) để thiết lập kết nối giữa hai UTXO Bitcoin, cho phép các script Bitcoin stateful. Một chương trình lớn được cam kết trong một địa chỉ Taproot, và các nhà điều hành và xác nhận viên tham gia vào các tương tác ngoại chuỗi một cách rộng lớn, để lại một dấu vết tối thiểu trên blockchain. Nếu cả hai bên hợp tác, bất kỳ tính toán ngoại chuỗi phức tạp nào có thể được thực thi mà không để lại bất kỳ dấu vết nào trên blockchain. Tuy nhiên, nếu các bên không hợp tác, việc thực thi trên chuỗi sẽ được yêu cầu trong trường hợp xảy ra tranh chấp. 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 nó phục vụ không chỉ là một loại tiền tệ mà còn là một nền tảng xác minh cho các ứng dụng phi tập trung và các nhiệm vụ tính toán phức tạp khác.

Tuy nhiên, mặc dù có những ưu điểm của công nghệ BitVM trong việc mở rộng Bitcoin, nhưng vẫn đang ở giai đoạn đầu và đối mặt với một số vấn đề về hiệu suất và bảo mật, như: (1) Thách thức và phản ứng yêu cầu nhiều tương tác, dẫn đến phí giao dịch cao và thời gian thách thức dài; (2) Chữ ký một lần Lamport có độ dài dữ liệu dài, cần phải giảm kích thước dữ liệu; (3) Độ phức tạp của hàm băm cao yêu cầu các hàm băm thân thiện với Bitcoin để giảm chi phí; (4) Các hợp đồng BitVM hiện có lớn, và khả năng chứa khối Bitcoin bị giới hạn, vì vậy việc sử dụng scriptless scripts có thể giúp đạt được Scriptless Scripts BitVM, tiết kiệm không gian khối Bitcoin và tăng cường hiệu suất BitVM; (5) BitVM hiện tại hoạt động trên mô hình cấp phép, với thách thức chỉ được khởi xướng bởi các thành viên hội đồng và giới hạn chỉ hai bên, điều này nên được mở rộng thành mô hình thách thức đa bên không giới hạn để tiếp tục giảm giả định về sự tin cậy. Để giải quyết những vấn đề này, bài báo đề xuất một số ý tưởng tối ưu hóa để cải thiện hiệu suất và bảo mật của BitVM.

2. Nguyên lý BitVM

BitVM được định vị là một hệ thống hợp đồng ngoại chuỗi cho Bitcoin, nhằm mục tiêu nâng cao chức năng hợp đồng của Bitcoin. Hiện tại, các script Bitcoin hoàn toàn không có trạng thái, có nghĩa là môi trường thực thi sẽ đặt lại sau mỗi script. Không có cách tự nhiên nào trong việc viết script Bitcoin để đảm bảo rằng script 1 và script 2 có cùng giá trị của x. Tuy nhiên, có thể làm cho các script Bitcoin có trạng thái bằng cách sử dụng các opcode hiện có và chữ ký một lần Lamport, bắt buộc rằng x trong script1 và script2 là giống nhau. Nếu các bên tham gia ký các giá trị x mâu thuẫn, họ có thể bị phạt.

Các phép tính BitVM diễn ra ngoại chuỗi, trong khi việc xác minh các phép tính này diễn ra trên chuỗi. Với giới hạn 1MB của các khối Bitcoin, khi cần xác minh các phép tính phức tạp, công nghệ OP có thể được sử dụng trong chế độ thách thức-đáp ứng để hỗ trợ việc xác minh các phép tính phức tạp hơn.

Tương tự như Optimistic Rollup và đề xuất MATT (Merkelize All The Things), hệ thống BitVM dựa trên chứng minh gian lận và giao thức thách thức-phản hồi nhưng không yêu cầu thay đổi các quy tắc đồng thuận của Bitcoin. Các nguyên tắc cơ bản của BitVM đơ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 vào chương trình từng byte, nhưng việc xác minh tất cả các tính toán trên chuỗi sẽ rất tốn kém. Do đó, người xác minh tiến hành một loạt các thách thức được thiết kế cẩn thận để một cách ngắn gọn bác bỏ những tuyên bố sai lệch của người chứng minh. Người chứng minh và người xác minh ký kết một loạt các giao dịch thách thức và phản hồi để giải quyết tranh chấp, cho phép xác minh tính toán chung trên Bitcoin.

Các thành phần chính của BitVM bao gồm:

• Cam kết mạch: Người chứng minh và người xác minh biên soạn chương trình thành một mạch nhị phân lớn. Người chứng minh cam kết với mạch này trong một địa chỉ Taproot, với mỗi tập lệnh lá dưới địa chỉ đó tương ứng với mỗi cổng logic trong mạch. Điều cốt lõi là đạt được cam kết cổng logic dựa trên cam kết bit.
• Thách thức và phản ứng: Người chứng minh và người xác minh trước ký một loạt giao dịch để thực hiện trò chơi thách thức-phản ứng. Lý tưởng, sự tương tác này xảy ra ngoại chuỗi, nhưng cũng có thể được thực hiện trên chuỗi nếu người chứng minh không hợp tác.
• Phạt mơ hồ: Nếu người chứng minh đưa ra bất kỳ yêu cầu không chính xác nào, người xác minh có thể lấy tiền đặt cọc của người chứng minh sau khi thách thức thành công và ngăn chặn các hành động độc ác 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

Có hai loại chính của Rollups: ZK Rollups và Optimistic Rollups (OP Rollups). ZK Rollups dựa vào việc xác minh tính hợp lệ của Zero-Knowledge (ZK) Proofs, đó là chứng minh mật mã về việc thực thi chính xác. Tính bảo mật của chúng phụ thuộc vào các giả định về phức tạp tính toán. Optimistic Rollups dựa vào Fraud Proofs, giả định rằng tất cả các trạng thái được gửi đi đều chính xác và thường thiết lập một giai đoạn thách thức khoảng bảy ngày. Tính bảo mật của chúng 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 fraud-proof.

Giả sử số bước tối đa cho chương trình thách thức BitVM là 2^{32}, nó sẽ cần khoảng 17GB bộ nhớ (2^{32}×4 byte). Trong trường hợp xấu nhất, khoảng 40 vòng thách thức và phản hồi có thể mất khoảng sáu tháng, với tổng kích thước tập lệnh xấp xỉ 150KB. Tình huống như vậy sẽ cung cấp ít động lực, nhưng hiếm khi xảy ra trong thực tế.

Sử dụng Zero-Knowledge Proofs để giảm số lượng thách thức trong BitVM có thể nâng cao hiệu suất của nó. Theo lý thuyết Zero-Knowledge Proof, nếu dữ liệu Data thỏa mãn một thuật toán F, thì bằng chứng sẽ thỏa mãn thuật toán xác minh Verify, đưa ra kết quả True. Ngược lại, nếu Data không thỏa mãn F, thì bằng chứng sẽ không thỏa mãn Verify, đưa ra kết quả False. Trong hệ thống BitVM, nếu người thách thức không chấp nhận dữ liệu của người chứng minh, một thách thức sẽ được khởi xướng.

Đối với thuật toán F, sử dụng phương pháp tìm kiếm nhị phân, giả sử cần 2^n lần lặp để tìm điểm lỗi. Nếu độ phức tạp của thuật toán cao, n 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 Chứng minh không biết Zero-Knowledge Verify là cố định. Bằng cách tiết lộ công khai chứng minh và quá trình xác minh Verify, có thể thấy một đầu ra sai. Ưu điểm của Chứng minh không biết Zero-Knowledge nằm ở việc cần ít phức tạp tính toán hơn để mở thuật toán xác minh Verify so với việc mở thuật toán ban đầu F bằng tìm kiếm nhị phân. Do đó, với Chứng minh không biết Zero-Knowledge, BitVM không còn thách thức thuật toán ban đầu F nữa, mà thay vào đó là thuật toán xác minh Verify, giảm số vòng thách thức và rút ngắn thời kỳ thách thức.

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, 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 đủ, mô hình Theo yêu cầu chỉ yêu cầu Bằng chứng ZK khi thực hiện thử thách, duy trì thiết kế lạc quan trong đó trạng thái được tạo ra được giả định là hợp lệ cho đến khi bị thách thức. Nếu một trạng thái không bị thách thức, không cần Bằng chứng ZK. Tuy nhiên, nếu một thách thức được thực hiện, Bằng chứng ZK phải được tạo ra để đảm bảo tính chính xác của tất cả các giao dịch trong khối bị thách thức. Trong tương lai, có thể tạo Bằng chứng gian lận ZK cho các hướng dẫn tranh chấp riêng lẻ, tránh chi phí tính toán của việc liên tục 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 thủ theo các quy tắc đồng thuận được coi là hợp lệ, nhưng vượt quá những quy tắc này, có một khái niệm bổ sung về tính chuẩn. Các nút Bitcoin chỉ truyền tải và phát sóng giao dịch chuẩn, và cách duy nhất để giao dịch hợp lệ nhưng không chuẩn được bao gồm trong một khối là thông qua sự hợp tác trực tiếp với các thợ đào.

Theo quy tắc đồng thuận, kích thước tối đa cho giao dịch cổ điển (không phải Segwit) là 1MB, có thể lấp đầy một khối hoàn toàn. Tuy nhiên, giới hạn chuẩn cho các giao dịch cổ điển được đặt ở mức 100kB. Đối với các giao dịch Segwit, kích thước tối đa cho phép theo quy tắc đồng thuận là 4MB, được biết đến với tên gọi là giới hạn trọng lượng, nhưng giới hạn chuẩn của chúng là 400kB.

Chữ ký Lamport là một thành phần cơ bản của BitVM, và việc giảm độ dài của chữ ký và khóa công khai giúp giảm kích thước dữ liệu giao dịch, từ đó giảm phí giao dịch. Chữ ký một lần của Lamport yêu cầu một hàm băm (như một hàm phép chiếu một chiều f). Trong một mô hình chữ ký một lần của Lamport, độ dài của thông điệp là v bit, và cả khóa công khai lẫn chữ ký đều có độ dài là 2v bit. Những chữ ký và khóa công khai dài này tiêu tốn một lượng lớn gas lưu trữ. Do đó, việc nghiên cứu các mô hình chữ ký có thể giảm độ dài của chữ ký và khóa công khai là cần thiết. 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 của chữ ký và khóa công khai, nhưng lại tăng sự phức tạp tính toán khi ký và xác minh.

Trong lược đồ chữ ký một lần của Winternitz, một hàm đặc biệt P ánh xạ một thông điệp v-bit thành một vector s có độ dài n, với mỗi phần tử của s có giá trị trong {0,…,d}. Lược đồ chữ ký một lần của Lamport là một trường hợp đặc biệt của lược đồ Winternitz, trong đó d=1. Trong lược đồ Winternitz, mối quan hệ giữa n, d và v là khoảng n≈v/log2(d+1). Khi d=15, n≈(v/4)+1. Đối với một chữ ký Winternitz với n phần tử, độ dài của khóa công khai và chữ ký ngắn gấp bốn lần so với lược đồ chữ ký một lần của Lamport, nhưng độ phức tạp của việc xác minh cao gấp bốn lần. Việc sử dụng d=15, v=160, f=ripemd160(x) trong BitVM cho chữ ký một lần của Winternitz có thể giảm kích thước cam kết bit điều này đi 50%, từ đó giảm phí giao dịch của BitVM ít nhất là 50%. Trong tương lai, trong quá trình tối ưu hóa việc triển khai tập lệnh Bitcoin Winternitz hiện có, việc khám phá các lược đồ chữ ký một lần gọn nhẹ hơn có thể được thực hiện trong tập lệnh Bitcoin.

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

Theo quy tắc ủy quyền, kích thước tối đa cho một kịch bản P2TR là 10kB, và kích thước tối đa cho một chứng nhận kịch bản P2TR cũng như kích thước giao dịch Segwit tối đa, là 4MB. Tuy nhiên, giới hạn tiêu chuẩn cho một chứng nhận kịch bản P2TR là 400kB.

Hiện tại, mạng Bitcoin không hỗ trợ OP_CAT, làm cho việc nối chuỗi cho xác minh đường dẫn Merkle trở nên không thể thực hiện. Do đó, cần phải triển khai một hàm băm thân thiện với Bitcoin bằng cách sử dụng kịch bản Bitcoin hiện có, một cách hiệu quả nhất về kích thước cho cả kích thước kịch bản và kích thước chứng nhận kịch bản, để hỗ trợ xác minh chứng thực bao gồm Merkle.

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

Khi BitVM được sử dụng để xác minh chứng minh tính bao gồm Merkle, đầu vào cho phép thực hiện băm bao gồm hai giá trị băm 256 bit được nối tiếp nhau, tổng cộng 64 byte. Với hàm băm BLAKE3, 64 byte này có thể vừa trong một chunk duy nhất, có nghĩa là phép băm BLAKE3 chỉ cần áp dụng hàm nén một lần cho chunk duy nhất này. Trong hàm nén của BLAKE3, bảy hàm vòng và sáu hàm hoán vị cần thiết.

BitVM đã triển khai các hoạt động cơ bản như XOR, cộng modulo và dịch bit sang phải dựa trên các giá trị u32, giúp việc lắp ráp hàm băm BLAKE3 bằng kịch bản Bitcoin trở nên dễ dàng. Ngăn xếp sử dụng bốn byte riêng biệt để biểu diễn các từ u32, tạo điều kiện cho việc cộng u32, XOR bit u32 và xoay bit u32 cần thiết bởi BLAKE3. Hàm băm BLAKE3 trong kịch bản Bitcoin hiện tại khoảng 100kB, đủ để xây dựng một phiên bản đồ chơi của BitVM.

Hơn nữa, bằng cách chia nhỏ các mã BLAKE3 này, Người xác minh và Người chứng minh có thể giảm đáng kể yêu cầu dữ liệu trên chuỗi bằng cách chia thực thi thành trò chơi thách thức-phản ứng thay vì thực hiện hoàn toàn. Cuối cùng, việc triển khai các hàm băm như Keccak-256 và Grøstl trong kịch bản Bitcoin sẽ xác định 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 khác thân thiện với Bitcoin.

3.4 Scriptless Scripts BitVM

Scriptless Scripts là một phương pháp 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 Scriptless Scripts bắt nguồn từ Mimblewimble, nơi không lưu trữ dữ liệu cố định ngoài lõi và chữ ký của nó.

Các lợi ích của Scriptless Scripts bao gồm tính năng, sự riêng tư và hiệu suất:

• Chức năng: Kịch bản không cần mã có thể mở rộng phạm vi và phức tạp của các hợp đồng thông minh. Các khả năng của kịch bản Bitcoin bị giới hạn bởi số lượng OP_CODES được kích hoạt trên mạng. Ngược lại, Kịch bản không cần mã chuyển việc quy định và thực thi của các hợp đồng thông minh khỏi chuỗi thành các cuộc thảo luận giữa các bên hợp đồng mà không cần chờ đợi mạng Bitcoin chia để kích hoạt các mã opcode mới.
• Quyền riêng tư: Chuyển việc quy định và thực thi hợp đồng thông minh từ on-chain sang off-chain tăng cường tính riêng tư. Trên on-chain, nhiều chi tiết của hợp đồng được chia sẻ với toàn bộ mạng lưới, bao gồm số lượng người tham gia, địa chỉ và số tiền được chuyển. Chuyển hợp đồng thông minh off-chain có nghĩa là mạng lưới chỉ biết rằng các bên đã đồng ý rằng các điều khoản của hợp đồng được thỏa thuận và các giao dịch liên quan hợp lệ.
• Hiệu quả: Kịch bản không cần kịch bản giảm thiểu lượng dữ liệu cần phải được xác minh và lưu trữ trên chuỗi. Bằng cách di chuyển hợp đồng thông minh ra khỏi chuỗi, chi phí quản lý cho các nút đầy đủ được giảm bớt, và phí giao dịch cho người dùng cũng giảm đi.

Scriptless scripts đại diện cho một cách để thiết kế các giao thức mật mã trên Bitcoin 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ật mã để đạt được chức năng mong muốn thay vì sử dụng scripts. Chữ ký Adaptor và đa chữ ký là các khối xây dựng cơ bản của Scriptless Scripts. Với Scriptless Scripts, các giao dịch có thể nhỏ hơn so với giao dịch thông thường, giảm phí giao dịch.

Scriptless Scripts có thể được sử dụng để thực hiện cam kết cổng logic trong mạch BitVM, tiết kiệm không gian script BitVM và nâng cao hiệu suất BitVM, sử dụng chữ ký đa chữ ký Schnorr và chữ ký Adaptor thay vì cung cấp giá trị băm và hình ảnh trước như giải pháp BitVM. Mặc dù các kế hoạch Scriptless Scripts hiện tại có thể giảm không gian script BitVM, nhưng chúng yêu cầu sự tương tác mở rộng giữa người chứng minh và người thách đấu để kết hợp các khóa công khai. Các cải tiến trong tương lai sẽ nhằm mục tiêu tích hợp Scriptless Scripts vào các mô-đun chức năng BitVM cụ thể.

3.5 Thách thức Đa bên không cần phép

Thách thức BitVM hiện tại yêu cầu sự cho phép vì một Bitcoin UTXO chỉ có thể được thực thi một lần, dẫn đến tình huống mà một người xác minh độc hại có thể “lãng phí” hợp đồng bằng cách thách thức một người chứng minh trung thực. BitVM hiện đang bị hạn chế trong mô hình thách thức hai bên. Một người chứng minh độc hại có thể sử dụng một người xác minh dưới sự kiểm soát của mình để khởi xướng một thách thức và “lãng phí” hợp đồng, đảm bảo hành động độc hại của mình thành công trong khi người xác minh khác không thể ngăn chặn hành vi này. Do đó, trên nền tảng Bitcoin, cần nghiên cứu một giao thức thách thức OP đa bên không cần sự cho phép có thể mở rộng mô hình tin cậy 1-trong-n hiện có của BitVM thành 1-trong-N, trong đó N lớn hơn n nhiều. Ngoài ra, quan trọng là giải quyết vấn đề cùng có mối liên kết giữa người thách thức và người chứng minh hoặc thách thức độc hại lãng phí hợp đồng để đạt được một giao thức BitVM tối thiểu về sự tin cậy hơn.

Một thách thức đa bên không cần phép mời cho phép bất kỳ ai tham gia mà không cần whitelist, 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. Hơn nữa, bất kỳ người dùng nào muốn tham gia vào giao thức thách thức OP đều có thể đặt câu hỏi và loại bỏ các lượt rút không hợp lệ.

Mở rộng BitVM thành một mô hình thách thức đa bên không cần phép mà liên quan đến việc đối phó với các cuộc tấn công sau đây:

• Cuộc tấn công Sybil: Ngay cả khi một kẻ tấn công tạo ra nhiều danh tính để tham gia vào thách thức tranh chấp, một người tham gia trung thực vẫn nên có khả năng chiến thắng trong tranh chấp. Nếu chi phí cho người tham gia trung thực để bảo vệ kết quả đúng tăng theo cấp số nhân với số kẻ tấn công, chi phí cho người tham gia trung thực để chiến thắng trong tranh chấp trở nên không thực tế và dễ bị tấn công Sybil khi liên quan đến một số lượng lớn kẻ tấn công. Bài báo “Giải đấu có sự kiểm duyệt không cần phépĐề xuất một thuật toán giải quyết tranh chấp thay đổi các quy tắc trò chơi, nơi chi phí cho một người tham gia trung thực để chiến thắng tranh chấp tăng theo cấp số nhân, không phải tuyến tính, với số đối thủ.
• Các cuộc tấn công trì hoãn: Một cá nhân hoặc nhóm các tác nhân độc hại tuân theo một 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 (như rút tài sản đến L1) trên L1, buộc người chứng minh trung thực phải chi tiền phí giao dịch L1. Để giảm thiểu vấn đề này, người thách thức có thể phải đặt cược trước. Nếu một người thách thức tiến hành một cuộc tấn công trì hoãn, số tiền cược của họ sẽ bị mất. Tuy nhiên, nếu kẻ tấn công sẵn lòng hy sinh một phần cược của họ để tiến hành các cuộc tấn công trì hoãn, nên có các chiến lược để giảm thiểu tác động của những cuộc tấn công này. Thuật toán được đề xuất trong bài báoBoLD: Bounded Liquidity Delay trong một Giao thức Thách thức Rollup” đảm bảo rằng độ trễ tối đa trong trường hợp xấu nhất do kẻ tấn công gây ra được giới hạn, bất kể số lượng cổ phần mà kẻ tấn công sẵn lòng mất.

Trong tương lai, sẽ có sự khám phá về một mô hình thách thức đa bên không cần phép tác giả BitVM chống lại những cuộc tấn công này và phù hợp với các đặc điểm của Bitcoin.

4. Kết luận

Sự khám phá công nghệ BitVM chỉ mới bắt đầu, và trong tương lai, sẽ được khám phá và thực hành nhiều tối ưu hóa hơn để đạt được quy mô hóa cho Bitcoin và làm phong phú hệ sinh thái Bitcoin.

免责声明：

1. Bài viết này được sao chép từ [@Bitlayer/bitvm-and-its-optimization-considerations-007da599d8ac">Bitlayer], Tất cả bản quyền thuộc về tác giả gốc [Lynndell và Mutourend]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ Học cửađội ngũ và họ sẽ xử lý nhanh chóng.
2. Bản quyền từ chối trách nhiệm: Các quan điểm được thể hiện trong bài viết này chỉ là quan điểm cá nhân của tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.