Showdown kontrak pintar: Hyperledger Fabric vs MultiChain vs Ethereum vs Corda

Ada lebih dari satu cara untuk meletakkan kode di blockchain

Dalam sebagian besar diskusi tentang blockchain, tidak butuh waktu lama untuk gagasan "kontrak pintar" muncul. Dalam imajinasi populer, kontrak pintar mengotomatiskan pelaksanaan interaksi antar pihak, tanpa memerlukan perantara tepercaya. Dengan mengungkapkan hubungan hukum dalam kode daripada kata-kata, mereka berjanji untuk memungkinkan transaksi terjadi secara langsung dan tanpa kesalahan, baik disengaja atau tidak.

Dari sudut pandang teknis, kontrak pintar adalah sesuatu yang lebih spesifik: kode komputer yang hidup di blockchain dan mendefinisikan aturan untuk transaksi rantai itu. Deskripsi ini terdengar cukup sederhana, tetapi di baliknya terdapat banyak variasi dalam cara aturan ini diekspresikan, dijalankan, dan divalidasi. Saat memilih platform blockchain untuk aplikasi baru, pertanyaan “Apakah platform ini mendukung kontrak pintar?” bukan orang yang tepat untuk bertanya. Sebagai gantinya, kita perlu bertanya: “Jenis kontrak pintar apa yang didukung platform ini?”

Dalam artikel ini, tujuan saya adalah untuk memeriksa beberapa perbedaan utama antara pendekatan kontrak pintar dan trade-off yang mereka wakili. Saya akan melakukan ini dengan melihat empat platform blockchain perusahaan populer yang mendukung beberapa bentuk kode on-chain yang disesuaikan. Pertama, IBM Kain Hyperledger, yang menyebut kontraknya "kode rantai". Kedua, platform MultiChain kami, yang memperkenalkan filter pintar dalam versi 2.0. Ketiga, Ethereum (dan diizinkan kuorum dan Liang spin-off), yang mempopulerkan nama "kontrak pintar". Dan akhirnya, R3 Corda, yang mereferensikan "kontrak" dalam transaksinya. Terlepas dari semua terminologi yang berbeda, pada akhirnya semua ini merujuk pada hal yang sama - kode khusus aplikasi yang mendefinisikan aturan rantai.

Sebelum melangkah lebih jauh, saya harus memperingatkan pembaca bahwa sebagian besar konten berikut bersifat teknis, dan mengasumsikan keakraban dengan pemrograman umum dan konsep database. Baik atau buruk, ini tidak dapat dihindari - tanpa membahas detailnya, tidak mungkin membuat keputusan yang tepat tentang apakah akan menggunakan blockchain untuk proyek tertentu, dan (jika demikian) jenis blockchain yang tepat untuk digunakan.

Dasar-dasar Blockchain

Mari kita mulai dengan beberapa konteks. Bayangkan sebuah aplikasi yang digunakan bersama oleh banyak organisasi, yang didasarkan pada database yang mendasarinya. Dalam arsitektur terpusat tradisional, database ini dihosting dan dikelola oleh satu pihak yang dipercaya oleh semua peserta, bahkan jika mereka tidak saling mempercayai. Transaksi yang mengubah database hanya dimulai oleh aplikasi pada sistem pihak pusat ini, seringkali sebagai tanggapan atas pesan yang diterima dari peserta. Database hanya melakukan apa yang diperintahkan karena aplikasi secara implisit dipercaya untuk hanya mengirimkan transaksi yang masuk akal.

Blockchain menyediakan cara alternatif untuk mengelola database bersama, tanpa perantara tepercaya. Dalam blockchain, setiap peserta menjalankan "node" yang menyimpan salinan database dan secara independen memproses transaksi yang memodifikasinya. Peserta diidentifikasi menggunakan kunci publik atau "alamat", yang masing-masing memiliki kunci pribadi terkait yang hanya diketahui oleh pemilik identitas. Meskipun transaksi dapat dibuat oleh node mana pun, transaksi "ditandatangani secara digital" oleh kunci pribadi pemrakarsa untuk membuktikan asalnya.

Node terhubung satu sama lain dengan cara peer-to-peer, dengan cepat menyebarkan transaksi dan "blok" di mana mereka diberi stempel waktu dan dikonfirmasi di seluruh jaringan. Blockchain itu sendiri secara harfiah merupakan rantai blok-blok ini, yang membentuk log yang dipesan dari setiap transaksi historis. Sebuah "algoritme konsensus" digunakan untuk memastikan bahwa semua node mencapai kesepakatan pada konten blockchain, tanpa memerlukan kontrol terpusat. (Perhatikan bahwa beberapa deskripsi ini tidak berlaku untuk Corda, di mana setiap node hanya memiliki sebagian salinan database dan tidak ada blockchain global. Kita akan membicarakannya lebih lanjut nanti.)

Pada prinsipnya, aplikasi database bersama apa pun dapat dirancang dengan menggunakan blockchain sebagai intinya. Tetapi melakukan hal itu menciptakan sejumlah tantangan teknis yang tidak ada dalam skenario terpusat:

