Detail Senja yang terus saya rujuk adalah: sebuah blok bisa memiliki attestation sukses dan tetap tidak menjadi final.
Bacaan pertama saya tentang Succinct Attestation terasa lebih sederhana.
proposal mendarat.
validasi mencapai supermajority dari suara Valid.
ratifikasi mengonfirmasi.
tanda tangan agregat BLS membuktikan kuorum.
done, kan?
belum.
Bagian rolling finality milik Dusk membagi sebuah blok menjadi accepted, attested, confirmed, dan final.
jika sebuah blok diproduksi pada iterasi I > 0 sementara iterasi sebelumnya masih belum memiliki fail attestation, ia dapat membawa success attestation dan hanya ditandai sebagai accepted.
karena “komite mencapai kuorum” terdengar sangat dekat dengan “blok ini tidak mungkin hilang.”
di Dusk, klaim-klaim itu berbeda.
iterasi sebelumnya yang masih belum terpecahkan tetap penting. jika sebuah blok beriterasi lebih rendah kemudian mencapai konsensus, fallback dapat mengganti blok yang accepted dan membuang penerusnya.
dengan demikian, success attestation membuktikan bahwa kesepakatan telah terjadi.
namun itu tidak selalu membuktikan bahwa rantai sudah selesai memilih.
sebuah blok yang sudah attested mendarat pada iterasi 0 atau memiliki fail attestations yang mencakup setiap iterasi sebelumnya, sehingga tidak ada blok beriterasi lebih rendah yang dapat menggantinya secara langsung. confirmed bergantung pada blok-blok setelahnya. final datang hanya ketika blok itu sudah confirmed dan induknya sudah final.
itulah yang membuat “finality dalam hitungan detik” terasa kurang seperti satu peristiwa dan lebih seperti sebuah batas yang harus dibaca dengan benar oleh sebuah aplikasi.
aplikasi di Dusk tidak hanya bertanya apakah konsensus menandatangani sesuatu.
melepas jaminan?
mengakui pemindahan keamanan?
biarkan kontrak lain menganggap status sebagai tidak dapat diubah?
hal-hal itu mungkin tidak layak mendapat ambang yang sama.
kebanyakan waktu ini mungkin bergerak cepat. baik.
titik khusus yang menarik bagi saya adalah: sebuah blok tampak sukses, sebuah aplikasi merespons, dan iterasi yang lebih rendah masih hidup.
Dusk tidak menyembunyikan celah itu. ia menamakannya.
accepted tidak final.
dan setelah saya menyadari itu, pertanyaan integrasi saya berubah.
bukan “apakah konsensus berhasil?”
seberapa tidak dapat diubah aplikasi ini perlu Dusk menjadi sebelum ia bertindak?
@Dusk_Foundation $DUSK #Dusk $ACE $APR
Bacaan pertama saya tentang Succinct Attestation terasa lebih sederhana.
proposal mendarat.
validasi mencapai supermajority dari suara Valid.
ratifikasi mengonfirmasi.
tanda tangan agregat BLS membuktikan kuorum.
done, kan?
belum.
Bagian rolling finality milik Dusk membagi sebuah blok menjadi accepted, attested, confirmed, dan final.
jika sebuah blok diproduksi pada iterasi I > 0 sementara iterasi sebelumnya masih belum memiliki fail attestation, ia dapat membawa success attestation dan hanya ditandai sebagai accepted.
karena “komite mencapai kuorum” terdengar sangat dekat dengan “blok ini tidak mungkin hilang.”
di Dusk, klaim-klaim itu berbeda.
iterasi sebelumnya yang masih belum terpecahkan tetap penting. jika sebuah blok beriterasi lebih rendah kemudian mencapai konsensus, fallback dapat mengganti blok yang accepted dan membuang penerusnya.
dengan demikian, success attestation membuktikan bahwa kesepakatan telah terjadi.
namun itu tidak selalu membuktikan bahwa rantai sudah selesai memilih.
sebuah blok yang sudah attested mendarat pada iterasi 0 atau memiliki fail attestations yang mencakup setiap iterasi sebelumnya, sehingga tidak ada blok beriterasi lebih rendah yang dapat menggantinya secara langsung. confirmed bergantung pada blok-blok setelahnya. final datang hanya ketika blok itu sudah confirmed dan induknya sudah final.
itulah yang membuat “finality dalam hitungan detik” terasa kurang seperti satu peristiwa dan lebih seperti sebuah batas yang harus dibaca dengan benar oleh sebuah aplikasi.
aplikasi di Dusk tidak hanya bertanya apakah konsensus menandatangani sesuatu.
melepas jaminan?
mengakui pemindahan keamanan?
biarkan kontrak lain menganggap status sebagai tidak dapat diubah?
hal-hal itu mungkin tidak layak mendapat ambang yang sama.
kebanyakan waktu ini mungkin bergerak cepat. baik.
titik khusus yang menarik bagi saya adalah: sebuah blok tampak sukses, sebuah aplikasi merespons, dan iterasi yang lebih rendah masih hidup.
Dusk tidak menyembunyikan celah itu. ia menamakannya.
accepted tidak final.
dan setelah saya menyadari itu, pertanyaan integrasi saya berubah.
bukan “apakah konsensus berhasil?”
seberapa tidak dapat diubah aplikasi ini perlu Dusk menjadi sebelum ia bertindak?
@Dusk_Foundation $DUSK #Dusk $ACE $APR
SELECTIVE DISCLOSURE
0%
DUSKVM
0%
DUSK'S MOONLIGHT
100%
DUSK'S PHOENIX
0%
1 Voting • Voting ditutup