freedomhero的博客

相信很多开发者朋友在使用 sCrypt 开发比特币智能合约时，会有这样一个问题：为什么没有浮点数的数据类型？比如 Float 或者 Double？这篇文章我们就来聊聊在合约中如何实现模拟浮点数的高精度计算。常见的编程语言一般都会有原生的浮点数支持，大部分都会参考实现 IEEE754 标准，但包括比特币在内的很多区块链的智能合约都没有原生支持浮点数，这其中可能有两个重要原因：1. 如果使用基于 FPU 硬件的实现（hard float）可能会有不同架构的节点在验证单笔交易时产生不同结果，从而导致共识失败；2

本文​​从多个方面比较两个智能合约区块链：比特币和以太坊。我们发现，由于其巧妙构建的基础设计，比特币具有卓越的性能、安全性和成本效益。文中重点介绍它们的技术差异，经济、哲学、法律和环境差异超出了本文的范围。可扩展性以太坊的账户模型和垂直扩展在以太坊，每个智能合约都驻留在一个帐户中。它有自己的存储空间，这种存储空间在整个合约执行过程中持续存在。为了了解如何做到这一点，让我们研究一下以太坊的核心智能合约引擎: Ethereum 虚拟机(EVM)。它是基于堆栈的，并将数据存储在三个地方: 堆栈、内存和存储

经过1年多的努力，40几个版本的迭代更新，sCrypt 今天正式发布 1.0.0 版本，包含以下重大更新：完整的 IDE 使用 文档高级付费功能 代码优化更加细致和安全的代码格式化器。更加完善的语法高亮效果。新增 :hex2Asm, :parsePreimage, :diffoutputs 三个内置的调试器命令新增 sCrypt: Launch Debugger 命令，以便快速启动调试器。代码优化代码优化是将一段代码转换为其他功能上等效的代码，以提高一个代码运行速

第一部分：手动优化sCrypt 编程与使用 Javascript 或 Python 进行的传统编程不同，因为当将包含编译结果的交易提交到比特币网络时，脚本大小直接决定了它们的运行成本。因此，最终的脚本应该尽可能小，以节省交易费用¹。下面我们列出了一些技巧，供开发人员手动优化其 sCrypt 合约的脚本输出。1. 合并相同的函数调用所有函数调用均通过内联实现。函数主体会被复制到调用它的位置。如果同一个函数在不同的地方多次调用，则可以通过合并它们来节省代码大小。在下面的示例中，将两个 Tx.checkP

之前，我们介绍了一种通用技术来维护比特币智能合约中的状态。它直接将状态存储在单个 UTXO 中。例如，我们将该技术用于1层 Token 解决方案，其中状态是全局 Token 余额表。当用户数量增加时，它很快变得非常昂贵，因为每个 UTXO 也即每个交易都携带整个状态。现在有一个更具突破性的想法，可以在有效地保持状态的同时避免交易体积快速膨胀。具体来说，是将状态的 Merkle 根而不是其本身存储在 UTXO 中，同时仍然在1层强制执行所有状态转换规则。它将 UTXO 大小从 O（n）减小为 O（log n

自从我们在 sCrypt 语言中实现了 OP_PUSH_TX 技术以来，大家已经使用此功能强大的原语构建出了许多智能合约。随着这些合约开始部署在比特币网络上，必须使 OP_PUSH_TX 变得更小以降低成本。从 sCrypt IDE 0.4.4 版本之后，我们已经可将 OP_PUSH_TX 的大小优化约 700％。如何使用优化版 OP_PUSH_TX？要使用优化版本，只需将 Tx.checkPreimage（SigHashPreimage txPreimage）替换为其优化版本Tx.checkPreim

