背景资料

阅读本文前，建议先看完老刘整理的《BitcoinToken的参考资料》。本次问答的英文原文参见 ClemensLey BitcoinTokenWeChat AMA 。

AMA问答

Clemens Ley 是 BitcoinToken 的创始人。开发人员很快就能用在BCH区块链上发token，并用javascript语言写智能合约了。Clemens 在本月早些时候的一次 聚会演讲中 首次介绍了他对 token 的一些想法 。

2018年9月12日，他在一个微信群中举行了一次“你问我答”的活动。参与的人包括来自中国的矿工和开发者。其中有来自BTC.com，BTC.top和Rawpool的代表进行了提问。为清楚起见，问答的内容有稍做调整。

来自矿工和开发者的问题

1. BitcoinToken会像编译器一样将Javascript编译成比特币的汇编脚本吗？

BitcoinToken可以被认为是一个编译器，它可以将（用Javascript编写的）智能合约编译成可以发布，传输和交易 token 的Javascript包。生成的Javascript包将非常容易使用，即使对于对比特币一无所知的人也是如此。例如，要发 token，用户只需如下几行 Javasript 代码：

const token = new BitcoinToken（）

token.name =’MyToken’

token.supply = 21000000

await token.create（’./ erc20.js’）

await token.send（500，myFriendsPublicKey）

文件“./erc20.js”将包含用Javascript来编写的智能合约。以下是此类文件的示例：

async function isValid (tx:Transaction): boolean{

const sumInputs = tx.inputs.reduce((a,b)=> a.data + b.data,0)

const sumOutputs = tx.outputs.reduce((a,b)=> a.data + b.data,0)

return sumInputs === sumOutputs

}

其他人可以编写其它如“erc20.js”的合约。如果写合约的人愿意和社区分享这个合约，任何人都利用此文件轻松地发布相同类型的 token 而无需创建新的合约。

Javascript 代码是被翻译成 Bitcoin Script 里的操作码吗？

不，它没有被翻译成操作码。比特币脚本中的操作码不足以表达智能合约。

你在哪里放置 Javascript 文件：在比特币区块链或其他文件系统，如 IPFS？

我的计划是将js文件存储在区块链中。我将JS文件存储在交易输出脚本上。

这样我们就可以在发行token的转账中创建合约规则，然后由每个用户找到并以此规则验证，是这样吗？

是的。

由于比特币区块链存储有限，大的合约可能无法在链上保存？

我们会把大的合约拆成小的，放在多个输出脚本里。

BitcoinToken 不会把所有的 JS 代码保存到链上，只保存合约或是验证代码对吗？

是的，只存验证 token 转移的合约代码。在大多数情况下，它不会非常大。它也可以链接到现有文件，这样我们只需要存储一次智能合约就够了。

你使用 P2SH 来保存 Javascript 代码吗？

是的。

2. 是否有我们可以用来编译的 Javascript 子集？

出于安全原因考虑，我们需要使用一些沙盒技术。这就可以包含一个有合适语言行为的 Javascript 子集。细节尚未完全确定。有一家非常好的计算机安全公司在给我们提供建议。

3. BitcoinToken 的限制是什么，例如哪个用例很难实现？

在表达能力（可以表达的智能合约类别）上，我认为没有限制。我认为 BitcoinToken 可以表达所有可以在以太坊中表达的智能合约。

我现在还不确定哪些例子难以实现。像 erc20，erc721 这样的基本合约将非常简单，并且很容易在沙盒外用代码库实现。更复杂的智能合约，如投票、点对点打赌和拍卖，将需要更多的工作。一旦有人实现了这些智能合约之一并愿意与社区分享他们的工作，我们也可以将它们变成库文件。一旦发生这种情况，它们将像 erc20 token一样易于使用。

4. 与 Solidity 或 WHC 相比，BitcoinToken 的实际成本是多少？它会为用户和矿工节省更多成本吗？我不是在谈论手续费。

