Dompet on-chain mencapai pemetaan sekitar 1-1 dari transaksi ke transaksi: untuk setiap transaksi ekonomi yang dilakukan pengguna, sekitar satu transaksi blockchain diperlukan. Agregasi, coinjoin, pembayaran cut-through, dll. mengubah pernyataan ini sedikit. Tetapi ini sekitar benar.

Lightning mencapai pemetaan banyak ke satu dari transaksi ke transaksi: keajaiban dari Lightning adalah bahwa sejumlah transaksi ekonomi yang efektif tak terbatas dapat terjadi dalam satu saluran Lighting, yang itu sendiri terikat pada satu output transaksi yang tidak dihabiskan (UTXO) tunggal. Pada dasarnya, kita telah mengambil dimensi "waktu" - transaksi - dan mencapai peningkatan signifikan dengan menggabungkan dimensi tersebut.

Namun menciptakan bahkan satu UTXO per pengguna, dapat dikatakan, tidak cukup baik. Oleh karena itu, ada banyak proposal di luar sana untuk mencapai skalabilitas yang lebih besar dengan memungkinkan beberapa pengguna untuk berbagi satu UTXO secara mandiri. Sekali lagi, mengecilkan satu dimensi 'ruang' lain dari skalabilitas - pengguna - menjadi satu UTXO.

Tujuan kami di sini adalah untuk memberikan gambaran umum tentang semua proposal ini, mencari tahu pola teknis apa yang mereka bagikan, mencari tahu jenis opcode baru dan peningkatan fork lunak lainnya yang mereka butuhkan untuk berfungsi, dan membuat tabel perbandingan tentang bagaimana semua bagian saling berhubungan. Dalam perjalanan ini, kami juga akan mendefinisikan apa sebenarnya protokol L2, jenis skalabilitas yang telah dapat dicapai oleh Lightning, dan memahami perbaikan apa yang perlu kami lakukan terhadap mempool untuk mencapai semua ini.

Terima kasih diberikan kepada Fulgur Venturesuntuk mensponsori penelitian ini. Mereka tidak memiliki kontrol editorial atas isi posting ini dan tidak meninjau nya sebelum publikasi.

Terima kasih juga kepada Daniela Brozzoni, Sarah Cox, dan yang lainnya untuk tinjauan pra-penerbitan.

Definisi

Apa itu Layer 2?

Seringkali istilah 'Layer 2' didefinisikan secara luas, sampai pada titik di mana entitas mirip bank (misalnya Liquid) dapat didefinisikan sebagai Layer 2. Untuk tujuan artikel ini, kami akan mengadopsi definisi yang ketat: Layer 2 (L2) adalah sistem yang denominasi Bitcoin, dengan tujuan memungkinkan BTC untuk ditransaksikan lebih sering daripada jumlah transaksi on-chain dengan pihak lain. Sehingga salah satu dari:

1. Tidak ada yang dapat mencuri dana dengan menguntungkan dalam sistem ini, dengan memperhitungkan hukuman dan biaya dalam sistem. Biaya dan hukuman di luar sistem seperti kerugian reputasi, konsekuensi hukum, dll. tidak dipertimbangkan dalam definisi kami.
2. (Diutamakan) Pemilik sebenarnya dana dapat menarik dana mereka secara sepihak, dikurangi biaya transaksi, tanpa kerjasama pihak ketiga mana pun.

Opsi pertama diperlukan karena kami ingin sistem L2 kami dapat mewakili jumlah dan transaksi dengan nilai kecil sehingga tidak dapat diwakili secara on-chain. Misalnya, di Lightning, HTLC dapat memiliki nilai yang terlalu kecil untuk mewakili on-chain. Dalam keadaan itu, nilai HTLC ditambahkan ke biaya transaksi dari transaksi komitmen. Sementara simpul Lightning dapat "mencuri" HTLC debu dengan menutup saluran pada saat yang tepat, melakukannya lebih mahal¹daripada HTLC bernilai, sehingga pencurian tidak menguntungkan.

Dengan demikian, penarikan sepihak selalu menjadi tujuan desain utama kami.²

Dengan definisi ini, hal-hal seperti Lightning dianggap sebagai sistem L2. Namun sistem seperti Liquid, Cashu, dan Fedimint bukanlah L2 karena pihak lain memiliki kendali atas dana Anda. Skema validasi sisi klien seperti RGB juga bukan L2 menurut definisi ini, karena tidak dapat melakukan transaksi BTC secara aman tanpa kepercayaan. Terakhir,@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39">Statechains gagal memenuhi syarat, karena entitas Statechain dapat mencuri dana jika mereka tidak mengikuti protokol.

Apa itu Covenants?

...dan mengapa sistem L2 yang lebih scalable membutuhkannya?

Dalam penyusunan Bitcoin, perjanjian adalah mekanisme di mana cara txout dapat dihabiskan dibatasi sebelumnya, sehingga bentuk transaksi yang digunakan untuk menghabiskan txout tersebut telah ditentukan sebelumnya atau dibatasi dengan cara yang tidak hanya terbatas pada tanda tangan. Sistem L2 yang berbagi UTXO antara beberapa pihak memerlukan perjanjian karena mereka memerlukan cara membatasi bagaimana UTXO dapat dihabiskan untuk menerapkan aturan dan insentif dari protokol L2.

Covenants Rekursif

Sebuah perjanjian rekursif adalah perjanjian dengan sifat bahwa aturan yang membatasi bagaimana UTXO dapat dihabiskan dapat diterapkan secara rekursif, ke UTXO anak dari transaksi pengeluaran secara tak terbatas. Perjanjian rekursif memiliki selama ini dianggap tidak diinginkan oleh beberapa orangkarena mereka dapat membebani koin secara tidak terbatas. Atau setidaknya, secara tak terbatas tanpa izin dari pihak ketiga seperti pemerintah.

Tujuan

Lightning adalah sistem Layer 2 terbaik saat ini. Namun, sistem ini memiliki keterbatasan. Yaitu:

1. Scaling - Saat ini Lightning memerlukan setidaknya satu UTXO per pengguna akhir.³
2. Liquidity - Lightning membutuhkan dana yang terikat dalam saluran.
3. Interaktivitas - Lightning memerlukan penerima pembayaran untuk online agar dapat menerimanya secara terpercaya.

Dalam mengevaluasi sistem Layer 2, tujuan kami adalah untuk meningkatkan batasan-batasan kunci ini, idealnya tanpa menambahkan batasan baru.

Batas Skalabilitas Lightning

Apa arti "satu UTXO per pengguna akhir" dalam praktiknya? Karena saluran Lightning dapat beroperasi tanpa batas, satu cara untuk melihat ini adalah dengan bertanya berapa banyak saluran baru yang dapat dibuat setiap tahun⁴Menciptakan output taproot memiliki biaya marginal sebesar 43vB; jika penciptaan saluran diamortisasi, dengan banyak saluran yang dibuat dalam satu transaksi, biaya overhead transaksi lainnya dapat diabaikan dan jumlah saluran yang cukup besar dapat dibuka setiap tahun untuk mendaftarkan pengguna baru. Sebagai contoh, misalkan 90% kapasitas blok digunakan untuk membuka saluran Lightning taproot baru:

Diperkirakan bahwa sekitar separuh populasi global memiliki smartphone, 4,3 miliar orang. Jadi sebenarnya kita dapat menjangkau persentase yang signifikan dari seluruh populasi yang kemungkinan dapat memanfaatkan saluran Lightning per tahun.

Namun, saluran tidak bertahan selamanya. Kadang-kadang pengguna akan ingin beralih dompet, meningkatkan atau mengurangi kapasitas saluran, dll. Metode paling efisien untuk mengubah kapasitas saluran adalah melalui splicing, terutama diimplementasikan di Phoenix Wallet.

Seperti pembukaan saluran, penyusunan juga dapat dilakukan secara diamortisasi untuk meningkatkan efisiensi, dengan beberapa operasi penyusunan bersama-sama dalam satu transaksi untuk mengurangi jumlah input dan output yang diperlukan untuk menambah dan menghapus dana⁵. Dengan demikian ruang blok delta yang diperlukan per potongan pengguna, dengan asumsi penggunaan musigIni adalah output taproot 43vB ditambah

Pengeluaran jalur kunci taproot 57.5vB, untuk total 100.5vB. Jika kita lagi mengasumsikan penggunaan ruang blok 90%, kita mendapatkan:

Akhirnya, perhatikan bagaimana beralih saluran Lightning antara dompet dapat dilakukan dalam satu transaksi dengan mempercayai dompet berikutnya untuk menandatangani transaksi komitmen setelah dana telah dikirim ke alamat komitmen, atau dengan dukungan penutupan saluran baru yang bersifat kooperatif di kedua implementasi dompet.

Tentu saja, ada kasus penggunaan yang bersaing untuk Bitcoin di luar saluran Lightning, dan bagaimana itu akan diterjemahkan ke dalam tingkat biaya sulit untuk diketahui. Tetapi angka-angka ini memberi kami gambaran kasar yang menunjukkan bahwa dengan teknologi saat ini, setidaknya secara teknis memungkinkan untuk mendukung ratusan juta pengguna Lightning yang berdaulat diri sendiri.

Ikhtisar L2

Menurut definisi kami tentang sistem L2, ada dua pola desain utama yang dibahas dalam komunitas pengembangan Bitcoin:

1. Saluran
2. Virtual UTXOs

Dalam pola saluran, di mana Lightning adalah contoh utama, protokol berlanjut dengan pertukaran transaksi yang telah ditandatangani sebelumnya antara pihak-pihak yang dapat ditambang, tetapi tidak dalam jalur yang “bahagia”. Transaksi yang telah ditandatangani sebelumnya ini membagi UTXO antara pihak-pihak; transaksi terjadi dengan mengubah saldo pemisahan itu secara berulang, dengan transaksi yang telah ditandatangani sebelumnya yang baru. Karena akan ada banyak transaksi yang valid yang berbeda yang menghabiskan UTXO yang sama, beberapa mekanisme insentif diperlukan untuk memastikan transaksi yang benar adalah yang benar-benar ditambang.

Dalam pola desain Virtual UTXO (V-UTXO), di mana Ark adalah contoh paling menonjol, V-UTXO dibuat melalui perjanjian multi-pihak, melalui pembuatan transaksi yang dapat ditambang untuk menarik dana V-UTXO secara sepihak dengan menempatkannya on-chain, tetapi tidak dalam "jalur bahagia". Dalam hal itu, V-UTXO mirip dengan saluran. Tetapi tidak seperti saluran, skema V-UTXO melakukan transaksi dengan mengeluarkan dana V-UTXO itu sendiri, dalam (konseptual) satu⁶transaksi yang ditandatangani sebelumnya.

Pola desain jalur bahagia adalah penggunaan jalur skrip 'semua pihak setuju', seperti multisig N-of-N; taproot dirancang khusus untuk konsep ini, memungkinkan jalur kunci menjadi multisig N-of-N melalui musig. Dengan asumsi bahwa semua pihak setuju, jalur bahagia memungkinkan koin untuk dihabiskan dengan efisien (dan secara pribadi).

