image
随着区块链相关技术的创新和突破，很多有形或无形资产都将实现去中心化，数字资产将无处不在。要保护数字出版物版权，实现去中心化，解决业界多年来版权保护不力的难题。无论数字资产，还是数字出版版权，都是有明确所有权的，当前实现数字资产所属的技术手段就是本期《区块链100讲》要介绍的数字签名。而多重签名是对数字签名的扩展使用，给数字资产转移提供了安全保障和技术手段。本期内容从基本概念入手，详细了解数字签名和多重签名的作用和代码实现。
1
数字签名
什么是数字签名？
很多人的第一反应是用笔签名。生活中我们经常需要用笔签名：借条要签名，合同要签名，去银行办理业务也要签名。签下名字，就表示对这件事负责。人的笔迹是很个性的，几乎不可能复制，即便是专业模仿也可以通过技术鉴别出来，因此签名就具有唯一性的特点，并被法律认可。数字签名的原理跟用笔签名类似，用于确认身份。
数字签名有两个作用：
-
一是能确定消息确实是由发送方签名并发出来的；
-
二是数字签名能确定消息的完整性。
然而，在没有笔迹验证的情况下，数字签名如何保持唯一性和可验证性呢？
签名的验证。如果，你拿着一张支票去银行兑换，银行职员会对支票上的签名和印章仔细比对，确保印章大小、样式，以及付款人签名等，与银行留存的信息一致，才会给你兑付，这就是签名验证。
简单地讲，就是加密技术代替人的笔迹，数字签名涉及一个哈希函数、发送者的公钥、发送者的私钥。
其操作方法是：
在区块链系统中发送一条广播时，发送方用一个哈希函数从广播文本中生成摘要，然后用自己的私钥对摘要进行加密，加密后的摘要将作为广播的数字签名和广播一起发送给接收方，接收方首先用与发送方一样的哈希函数从接收到的原始广播中计算出报文摘要，接着再用发送方的公钥来对广播附加的数字签名进行解密。如果这两个摘要相同，那么接收方就能确认该数字签名是发送方的。
比特币客户端签名功能
数字资产需要签名。类比人类签名，比特币也有签名功能。如果了解比特币钱包（客户端软件），就会发现它提供了一个签名消息的功能，可以用来对其他用户通过比特币网络之外的信息进行签名和验证。我个人使用的是 比特币官方网站 提供的比太钱包，如图：
image
这个功能干什么用的呢？有好多小伙伴不清楚，这里举个简单的例子解释一下，具体使用的时候绝不限于这些应用。
Alice开了一个网店，但没有直接接入比特币网络，不能自动确认和验证支付者。客户Imfly购买了她的产品，并用比特币支付了全部货款。因为比特币地址和交易都是公开匿名的，为了防止冒充冒领，Alice需要确认Imfly提供的那个付款地址确实是imfly本人的，否则不能发货。这时候，就需要Imfly先把支付货款的比特币地址和相关交易签名信息（如图），然后通过QQ或邮件传给Alice，Alice使用客户端验证信息签名，才能确认交易确实是Imfly的。
想象一下，如果没有签名功能会怎么样呢？因为比特币仅是一个匿名、安全的支付手段，但却无法确认支付方或收款方是谁，信息的不确定性，将使得比特币网络之外的交易无法达成。在中心化的世界里，这个问题是通过运营平台这个第三方达成的，比如支付宝等，双方的全部信息，平台都掌握，任何一方出现欺诈，都需要通过向平台投诉来解决。用户需要对第三方平台绝对信任，并通过牺牲个人信息安全获得交易的基本保障。
电子签名
通过上述分析，可以理解的是，签名的作用是确定资产所属，其特征是简单、安全、可验证。把这个概念抽象出来，应用到计算机系统里，为了确定数字资产所属，也需要进行签名，这就是大家经常看到的“电子签名”的概念。在网络世界里，签名可以对任何需要确认的数字资产进行处理，比如比特币地址、电子书版权等，并以此来宣告重要资产的所属，这让无需监管的去中心化交易成为可能。
具体开发设计中，就是用加密技术代替人的笔迹，不然任何签名方法都会被模仿，而且模仿的成本极低，相反，验证的成本却很高。这也是当前数字出版行业版权保护不力的原因之一，各大平台仅仅通过用户权限来限制用户使用数字出版物，并没有对出版物本身采取数字签名等加密措施，一旦被盗版，验证和取证工作耗费很多人力物力。下面那某个项目为例：
支付密码
签名方法在modules/signatures.js文件里，类图如下：
image
我们还是从Api开始，代码如下：
// modules/signatures.js文件
router.map(shared, {
"get /fee": "getFee",
"put /": "addSignature"
});
library.network.app.use('/api/signatures', router);
通过上面的代码，可以了解签名提供了两个简单的公共接口：
get /api/signatures/fee -> shared.getFee
put /api/signatures/ -> shared.addSignature //签名操作
显然，最核心的方法也就是shared.addSignature，代码：
shared.addSignature = function (req, cb) {
...
library.scheme.validate(body, {
properties: {
...
},
required: ["secret", "secondSecret"] },
function (err) {
...
library.balancesSequence.add(function (cb) {
if (body.multisigAccountPublicKey && body.multisigAccountPublicKey != keypair.publicKey.toString('hex')) { modules.accounts.getAccount({publicKey: body.multisigAccountPublicKey}, function (err, account) {
...
try {
var transaction = library.logic.transaction.create({
type: TransactionTypes.SIGNATURE,
sender: account,
keypair: keypair,
requester: keypair,
secondKeypair: secondKeypair,
});
} catch (e) {
return cb(e.toString());
}
... }
毫无疑问，支付密码也是一个简单的交易（交易类型TransactionTypes.SIGNATURE）。基于此，我们不难想象，添加类似比特币的签名功能也是件非常简单的事情。
再简单一点：
image
发送方把hello kitty的信息进行双重处理。首先是通过接收方公钥来进行加密。
为什么要接收方的公钥来加密? 因为只有接收方的私钥可以解开接受方公钥加过的密，所以只有接受方可以解密。
然后hello kitty还要通过哈希值得到摘要，接要再经过发送方私匙进行签名，签名后得出的原文密文和发送方签名一起发给接受方。
接收方用自己的私匙解开密文，得到hello kitty.
然后通过哈希得到摘要。
另外则是通过发送方的公钥解开发送方签名，得到摘要，并且通过解密原文密文的摘要和解密发送方签名的摘要进行对比，最后的摘要一致，则认为摘要是对的。
通过这样的方式，接受方完成了对发送方签名过的hello kitty信息的认证。
这里要记一个口诀，公钥加密，私钥解密，私钥签名，公钥解密。
再短一点，则是公钥加，私钥解，私钥签，公钥解。
有个问题，为什么用接收方的公钥加密hello kitty？因为通过这种方式，只有接受方的私钥才能解开。
为什么要用发送方的私钥签名，不用其它人的私钥签名？因为这种方式，才能让接收方确认这条信息是发送方发出来的。只有发送方的公钥才能解开发送方的签名。
2
多重签名
什么是多重签名
比特币的匿名性，使交易处于不可信之中，最终导致用户不敢交易。有了签名功能，就有了确认双方信息的有效手段。那么，什么是多重签名呢？
多重签名，可以简单地理解为一个数字资产的多个签名。多重签名预示着数字资产可由多人支配和管理。多重签名，就表示动用这笔资金需要多个私钥签名，通常这笔资金或数字资产会保存在一个多重签名的地址或账号里。类似于生活中有一份文件需要多个部门签署才能生效一样。
多重签名是数字签名的升级，它让区块链相关技术应用到各行各业成为可能。在实际的操作过程中，一个多重签名地址可以关联n个私钥，在需要转账等操作时，只要其中的m个私钥签名就可以把资金转移了，其中m要小于等于n，也就是说m/n小于1，可以是2/3, 3/5等等，是要在建立这个多重签名地址的时候确定好的。
例如，电子商务、财产分割、资金监管等。例如，一对夫妻要储备一笔资金，供孩子上大学使用，在这之前谁都不能动，那么把签名模式改为2/2，不仅限制了夫妻双方，也给黑客攻击增加了难度。多重签名的设计，让各种业务去中心化充满无限可能。
工作原理
数字资产在某种情况下，需要多人支配。换句话说，在某些特定条件下，数字资产如果无法确认归属某个特定的人，那么最好让相关人共同签署它的所有权。
仍然举上面的例子，在Alice发货之后，Imfly收到货之前，这笔钱应该由第三方信用比较高的中介暂时保存，这个阶段，这笔钱要么是Alice的，要么是Imfly的，最终的归属要看Imfly是否收到货。所以，这个第三方，无论如何都是应该有的，不然Imfly就要承担大部分风险（因为比特币的单向不可逆，Imfly发送之后就没有办法收回了）
这样一来，这笔钱的所属关系，在交易过程中涉及到Alice、Imfly和平台第三方（虽然不属于它，但它有权裁定资金去向），那么就应该由他们三方签名，因此网上购物就是典型的多重签名的例子。其多重签名模型就是2/3，也就是说只要他们中的两个签名，资金就可以被转移。
具体到这个例子，Imfly把钱打给一个关联三方私钥的多重签名地址，如果整个交易过程顺利，只要Alice和Imfly两个签名，这笔钱就会顺利到达Alice手里。如果不顺利，他们任何一人提出仲裁，平台第三方调查之后，通过签名就能把这笔钱转给Alice或退回Imfly。这非常类似淘宝和京东的模式，但是比他们更加便捷和安全，至少不用担心第三方倒闭、挪用资金或携款跑路。
应用场景
很显然，多重签名给了加密货币腾飞的翅膀，让它单一单项支付的能力更具吸引力，让加密货币技术应用到各行各业成为可能。这里简单的罗列几个应用场景，供探索和思考：
电子商务。比较常见的是2/3的模式。上面电子商务网站的例子，就是最典型的场景之一，目前已经有成功的案例了。延伸一下，这类应用本质就是中介，所以还可用在各类中介机构性质的服务上。
财产分割。比如夫妻双方共有财产，可以使用1/2的模式，一个账户谁都可以使用，跟各自拥有帐号一样，好处是系统忠实记录了每个人的花销，闹掰的时候很容易清算。扩展到公司合伙经营，可以使用1/n模式，n个人合伙人，都可以直接支配共有资金，具体清算时，一目了然。
资金监管。其实，这是多重签名的最直接作用，一笔钱需要多个人签名才能使用，任何一个人都无法直接动用资金，这在生活中太常见了，只要灵活设置多重签名的比重模式，就能解决生活中很多问题。比如，接着上面夫妻的例子，夫妻要储备一笔资金，供孩子上大学使用，在这之前谁都不能动，那么把模式改为2/2，不仅限制了夫妻双方，也给黑客攻击增加了难度.
多重签名的设计，让各种业务去中心化充满无限可能。
多重签名
多重签名方法在modules/multisignatures.js文件里，类图如下：
image
实现Api的代码如下：
router.map(shared, {
"get /pending": "pending",
// Get pending
transactions "post /sign": "sign",
// Sign transaction
"put /": "addMultisignature",
// Add multisignature
"get /accounts": "getAccounts" });
library.network.app.use('/api/multisignatures', router);
解析一下，最后产生的Api如下：
get /api/multisignatures/pending -> shared.pending // 查询等待中的交易
post /api/multisignatures/sign -> shared.sign // 签名交易
put /api/multisignatures/ -> shared.addMultisignature // 创建多重签名帐号
get /api/multisignatures/accounts -> shared.getAccounts // 获得关联的帐号（对应者用户私钥）
提供的功能很显然，包括：待交易查询、关联帐号列表查询，用户签名交易，创建多重签名帐号等4个核心功能。我们先从创建多重签名帐号开始，这个Api使用的是http的put方法，对应的自然是更新操作，不查看代码也可以猜想到，该功能应该是在已有帐号基础上的操作，从客户端钱包设置菜单里，可以看到如图操作：
image
看看shared.addMultisignature的源代码如下：
// modules/multisignatures.js文件
shared.addMultisignature = function (req, cb) {
var body = req.body;
library.scheme.validate(body, {
... required: ['min', 'lifetime', 'keysgroup', 'secret'] },
function (err) {
...
library.balancesSequence.add(function (cb) {
modules.accounts.getAccount({publicKey: keypair.publicKey.toString('hex')}, function (err, account) {
...
try {
var transaction = library.logic.transaction.create({
type: TransactionTypes.MULTI,
sender: account,
keypair: keypair,
secondKeypair: secondKeypair,
min: body.min,
keysgroup: body.keysgroup,
lifetime: body.lifetime
});
} catch (e) {
return cb(e.toString());
}
... };
创建一个多重签名，必须'min', 'lifetime', 'keysgroup', 'secret'这四参数（其实，一个默认参数就是当前帐号），min代表上面讲到的m值，即需要确认的人数;lifetime代表生命周期;keysgroup包含多重签名关联的全部帐号，它是数组类型，包含的元素个数就是n，secret是用户密码，与用户私钥对应。
经过一系列的验证之后，作为一个交易（交易类型TransactionTypes.MULTI）保存到数据库(区块链)里。创建成功的帐号，可以显示多重帐号菜单，对交易进行操作。接下来，自然应该能够查看全部关联的帐号（请看shared.getAccounts方法），查看待确认的交易（请看shared.pending方法），这两个方法仅仅是简单的查询，没什么难度，这里不再浪费篇幅。
如果用户同意交易，就可以对待确认的交易进行签名（shared.sign方法），这个方法的源码如下：
shared.sign = function (req, cb) {
var body = req.body;
library.scheme.validate(body, {
...
required: ['transactionId', 'secret'] },
function (err) {
...
function done(cb) {
library.balancesSequence.add(function (cb) {
var transaction = modules.transactions.getUnconfirmedTransaction(body.transactionId);
if (!transaction) {
return cb("Transaction not found"); }
transaction.signatures = transaction.signatures || [];
transaction.signatures.push(sign);
library.bus.message('signature', {
signature: sign,
transaction: transaction.id
}, true);
cb();
}, function (err) {
if (err) {
return cb(err.toString());
}
cb(null, {transactionId: transaction.id});
});
}
... };
这个方法，相比单独的签名方法，不同的是单独的签名方法相当于一个新建交易，而这里的多重签名的用户签名，显然仅仅是对未确认交易进行签名确认（640行维护了一个签名数组，push方法把用户签名写入数组）。
延伸阅读：区块链100讲：梅克尔树保障区块链数据不可篡改，想换根就要砍树！
内容来源：图书--机械工业出版社华章分社《链接未来：迎接区块链与数字资产的新时代》；公众号--区块链研究实验室、链社区
作者：许子敬、链三丰、社长等
整理：Cynthia
活动推荐
image
扫描下图中二维码或点击“阅读原文”即可报名参加
网友评论