Saya dulu mengira batas epoch di Dusk sebagian besar adalah peristiwa penjadwalan: satu epoch berakhir, epoch lain dimulai.
Namun, jika dilihat lebih dekat, saya pikir cara pandang itu mengabaikan kendala sistem yang penting.
Sebuah epoch mengubah keadaan dari mana kelayakan provisioner dinilai, sementara konsensus tetap harus beroperasi dalam jumlah komputasi yang dibatasi. Itu membuat batas tersebut lebih dari sekadar penanda kalender: ini adalah titik di mana status partisipasi dapat berubah tanpa mengizinkan pekerjaan konsensus tumbuh tanpa batas.
Rangkaian rekayasa yang menurut saya menarik adalah:
transisi epoch → keadaan kelayakan berubah → konsensus mengevaluasi keadaan baru → komputasi tetap terbatas.
Itu menciptakan tradeoff yang halus.
Jika perubahan pada stake atau kelayakan diizinkan memengaruhi konsensus secara langsung dan tanpa batas yang jelas, node dapat menghadapi transisi keadaan yang lebih rumit. Jika perubahan dikendalikan oleh kondisi epoch, protokol mendapatkan model keadaan yang lebih rapi, tetapi perubahan partisipasi menjadi kurang instan.
Yang mengejutkan saya adalah segmentasi waktu dan batas komputasi dapat menyelesaikan masalah yang berbeda sekaligus saling menguatkan.
Sebuah epoch menjawab kapan keadaan konsensus bisa berubah.
Proses iterasi yang dibatasi menjawab seberapa banyak pekerjaan yang diizinkan untuk dilakukan oleh konsensus.
Pertanyaan terbukanya adalah: ketika kumpulan provisioner dalam sebuah jaringan berubah semakin cepat, bagaimana panjang epoch harus menyeimbangkan kestabilan keadaan dengan responsivitas?
@Dusk_Foundation $DUSK #dusk
Namun, jika dilihat lebih dekat, saya pikir cara pandang itu mengabaikan kendala sistem yang penting.
Sebuah epoch mengubah keadaan dari mana kelayakan provisioner dinilai, sementara konsensus tetap harus beroperasi dalam jumlah komputasi yang dibatasi. Itu membuat batas tersebut lebih dari sekadar penanda kalender: ini adalah titik di mana status partisipasi dapat berubah tanpa mengizinkan pekerjaan konsensus tumbuh tanpa batas.
Rangkaian rekayasa yang menurut saya menarik adalah:
transisi epoch → keadaan kelayakan berubah → konsensus mengevaluasi keadaan baru → komputasi tetap terbatas.
Itu menciptakan tradeoff yang halus.
Jika perubahan pada stake atau kelayakan diizinkan memengaruhi konsensus secara langsung dan tanpa batas yang jelas, node dapat menghadapi transisi keadaan yang lebih rumit. Jika perubahan dikendalikan oleh kondisi epoch, protokol mendapatkan model keadaan yang lebih rapi, tetapi perubahan partisipasi menjadi kurang instan.
Yang mengejutkan saya adalah segmentasi waktu dan batas komputasi dapat menyelesaikan masalah yang berbeda sekaligus saling menguatkan.
Sebuah epoch menjawab kapan keadaan konsensus bisa berubah.
Proses iterasi yang dibatasi menjawab seberapa banyak pekerjaan yang diizinkan untuk dilakukan oleh konsensus.
Pertanyaan terbukanya adalah: ketika kumpulan provisioner dalam sebuah jaringan berubah semakin cepat, bagaimana panjang epoch harus menyeimbangkan kestabilan keadaan dengan responsivitas?
@Dusk_Foundation $DUSK #dusk