Scaling Consensus for Enterprise: Menjelaskan Algoritma IBFT

blog 1NewsPengembangEnterpriseBlockchain DijelaskanAcara dan KonferensiTekanBuletin

Berlangganan newsletter kami.

Alamat email

Kami menghormati privasi Anda

BerandaBlogEnterprise Blockchain

Scaling Consensus for Enterprise: Menjelaskan Algoritma IBFT

Bagaimana Istanbul Byzantine Fault Tolerance (IBFT) meningkatkan finalitas dan meningkatkan throughput dalam jaringan Ethereum pribadi. Oleh ConsenSysJuni 22, 2018Diposting pada 22 Juni 2018

Pahlawan Ethereum, ConsenSys

Algoritme konsensus adalah salah satu inovasi inti dari blockchain, namun juga salah satu yang paling membingungkan. Satoshi Nakamoto membuat versi Proof of Work (PoW) yang diimplementasikan sebagai sarana untuk mengamankan dan memvalidasi transaksi Bitcoin secara bersamaan. Komunitas blockchain telah membangun visi inti tersebut untuk membuat sup alfabet Proof of Stake (PoS), Proof of Authority (PoA), PBFT (Practical Byzantine Fault Tolerant), dan banyak lainnya yang semuanya dirancang untuk membangun konsensus secara terdistribusi. sistem, menciptakan satu sumber kebenaran yang membuat blockchain sangat berharga.

IBFT (Istanbul Byzantine Fault Tolerant) adalah mekanisme konsensus yang merupakan alternatif dari Proof of Work di jaringan Ethereum. Seperti algoritme lainnya, IBFT memastikan pemesanan tunggal yang disepakati untuk transaksi di blockchain, dan memberikan manfaat tambahan bagi perusahaan, termasuk penyelesaian penyelesaian. IBFT tadinya pertama kali diterapkan di Geth oleh Amis Technologies, dan segera setelah diterapkan di Kuorum.

Sebelum memasuki mekanisme konsensus IBFT, perlu disebutkan kapan dan mengapa seseorang ingin menggunakan IBFT. Dalam blockchain publik, jawaban singkatnya kemungkinan besar Anda tidak akan melakukannya. Tetapi ketika berbicara tentang konsorsium atau blockchain pribadi, IBFT mulai terlihat cukup menarik.

Algoritme PoW terkenal mahal, baik untuk perangkat keras maupun listrik. Biaya ini disengaja, untuk mencegah siapa pun dengan mudah mengambil alih jaringan, dan dengan demikian PoW sangat cocok untuk situasi dengan desentralisasi penuh di mana siapa pun (termasuk penyerang) dapat berpartisipasi. Node dalam rantai konsorsium / privat yang digunakan oleh perusahaan, bagaimanapun, secara intrinsik lebih dipercaya daripada yang ada dalam rantai publik. Dengan demikian, mekanisme konsensus PoW mungkin terlalu memberatkan, dan mekanisme lain mungkin memberikan kepercayaan yang “cukup” untuk menjalankan sistem terdistribusi.

Proof of Stake, juga, mungkin kurang relevan untuk perusahaan, karena membayar gas kurang penting dalam jaringan yang diizinkan. Karena node tidak (perlu) perlu mempertahankan mata uang di jaringan, PoS akan memperkenalkan persyaratan asing.

Mempertimbangkan pengorbanan ini, Proof of Authority (PoA) muncul sebagai solusi terbaik yang mungkin, memanfaatkan sistem di mana node dalam jaringan dialokasikan hak istimewa untuk menghasilkan blok baru untuk rantai menggunakan round-robin atau sistem arbitrer lainnya..

IBFT adalah salah satu dari banyak rasa PoA dan memberikan manfaat sebagai berikut:

  • Finalitas blok langsung. Hanya ada 1 blok yang diusulkan pada ketinggian rantai tertentu. Rantai tunggal dengan demikian menghilangkan forking, blok paman, dan risiko bahwa transaksi dapat “dibatalkan” sekali pada rantai di lain waktu.
  • Mengurangi waktu antar blok. Upaya yang diperlukan untuk membangun dan memvalidasi blok berkurang secara signifikan (khususnya yang berkaitan dengan PoW), sangat meningkatkan throughput rantai.
  • Integritas data yang tinggi dan toleransi kesalahan. IBFT menggunakan sekelompok validator untuk memastikan integritas setiap blok yang diusulkan. Sebagian besar (~ 66%) validator ini diminta untuk menandatangani blok sebelum penyisipan ke rantai, membuat pemalsuan blok menjadi sangat sulit. ‘Kepemimpinan’ grup juga berputar dari waktu ke waktu – memastikan node yang salah tidak dapat memberikan pengaruh jangka panjang terhadap rantai.
  • Fleksibel secara operasional. Grup validator dapat dimodifikasi tepat waktu, memastikan grup tersebut hanya berisi node tepercaya penuh.

Di sini kami memberikan gambaran umum tentang IBFT, sebagian besar dalam istilah non teknis. Untuk beberapa proposal asli IBFT, Anda dapat meninjau EIP di GitHub:

