Asal Mula ,
Apa itu Algoritma Konsensus (Consensus ) atau kesepakatan dalam blockchain , Blockchain berbasis Vexanium adalah sebuah blockchain dengan aturan yang terdistribusi dengan sangat efisien, deterministik, dan dapat beroperasi secara desentralisasi. Blockchain Vexanium melacak transaksi dalam urutan blok yang diberkaitan . Setiap blok secara kriptografis terkoneksi dan tersambung ke blok sebelumnya di sepanjang rantai (chain) yang sama. Oleh karena itu sangat sulit untuk memodifikasi transaksi yang dicatat pada blok tertentu tanpa melanggar pemeriksaan kriptografi dari blok secara simultant dan berturut-turut. Fakta sederhana ini membuat transaksi blockchain tidak dapat diubah dan aman.
Block Producers
Dalam ekosistem Vexanium , proses produksi blok dan validasi blok dilakukan oleh node khusus yang disebut “Block Producers/ produsen blok“. Produser dipilih oleh para voters/users diblockchain Vexanium . Setiap produsen menjalankan instance dari node vexanium melalui layanan nodeos. Untuk alasan ini, produsen yang berada pada jadwal aktif untuk memproduksi blok juga disebut node “aktif” atau “memproduksi”.
Pentingnya Sebuah Consensus (Konsensus)
Konsensus (Consensus) dalam arti menurut kamus Bahasa Indonesia , adalah sebuah frasa untuk menghasilkan atau menjadikan sebuah kesepakatan yang disetujui secara bersama-sama antarkelompok atau individu setelah adanya perdebatan dan penelitian yang dilakukan dalam kolektif intelijen untuk mendapatkan konsensus pengambilan keputusan
Untuk menValidasi blok pada blockchain vexanium sebenarnya menghadirkan sebuah tantangan tersendiri di antara para node / Block Producers yang ada di jaringan blockchain , oleh karena itu Sebuah model konsensus(sebuah kesepakatan) itu diperlukan untuk memvalidasi blok ke blok , agar disepakati sebuah cara yang toleran terhadap sebuah kesalahan pada sistem desentralisasi. Konsensus adalah cara agar node dan pengguna yang terdistribusi untuk menyetujui apa yang terjadi blockchain saat ini ( lihat dibagian selanjutnya Konsensus VEXANIUM (DPoS + aBFT)
Model CONSENSUS (Konsensus)
Sebelum mengarah ke pembahas Consensus Vexanium , ada baiknya kita mengenal berbagai cara untuk mencapai konsensus(kesepakatan) yang populer di antara sekelompok Node yang terdistribusi dalam sistem desentralisasi. Sebagian besar model konsensus mencapai kesepakatan melalui beberapa bukti. yang paling populer adalah Proof of Work (PoW) , Proof of Stake (PoS), dan DPOS ( Delegate Proof Stake ) , memang ada beberapa metode yang lain namun untuk belajar blockchain 3 metode populer ini sudah mewakili
1. Proof Of Work
Proof of Work (PoW)
POW merupakan Konsensus yang Populer dan digunakan oleh banyak blockchain Generasi Pertama seperti Bitcoin , POW (proof of work) adalah sebuah metode kesepakatan yang dibuat dari sebuah Pembuktian sebuah Pekerjaan atau Bukti Kerja dan Bukti Menambang . Dalam POW , node penambang (Miner ) bersaing untuk menemukan angka yang ditambahkan ke header blok yang menyebabkan blok memiliki beberapa properti yang diinginkan (biasanya sejumlah nol dalam bit paling signifikan dari hash kriptografi dari header blok). Dengan menjadikannya mahal secara komputasi untuk menemukan nonce yang membuat blok valid ( nonce adalah angka arbitrer yang dapat digunakan hanya sekali dalam komunikasi kriptografi )
Kerugian utama Proof of Work adalah bahwa keamanan jaringan tergantung pada pengeluaran banyak sumber daya pada daya komputasi untuk menemukan nonces.
2 Proof Of Stake ( POS)
Dalam Proof-of-Stake, node yang memiliki stake atau persentase terbesar dari beberapa aset ( coin yang digunakan pada utilitas blockchain tersebut memiliki kekuatan keputusan yang setara. Dengan kata lain, kekuatan memilih sebanding dengan stake yang dimiliki. salah satu varian yang menarik dari POS adalah Delegated Proof-of-Stake (DPoS) di mana sejumlah besar peserta atau pemangku kepentingan memilih sejumlah kecil delegasi, yang pada gilirannya membuat keputusan untuk mereka.
3. Delegate Proof Of Stake (DPOS) ,Vexanium Consensus
DPOS (Delegate Proof of Stake ) ditemukan oleh seorang Blockchain developer bernama Dan Larimer , founder dari Blockchain Bitshares , Steem dan Eos , Blockchain Berbasis Vexanium berbasis sebuah kepemilikan yang didelegasikan (DPoS) untuk memilih Blockproducers aktif yang akan diberi wewenang untuk memvalidasi blok yang valid dalam jaringan Blockchain . Namun, ini hanya setengah dari proses konsensus Vexanium . Setengah lainnya terlibat dalam proses aktual mengkonfirmasikan setiap blok sampai menjadi final (ireversibel), yang dilakukan dengan cara asynchronous byzantine fault tolerant (aBFT). Oleh karena itu, ada dua lapisan yang terlibat dalam model konsensus Vexanium :
Layer 1 – Model Konsensus Asli /Native Consensus (aBFT).
Layer 2 – Delegate Proof of Stake Konsensus (DPoS).
Model konsensus asli (Native consensus ) yang digunakan dalam Vexanium tidak memiliki konsep pendelegasian / pemungutan suara (voting) , staking, atau bahkan token. Ini digunakan oleh lapisan DPoS untuk menghasilkan jadwal pertama produsen blok dan, jika berlaku, memperbarui set paling banyak setiap putaran jadwal setelah setiap block produsen telah berputar. Kedua lapisan ini secara fungsional terpisah dalam perangkat lunak software vexanium.
Layer 1 : Model Native Consensus (aBFT )
Lapisan 1: Konsensus Asli / Native Consensus (aBFT / Asynchronous Byzantine Fault Tolerant )
Layer 1 inilah yang pada akhirnya memutuskan blok mana, diterima dan disinkronkan (received and synced ) di antara (blockproducers terpilih, akhirnya menjadi final, dan karenanya secara permanen dicatat dalam blockchain. selanjutnya Blockproducers mendapat jadwal produksi block yang diusulkan oleh lapisan Layer kedua (DPos yang didelegasikan) dan menggunakan jadwal itu untuk menentukan blok mana yang ditandatangani dengan benar oleh BP (Blockproducers ) yang sesuai.
Untuk toleransi kesalahan Bizantium (byzantine fault tolerance / BFT ) , layer 1 , menggunakan proses konfirmasi dua tahap blok dimana supermajoritas (2/3) dua pertiga dari blockproducers dari jadwal yang dijadwalkan saat ini mengkonfirmasi setiap blok dua kali. Tahap konfirmasi pertama mengusulkan blok ireversibel terakhir last irreversible block (LIB). Tahap kedua mengkonfirmasi last irreversible block (LIB ) yang diusulkan sebagai final. Pada titik ini, blok menjadi ireversibel. Lapisan ini juga digunakan untuk menandai perubahan jadwal blockproducer , jika ada, di awal setiap putaran jadwal.
Algoritma Finality
Model konsensus Blockchain Vexanium mencapai finalitas algoritme (Finality) melalui validasi Digital (signature) dari set peserta khusus yang dipilih (Block Produser aktif) yang diatur dalam sebuah jadwal untuk menentukan pihak mana berwenang untuk memvalidasi blok pada slot waktu tertentu. ( memang tidak bisa dipungkiri bahwa untuk finality, finality yang paling baik dapat dicapai dalam model Proof of Work)
untuk perubahan pada jadwal ini bisa juga dilakukan dengan smartcontract special yang berjalan di blockchain Vexanium , tetapi setiap perubahan yang dimulai pada jadwal tidak berlaku sampai setelah blok yang memprakarsai perubahan jadwal telah diselesaikan oleh dua tahap konfirmasi. Setiap tahap konfirmasi dilakukan oleh supermajoritas (2/3 Block produser dari rangkaian BP aktif yang dijadwalkan saat ini.
Layer 2 Delegated Proof of Stake
Layer DPoS atau Delegasi Proof of Stake memperkenalkan konsep token, Staking ( menyimpan ), Voting (memilih) / proxying, pengurangan suara(vote), penghitungan suara (pemilu ) , peringkat BlockProducers/ Validator, dan pembayaran reward inflasi. Lapisan Layer 2 ini juga bertugas menghasilkan jadwal Block Producers baru dari peringkat yang dihasilkan dari voting produser. Ini terjadi dalam putaran jadwal sekitar dua menit (126 detik) yang merupakan periode yang diperlukan untuk produsen blok untuk diberikan slot waktu untuk memproduksi dan memvalidasi blok. Lot waktu berlangsung total 6 detik per produsen, yang merupakan putaran produsen, di mana maksimum 12 blok dapat diproduksi dan ditandatangani. Lapisan DPoS diaktifkan oleh kontrak pintar / Smartcontrat WASM
Stake Holder dan Delegasi
Seleksi aktual dari produsen aktif / Block producers (jadwal produsen) terbuka untuk memilih setiap putaran jadwal dan melibatkan semua stake holder yang menggunakan hak mereka untuk berpartisipasi. Namun dalam praktiknya, peringkat produsen aktif tidak sering berubah. Stakeholder adalah pemegang akun VEXANIUM (VEX) reguler yang memilih produsen blok preferensi mereka untuk bertindak atas nama mereka sebagai delegasi DPoS. Namun, penyimpangan utama dari DPoS reguler adalah, begitu terpilih, semua produsen blok memiliki kekuatan yang sama terlepas dari peringkat suara yang diperoleh. Dalam model DPoS lainnya, kekuatan suara proporsional dengan jumlah suara yang diperoleh oleh masing-masing delegasi.
Proses Consensus
Proses konsensus Blockchain Vexanium terdiri dari dua bagian:
1. Voting / penjadwalan produser – dilakukan oleh layer 2 DPoS
2. Blok produksi / validasi – dilakukan oleh konsensus asli / Native consensus Layer 1 (ABFT / asynchronous byzantine fault tolerant )
Kedua proses ini independen dan dapat dieksekusi secara paralel, kecuali untuk putaran jadwal pertama setelah urutan boot ketika blok genesis atau block no 1 / block pertama saat blockchain dibuat.
Producer Voting dan Scheduling
Pemungutan suara (voting) dari block producers aktif untuk dimasukkan dalam jadwal berikutnya dilaksanakan oleh lapisan DPoS. Sebenarnya, pemegang token pertama-tama harus melakukan stake beberapa VEX coin untuk menjadi Stake holder dan dengan demikian dapat memilih dengan kekuatan stake yang diberikan.
Voting Proses / Proses Pemungutan Suara di Blockchain
Setiap stake Holder Vexanium sebenarnya dapat memilih hingga 30 produsen blok dalam satu tindakan pemilihan namun setiap block producers yang dipilih maka nilai suaranya akan terpecah , contoh anda memilih 2 blockproducers maka suara anda terbagi (2) . nah BlockProducers utama atau active producers ini berjumlah 21 Block produceres , untuk 21 block producers terpilih teratas kemudian akan bertindak sebagai delegasi DPoS ( Wakil Terpilih ) untuk memproduksi dan menandatangani blok atas nama stake Holder . Block Producers lain yang tersisa ditempatkan dalam daftar blockproducers Standby / siaga sesuai urutan suara yang diperoleh. Proses pemungutan suara mengulang setiap putaran jadwal dengan menambahkan jumlah suara yang diperoleh oleh masing-masing Block producers . Block Producers tidak memilih untuk mempertahankan suara lama mereka, meskipun terdepresiasi karena peluruhan suara. Para blockproducers yang memberikan suara juga dapat mempertahankan suara lama mereka, kecuali untuk kontribusi bobot suara terakhir untuk setiap pemilih, yang akan digantikan oleh bobot suara baru mereka.
Voting Weight
Bobot pemungutan suara (Voting Weight ) dari masing-masing stake holder dihitung sebagai fungsi dari jumlah VEX coin yang distake dan waktu yang berlalu sejak zaman timestamp blok Vexanium, didefinisikan sebagai 1 Januari 2000. Dalam implementasi saat ini, bobot pemungutan suara berbanding lurus dengan jumlah token distak dan basis-2 secara proporsional sebanding dengan waktu yang telah berlalu dalam tahun sejak tahun 2000. Berat aktual meningkat pada tingkat 2 1/52 = 1.013419 per minggu. Ini berarti bahwa bobot suara berubah setiap minggu dan dua kali lipat setiap tahun untuk jumlah coin yang sama.
Vote Decay
Peningkatan bobot suara(voting) menghasilkan depresiasi suara saat ini yang dipegang oleh masing-masing blockproducers. Pengurangan suara semacam itu disengaja dan alasannya ada dua:
Dorong partisipasi dengan memungkinkan suara yang lebih baru memiliki bobot lebih dari suara yang lebih tua.
Berikan lebih banyak suara kepada para pengguna yang terlibat aktif dalam masalah tata kelola penting.
Producers schedule
Setelah Bock Producers dipilih dan dipilih untuk jadwal berikutnya, mereka hanya diurutkan berdasarkan abjad berdasarkan nama produsen. Ini menentukan urutan produksi. Setiap produsen menerima set produsen yang diusulkan untuk putaran jadwal berikutnya dalam blok pertama yang akan divalidasi dari putaran jadwal saat ini yang akan dimulai. Ketika blok pertama yang berisi jadwal yang diusulkan dianggap tidak dapat diubah oleh supermajority dari blockproducers ditambah satu, jadwal yang diusulkan menjadi aktif untuk putaran jadwal berikutnya.
Production Parameters
Jadwal produksi blok dibagi rata di antara Block producers terpilih. Produser dijadwalkan untuk menghasilkan jumlah blok yang diharapkan setiap putaran jadwal, berdasarkan pada parameter berikut (per putaran jadwal):
Parameter | Description | Default | Layer |
---|---|---|---|
P (producers) | jumlah blockproducers Active | 21 | 2 |
Bp (blocks/producer) | jumlah blok yang berdekatan per Blockproducers | 12 | 1 |
Tb (s/block) | Producksi block time per block (s: seconds) | 0.5 | 1 |
Penting untuk menyebutkan bahwa Bp (jumlah blok yang berdekatan per produsen), dan Tb (waktu produksi per blok) adalah konstanta konsensus layer 1 (ABFT). Sebaliknya, P (jumlah produsen aktif) adalah konstanta layer 2 yang dikonfigurasikan oleh lapisan DPoS, yang diaktifkan oleh kontrak WASM.
Variabel berikut dapat didefinisikan dari parameter di atas (per putaran jadwal):
Variable | Description | Equation |
---|---|---|
B (blocks) | Total number of blocks | Bp (blocks/producer) x P (producers) |
Tp (s/producer) | Production time per producer | Tb (s/block) x Bp (blocks/producer) |
T (s) | Total production time | Tp (s/producer) x P (producers) |
Oleh karena itu, nilai P, yang didefinisikan pada layer 2 (Layer DPos) , dapat berubah secara dinamis dalam blockchain Vexanium. Dalam praktiknya, bagaimanapun, N secara strategis ditetapkan untuk 21 Block Producers, yang berarti bahwa 15 blockproducers diperlukan untuk supermajoritas dua pertiga produsen ditambah satu untuk mencapai konsensus.
Production Default Values
Nilai Default Produksi
Dengan default saat ini: P = 21 Blockproducers terpilih, Bp = 12 blok dibuat per produsen, dan blok diproduksi setiap T = 0,5 detik, waktu produksi saat ini adalah sebagai berikut (per putaran jadwal):
Nilai Variabel
Tp: Waktu produksi per produsen Tp = 0,5 (s / blok) x 12 (blok / produser) ⇒ Tp = 6 (s / produser)
T: Total waktu produksi T = 6 (s / produser) x 21 (produser) ⇒ T = 126 (s)
Ketika sebuah blok tidak diproduksi oleh produser tertentu selama slot waktu yang ditentukan, celah menghasilkan blockchain. Jika produsen terus tidak menghasilkan blok di luar batas waktu yang diberikan (ditetapkan oleh konstanta lapisan 2), produsen diturunkan ke daftar siaga.
Block Lifecycle
Blok dibuat oleh BP Blockproducers aktif sesuai jadwal selama jangka waktu yang ditetapkan, kemudian diteruskan ke node produsen lain untuk disinkronkan dan divalidasi. Proses ini berlanjut dari produser ke produser sampai jadwal baru produser tersebut disetujui pada putaran jadwal selanjutnya. Ketika blok yang valid memenuhi persyaratan konsensus (lihat Bagian Konsensus diatas ), blok menjadi final dan dianggap tidak dapat diubah. Oleh karena itu, blok menjalani tiga fase utama selama masa pakainya: produksi, validasi, dan finality. Setiap fase melewati berbagai tahap juga.
Block Structure
Sebagai urutan blok yang dirantai dalam sebuah rangkaian rantai yang bernama blockchain , unit dasar dalam blockchain adalah sebuah blok. Blok berisi catatan transaksi pra-divalidasi dan overhead kriptografi tambahan seperti hash dan tanda tangan yang diperlukan untuk konfirmasi blok, eksekusi ulang transaksi selama validasi, replay blockchain, perlindungan terhadap serangan replay, dll. (Lihat skema blok di bawah).
block schema
Name | Type | Description |
---|---|---|
timestamp |
block_timestamp_type |
expected time slot this block is produced (ends in .000 or .500 seconds) |
producer |
name |
account name for producer of this block |
confirmed |
uint16_t |
number of prior blocks confirmed by the producer of this block in current producer schedule |
previous |
block_id_type |
block ID for previous block |
transaction_mroot |
checksum256_type |
merkle tree root hash of transaction receipts included in block |
action_mroot |
checksum256_type |
merkle tree root hash of action receipts included in block |
schedule_version |
uint32_t |
number of times producer schedule has changed since genesis |
new_producers |
producer_schedule_type |
holds producer names and keys for new proposed producer schedule; null if no change |
header_extensions |
extensions_type |
extends block fields to support additional features (included in block ID calculation) |
producer_signature |
signature_type |
digital signature by producer that created and signed block |
transactions |
array of transaction_receipt |
list of valid transaction receipts included in block |
block_extensions |
extension_type |
extends block fields to support additional features (NOT included in block ID calculation) |
id |
block_id_type |
UUID of this block ID (a function of block header and block number); can be used to query block for validation/retrieval purposes |
block_num |
uint32_t |
block number (sequential counter value since genesis block 0); can be used to query block for validation/retrieval purposes |
ref_block_prefix |
uint32_t |
lower 32 bits of block ID; used to prevent replay attacks |
Beberapa bagian blok diketahui sebelumnya ketika blok dibuat, sehingga ditambahkan selama inisialisasi blok. Lainnya dihitung dan ditambahkan selama finalisasi blok, seperti hash root merkle untuk transaksi dan tindakan, nomor blok dan ID blok, validasi dari blockproducers yang membuat dan memvalidasi blok, dll
Produksi Block / Block Production
Selama setiap jadwal putaran produksi blok, produsen sesuai jadwal harus membuat Bp = 12 blok yang berdekatan yang berisi sebanyak mungkin transaksi yang divalidasi. Setiap blok saat ini diproduksi dalam rentang Tb = 500 ms (0,5 s). Untuk menjamin waktu yang cukup untuk menghasilkan setiap blok dan mengirimkan ke node lain untuk validasi, waktu produksi blok dibagi lagi menjadi dua parameter yang dapat dikonfigurasi
Maximum processing Interval : time window to push transactions into the block (currently set at 200 ms).
Minimum Propagration Time : time window to propagate blocks to other nodes (currently set at 300 ms).
Semua transaksi mengambang dan yang belum kedaluwarsa, atau jatuh sebagai akibat dari validasi sebelumnya yang gagal, disimpan dalam antrian lokal untuk kedua blok inklusi dan sinkronisasi dengan node lain. Selama produksi blok, transaksi yang dijadwalkan diterapkan dan divalidasi oleh produsen sesuai jadwal, dan jika valid, didorong ke blok yang tertunda dalam interval pemrosesan. Jika transaksi jatuh di luar jendela ini, itu tidak diterapkan dan dijadwal ulang untuk dimasukkan dalam blok berikutnya. Jika tidak ada lagi slot blok yang tersedia untuk produsen saat ini, transaksi akhirnya diambil oleh simpul produksi lain (melalui protokol peer-to-peer) dan didorong ke blok lain. Interval pemrosesan maksimum sedikit kurang untuk blok terakhir (dari putaran produsen blok Bp) untuk mengkompensasi latensi jaringan selama handoff ke produsen berikutnya. Pada akhir interval pemrosesan, tidak ada lagi transaksi yang diperbolehkan di blok yang tertunda, dan blok melewati tahap finalisasi sebelum disiarkan ke produsen blok lain untuk validasi.
Blok melewati berbagai tahap selama produksi: menyetujui (apply ), menyelesaikan (finalize) , menandatangani/validasi (Sign ) , dan berkomitmen (finalize ).