升级比特币共识引擎：核心开发者Sedited详解Bitcoin Kernel

大家好。

Hello, everybody.

我是Shinobi，Bitcoin杂志的技术编辑，今天和Seredid一起，他是一位参与Kernel项目开发的Bitcoin核心开发者。

I am Shinobi, technical editor at Bitcoin Magazine, joined by Seredid, a Bitcoin core developer contributing to the Kernel project.

所以Seredid，Kernel项目有着一段漫长而复杂的历史。

So Seredid, there's a little bit of a long tangled history to the Kernel project.

多年前，曾经有一个lib_consensus项目。

Years ago, there was the lib consensus project.

这个项目试图将所有的共识规则提取出来，迁移到一个完全独立的外部库中，使其能够像其他软件库一样被独立调用和使用。

So attempting to actually take all of the consensus rules and move them to a totally external library that could just be called, used independently on its own, like any other software library.

后来这个项目逐渐被Kernel项目取代，后者不再试图成为一个完整的库，而是专注于将Bitcoin守护进程中的共识逻辑分离出来，以便能够独立地、逐粒度地调用这些功能，而无需像核心代码那样必须经过完整的验证流程。

And that project kind of got sunsetted in favor of the Kernel project, which as opposed to trying to become a full library, is looking at just isolating kind of the consensus logic in the Bitcoin daemon so that you can call it independently, or, like, granularly, bit by bit from that program running rather than having to go through the whole validation flow as it's implemented in core.

你能谈谈为什么所有努力都从lib_consensus项目转向了Kernel项目吗？背后的逻辑和原因是什么？

You kind of want to talk a little bit about why all the efforts switched from the lib consensus project to kernel and kind of the logic and the reasoning for that?

是的，当然可以。

Yeah, sure.

最初，目标只是隔离一小部分共识逻辑，具体来说，最初的一致性库只暴露了脚本解释器。

So when it started out, the initial goal was to just isolate a very small subset of the entire consensus logic, and specifically it was only the script interpreter that was surfaced through the original consensus library.

一些项目确实集成了它，但它的受欢迎程度非常有限。

And some projects did integrate this, but the traction it got was pretty limited.

这有多方面的原因，但我认为最主要的是，它给使用该库的程序员带来的便利太少。

And this had a multitude of reasons, but I think the main one was that it just didn't give enough leverage to the programmers using the library.

而且它的功能集也非常有限。

And its feature set was also pretty limited.

扩大原始库范围的主要问题是，当时比特币核心内部的代码并不适合这样做。

And the main problem with expanding the scope of the original library was that the code within Bitcoin Core just wasn't suitable for that at the time.

因为所有内容都与完全无关的功能（如图形界面或钱包）紧密耦合，几乎不可能逐个地暴露更多的验证逻辑。

So because everything was so very tightly coupled with completely unrelated functionality like the GUI or the wallet, it was basically impossible to surface more validation logic that just did one thing at a time.

确实，从最初发布比特币共识代码以来，花了很长时间才将内部代码调整到如今的状态，我们现在终于可以为使用该库的开发者提供更多灵活性，以及超越仅验证脚本的功能。

And yeah, it just took a lot of time since that original, the Bitcoin consensus release to get the internal code into a state where we can now finally add a bit more, let's say, flexibility for the developers using the library and features beyond just verifying scripts.

你之前特别问过，Libbitcoin共识和新的Libbitcoin内核之间的分界点在哪里。

And you were specifically asking before where, like, the cut between the Libbitcoin consensus and the new Libbitcoin kernel happens.

而主要区别在于，Libbitcoin 内核的功能是有状态的，它们会维护直接分配在硬件上的系统资源。

And the main difference there is that the Libbitcoin kernel functions are stateful, so they maintain system resources that are allocated on the hardware itself.

它包含了典型比特币节点所具备的所有数据库功能。

It has all the database functionality that a typical Bitcoin node would have.

通过原始的 Bitcoin 共识架构来暴露所有这些功能几乎是不可能的。

And surfacing all of that through the original Bitcoin consensus architecture was basically impossible.