使用 BitcoinToken 一开始是免费的（矿工费除外）。之后，我可能会使用一种商业模式，开发人员可以免费创建和发行 token，但是一旦他们超过某个收入门槛就必须要付费了。他们可以用 bitcoin 或是他的自己创建的 token 来付费，因为这样对他们来说也是最简单的。

在 WHC 中，用户需要为发行 token、向多个用户发送 token、以及其他交易付费，否则这些行为可能会有 DoS 风险。在我看来，这种方法存在两个问题：首先，用户哪怕想在主网上试一下，也需要付费。其次，他们必须先买 WHC 币来付费。这会让入门门槛变高。

与以太坊相比，BitcoinToken 将更便宜，因为 BCH 的交易费的中位数通常比以太坊的1/100。

5. BitcoinToken Javascript 是图灵完备的吗？

我认为目前在智能合约里的图灵完备目前没有一个明确的定义。但是，我认为（约95％的确定性）BitcoinToken 可以表达以太坊中表达的每个智能合约。因此，如果您认为以太坊是图灵完成的话，那么 BitcoinToken 也是如此。

6. 我们如何优化 Javascript 编译后的代码？

这是一个很宽泛的问题。可以说在过去80年左右的时间，传统编程语言的编译器一直在进行优化，但仍然是一个难题。我还不知道我们将如何为 BitcoinToken 做到这一点。但是我想指出，传统的软件已经过优化，可以实现低时间或空间复杂度。在智能合约的情况中，我们必须为低成本而进行优化。这将在未来几十年为计算机科学家提供许多有趣的工作。

7. 我们是否需要把编绎后的 Javascript 代码转换回去，这容易实现吗？

BitcoinToken 需要在 Web 浏览器中工作，因为这样可以构建非托管应用程序。因此，最终到达用户终端的代码都会是 Javascript。可以对 Javascript 代码进行混淆，但是某种程度上是可以解混淆的。

8. 我们如何使用比特币的输入来保存区块链中智能合约的状态？

智能合约的状态将存储在输出脚本中。

但这不是很有限吗？例如有一百万持有人的代币合约。

一种思考方式是：数据将在区块链上，程序将用 JS 编写，也存储在区块链中（类似于以太坊）。每个持有者将有一个输出，存储着与他相关的状态（如他的账户余额）。

9. token 转账是否支持零确认？

BitcoinToken 上的零确认与 BCH 的零确认一样安全。如果您要转移 1 美元的 token，接收方将乐意接受零确认。如果 token 价值100美元，接受方可能会选择等待几个确认。

BitcoinToken 的零确认足够安全吗？

是的，BitcoinToken 的工作方式与 BCH 相同，所以是一样安全的。这与Omni（以及WHC）形成鲜明对比，他们的零确认不仅不安全，而且基本上不可能。这使得 WHC 在即使是中等吞吐量要求的应用中，也难以用现有形容满足。

10. BitcoinToken 是否支持 SPV 钱包？普通用户使用它的门槛是什么？

支持的，因为它就像比特币一样。用户的要求是客户端要能执行 JS 代码。

11. 它是否设置了约束以防止无限循环，例如以太坊上的燃油手续费机制或其他方式？您将如何预防恶意代码所造成的风险？

这些都是非常重要的问题，因为它们涉及到了矿工的安全问题，从而可能是整个比特币现金网络的安全问题。值得注意的地方是，BitcoinToken 所提供的智能合约不会被矿工执行。只有收到该token的用户才会运行实际的 Javascript 。如果 Javascript 包含一个（可能是隐藏的）无限循环，则用户的客户端进入无限循环，而不是矿工。结果将是没有人能够接受这样的token，这将使它变得毫无价值。攻击者发行使用户进入无限循环的 token 得不到一点好处。

