兰林

@meyer-net expo 感觉就是个试验品，用来引导入门的。但是对于真实项目，感觉没什么卵用。我完全放弃那个东西了，还是需要 detach。不要很多东西都没有。比如 expo 官网好像自己都说不支持蓝牙什么的。

I have the same error here, even though i had set the `cpu-count` to 4 at the beginning, it still complains about ` Insufficient CPUs available in the pool` ```shell...

```go package mongox // ------------------------------------------------------------------------------ import ( "context" "github.com/chenmingyong0423/go-mongox/hook/field" "github.com/chenmingyong0423/go-mongox/operation" "github.com/stretchr/testify/assert" "go.mongodb.org/mongo-driver/bson" "go.mongodb.org/mongo-driver/bson/primitive" "go.mongodb.org/mongo-driver/mongo" "go.mongodb.org/mongo-driver/mongo/options" "testing" "time" ) // ------------------------------------------------------------------------------ type TestColl struct { Model `bson:"inline"` TypeId primitive.ObjectID `bson:"typeId"` Title...

> `update` 的时候，设置的 `updates` 文档，这个文档有内嵌 `mongox.Model` 文档吗？或者实现 `DefaultModelHook` 了吗？如果没有满足这两个条件之一，是不会触发调用 `DefaultUpdatedAt()` 的 ```go coll := NewCollection[TestColl](getTheCollection(t)) ``` 额，难道不是直接根据泛型来判断触发的吗？一般来说既然定义了 collection的 struct包含了内置的 Model, 更新的时候应该可以直接根据泛型来判断吧，还需要另外将 update 也嵌入一个 Model 吗？

好的，谢谢你的解释。 个人感觉可以考虑直接根据泛型来判断。 主要是mongodb的update太灵活了，很多种写法，根据updates来判断估计会比较麻烦。 另外就是根据updates的话可能侵入性也比较大。 毕竟更新可能就发生在很多不同的字段组合，这个时候还要每个组合额外去定义一个包含内嵌Model的struct的话，好像有点得不偿失。 个人的一点浅见，仅供参考 这个库写的非常棒，加油！

## 一、链抽象技术体系的架构分层 ### （一）账户抽象层的统一身份管理 Particle Network的核心创新在于其**Universal Account（通用账户）系统**。 该系统基于ERC-4337标准构建智能合约账户，并通过Omnichain AA（全链账户抽象）技术实现跨链账户的统一管理。 当用户首次创建通用账户时，系统会在Particle Layer1上生成主控智能合约，并自动在各支持链（如EVM链、Solana等）部署对应的从属合约。 这些分布式合约共享同一套密钥体系，形成逻辑上的单一账户视图。 技术实现上，Omnichain AA采用**合约代码与存储分离架构**。 各链部署的智能合约仅保留执行逻辑，而账户状态数据统一存储在Particle Layer1的ZK Rollup中。 通过零知识证明技术，系统可在不同链间同步验证账户状态变更，确保跨链交易的一致性。 这种设计使得用户在任意链发起交易时，都能以原子操作的方式调用其他链的资产，而无需显式切换链环境。 ### （二）流动性层的原子交易协调 **Universal Liquidity（通用流动性）层**是链抽象体系的核心执行引擎。 该层由分布式Bundler节点网络构成，负责将用户的多链交易请求分解为原子化的操作序列。 当用户发起"用SOL购买Base链MEME"的交易指令时，Bundler节点会执行以下关键步骤： 1. **资产映射与路径发现** 节点首先扫描用户通用账户在各链的资产分布（如Solana上的SOL，Base上的ETH等），通过内置的流动性路由算法寻找最优兑换路径。 此时系统会将SOL映射为中间代币（通常选择USDC或USDT等稳定币），并计算跨链兑换的滑点与手续费成本。 2....

## 二、跨链交易的技术实现流程 ### （一）交易初始化阶段 当用户在UniversalX界面发起"用SOL购买Base链MEME"指令时，前端SDK会构造符合ERC-4337标准的UserOperation对象。该对象包含以下关键字段： ```solidity struct UserOperation { address sender; // 用户通用账户地址 uint256 nonce; // 跨链原子计数器 bytes initCode; // 合约初始化代码（首次交易时部署） bytes callData; // 包含目标链、代币地址、数量等参数 uint256 verificationGasLimit; uint256 callGasLimit; uint256...

## 三、关键技术创新点分析 ### （一）流动性网络的动态路由算法 Particle Network的LP网络采用改良后的**路径拍卖机制**，其数学模型可表示为： $$ \min_{p \in P} \left( \sum_{i=1}^{n} (1-\alpha_i)S_i + \beta T_p + \gamma F_p \right) $$ 其中： - $P$ 为所有可行路径集合 - $S_i$ 为第i个LP的滑点率 - $T_p$...

## 四、性能优化与实测数据 ### （一）延迟优化技术 通过以下创新手段将跨链交易延迟压缩至亚秒级： 1. **预执行机制** 在用户签署交易前，Bundler节点预先模拟执行并保留临时状态。 当正式交易到达时，直接提交预存结果，将确认时间缩短70%。 2. **状态通道网络** 高频交易对（如SOL/USDC）建立专用状态通道，交易双方可通过链下签名完成多轮交互，最终批量结算上链。 实测数据显示，状态通道可使TPS提升至5000+。 ### （二）成本降低方案 对比传统跨链方案，Particle Network实现Gas成本下降85%的关键在于： 1. **批量证明聚合** 将多个交易的零知识证明聚合成单个证明，验证成本分摊公式为： $$ C_{agg} = C_{base} + \frac{n \times C_{single}}{k} $$ 其中...

## 五、技术演进方向 ### （一）ZK-Rollup的深度集成 计划将Particle Chain升级为基于zkEVM的Rollup方案，其技术路线包括： 1. **统一证明电路** 设计可同时验证EVM、Solana和Cosmos交易的zk电路，验证时间目标压缩至5秒内。 2. **状态树共享** 构建跨链状态Merkle树，允许不同链的智能合约直接读取彼此状态，无需通过跨链消息传递。 ### （二）AI驱动的流动性优化 引入强化学习模型实现流动性调度的动态优化： 1. **需求预测** 使用LSTM网络预测各链未来30分钟的流动性需求，提前调度资金。实测模型准确率达92%。 2. **风险定价** 通过GAN生成对抗网络模拟市场极端情况，动态调整LP抵押率要求，提高系统抗风险能力。 ### （三）量子安全升级 为应对量子计算威胁，正在研发基于格密码的替代方案： 1. **NTRU签名算法** 替换现有的ECDSA签名方案，签名长度控制在1KB以内，兼容现有区块链架构。 2. **抗量子聚合签名** 设计基于MLWE（Module...