2022-10-13

AppChain的设计空间
在决定基于哪个AppChain基础架构时，需要考虑以下几个设计权衡：
安全类型：攻击链改变状态有多难?
共享：由多个异构验证者保护的状态，可能由不同方运行（例如Polkadot parachains, Skale）；
隔离：由应用程序本身提供的安全性；可能使用应用程序拥有的验证者或排序器，并使用应用程序的代币来获得经济利益(例如Cosmos链，Axie Ronin）；
继承：底层结算/共识层提供的安全性（例如 zkSync、Optimism）。
安全来源：安全从何而来，结算在何处发生?
以太坊：使用以太坊作为结算层，用于欺诈证明、有效性证明和一般的双花保护（例如 Arbitrum、zkSync）；
非以太坊L：:使用非以太坊安全性，并可能具有完全不同的共识模型(例如NEAR Aurora、Tezos rollup)；
应用代币：应用代币被用作加密经济安全（例如 Avalanche 子网、Cosmos 链）。
权限：如何选择节点，谁可以读/写状态?
无需许可：任何人都可以读/写合约并验证状态转换（例如 Optimism、StarkNet）；
可选择权限：只有在白名单中的验证者/开发人员可以读/写/验证链（例如 Polygon Supernets、Avalanche Subnets）。
可组合性：流动性和状态在同一生态系统中的其他应用程序之间移动的容易程度和安全性
Full：移动到任何延迟最小、安全性最高的应用程序(例如Polkadot XCMP、Cosmos IBC)；
Limited：在连续性、延迟和/或安全性方面有限制(例如Avalanche Subnets, Polygon Supernets)。
最终性：什么时候交易被认为是最终的？(假设概率上最终被认为是最终)
即时：通常使用BFT共识机制(例如NEAR Aurora, Evmos)；
最终：通常使用rollup，一旦区块被发布到L1(并假设数据可用)，就可以认为交易是最终的(例如Arbitrum, zkSync)。
Gas货币：用户用哪种代币支付交易?
非应用程序代币：通常是构建应用程序的L1或L2的基础资产(如以太坊、Evmos)；
应用程序代币：通常应用程序代币本身运行在特定于应用程序的L1或L2上(例如Avalanche Subnets、Osmosis)；
无：L1或L2验证者或应用程序为用户补贴硬件成本。(例如 AltLayer、Skale)。
还有其他几个更直接的因素：
所需的质押：应用程序拥有验证者以保护其链所需的质押数量；
每秒交易数(TPS)：对吞吐量的主观度量，因为交易的大小可能不同(例如，较大的交易将导致较低的TPS，反之亦然)；
支持EVM：无需开发人员修改其代码库即可同时支持 Solidity 和 EVM 操作码的能力。
我们可以根据以下因素映射现有的AppChain解决方案：