1. Giới thiệu

The Discreet Log Contract (DLC) là một khung thực thi hợp đồng dựa trên một Oracle, được đề xuất bởi Tadge Dryja của Viện Công nghệ Massachusetts 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. Các bên xác định các kết quả có thể xảy ra, ký trước chúng và sử dụng những chữ ký trước đó để thực hiện thanh toán khi Oracle ký duyệt kết quả. Do đó, DLC cho phép các ứng dụng tài chính phi tập trung mới trong khi đảm bảo an toàn cho các khoản tiền gửi Bitcoin.

So với Lightning Network, DLC có những lợi ích đáng kể sau đây:

• Quyền riêng tư: DLC cung cấp bảo vệ quyền riêng tư tốt hơn so với Mạng Lightning. Chi tiết hợp đồng chỉ được chia sẻ giữa các bên liên quan và không được lưu trữ trên chuỗi khối. Ngược lại, các giao dịch trên Mạng Lightning được định tuyến thông qua các kênh và nút công khai, khiến thông tin của họ trở nên công khai và minh bạch.
• Độ phức tạp và tính linh hoạt của hợp đồng tài chính: DLC có thể trực tiếp tạo và thực thi các hợp đồng tài chính phức tạp trên mạng Bitcoin, chẳng hạn như hợp đồng tương lai, bảo hiểm và cá cược, trong khi Mạng Lightning chủ yếu được sử dụng cho thanh toán nhanh, giá trị nhỏ và không thể hỗ trợ các ứng dụng phức tạp.
• Rủi ro đối tác giảm: Quỹ DLC được khóa trong các hợp đồng đa chữ ký và chỉ được giải phóng khi kết quả của một sự kiện đã được xác định xảy ra, giảm thiểu rủi ro của bất kỳ bên nào không tuân theo hợp đồng. Mặc dù Lightning Network giảm thiểu nhu cầu tin cậy, nhưng vẫn mang theo một số rủi ro đối tác cụ thể trong quản lý kênh và cung cấp thanh khoản.
• Không cần quản lý các kênh thanh toán: Các hoạt động DLC không đòi hỏi việc tạo ra hoặc duy trì các kênh thanh toán, mà đó là yếu tố trung tâm của Lightning Network và liên quan đến việc quản lý 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ể: Trong khi Lightning Network tăng khả năng xử lý giao dịch của Bitcoin một cách đáng kể, 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ù DLCs mang lại nhiều lợi ích đáng kể trong hệ sinh thái Bitcoin, nhưng vẫn còn một số rủi ro và vấn đề, chẳng hạn như:

• Rủi ro chính: Có nguy cơ rò rỉ hoặc mất chìa khóa riêng của Oracle và các số nonce đã cam kết, dẫn đến mất tài sản của người dùng.
• Rủi ro Tín dụng Tập trung: Tính tập trung trong các Oracle dễ dẫn đến các cuộc tấn công từ chối dịch vụ một cách dễ dàng.
• Vấn đề Phát Sinh Khóa Phân Cấp Phi Tập Trung: Nếu Oracle là phi tập trung, các nút Oracle chỉ sở hữu các phần của 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 để tạo khóa dựa trên các phần khóa riêng này.
• Rủi ro kết hợp: Nếu các nút Oracle kết hợp với nhau hoặc với một bên, vấn đề tin cậy với Oracles vẫn chưa được giải quyết. Cơ chế giám sát đáng tin cậy cần được thiết lập để giảm thiểu sự tin cậy vào Oracles.
• Vấn đề Thay Đổi Mệnh Giá Cố Định: Chữ ký điều kiện yêu cầu một tập hợp xác định, có thể liệt kê các sự kiện trước khi xây dựng hợp đồng để tạo giao dịch. Do đó, việc sử dụng DLC cho việc phân phối lại tài sản có hạn chế về số tiền tối thiểu, dẫn đến vấn đề về việc thay đổi mệnh giá cố định.

Để giải quyết những vấn đề này, bài báo này đề xuất một số giải pháp và ý tưởng tối ưu hóa để giảm thiểu các rủi ro và vấn đề liên quan đến DLCs, từ đó nâng cao tính bảo mật của hệ sinh thái Bitcoin.

2. Nguyên lý DLC

