Dalam artikel sebelumnya, sudah dibahas seperti apa mekanisme platform Stellar secara umum serta keuntungan yang bisa didapatkan oleh pengguna. Mari bahas bagaimana cara kerja platform Stellar lebih detil lagi: Mekanisme dan Protokol Konsensus Stellar.

Mekanisme Konsensus Stellar

Mekanisme konsensus adalah bagaimana cara kerja sistem desentralisasi. Tujuan utama dari sistem desentralisasi adalah untuk mengatasi permasalahan Jenderal-jenderal Byzantine. Artinya, sistem harus tetap bekerja bahkan ketika banyak pihak yang bertindak buruk.

Karena Stellar merupakan fork dari Ripple, mereka memiliki sistem RPCA (Algoritma Konsensus Ripple) yang merupakan algoritma PBFT (Practical Byzantine Fault Tolerant). Begini cara kerja PBFT:

• Terdapat pengaturan yang telah ditentukan dari validator yang dipilih oleh otoritas sentral.
• Validator ini mengatur sistem dengan menyetujui berbagai hal seperti verifikasi transaksi.
• 66% dari validator perlu mencapai konsensus yang dicatat dalam blockchain.
• Selama elemen buruk tidak mencapai lebih dari 33% konsensus, semuanya masih berjalan seperti biasa.

Stellar memiliki sistem ini hingga mereka menemukan fork setelah menemukan kesalahan pada sistem PBFT yang menghentikan mereka mencapai konsensus. Professor David Mazières dari Stanford memeriksa masalahnya dan beliau menyadari bahwa terdapat isu mendasar dengan sistem PBFT.

Pertama, beliau mengklaim bahwa hasil imposibility FLP (Fisher Lynch Paterson) menyatakan bahwa sistem konsensus asinkron deterministik bisa memiliki dua dari tiga karakter di bawah ini:

• Keamanan,
• Pemutusan atau penghidupan terjamin,
• Toleransi Kesalahan (Fault Tolerance).

Menurut David, PBFT mengorbankan Keamanan di atas dua hal lainnya. Dia menyimpulkan bahwa ini berarti algoritma ini memprioritaskan penutupan buku besar dan ketersediaan atas semua orang yang benar-benar menyetujui apa buku besar itu — sehingga membuka beberapa skenario risiko potensial.”

Kedua, isu “Kebenaran yang bisa Dibuktikan”. David meriset keseluruhan sistem dan menemukan bahwa algoritma gagal menjadi aman dalam semua kondisi.

Sejak itu, Stellar mulai versi algoritma konsensus berbasis FBA (Federated Byzantine Agreement). Algoritma disebut SCP atau Protokol Konsensus Stellar. Karena ini basis dari Stellar secara lengkap dicatat.

Jadi bagaimana SCP Bekerja?

Sebelumnya, mari kita mengerti dua konsep dasar algoritma:

• Federated Byzantine Agreement,
• Optimal Failure Resilience.

Federated Byzantine Agreement (FBA)

Dalam White Paper tertulis:

“Pada FBA, tiap peserta mengerti bahwa mereka semua dianggap penting. Tiap peserta menunggu sebagian besar dari mereka untuk setuju pada transaksi manapun sebelum mempertimbangkan untuk menyelesaikan transaksi. Sebagai gantinya, peserta-peserta yang dianggap penting memilih tidak menyetujui transaksi sebelum peserta lain yang mereka anggap penting menyetujuinya, dan sebagainya. Akhirnya, jumlah cukup dalam network menerima sebuah transaksi yang menjadi tidak layak bagi peretas untuk mengembalikannya kembali. Kemudian peserta menganggap transaksi sudah selesai. Konsensus FBA bisa meyakinkan integritas network finansial. Pengaturan desentralisasi dapat memacu pertumbuhan organik.

FBA merupakan variasi dari masalah Perjanjian Byzantine yang diselesaikan tanpa mengetahui berapa node yang berpartisipasi. Satu tantangan mendasar dari pembuatan FBA adalah memilih kuorum dalam sistem desentralisasi.

Untuk memilih kuorum, tiap node v memilih satu atau lebih kuorum. Sebuah kuorum harus memiliki setidaknya satu dari dua pengaturan ini:

• Untuk node v, kuorum manapun yang dipilih harus mencakup v,
• Set node pada v harus berupa node yang dirasa cukup penting dan dapat dipercaya.

Lalu jika keseluruhan bagian kuorum telah menyetujui pernyataan, maka pernyataan dianggap benar. Setelah kita mengetahui apakah potongan kuorum, mari mendefinisi FBA.

FBA adalah set node v dan fungsi kuorum Q() seperti Q(v) adalah set dari semua potongan yang dipilih oleh v.