• Aturan transaksi. Jika ada peserta yang dapat langsung mengubah database, bagaimana kami memastikan bahwa mereka mengikuti aturan aplikasi? Apa yang menghentikan satu pengguna dari merusak konten database dengan cara yang melayani diri sendiri?
• Determinisme. Setelah aturan ini ditentukan, aturan tersebut akan diterapkan beberapa kali oleh beberapa node saat memproses transaksi untuk salinan database mereka sendiri. Bagaimana kita memastikan bahwa setiap node mendapatkan hasil yang persis sama?
• Pencegahan konflik. Tanpa koordinasi pusat, bagaimana kita menangani dua transaksi yang masing-masing mengikuti aturan aplikasi, tetapi tetap bertentangan satu sama lain? Konflik dapat berasal dari upaya yang disengaja untuk mempermainkan sistem, atau merupakan hasil yang tidak bersalah dari nasib buruk dan waktu.

Jadi, di mana kontrak pintar, filter pintar, dan kode rantai masuk? Tujuan inti mereka adalah bekerja dengan infrastruktur dasar blockchain untuk menyelesaikan tantangan ini. Kontrak pintar adalah padanan kode aplikasi yang terdesentralisasi - alih-alih berjalan di satu tempat pusat, mereka berjalan di banyak node di blockchain, membuat atau memvalidasi transaksi yang memodifikasi konten database itu.

Mari kita mulai dengan aturan transaksi, tantangan pertama ini, dan lihat bagaimana aturan tersebut diekspresikan di Fabric, MultiChain, Ethereum, dan Corda.

Aturan transaksi

Aturan transaksi menjalankan fungsi tertentu dalam database yang didukung blockchain - membatasi transformasi yang dapat dilakukan pada status database itu. Ini diperlukan karena transaksi blockchain dapat dimulai oleh salah satu partisipannya, dan para peserta ini tidak cukup mempercayai satu sama lain untuk memungkinkan mereka memodifikasi database sesuka hati.

Mari kita lihat dua contoh mengapa aturan transaksi diperlukan. Pertama, bayangkan blockchain yang dirancang untuk mengumpulkan dan memberi label waktu pada dokumen PDF yang diterbitkan oleh pesertanya. Dalam kasus ini, tidak ada yang berhak menghapus atau mengubah dokumen, karena hal itu akan merusak keseluruhan tujuan sistem - persistensi dokumen. Kedua, pertimbangkan blockchain yang mewakili buku besar keuangan bersama, yang melacak saldo penggunanya. Kami tidak dapat mengizinkan peserta untuk secara sewenang-wenang meningkatkan saldo mereka sendiri, atau mengambil uang orang lain.

Masukan dan keluaran

Platform blockchain kami mengandalkan dua pendekatan luas untuk mengekspresikan aturan transaksi. Yang pertama, yang saya sebut "model input-output", digunakan di MultiChain dan Corda. Di sini, transaksi secara eksplisit mencantumkan baris database atau "status" yang dihapus dan dibuatnya, membentuk satu set "input" dan "output" masing-masing. Mengubah baris diekspresikan sebagai operasi yang setara dengan menghapus baris itu dan membuat baris baru sebagai gantinya.

Karena baris database hanya dihapus dalam masukan dan hanya dibuat dalam keluaran, setiap masukan harus "menghabiskan" keluaran transaksi sebelumnya. Status database saat ini didefinisikan sebagai himpunan "keluaran transaksi yang tidak terpakai" atau "UTXO", yaitu keluaran dari transaksi sebelumnya yang belum digunakan. Transaksi juga dapat berisi informasi tambahan, yang disebut "metadata", "perintah" atau "lampiran", yang tidak menjadi bagian dari database tetapi membantu untuk menentukan arti atau tujuannya.

Dengan adanya tiga set input, output, dan metadata ini, validitas transaksi di MultiChain atau Corda ditentukan oleh beberapa kode yang dapat melakukan penghitungan arbitrer pada set tersebut. Kode ini dapat memvalidasi transaksi, atau mengembalikan kesalahan dengan penjelasan yang sesuai. Anda dapat menganggap model input-output sebagai "pemeriksa" otomatis yang memiliki daftar periksa yang memastikan bahwa transaksi mengikuti setiap aturan. Jika transaksi gagal salah satu dari pemeriksaan itu, secara otomatis akan ditolak oleh semua node di jaringan.

Perlu dicatat bahwa, meskipun berbagi model input-output, MultiChain dan Corda menerapkannya dengan sangat berbeda. Di MultiChain, output dapat berisi aset dan / atau data dalam JSON, teks atau format biner. Aturan ditentukan dalam "filter transaksi" atau "filter aliran", yang dapat disetel untuk memeriksa semua transaksi, atau hanya transaksi yang melibatkan aset atau pengelompokan data tertentu. Sebaliknya, "status" keluaran Corda diwakili oleh objek dalam bahasa pemrograman Java atau Kotlin, dengan kolom data yang ditentukan. Aturan Corda didefinisikan dalam "kontrak" yang dilampirkan ke negara bagian tertentu, dan kontrak negara bagian hanya berlaku untuk transaksi yang berisi status tersebut dalam input atau outputnya. Ini terkait dengan Corda model visibilitas yang tidak biasa, di mana transaksi hanya dapat dilihat oleh pihak lawan atau pihak yang transaksi selanjutnya terpengaruh.

Kontrak dan pesan