而这也是必须弃用它的原因。

And, yeah, that's why the step had to be taken to deprecate it.

所以，正是因为共识机制将脚本之外的太多东西纠缠在一起，导致在尝试将该库与 UTXO 集或区块数据库等共识关键组件的其他实现交互时，会出现不可预测的问题。

So it's just, you know, because consensus entangles so many things outside of script, it's just, like, unpredictability in terms of how trying to apply that library interacting with, alternate implementations of consensus critical things like the UTXO set or a block database, like, that that kind of issue.

你可以隔离脚本规则，但无法真正保证共识过程中其他所有需要涉及的部分都能正常运作。

Like, you you can isolate the script rules, but you can't actually guarantee that the rest of everything that needs to be touched in the consensus process will behave properly.

是的，完全正确。

Yeah, exactly.

所以，理论上，如果你非常非常谨慎地用手动复制的桩函数剔除所有无关功能，它本来是可能行得通的。

So I guess it would have theoretically worked if you would have been very, very careful to, like, patch out all the unrelated functionality with, like, stub functions that you manually copy in.

但一旦你这么做，发布起来就太麻烦了。

But once you're doing that, yeah, it's too much of a hassle to release.

对吧？

Right?

是的。

Yeah.

如果你本来就要这么做，直接拿现有代码整体使用就行了。

You could just take the current code wholesale if that's what you're doing anyway.

是的，到了那个阶段，你就无法实现拥有一个已知、一致、可复现的共识规则集或实现的目标了。

Yeah, at that point you're not achieving the goal of having a known consistent reproducible consensus rule set or implementation that you need.

没错。

Exactly.

关键就在于，你每次只是想验证一个区块时，根本不需要像自闭症一样去修改代码，对吧？

The entire point is that you don't have to autismally interfere with the code every time you want to just verify a block, right?

我们只是想提供一个能正确执行逻辑的函数，让每个人都能以完全相同的方式调用它，并获得可复现的结果。

We just want to give this one function that does the logic correctly and everybody can just call it in exactly the same way and get a reproducible result.

嗯。

Mhmm.

那么，当初推动libconsensus以及现在Kernel项目的主要动机是什么？

So what was kind of the original impetus for, you know, lib consensus and now the Kernel project?

我的意思是，Bitcoin Core无疑是网络上主导的客户端。

I mean, Bitcoin Core is unquestionably the dominant client on the network.

任何认真的矿工要么运行Core，要么运行与Core在自定义行为或代码改动方面非常接近的版本。

Like, any serious miner is either running Core or running something very tightly related to core in terms of custom behavior or code based changes.

所有主要的企业、交易所都在运行Core。

All the major businesses, exchanges are running core.

既然如此，为什么还要投入大量时间和精力去剥离并隔离共识规则，以便它们能在其他地方使用，而不是继续专注于Core这个实现？

Like, why put so much time and effort into trying to strip out and isolate the consensus rules so they can be used somewhere else as opposed to just continuing to focus on core as an implementation?

是的。

Yeah.

所以我认为，最初的动机纯粹是出于哲学层面：我们不希望Bitcoin Core主导整个生态系统，并仅仅因为它们掌控了验证逻辑，就阻止其他节点实现获得同等的信任水平。

So I think initially the impetus was purely on a philosophical level where we don't just want Bitcoin Core to dictate everything to the entire ecosystem and kind of prohibit other node implementations from ever receiving the same trust level just because they kind of gatekeep the validation logic.

但不仅如此，内核对项目还有显著的好处，因为它清晰地划分了哪些是真正的验证代码，哪些不是。

But even beyond that, the kernel has like significant benefits to the project because it really clearly demarcates what actually is validation codes and what isn't.

而且，让外部使用更加友好，也会自动让我们的内部代码使用起来更方便，并让我们能更自由地对其进行实验，用它来编写自己的工具和实用程序。

And yeah, making things nice to use from the outside will automatically also make it nicer to use for our own codes and allow us to also experiment more freely with it, write our own tools and utilities with it.

是的，这为我们提供了极大的灵活性，也让我们在阅读代码和审查一些相当复杂的验证变更时更有信心。