Menariknya, karena UTXO virtual adalah "nyata" dalam banyak hal, cukup mudah untuk membangun saluran di atas UTXO virtual hanya dengan membuat UTXO virtual yang, jika ditambang, akan mengarah pada pembuatan UTXO yang diperlukan untuk saluran. Dalam hal ini, skema UTXO virtual adalah

sedikit lebih rendah dari saluran.

Lightning

Status quo, yang diimplementasikan dalam produksi sebagai Lightning Network, terutama berbasis padastandar BOLTs. Lightning adalah kombinasi dari sejumlah hal, termasuk saluran Lightning dan HTLC, jaringan routing P2P, onion routing, standar faktur, dll Khususnya, Lightning bukan sistem konsensus, sehingga elemen yang berbeda dari "sistem Lightning" tidak perlu diadopsi dengan cara yang sama persis oleh semua pengguna. Untuk tujuan artikel ini, ketika kami mengatakan "Lightning" kami akan menggunakannya dalam arti luas, termasuk peningkatan yang mudah diramalkan ke protokol Lightning saat ini (khas) yang banyak digunakan.

Seperti yang dibahas di atas, karakteristik kunci dari Lightning adalah batas skalabilitas pengguna akhirnya, karena perlu memiliki setidaknya satu UTXO per pengguna. Akan tetapi, untuk elemen routing “inti” dari Lightning — node Lightning publik yang mengarahkan sebagian besar transaksi — batas skalabilitas ini tidak terlalu menjadi perhatian karena Lightning tetap berfungsi dengan baik jika terdapat jauh lebih banyak pengguna akhir daripada node routing, karena setiap saluran publik yang digunakan untuk routing pembayaran dapat dengan mudah mendukung sejumlah besar transaksi per detik. Inilah juga mengapa begitu banyak sistem L2 masa depan diharapkan juga berpartisipasi dalam jaringan Lightning. Kita juga melihat hal ini dalam bagaimana sistem yang belum sepenuhnya L2 seperti Cashu sangat bergantung pada jaringan Lightning untuk benar-benar berguna: penggunaan utama Cashu mungkin adalah untuk mengirim dan menerima pembayaran Lightning.

Saluran Non-Interaktif

Konstruksi ini meningkatkan saluran Lightning dengan menggunakan OP_CTV untuk mengurangi persyaratan interaktivitas. Namun, karena ini tidak meningkatkan batas skala 1-UTXO-per-user, kami tidak akan membahasnya lebih lanjut.

Pabrik Saluran

Di sini kita memiliki beberapa pihak yang menegosiasikan alamat multisig n-of-n tunggal, bersama dengan transaksi pengeluaran alamat multisig untuk membuat n UTXO yang berbeda membagi dana tersebut. UTXO tersebut pada gilirannya digunakan untuk saluran pembayaran. Saluran tersebut dapat digunakan dengan keamanan yang sama seolah-olah mereka telah dibuka secara langsung on-chain, karena jika keadaan saluran perlu dipasang on-chain, transaksi split dapat ditambang. Ini berpotensi menghemat ruang on-chain saat saluran ditutup, karena n pihak dapat - dalam teori - menutup semua saluran nn secara kooperatif sekaligus.

Karena pabrik channel sedang menegosiasikan UTXO yang bisa ditambang, tetapi tidak diharapkan benar-benar ditambang dalam jalur bahagia, mereka adalah contoh yang sangat primitif dari V-UTXOs.

Channel factory itu sendiri tidak memerlukan soft-fork apa pun untuk dimungkinkan. Namun, channel factory sederhana yang dijelaskan di atas mungkin tidak praktis jika melibatkan banyak pihak karena koordinasi yang diperlukan untuk benar-benar mencapai manfaat skalabilitas. Oleh karena itu, proposal covenant seperti OP_Evictatau CTV (melalui pohon txout) bertujuan untuk memungkinkan hasil yang lebih halus di mana pihak-pihak individu dapat dipaksa on-chain, tanpa memaksa semua orang on-chain sekaligus.

Eltoo/LN-Symmetry

Karena Eltoo adalah nama yang sangat membingungkan, kami hanya akan menggunakan nama yang diperbarui LN-Symmetry ke depannya.

Sementara saluran Poon-Dryja mendorong status yang benar untuk dipublikasikan secara on-chain dengan menghukum status yang salah, LN-Symmetry malah memungkinkan status yang salah diperbarui dengan transaksi tambahan. Ini memiliki keuntungan menyederhanakan saluran Lightning dengan menghilangkan kompleksitas hukuman. Namun, ini kemungkinan akan menjadi kerugian dalam skenario yang tidak dipercaya, karena hukuman bisa dibilang diperlukan untuk mencegah penipuan.

LN-Simetri memerlukan sebuah fork lunak untuk mengaktifkanSIGHASH_ANYPREVOUT, yang diperlukan untuk memungkinkan transaksi negara untuk mengulangi pengeluaran transaksi negara lain selama pembaruan.

Secara mandiri, LN-Symmetry tidak menawarkan peningkatan skalabilitas pada saluran Lightning konvensional. Tapi pendukung telah berpendapatbahwa hal itu membuat hal-hal seperti pabrik saluran lebih mudah untuk diimplementasikan.

Ark

Ark mengambil pendekatan baru terhadap skala transaksi: fully transferable virtual UTXOs (V-UTXOs), yang dapat digabungkan dan dibagi secara atom⁷transaksi off-chain. Di Ark, koordinator pusat, Ark Service Provider (ASP), menyediakan V-UTXO untuk pengguna dengan masa aktif yang ditentukan, misalnya 4 minggu. Periode ini dikenal sebagai putaran. V-UTXO ini dibuat melalui pool txouts, satu per putaran, melalui mekanisme seperti CTV untuk memungkinkan satu on-chain txout untuk mengikatkan pada pohon V-UTXO. Kedaluwarsa putaran adalah cara Ark mencapai keunggulan dalam skalabilitas: pada akhir putaran, pool txout terbuka, memungkinkan ASP untuk menghabiskannya sendiri dengan satu tanda tangan dalam transaksi kecil. Karena waktu kedaluwarsa putaran, V-UTXO itu sendiri kedaluwarsa ketika pool txouts yang membuatnya kedaluwarsa: pengguna yang memiliki V-UTXO harus menghabiskan V-UTXO tersebut sebelum waktu kedaluwarsa pool txout tercapai, atau memasukkannya ke on-chain (penarikan sepihak).

Untuk bertransaksi V-UTXO antar pihak, koordinator Ark ikut menandatangani transaksi yang menghabiskan satu atau lebih V-UTXO, sehingga transaksi hanya valid jika satu atau lebih V-UTXO lainnya dibuat dalam putaran yang berbeda. Dalam kombinasi dengan beberapa batas waktu yang cermat — lihat dokumen Ark untuk detail lengkapnya — ketergantungan inilah yang membuat pengeluaran V-UTXO tidak dapat dipercaya: V-UTXO tidak dapat diklaim secara on-chain kecuali V-UTXO baru dibuat dalam transaksi kumpulan yang berbeda. Ada beberapa cara potensial untuk benar-benar menerapkan ketergantungan itu. Tetapi detail pastinya tidak relevan dengan tujuan artikel ini.

Perhatikan bagaimana ini berarti bahwa ASP yang diberikan akan memiliki banyak putaran aktif yang terjadi sekaligus. Putaran baru sering dibuat untuk memungkinkan dana dalam putaran yang ada untuk ditransfer. Tetapi putaran yang ada tumpang tindih dengan putaran baru, karena umumnya akan kedaluwarsa setelah putaran baru, dan txouts kolam yang baru, dibuat.

Ekonomi Ark

Ketika V-UTXO dihabiskan, ASP harus menyediakan BTC yang sesuai dalam transaksi pool baru yang mewakili putaran baru. Tetapi mereka tidak dapat mengembalikan nilai dari V-UTXO yang dihabiskan sampai putaran berakhir. Dengan demikian, ekonomi pengeluaran V-UTXO memiliki biaya nilai waktu uang, karena likuiditas yang harus disediakan oleh ASP.

Secara khusus, biaya dikeluarkan ketika V-UTXO dihabiskan. Sementara V-UTXO tidak dibelanjakan, ini merupakan potensi UTXO yang sangat nyata yang dapat ditempatkan secara onchain untuk menarik dana secara sepihak; Pengguna memiliki dana tersebut. Namun, untuk menghabiskan V-UTXO, ASP harus membuat kumpulan txout baru, menggunakan dana yang diperoleh ASP di tempat lain, sedangkan dana dalam V-UTXO yang dihabiskan tidak tersedia untuk ASP sampai waktu kedaluwarsa tercapai.

Oleh karena itu, menghabiskan V-UTXO membutuhkan pinjaman jangka pendek, meminjam dana untuk menutupi selang waktu antara sekarang dan saat putaran berakhir. Ini berarti bahwa biaya likuiditas untuk menghabiskan V-UTXO sebenarnya menurun ketika V-UTXO semakin tua dan waktu kadaluwarsa semakin dekat, pada akhirnya - dalam teori - mencapai nol ketika putaran akhirnya berakhir.

Akhirnya, ingat bahwa biaya untuk menghabiskan V-UTXO terkait dengan ukuran total V-UTXO yang dihabiskan. Bukan jumlah yang dibayarkan kepada penerima. Ini berarti bahwa dompet yang dimaksudkan untuk bertransaksi V-UTXO secara langsung (sebagai lawan mengelola satu V-UTXO untuk tujuan, misalnya, saluran Pencahayaan berbasis V-UTXO), harus melakukan trade-off dalam cara mereka membagi dana menjadi V-UTXO. Satu V-UTXO meminimalkan biaya penarikan sepihak, sekaligus memaksimalkan biaya transaksi berbasis likuiditas; membagi dana menjadi banyak V-UTXO melakukan yang sebaliknya. Ini sama sekali tidak seperti ekonomi Bitcoin on-chain, atau transaksi Lightning.

Apa biaya likuiditas ini? Saat ini, dompet Lightning Phoenix mengenakan biaya 1% untuk menyediakan likuiditas saluran selama 1 tahun; pada kondisi terburuk, Phoenix harus mengikat dana mereka selama 1 tahun. Namun, asumsi ini mengasumsikan bahwa likuiditas tidak digunakan. Kemungkinan besar biaya modal untuk Phoenix sebenarnya lebih tinggi, dan mereka mengasumsikan bahwa pelanggan rata-rata menggunakan likuiditas masuk mereka dalam waktu kurang dari satu tahun. Phoenix juga mendapatkan uang dari biaya transaksi, yang mungkin mensubsidi likuiditas saluran. Akhirnya, Phoenix mungkin tidak menguntungkan!