sCrypt IDE 允许您在单元测试失败的地方启动调试器，这将帮助开发人员极大地提高调试合约问题的效率。早些时候使用 sCrypt 单元测试框架时，如果测试失败时，错误消息仅在JavaScript / TypeScript 代码中显示失败的位置。如果用户想要找出失败的具体原因，则必须打印出调试参数，然后将其复制并粘贴到 launch.json 文件中再启动调试。这是一个费力且容易出错的过程。单元测试失败时直接启动调试器使用这个功能之前，我们首先需要确保已经打开了 SourceMap 的设置，参考下

在上一篇文章中，我们将比特币智能合约泛化为包括可选的链下验证部分，以及由比特币脚本组成的常规链上部分。我们将这一概念应用于抛硬币游戏，通过使用抵押金的方式反向激励两人不要单方面中止游戏。在本文中，我们使用参考文献[^1]中所述的方法，实现了另外一种公平抛硬币合约，并再次展示了如何设计带有链上和链下部分的混合智能合约。智能合约被定义为一种协议，无需信任方可以根据其交互协议安全地进行交易，而无需受信任的第三方。 安全性取决于特定的合约，通常来说可以包括以下属性：1）遵守合约/协议的诚实方绝不应该赔钱； 2）必

我们将介绍一种全新的方式来设计比特币上的智能合约。在我们以前的所有合约中，所有内容都嵌入在比特币脚本中并由矿工进行验证。在新方法中，我们将结合以前的合约，在链下验证交易。令人惊讶的是，它可以保持链上合约的不信任性质，同时大大提高效率和私有性。我们通过改进公平的抛硬币合约来举例说明总体的思路。实用公平硬币抛使用基于哈希的承诺方案，我们引入了一种无需受信任的第三方即可实现公平抛硬币的合约。但是在实际应用之前它有一个小问题：即当其中一方知道了对方的秘密之后，他/她发现自己输掉了比赛，即使他/她不能拿回赌注，也

受到最新的 比特币课程 的启发，我们将展示如何将机器学习技术应用于比特币。具体来说，我们将演示如何将奇异值分解（SVD）应用于低分辨率图像预览，并以此为基础实现对原始图像的无需信任购买。奇异值分解 (SVD)SVD 是一种矩阵分解类型，可将单个矩阵分解为矩阵U，∑和V*。U和V*是正交矩阵。∑是奇异值的对角矩阵。直觉上，它可以看作是将一个复杂的矩阵转换为3个更简单的矩阵（旋转，缩放和旋转），其中矩阵U和V*引起旋转对角矩阵∑引起缩放数据压缩一个典型的机器学习问题可能面对数百个或

在我们之前的博客中，介绍了如何使用 sCrypt 来编写比特币智能合约。但是作为刚入门的开发者，你可能对如何使用 sCrypt 来构建 dApp 更加感兴趣。接下来我们将教大家如何使用 sCrypt 一步一步地构建一个井字棋 dApp.该应用程序非常简单，它所做的就是使用两个玩家(分别是 Alice 和 Bob)的公钥哈希，初始化合约，各自下注相同的金额锁定到合约中，只有赢得那个人可以取走合约里面的钱，如果最后没有人赢，则两个玩家各自可以取走一半的钱。目标不仅是对应用程序进行编码，主要是学习如何对其进行编

我们在比特币网络上设计并实现了一个安全的拍卖合约。 它是公开透明的，每个人都可以参加，竞标结束后出价最高的竞标者将中标。 投标人受其出价的约束，而拍卖人则受拍卖结果的约束。实现// Auction: highest bid before deadline winscontract Auction { PubKey auctioner; int auctionDeadline; // bid with a higher offer public function bid

