最近两周我在研究BTC生态和各种铭文项目的时候，发现很少有文章能够清晰地把原理和技术细节介绍的清楚：比如铭文在铸造的时候，交易是如何发起的，UTXO里面的sats到底是怎么被追踪的，铭刻的内容到底是放在脚本什么地方，以及BRC20在转账的时候为何需要两次操作？我发现不了解这些技术细节，就很难搞明白BRC20,BRC420,atomicals,stamps,符文Runes这些各种协议的区别，本文将深入到BTC区块链的基础知识，试着回答上述问题。
区块链本质是一种多用户记账技术，用计算机科学术语来说，是一种分布式数据库，每一段时间内的记录（账目）组成一个区块，然后根据时间先后顺序进行账本扩展。
我们用excel做了表格来说明区块链的工作原理。一份excel文件代表了一个区块链，其中每一个单独表格表示一个个区块，区块按照时间顺序从560331，560332.一直到最新的560336.560336会在区块内打包最近的交易。区块内部主体部分就是我们在会计领域最常见的复式记账法，一边地址记做借出（debit）就是inputsfrom，另一边地址记做贷入（credit）就是outputsto。Value对应相应地址的BTC数量。Inputs的币的数量会大于Outputs币的数量，差额就是用户层面的转账费，也是矿工（记账人）的取得的手续费。区块头部会获取上一个区块高度，上一个区块的哈希值，本区块的建立时间（时间戳），和随机数。那么做为去中心化的记账技术，到底是谁来抢到下一个区块的记账权呢？靠的就是这个随机数和与之对应的哈希值。拥有算力的矿工通过对当前区块的随机数进行哈希计算，最先得到符合条件哈希值的矿工拥有下一个区块的记账权并且赢得区块奖励和转账费。最后是脚本区域，可以用来做一些扩展应用，比如脚本op_return可以当做附言栏。需要注意的是，在实际的区块中，脚本区是附着在input和output信息中的，而不是真的另外单独一个区域。比如附着在input的脚本是解锁脚本（ScriptSig），需要钱包地址进行私钥签名授权允许转出，而附着在output的脚本是锁定脚本（ScriptPubKey），用来设置收到该BTC的解锁条件（一般情况条件就是有相应私钥的人才能消费）。
上面两张图是原始的input和output的数据结构表，在执行层面，脚本表现为交易信息的附带参数，其中解锁脚本（ScriptSig）因为需要私钥授权，也被称为见证数据（witnessdata）。
尽管比特币网络已经运行了超过10年，没有发生过什么显著的事件，但曾多次出现交易成本飙升到不再可行的高点。因此，比特币的开发人员一直在讨论如何最好地扩展网络，以处理未来不断增长的交易量。
2017年，这场辩论达到高潮，比特币开发社区分裂成两派，一派是支持使用软分叉实施名为SegWit的功能，另一派是支持直接区块扩容的大区块派。
我们在上文提到了解锁脚本需要用到私钥授权生成见证数据，那么是不是可以把这个见证数据从区块中分离，从而变相增加每个区块可容纳的交易数呢？隔离见证（SegregatedWitness）在2017年8月激活正式激活。它的实现方式正是将所有的交易数据分为两部分，一部分是交易的基本信息（TransactionData），另一部分是交易的签名信息（WitnessData），并把签名信息保存在一个新的数据结构中，是被称为隔离见证（witness）的新区块中，并与原始交易分开传输。
在技术上，SegWit的实施意味着交易不再需要包括见证数据（不会占用比特币原本为区块安排的1MB空间）。取而代之的是，在一个区块的末尾，为见证数据创建了一个额外独立的空间。它支持任意的数据转账，并有一个折扣的区块重量（blockweight），巧妙地将大量的数据保持在比特币的区块大小限制内，以避免硬分叉的需要。这样，比特币交易的交易数据大小提高了上限，同时降低了签名数据的交易费用。在SegWit升级之前，比特币的容量上限是1MB，而SegWit之后，虽然单纯交易的容量上限仍旧是1M，但隔离见证空间的大小达到了4MB。
Taproot于2021年11月实施，由3项不同的比特币改进提案(BIP)组成，其中包括：Taproot、Tapscript及其名为「Schnorr签名」的全新数字签名方案。Taproot旨在为比特币用户带来诸多好处，例如提升交易私密性和降低交易费用。还将让比特币执行更多复杂的交易，从而拓宽应用场景（新增加了一些操作码opcodes）。
这些更新是OrdinalsNFT的关键推动因素，它将NFT数据存储在Taproot脚本路径的花费脚本（spentscript）中（见证数据空间）。这次升级使得结构化和存储任意的见证数据变得更加容易，为ord标准奠定了基础。随着数据要求的放宽，假设一个交易可以用其交易和见证数据填满整个区块--达到4MB的区块大小（见证数据空间）限制--极大地扩展了可以放在链上的媒体类型。
也许有人会问，既然在脚本中放入一些字符串，那对这些字符串没有限制条件吗？万一真的执行这些脚本呢？如果随便放内容，那会不会出现错误代码拒绝出块呢？这就要提到OP_FALSE指令。OP_FALSE（在比特币脚本中也表示为0）确保脚本语言中的执行路径永远不会进入OP_IF分支，并保持未执行状态。它充当脚本中的占位符或空操作（NoOperation），类似于高级语言中的注释，来保证后续的代码不被执行。
以上都是从计算机数据结构方面来研究BTC的基本原理，我们再从金融模型方面来讨论一下UTXO模型。
UTXO是UnspentTransactionOutputs的缩写，中文翻译是没有花掉的交易输出，实际可以理解为在一次转账时剩余没有转出的资金。那比特币为啥要使用这么一个概念呢？这就要从记账方法的账户交易模型和账户余额模型说起了。
因为我们在中心化的体系待的太久，已经非常习惯账户余额模型的记账方式。当用户A给用户B转100块钱时，银行会先检查A的银行账户上是否有100元，如果有就从A的账户里扣除100元再在B的账户上加上100元，这样一笔转账就完成了。
然而，比特币的记账算法里没有余额这个概念。在区块链的分布式账本上记录的只有一笔笔的交易，并不会直接记录一个账户当前余额是多少（记录余额一般需要专门的服务器节点来记录，那就中心化了）。假设当前用户A余额是1000元，如果用户A给用户B转100元，这笔转账会被记录成：
交易1用户A给用户B转账100元
交易2用户A给用户A自己转账900元（UTXO）
这里的交易2虽然是一笔交易，但从功能上来说他担当了账户余额的作用，表示在完成这笔100元转账后A的账户上还剩余900元。
那么问题来了，为啥非要造一个这样的UTXO呢？因为在BTC区块链上只能记录交易，没法记录账户余额。如果没有这个UTXO的话，要计算余额需要把一个账户的所有交易的入账和出账全部累加一遍，这是个非常消耗时间和计算资源的事情。而UTXO的出现巧妙的避免了在计算余额时要回溯所有交易的痛点问题。
UTXO有个特点，就是跟硬币一样，不能掰开用，那么交易过程中如何凑够输入金额，又如何找零的呢？我们可以用硬币来做类比（实际上每次当你看到UTXO这个单词的时候请自动翻译成硬币比较好）。
小明给小刚转账1比特币。整个过程是这样的，小明要收集足够的input，比如小明的地址对应的以往交易中，找到了一个面值为0.9的UTXO，不够1比特币，好在交易中是允许有多个输入的，所以小明又找到了一个面值0.2的UTXO，这样在这次转账的交易中，就会有两个输入。同时输出也会有两个，一个是指向小刚地址，面值是1比特币。另一个指向小明自己的地址，面值是0.1比特币，这个输出就是找零了（这个例子忽略了gas）。
换句话说，小明口袋里面有两个硬币，一个面值0.9，另一个面值0.2，此时小明需要支付面值1的硬币，就需要同时把这两个硬币递给小刚，小刚收到后找零0.1给小明。所以这个记账模型的本质就是通过找零的动作来避免了计算余额。
Ordinal协议可以说是本轮BTC生态爆发的源头，是把同质化的BTC分解成最小单位sat，然后对每一个sat标记一个序号。那是怎么做的呢？
我们知道，BTC的总量是2100万枚，一枚BTC最小可以拆分到一亿份（sat），所以BTC的最小单位就是sat，这些BTC也好，最小单位sat也好，都是典型的同质化代币FT。我们现在试着给这些sats分配一个序号（ordinal）。
前面在谈到区块数据结构的时候，我们提到交易信息需要注明input的地址和数额以及output的地址和数额。而每个区块是包含了两部分交易：BTC出块奖励和转账的手续费。手续费交易必然有input和output，但出块奖励因为是凭空生成的BTC，无input地址，所以这个inputfrom的字段是空白的，也叫做coinbase交易。BTC总量的2100万枚都是来源于这个coinbase交易，也是所有区块中交易列表排列在第一位的。
Ordinal协议规定如下：
编号:每一个sat以他们被开采出来的顺序进行编号
转移:按照先进先出规则，从交易的输入转移到输出
第一条规则相对简单,它决定了编号只能由挖矿奖励中的coinbase交易生成。例如，若第一个区块的挖矿奖励为50个BTC，则第一个区块会分配出[0;1;2;...;4,999,999,999]范围的sats；第二个区块奖励也为50BTC时，则第二个区块会分配出[5,000,000,000;5,000,000,001;...;9,999,999,999]范围的sats。
以上就是Ordinal铭文协议的原理与技术细节讨论的全部内容，望能这篇Ordinal铭文协议的原理与技术细节讨论可以帮助您解决问题，能够解决大家的实际问题是非常好学习网一直努力的方向和目标。