Alice và Bob ký một thỏa thuận cược về việc giá trị băm của khối (n+k) có phải là số lẻ hay chẵn. Nếu là số lẻ, Alice thắng cuộc và có thể rút tài sản trong thời gian t; nếu là số chẵn, Bob thắng cuộc và có thể rút tài sản trong thời gian t. Sử dụng DLC, thông tin khối (n+k) được truyền qua một Oracle để xây dựng chữ ký có điều kiện, đảm bảo người chiến thắng đúng nhận tất cả tài sản.

Khởi tạo: Bộ tạo ra của đường cong elip là G, và thứ tự của nó là q.

Sinh khóa: Oracle, Alice và Bob tạo ra các khóa riêng và khóa công khai của họ một cách độc lập.

• Khóa riêng của Oracle là z, và khóa công khai của nó là Z, thỏa mãn Z=z⋅G;
• Chìa khóa riêng của Alice là x, và chìa khóa công khai của cô ấy là X, thỏa mãn X=x⋅G;
• Khóa riêng của Bob là y, và khóa công khai của anh ấy là Y, thỏa mãn Y=y⋅G.

Giao dịch tài trợ: Alice và Bob tạo một giao dịch tài trợ cùng nhau, khóa 1 BTC mỗi người trong một đầu ra đa chữ ký 2 trên 2 (một khóa công khai X thuộc về Alice và khóa Y khác thuộc về Bob).

Giao dịch thực hiện hợp đồng (CET): Alice và Bob tạo hai CET để chi tiêu giao dịch tài trợ.

Người tiên tri tính toán sự cam kết

và sau đó tính toán S và S′

và 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

Thanh toán: Sau khi khối (n+k) xuất hiện, 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 (n+k) là lẻ, Oracle tính toán và phát sóng

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

Rút tiền: Cả Alice lẫn Bob đều có thể rút tiền dựa trên s hoặc s′ được phát sóng bởi Oracle.

• Nếu Oracle phát sóng s, Alice có thể tính toán 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 toán 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} được tính bởi Alice và khóa công khai mới PK^{Alice} thỏa mãn mối quan hệ logarit rời rạc

Do đó, 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} được tính toán bởi Bob và khóa công khai mới PK^{Bob} thỏa mãn mối quan hệ logarith rời rạc

Do đó, việc rút tiền của Bob sẽ thành công.

Ngoài ra, nếu Oracle phát sóng s, điều này hữu ích cho Alice, nhưng không hữu ích cho Bob vì Bob không thể tính toán được khóa bí mật mới tương ứng sk^{Bob}. Tương tự, nếu Oracle phát sóng s′, điều này hữu ích cho Bob, nhưng không hữu ích cho Alice vì Alice không thể tính toán được khóa bí mật mới tương ứng sk^{Alice}. Cuối cùng, mô tả trên đã bỏ qua khóa thời gian. Một khóa thời gian phải được thêm vào để cho phép một bên tính toán khóa bí mật mới và rút tiền trong thời gian t. Nếu không, nếu vượt quá thời gian t, bên kia có thể sử dụng khóa bí mật ban đầu để rút tiền.

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à nonce cam kết là rất quan trọng. Sự rò rỉ hoặc mất khóa riêng của Oracle và nonce cam kết có thể dẫn đến bốn vấn đề bảo mật sau:

(1) Oracle Mất Khóa Riêng z

Nếu Oracle mất khóa riêng, DLC không thể giải quyết, buộc phải thực hiện hợp đồng hoàn tiền DLC. Do đó, giao thức DLC bao gồm giao dịch hoàn tiền để ngăn chặn hậu quả khi Oracle mất khóa riêng.

(2) Sự rò rỉ Khóa riêng tư của Oracle z

Nếu khóa riêng của Oracle bị rò rỉ, tất cả các hợp đồng thông minh dựa trên khóa riêng đó đều đối mặt với nguy cơ thanh toán gian lận. Kẻ tấn công nào đó lấy cắp khóa riêng có thể ký bất kỳ thông điệp mong muốn nào, 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 chỉ việc phát hành một thông điệp được ký duy nhất mà còn có thể công bố các thông điệp mâu thuẫn, chẳng hạn như ký rằng giá trị băm của khối (n+k) lẻ và chẵn.

(3) Rò rỉ hoặc tái sử dụng Nonce k của Oracle

Nếu Oracle rò rỉ nonce k, thì tại 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 toán khóa riêng của Oracle z như sau:

