Saya menemukan ada perubahan teknis yang digabung ke cabang utama PLONK di Dusk. Perubahannya adalah pada alur deserialisasi file rangkaian (circuit) terkompresi: setelah bagian isi (body) diparsing, jika masih ada byte sisa, compile_with_compressed akan mengembalikan InvalidCompressedCircuit. Pengujian regresi resmi menambahkan secara khusus sebuah nilai ekor (tail) MessagePack yang valid untuk memastikan sebelum perbaikan diterima, dan setelah perbaikan ditolak.
Untuk rangkaian terkompresi yang sama, isi (body) persis identik; yang berubah hanya satu byte tidak relevan yang disisipkan di bagian akhir. Sistem pengendalian risiko atau cache yang menghitung hash berdasarkan byte asli akan menganggapnya sebagai file yang berbeda; PLONK versi lama mungkin tetap dapat membacanya seperti biasa.
Melihat ini, saya sebenarnya agak khawatir. File jelas sudah berubah, tetapi alatnya bilang “tidak berubah”. Untuk sistem keuangan, ini lebih merepotkan daripada sekadar gagal error: satu objek bisa memiliki dua kartu identitas.
Pertama, saya perjelas objeknya. Kali ini yang diubah adalah file rangkaian terkompresi yang digunakan untuk menghasilkan bukti (proof). Bukti yang sudah dihasilkan di chain tidak termasuk dalam ruang lingkup ini. Penanganan terbaru yang digabung oleh Dusk sangat tegas: setelah isi rangkaian dibaca, jika masih ada byte berlebih di bagian setelahnya, seluruh file langsung dianggap tidak valid.
Jujur, awalnya saya agak merasa itu terlalu “kaku”. Kalau alat lama bisa berjalan, kenapa harus memotong kompatibilitas hanya demi beberapa byte ekor? Tapi ketika masuk ke sistem transaksi, pemikirannya berubah. Jika file aslinya diaudit, dicache, atau dikenali oleh version library berdasarkan byte, sementara kompiler justru memperlakukan dua file berbeda sebagai aturan yang sama, maka ketika terjadi masalah akan sulit menjelaskan versi mana yang benar-benar dipakai.
Ini memberi saya sebuah patokan yang cukup berguna: setelah upgrade, jika beberapa aplikasi ZK tiba-tiba gagal, pertama cek InvalidCompressedCircuit, versi alat, dan apakah kegagalan bisa dipulihkan setelah re-eksport file. Jika file lama gagal dan file baru normal, itu lebih mirip migrasi format; jika file yang sesuai standar gagal secara luas, barulah perlu menggali lebih dalam ke logika proof atau gangguan jaringan. Jangan campur dua jenis risiko dalam satu baris.
Untuk $DUSK , pengencangan ini dalam jangka pendek mungkin mengurangi jumlah pemanggilan yang berhasil, bahkan membuat alat lama berhenti sementara. Nilai jangka panjangnya bergantung pada apakah setelah migrasi hilir, biaya untuk membenahi kegagalan proof, perselisihan versi, dan re-check oleh institusi benar-benar menurun. Parser tidak langsung menciptakan “bidding”. Yang bisa dilakukannya adalah membuat setiap rangkaian hanya diakui oleh satu kartu identitas.
Dalam transaksi, saya tidak menganggap “sebisa mungkin bisa dibaca” sebagai sesuatu yang ramah. Saya justru berpikir, buku besar keuangan membutuhkan keunikan yang sah. DYOR!
#dusk $DUSK @Dusk
Untuk rangkaian terkompresi yang sama, isi (body) persis identik; yang berubah hanya satu byte tidak relevan yang disisipkan di bagian akhir. Sistem pengendalian risiko atau cache yang menghitung hash berdasarkan byte asli akan menganggapnya sebagai file yang berbeda; PLONK versi lama mungkin tetap dapat membacanya seperti biasa.
Melihat ini, saya sebenarnya agak khawatir. File jelas sudah berubah, tetapi alatnya bilang “tidak berubah”. Untuk sistem keuangan, ini lebih merepotkan daripada sekadar gagal error: satu objek bisa memiliki dua kartu identitas.
Pertama, saya perjelas objeknya. Kali ini yang diubah adalah file rangkaian terkompresi yang digunakan untuk menghasilkan bukti (proof). Bukti yang sudah dihasilkan di chain tidak termasuk dalam ruang lingkup ini. Penanganan terbaru yang digabung oleh Dusk sangat tegas: setelah isi rangkaian dibaca, jika masih ada byte berlebih di bagian setelahnya, seluruh file langsung dianggap tidak valid.
Jujur, awalnya saya agak merasa itu terlalu “kaku”. Kalau alat lama bisa berjalan, kenapa harus memotong kompatibilitas hanya demi beberapa byte ekor? Tapi ketika masuk ke sistem transaksi, pemikirannya berubah. Jika file aslinya diaudit, dicache, atau dikenali oleh version library berdasarkan byte, sementara kompiler justru memperlakukan dua file berbeda sebagai aturan yang sama, maka ketika terjadi masalah akan sulit menjelaskan versi mana yang benar-benar dipakai.
Ini memberi saya sebuah patokan yang cukup berguna: setelah upgrade, jika beberapa aplikasi ZK tiba-tiba gagal, pertama cek InvalidCompressedCircuit, versi alat, dan apakah kegagalan bisa dipulihkan setelah re-eksport file. Jika file lama gagal dan file baru normal, itu lebih mirip migrasi format; jika file yang sesuai standar gagal secara luas, barulah perlu menggali lebih dalam ke logika proof atau gangguan jaringan. Jangan campur dua jenis risiko dalam satu baris.
Untuk $DUSK , pengencangan ini dalam jangka pendek mungkin mengurangi jumlah pemanggilan yang berhasil, bahkan membuat alat lama berhenti sementara. Nilai jangka panjangnya bergantung pada apakah setelah migrasi hilir, biaya untuk membenahi kegagalan proof, perselisihan versi, dan re-check oleh institusi benar-benar menurun. Parser tidak langsung menciptakan “bidding”. Yang bisa dilakukannya adalah membuat setiap rangkaian hanya diakui oleh satu kartu identitas.
Dalam transaksi, saya tidak menganggap “sebisa mungkin bisa dibaca” sebagai sesuatu yang ramah. Saya justru berpikir, buku besar keuangan membutuhkan keunikan yang sah. DYOR!
#dusk $DUSK @Dusk