1. Pengenalan

Discreet Log Contract (DLC) adalah kerangka eksekusi kontrak berdasarkan Oracle, yang diusulkan oleh Tadge Dryja dari Massachusetts Institute of Technology pada tahun 2018. DLC memungkinkan dua pihak untuk melakukan pembayaran bersyarat berdasarkan kondisi yang telah ditentukan sebelumnya. Para pihak menentukan hasil yang mungkin, menandatanganinya sebelumnya, dan menggunakan tanda tangan sebelumnya ini untuk melakukan pembayaran ketika Oracle menyetujui hasilnya. Oleh karena itu, DLC memungkinkan aplikasi keuangan terdesentralisasi baru sambil memastikan keamanan deposit Bitcoin.

Dibandingkan dengan Jaringan Lightning, DLC memiliki keunggulan signifikan berikut ini:

• Privasi: DLC menawarkan perlindungan privasi yang lebih baik daripada Jaringan Petir. Detail kontrak hanya dibagikan antara pihak-pihak yang terlibat dan tidak disimpan di blockchain. Sebaliknya, transaksi Jaringan Petir diarahkan melalui saluran dan node publik, membuat informasi mereka menjadi publik dan transparan.
• Kompleksitas dan Fleksibilitas Kontrak Keuangan: DLC dapat langsung membuat dan mengeksekusi kontrak keuangan kompleks di jaringan Bitcoin, seperti derivatif, asuransi, dan taruhan, sedangkan Jaringan Lightning terutama digunakan untuk pembayaran cepat nilainya kecil dan tidak dapat mendukung aplikasi kompleks.
• Risiko Kontrapihak yang Dikurangi: Dana DLC dikunci dalam kontrak multi-tanda tangan dan hanya dirilis ketika hasil dari sebuah acara yang telah ditentukan terjadi, mengurangi risiko dari pihak mana pun yang tidak mematuhi kontrak. Meskipun Jaringan Petir mengurangi kebutuhan akan kepercayaan, tetapi masih membawa risiko kontrapihak tertentu dalam manajemen saluran dan penyediaan likuiditas.
• Tidak Perlu Mengelola Saluran Pembayaran: Operasi DLC tidak memerlukan penciptaan atau pemeliharaan saluran pembayaran, yang sangat penting dalam Jaringan Lightning dan melibatkan manajemen yang kompleks dan membutuhkan sumber daya yang intensif.
• Skalabilitas untuk Kasus Penggunaan Tertentu: Sementara Jaringan Lightning agak meningkatkan throughput transaksi Bitcoin, DLC menawarkan skalabilitas yang lebih baik untuk kontrak kompleks di Bitcoin.

Meskipun DLCs memiliki keunggulan signifikan dalam ekosistem Bitcoin, masih ada beberapa risiko dan isu, seperti:

• Resiko Kunci: Ada risiko kebocoran atau kehilangan kunci pribadi Oracle dan nonce yang telah dikomunikasikan, yang dapat menyebabkan kerugian aset pengguna.
• Resiko Kepercayaan Terpusat: Sentralisasi dalam Oracles dengan mudah dapat menyebabkan serangan denial-of-service.
• Masalah Pemunculan Kunci Terdesentralisasi: Jika Oracle terdesentralisasi, node Oracle hanya memiliki bagian dari kunci pribadi. Namun, node Oracle terdesentralisasi tidak dapat langsung menggunakan BIP32 untuk penurunan kunci berdasarkan bagian kunci pribadi ini.
• Risiko Kolusi: Jika node Oracle berkolusi di antara mereka sendiri atau dengan satu pihak, isu kepercayaan dengan Oracle tetap belum terselesaikan. Mekanisme pemantauan yang dapat diandalkan diperlukan untuk meminimalkan kepercayaan pada Oracle.
• Masalah Perubahan Denominasi Tetap: Tanda tangan bersyarat memerlukan kumpulan peristiwa yang dapat ditentukan sebelum membangun kontrak untuk membangun transaksi. Oleh karena itu, menggunakan DLC untuk alokasi aset memiliki pembatasan jumlah minimum, yang mengakibatkan masalah perubahan denominasi tetap.

Untuk mengatasi hal-hal ini, makalah ini mengusulkan beberapa solusi dan ide optimisasi untuk mengurangi risiko dan masalah yang terkait dengan DLC, sehingga meningkatkan keamanan ekosistem Bitcoin.

2. Prinsip DLC