Pendekatan kedua, yang saya sebut "model pesan-kontrak", digunakan di Hyperledger Fabric dan Ethereum. Di sini, beberapa "kontrak pintar" atau "kode rantai" dapat dibuat di blockchain, dan masing-masing memiliki basis data dan kode terkait sendiri. Basis data kontrak hanya dapat dimodifikasi dengan kodenya, bukan langsung oleh transaksi blockchain. Pola desain ini mirip dengan "enkapsulasi" kode dan data dalam pemrograman berorientasi objek.

Dengan model ini, transaksi blockchain dimulai sebagai pesan yang dikirim ke kontrak, dengan beberapa parameter atau data opsional. Kode kontrak dijalankan sebagai reaksi terhadap pesan dan parameter, dan bebas untuk membaca dan menulis database-nya sendiri sebagai bagian dari reaksi tersebut. Kontrak juga dapat mengirim pesan ke kontrak lain, tetapi tidak dapat mengakses database satu sama lain secara langsung. Dalam bahasa database relasional, kontrak bertindak sebagai ditegakkan "Prosedur tersimpan", di mana semua akses ke database melalui beberapa kode yang telah ditentukan sebelumnya.

Baik Fabric dan Quorum, variasi pada Ethereum, memperumit gambaran ini dengan mengizinkan jaringan untuk menentukan beberapa "saluran" atau "status pribadi". Tujuannya adalah untuk mengurangi masalah kerahasiaan blockchain dengan membuat lingkungan terpisah, yang masing-masing hanya dapat dilihat oleh subkelompok peserta tertentu. Meskipun secara teori ini terdengar menjanjikan, pada kenyataannya kontrak dan data di setiap saluran atau negara bagian terisolasi dari yang lain. Akibatnya, dalam hal kontrak pintar, lingkungan ini setara dengan blockchain terpisah.

Contoh aturan

Mari kita lihat bagaimana menerapkan aturan transaksi untuk buku besar keuangan aset tunggal dengan dua model ini. Setiap baris dalam database buku besar kami memiliki dua kolom, yang berisi alamat pemilik dan jumlah aset yang dimiliki. Dalam model input-output, transaksi harus memenuhi dua kondisi:

1. Jumlah total aset dalam output transaksi harus cocok dengan total inputnya. Ini mencegah pengguna membuat atau menghapus uang secara sewenang-wenang.
2. Setiap transaksi harus ditandatangani oleh pemilik setiap inputnya. Ini menghentikan pengguna untuk saling membelanjakan uang tanpa izin.

Secara bersama-sama, kedua syarat ini diperlukan untuk menciptakan sistem keuangan yang sederhana namun layak.

Dalam model kontrak-pesan, kontrak aset mendukung pesan "kirim pembayaran", yang mengambil tiga parameter: alamat pengirim, alamat penerima, dan jumlah yang akan dikirim. Sebagai tanggapan, kontrak melaksanakan empat langkah berikut:

1. Verifikasi bahwa transaksi telah ditandatangani oleh pengirim.
2. Periksa apakah pengirim memiliki dana yang cukup.
3. Kurangi jumlah yang diminta dari baris pengirim.
4. Tambahkan jumlah itu ke baris penerima.

Jika salah satu cek dalam dua langkah pertama gagal, kontrak akan dibatalkan dan tidak ada pembayaran yang akan dilakukan.

Jadi baik model input-output dan contract-message adalah cara yang efektif untuk menentukan aturan transaksi dan menjaga keamanan database bersama. Memang, pada level teoritis, masing-masing model ini dapat digunakan untuk mensimulasikan yang lain. Namun dalam praktiknya, model yang paling sesuai akan bergantung pada aplikasi yang dibangun. Apakah setiap transaksi mempengaruhi sedikit atau banyak informasi? Apakah kita harus bisa menjamin independensi transaksi? Apakah setiap bagian data memiliki pemilik yang jelas atau adakah kondisi global yang harus dibagikan?

Di luar lingkup kami di sini untuk mengeksplorasi bagaimana jawaban harus memengaruhi pilihan di antara kedua model ini. Tetapi sebagai pedoman umum, saat mengembangkan aplikasi blockchain baru, ada baiknya untuk mencoba mengekspresikan aturan transaksinya dalam kedua bentuk, dan melihat mana yang lebih cocok secara alami. Perbedaannya akan terekspresikan dalam hal: (a) kemudahan pemrograman, (b) persyaratan penyimpanan dan throughput, dan (c) kecepatan deteksi konflik. Kami akan membicarakan lebih banyak tentang masalah terakhir ini nanti.

Aturan bawaan

Dalam hal aturan transaksi, ada satu cara yang membedakan MultiChain dari Fabric, Ethereum, dan Corda. Tidak seperti platform lain ini, MultiChain memiliki beberapa abstraksi bawaan yang menyediakan beberapa blok bangunan dasar untuk aplikasi yang digerakkan oleh blockchain, tanpa Mewajibkan pengembang untuk menulis kode mereka sendiri. Abstraksi ini mencakup tiga area yang biasanya dibutuhkan: (a) izin dinamis, (b) aset yang dapat dialihkan, dan (c) penyimpanan data.

