共享应用需要明确哪些边界
区块链技术共享应用有哪些常见问题，可以从运行容量和协作权限两方面理解：前者关系到多方能否顺畅提交操作，后者关系到各参与者能够执行哪些操作。这里讨论以太坊及智能合约的通用机制，不将其直接视为所有共享平台的实际表现。
参与者增加后，为何会变慢、变贵
以太坊扩容文档指出，主网需求增加可能造成拥堵并推高交易费用。Layer 2通过在主网之外处理交易、再与主网结算等方式扩展容量；不同方案的安全机制存在差异。
对共享应用而言，需要区分提交成功、处理完成和最终确认。界面已经显示操作结果，不一定表示它已达到业务要求的确认程度。涉及多个机构共同认可的记录时，应明确以哪个阶段作为后续流程的起点。
扩容方案是否具有相同的安全保障
同一扩容文档区分了从以太坊主网获取安全保障的Layer 2与采用独立共识的侧链，也指出链下数据存放方式存在差异。因此，不能仅凭速度或费用判断方案是否适合。
适用条件应围绕具体业务展开：共享记录需要保留哪些验证依据，参与方能否取得这些依据，以及依赖哪些运营主体。高频协作与低频重要记录可能有不同要求，技术名称本身不能替代这些判断。
共享是否意味着所有人权限相同
OpenZeppelin访问控制文档介绍了单一所有者和基于角色的授权方式，并强调最小权限原则。多人参与的应用可以按职责划分权限，但持有某个业务角色，并不自动拥有向他人授予该角色的权力。
例如，共享流程中的提交、审核和权限分配可以分别考虑。设计时既要回答谁能处理业务，也要回答谁能改变授权关系，否则表面上的职责分工仍可能被集中管理权限绕过。
管理员交接和成员退出有哪些问题
同一访问控制文档提示，所有权转交给错误账户可能影响管理操作，两步交接可要求接收方确认；放弃所有权则会使受所有者权限保护的功能无法再调用。
因此，权限交接需要结合业务连续性设计。成员退出时，应核对其仍持有的各项角色；管理员更换时，应确认接收方能够履职。对于职责会持续变化的共享应用，权限撤销、交接和变更记录都应纳入日常管理，而不能只在部署时设置一次。