Kuorum U adalah set node V yang mencakup setidaknya satu slice dari tiap anggota. Dalam bahasa awamnya, node memilih dan menjadi bagian slice kuorum dan slice menjadi beberapa kuorum.

Mari melihat representasi visual dari semua kuorum dan slice pada praktiknya. Mari lihat diagram di bawah ini:

Anggap terdapat 4 set node v1, v2, v3, dan v4. Tanda panah menunjukkan ketergantungan kuorum.

Mari lihat pada v2, v3, dan v4.

Dalam hal ini, v1 mengatakan keputusan mereka berdasarkan keputusan v2 dan v3. Namun, keputusan v2 dan v3 tidak mencantumkan v1. Karenanya, ketika v1, v2, dan v4 adalah slice kuorum untuk v1 tapi mereka bukan kuorum karena v2 dan v3 tidak memiliki slice kuorum mereka dalam kuorum.

Lalu bagaimana bisa v1 menjadi bagian dari kuorum seperti dalam diagram di atas?

Satu-satunya cara v1 bisa menjadi bagian kuorum adalah jika kita mencantumkan keempat node. Dengan cara ini tiap node memiliki slice kuorum. Ini adalah kesepakatan node yang sederhana. Mari lihat yang sedikit lebih rumit.

Di bawah ini adalah versi node dengan tier (tingkat). Terdapat tier paling atas, tier menengah dan tier paling bawah; seperti pada contoh berikut:

Pada tier atas, tiap node bisa membuat slice dari dua node di dalam tier atas.
Pada tier menengah, tiap node bisa membuat satu slice dari dua node di tier atas.
Pada tier bawah, tiap node bisa membuat satu slice dari dua node di tier menengah.

Tier paling atas tidak ditentukan oleh otoritas pusat, tetapi oleh market.

Mari lihat contoh real life dari cara kerja ini. Anggap kita memiliki struktur dengan tier dari bank.

Pada gambar atas, terdapat bank seperti Citibank, Wells Fargo, dan sebagainya pada tier atas. Anggap mereka menjadi node dalam tier menengah dan pada tier bawah adalah nasabah/klien.

Sekarang, mari membuat sebuah modifikasi di sini.

Anggap node pada tier menengah tidak begitu percaya pada bank, mereka tidak ingin konsensus terjadi tergantung pada mereka. Mereka bisa membawa pihak ketiga dari institusi keuangan untuk menjadi penghubung tier atas.

Konsensus dan slice kuorum berubah. Kita memiliki penghubung tier atas di mana sebuah slice untuk tiap node pada tier atas bisa dibentuk dengan node lain dalam tingkat mereka.

Sekarang, tier tengah membentuk sebuah slice dari mereka sendiri: 2 dari 4 bank pada tingkat atas dan 1 dari 3 dalam penghubung tingkat atas.

Dalam bentuk reiterasi:

Q(node tier tengah) = { node tier tengah, node dari bank dalam tier atas, node dari bank dalam tier atas, node dari pihak ketiga penghubung tier atas }

Sekarang kita akan melihat bagaimana struktur dan modifikasi bisa menghentikan terjadi double spending. Anggap Citibank mengatakan pada v7 bahwa akan memberikan mereka miliar dollar untuk layanan mereka. Dalam kasus ini, mari lihat dari tiga slice kuorum:

3 dari 4 bank dalam tier atas akan membentuk slice.
2 dari 3 node dalam penghubung pihak ketiga tier institusi keuangan akan membentuk slice.
Node tengah akan membentuk slice, 2 dari 4 bank dalam tier atas dan 1 dari 3 dalam paralel tier atas.

Semua slice ini akan bergabung dan membentuk sebuah kuorum.

Node yang ditandai dengan centang hijau adalah bagian dari kuorum.

Anggap Citibank ingin mengembalikan transaksi dan mengirim uang pada v8, pada intinya melakukan double spending. Lalu, anggap bank yang tidak membentuk sebuah slice berubah menjadi jahat (evil).

Konsensus tidak akan terjadi karena v8 harus melalui rute yang sama dengan v7 dan membentuk kuorum dengan bank dari tier atas dan pihak ketiga paralel tier atas. Tier pihak ketiga tidak akan menyetujui transaksi karena mereka telah menyelesaikan transaksi yang sama dengan v7.

V8 hanya perlu memiliki satu pihak dari paralel tier atas untuk setuju dengan mereka, lalu mengapa mereka tidak bisa pergi menuju ACLU (node ketiga dalam tier paralel)? Hal itu karena ACLU perlu membuat sebuah slice dengan satu dari dua node lainnya, dan karena node telah menolak transaksi, ACLU harus menolaknya juga (karena aturan dari slice kuorum).

Itu adalah contoh dari bagaimana FBA bekerja dalam real life.