Misalnya, MultiChain mengelola izin untuk menghubungkan ke jaringan, mengirim dan menerima transaksi, membuat aset atau aliran, atau mengontrol izin pengguna lain. Beberapa aset yang dapat dipertukarkan dapat dikeluarkan, ditransfer, pensiun atau ditukar dengan aman dan atomis. Sejumlah "aliran" dapat dibuat dalam satu rantai, untuk menerbitkan, mengindeks dan mengambil data on-chain atau off-chain dalam format JSON, teks atau biner. Semua aturan transaksi untuk abstraksi ini tersedia di luar kotak.

Saat mengembangkan aplikasi di MultiChain, dimungkinkan untuk mengabaikan fungsionalitas bawaan ini, dan mengungkapkan aturan transaksi hanya menggunakan filter pintar. Namun, filter pintar dirancang untuk bekerja bersama dengan abstraksi bawaannya, dengan mengaktifkan perilaku defaultnya terbatas dengan cara yang disesuaikan. Misalnya, izin untuk aktivitas tertentu mungkin dikontrol oleh administrator tertentu, bukan perilaku default yang akan dilakukan oleh setiap administrator. Pengalihan aset tertentu dapat dibatasi oleh waktu atau memerlukan persetujuan tambahan di atas jumlah tertentu. Data dalam aliran tertentu dapat divalidasi untuk memastikan bahwa itu hanya terdiri dari struktur JSON dengan bidang dan nilai yang diperlukan.

Dalam semua kasus ini, filter pintar membuat persyaratan tambahan untuk transaksi yang akan divalidasi, tetapi tidak menghapus aturan sederhana yang ada di dalamnya. Ini dapat membantu mengatasi salah satu tantangan utama dalam aplikasi blockchain: fakta bahwa bug di beberapa kode on-chain dapat menyebabkan konsekuensi yang menghancurkan. Kami telah melihat contoh tak berujung dari masalah ini di blockchain Ethereum publik, yang paling terkenal di Matinya DAO dan Bug multisignature paritas. Survei yang lebih luas telah menemukan sejumlah besar kerentanan umum dalam kontrak pintar Ethereum yang memungkinkan penyerang mencuri atau membekukan dana orang lain.

Tentu saja, filter pintar MultiChain mungkin mengandung bug juga, tetapi konsekuensinya lebih terbatas cakupannya. Misalnya, aturan aset bawaan mencegah satu pengguna membelanjakan uang orang lain, atau secara tidak sengaja membuat uang mereka sendiri hilang, apa pun logika lain yang terkandung dalam filter pintar. Jika bug ditemukan di filter pintar, itu dapat dinonaktifkan dan diganti dengan versi yang diperbaiki, sementara integritas dasar buku besar dilindungi. Secara filosofis, MultiChain lebih mirip dengan arsitektur database tradisional, di mana platform database menyediakan sejumlah abstraksi bawaan, seperti kolom, tabel, indeks, dan batasan. Fitur yang lebih kuat seperti pemicu dan prosedur tersimpan secara opsional dapat dikodekan oleh pengembang aplikasi, dalam kasus di mana mereka benar-benar dibutuhkan.

Aturan transaksi	Kain	MultiRantai	Ethereum	Tali
Model	Kontrak – pesan	Input output	Kontrak – pesan	Input output
Bawaan	None	Izin + aset + aliran	None	None

Determinisme

Mari beralih ke bagian selanjutnya dari pertarungan kita. Apa pun pendekatan yang kami pilih, aturan transaksi khusus dari aplikasi blockchain diekspresikan sebagai kode komputer yang ditulis oleh pengembang aplikasi. Dan tidak seperti aplikasi terpusat, kode ini akan dieksekusi lebih dari satu kali dan di lebih dari satu tempat untuk setiap transaksi. Ini karena beberapa node blockchain milik peserta yang berbeda harus memverifikasi dan / atau menjalankan transaksi itu sendiri.

Eksekusi kode berulang dan berlebihan ini memperkenalkan persyaratan baru yang jarang ditemukan dalam aplikasi terpusat: determinisme. Dalam konteks komputasi, determinisme berarti sepotong kode akan selalu memberikan jawaban yang sama untuk parameter yang sama, di mana pun dan kapan pun dijalankan. Ini sangat penting untuk kode yang berinteraksi dengan blockchain karena, tanpa determinisme, konsensus antara node pada rantai itu dapat rusak secara dahsyat.

Mari kita lihat bagaimana ini terlihat dalam praktiknya, pertama dalam model input-output. Jika dua node memiliki pendapat berbeda tentang valid atau tidaknya suatu transaksi, yang satu akan menerima blok yang berisi transaksi itu dan yang lainnya tidak. Karena setiap blok secara eksplisit menautkan kembali ke blok sebelumnya, ini akan membuat "garpu" permanen di jaringan, dengan satu atau lebih node tidak menerima pendapat mayoritas tentang seluruh konten blockchain sejak saat itu. Node dalam minoritas akan terputus dari status perkembangan database, dan tidak lagi dapat menggunakan aplikasi secara efektif.

Sekarang mari kita lihat apa yang terjadi jika konsensus rusak dalam model kontrak-pesan. Jika dua node memiliki pendapat berbeda tentang bagaimana kontrak harus menanggapi pesan tertentu, ini dapat menyebabkan perbedaan dalam konten database mereka. Hal ini pada gilirannya dapat memengaruhi respons kontrak terhadap pesan di masa mendatang, termasuk pesan yang dikirim ke kontrak lain. Hasil akhirnya adalah peningkatan divergensi antara tampilan node yang berbeda dari status database. (Bidang "akar negara" di blok Ethereum memastikan bahwa setiap perbedaan dalam respons kontrak langsung mengarah ke garpu blockchain yang sangat dahsyat, alih-alih mengambil risiko tetap tersembunyi untuk jangka waktu tertentu.)

