BitVM 2: Xác minh không cần cấp phép trên Bitcoin

Tác giả: Robin Linus, Nghiên cứu BTC

Thiết kế phiên bản đầu tiên của BitVM được giới hạn cho hai người tham gia. Công việc tiếp theo kết hợp các trường hợp song song và dự phòng để giới thiệu sự tham gia của nhiều bên dựa trên giả định trung thực 1/n. Hạn chế chính của các hợp đồng này là tất cả các trình xác nhận phải được xác định tại thời điểm biên dịch. Hơn nữa, chi phí khởi động tăng theo số lượng xác minh. Điều này ngụ ý rằng để phá vỡ hợp đồng, chỉ một số lượng hạn chế người tham gia mới có thể bị hối lộ.

BitVM2 là một biến thể táo bạo: bất kỳ ai cũng có thể đóng vai trò là người xác thực. Điều này vẫn yêu cầu thiết lập một lần với giả định 1 trong n người tham gia trung thực, nhưng trong thời gian chạy, bất kỳ ai cũng có thể phản đối một xác nhận không hợp lệ mà không phải là thành viên của nhóm khởi tạo (không phải là một trong n người tham gia) một trong số họ). Điều này khắc phục những hạn chế của các kế hoạch trước đó và tối ưu hóa các giả định về độ tin cậy của chúng. Hơn nữa, nó đơn giản hóa thiết kế tổng thể, giảm số vòng tối đa trong thử nghiệm xuống còn hai.

Hợp đồng bridge (cầu) vẫn yêu cầu thêm một số nhóm người vận hành được xác định trước và ít nhất một trong số m người điều hành phải trung thực. Tuy nhiên, ngay cả trong trường hợp tất cả những người điều hành đều không trung thực, họ không thể lấy trộm tiền của bạn mà chỉ có thể đốt nó.

Giới thiệu

Đối với chương trình f cho trước, ta muốn kiểm tra một số khẳng định: nhập một số x, sẽ xuất ra y, tức là f (x) = y. Ví dụ: f có thể là trình xác thực SNARK, chẳng hạn như trình xác nhận của hệ thống chứng minh Groth16. Khi đó x là một bằng chứng và y là một số trạng thái đầu ra chứng minh tính hợp lệ của SNARK.

Trong trường hợp trình xác thực SNARK, mức độ quá lớn để có thể được thể hiện bằng một đoạn tập lệnh Bitcoin. Việc triển khai trình xác thực Groth16 có thể yêu cầu tập lệnh có kích thước tối đa 20 MB. Tuy nhiên, kích thước tập lệnh cho phép được giới hạn ở kích thước khối Bitcoin: 4 MB. Và ngay cả khi nó được nén đến kích thước này, nó vẫn có thể quá lớn.

Giải pháp ngây thơ

"Chữ ký Lamport" cung cấp cách chia chương trình f(x)=y thành nhiều bước. Ví dụ: các bước: n=42.

Bằng cách này, Việc tính toán f có thể được chia thành 43 giao dịch theo thứ tự và được thực hiện trong nhiều khối. Mỗi giao dịch sử dụng trạng thái đầu ra của giao dịch trước đó làm trạng thái đầu vào của chính nó. Bất cứ khi nào người chứng minh lập lờ về bất kỳ trạng thái z_i nào, mọi người đều có thể sử dụng chữ ký Lamport mâu thuẫn làm bằng chứng gian lận.

Đây thực sự là một cách không đáng tin cậy để thách thức người chứng minh. Tuy nhiên, một hạn chế đáng kể của giải pháp này là dấu chân dày đặc trên chuỗi, vì nó vẫn yêu cầu người chứng minh thực hiện toàn bộ tính toán. Ngoài ra, cũng vì chữ ký Lamport, nó gây ra chi phí cho trạng thái chuyển đổi.

Giải pháp cân bằng

Chúng tôi có thể giảm đáng kể dấu chân trên chuỗi bằng cách chuyển một số công việc nặng nhọc từ phía người chứng minh sang người xác minh để chống gian lận. Bây giờ, người chứng minh chỉ cần cam kết x và y một lần, cũng như tất cả các kết quả trung gian z1, z2..., z42.

