标榜 去中心化 永久存储，当然，存储需要支付 AR Token 作为存储费用。
永久存储的付费
根据硬盘费用历史曲线等大概的方式，预估未来200年左右可能需要的费用，来作为计价。（基于未来硬盘价格会越来越便宜，所以总的支付费用不高）。
永久存储的实现
巧妙地通过一种机制：
- 付费上传文件，该文件并不是一次性上传，而是只上传该文件的 hash，这样也达到了可以断点续传的目的
- 实际在挖矿打包过程中，会有一个 POA 的存在证明。简单讲就是，随机寻找以前的一个区块，找到一个文件，比如 1G，里面 几kb 的片段，看该文件是否存在
- 如果该 几kb 的文件片段存在，才有资格进行 POW 工作量证明，去随机算一个数
- 以这种机制，来让矿工进行多存文件的操作 —— 多存，意味着有更大的概率可以去参与挖矿
- 所以 arweave 本质上可能不算是 blockchain，而是 blockshadow 这样的新结构，网状
- 以及也就没有全节点和轻节点 —— 只有数据多、数据少的节点【只影响节点挖矿中奖率】
以太坊智能合约
像以太坊上，构建了一个 “EVM” 类似 docker 这样的虚拟环境，包括实现了 solidity 这样的语言，来编写区块链的应用程序
以太坊智能合约，对应一个合约地址。在部署智能合约代码到以太坊区块链上时，会生成合约地址。
可以将一些数据，存储在智能合约的状态中。
此后，针对该智能合约的获取数据、进行 “写” 的操作来更改数据，都是通过该 合约地址 来进行，通过智能合约创建时设定的 API 方法。
而 Arweave “合约”
Arweave 没有合约账户，本质上其实也没有合约的概念。
Arweave 的 SmartWeave “合约”，其实质是基于不可变的永久存储文件来实现。
- 将 JS 代码提交到 arweave 上，得到 txId，就作为 'SmartWeaveContractSource' application/javascript
- 初始状态，作为数据提交，SmartWeaveContract application/json Contract-Src【指向合约代码】，作为合约地址（实际上只有 initState 数据）
- 合约调用，实际上还是数据存储。对应的也是 JSON 文件，以一个规范的形式。tag 增加 SmartWeaveAction、Contract（ContractID）。标识是这个合约的操作
- 获取合约状态，会通过 AR上的交易记录筛选功能，读取对应的 SmartWeaveAction、SmartWeaveContract、SmartWeaveContractSource，对 这些 action 依次遍历。出错就做一下 log（认为是无效操作忽略），不出错，就继续。直到全部执行完成以后，把最终状态返回
- 最后再进行新的合约调用（发送新的 SmartWeaveAction）操作
以此完全不同的构思方式，Arweave 的 “合约”，读的操作，因为需要通过 N 个请求，把 arweave 关于该“合约”所有的 action json集合、sourceCode javascript、initState json 全部拉取下来，会比较消耗资源；而写的操作，因为都是拉取下来后，在本地校验执行，再通过 arweave 的上传文件上传一个非常小的 action json 文件，而成本极低。
此外，目前的 AR 交易记录筛选机制，AR 的“合约”无法组合（无法在一个 SmartWeaveAction 的文件存储中，指定更改两个或N个 “合约”的状态）。除非自己定义另一套规范，当然，以 go、js、ts、php、java 等等语言，都是可行的，只要规范定义、并实现这个定义相应的 SDK 工具即可。
以此思路，arweave 上可以做非常复杂的 “合约”，或者是说，一套规则制定。但当前，因为生态发展尚不完善，暂时还没有特别突出的 “合约”（规则）制定出来。
