Home / Cara Kerja Bitcoin / Cara Kerja Bitcoin – Jaringan Bitcoin
Cara Kerja Bitcoin - Jaringan Bitcoin

Cara Kerja Bitcoin – Jaringan Bitcoin

Bagian Lima: Cara Kerja Bitcoin – Jaringan Bitcoin

Cara Kerja Bitcoin – Jaringan Bitcoin. Sampai sejauh ini telah kita pelajari bersama bagaimana transaksi bisa dipublikasikan dan dimasukkan kedalam Blockchain. Proses ini terjadi melalui jaringan Bitcoin. Jaringan Bitcoin, seperti yang telah diketahui, adalah jaringan peer-to-peer. Jaringan peer-to-peer bisa juga digunakan untuk banyak keperluan lain, tidak hanya seperti yang digunakan di Bitcoin. Di bahasan kelima Cara Kerja Bitcoin – Jaringan Bitcoin ini, kita bahas lebih spesifik pada bagaimana cara kerja Bitcoin dalam jaringan Bitcoin.

Node dalam Bitcoin, semuanya adalah sama. Tidak ada hirarki, tidak ada node khusus maupun yang berfungsi sebagai node induk. Jaringan Bitcoin berjalan melalui TCP dan memiliki tipologi acak. Setiap node baru, bisa langsung tergabung pada jaringan kapanpun yang ia inginkan. Semua orang bisa mengunduh Aplikasi Bitcoin, menginstal, dan lalu menjalankan dari laptop ataupun komputer desktop anda. Semua yang tergabung dan terhubung dalam jaringan Bitcoin, mempunyai hak dan kemampuan yang sama.

Jaringan Bitcoin sering berubah dalam waktu ke waktu, dan cukup dinamis, karena ada node yang masuk, dan ada node yang keluar jaringan. Tidak ada cara yang bisa secara eksplisit bisa menjelaskan mengapa node itu meninggalkan jaringan. Jika satu node tidak bisa mendengar publikasi transaksi dalam beberapa waktu, ditubuhkan waktu kurang lebih tiga jam, sebagai durasi untuk proses hardcode kepada klien secara umum. Sedang, node lain akan mulai melupakannya. Dengan cara ini, jaringan bisa menangani node yang akan beranjak ofline. Jadi jeda waktu ini bisa bermanfaat atas keluar masuknya node dalam jaringan tersebut.

Node terhubung ke peer secara acak. Namun tidak ada topologi geografis apapun. Maksudnya, misalkan sekarang anda menjalankan node baru dan hendak bergabung kedalam jaringan. Lalu memulainya dengan sebuah pesan sederhana kepada satu node yang telah anda ketahui. Ini biasanya disebut dengan seed node. Biasanya, ada beberapa cara untuk bisa melihat daftar seed node, sehingga anda bisa saling berhubungan secara khusus.

Misalnya anda mengirim pesan seperti ini, “Katakan alamat dari node lain yang anda ketahui”. Dan anda pun bisa mengulang mengirim pesan ini kepada node baru yang masuk. Lalu, anda bisa memillih node mana yang akan anda kontak. Sehingga anda menjadi sebuah member jaringan Bitcoin yang berfungsi secara penuh.

Ada beberapa cara yang bisa melihat node secara acak. Idealnya akan menghasilkan satu node yang bisa dilihat dengan cara acak tersebut. Saat node bergabung ke dalam jaringan, satu hal yang perlu diketahui adalah bagaimana cara node itu untuk bisa melakukan kontak dengan salah satu node lain yang telah berada dalam jaringan sebelum anda.

Fungsi jaringan ini, adalah untuk menjaga Blockchain. Dalam mempublikasikan transaksi, semua node dalam jaringan perlu mendengarkan pulikasi transaksi tersebut. Proses ini terjadi melalui flooding algorithm sederhana yang disebut dengan gossip protocol. Mengapa melalui flooding algorithm (argoritma flood)? Karena pada dasarnya nantinya node dalam jaringan akan mendengarkan publikasi transaksi yang begitu banyak terjadi dalam jaringan Bitcoin. Dan flooding algorithm ini adalah algoritma yang berfungsi untuk mendistribusikan materi transaksi yang akan dipublikasikan dalam jaringan Bitcoin.

