Satu hal membuatku berhenti menggulir. Bukan bug itu sendiri. Melainkan kalimat yang mengatakan bahwa jendela race hanya ada di antara pembacaan database dan penulisan database. Itu terlihat seperti detail implementasi kecil sampai aku mulai memikirkan apa yang dikatakannya tentang model eksekusi Babylon.
Aku berhenti mencari penyerang dan mulai mencari alurnya. Aku kembali untuk membandingkan jalur validasi dan menghabiskan waktu melacak di mana perubahan state benar-benar menjadi final. Lalu aku mengambil kopi dan membaca ulang urutannya lagi. Semakin lama aku melihatnya, semakin terasa bahwa ini bukan semata masalah keamanan. Ini terasa seperti pilihan desain tentang seberapa banyak risiko timing yang bersedia ditoleransi oleh protokol.
Yang perlahan menjadi jelas adalah bahwa perlindungannya tidak dibangun untuk membuat race itu mustahil. Perlindungannya dibangun untuk membuat peluangnya sangat kecil. Dua gagasan itu berbeda. Yang pertama menghilangkan kondisinya. Yang kedua mengurangi probabilitasnya. Perbedaan itu mudah terlewat karena keduanya bisa terlihat aman dari luar.
Bagian itulah yang tidak pernah dimasukkan ke slide. Babylon bergantung pada validator dan layanan yang memproses state dalam urutan yang dapat diprediksi sambil menerima bahwa masih ada celah eksekusi yang sangat kecil. Secara efektif, protokol ini mengatakan bahwa biaya operasional untuk menghilangkan setiap kemungkinan race lebih besar daripada risiko sisa karena membiarkan satu jendela sempit.
Mungkin itu tradeoff yang tepat untuk performa. Mungkin eksposur yang tersisa sedemikian kecil sehingga menambahkan sinkronisasi tambahan justru akan menimbulkan masalah yang lebih besar di tempat lain.
Yang masih belum bisa kupastikan adalah di mana Babylon menarik garis antara asumsi timing yang masih dapat diterima dan jaminan protokol yang seharusnya sama sekali tidak bergantung pada timing.
@BabylonLabs_io
#baby $BABY
Aku berhenti mencari penyerang dan mulai mencari alurnya. Aku kembali untuk membandingkan jalur validasi dan menghabiskan waktu melacak di mana perubahan state benar-benar menjadi final. Lalu aku mengambil kopi dan membaca ulang urutannya lagi. Semakin lama aku melihatnya, semakin terasa bahwa ini bukan semata masalah keamanan. Ini terasa seperti pilihan desain tentang seberapa banyak risiko timing yang bersedia ditoleransi oleh protokol.
Yang perlahan menjadi jelas adalah bahwa perlindungannya tidak dibangun untuk membuat race itu mustahil. Perlindungannya dibangun untuk membuat peluangnya sangat kecil. Dua gagasan itu berbeda. Yang pertama menghilangkan kondisinya. Yang kedua mengurangi probabilitasnya. Perbedaan itu mudah terlewat karena keduanya bisa terlihat aman dari luar.
Bagian itulah yang tidak pernah dimasukkan ke slide. Babylon bergantung pada validator dan layanan yang memproses state dalam urutan yang dapat diprediksi sambil menerima bahwa masih ada celah eksekusi yang sangat kecil. Secara efektif, protokol ini mengatakan bahwa biaya operasional untuk menghilangkan setiap kemungkinan race lebih besar daripada risiko sisa karena membiarkan satu jendela sempit.
Mungkin itu tradeoff yang tepat untuk performa. Mungkin eksposur yang tersisa sedemikian kecil sehingga menambahkan sinkronisasi tambahan justru akan menimbulkan masalah yang lebih besar di tempat lain.
Yang masih belum bisa kupastikan adalah di mana Babylon menarik garis antara asumsi timing yang masih dapat diterima dan jaminan protokol yang seharusnya sama sekali tidak bergantung pada timing.
@BabylonLabs_io
#baby $BABY