Dusk sedang meluncurkan lapisan yang kompatibel dengan EVM
di samping chain natifnya, dan alasan yang dikemukakan
cukup sederhana:
menurunkan hambatan bagi developer, memungkinkan perangkat
Solidity yang sudah ada digunakan, alih-alih meminta setiap builder
mempelajari stack baru dari awal.
Sekilas, ini langkah yang jelas — EVM
paling dikenal oleh kalangan developer di dunia kripto,
dan menolak menyesuaikan diri dengan mereka adalah cara agar L1 yang menjanjikan tetap menjadi ceruk selamanya.
Hal yang terus saya pikirkan adalah pertanyaan yang lebih spesifik:
apakah lapisan yang kompatibel dengan EVM mewarisi jaminan privasi Dusk yang sesungguhnya,
atau justru mewarisi transparansi bawaan EVM dan hanya berada di samping lapisan privasi Dusk tanpa terhubung dengannya?
Keduanya bukan hal yang sama, dan perbedaan ini
jauh lebih penting di sini daripada bagi kebanyakan L1
yang menambahkan kompatibilitas EVM, karena privasi dan pengungkapan yang mempertimbangkan kepatuhan adalah alasan utama Dusk ada.
Jika kontrak yang diterapkan di lapisan EVM berperilaku
seperti kontrak EVM lainnya — state publik, calldata
publik, model transparansi standar — maka "Dusk mendukung EVM" dan "model privasi Dusk berlaku juga untuk EVM" adalah dua klaim yang berbeda, dan biasanya hanya materi pemasaran yang menyatukan keduanya.
Penjelasan jujur tentang kompromi ini adalah bahwa kompatibilitas EVM dan komputasi rahasia natif secara struktural agak bertentangan.
Model eksekusi EVM tidak dirancang dengan mempertimbangkan pengungkapan selektif;
proposisi nilai inti Dusk justru dibangun secara khusus berdasarkan hal itu.
Menjembatani keduanya dengan baik — memungkinkan penggunaan
perangkat yang sudah dikenal sambil tetap mendapatkan transaksi
rahasia dan smart contract yang mempertimbangkan kepatuhan — benar-benar merupakan masalah integrasi yang sulit, bukan sekadar mencentang kotak.
Mungkin saja Dusk telah mengatasinya dengan elegan.
Namun, bisa juga "kompatibel dengan EVM" secara tersirat berarti "kompatibel dengan EVM untuk bagian chain yang transparan,"
sementara kontrak yang benar-benar menjaga privasi tetap memerlukan stack natif, XSC, dan kurva pembelajaran yang seharusnya dihilangkan oleh kompatibilitas EVM.
@Dusk #dusk $DUSK
di samping chain natifnya, dan alasan yang dikemukakan
cukup sederhana:
menurunkan hambatan bagi developer, memungkinkan perangkat
Solidity yang sudah ada digunakan, alih-alih meminta setiap builder
mempelajari stack baru dari awal.
Sekilas, ini langkah yang jelas — EVM
paling dikenal oleh kalangan developer di dunia kripto,
dan menolak menyesuaikan diri dengan mereka adalah cara agar L1 yang menjanjikan tetap menjadi ceruk selamanya.
Hal yang terus saya pikirkan adalah pertanyaan yang lebih spesifik:
apakah lapisan yang kompatibel dengan EVM mewarisi jaminan privasi Dusk yang sesungguhnya,
atau justru mewarisi transparansi bawaan EVM dan hanya berada di samping lapisan privasi Dusk tanpa terhubung dengannya?
Keduanya bukan hal yang sama, dan perbedaan ini
jauh lebih penting di sini daripada bagi kebanyakan L1
yang menambahkan kompatibilitas EVM, karena privasi dan pengungkapan yang mempertimbangkan kepatuhan adalah alasan utama Dusk ada.
Jika kontrak yang diterapkan di lapisan EVM berperilaku
seperti kontrak EVM lainnya — state publik, calldata
publik, model transparansi standar — maka "Dusk mendukung EVM" dan "model privasi Dusk berlaku juga untuk EVM" adalah dua klaim yang berbeda, dan biasanya hanya materi pemasaran yang menyatukan keduanya.
Penjelasan jujur tentang kompromi ini adalah bahwa kompatibilitas EVM dan komputasi rahasia natif secara struktural agak bertentangan.
Model eksekusi EVM tidak dirancang dengan mempertimbangkan pengungkapan selektif;
proposisi nilai inti Dusk justru dibangun secara khusus berdasarkan hal itu.
Menjembatani keduanya dengan baik — memungkinkan penggunaan
perangkat yang sudah dikenal sambil tetap mendapatkan transaksi
rahasia dan smart contract yang mempertimbangkan kepatuhan — benar-benar merupakan masalah integrasi yang sulit, bukan sekadar mencentang kotak.
Mungkin saja Dusk telah mengatasinya dengan elegan.
Namun, bisa juga "kompatibel dengan EVM" secara tersirat berarti "kompatibel dengan EVM untuk bagian chain yang transparan,"
sementara kontrak yang benar-benar menjaga privasi tetap memerlukan stack natif, XSC, dan kurva pembelajaran yang seharusnya dihilangkan oleh kompatibilitas EVM.
@Dusk #dusk $DUSK