Contohnya seperti ini, misalkan Nita ingin malakukan pembayaran kepada Rudi. Klien dan node mengirimkan transaksi itu kepada semua node yang telah terhubung dengannya. Lalu, setiap node akan mengeksekusi serangkaian pemeriksaan untuk menentukan apakah transaksi itu diterima dan diteruskan. Jika pemeriksaan tersebut berhasil, selanjutnya node akan mengirimkan kepada semua rekan node-nya.

Jika ada node yang mendengar sebuah transaksi namun belum masuk kedalam Blockchain, node tersebut akan menempatkan transaksi itu ke dalam pool transaksi. Namun tidak perlu untuk menyiarkannya. Hal ini dilakukan untuk memastikan flooding protokol telah benar-benar berakhir terlebih dahulu. Sehingga transaksi tidak looping di sekitar jaringan. Setiap transaksi bisa diidentifikasi secara unik pada hash-nya. Sehingga akan memudahkan mencari transaksi di pool transaksi.

Lalu bagaimana cara node itu saat memutuskan apakah transaksi itu harus disebarkan atau tidak? Sebelumnya, ada empat pemeriksaan yang dibutuhkan saat memberikan validasi pada sebuah transaksi.

  1. Transaksi harus valid dengan rantai bloknya. Lalu node menjalankan script pada setiap output di transaksi sebelumnya yang telah di tebus (redeem). Dan memastikan script berjalan dengan benar.
  2. Memeriksa bahwa output yang telah ditebus pada transaksi sebelumnya itu belum dibelanjakan atau dikeluarkan.
  3. Tidak akan merelay transaksi yang telah dilihat atau didengar. (seperti pada contoh pada transaksi yang telah ditempatkan di pool transaksi)
  4. Node hanya akan menerima dan merelay “standar” script berdasarkan script yang berada dalam list saja (whitelist script).

Semua pemeriksaan ini adalah pemeriksaan yang wajar saja sifatnya. Dan semua node harus menerapkan ini untuk menjaga jaringan bisa terus terjaga dan bekerja dengan baik. Meski pada dasarnya tidak ada aturan yang secara spesifik bahwa node harus menjalankan langkah ini. Karena jaringan Bitcoin adalah peer-to-peer. Semua orang bisa bergabung didalamnya. Kemungkinan-kemungkinan node yang melakukan double spend selalu ada.

Kadang-kadang, node juga harus melakukan pengecekan ini untuk dirinya sendiri. Karena kemungkinan-kemungkinan tadi selalu ada. Sehingga memungkinkan pula akan ada perbedaan pandangan pada transaksi yang tertunda, namun telah ditempatkan di pool transaksi.

Jika ada yang mencoba melakukan double spend, menjadi cukup menarik. Karena akhirnya akan ada perbedaan pandangan itu tadi. Misalkan dalam contoh seperti ini, Nita mencoba melakukan pembayaran koin yang sama kepada Rudi dan Anton. Lalu mengirim koin tersebut pada kedua orang tadi secara bersamaan. Beberapa node akan mendengar transaksi Nita kepada Rudi terlebih dahulu. Sementara node lain mendengar transaksi Nita kepada Anton terlebih dahulu.

Ketika seorang node mendengar salah satu transaksi itu, maka kemudian menambahkannya ke dalam pool transaksi. Sedangkan jika mendengar tentang transaksi lainnya, maka akan terlihat adanya double spend. Lalu node itu menjatuhkan transaksi terakhir tersebut, dan tidak merelay transaksi ataupun memasukkan kedalam pool transaksi. Akibatnya, node tidak menyetujui transaksi itu untuk ditambahkan kedalam blok berikutnya. Situasi seperti ini disebut dengan race condition.

Kabar bagusnya, proses ini bisa berjalan dengan baik untuk mengatasi double spend. Jadi siapapun penambangnya yang akan menambang blok berikutnya, harus menentukan satu diantara dua transaksi tertunda itu. Transaksi mana yang akan dimasukkan ke dalam blok secara permanen.