Sumber non-determinisme

Jadi non-determinisme dalam kode blockchain jelas menjadi masalah. Tetapi jika blok bangunan dasar komputasi, seperti aritmatika, bersifat deterministik, apa yang harus kita khawatirkan? Ternyata, ada beberapa hal:

• Yang paling jelas, generator bilangan acak, karena menurut definisi ini dirancang untuk menghasilkan hasil yang berbeda setiap saat.
• Memeriksa waktu saat ini, karena node tidak akan memproses transaksi pada waktu yang persis sama, dan dalam hal apa pun jamnya mungkin tidak sinkron. (Masih mungkin untuk mengimplementasikan aturan yang bergantung pada waktu dengan membuat referensi ke stempel waktu dalam blockchain itu sendiri.)
• Menanyakan sumber daya eksternal seperti Internet, file disk, atau program lain yang berjalan di komputer. Sumber daya ini tidak dapat dijamin untuk selalu memberikan respons yang sama, dan mungkin menjadi tidak tersedia.
• Menjalankan beberapa bagian kode dalam "utas" paralel, karena hal ini mengarah ke "kondisi balapan" di mana urutan penyelesaian proses ini tidak dapat diprediksi.
• Melakukan kalkulasi floating point yang dapat memberikan jawaban yang sangat berbeda pada arsitektur prosesor komputer yang berbeda.

Empat platform blockchain kami menggunakan beberapa pendekatan berbeda untuk menghindari jebakan ini.

Eksekusi deterministik

Mari kita mulai dengan Ethereum, karena pendekatannya adalah yang paling "murni". Kontrak Ethereum dinyatakan dalam format tujuan khusus yang disebut "bytecode Ethereum", yang dijalankan oleh Mesin Virtual Ethereum ("EVM"). Pemrogram tidak menulis bytecode secara langsung, melainkan menghasilkan atau "mengompilasinya" dari bahasa pemrograman mirip JavaScript yang disebut Solidity. (Bahasa lain dulu tersedia tetapi sejak itu tidak digunakan lagi.) Determinisme dijamin oleh fakta bahwa bytecode Soliditas dan Ethereum tidak dapat menyandikan operasi non-deterministik apa pun - sesederhana itu.

Filter MultiChain dan kontrak Corda memilih pendekatan yang berbeda, dengan mengadaptasi bahasa pemrograman dan lingkungan runtime yang ada. MultiChain menggunakan JavaScript yang berjalan di Google V8 engine, yang juga merupakan inti dari browser Chrome dan platform Node.js, tetapi dengan sumber non-determinisme dinonaktifkan. Demikian pula, Corda menggunakan Java atau Kotlin, keduanya dikompilasi menjadi "Java bytecode" yang dijalankan dalam Java Virtual Machine ("JVM"). Untuk saat ini, Corda menggunakan JVM non-deterministik standar Oracle, tetapi pekerjaan sedang dilakukan untuk mengintegrasikan a versi deterministik. Sementara itu, pengembang kontrak Corda harus berhati-hati untuk tidak mengizinkan non-determinisme dalam kode mereka.

Bagaimana purisme Ethereum dibandingkan dengan pendekatan evolusioner yang diambil oleh MultiChain dan Corda? Keuntungan utama Ethereum adalah minimisasi risiko - mesin virtual yang dibangun untuk tujuan kecil kemungkinannya mengandung sumber non-determinisme yang tidak disengaja. Meskipun pengawasan semacam itu dapat diperbaiki dengan pembaruan perangkat lunak, itu akan mengganggu rantai apa pun yang tidak cukup beruntung untuk menghadapinya. Masalah Ethereum, bagaimanapun, adalah bahwa Soliditas dan EVM merupakan ekosistem kecil dan baru lahir dalam konteks yang lebih luas dari bahasa pemrograman dan lingkungan runtime. Sebagai perbandingan, JavaScript dan Java adalah dua bahasa teratas di Github, berjalan di miliaran perangkat digital, dan memiliki runtime yang telah dioptimalkan selama beberapa dekade. Agaknya inilah mengapa blockchain Ethereum publik sedang mempertimbangkan transisi ke eWASM, garpu deterministik dari standar WebAssembly.

Determinisme dengan dukungan

Dalam hal determinisme, Hyperledger Fabric mengadopsi pendekatan yang sama sekali berbeda. Di Fabric, saat node "klien" ingin mengirim pesan ke beberapa kode rantai, pertama kali node tersebut mengirimkan pesan tersebut ke beberapa node "pendukung". Masing-masing node ini mengeksekusi kode rantai secara independen, membentuk opini tentang pesan tersebut efek di database chaincode itu. Pendapat ini dikirim kembali ke klien bersama dengan tanda tangan digital yang merupakan "dukungan" formal. Jika klien menerima cukup dukungan dari hasil yang diinginkan, itu membuat transaksi yang berisi dukungan tersebut, dan menyiarkannya untuk dimasukkan dalam rantai.