Tingkat Surat Utang AS memberikan kita perkiraan lain. Saat ini Tingkat Surat Utang AS 3 Bulan sekitar 5% per tahun. Karena ada argumen bahwa tingkat ini terlalu tinggi karena inflasi dolar AS, kita akan mengasumsikan biaya likuiditas untuk dana yang dinyatakan dalam BTC sebesar 3% per tahun untuk analisis kita.

Jika interval putaran adalah 4 minggu, ini berarti bahwa transaksi akan dimulai dengan biaya likuiditas

,akhirnya menurun menjadi nol. Dengan asumsi pengguna mencoba memindahkan dana mereka ke putaran baru dua minggu sebelum putaran berakhir, pengguna membayar sekitar 1,5% per tahun dalam biaya likuiditas untuk mencapai self-custody dana mereka. Di sisi lain, jika pengguna menunggu hingga saat terakhir⁸, biaya dapat hampir nol, dengan risiko melewatkan waktu kedaluwarsa.

Pengguna mungkin tidak melihat hal ini sebagai biaya sepele. Dan biaya ini mengasumsikan bahwa biaya tetap setiap putaran telah dibuat tidak signifikan dengan mengamortisasi biaya transaksi dan biaya lainnya atas jumlah peserta yang besar.

Bagaimana jika biaya tetapnya tidak begitu kecil? Anggaplah ASP memiliki 1000 pengguna, dan pool txouts dibuat sekali dalam satu jam rata-rata. Dalam periode 4 minggu, itu adalah 672 transaksi on-chain. Ini berarti untuk hanya menyimpan dana mereka, para pengguna ASP secara kolektif harus membayar hampir sama banyaknya transaksi dengan para pengguna! Mungkin lebih murah bagi mereka semua untuk membuka saluran Lightning mereka sendiri, meskipun ASP meminta mereka untuk menunggu satu jam untuk konfirmasi.

Ark Bootstrapping

Sebuah ASP baru dengan sedikit pengguna menghadapi dilema: entah ASP round terjadi jarang, dan pengguna harus menunggu lama untuk round yang diusulkan mengumpulkan cukup V-UTXO untuk mencapai peningkatan skala yang berguna dan pengurangan biaya transaksi. Atau transaksi ASP pool terjadi sering, dengan biaya transaksi tinggi yang dibayarkan oleh setiap pengguna. Seperti yang kami tunjukkan di bagian sebelumnya, dapat membutuhkan banyak pengguna untuk mengamortisasi round yang sering, dan txouts pool yang mendasarinya.

Karena putaran kedaluwarsa, masalah ini menjadi masalah yang berkelanjutan, bahkan lebih buruk daripada yang dihadapi oleh saluran Lightning: setidaknya saluran Lightning dapat terus berguna secara tak terbatas, memungkinkan saluran dibuka sekarang dan diamortisasi secara bertahap selama beberapa bulan. Kedua, karena putaran kedaluwarsa, ada lebih sedikit fleksibilitas dalam hal kapan membuat txouts baru yang mendukung putaran ini: jika biaya tinggi selama seminggu atau dua, pengguna yang txouts kolamnya kedaluwarsa tidak punya pilihan selain (secara kolektif) membayar biaya tinggi tersebut untuk mempertahankan pengawasan mereka atas dana mereka. Dengan saluran Lightning, ada jauh lebih banyak fleksibilitas dalam hal kapan sebenarnya membuka saluran.

Sementara para penulis Ark awalnya membayangkan skenario yang sangat optimis di mana putaran baru terjadi setiap beberapa detik, bootstrapping awal kemungkinan harus terjadi dengan kasus penggunaan yang mampu menunggu berjam-jam untuk transaksi Ark dikonfirmasi, jika biaya transaksi tidak disubsidi.

Interaktivitas

Ark non-custodial adalah protokol yang sangat interaktif: karena V-UTXO Anda kedaluwarsa, Anda memiliki batas waktu yang ketat untuk berinteraksi dengan ASP Anda, jika tidak ASP dapat memilih untuk mengambil dana Anda. Interaktivitas ini juga tidak dapat dioutsourcing: sementara Lightning memilikiwatchtowers yang mencegah rekanan mencoba merobek Anda — bahkan jika saluran Anda belum online — pemilik koin Ark harus menggunakan kunci pribadi mereka sendiri untuk menyegarkan dana tanpa kepercayaan. Hal yang paling dekat di Ark dengan menara pengawas adalah menandatangani transaksi yang memungkinkan menara pengawas untuk secara sepihak menarik dana Anda secara on-chain menuju waktu kedaluwarsa, yang memiliki biaya biaya transaksi yang signifikan.

Pertimbangkan apa yang terjadi pada V-UTXO jika pemiliknya offline: setelah putaran berakhir, ASP perlu memulihkan dana untuk mendapatkan likuiditas mereka kembali untuk putaran selanjutnya. Jika pemilik V-UTXO offline, menempatkan V-UTXO tersebut on-chain memiliki biaya transaksi yang signifikan, karena ASP sekarang perlu memulihkan dana pada beberapa level pohon V-UTXO. ASP dapat membuat kembali V-UTXO yang belum dihabiskan dalam putaran baru. Tetapi ini bukanlah trustless dari perspektif pemilik V-UTXO, karena mereka tidak dapat menghabiskan V-UTXO tersebut tanpa mendapatkan data.⁹ dari ASP. ASP juga bisa dengan mudah merekam V-UTXO yang tidak terpakai sebagai saldo kustodian. Atau bahkan mungkin memiliki kebijakan menyita dana!

Secara pribadi, saya curiga bahwa mengingat biaya yang tidak sepele dari penyimpanan sendiri di Ark, banyak pengguna akan memilih ASP dengan kebijakan menggulirkan dana ke putaran baru dan hanya menerima potensi penipuan di akhir setiap putaran. Ini lebih murah daripada secara proaktif memindahkan dana mereka cukup awal untuk menjamin keamanan jika, misalnya, mereka gagal menghidupkan telepon mereka tepat waktu agar dompet mereka memindahkan dana ke putaran baru.

Ark Lanjutan

Mungkin memungkinkan untuk mengurangi persyaratan likuiditas Ark melalui pakta yang lebih canggih, jika biasanya likuiditas habis setengah jalan melalui putaran. Misalnya, mari kita anggap bahwa 50% dari total nilai V-UTXO dalam txout kolam telah digunakan. Jika ASP bisa menebus hanya bagian dari txout kolam putaran itu, mereka bisa memulihkan likuiditas lebih cepat, mengurangi biaya likuiditas secara keseluruhan. Meskipun belum ada proposal konkret tentang cara melakukannya, sepertinya sangat mungkin dilakukan dengan pakta Sufficiently Advanced ™. Kemungkinan besar melalui semacam soft-fork script revival yang menambahkan banyak opcode yang berguna sekaligus.

Demikian pula, melalui perjanjian Cukup Maju™, seluruh struktur pohon txout dapat diganti dengan semacam skema penarikan bergulir, yang berpotensi menawarkan penghematan ruang. Kami akan membahas ini di bagian lebih lanjut, karena teknik ini berpotensi berguna untuk skema lain.

Masalah penjagaan akhir putaran adalah kasus lain di mana perjanjian Sufficiently Advanced™ dapat memecahkan masalah: perjanjian, khususnya perjanjian bukti ZK, dapat memaksa ASP untuk membuat kembali semua V-UTXO yang belum dihabiskan pada putaran berikutnya, menghilangkan masalah penjagaan yang kembali kepada mereka pada akhir putaran. Meskipun mungkin tidak mungkin membuat ini tanpa kepercayaan, karena pengguna kemungkinan perlu beberapa data dari ASP untuk menghabiskan V-UTXO mereka pada putaran baru, ini dapat mencegah ASP mendapatkan keuntungan finansial dari penipuan terhadap pengguna offline.

Pembayaran Biaya On-Chain dalam Penarikan Unilateral

Sama seperti Lightning, ekonomi pembayaran biaya on-chain dan nilai sebenarnya dari V-UTXO setelah biaya menentukan apakah penggunaan Ark memenuhi definisi L2 kami melalui penarikan satu arah, atau penipuan yang tidak menguntungkan ASP. Kami akan membahas rincian ini lebih lanjut saat membahas pola desain pohon txout.

Validity Rollups

Sebuah kelas besar konstruksi mirip sidechain, umumnya diusulkan untuk menggunakan berbagai bentuk teknologi bukti pengetahuan nol (ZK) untuk menegakkan aturan rantai. Teknologi bukti ZK adalah perbedaan kritis antara teknologi rollup validitas dan bentuk lain dari sidechain: jika skema bukti ZK berhasil, validitas transaksi dapat dijamin oleh matematika daripada harus mempercayai pihak ketiga. Aspek “pengetahuan nol” dari bukti ZK sebenarnya bukan merupakan keharusan dalam kasus penggunaan ini: itu sama sekali tidak masalah jika bukti “bocor” informasi tentang apa yang sedang dibuktikan. Hanya saja kebetulan kebanyakan skema matematika untuk kelas bukti ini kebetulan menjadi bukti pengetahuan nol.

Dari sudut pandang Bitcoin, skema kesepakatan keabsahan memerlukan perjanjian, karena kita ingin dapat membuat UTXO untuk skema yang hanya bisa dihabiskan jika aturan skema diikuti. Ini tidak selalu proses terdesentralisasi. Banyak skema kesepakatan keabsahan sebenarnya sepenuhnya terpusat; bukti kesepakatan adalah membuktikan bahwa pengurutan transaksi terpusat mengikuti aturan untuk urutan transaksi tertentu.

Mengenai perjanjian apa pun... Teknologi Bukti Zero Pengetahuan masih merupakan bidang yang sangat baru, dengan kemajuan yang masih sering dilakukan. Jadi kemungkinan besar kita tidak akan melihat kode operasi apa pun yang ditambahkan ke Bitcoin yang secara langsung memvalidasi skema ZK-proof tertentu. Sebaliknya, secara umum diterima bahwa skema-spesifik akan menggunakan kode operasi yang lebih umum, khususnya OP_CAT, untuk memvalidasi ZK-proofs melalui skrip. Sebagai contoh, StarkWareadalahmencalonkan diri agar OP_CAT diadopsi.

Validity rollups adalah topik potensial yang sangat besar, dengan begitu banyak proyek rendah-substansi/tinggi-hype, sehingga kami tidak akan membahasnya lebih lanjut selain menunjukkan opcode mana yang mungkin membuat kelas desain ini layak.

BitVM

Secara kasar, BitVM adalah cara untuk membangun saluran petir antara dua pihak sehingga aturan saluran Lightning ditegakkan oleh bukti tanpa pengetahuan. Karena sebenarnya tidak memerlukan perjanjian untuk diterapkan pada Bitcoin hari ini, dan karena tidak dapat secara langsung digunakan untuk membuat sistem L2 yang berskala melampaui batas 1-UTXO-per-pengguna, kami tidak akan membahasnya lebih lanjut.

Saluran Hierarkis