BitcoinToken 并没有给矿工带来新的可攻击点。它的工作方式与比特币完全相同，矿工甚至不会注意到它的存在。如果您是专业 BCH 矿工，您也同样能处理好 BitcoinToken 无需任何改变。

12. 您对大量使用 op_return 并将数据放入其他节点以确定其含义的看法是什么？你认为从长远来看这会对比特币造成损害吗？

我不认为 op_return 是放置数据的正确位置。其中两个原因：

首先，op_return 未来可能会被修剪掉。我想把数据放在区块链上的原因正是因为我能保证它不会被修剪。可以被修剪的数据最好不要放在区块链中。

第二个更重要的原因：op_return 中可以存 token 的转帐信息。但是它也可能以错误的方式被使用，这可能导致问题。比如说：Omni 容易受到块重组这一事实恰恰是因为 op_returns 中的 token 流以错误的方式编码。在 Omni 中修复它将非常混乱并且容易出错并且将导致非常糟糕的性能（在某些情况下，必须在重组后重新解析 token 的整个历史）。解决该问题的最简单方法是更改比特币并强制执行指定交易排序。但应用程序写入错误代码时，不应当去改 Bitcoin。

你能解释一下这一句吗：“… omni容易受到块重新排序这一事实正是因为 op_return 中的令牌流以错误的方式编码。”

不好意思我不能，因为我无法很好的解释这里面的细节。我是根据 Mastercoin（和Omni）创始人对别人的问题回答^c 来判断的。

我对此的唯一解释是他们以错误的方式编码了token的传输信息。当我开发 BitcoinToken 时，我甚至没有想到这一点。我只是试着让它尽可能地与比特币相似。这样 BitcoinToken 不会受到块重组的干扰，就像比特币一样。

13. 与其他 BCH token 方案比，BitcoinToken 的优缺点是什么？

这是一个广泛的问题，因为现在有这么多新提案。我尽量长话短说。

• OP_GROUP 需要更改比特币协议，BitcoinToken 不需要。
• RSK使用一个基于不同的挖矿网络（联合挖矿，但仍然是不同的挖矿网络）的侧链，这比直接在比特币现金上构建的 token 安全性低
• Tokeda 需要一个（或多个）可信任的第三方。BitcoinToken 是无需第三方信用背书的
• 我所知道的所有其他方法（Omni，SLP，Counterparty，EPOBC，Coinspark，Colu，Open Assets）都不可编程。每个只支持一种小范围的，硬编码的智能合约。这些智能合约仅对极少数应用程序有用。在过去10天里，我曾与七家公司进行了交谈，都希望使用我的软件。他们都不需要千篇一律的解决方案，他们都需要定制智能合约。目前，只有 BitcoinToken 可以做到这一点。

14. 我们如何使用输出脚本存储一些复杂状态？持有人余额只是一个很简单的场景。

好问题。我们必须要解决好这个问题。我有一些初步想法，但想以后再分享。

15. BitcoinToken 是基于 UTXO 模型还是基于帐户模型？

BitcoinToken 的构建与比特币类似。因此它像比特币一样基于 UTXO 模型。

16. 再确认一下：我认为我们通过利用比特币交易来解决双花问题。我们不能在一个块中发生冲突，因此传输 token 是零确认安全的。是这样吗？

它与接受比特币的零确认一样安全。双花 BitcoinToken 生成的 token 的唯一方法是将包含 token 传输的比特币双花掉。

17. 您将如何支持不可交换的 token？有办法实现吗？

一般的token要求输入所花费的数量等于输出创建的数量。要做一个不可交换的 token，必须验证比特币交易的输入和输出中 token 集合相等而不是数量相等

async function isValid（tx：Transaction）：boolean {

const sumInputs = tx.inputs.reduce（（a，b）=> a.data + b.data，0）

const sumOutputs = tx.outputs.reduce（（a，b）=> a.data + b.data，0）

return sumInputs === sumOutputs

}

18. 如果钱包意外地将染色币用于错误的输出脚本，会发生什么情况？token 会被销毁吗？