Untuk menjamin determinisme, setiap bagian dari kode rantai memiliki "kebijakan pengesahan" yang mendefinisikan dengan tepat tingkat persetujuan yang diperlukan untuk membuat transaksinya valid. Misalnya, kebijakan satu kode rantai mungkin menyatakan bahwa dukungan diperlukan dari setidaknya setengah dari node blockchain. Pihak lain mungkin memerlukan dukungan dari salah satu dari tiga pihak tepercaya. Apa pun itu, setiap node dapat memeriksa secara independen apakah dukungan yang diperlukan telah diterima.

Untuk memperjelas perbedaannya, determinisme di sebagian besar platform blockchain didasarkan pada pertanyaan: "Apa hasil dari menjalankan kode ini pada data ini?" - dan kami harus benar-benar yakin bahwa setiap node akan menjawab pertanyaan ini secara identik. Sebaliknya, determinisme di Fabric didasarkan pada pertanyaan yang berbeda: "Apakah cukup pendukung setuju dengan hasil menjalankan kode ini pada data ini?" Menjawab itu adalah masalah penghitungan yang agak sederhana, dan tidak ada ruang bagi non-determinisme untuk masuk.

Determinisme demi dukungan kain memiliki sejumlah konsekuensi yang menarik. Pertama, kode rantai dapat ditulis dalam banyak bahasa pemrograman yang berbeda, karena ini tidak perlu diadaptasi untuk determinisme (Go, Java dan JavaScript saat ini didukung). Kedua, chaincode dapat disembunyikan dari beberapa peserta blockchain, karena hanya perlu dijalankan oleh klien dan endorser (database itu sendiri terlihat secara global). Terakhir dan yang paling menonjol, kode rantai Fabric dapat melakukan hal-hal yang dilarang di lingkungan blockchain lain, seperti memeriksa cuaca menggunakan API web online. Dalam kasus terburuk, di mana setiap endorser mendapatkan jawaban berbeda dari API ini, klien akan gagal mendapatkan dukungan yang cukup untuk hasil tertentu, dan tidak ada transaksi yang akan terjadi. (Perlu dicatat bahwa anggota tim Fabric masih sarankan menggunakan logika deterministik di dalam kode rantai, untuk menghindari kejutan.)

Berapa harga yang harus dibayar Fabric untuk fleksibilitas ini? Jika tujuan blockchain adalah untuk menghapus perantara dari aplikasi berbasis database bersama, maka ketergantungan Fabric pada pendukung mengambil langkah besar dari tujuan itu. Untuk peserta dalam rantai, tidak cukup lagi mengikuti aturan kode rantai - mereka juga membutuhkan simpul lain tertentu untuk menyetujui bahwa mereka telah melakukannya. Lebih buruk lagi, subset pendukung yang berbahaya dapat menyetujui perubahan database yang tidak mengikuti kode rantai sama sekali. Ini memberi pendukung lebih banyak kekuatan daripada validator di blockchain biasa, yang dapat menyensor transaksi tetapi tidak dapat melanggar aturan blockchain. Pengembang aplikasi Blockchain harus memutuskan apakah pertukaran ini masuk akal dalam kasus khusus mereka.

Determinisme	Kain	MultiRantai	Ethereum	Tali
Model	Pengesahan	Waktu proses yang disesuaikan	VM yang dibuat khusus	Waktu proses yang disesuaikan
Bahasa	Buka + Java + JavaScript	JavaScript	Kepadatan	Jawa + Kotlin
Visibilitas kode	Pihak lawan + pendukung	Blockchain	Blockchain	Pihak lawan + tanggungan
Ditegakkan	Tidak	Yes	Yes	Tidak (untuk saat ini)

Pencegahan konflik

Sejauh ini, kita telah membahas bagaimana platform blockchain yang berbeda mengekspresikan aturan transaksi dalam kode, dan bagaimana mereka secara deterministik memastikan bahwa setiap node menerapkan aturan tersebut secara identik. Sekarang saatnya untuk berbicara tentang aspek ketiga dari pertarungan kita: Bagaimana setiap platform menangani kemungkinan bahwa dua transaksi, yang valid di dalam dan dari dirinya sendiri, bertentangan satu sama lain? Dalam contoh paling sederhana, bayangkan Alice memiliki $ 10 dalam buku besar keuangan dan menyiarkan dua transaksi - satu mengirim $ 8 ke Bob, dan yang lain mengirim $ 7 ke Charlie. Jelas, hanya satu dari transaksi ini yang diizinkan untuk berhasil.

Dua model

Kita bisa mulai dengan mengelompokkan pendekatan MultiChain dan Corda untuk masalah ini bersama-sama. Seperti dijelaskan sebelumnya, keduanya menggunakan model input-output untuk merepresentasikan transaksi dan aturannya, di mana setiap input transaksi menggunakan output transaksi sebelumnya. Ini mengarah pada prinsip sederhana untuk mencegah konflik: Setiap keluaran hanya dapat digunakan satu kali. Filter MultiChain dan kontrak Corda dapat mengandalkan platform masing-masing untuk menerapkan batasan ini sepenuhnya. Karena $ 10 Alice diwakili oleh hasil transaksi sebelumnya, aturan pembelanjaan tunggal ini secara otomatis menghentikan pengirimannya ke Bob dan Charlie.