Yeah, so it gives us a whole lot more flexibility and also confidence with reading the codes and doing reviews of, yeah, sometimes pretty complex validation changes.

嗯。

Mhmm.

那么，内核的实现对多进程分离的工作产生了怎样的影响？

So how has implemented kernel impacted or affected, the work towards multiprocess separation.

比如，长期以来，Core项目一直在努力清理代码库，使各项功能良好隔离，未来甚至可能将它们拆分成完全独立、彼此通信的程序，而不是维持单一的代码库。

Like, that's that's something, you know, for a similarly long time, Core as a project has kind of been trying to clean up, the code base so that things are nicely isolated, could potentially, in future, actually be separated into completely separate programs that talk to each other as opposed to, you know, one singular code base.

但这是一条漫长的路。

But it's it's been a long road.

这条路比lib共识和内核项目从Satoshi留下的那个庞大文件演变为今天这种更模块化、更清晰的代码库所走过的路要长得多。

Think a lot longer than, lib consensus and the Kernel project going from the giant file that Satoshi left everybody to, like, the much more modular clean code base that we have today.

是的，当然。

Yeah, definitely.

我会说，到目前为止，累计花在多进程项目上的时间可能更多。

I would say the time spent on either probably more time was spent on the multiprocess project cumulatively so far.

最初用于分离多进程代码的努力对内核也非常有帮助，但总体而言，这种分离现在已经基本完成了。

Initially the efforts that went into separating the code for multiprocess were also really useful for the kernel, but by and large that split is kind of done now.

比如在索引代码方面，我们确实还需要更清晰地分离一些部分，但这些已经不再直接影响内核了。

Like there are a few areas where we definitely still need to separate a bit more cleanly, for example for the indexing code, but that doesn't really directly affect the kernel anymore.

因此，内核已经是内部最核心的多进程二进制文件（即比特币节点多进程二进制文件）中的一个子组件。

So the kernel is already like one sub component of the innermost multiprocess binary or like Bitcoin the nodes multiprocess binary.

现在内核项目中的大部分组织工作，都已经发生在比特币节点多进程程序内部了。

And most of the organization that takes place now in the kernel project is within that Bitcoin nodes multiprocess program already.

所以这两个项目之间并没有太多协同关系。

So there's not really much of a symbiosis between the two.

它们只是各自独立推进，互不干扰。

They're just, yeah, on separate tracks and don't really interfere with each other.

是的。

Yeah.

只是在早期阶段有一些轻微的工作重叠，我想。

Just kind of a little work overlap, I guess, in the early phases

是的。

Yeah.

内核。

Kernel.

好的。

Okay.

你知道，我认为最初libconsensus内核项目的目标是让其他实现能够直接采用Core的共识逻辑，然后自行构建实现的其余部分，确保最关键的部分能够与网络的其他部分互操作。

You know, I think kind of the the original goal of, you know, lib consensus of Kernel project was to kind of enable other implementations to just take Core's consensus logic and then build out all the rest of an implementation themselves, knowing that the core thing that matters is going to be interoperable with the rest of the network.

从实际角度来看，这个项目离那个阶段还有多远？

Practically speaking, like how far from that stage is development for the project?

你觉得现在这样做安全吗？还是说我们还需要做一些基础工作才能真正达到那个阶段？

Like do you think that would be a safe thing to do now or is there kind of still some more groundwork to be laid before we're really at that point?

我认为现在这样做相当安全。

I think it's a fairly safe thing to do now.

我们现在正处于这样一个阶段：我认为有两个或三个项目正在尝试基于内核库构建完整的全节点。

We are at the point where there's, I think, two or three projects which are now trying to build out a complete full nodes around the kernel library.

我对此仍主要担心的是，这些阶段的划分和结束仍相当不成熟。

My main hesitation still with that is the splits and the end of phases for that are still pretty immature.

比如，我们可能需要再等待几个发布周期，才能说：好的，我们现在正式发布这个。

Like we probably want to wait a few more release cycles before we say, okay, we now officially release this.

它已经被大约十到二十个其他项目成功使用。