在某种程度上智能合约开发人员可以防止这种情况发生，但如果智能合约开发人员不关心或者一些边界情况，token 可能会丢失。有几种解决方案。最简单的方法是在初始化token钱包时使用新的私钥。不要在任何其他钱包中使用该密钥，也不能花费 token 承载交易。或者，我们可以使用特殊地址类型，如染色币，但这不会立即可用。

你的意思是 token 可以被销毁，但不会影响 BCH 的交易正常进行？

是。如果用户广播无效的 token 转账，那么他会销毁掉里面的 token。BCH是保持不变的（因为矿工根本不知道有只能合约这回事）。

19. 我们可以使用 BitcoinToken 控制比特币（不仅仅是 token）的流转吗？如果可以，请分享一些例子。

另一个好问题。可以，但我想不出有啥好的例子需要用这种方式的。您可以编写一份智能合约，要求您只能发送偶数个比特币。如果用户要发送奇数的比特币，他将使 token 无效（如果没有 token 则不是问题）。BCH 仍然是安全的。

不是最好的例子，但我只是想说，你可以强制执行任何可以在 JS 中编码的属性，给定事务的 JSON 表示。

20. 您刚才说我们需要将 JS 代码分到多个转账里。你现在如何存储 JS 代码，以及钱包需要做多少工作才能正确解码 token？

目前我只能存一个输入脚本可以放得下的javascript代码长度。使用某种机制可以很容易地在多个输出上展开更长的文件。我只是还没有去实现这一点。

21. 为什么选择直接存储Javascript而不是编译操作码？有什么好处？

有许多 Javascript 程序无法用比特币脚本表达，因此我们无法编译成比特币脚本。当然，我们可以将JS代码编译成任何形式的汇编代码，这将同样可以工作。如果用户有需求，我将会创建这个工具。

22. BitcoinToken项目现在如何进展？产品发布的任何时间表或路线图？

我正努力在几周内准备好原型，以便让开发者把玩。如果一切顺利的话，主网的发布将计划在年底进行。我将把我的原型提供给选定的一些想要在BItcoinToken之上构建应用的开发人员。如果您想在BitcoinToken之上构建一些东西，请发送电子邮件至[email protected]，我会为您安排。

23. 是否需要 每个 相关用户都来运行嵌入在转账中的JS代码？

有可能可以定制BitcoinToken，这样就不必让每个用户在每个实例里都运行代码。例如，token的发行方式受信任的。该发行方可以验证所有token转账。如果用户信任发行方，他们就不必验证任何内容。这在需要低延迟或高吞吐量的应用中非常有用。在这个模型中，用户只需检查区块链上是否存在转账，这会超级快。尽管一些用户可以出于效率原因选择信任发行方，但是其他用户可以很容易审核被信任的发行方。如果发行方欺诈，则会在区块链上留下证据，并可以被其他用户揭发。

24. 鉴于最近社区发生的事情，如果链分裂成多条，token会怎样？在两个链上都有效，还是说用户需要选择其中一个？

另一个好问题！BitcoinToken方案下，token就像比特币一样，会存在于两个链上。

25. 存在一种攻击情形：我发行一个代码中带有无限循环的token。我将一个token发送到一个地址。此地址的钱包服务提供商需要运行合约代码，因为他们希望向其用户显示任何收到的token。当钱包服务提供商运行代码时，它们会受到攻击。钱包服务商如何避免此类攻击？不说矿工受到攻击，而是说钱包提供商受到攻击。钱包服务商需要运行代码，是那种基于客户端服务器模型的轻钱包。

对于客户端钱包，只有接收方必须运行代码，而不是钱包提供商。获取令牌的用户的计算机进入无限循环，生态系统的其余部分不受影响。如果钱包在服务器上，那么服务器可以设置一个时间限制并说：我们只运行在一秒钟内终止的智能合约。如果用户想要运行计算成本更高的智能合约，他将不得不使用客户端钱包。