Nếu Oracle tái sử dụng nonce k, sau hai lần giải quyết, một kẻ tấn công có thể giải hệ phương trình dựa trên chữ ký phát sóng của Oracle để suy luận khóa riêng của Oracle z trong một trong bốn kịch bản có thể xảy ra,

case 1:

case 2:

trường hợp 3:

case 4:

(4) Oracle Mất Nonce k

Nếu Oracle mất nonce k, DLC tương ứng sẽ không thể giải quyết, buộc phải thực hiện hợp đồng hoàn tiền DLC.

Do đó, để tăng cường bảo mật cho khóa riêng của Oracle, nên sử dụng BIP32 để tạo ra các khóa con hoặc cháu để ký. Ngoài ra, để tăng cường bảo mật cho nonce, giá trị băm k:=hash(z, counter) nên được sử dụng làm nonce k, để ngăn sự lặp lại hoặc mất mát của nonce.

3.2 Decentralized Oracle

Trong DLC, vai trò của Oracle rất quan trọng vì nó cung cấp dữ liệu bên ngoài quan trọng để xác định kết quả của hợp đồng. Để tăng cường an ninh cho các hợp đồng này, cần có Oracles phi tập trung. Khác với Oracles tập trung, Oracles phi tập trung phân phối trách nhiệm cung cấp dữ liệu chính xác và không thể can thiệp trên nhiều nút độc lập, giảm thiểu rủi ro liên quan đến một điểm thất bại duy nhất và giảm thiểu khả năng bị can thiệp hoặc tấn công mục tiêu. Với một Oracle phi tập trung, DLCs có thể đạt được một mức độ tin cậy và đáng 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 trên tính khách quan của các điều kiện đã quyết định trước.

Chữ ký ngưỡng Schnorr có thể được sử dụng để triển khai các Oracle phi tập trung. Chữ ký ngưỡng Schnorr cung cấp các lợi ích sau:

• Bảo mật nâng cao: Bằng cách phân phối quản lý các khóa, chữ ký ngưỡng giảm thiểu rủi ro của điểm hỏng duy nhất. Ngay cả khi một số khóa của các bên tham gia bị xâm nhập hoặc tấn công, toàn bộ hệ thống vẫn an toàn miễn là việc xâm nhập không vượt quá ngưỡng được xác định trước.
• Kiểm soát phân phối: Chữ ký ngưỡng cho phép kiểm soát phân phối về quản lý khóa, loại bỏ một thực thể duy nhất giữ tất cả quyền ký, do đó giảm thiểu các rủi ro liên quan đến tập trung quyền lực.
• Sự sẵn có được cải thiện: Chữ ký có thể được hoàn thành miễn là một số lượng nhất định các nút Oracle đồng ý, tăng tính linh hoạt và sẵn có của hệ thống. Ngay cả khi một số nút không khả dụng, tính đáng tin cậy của hệ thống tổng thể không bị ảnh hưởng.
• Tính linh hoạt và khả năng mở rộng: Giao thức chữ ký ngưỡng có thể thiết lập ngưỡng khác nhau theo nhu cầu để đáp ứng các yêu cầu bảo mật và kịch bản khác nhau. Ngoài ra, nó phù hợp cho các mạng quy mô lớn, cung cấp tính mở rộng tốt.
• Trách nhiệm: Mỗi nút Oracle tạo ra một phần chia chữ ký dựa trên phần chia khóa riêng, và những người tham gia khác có thể xác minh tính chính xác của phần chia chữ ký này bằng cách sử dụng phần chia khóa công khai tương ứng, cho phép trách nhiệm. Nếu chính xác, những phần chia chữ ký này được tích lũy để tạo ra một chữ ký hoàn chỉnh.

Do đó, giao thức chữ ký ngưỡng Schnorr có những ưu điểm đáng kể trong Oracles phi tập trung về việc cải thiện an ninh, đáng tin cậy, linh hoạt, khả năng mở rộng và trách nhiệm.

3.3 Kết nối giữa phân quyền và quản lý khóa

