为什么？

我们为什么产生的文字/语言/信号？

• 从高维度角度来说，就是我们本来就是相连的能量，能量显化成时空
• 为了能量的膨胀/平衡/墒增，时空之间需要交错交错交错
• 交错落地到三维人类+ 表达的频率+计算+想象力+感知，形成了图文信号，共识和效率

就是信息，就是通过对过去的描述，来对抗未来的不确定性的一个东西

• 信息墒，就是熵越低，则意味着传输的信息越少

图灵机，就是一个模拟人的计算的计算器

冯诺依曼结构（英语：Von Neumann architecture），也称冯诺依曼模型（Von Neumann model）或普林斯顿结构（Princeton architecture），是一种将程序指令存储器和数据存储器合并在一起的电脑设计概念结构。本词描述的是一种实现通用图灵机的计算设备，以及一种相对于并行计算的序列式结构参考模型（referential model）。

本结构隐约指导了将存储设备与中央处理器分开的概念，因此依本结构设计出的计算机又称存储程序计算机。

邱奇－图灵论题对于心智哲学（philosophy of mind）有很多寓意，但是对于该论题的很多哲学解读存在曲解。哲学学者B. Jack Copeland认为关于图灵机是否可模拟确定的物理过程的问题仍没有得到解答。他进一步声称关于这些物理过程是否在人类的智能机制中起到作用的问题也是未决的。有很多重要而悬而未决的问题也涵盖了邱奇－图灵论题和物理学及超计算（hypercomputation）的可能性之间的关系。应用到物理学上，该论题有很多可能的意义：

1. 宇宙是一台图灵机（由此，在物理上对非递归函数的计算是不可能的）。该论述被定义为大邱奇－图灵论题。
2. 宇宙不是一台图灵机（也就是说，物理的定律不是图灵可计算的），但是不可计算的物理事件却不能阻碍创建超计算机（hypercomputer）的可能性。比如，一个在物理上包含实数而非可计算实数的宇宙就可以被划为此类。
3. 宇宙是一台超计算机，而且建造物理设备来实现这一特性并以之计算非递归函数是可能的。比如，一个悬而未决的问题是我们无法确定量子力学（quantum mechanical）的事件是否图灵可计算的，尽管诸如量子图灵机之类的严格模型实际上等价于确定性图灵机（但并不一定在效率上等价）。约翰·卢卡斯和名气更大一点的罗杰·潘洛斯曾经建议说人的心灵可能是量子力学和非算法计算的结果， 尽管并没有科学证据支持这一提议。

实际上在这三类之外或其中还有许多其他的技术上的可能性，但这三类只是为了阐述这一概念。

计算机的核心- 就是主要是自动的执行 某种逻辑 序列

是利用模拟或者数字电子技术，根据一系列指令指示并且自动执行任意算术或逻辑操作序列的设备。通用计算机因有能遵循被称为“程序”的一般操作集的能力而使得它们能够执行极其广泛的任务。^[2]

• 比特币- 就是一个全球时间戳计算机，只在算交易y or n就是两个状态

1. POW就是通过这种随机性+博弈性+公开性，保证一种fairness
2. 还得抗女巫攻击和抗这种double spend
3. 账本结构就是UTXO，这种结构就是

• 以太坊- 就是一个全球时间戳的状态转换机，他把这个状态函数给可编程了

1. 就是以太坊就是StateDB肯定是很大的，所以为啥就是要搞成这种POS，就是为了扩容
2. 这里面三种方法，就是作恶就惩罚你，然后三层安全链，POW
3. 这里面有个finality瓶颈, 就是一层层下来，就是Finality
4. 检查区块的时间戳是否大于引用的前一个区块的时间戳，并且在将来不到15分钟内

状态存储着关于过去的信息，可反映从系统开始到现在时刻的状态变化。状态即可归纳为4 个要素：

1. 现态：当前所处状态。
2. 条件：又称为“事件”。当一个条件被满足，将会触发一个动作，或者执行一次状态的转移。
3. 动作：非必要要素，是条件满足后执行的动作。动作执行完毕后，可以迁移到新的状态，也可以保持原状态。当然满足条件后，也可以不执行任何动作，直接迁移到新状态。
4. 次态：条件满足后要迁移的动作。”次态“是相对于”现态“，”次态“一旦被激活，将转移为新的”现态“。

• Solona- 就是一个全球时间下的分频段并行处理机器，他的核心就是突破一种瓶颈

• Solona的问题，就是处理这种有逻辑顺序的交易 其实会出问题？
• 还有就是leader的问题，就是拆分的太厉害的话，leader挂了就很麻烦。
• Hetu- 就是一个全球时间戳下的，分频段，并行处理，矩阵状态转换机

本质就是物理时间+逻辑时间，是不是可以这么说，就是多出一个维度的扩展性可能而已。

