[Transaction & Stata & Pre-confirmation] 链上交易体验的另一个最后一公里
在数据库系统中，Transaction（事务）具有特殊意义：要么全部成功、要么全部失败，确保状态一致性。
区块链系统本质上也是如此。一笔交易（Transaction）要么更新全局状态（Root State），要么被丢弃、回滚。
说这些基础定义，是为了引出一个核心问题：一笔链上交易究竟在什么时候才算‘被确定’了？
按照正常的理解：只有当交易被打包进区块，且这个区块已经被回滚/分叉的概率小于某个值的时候，我们才说这笔交易被确定下来了。
这当然绝对的正确。
但对于链上冲浪类产品来说，这却是个体验痛点，得先等交易被打包进区块，再等几个确认块。以ETH为例，这一流程可能就要耗掉几十秒。很多用户的需求其实很简单：点了trade按钮的那一刻，就想马上买进/卖出。
这种方案有点似乎有点跟不上人民群众链上冲浪的极致速度的追求了。每次到了提及链上交易体验的时候，Sol总是位列前茅。快，就是用户体验好。
那有什么奇技淫巧是可以救一救的么。
Lamport大爷说过：Time, Clocks, and the Order
Builder 和 Validator 掌控着链上时间线，决定了每笔交易的排序，而排序又直接影响最终的链上状态和价格走向。
一个乐观的假设是：一个交易还没有被打包进区块，但是如果它已经确定的会被打包到下一个区块中。那么某种程度上说，这笔交易就是基本确定的了。因此在排序阶段，我们其实是可以推演出未来State的走向和链上价格变化的。（MEV Searcher们已经研究透了）
事实上，分叉的概率是远小于不分叉的概率的。如果愿意产品们愿意赌一把的话，完全可以带给用户链上下单即成交的体验（事实上还没成交，在未来大概率能成交）。
当然，最后又是那个哲学问题了：
古尔丹老师，代价，是什么呢？