26. 如果在11月15日升级时比特币现金出现拆分，那么BitcoinToken会选择哪种区块链 ？（ 不要问你会选择哪一方，只想从开发人员的角度知道哪个方向对比特币更有前途）

我不认为比特币现金足够大，可以再次分叉并且两个分叉都能存活下来。我会在那个幸存下来的链上。

如果在比特币现金发生分叉，我认为这将是灾难性的。最大的问题是信任受到侵蚀。竞争总是存在的。

你们（指矿工，译者注）恰恰是可以防止分叉的人。别让他们分叉。如果我们没有提前搞砸的话，我们可以将比特币现金变成令人惊奇的东西。

27.oken数量如何被编码，在转账输出中的比特币的数额里，还是在转账输出的其他部分？金额或ScriptPubKey？

token数量编码在交易输出中。令牌的所有者可以花费该输出并将token发送给另一个用户。

那么在输数额里，不在ScriptPubKey里？

哦对不起。不是在satoshi数额里。在ScriptPubKey里（这里应该是说在脚本里，译者注）。

Clemens 对矿工的问题

Clemens Ley也对出席的矿工和开发人员提出了一些问题。个别与会者从他们自己的角度提供反馈。

1. 我可以请这个小组中的更多人评论他们对允许非标准脚本的看法吗？

Xiaohui ：我非常支持它，当然，必须找到一种确保安全的方法。

Edward ：我们确实需要非标准的脚本。

linzheming ：在我看来，这将给钱包服务提供商带来相当大的挑战。我将密切关注这一进展。

Clemens回复linzheming ：如果只允许我们用那一种非标脚本，那对于钱包提供者来说会更容易实现。

2. 挖矿中的痛点/问题是什么？

Jason ：其实现在并不太多。但是对于更大的块，矿池需要协同工作以实现快速可靠的块广播。BCH的当前代码库在交易事务及区块的广播方面无法处理压力测试。

imcoddy ：我认为矿工们的竞争力不够。从压力测试来看，我认为有些矿池池可以在这部分做得更好。现在我看到Rawpool正在积极调查SV和ABC的好处，这对我来说是一个好兆头。我们也担心集中化，但我个人希望更多的矿工参与竞争并提供高可扩展性和服务，以使BCH成为真正的全球现金。

3. 采矿当前的瓶颈是什么？也就是说，如果块太大，软件的哪一部分会出问题？

Jason ：我们已经设法在3月初使用比特币ABC 0.17.1测试32MB块。我们通过重构我们的矿池后端来为此做好准备。瓶颈是比特币客户端本身。它无法在测试中产生大块。虽然有些矿池还没有为大块做好准备，但是修复他们的后端应该不是大问题。在压力测试期间，通过观察我们池中的不同节点，块高度延迟达6分钟。大多数节点的mempool大小差异超过10 MB。

程序只是崩溃？你是否看到一些有价值的错误信息？

Jason ：没有崩溃，但是块的延迟很高。我想很多人都应该注意到 TX Highway 和 TxStreet 在压力测试日的mempool大小的巨大差异 。转账没有在BCH网络中顺利广播。我们所有节点都运行相同的比特币ABC。我们需要进行更多测试和基准性能评测来形成一份精确的报告。现在，我只能通过观察来说。

问题是验证大块需要太长时间吗？

Jason ：不，验证不是压力测试中的瓶颈。许多节点甚至可能都没有收到块。在我们3月份测试32MB的过程中，我们模拟了一个300MB的mempool并挖掘了32MB的块。区块校验在我们的测试中不是问题。但是，我们没有测试验证时的最差情况。

4. 您是否知道有人确定了块验证时间如何与块大小一起缩放？也就是说，验证大小为100kb，1mb，10mb的块需要多长时间……