• 第一种性能就是1s处理的transcations
• 第二种性能就是1Ls处理的transcations，理论上来说一个逻辑时间下的吞吐量是可以无限的

如果我们说，目前物理时钟就是客观共识，那么我们这种主体间共识就是为了辅助这种客观共识的Finality而出现：

• 主要功能就为客观共识网络带新能量，更flexible针对对象的Finality Guarantee
• 当然还为这种客观性网络提供强大的Hyperscalablity
• 为客观共识网络提供必要的抗审查为基础的一些另外一种见证性安全

我们可以简单的把消息分成几种

1. 交易类和非交易类，比如Transactions和Intents
2. 就是 有没有逻辑顺序，比如说NFT Mint很多时候就本身有时间顺序，有些是就是没有的，时间顺序本身就是一个很简单的带逻辑（物理时间）顺序的交易

• 归类，分流，预确认，并行处理，可能是我们的三大特点

类似就是这样的，就是我们会根据虹桥的火车站/机场来看，就是提前让大家领号，这种提前领号有一些好处

• 第一号之间可能时间顺序或者逻辑顺序，在队列内，一家人可以放在一起处理
• 第二这种提前取号，本身是有拓展性的，完全可以快速快速形成相对的顺序
• 第三种就是提前领号，可以对batch进行归类，不同目的的可以分成不同batch，最简单的就是，可以立刻处理成去虹桥机场
• 第四种就是有些人，本身就是只想要个站台票，其实直接可以给了，不需要去窗口来进行排队了，因为他们本身不占有限的BlockSpace

然后呢，就是当排队买票的时候，按照不同类的号和队列来重新排队：

• 第一 就是这种重新排队，是带了大屏幕的，就是“有限的公正性”，类似飞机先叫G1类，然后G2，就是队列和队列只是相对的一种顺序，而不是绝对的，有限的公正性
• 第二 就是当然也是可以并行的，就是G1-G5先来，然后xxxx再来、
• 第三 就是这种因为处理对象是针对了这些队列，这样就是肯定还可以自动匹配给不同的窗口，这样也是增大效率的

接着就是第三窗口出票了，就是这个问题：

• 要进行一次确认，就是要确认这个票是你这个ID买的
• 有了号基本上也不太用就是现场再看身份证了，就是直接贴上就行
• 当窗口其实数量也可以完全不同，就是每一秒，究竟是有多少窗口再处理也很关键

第四步就是类似售票员盖时间章，为啥要盖时间章，就是防止票造假，最终性：

• 在任何一个火车站都可以查这个章是不是真的，就是增大造假成本
• 就是查验方法也是可以多种，就是自动和手动两种方案
• 就是这个时间章和挂号连在一起的好处，就是还可以
• 类似我们可以用比特币和以太坊来确定这个最终性，然后拿到Timestamp防造假

============================================

1. 客户端COS状态输入（Causality Object因果对象，这个部分是可以编程的）
2. H1 预排序分成COSA1和COSB1类，对象是消息，Type1交易和Type2非交易，COSB类直接预处理和分类撮合，成状态COSB2输出，Witness Tower类DAG+TEE+VLC方案
3. COSA1Batch排序，分开COSABatchL（有逻辑关系可因果timestamp的交易）和COSABatchN（无因果Timestamp关系交易），并串行化抗审查执行
4. COSA1异步共识全球因果HLC时钟决定确认LCFinality，然后Merge，（Restaking/Wstaking/POCW）
5. 分不同的COSBatchL串并行执行Merge后丢给H1去执行或者以太坊去最终确认状态
6. 客户端COSA2状态输出（COS因果对象）

==========================================

1. 垂直，就是类似就是提升这一个节点的利用率和处理能力，比如并行方案
2. 模块化 倾向于水平，就是比如把工作分散到更多节点来增加处理量
3. 多维拓展，就是我们完全可以变化Block的时间戳，让水平和垂直同时来拓展

=========================================

• 第一个维度，就是改变对象，类似Solona或者Sui的这种，公交车买票法，通过区分交易，来串行和并行计算
• 第二个维度，就是改变共识，类似Solona那种，就是共识提前确认，就是在上链之前，就已经确认了这种交易了，上链就是状态同步
• 第三个维度，就是改变排序，类似就是SUI这种，直接就是重新划组了，就是
• 第四个维度，就是改变

1. Global Timestamp， 类似VDF的东西
2. Sequencer pre-confirmation
3. Witness Clock tower

• 这里面有很多新的东西，一种就是水平扩容，就是把并行进行到底
• 还有一种就是垂直扩容，就提升容量，一秒内的方案，类似layer2这种
• 其实就是提前拿号
• 根据号（对象/Intent）之间的逻辑来进行提前分组
• 然后并行检查
• 不同车辆送往目的地