It has been used successfully by, I don't know, maybe ten, twenty other projects.

在过去半年里，没有报告任何重大漏洞，因为一旦进入生产环境，我们绝对不能出错。

No major bugs have been reported in like half a year because obviously we really can't mess this up once it hits production.

是的，我们确实必须对此非常谨慎。

Yeah, we definitely have to be very careful with that.

所以最近，我认为两周前，U3xO的其中一个实现Floresta集成了内核或内核库的一个子集。

So most recently, I think two weeks ago, Floresta, one of the U3xO implementations, integrated the kernel or a subset of the kernel library.

是的，这是Vintium在巴西资助的项目，对吧？

Yeah, that's the project Vintium's funding in Brazil, right?

对。

Yeah.

所以他们现在正在运行它，这相当酷。

So they're running it now, which is pretty cool.

而且他们也承诺会与我们合作并提供良好的反馈。

And they've also committed to working with us a bit and giving good feedback.

我们也会尝试将我们计划很快推送到Bitcoin Core的更改向上游提交给他们。

And we also try to upstream changes that we're planning to roll out to Bitcoin Core soon to them.

所以，是的，这一直是一种良好的协同关系。

So yeah, that's been a good symbiosis.

大家好。

Hey, everyone.

我是Shinobi，我现在站在芝加哥联储银行前，跟你们聊聊《Bitcoin Magazine》的核心议题。

It's Shinobi, and I'm here in front of the Chicago Fed to talk to you about the core issue of Bitcoin Magazine.

过去几年，开发者和比特币使用者之间出现了一些沟通上的断裂。

The last few years have been a bit of a communication breakdown between developers and people using Bitcoin.

比特币的存在是为了成为这种体制的替代品，但要做到这一点，需要人们积极地维护它。

Bitcoin exists to be an alternative to this institution, but to do that, it needs people to actively maintain it.

如果你真的想听听开发者本人是如何看待他们的工作以及他们选择做什么的，请访问 bitcoinmagazine.com，获取《核心特刊》。

If you actually want to hear from developers themselves, how they approach their work and what they choose to work on, go to bitcoinmagazine.com and get yourself a copy of the core issue.

好了。

Alright.

我想，我们或许应该尽量保持讨论的宏观层面。

And I guess, you know, we should probably try to keep this higher level.

但对一些好奇的观众来说，你能大致梳理一下现在被隔离到内核中的不同验证步骤吗？

But, you know, I I guess for some of the curious viewers out there, you think you can kinda, like, walk through the different validation steps that were in the, code base and isolated in the kernel now?

我不知道，也许可以谈谈其中哪一个最难隔离，或者哪个在代码库的不同部分中最为分散。

And I don't know, maybe kind of talk a little bit about which of those was maybe the toughest to kind of isolate or was sprawled the most across different sections of the code base.

是的，我可以试着讲一讲。

Yeah, I can try to do that.

所以从高层次来看，你从网络中获取一个区块，然后将其传递给内核库中的各个函数，这些函数会验证区块头。

So on a high level, you get a block from the network and then you pass that to various functions in the kernel library And those functions then validate the block header.

所以检查工作量证明、时间戳、前一个区块，以及默克尔根是否根据区块中的所有交易正确计算。

So check the proof of work, check the timestamp, the previous block, that the Merkle root is actually calculated correctly with all the transactions in the block.

嗯。

Mhmm.

一旦完成，就会将其提交到磁盘，或者更准确地说，写入磁盘。

And, yeah, once that is done, it commits it to disk or writes it to disk rather.

一旦完成，就会验证区块中所有交易及其脚本。

And once that is done, it validates all the transactions and all the scripts from the transactions.

因此，它会检查交易中每一个被花费输出的签名。

So it checks the signatures of every single spent output in the transaction.

是的，这基本上就是该逻辑高层级的运作概述。

So yeah, that's basically like the high level overview of what the logic actually does.

至于最具挑战性的部分，可能是将区块写入磁盘与实际验证之间的步骤。

In terms of what was most challenging was probably the step between writing a block to disk and doing the actual validation.

