Last night, I opened a DuskVM contract from @DuskFoundation and noticed two WASM files built from the same source. One runs on-chain, the other off-chain. I stopped there: does one contract really need two WASMs, or is this just adding complexity?
Digging into the interface, I found argbuf: 64 KB. The interface is stripped down: bytes enter the buffer, a u32 tells the contract how much to read, and the output comes back through the same path.
Then the two WASMs started to make sense. Contract WASM executes the logic. Data-driver WASM translates the data: JSON from wallets, explorers, or frontends is encoded into a format the contract understands, then the result is decoded back.
The trade-off is clear: developers need to understand one extra boundary what runs on-chain and what stays outside to handle translation. I opened the docs because 64 KB caught my eye. I ended up remembering the two files instead. One executes. One translates. Same source, different jobs.
@Dusk_Foundation $CYS $ACE $DUSK #dusk
Two WASMs from one source smart design or extra complexity?
Digging into the interface, I found argbuf: 64 KB. The interface is stripped down: bytes enter the buffer, a u32 tells the contract how much to read, and the output comes back through the same path.
Then the two WASMs started to make sense. Contract WASM executes the logic. Data-driver WASM translates the data: JSON from wallets, explorers, or frontends is encoded into a format the contract understands, then the result is decoded back.
The trade-off is clear: developers need to understand one extra boundary what runs on-chain and what stays outside to handle translation. I opened the docs because 64 KB caught my eye. I ended up remembering the two files instead. One executes. One translates. Same source, different jobs.
@Dusk_Foundation $CYS $ACE $DUSK #dusk
Two WASMs from one source smart design or extra complexity?
Smart separation
75%
Extra complexity
0%
Depends on the use case
25%
Need to dig deeper
0%
4 الأصوات • تمّ إغلاق التصويت