先明确讨论范围
这里的“区块链养猫”指一种通用应用设想：用区块链记录虚拟猫咪的部分状态或操作。不同产品的技术架构可能不同，下面讨论的是常见设计问题，不代表某个具体项目已经出现故障，也不表示所有猫咪数据都会存放在链上。
区块链记录不等于完整应用
区块链可以看作分布式共享账本；在网络正常运行时，已发布的交易通常不会被改写。以太坊智能合约则是部署在链上的程序，由代码和状态组成，并按照设定规则处理交易。因此，合约可以记录或执行特定规则，但它本身不等于完整的游戏界面、服务和数据系统。
常见问题一：合约无法自行读取链外信息
智能合约不能直接获取链外事件或数据。如果某项游戏规则依赖外部信息，就需要通过预言机等机制将数据提供给合约。这会带来新的设计问题：数据由谁提供、如何校验，以及数据服务不可用或出错时应用如何处理。使用预言机并不意味着外部信息天然准确，具体保障方式要看系统设计。
常见问题二：错误操作可能难以撤回
合约部署后默认不能删除，链上交互也可能不可逆。因此，状态设置错误、权限配置不当或用户误操作，都不应被假设为可以像修改普通网页内容一样直接恢复。是否存在纠错、暂停或升级机制，取决于合约的具体设计；使用者和开发者都应先弄清楚相关规则。
常见问题三：交易费用与合约体量有限制
在以太坊上，部署智能合约属于交易，需要支付 gas，部署成本高于简单的 ETH 转账。涉及链上状态写入的功能也需要考虑交易费用。以太坊合约还有体量限制，过大的合约可能需要拆分设计。费用和实现方案应结合实际合约与所用网络判断，不能只看应用界面上的操作是否简单。
常见问题四：密钥和权限管理容易被忽略
用户通过提交交易与合约交互，谁持有签名密钥、哪些账户有管理权限，会影响资产和功能操作的安全性。如果管理权限集中在单一密钥上，密钥丢失或被滥用可能造成严重后果。多签合约要求多个有效签名才能执行操作，可以分散密钥管理责任；与此同时，也要提前设计签名人变更和密钥丢失后的处理方式。
常见问题五：调用其他合约会增加依赖
智能合约可以调用其他公开合约，以扩展应用功能。这种组合方式也意味着需要关注接口是否兼容、调用权限是否清楚，以及依赖合约发生异常时会怎样。阅读技术说明时，除了看猫咪相关功能，还应留意应用是否依赖其他合约或外部服务。
核对方案时可以问哪些问题
可以先确认哪些状态确实写入链上、哪些信息依赖链外服务；再查看谁能发起管理操作、是否使用多签，以及错误交易是否有预先设计的处理方式。若功能依赖外部数据或其他合约，还要了解数据来源、依赖关系和故障处理。最后核对部署与链上操作的费用，以及合约是否存在体量限制。