功能架构解决什么问题
区块链功能架构可以从记录保存、状态确认和业务执行之间的分工来理解。判断是否适用，应先明确哪些参与方需要共享哪些记录，再确定记录如何确认、如何核验，以及哪些处理需要放在链上。功能划分应服务于业务需求，不必套用固定的层数。
条件一：存在多方共享和核验记录的需求
NIST《区块链技术概述》将区块链描述为以分布式方式实现、能够显露并抵抗篡改的数字账本，供参与者共同记录交易。这意味着，共享历史和核验记录是评估适用性的基础。
当多个参与方需要依据同一份历史确认业务状态时，共享账本具有讨论价值。若记录始终由单一主体使用，且已有被各方接受的管理方式，则需要进一步说明引入分布式账本的必要性。
条件二：业务能够接受记录的持久性
NIST概述强调，在区块链网络正常运行的条件下，已发布的交易不能被更改。适用业务因此应重视历史留存，并能区分原始记录与后续更正。
防篡改不能保证输入内容符合现实。例如，外部事件被错误记录后，保存得再牢固也不能自动纠正事实。架构评估仍需明确数据由谁提交、依据什么确认，以及发生错误后如何补充说明。
条件三：参与方能够明确共同确认的规则
共享账本需要解决哪些记录可以被接受、各节点如何确认一致状态等问题。因此，参与范围、验证责任以及异常处理规则需要明确。
业务若要求共同核验，却无法约定确认规则，单靠部署节点难以解决分歧。共识机制承担技术层面的状态确认，业务规则仍需说明记录代表什么，以及谁对输入负责。
条件四：性能与安全要求能够同时满足
以太坊扩容文档指出，扩容需要提高处理速度和吞吐量，同时保留安全性与去中心化特征；不同链下方案与主网的安全关系也存在差异。
因此，评估架构不能只看处理数量，还应关注确认等待、运行成本、数据存放位置和验证方式。引入链下执行时，需要明确结果如何被链上验证，以及出现争议时依靠什么机制解决。具体能力应以所选实现为准。
常见问题
是否所有数据都要上链？不必。链上与链下可以承担不同职责，但这种分工必须说明哪些信息可供核验、哪些部分依赖外部系统，不能仅以减少链上负担作为判断依据。
扩容方案是否共享同样的安全保障？并非如此。以太坊扩容文档区分了依托主网安全的二层方案与采用独立共识的侧链。连接主网本身不足以说明安全保障相同，适用性还取决于具体的验证和数据可用性安排。