Alice dan Bob memasuki perjanjian taruhan tentang apakah nilai hash dari blok (n+k) ke- ganjil atau genap. Jika ganjil, Alice menang dalam permainan dan dapat menarik aset dalam waktu t; jika genap, Bob menang dalam permainan dan dapat menarik aset dalam waktu t. Dengan menggunakan DLC, informasi blok ke-(n+k) disampaikan melalui Oracle untuk membangun tanda tangan bersyarat, memastikan pemenang yang benar mendapatkan semua aset.

Inisialisasi: Generator dari kurva eliptik adalah G, dan ordernya adalah q.

Generasi kunci: Oracle, Alice, dan Bob secara independen menghasilkan kunci privat dan publik masing-masing.

• Kunci privat Oracle adalah z, dan kuncinya adalah Z, memenuhi Z=z⋅G;
• Kunci pribadi Alice adalah x, dan kuncinya adalah X, memenuhi X=x⋅G;
• Kunci pribadi Bob adalah y, dan kuncinya publik adalah Y, memenuhi Y=y⋅G.

Transaksi pendanaan: Alice dan Bob membuat transaksi pendanaan bersama, mengunci masing-masing 1 BTC dalam output multi-tanda tangan 2 dari 2 (satu kunci publik X milik Alice, dan yang lain Y milik Bob).

Transaksi Eksekusi Kontrak (CET): Alice dan Bob membuat dua CET untuk menghabiskan transaksi pendanaan.

Oracle menghitung komitmen

dan kemudian menghitung S dan S′

dan siaran (R, S, S′).

Alice dan Bob masing-masing menghitung kunci publik baru yang sesuai

Penyelesaian: Setelah blok (n+k) muncul, Oracle menghasilkan s atau s′ yang sesuai berdasarkan nilai hash blok tersebut.

• Jika nilai hash dari blok (n+k) ganjil, Oracle menghitung dan menyiarkan

• Jika nilai hash blok (n+k) adalah genap, Oracle menghitung dan menyiarkan

Penarikan: Baik Alice maupun Bob dapat menarik aset berdasarkan s atau s′ yang disiarkan oleh Oracle.

• Jika Oracle menyiarkan s, Alice dapat menghitung kunci privat baru sk^{Alice} dan menarik 2 BTC yang terkunci

• Jika Oracle menyiarkan s′, Bob dapat menghitung kunci privat baru sk^{Bob} dan menarik 2 BTC yang terkunci

Analisis: Kunci privat baru sk^{Alice} yang dihitung oleh Alice dan kunci publik baru PK^{Alice} memenuhi hubungan logaritma diskrit

Oleh karena itu, penarikan dana Alice akan berhasil.

Demikian pula, kunci privat baru sk^{Bob} yang dihitung oleh Bob dan kunci publik baru PK^{Bob} memenuhi hubungan logaritma diskret

Jadi, penarikan Bob akan berhasil.

Selain itu, jika Oracle menyiarkan s, itu berguna bagi Alice, tetapi tidak bagi Bob karena Bob tidak dapat menghitung kunci pribadi baru yang sesuai sk^{Bob}. Demikian pula, jika Oracle menyiarkan s′, itu berguna bagi Bob, tetapi tidak bagi Alice, karena Alice tidak dapat menghitung kunci pribadi baru yang sesuai sk^{Alice}. Akhirnya, deskripsi di atas mengabaikan kunci waktu. Kunci waktu harus ditambahkan untuk memungkinkan salah satu pihak menghitung kunci pribadi baru dan menarik dalam waktu t. Jika melebihi waktu t, pihak lain dapat menggunakan kunci pribadi asli untuk menarik aset.

3. Optimisasi DLC

3.1 Manajemen Kunci

Dalam protokol DLC, kunci pribadi Oracle dan nonce yang diikat sangat penting. Kebocoran atau kehilangan kunci pribadi Oracle dan nonce yang diikat dapat menyebabkan empat isu keamanan berikut:

(1) Oracle Kehilangan Kunci Pribadi z

Jika Oracle kehilangan kunci privatnya, DLC tidak dapat diselesaikan, yang mengharuskan pelaksanaan kontrak pengembalian DLC. Oleh karena itu, protokol DLC mencakup transaksi pengembalian untuk mencegah konsekuensi kehilangan kunci privat Oracle.

(2) Kebocoran Kunci Pribadi Oracle z