Trong công nghệ quản lý khóa, một Oracle sở hữu một khóa z hoàn chỉnh và, sử dụng BIP32 cùng với các gia tăng ω, có thể tạo ra nhiều khóa con z+ω^{(1)} và khóa cháu z+ω^{(1)}+ω^{(2)}. Đối với các sự kiện khác nhau, Oracle có thể sử dụng các khóa riêng z+ω^{(1)}+ω^{(2)} để tạo ra chữ ký tương ứng σ cho các sự kiện tương ứng msg.

Trong kịch bản Oracle phi tập trung, có n người tham gia, và chữ ký ngưỡng đòi hỏi t+1 người tham gia, trong đó t

Tuy nhiên, trong kịch bản Oracle phi tập trung, khóa riêng tư hoàn chỉnh z không xuất hiện, và do đó việc suy luận khóa trực tiếp bằng cách sử dụng BIP32 không khả thi. Nói cách khác, công nghệ Oracle phi tập trung và công nghệ quản lý khóa không thể được tích hợp trực tiếp.

Bài báo “Phân phối khóa tạo dẫn cho Quản lý Đa bên của Tài sản Kỹ thuật số BlockchainĐề xuất một hệ thống phân phối khóa phân tán trong các kịch bản chữ ký ngưỡng. Ý tưởng cốt lõi dựa trên đa thức nội suy Lagrange, trong đó phần chia khóa riêng z_i và khóa riêng hoàn chỉnh z thỏa mãn mối quan hệ nội suy sau:

Thêm increment ω vào cả hai bên của phương trình cho kết quả là:

Phương trình này cho thấy rằng phần chia khóa riêng tư z_i cộng với bước nhảy ω vẫn thỏa mãn mối quan hệ nội suy với khóa riêng tư hoàn chỉnh z cộng ω. Nói cách khác, phần chia khóa riêng tư con z_i+ω và khóa con z+ω thỏa mãn mối quan hệ nội suy. Do đó, mỗi người tham gia có thể sử dụng phần chia khóa riêng tư z_i cộng với bước nhảy ω của họ để tạo ra phần chia khóa riêng tư con z_i+ω, sử dụng để tạo ra phần chia chữ ký con và xác minh chúng bằng cách sử dụng khóa công khai con tương ứng Z+ω⋅G.

Tuy nhiên, người ta phải xem xét về BIP32 cứng và không cứng. BIP32 cứng lấy khóa riêng, mã chuỗi và đường dẫn làm đầu vào, thực hiện SHA512 và đầu ra là tăng và mã chuỗi con. BIP32 không cứng, ngược lại, lấy khóa công khai, mã chuỗi và đường dẫn làm đầu vào, thực hiện SHA512 và đầu ra là tăng và mã chuỗi con. Trong kịch bản chữ ký ngưỡng, khóa riêng không tồn tại, vì vậy chỉ có thể sử dụng BIP32 không cứng. Hoặc, sử dụng một hàm băm đồng cấu, BIP32 cứng có thể được áp dụng. Tuy nhiên, một hàm băm đồng cấu khác biệt so với SHA512 và không tương thích với BIP32 ban đầu.

3.4 OP-DLC: Oracle Trust-minimized

Trong DLC, hợp đồng giữa Alice và Bob được thực hiện dựa trên kết quả đã được ký của Oracle, do đó đòi hỏi một mức độ tin cậy nhất định vào Oracle. Do đó, hành vi chính xác của Oracle là một điều kiện quan trọng cho hoạt động của DLC.

Để giảm sự tin cậy vào Oracle, đã tiến hành nghiên cứu về việc thực hiện DLC dựa trên kết quả của n Oracles, giảm sự phụ thuộc vào một Oracle duy nhất.

• Mô hình “n-of-n” bao gồm việc sử dụng n Oracles để ký hợp đồng và thực thi hợp đồng dựa trên kết quả của tất cả Oracles. Mô hình này đòi hỏi tất cả Oracles phải online để ký. Nếu bất kỳ Oracle nào bị offline hoặc có sự không đồng ý về kết quả, nó ảnh hưởng đến việc thực thi hợp đồng DLC. Giả định tin cậy ở đây là tất cả các Oracles đều trung thực.
• Mô hình “k-of-n” liên quan đến việc sử dụng n Oracles để ký hợp đồng, thực hiện hợp đồng dựa trên kết quả của bất kỳ k Oracles nào. Nếu hơn k Oracles âm mưu, nó ảnh hưởng đến việc thực hiện công bằng của hợp đồng. Hơn nữa, số lượng CETs cần thiết trong mô hình “k-of-n” là C_n^k lần so với một Oracle đơn lẻ hoặc mô hình “n-of-n”. Giả định tin cậy trong mô hình này là ít nhất k trong số n Oracles là trung thực.