SUI的对象

• 由一个地址拥有的对象（NFT 或可替换代币）
• 由其他对象拥有的对象（例如，在游戏 NFT 中，剑 NFT 可以由头像 NFT 拥有）
• 任何人都可以读 / 写的共享对象（去中心化交易所或拍卖合约）
• 没有独家所有者且只读的不可变对象（拍卖结束后，拍卖被冻结为不可变）
• 所有者、对象 ID、类型、版本、最后一个交易摘要

=======================

打个比方，这就像是坐公交车。在传统区块链上，所有乘客必须排队（共识）上车，每一位乘客都需要在发车前检票（执行），然后再于同一个地点下车（默克尔树更新），只有当公交车再次空开之后才能继续容纳新乘客，链才能继续向前运行；而在 Sui 之上，链会根据目的地（对象）对所有旅客进行分组，各组旅客的票都会并行检查，然后再由不同的车辆并行送往目的地。

其实首先就是，对于用户角度来说，拿到提前的交易预确认才是核心，就是已经确认了就好，State端的Finality其实用户感受不到。

• 可以类似SUI，就是分成复杂交易，和简单交易
• 类似把复杂交易扔到H0
• 简单交易给放到H1

========================================

1）第一条方案就是类似 “交易” 分成两种，简单和复杂的

2）第二条方案就是说类似“交易数据类型进行区分

3）第三种方案就是类似交易用”世界状态“+”区块“这种逻辑来进行

给分布式系统中每个事件分配一个HLC，比如e事件的HLC记作 l.e，HLC保证能够满足以下四个性质：

1. 如果 e 事件发生在 f 事件之前（e happened before f），那么 l.e 一定小于 l.f，也就是满足因果关系。
2. l.e 可以存储在一个整数中，不会随着分布式系统中节点数的增加而增加。（这点和向量时钟不一样，向量时钟会随着节点数的增加而增加）
3. l.e 的值不会无限增长。（这点和Lamport逻辑时钟不一样，Lamport逻辑时钟会无限增长）
4. l.e 的值和 e 事件发生的物理时钟值接近，| l.e - pt.e |的值会小于一定的范围。

• NTP 的一些缺点，无法完全满足分布式下并发任务的协调问题
  
  • 节点间时间不同步
  • 硬件时钟漂移
  • 线程可能休眠
  • 操作系统休眠
  • 硬件休眠

如果我们引入了 Vector Clock，我们可以实现多点写，如 Dynamo 论文中所示。

假设 Key K 有三个副本 k1, k2, k3（目前是一样的），分别位于 M1, M2, M3 三台服务器上面，现在因为某种故障，导致了网络分区，三台机器均不能互相通信，但是每台机器仍然能够和客户端保持通讯。

其中 k1 副本被 client 1 持续更新，k2 副本被 client 2 持续更新。当三台机器之间互相通讯恢复的时候，进行副本同步时，应该保留哪个版本？如果只保留 k2，即采用 last write win 机制，那么同步后，client 1 会发现它写的数据丢了。

这个时候就需要 Vector Clock，更确切的说是 Version Clock（Dynamo 中是这么说的）。

为了处理这种场景，Dynamo 使用 Version Clock 来捕获同一份数据（Object） 的不同版本之间的因果关系（causality）。每个 Object 的每个版本会有一个相关联的 Version Clock , 形如 [(serverA, counter), (serverB, counter),...]， 通过检查同一个 Object 不同版本的 Version Clock，可以决定是否可以完全丢弃一个版本，仅保留另外一个版本，还是需要将两个版本进行合并（merge）。如果 Object 的版本 A 的 Version Clock 中的每项 (server, counter) 在版本 B 的 Version Clock 中都有对应项，并且 counter 小于等于版本 B 中对应项的 counter，那么这个 Object 的版本 A 可以被丢弃，否则需要对两个版本进行 merge。

回到刚才的例子，k1 被更新，Version Clock (注:此处假设 k1/k2/k3 三个副本之前一模一样) 为[(M1, 1), (M2, 0), (M3, 0)]，k2 被更新，Version Clock 为[(M1, 0), (M2,1), (M3, 0)]，随后 k1 和 k2 网络通了，他们通过比较两个 Version Clock 发现两个 Version Clock 存在冲突，且不存在对方每一项 Logic Clock 小于自己的 Logic Clock，那么就两个版本都保留，当客户端来读 Key=K 的时候，两个版本的数据和对应的 Version Clock 都返回给客户端，由客户端进行冲突合并，客户端进行冲突合并后写入Key K的时候，带着合并后的 Version Clock [(M1, 1), (M2, 1), (M3, 0)] 发到M1 和 M2 两台机器，覆盖服务器版本，冲突解决。