Jika kunci privat Oracle bocor, semua DLC yang didasarkan pada kunci privat tersebut menghadapi risiko penyelesaian penipuan. Penyerang yang mencuri kunci privat dapat menandatangani pesan yang diinginkan, mendapatkan kontrol penuh atas hasil semua kontrak di masa depan. Selain itu, penyerang tidak terbatas pada mengeluarkan satu pesan yang ditandatangani tetapi juga dapat mempublikasikan pesan yang bertentangan, seperti menandatangani bahwa nilai hash blok (n+k) ke-nya genap dan ganjil.

(3) Kebocoran atau Penggunaan Ulang Nonce k oleh Oracle

Jika Oracle bocor nonce k, maka pada fase penyelesaian, tanpa memperhatikan apakah Oracle menyiarkan s atau s′, seorang penyerang dapat menghitung kunci pribadi Oracle z sebagai berikut:

Jika Oracle menggunakan kembali nonce k, maka setelah dua penyelesaian, seorang penyerang dapat memecahkan sistem persamaan berdasarkan tanda tangan siaran Oracle untuk menduga kunci privat Oracle z dalam salah satu dari empat skenario yang mungkin.

kasus 1:

kasus 2:

kasus 3:

kasus 4:

(4) Oracle Kehilangan Nonce k

Jika Oracle kehilangan nonce k, DLC yang sesuai tidak dapat diselesaikan, memerlukan pelaksanaan kontrak pengembalian DLC.

Oleh karena itu, untuk meningkatkan keamanan kunci privat Oracle, disarankan untuk menggunakan BIP32 untuk menurunkan kunci anak atau cucu untuk menandatangani. Selain itu, untuk meningkatkan keamanan nonce, nilai hash k:=hash(z, counter) harus digunakan sebagai nonce k, untuk mencegah pengulangan atau kehilangan nonce.

3.2 Orakel Terdesentralisasi

Dalam DLC, peran Oracle sangat penting karena menyediakan data eksternal kunci yang menentukan hasil kontrak. Untuk meningkatkan keamanan kontrak-kontrak ini, Oracles terdesentralisasi diperlukan. Berbeda dengan Oracles terpusat, Oracles terdesentralisasi mendistribusikan tanggung jawab menyediakan data yang akurat dan tahan manipulasi di sejumlah node independen, mengurangi risiko yang terkait dengan satu titik kegagalan dan mengurangi kemungkinan manipulasi atau serangan tertarget. Dengan Oracle terdesentralisasi, DLC dapat mencapai tingkat ketidakpercayaan dan keandalan yang lebih tinggi, memastikan bahwa pelaksanaan kontrak bergantung sepenuhnya pada objektivitas kondisi yang telah ditetapkan.

Tanda tangan ambang Schnorr dapat digunakan untuk mengimplementasikan Oracle terdesentralisasi. Tanda tangan ambang Schnorr menawarkan berbagai keunggulan berikut:

• Keamanan yang Ditingkatkan: Dengan mendistribusikan manajemen kunci, tanda tangan ambang mengurangi risiko titik kegagalan tunggal. Bahkan jika beberapa kunci peserta dikompromikan atau diserang, seluruh sistem tetap aman selama pelanggaran tidak melebihi ambang batas yang telah ditentukan.
• Distributed Control: Tanda tangan ambang memungkinkan kontrol terdistribusi atas manajemen kunci, menghilangkan entitas tunggal untuk memegang semua kekuatan tanda tangan, dengan demikian mengurangi risiko yang terkait dengan konsentrasi kekuatan.
• Ketersediaan yang Ditingkatkan: Tanda tangan dapat diselesaikan selama sejumlah node Oracle setuju, meningkatkan fleksibilitas dan ketersediaan sistem. Bahkan jika beberapa node tidak tersedia, keandalan sistem secara keseluruhan tidak terpengaruh.
• Fleksibilitas dan Skalabilitas: Protokol tanda tangan ambang dapat mengatur ambang yang berbeda sesuai kebutuhan untuk memenuhi berbagai persyaratan keamanan dan skenario. Selain itu, ini cocok untuk jaringan berskala besar, menawarkan skalabilitas yang baik.
• Akuntabilitas: Setiap simpul Oracle menghasilkan tanda tangan berdasarkan bagian kunci pribadinya, dan peserta lain dapat memverifikasi kebenaran tanda tangan ini menggunakan bagian kunci publik yang sesuai, memungkinkan akuntabilitas. Jika benar, tanda tangan ini dikumpulkan untuk menghasilkan tanda tangan lengkap.

