#dusk $DUSK
以前看到“EVM compatible”,我基本不会多想。
Solidity 能写,Foundry 能跑,钱包也能接,那不就是 Ethereum 那套继续用?
最近看 @Dusk_Foundation 的 DuskEVM Reference,才发现真部署的时候还是不能这么偷懒。
最简单一个例子,DuskEVM 现在有自己的 sequencer。
交易拿到 receipt,说明已经被打包进去了,但这跟后面的 settlement 不是一个概念。
还有 prevrandao。
在 Ethereum 上有些开发者会顺手拿它做随机数相关逻辑,但 Dusk 官方文档专门提醒,在 DuskEVM 里别把它当成安全、无偏的随机数源。
这种东西平时不看 Reference,很容易直接按老习惯写过去。
所以现在我对 EVM compatibility 的理解比以前现实多了:
它能省掉很多迁移成本,这点没问题。
但“接口熟悉”和“底层环境一样”不是一回事。
真准备上线,sequencer、finality、跨层状态这些东西还是得重新看。
我反而挺喜欢官方把这些限制直接写出来。
最怕的不是有差异。
是你以为没有差异。
以前看到“EVM compatible”,我基本不会多想。
Solidity 能写,Foundry 能跑,钱包也能接,那不就是 Ethereum 那套继续用?
最近看 @Dusk_Foundation 的 DuskEVM Reference,才发现真部署的时候还是不能这么偷懒。
最简单一个例子,DuskEVM 现在有自己的 sequencer。
交易拿到 receipt,说明已经被打包进去了,但这跟后面的 settlement 不是一个概念。
还有 prevrandao。
在 Ethereum 上有些开发者会顺手拿它做随机数相关逻辑,但 Dusk 官方文档专门提醒,在 DuskEVM 里别把它当成安全、无偏的随机数源。
这种东西平时不看 Reference,很容易直接按老习惯写过去。
所以现在我对 EVM compatibility 的理解比以前现实多了:
它能省掉很多迁移成本,这点没问题。
但“接口熟悉”和“底层环境一样”不是一回事。
真准备上线,sequencer、finality、跨层状态这些东西还是得重新看。
我反而挺喜欢官方把这些限制直接写出来。
最怕的不是有差异。
是你以为没有差异。