Terlepas dari kesamaan ini, penting untuk menunjukkan perbedaan utama dalam cara MultiChain dan Corda mencegah konflik. Di MultiChain, setiap node melihat setiap transaksi sehingga dapat memverifikasi secara independen bahwa setiap output hanya digunakan satu kali. Setiap transaksi yang melakukan pembelanjaan ganda terhadap transaksi yang dikonfirmasi sebelumnya akan langsung dan otomatis ditolak. Sebaliknya, di Corda tidak ada blockchain global, jadi "notaris" diperlukan untuk mencegah pengeluaran ganda ini. Setiap negara keluaran Corda ditugaskan ke notaris, yang harus menandatangani transaksi apa pun yang membelanjakan keluaran itu, mengkonfirmasikannya belum pernah dibelanjakan sebelumnya. Peserta blockchain harus mempercayai notaris untuk mengikuti aturan ini dengan jujur, dan notaris jahat dapat menyebabkan malapetaka sesuka hati. Seperti halnya dukungan di Fabric, “pembelanjaan tunggal sebagai layananDesain memiliki keunggulan dalam hal kerahasiaan tetapi memperkenalkan kembali perantara, bertentangan dengan butir blockchain. (Penting untuk diklarifikasi bahwa notaris Corda dapat dijalankan oleh kelompok peserta menggunakan algoritma konsensus, sehingga integritas buku besar masih dapat dilindungi dari pelaku kejahatan individu).

Mari beralih ke Ethereum. Untuk diingat, Ethereum menggunakan kontrak dan pesan daripada input dan output. Akibatnya, konflik transaksi seperti dua pembayaran Alice tidak langsung terlihat oleh mesin blockchain. Sebaliknya, mereka dideteksi dan diblokir oleh kontrak yang memproses transaksi, setelah pesanan mereka dikonfirmasi di rantai. Saat memproses setiap pembayaran Alice, kontrak memverifikasi apakah saldonya mencukupi. Jika transaksi membayar $ 8 kepada Budi diutamakan, maka transaksi akan diproses seperti biasa, meninggalkan Alice dengan $ 2 di akunnya. Akibatnya, ketika kontrak memproses transaksi kedua yang membayar $ 7 kepada Charlie, terlihat bahwa Alice kekurangan dana yang diperlukan dan transaksi dibatalkan.

Output vs kontrak

Sejauh ini kita telah melihat dua teknik berbeda untuk mencegah transaksi yang bertentangan - keluaran pembelanjaan tunggal di MultiChain dan Corda, dan verifikasi berbasis kontrak di Ethereum. Jadi mana yang lebih baik?

Untuk membantu menjawab pertanyaan ini, mari pertimbangkan contoh akun "1-dari-2 multisignature" yang memiliki $ 100 atas nama Gavin dan Helen, dan memungkinkan salah satu dari mereka membelanjakan uang itu secara mandiri. Gavin menginstruksikan lamarannya untuk membayar $ 80 kepada Donna, dan beberapa detik kemudian, Helen ingin mengirim $ 40 kepada Edward. Karena tidak ada cukup dana untuk kedua pembayaran, transaksi ini pasti akan menimbulkan konflik. Jika kedua transaksi disiarkan, hasilnya akan ditentukan oleh mana yang pertama kali masuk ke dalam rantai. Perhatikan bahwa tidak seperti contoh Alice, konflik ini adalah kebetulan, karena tidak ada yang mencoba melanggar aturan aplikasi - mereka hanya memiliki waktu yang tidak tepat.

Dalam mempertimbangkan kemungkinan terjadinya konflik ini, pertanyaan kuncinya adalah ini: Setelah Gavin mengirimkan transaksinya, berapa lama waktu yang dibutuhkan node Helen untuk mengetahui bahwa pembayarannya mungkin gagal? Semakin pendek periode ini, semakin besar kemungkinan Helen akan dihentikan untuk mencoba pembayaran itu, menyelamatkannya dan permohonannya dari kejutan berikutnya.

Dengan model input-output, setiap konflik antara transaksi langsung terlihat oleh platform blockchain, karena dua transaksi secara eksplisit akan mencoba untuk menggunakan output sebelumnya yang sama. Di MultiChain, ini terjadi segera setelah transaksi Gavin menyebar ke node Helen, biasanya dalam satu detik atau kurang. Di Corda, notaris keluaran akan menolak permintaan untuk menandatangani transaksi Helen, karena sudah menandatangani transaksi Gavin, jadi Helen akan langsung tahu bahwa pembayarannya akan gagal. (Meskipun jika notaris Corda sendiri didistribusikan, dia mungkin harus menunggu beberapa detik untuk mendapatkan balasan.) Bagaimanapun, tidak perlu menunggu transaksi untuk dikonfirmasi dan dipesan di blockchain.

Bagaimana dengan model Ethereum? Dalam hal ini, tidak ada cara langsung bagi platform blockchain untuk mengetahui bahwa konflik akan terjadi. Walaupun node Helen dapat melihat transaksi Gavin di jaringan, node tidak dapat mengetahui bagaimana hal ini akan memengaruhi transaksi Helen sendiri, karena dari sudut pandangnya, ini hanyalah dua pesan yang dikirim ke kontrak yang sama. Mungkin sepuluh detik kemudian, setelah pemesanan terakhir dari transaksi yang bentrok dikonfirmasi di blockchain, node Helen akan menghitung ulang yang sebenarnya, bukan hasil yang diharapkan, dan aplikasinya akan memperbarui tampilannya. Sementara itu, Gavin dan Helen akan dibiarkan dalam kegelapan.