Oleh karena itu, protokol tanda tangan ambang Schnorr memiliki keunggulan signifikan dalam Orakel terdesentralisasi dalam hal meningkatkan keamanan, keandalan, fleksibilitas, skalabilitas, dan akuntabilitas.

3.3 Pengaitan Desentralisasi dan Manajemen Kunci

Dalam teknologi manajemen kunci, sebuah Oracle memiliki kunci lengkap z dan, menggunakan BIP32 bersama dengan penambahan ω, dapat menurunkan berbagai kunci anak z+ω^{(1)} dan kunci cucu z+ω^{(1)}+ω^{(2)}. Untuk peristiwa yang berbeda, Oracle dapat menggunakan berbagai kunci privat cucu z+ω^{(1)}+ω^{(2)} untuk menghasilkan tanda tangan σ yang sesuai untuk pesan-pesan peristiwa tersebut.

Dalam skenario Oracle terdesentralisasi, ada n peserta, dan tandatangan ambang memerlukan t+1 peserta, di mana t

Namun, dalam skenario Oracle terdesentralisasi, kunci privat lengkap z tidak muncul, dan oleh karena itu derivasi kunci langsung menggunakan BIP32 tidak mungkin. Dengan kata lain, teknologi Oracle terdesentralisasi dan teknologi pengelolaan kunci tidak dapat diintegrasikan secara langsung.

Kertas Pemutakhiran Kunci Terdistribusi untuk Manajemen Multi-Pihak Aset Digital Blockchain” mengusulkan skema derivasi kunci terdistribusi dalam skenario tandatangan ambang. Ide inti didasarkan pada polinomial interpolasi Lagrange, di mana bagian kunci privat z_i dan kunci privat lengkap z memenuhi hubungan interpolasi berikut:

Menambahkan penambahan ω ke kedua sisi persamaan menghasilkan:

Persamaan ini menunjukkan bahwa bagian kunci privat z_i ditambahkan dengan penambahan ω masih memenuhi hubungan interpolasi dengan kunci privat lengkap z ditambah ω. Dengan kata lain, bagian kunci privat anak z_i+ω dan kunci anak z+ω memenuhi hubungan interpolasi. Oleh karena itu, setiap peserta dapat menggunakan bagian kunci privat mereka z_i ditambah penambahan ω untuk mendapatkan bagian kunci privat anak z_i+ω, digunakan untuk menghasilkan bagian tanda tangan anak, dan memvalidasi mereka menggunakan kunci publik anak yang sesuai Z+ω⋅G.

Namun, seseorang harus mempertimbangkan BIP32 yang tahan dan tidak tahan. BIP32 yang tahan mengambil kunci privat, kode rantai, dan jalur sebagai masukan, melakukan SHA512, dan mengeluarkan inkremen dan kode rantai anak. BIP32 yang tidak tahan, di sisi lain, mengambil kunci publik, kode rantai, dan jalur sebagai masukan, melakukan SHA512, dan mengeluarkan inkremen dan kode rantai anak. Dalam skenario tanda tangan ambang, kunci privat tidak ada, sehingga hanya BIP32 yang tidak tahan dapat digunakan. Atau, dengan menggunakan fungsi hash homomorfik, BIP32 yang tahan dapat diterapkan. Namun, fungsi hash homomorfik berbeda dari SHA512 dan tidak kompatibel dengan BIP32 asli.

3.4 OP-DLC: Oracle Trust-minimized

Dalam DLC, kontrak antara Alice dan Bob dieksekusi berdasarkan hasil yang ditandatangani oleh Oracle, sehingga memerlukan tingkat kepercayaan tertentu pada Oracle. Oleh karena itu, perilaku yang benar dari Oracle adalah premis utama untuk operasi DLC.

Untuk mengurangi kepercayaan pada Oracle, penelitian telah dilakukan tentang menjalankan DLC berdasarkan hasil dari n Oracle, mengurangi ketergantungan pada satu Oracle saja.

• Model “n-of-n” melibatkan penggunaan n Oracle untuk menandatangani kontrak dan menjalankan kontrak berdasarkan hasil dari semua Oracle. Model ini memerlukan semua Oracle untuk online saat penandatanganan. Jika salah satu Oracle offline atau terjadi ketidaksepakatan pada hasil, hal tersebut memengaruhi pelaksanaan kontrak DLC. Asumsi kepercayaan di sini adalah bahwa semua Oracle jujur.
• Model “k-of-n” melibatkan penggunaan n Orakel untuk menandatangani kontrak, menjalankan kontrak berdasarkan hasil dari k Orakel mana pun. Jika lebih dari k Orakel bersekongkol, itu memengaruhi pelaksanaan kontrak yang adil. Selain itu, jumlah CET yang diperlukan dalam model “k-of-n” adalah C_n^k kali lipat dari satu Orakel atau model “n-of-n”. Asumsi kepercayaan dalam model ini adalah bahwa setidaknya k dari n Orakel adalah jujur.