当时有一些回调钩子会回到图形界面，还有一些不必要的额外函数调用了钱包。

There were like a couple of callback hooks back into the GUI and some extra functions that called out to the wallet unnecessarily.

我个人需要处理的其实并不是特别复杂的东西。

It's not really too complicated stuff that I had to deal with personally.

但我也得说，当我三年前接手这个项目时，它已经处于相当成熟的阶段了，而在此之前，已经有过一系列多进程工作来清理这些问题。

But I also have to say at that point that when I took the project over three years ago now, it already was in a fairly mature state and that preceded, yeah, all the multiprocess work before it that cleaned that up.

一些是科里·菲尔兹最初在旧的Lipitcoin共识机制上做的工作，还有一些是卡尔·东做的。

Some of the work that Corey Fields did on the old Lipitcoin consensus originally, some of the work that Carl Dong did.

是的。

Yeah.

所以这其实是一个漫长的过程，大概持续了十多年，才走到今天这一步。

So it's really been this long process over, yeah, probably more than a decade to to get to this point.

是的。

Yeah.

你知道，当我看到像核心中的这些工作——比如libconsensus、之后的内核、多进程——投入了这么多精力时，我很难真正理解。

You know, it's It's kind of hard for me to reconcile looking at how much work has gone into things like this in core, like libconsensus, the kernel after that, multiprocess.

所有这些项目都已经持续了十年之久，其明确目标是开放这个项目，让更广泛的人群能够以不同方式使用它，或将它集成到其他系统中，甚至基于核心共识逻辑从头开始构建全新的系统——而这才是真正重要的部分。

All of these things that are decade long projects at this point with the explicit goal of opening the project, of making it easier for more people to do different things with it or to integrate it into something in different ways or even with Kernel itself to explicitly build something from scratch entirely around that core consensus logic that is really what matters.

如今，人们常常认为核心开发者就像高高在上的精英团体，试图将自己的意志强加于网络，或保留某种权力和影响力；但在我看来，实际发生的工作恰恰相反——我们正在努力放弃部分自身的权力和影响力，尽可能降低门槛，让其他人能够轻松接手并真正加以利用。

You know, with this attitude nowadays that core developers are like some ivory tower group from above just trying to force their will on the network or retain, like, some position of power or influence when the work I see is things like this trying to do the exact opposite, like, actually trying to give away, some of that power and influence that they have and make it as easy as possible for other people to pick that up and actually do something with it.

在这种环境下从事这样的工作，感觉如何？

What's it like working on something like this in that environment?

是的，我其实并不认同这种批评。

Yeah, I mean, I don't really get that criticism.

我经常听到的一种说法是，这反而会进一步将权力集中到核心团队手中，因为我们正在将控制权扩展到其他项目中。

So one of the things I've heard repeatedly is that it might actually centralise power further around CORE because now we're extending our control into other projects.

但我认为这种说法离真相更远，因为我们真正建立的只是一个接口，任何人都可以自由修改和调整实际的验证代码。

But I think that's even further from the truth because the only thing that we're really establishing here is an interface and everybody can tinker with the actual validation codes as much as they want to.

在过去一年的开发过程中，令人欣喜的是，确实有几个人出现了，并且正是这样做了。

And the cool thing to see over the past year of development on it was that a few people actually showed up and did exactly that.

他们只需要一个可以信赖和复用的接口，用于自己的项目。

So they only wanted this interface that they can rely on and reuse for their own projects.

他们最终实现了一些新的操作码，还有一些奇怪的Tapscript内容。

And they ended up implementing some of the new opcodes, some weird Tapscript stuff.

所以，是的，这让我感到非常振奋，也让我对整个比特币的未来充满希望——如果我们能把这个项目推广出去，让人们能够放心地随心所欲地使用它，因为它提供了这个接口。

So, yeah, this is I mean, it gives me a very good feeling and it makes me very hopeful for Bitcoin as a whole if we can get this project out there and just allow people to do whatever they want with it with the confidence that they have this interface.

是的，他们可以随意修改它，但这样做可能有一定风险。

