Kandungan berikut diterbitkan semula daripada forum Nervos Talk, yang ditulis oleh Ajian (Ketua Editor platform kandungan Bitcoin BTC Study).
Memahami kebolehprograman sistem memerlukan kita mengenal pasti ciri-ciri struktur sistem. Penerokaan pengaturcaraan aplikasi berdasarkan skrip Bitcoin membantu kami memahami struktur asas CKB Cell dan paradigma pengaturcaraannya. Bukan itu sahaja, tetapi ia memecahkan elemen pengaturcaraan CKB kepada bahagian yang sesuai dan membantu kami memahami keuntungan kebolehprograman yang dibawa oleh setiap bahagian.
"Kebolehprograman" ialah dimensi yang sering diambil oleh orang ramai apabila membandingkan sistem blockchain. Walau bagaimanapun, perselisihan pendapat adalah perkara biasa tentang bagaimana kebolehprograman diterangkan. Ungkapan biasa ialah, "Blok blok XX menyokong bahasa pengaturcaraan lengkap Turing", atau, "Blok blok XX menyokong pengaturcaraan umum", yang bermaksud bahawa "blockchain XX" di sini mempunyai jantina kebolehprograman yang kuat. Terdapat beberapa kebenaran untuk implikasi pernyataan ini: sistem yang menyokong pengaturcaraan lengkap Turing biasanya lebih mudah untuk diprogramkan daripada sistem yang tidak. Walau bagaimanapun, terdapat banyak aspek kepada ciri struktur sistem kontrak pintar, dan kenyataan ini hanya menyentuh salah satu daripadanya, tidak cukup untuk mendapatkan pemahaman yang cukup mendalam: pemaju tidak boleh mendapatkan panduan daripadanya, dan pengguna biasa tidak dapat membezakannya. ia daripada itu.
Ciri-ciri struktur sistem kontrak pintar termasuk:
Jadi, sebagai tambahan kepada "sama ada pengiraan sewenang-wenangnya boleh diprogramkan", sekurang-kurangnya terdapat Terdapat empat ciri yang mempengaruhi kebolehprograman sistem kontrak pintar. Malah boleh dikatakan bahawa ciri-ciri lain ini lebih penting, kerana ia menentukan secara lebih mendalam apa yang mudah dilaksanakan dan apa yang sukar untuk dilaksanakan, apakah pelaksanaan yang lebih menjimatkan dan apakah pelaksanaan yang kurang efisien;
Sebagai contoh, orang sering mengambil Ethereum sebagai contoh kebolehprograman yang baik Walau bagaimanapun, bentuk asas ungkapan keadaan dalam Ethereum ialah akaun, dan sukar untuk memprogramkan kontrak peer-to-peer (contohnya, saluran pembayaran, satu. -kontrak pertaruhan -to-one ) ——Ia tidak mustahil, ia hanya tidak bersyukur. Bukannya ekosistem Ethereum tidak pernah mempunyai projek yang cuba melaksanakan saluran pembayaran/saluran status Terdapat juga banyak perbincangan teori, tetapi projek ini nampaknya tidak aktif hari ini - ini jelas tidak boleh dikaitkan dengan kekurangan usaha oleh pemaju. Bukan kebetulan bahawa projek yang aktif di Ethereum hari ini semuanya berbentuk "kumpulan dana" dan bukannya "kontrak point-to-point". Begitu juga, orang mungkin sangat berpuas hati dengan kebolehprograman Ethereum, tetapi apabila ia datang untuk mencapai "abstraksi akaun" (yang juga boleh difahami sebagai generalisasi konsep dompet), model akaun sememangnya kekurangan.
Begitu juga, meneroka kebolehprograman CKB juga memerlukan kita memahami ciri-ciri struktur sistem kontrak pintar CKB dalam aspek ini. Apa yang kita sedia maklum ialah CKB membenarkan pengaturcaraan pengiraan sewenang-wenangnya, membenarkan rakaman keadaan tambahan dalam kontrak, dan membenarkan satu kontrak mengakses keadaan kontrak lain semasa pelaksanaan. Walau bagaimanapun, bentuk kontraknya adalah output transaksi (dipanggil "Sel"), yang menjadikannya berbeza secara asas daripada Ethereum. Oleh itu, memahami sistem kontrak pintar Ethereum dan contoh kontrak di dalamnya tidak membantu kami memahami cara CKB melaksanakan ciri struktur ini, dan juga tidak membantu kami memahami kebolehprograman CKB.
Nasib baik, kontrak pintar pada Bitcoin nampaknya menyediakan asas terbaik untuk kita memahami kebolehprograman CKB. Ini bukan sahaja kerana bentuk asas ungkapan keadaan Bitcoin juga merupakan output transaksi (dipanggil "UTXO"), tetapi juga kerana, dengan bantuan konsep "perjanjian" yang dicadangkan oleh komuniti Bitcoin, kita dapat memahami bahawa CKB mempunyai ciri-ciri struktur di atas, dan keuntungan kebolehprograman yang dibawa dengan membahagikan kesan akhir dengan sewajarnya kepada beberapa bahagian dan mengenal pastinya satu demi satu.
Sebagai bentuk asas ungkapan keadaan Bitcoin, UTXO Bitcoin ("Output Transaksi Tidak Dibelanjakan") mempunyai dua medan:
Berbanding sistem kontrak pintar yang datang kemudian, skrip Bitcoin agak terhad:
Walaupun skrip jenis ini terhad, ia tidak kekurangan keupayaan untuk memprogramkan aplikasi yang menakjubkan, dan ia juga menjadi asas untuk kami meneroka kebolehprograman CKB. Akan ada bahagian khas kemudian untuk memperkenalkan dua contoh pengaturcaraan skrip Bitcoin.
Sebaliknya, unit keadaan CKB dipanggil "Sel" dan mempunyai empat medan:
Selain itu, Skrip Kunci dan Skrip Jenis juga boleh memprogramkan pengiraan sewenang-wenangnya. Anda boleh memprogramkan sebarang algoritma pengesahan tandatangan, anda juga boleh memprogram sebarang semakan praimej untuk sebarang algoritma cincang, dan sebagainya.
Pembaca dengan mudah boleh melihat peningkatan dalam kebolehprograman Sel berbanding UTXO:
Digabungkan dengan struktur "output transaksi" Cell sendiri, faedah yang boleh dibawa oleh kedua-dua mata ini adalah sangat, sangat besar Namun, daripada penerangan di atas sahaja, kita masih tidak tahu bagaimana Cell melaksanakan "akses masa jalan kontrak "status kontrak lain". Untuk melakukan ini, kita perlu beralih kepada konsep yang telah lama dibincangkan oleh komuniti Bitcoin: "perjanjian".
Niat asal sekatan adalah untuk mengehadkan di mana sejumlah wang boleh dibelanjakan. Mengenai Bitcoin semasa (yang masih belum menggunakan sebarang cadangan kekangan), sebaik sahaja dana dibuka, ia boleh dibelanjakan di mana-mana sahaja (boleh dibayar kepada mana-mana kunci awam skrip). Tetapi idea klausa sekatan adalah bahawa ia boleh dihadkan dalam beberapa cara untuk hanya dibelanjakan di tempat tertentu Sebagai contoh, UTXO tertentu hanya boleh dibelanjakan oleh transaksi tertentu, walaupun seseorang boleh memberikan tandatangan untuk UTXO ini, Apa yang boleh dibelanjakan juga telah ditentukan oleh perjanjian itu. Fungsi ini mungkin kelihatan agak pelik, tetapi ia boleh menghasilkan beberapa aplikasi yang menarik, yang akan diperkenalkan dalam bahagian khusus nanti. Yang penting, ia adalah kunci kepada pemahaman kami yang lebih lanjut tentang kebolehprograman CKB.
Rusty Russell dengan betul menegaskan bahawa klausa sekatan boleh difahami sebagai keupayaan "introspeksi" transaksi, iaitu, apabila UTXO A dibelanjakan oleh transaksi B, pengendali skrip boleh membaca sebahagian (atau semua) transaksi B , dan kemudian semak sama ada ia konsisten dengan parameter yang diperlukan oleh skrip. Sebagai contoh, sama ada kunci awam skrip keluaran pertama transaksi A adalah konsisten dengan kunci awam skrip UTXO A (ini ialah maksud asal klausa sekatan).
Memastikan pembaca akan menyedari bahawa jika anda mempunyai keupayaan introspeksi yang lengkap, maka input satu transaksi boleh membaca status input lain dari transaksi yang sama, yang menyedari apa yang kami katakan sebelum ini "kontrak sedang berjalan semasa runtime" Keupayaan untuk mengakses keadaan kontrak lain. Sebenarnya, CKB Cell direka dengan cara ini.
Berdasarkan ini, kita boleh membahagikan keupayaan introspeksi lengkap ini kepada empat situasi:
Ini membolehkan kita Di bawah andaian (bahagian fungsi Skrip Kunci dan Skrip Jenis), kami menganalisis peranan keupayaan introspeksi setiap bahagian dalam senario aplikasi yang berbeza, iaitu, menganalisis keuntungan kebolehprograman yang dibawa oleh setiap bahagian kepada kami.
Dalam dua bab berikut, kita akan melihat pada pengaturcaraan skrip Bitcoin semasa (cadangan klausa belum dikekang), dan kefungsian yang dijangka dilaksanakan oleh cadangan klausa terkawal, untuk memahami secara khusus bagaimana CKB Cell boleh diprogramkan untuk buat lebih baik.
Bahagian ini akan menggunakan "Saluran Lightning/Rangkaian Kilat" dan "Kontrak Log Bijak (DLC)" sebagai contoh pengaturcaraan aplikasi berdasarkan Skrip Bitcoin. Sebelum meneruskan, kita perlu memahami dua konsep.
Konsep pertama ialah opcode kawalan proses dalam skrip Bitcoin, seperti: OP_IF, OP_ELSE. Opkod ini tidak berbeza dengan IF dalam pengaturcaraan komputer Fungsinya adalah untuk melaksanakan pernyataan yang berbeza berdasarkan input yang berbeza. Dalam konteks skrip Bitcoin, ini bermakna kita boleh menyediakan berbilang laluan buka kunci untuk dana yang dipasangkan dengan ciri kunci masa, ini bermakna kita boleh menetapkan keutamaan kepada tindakan.
Ambil "Kontrak Kunci Masa Hash (HTLC)" yang terkenal sebagai contoh Skrip ini diterjemahkan ke dalam bahasa vernakular sebagai:
Atau, Bob boleh mendedahkan imej asal di sebalik nilai cincang H tertentu, dan kemudian memberikan Tandanya sendiri. untuk membelanjakan dana;
Sebagai alternatif, Alice boleh membelanjakan dana dengan tandatangannya selepas tempoh masa T.
Kesan "sama ada... atau..." ini dicapai melalui opcode kawalan proses.
Kelebihan HTLC yang paling menonjol ialah ia boleh menggabungkan berbilang operasi bersama-sama dan mencapai atomicity. Sebagai contoh, jika Alice ingin menukar BTC untuk CKB dengan Bob, Bob boleh memberikan nilai cincang dan mencipta HTLC pada Rangkaian Nervos kemudian Alice mencipta HTLC pada Bitcoin menggunakan nilai cincang yang sama; Sebagai alternatif, Bob mengambil BTC yang dibayar oleh Alice pada Bitcoin dan juga mendedahkan imej asal, membolehkan Alice mengambil CKB pada Rangkaian Nervos. Atau, jika Bob tidak mendedahkan imej asal, kedua-dua kontrak akan tamat tempoh dan kedua-dua Alice dan Bob boleh mendapatkan semula dana yang mereka laburkan.
Selepas pengaktifan garpu lembut Taproot, ciri laluan buka kunci berbilang ini telah diperkukuhkan lagi dengan pengenalan MAST (Pokok Sintaks Abstrak Merkle): kita boleh menukar laluan buka kunci menjadi laluan buka kunci pada pokok Merkle Setiap daun adalah bebas , jadi tidak perlu menggunakan opcode kawalan aliran sedemikian dan, kerana mendedahkan satu laluan tidak memerlukan pendedahan laluan lain, kami boleh menambah lebih banyak laluan tidak berkunci pada output tanpa perlu risau tentang isu Ekonomi.
Konsep kedua ialah "transaksi komitmen". Idea transaksi yang komited ialah, dalam keadaan tertentu, transaksi Bitcoin yang sah masih benar dan mengikat walaupun ia tidak disahkan oleh blockchain.
Sebagai contoh, Alice dan Bob memiliki UTXO secara bersama, dan UTXO ini memerlukan kedua-dua tandatangan mereka untuk dibelanjakan. Pada ketika ini, Alice membina urus niaga untuk membelanjakannya, memindahkan 60% daripada nilai kepada Bob dan baki nilai kepada dirinya sendiri Alice memberikan tandatangannya sendiri untuk transaksi itu dan menghantarnya kepada Bob. Kemudian, bagi Bob, tidak perlu menyiarkan urus niaga ke rangkaian Bitcoin atau mengesahkan urus niaga oleh blockchain Kesan pembayaran transaksi juga adalah nyata dan boleh dipercayai. Oleh kerana Alice tidak boleh membelanjakan UTXO ini sendiri (dan oleh itu tidak boleh membelanjakannya lagi), dan kerana tandatangan yang diberikan oleh Alice adalah sah, Bob boleh menambah tandatangannya sendiri pada bila-bila masa dan kemudian menyiarkan urus niaga itu, dengan itu menunaikan pembayaran. Dalam erti kata lain, Alice memberikan Bob "komitmen yang boleh dipercayai" melalui transaksi yang sah (bukan dalam rantaian) ini.
Urus niaga komitmen ialah konsep teras pengaturcaraan aplikasi Bitcoin. Seperti yang dinyatakan sebelum ini, kontrak Bitcoin adalah berdasarkan pengesahan, tanpa kewarganegaraan, dan tidak membenarkan akses silang walau bagaimanapun, jika kontrak tidak membawa keadaan, di manakah negeri ini disimpan dan bagaimana kontrak itu boleh dimajukan dengan selamat (keadaan berubah)? Urus niaga komitmen memberikan jawapan yang mudah: keadaan kontrak boleh dinyatakan dalam bentuk urus niaga, supaya peserta kontrak boleh menyelamatkan negeri sendiri tanpa perlu menunjukkannya pada blockchain masalah perubahan keadaan kontrak juga boleh Diubah menjadi masalah bagaimana untuk mengemas kini transaksi yang dilakukan dengan selamat di samping itu, jika kita bimbang tentang bahaya memasuki kontrak (contohnya, memasuki kontrak yang memerlukan kedua-dua pihak menandatangani sebelum berbelanja, kita akan menghadapi risiko pihak lain tidak bertindak balas dan tersekat), kemudian, Hanya menjana dan menandatangani transaksi komitmen yang menghabiskan kontrak lebih awal daripada masa menghapuskan risiko dan menghapuskan kepercayaan kepada peserta lain.
Saluran Kilat ialah kontrak satu lawan satu di mana dua pihak boleh membayar antara satu sama lain tanpa had kali tanpa sebarang pembayaran disahkan oleh blockchain. Seperti yang anda jangkakan, ia menggunakan transaksi janji.
Dalam bahagian yang menerangkan "Transaksi Komitmen", kami telah memperkenalkan saluran pembayaran. Walau bagaimanapun, kontrak ini, yang hanya menggunakan 2 daripada 2 berbilang tandatangan, hanya membolehkan pembayaran sehala. Iaitu, sama ada Alice sentiasa membayar Bob, atau Bob membayar Alice sehingga baki kontraknya habis. Jika ia adalah pembayaran dua hala, ini bermakna selepas kemas kini status tertentu, baki satu pihak mungkin menjadi kurang daripada sebelumnya, tetapi dia mempunyai transaksi terakhir yang ditandatangani oleh pihak yang satu lagi - Adakah terdapat cara untuk menghalangnya? menyiarkan transaksi komitmen lama supaya TA hanya boleh menyiarkan transaksi komitmen terkini?
Penyelesaian Lightning Channel untuk masalah ini dipanggil "LN-Penalty". Sekarang, anggapkan bahawa Alice dan Bob masing-masing mempunyai 5 BTC dalam saluran sekarang Alice ingin membayar Bob 1 BTC, jadi dia menandatangani transaksi komitmen seperti ini dan menghantarnya kepada Bob:
Masukkan #0, 10 BTC: Alie-Bob; 2 daripada 2 output berbilang tandatangan (iaitu kontrak saluran)
Output #0, 4 BTC: Alice tandatangan tunggal
Output #1, 6 BTC: Sama ada kunci awam sementara bersama Alice-Bob #1 tandatangan tunggal atau kunci masa T1, tandatangan tunggal Bob
Bob juga menandatangani transaksi komitmen (bersamaan dengan transaksi di atas) dan menghantarnya kepada Alice:
Input #0, 10 BTC: Alie-Bob 2-of-2 keluaran berbilang tandatangan (iaitu kontrak saluran)
Output #0, 6 BTC: Bob tandatangan tunggal
Output #1, 4 BTC: atau Bob -Alice kunci awam sementara bersama #1 tandatangan tunggal atau kunci masa T1, tandatangan tunggal Alice
Helah di sini terletak pada "kunci awam sementara bersama" ini, yang dijana menggunakan kunci awam pihak sendiri dan kunci awam yang disediakan oleh pihak lain parti Contohnya, kunci awam sementara bersama Alice-Bob diperoleh dengan menggunakan salah satu kunci awam Alice sendiri dan kunci awam yang disediakan oleh Bob, mendarabkan setiap satu dengan nilai cincang dan kemudian menambahkannya bersama-sama. Apabila kunci awam sedemikian dijana, tiada siapa yang mengetahui kunci peribadinya. Walau bagaimanapun, jika Bob memberitahu Alice kunci persendirian kunci awam yang diberikannya, Alice boleh mengira kunci persendirian kunci awam sementara bersama. ——Ini adalah kunci kepada cara Lightning Channel boleh "membuang asal" keadaan lama.
Lain kali kedua-dua pihak ingin mengemas kini status saluran (mulakan pembayaran), kedua-dua pihak akan menukar kunci persendirian kunci awam sementara yang diberikan kepada pihak lain pada pusingan sebelumnya. Dengan cara ini, peserta tidak lagi berani menyiarkan transaksi komitmen terakhir yang mereka terima: output transaksi komitmen ini memberikan nilai kepada diri sendiri mempunyai dua laluan, dan kunci persendirian laluan kunci awam sementara sudah diketahui oleh pihak lain; Sebaik sahaja transaksi komitmen lama disiarkan, pihak yang satu lagi boleh segera menggunakan kunci persendirian sementara bersama ini untuk mengambil semua dana dalam output ini. – Inilah maksud “LN-Penalty”.
Secara khusus, urutan interaksi ialah: pihak yang memulakan pembayaran mula-mula meminta kunci awam sementara baharu daripada pihak satu lagi, dan kemudian membina transaksi komited baharu dan menyerahkannya kepada pihak lain yang mendapat pendedahan transaksi yang komited itu dirinya kepada pihak yang satu lagi, bulatkan kunci persendirian yang diberi kunci awam sementara. Urutan interaksi ini memastikan peserta sentiasa mendapat urus niaga komitmen baharu terlebih dahulu, dan kemudian membatalkan transaksi komitmen yang mereka perolehi pada pusingan sebelumnya, jadi ia bebas amanah.
Ringkasnya, reka bentuk utama saluran kilat ialah:
Kedua-dua pihak sentiasa menggunakan transaksi komitmen untuk menyatakan status dalaman kontrak, dan menggunakan perubahan dalam jumlah untuk mewakili pembayaran
Urus niaga komitmen sentiasa menelan kos input yang sama ( kedua-dua pihak perlu berbuat demikian pada masa yang sama Menyediakan input yang ditandatangani), jadi semua transaksi komitmen bersaing antara satu sama lain, dan hanya satu yang akhirnya boleh disahkan oleh blockchain
Tandatangan kedua-dua peserta bukan transaksi komitmen yang sama ( walaupun mereka berpasangan) ; Dan urus niaga yang mereka tandatangani sentiasa lebih menguntungkan diri mereka dengan kata lain, urus niaga komited yang diterima oleh peserta sentiasa merugikan diri mereka sendiri
Keburukan ini tercermin dalam output yang memberikan nilai kepada dirinya sendiri membuka kunci laluan: satu laluan boleh dibuka kunci dengan tandatangan anda sendiri, tetapi anda perlu menunggu seketika sementara laluan yang satu lagi menggunakan kunci awam pihak satu lagi dan dilindungi hanya jika salah satu kunci peribadi sementara anda tidak terdedah
Dalam setiap pembayaran, kedua-dua pihak menukar transaksi komitmen baharu untuk kunci persendirian sementara yang digunakan oleh pihak satu lagi pada pusingan sebelumnya Oleh itu, pihak yang menyerahkan kunci persendirian sementara tidak lagi berani menyiarkan transaksi komitmen lama. , transaksi komited terakhir "dibatalkan" dan status kontrak dikemas kini (Sebenarnya, transaksi komited ini semua transaksi yang sah dan boleh disiarkan ke rantaian blok, tetapi peserta terpaksa menghukum mereka. Berani untuk menyiarkan semula)
Mana-mana pihak boleh menarik diri daripada kontrak pada bila-bila masa dengan urus niaga yang dijanjikan ditandatangani oleh pihak yang satu lagi, namun, jika kedua-dua pihak bersedia untuk bekerjasama, mereka boleh menandatangani transaksi baru supaya kedua-dua pihak boleh mendapatkan wang mereka dengan segera.
Akhir sekali, kerana HTLC juga boleh diletakkan dalam transaksi komitmen, saluran kilat juga boleh memajukan pembayaran. Dengan mengandaikan bahawa Alice boleh mencari laluan yang terdiri daripada saluran kilat yang disambungkan ke sana ke mari dan mencapai Daniel, maka pembayaran multi-hop tanpa amanah boleh dicapai tanpa membuka saluran dengan Daniel. Ini ialah Rangkaian Lightning:
Alice -- HTLC --> Bob --> Suka-- Carol
Apabila Alice mengetahui laluan sedemikian dan ingin membayar Daniel, dia meminta nilai cincang daripada Daniel, berdasarkan mana dia membina HTLC dan memberikannya kepada Bob, dan menggesa Bob Majukan mesej kepada Carol dan menyediakan HTTP yang sama, mesej itu menggesa Carol untuk memajukan mesej kepada Daniel dan menyediakan HTTP yang sama Apabila berita itu sampai kepada Daniel, dia mendedahkan imej asal kepada Carol, dengan itu memperoleh nilai HTLC dan mengemas kini status kontrak Carol melakukan perkara yang sama, mendapatkan bayaran Bob dan mengemas kini status saluran akhirnya, Bob mendedahkan imej asal dan mengemas kini; status kepada Alice. Disebabkan oleh ciri-ciri HTLC, siri pembayaran ini sama ada berjaya bersama atau gagal bersama, jadi ia tidak boleh dipercayai.
Rangkaian Lightning terdiri daripada saluran satu demi satu, dan setiap saluran (kontrak) adalah bebas antara satu sama lain. Ini bermakna Alice hanya perlu mengetahui perkara yang berlaku dalam salurannya sendiri dengan Bob, dan tidak perlu mengambil berat tentang berapa banyak interaksi yang berlaku dalam saluran orang lain, mahupun mata wang yang digunakan oleh interaksi ini, atau sama ada interaksi itu benar-benar menggunakan saluran) .
Skala Rangkaian Lightning bukan sahaja dicerminkan dalam fakta bahawa kelajuan pembayaran dalam saluran Lightning hanya dihadkan oleh pelaburan sumber perkakasan kedua-dua pihak, tetapi juga disebabkan oleh storan keadaan yang tidak berpusat, satu nod boleh memanfaatkan leverage terbesar pada kos terendah.
Kontrak Log Berhemat (DLC) menggunakan teknik kriptografi yang dipanggil "tandatangan penyesuai" untuk membenarkan skrip Bitcoin memprogramkan kontrak kewangan yang bergantung pada peristiwa luaran.
Tandatangan penyesuai membenarkan tandatangan menjadi tandatangan yang sah hanya selepas menambah kunci peribadi. Mengambil tandatangan Schnorr sebagai contoh, bentuk standard tandatangan Schnorr ialah (R, s), di mana:
R = r.G # Nilai nonce r yang digunakan dalam tandatangan didarab dengan titik penjanaan lengkung eliptik, yang juga boleh dikatakan sebagai kunci awam r
s = r + Hash(R || m || P) * p # p ialah kunci persendirian tandatangan, P ialah kunci awam
Mengesahkan tandatangan bermakna mengesahkan s.G = r.G + Hash(R || m || P) * p.G = R + Hash(R || m || P) * PK
Andaikan saya diberi sepasang data (R, s'), di mana:
R = R1 + R2 = r1.G + r2.G
s ' = r1 + Hash(R || m || P) * p
Jelas sekali, ini bukan tandatangan Schnorr yang sah. Ia tidak boleh melepasi formula pengesahan tandatangan . Walau bagaimanapun, saya boleh membuktikannya kepada pengesah, selagi TA tahu kunci peribadi R2 r2 boleh menjadikannya tandatangan yang sah:
s'.G + R2 = R1 + Hash(R || m || P) * P + R2 = R + Hash(R || m || P) * P
Tandatangan penyesuai membenarkan kesahihan tandatangan bergantung pada data rahsia dan boleh disahkan. Tetapi apa kaitannya dengan kontrak kewangan?
Andaikan Alice dan Bob ingin bertaruh pada keputusan permainan bola sepak. Alice dan Bob bertaruh 1 BTC pada Green Goblin dan Alina masing-masing. Selain itu, laman web ulasan bola sepak Carol berjanji untuk menggunakan R_c nonce untuk menerbitkan tandatangan s_c_i keputusan apabila keputusan permainan bola sepak diumumkan.
Dapat dilihat bahawa terdapat tiga kemungkinan keputusan (jadi tandatangan Carol mempunyai 3 kemungkinan):
Untuk melakukan ini, kedua-dua orang membuat transaksi komitmen untuk setiap hasil. Contohnya, transaksi komitmen yang mereka buat untuk hasil pertama kelihatan seperti ini:
Input #0, 2 BTC: Alie-Bob 2-of-2 keluaran berbilang tandatangan (iaitu kontrak pertaruhan)
Output #0, 2 BTC: Tandatangan tunggal Alice
Walau bagaimanapun, tandatangan yang dibuat oleh Alice dan Bob untuk transaksi ini bukan (R, s), tetapi tandatangan penyesuai (R, s'), iaitu tandatangan yang diberikan oleh kedua-dua pihak kepada satu sama lain tidak boleh digunakan secara langsung untuk membuka kunci kontrak ini, nilai rahsia mesti didedahkan. Nilai rahsia ini betul-betul imej asal s_c_1.G, iaitu tandatangan Carol! Oleh kerana nilai nonce tandatangan Carol telah ditentukan (ia adalah R_c), s_c_1.G boleh dibina (s_c_1.G = R_c + Hash(R_c || 'The Green Goblin menang' || PK_c) * PK_c).
Apabila keputusan diumumkan, dengan andaian Green Goblin menang, Carol akan mengeluarkan tandatangan (R_c, s_c_1 Kemudian kedua-dua Alice dan Bob boleh melengkapkan tandatangan penyesuai pihak lawan, ditambah dengan tandatangan mereka sendiri, menjadikan transaksi di atas menjadi transaksi yang sah). disiarkan ke rangkaian dan mencetuskan kesan penyelesaian. Tetapi jika Goblin Hijau tidak menang, Carol tidak akan mengeluarkan s_c_1, dan perjanjian yang komited itu tidak akan menjadi perjanjian yang sah.
Begitu juga dengan dua transaksi yang lain. Dengan cara ini, Alice dan Bob membuat pelaksanaan kontrak ini bergantung pada peristiwa luaran (secara tepatnya, bergantung pada penyiaran acara luaran mesin penegasan dalam bentuk tandatangan) tanpa mempercayai rakan niaga. Kontrak kewangan, besar dan kecil, seperti niaga hadapan dan opsyen, boleh dilaksanakan dengan cara ini.
Berbanding dengan bentuk pelaksanaan lain, ciri terbesar kontrak log berhati-hati ialah privasinya: (1) Alice dan Bob tidak perlu memberitahu Carol bahawa mereka menggunakan data Carol, yang tidak menjejaskan pelaksanaan kontrak di semua; (2) Pemerhati Rantaian (termasuk Carol) tidak boleh menentukan perkhidmatan tapak web yang mereka gunakan dengan melaksanakan transaksi melalui kontrak Alice dan Bob, atau bahkan menentukan bahawa kontrak mereka adalah kontrak pertaruhan (bukan saluran kilat).
Pemaju dalam komuniti Bitcoin telah mencadangkan pelbagai cadangan yang boleh diklasifikasikan sebagai klausa sekatan. Dari sudut pandangan semasa, cadangan yang paling terkenal ialah OP_CHECKTEMPLATEVERIFY (OP_CTV) Konsepnya agak mudah, tetapi ia mengekalkan fleksibiliti yang besar, jadi ia dialu-alukan oleh komuniti Bitcoin yang menyokong kesederhanaan. Idea OP_CTV adalah untuk melakukan nilai cincang dalam skrip untuk mengekang bahawa dana hanya boleh dibelanjakan oleh transaksi yang diwakili oleh nilai cincang ini melakukan output transaksi dan kebanyakan medan, tetapi tidak komit Input urus niaga hanya komited kepada kuantiti input.
"Congestion Control" ialah contoh yang baik yang boleh mencerminkan ciri-ciri OP_CTV. Senario aplikasi asasnya adalah untuk membantu sebilangan besar pengguna menarik diri daripada bursa (persekitaran yang memerlukan kepercayaan) ke dalam kumpulan dana memandangkan kumpulan dana ini menggunakan OP_CTV untuk merancang kaedah perbelanjaan masa hadapan, ia boleh memastikan pengguna boleh menarik diri daripada amanah ini; -percuma Kumpulan dana tidak memerlukan bantuan sesiapa dan kerana kumpulan dana ini hanya muncul sebagai UTXO, ia mengelak daripada membayar sejumlah besar yuran pengendalian apabila permintaan untuk transaksi dalam rantaian tinggi (dikurangkan daripada n output kepada 1 output; juga daripada n urus niaga Urus niaga dikurangkan kepada 1 urus niaga). Pengguna dalam kolam boleh menunggu peluang dan kemudian menarik diri dari kolam.
Andaikan Alice, Bob dan Carol masing-masing ingin mengeluarkan 5 BTC, 3 BTC dan 2 BTC daripada bursa. Kemudian pertukaran boleh membuat output dengan 3 cawangan OP_CTV dalam jumlah 10 BTC. Katakan Alice ingin mengeluarkan wang, dia boleh menggunakan cawangan 1 yang diwakili oleh nilai hash yang digunakan oleh OP_CTV cawangan ini akan membentuk dua output, satu output adalah untuk memperuntukkan 5 BTC kepada Alice; Juga gunakan OP_CTV untuk melakukan transaksi yang hanya membenarkan Bob mengeluarkan 3 BTC dan menghantar baki 2 BTC kepada Carol.
Begitu juga jika Bob atau Carol ingin mengeluarkan wang. Apabila mereka mengeluarkan wang, mereka hanya boleh menggunakan transaksi yang boleh lulus cek OP_CTV yang sepadan, iaitu, mereka hanya boleh membayar sendiri jumlah yang sepadan, dan tidak boleh mengeluarkan wang sesuka hati akan memasuki kumpulan dana yang dikunci menggunakan OP_CTV, dengan itu memastikan bahawa tidak kira apa jua susunan pengguna mengeluarkan dana mereka, pengguna yang selebihnya boleh menarik diri daripada kumpulan tanpa amanah.
Secara abstrak, peranan OP_CTV di sini adalah untuk merancang laluan untuk kontrak hingga ke akhir hayatnya, supaya kontrak kumpulan modal di sini dapat mengekalkan sifat keluar tanpa amanah tidak kira jalan mana yang diambil atau negeri mana. ia sampai.
OP_CTV jenis ini juga mempunyai penggunaan yang sangat menarik: "saluran pembayaran sehala tersembunyi". Katakan Alice membentuk kumpulan sedemikian dan menjamin bahawa dana boleh dikeluarkan tanpa amanah ke dalam output dengan skrip seperti ini:
Sama ada, Alice dan Bob membelanjakannya bersama atau, selepas beberapa lama, Alice boleh membelanjakannya bersendirian
Jika Alice melakukannya tidak mendedahkannya kepada Bob, Bob tidak akan tahu bahawa output sedemikian wujud sebaik sahaja Alice mendedahkannya kepada Bob, Bob boleh menggunakan output ini sebagai saluran pembayaran sehala yang sensitif masa dan Alice boleh menggunakan dana tersebut dengan serta-merta kepada Bob Pay tanpa perlu menunggu pengesahan pada blockchain. Bob hanya perlu membenarkan Alice mendapatkan urus niaga komitednya dalam rantaian sebelum Alice boleh membelanjakannya sendiri.
OP_VAULT ialah cadangan klausa sekatan yang dicadangkan khas untuk membina "vaults".
Kontrak bilik kebal direka bentuk untuk menjadi bentuk penjagaan diri yang lebih selamat dan lebih maju. Walaupun kontrak berbilang tandatangan semasa boleh mengelakkan satu titik kegagalan satu kunci persendirian, jika penyerang memperoleh nombor ambang kunci persendirian, pemilik dompet tidak akan dapat melakukan apa-apa. Vault berharap untuk mengenakan had perbelanjaan tunggal ke atas dana, pada masa yang sama, apabila menarik diri daripadanya menggunakan laluan biasa, operasi pengeluaran akan menguatkuasakan tempoh menunggu, operasi pengeluaran boleh diganggu oleh dompet kecemasan operasi pemulihan. Walaupun kontrak sedemikian dikompromi, pemilik dompet boleh memulakan tindakan balas (menggunakan cawangan pemulihan kecemasan).
Secara teorinya, OP_CTV juga boleh memprogramkan kontrak sedemikian, tetapi terdapat banyak kesulitan, salah satunya ialah yuran pengendalian: semasa melakukan transaksi, ia juga komited dengan yuran pengendalian yang akan dibayar untuk transaksi tersebut. Memandangkan tujuan kontrak sedemikian, masa antara menetapkan kontrak dan mengeluarkan wang mestilah sangat lama, menjadikannya hampir mustahil untuk meramalkan yuran yang sesuai. Walaupun OP_CTV tidak mengehadkan input, jadi yuran pengendalian boleh dinaikkan dengan meningkatkan input, tetapi semua input yang diberikan akan menjadi yuran pengendalian, jadi cara lain adalah CPFP, iaitu dengan membelanjakan dana yang dikeluarkan, dalam Yuran disediakan untuk transaksi baharu. Di samping itu, penggunaan OP_CTV juga bermakna bahawa kontrak selamat sedemikian tidak boleh ditarik balik secara berkelompok (dan sudah tentu tidak boleh memulihkan dalam kelompok). Cadangan
OP_VAULT cuba menyelesaikan masalah ini dengan mencadangkan opcode baharu (OP_VAULT dan OP_UNVAULT). OP_UNVAULT direka untuk pemulihan kelompok, jadi kami tidak akan menyebutnya buat masa ini. Tindakan OP_VAULT adalah seperti ini: apabila kita meletakkannya pada cawangan pepohon skrip, ia boleh digunakan untuk menjanjikan opcode yang boleh diambil tindakan (seperti OP_CTV) tanpa parameter tertentu apabila membelanjakan cawangan ini, Transaksi boleh lulus dalam parameter tertentu, tetapi cawangan lain tidak boleh diubah. Oleh itu, ia tidak perlu menetapkan yuran pengendalian, dan boleh menetapkan yuran pengendalian apabila membelanjakan cawangan ini dengan andaian bahawa cawangan ini juga mempunyai kunci masa, maka ia akan menguatkuasakan kunci masa, kerana ia hanya boleh menukar lokasi di mana ia terletak Cawangan, cawangan lain pada pokok skrip baharu (termasuk cawangan pemulihan kecemasan) tidak akan ditukar, sekali gus membolehkan kami mengganggu operasi pengeluaran tersebut.
Selain itu, terdapat dua perkara yang patut disebut: (1) Tindakan opcode OP_VAULT adalah serupa dengan cadangan sekatan yang lain: OP_TLUV dengan betul menunjukkan bahawa ini telah menimbulkan konsep "pengiraan" kepada yang tertentu takat: OP_TLUV /OP_VAULT mula-mula menjanjikan opcode untuk membenarkan pengguna menghantar parameter ke opcode melalui transaksi baharu, dengan itu mengemas kini keseluruhan daun pepohon skrip ini bukan lagi "mengesahkan data masuk berdasarkan syarat tertentu" , tetapi " menjana data baharu yang bermakna berdasarkan data masuk", walaupun pengiraan yang boleh didayakan adalah agak terhad.
Cadangan OP_VAULT yang lengkap juga menggunakan beberapa cadangan mengenai dasar mempool (seperti transaksi format v3) untuk mencapai hasil yang lebih baik. Ini mengingatkan kita bahawa "pengaturcaraan" boleh bermakna lebih daripada yang kita fikirkan. (Contoh yang serupa ialah Transaksi Terbuka dalam Rangkaian Nervos.)
Dalam dua bab di atas, kami memperkenalkan cara kami menggunakan CKB pada struktur yang lebih terhad (Bitcoin UTXO) pengaturcaraan skrip untuk aplikasi yang menarik; cuba menambah keupayaan introspeksi kepada struktur ini juga diperkenalkan.
UTXO Walaupun tiada kekurangan keupayaan untuk memprogramkan aplikasi ini, pembaca boleh mengesan kelemahan mereka dengan mudah, atau kawasan yang boleh dioptimumkan, seperti:
Malah, komuniti Bitcoin telah menghasilkan jawapan kepada soalan-soalan ini, pada asasnya berkaitan dengan cadangan Sighash (BIP-118 AnyPrevOut).
Namun, jika kami memprogramkan pada CKB, BIP-118 tersedia sekarang (tag Sighash ini boleh disimulasikan dengan keupayaan untuk introspeksi dan mengesahkan tandatangan secara khusus).
Dengan mempelajari pengaturcaraan Bitcoin, kita bukan sahaja tahu cara memprogramkan format "output transaksi" (apa yang boleh program CKB), tetapi juga bagaimana untuk menambah baik aplikasi ini (apa yang boleh kita lakukan jika kita memprogramkan aplikasi ini pada CKB Gunakan keupayaan CKB untuk memperbaikinya). Bagi pembangun CKB, pengaturcaraan berdasarkan skrip Bitcoin boleh dianggap sebagai buku teks pembelajaran atau pun jalan pintas.
Di bawah, kami menganalisis kebolehprograman setiap modul pengaturcaraan CKB satu per satu. Jangan kita mempertimbangkan kebolehan introspektif buat masa ini.
Seperti yang dinyatakan di atas, UTXO tidak boleh diprogramkan untuk pengiraan sewenang-wenangnya. Skrip Kunci boleh, yang bermaksud Skrip Kunci boleh memprogram (sebelum sekatan digunakan) semuanya berdasarkan pengaturcaraan UTXO, termasuk tetapi tidak terhad kepada saluran kilat dan DLC yang disebutkan di atas.
Selain itu, keupayaan untuk mengesahkan sebarang pengiraan ini juga membolehkan Skrip Kunci menggunakan lebih banyak kaedah pengesahan dan lebih fleksibel daripada UTXO. Sebagai contoh, kami boleh melaksanakan saluran Lightning pada CKB di mana satu pihak menggunakan tandatangan ECDSA dan pihak lain menggunakan tandatangan RSA.
Malah, ini adalah salah satu bidang terawal yang orang mula terokai di CKB: menggunakan keupayaan pengesahan identiti fleksibel ini dalam jagaan autonomi pengguna untuk mencapai apa yang dipanggil "abstraksi akaun" - kesahihan transaksi Kedua-dua kebenaran dan pemulihan kawalan adalah fleksibel dan hampir tidak terhad. Pada dasarnya, ini adalah gabungan "cawangan perbelanjaan berbilang" dan "sebarang kaedah pengesahan". Contoh pelaksanaan termasuk: Dompet JoyID, UniPass.
Selain itu, Lock Script juga boleh melaksanakan cadangan eltoo, dengan itu merealisasikan saluran kilat yang hanya perlu mengekalkan transaksi komited terkini (malah, eltoo boleh memudahkan semua kontrak point-to-point).
Seperti yang dinyatakan di atas, salah satu kegunaan utama Skrip Jenis adalah untuk memprogramkan UDT. Digabungkan dengan Skrip Kunci, ini bermakna kami boleh melaksanakan saluran Lightning yang disokong UDT (serta jenis kontrak lain).
Malah, pemisahan Skrip Kunci dan Skrip Jenis boleh dianggap sebagai peningkatan keselamatan: Skrip Kunci memfokuskan pada pelaksanaan kaedah penjagaan atau protokol kontrak, manakala Skrip Jenis memfokuskan pada definisi UDT.
Selain itu, keupayaan untuk memulakan semakan berdasarkan definisi UDT juga membolehkan UDT mengambil bahagian dalam kontrak dengan cara yang sama seperti CKB (UDT ialah warganegara kelas pertama).
Sebagai contoh: Penulis pernah mencadangkan protokol untuk melaksanakan pinjaman bercagar NFT tanpa amanah pada Bitcoin. Kunci kepada protokol ini ialah transaksi komitmen di mana nilai input adalah kurang daripada nilai output (jadi ia belum lagi menjadi transaksi yang sah, bagaimanapun, apabila input yang mencukupi boleh disediakan untuk transaksi ini, ia adalah A transaksi yang sah: Setelah pemberi pinjaman dapat membayar balik, pemberi pinjaman tidak boleh menyimpan NFT yang dicagarkan sebagai miliknya. Walau bagaimanapun, sifat tidak amanah bagi urus niaga komitmen ini adalah berdasarkan transaksi yang menyemak jumlah input dan output, jadi pemberi pinjaman hanya boleh membayar balik pinjaman dalam Bitcoin - walaupun kedua-dua pemberi pinjaman dan pemberi pinjaman bersedia menerima mata wang lain (seperti dalam RGB USDT yang dikeluarkan oleh protokol), transaksi komitmen Bitcoin tidak dapat menjamin bahawa selagi pemberi pinjaman mengembalikan jumlah USDT yang mencukupi, ia akan dapat mendapatkan semula NFTnya, kerana transaksi Bitcoin tidak mengetahui status USDT sama sekali ! (Semakan: Dalam erti kata lain, adalah mustahil untuk membina transaksi komitmen yang bersyarat pada pembayaran balik USDT.)
Jika kita boleh memulakan cek berdasarkan definisi UDT, pemberi pinjaman boleh menandatangani transaksi komitmen yang lain. , membenarkan pemberi pinjaman menggunakan USDT untuk membayar balik pembayaran. Urus niaga akan menyemak jumlah input USDT dan jumlah output USDT, memberikan pengguna pembayaran balik tanpa kepercayaan menggunakan USDT.
Semakan: Dengan mengandaikan bahawa NFT yang digunakan sebagai cagaran dan token yang digunakan untuk pembayaran balik dikeluarkan menggunakan protokol yang sama (seperti RGB), maka masalah di sini boleh diselesaikan. Kami boleh membina transaksi komitmen berdasarkan protokol RGB, jadi bahawa peralihan keadaan dan pembayaran balik NFT boleh berlaku serentak (urus niaga digunakan untuk mengikat dua peralihan keadaan dalam protokol RGB). Walau bagaimanapun, kerana transaksi RGB juga bergantung pada transaksi Bitcoin, pembinaan transaksi komitmen di sini akan menjadi agak sukar. Secara keseluruhan, sementara masalah itu boleh diselesaikan, token adalah warganegara kelas pertama.
Seterusnya kita akan pertimbangkan keupayaan introspeksi.
Skrip Kunci membaca Skrip Kunci lain
Ini bermakna kemungkinan pengaturcaraan penuh pada Bitcoin UTXO selepas sekatan yang dicadangkan dilaksanakan. Termasuk kontrak selamat yang disebutkan di atas, serta aplikasi berdasarkan OP_CTV (seperti kawalan kesesakan).
XueJie pernah menyebut contoh yang sangat menarik: anda boleh melaksanakan Sel akaun koleksi pada CKB Apabila menggunakan Sel ini sebagai input transaksi, jika Sel yang dikeluarkannya (Sel menggunakan Skrip Kunci yang sama) mempunyai Lebih Kapasiti, maka ini. input tidak perlu memberikan tandatangan dan tidak akan menjejaskan kesahihan transaksi. Sebenarnya, Sel sebegitu tidak akan dapat dicapai tanpa kebolehan untuk introspeksi. Akaun kutipan seperti ini Cell sangat sesuai sebagai kaedah pengumpulan untuk institusi kerana ia boleh mengumpulkan dana Kelemahannya ialah ia mempunyai privasi yang lemah.
Aplikasi menarik keupayaan ini ialah token ekuiti. Skrip Kunci akan memutuskan sama ada ia boleh menggunakan Kapasitinya sendiri berdasarkan bilangan Token dalam input lain, dan tempat Kapasiti boleh dibelanjakan (memerlukan keupayaan untuk mengintrospeksi Skrip Kunci).
Tidak pasti, tetapi boleh diandaikan sebagai berguna. Contohnya, Skrip Kunci yang boleh menyemak input dan output transaksi dalam Skrip Jenis kekal tidak berubah.
Kad dagangan? Mengumpul n token boleh ditukar dengan token yang lebih besar: )
Berbanding dengan sistem kontrak pintar yang boleh diprogramkan sebelumnya untuk pengiraan sewenang-wenangnya (seperti Ethereum), Nervos Network menggunakan struktur yang berbeza oleh itu , Pemahaman tentang pintar sebelumnya sistem kontrak selalunya sukar untuk membentuk asas untuk memahami Rangkaian Nervos. Artikel ini mencadangkan kaedah untuk memahami kebolehprograman Sel CKB bermula daripada pengaturcaraan aplikasi struktur yang lebih terhad daripada Sel CKB - BTC UTXO. Selain itu, dengan menggunakan konsep "introspeksi" untuk memahami keupayaan "akses silang kontrak" Cell, kita boleh membahagikan situasi di mana keupayaan introspeksi digunakan dan menentukan kegunaan khusus untuknya.
Semakan:
1 Tanpa mengira keupayaan akses silang Cell (iaitu, keupayaan introspeksi), skrip kunci boleh dianggap sebagai Skrip Bitcoin dengan keupayaan pengaturcaraan keadaan dan ekstrem Oleh itu, semua program berasaskan Bitcoin boleh diprogramkan berdasarkan ini sahaja. Aplikasi Skrip;
2 Tanpa mengira keupayaan akses silang Sel (iaitu, keupayaan introspeksi), perbezaan antara skrip kunci dan skrip jenis boleh dianggap sebagai peningkatan keselamatan: ia memisahkan definisi aset dan kaedah penyimpanan UDT; Di samping itu, taip skrip (serta Data) yang boleh mendedahkan keadaan melaksanakan kesan bahawa UDT adalah warganegara kelas pertama.
Atas ialah kandungan terperinci Bermula dari pengaturcaraan aplikasi Bitcoin, sepuluh ribu perkataan menerangkan kebolehprograman CKB secara terperinci. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
