Saya sedang menelusuri pekerjaan teknik terbaru Dusk dan mengharapkan bagian yang menariknya adalah peningkatan lain pada sistem pembuktian.
Namun yang saya dapat justru tersangkut pada hal yang jauh kurang menarik:
bagaimana sistem menangani data prover yang buruk sebelum masuk lebih dalam ke pipeline..
Perubahan terbaru terkait Plonk berfokus pada penolakan data prover yang cacat sejak lebih awal.
Di permukaan itu terdengar seperti rekayasa yang rutin.
Tapi ada perbedaan penting di sini.
Bukti kriptografis bisa saja secara matematis benar, sementara data yang membawanya atau yang mengelilinginya malah cacat karena serialisasi yang salah, atau berada di luar apa yang diharapkan oleh implementasi.
Jika data tersebut terlanjur terlalu jauh masuk ke pipeline pembuktian, kegagalannya menjadi lebih sulit untuk diisolasi dan berpotensi lebih mahal untuk ditangani.
Jadi peningkatannya tidak selalu tentang membuat kriptografinya menjadi lebih kuat.
Intinya adalah membuat sistem menjadi kurang mau mempercayai masukan secara membabi buta.
Ini jauh lebih penting begitu sebuah sistem pembuktian dijalankan sebagai infrastruktur produksi, bukan sekadar menunjukkan bahwa matematika yang mendasarinya bekerja.
Sistem nyata harus menangani decoding serialisasi, penanganan memori, jalur eksekusi, dan masukan yang tidak terduga.
Matematikanya bisa benar, tetapi perangkat lunak di sekitarnya tetap bisa memiliki asumsi yang lemah.
Itulah mengapa perubahan rekayasa yang lebih kecil seperti ini menarik perhatian saya.
Pengumuman fitur menunjukkan apa yang ingin dibangun oleh sebuah protokol…
Perubahan seperti ini menunjukkan apa yang dipelajari tim tentang apa yang sebenarnya bisa salah.
Bagi Dusk, mendorong data yang tidak valid untuk keluar lebih awal terasa seperti perubahan kecil dengan implikasi yang jauh lebih besar:
infrastruktur ZK kelas produksi bukan hanya tentang membuktikan hal yang valid dengan benar.
Tapi juga tentang membuat hal-hal yang tidak valid gagal secara aman, dapat diprediksi, dan sedini mungkin.
#dusk @Dusk $DUSK
$TUT
$UAI
Namun yang saya dapat justru tersangkut pada hal yang jauh kurang menarik:
bagaimana sistem menangani data prover yang buruk sebelum masuk lebih dalam ke pipeline..
Perubahan terbaru terkait Plonk berfokus pada penolakan data prover yang cacat sejak lebih awal.
Di permukaan itu terdengar seperti rekayasa yang rutin.
Tapi ada perbedaan penting di sini.
Bukti kriptografis bisa saja secara matematis benar, sementara data yang membawanya atau yang mengelilinginya malah cacat karena serialisasi yang salah, atau berada di luar apa yang diharapkan oleh implementasi.
Jika data tersebut terlanjur terlalu jauh masuk ke pipeline pembuktian, kegagalannya menjadi lebih sulit untuk diisolasi dan berpotensi lebih mahal untuk ditangani.
Jadi peningkatannya tidak selalu tentang membuat kriptografinya menjadi lebih kuat.
Intinya adalah membuat sistem menjadi kurang mau mempercayai masukan secara membabi buta.
Ini jauh lebih penting begitu sebuah sistem pembuktian dijalankan sebagai infrastruktur produksi, bukan sekadar menunjukkan bahwa matematika yang mendasarinya bekerja.
Sistem nyata harus menangani decoding serialisasi, penanganan memori, jalur eksekusi, dan masukan yang tidak terduga.
Matematikanya bisa benar, tetapi perangkat lunak di sekitarnya tetap bisa memiliki asumsi yang lemah.
Itulah mengapa perubahan rekayasa yang lebih kecil seperti ini menarik perhatian saya.
Pengumuman fitur menunjukkan apa yang ingin dibangun oleh sebuah protokol…
Perubahan seperti ini menunjukkan apa yang dipelajari tim tentang apa yang sebenarnya bisa salah.
Bagi Dusk, mendorong data yang tidak valid untuk keluar lebih awal terasa seperti perubahan kecil dengan implikasi yang jauh lebih besar:
infrastruktur ZK kelas produksi bukan hanya tentang membuktikan hal yang valid dengan benar.
Tapi juga tentang membuat hal-hal yang tidak valid gagal secara aman, dapat diprediksi, dan sedini mungkin.
#dusk @Dusk $DUSK
$TUT
$UAI