Chỉ đơn giản việc tăng số lượng Oracles không đạt được sự không tin cậy vào các Oracles vì sau khi một Oracle thực hiện hành vi độc hại, bên bị hại trong hợp đồng không có cách giải quyết trên chuỗi.

Do đó, chúng tôi đề xuất OP-DLC, mà kết hợp một cơ chế thách thức lạc quan vào DLC. Trước khi tham gia thiết lập DLC, n Oracles cần cam kết và xây dựng một trò chơi OP trên chuỗi không cần phép, cam kết không hành động độc hại. Nếu bất kỳ Oracle nào hành động độc hại, thì Alice, Bob, bất kỳ Oracle trung thực nào khác, hoặc bất kỳ quan sát viên trung thực của bên thứ ba nào khác cũng có thể khởi xướng một thách thức. Nếu người thách thức chiến thắng trò chơi, hệ thống trên chuỗi sẽ phạt Oracle độc hại bằng cách tịch thu tiền đặt cọc của nó. Ngoài ra, OP-DLC cũng có thể áp dụng mô hình “k-of-n” cho việc ký, trong đó giá trị k có thể là 1. Do đó, giả định về sự tin cậy được giảm xuống chỉ cần một người tham gia trung thực trong mạng lưới để khởi xướng một thách thức OP và phạt một nút Oracle độc hại.

Khi thanh toán OP-DLC dựa trên kết quả tính toán Layer 2:

• Nếu một Oracle ký với kết quả không chính xác, gây thiệt hại cho Alice, Alice có thể sử dụng kết quả tính toán chính xác của Layer 2 để thách thức trò chơi OP trên chuỗi không cần quyền trước của Oracle. Chiến thắng trò chơi, Alice có thể trừng phạt Oracle độc hại và bồi thường cho thiệt hại của mình.
• Tương tự, Bob, các nút Oracle trung thực khác và các quan sát viên trung thực của bên thứ ba cũng có thể khởi động các thách thức. Tuy nhiên, để ngăn chặn các thách thức độc hại, người thách thức cũng phải cam kết.

Do đó, OP-DLC giúp việc giám sát chéo lẫn nhau giữa các nút truy vấn, giảm thiểu sự tin tưởng đặt vào các truy vấn. Cơ chế này chỉ cần một bên tham gia trung thực và có khả năng chịu lỗi 99%, hiệu quả đối phó với nguy cơ kết hợp của Oracle.

3.5 OP-DLC + BitVM Dual Bridge

Khi DLC được sử dụng cho cầu nối giữa chuỗi, việc phân phối quỹ phải diễn ra khi hợp đồng DLC được thanh toán:

• Nó đòi hỏi thiết lập trước thông qua CETs, có nghĩa là độ tinh mịch thanh toán quỹ của DLC bị hạn chế, chẳng hạn như 0.1 BTC trong mạng lưới Bison. Điều này đặt ra một vấn đề: Tương tác tài sản Layer 2 cho người dùng không nên bị hạn chế bởi độ tinh mịch quỹ của DLC CETs.
• Khi Alice muốn thanh toán tài sản Layer 2 của mình, điều đó buộc việc thanh toán tài sản Layer 2 của người dùng Bob sang Layer 1. Điều này đặt ra một vấn đề: mỗi người dùng Layer 2 nên có quyền lựa chọn gửi và rút tiền độc lập khỏi các hành động của người dùng khác.
• Alice và Bob đàm phán về việc chi tiêu. Vấn đề ở đây là nó đòi hỏi cả hai bên đều sẵn lòng hợp tác.

Vì vậy, để giải quyết vấn đề đã đề cập, chúng tôi đề xuất cầu nối 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 qua cầu nối không cần phép của BitVM cũng như thông qua cơ chế OP-DLC, đạt được sự thay đổi ở mọi độ tinh nhất và tăng cường tính thanh khoản.

