简介
本文介绍了从code 和 data 一起 到 code 和 data 分离 这种智能合约开发范式转移,再通过在 Aptos 和 Sui 上 BTC 跨链镜像资产合约实例, 介绍了 Aptos 和 Sui 合约开发的异同点。
哈佛结构和冯·诺依曼结构
学过计算机体系结构的都知道, 哈佛结构和冯·诺依曼结构。
哈佛结构出现的更早, 当时的计算机设计, 程序和数据是俩个截然不同的概念,
数据放在存储器中，而程序作为控制器的一部分。
这种架构灵活性较差, 需要技术员既要懂硬件设计,又要懂程序设计。
冯·诺依曼结构中, 将程序和数据一样看待, 将程序编码为数据,然后与数据一同存放在存储器中。这样计算机就可以调用存储器中的程序来处理数据，程序不再是控制器的一部分了。
这种设计思想导致了硬件和软件的分离, 即硬件设计和程序设计可以分开执行！这就催生了程序员这个职业的诞生。
哈佛结构在嵌入式芯片行业常见 ( 比如 ARM9~ARM11 芯片, 而 ARM7 系列则采用了冯·诺依曼结构 )，而 PC 和服务器芯片基本是冯·诺依曼结构。
可以说, 互联网程序员都是在冯·诺依曼结构下进行程序设计。
简单地, 哈佛结构就是code 和 data 分离, 冯·诺依曼结构就是code 和 data 一起。
区块链虚拟机与智能合约开发
code 和 data 一起：data 处于 code 所在的作用域, code 随时读取 data。code 和 data 分离：将 data 或 data 的位置传给 code, 且 code 只能处理这些给定的数据 ( 无法访问其他数据 )。
(2) Who: 谁能访问这些数据
(3) How：如何处理这些数据 ( 业务逻辑 )
EVM:code 和 data 一起WASM:code 和 data 一起Solana-BPF:code 和 data 分离Aptos-Move:code 和 data 分离Sui-Move:code 和 data 分离
EVM和WASM上编写合约程序更简单。Solana-BPF,Aptos-Move,Sui-Move上开发智能合约,就需要像硬件工程师关心数据控制器一样去关心 data 的位置:Solana 合约: 调用者需要指定访问 data 的地址及其读写属性。Sui 合约: 与 solana 类似, 调用者需要指定访问 data 的 object-id。Aptos 合约: 更简单, 数据通过 move_to 和 signer 绑定, 又通过将合约部署者和合约绑定,使得合约也可以拥有自己的状态数据, 调用者不再需要自己指定访问 data( 但需要调用者提前注册 data, 完成 move_to 绑定 )。
solana > sui > aptosAptos 和 Sui 智能合约开发对比
为了防止重复 deposit, 需要一个队列存储已 deposit 的请求bridge-aptos 的 iterable_table 底层用的是 table( 定义在 AptosStdlib)bridge-sui 的 vec_queue 底层用的是vector( 定义在 MoveStdlib)
0x0地址下。bridge::initialize 只能由合约的 owner 调用bridge-aptos 中可以直接用 "@owner"进行对比bridge-sui 中只能在 init 时将 creator 先保存到 Info 中, 调用 initialize 时在取出对比
(3) Aptos 用户需要自己定义调用 initialize 等函数完成合约的初始化, 而 Sui 用户只需要自己定义 init 函数 ( 不能传自定义参数 ), 合约部署的时候完成初始化。
admin 和 controller 只能被初始化一次bridge-aptos 中的 initialize 做了存在性检查, 确保 admin 和 controller 只被初始化一次bridge-sui 中的init先初始化一个object, 在调用 initialize 完成最后的初始化
(4) Aptos resource 不能直接转移到 receiver 地址, 而 Sui object 可以直接转移到 receiver 地址。
XBTC 的 transferbridge-aptos 需要先 xbtc::register, 再 xbtc::transferbridge-sui 只需一步 xbtc::split_and_transfer(5) Aptos 中的 fungible tokens 不需要merge操作, 而 Sui 则提供了merge,以便将很多小额 objects 合并为 1 个 object。
XBTC 的 transferbridge-sui xbtc::join 和 xbtc::join_vec
(6) Aptos 合约内通过 move_to 将 resource 和 signer 绑定, 而 Sui 合约内禁用 move_to。
xbtc::init 调用 move_to, 编译时报如下错误ExecutionErrorInner {kind: SuiMoveVerificationError,source: Some(to Move global storage is not allowed.Found in function init: [MoveTo(StructDefinitionIndex(1))]"}
public(script), 而 Sui 则废弃了public(script)。bridge-sui 中使用`public(script)`, 编译时报如下错误'public(script)' is deprecated in favor of the 'entry' modifier. Replace with 'public entry'
bridge-aptos admin example: 0xa24881e004fdbc5550932bb2879129351c21432f21f32d94bf11603bebd9f5c0bridge-sui admin example: 0xdea83a5c27ef936cd9efd3bc596696e1d101d647
bridge-aptos upgrade-policy`arbitrary`, `compatible`, `immutable` 对应 0， 1，20 不做任何检查，强制替换 code,1 做兼容性检查 ( 同样的public 函数，不能改变已有 Resource 的内存布局 )2 禁止升级每次 publish 的时候会比较链上的 policy 和此次 publish 的 policy( 默认是1),只有此次的 policy 小于链上的 policy 时才允许合约升级
bridge-sui bridge::deposit 函数签名及函数调用 public entry fun deposit(account: &signer,receiver: address,amount: u64,memo: String,) acquires Infoaptos move run \--private-key=$PRIVATE \--url=http://127.0.0.1:8080 \--function-id=0xa24881e004fdbc5550932bb2879129351c21432f21f32d94bf11603bebd9f5c0::bridge::deposit \--args address:0xa24881e004fdbc5550932bb2879129351c21432f21f32d94bf11603bebd9f5c0 u64:10000000 string:"test" \bridge-sui bridge::deposit 函数签名及函数调用public entry fun deposit(info: &mut Info,xbtc_cap: &mut TreasuryCap<XBTC>,receiver: address,amount: u64,memo: vector<u8>,ctx: &mut TxContext)sui client call --gas-budget 10000 \--package 0xc087a76e0495c395db814587688930b7fd808cad \--module "bridge" \--function "deposit" \--args 0xe57396fb7f2c09ffb0fec0af7e175d106dc18253 \0x5c3d9503d9963c0887b13e6b1cca4c9ca341d39d \0xdea83a5c27ef936cd9efd3bc596696e1d101d647 \100000 \"test"
【免责声明】市场有风险，投资需谨慎。本文不构成投资建议，用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。
