Phân tích nguyên tắc DLC và cân nhắc tối ưu hóa

Tiêu đề gốc: "Công nghệ lõi Bitlayer: DLC và những cân nhắc tối ưu hóa nó"

Tác giả: 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 do 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 đảm bảo tính bảo mật cho tiền gửi Bitcoin.

So với Lightning Network, DLC có những ưu điểm đáng kể sau:

• Quyền riêng tư:

  • Quyền riêng tư:

    mạnh >DLC vượt trội hơn Lightning Network về khả năng bảo vệ quyền riêng tư. Chi tiết hợp đồng chỉ được chia sẻ giữa những người tham gia và sẽ 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 là 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:

  • strong>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 cho các giao dịch nhỏ nhanh chóng. thanh toán và không thể hỗ trợ các ứng dụng phức tạp;

    < /li>

  • Giảm rủi ro đối tác: Quỹ DLC bị khóa trong hợp đồng nhiều chữ ký và sẽ chỉ được giải phóng khi có kết quả các sự kiện được xác định trước xảy ra, làm giảm rủi ro về việc không tuân thủ của một trong hai bên. 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:< /strong >Hoạt động DLC ​​không yêu cầu tạo hoặc duy trì các kênh thanh toán vốn là 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à tiêu tốn nhiều tài nguyên;

  • < mạnh>Có thể mở rộng cho các trường hợp sử dụng cụ thể Hiệu suất: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 đối với 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 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;

  < li>

  Rủi ro tin cậy tập trung:Vấn đề tập trung hóa của máy oracle có thể dễ dàng dẫn đến các cuộc tấn công từ chối dịch vụ;

  • Sự phân cấp không thể dẫn xuất khóa: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ể trực tiếp sử dụng BIP32 để phái sinh khóa dựa trên việc phân chia khóa riêng;

  • Rủi ro thông đồng:Nếu oracle Thông đồng giữa các nút máy hoặc thông đồng với các bên tham gia vẫn không giải quyết được vấn đề tin cậy vào máy oracle. Cần có cơ chế giám sát đáng tin cậy để giảm thiểu sự tin cậy của oracle;

  • Vấn đề thay đổi mệnh giá cố định:Cần xác định chữ ký có điều kiện trước khi xây dựng hợp đồng Một bộ sưu tập các vô số sự kiện để xây dựng các giao dịch. Do đó, sẽ có giới hạn số lượng tối thiểu để DLC được sử dụng để 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 nhằm giải quyết các rủi ro và vấn đề của DLC và cải thiện tính bảo mật của hệ sinh thái Bitcoin.

  2. Nguyên tắc DLC

  Alice và Bob ký thỏa thuận cá cược: đặt cược xem giá trị băm của khối thứ n+k là số lẻ hay 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 trong 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:Nhà tiên tri, Alice và Bob tạo khóa riêng và khóa chung của riêng họ một cách độc lập.

  • Khóa riêng của oracle là z, khóa chung là Z và mối quan hệ Z=z⋅G được thỏa mãn;

  • Khóa riêng của Alice là x và khóa chung 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 là Y, thỏa mãn mối quan hệ Y=y⋅G.

  Giao dịch 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 1BTC trong đầu ra 2 trên 2 chữ ký. ( Khóa công khai X thuộc về Alice và khóa chung Y thuộc về Bob).

  Giao dịch thực thi 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.

  Nhà tiên tri tính toán cam kết

  $R:=k ⋅ G$

  Sau đó, tính S và S'

  $S:=R-hash(OddNumber,R) ⋅  Z,$

  $S':=R-hash(EvenNumber,R) ⋅  Z$

  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

  $PK^{Alice}:=X+ S,$

  $PK^{Bob}: =Y+ S'.$

  Giải quyết: Khi khối n+k xuất hiện, máy oracle tạo ra s hoặc s tương ứng dựa trên giá trị băm của khối '.

  • Nếu giá trị băm của khối thứ n+k là số lẻ, oracle sẽ tính toán và phát sóng s

  $s:=k-hash(OddNumber,R) ⋅ z$

  • Nếu n+k Nếu giá trị băm của một khối là một số chẵn, oracle tính toán và phát sóng s'

  $s':=k-hash(EvenNumber,R) ⋅ z$ < /p>

  Rút tiền: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 s hoặc s' được máy oracle phát đi.

  • Nếu nhà tiên tri phát sóng s, Alice có thể tính khóa riêng mới sk^{Alice} và trích xuất 2 BTC bị khóa

  $sk^{Alice}:= x + s.$

  • Nếu Nhà tiên tri phát sóng s', thì Bob có thể tính toán khóa riêng mới sk^{Bob} và trích xuất 2 BTC bị khóa

  $sk^{Bob}:= y + s'. $

  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

  $sk^{Alice} ⋅  G= (x+s) ⋅  G=X+S=PK^{Alice}$

  Trong trường hợp này, việc rút tiền của Alice sẽ thành công.

  Tương tự, 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

  $sk^{Bob} ⋅ G = (y+s') ⋅ G=Y+S'=PK^{Bob}$

  Trong trường hợp này, việc rút tiền của Bob sẽ thành công.

  Ngoài ra, 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, phần mô tả ở trên bỏ qua việc khóa thời gian. Cần phải thêm khóa thời gian để một bên có thể 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.

  3. Tối ưu hóa 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 đã cam kết là rất quan trọng. Nếu khóa riêng của máy 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 bị rò rỉ khóa riêng z

  Nếu khóa riêng của máy oracle bị rò rỉ, tất cả DLC đều dựa trên khóa riêng sẽ phải đối mặt với rủi ro thanh toán 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 nhau, 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 máy oracle rò rỉ số ngẫu nhiên k thì trong giai đoạn giải quyết, bất kể máy oracle phát sóng s hay s', kẻ tấn công có thể tính khóa riêng z của máy oracle như sau

  $z:=(k-s)/hash(OddNumber, R)$

  $z:= (k-s')/hash(EvenNumber, R)$

  Nếu nhà tiên tri 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ể sử dụng phát sóng chữ ký bởi oracle, theo 4 tình huống sau Giải hệ phương trình tìm khóa riêng z của máy oracle,

  Trường hợp 1:

  $s_1=k-hash( OddNumber_1, R) ⋅ z$

  $s_2=k-hash(OddNumber_2, R) ⋅ z$

  Trường hợp 2:

  $s_1'=k -hash(EvenNumber_1, R) ⋅ z$< /p>

  $s_2'=k-hash(EvenNumber_2, R) ⋅ z$

  Trường hợp 3:

  $ s_1=k-hash(OddNumber_1, R) ⋅ z$

  $s_2'=k-hash(EvenNumber_2, R) ⋅ z$

  Trường hợp 4:

  < p>$s_1'=k-hash(EvenNumber_1 , R) ⋅ z$

  $s_2=k-hash(OddNumber_2, R) ⋅ z$

  (4 ) Máy oracle mất số ngẫu nhiên k

  Nếu oracle mất số ngẫu nhiên k thì không thể giải quyết được DLC tương ứng và hợp đồng hoàn trả DLC phải được thực hiện.

  Vì vậy, để nâng cao tính bảo mật của khóa riêng oracle, nên sử dụng BIP32 để lấy khóa con hoặc khóa cháu cho chữ 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, vai trò của oracle là rất 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 có thể nhận ra một 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ý các khóa phi tập trung, chữ ký ngưỡng được giảm đi sẽ loại bỏ nguy cơ xảy ra lỗi ở một điểm duy nhất. 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 kiểm soát phân tán đối với việc quản lý khóa. Không một thực thể nào có toàn bộ quyền ký, do đó giảm bớt quyền lực Rủi ro từ quá nhiều sự tập trung.

  • Cải thiện tính khả dụng: Chỉ một số nút oracle nhất định cần đồng ý để hoàn thành chữ ký, 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 nhu 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.

  • Khả năng 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 tư và những người tham gia khác có thể sử dụng đoạn khóa chung tương ứng để xác minh tính chính xác của đoạn chữ ký để đạ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 ưu điểm rõ ràng 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 quyền và quản lý khóa

  Trong công nghệ quản lý khóa, 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 BIP32 có thể tạo ra một lượng lớn số lượng khóa con z+{ω }^{(1)} và khóa cháu 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. Mỗi nút trong số n nút oracle có một đ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' cho thông điệp tin nhắn' và các đoạn chữ ký σ_i' được hợp nhất thành chữ ký hoàn chỉnh σ '. Người xác minh có thể xác minh tính đúng đắn của cặp chữ ký thông điệp (msg',σ ') bằng cách sử dụng khóa chung Z hoàn chỉnh. Vì các nút oracle t+1 được yêu cầu phải 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 của các nhà tiên tri phi tập trung, khóa riêng z hoàn chỉnh không xuất hiện và BIP32 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.

  Bài viết Dẫn xuất khóa phân tán để quản lý nhiều bên đối với tài sản kỹ thuật số Blockchain đề xuất một phương pháp phái sinh khóa phân tán trong kịch bản chữ ký ngưỡng. Ý 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 số gia ω vào cả hai vế của phương trình trên, 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 đoạn khóa riêng hoàn chỉnh phím z cộng với số gia ω. 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+ω, được sử dụng để tạo đoạn chữ ký phụ và sử dụng khóa công khai phụ tương ứng Z+ω ⋅   G Có thể thực hiện xác minh tính hợp lệ.

  Tuy nhiên, BIP32 nâng cao và không nâng cao cần được xem xét. BIP32 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 SHA512 và xuất mã tăng dần và mã chuỗi phụ. BIP32 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 SHA512 và xuất ra mã tăng dần và mã 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 BIP32 không nâng cao. Hoặc sử dụng hàm băm đồng cấu, có BIP32 nâng cao. Tuy nhiên, hàm băm đồng cấu khác với SHA512 và không tương thích với BIP32 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, vì vậy nó cần phải được thực hiện theo một ở một mức độ nhất định. Hãy tin vào lời tiên tri. 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 các máy oracle, đã có những nghiên cứu về việc thực thi DLC ​​dựa trên kết quả của các máy oracle nhằm giảm sự phụ thuộc vào một máy oracle duy nhất.

  • Mô hình "n-of-n" có nghĩa là 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 lời tiên tri. 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.

  • Mô hình "k-of-n" có nghĩa là sử dụng n oracles để ký hợp đồng, theo k Hợp đồng được thực hiện dựa trên kết quả của máy oracle. 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, khi sử dụng mô hình "k-of-n", số lượng CET cần chuẩn bị gấp C_n^k lần so với mô hình oracle đơn lẻ hoặc mô hình "n-of-n". Giả định về độ tin cậy là ít nhất k oracle trong số n oracle đều trung thực.

  Việc tăng số lượng máy oracle không đạt được sự mất lòng tin vào 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, giới thiệu cơ chế thử thách lạc quan trong DLC. Trước khi n oracles tham gia thiết lập DLC, họ cần cam kết trước sẽ xây dựng một trò chơi OP on-chain không cần xin phép và hứa không làm điều ác. Nếu bất kỳ nhà tiên tri nào làm điều ác, 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 ký bằng mô hình "k-of-n". Trong số đó, giá trị 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, 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ả sai, gây ra Lợi ích của Alice bị tổn hại, Alice có thể sử dụng Layer2 để tính toán chính xác kết quả và thách thức trò chơi OP trên chuỗi không được phép, nơi lời tiên tri được 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;

  • Tương tự như vậy, 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 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.

  3.5 Cầu kép OP-DLC + BitVM

  Khi DLC được sử dụng làm cầu nối chuỗi chéo, cần phải phân bổ vốn khi hợp đồng DLC ​​được giải quyết:

  • Cần được CET đặt trước. Điều này có nghĩa là mức độ chi tiết trong việc thanh toán quỹ của DLC bị hạn chế, chẳng hạn như mức độ chi tiết của mạng Bison là 0,1 BTC. 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 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, oracle 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 được cung cấp cho người dùng Alice có thể được sử dụng ngay lập tức trên Lớp 1 và trong đầu ra được cung cấp cho Bob, "trò chơi DLC mà Alice có thể tham gia thử thách" được xây dựng và khóa thời gian thời gian khóa đượ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 tại Layer1. Tuy nhiên, Bob có thể rút tiền ở Lớp 1 sau khi hết thời gian khóa.

  • 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ị tịch thu. 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ách sau phương thức:

  • Rút tiền thông qua BitVM, được nhà điều hành BitVM nâng cao trên Layer1. Cầu BitVM giả định một người tham gia trung thực trong liên minh 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 chuyển tiếp trong Layer1. 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 Layer1 mà không buộc những người dùng Layer2 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 oracle, yêu cầu Bob phải hợp tác.

  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;

  • Kết hợp cầu OP-DLC và Cầu nối BitVM, Người dùng được cung cấp nhiều kênh rút tiền và gửi tiền khác nhau và có thể thực hiện 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, rồi sử dụng cơ chế OP để giảm thiểu niềm tin vào oracle;< /p>

  • Đưa số dư rút của kênh DLC vào nhóm 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à Lightning Network đã được triển khai, và DLC Nó đã được mở rộng để cho phép các hợp đồng liên tục được cập nhật và thực thi 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.

  Tài liệu tham khảo

  1. Thông số kỹ thuật cho Hợp đồng nhật ký kín đáo

  2. Hợp đồng nhật ký kín đáo< / p>

  3. Mở rộng DLC Phần 1: Hợp đồng nhật ký kín đáo ngoài chuỗi

  4. Mở rộng DLC ​​​​Part2: Vấn đề tùy chọn miễn phí với DLC

  5. Mở rộng DLC ​​​​Part3: Cách tránh sự cố tùy chọn miễn phí với DLC

  6. Sét Mạng

  a>

  7. DLC trên Lightning < /p>

  8. Phần quản lý khóa riêng tư DLC 1

  9. Quản lý khóa riêng DLC ​​Phần 2: Khóa riêng của Oracle

  10. Quản lý khóa DLC Phần 3: Phân phối khóa công khai của Oracle

  11. BitVM: Tính toán mọi thứ trên Bitcoin

  12. BitVM 2: Xác minh không cần cấp phép đối với Bitcoin

  13. Hợp đồng Bitcoin ngoài chuỗi BitVM

  14. BIP32BIP44

  15. Chữ ký Schnorr

  < li>

  FROST: Chữ ký ngưỡng Schnorr được tối ưu hóa theo vòng linh hoạt

  16. Khảo sát về việc ký ngưỡng ECDSA

  17. Đạo hàm chính được phân phối để quản lý nhiều bên đối với tài sản kỹ thuật số Blockchain

  18. Nhân chứng tách biệt

  19. Bản tổng hợp lạc quan

  20. Taproot

  Liên kết gốc