Penulis: RGB++ Fans; Sumber: Bytecoin CKB
Dalam artikel edukasi sebelumnya, kami telah menjelaskan secara singkat konsep inti terkait Jaringan Lighting seperti saluran pembayaran, rute multi-hop, HTLC, dan sebagainya.
Ketika melakukan transfer di Jaringan Lighting, seringkali harus melalui beberapa middleman Node untuk membangun jalur, namun saldo yang dapat ditransfer pada Node tengah seringkali terbatas, yang pada akhirnya mempengaruhi tingkat keberhasilan pembayaran. Untuk memastikan Node di jalur memiliki cukup dana dan meningkatkan pengalaman pengguna, beberapa skema manajemen Likuiditas harus disesuaikan. Namun, untuk memahami masalah manajemen Likuiditas dengan lebih mendalam, kita perlu memperkenalkan beberapa konsep dasar seperti saldo lokal dan jarak jauh (Local and Remote Balance), kapasitas masuk dan kapasitas keluar (Inbound and Outbound Capacity), dan lain-lain.
![]()
Dahulu kami pernah menyebutkan bahwa unit dasar Jaringan Lighting adalah Node dan saluran, yang terakhir adalah fasilitas transfer 1 ke 1 off-chain yang dibangun di atas jaringan BTC. Saat inisialisasi saluran, kedua belah pihak akan mentransfer sejumlah uang sebagai saldo awal, saldo di sisi Anda disebut sebagai “saldo lokal”, dan saldo di sisi lawan disebut sebagai “saldo ujung”. Saldo lokal menentukan seberapa banyak uang yang dapat Anda transfer ke pihak lawan, membatasi kemampuan pembayaran Anda atau “kapasitas pengeluaran”, sedangkan saldo ujung menentukan seberapa banyak uang yang dapat ditransfer oleh pihak lawan ke Anda, membatasi “kapasitas penerimaan” atau kemampuan menerima pembayaran Anda.
Meskipun saldo kedua belah pihak dalam saluran dapat berubah secara sering sebelum saluran ditutup, namun total kapasitas saluran tidak dapat diubah kecuali Anda menghidupkan kembali saluran secara keseluruhan atau menyuntikkan dana melalui ‘penggabungan saluran’.
![]()
(Grafik ini menunjukkan saldo lokal Anda dan saldo Robert masing-masing, saldo lokal Anda adalah 5, saldo ujung adalah 3, dan kapasitas total saluran adalah 8)
Setelah memahami beberapa konsep dasar di atas, mari kita lihat manajemen Likuiditas dalam Jaringan Lighting untuk memahami masalah yang ingin dipecahkan. Gambar berikut menunjukkan gambaran sederhana dari koneksi Node. Tampak jelas bahwa Anda (sudut kiri bawah) hanya terhubung ke satu Node LNTop. Karena saldo eksternal Anda adalah 3, Anda hanya dapat menerima transfer sebesar 3 dolar. Namun, jika Sophie ingin mentransfer 1 dolar ke Anda, transfer akan gagal karena Node tengah tidak memiliki cukup sisa saldo yang dapat ditransfer ke LNTop (kotak merah, kapasitas pengeluaran Node ini ke LNTop adalah 0).
![]()
Dapat dikatakan bahwa kapasitas saluran adalah salah satu masalah serius yang dihadapi Jaringan Lighting pada tahap awal. Jika Likuiditas lebih merata di seluruh jaringan, masalah semacam ini akan teratasi secara efektif, dan solusinya sering disebut sebagai ‘pengelolaan Likuiditas’, seperti menghubungkan klien ke beberapa Node Likuiditas melalui pasar sewa (Lighting Pool), membuka/menutup saluran baru sesuai kebutuhan, atau memperkenalkan metode penyeimbangan saluran, penataan ulang (Channel Rebalancing), dan sebagainya, untuk mengatur saldo dalam saluran secara on-chain atau off-chain.
Saat ini, beberapa klien dompet juga menyediakan fitur manajemen saluran otomatis, yang mengelola saluran secara cerdas berdasarkan perilaku pembayaran pengguna dan kondisi jaringan, untuk memastikan likuiditas yang memadai untuk transfer. Pengguna baru saat baru saja terhubung ke Jaringan Lighting juga dapat menggunakan mode “pendanaan satu arah”, yaitu hanya membiarkan pihak lawan dalam saluran melakukan pendanaan, tanpa melakukan pendanaan saat inisialisasi saluran, ini dapat mengurangi biaya ekonomi pengguna, tetapi dengan biaya tidak memiliki kemampuan pembayaran eksternal pada awal/memiliki kapasitas keluar.
Berikut ini kami akan menjelaskan secara lebih rinci tentang teknik umum dalam manajemen Likuiditas di Jaringan Lighting. Pertama-tama, mari kita memahami sewa saluran, yang bertujuan utama untuk mengatasi masalah “kapasitas masuk” Node, yaitu ketika orang lain ingin mentransfer ke Anda, Anda harus memastikan bahwa mereka dapat berhasil membangun jalur pembayaran, yang mana setiap Node dalam jalur tersebut harus memenuhi persyaratan, misalnya harus memiliki saldo yang cukup / kapasitas keluar yang mencukupi. Seperti yang kita sebutkan sebelumnya, kegagalan jalur pembayaran terjadi karena kurangnya Likuiditas dalam saluran yang dibangun antara beberapa Node tengah dan Node lainnya.
Membangun saluran membutuhkan biaya, karena pihak yang terlibat sering harus mengunci sebagian dana, yang menghasilkan biaya kesempatan. Sementara itu, konsep sewa saluran adalah untuk memungkinkan para pelaku node melakukan transaksi secara langsung melalui mekanisme pasar, dengan menggunakan sistem ‘sewa’ sehingga node dengan kelebihan dana secara aktif membangun saluran untuk node lainnya. Misalnya, jika Anda adalah pedagang, Anda perlu menerima uang yang dikirim oleh orang lain kapan saja, dengan persyaratan kredit yang tinggi, kemampuan ‘penerimaan’ dalam sehari harus melebihi 200 BTC.
Jadi Anda mencapai protokol dengan Lighting Pool dan 4 Node besar, masing-masing Node membentuk saluran selama 24 jam dengan Anda, mengunci 50 BTC, dan memberikan saldo jauh sebesar 50 BTC. Dengan demikian, kemampuan penerimaan Anda dalam setiap saluran akan mencapai 50 BTC. Jika seseorang mentransfer uang kepada Anda, Anda dapat menggunakan salah satu dari 4 Node ini sebagai middleman untuk membentuk jalur pembayaran.
![]()
(Di 1ml.com, kita bisa melihat beberapa operator Node Jaringan Lighting yang terkenal, Node ini memiliki dana yang cukup dan telah membentuk beberapa saluran dengan Node lainnya, sehingga dapat memperoleh pendapatan dengan menyewa Likuiditas)
Selain kolam sewa yang disebutkan di atas, ada juga Iklan Likuiditas (Liquidity Advertisement), penyedia Likuiditas dapat mengumumkan harga dan durasi saluran mereka melalui pesan gossip Node petir, Node yang menerima harga tersebut dapat membuka saluran dengan mereka. Semua skema berbasis penyewaan semacam ini akan menggabungkan sistem Margin untuk mencegah pelanggaran kontrak tiba-tiba.
Saat ini pengembang seperti Lighting Labs dan Jaringan Lighting serta Fiber sedang mencoba mengoptimalkan skenario sewa Likuiditas di bawah pendanaan satu arah, misalnya Fiber berencana untuk memperkenalkan skema pembayaran Likuiditas di atas fungsi Kontrak Pintar CKB, dengan kerjasama antara penyedia layanan LSP Node yang ditunjuk dan pengguna untuk membentuk saluran pembayaran, dan memberikan kapasitas penerimaan secara gratis kepada pengguna untuk jangka waktu tertentu, memenuhi kebutuhan penerimaan mereka. Setelah pengguna menerima sejumlah uang, kontrak akan secara otomatis mengambil kembali biaya yang dikeluarkan, mekanisme penjaminan Likuiditas yang terkait dengan skenario semacam ini juga sedang didiskusikan.
Secara umum, sewa saluran sering digunakan untuk menyelesaikan masalah koneksi antar Node, dan mendapatkan Likuiditas yang masuk, sedangkan skema Splicing saluran di bawah ini akan melakukan penambahan/drawal melalui operasi on-chain, langsung mengubah total saldo kedua belah pihak di saluran. Biasanya, pembukaan dan penutupan saluran menggunakan tanda tangan 2/2, yang melakukan redistribusi aset on-chain yang dimiliki bersama oleh kedua belah pihak, sementara dalam skema Jaringan Lighting awal, setelah saluran dibuka, tidak mungkin mengubah saldo keseluruhan saluran kecuali ditutup dan dibuka kembali.
Sementara itu, penyatuan saluran adalah solusi baru yang diajukan belakangan ini. Ini memungkinkan saluran yang ada tetap terbuka, dan dengan kerjasama pihak-pihak yang terlibat, langsung merekonstruksi dan memperbarui UTXO yang dikuasai bersama oleh kedua pihak di on-chain, misalnya dengan menambahkan aset baru ke atas aset yang sudah ada untuk dikelola bersama oleh pihak-pihak yang terlibat, sehingga mengubah saldo keseluruhan dalam saluran. Gambar di bawah ini secara ringkas menggambarkan gagasan ini, di mana sebelah kiri adalah aset on-chain dari saluran lama (UTXO1), dikendalikan oleh multi-tanda tangan Alice dan Bob; kemudian kedua pihak memulai penyatuan saluran, dengan menambahkan aset lain (UTXO2) untuk dikelola bersama, akhirnya jumlah aset (UTXO3) yang dapat dikelola bersama oleh kedua pihak dalam saluran bertambah, begitu pula kapasitasnya.
![]()
Penyambungan saluran juga dapat digunakan untuk mengurangi kelebihan dana di saluran, mentransfer aset menganggur sementara keluar dari saluran, dan meningkatkan efisiensi pemanfaatan modal. Dibandingkan dengan interaksi on-chain tradisional yang memerlukan dua interaksi on-chain saat menutup/memulai ulang saluran, penyambungan saluran hanya membutuhkan satu operasi on-chain, yang secara signifikan dapat mengurangi biaya penjatuhan. Meskipun penyambungan saluran memiliki keuntungan yang jelas, karena alasan historis, skema tersebut belum sepenuhnya matang, dan adopsi skala besarnya masih akan memakan waktu.
Setelah memahami penggabungan saluran, kami akan melanjutkan dengan memperkenalkan konsep penyeimbangan saluran (Channel Rebalancing), yang merupakan cara untuk menyesuaikan saldo off-chain di berbagai saluran tanpa menutup saluran atau mengubah kapasitas total saluran (menyimpan biaya transaksi). Misalkan Anda menjalankan klien Jaringan Lighting dan telah mendirikan total tiga saluran pembayaran dengan Node lain:
- Saluran 1: Didirikan dengan Node X, total kapasitasnya adalah 1 BTC
- Channel 2: Terhubung dengan Node Y, total kapasitasnya adalah 0,5 BTC
- Saluran 3: Dibangun dengan Node Z, dengan kapasitas total 0.5 BTC
Distribusi dana untuk setiap saluran adalah sebagai berikut:
- Saluran 1: Saldo lokal Anda: 0,9 BTC Saldo jarak jauh: 0,1 BTC
- Saluran 2: Saldo Lokal Anda: 0.1 BTC Saldo Jarak Jauh: 0.4 BTC
- Saluran 3: Saldo lokal Anda: 0.1 BTC Saldo jarak jauh: 0.4 BTC
![]()
Masalahnya sekarang adalah bahwa kapasitas pengeluaran Anda di saluran 2 dan saluran 3 tidak mencukupi, Anda hanya dapat mentransfer maksimal 0,1 BTC ke pihak lawan, tidak dapat memenuhi kebutuhan transfer besar. Sementara itu, kapasitas pengeluaran di saluran 1 berlebih, mencapai 0,9 BTC, tetapi Anda sama sekali tidak membutuhkan jumlah sebesar itu dalam jangka pendek. Jelas, yang terbaik adalah memindahkan dana yang berlebih dari saluran 1 ke dua saluran lainnya. Jadi Anda berencana untuk mentransfer 0,4 BTC dari saldo lokal saluran 1 ke saluran 2, dan mentransfer 0,4 BTC ke saluran 3. Untuk mencapai hal ini, Anda perlu menyelesaikan dua pembayaran lingkaran.
![]()
Metode operasi yang spesifik seperti yang ditunjukkan pada gambar di atas, Anda dapat langsung mentransfer 0,8 BTC ke Node X, yang kemudian mentransfer masing-masing 0,4 BTC ke Y dan Z. Kemudian, Y dan Z akan mentransfer masing-masing 0,4 BTC kepada Anda melalui saluran 2 dan saluran 3, meningkatkan saldo lokal Anda. Dengan demikian, Anda akan memiliki dana yang cukup untuk kebutuhan transfer besar di masa depan.
Dengan melihat gambar di atas, tidak sulit untuk menemukan bahwa inti dari pembayaran loop adalah Anda mentransfer uang ke diri sendiri, mengalihkan saldo Anda di berbagai saluran, dan akhirnya memastikan alokasi saldo keseluruhan mencapai hasil yang diinginkan, namun metode ini tidak dapat secara tiba-tiba meningkatkan total saldo dari kedua pihak di saluran manapun, selain itu, implementasinya bergantung pada asumsi berikut: X memiliki dana yang cukup untuk ditransfer ke Y dan Z, dengan kata lain, pembayaran loop sering kali memerlukan Node terkait untuk memiliki cadangan Likuiditas yang memadai.
Pembayaran Loop adalah cara untuk menerapkan pemikiran keseimbangan ulang saluran, dan skema keseimbangan ulang dapat dikombinasikan dengan metode lain dalam praktiknya, seperti Pertukaran Submarine. Mari kita perkenalkan Pertukaran Submarine, gagasan inti dari skema ini adalah menukar dana on-chain dan off-chain dengan bantuan metode seperti HTLC tanpa menutup saluran.
Skenario pertukaran selam paling sederhana terjadi on-chain menuju saluran dengan setoran. Misalnya, jika Alice telah membangun saluran 1-ke-1 dengan Bob tetapi setelah beberapa waktu, saldo lokal Alice hampir habis dan tidak dapat membayar lagi. Saat itu, Alice perlu menyuntikkan lebih banyak dana dan perlu menutup saluran dan memulainya kembali. Namun, saluran ini disewa dan menutupnya lebih awal tidak menguntungkan. Apa yang harus dilakukan?
Jika pertukaran dilakukan melalui pertukaran selam, prosesnya akan lebih mudah, tetapi memerlukan HTLC. Pertama, Alice dapat menghasilkan nomor acak R, lalu menghasilkan hash H®. Selanjutnya, Alice dapat mengirim BTC ke Alamat Bob secara on-chain, dengan kondisi penguncian terbatas oleh HTLC. Bob harus mengetahui preimage R yang sesuai dengan H® untuk membuka kunci BTC tersebut secara on-chain.
![]()
Bob melakukan transaksi dengan Alice melalui saluran off-chain menggunakan HTLC, namun dengan arah yang terbalik: Alice harus memperlihatkan R untuk membuka uang yang dibayarkan oleh Bob. Begitu Alice memperlihatkan nilai R, Bob dapat menggunakannya untuk membuka BTC yang terkunci oleh Alice di on-chain. Setelah itu, saldo lokal Alice di saluran akan bertambah, sementara saldo aset di on-chain akan berkurang setara (jika tidak memperhitungkan biaya transaksi), dengan pertukaran 1:1 yang mendasarinya (di atas, untuk memudahkan penjelasan prinsip, tidak dijelaskan dengan urutan operasi konvensional yang umum dalam pertukaran selam, dalam praktiknya sebagian besar waktu salah satu pihak membuat HTLC di saluran off-chain terlebih dahulu, baru pihak lain membuat HTLC simetris di on-chain).
Skenario di atas terutama digunakan untuk pertukaran aset on-chain dengan saldo off-chain, asalkan arah tindakan Alice dan Bob disesuaikan, maka dapat ditukar dengan operasi penarikan, mengubah saldo off-chain menjadi aset on-chain. Pertukaran selam didasarkan pada kombinasi fitur HTLC dan kunci waktu untuk memastikan keamanan, bahkan jika pihak lain menolak untuk bekerja sama dengan Anda di tengah jalan, uang yang Anda kunci dalam HTLC tetap aman karena pihak lain tidak tahu Kunci Rahasia untuk membuka HTLC, setelah waktu kunci berakhir, Anda dapat mengambil kembali modal Anda.
Namun perlu diperhatikan, meskipun dalam skenario di atas modal Anda tidak akan dicuri, namun salah satu pihak perlu mengunci dana HTLC on-chain, ini akan menghasilkan biaya transaksi yang pasti menyebabkan gesekan, jika pihak lainnya mengecewakan, pasti akan berdampak pada Anda. Untuk mengatasi masalah ini, pertukaran selam sering kali memiliki beberapa metode bantu kerja sama, seperti deposit, sistem reputasi, dan hukuman lainnya.
Mari kita ringkas lagi, Idea inti pertukaran selam adalah untuk memungkinkan aset on-chain/off-chain dapat ditukar dengan fleksibel, jika kita mengikuti gagasan keseimbangan kembali melalui saluran, dapat dilakukan tindakan penyesuaian Likuiditas yang lebih optimal. Di sini kita akan memberikan contoh sederhana:
Namun, dengan merangkum poin-poin pengetahuan di atas, kita dapat melihat bahwa operasi pengaturan Likuiditas seperti pertukaran kapal selam dan penggabungan saluran, penyewaan saluran, dll., akan meninggalkan jejak operasi on-chain dan menghasilkan biaya transaksi. Jika operasi semacam ini dilakukan secara sering, pasti akan memberikan tekanan pada biaya ekonomi dan UX pengguna. Karena BTC Jaringan Lighting bergantung pada BTC Mainnet, berinteraksi on-chain secara sering tidak realistis, sedangkan Fiber berbasis CKB menghadapi tekanan semacam ini dalam skala yang relatif lebih kecil dan memberikan pengalaman pengelolaan Likuiditas yang lebih lancar. Namun, baik Jaringan Lighting maupun Fiber sedang melakukan penelitian mendalam terhadap solusi Likuiditas yang lebih inovatif, dan di masa depan, mungkin akan menemukan jalur yang lebih sesuai melalui kerja sama aktif dengan tim proyek seperti Mercury Layer.
