#dusk $DUSK
Hari ini saya lanjut menonton pembaruan Boreas @Dusk . Yang paling membuat saya khawatir bukan Phoenix pensiun, juga bukan karena ada beberapa fork rule lagi.
Namun, ini masalah yang lebih mendasar:
Setelah upgrade protokol, mengapa transaksi lama—yang sudah pernah terjadi—masih bisa terus mempertahankan makna yang sama?
Kedengarannya seperti omong kosong.
Tapi setelah hard fork, node sudah menjalankan aturan baru, sementara di dalam blok-blok historis masih tersimpan transaction versi lama, verifier lama, dan execution semantics versi lama.
Kalau hari ini node memakai seperangkat aturan yang ada sekarang untuk menginterpretasikan bytes dari masa lalu, maka replay historis bisa jadi bermasalah.
Jadi, pada kesempatan ini Boreas membuat batas versi untuk penanganan transaksi menjadi lebih jelas.
Live ingress mengikuti aturan protokol saat ini.
Envelope lama bisa dikenali dan di-normalize di pintu masuk.
Sebelum masuk ke ledger, barulah diubah menjadi canonical transaction.
Sedangkan blok historis, tetap didecode dan direplay mengikuti aturan pada saat itu.
Saya rasa yang benar-benar penting di sini bukan soal “penyeragaman format”.
Tapi:
Transaksi tidak hanya punya isi, melainkan juga punya era protokol tempat ia berasal.
Aegis memiliki aturan-aturan versi Aegis.
Boreas memiliki aturan-aturan versi Boreas.
Hard fork boleh mengubah masa depan, tapi tidak bisa sekalian mengartikan ulang masa lalu.
Itulah sebabnya saat ini saya melihat upgrade chain, saya tidak terlalu hanya fokus pada “apa yang ditambahkan”.
Yang lebih saya pedulikan adalah:
Setelah versi baru diluncurkan, apakah node saat ini masih bisa memahami dengan akurat apa yang sebenarnya terjadi di rantai beberapa tahun lalu.
Untuk jaringan yang akan membangun regulated market infrastructure, kesinambungan historis seperti ini sebenarnya sangat dasar.
Akun boleh di-upgrade.
Tapi masa lalu di dalam akun tidak boleh ikut di-upgrade.
Hari ini saya lanjut menonton pembaruan Boreas @Dusk . Yang paling membuat saya khawatir bukan Phoenix pensiun, juga bukan karena ada beberapa fork rule lagi.
Namun, ini masalah yang lebih mendasar:
Setelah upgrade protokol, mengapa transaksi lama—yang sudah pernah terjadi—masih bisa terus mempertahankan makna yang sama?
Kedengarannya seperti omong kosong.
Tapi setelah hard fork, node sudah menjalankan aturan baru, sementara di dalam blok-blok historis masih tersimpan transaction versi lama, verifier lama, dan execution semantics versi lama.
Kalau hari ini node memakai seperangkat aturan yang ada sekarang untuk menginterpretasikan bytes dari masa lalu, maka replay historis bisa jadi bermasalah.
Jadi, pada kesempatan ini Boreas membuat batas versi untuk penanganan transaksi menjadi lebih jelas.
Live ingress mengikuti aturan protokol saat ini.
Envelope lama bisa dikenali dan di-normalize di pintu masuk.
Sebelum masuk ke ledger, barulah diubah menjadi canonical transaction.
Sedangkan blok historis, tetap didecode dan direplay mengikuti aturan pada saat itu.
Saya rasa yang benar-benar penting di sini bukan soal “penyeragaman format”.
Tapi:
Transaksi tidak hanya punya isi, melainkan juga punya era protokol tempat ia berasal.
Aegis memiliki aturan-aturan versi Aegis.
Boreas memiliki aturan-aturan versi Boreas.
Hard fork boleh mengubah masa depan, tapi tidak bisa sekalian mengartikan ulang masa lalu.
Itulah sebabnya saat ini saya melihat upgrade chain, saya tidak terlalu hanya fokus pada “apa yang ditambahkan”.
Yang lebih saya pedulikan adalah:
Setelah versi baru diluncurkan, apakah node saat ini masih bisa memahami dengan akurat apa yang sebenarnya terjadi di rantai beberapa tahun lalu.
Untuk jaringan yang akan membangun regulated market infrastructure, kesinambungan historis seperti ini sebenarnya sangat dasar.
Akun boleh di-upgrade.
Tapi masa lalu di dalam akun tidak boleh ikut di-upgrade.