Tetapi kita tidak boleh menyimpulkan dari sini bahwa model input-output selalu bekerja paling baik. Pertimbangkan variasi pada contoh skenario kami, di mana Gavin dan Helen meminta pembayaran $ 40 yang lebih kecil dari saldo awal $ 100, pada waktu yang persis sama. Dalam model input-output, transaksi ini akan bertentangan, karena keduanya menggunakan baris database yang sama yang berisi $ 100 itu, dan hanya satu pembayaran yang akan berhasil. Tetapi di Ethereum, kedua transaksi akan berhasil diproses, terlepas dari pesanan terakhirnya, karena akun tersebut berisi dana yang cukup untuk keduanya. Dalam hal ini, Ethereum dengan lebih setia memenuhi niat Gavin dan Helen.

Perangkat baca-tulis

Terakhir, mari kita bicara tentang Fabric, yang pendekatan berbasis endorsemennya merupakan gabungan dari dua teknik ini. Seperti yang dijelaskan sebelumnya, ketika node "klien" Fabric ingin mengirim pesan ke kontrak, node tersebut meminta beberapa node pendukung untuk mengeksekusi pesan tersebut atas namanya. Node pendukung melakukannya dengan cara yang mirip dengan Ethereum - menjalankan kontrak dengan database lokalnya - tetapi proses ini diamati daripada segera diterapkan. Setiap pendukung mencatat kumpulan baris yang akan dibaca dan ditulis, juga mencatat versi persis dari baris tersebut pada saat itu. "Kumpulan baca-tulis" dari baris berversi ini secara eksplisit direferensikan dalam pengesahan, dan termasuk dalam transaksi yang disiarkan oleh klien.

Konflik di antara transaksi Fabric diselesaikan setelah pesanan mereka diselesaikan dalam rantai. Setiap node memproses setiap transaksi secara independen, memeriksa kebijakan endorsement dan menerapkan perubahan database yang ditentukan. Namun, jika transaksi membaca atau menulis versi baris database yang telah dimodifikasi oleh transaksi sebelumnya, transaksi kedua tersebut diabaikan. Untuk kembali ke pembayaran Alice yang bentrok kepada Bob dan Charlie, kedua transaksi ini akan membaca dan mengubah versi baris yang sama, berisi $ 10 yang digunakan Alice. Jadi transaksi kedua akan aman dan otomatis dibatalkan.

Pendekatan Fabric terhadap resolusi konflik berfungsi dengan baik, tetapi dalam hal kinerja dan fleksibilitas, ia menggabungkan yang terburuk dari dua model sebelumnya. Karena dukungan mengubah transaksi menjadi kumpulan baca-tulis tertentu, pembayaran $ 40 Gavin dan Helen secara simultan tetapi kompatibel akan menyebabkan konflik yang dihindari Ethereum. Namun, Fabric tidak mendapatkan keuntungan kecepatan dari model input-output, karena endorser mengeksekusi kontrak dengan versi terbaru dari database yang dikonfirmasi oleh blockchain, mengabaikan transaksi yang belum dikonfirmasi. Jadi, jika Helen memulai pembayarannya beberapa detik setelah Gavin, tetapi sebelum Gavin dikonfirmasi di blockchain, Fabric akan membuat transaksi yang bertentangan yang dihindari oleh model input-output murni.

Pencegahan konflik	Kain	MultiRantai	Ethereum	Tali
Model	Perangkat baca-tulis	Pembelanjaan tunggal	Cek kontrak	Pembelanjaan tunggal
Verifikasi	Independen	Independen	Independen	Notaris terpercaya
Kecepatan	~ 10s (konfirmasi)	~ 1s (propagasi)	~ 10s (konfirmasi)	0 ~ 5s (notaris)

Pilihan yang kompleks

Dalam bagian ini, kami meninjau banyak cara berbeda di mana Corda, Ethereum, Fabric, dan MultiChain mengatasi tantangan utama "kontrak pintar", atau kode aplikasi yang tertanam dalam blockchain. Dan setiap platform memiliki jawaban berbeda untuk tiga pertanyaan inti kami: Bagaimana aturan transaksi direpresentasikan? Bagaimana kode dieksekusi secara deterministik? Dan bagaimana kita mencegah konflik?

Jadi siapa pemenang pertarungan kontrak pintar kami? Seharusnya sekarang sudah jelas bahwa tidak ada jawaban yang sederhana. Setiap platform mewakili pertukaran multi-arah yang kompleks antara fleksibilitas, kesederhanaan, kinerja, disintermediasi, keamanan, dan kerahasiaan. Jadi, pilihan platform untuk aplikasi tertentu harus dimulai dengan pemahaman terperinci tentang model kepercayaan aplikasi itu, jenis transaksi yang dilibatkannya, dan kemungkinan pola konfliknya. Jika Anda menemukan seseorang mendorong solusi kontrak pintar tertentu sebelum mereka mengetahui jawaban atas pertanyaan-pertanyaan ini, saya sarankan dengan sopan tetapi dengan tegas bersikeras bahwa mereka mengadopsi pendekatan yang "lebih cerdas".

Silakan kirim komentar di LinkedIn.