该提案建议移除区块内交易条目之间不能存在冲突的约束，以简化协议并提升灵活性。在新的设计中，允许冲突的交易以顺序执行，并明确条目的结构和约束，以便更灵活地进行块生产，也说明了与当前协议的向后兼容性。
概要
移除交易条目不能包含冲突交易的限制。
动机
当前交易条目中的交易必须互不冲突的限制是不必要的。
这是一个限制，使当前的 labs-client 实现变得更容易，但并不是协议正确运行所必需的。
移除这个限制简化了协议，并在区块生成和区块验证的实现中提供了更多的灵活性。
考虑的替代方案
- 什么都不做
- 这是最简单的选择，因为我们可以让协议保持不变。
然而，这使得协议比实际需要的复杂。
- 移除限制，但按优先级执行冲突交易。
- 这是一个比当前提案更复杂的选项。
- 它也给予区块生产者更少的灵活性，因为交易将被重新排序。
新术语
冲突交易定义为下列交易之一：
- 两个交易都需要对同一账户进行写锁定，或
- 一个交易需要写锁定，而另一个交易需要对
同一账户进行读锁定。
tick条目定义为不包含任何交易的条目。
详细设计
目前，如果区块中的交易条目包含冲突的交易，则整个区块标记为无效。
提案是完全移除该限制，并允许条目包含互相冲突的交易。
如果条目中的交易相互冲突，则必须按出现的顺序依次执行。
这一决定给予区块生产最多的自由，因为它允许区块生产者在条目内对交易进行任意排序。
如果提案被接受，则每个条目的约束如下：
-
每个条目必须通过 bincode（或等效方式）可反序列化为一个结构：
struct Entry {
num_hashes: u64,
hash: Hash,
transactions: Vec<VersionedTransaction>,
}
其中 Hash 和 VersionedTransaction 在 solana-sdk 中定义。
- tick条目仅在所有条目的
num_hashes 总和（包括tick条目本身）与
Bank 的 hashes_per_tick 字段相匹配时有效。该值在功能网关中可能会变化，但当前为 12500。这意味着如果一个tick条目的
num_hashes 字段超过 Bank 的 hashes_per_tick 字段，则该条目无效。
如果违反这些约束中的任何一项，则整个区块无效。
影响
安全考虑
该提案改变了协议，并可能破坏共识。
该提案将需要一个功能网关，以便所有验证者能够同时改变行为。
缺点
没有超出上述安全考虑的缺点。
向后兼容性
该提案与当前协议向后兼容，因为它仅放宽限制，而没有添加任何新限制。
所有先前有效的区块仍将有效。
然而，新的生成的区块在旧协议下可能不再有效。