Bất kỳ người xác minh nào cũng có thể bác bỏ bất kỳ khẳng định sai nào. Trong giai đoạn khởi động, chúng tôi xác định Taptree, chứa 43 tập lệnh để xác minh mọi phép tính f1, f2, f3 và f43. Chỉ một khẳng định

Không thể Thành lập, bất cứ ai cũng có thể chi tiêu từ kịch bản tương ứng. Điều này làm giảm tính toán trong trường hợp xấu nhất xuống còn một bước f_i , được thực thi bởi trình xác minh. Bước này có thể vẫn yêu cầu thực hiện nhiều Tập lệnh. Về lý thuyết, miễn là nó vừa với một khối thì không có vấn đề gì lớn, hoặc tốt hơn nữa là có thể đạt được kích thước chuẩn hóa là 400 KB. Trong thực tế, đối với một số triển khai f  cụ thể, chúng tôi sẽ cố gắng tìm sự cân bằng tối ưu giữa khối lượng cam kết của người chứng minh và khối lượng tập lệnh của người xác minh.

Về cơ bản, điều này cho phép bất kỳ ai hủy bỏ kết quả đầu ra của người chứng minh nếu người chứng minh đưa ra bất kỳ khẳng định sai nào. Mặt khác, nếu không ai có thể chứng minh bất kỳ phần tính toán nào, thì khi tập lệnh hết thời gian, một người chứng minh trung thực có thể sử dụng kết quả đầu ra. Nhiều nhất chỉ mất hai vòng.

Cơ chế này có thể được sử dụng làm nền tảng cơ bản để xác minh các hợp đồng bắc cầu mà không cần xin phép.

Giải pháp lạc quan

Giao thức sau đây cải thiện con đường may mắn trong thiết kế trên (hy vọng là con đường phổ biến nhất), với cái giá là phải thêm hai vòng tương tác nữa trong trường hợp xấu nhất:

1. Người chứng minh hứa sẽ đưa ra trạng thái y

2. Nếu sai, bất kỳ ai cũng có thể bắt đầu một vòng thử thách

3 . Người chứng minh hứa hẹn kết quả trung gian z1, z2,...z42

4. Nếu nó sai, bất kỳ ai cũng có thể chứng minh hoặc bác bỏ khẳng định f _i

Cầu nối không cần xin phép thiết kế hợp đồng

< img src="https://img.jinse.cn/7205819_watermarknone.png" title="7205819" alt="fSJTiPgstO1WN5lSZ5gJUUCPKKO91BfzfxCy6hdC.jpeg">

Hạn chế: Phí xử lý

Trong thiết kế trên, người chứng minh có thể lấy đi một số phí xử lý. Trong trường hợp này, vốn dự trữ vẫn an toàn, nhưng người xác nhận sẽ mất một số tiền được đảm bảo.

Kịch bản tấn công như sau:

• Người chứng minh là độc hại

• < p>Bằng chứng sử dụng KickOff_Tx của chính nó (không có PegOut_Tx hợp lệ)

• Người chứng minh chờ người thách thức thực hiện Challenge_TX và trả tiền cho người chứng minh thực hiện thử thách< /p>

• Người chứng minh không thực hiện thử thách và chỉ ngừng phản hồi

Hình ảnh đã sửa bên dưới giải quyết được vấn đề này. Cần có thêm hai giao dịch được chỉ định n-of-n.

Hạn chế: Người vận hành trung thực

Thiết kế này yêu cầu người vận hành ít nhất phải trung thực, nếu không thì tiền cuối cùng sẽ trở nên không thể chi tiêu được. Trên thực tế, các lỗi đang hoạt động có thể đi kèm với các cuộc tấn công bắt cóc để đánh cắp tiền (ví dụ: trừ khi bạn trả cho tôi 50% số tiền chuộc, tiền của bạn sẽ không được mở khóa.)