我很少会去教人做事指指点点的，但这个刷到我是真绷不住

今天我们继续来讲一个新瓶装旧酒的项目Sonic，最近这两天热度还挺高，因为明天将会进行TGE(Token Generation Event )，并且还会给空投。Sonic是Sol的L2，大家居然奇怪的是速度这么快的SOL还需要L2？这不就是币圈所需要的热点吗？

那么SOL为什么需要L2？
随着 Solana 上 dAPP 和 DeFi 活动增速更快，24年1月每天链上交易已经超过了2亿笔，有分析人士保守估计26年交易量将超过40亿笔。
在这种可预见的压力下，Solana 的 TPS 在2500-4000左右，Solana 集群的平均 ping 时间在 6 秒到 80 秒之间波动；当TPS日益饱和甚至超过4000时，Solana交易的成功率仅达到70%至85%。
除了网络状况导致的物理延迟和网络波动外，显然主要原因与 TPS 的饱和度不断增加有关。根据 Solana 的增长趋势，预测未来几年 TPS 值将达到 10,000 到数万，这将导致更明显的性能问题。
上面是Sonic白皮书给出的答案，而我这边在增加一点：
1.在前两天Messari对以太坊L2的报告中说过，目前的L1最适合的还是主打安全结算，应用放在L2比较好。
2.Sonic目前主打的是游戏公链，主打全链游戏的链，如果真的是10万人，或者百万人在线的链游，如果数据是全链的那么几千几万的TPS确实扛不住，所以确实需要更加高速且便宜的L2.   

一．简介
Sonic 是第一条原子 SVM 链（什么叫原子级互操作，就是账户和程序和sol互通），也是Solana的最快速的L2层，Sonic 建立在 Solana 的第一个并发扩展框架 HyperGrid 之上。通过 HyperGrid 的解释器，轻松将 dApp 从 EVM 链部署到 Solana，所以它及兼容EVM也兼容SOL。
Sonic 在链上基于 ECS 框架公开原生可组合游戏原语和可扩展数据类型。游戏引擎沙盒为开发者提供实用工具，帮助他们在链上构建业务逻辑。  
二．Rush ECS框架
Rush 是一个完全用 Rust 构建的声明式快速实体-组件-系统（Entity-Component-System, ECS）框架，其唯一目标是：通过采用已验证的开发体验抽象技术，将区块链技术与开发者熟悉的工具（如游戏引擎 SDK 和 API）的集成复杂性降到最低。 
Rush 展望着一个未来：任何已经构建或即将构建的游戏，都可以轻松通过 Rush 和他们喜欢的游戏开发技术栈，转化为全链游戏（Fully-Onchain Game）或自治世界（Autonomous World）。 
          
 Rush 的工作原理
通常，游戏开发者使用游戏引擎来创建游戏。 
借助游戏引擎，底层逻辑的复杂性大大降低，开发者可以专注于游戏设计和机制，而复杂性由游戏引擎处理。 

另一方面，全链游戏（FOCG）和自治世界（AW）的实现必须依赖去中心化的数据存储，例如区块链。 
这种去中心化特性使得数据的持久性远胜于单一数据存储库，但这也伴随着额外的成本。 
          
 开发者面临的问题
为了实现 FOCG 或 AW，游戏开发者需要掌握区块链的全栈技术，或雇佣区块链专家。 
无论是学习还是雇佣，这都需要大量资源，并且常常是游戏开发者迈向全链游戏或自治世界的巨大障碍。 

Rush 正是为了解决这一问题而生。 
它通过已验证的高效开发体验抽象技术，如： 
- 声明式配置（Declarative Configuration） 
- 实体-组件-系统（Entity-Component-System, ECS） 
- 代码生成（Code Generation）     
从而大幅简化复杂性。   

三． HyperGrid 框架
HyperGrid 协议是一个 Rollup 扩展与编排框架，旨在支持 SVM 生态系统的 Rollup 运营者。它通过状态压缩（State Compression）和拜占庭容错（Byzantine Fault Tolerance, BFT）技术，实现潜在的无限交易吞吐量。这是通过在多个网格（Grids）间实现水平扩展来完成的，正如 Sonic（一个专注于游戏的网格）所示，其交易最终在 Solana 上结算。      
3.1架构概述   
HyperGrid 的多网格架构概述：半自治网格通过 Solana 实现共识和最终性。 
HyperGrid 的架构基于多网格（multi-grid）模式，每个网格都以半自治的方式运行，同时通过 Solana 主网实现共识和最终性。 

 3.2HyperGrid 系统架构      
 关键组件 
1. Solana 基础层： 
   - HyperGrid 系统的基础，为其提供最终的共识和数据最终性。 
          
2. HyperGrid 共享状态网络（HSSN）： 
   - 系统的核心，跨所有网格运行。 
   - 包含多个验证者（Validator 1 至 Validator N）。 
   - 在网格和 Solana 基础层之间共享状态。 
   - 管理用于结算的批量零知识证明（ZK Proofs）。 
          
3. 网格结构（以 Grid 1 和 Grid 2 为例）： 
   - 每个网格代表一个半自治生态系统，可专用于特定应用（如不同的游戏）。 
   - 每个网格的组成部分包括： 
     - ZK 协处理器：处理网格特定的操作和 Merkle 证明。 
     - SVM 运行时：在 Solana 虚拟机上执行网格操作。 
     - Sonic Gas 引擎：管理计算资源。 
     - 并发 Merkle 树生成器：高效处理状态转换。 
              