Hanya meningkatkan jumlah Oracles tidak mencapai de-trust Oracles karena, setelah tindakan jahat oleh Oracle, pihak yang dirugikan dalam kontrak tidak memiliki jalan keluar on-chain.

Oleh karena itu, kami menyarankan OP-DLC, yang menggabungkan mekanisme tantangan optimis ke dalam DLC. Sebelum berpartisipasi dalam menyiapkan DLC, n Orakel perlu menjanjikan dan membangun permainan OP tanpa izin di rantai yang telah diatur sebelumnya, berkomitmen untuk tidak bertindak dengan jahat. Jika ada Oracle yang bertindak dengan jahat, maka Alice, Bob, Orakel jujur lainnya, atau pengamat jujur pihak ketiga lainnya dapat memulai sebuah tantangan. Jika penantang memenangkan permainan, sistem di rantai akan menghukum Oracle yang jahat dengan mengorbankan depositnya. Selain itu, OP-DLC juga dapat mengadopsi model “k-of-n” untuk penandatanganan, di mana nilai k bahkan bisa 1. Oleh karena itu, asumsi kepercayaan dikurangi hanya membutuhkan satu peserta jujur dalam jaringan untuk memulai sebuah tantangan OP dan menghukum node Oracle yang jahat.

Saat menyelesaikan OP-DLC berdasarkan hasil komputasi Layer 2:

• Jika Seorang Oracle menandatangani dengan hasil yang salah, menyebabkan Alice menderita kerugian, Alice dapat menggunakan hasil perhitungan Layer 2 yang benar untuk menantang permainan OP on-chain tanpa izin yang dijanjikan oleh Oracle. Dengan memenangkan permainan, Alice dapat menghukum Oracle jahat dan mengganti kerugiannya.
• Demikian pula, Bob, node Oracle jujur lainnya, dan pihak ketiga pengamat jujur juga dapat memulai tantangan. Namun, untuk mencegah tantangan jahat, penantang juga harus melakukan jaminan.

Oleh karena itu, OP-DLC memfasilitasi pengawasan saling antara node orakel, meminimalkan kepercayaan yang ditempatkan pada orakel. Mekanisme ini hanya memerlukan satu peserta jujur ​​dan memiliki toleransi kesalahan 99%, secara efektif mengatasi risiko kolusi Oracle.

3.5 OP-DLC + BitVM Dual Bridge

Ketika DLC digunakan untuk jembatan lintas-rantai, distribusi dana harus terjadi pada penyelesaian kontrak DLC:

• Hal ini memerlukan pra-pengaturan melalui CETs, yang berarti granularitas penyelesaian dana DLC terbatas, seperti 0.1 BTC dalam jaringan Bison. Ini menimbulkan masalah: Interaksi aset Layer 2 untuk pengguna tidak boleh dibatasi oleh granularitas dana CETs DLC.
• Ketika Alice ingin menyelesaikan aset Layer 2-nya, itu memaksa penyelesaian aset pengguna Bob di Layer 2 ke Layer 1 juga. Ini menimbulkan masalah: setiap pengguna Layer 2 harus memiliki kebebasan untuk memilih deposit dan penarikan secara independen dari tindakan pengguna lain.
• Alice dan Bob bernegosiasi pengeluaran. Masalahnya di sini adalah bahwa hal ini memerlukan kedua belah pihak bersedia untuk bekerjasama.

Oleh karena itu, untuk mengatasi masalah yang disebutkan di atas, kami menyarankan jembatan ganda OP-DLC + BitVM. Solusi ini memungkinkan pengguna untuk melakukan deposit dan penarikan melalui jembatan tanpa izin BitVM serta melalui mekanisme OP-DLC, mencapai perubahan pada setiap granularitas dan meningkatkan likuiditas.