Kita lihat dalam contoh tadi, pada salah satu transaksi Nita kepada Anton yang diharapkan bisa masuk kedalam blok berikutnya. Ketika node yang melihat transaksi Nita kepada Rudi melihat transaksi lain ini (Nita kepada Anton), node akan menjatuhkan transaksi ini dari pool transaksi karena telah dilihat sebagai double spend. Sedangkan node yang mendengar blok dengan transaksi Nita kepada Anton, akan menghapus transaksi itu dari memory pool transaksi. Karena transaksi yang valid atas ini telah masuk kedalam blokchain. Sehingga tidak akan ada perselisihan jika sekali saja blok ini telah tersebar ke jaringan Bitcoin.

Umumnya perilaku node bergantung pada apa yang pertamakali mereka dengar. Hal ini akan memposisikan transaksi di dalam jaringan. Jika dua transaksi yang berbeda atau bertentangan diumumkan pada dua posisi jaringan yang berbeda, maka selanjutnya mereka akan mulai membanjiri seluruh jaringan Bitcoin. Transaksi mana yang dilihat node pertamakali bergantung pada di posisi mana transaksi itu berada dalam jaringan Bitcoin.

Asumsinya, bahwa semua node akan menerapkan hal ini, yakni tetap berdasarkan pada apapun yang dilihatnya pertamakali. Karena tidak ada otoritas terpusat yang membuat node harus menjalankan ini, maka node juga bebas untuk mengimplementasikan logika lain yang diinginkan. Dalam hal memilih satu dari dua transaksi yang bertentangan itu.

Nah, sejauh ini kita telah melihat bagaimana proses berjalannya transaksi. Dalam mengumumkan blok baru, prosesnya sama seperti pada penyebaran sebuah transaksi baru. Selain itu juga bergantung pada race condition yang sama. Jika dua blok ditambang dalam waktu yang bersamaan, hanya akan ada satu blok yang akan dimasukkan. Blok mana dari keduanya yang akan dimasukkan, bergantung pada blok mana yang salah satu bloknya, dibangun diatasnya oleh node lain. Maka blok lainnya akan menjadi blok yatim (orphan block).

Sementara, untuk memvalidasi blok, lebih kompleks sifatnya daripada memvalidasi sebuah transaksi. Karena selain memberikan validasi pada header dan memastikan nilai hash bisa diterima, node juga harus memvalidasi setiap transaksi yang ada didalam bloknya.

Node hanya akan meneruskan blok yang diatasnya dibagun blok lagi oleh node lain, pada cabang yang terpanjang dalam rantai blok. Hal ini untuk menghindari pembangunan forks. Ada kesamaan pada validasi transaksi, node juga bisa mengimplementasikan logika yang berbeda. Node mungkin akan merelay blok yang tidak valid. Atau juga akan merelay blok yang dibangun diluar titik awal dalam rantai blok. Meski ini akan menimbulkan pembangunan fork, namun tidak masalah. Karena protokol dalam validasi blok dirancang untuk bisa menahan hal seperti ini.

Ukuran Jaringan Bitcoin

Pada dasarnya, cukup sulit untuk bisa mengukur besarnya jaringan dalam Bitcoin. Karena seperti yang telah disampaikan diawal, bahwa jaringan cukup dinamis, dan tidak ada otoritas pusat didalamnya. Ada peneliti yang mengatakan bahwa jaringan terdapat satu juta alamat IP pada bulan tertentu sebagai simpul node Bitcoin. Lalu ada yang melihat hanya ada sekitar 5.000 sampai 10.000 node yang terhubung secara permanen di dalam jaringan Bitcoin. Dan node tersebut sepenuhnya memvalidasi setiap transaksi yang mereka dengar.

Full Node dan Ruang Penyimpanan (Storage)

Full node, harus tetap terhubung secara permanen di dalam jaringan. Sehingga bisa mendengar keseluruhan data. Semakin lama node ofline, maka semakin membutuhkan penangkapan data yang harus dilakukan ketika kembali terhubung kedalam jaringan. Selain itu, node itu juga harus menyimpan seluruh rantai blok dan memerlukan koneksi jaringan yang baik. Tentu saja untuk bisa mendengar setiap transaksi baru dan meneruskannya kepada node lainnya. Kebutuhan akan ruang penyimpanan ini saat ini berukuran gigabytes.