Ketahanan Kegagalan Optimal

Ketahanan Kegagalan Optimal adalah seberapa aman kita bisa membuat protokol konsensus. Untuk mengecek sistem dalam hal ketahanan, kita perlu mengeceknya untuk dua skenario di mana sistem bisa mengalami kerusakan. Dua skenario tersebut adalah: Kegagalan dan Kekurangan Liveness.

Kasus 1: Kegagalan

Satu dari titik kegagalan paling mendasar untuk sistem ini bisa menjadi eksistensi dari dua kuorum independen dan terpisah seperti ini:

Seperti dalam gambar di atas, terdapat dua kuorum yang berbeda dan kemungkinan ini bisa menyebabkan kerusakan pada sistem. Kita tidak bisa memiliki dua keputussan akhir dalam sistem pengambilan keputusan.

Jadi bagaimana solusinya?

Solusinya disebut Persimpangan Kuorum, yang pada dasarnya berarti bahwa dua kuorum dalam sebuah sistem FBA akan berbagi satu kontak node. Karenanya skenario di atas akan terlihat seperti ini:

Dalam diagram di atas, v7 adalah Persimpangan Kuorum. Sekarang ini jelas mengarah pada masalah yang sangat valid: bagaimana jika v7 berubah menjadi buruk?

Karenanya, karakter lain yang harus dimiliki FBA adalah ketahanan, di mana persimpangan kuorum harus bisa terjadi walau terdapat node yang buruk. Bahkan jika Anda menghapus node yang buruk, sistem harus tetap bekerja seperti biasa.

Ini jelas tidak akan bekerja dalam diagram di atas, karena node v7 adalah node tersendiri dan jika dihapus sistem akan kembali pada kondisi sebelumnya seperti ini:

Kasus 2: Kurangnya Liveness

Bagaimana dengan liveness dan keabsahan tiap kuorum? Sebuah node dalam FBA memiliki liveness jika node bisa berfungsi tanpa partisipasi node buruk.

Anggap kita memiliki kuorum di atas.

Tiap node bergantung pada masing-masing dan 2 dari 3 node membuat sebuah kuorum. Bagaimana jika terdapat skenario di mana node v3 dan v4 menjadi buruk?

Dan kita memiliki situasi seperti ini:

Bahkan jika v1 dan v2 adalah node baik, mereka tidak bisa membuat slive kuorum karena tidak percaya pada v3 dan v4 yang keduanya menjadi buruk.

Seperti pada diagram, dua slice kuorum yang bisa terjadi adalah:

Q(v1) = v1 dan 2 dari {v2,v3,v4}

Q(v2) = v2 dan 2 dari {v1,v3,v4}

Elemen kedua slice adalah v3 dan v4, secara kolektif disebut v-blocking. V-blocking adalah sebuah set yang memiliki setidaknya satu node dari tiap slice v. Ini mengapa, dalam skenario ini, kuorum menggagalkan ujicoba liveness karena mendapatkan v-blocking dari node yang buruk. Dengan demikian, kita bisa menyimpulkan bahwa hanya node yang benar dan tidak buruk yang bisa melakukan v-blocking.

Simpulan: Keamanan

Karena sudah melihat dua kasus, apa yang bisa kita simpulkan? Anggap terdapat set dari node baik A dan set dari node baik B. Node A bisa dianggap tahan kegagalan hanya jika:

A bisa lebih menikmati persimpangan kuorum daripada B.
A adalah sebuah kuorum yang tidak mendapatkan v-blocked dari B.

Jika A merasa puas dengan dua kondisi di atas, maka A disebut node utuh (intact).

Protokol Konsensus Stellar

Setelah membahas bagaimana FBA bekerja dan permasalahan yang dihadapi protokol FBA untuk menjadi tahan kegagalan, mari membahas apa itu SCP (Protokol Konsensus Stellar).

SCP adalah protokol FBA yang menjamin bahwa node baik akan menikmati persimpangan kuorum meskipun dengan kehadiran node yang buruk. Ini merupakan kasus Byzantine Fault Tolerant. Cara agar SCP mencapai ini dan ide di belakangnya adalah Penggabungan Voting (Federated Voting).

Penggabungan Voting

Tiap node v dalam ekosistem bisa voting untuk pernyataan “a” yang memasukkan “a” konsisten dengan pernyataan sebelumnya yang telah disetujui sebelumnya. Sekarang, anggap kita memiliki kuorum U yang terdiri dari node v, lalu kita memiliki dua kondisi ratifikasi:

U meratifikasi a jika tiap member U meratifikasi a.
Node v meratifikasi a jika kuorum U meratifikasi a.