Saluran Hirarkis¹⁰bertujuan membuat perubahan ukuran saluran cepat dan murah: "Saluran Hierarkis melakukan untuk kapasitas saluran apa yang dilakukan LN untuk bitcoin". Namun, mereka tetap tidak melebihi batas 1 UTXO-per-pengguna secara fundamental. Mereka juga tidak memerlukan perubahan apa pun pada protokol Bitcoin. Jadi kami tidak akan membahasnya lebih lanjut. Para pendukungnya seharusnya hanya mengimplementasikannya! Mereka tidak membutuhkan izin kami.

CoinPool

CoinPool memungkinkan beberapa pengguna untuk berbagi satu UTXO tunggal, mentransfer dana antar pengguna yang berbeda, dan menarik secara sepihak. Proposal kertas CoinPool memerlukan tiga fitur softfork baru, yaitu SIGHASH_ANYPREVOUT, SIGHASH_GROUP yang memungkinkan tanda tangan hanya berlaku untuk UTXO tertentu, dan OP_MerkleSub untuk memvalidasi penghapusan cabang tertentu dari pohon merkle; yang terakhir ini juga dapat dicapai dengan OP_CAT.

Saat ini pengembangan CoinPool tampaknya mengalami stagnasi, dengan komit terakhir ke situs web spesifikasi adalah dua tahun lalu.

Jaringan Enigma

Saat saya diminta untuk membahas Jaringan Engima, tampaknya ada kekurangan dokumentasi mengenai apa sebenarnya proposalnya. Bitfinex's pos blogmembuat banyak klaim; yang Halaman MIT kosong. Karena postingan blog tidak benar-benar menjelaskan apa yang seharusnya terjadi, kami tidak akan membahasnya lebih lanjut.

Pertimbangan Mempool

Kebijakan mempool saat ini di Bitcoin Core tidak ideal untuk sistem L2. Di sini kita akan membahas beberapa tantangan utama yang mereka hadapi, dan potensi peningkatan.

Transaction Pinning

