🗒️#059 关于铭文号的稳定性提案解读
type
status
date
slug
summary
tags
category
icon
password
ordinals作者casey的提案：
https://github.com/ordinals/ord/discussions/2458#discussioncomment-7052170
主要是讨论了关于铭文（inscriptions）编号的稳定性和可变性的问题。最初，铭文编号被引入用于标识铭文的创建顺序，从创世铭文开始，编号从零开始递增。然而，随着对协议的经验积累，保持稳定的铭文编号变得更加困难，并带来了一些不可取的后果，因为铭文协议的更改会对编号产生影响。
当铭文协议最初引入铭文编号时，目的是为了稳定地标识铭文的创建顺序。然而，随着对协议的进一步实践和经验积累，维护稳定的铭文编号变得越来越困难，并且引入了一些不可取的后果。因此，提出了让铭文编号永久不稳定的建议。
现有的稳定铭文编号面临着一些挑战和问题。例如，当协议进行更新以允许在单个交易中创建多个铭文时，不同实现的铭文编号会有所不同。这就导致了不同实现之间的铭文编号不一致。
为了解决这个问题，引入了“cursed inscriptions”和负数编号的概念。当旧版本无法识别新的铭文时，会给这些铭文分配负数编号，以保持旧编号的稳定性。然而，“cursed inscriptions”和负数编号也带来了一些问题，包括铭文编号不再反映创建顺序、逻辑复杂性和需要协调的问题。
“cursed inscriptions”和负数编号存在一些问题：
- 铭文编号不再表示铭文创建的顺序。
- 跟踪哪些铭文是“cursed”的逻辑会增加错误和复杂性。
- 对“cursed inscriptions”进行“blessing”，即在某个区块高度之后决定不再将某些“cursed inscriptions”分配负数编号，而分配正数编号，需要协调。
- “cursed inscriptions”编号是永久不稳定的，即使在现行状态下，大量铭文编号已经不稳定。
作者观点
因此，提议让铭文编号永久不稳定，并对所有“cursed inscriptions”进行“blessing”，即将它们合并到主序列中。这样做可以简化代码库，使实现分配相同序列编号的实现更加容易，并且有利于未来的协议更改。
需要注意的是，这种改变会导致铭文编号的变化，但并不会完全消失。新的铭文编号将与旧的铭文编号非常接近，可能只有很小的差异。
其他观点
金狗博士DrJinglee @ordjingle我将投反对票并且不同意该提案。1%不稳定通常还可以认为是稳定编号。然而，我相信大多数社区用户现在都认为铭文是一成不变的，包括编号。通过引入“被诅咒”的铭文，我们看到协议团队已经尽力维持编号系统的稳定性。协议团队应该表现出一致性，试图保持编号永远稳定，误差小于 1%。对于重新编号和多重编号等，采用新的编号系统添加到当前编号系统可能会有所帮助，例如子编号或特殊标签......再次强调，1%的编号误差仍然是稳定的编号系统。
金狗博士强调了铭文号稳定的重要性，社区用户的习惯的认同铭文号固定不变，维持小幅度的可变是可以接受的，但是金狗博士不认同铭文号重新编排。
我的观点
我的观点不是支持或者反对，任何结果被通过我都是可以接受的，以下是我想罗列出来的几个个人想法
其实一直以来，ordinals铭文不变的是铭文id，就是很长的那一串字符，铭文号是为了方便好记忆，才引入的，估计作者也没想到会有这么多的意外状况出现
其实从诅咒铭文开始，铭文号系统就已经不是一成不变的了，期间也出现过多次重新索引的情况。
铭文是永久不变的，铭文号变动我认为也不会改变oridnals系统的稳定性，只是看起来铭文号变了，社区用户容易误解。
关于铭文号的稀缺性，其实我一直是存在疑问的，早期总铭文只有几十万的时候，每次整数铭文，大家都会盯着浏览器，看是哪个幸运儿抢到了这个铭文号。现在随着brc-20的发展，把铭文号扩充到了三千万，以后可能会更高，以前的靓号已经被淹没在三千万铭文里了。
投资要慎重，大家当初花重金铸造的负数铭文，很可能因为作者的一个想法就归零了。
🤗 总结
总的来说，这个建议旨在提高协议的灵活性和可维护性。然而，在做出决策之前，需要仔细考虑这种改变的影响和潜在的挑战，特别是在协调和向后兼容性方面。
作者Casey给出了改变铭文号的理由，虽然不能完全被接受，但是也是出于ordinals的发展考虑。其实我个人更偏向于彻底改变铭文编号系统，更加全面的兼容父子铭文等功能特征。
Loading...