放宽条目约束

该提案建议移除区块内交易条目之间不能存在冲突的约束,以简化协议并提升灵活性。在新的设计中,允许冲突的交易以顺序执行,并明确条目的结构和约束,以便更灵活地进行块生产,也说明了与当前协议的向后兼容性。

概要

移除交易条目不能包含冲突交易的限制。

动机

当前交易条目中的交易必须互不冲突的限制是不必要的。 这是一个限制,使当前的 labs-client 实现变得更容易,但并不是协议正确运行所必需的。 移除这个限制简化了协议,并在区块生成和区块验证的实现中提供了更多的灵活性。

考虑的替代方案

  1. 什么都不做
    • 这是最简单的选择,因为我们可以让协议保持不变。 然而,这使得协议比实际需要的复杂。
  2. 移除限制,但按优先级执行冲突交易。
    • 这是一个比当前提案更复杂的选项。
    • 它也给予区块生产者更少的灵活性,因为交易将被重新排序。

新术语

冲突交易定义为下列交易之一:

  1. 两个交易都需要对同一账户进行写锁定,或
  2. 一个交易需要写锁定,而另一个交易需要对 同一账户进行读锁定。

tick条目定义为不包含任何交易的条目。

详细设计

目前,如果区块中的交易条目包含冲突的交易,则整个区块标记为无效。 提案是完全移除该限制,并允许条目包含互相冲突的交易。

如果条目中的交易相互冲突,则必须按出现的顺序依次执行。 这一决定给予区块生产最多的自由,因为它允许区块生产者在条目内对交易进行任意排序。

如果提案被接受,则每个条目的约束如下:

  1. 每个条目必须通过 bincode(或等效方式)可反序列化为一个结构:

    struct Entry {
      num_hashes: u64,
      hash: Hash,
      transactions: Vec<VersionedTransaction>,
    }

    其中 HashVersionedTransactionsolana-sdk 中定义。

  2. tick条目仅在所有条目的 num_hashes 总和(包括tick条目本身)与 Bankhashes_per_tick 字段相匹配时有效。该值在功能网关中可能会变化,但当前为 12500。这意味着如果一个tick条目的 num_hashes 字段超过 Bankhashes_per_tick 字段,则该条目无效。

如果违反这些约束中的任何一项,则整个区块无效。

影响

  • 协议得到简化
  • 区块生产更加灵活

安全考虑

该提案改变了协议,并可能破坏共识。 该提案将需要一个功能网关,以便所有验证者能够同时改变行为。

缺点

没有超出上述安全考虑的缺点。

向后兼容性

该提案与当前协议向后兼容,因为它仅放宽限制,而没有添加任何新限制。 所有先前有效的区块仍将有效。 然而,新的生成的区块在旧协议下可能不再有效。

  • 原文链接: github.com/solana-founda...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
solana-foundation
solana-foundation
江湖只有他的大名,没有他的介绍。