在某个地方,我读到了关于存储名字的建议(标题、地名、人名等等)。事件中的价值链价值。
但是,如果一个值存储在一个事件中,那么是否有一种有效的方法可以从web3.js脚本(它不是一直在运行,因此无法有效地订阅事件)检索它的值?
如果我真的决定在一份合同中储存,我是否应该专门为姓名仓库订立第二份合同?(因为在主契约存储中存储名称将打破单一责任原则和抽象模式)
发布于 2020-01-15 06:02:22
但是,如果一个值存储在一个事件中,那么是否有一种有效的方法可以从web3.js脚本(它不是一直在运行,因此无法有效地订阅事件)检索它的值?
有一个无状态(几乎)模式需要考虑。
pragma solidity 0.5.16;
contract BreadCrumbs {
uint public prevChange;
event LogChange(string arg1, string arg2, string arg3. uint previous);
function change(string memory _arg1, string memory _arg2, string memory _arg3) public {
emit LogChange(_arg1, _arg2, _arg3, prevChange);
prevChange = block.number;
}
}一般的想法是将信息填充到比合同状态变量便宜几个数量级的日志中。
prevChange()给出了一个块号,其中包含了最新的值,从而大大减少了客户机需要通过日志进行捕捞的数量。在许多情况下,最新的价值是唯一的价值感兴趣。
如果是0,那么就没有任何信息。
通过跟踪提示直到0,可以按反向顺序探索历史。
另一种流行的模式是将大量数据写入其他地方,例如IPFS,然后编写url以便客户端能够找到它,而散列则使客户能够知道它是真实的。IPFS在一次行动中解决了这两个问题。您需要的信息将打包到bytes32中,您可以存储或记录这些信息。
如果我真的决定在一份合同中储存,我是否应该专门为姓名仓库订立第二份合同?(因为在主契约存储中存储名称将打破单一责任原则和抽象模式)
您可能已经读过可升级合同的永恒存储模式。我认为,你决定分开关注的方式因许多考虑因素而有所不同。创建一个封装状态和逻辑的紧凑的、不可升级的契约是很正常的。如果我没弄错的话,大多数人就是这么做的。
希望能帮上忙。
https://ethereum.stackexchange.com/questions/78984
复制相似问题