Kita sudah mulai melihat benih-benih potensi lapisan kedua berkembang dari primitif lapisan dasar yang telah ditambahkan atau dioptimalkan dalam dekade pertama. Lightning, meskipun masih tunduk pada beberapa keterbatasan yang cukup besar, benar-benar mulai berkembang. Dan itu hanyalah versi pertama terbatas yang saat ini ditentukan dan diterapkan. Sekarang ada sidechain dari berbagai jenis yang diterapkan: Liquid, RSK, dan bahkan rantai token terikat pada Bitcoin yang dikembangkan oleh Commerceblock. Ini hanya permulaan.
Schnorr dan Taproot
Di cakrawala, kami memiliki kombinasi Schnorr dan Taproot. Di sisi Schnorr, ini jauh lebih murah untuk memverifikasi skema tanda tangan dalam batch, serta lompatan besar berikutnya dalam mengoptimalkan konstruksi skrip multi-tanda tangan di Bitcoin. Multisig dimulai sebagai hanya memasukkan semua kunci publik dan skrip untuk multisig dalam output transaksi untuk dikirim ke sana, dan harus memasukkan semua itu dalam input untuk membelanjakannya. P2SH mengoptimalkan aspek output, dengan memasukkan hash panjang konstan dari kunci publik dan skrip multisig, menghemat biaya bagi siapa saja yang mengirim ke alamat multisig dan meninggalkan peningkatan biaya hanya untuk pengirim. SegWit bisa dibilang "dioptimalkan" lebih lanjut dengan membuat pengeluaran UTXO multisig lebih murah dengan diskon saksi. Schnorr mengambil semua optimasi inkremental ini secara ekstrem. Anda menggabungkan kunci publik individual menjadi satu kunci, yang dapat berkolaborasi dengan semua orang untuk membuat satu tanda tangan, dan cukup periksa itu. Ini menciptakan penghematan biaya besar-besaran untuk semua penggunaan multisig, termasuk lapisan kedua seperti Lightning dan sidechain federasi, dan menciptakan manfaat privasi juga dengan membuat semua UTXO multisig ini tidak dapat dibedakan dari yang tanda tangan tunggal.
Sekarang itu tidak secara ajaib membuat semuanya benar-benar pribadi. (transaksi) saluran petir masih memerlukan jalur kunci terpisah untuk transaksi hukuman mereka untuk bereaksi terhadap pengajuan negara lama. Itu berarti itu harus berada di dalam skrip output yang membuat sidik jari. Taproot memecahkan ini dengan crypto-magic-nya yang memungkinkan Anda untuk mendaftarkan pohon merkle dari kondisi pengeluaran yang berbeda, yang hanya memerlukan kondisi yang digunakan dan bukti merkle ke akar merkle untuk menghabiskan, ke kunci publik Schnorr yang terlihat normal. Sekarang Anda dapat menyembunyikan jalur skrip hukuman itu dengan taproot. Anda dapat menyembunyikan jalur skrip kondisional apa pun dengan Taproot, terkubur di bawah kunci Schnorr yang terlihat normal yang memungkinkan semua peserta menyetujui sesuatu dan membuat transaksi yang terlihat normal.
SIGHASH_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (sebelumnya SIGHASH_NOINPUT) diharapkan menjadi primitif baru berikutnya yang akan datang. Ini adalah format kunci publik/sighash flag upgrade baru. Bendera Sighash menentukan bagian mana dari transaksi yang diamanahkan oleh tanda tangan. Fungsionalitas ini ada agar Anda dapat melakukan sesuatu seperti menandatangani hanya masukan dan keluaran Anda, tetapi memungkinkan orang lain menambahkan masukan dan keluaran mereka sendiri ke dalam transaksi tanpa membuatnya tidak valid. Namun saat ini, tanda tangan harus mengamanahkan UTXO yang tepat dari transaksi yang tepat. SIGHASH_ANYPREVOUT, antara lain, akan memungkinkan mengamanahkan tanda tangan hanya pada skrip UTXO, bukan UTXO tertentu yang sebenarnya. Ini memungkinkan cara baru (eltoo) untuk membangun status saluran Lightning yang tidak memerlukan kunci hukuman atau menangani status lama dengan memungkinkan pihak yang ditipu untuk menyita semua uang. Sebaliknya, status saluran saat ini hanya perlu menghabiskan ulang status saluran lama jika kalah dalam perlombaan double spend, menjamin semua orang mendapatkan saldo saluran saat ini di rantai daripada saldo usang sebelumnya. Anda dapat mencapainya dengan hanya menggunakan ulang skrip yang sama di tempat yang tepat dan menggunakan SIGHASH_ANYPREVOUT.
Ini menghilangkan banyak risiko terkait kehilangan status saluran saat ini yang mengakibatkan transaksi hukuman mengambil dana Anda karena kesalahan jujur. Ini juga memungkinkan BANYAK lagi. Sekarang kita dapat memiliki saluran Lightning dengan lebih dari 2 peserta, dan bahkan dapat menumpuk “sub-saluran” di atasnya. Juga, SIGHASH_ANYPREVOUT dan eltoo memungkinkan penciptaan Statechains, jenis konstruksi saluran federasi yang memungkinkan peserta baru masuk dan keluar sepenuhnya di luar rantai dengan asumsi kepercayaan bahwa federasi tidak akan berkolusi dengan peserta masa lalu untuk menipu siapa pun. Ini membuka banyak potensi untuk apa yang saya sebut sendiri sebagai “protokol UTXO statis multipihak.”
OP_CHECKTEMPLATEVERIFY
OP \ _CTV adalah proposal oleh Jeremy Rubin untuk mengaktifkan jenis "perjanjian" yang sangat mendasar pada Bitcoin. Perjanjian adalah batasan yang lebih rumit untuk membelanjakan koin di luar tanda tangan dari kunci tertentu. Jenis perjanjian yang akan diterapkan oleh proposal Rubin adalah "templat." Pada dasarnya, ini memungkinkan skrip UTXO untuk meminta output spesifik yang tepat untuk dibuat oleh transaksi pengeluaran. Jadi setelah UTXO dibuat menggunakan OP \ _CTV, itu ditegakkan oleh konsensus bahwa UTXO harus dihabiskan ke alamat tertentu dalam jumlah tertentu yang ditentukan dalam skrip UTXO itu. Anda bahkan dapat merangkai ini bersama-sama sehingga salah satu UTXO ini dipaksa untuk membuat beberapa lagi, yang kemudian dipaksa untuk membuat beberapa lagi, terus dan terus.
Ini memiliki aplikabilitas umum yang sangat besar di mana saja. Di lingkungan biaya tinggi, sebuah UTXO tunggal dapat dibuat oleh entitas kustodian yang 100% di bawah aturan konsensus menjamin semua dana pelanggan mereka akan berakhir di bawah kontrol pelanggan mereka, meskipun mereka tidak memiliki akses langsung ke dana tersebut pada saat itu. Ini memiliki potensi sinergi yang besar dengan saluran multi-pihak (pabrik saluran), di mana “penarikan” massal yang dilakukan seperti ini juga dapat secara simultan menciptakan dan digunakan sebagai pabrik saluran. OP_CTV dapat digunakan untuk membuat saluran pembayaran yang setidaknya bekerja secara satu arah tanpa pihak penerima harus berpartisipasi atau memiliki kunci online untuk menerima pembayaran (dan ingat Anda dapat menumpuk saluran satu sama lain). Ini bahkan dapat digunakan untuk memungkinkan sebuah saluran tunggal memproses lebih banyak HTLC pada satu waktu dengan mengikatnya bersama dengan trik yang sama dengan contoh pertama yang menggunakan penarikan kustodian. Dan mungkin bahkan menciptakan beberapa potensi untuk jenis coinjoin baru.
Menggabungkan Semua Hal
Dengan asumsi bahwa semua proposal di atas diadopsi dan dimasukkan ke dalam Bitcoin, saya benar-benar berpikir bahwa selain para pengembang yang benar-benar bekerja di garis depan hal-hal ini, orang-orang bahkan tidak memiliki petunjuk samar tentang jenis protokol dan layanan apa yang akan dibangun menggunakan elemen dasar ini. Atau hal-hal aneh di mana tidak ada garis pembatas yang jelas antara layanan atau protokol.
Mereka akan mengaktifkan saluran multi-pihak dengan jumlah peserta yang secara teoritis tidak terbatas, yang dapat menumpuk sub-saluran di atas dengan sub-grup peserta saluran dasar yang lebih kecil. Saluran dapat dibangun di atas “pabrik saluran” ini yang memungkinkan orang menerima uang tanpa memiliki kunci online untuk dompet panas. Saluran multi-pihak ini sendiri dapat ditumpuk di atas saluran federasi (rantaian keadaan) yang memungkinkan peserta masuk atau keluar tanpa aktivitas on-chain! Dan konstruksi “splicing” saluran akan memungkinkan likuiditas bergerak dengan relatif lancar antara saluran yang berbeda dengan cara yang akan memungkinkan berbagai hal yang orang bahkan belum benar-benar mulai memikirkan.
Kata terakhir saya dalam bagian ini adalah: ini hanya mempertimbangkan apa yang dapat dilakukan dengan hal-hal yang saya anggap sebagai bagian langsung dari tumpukan protokol Bitcoin itu sendiri. Anda dapat melakukan banyak hal lagi jika Anda mulai melihat layanan kustodian terpusat, dan subset properti Bitcoin mana yang dapat mereka sediakan tanpa memperhatikan hambatan regulasi atau hukum dalam melakukannya.
Ini hanya Bagian 2 dari 4, baca bagian berikutnya besok
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Dekade Berikutnya, Bagian 2: Jalan ke Depan
Kita sudah mulai melihat benih-benih potensi lapisan kedua berkembang dari primitif lapisan dasar yang telah ditambahkan atau dioptimalkan dalam dekade pertama. Lightning, meskipun masih tunduk pada beberapa keterbatasan yang cukup besar, benar-benar mulai berkembang. Dan itu hanyalah versi pertama terbatas yang saat ini ditentukan dan diterapkan. Sekarang ada sidechain dari berbagai jenis yang diterapkan: Liquid, RSK, dan bahkan rantai token terikat pada Bitcoin yang dikembangkan oleh Commerceblock. Ini hanya permulaan.
Schnorr dan Taproot
Di cakrawala, kami memiliki kombinasi Schnorr dan Taproot. Di sisi Schnorr, ini jauh lebih murah untuk memverifikasi skema tanda tangan dalam batch, serta lompatan besar berikutnya dalam mengoptimalkan konstruksi skrip multi-tanda tangan di Bitcoin. Multisig dimulai sebagai hanya memasukkan semua kunci publik dan skrip untuk multisig dalam output transaksi untuk dikirim ke sana, dan harus memasukkan semua itu dalam input untuk membelanjakannya. P2SH mengoptimalkan aspek output, dengan memasukkan hash panjang konstan dari kunci publik dan skrip multisig, menghemat biaya bagi siapa saja yang mengirim ke alamat multisig dan meninggalkan peningkatan biaya hanya untuk pengirim. SegWit bisa dibilang "dioptimalkan" lebih lanjut dengan membuat pengeluaran UTXO multisig lebih murah dengan diskon saksi. Schnorr mengambil semua optimasi inkremental ini secara ekstrem. Anda menggabungkan kunci publik individual menjadi satu kunci, yang dapat berkolaborasi dengan semua orang untuk membuat satu tanda tangan, dan cukup periksa itu. Ini menciptakan penghematan biaya besar-besaran untuk semua penggunaan multisig, termasuk lapisan kedua seperti Lightning dan sidechain federasi, dan menciptakan manfaat privasi juga dengan membuat semua UTXO multisig ini tidak dapat dibedakan dari yang tanda tangan tunggal.
Sekarang itu tidak secara ajaib membuat semuanya benar-benar pribadi. (transaksi) saluran petir masih memerlukan jalur kunci terpisah untuk transaksi hukuman mereka untuk bereaksi terhadap pengajuan negara lama. Itu berarti itu harus berada di dalam skrip output yang membuat sidik jari. Taproot memecahkan ini dengan crypto-magic-nya yang memungkinkan Anda untuk mendaftarkan pohon merkle dari kondisi pengeluaran yang berbeda, yang hanya memerlukan kondisi yang digunakan dan bukti merkle ke akar merkle untuk menghabiskan, ke kunci publik Schnorr yang terlihat normal. Sekarang Anda dapat menyembunyikan jalur skrip hukuman itu dengan taproot. Anda dapat menyembunyikan jalur skrip kondisional apa pun dengan Taproot, terkubur di bawah kunci Schnorr yang terlihat normal yang memungkinkan semua peserta menyetujui sesuatu dan membuat transaksi yang terlihat normal.
SIGHASH_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (sebelumnya SIGHASH_NOINPUT) diharapkan menjadi primitif baru berikutnya yang akan datang. Ini adalah format kunci publik/sighash flag upgrade baru. Bendera Sighash menentukan bagian mana dari transaksi yang diamanahkan oleh tanda tangan. Fungsionalitas ini ada agar Anda dapat melakukan sesuatu seperti menandatangani hanya masukan dan keluaran Anda, tetapi memungkinkan orang lain menambahkan masukan dan keluaran mereka sendiri ke dalam transaksi tanpa membuatnya tidak valid. Namun saat ini, tanda tangan harus mengamanahkan UTXO yang tepat dari transaksi yang tepat. SIGHASH_ANYPREVOUT, antara lain, akan memungkinkan mengamanahkan tanda tangan hanya pada skrip UTXO, bukan UTXO tertentu yang sebenarnya. Ini memungkinkan cara baru (eltoo) untuk membangun status saluran Lightning yang tidak memerlukan kunci hukuman atau menangani status lama dengan memungkinkan pihak yang ditipu untuk menyita semua uang. Sebaliknya, status saluran saat ini hanya perlu menghabiskan ulang status saluran lama jika kalah dalam perlombaan double spend, menjamin semua orang mendapatkan saldo saluran saat ini di rantai daripada saldo usang sebelumnya. Anda dapat mencapainya dengan hanya menggunakan ulang skrip yang sama di tempat yang tepat dan menggunakan SIGHASH_ANYPREVOUT.
Ini menghilangkan banyak risiko terkait kehilangan status saluran saat ini yang mengakibatkan transaksi hukuman mengambil dana Anda karena kesalahan jujur. Ini juga memungkinkan BANYAK lagi. Sekarang kita dapat memiliki saluran Lightning dengan lebih dari 2 peserta, dan bahkan dapat menumpuk “sub-saluran” di atasnya. Juga, SIGHASH_ANYPREVOUT dan eltoo memungkinkan penciptaan Statechains, jenis konstruksi saluran federasi yang memungkinkan peserta baru masuk dan keluar sepenuhnya di luar rantai dengan asumsi kepercayaan bahwa federasi tidak akan berkolusi dengan peserta masa lalu untuk menipu siapa pun. Ini membuka banyak potensi untuk apa yang saya sebut sendiri sebagai “protokol UTXO statis multipihak.”
OP_CHECKTEMPLATEVERIFY
OP \ _CTV adalah proposal oleh Jeremy Rubin untuk mengaktifkan jenis "perjanjian" yang sangat mendasar pada Bitcoin. Perjanjian adalah batasan yang lebih rumit untuk membelanjakan koin di luar tanda tangan dari kunci tertentu. Jenis perjanjian yang akan diterapkan oleh proposal Rubin adalah "templat." Pada dasarnya, ini memungkinkan skrip UTXO untuk meminta output spesifik yang tepat untuk dibuat oleh transaksi pengeluaran. Jadi setelah UTXO dibuat menggunakan OP \ _CTV, itu ditegakkan oleh konsensus bahwa UTXO harus dihabiskan ke alamat tertentu dalam jumlah tertentu yang ditentukan dalam skrip UTXO itu. Anda bahkan dapat merangkai ini bersama-sama sehingga salah satu UTXO ini dipaksa untuk membuat beberapa lagi, yang kemudian dipaksa untuk membuat beberapa lagi, terus dan terus.
Ini memiliki aplikabilitas umum yang sangat besar di mana saja. Di lingkungan biaya tinggi, sebuah UTXO tunggal dapat dibuat oleh entitas kustodian yang 100% di bawah aturan konsensus menjamin semua dana pelanggan mereka akan berakhir di bawah kontrol pelanggan mereka, meskipun mereka tidak memiliki akses langsung ke dana tersebut pada saat itu. Ini memiliki potensi sinergi yang besar dengan saluran multi-pihak (pabrik saluran), di mana “penarikan” massal yang dilakukan seperti ini juga dapat secara simultan menciptakan dan digunakan sebagai pabrik saluran. OP_CTV dapat digunakan untuk membuat saluran pembayaran yang setidaknya bekerja secara satu arah tanpa pihak penerima harus berpartisipasi atau memiliki kunci online untuk menerima pembayaran (dan ingat Anda dapat menumpuk saluran satu sama lain). Ini bahkan dapat digunakan untuk memungkinkan sebuah saluran tunggal memproses lebih banyak HTLC pada satu waktu dengan mengikatnya bersama dengan trik yang sama dengan contoh pertama yang menggunakan penarikan kustodian. Dan mungkin bahkan menciptakan beberapa potensi untuk jenis coinjoin baru.
Menggabungkan Semua Hal
Dengan asumsi bahwa semua proposal di atas diadopsi dan dimasukkan ke dalam Bitcoin, saya benar-benar berpikir bahwa selain para pengembang yang benar-benar bekerja di garis depan hal-hal ini, orang-orang bahkan tidak memiliki petunjuk samar tentang jenis protokol dan layanan apa yang akan dibangun menggunakan elemen dasar ini. Atau hal-hal aneh di mana tidak ada garis pembatas yang jelas antara layanan atau protokol.
Mereka akan mengaktifkan saluran multi-pihak dengan jumlah peserta yang secara teoritis tidak terbatas, yang dapat menumpuk sub-saluran di atas dengan sub-grup peserta saluran dasar yang lebih kecil. Saluran dapat dibangun di atas “pabrik saluran” ini yang memungkinkan orang menerima uang tanpa memiliki kunci online untuk dompet panas. Saluran multi-pihak ini sendiri dapat ditumpuk di atas saluran federasi (rantaian keadaan) yang memungkinkan peserta masuk atau keluar tanpa aktivitas on-chain! Dan konstruksi “splicing” saluran akan memungkinkan likuiditas bergerak dengan relatif lancar antara saluran yang berbeda dengan cara yang akan memungkinkan berbagai hal yang orang bahkan belum benar-benar mulai memikirkan.
Kata terakhir saya dalam bagian ini adalah: ini hanya mempertimbangkan apa yang dapat dilakukan dengan hal-hal yang saya anggap sebagai bagian langsung dari tumpukan protokol Bitcoin itu sendiri. Anda dapat melakukan banyak hal lagi jika Anda mulai melihat layanan kustodian terpusat, dan subset properti Bitcoin mana yang dapat mereka sediakan tanpa memperhatikan hambatan regulasi atau hukum dalam melakukannya.
Ini hanya Bagian 2 dari 4, baca bagian berikutnya besok