4. 用户交互： 
   - 用户可独立与各网格交互。 
   - 交易（包括 SVM 和 EVM 交易）在用户与相应网格运行时之间流转。 
   - 交易响应返回给用户。 
          
 3.2数据流
 互操作性与状态共享： 
- Solana 基础层和 HSSN 之间进行双向状态共享。 
- HSSN 将状态共享给各个网格。 
- 状态共享也可以发生在不同网格之间。 
          
3.4 ZK 证明： 
1. 交易被压缩并聚合到 Merkle 树中。 
2. 对于每个区块，提交相应的根状态哈希值。 
3. 有效性证明（Validity Proof）在网格上计算。 
4. HSSN 将 ZK 证明用于结算并提交到 Solana 基础层。 

四． 网格与网络通信
HyperGrid 的网络架构：共享状态网络、网格实例与 Solana 基础层的关系，为可扩展的 dApp 部署提供支持。               

 HyperGrid 共享状态网络的数据流
HyperGrid 框架旨在支持广泛的应用特定网络或去中心化应用（dApp），特别关注其生态系统内需求量大的应用，如游戏、DeFi、AI 代理等。 
该架构的目标包括： 
1. 减轻 Solana 基础层的性能压力。 
2. 最小化基础层与各种特定领域 dApp 之间因争夺区块空间引发的性能冲突和竞争。 
          
 关键特性 
1. 灵活性，为网格网络创建者提供选择： 
  - 开发者可以选择： 
     - 使用 HyperGrid 公共网络。 
     - 水平扩展以创建专用于特定需求的专属网络。 

2. 性能与成本优化： 
   - 公共网络与专属网络之间的选择，取决于开发者对性能需求和相关成本的评估。 
          
3. 网络独立性： 
   - 开发者可随时停用其专属网络，而不会影响生态系统中的其他网络。         
 操作框架 
1. 验证： 
   - 每个网络自主处理其交易和状态变更的验证。 
2. 日志记录： 
   - 每个网络独立维护其交易和状态变更日志。 
3. 数据检索： 
   - 数据检索流程在每个网络中独立执行。 
          
五．于Solana的互操作性
5.1将数据从 Solana 读取到 HyperGrid

上图说明了从 Solana 到 HyperGrid 上的网格（如 Sonic）执行状态同步时的以下流程。
初始加载：将预先存在的 Solana 程序从存储加载到 HyperGrid 的缓存中。    
用户向 HyperGrid 的 Sonic RPC 发送对特定程序的读取请求。    
同步程序检查缓存中是否存在所请求的程序，但未找到。       
同步程序向 Solana 基础层 RPC 发送程序的请求。    
Solana 基础层使用程序数据进行响应。       
同步程序接收响应并使用新的程序数据更新 HyperGrid 的缓存。       
同步程序将读取响应发送回 Sonic RPC。     
Sonic RPC 将读取响应转发给用户。
            
5.2将更新同步回 Solana 基础层  

上图说明了从 HyperGrid 上的网格（如 Sonic）执行状态同步回到 Solana 时的以下流程。    
初始加载：将预先存在的程序从存储加载到 HyperGrid 的缓存中。   
用户向 HyperGrid 的 Sonic RPC 发送特定程序的写入请求。
同步程序检查缓存中是否存在所请求的程序，但未找到。
同步程序发送请求，锁定 Solana 基础层上的程序。 
Solana Base Layer RPC 锁定请求的程序。    
Solana 基础层使用程序数据进行响应。
同步程序接收响应并使用新的程序数据更新 HyperGrid 的缓存。 
同步程序发送请求以释放锁，并将程序的更新数据写入 Solana 基础层。
Solana Base Layer RPC 释放锁并写入更新的数据。
同步程序将写入响应发送回 Sonic RPC。
Sonic RPC 将写入响应转发给用户。

六．超网格共享状态网络 (HSSN) 
HyperGrid 共享状态网络 (HSSN) 是 Grid 生态系统中的关键组成部分。它充当共识层、通信中心和状态管理集群，促进 Grid 和 Solana 基础层之间的交互。该网络管理所有通信的状态，包括定期将区块数据从 Grid Rollups 同步到 Solana 基础层。

主要组件和功能
HSSN 架构：基于 Cosmos 框架构建，保证跨链通信的可靠性和安全性。    
数据结构：管理网格和 Solana 基础层之间的状态，包括：
-电网注册   
-通信数据源     
-版本控制
-读/写状态
-扩展账户数据字段：增强原生 Solana 基础层账户数据字段，以适应 HSSN 管理的新字段，确保与网格账户状态同步。  
-重构的网格 RPC：实现网格和 HSSN 之间的直接通信，促进生态系统内的互操作性。          
GAS充装及分配机制：用户为某些电网请求支付 gas 费，专门的网格（Sonic Grid）运行气体计算程序，集中管理整个电网生态系统的天然气。
    
项目融资情况
Sonic完成1200万美元A轮融资，此轮融资由Bitkraft Ventures领投，Galaxy Interactive、BigBrain Holdings等公司参投，目前估值1.2亿美金。
          
TGE:
SONIC总供应量为24亿枚，其中57%分配给社区，包含社区与生态发展（30%）、初始认领（7%）和HyperGrid 奖励（20%）。TGE定于2025年1月7日，初始流通量占总量15%。SONIC将在6年内分发完毕，届时，所有SONIC将完全流通，其中大部分分配给社区。在推出后的前12-18个月内，不会解锁任何团队和投资者代币，锁定的代币不能质押。
   
最后总结下这个项目，SOL开始推出L2了，那么其实目前在速度快的公链应该都是有L2需求的，按照这个逻辑推理，那么其实avax的多链架构其实说明是有用的，而SOL的L2可能会崛起一波。