我正在为 NEAR 区块链编写一组交互智能合约。让我们想象以下场景
- 用户向交易所智能合约发送代币
- 代币智能合约调用交易所智能合约
- 交易所智能合约调用费智能合约
- 交易所智能合约调用另一个代币合约在交易中发回另一个集合代币
与单个分片以太坊不同,NEAR 确实使用承诺交叉合约调用。虽然单次触发require()
会自动回滚到整个以太坊交易,但 NEAR 智能合约本身的分片性质负责在它们触发的承诺未成功完成时回滚状态更改。
我的问题是如何安全地处理 NEAR 智能合约之间的承诺链中的失败
- 故障模式有哪些(智能合约功能死机、目标账户不包含代码、耗尽gas)
- 如何捕捉上面的不同错误,处理不同的错误模式
- 是否已经有一种模式允许以简单的方式安全地编写承诺链,类似于
try {} catch {}
JavaScript 中的等待/异步模型 - 如何在不同的 Promise 之间跟踪导致 Promise 链触发的初始用户交易是什么
- 智能合约如何转发 gas 并确保有足够的 gas 来完成整个承诺链