Full node juga harus menjaga keseluruhan output transaksi yang belum terpakai atau terbelanjakan, pada koin yang bisa dan tersedia untuk dibelanjakan. Idealnya, ini akan bisa tersimpan dalam RAM. Sehingga setelah mendengar ada transaksi baru yang diusulkan dalam jaringan, node bisa secara cepat melihat output transaksi yang akan di klaim. Lalu menjalankan script, melihat apakah signature pada transaksi itu valid, lalu menambahkan transaksi tersebut kedalam pool transaksi.

Lightweight node

Cukup berbeda dengan full node, pada lightweight node (node ringan) ini disebut juga dengan thin clients, atau Simple Payment Verification (SPV). Sebagian besar node dalam jaringan Bitcoin adalah node ringan ini. Node ringan berbeda sepenuhnya dengan full node. Perbedaannya, karena node ringan ini tidak menyimpan seluruh rantai blok. Mereka hanya menyimpan potongan-potongan kecil saja, yang mereka butuhkan untuk memverifikasi transaksi tertentu yang mereka perdulikan.

Mudahnya, contoh node ringan ini bisa dilihat saat kita menggunakan wallet Bitcoin. Karena biasanya akan menggabungkan node SPV. Node ini mendownload header blok dan transaksi yang mewakili pembayaran ke alamat yang anda gunakan.

Node SPV ini tidak memiliki tingkat keamanan seperti halnya pada full node. Karena node SPV telah bisa mengunduh header blok, itu bisa dipakai untuk memeriksa apakah blok itu sullit untuk ditambang atau tidak. Namun tidak bisa untuk melihat setiap transaksi yang dimasukkan kedalam blok yang valid. Karena mereka tidak menyimpan sejarah transaksi, dan tidak juga mengetahui serangkaian output transaksi yang belum dibelanjakan.

Node SPV hanya bisa memvalidasi transaksi yang berhubungan dan akan mempengaruhi transaksi mereka saja. Sehingga pada dasarnya, node ini mempercayakan kepada full node untuk memvalidasi seluruh transaksi lainnya yang terjadi di dalam jaringan.

Anggapannya, telah ada full node yang akan bisa bekerja keras, dan jika para penambang kesulitan untuk menambang blok ini, yang pada dasarnya merupakan proses yang mahal, mereka mungkin juga melakukan beberapa validasi untuk memastikan bahwa blok ini tiddak akan ditolak.

Untuk menjadi node SPV ini artinya telah melakukan penghematan biaya yang besar. Karena tidak membutuhkan koneksi bagus, ruang penyimpanan yang besar hingga gigabyte, perangkat yang memadai seperti pada full node. Sedangkan, header blok yang dibutuhkan node ringan ini hanya berukuran 1/1000 dari ukuran blockchain. Jadi, untuk menyimpannya hanya membutuhkan puluhan megabyte.

Maka, usailah pembahasan kita pada bagian kelima Cara Kerja Bitcoin – Jaringan Bitcoin kali ini. Pembahasan yang panjang lebar ini tadi, telah membahas bagaimana keseluruhan proses transaksi dalam jaringan, bagaimana validasi transaksi, begitupun juga pada sebuah blok baru. Selain itu, telah dibahas juga kaitannya dengan ukuran jaringan, ruang penyimpanan, dan full node maupun lightweight node yang ada dalam jaringan Bitcoin.

Bitconnect

About Edukasi Bitcoin

EdukasiBitcoin adalah media online untuk berbagi pengetahuan dasar tentang Bitcoin. Harapannya, agar bisa dijadkan sebagai sumber informasi maupun sebagai referensi penambah pengetahuan yang bermanfaat, berkaitan dengan Bitcoin dan teknologi yang melingkupinya.

Check Also

Keterbatasan dan Pengembangan Bitcoin

Keterbatasan dan Pengembangan Bitcoin

Cara Kerja Bitcoin – Keterbatasan Dan Pengembangan Bitcoin Keterbatasan dan Pengembangan. Protokol Bitcoin juga memiliki …

Leave a Reply

Your email address will not be published. Required fields are marked *