Teori di belakang ini sangat mudah. Jika kita memiliki sistem Byzantine Fault Tolerant, daripada memiliki node buruk, pernyataan “a” masih bisa diratifikasi. Walau begitu, kita masih tetap memiliki dua skenario kegagalan:

Node v mungkin tidak akan voting untuk a.
Beberapa node yang telah voting untuk a berhenti bekerja.

Karenanya, seperti apa hasil dari Penggabungan voting? Ini sama dengan hasil dari voting sederhana harian yang akan terlihat seperti ini:

Apa yang Terjadi di Sini?

Pada awalnya, kita memiliki set gabungan dari orang-orang. Mereka bisa voting untuk “a” atau “a”. Gabungan bagian yang bisa voting untuk salah satu bagian disebuah bagian “bivalent”. Sekarang kita memiliki tiga skenario. Entah mayoritas node akan voting untuk “a”.
Atau, mayoritas node voting untuk “a”.
Atau, tidak ada mayoritas dan seluruh sistem terjebak.

Inilah cara kerja sistem voting sentralisasi. Dan ini bagaimana hasil Penggabungan Voting terlihat.

Namun, sekali lagi kita memiliki dua titik kegagalan:

• Keseluruhan dasar cara kerja voting berdasarkan anggapan bahwa sistem tidak bisa gagal. Namun, ini tidak menjadikannya Byzantine Fault Tolerant.
• Sebuah node v dalam kuorum Q tidak bisa menganggap kuorum lain akan benar.

Jadi bagaimana kita mengetahui sistem desentralisasi dalam SCP akan voting bagian “a” dan membuatnya a-valent? Untuk membuatnya terjadi, tiap node perlu memiliki ratifikasi dari dekat. Dan kita perlu menjawab dua pertanyaan ini:

Bagaimana bisa node v mencapai konsensus tentang bagian “a” bahkan setelah voting melawannya?
Bagaimana Anda mengetahui keseluruhan sistem telah mencapai konsensus pada “a”?

Menjawab Pertanyaan 1

Pertama, mari menjawab pertanyaan: Bagaimana bisa node v mencapai konsensus tentang bagian “a” bahkan setelah voting melawannya? Agar bagian “a” bisa diterima oleh node “v”, bagian ini harus memenuhi dua kondisi:

Kuorum milik v yang harus voting atau diterima oleh “a”.
Tiap member dari set v-blocking yaitu node yang membuat slice kuorum dengan “v”, harus menerima “a”.

Poin terakhir memastikan bahwa node “v” menerima bagian “a” bahkan setelah voting melawannya. Namun, kita tetap tidak memiliki konsensus yang jelas. Kita tetap menghadapi dua masalah:

Kita tidak tahu jika semua node utuh (intact) akan menerima bagian “a”.
Kita tidak bisa meyakinkan keamanan sub-optimal dari node yang tidak utuh (non-intact) memiliki persimpangan kuorum.

Menjawab Pertanyaan 2

Untuk mengatasi masalah-masalah ini, kita perlu menjadwab pertanyaan kedua: Bagaimana Anda mengetahui keseluruhan sistem telah mencapai konsensus pada “a”?

Solusinya adalah voting lainnya. Ini adalah voting untuk mengkonfirmasi fakta bahwa vote pertama berhasil.

Bagaimana konfirmasi ini bekerja?

Kuorum U mengkonfirmasi bagian “a”, dengan meratifikasi bahwa “kita voting untuk a”.
Node v mengkonfirmasi “a” jika “a” termasuk dalam kuorum “a”.

Bagaimana voting kedua ini akan menyelesaikan masalah yang ada sebelumnya?

Masalah: Kita tidak tahu apakah semua node utuh akan menerima bagian “a”.
Solusi: Node utuh akan voting melawan bagian “a” tapi tidak voting melawan fakta yang divoting kuorum untuk bagian “a”.

Masalah: Kita tidak bisa menjamin keamanan sub-optimal dari node yang tidak utuh memiliki persimpangan kuorum.
Solusi: Node yang tidak utuh tidak lagi mengalami kegagalan karena node buruk yang mendapat v-blocking karena ratifikasi dalam tahap imi adalah langkah pertama dan tidak tergantung pada keputusan dalam kuorum.

Teori yang mendasari seperti ini: jika satu node utuh mengkonfirmasi sebuah bagian, maka semua node utuh akan mengikutinya.

Simpulan: Penggabungan Voting

Akhirnya, mari menggabungkan semuanya dan melihat gambaran dari proses Penggabungan Voting.

Gambar di atas menjelaskan dua layer dari voting dalam sistem penggabungan voting. Jadi bagaimana SCP mengukur mekanisme konsensus lainnya?

Selanjutnya, kita akan membahas mengenai apakah Stellar menjadi platform ICO yang bagus.

Sumber: Blockgeeks