Jason ：目前，验证时间与大小呈线性关系。由于我们每MB有sigop限制。发送交易方面还有很大的提升空间。我们还没有像比特币中的 Fibre 这样的东西。我们也愿意在BCH上测试紧凑块实现。

linzheming ：如果系统是无权限的，我认为我们确实存在竞争，但我不知道比特币的系统是否迫使我们更加集中化。

Lise ：Amaury之前告诉我，他们认为传播和验证比CTOR本身复杂得多。这就是他们试图突破的目标。

5. 块验证时间与网络延迟相比如何？

Jason ：是的，现在32MB可能会有问题。但我们需要测试CTOR可以带给我们多少收益以及是否还存在其他可能的解决方案？

6. 您对CTOR与TTOR有什么看法？有没有人进行实验比较两者？

imcoddy ：我认为Rawpool目前正在测试SV和ABC，他们已经与双方的开发者联系。如果我们这次不急于推出CTOR，这次可能采取不升级策略吗？我们现在可能不会有大于32 MB的巨大块，但是新启用的SV操作码可能会导致分裂。

Jason ：我们愿意进行测试。目前，SV和ABC在主链上完全相同。为我们提供测试用例会很有帮助。我承认我们缺乏与开发者的沟通。我们在最近的0.18公告中才知道了这一点。

Lise ：作为一个矿池，David和我都认为社区很有可能达成协议而不是分裂。虽然ABC和nChain似乎有相反的意见，但还有很多其他利益相关方在双方支持更加实际的立场。例如，我刚刚翻译了比特币无限的Andrew Stone的一篇文章，他认为CTOR是一种不切实际的分片方式。一些团体表示他们支持CTOR，但也同意更大的块。

Clemens ：我认为我们应该在两者之间进行竞争。让两个团队准备他们的解决方案，然后我们测量每个解决方案验证不同大小的块所需的时间。我将很乐意提供帮助。在做出类似的重要决定之前，我们至少需要一些数据。我个人认为绝对没有必要急于求成。我们在比特币现金中没有扩容问题。我们知道现在的系统在目前还是有效的。如果我们要更改的话，我们应该非常确定我们在做什么。

7. 您如何看待比特币现金的现有token解决方案？您希望token解决方案有什么功能？

linzheming ：我不太关注token解决方案，但我认为如果一个可信方能够以非常低的成本发行token作为数字票证，它将会有很大帮助。

Edward ：我们需要智能合约的token方案。BCH上已经有一些token方案了，但智能合约方案不多。Wormhole ，Keoken和BitcoinToken是目前仅有的三种智能合约解决方案。我们应该在这些解决方案中找到并选择最强大，最简单的一个。虫洞现在已经可以发token了，智能合约部分可能会在明年初上线。Keoken的token功能将在几周后发布，后续会增加智能合约。@姜家志JZ 是虫洞的主要开发者，我可以介绍你们认识。

8. 您是否愿意扩展标准脚本集或甚至允许所有脚本？

linzheming ：我对开放所有脚本没有意见。我们可以看到我们可以用这些砖块建造什么。在此之前我甚至不知道边界在哪里。我认为关于比特币脚本的争论最多的是无状态的性质。

imcoddy ：我认为我们还没有完全理解比特币能做什么，脚本系统是个等待着人们去挖掘的隐藏宝藏。我个人认为，作为金钱，它需要稳定，问题在于脚本系统是否足以让人们在其上构建东西。BitcoinToken是一个很好的尝试，但我们确实需要更友好的工具来帮助开发人员更快地制作应用程序。我并不反对在基础层上添加更多内容，但我们需要知道协议的每次修改的优缺点，这真正需要更多的测试和良好的处理。

翻译：Andy、linzheming
校对：老刘
AMA主持：邱少贤
英文原文采访内容整理：老刘

欢迎关注微信公众号：闪电HSL

欢迎打赏BTM：bm1qefc720au672awrgazgw5c3kx7etr5kejju02p7