Trong OP-DLC, Oracle là liên minh BitVM, với Alice là người dùng thông thường và Bob là liên minh BitVM. Khi thiết lập OP-DLC, CETs được xây dựng cho phép chi tiêu ngay lập tức của đầu ra của Alice trên Layer 1, trong khi đầu ra của Bob bao gồm một “trò chơi DLC mà Alice có thể thách thức” với một khoảng thời gian khóa. Khi Alice muốn rút tiền:

• Nếu liên minh BitVM, hoạt động như Oracle, ký đúng, Alice có thể rút tiền ở Layer 1. Tuy nhiên, Bob có thể rút tiền ở Layer 1 sau khoảng thời gian khóa thời gian.
• Nếu liên minh BitVM, hành động như một người Oracle, gian lận, gây thiệt hại cho Alice, cô ấy có thể thách thức UTXO của Bob. Nếu thách thức thành công, số tiền của Bob có thể bị tịch thu. Lưu ý: một thành viên khác của liên minh BitVM cũng có thể khởi xướng thách thức, nhưng Alice, là bên bị hại, có động lực nhất để làm như vậy.
• Nếu liên minh BitVM, đóng vai trò là Oracle, gian lận, gây thiệt hại cho Bob, 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” để trừng phạt nút Oracle gian lận.

Hơn nữa, nếu người dùng Alice muốn rút tiền từ Layer 2 nhưng số CET được đặt trước trong hợp đồng OP-DLC không khớp với số lượng, Alice có thể chọn các phương pháp sau:

• Rút tiền qua BitVM, với người vận hành BitVM đứng ra trước số tiền trên Layer 1. Cầu nối BitVM giả định rằng ít nhất có một người tham gia trung thực trong liên minh BitVM.
• Rút tiền qua một số CET cụ thể trong OP-DLC, với số tiền thừa được trả bởi người điều hành BitVM trên Layer 1. Rút tiền qua OP-DLC sẽ đóng kênh DLC, nhưng số tiền còn lại trong kênh DLC sẽ chuyển đến hồ bơi Layer 1 của BitVM, mà không buộc người dùng Layer 2 khác phải rút tiền. Cầu nối OP-DLC giả định rằng ít nhất có một bên trung thực trong kênh.
• Alice và Bob đàm phán về việc tiêu dùng mà không cần sự tham gia của một Oracle, đòi hỏi sự hợp tác từ Bob.

Do đó, cầu nối kép OP-DLC + BitVM cung cấp các lợi ích sau:

• BitVM giải quyết vấn đề thay đổi kênh DLC, giảm số lượng CET cần thiết và không bị ảnh hưởng bởi độ tinh tế quỹ CET;
• Bằng cách kết hợp cầu OP-DLC với cầu BitVM, nó cung cấp cho người dùng nhiều kênh gửi tiền và rút tiền, nâng cao trải nghiệm người dùng;
• Thiết lập hội đồng BitVM với cả Bob và bộ thiên văn học, và sử dụng cơ chế OP, giảm thiểu sự tin tưởng vào bộ thiên văn học;
• Tích hợp việc rút tiền dư thừa từ kênh DLC vào hồ bơi cầu BitVM tăng cường 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à đã được tích hợp với Lightning Network, cho phép mở rộng DLC để cập nhật và thực hiện hợp đồng liên tục trong cùng một kênh DLC. Với các công nghệ như Taproot và BitVM, việc xác minh và giải quyết hợp đồng ngoại chuỗi phức tạp hơn có thể được thực hiện trong DLC. Ngoài ra, bằng cách tích hợp cơ chế thách thức OP, có thể giảm thiểu sự tin cậy vào Oracles.

Tuyên bố:

1. Bài viết này được tái bản từ trung bình, ban đầu có tựa đề “Công nghệ Bitlayer Core: DLC và Những Yếu Tố Tối Ưu Hóa”. Bản quyền thuộc về tác giả gốc, Bitlayer. Nếu có bất kỳ ý kiến phản đối nào về việc tái in này, vui lòng liên hệ với Nhóm Gate Learn. Nhóm sẽ xử lý nó theo các quy trình liên quan càng nhanh càng tốt.

2. Xin lưu ý: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ đại diện cho quan điểm cá nhân của tác giả và không hề cung cấp bất kỳ lời khuyên đầu tư nào.

3. Các phiên bản ngôn ngữ khác của bài viết đã được dịch bởi nhóm Gate Learn. Mà không đề cập đếnGate.io, các bài báo dịch không được sao chép, phổ biến hoặc đạo văn.