Dalam OP-DLC, Oracle adalah federasi BitVM, dengan Alice sebagai pengguna reguler dan Bob sebagai federasi BitVM. Saat menyiapkan OP-DLC, CET yang dibangun memungkinkan pengeluaran langsung dari output Alice di Layer 1, sementara output Bob termasuk 'permainan DLC yang bisa ditantang oleh Alice' dengan periode kunci waktu. Ketika Alice ingin menarik:

• Jika federasi BitVM, yang bertindak sebagai Oracle, menandatangani dengan benar, Alice dapat menarik dana di Layer 1. Namun, Bob dapat menarik dana di Layer 1 setelah periode kunci waktu.
• Jika federasi BitVM, bertindak sebagai Oracle, curang, menyebabkan kerugian pada Alice, dia dapat menantang UTXO Bob. Jika tantangannya berhasil, jumlah Bob dapat disita. Catatan: anggota lain dari federasi BitVM juga dapat memulai tantangan, tetapi Alice, sebagai pihak yang dirugikan, paling termotivasi untuk melakukannya.
• Jika federasi BitVM, yang bertindak sebagai Oracle, curang, menyebabkan kerugian pada Bob, anggota jujur dari federasi BitVM dapat menantang "permainan BitVM" untuk menghukum node Oracle yang curang.

Selain itu, jika pengguna Alice ingin menarik dana dari Layer 2 tetapi CET yang telah ditetapkan dalam kontrak OP-DLC tidak sesuai dengan jumlahnya, Alice dapat memilih metode berikut:

• Menarik melalui BitVM, dengan operator BitVM memajukan jumlahnya di Layer 1. Jembatan BitVM mengasumsikan ada setidaknya satu peserta jujur di federasi BitVM.
• Menarik melalui CET tertentu dalam OP-DLC, dengan sisa kembalian dibiayai oleh operator BitVM di Layer 1. Menarik melalui OP-DLC akan menutup saluran DLC, tetapi dana yang tersisa dalam saluran DLC akan dipindahkan ke kolam BitVM Layer 1, tanpa memaksa pengguna Layer 2 lainnya untuk menarik. Jembatan OP-DLC mengasumsikan bahwa setidaknya ada satu peserta jujur dalam saluran.
• Alice dan Bob bernegosiasi pengeluaran tanpa keterlibatan Oracle, memerlukan kerjasama dari Bob.

Oleh karena itu, jembatan ganda OP-DLC + BitVM menawarkan keuntungan berikut:

• BitVM memecahkan masalah perubahan saluran DLC, mengurangi jumlah CET yang diperlukan, dan tidak terpengaruh oleh granularitas dana CET;
• Dengan menggabungkan jembatan OP-DLC dengan jembatan BitVM, itu memberikan pengguna dengan beberapa saluran untuk deposit dan penarikan, meningkatkan pengalaman pengguna;
• Mengatur konsorsium BitVM sebagai Bob dan orakel, dan memanfaatkan mekanisme OP, meminimalkan kepercayaan pada orakel;
• Mengintegrasikan penarikan berlebih dari saluran DLC ke dalam pool jembatan BitVM meningkatkan pemanfaatan dana.

4. Kesimpulan

DLC muncul sebelum aktivasi Segwit v1 (Taproot) dan telah diintegrasikan dengan Jaringan Lightning, memungkinkan perluasan DLC untuk memperbarui dan menjalankan kontrak kontinu dalam saluran DLC yang sama. Dengan teknologi seperti Taproot dan BitVM, verifikasi kontrak off-chain yang lebih kompleks dan penyelesaian dapat diimplementasikan dalam DLC. Selain itu, dengan mengintegrasikan mekanisme tantangan OP, memungkinkan untuk meminimalkan kepercayaan pada Oracle.

Pernyataan:

1. Artikel ini dicetak ulang darimedium, yang awalnya berjudul “Teknologi Inti Bitlayer: DLC dan Pertimbangan Optimisasinya”. Hak cipta dimiliki oleh penulis asli, Bitlayer. Jika ada keberatan terhadap cetakan ini, silakan hubungi tim Pembelajaran GateTim akan menanganinya sesuai dengan prosedur yang relevan secepat mungkin.

2. Penyangkalan: Pandangan dan opini yang terdapat dalam artikel ini hanya mewakili pandangan pribadi penulis dan tidak merupakan nasihat investasi apa pun.

3. Versi bahasa lain dari artikel tersebut telah diterjemahkan oleh tim Gate Learn. Tanpa menyebutkan Gate.ioArtikel yang diterjemahkan mungkin tidak boleh disalin, disebarluaskan, atau diplagiat.