#dusk $DUSK
Angka 2/3 dan 1/2 terus muncul di bagian-bagian berbeda dari dokumentasi konsensus, dan saya terus memperlakukan keduanya sebagai ambang yang sama dengan notasi yang berbeda. Padahal tidak. Itu dua aturan kuorum yang berbeda untuk dua hasil yang berbeda.
Ambang persetujuan blok: ≥2/3 dari kredit komite harus memilih Valid. Itu supermajority. Untuk komite 64 kredit, berarti minimal 43 kredit perlu sepakat bahwa blok tersebut benar sebelum dapat diterima.
Ambang penolakan blok: >1/2 dari kredit komite — lebih dari setengah, plus satu — harus memilih Invalid, NoCandidate, atau NoQuorum. Itu simple majority. Untuk 64 kredit, itu berarti setidaknya 33.
Komite yang sama. Standar yang berbeda. Mencapai persetujuan lebih sulit daripada memicu kegagalan.
Jadi mengapa ambang penolakan tidak juga memerlukan 2/3.
Asimetri ini disengaja. Alasan desainnya adalah: menyetujui sebuah blok membutuhkan tingkat keyakinan yang tinggi — Anda tidak ingin sebuah blok diterima kecuali mayoritas kuat menyetujuinya sebagai benar. Tetapi menutup iterasi yang gagal tidak membawa risiko yang sama. Jika pembangkit blok sedang offline, atau mengirim sesuatu yang tidak valid, Anda ingin jaringan bergerak cepat daripada menunggu ambang yang lebih tinggi untuk mengonfirmasi kegagalannya. Ambang penolakan yang lebih rendah membuat jaringan gagal lebih cepat dan mencoba lagi lebih cepat.
Saya justru merasa asimetri ambang ini lebih menarik dari sudut pandang keamanan daripada kecepatan. Ambang persetujuan yang lebih sulit membuat penyerang harus mengeluarkan biaya jauh lebih besar agar blok berbahaya diterima dibandingkan biaya bagi validator yang jujur untuk menolak yang buruk.
Yang belum saya lihat dijelaskan adalah bagaimana pembobotan komite berinteraksi dengan ambang-ambang ini — apakah satu penyedia (provisioner) yang memegang 20 dari 64 kredit dapat secara berarti menghambat persetujuan atau mempercepat penolakan sendirian, atau apakah distribusi kredit di dalam komite membuat konsentrasi seperti itu secara praktis tidak mungkin. @Dusk
$DUSK #dusk
Angka 2/3 dan 1/2 terus muncul di bagian-bagian berbeda dari dokumentasi konsensus, dan saya terus memperlakukan keduanya sebagai ambang yang sama dengan notasi yang berbeda. Padahal tidak. Itu dua aturan kuorum yang berbeda untuk dua hasil yang berbeda.
Ambang persetujuan blok: ≥2/3 dari kredit komite harus memilih Valid. Itu supermajority. Untuk komite 64 kredit, berarti minimal 43 kredit perlu sepakat bahwa blok tersebut benar sebelum dapat diterima.
Ambang penolakan blok: >1/2 dari kredit komite — lebih dari setengah, plus satu — harus memilih Invalid, NoCandidate, atau NoQuorum. Itu simple majority. Untuk 64 kredit, itu berarti setidaknya 33.
Komite yang sama. Standar yang berbeda. Mencapai persetujuan lebih sulit daripada memicu kegagalan.
Jadi mengapa ambang penolakan tidak juga memerlukan 2/3.
Asimetri ini disengaja. Alasan desainnya adalah: menyetujui sebuah blok membutuhkan tingkat keyakinan yang tinggi — Anda tidak ingin sebuah blok diterima kecuali mayoritas kuat menyetujuinya sebagai benar. Tetapi menutup iterasi yang gagal tidak membawa risiko yang sama. Jika pembangkit blok sedang offline, atau mengirim sesuatu yang tidak valid, Anda ingin jaringan bergerak cepat daripada menunggu ambang yang lebih tinggi untuk mengonfirmasi kegagalannya. Ambang penolakan yang lebih rendah membuat jaringan gagal lebih cepat dan mencoba lagi lebih cepat.
Saya justru merasa asimetri ambang ini lebih menarik dari sudut pandang keamanan daripada kecepatan. Ambang persetujuan yang lebih sulit membuat penyerang harus mengeluarkan biaya jauh lebih besar agar blok berbahaya diterima dibandingkan biaya bagi validator yang jujur untuk menolak yang buruk.
Yang belum saya lihat dijelaskan adalah bagaimana pembobotan komite berinteraksi dengan ambang-ambang ini — apakah satu penyedia (provisioner) yang memegang 20 dari 64 kredit dapat secara berarti menghambat persetujuan atau mempercepat penolakan sendirian, atau apakah distribusi kredit di dalam komite membuat konsentrasi seperti itu secara praktis tidak mungkin. @Dusk
$DUSK #dusk
