Hal paling sering diabaikan dari jembatan lintas-rantai adalah ketidaksimetrian arah: deposit bisa sangat cepat, tetapi penarikan harus melalui pembuktian dan tantangan. DuskEVM berbasis OP Stack, dan resmi @Dusk menuliskan siklus penarikan menjadi: inisiasi, output menjadi tersedia, persiapan bukti, masuk periode tantangan, persiapan finalize, hingga selesai secara akhir. Artinya, ini bukan “klik sekali lalu langsung kembali”.
Dalam model OP standar, periode tantangan klasik Optimism adalah 7 hari, digunakan agar penantang dapat membuktikan bahwa suatu root output atau komitmen status itu salah. $DUSK karena anchor penyelesaian ada di DuskDS, materi promosi menyebutkan bahwa jendela ini bisa dihilangkan atau dipersingkat secara signifikan, tetapi data publik tidak memberikan angka periode tantangan yang tetap dan bisa dicek semua orang seperti pada Optimism. Sebaliknya, pengguna diminta mengikuti status dompet, jangan menilai kesiapan hanya berdasarkan “sudah berapa lama”. Desain “melihat status” ini mungkin lebih akurat bagi protokol, namun bagi pengguna dan institusi justru lebih sulit membentuk ekspektasi.
Yang benar-benar membuat saya waspada adalah asumsi kepercayaan. Jika kontrak jembatan memiliki celah, atau seseorang mengajukan bukti yang salah, kerugian ditanggung oleh siapa? Materi tidak menjelaskan dengan jelas tentang dana asuransi, kepemilikan jembatan, dan hak upgrade. Keamanan jembatan model OP bergantung pada premis bahwa “ada orang yang bisa menantang dalam jendela tersebut”; jika tidak ada yang mengawasi, kesalahan bisa saja akhirnya dikonfirmasi. #dusk juga menunjukkan bahwa sebelumnya pernah ada risiko operasional terkait jembatan, yang semakin menegaskan bahwa pengelolaan operasional dan manajemen izin pada jembatan itu sendiri adalah titik risiko.
Karena itu, pengembang perlu memisahkan “tiba” di DuskEVM dengan “penyelesaian sesungguhnya” di Dusk L1. Saat pengguna melakukan aset lintas rantai, terutama pastikan apakah jembatan Dusk memberikan periode tantangan yang jelas, atau hanya “tergantung kondisi”. Jika jawabannya adalah yang terakhir, maka jembatan ini belum menjadi infrastruktur dasar yang bisa digunakan dengan mata tertutup.
Dalam model OP standar, periode tantangan klasik Optimism adalah 7 hari, digunakan agar penantang dapat membuktikan bahwa suatu root output atau komitmen status itu salah. $DUSK karena anchor penyelesaian ada di DuskDS, materi promosi menyebutkan bahwa jendela ini bisa dihilangkan atau dipersingkat secara signifikan, tetapi data publik tidak memberikan angka periode tantangan yang tetap dan bisa dicek semua orang seperti pada Optimism. Sebaliknya, pengguna diminta mengikuti status dompet, jangan menilai kesiapan hanya berdasarkan “sudah berapa lama”. Desain “melihat status” ini mungkin lebih akurat bagi protokol, namun bagi pengguna dan institusi justru lebih sulit membentuk ekspektasi.
Yang benar-benar membuat saya waspada adalah asumsi kepercayaan. Jika kontrak jembatan memiliki celah, atau seseorang mengajukan bukti yang salah, kerugian ditanggung oleh siapa? Materi tidak menjelaskan dengan jelas tentang dana asuransi, kepemilikan jembatan, dan hak upgrade. Keamanan jembatan model OP bergantung pada premis bahwa “ada orang yang bisa menantang dalam jendela tersebut”; jika tidak ada yang mengawasi, kesalahan bisa saja akhirnya dikonfirmasi. #dusk juga menunjukkan bahwa sebelumnya pernah ada risiko operasional terkait jembatan, yang semakin menegaskan bahwa pengelolaan operasional dan manajemen izin pada jembatan itu sendiri adalah titik risiko.
Karena itu, pengembang perlu memisahkan “tiba” di DuskEVM dengan “penyelesaian sesungguhnya” di Dusk L1. Saat pengguna melakukan aset lintas rantai, terutama pastikan apakah jembatan Dusk memberikan periode tantangan yang jelas, atau hanya “tergantung kondisi”. Jika jawabannya adalah yang terakhir, maka jembatan ini belum menjadi infrastruktur dasar yang bisa digunakan dengan mata tertutup.
