Sebenarnya, tumpukan @Dusk ini punya dua pembukuan yang terkait tapi berbeda: satu adalah buku eksekusi DuskEVM, yang dipaparkan sebagai Ethereum JSON-RPC; yang lain adalah buku penyelesaian Dusk L1, yang dipaparkan sebagai GraphQL / RUES. DUSK harus terbaca sebagai angka yang sama di kedua buku ini, tetapi jamnya, satuannya, dan jumlah desimalnya tidak sama.
DuskEVM adalah layer eksekusi EVM bergaya OP Stack; ia mengembalikan blok, log, dan receipt dengan bentuk standar EVM. Penyelesaian akhirnya—termasuk ketersediaan data—lalu ditambatkan ke DuskDS melalui batcher, komitmen status, dan juga jangkar bridge. Artinya, ini bukan adaptor “menerjemahkan GraphQL real-time menjadi JSON-RPC”, melainkan dua lapisan yang menjaga konsistensi final lewat bridge dan komitmen status. Yang benar-benar perlu diperhatikan adalah skenario lintas lapisan: inclusion di DuskEVM cepat, tetapi penyelesaian penuh dan konfirmasi bridge masih perlu beberapa langkah lagi; selama itu, status yang terlihat di kedua sisi bisa sementara berbeda.
Peran $DUSK membuat risiko ini jadi lebih konkret. Sisi L1 asli menggunakan LUX untuk merepresentasikan nilai: 1 DUSK sama dengan 10^9 LUX. DuskEVM, untuk kompatibilitas dengan toolchain Ethereum, mengekspos DUSK dengan desimal 18 digit. Saat melakukan bridging, jika konversi atau penanganan presisi dilakukan secara keliru, nilai yang sama bisa terlihat tidak cocok sesaat di dua pembukuan. Untuk transfer biasa, mungkin hanya tampak sebagai selisih tampilan; tetapi untuk settlement yang teregulasi, bisa menjadi jendela kesalahan operasi seperti “satu sisi menampilkan sudah masuk, sementara sisi lain belum dikonfirmasi final”.
Kesimpulan yang saya ambil setelah membaca semuanya adalah: evaluasi #dusk —jangan hanya melihatnya “kompatibel dengan EVM”, tetapi juga lihat jaminan konsistensi antara buku settlement L1 dan buku eksekusi EVM. Materi yang ada saat ini belum menjelaskan prioritas sumber data yang otoritatif, mekanisme deteksi konflik, dan mekanisme perbaikannya secara memadai; dan DUSK adalah angka yang paling tidak boleh salah dibaca di kedua buku itu. DYOR.
DuskEVM adalah layer eksekusi EVM bergaya OP Stack; ia mengembalikan blok, log, dan receipt dengan bentuk standar EVM. Penyelesaian akhirnya—termasuk ketersediaan data—lalu ditambatkan ke DuskDS melalui batcher, komitmen status, dan juga jangkar bridge. Artinya, ini bukan adaptor “menerjemahkan GraphQL real-time menjadi JSON-RPC”, melainkan dua lapisan yang menjaga konsistensi final lewat bridge dan komitmen status. Yang benar-benar perlu diperhatikan adalah skenario lintas lapisan: inclusion di DuskEVM cepat, tetapi penyelesaian penuh dan konfirmasi bridge masih perlu beberapa langkah lagi; selama itu, status yang terlihat di kedua sisi bisa sementara berbeda.
Peran $DUSK membuat risiko ini jadi lebih konkret. Sisi L1 asli menggunakan LUX untuk merepresentasikan nilai: 1 DUSK sama dengan 10^9 LUX. DuskEVM, untuk kompatibilitas dengan toolchain Ethereum, mengekspos DUSK dengan desimal 18 digit. Saat melakukan bridging, jika konversi atau penanganan presisi dilakukan secara keliru, nilai yang sama bisa terlihat tidak cocok sesaat di dua pembukuan. Untuk transfer biasa, mungkin hanya tampak sebagai selisih tampilan; tetapi untuk settlement yang teregulasi, bisa menjadi jendela kesalahan operasi seperti “satu sisi menampilkan sudah masuk, sementara sisi lain belum dikonfirmasi final”.
Kesimpulan yang saya ambil setelah membaca semuanya adalah: evaluasi #dusk —jangan hanya melihatnya “kompatibel dengan EVM”, tetapi juga lihat jaminan konsistensi antara buku settlement L1 dan buku eksekusi EVM. Materi yang ada saat ini belum menjelaskan prioritas sumber data yang otoritatif, mekanisme deteksi konflik, dan mekanisme perbaikannya secara memadai; dan DUSK adalah angka yang paling tidak boleh salah dibaca di kedua buku itu. DYOR.