Pada akhirnya, serangan penjenisan transaksi adalah eksploitasi ekonomi yang melibatkan berbagai situasi di mana seseorang dengan sengaja dapat (atau tidak disengajamembuatnya sulit untuk mendapatkan transaksi yang diinginkan ditambang karena transaksi yang bertentangan sebelumnya tidak ditambang. Ini adalah eksploitasi ekonomi, karena dalam situasi pinning transaksi yang sebenarnya, ada transaksi yang diinginkan yang akan menguntungkan para penambang jika mereka menambangnya; transaksi pinning yang bertentangan tidak ditambang dalam waktu yang wajar, jika pernah.

Contoh paling sederhana dari penyematan berasal dari fakta tanpa RBF penuh, penggantian transaksi dapat dimatikan. Dengan demikian, kita dapat memiliki transaksi suku bunga rendah, dengan penggantian dimatikan, yang tidak akan ditambang namun tidak dapat diganti. Pada dasarnya 100% kekuatan hash telah memperbaiki masalah ini dengan mengaktifkan RBF penuh, dan pada saat penulisan, RBF penuh harus diaktifkan secara default dalam rilis Bitcoin Core berikutnya (setelah 11 tahun usaha!).

Itu meninggalkan penancapan aturan BIP-125 #3, satu-satunya masalah penancapan yang relevan dengan protokol L2 multipihak dan belum diperbaiki di Bitcoin Core. Untuk referensi, aturan BIP-125 #3 menyatakan hal berikut:

Diperlukan transaksi pengganti untuk membayar biaya absolut yang lebih tinggi (bukan

hanya tingkat biaya) daripada jumlah biaya yang dibayarkan oleh semua transaksi yang digantikan.

Aturan ini dapat dieksploitasi dengan menyiaran transaksi pinning berbiaya rendah dan besar yang menghabiskan output yang relevan dengan protokol multiparty (atau kelompok transaksi). Karena transaksi tersebut memiliki fee-rate rendah, transaksi tersebut tidak akan ditambang tepat waktu, jika pernah. Namun, karena memiliki total biaya tinggi, menggantinya dengan transaksi yang berbeda tidak ekonomis.

Aturan #3 pinning dapat dengan mudah diperbaiki melaluireplace-by-fee-rate, dan perbaikan ini berfungsi di semua situasi. Sayangnya tidak jelas apakah RBFR akan diadopsi oleh Core dalam waktu dekat, karena mereka telah menghabiskan sejumlah besar upaya pada solusi parsial yang lebih rendah, Transaksi TRUC/V3.

Pembayaran Biaya: RBF, CPFP, SIGHASH_ANYONECANPAY, Anchor, dan Sponsorship

Karena tingkat biaya yang tidak dapat diprediksi, membayar secara andal dan ekonomis dalam situasi di mana transaksi telah ditandatangani sebelumnya sulit dilakukan. Standar emas untuk pembayaran biaya adalah menggunakan RBF, dimulai dengan perkiraan awal yang rendah, dan mengganti transaksi dengan versi biaya yang lebih tinggi jika diperlukan hingga berhasil ditambang. Sebagai contoh, perangkat lunak kalender OpenTimestamps telah menggunakan RBF ini selama bertahun-tahun, dan LND menambahkan dukungan untuk ...RBF yang sadar tenggat waktu di v0.18.

RBF adalah standar emas untuk pembayaran biaya karena paling efisien dalam hal ruang blok hampir di semua¹¹situasi: transaksi pengganti tidak memerlukan input atau output tambahan, relatif terhadap apa yang akan diperlukan jika biaya yang benar telah ditebak pada percobaan pertama.

Efisiensi itu penting, karena inefisiensi dalam pembayaran biaya membuat pembayaran biaya di luar jalur sumber pendapatan yang menguntungkan bagi penambang besar; Lebih kecil, terdesentralisasi, penambang tidak dapat mengambil untung dari pembayaran biaya out-of-band karena ketidakpraktisan dan tidak berguna membayar penambang kecil untuk mendapatkan konfirmasi transaksi. Pembayaran biaya out-of-band juga tampaknya mengundang masalah AML / KYC: saat ini, sebagian besar sistem pembayaran biaya out-of-band yang sebenarnya tersedia saat ini memerlukan semacam proses AML / KYC untuk melakukan pembayaran biaya, dengan pengecualian Akselerator mempool.space, yang pada saat penulisan (Agustus 2024), menerima Lightning tanpa akun.

Untuk menggunakan RBF secara langsung dalam situasi dengan transaksi yang telah ditandatangani sebelumnya, Anda perlu menandatangani varian biaya yang mencakup berbagai biaya potensial. Meskipun ini cukup layak dalam banyak kasus karena jumlah varian yang diperlukan biasanya kecil¹², sejauh ini protokol Lightning produksi — dan protokol yang diajukan lainnya — memilih untuk menggunakan Child-Pays-For-Parent(CPFP), biasanya melalui output anchor.

Ide di balik output anchor adalah dengan menambahkan satu atau lebih output ke dalam transaksi dengan nilai minimal atau nol, dengan tujuan membayar biaya melalui CPFP dengan mengeluarkan output tersebut dalam transaksi sekunder. Tentu saja ini sangat tidak efisien ketika diterapkan pada protokol seperti LN yang memiliki transaksi on-chain kecil, hampir tidak berarti.menggandakan ukuran total dari transaksi komitmen LN yang menggunakan output anchor sementara. Itu akan menjadi lebih sedikit kekhawatiran ketika menerapkan protokol yang menggunakan transaksi yang lebih besar, seperti apapun yang menggunakan OP_CAT untuk mengimplementasikan perjanjian.

Masalah yang kurang jelas dengan output jangkar adalah kebutuhan untuk tetap menggunakan UTXO tambahan untuk membayar biaya. Dalam aplikasi "klien" yang khas, ini bisa menjadi beban keseluruhan yang signifikan, karena tanpa output jangkar seringkali tidak perlu sama sekali untuk mempertahankan lebih dari satu UTXO. Memang, ada kemungkinan bahwa beberapa dompet Lightning yang berfokus pada konsumen yang ada rentan terhadap pencurian oleh sisi saluran yang jauh di lingkungan berbiaya tinggi karena ketidakmampuan untuk membayar biaya.

SIGHASH_ANYONECANPAY dapat digunakan untuk pembayaran biaya dalam beberapa kasus dengan memungkinkan input tambahan ditambahkan ke transaksi yang ditandatangani; SIGHASH_SINGLE memungkinkan juga ditambahkannya output. Lightning menggunakan ini untuk transaksi HTLC. Saat ini praktik ini rentan terhadap penahanan transaksi jika tidak ditangani dengan hati-hati.¹³, karena seorang penyerang dapat menambahkan sejumlah besar input dan/atau output ke dalam transaksi untuk membuat pin dengan biaya tinggi/tarif biaya rendah. RBFR memperbaiki masalah ini; pendekatan yang digunakan dalam transaksi TRUC/V3 tidak dapat memperbaiki masalah ini. Gaya pembayaran biaya ini tidak efisien seperti RBF. Tetapi dapat lebih efisien daripada output jangkar.

Akhirnya ada berbagai proposal soft-fork untuk menambahkan biaya sponsor sistem ke protokol Bitcoin. Ini akan memungkinkan transaksi untuk menyatakan ketergantungan pada transaksi lain, sehingga transaksi sponsor hanya dapat ditambang jika transaksi sponsor juga ditambang (kemungkinan besar di blok yang sama). Ini bisa jauh lebih efisien daripada CPFP tradisional karena transaksi sponsor dapat menyatakan bahwa ketergantungan menggunakan vbytes yang jauh lebih sedikit daripada ukuran input transaksi.

Penggantian Bersepeda

Serangan Penggantian Bersepeda¹⁴ mengambil keuntungan dari penggantian transaksi untuk mencoba mengganti transaksi L2 yang diinginkan cukup lama untuk mendapatkan yang tidak diinginkan ditambang sebagai gantinya. Pada dasarnya, serangan siklus pengganti, bagi penyerang, merupakan alternatif untuk teknik penyematan transaksi karena mereka bertujuan untuk mencegah transaksi yang diinginkan, jujur, ditambang cukup lama untuk memungkinkan transaksi yang tidak diinginkan dan tidak jujur untuk ditambang sebagai gantinya. Tidak seperti serangan penyematan transaksi, serangan siklus pengganti tidak dapat terjadi secara tidak sengaja.

Contoh kanonikal adalah melawan Kontrak Terkunci Waktu Hashed (HTLC). Meskipun mudah untuk berpikir bahwa HTLC adalah kontrak untuk mengizinkan transaksi untuk dibelanjakan melalui pengungkapan preimage, atau melalui waktu habis. Kenyataannya, karena keterbatasan pengkodean skrip Bitcoin, HTLC memungkinkan transaksi selalu dibelanjakan melalui pengungkapan preimage, dan kemudian setelah waktu habis, tambahan melalui mekanisme waktu habis.

Siklus penggantian memanfaatkan ini menggunakan preimage setelah batas waktu, untuk mengganti transaksi yang mencoba menebus output HLTC melalui mekanisme batas waktu tanpa korban mempelajari preimage. Serangan bersepeda pengganti yang berhasil melakukan ini cukup lama untuk HTLC saluran yang berbeda untuk waktu habis.

Tantangan utama dalam memanfaatkan siklus penggantian dengan untung adalah bahwa setiap putaran penggantian menghabiskan uang. Implementasi Lightning yang sadar akan batas waktu akan mengeluarkan biaya yang lebih tinggi dalam upaya untuk menghabiskan output HTLC yang kedaluwarsa sebelum jatuh tempo output HTLC berikutnya berakhir. Kedua, siapa pun dapat mengalahkan serangan tersebut dengan hanya menyiarkan ulang transaksi yang digantikan¹⁵setelah siklus penggantian selesai.

Seperti halnya penyematan transaksi, siklus penggantian juga merupakan eksploitasi ekonomi bagi para penambang. Pada akhir setiap siklus penggantian, ada transaksi yang telah dihapus dari mempool, namun sepenuhnya valid dan dapat ditambang jika hanya penambang yang masih memilikinya di mempool mereka.

Pola Fitur dan Fork Lunak

Sekarang setelah kami memberikan gambaran tentang berbagai sistem L2 yang tergantung pada perjanjian yang ada, dan tantangan mempool, kami akan mencoba merangkum informasi tersebut menjadi seperangkat fitur fork lunak yang mencolok (terutama opcode baru) dan pola desain yang dibagikan oleh sistem L2 ini. Untuk proposal fork lunak, kami juga akan membahas risiko teknis dan tantangan khusus dari setiap proposal untuk didukung.

OP_Expire

Mari kita selesaikan ini terlebih dahulu. OP_Expire diusulkan¹⁶ sebagai cara sederhana untuk menghilangkan serangan bersepeda pengganti dengan memperbaiki masalah pada sumbernya: fakta bahwa HTLC dapat dihabiskan dengan dua cara berbeda sekaligus. Dalam konteks sistem L2, ini relevan untuk apa pun yang menggunakan mekanisme seperti HTLC, dan mungkin kasus penggunaan lainnya. OP_Expire akan memungkinkan output transaksi menjadi tidak dapat dibelanjakan setelah suatu titik waktu, memungkinkan kondisi pengeluaran HTLC menjadi OR eksklusif sejati daripada "programmer ATAU".

Soft-fork OP_Expire yang sebenarnya kemungkinan besar terdiri dari dua fitur, mirip dengan cara bagaimana ituOP_CheckLockTimeVerifydanOP_CheckSequenceVerify Opcode datang dalam dua bagian:

1. Sebuah bidang tinggi kadaluarsa untuk transaksi, kemungkinan besar diimplementasikan dalam lampiran taproot.
2. Sebuah opcode OP_Expire yang memeriksa bahwa ketinggian kedaluwarsa diatur setidaknya pada ketinggian yang diinginkan.

Sementara OP_Expire sendiri hampir tidak memenuhi syarat sebagai perjanjian, itu tampaknya berguna untuk banyak sistem L2 yang bergantung pada perjanjian. Namun, itu mungkin tidak cukup berguna mengingat bahwa bersepeda pengganti juga dapat dikurangi dengan penyiaran ulang altruistik¹⁵

Tantangan yang sangat mencolok dalam implementasi dan penggunaan OP_Expire adalah reorgs: komunitas teknis Bitcoin, dimulai dengan Satoshi¹⁷, telah berusaha untuk memastikan bahwa protokol konsensus Bitcoin dirancang sedemikian rupa sehingga setelah deep reorg, transaksi yang sebelumnya telah ditambang dapat ditambang ke dalam blok baru. Prinsip desain ini berusaha untuk menghindari skenario mimpi buruk di mana sejumlah besar koin yang telah dikonfirmasi menjadi tidak valid secara permanen — dan dengan demikian orang-orang yang mengandalkan koin-koin tersebut kehilangan uang — jika kegagalan konsensus mengakibatkan reorg yang besar.

Dalam kasus reorg besar, transaksi yang menggunakan kadaluwarsa dapat menjadi tidak dapat ditambang karena mencapai ketinggian kadaluwarsa. Proposal OP_Expire, mengusulkan untuk mengatasi masalah ini dengan memperlakukan output dari transaksi yang menggunakan kadaluwarsa secara serupa dengan transaksi coinbase, juga membuatnya tidak dapat dibelanjakan selama ~100 blok.

Hambatan signifikan untuk menerapkan kedaluwarsa transaksi akan mencapai konsensus tentang apakah trade-off ini dapat diterima, atau bahkan diperlukan. Jenis transaksi di mana OP_Expire akan berguna sudah melibatkan timeout yang lama di mana dana pengguna dibekukan. Menambahkan lebih banyak waktu ke timeout ini tidak diinginkan. Juga, pengeluaran ganda selalu menjadi cara lain untuk membatalkan koin setelah reorg: dengan meningkatnya penggunaan RBF dan usulan penggunaan output jangkar tanpa kunci, apakah kedaluwarsa transaksi akan membuat perbedaan yang signifikan?

SIGHASH_ANYPREVOUT

BIP-118mengusulkan dua mode hashing tanda tangan baru, yang keduanya tidak berkomitmen pada UTXO tertentu yang digunakan. SIGHASH_ANYPREVOUT, yang (secara esensial) berkomitmen pada scriptPubKey, dan SIGHASH_ANYPREVOUTANYSCRIPT, yang memungkinkan setiap script. Seperti yang dibahas di atas, ini awalnya diusulkan untuk digunakan oleh LN-Symmetry untuk menghindari kebutuhan untuk secara terpisah tanda tangan setiap status saluran sebelumnya yang mungkin perlu direspons.

SIGHASH_ANYPREVOUT juga potensial digunakan dalam kasus di mana kita ingin menggunakan varian tarif biaya RBF yang ditandatangani sebelumnya bersama dengan transaksi yang ditandatangani sebelumnya, karena kenyataan bahwa tanda tangan tidak lagi bergantung pada txid spesifik menghindari sebuahledakan kombinatorial varian tarif-biaya. Namun, proposal BIP-118 saat ini tidak mengatasi kasus penggunaan ini, dan mungkin tidak kompatibel dengan hal itu karena SIGHASH_ANYPREVOUT juga diusulkan untuk mengikat nilai dari UTXO.

Sebuah keberatan awal terhadap SIGHASH_ANYPREVOUT adalah gagasan bahwa dompet akan mendapatkan masalah dengan menggunakannya secara tidak tepat. Masalahnya adalah bahwa begitu tanda tangan SIGHASH_ANYPREVOUT tunggal telah diterbitkan, itu dapat digunakan untuk menghabiskan txout apa pun dengan skrip yang ditentukan. Oleh karena itu, jika output kedua dengan skrip yang sama secara tidak sengaja dibuat, SIGHASH_ANYPREVOUT memungkinkan untuk serangan replay yang remeh untuk mencuri koin-koin tersebut. Namun, karena ada begitu banyak footguns lain yang melekat pada dompet dan implementasi L2, kekhawatiran ini tampaknya telah reda.

Saat ini, komunitas teknis umum nampaknya cukup positif tentang mengimplementasikan BIP-118. Namun, seperti yang dibahas di atas dalam pembahasan LN-Symmetry kami, ada perdebatan tentang apakah kasus penggunaan utamanya — LN-Symmetry — sebenarnya merupakan ide yang baik.

OP_CheckTemplateVerify

Proposal opcode pertama kami yang spesifik untuk perjanjian, OP_CheckTemplateVerify — atau yang biasa disebut “CTV” — bertujuan untuk membuat opcode perjanjian yang sangat spesifik dan terbatas dengan melakukan satu hal saja: menghash transaksi pengeluaran dengan cara tertentu yang tidak mengikat pada input UTXO, dan memeriksa hasil digestnya dengan elemen tumpukan teratas. Ini memungkinkan transaksi pengeluaran dibatasi sebelumnya, tanpa membuat batasan perjanjian rekursif yang sebenarnya.

Mengapa perjanjian rekursif tidak mungkin dalam CTV? Karena fungsi hash: CTV memeriksa transaksi pengeluaran dengan hash template, dan tidak ada cara¹⁸menciptakan template yang berisi CTV dengan hash dirinya sendiri.

Dikatakan demikian, ini bukanlah batasan yang nyata: Anda dapat dengan mudah menghash rantai hash template CTV hingga kedalaman puluhan juta transaksi dalam beberapa detik di komputer modern. Dengan kunci waktu nSequence relatifdan ukuran blok terbatas sebenarnya mencapai akhir rantai tersebut bisa dengan mudah memakan ribuan tahun.

Proposal CTV saat ini di BIP-119memiliki hanya satu mode hashing, yang dikenal sebagai DefaultCheckTemplateVerifyHash, yang pada dasarnya menyetujui setiap aspek dari transaksi pengeluaran dalam hash template. Dalam pandangan praktis, hal ini berarti bahwa dalam banyak situasi, mekanisme yang tersedia untuk pembayaran biaya hanya akan menjadi CPFP. Seperti yang disebutkan di atas, ini merupakan masalah potensial karena membuat pembayaran biaya di luar jalur menjadi penghematan biaya yang tidak mudah dalam kasus di mana transaksi yang menggunakan CTV adalah kecil.

Dapat dikatakan bahwa CTV mendapat dukungan terluas di kalangan komunitas teknis daripada proposal opcode perjanjian manapun karena kelengkapan relatifnya dan beragamnya kasus penggunaan.

LNHANCE

Salah satu proposal untuk mengimplementasikan CTV adalah menggabungkannya dengan dua opcode lagi, OP_CheckSigFromStack (Verifikasi) dan OP_InternalKey. Masalahnya adalah, pada saat penulisan, dokumentasi dalam pull-req dan BIP terkait tidak cukup untuk memperdebatkan atau menentang proposal ini. BIP sama sekali tidak memiliki rasional untuk apa yang diharapkan opcode untuk benar-benar dilakukan dalam contoh dunia nyata, apalagi contoh skrip yang mendalam.

Sementara para penulis mungkin memiliki alasan yang baik untuk proposal mereka, beban terletak pada mereka untuk benar-benar menjelaskan alasan tersebut dan membenarkannya dengan baik. Oleh karena itu, kami tidak akan membahasnya lebih lanjut.

OP_TXHASH

Sama seperti CTV, proposal ini mencapai fungsionalitas perjanjian non-rekursif dengan menghash data dari transaksi pengeluaran. Tidak seperti CTV, proposal TXHASH menyediakan mekanisme "pemilih lapangan", yang memungkinkan fleksibilitas dalam cara tepat transaksi pengeluaran dibatasi. Fleksibilitas ini mencapai dua tujuan utama:

1. Memungkinkan penambahan biaya ke dalam transaksi tanpa merusak protokol multi-transaksi.
2. Protokol multi-pengguna di mana pengguna hanya membatasi masukan dan keluaran mereka sendiri.

Masalah utama dengan OP_TXHASH adalah bahwa mekanisme pemilih bidang menambah kompleksitas yang cukup banyak, sehingga membuat tinjauan dan pengujian menjadi lebih menantang dibandingkan dengan proposal CTV yang jauh lebih sederhana. Saat ini, belum ada analisis desain yang cukup mengenai seberapa bermanfaat mekanisme pemilih bidang tersebut sebenarnya, atau bagaimana tepatnya cara penggunaannya. Oleh karena itu, kita tidak akan membahasnya lebih lanjut.

OP_CAT

Operator penggabungan, yang menggabungkan dua elemen teratas dari tumpukan dan mendorong hasil penggabungan kembali ke tumpukan. Bitcoin awalnya dikirim dengan OP_CAT diaktifkan. Tapi Satoshi diam-diam menghapusnya pada tahun 2010, mungkin karena implementasi awal rentan terhadap serangan DoS karena kurangnya pembatasan pada ukuran elemen script yang dihasilkan. Pertimbangkan skrip berikut:

DUP KUCING DUP KUCING...

Tanpa batasan ukuran elemen, setiap iterasi DUP CAT menggandakan ukuran elemen tumpukan teratas, akhirnya menggunakan semua memori yang tersedia.

Rangkaian cukup untuk mengimplementasikan banyak jenis perjanjian, termasuk perjanjian rekursif, dengan melakukan yang berikut:

1. Kumpulkan transaksi parsial, tanpa data saksi, di stack dengan satu atau lebih invokasi OP_CAT (dan logika khusus perjanjian apa pun yang diperlukan).
2. Validasi bahwa transaksi pada stack sesuai dengan transaksi pengeluaran.

Ternyata, dengan menyalahgunakan matematika tanda tangan Schnorr, mungkin dilakukan langkah kedua menggunakan OP_CheckSig melalui tanda tangan yang dibuat dengan hati-hati. Namun, lebih mungkin bahwa soft-fork OP_CAT akan digabungkan dengan OP_CheckSigFromStack, memungkinkan langkah kedua dilakukan dengan memvalidasi bahwa tanda tangan yang ada di tumpukan adalah tanda tangan yang valid untuk transaksi tersebut¹⁹dan kemudian menggunakan tanda tangan yang sama dengan OP_CheckSig untuk memvalidasi bahwa transaksi pengeluaran sesuai.²⁰

Fakta bahwa kita hanya perlu mengumpulkan transaksi tanpa data saksi adalah poin kunci: perjanjian hanya perlu memvalidasi apa yang dilakukan transaksi – input dan outputnya – bukan data saksi (jika ada) yang benar-benar membuatnya valid.

Dengan batasan ukuran skrip modulo, kombinasi OP_CAT dan OP_CheckSigFromStack sudah cukup untuk membangun banyak jenis perjanjian, termasuk perjanjian rekursif. Dibandingkan dengan solusi yang lebih efisien seperti CTV, biayanya lebih mahal. Namun, perbedaan biaya lebih kecil dari yang Anda harapkan!

Secara kasar, menggunakan OP_CAT untuk melakukan ini memerlukan semua bagian non-witness dari transaksi pengeluaran ditempatkan di tumpukan melalui saksi. Untuk kasus penggunaan CTV yang khas seperti pohon txout, transaksi pengeluaran tidak akan memiliki data saksi sama sekali. Karena ruang saksi didiskon 75%, itu meningkatkan biaya transaksi efektif untuk transaksi anak hanya sebesar 25%. Tidak buruk!

Apakah OP_CAT Terlalu Kuat?

Ini mungkin merupakan hambatan politik dan teknis terbesar untuk menerapkan OP_CAT: sangat sulit untuk memprediksi kasus penggunaan apa yang akan dimungkinkan oleh OP_CAT. Dan begitu "kucing" keluar dari tas, sangat sulit untuk memasukkannya kembali.

Contoh bagus adalah bagaimana OP_CAT diklaim cukup untuk memungkinkan efisiensi yang cukup dan amanVerifikasi STARK yang akan diterapkan dalam skrip Bitcoin. Karena STARKs mampu membuktikan pernyataan yang sangat umum, membuatnya memungkinkan untuk menerapkan STARKs secara efisien memiliki dampak signifikan yang melampaui cakupan sistem L2 karena hal itu akan memungkinkan banyak sistem yang berbeda dibangun di atas Bitcoin. Argumen kuat melawan OP_CAT adalah bahwa kasus penggunaan ini mungkin tidak sepenuhnya baik bagi pengguna Bitcoin.

Penciptaan Nilai Ekstraktable oleh Penambang yang Membahayakan Pusat adalah masalah potensial yang sangat penting,disebut “MEV yang jahat” (MEVil) oleh Matt Corallo. Singkatnya, MEVil adalah keadaan di mana penambang / kolam besar dapat mengekstrak nilai tambahan dengan menggunakan strategi penambangan transaksi yang canggih - lebih dari sekadar memaksimalkan total biaya - yang tidak praktis untuk diadopsi oleh penambang / kolam yang lebih kecil. Kompleksitas geser instrumen keuangan potensial yang dapat dibuat dengan OP_CAT membuat mengesampingkan MEVil sangat sulit. MEVil yang signifikan telah muncul di Bitcoin dari protokol lelang token; untungnya kasus spesifik itu dikalahkan melalui adopsi RBF penuh.

Selain potensi MEVil, ada banyak kasus penggunaan OP_CAT konkret lainnya yang berpotensi berbahaya. Misalnya, proposal Drivechains telah ditinjau di sini, dan secara luas dianggap merugikan bagi Bitcoin. Ini adalah dianggap mungkinuntuk mengimplementasikan Drivechain’s dengan OP_CAT. Contoh lain adalah proposal token seperti Aset Taproot. Meskipun umumnya tidak mungkin mencegah implementasi mereka dengan validasi sisi klien, ada proposal untuk menerapkannya dengan OP_CAT dengan cara yang mungkin lebih menarik bagi pengguna akhir, sambil juga menggunakan lebih banyak ruang blok, yang pada akhirnya dapat mengalahkan transaksi Bitcoin yang “sahe”. Penggunaan ini juga dapat menimbulkan masalah hukum karena seberapa sering protokol token digunakan untuk penipuan keuangan.

Penghasingan Bertahap

Untuk perjanjian, OP_CAT akan digunakan utamanya untuk menggabungkan data, dan kemudian menghashnya. Cara lain untuk mencapai tujuan yang sama ini adalah dengan opcode penghashan bertahap yang mengambil SHA256 midstate dari beberapa jenis, dan menghash lebih banyak data ke dalamnya; SHA256 sendiri beroperasi pada blok 64-byte. Ada banyak desain yang mungkin untuk opcode penghashan bertahap.

Salah satu keputusan desain penting adalah apakah akan mengungkapkan byte midstate sebenarnya di dalam tumpukan dalam bentuk kanonik, atau mewakili mereka dalam jenis item tumpukan yang transparan baru yang nilai bytenya sebenarnya tidak dapat dimanipulasi secara langsung. SHA256 ditetapkan untuk vektor inisialisasi tertentu, tetap, dan tampaknya tidak diketahui apakah properti kriptografi SHA256 tetap benar jika midstate/vektor inisialisasi sembarang diizinkan.

Tentu saja, karena hashing bertambah dapat melakukan hampir semua yang OP_CAT bisa lakukan, hanya lebih efisien, maka semua kekhawatiran tentang OP_CAT terlalu kuat berlaku juga.

Pemulihan Script

OP_CAT adalah salah satu opcode yang dinonaktifkan oleh Satoshi. Selain mengembalikan OP_CAT, Rusty Russell mengusulkan²¹untuk pada dasarnya mengembalikan skrip Bitcoin ke “Visi Asli Satoshi” dengan mengaktifkan kembali sebagian besar opcode tersebut, menambahkan batasan DoS, dan mungkin menambahkan beberapa lagi dalam soft-fork yang sama. Terutama, OP_CheckSigFromStack kemungkinan besar.

Meskipun OP_CAT saja memungkinkan adanya perjanjian (rekursif), sebuah "script revival" penuh akan membuat perjanjian yang lebih canggih menjadi mungkin - dan jauh lebih mudah untuk diimplementasikan - karena bagian-bagian dari transaksi pengeluaran dapat dimanipulasi secara langsung. Sebagai contoh, Anda bisa membayangkan sebuah skrip perjanjian yang menggunakan opcode aritmatika untuk memastikan bahwa total nilai dari txouts dalam transaksi sesuai dengan beberapa properti yang diinginkan.

Sekali lagi, kebangkitan skrip menimbulkan keprihatinan yang sama, dan lebih banyak lagi, tentang menjadi terlalu kuat yang hanya dimiliki oleh OP_CAT saja.

Kesederhanaan

Sama seperti Script Revival, Simplicity berkaitan dengan L2 dan perjanjian dengan memungkinkan segala hal dilakukan. Tidak seperti Script Revival, soft-fork Simplicity akan menambahkan bahasa pemrograman yang benar-benar baru ke sistem scripting Bitcoin berdasarkan sembilan operator primitif yang dikenal sebagai kombinator.

Dalam prakteknya, Simplicity terlalu sederhana, dan sama sekali tidak sederhana. Kombinator primitif sangat rendah sehingga operasi dasar seperti penambahan harus diimplementasikan dengan susah payah dari awal; Simplicity mentah akan sangat panjang dalam prakteknya. Oleh karena itu, penggunaan nyata Simplicity akan menggunakan sistem substitusi kode, mirip dengan panggilan fungsi pustaka, yang dikenal sebagai jets. Ini menimbulkan masalah praktis / politis: bagaimana Anda memutuskan untuk menerapkan jet mana? Kemungkinan besar jet akan diimplementasikan dalam C++, seperti opcode lainnya, memerlukan fork lunak untuk setiap jet baru.

OP_FancyTreeManipulationStuff

Ada beragam opcode yang relatif spesifik yang telah diusulkan untuk melakukan manipulasi pohon secara efisien dalam ruang untuk proposal L2 yang bergantung pada perjanjian. Sebagai contoh, Coinpools telah mengusulkan keduanya TAPLEAF_UPDATE_VERIFY dan OP_MERKLESUB, keduanya memanipulasi pohon taproot dengan cara yang diperlukan untuk proposal Coinpools, dan MATTusulan telah mengusulkan opcode OP_CheckContractVerify yang, pada dasarnya, memverifikasi pernyataan tentang pohon merkle.

Untuk tujuan artikel ini, kita tidak perlu memperinci setiap satu dari banyak proposal ini. Sebaliknya, kita dapat membicarakannya sebagai sebuah kelompok: semuanya adalah proposal yang relatif spesifik untuk kasus penggunaan yang membuat satu kelas L2 menjadi mungkin, idealnya tanpa efek samping yang tidak diinginkan. Semuanya memiliki keunggulan dalam efisiensi: semuanya menggunakan ruang blok yang lebih sedikit daripada mencapai tujuan yang sama dengan opcode yang lebih generik seperti manipulasi OP_CAT. Tetapi semuanya memiliki kelemahan dalam menambah kompleksitas pada sistem script, untuk penggunaan yang mungkin hanya pada segelintir kasus.

Hal yang sama akan terjadi jika Bitcoin mengadopsi sistem scripting Simplicity. Setara dengan opcode dalam Simplicity adalah menambahkan jet untuk pola yang umum digunakan. Lagi, mengimplementasikan jet untuk operasi kasus pengguna seperti manipulasi pohon memiliki kelebihan dan kekurangan yang mirip dengan mengimplementasikan opcode kompleks untuk operasi kasus pengguna.

Kolam Dana

Semua sistem L2 yang mencoba memiliki beberapa pengguna berbagi satu UTXO dapat dianggap sebagai semacam kolam dana multi-pengguna, dengan pengguna memiliki semacam hak penarikan. Potensialnya, akan ada juga mekanisme untuk menambah dana ke dalam kolam (selain membuat kolam dengan dana yang sudah ditetapkan sebelumnya).

Untuk kolam dana menjadi berguna, harus ada jenis 'data bagi state' yang terkait dengannya: bagaimana nilai txout dibagi? Jika kolam dana akan berkembang seiring waktu, state tersebut juga harus berubah saat dana ditambahkan atau dihapus dari kolam. Karena kita membangun di atas Bitcoin, menambahkan atau menghapus dana dari kolam akan melibatkan pengeluaran UTXO yang dikendalikan oleh kolam.

Ingatlah bahwa sistem konsensus Bitcoin itu sendiri didasarkan pada validasi perubahan keadaan: transaksi membuktikan melalui saksi mereka bahwa perubahan pada keadaan yang ditetapkan UTXO adalah valid; Bukti kerja memungkinkan kita mencapai konsensus tentang rangkaian transaksi mana yang benar. Ini berarti bahwa kumpulan dana itu sendiri juga akan didasarkan pada validasi perubahan negara: kami membuktikan kepada setiap node Bitcoin bahwa aturan untuk kumpulan dana diikuti pada setiap perubahan negara.

Tetapi ada aspek kunci lain untuk kumpulan dana L2 yang tidak dapat dipercaya: ketika keadaan kumpulan dana berubah, sistem harus secara inheren mempublikasikan data yang cukup bagi pengguna yang berpartisipasi dalam kumpulan dana untuk memulihkan dana mereka. Jika kami belum melakukan itu, maka sistem kami gagal memberikan penarikan sepihak, tanpa kerja sama pihak ketiga. Banyak skema berbasis rollup gagal di sini: mereka mengalami kegagalan ketersediaan data, di mana pengguna tidak dapat memulihkan dana mereka jika koordinator pihak ketiga offline, karena mereka tidak memiliki cara untuk mendapatkan data yang diperlukan bagi mereka untuk membangun transaksi pemulihan dana yang valid.

Dengan mempertimbangkan kendala-kendala ini, struktur data seperti apa yang digunakan oleh dana investasi? Tanpa terhindarkan, semuanya adalah jenis pohon tertentu. Secara khusus, jenis pohon merkle. Mereka harus berbentuk pohon, karena itu adalah satu-satunya struktur data yang dapat diskalakan dalam ilmu komputer; mereka harus merkelized, karena itu adalah satu-satunya cara yang masuk akal untuk secara kriptografis mengikat keadaan pohon tersebut. Terakhir, pembaruan pada pohon ini tak terhindarkan akan dipublikasikan ke blockchain Bitcoin, karena itulah satu-satunyamedia publikasi semua pengguna L2 berbagi, dan satu-satunya yang dapat kami paksa pengguna untuk mempublikasikan untuk memindahkan koin. Dan karena setiap implementasi perjanjian akan membutuhkan bagian-bagian pohon untuk memvalidasi bahwa aturan-aturan perjanjian sedang diikuti.

Jadi, dengan teori tingkat tinggi selesai, bagaimana cara menerjemahkan ini ke dalam skrip dan transaksi Bitcoin secara aktual?

Transaksi Individual yang Ditandatangani Sebelumnya

Kasus degeneratif dari pohon, dengan tepat satu daun di dalamnya. Di sini, keadaan kolam dana kita dapat berubah, secara kasar, sekali. Sebagai contoh, saluran Lightning standar masuk ke dalam kategori ini, dan setelah dibuka, hanya dapat ditutup. Data yang dipublikasikan ketika saluran ditutup adalah transaksi itu sendiri, yang merupakan informasi yang cukup bagi pihak lawan dalam saluran untuk mengetahui txid dari data blockchain, dan memulihkan dana mereka dengan menghabiskannya.

Satu-satunya “perjanjian” yang diperlukan di sini adalah perjanjian paling dasar: transaksi yang ditandatangani sebelumnya.

Pohon Txout

Pola desain berikutnya yang lebih kompleks yang kita lihat di kumpulan dana adalah pohon txout. Ark adalah contoh penting. Di sini kumpulan dana dapat dibagi dengan membelanjakan UTXO root dalam pohon transaksi yang telah ditentukan sebelumnya, ditegakkan dengan perjanjian sederhana seperti transaksi yang telah ditandatangani sebelumnya atau CTV, membagi nilai UTXO tersebut menjadi jumlah yang lebih kecil dan lebih kecil sampai node daun tercapai yang dapat dibelanjakan oleh pemilik yang sah.

Penting untuk diakui bahwa tujuan dari pohon txout adalah memberi pengguna opsi tentang bagaimana memulihkan dana mereka, dan opsi-opsi tersebut datang dengan biaya: pohon txout akan selalu menjadi cara yang lebih mahal untuk membagi kelompok dana, mengembalikannya kepada pemiliknya, daripada hanya membagi UTXO dalam satu transaksi. Setiap lapisan dalam pohon menambah biaya karena byte yang digunakan dalam txouts dan txins yang diperlukan untuk membuat lapisan tersebut.

Jadi, jenis opsi apa yang mungkin disediakan oleh pohon txout? Sekali lagi, Ark adalah contoh yang bagus: kita tidak ingin penebusan on-chain dari satu V-UTXO memerlukan setiap V-UTXO untuk dimasukkan ke dalam rantai. Dengan menggunakan pohon, penebusan dapat membagi pohon menjadi bagian-bagian kecil sampai V-UTXO yang diinginkan dimasukkan ke dalam rantai.

Sama seperti kasus transaksi pratinjau individu, informasi yang dipublikasikan adalah transaksi itu sendiri, yang memberi tahu dompet pengguna lain bagaimana menghabiskan dana mereka jika diperlukan.

Skalabilitas pohon txout memiliki ekonomi skala yang menarik. Biaya untuk V-UTXO pertama yang dimasukkan ke dalam rantai, dalam kolam dana dengan n V-UTXO, kira-kira log2(n)log2⁡(n) kali lebih mahal daripada transaksi tunggal karena log2(n) tingkat transaksi terbagi harus dimasukkan ke dalam rantai. Namun, setelah V-UTXO pertama dimasukkan ke dalam rantai, V-UTXO selanjutnya menjadi lebih murah untuk ditebus di rantai karena orang lain sudah membayar biaya untuk menambang transaksi perantara.

Ingatlah bahwa jumlah total elemen dalam pohon biner dengan

n daun adalah 2n. Ini berarti bahwa untuk menempatkan semua V-UTXO di rantai, biaya total untuk melakukannya melalui pohon txout akan menjadi kelipatan kecil dari biaya total untuk melakukannya dalam satu transaksi. Menakjubkan efisien!

Atau mungkin tidak... Jika ukuran total penebusan kumpulan dana cukup tinggi, mereka mungkin mewakili permintaan non-sepele pada total keseluruhan blockspace. Blockspace adalah sistem penawaran dan permintaan, sehingga pada titik tertentu biaya akan naik karena permintaan yang tinggi. Pada ekstremnya, sangat mungkin untuk membuat pohon txout begitu besar dan begitu dalam sehingga benar-benar menebus setiap

V-UTXO di dalam pohon tidak mungkin.

Pertanyaan terbuka dengan pohon txout adalah siapa yang membayar biaya, dan bagaimana? Salah satu solusi yang jelas adalah menggunakan output anchor tanpa kunci pada transaksi daun, dan memungkinkan siapa saja yang ingin transaksi daun tersebut ditambang untuk membayar biaya melalui CPFP. Dalam beberapa kasus penggunaan, V-UTXO itu sendiri dapat dihabiskan segera setelah dibuat, tanpa penundaan CSV, sehingga V-UTXO itu sendiri dapat dihabiskan untuk menambahkan biaya melalui CPFP.

RBF sulit untuk diimplementasikan karena izin: tempat yang jelas untuk mengambil biaya untuk RBF adalah nilai V-UTXO. Tetapi bagaimana Anda memastikan bahwa hanya pemilik yang memiliki kemampuan untuk menandatangani transaksi biaya yang lebih tinggi? Dalam banyak keadaan, tidak jelas bagaimana melakukannya dengan cara yang lebih efisien daripada output anchor tanpa kunci. Namun, gagal melakukannya memunculkan tantangan serius bagi skema yang digunakan oleh dompet pengguna akhir, yang mungkin tidak memiliki UTXO untuk dihabiskan untuk melakukan CPFP, jika V-UTXO itu sendiri tidak dapat dihabiskan segera.

Akhirnya, pemikiran yang cermat perlu dimasukkan ke dalam insentif apa yang ada dalam sistem pohon txout, dengan mempertimbangkan pembayaran biaya. Misalnya, dalam sistem seperti Ark, jika satu set V-UTXO secara individual menghabiskan terlalu banyak uang untuk layak dibawa ke V-UTXO on-chain, koordinator yang tidak kooperatif dapat menolak untuk mengizinkan V-UTXO tersebut ditebus di luar rantai, dan kemudian mendapat untung dengan mencuri nilai V-UTXO tersebut dalam satu UTXO yang dihabiskan setelah batas waktu tercapai.

Jika ini masalahnya, bisa dibilang sistem seperti itu akan gagal dalam kriteria kami untuk menjadi L2 untuk V-UTXO kecil.

Skema Berbasis Saldo

Mesin negara dari pohon txout masih relatif sederhana: baik kolam dana ada, atau sudah dihabiskan, untuk membuat dua atau lebih kolam dana yang lebih kecil. Dengan konvenan yang lebih canggih, kita sebaliknya bisa memperlakukan kolam dana sebagai saldo yang berkembang, dengan kemampuan untuk menambah dan mengurangi dana dari saldo tersebut.

Untuk melakukan ini, kita perlu menerapkan mesin keadaan non-sepele. Tetapi kita juga membutuhkan apa yang pada dasarnya adalah database bersama. Mengapa? Karena tujuannya di sini adalah untuk berbagi satu UTXO di banyak pemilik yang berbeda. Akhirnya, jika kita benar-benar ingin mendapatkan peningkatan skalabilitas, kita harus melakukannya dengan cara yang menempatkan sesedikit mungkin data kepemilikan itu secara berantai.

Persyaratan-persyaratan ini secara inheren mengarahkan kita pada jenis struktur data merkelisasi yang mirip pohon, seperti pohon jumlah merkle. Memanipulasi struktur data tersebut secara inheren akan membutuhkan sesuatu seperti OP_CAT, jenis opcode verifikasi bukti pengetahuan nol, atau jenis opcode manipulasi pohon yang spesifik tujuan.

Menariknya, seperti pada pohon txout, Anda tidak bisa melakukan yang lebih baik dari skala log(n) pesanan sambil mempertahankan properti keamanan yang serupa. Mengapa? Mari kita anggap kita memiliki OP_ZKP hipotetis yang melalui matematika canggih tertentu, hanya memerlukan 32 byte untuk membuktikan pernyataan apa pun. Meskipun bukti zk ini bisa membuktikan bahwa struktur data merkelized telah dimanipulasi sesuai dengan aturan sistem layer 2, ia akan gagal untuk memberikan data yang diperlukan bagi pengguna berikutnya untuk juga melakukan perubahan status. Ini tidak memenuhi kriteria yang diinginkan dari memungkinkan penarikan tanpa syarat: paling tidak satu pengguna mungkin bisa mencapai penarikan tanpa syarat. Tetapi tidak ada pengguna lain yang bisa melakukannya.

Sebaliknya, jika bagian yang dimodifikasi dari struktur data merklized dipublikasikan melalui skrip covenantsig - misalnya, digest saudara dalam pohon merkle - pengguna selanjutnya memiliki cukup data untuk memperbarui pemahaman mereka tentang status sistem dan melakukan penarikan tanpa syarat sendiri.

Salah satu cara potensial untuk mengatasi masalah ini adalah jika perjanjian memerlukan bukti publikasi di media publikasi yang berbeda dengan rantai Bitcoin. Namun, jaminan keamanannya akan lebih lemah daripada yang dapat dicapai melalui Bitcoin.

Akhirnya, perhatikan bagaimana pohon txout dan pendekatan berbasis keseimbangan dapat digabungkan. Jika struktur data yang dimanipulasi adalah pohon txout, dana dapat ditambahkan ke pohon txout dengan membelanjakan output dan menambahkan dana baru, dengan skrip perjanjian yang memvalidasi bahwa dana tersebut sebenarnya ditambahkan ke pohon txout. Sama halnya, dana dapat dihapus oleh semua mekanisme yang biasanya tersedia untuk pohon txout. Advanced Ark adalah contoh dari kelas skema ini.

Rasio Data Kegagalan

L2 mencapai skalabilitas dengan menambahkan persyaratan interaktivitas dalam situasi yang bermusuhan. Dalam hampir semua kasus ini berarti bahwa pihak yang jujur dalam protokol memiliki batas waktu untuk melakukan penambangan transaksi; jika batas waktu tidak terpenuhi, dana dapat dicuri.

Kapasitas blok maksimum dalam semua blockchain terdesentralisasi (dan terpusat) dibatasi oleh kendala teknis. Dalam Bitcoin, ukuran blok maksimum adalah sedemikian rupa sehingga Bitcoin beroperasi pada kapasitas ~100% sepanjang waktu. Karena penambangan Bitcoin berfungsi sebagai sistem lelang, melelang ruang blok kepada penawar tertinggi, dalam praktiknya ini berarti bahwa tingkat biaya minimum untuk memperoleh transaksi yang ditambang naik turun seiring dengan peningkatan dan penurunan permintaan.

Tarif biaya selalu menjadi faktor dalam ekonomi L2 dan mode kegagalan. Sebagai contoh, dalam Lightning, HTLC yang berukuran 'debu' yang terlalu kecil untuk ditebus dengan untung di rantai menggunakan model keamanan yang berbeda dari HTLC yang lebih besar. Meskipun protokol Lightning belum sepenuhnya menerapkan hal ini, secara teori ambang batas ini seharusnya dinamis, berdasarkan tarif biaya saat naik dan turun, idealnya sampai pada titik di mana pihak dapat memilih apakah HTLC bahkan ada dalam transaksi komitmen tertentu berdasarkan tarif biaya.

Berbagai serangan telah diajukan di mana situasi ini sengaja dipicu di Lightning, seperti banjir dan rampok²² dan serangan keluar massal²³. Karena kapasitas blockchain Bitcoin dibagi di semua kasus penggunaan, serangan antara sistem L2 yang berbeda juga dimungkinkan: misalnya memicu keluar massal di Ark untuk mendapatkan keuntungan dari saluran Lightning.

L2 yang membagi UTXO di antara beberapa pengguna secara inheren membuat masalah ini berpotensi menjadi lebih buruk, karena permintaan blok kasus terburuk selama kegagalan secara proporsional lebih tinggi. Pada saat penulisan, kami sebenarnya belum pernah melihat kegagalan skala besar pada Lightning di mana banyak saluran harus ditutup sekaligus. Ada argumen yang baik bahwa kita harus mendapatkan pengalaman operasional tambahan dengan Lightning dan skalabilitas 1-UTXO-per-pengguna sebelum mendorong batas bahkan lebih jauh dengan skema pembagian UTXO.

Kedua, sebelum skema berbagi UTXO baru secara luas diadopsi, penelitian yang cermat harus dilakukan tentang potensi profitabilitas serangan selama permintaan tinggi untuk ruang blok. Sebagai contoh, dalam sistem seperti Ark di mana ASP dapat menebus dana menggunakan ruang blok yang jauh lebih sedikit dari pihak lain, mungkin kasusnya adalah sengaja memicu tingkat biaya tinggi dan kemudian merebut dana yang tidak dapat ditarik secara menguntungkan secara sepihak adalah penipuan yang menguntungkan, melanggar kedua kondisi kami untuk sistem L2 yang sebenarnya.

Pembersihan Konsensus

Ada beberapa hal yang salah dalam protokol Bitcoin awal yang ditemukan oleh Satoshi, terutama serangan DoS scripting, serangan time-warp, dan masalah dengan pohon merkle. Sebelumnya, beberapa bug konsensus lainnya telah diperbaiki dengan soft-fork, seperti beralih ke evaluasi nLockTime berbasis waktu terhadap waktu median terakhir, (berusaha) memperbaiki masalah txid duplikat, dll.

Soft-fork terbaru, akar tunggang, memiliki proses penyebaran yang relatif kontroversial, membutuhkan waktu yang cukup lama untuk benar-benar digunakan. Argumen untuk melakukan pembersihan konsensus soft-fork terlebih dahulu, sebelum mengaktifkan opcode baru atau fitur lain untuk jenis L2 baru, adalah bahwa kita akan belajar lebih banyak tentang seberapa besar keinginan masyarakat luas untuk menerapkan apa yang seharusnya menjadi soft-fork yang relatif tidak kontroversial yang bisa dibilang menguntungkan semua orang.

Menguji L2 yang bergantung pada Soft-Fork

Pengembang tidak perlu menunggu fork lunak benar-benar terjadi untuk menguji ide-ide mereka. Salah satu pendekatan yang sangat canggih yang digunakan oleh para pengembang Ark di Ark tanpa perjanjianadalah untuk mensimulasikan perjanjian yang mereka butuhkan dengan transaksi yang telah ditandatangani sebelumnya. Ini memungkinkan mereka untuk menguji ide-ide Ark dengan BTC sungguhan, di mainnet, dengan karakteristik kepercayaan yang sama, seperti yang diharapkan Ark capai dengan perjanjian. Komprominya adalah bahwa Ark tanpa perjanjian memerlukan semua pihak untuk online untuk menandatangani transaksi yang telah ditandatangani sebelumnya. Karena clArk benar-benar bekerja dengan BTC sungguhan, mungkin membuktikan bahkan cukup berguna untuk digunakan dalam produksi untuk beberapa kasus penggunaan transfer yang dapat mentolerir kompromi interaktivitas.

Pendekatan yang lebih sederhana adalah dengan berpura-pura bahwa pihak-pihak tertentu tidak dapat melakukan tindakan yang akan dicegah oleh perjanjian. Misalnya, jika protokol yang diusulkan ingin menggunakan CTV untuk menegakkan bahwa pohon txout dihabiskan dalam pohon transaksi, setiap penggunaan CTV dapat diganti dengan NOP atau CheckSig. Meskipun pada kenyataannya pohon txout tidak benar-benar ditegakkan, setiap bit kode yang berinteraksi dengan pohon dan masing-masing pihak dapat diuji seolah-olah itu, dan karena NOP dan CheckSig diizinkan dalam skrip standar, protokol dapat diuji di mainnet dengan dana nyata.

Potensi Soft-Fork

Apa rencana ke depannya? Di sini kami akan menjabarkan semua skema L2 utama yang kami analisis, dan fork lunak mana yang berguna (U) atau diperlukan (R) untuk membuat skema L2 ini berhasil. Seperti yang dibahas di atas, OP_CAT (dan dengan perluasan, Script Revival, yang mencakup OP_CAT), dapat meniru semua fork lunak lain dalam daftar ini — kecuali OP_Expire dan Fee Sponsorship — jadi jika kebutuhan proyek dapat dipenuhi secara efisien oleh fork lunak lain secara langsung, kami tidak akan mencantumkan OP_CAT.

Kami juga akan meninggalkan semua opcode manipulasi pohon merkle yang diusulkan. Mereka semua terlalu niche, terlalu spesifik pada kasus penggunaan, untuk memiliki kesempatan signifikan untuk diadopsi saat ini. Sejauh mana opcode ini berguna, mengimplementasikan efek mereka melalui OP_CAT dan/atau Script Revival adalah jalan yang jauh lebih mungkin untuk diadopsi.

CTV jelas menjadi pemenang di sini, diikuti oleh SIGHASH_ANYPREVOUT (OP_Expire berguna untuk banyak hal dengan menjadi pengganti perbaikan siklus, tetapi tidak penting). CTV menang karena begitu banyak hal yang cocok dengan pola desain 'pastikan transaksi pengeluaran sesuai dengan template ini'; bahkan konstruksi OP_CAT dapat efisien menggunakan CTV.

Berbeda dengan OP_CAT, CTV tidak tampaknya menimbulkan banyak risiko konsekuensi tidak disengaja selain mendorong pembayaran biaya di luar jalur dalam beberapa kasus. Ini tidak ideal. Namun, tidak ada yang menemukan alternatif yang didukung secara luas.

Rekomendasi pribadi saya: lakukan soft-fork pembersihan konsensus, diikuti oleh CTV.

Disclaimer：

1. Artikel ini dicetak ulang dari [petertodd], Teruskan Judul Asli 'Apakah Peta Jalan Ethereum Sedang Tidak Tepat?', Semua hak cipta milik penulis asli [petertodd]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Gerbang Belajartim, dan mereka akan menanganinya dengan segera.

2. Penolakan Tanggung Jawab Kewajiban: Pandangan dan opini yang tertera dalam artikel ini semata-mata merupakan milik penulis dan tidak merupakan nasihat investasi apa pun.

3. Penerjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.