Factom 这个 Solution 在 2014 年的时候就已经推出了,现在已经 2018 年了,我才来写这一篇分析文章可能有些迟了,但是它是十分具有参考价值的.因为现阶段来开区块链虽然炒得火热 -- 养猫,养狗,草泥马之类的,但是真正成熟的应用比较少,有很多连基本的链平台都没有开发完全.而 bitcoin 作为区块链的 1.0 时代的代表,也是区块链行业的标杆存在,它的生态是最完整的 -- 矿池,钱包,交易所.但是相对于区块链 2.0Ethereum 来讲功能就比较单一了,它的智能合约 -- 公钥脚本功能单一,不是图灵完备的.基于 bitcoin 开发的应用就比较少,而 ethereum 上面的应用就多达 800 多个(养猫应该是最火的了).
但 bitcoin 不是说不能基于它去做一些事情,它也有一些扩展协议可以让 bitcoin Blockchain 来发挥更大的作用,比如说 OP_RETRUN 扩展交易.而 Factom 就是基于这个协议,如果换做此时此刻的话,Factom 的创始人可能会选择更加方便的 Ethereum,而不是 Bitcoin,但在 14 年的时候以太坊还不是很成熟,而 Bitcoin 则更加的稳定可靠,时至今日 Bitcoin 很少会因为本身的漏洞而造成财产损失,大多数都是因为交易所遭受攻击而导致大量的 Bitcoin 被黑客盗取.这一点一要归功于 pow 这个被人'诟病'的协议,二,它没有支持图灵完备的智能合约,功能单一也有好处,有时越简单粗暴的越可靠,像以太坊就因为智能合约 sdk 的漏洞造成过两次大规模的 ether 泄露.
一,Bitcoin 的 OP_RETRUN 协议介绍
OP_RETURN 是一个脚本操作码,用于将事务输出标记为无效.由于任何带有 OP_RETURN 的输出可证明是不可靠的,OP_RETURN 输出可以用来烧毁比特币.
比特币社区的许多成员认为使用 OP_RETURN 是不负责任的,部分原因是比特币旨在为金融交易提供记录,而不是任意数据的记录.此外,对于外部大规模复制数据存储的需求本质上是无限的,这一点显而易见.尽管如此,与在区块链中存储数据的一些其他方式相比,OP_RETURN 具有不会创建虚假 UTXO 条目的优势. 从比特币核心版本 0.9.0: 这种变化并不意味着将数据存储在区块链中. OP_RETURN 类型的交易请求创建了一个可证明的可修剪 txo,以避免数据存储方案(其中一些已经部署)将诸如图像之类的任意数据存储为永远不可用的 TX 输出,从而膨胀了比特币的 UTXO 数据库. 在区块链中存储任意数据仍然是一个坏主意,在其他地方存储非货币数据的成本更低,效率更高.
二,Factom 的基本原理在阐述基本原理之前,我先说几个有关于 Factom 的关键词:
Factoids : factom 发行的代币,使用 factom 的服务时要消耗代币,而且不可以交易.
Entry Credits:提交 Entry 时要消耗 Credits,而 Credits 是用 Factoids 换取的,可以交易.
Entry:提交到 Factom 上存储的文件
Entry Block:记录 Entry 完整性(Hash 值)证明的区块
Directory Block:记录 Entry Block 块完整性(Hash 值)证明的区块
ChainID:APPlication 的账本 ID
APPlication:基于 Factom 服务开发的应用
Federated Servers:用来管理运行 Factom 的分布式服务集群
Auditing Servers:审查节点,这些审查节点负责审查 Federated Servers 的生成的账本是否合法
看到这,你想必应该猜测到了,Factom 是有自己的账本 --chain 的,不光 Factom 有每一个 App 都有自己对应的 chain.
factom 存证充分的利用了 Merkle Hash tree,它的最基本原理就是: 首先将一段时间内上传的数据都纳入到 Merkle Hash tree(间接或者直接);然后每隔 10min 中 Root Hash 加入到 OP_RETRUN 交易中,锚定到 bitcoin 区块链.
稍微了解过 bitcoin 原理的老铁应该都知道 Merkle tree 的精妙之处 -- 假定 root hash 是正确的,则在不知道其他叶子节点的情况下,仍然能证明单个叶子结点的完整性.这样做的好处就是你可以不需要关心其他叶子结点(在 Bitcoin 中是 Utxo,在 factom 中是 Entry 数据),也能证明自己的完整性,有老铁可能就问了这么费劲干啥?咋不直接把 Entry 的 Hash 锚定到 Bitcoin 上?贵啊!现在一个 Bitcoin 市值 $14,000 左右,矿工费最低要 0.0009(不同矿池收费标注不同),而且十分钟才能添加一块,还要等待 6 个块确认,不说矿工费开销大,效率也低啊.利用 Merkle tree 可以上传最少的数据 32bytes(上面说过一个 OP_RETURN 最多 40),同时又能证明大量的数据完整性,何乐而不为?
本图将 Factom 大致的逻辑关系已经呈现的很清楚了:
1.APP 的运营者先去 Factom 上买 Factoids,然后将 Factoids 兑换成 Entry Credit
2.APP 将数据提交到 Factom Servers,加入该 APP 对应的 Entry Chain
3. 将 当前周期内上传 Entry 打包成 EntryBlocks(白皮书上显示 1min 钟生成一个块);
4. 将 当前周期内生成的 EntryBlocks 打包成 Directory Blocks;
5. 间隔一段时间(白皮书显示是 10min,正好是比特币生成区块的平均时间)将未锚定的 Diretory Blocks 加入到一个 Merkle tree 中(按照白皮书说法应该是 10 块);
6. 将 root hash 锚定到 Bitcoin 中
APP 参照了中本聪在 bitcoin 白皮书中提到的 SPV 原理,只要关心和自己相关的数据就好了.
三,Factom 的组织架构
Factom 整个架构体系中有三层,如下:
Factom 的账本有四层,如下:
APPLication
---------------------------------------
FACTOM Server| Audis Server
---------------------------------------
BItcoin Miners
3.1 我们先按照架构体系来说:
APP Entry Chains | FactorId Chain | Credit Chain
------------------------------------------------------
Entry Blocks
------------------------------------------------------
Directory Blocks
-----------------------------------------------------
Bitcoin Blocks
APPlication :由开发者开发面向用户的应用,它们都使用了 Factom 的服务来做数据存储证明.我们下面描述一下 APP 加入 Factom 的过程:
setup 0: 一个 APP 在初始化加入 Factom 体系时候做的第一件事就是充钱(不充钱你怎么能变强?),你将公钥发送给 Factom Server,Factom Server 会分配给你一笔 Factoids,这笔交易会记录在 FactorId Chain 中.
setup 1 : 服务器 会向你反馈一个 Entry 确认信息, 同时会向外广播这个确认信息(我们前面说过 factom 是有一个分布式服务集群的)
setup2:APP 用 Factoids 换取 Entry Credit, 服务器会将这笔交易记录在 Credit Chain 中,同时向外广播.
setup3:APP 上传第一个实体 Entry(初始化,里面包含着你自己定义的 Entry 校验规则的 Hash 值,或其他细则),服务器会帮你创建一个对应 ChainId 的账本,同时扣除相应的 Credit,向外广播消息.
ps: ChainId ID 是由 APP 自己定义的 ChainName 的 Hash 值.
创建后提交一个 Entry 的过程就是 setup 1~3 的过程,当然客户端看起来就这么简单,在服务端就复杂多了.同时这里面我们要重点强调的是,Factom 服务器不负责校验 Entry 数据的合法性,数据的合法性是在 APP 这一端校验的.我们可以在创建账本的时候将校验规则(比如一个审计程序)的 Hash 加入到第一个 Entry 中,这个审计程序在 APP 运行,这样就能屏蔽掉那些无效的 Entry.
Factom Servers: factom 有一个分布式的服务集群,每一个服务器都会负责一维护部分 APP 的账本,同时将更新同步到其他服务器中.Factom 中服务器有两种类型,一种是记账服务器,一种是审查服务器.
我们来讲一下 servers 的工作过程,首先介绍几个关键词:
process list: 每一个服务器都要维护一个 list,这个列表里面存储着本服务器和其他服务器负责的 chain.
Weighted Number of Entry Credits: 根据消费的 Credits 计算出投票权重用于选择 Factom Server
Weighted Number of Entries:根据 Entry 计算出投票权重用于选择 Factom Server.
Factom Servers 一个记录周期如下:
所有服务器重设其进程列表(Process List)为空.
用户通与其
Entry信用的积分(Entry Credit
)相关的公钥提交付款
根据用于支付的公钥,轮值服务器接受该付款.
该服务器向网络广播该支付被接受.
用户看到支付被接受, 然后提交 Entry.
根据 Entry 的 ChainID,其中一台服务器把 Entry 加入其进程列表,并添加进入到相应链的区块中(如果这是该链的第一个 Entry, 那就创建这个新链).
服务器对网络广播该 Entry 的确认,内容含有 Entry 在 Process list 中的位置(Index) + Hash(Entry)(链接到 Entry 付款)+ Hash(process list).
所有其他服务器更新该服务器的 process list,验证该列表,并更新该链的区块.
只要用户可以验证到相关的 process list 中包含自己的提交的数据 Entry,那么他们就可以有相当的信心相信它会被成功地被录入到 Factom 上.
在一分钟结束时,所有服务器确认 process list 的 高度,揭示一个确定性的秘密数值(该值为一个 Reverse Hash 值,即一条较长的,连续的区块链哈希值的原像值),还有被处理区块的一系列哈希值(将与 process list 中的最后一项相匹配).
那一分钟的目录区块(Directory Block)是由所有服务器中定义的所有 Entry 区块(Entry Block)组合到一起建造而生成的.因此,每个服务器都拥有所有的 Entry 区块(Entry Block),所有的目录区块(Directory Block),和所有 Entry(all Entries).
使用 Reverse Hash 值的集合来创造一个种子,为下一轮的 ChainIDs 重新分配服务器.
在完成 10 个目录区块后,请执行以下操作:
a 对最后一分钟的 Entry 块创建梅克尔根(Merkle Root),按 ChainID 排序.
b 创建最后一分钟的目录区块,并计算其梅克尔根(Merkle Root).
c 用 10 个目录区块的梅克尔根(Merkle Root)创建一个锚定
d 用服务器的反向哈希值集合来创建一个种子,再用其选择下一个服务器来把锚定写到比特币区块链
14. 重复. (又从第 1 部开始循环)
Factom 为了防止腐败发生,所以它的 Servers 集群中记账的服务器是会不断变化的,每隔 4 个小时进行一次选举,由 user 投票来决定哪些服务器能够成为 Factom 的记账服务器,用户投票的权重是根据 Weighted Number of Entry Credits 和 Weighted Number of Entries 计算出来的,所有的服务器都会参选最后进行一个排名,然后选择前 n 名成为 Federated Servers 其余的为 Auditing Servers. 为了防止被选择的服务器发生故障,每隔四秒就要广播心跳包(Entry 确认信息),如果一台服务器没有收到 X 的心跳包就会发送一个 SFM 信息认为 X 是故障的,如果大多数(没有给出阈值)认为 X 服务器是故障的,那么 X 服务器就会降级,由第 n+1 名服务器升级为 Federated Servers,X 降级为 Auditing Servers.
ps0:大家可能会困惑既然合法性校验放在了 client side,那么 Auditing Servers 有个卵用?Auditing Servers 有两个作用: 一,审查 Federated Servers 生成块是否符合规则;二,为 Entry 提供存在性证明(Proof of existence)(这是从 Factom 社区里面得到的回复).
ps1:Weighted Number of Entry Credits: 加权最近六个月购入的入场券数量(每月购买金额,当月加权 6 次,前 5 次加权等) ;Weighted Number of Entries: 加权最近六个月使用的条目数量(每月使用的条目数量,当前月份加权 6 个,前一个加权 5 个).
bitcoin miner:这一层我就不多说了.
上面就是按照体系架构来讲述一下它工作的基本流程,Factom 的实现比较复杂.
3.2 我们再按照账本层次来说:
Directory Blocks
目录块中引用的每个 Entry 块占用 64 个字节(两个 32 字节散列,Entry Block 的 ChainID 和 Merkle 根).一百万个这样的条目将导致一组目录块大小约为 64MB.如果平均的每个 Entry Block 有 5 个 Entry,64 MB 的 Directory Blocks 将提供 500 万个不同 Entry 的高级管理.Factom 服务器收集 Entry Block 的 Merkle 根并将它们打包到目录块中.十个连续的目录块通过 Merkle 树散列,Merkle 根被记录在比特币区块链中.这允许区块链的最小扩展,并且仍然允许通过比特币散列权限保护分类账.将 Merkle 根加入比特币区块链的过程称为 "锚定".有关更多详细信息,请参阅 "附录:比特币时间戳" 部分.从带宽和存储的角度来看,输入到目录块中的数据是最昂贵的.如果 Factom 用户希望在链中找到数据,那么他们需要从账本创建时开始的所有目录块.会增加目录块大小的 Active 包括 APP chain 的创建和首次更新.这些 Active 将 APP 程序细化账本规则的 花费 进行了公示.相比记录一个 Entry,APP 必须要花费更多的 Entry 积分来执行这些特殊的 Active,这样可以阻止目录块的膨胀.也就是说实际上 Directory block 中记录的是一个 map 的表.
Entry Blocks
Entry Block Later 是系统中的第二层级.APP 将拥有各自的 ChainID.在 Entry Blocks 里,APP 可以 ChainID 为线索扩展搜索所有相关的条目.每个目录块中包含的 chainId 都会有一个更新的 Entry Block.Entry Block 包含上传的 Entry 的散列值.Entry 的哈希证明了数据的存在,同时也充当在分布式哈希表(DHT)网络中查找 Entry 的 Key. (更多细节参见 "Factom 点对点网络 Entry Block 有意不包含 Entry 本身.这使得 Entry Block 很小.从 Entry Block 中分离 Entry 还可以使审计人员更容易审计.审核员可以在一个单独的链中,这个链用来记录那些来自普通链中的被批准或被拒绝的 Entry.审核员可以在其 Entry 中增加拒绝的理由.如果应用程序信任审核员,他们可以交叉引用审核员批准或拒绝每个 Entry,而不需要知道 Entry 是什么.然后应用程序将只尝试下载通过审计的 Entry.多个审计人员可以引用相同的 Entry,并且条目将只在分布式散列表(DHT)上存在一次.预计条目将比散列占用的仅仅 32 个字节大得多.要忽略的事物列表不一定要让应用程序忽略完整的对象.输入块包含与 ChainID 相关的所有可能的输入项.如果一个 Entry 没有在 Entry Block 中被引用,那么可以假定它不存在,这允许应用程序证明是否定的.
ps:现在 Factom 并未构建起 DHT 存储,他们准备和 IPFS 进行合作来存储文件.
Entrys
记录是被用户创建并提交到 Factom 的.通过散列和编码信息,用户可以确保记录的隐私性.如果编码或隐藏数据是不必要的话,那么记录可以替换成为纯文本.通过记录一份文档的一段哈希值,Factom 可以提供
基本的发布证明 (proof of publication)
.稍后, 人们可以生成文档的哈希值, 并和之前链块记录的哈希值进行比对, 来判断文档是否是当初发布的那个版本.这在数据的处理可以有很大的灵活性,可以出现类似超链接的东西.数据还可以更庞大,但不能过于庞大.,因为数据越大需要付的费用也越多.这和比特币比较相似,超过 100 兆字节的比特币转账数据是可能发生的,但需要支付更多的转账费用.Factom 可以处理比比特币网络里大得多的数据,由于比特币的完整节点需扫描完整的区块链数据,所以区块链体积不能太大.在 Factom 中完整节点只需要扫描最高级的目录区块 (Directory Block), 并不需要扫描全部的链块数据.如果人不对链数据感兴趣的话,完全可以忽略它.
ps:Factom 实际上到底有没有存储这些 Entry 链接的文件尚未得知,我在社区中询问但是没有得到解答.
最后给大家上一个总体的账本结构图,如下:
参考网址:
https://www.factom.com/devs/docs/guide/factom-white-paper-1-0
http://www.8btc.com/factombaipishu
https://en.bitcoin.it/wiki/OP_RETURN
https://www.cnblogs.com/fengzhiwu/p/5524324.html
----------------------------------------------------------------------------------------------------------------------- 分割线 ------------------------------------------------------------------------------------------------
以上的内容一部分来自我自己从白皮书中的翻译,一部分引用于上面的网址,其中还有一些不确定性,我在注释中已经指出,如果哪位老铁知道答案的话请在评论区留言,我会及时改正.下面我阐述一个自己并不成熟的观点,就是基于 pow 链的存证系统有多大价值?我们知道现在数据存证常用的是数字签名,既可以保证数据的完整性,又能保证数据的合法性.最多我再多云备份几份,你这个存证系统到底有什么存在的必要?
从密码学破解的角度来看,篡改 Factom 中的 Hash 证明要比篡改签名难度等级要高.因为 Factom 锚定到了 bitcoin 上,这是一种信任的传递,你如果要想篡改出来一个合法的 Hash 证明首先要从 bitcoin 区块下手.而且随着时间的推移,后续块的增多篡改的难度越大,这相比从公钥推导出私钥的难度要更大!(当然这是在私钥没有被窃取的条件下,如果你的用户私钥被窃取,或者说你的 Factom 账号被窃取,你仍然可以去篡改 Entry 的 Hash 证明.)
但是,从现阶段来看,这两者都是基本 "零" 可能.然而当量子计算机出现的时候情况就不一样了,量子计算理论上可以暴力破解非对称加密,虽然格密码理论上能够抵御量子计算,但现有的 PKI 体系还是难免会收到冲击.而这个时候 Factom 的作用就体现出来了,你可以去破解 ecc 和 rsa 的证书去伪造证明,但是你依然很难篡改 Bitcoin 账本.因为区块链账本是靠强大的 hash 算力保护的,而量子计算机在破解 hash 算法上并没有什么优势,所以伪造区块依旧很难,只要是已经存在的账本正确性依旧难以动摇.
附,量子计算机维基百科:
历史
随着 计算机科学 的发展, 史蒂芬 · 威斯纳 在 1969 年最早提出 "基于量子力学的计算设备".而关于 "基于量子力学的信息处理" 的最早文章则是由 亚历山大 · 豪勒夫 (1973),帕帕拉维斯基(1975), 罗马 · 印戈登 (1976)和 尤里 · 马尼 (1980)年发表 [2] [3] [4] [5] .史蒂芬 · 威斯纳的文章发表于 1983 年 [6] .1980 年代一系列的研究使得量子 计算机 的理论变得丰富起来.1982 年, 理查德 · 费曼 在一个著名的演讲中提出利用量子体系实现通用计算的想法.紧接着 1985 年 大卫 · 杜斯 提出了 量子图灵机 模型 [7] .人们研究量子计算机最初很重要的一个出发点是探索通用计算机的计算极限.当使用计算机模拟 量子 现象时,因为庞大的 希尔伯特空间 而数据量也变得庞大.一个完好的模拟所需的运算时间则变得相当长,甚至是不切实际的天文数字.理查德 · 费曼当时就想到如果用量子系统所构成的 计算机 来模拟量子现象则运算时间可大幅度减少,从而量子计算机的概念诞生.半导体靠控制 集成电路 来记录及运算信息,量子计算机则希望控制原子或小分子的状态,记录和运算信息.
量子计算机在 1980 年代多处于理论推导状态.1994 年 彼得 · 秀尔 (Peter Shor)提出 量子质因数分解算法 后 [8] ,证明量子计算机能做出 离散对数 运算 [9] ,而且速度远胜传统电脑.因为量子不像 半导体 只能记录 0 与 1,可以同时表示多种状态.如果把半导体比喻成单一乐器,量子计算机就像交响乐团,一次运算可以处理多种不同状况,因此,一个 40 比特的量子计算机,就能在很短时间内解开 1024 位电脑花上数十年解决的问题.因其对于现在通行于银行及网络等处的 RSA 加密算法 可以破解而构成威胁之后,量子计算机变成了热门的话题,除了理论之外,也有不少学者着力于利用各种量子系统来实现量子计算机.
基本概念
传统计算机即对输入信号序列按一定算法进行变换的机器,其算法由计算机的内部逻辑电路实现.
输入态和输出态都是传统信号,用 量子力学 的语言来描述,也即是:其输入态和输出态都是某一力学量的 本征态 .如输入二进制序列用量子记号 0110110,用量子记号则为 | 0110110> .所有的输入态均相互 正交 .对传统计算机不可能输入如下 叠加态 :c1 |0110110> + c2|1001001> 0110110 {\displaystyle 0110110} ,用量子记号,即 | 0110110 ⟩ {\displaystyle \left|0110110\right\rangle} .所有的输入态均相互 正交 .对传统计算机不可能输入如下 叠加态 : c 1 | 0110110 ⟩ + c 2 | 1001001 ⟩ {\displaystyle c_{1}\left|0110110\right\rangle +c_{2}\left|1001001\right\rangle } .
传统计算机内部的每一步变换都演化为正交态,而一般的量子变换没有这个性质,因此,传统计算机中的变换(或计算)只对应一类特殊集.
量子计算机分别对传统计算机的限制作了推广.量子计算机的输入用一个具有有限 能级 的量子系统来描述,如二能级系统(称为 量子比特 (qubits)),量子计算机的变换(即量子计算)包括所有可能的正变换.
量子计算机的输入态和输出态为一般的叠加态,其相互之间通常不正交;
量子计算机中的变换为所有可能的正变换.得出输出态之后,量子计算机对输出态进行一定的测量,给出计算结果;
传统计算是一类特殊的量子计算,量子计算对传统计算作了极大的扩充,其最本质的特征为 量子叠加性 和 量子相干性 .量子计算机对每一个叠加分量实现的变换相当于一种经典计算,所有这些传统计算同时完成,并按一定的概率振幅叠加起来,给出量子计算机的输出结果.这种计算称为量子并行计算.
来源: https://www.cnblogs.com/cnblogs-wangzhipeng/p/8270075.html