Tiêu đề ban đầu: Bitlayer Core Technology: DLC and Its Optimization Considerations》
Tác giả gốc: lynndell mutourend, Nhóm nghiên cứu Bitlayer
1. Giới thiệu
Hợp đồng nhật ký kín đáo (DLC) là một tập hợp các giải pháp thực thi hợp đồng dựa trên oracle được Tadge Dryja của MIT đề xuất vào năm 2018. DLC cho phép hai bên thực hiện thanh toán có điều kiện dựa trên các điều kiện được xác định trước. Mỗi bên xác định và ký trước các kết quả có thể xảy ra, đồng thời sử dụng các chữ ký trước này để thực hiện thanh toán khi nhà tiên tri ký vào kết quả. Do đó, DLC cho phép các ứng dụng tài chính phi tập trung mới đồng thời giữ an toàn cho tiền gửi Bitcoin.
So với Lightning Network, DLC có những ưu điểm đáng kể sau:
Sự riêng tư:DLC vượt trội hơn Lightning Network về khả năng bảo vệ quyền riêng tư, vì chi tiết hợp đồng chỉ được chia sẻ giữa những người tham gia và không được lưu trữ trên blockchain. Ngược lại, các giao dịch của Lightning Network được định tuyến thông qua các kênh và nút công khai, đồng thời thông tin của chúng được công khai và minh bạch;
Sự phức tạp và linh hoạt của hợp đồng tài chính:DLC có thể tạo và thực hiện các hợp đồng tài chính phức tạp trực tiếp trên mạng Bitcoin, chẳng hạn như hợp đồng phái sinh, bảo hiểm và cờ bạc, trong khi Lightning Network chủ yếu được sử dụng để thanh toán nhỏ nhanh chóng và không thể hỗ trợ các ứng dụng phức tạp;
Giảm rủi ro đối tác:Quỹ DLC bị khóa trong một hợp đồng nhiều chữ ký và sẽ chỉ được giải phóng khi xảy ra kết quả của một sự kiện được xác định trước, giúp giảm nguy cơ một trong hai bên không tuân thủ hợp đồng. Mặc dù Lightning Network làm giảm nhu cầu về niềm tin nhưng vẫn có một số rủi ro đối tác về quản lý kênh và cung cấp thanh khoản;
Không cần quản lý kênh thanh toán:Hoạt động DLC không yêu cầu tạo hoặc duy trì các kênh thanh toán, một thành phần cốt lõi của Lightning Network. Việc quản lý kênh rất phức tạp và tốn nhiều tài nguyên;
Khả năng mở rộng cho các trường hợp sử dụng cụ thể:Lightning Network cải thiện thông lượng giao dịch của Bitcoin ở một mức độ nhất định, trong khi DLC cung cấp khả năng mở rộng tốt hơn cho các hợp đồng phức tạp trên Bitcoin.
Mặc dù DLC có lợi thế lớn trong các ứng dụng sinh thái Bitcoin nhưng vẫn tồn tại một số rủi ro và vấn đề, chẳng hạn như:
Rủi ro chính:Khóa riêng của máy oracle và số ngẫu nhiên đã hứa có nguy cơ bị rò rỉ hoặc bị mất dẫn đến mất tài sản của người dùng;
Rủi ro niềm tin tập trung:Vấn đề tập trung hóa oracle có thể dễ dàng dẫn đến các cuộc tấn công từ chối dịch vụ;
Việc dẫn xuất khóa phi tập trung là không thể:Nếu oracle được phân cấp, nút oracle chỉ sở hữu phân đoạn khóa riêng. Tuy nhiên, các nút oracle phi tập trung không thể sử dụng trực tiếp BIP 32 để lấy khóa dựa trên phân đoạn khóa riêng;
Rủi ro thông đồng:Nếu các nút oracle thông đồng với nhau hoặc với các bên tham gia thì vấn đề tin cậy của máy oracle vẫn chưa được giải quyết. Cần có cơ chế giám sát đáng tin cậy để giảm thiểu niềm tin vào oracle;
Đã khắc phục sự cố thay đổi mệnh giá:Chữ ký có điều kiện yêu cầu một tập hợp xác định các sự kiện có thể đếm được trước khi xây dựng hợp đồng để xây dựng giao dịch. Do đó, DLC sẽ có giới hạn số lượng tối thiểu để phân phối lại tài sản, dẫn đến vấn đề thay đổi mệnh giá cố định.
Để đạt được mục đích này, bài viết này đề xuất một số giải pháp và ý tưởng tối ưu hóa để giải quyết các rủi ro và vấn đề của DLC cũng như cải thiện tính bảo mật của hệ sinh thái Bitcoin.
Nguyên tắc 2.DLC
Alice và Bob ký một thỏa thuận cá cược: đặt cược rằng giá trị băm của khối thứ n+k là số lẻ hoặc số chẵn. Nếu đó là số lẻ, Alice thắng trò chơi và có thể rút tài sản trong thời gian t; nếu đó là số chẵn, Bob thắng trò chơi và có thể rút tài sản sau thời gian t. Bằng cách sử dụng DLC, thông tin khối thứ n+k được chuyển qua oracle để xây dựng chữ ký có điều kiện để người chiến thắng chính xác sẽ giành được tất cả tài sản.
khởi tạo:Bộ tạo đường cong elip là G và bậc là q.
Tạo khóa:Oracle, Alice và Bob tạo khóa riêng và khóa chung một cách độc lập.
Khóa riêng của oracle là z và khóa chung là Z, thỏa mãn mối quan hệ Z=z⋅G;
Khóa riêng của Alice là x và khóa chung của cô ấy là X, thỏa mãn mối quan hệ X=x⋅G;
Khóa riêng của Bob là y và khóa chung của anh ấy là Y, thỏa mãn mối quan hệ Y=y⋅G.
Giao dịch bơm vốn:Alice và Bob cùng nhau tạo một giao dịch cấp vốn, mỗi người khóa 1 BTC ở đầu ra 2 trên 2 chữ ký (một khóa chung X thuộc về Alice, một khóa chung Y thuộc về Bob).
Giao dịch thực hiện hợp đồng:Alice và Bob tạo hai Giao dịch thực thi hợp đồng (CET) để chi tiêu cho các giao dịch bơm vốn.
Cam kết tính toán của Oracle
Sau đó tính S và S
phát sóng (R, S, S).
Alice và Bob mỗi người tính toán khóa công khai mới tương ứng
Giải quyết:Khi khối thứ n+k xuất hiện, oracle sẽ tạo ra s hoặc s tương ứng dựa trên giá trị băm của khối.
Nếu hàm băm của khối n+k là số lẻ, oracle sẽ tính toán và phát sóng s
Nếu giá trị băm của khối n+k là chẵn, oracle sẽ tính toán và phát sóng s
Rút xu:Một trong những người tham gia, Alice hoặc Bob, có thể rút tài sản dựa trên thông báo của nhà tiên tri.
Nếu oracle phát sóng s, Alice có thể tính khóa riêng mới sk^{Alice} và rút 2 BTC bị khóa
Nếu oracle phát sóng s, Bob có thể tính khóa riêng mới sk^{Bob} và rút 2 BTC bị khóa
Phân tích: Khóa riêng mới sk^{Alice} do Alice tính toán và khóa chung mới PK^{Alice} thỏa mãn mối quan hệ logarit rời rạc
Trong trường hợp này, việc rút tiền của Alice sẽ thành công.
Tương tự như vậy, khóa riêng mới sk^{Bob} do Bob tính toán và khóa chung mới PK^{Bob} thỏa mãn mối quan hệ logarit rời rạc
Trong trường hợp này, việc rút tiền của Bob sẽ thành công.
Hơn nữa, nếu nhà tiên tri phát sóng s, nó có ích cho Alice nhưng không hữu ích cho Bob. Bởi vì Bob không thể được sử dụng để tính khóa riêng mới tương ứng sk^{Bob}. Theo cách tương tự, nếu nhà tiên tri phát sóng s, nó có ích cho Bob, nhưng không hữu ích cho Alice. Bởi vì Alice không thể được sử dụng để tính toán khóa riêng mới tương ứng sk^{Alice}.
Cuối cùng, mô tả ở trên bỏ qua việc khóa thời gian. Cần thêm khóa thời gian để cho phép một bên tính toán khóa riêng mới và rút tiền trong thời gian t. Mặt khác, nếu vượt quá thời gian t, bên kia có thể rút tài sản bằng khóa riêng ban đầu.
Tối ưu hóa 3.DLC
3.1 Quản lý khóa
Trong giao thức DLC, khóa riêng của oracle và số ngẫu nhiên đã hứa là rất quan trọng. Nếu khóa riêng của oracle và số ngẫu nhiên đã hứa bị rò rỉ hoặc bị mất sẽ dễ dẫn đến 4 vấn đề bảo mật sau:
(1) Máy oracle mất khóa riêng z
Nếu oracle mất khóa riêng, DLC sẽ không thể được giải quyết, dẫn đến việc phải thực hiện hợp đồng hoàn trả DLC. Do đó, giao dịch hoàn lại tiền được thiết lập trong giao thức DLC để ngăn oracle mất khóa riêng.
(2) Máy oracle rò rỉ khóa riêng z
Nếu khóa riêng của oracle bị rò rỉ, tất cả DLC dựa trên khóa riêng sẽ phải đối mặt với nguy cơ giải quyết gian lận. Kẻ tấn công đánh cắp khóa riêng có thể ký bất kỳ tin nhắn nào chúng muốn, đạt được quyền kiểm soát hoàn toàn kết quả của tất cả các hợp đồng trong tương lai. Hơn nữa, kẻ tấn công không bị giới hạn trong việc xuất bản một tin nhắn được ký đơn lẻ mà còn có thể xuất bản các tin nhắn xung đột, chẳng hạn như ký khối thứ n+k với các hàm băm chẵn và lẻ cùng một lúc.
(3) Máy oracle rò rỉ hoặc sử dụng lại số ngẫu nhiên k
Nếu oracle rò rỉ số ngẫu nhiên k thì trong giai đoạn giải quyết, bất kể oracle phát sóng s hay s, kẻ tấn công có thể tính khóa riêng z của oracle như sau
Nếu máy oracle sử dụng lại số ngẫu nhiên k thì sau 2 lần xử lý, kẻ tấn công có thể giải hệ phương trình theo chữ ký do máy oracle phát ra và tính khóa riêng z của máy oracle theo một trong 4 tình huống sau :
Trường hợp 1:
Trường hợp 2:
Trường hợp 3:
Trường hợp 4:
(4) Máy oracle mất số ngẫu nhiên k
Nếu oracle mất số ngẫu nhiên k, thì DLC tương ứng không thể giải quyết được và hợp đồng hoàn trả DLC cần phải được thực thi.
Do đó, để cải thiện tính bảo mật của khóa riêng của Oracle, nên sử dụng BIP 32 để lấy khóa con hoặc khóa cháu để ký. Ngoài ra, để cải thiện tính bảo mật của số ngẫu nhiên, nên sử dụng giá trị băm k:=hash(z, bộ đếm) của khóa riêng và bộ đếm làm số ngẫu nhiên k để tránh số ngẫu nhiên bị lặp lại hoặc bị mất.
3.2 Oracle phi tập trung
Trong DLC, oracle đóng một vai trò quan trọng, cung cấp dữ liệu bên ngoài quan trọng để xác định kết quả của hợp đồng. Để cải thiện tính bảo mật của các hợp đồng này, cần có các oracle phi tập trung. Không giống như các oracle tập trung, các oracle phi tập trung phân bổ trách nhiệm cung cấp dữ liệu chính xác và chống giả mạo trên nhiều nút độc lập, điều này có thể làm giảm nguy cơ dựa vào một điểm lỗi duy nhất và giảm khả năng thao túng hoặc tấn công có chủ đích. Thông qua các oracle phi tập trung, DLC có thể đạt được mức độ tin cậy và độ tin cậy cao hơn, đảm bảo rằng việc thực hiện hợp đồng hoàn toàn dựa vào tính khách quan của các điều kiện được xác định trước.
Chữ ký ngưỡng Schnorr cho phép các oracle phi tập trung. Chữ ký ngưỡng Schnorr có những ưu điểm sau:
Bảo mật nâng cao:Thông qua việc quản lý khóa phi tập trung, chữ ký ngưỡng giúp giảm nguy cơ lỗi một điểm. Ngay cả khi khóa của một số người tham gia bị rò rỉ hoặc bị tấn công, toàn bộ hệ thống vẫn an toàn miễn là không vượt quá ngưỡng đã đặt.
Kiểm soát phân tán:Chữ ký ngưỡng thực hiện quyền kiểm soát phân tán đối với việc quản lý khóa và không một thực thể nào có toàn bộ quyền ký, do đó giảm rủi ro do tập trung quyền lực quá mức gây ra.
Cải thiện khả năng sử dụng:Chữ ký chỉ cần được một số nút oracle nhất định đồng ý, điều này giúp cải thiện tính linh hoạt và tính khả dụng của hệ thống. Ngay cả khi một số nút không khả dụng, nó sẽ không ảnh hưởng đến hoạt động đáng tin cậy của toàn bộ hệ thống.
Tính linh hoạt và khả năng mở rộng:Giao thức chữ ký ngưỡng có thể đặt các ngưỡng khác nhau nếu cần để thích ứng với các yêu cầu và tình huống bảo mật khác nhau. Ngoài ra, nó cũng phù hợp với các mạng quy mô lớn và có khả năng mở rộng tốt.
Trách nhiệm giải trình:Mỗi nút oracle tạo ra các đoạn chữ ký cho các tin nhắn dựa trên các đoạn khóa riêng và những người tham gia khác có thể sử dụng các đoạn khóa chung tương ứng để xác minh tính chính xác của các đoạn chữ ký nhằm đạt được trách nhiệm giải trình. Nếu đúng, các đoạn chữ ký sẽ được tích lũy để tạo ra chữ ký hoàn chỉnh.
Do đó, giao thức chữ ký ngưỡng Schnorr có những lợi thế đáng kể trong các oracle phi tập trung giúp cải thiện tính bảo mật, độ tin cậy, tính linh hoạt, khả năng mở rộng và trách nhiệm giải trình.
3.3 Kết hợp phân cấp và quản lý khóa
Trong công nghệ quản lý khóa, máy oracle có khóa z hoàn chỉnh, dựa trên khóa z hoàn chỉnh và số gia ω, sử dụng BIP 32, nó có thể gửi ra một số lượng lớn khóa phụ z+{ω }^{(1) } và Khóa bí mật Mặt trời z+ω ^{( 1)}+ω ^{( 2)}. Đối với các sự kiện khác nhau, nhà tiên tri có thể sử dụng các khóa riêng lớn khác nhau z+ω ^{(1)}+ω ^{(2)} để tạo chữ ký tương ứng σ cho thông báo sự kiện tương ứng.
Trong kịch bản ứng dụng oracle phi tập trung, có n người tham gia và t+1 người tham gia được yêu cầu thực hiện chữ ký ngưỡng. Trong số đó, t. n nút oracle đều có một phân đoạn khóa riêng z_i, i= 1,..., n. N đoạn khóa riêng z_i này tương ứng với một khóa riêng z hoàn chỉnh, nhưng khóa riêng z hoàn chỉnh không xuất hiện từ đầu đến cuối. Với tiền đề là khóa riêng z hoàn chỉnh không xuất hiện, các nút oracle t+1 sử dụng các đoạn khóa riêng z_i, i= 1,..., t+ 1 để tạo các đoạn chữ ký σ_i và các đoạn chữ ký σ_i cho tin nhắn được sáp nhập vào chữ ký đầy đủ σ. Người xác minh sử dụng khóa chung Z hoàn chỉnh để xác minh tính chính xác của cặp chữ ký thông báo (msg,σ ). Vì cần có t+1 nút oracle để cùng tạo ra chữ ký ngưỡng nên nó có tính bảo mật cao.
Tuy nhiên, trong kịch bản ứng dụng oracle phi tập trung, khóa riêng z hoàn chỉnh không xuất hiện và BIP 32 không thể được sử dụng trực tiếp để lấy khóa. Nói cách khác, công nghệ phân cấp oracle và công nghệ quản lý khóa không thể kết hợp trực tiếp với nhau.
giấyDistributed Key Derivation for Multi-Party Management of Blockchain Digital AssetsMột phương pháp phái sinh khóa phân tán trong kịch bản chữ ký ngưỡng được đề xuất.Ý tưởng cốt lõi của bài viết này là theo đa thức nội suy Lagrange, đoạn khóa riêng z_i và khóa riêng z hoàn chỉnh thỏa mãn mối quan hệ nội suy sau
Thêm gia số ω vào cả hai vế của phương trình trên, chúng ta thu được phương trình sau
Phương trình này cho thấy: đoạn khóa riêng z_i cộng với gia số ω vẫn thỏa mãn mối quan hệ nội suy với khóa riêng hoàn chỉnh z cộng với gia số ω. Nói cách khác, đoạn khóa riêng phụ z_i+ω và khóa phụ z+ω thỏa mãn mối quan hệ nội suy. Do đó, mỗi người tham gia có thể sử dụng đoạn khóa riêng z_i cộng với gia số ω để lấy đoạn khóa riêng phụ z_i+ω để tạo các đoạn chữ ký phụ và sử dụng khóa công khai phụ tương ứng Z+ω ⋅ G để thực hiện xác minh tính hợp lệ .
Tuy nhiên, BIP nâng cao và không nâng cao cần được xem xét 32 . BIP 32 nâng cao lấy khóa riêng, mã chuỗi và đường dẫn làm đầu vào, tính toán SHA 512 và xuất ra mã delta và mã chuỗi phụ. BIP 32 không nâng cao lấy khóa chung, mã chuỗi và đường dẫn làm đầu vào, tính toán SHA 512 và xuất ra mã delta và chuỗi phụ. Trong trường hợp chữ ký ngưỡng, khóa riêng không tồn tại nên chỉ có thể sử dụng BIP 32 không nâng cao. Hoặc sử dụng hàm băm đồng cấu, có BIP 32 nâng cao. Tuy nhiên, hàm băm đồng cấu khác với SHA 512 và không tương thích với BIP 32 gốc.
3.4 OP-DLC: Giảm thiểu sự tin cậy của Oracle
Trong DLC, hợp đồng giữa Alice và Bob được thực thi dựa trên kết quả của chữ ký oracle, do đó oracle cần phải được tin cậy ở một mức độ nhất định. Do đó, hoạt động đúng đắn của máy oracle là điều kiện tiên quyết chính để vận hành DLC.
Để không tin tưởng vào oracle, đã có nghiên cứu thực hiện DLC dựa trên kết quả của n oracle để giảm sự phụ thuộc vào một oracle duy nhất.
"n-of-n"Mô hình thể hiện việc sử dụng n oracle để ký hợp đồng và thực hiện hợp đồng dựa trên kết quả của n oracle. Mô hình này yêu cầu n oracle để tất cả đều đăng nhập trực tuyến. Nếu oracle ngoại tuyến hoặc có bất đồng về kết quả sẽ ảnh hưởng đến việc thực hiện hợp đồng DLC. Giả định về độ tin cậy là tất cả n nhà tiên tri đều trung thực.
"k-of-n"Mô hình chỉ ra rằng n oracles được sử dụng để ký hợp đồng và hợp đồng được thực hiện dựa trên kết quả của k oracles. Nếu có nhiều hơn k oracle thông đồng sẽ ảnh hưởng đến việc thực hiện hợp đồng một cách công bằng. Ngoài ra, sử dụng"k-of-n"mô hình, số lượng CET cần chuẩn bị là một oracle hoặc"n-of-n"C_n^k lần của mô hình. Giả định về độ tin cậy là ít nhất k trong số n oracle đều trung thực.
Việc tăng số lượng máy oracle không làm mất đi sự tin tưởng của máy oracle. Bởi vì khi nhà tiên tri làm điều gì đó xấu xa, bên bị tổn thương trong hợp đồng không có kênh kháng cáo trên chuỗi.
Do đó, phần này đề xuất OP-DLC, trong đó giới thiệu cơ chế thử thách lạc quan trong DLC.Trước khi tham gia setup DLC, oracle cần phải cam kết trước sẽ xây dựng game OP trên chuỗi không được phép và hứa không làm điều ác. Nếu bất kỳ nhà tiên tri nào hành động xấu xa, Alice hoặc Bob, hoặc bất kỳ nhà tiên tri trung thực nào khác hoặc người quan sát trung thực của bên thứ ba khác, có thể bắt đầu thử thách. Nếu người thách đấu thắng trò chơi, nhà tiên tri độc ác sẽ bị trừng phạt trên dây chuyền và tiền đặt cọc sẽ bị mất. Ngoài ra, OP-DLC cũng có thể được sử dụng"k-of-n"mẫu để ký. trong đó k thậm chí có thể là 1. Do đó, giả định về độ tin cậy giảm xuống mức miễn là có người tham gia trung thực trong mạng, một thử thách OP có thể được đưa ra để trừng phạt nút oracle độc ác.
Khi giải quyết OP-DLC dựa trên kết quả tính toán Lớp 2:
Nếu oracle sử dụng chữ ký kết quả không chính xác, khiến lợi ích của Alice bị tổn hại, Alice có thể sử dụng Lớp 2 để tính toán chính xác kết quả và thách đấu trò chơi OP trên chuỗi không được phép mà oracle đã cam kết trước. Alice thắng trò chơi, trừng phạt nhà tiên tri độc ác và bù đắp tổn thất;
Theo cách tương tự, Bob, các nút oracle trung thực khác và những người quan sát trung thực của bên thứ ba đều có thể bắt đầu các thử thách. Tuy nhiên, để ngăn chặn những thử thách độc hại, người thách thức cũng cần phải đặt cược.
Do đó, OP-DLC cho phép các nút oracle giám sát lẫn nhau, giảm thiểu sự tin cậy của oracle. Cơ chế này chỉ yêu cầu một người tham gia trung thực và có tỷ lệ chịu lỗi là 99%, giúp giải quyết tốt hơn nguy cơ thông đồng oracle.
Cầu kép 3.5 OP-DLC + BitVM
Khi DLC được sử dụng làm cầu nối xuyên chuỗi, cần phải phân bổ vốn khi hợp đồng DLC được giải quyết:
Yêu cầu thiết lập trước thông qua CET. Điều này có nghĩa là mức độ chi tiết thanh toán quỹ của DLC bị hạn chế, chẳng hạn như mức độ chi tiết 0,1 BTC của mạng Bison. Có một vấn đề: Tương tác tài sản của người dùng trong Lớp 2 không nên bị giới hạn ở mức độ chi tiết cấp vốn của DLC CET.
Khi Alice muốn giải quyết tài sản Lớp 2 của mình, tài sản Lớp 2 của người dùng Bob cũng sẽ bị buộc phải chuyển sang Lớp 1. Có một vấn đề: Mỗi người dùng Lớp 2 có thể tự do lựa chọn gửi và rút tiền mà không bị ảnh hưởng bởi việc gửi và rút tiền của những người dùng khác.
Alice và Bob thương lượng chi phí. Có một vấn đề: yêu cầu cả hai bên phải sẵn sàng hợp tác.
Vì vậy, để giải quyết các vấn đề trên, phần này đề xuất cầu kép OP-DLC + BitVM. Giải pháp này cho phép người dùng gửi và rút tiền thông qua cầu nối không cần cấp phép của BitVM, đồng thời gửi và rút tiền thông qua cơ chế OP-DLC, đạt được sự thay đổi ở mọi mức độ chi tiết và cải thiện tính thanh khoản vốn.
Trong OP-DLC, nhà tiên tri là Liên minh BitVM, Alice là người dùng bình thường và Bob là Liên minh BitVM. Khi thiết lập OP-DLC, trong CET được xây dựng, đầu ra cho người dùng Alice có thể được sử dụng ngay lập tức ở Lớp 1 và trong đầu ra cho Bob, trò chơi DLC mà Alice có thể tham gia thử thách được xây dựng và khóa khóa thời gian khoảng thời gian được thiết lập. Khi Alice muốn rút tiền:
Nếu Liên minh BitVM hoạt động như một nhà tiên tri và ký chính xác, Alice có thể rút tiền ở Lớp 1. Tuy nhiên, Bob đợi thời gian khóa hết hạn trước khi có thể rút tiền ở Lớp 1.
Nếu Liên minh BitVM hoạt động như một nhà tiên tri và gian lận, lợi ích của Alice sẽ bị tổn hại. Tuy nhiên, Alice có thể thách thức UTXO của Bob. Nếu thử thách thành công, số tiền của Bob có thể bị mất. Lưu ý: Một trong những thành viên khác của Liên minh BitVM cũng có thể bắt đầu thử thách, nhưng Alice có động lực nhất để bắt đầu thử thách vì lợi ích của cô ấy bị tổn hại.
Nếu Liên minh BitVM hoạt động như một nhà tiên tri và gian lận, lợi ích của Bob sẽ bị tổn hại. Tuy nhiên, một thành viên trung thực của Liên minh BitVM có thể thách thức Trò chơi BitVM và trừng phạt các nút oracle gian lận.
Ngoài ra, khi người dùng Alice muốn rút tiền từ Lớp 2, nhưng CET đặt trước trong hợp đồng OP-DLC không khớp với số tiền, Alice có thể chọn các phương thức sau:
Việc rút tiền thông qua BitVM được nhà điều hành BitVM nâng cao trên Lớp 1. Cầu BitVM giả định một người tham gia trung thực trong tập đoàn BitVM.
Rút tiền thông qua một CET nhất định trong OP-DLC và phần thay đổi còn lại sẽ được nhà điều hành BitVM xử lý ở Lớp 1. Việc rút tiền OP-DLC sẽ đóng kênh DLC, nhưng số tiền còn lại trong kênh DLC sẽ được chuyển vào nhóm quỹ BitVM Lớp 1 mà không buộc người dùng Lớp 2 khác phải rút tiền. Niềm tin cầu nối OP-DLC giả định rằng có một người tham gia trung thực trong kênh.
Alice và Bob thương lượng chi phí mà không có sự tham gia của máy tiên tri, cần có sự hợp tác của Bob.
Do đó, cầu kép OP-DLC + BitVM có những ưu điểm sau:
Sử dụng BitVM giải quyết vấn đề thay đổi quỹ kênh DLC, giảm số lượng cài đặt CET và không bị ảnh hưởng bởi mức độ chi tiết của quỹ CET;
Việc kết hợp cầu OP-DLC và cầu BitVM cung cấp cho người dùng nhiều kênh rút tiền và gửi tiền cũng như thay đổi ở bất kỳ mức độ chi tiết nào;
Đặt liên minh BitVM thành Bob và nhà tiên tri, đồng thời giảm thiểu độ tin cậy của nhà tiên tri thông qua cơ chế OP;
Đưa số dư rút của kênh DLC vào quỹ cầu nối BitVM để cải thiện việc sử dụng quỹ.
4. Kết luận
DLC xuất hiện trước khi kích hoạt Segwit v1 (Taproot) và việc tích hợp kênh DLC với Lightning Network đã được triển khai và DLC đã được mở rộng để cập nhật và thực hiện các hợp đồng liên tục trong cùng một kênh DLC. Với sự trợ giúp của các công nghệ như Taproot và BitVM, có thể đạt được việc xác minh và giải quyết hợp đồng ngoài chuỗi phức tạp hơn trong DLC, đồng thời kết hợp với cơ chế thách thức OP, có thể đạt được mức độ tin cậy tối thiểu của oracle.
người giới thiệu
IOS
Android