Yeah, they can tinker with it and probably have a bit of risk doing that.

但总的来说，他们可以建立在这个已经发展了十五年多的坚实基础上。

But all in all, they can build on this one and a half decades strong foundation.

所以，这确实很酷。

So, yeah, that's pretty cool.

这种逻辑对我来说有点困惑：为什么说Kernel会让Core获得更多的权力？因为这里的根本动态其实是从零开始构建一个与Core完全无关的东西，而共识不兼容的风险之所以存在，正是因为Core太强大了。

That's that's kind of just confusing logic to me that something like Kernel would give more power to Core because, like, the the underlying dynamic here is, like, to do something completely from scratch, like unrelated to core, is the risk of consensus incompatibility, and that's only a risk because of how big core is.

而且你知道，它是网络上主导的实现。

And, you know, they're the dominant implementation on the network.

几乎所有具有经济重要性的节点都在运行它。

Almost everybody economically relevant is running that.

当你打开这扇门，允许构建与Core完全兼容的新事物时，你就为任何东西进入并竞争、获取网络份额打开了大门，而无需承担共识分裂的风险。

And when you open the door like this to build entirely new things knowing they're compatible with Core, you're opening the door for anything to come in and compete and gain network share without that risk of a consensus split.

到了那时，如果真的有其他基于内核的项目获得普及，成为网络的主流，那它就只是一个普通的代码仓库而已。

And at that point, if it comes down to it, if if something else using the kernel were to actually, you know, gain adoption, become a majority of the network, like, at that point, it's just just another repository.

其他项目完全可以对它进行分叉，随心所欲地修改和使用。

Like, those other projects can simply fork it and do whatever they want with it.

Core并没有因为最初实现了这套代码库就拥有任何权力。

Like, Core has no power just because they originally implemented that code base.

它只是点一下分叉而已。

Like, it just click fork.

如果所有人都在运行基于它构建的其他系统，而不是Core本身，那么Core实际上就是在这种情况下自愿让自己过时了。

And if everybody's running some other thing built around it instead of Core itself, like, Core literally voluntarily obsoleted itself in that scenario.

所以，我真的不理解这种说法——认为这会进一步巩固Core的地位。

So I I I just I don't get the argument that that's entrenching core more.

是的。

Yeah.

我也不认同，理由相同。

I don't buy it either for the same reason.

我能看到的一种可能情况是，人们会继续选择我们，因为我们建立在深厚的传统之上。

One thing that I can see playing out maybe is that people will just stick with us because we have all this tradition that we're building on top of.

但只要这些传统是真正赢得的，并且可以轻松切换——而如果我们部署了这个大家都已经在使用的通用接口，确实可以轻松切换——那么在我看来，这纯粹是双赢。

But I mean, as long as that is well earned and it can be switched away from easily, which it definitely can if we deploy this common interface that everybody just uses anyway, then yeah, this is just a pure win in my eyes.

是的。

Yeah.

我的意思是，这确实是一个重要的项目。

I mean, it's it's definitely an important project.

你知道，我想回到 libconsensus 和内核的历史脉络，展望未来，下一个理想的步骤应该是制定一个正式规范。

You know, I I think I I think to kind of, like, go back to the lineage of, like, lib consensus and then kernel and kind of project out to the future, you know, the next ideal step would be a formal specification.

比如一个逐位精确的协议运作方式说明。

Like, an actual, like, bit for bit, this is how the protocol should operate.

这就是它应该如何评估数据的方式。

This is how it should evaluate data.

无论在何种条件下，这都应该是输出的结果，以提供与内核所追求的相同程度的保证，而无需任何实际的代码依赖。

This is the result that should be output in whatever conditions to provide the same degree of guarantee that the kernel is aiming to without any actual code dependency.

在这方面，这确实是一个非常棘手的问题，关于这种做法是否值得投入精力，甚至是否可能实现。

Like, that is a really sticky topic in this space in terms of the practicality of that, whether that's worth the effort, whether that's something that's even potentially possible.

对于正式规范这个问题，你有什么看法？

Like, what are your thoughts on just the issue of a formal specification

