Konsensus Tanpa Identitas Dan Relevansinya Dalam Blockchain
Sekarang kita akan membahas tentang konsensus tanpa identitas dalam rantai blok (Blockchain). Di bagian pembahasan kali ini, kita akan melihat detail teknis algoritma konsensus Bitcoin. Perlu diingat kembali bahwa node Bitcoin tidak memiliki identitas secara jangka panjang. Dan akan tetap seperti itu.
Salah satu alasannya kurangnya identitas ini adalah karena sistem Bitcoin menggunakan jaringan peer-to-peer. Sehingga tidak ada otoritas pusat untuk menetapkan identitas penggunanya. Tidak ada pula otoritas pusat untuk seluruh node di dalam jaringan Bitcoin.
Kondisi semacam ini diibaratkan punya potensi terjadi Sybil attack. Sybil Attack ini bertindak seperti halnya sebuah salinan node. Namun node itu adalah yang berpotensi merusak, dan nampak seolah ada banyak node yang berbeda. Padahal sebenarnya semua node dengan “pseudo” tersebut dikendalikan oleh orang yang sama. Sementara disisi lain pembentukan nama samaran sebagai identitas ini sebenarnya juga menjadi tujuan utama Bitcoin.
Meski memungkinkan untuk memberikan identitas untuk node tapi tetap tidak akan digunakan oleh Bitcoin. Bitcoin memang tidak menjamin anonimitas secara penuh. Terutama dalam kaitannya dengan transaksi yang dilakukan di dalamnya. Ada properti yang tidak bisa memaksa pengguna untuk mengungkapkan identitas asli mereka. Seperti nama identitas ataupun alamat IP terhubung di sistem Bitcoin. Hal itu menjadi sifat penting dari desain sistem Bitcoin.
Mari kita lanjutkan. Asumsinya jika node sudah memiliki sebuah identitas maka desain sistem bitcoin bisa lebih mudah. Pertama identitas tersebut memungkinkan untuk dimasukkan ke dalam protokol. Identitas pengguna semisal ID numerik harus melewati beberapa langkah. Namun jika node itu tanpa identitas, maka perlu ada set instruksi khusus yang dapat membatasi hal itu. Yang jelas memang node harus memiliki identitas. Pertanyaannya, identitas seperti apa yang digunakan node di dalam bitcoin? Anda akan mengetahui sendiri nantinya.
Setelah identitas node tersebut dapat diidentifikasi, maka mudah juga membuat identitas baru di Bitcoin. Anggap saja kita berasumsi bahwa akan ada sejumlah node yang berpotensi berbahaya. Node memang bisa membuat identitas baru lagi. Oleh karena itulah potensi Sybil Attack bisa saja terjadi. Node yang tidak memiliki identitas ini akan menjadi hambatan protokol konsensus Bitcoin.
Agar dapat mengimbangi hal itu, bisa diatasi dengan sebuah asumsi sederhana. Misalkan saja bagaimana jika memilih node secara acak di dalam sistem? Kita dapat mengambil contoh pada sebuah lotere atau undian. Sayangnya cara itu menjadi sulit untuk melacak, memberikan identitas, dan memverifikasi identitasnya.
Ada sebuah alternatif lain yang bisa dilakukan. Caranya adalah memberikan mereka semacam token atau tiket. Kemudian token atau tiket tersebut bisa dipilih ID secara acak. Hingga selanjutnya memanggil pemilik ID tersebut.
Konsensus Secara Implisit
Asumsi ini didasarkan pada sejumlah node secara acak dan disebut dengan konsensus implisit. Ada beberapa putaran dalam protokol. Masing-masingnya berbeda dalam rantai blok. Di setiap putaran, node secara acak dapat dipilih. Selanjutnya simpul node ini dapat mengusulkan blok berikutnya kedalam rantai block (blockchain).
Namun kekurangannya adalah karena tidak ada algoritma tertentu agar node bisa memilih blok baru. Padahal simpul node yang dipilih secara sepihak itu, dapat mengusulkan blok apa yang akan dimasukkan dalam rantai blok berikutnya. Bagaimana jika node yang dipilih tersebut adalah node yang berpotensi berbahaya atau malicious?
Konsensus implisit inilah yang akan menangani hal tersebut. Perlu diingat bahwa setiap blok mempunyai nilai hash dari setiap blok yang telah dimasukkan. Mekanisme teknis ini bertujuan agar node tersebut bisa mengirimkan signal bahwa sebuah blok telah dimasukkan kedalam rantai blok.
Algoritma konsensus Bitcoin Secara Sederhana
Secara sederhana, algoritma akan nampak seperti dibawah. Untuk bisa mengasumsikan kemampuan dalam memilih node secara acak, dan tahan terhadap serangan Sybil.
- Transaksi baru disiarkan ke seluruh node
- Setiap node mengumpulkan transaksi baru ke dalam blok
- Dalam setiap putaran, node secara acak akan mendapat siaran blok nya
- Node lain menerima blok – hanya jika semua transaksi di dalamnya adalah valid (terpakai, dan telah ditandatangani)
- Nodes mengungkapkan penerimaan blok dengan memasukkan hash di blok berikutnya.
Mengatasi Potensi Pencurian Bitcoin
Bagaimana algoritma ini akan bisa bekerja? Untuk bisa melihatnya, kita ambil sebuah contoh. Misalkan ada seorang penyerang bernama Nita yang ingin menggagalkan proses algoritma ini. Bisakah Nita untuk mencuri Bitcoin dari pengguna lain? Jawabannya adalah tidak bisa. Meskipun Nita bisa mengusulkan blok berikutnya, namun Nita tidak bisa mencuri Bitcoin dari pengguna lainnya. Karena Nita harus membuat sebuah transaksi yang benar-benar valid atas Bitcoin tersebut.
Selain itu, Nita juga harus menempa atau memalsukan tanda tangan pemilik Bitcoin tersebut. Sedangkan hal itu tidak bisa dilakukan Nita. Jadi selama kriptografi yang melandasi sistem ini cukup solid, maka Nita tidak bisa mencuri Bitcoin dari pengguna yang lain.
Mengatasi Potensi Denial of Service Attack
Sekarang kita coba apakah algoritma tersebut bisa bekerja jika ada bentuk serangan lain. Sebagai contoh, misalkan Nita tidak suka dengan pengguna lain bernama Rudi. Kemudian Nita memutuskan tidak mencantumkan transaksi dari alamat Bitcoin Rudi. Maka disetiap blok yang diusulkan Nita, transaksi Rudi harus tidak dicantumkan juga. Contoh kondisi ini berarti Nita sedang berupaya melakukan Denial of Service Attack terhadap Rudi.
Saat Nita menyerang Rudi, yang dilakukan Nita tidak lain adalah upaya untuk menyusun ulang transaksi kembali. Hal semacam ini tidak lebih dari sebuah gangguan kecil saja. Mengapa demikian? Jika transaksi Rudi tidak dimasukkan ke blok Nita berikutnya, maka Nita hanya akan terus menunggu sampai mendapat kesempatan blok tersebut dimasukkan ke dalam rantai blok. Sehingga serangan Nita terhadap Rudi itu baru bisa dikatakan sebagai serangan yang bagus. Kenyataanya Nita pasti cukup kesulitan untuk bisa memasukkan blok usulannya tersebut ke dalam blockchain.
Agar lebih detail mengapa serangan Nita terhadap Rudi ini menjadi tidak akan berfungsi, bisa di review kembali bahasan-bahasan sebelumnya di topik: konsep dasar Bitcoin.
Mengatasi Potensi Double‐spend attack
Anggap saja Nita mencoba melakukan serangan lain karena serangan sebelumnya telah gagal. Kali ini mungkin Nita akan mencoba dengan serangan transaksi ganda (double-spend attack). Kita asumsikan contoh kali ini Nita adalah seorang pelanggan sebuah layanan online milik Rudi.
Rudi menyediakan layanan online berupa pertukaran file. Jasa layanan online Rudi tersebut bisa dibayar dengan Bitcoin. Jika pembayaran sudah dilakukan, pelanggan baru bisa mengunduh aplikasi atau file tersebut.
Double-spend attack baru dapat dilakukan jika dalam kondisi seperti berikut ini:
Nita menambahkan beberapa item di keranjang belanjanya pada website Rudi. Selanjutnya server website Rudi itu akan meminta pembayaran transaksi Nita. Setelah Nita membayar dengan Bitcoin, transaksi itu disiarkan kedalam jaringan Bitcoin. Node yang jujur dalam jaringan Bitcoin selanjutnya akan membuat blok berikutnya. Termasuk juga transaksi-transaksi yang ada dalam blok tersebut. Salah satunya adalah transaksi pembayaran Nita kepada Rudi tadi.
Yang perlu diingat adalah bahwa transaksi itu sudah ada dilakukan Nita. Dalam transaksi Nita tersebut berisi instruksi untuk membayar sejumlah bitcoin pada public key milik Rudi beserta hash transaksinya. Hash transaksi ini merepresentasikan output pointer hash transaksi Nita sebelumnya. Yaitu transaksi Nita saat memperoleh sejumlah Bitcoin yang sedang digunakan untuk melakukan pembayaran. Pointer hash itu harus bisa menunjuk referensi transaksi sebelumnya.
Perlu dijadikan catatan juga agar tidak menjadi bingung. Bahwa disini ada dua tipe pointer hash, Blok mencakup pointer hash pada blok sebelumnya. Sedangkan transaksi mencakup satu atau lebih pointer hash pada output transaksi sebelumnya.
Sekarang mari kita lanjutkan bagaimana Nita bisa melakukan Double-Spend Attack. Sebuah blok baru yang telah dibuat node yang jujur akan memasukkan juga transaksi Nita kepada Rudi tadi. Rudi pun menyimpulkan bahwa Nita telah membayar transaksi tersebut. Nita juga telah bisa mengunduh aplikasi di situs Rudi itu.
Kita anggap saja bahwa Nita merupakan salah satu simpul node yang bisa mengusulkan block berikutnya. Maka Nita bisa mengusulkan blok selanjutnya dengan mengabaikan blok yang telah berisi transaksinya kepada Rudi. Artinya pada block baru yang diusulkan Nita adalah tidak berisi pointer hash ke blok sebelumnya. Setelah itu Nita memasukkkan kembali transaksi yang aslinya telah dikirimkan ke Rudi, namun untuk alamat yang berbeda.
Contoh inilah yang disebut dengan double spend. Nita dalam hal ini telah menggunakan sejumlah koin yang sama pada dua transaksi yang berbeda. Sedangkan hanya akan ada satu transaksi valid saja yang bisa dimasukkan ke dalam blockchain. Jika Nita berhasil memasukkan transaksi pembayaran ke alamatnya sendiri di dalam rantai blok, maka transaksinya kepada Rudi menjadi tidak berlaku karena tidak dimasukkan ke dalam rantai blok.
Lantas bagaimana cara mengetahui apakah upaya Nita ini berhasil atau tidaknya? Pada upaya Nita tadi, artinya telah ada dua cabang block yang berbeda. Sehingga akan bergantung pada blok paling akhir di masing-masing cabang block. Satu blok yang berisi transaksi Nita kepada Rudi. Atau blok satunya lagi yang berisi transaksi Nita kepada Nita sendiri.
Lalu apa yang menentukan blok manakah yang akan dimasukkan kedalam Blockchain? Node yang jujur akan mengikuti prosedur perpanjangan blockchain secara valid. Sehingga bisa menentukan cabang blok manakah yang akan diikutkan dalam blockchain dan dianggap sebagai blok yang valid. Pada poin ini, sebenarnya dua blok yang berbeda tersebut sama-sama memiliki panjang yang sama. Hanya saja, antara keduanya memiliki perbedaan di blok terakhir. Node yang jujur akan dapat memutuskan pilihan blok manakah yang akan dimasukkan. Dan pilihan inilah yang menentukan apakah upaya Nita disini berhasil atau gagal.
Node pada akhirnya akan bisa melihat perbedaan jelas antara kedua blok tersebut. Satu blok berisi transaksi valid Nita kepada Rudi. Sementara blok lainnya berisi transaksi Nita kepada Nita sendiri. Sementara jika kita melihat dari sisi teknis, kedua blok itu akan terlihat cukup identik. Sehingga cukup sulit untuk bisa mengetahui transaksi manakah yang benar-benar valid.
Dalam prakteknya, node lebih cenderung untuk mengikuti perpanjangan blok itu dari urutan blok yang pertama dalam jaringan peer-to-peer secara heuristik. Meski hal itu tidaklah menjadi aturan yang pasti. Sementara dalam kondisi apapun, karena adanya kondisi laten dalam jaringan, menjadi mudah bahwa sebuah blok yang didengar node pertama adalah blok yang diciptakan kedua. Jadi memang ada sebuah kesempatan bahwa node berikutnya akan mengusulkan blok yang bisa jadi berisi transaksi ganda.
Atas dasar ini Nita lebih jauh berusaha meningkatkan peluang dengan menyuap node berikutnya untuk bisa memasukkan usulan blok Nita. Jika node berikutnya tidak membangun blok berikutnya yang berisi transaksi ganda, maka rantai blok ini tidak akan melebihi panjang dari blok yang berisi transaksi Nita kepada Rudi. Pada titik ini, node berikutnya jauh lebih besar kemungkinannya untuk meneruskan blok yang lebih panjang. Dan akhirnya akan mengabaikan blok yang berisi transaksi ganda itu. Jelas, karena blok yang berisi transaksi valid Nita kepada Rudi telah menjadi lebih blok berukuran lebih panjang setelah dibangun pada node sebelumnya bukan?
Namun jika Nita berupaya untuk terus melanjutkan upayanya, maka akan menjadi bagian dari rantai konsensus yang panjang. Sementara di sisi lain, blok yang berisi transaksi valid Nita kepada Rudi akan benar-benar diabaikan didalam jaringan Bitcoin. Blok yang seperti ini disebut dengan Orphan Block (blok yatim).
Sekarang mari kita melihat dari sudut pandang Rudi sebagai merchant dalam contoh ini. Bagaimana Rudi bisa melindungi dirinya sendiri atas upaya serangan transaksi ganda ini? Karena dari sisi inilah kita akan mengetahui bagaimana Rudi bisa melindungi dirinya. Dan dari sisi inilah yang juga menjadi bagian penting keamanan dalam sistem Bitcoin atas upaya double-spending ini.
Ketika Nita menyiarkan transaksi pembayarannya kepada Rudi, maka Rudi dapat mendengarkan hal tersebut didalam jaringan Bitcoin. Dan Rudi juga mendengarkan transaksi lanjutan dari blok selanjutnya. Namun jika Rudi ternyata lebih bodoh, maka Rudi bisa menyelesaikan proses transaksi itu, dan memperbolehkan Nita untuk mengunduh aplikasi tersebut pada saat itu juga. Inilah yang disebut dengan transaksi zero-confirmation. Transaksi inilah yang lebih banyak memungkinkan terjadinya double-spend attack.
Ketika terjadi serangan double-spend, kita mengasumsikan bahwa ada seseorang yang berusaha mengontrol node untuk mengusulkannya kepada blok selanjutnya. Sementara jika Rudi memungkinkan Nita untuk mengunduh aplikasi tepat sebelum pembayaran transaksi mendapat satu konfirmasi di blockchain, maka Nita bisa sesegera mungkin untuk menyiarkan transaksi ganda berikutnya. Sedangkan node berikutnya akan bisa memasukkan blok berisi transaksi ganda tersebut. Sedangkan blok yang berisi transaksi valid Nita kepada Rudi tidak dimasukkan.
Dalam hal ini Rudi bisa melindungi dirinya dari serangan double-spend. Rudi harus menunggu sampai mendapat satu atau lebih konfirmasi. Disisi lainnya, seorang pedagang harus berhati-hati saat melakukan. Bahkan ketika transaksi tersebut sudah dimasukkan kedalam rantai blok. Jika Rudi dalam hal ini bisa melihat bahwa Nita berhasil meluncurkan serangan double-spend, maka Rudi bisa menyadari hal itu karena blok yang berisi transaksi validnya telah menjadi orphan block. Jika hal itu terjadi Rudi sepatutnya tidak mengabaikan transaksi itu, dan tidak membiarkan Nita mendownload aplikasinya. Sebaliknya jika itu terjadi meskipun ada upaya serangan transaksi ganda, beberapa node berikutnya akan membangun blok yang berisi transaksi valid pembayaran Nita ke Rudi. Karena keyakinan dalam konsensus akan selalu berada pada blok yang terpanjang.
Secara umum, semakin banyak konfirmasi transaksi yang didapat, maka semakin tinggi kemungkinan akan berada pada konsensus blok jangka panjang. Perlu diingat lagi bahwa node yang jujur kecenderungannya akan lebih banyak memperpanjang blok yang berukuran lebih panjang saat mereka melihatnya di rantai blok. Sehingga peluang cabang blok yang pendek berisi transaksi ganda tersebut makin sempit.
Kenyatannya adalah, double-spend ini akan bisa diminimalisir dengan banyaknya jumlah konfirmasi transaksi. Sehingga transaksi yang telah menerima sejumlah konfirmasi lebih banyak maka peluang adanya serangan double-spend menjadi lebih sedikit. Secara heuristik, dalam transaksi Bitcoin paling tidak menunggu setelah ada enam konfirmasi. Meski tidak ada penjelasan secara lebih detail bahwa transaksi anda harus menunggu enam konfirmasi tersebut. Angka enam konfirmasi itu hanya sebagai jaminan saja bahwa transaksi anda akan benar-benar aman dan bisa berada dalam konsensus panjang blockchain.
Perlindungan atas upaya transaksi ganda ini sepenuhnya dilakukan dalam kriptografi. Namun hal itu juga perlu ditegakkan dalam konsensus. Artinya, bahwa jika sebuah node berusaha memasukkan transaksi yang tidak valid, maka satu-satunya alasan yang akan membantahnya adalah beberapa dan mayoritas node yang jujur tidak akan memasukkan transaksi tersebut sebagai transaksi yang sah didalam rantai blok.
Di sisi lainnya, perlindungan dari upaya transaksi ganda ini didasarkan pada konsensus. Dalam hal ini, kriptografi tidak bisa banyak berperan dalam hal ini. Dan dua transaksi yang salah satunya mewakili upaya transaksi ganda hanya berlaku pada perspektif kriptografi. Tapi konsensus tersebut menentukan blok manakah yang akan dimasukkan dalam konsensus blok jangka panjang. Pada akhirnya, anda tidak bisa 100 persen yakin bahwa transaksi anda akan bisa berada di cabang konsensus blok. Namun jaminan probabilitas eksponensial ini sudah cukup baik. Setidaknya setelah enam konfirmasi transaksi, maka hampir tidak ada peluang akan ada hal salah terjadi berikutnya.
Sekarang kita telah mengetahui bagaimana konsensus tanpa identitas ini bisa dilakukan di dalam blokchain bitcoin.
