Ada sebuah malam ketika aku membuka dokumen untuk DuskEVM dan DuskVM berdampingan, dengan berkas catatan penuh panah di sampingnya, lalu menjalankan uji simulasi sendiri: dengan alur Smart Contract yang sama, bagaimana pikiranku memprosesnya di bawah EVM Compatibility, dan saat pindah ke Native Execution, berapa kali proses berpikir itu harus berubah...
Aku membagi alurnya menjadi 10 langkah: 6 langkah yang sudah familiar dari Solidity, Gas, Account Model; 4 langkah sisanya menyentuh Rust/WASM, Transaction Model, Ledger Logic, State Transition, Privacy dan Zero-Knowledge Proof.
6/10 = 60% terdengar ringan, tetapi 40% sisanya di situlah waktu benar-benar habis.
karena sintaks hanyalah lapisan terluar.
bagian yang lebih sulit adalah mental model.
di EVM, aku berpikir dalam hal pemanggilan kontrak, status akun, konsumsi gas; pindah ke DuskVM, pertanyaannya berubah total: bagaimana state direpresentasikan, di mana Privacy berada, kapan Zero-Knowledge Proof masuk ke dalam State Transition?
dengan jujur, bagian ini membuatku lebih menyukai Dusk... tetapi juga membuatku lebih waspada.
Aku mencoba 8 tugas lain untuk sebuah aplikasi dengan Protocol Assets: 5 tugas EVM hampir datang begitu saja, sementara 3 tugas native memaksaku untuk berhenti dan menggambar dependensi serta alur eksekusinya.
3/8 = 37,5% dari tugas, tetapi Context Switching tetap menghabiskan banyak usaha.
ini bukan benchmark resmi, hanya caraku mengukur beban kognitif ketika sebuah tim hidup di 2 Execution Environments.
EVM Compatibility membuat onboarding lebih cepat.
tetapi jika Privacy, Zero-Knowledge, dan Protocol Assets tertanam dalam Native Execution, pengembang tetap harus melewati dua tumpukan, dua Ledger Logic, dua Transaction Model.
Aku tidak takut dengan arsitektur berlapis.
bagi saya, arsitektur yang baik harus membuat pengembang memahami dengan benar State, Execution Semantics, dan asumsi keamanan sebelum kode benar-benar berjalan.
menurut kalian, apakah keunggulan Dusk yang lebih besar terletak pada entry point EVM... atau pada kemampuannya membuat pengembang benar-benar menguasai lapisan native di baliknya?
#dusk $DUSK @Dusk
Aku membagi alurnya menjadi 10 langkah: 6 langkah yang sudah familiar dari Solidity, Gas, Account Model; 4 langkah sisanya menyentuh Rust/WASM, Transaction Model, Ledger Logic, State Transition, Privacy dan Zero-Knowledge Proof.
6/10 = 60% terdengar ringan, tetapi 40% sisanya di situlah waktu benar-benar habis.
karena sintaks hanyalah lapisan terluar.
bagian yang lebih sulit adalah mental model.
di EVM, aku berpikir dalam hal pemanggilan kontrak, status akun, konsumsi gas; pindah ke DuskVM, pertanyaannya berubah total: bagaimana state direpresentasikan, di mana Privacy berada, kapan Zero-Knowledge Proof masuk ke dalam State Transition?
dengan jujur, bagian ini membuatku lebih menyukai Dusk... tetapi juga membuatku lebih waspada.
Aku mencoba 8 tugas lain untuk sebuah aplikasi dengan Protocol Assets: 5 tugas EVM hampir datang begitu saja, sementara 3 tugas native memaksaku untuk berhenti dan menggambar dependensi serta alur eksekusinya.
3/8 = 37,5% dari tugas, tetapi Context Switching tetap menghabiskan banyak usaha.
ini bukan benchmark resmi, hanya caraku mengukur beban kognitif ketika sebuah tim hidup di 2 Execution Environments.
EVM Compatibility membuat onboarding lebih cepat.
tetapi jika Privacy, Zero-Knowledge, dan Protocol Assets tertanam dalam Native Execution, pengembang tetap harus melewati dua tumpukan, dua Ledger Logic, dua Transaction Model.
Aku tidak takut dengan arsitektur berlapis.
bagi saya, arsitektur yang baik harus membuat pengembang memahami dengan benar State, Execution Semantics, dan asumsi keamanan sebelum kode benar-benar berjalan.
menurut kalian, apakah keunggulan Dusk yang lebih besar terletak pada entry point EVM... atau pada kemampuannya membuat pengembang benar-benar menguasai lapisan native di baliknya?
#dusk $DUSK @Dusk