Untuk sisa artikel ini, kami akan mempelajari lebih banyak pertimbangan teknis IBFT, membahas banyak konsep yang ditemukan di EIP dan yang telah kami pelajari melalui penelitian kami sendiri.


Catatan: Kode IBFT juga dapat ditemukan di permintaan tarik go-ethereum # 16385.

Operasi

Mekanisme konsensus IBFT terdiri dari komponen-komponen berikut:

  1. SEBUAH PBFT model konsensus kelompok yang terinspirasi.
  2. Sebuah proses dimana anggota dapat ditambahkan / dihapus dari grup yang memvalidasi.

IBFT mengharuskan Header Blok (secara halus) dikerjakan ulang untuk mendukung semua aspek kapabilitas.

Model Konsensus Kelompok

Gambaran

IBFT menggunakan kumpulan node validasi (Validator) yang beroperasi di jaringan Ethereum untuk menentukan apakah blok yang diusulkan cocok untuk ditambahkan ke rantai.

Satu node dari Validator dipilih secara sewenang-wenang sebagai Pengusul dan bertanggung jawab untuk membangun blok pada interval blok dan berbagi blok tersebut dengan grup. Jika sebagian besar Validator menganggap blok itu valid, itu ditambahkan ke blockchain.

Pada penyelesaian putaran konsensus, Validator dapat memilih Pengusul baru yang akan bertanggung jawab untuk menyediakan Blok kandidat pada interval blok berikutnya..

Mekanisme konsensus adalah mesin status tersinkronisasi yang bertanggung jawab untuk memastikan semua Validator menambahkan blok yang sama ke rantai pada ketinggian yang sama.

Jika blok gagal dimasukkan, Pengusul diubah, dan proses dimulai lagi.

Untuk memastikan hanya satu blok yang dapat ditambahkan ke mesin negara, IBFT mencegah pengubahan blok yang diusulkan setelah sebagian besar validator menyetujui penyisipannya (tetapi tidak melakukan pekerjaan tersebut), proses ini disebut sebagai ‘Penguncian Blok’.

Mekanisme konsensus IBFT menawarkan stabilitas sistem asalkan kurang dari 1/3 node validasi berperilaku tidak benar (baik karena disusupi atau karena kode yang salah). Yaitu. untuk mentolerir node yang salah F, grup validasi harus berisi setidaknya 3F + 1 node (lebih dari ini tidak meningkatkan integritas sistem).

Catatan: Di sini F menyiratkan jumlah node rusak yang dapat ditoleransi oleh sistem.

Mesin Negara

Mesin Negara IBFT

Serikat
  • Menunggu Proposal. Validator sedang menunggu blok baru dipasok oleh pengusul saat ini. Jika validator adalah pengusul untuk babak ini, mereka menyiapkan blok yang diusulkan dan mengirimkannya dalam pesan persiapan sebelumnya.
  • Mempersiapkan. Telah menerima blok yang diusulkan (valid) dan validator-peer yang diberi tahu; sekarang menunggu rekan validator untuk memberi tahu penerimaan mereka atas pemblokiran tersebut.
  • Siap. Telah menerima penerimaan blok oleh validator-peer, dan menunggu mereka untuk berada di posisi yang sama. Pada tahap ini blok yang diusulkan telah ‘dikunci’, dan tidak dapat diganti sampai upaya penyisipan telah dilakukan.
  • Putaran Perubahan. Waktu putaran habis sebelum konsensus tercapai atau blok gagal dimasukkan. Tunggu sampai semua validator menyetujui nomor putaran berikutnya.
Transisi
  1. SEBUAHmenunggu Proposal → Mempersiapkan. Saat menerima blok baru (Siapkan pesan) dari pengusul (yaitu blok valid dalam isinya, seperti titik penyisipan rantai yang diusulkan).
  2. Menunggu Proposal → Perubahan Babak. Proposal yang diterima bukanlah blok yang valid sesuai dengan seperangkat aturan yang diberikan (mis. Pengusul tidak valid, penomoran putaran salah).
  3. Mempersiapkan → Siap. Saat menerima notifikasi 2F + 1 (Siapkan pesan) dari validator-peer yang menunjukkan blok yang diusulkan cocok untuk penyisipan.
  4. Siap → Menunggu Proposal. Saat menerima notifikasi 2F + 1 (pesan Komit) dari validator-peer yang menunjukkan bahwa mereka siap untuk menambahkan blok ke rantai. Saat transisi, proses menambahkan blok ke rantai dilakukan (berhasil).
  5. Siap → Perubahan Putaran. Sesuai Siap->Akan tetapi, menunggu Proposal, penyisipan blok gagal.
  6. Putaran Perubahan → Menunggu Proposal. 2F + 1 validator menyetujui nomor babak berikutnya yang akan digunakan.

Catatan: Semua transisi ke dalam hasil “RoundChange” di Validator mengirimkan pesan “RoundChange” ke validator-peer-nya.

Blokir Penguncian

IBFT mengamanatkan bahwa garpu tidak boleh dibuat. Untuk tujuan ini, setelah blok telah disepakati oleh mayoritas (yaitu saat masuk ke status Siap), blok itu menjadi “terkunci”.