这里我们介绍一个定期支付合约，允许用户定期存入款项，并且收款者可以定期收取款项。合约实现合约代码如下：contract Recurring { Ripemd160 userPubKeyHash; //Address of the owner of the coin int merchantPayment; //How much the merchant can take from the contract Ripemd160 merchantPubKeyHash; //Add

上篇文章中，我们使用 XOR 在比特币网络上进行了公平的抛硬币。今天我们来介绍另一种使用 Blum 原始协议 [^1] 来实现这个游戏的方法。它包括以下步骤：Alice 选择质数 p 和 q。 他告诉 Bob 二者乘积 N = p * q。Alice 可以选择很大的 p 和 q ，这样 Bob 就无法进行从 N 进行反推；Bob 在 0 到 N 之间选择 x [^2]，并计算 b =x² mod N。他告诉Alice 数值 b。 此步骤类似于在掷硬币之前就选择一个结果并作出承诺；Alice 计算

我们可以在比特币网络上基于比特承诺方法实现一个公平且不需要第三方的掷硬币游戏。假设 Alice 和 Bob 决定掷硬币，但他们没有实物硬币，或者他们想通过互联网进行。通过遵循下面这个比特币协议，他们可以实现公平的抛硬币。Alice 和 Bob 各自将 x 个比特币锁定在如下所示的智能合约中（注意：此时他们并没有透露自己的秘密数字）；在新交易里同时提交他们各自的秘密数字，然后对这两个秘密数字进行异或操作，以确定硬币是正面还是反面。如果是正面则 Alice 赢，否则 Bob 赢。获胜者将获得所有 2x

继上次我们推出 sCrypt Deploy 功能后，这次我们新增了花费有状态合约的功能。拿我们boilerplate中的 advancedCounter 合约作为例子，我们将介绍如何使用这个功能部署和花费合约。对于带状态的合约， 你需要在部署的时候填写正确的初始化状态。AdvancedCounter 合约是一个计数器合约， 我们将状态设置为 00，从0开始计数，合约的锁定的余额我们使用默认设置 10000 聪。合约部署成功之后，我们会看到左下角的 DEPLOYED CONTRACTS 增加一个了 Ad

我们在 Bitcoin SV 上实现了一个数独游戏的合约，利用之前介绍过的一种合约范式可以将游戏中寻找解题方案的过程外包上链。因为求解数独问题的计算工作量会随着其行列数快速增长，实际上它也是一个 NP-完全 问题。不过我们可以借由比特币智能合约巧妙地寻求答案，只需要验证答案提供者所给出的解答是否满足要求即可，这样可以将复杂的求解过程计算在链下进行实现。sCrypt 合约代码如下：import "util.scrypt";import "array.scrypt";contract Sudoku

Pay to Script Hash (P2SH) 之前在 Bitcoin SV 网络上已被废弃，这里我们提供了一种使用 sCrypt 语言来实现它的例子，在不需要修改共识规则的前提下使得这种技术依然可以被继续使用。致谢感谢 Edward Liu 和 Owen Vaughan 提出了这个想法。...

赶在2020年的最后一天，我们的 sCrypt IDE 推出了一个重要更新：sCrypt Deploy，这个功能是方便开发者快速部署和调试他们编写的合约的，下面给大家大概介绍下。在推出这个功能之前，如果开发者想要将自己编写的合约部署到测试网上，验证合约的方法能否被正常调用，只能在 deployments 目录里面手撸 js，往测试网发交易。sCrypt Deploy 功能提供一个通用的 UI 交互界面，只需简单的填写相关参数，就能一键部署合约，点击 Call 按钮就能调用合约方法了。sCrypt ID

康威生命游戏是一个在网格上的迷人的零玩家游戏，其演变取决于其初始状态。 每一代都是前一个的纯函数。我们在比特币 SV 上实现了这个游戏。当比特币交易触发时，每一代都会发展成为新一代。整个游戏完全运行在链条上。只要有交易与它相互作用，它就会永远活在链条上。游戏规则任何少于两个活着的邻居的活细胞都会死亡，因为人口不足任何有三个以上活着的邻居的活细胞都会死亡，因为过度拥挤何有两个或三个活着的邻居的活细胞都会一直存活到下一代任何正好有三个活着的相邻细胞的死细胞都会复活实现游戏的每一代被存储为合约的

Script-level Debugger最近我们的 sCrypt VSCode IDE 推出了一个重要更新：Script-level Debugger！这也是我们的第一个付费版功能，下面给大家大概介绍下。之前大家已经可以用 IDE 进行 sCrypt 源码级的 debug 了，而本次更新则在此基础上添加了 Script 脚本级的 debug 功能，主要包括这几个功能点：sCrypt 源码与其编译出的 Script 脚本之间关联的实时展示；在 Script 脚本上设置断点或单步调试；查看 Mai

最近，一个黑客利用ElectrumSV新推出的累计多签功能中的一个漏洞，盗取了大量比特币。我们对这次攻击进行了分析，并对今后如何减少此类攻击提出了一些建议。背景2019年nChain引入了累计多签，用来替代基于P2SH的多签，P2SH功能已经在创世纪升级时移除。它不用P2SH就实现了与多签相同的安全性和隐私性。在ElectrumSV的累计多签实现中，可能是由于疏忽了栈上操作对象的顺序，最后一个操作码 OP_LESSTHANOREQUAL 被错用成了 OP_GREATERTHANOREQUAL 。这意味

在 sCrypt 合约的开发调试过程中，最常见也最头疼的两个问题就是碰到 checkSig 和 checkPreimage 异常。虽然我们可以在 Debug 过程中定位到源码中错误的具体位置，但对于为什么失败以及如何修复总是感觉一头雾水。今天我们就来聊聊如何快速定位和修复这两类问题的一些技巧，希望能对大家有所帮助。sCrypt boilerplate 项目中包含了一些 sCrypt 合约的具体示例代码且在不断更新中，所以有时可能会碰到配置失效导致无法正常完成 Debug 的情况。下面我们以该项目中的 t

在前一篇文章中，我们介绍了一个强大的功能 OP_PUSH_TX。它允许在比特币智能合约里访问当前 transaction，这样就可以实现很多复杂功能，比如有状态的合约。本文将在此基础上进一步介绍一个有意思的扩展合约。Tx.checkPreimageAdvanced() 方法sCrypt 在标准库合约 Tx 中提供了 Tx.checkPreimage(txPreimage) 方法来实现 OP_PUSH_TX 的基础功能，它可以满足很多场景的需求。但是，随着合约变得越来越复杂，可能需要做更多的定制。比如，在

原子交换是指不同资产之间的无信任交换，且不会出现交易对手风险（即指一方违约，另一方损失资产）。接下来我们将展示一种通用的方法，使用 sCrypt 语言实现比特币和 token 的原子交换智能合约。Token 售卖合约我们将开发一个 token 售卖合约，用于进行比特币和比特币网络上1层 token 1的交易，该合约不会出现一方违约的风险。任何人都可以向该合约发送比特币以购买 token，并保证自动获得以预定价格计算出的 token 个数。合约是在共识层面强制执行的，由矿工验证和记录上链。该合约建立在有状

很早之前就有人开始研究在比特币网络上实现外部资产的 Token 化，也产生了很多相关的协议。总体来说，这些协议大部分是通过将代表资产的原信息通过诸如 OP_RETURN 之类的操作码放入脚本后进行上链，从而实现了“资产上链”的过程。但是因为用于执行和验证这些元数据的逻辑并不是由比特币矿工完成的，故而这些方案被称作第二层（Layer 2）解决方案。与之前这些工作不同，我们在这里即将介绍的是一种实现第一层 Token 智能合约的机制。这种方案的核心是依靠比特币网络的矿工在共识层完成合约的相关逻辑和验证，从而进

比特币智能合约比特币脚本的能力通常被认为是很有限的，无法实现复杂的智能合约。一个经常被诟病的点就是其无法实现有状态的智能合约。以太坊出现的一个主要原因，就是为了克服这个问题。有些合约的确是有状态的，因为这些合约需要参与者在合约的多个阶段与之交互，并依赖随时间变化的状态，比如链上投票或游戏。接下来我们将展示一种在比特币智能合约中管理状态的通用机制。我们还将用 sCrypt 语言来实现一个有状态的合约，sCrypt 语言是可以编译成比特币脚本语言的高级语言。预备知识：OP_PUSH_TX在研究如何在比特

了解比特币脚本（Bitcoin Script）的朋友都知道，它是由一串计算指令（即操作码 Opcode）和数据组成的。脚本执行就是使用指令对数据进行运算的过程，换言之，这个程序的输入在它执行之前就已经确定了。也正是因为这种设定，很多人下意识地认为它的能力范围也是非常有限的，因为它不够“灵活”。今天想给大家介绍的东西实则是突破了这种刻板印象，也让我们可以更加深入地理解脚本的强大和有趣。我们设计了一个算法，使脚本可以访问正在被执行的脚本所在的当前 transaction 数据。我们称之为OP_PUSH_TX

预言机（Oracle）1比特币或其他区块链上的智能合约通常需要访问区块链外部的数据使之更加实用，例如：现实中保险合约中的天气变化或博彩合约中的体育比赛结果等。出于安全性考虑，在一个独立的沙箱内运行智能合约时，外部数据检索是禁止的。他们依赖第三方预言机（Oracle）来提供这些数据。这样就产生了一个“完整性”的问题，又称预言机问题（the Oracle problem）。需要使用数字签名来验证由已知的预言机提供数据的真实性与完整性。本文介绍了一种有效的方法，可以验证和访问任意链上或链下由预言机在比特币智能

上一篇文章主要介绍了 sCrypt 语言开发利器 sCrypt Visual Studio Code 插件 的相关功能。现在我们就要实操起来，体验一下 sCrypt 合约完整的设计、开发、测试、部署、及调用全流程。设计构建任何一个智能合约的第一步都是从想法出发完成一个设计，这里我们选择将一种比特币网络中常见的交易类型（P2PKH）进行 sCrypt 合约化。把这个过程作为示例的主要原因有两个：P2PKH 是目前比特币网络中最主要的一种交易类型，对于初学者来说很有必要了解；通过将这个经典交易类型合约

上一篇主要给大家介绍了比特币智能合约高级语言 sCypt 的一些基础知识，有些同学可能已经跃跃欲试了。俗话说得好，工欲善其事必先利其器。在真正的编码工作开始前，还是有必要花些时间学习如何使用合适的工具。相信不少开发者朋友都在使用 Visusal Studio Code 这款微软出的 IDE，其优异的性能和灵活的插件机制带来了非常丝滑的编程体验。为了帮助大家更加轻松高效地编写比特币智能合约，sCrypt 提供了一个功能丰富实用的工具应用：sCrypt Visual Studio Code 插件。大家可以在

脚本之谜上一篇文章中我们简要介绍了比特币智能合约的运行基础，即比特币网络底层脚本语言 Script 及其虚拟机运行原理。相信不少第一次接触的同学看过之后都会有一些困惑：这玩意和大家通常熟悉的 Python 、JavaScript 之类的脚本语言长得怎么一点都不像？“骨骼如此惊奇”的脚本语言该如何学习和运用呢？带着这些问题，我们再来深入聊聊。为什么是 Script ？众所周知，比特币网络本质上是由很多矿工节点运行和维护的一套公共账本，所有节点都需要保证这个账本上的数据是合法准确的。换句话说，任何一笔交易

当谈及智能合约时，大多数人都会下意识地把比特币排除在讨论范围之外，因为当下流行的观点是比特币不具有智能合约的能力。但是今天想跟大家介绍的内容则正好与此相反：即比特币从诞生之日即拥有支持智能合约的能力，下面让我们一起来探个究竟。比特币 UTXO 模型比特币底层采用了一个很特别的交易模型设计，即 UTXO（Unspent Transaction Outputs） 模型。这里我们简单介绍一下，首先来看最基本的交易是如何表示的。每一个比特币交易主要包括两部分：输入记录和输出记录。每条输出记录主要包括的信息：