你确实说得对，这是一个棘手的话题。

for You're definitely right that it is a sticky topic.

我认为这是比特币历史上从一开始就讨论过的主题之一。

I think it was one of the first topics that were discussed in Bitcoin's history from the very beginning.

所以我们一直在围绕一个问题打转：是拥有规范更好，还是直接以代码作为参考更好？

So we have been going a bit in circles around is it better to have a specification or is it better to just have the code be the reference?

而且，是的，如果你想实现，就必须逐行逐bug地重写，而这将非常困难，因为代码难以阅读且相当复杂。

And, yeah, you have to reimplement it bug for bug if you want to, and that's gonna be very hard because the code is difficult to read and it's pretty complicated.

是的。

Yeah.

展望未来，我希望比特币最终能有一个正式规范，我也希望内核可以成为让这更容易实现的工具，这样我们就能把所有验证逻辑拆分成对内核库本身的独立调用，每个验证函数只做单一检查，然后让每个验证函数的接口及其确切功能成为比特币的规范。

Looking out into the future, I think I would like to see a specification of Bitcoin eventually, and I'm kind of hoping that the kernel can be a tool to make that easier so that we can break all the validation logic into like separate calls to the kernel library itself and have these calls be super super granular where you just do a single check per validation function and then you just let the interface for each of that validation function and what it exactly does beat a specification for Bitcoin.

我认为，这是实现比特币任何形式化描述最清晰的方式，因为你能保证在从参考客户端转换时不会引入错误。

I think that is probably the cleanest way to achieve any kind of formal description of Bitcoin, just because you have this guarantee that you don't introduce a bug when you translate from the reference client to

是的，即使作为一个分布式系统，这已经够难了，但考虑到代码库最初一团糟，要逆向推导比从规范出发逐步实现更困难，而后者才是常态，你仔细想想就会明白。

Yeah, it's really It would have been hard enough as just a distributed system, But with the mess that the code base was in the beginning, it's the even worse problem to go backwards rather than having started with a spec and, like, move towards an implementation, which is the norm, you know, when you really look at things.

是的。

Yeah.

但我们并没有那样做。

But that's not what we have.

对吧？

Right?

是的。

Yeah.

我们有的，是中本聪给我们的东西。

We have what Satoshi gave us.

是的。

Yes.

好的。

Alright.

那么，我想问问，你对这个项目或者过去几年的工作有什么最后的想法想分享吗？

Well, I guess, any, you know, last thoughts on the project or your work over the last few years you wanna voice?

是的。

Yeah.

我对它在上线时能为生态系统带来什么充满希望。

I'm I'm pretty hopeful on what it will enable for the ecosystem at launch.

像我一年前还比较犹豫，那时觉得它并没有真正获得关注。

Like, I was hesitant, I think, a year ago or so, where had the feeling that it didn't really get traction.

但现在我们已经有三四个与Bitcoin Core完全无关的大型项目在实际使用它，并将其集成到它们的系统中。

But now we have like three, four bigger projects completely external to Bitcoin Core actually using it, actually integrating it into their stacks.

其次，其中一个ARC实现现在已在他们的测试框架中使用它。

Second, one of the ARC implementations now uses it in their test framework.

我可以预见一个未来，闪电网络的实现会使用它来检查交易脚本，或对它们创建的交易进行预验证，以确保这些交易符合策略规则。

I can see a future where the Lightning implementations will use it to either check their scripts for their transactions or do some pre validation that their transactions that they create actually pass the policy rules.

是的，用这个技术可以构建的东西太多了，我认为只要把它发布出来，并确保它对开发者来说尽可能易于使用，虽然这仍需要大量工作，但我认为这将非常值得。

Yeah, there's just so much that can be built with this and I think just putting it out there, ensuring that it is as easy to use for developers as possible, that's going to take a lot of work still, but I think it'll be very worthwhile.

我完全同意。

I couldn't agree more.

好吧，感谢你周六坐下来与我们交谈，希望大家都享受了这次对话。

Well, thanks for sitting down and talking Saturday, and I hope you all enjoyed.

谢谢。

Thank you.