Ini berarti tidak ada blok lain yang akan dipertimbangkan untuk dimasukkan hingga upaya untuk menambahkan blok ini ke rantai telah dicoba. Dengan demikian, blok berhasil dimasukkan (setelah pesan komit yang cukup diterima, baik dalam putaran ini atau putaran berikutnya), atau blok gagal dimasukkan, dibuang, dan blok baru diusulkan pada ketinggian rantai saat ini..

Keanggotaan Grup Validasi

Anggota grup validasi dapat berubah seiring waktu melalui mekanisme pemungutan suara. Anggota dapat ditambahkan atau dihapus melalui suara mayoritas (Lantai (N / 2) + 1); setiap suara ditangkap di Block Header.

Setiap node dalam jaringan (termasuk node yang tidak memvalidasi) bertanggung jawab untuk melacak penghitungan suara untuk setiap validator untuk menentukan Validator saat ini dan memastikan tanda tangan pada blok yang ditambang termasuk dalam kelompok yang diharapkan.

Mengingat setiap suara terdapat dalam Block Header, hanya Pengusul untuk babak tertentu yang dapat memberikan suara. Oleh karena itu, penting, jika node akan ditambahkan / dihapus tepat waktu, peran Pengusul diperbarui secara teratur..

Setelah node mencapai suara mayoritas, mereka segera bergabung / keluar dari grup validator.

IBFT mengakui Masa Pemungutan Suara, yang menetapkan titik di mana semua suara yang belum mencapai mayoritas dihapus, memaksa penghitungan suara dimulai kembali. Ini berarti saat menghitung suara, Validator hanya perlu mulai di periode terbaru. Secara default, Voting Epoch terjadi setiap 30.000 blok.

Voting menentukan perubahan status (yaitu kandidat dipilih, validator dipilih keluar), tidak memberikan suara untuk node yang diberikan berarti Validator tidak ingin node mengubah status (voting eksplisit tidak diperlukan untuk mempertahankan status quo).

Block Header Refactor

Untuk mendukung IBFT di Ethereum, sejumlah perubahan harus dilakukan pada header blok. Perubahan tersebut meliputi:

  • penerima: mengidentifikasi node di mana pemungutan suara sedang dilakukan.
  • nonce: menentukan “arah” suara – AUTH atau DROP.
  • mixHash: angka ajaib tetap, mengidentifikasi blok ini sebagai IBFT yang divalidasi.
  • ommersHash: harus berupa hash dari kumpulan kosong, karena tidak ada blok ommer saat beroperasi di bawah IBFT.
  • stempel waktu: minimal harus stempel waktu + interval blok dari blok induk.
  • kesulitan: harus diisi dengan 0x0000000000000001.
  • extraData: berisi data khusus IBFT termasuk Daftar Alamat Validator, ProposerSeal (mengidentifikasi pengusul), CommittingSeals (daftar validator yang melaporkan ‘komit’ pada blok ini).

Karena daftar CommittingSeals untuk setiap validator (berpotensi) berbeda, penting agar blok hash tidak menyertakan informasi ini – yaitu meskipun dua blok memiliki bidang CommittingSeals yang berbeda, mereka mewakili informasi yang sama (yaitu transaksi, dll. Identik).

Kesimpulan

Sebagai penutup, IBFT adalah solusi toleransi kesalahan Bizantium yang menawarkan penyelesaian transaksi langsung yang mengurangi infrastruktur yang dibutuhkan yang diminta PoW.

Meskipun kemungkinan tidak akan pernah digunakan di mainnet Ethereum (dengan sekumpulan aktor yang berpartisipasi yang jauh lebih luas dan tidak diketahui), ia menawarkan manfaat yang substansial ketika digunakan pada rantai pribadi di mana kumpulan validator dipercaya dan bertanggung jawab; ini memberikan solusi ideal untuk rantai dengan irama tetap dan kecepatan pemrosesan transaksi yang dapat diprediksi.

Proses yang dieksplorasi dalam artikel ini memberikan keyakinan bahwa jaringan yang menggunakan IBFT akan toleran terhadap node Bizantium dan dapat dipulihkan jika node tersebut terlihat menggunakan kontrol di jaringan..

Berlangganan buletin kami untuk berita Ethereum terbaru, solusi perusahaan, sumber daya pengembang, dan banyak lagi Alamat emailKonten EksklusifPanduan Lengkap untuk Jaringan Bisnis BlockchainPanduan

Panduan Lengkap untuk Jaringan Bisnis Blockchain

Pengantar TokenisasiWebinar

Pengantar Tokenisasi

Masa Depan Keuangan Aset Digital dan DeFiWebinar

Masa Depan Keuangan: Aset Digital dan DeFi

Apa Itu Enterprise EthereumWebinar

Apa Itu Enterprise Ethereum?

Bank Sentral dan Masa Depan UangKertas putih

Bank Sentral dan Masa Depan Uang

Komgo Blockchain untuk Commodity Trade FinanceStudi Kasus

Komgo: Blockchain untuk Commodity Trade Finance

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
Adblock
detector
map