Topic: 公证通Factom白皮书：利用区块链真实地记录一切 (Read 1887 times)
公证团队是哪里的
公证通是刚出来的？
公证通我十分看好它的团队和前景。
公证算老币了
公证通这几天很不给力呀
应用前景不错
這是很好的構思 
现在价值几何，一年多了，有多少应用呢？
老币重提，真的那么好吗？
听说这个币 火的不要不要的!
公正通应该也有机会拿融资吧
这个币确实算不错的了
这个币确实不错，可惜错过了
这个币确实不错，可惜错过了 
难得还有这样的币
嗯，去看看
老是推这个币？
这个币确实不错，可惜错过了
好长的一段文字，看得我都凌乱了
Factom正在革新整个世界对数据的记录方式，并利用比特币区块链技术来保护您的数据安全。
图片无法粘贴上来，可以直接查阅 http://www.8btc.com/factombaipishu
公证通Factom白皮书 1.0版
在区块链上建立不可更改的审计公证业务流程
摘要：
Factom利用比特币的区块链技术来革新商业社会和政府部门的数据管理和数据记录方式。
利用区块链技术帮助各种各样应用程序的开发，包括审计系统，医疗信息记录，供应链管理，投票系统，财产契据，法律应用，金融系统等。开发者能够创造新的应用程序，并把数据保存在区块链上面，同时不用受到直接把数据写入比特币区块链的各种限制：例如写入的数据速度，成本，大小等限制。
Factom维护了一个永久不可更改的、基于时间戳记录的、区块链数据网络。大大减少了进行独立审计、管理真实记录、遵守政府监管条例的成本和难度。
商业社会和政府部门可以利用Factom简化数据记录的管理，记录商业活动，并解决数据记录安全性和符合监管的问题。
Factom正在革新整个世界对数据的记录方式，并利用比特币区块链技术来保护您的数据安全。
一、概要
“诚信是具备颠覆性的” – 保罗·斯诺
在当今的全球经济中，信任是稀有的。这种信任的缺乏，造成了大量资源的投入来进行审计和记录核查，从而降低了全球效率，投资回报率和经济繁荣。此外，如2010年美国的次贷危机等事件表明，目前的审计和核查流程是非常不准确和低效的，容易造成问题。 Factom提供了世界上首个准确的，可核查的和不可更改的审计公证流程和方法，从此我们不再需要盲目信任。
在过去，记录靠手工完成，数据的保护，同步更新和真实性的验证都非常困难。其中的一部分流程被计算机自动化以后，并没有使这些事情变得容易，反而是变得更加困难，因为电脑记录是如此容易被更改。权限和可靠性被四分五裂的分割到无数的独立系统中。
区块链提供了一个分布式的机制进行数据锁定，使数据可以被核查和独立审计。比特币区块链是现存最值得信赖的不可变的数据存储，但这往往只限于比特币交易上。 Factom能使企业获得最新的区块链技术，而又无需在采用虚拟货币的问题上陷入麻烦。
在本文中，我们将介绍Factom是如何创建一个分布式的，自治的协议，并把比特币区块链从Bitcoin网络中剥离。我们将讨论 客户端自定义的记录链（Chains of Entries），客户端如何验证记录条目，分布式共识算法， 基于区块链锚定的安全机制等。
111
二、Factom设计目标
用Factom创建更快，更便宜，无膨胀的方式来开发区块链应用
中本聪推出的比特币区块链彻底改变了交易记录的方式。在这以前从未存在过永久的，分散的，和无需信任的分类账。开发商纷纷开始开发建立在这个分类帐之上的应用程序。不幸的是，由于比特币一些初始的设计权衡， 他们已经碰到了几个核心的约束和问题：
1）速度 – 因为比特币的分布式设计和工作量证明的共识方法，工作量难度会被调整到以保持大致10分钟确认时间。对于希望更大的安全性的应用中，多个确认可能是必需的。一个常见的要求是要等待6确认，这可能会导致等待时间超过一个小时。
2）成本 – 默认的交易成本大约是0.01 mBTC（约0.003美元美元于2014年11月）。 BTC的交易价格一直不停的波动。如果BTC的价格上涨，则交易成本也上去了。这对需要管理非常大的数字交易数据的应用程序来讲， 是一个严重的成本障碍。此外，还有许多因素，如对区块大小的限制和奖励减半等，会导致交易费用增加。
3）区块链膨胀 – 比特币区块大小限制目前是1MB，交易流量的上限是每秒7交易。任何应用程序想要使用区块链写入和存储信息都将会增加流量。这个问题已致使各方寻求增加区块大小限制。
Factom是旨在解决这三大核心约束的协议。 Factom协议为应用程序提供的功能和特性超越了虚拟货币。 Factom构建了一个标准的，有效的，安全的基础，这将使应用程序的运行速度更快，更便宜，并且不会造成区块链膨胀。
三、Factom生态系统
Factom生态系统的几个主要部件，描述如下：
121
一旦系统建立后，Factoids（即Factom币）和用户帐户会被激活，用户将会交易Factom币。Factom和比特币具有以下主要的互动：
1.应用程序用户使用Factom币（Factoids）购买数据条目信用（Entry Credit）
2.应用程序记录数据条目
3. Factom服务器创建条目区块和目录区块
4. Factom将目录区块的哈希值锚定到比特币区块链
这些数据条目和区块链互动的部分请细看下面的几个章节。
安全性和证明
Factom如何保障条目的安全记录？
Factom把比特币的功能拓展到其货币属性之外的事件记录的功能。 Factom设有最小的规则集，用于永久记录数据条目。 Factom让客户的应用程序来执行大多数的数据验证任务。唯一Factom强制实施的验证是那些通过协议要求交易Factoids，购买条目信用，并确保条目正确付款和记录。
Factom具有关于激励运行网络和内部一致性的一些规则，但它不能检查用户记录的信息本身的真实性和有效性。
比特币交易限制被限制为从一组输入值集合映射到到一组输出值集合。只要满足输入值条件的输入值集合（通常需要一定的签名）就可以保证系统输入的有效性。这是可以实现自动化一个验证过程，所以可以使审计过程是容易的。例如，为了记录的房地产的产权转让，Factom可以只记录转让发生那一刻的过程。现实世界中，房地产产权的转让的规则是非常复杂的。 例如，一个地方管辖机构可能对房地产购买者有不同的和特殊的要求，如果买家是外国人，农民，或兼职居民，则购买限制条件是不一样的。房地产的地段位置，房屋价格，或建筑类别等不同属性，也可以使房地产被归到不同的类别中。每个类别都可以有自己的规则来反映智能合约的验证和执行过程。在这种情况下，单独一个加密签名不足以充分验证所有权转移的有效性。 此时Factom更多是用来记录房地产所有权转移和交易的发生，而不是验证房地产所有权转移是否有效。
比特币矿工主要执行两个任务。首先，他们解决双重花费的问题。看到两次花同样的一笔资金的相互冲突的交易发生时，他们选择哪一个是可以受理的和接受的。矿工（连同其他全结点）的第二个任务是进行交易验证和审核。由于比特币矿工只受理有效的交易，一个被包含在区块的交易是可以被假定为已经被审核。轻型客户端并不需要知道比特币的完整历史来看接受的资金是否已经被花掉了。 （见SPV客户端）。
Factom服务器和审核服务器如何验证数据条目？
Factom把比特币矿工做的事情分为两个任务：按照顺序记录条目和审计条目的有效性。
1 – Factom服务器接受数据条目，并将它们装入到不同的区块，并修复条目的顺序。 10分钟后，该条目的顺序通过插入到比特币区块链的一个锚定而变得不可逆转。 Factom通过对10分钟内收集的数据创建哈希值，然后把这个哈希值记录到比特币的区块链来实现这个功能。
2 – 条目的审计是一个独立的过程，可以依靠信任第三方或不依靠信任第三方来完成。审计是至关重要的，因为条目在被包括在Factom数据集之前， Factom是无法验证它们的真伪的。
以信任为基础的审计，轻型客户端可以信任他们选择一个称职的审计师。一个项目被输入到系统中以后，审计人员将可以验证输入是否有效。审计师将提交自己的加密签名条目。签名会显示该条目通过了所有审计师认为需要做的的检查。审计要求的条件实际上可能是一个Factom链的一部分。以之前的房地产为例，审计师会仔细检查财产转移是否符合当地标准。审核员将公开证明，财产转移是有效的。
不依靠信任的审计系统将类似于比特币网络。如果一个系统的有效性像比特币网络的数学定义一样完美，那么它可以实现程序化的审计过程。如果用于转移的规则能够由计算机进行审核，则应用程序可以下载有关的数据，并进行自我审计和审核过程。该应用程序可以通过下载数据条目，验证数据条目，并决定条目是否有效，从而使该应用程序建立起对系统的感知。
Mastercoin, Counterparty, 和Colored Coin也有类似的信任模型。这些都是基于客户端的验证协议，这意味着交易被嵌入到比特币的区块链上。比特币矿工不审核其有效性；因此，基于这些协议的无效的交易如果被故意设计伪装成有效的交易也可以嵌入到比特币的区块链上。支持这些协议之一的客户端通过对区块链扫描并寻找潜在的交易，检查它们的有效性，并对控制这些数字资产的地方建立说明和解释（通常是一个比特币地址）。在这些协议中，都是由客户端来执行自我审计。
要把这些由客户端验证的协议搬到Factom上，将会只是一个如何定义协议中的交易并建立一个链来保存交易的问题。和比特币相比，交易协议在Factom下不会有太大的不同。不同之处在于信息在Factom上很容易表达，而不必以某种特殊方式对其进行编码并嵌入比特币的交易信息中。
证明否定
比特币，土地登记，以及许多其他系统需要解决的一个根本性的问题：证明否定。他们证明了某个“东西”已经被转移到某个人，并证明这个“东西”还没有被转移给其他人。在无界系统里，否定的证明是不可能的，而在一个有界系统里它是很有可能的。 加密货币通过限制交易数据可以存在的地方来解决这个问题。比特币交易只能在比特币区块链里找到。如果某个交易没在比特币区块链里被找到，那它在比特币协议下就不存在，因此，该比特币就尚未被发送两次（双花）。
某些土地所有权记录系统是相似的。假设在一个系统里，土地转让要在政府登记，而且法律制度规定，未记录的转让是无效的（sans litigation）。如果一个人要检查某个产权是否明确（即，没有其他人声称这片土地所有权），答案就在政府登记处。利用政府记录可以证明为否定，土地不被第三方拥有。如果产权登记不是必须的，政府的注册表只能证明什么已被登记。私人转让很可能存在，注册表也就不能代表全部的转让情况。
在上述两种情况下，否定可以在某个环境中得到证明。以万事达币（Mastercoin）为例，这个证明是强而有力的。而土地登记，则仅限于被注册的环境下，可能遭到一定的质疑和挑战。现实世界是复杂的。Factom的设计，针对的不只是精确的数字资产，而且是物质的世界中复杂的现实情况。
在Factom中，数据分类有层次结构。 Factom只在链中记录数据条目；诸多用户定义的链在Factom执行的协议中没有互相依赖关系。这不同于比特币，每一笔比特币交易是都存在潜在的双重支付，因此它必须被验证。和把所有数据合并在一起成一个总账相比，Factom通过把条目放到多个链当中，可以让应用程序在较小的空间内搜索数据。
如果Factom要用来管理土地转让，使用某个链来记录的应用程序可以安全地忽略在其他链上的条目，比如那些本来用于保安摄像机的记录的链就不与需要更新。如果政府法庭判决需要变更土地转让记录，那么和其相关的链将被更新，以反映上述判决的结果。但更改的历史不会丢失，并且如果这样的土地产权变更的更改从法律或其他角度来讲无效的话，它的记录的内容和顺序在Factom上都不能被更改或隐藏。
尼克·萨博（Nick Szabo）在关于“房产俱乐部”的论述中，与本系统有许多重叠。以下是他在论文“安全产权与所有者权限”中的一个要点：
虽然暴徒还可以通过暴力攫取物质资产，但延续存在的正确的所有权记录将是留在盗用者眼中的眼中钉。
应用程序如何验证Factom链？
Factom不验证条目；条目是由用户客户端和应用程序来验证的。只要应用程序了解并熟知该条链应遵循的规则，那么无效条目的存在也不会引起不合理的干扰。在链里的不遵守规则的条目可以被应用程序忽略。
用户可以给他们的链设置任意规则，并且可以使用任意方法给这条链的用户传达这条链的规则。在这条链中的第一个数据条目可以被设计成这条链的一组规则，或某个审计程序的哈希值，等等。这些规则可以被应用程序理解，并通过运行Factom，在网络中忽略掉不符合这些规则的客户端应用程序。
强制执行的序列可以在每条链的规则中指定。不符合这种顺序规定的条目将被应用程序拒绝。然而，那些被规则或审计程序拒绝的条目仍可能被Factom记录在这条链上。这种链的用户将需要运行审计程序，来验证这种序列。Factom服务器将不会使用审计程序来验证此类规则。
上面所述的应用程序验证（与用户自定义链相结合）提供了许多优点：
1.应用程序可以在Factom上录入任何应用程序可以理解的条目。比如，验证帐户报表的哈希列表，可以像资产的交易一样简单方便的被记录下来。
2.规则的执行是非常高效的。分布式网络必须执行验证规则，然后要求所有节点做所有验证。客户端验证只需要对这些规则关心的系统来执行验证。 Factom允许链使用任何一种语言来设计定义规则，可以使用任何外部数据，并选择在任何平台上运行。一个应用程序所做的决定，对另外一个应用程序不会产生任何影响。
3. Factom服务器对记录下来的条目的内容没有多少认知。我们用一个承诺方案来限制对条目的了解：在服务器承诺记录条目之后再透露该条目的内容。这使得Factom的记录条目的角色很简单，也使得各个服务器的工作流程很公开。 Factom服务器接受来自节点网络的信息，它们的决定和行为总是一目了然的。如不履行规则，就会被Factom自己的审核和来自Factom网络外面的审核所发现。所以，一个Factom服务器是否履行记录条目的责任就可以很容易被第三方核实; Factom不可能掩盖潜在的错误行为。
4.写入记录的速度可以非常快，因为由Factom服务器把所需检查的次数降至最低。
5.针对Factom某个链的证明不需要管其它任何链的内容。用户只需拥有他们使用的Factom的部分数据，可以忽略其余部分。
Factom联合服务器如何管理链？
究其核心，Factom是用一种去中心化的方式来收集，打包，安全保护数据，并把数据锚定到比特币的区块链上。 Factom以联邦服务器的网络来实现这个目标。这些服务器不断变换在系统中所承担的责任，永远不会只有一个服务器在控制整个系统，每个服务器都只是系统中的一部分。Factom的服务器每一分钟变换一次角色，没有服务器会永久控制系统的任何一部分。
在开始创建一个目录区块的时候，每个联邦服务器需要对某一部分的用户链负责。过程是这样的：
1.所有服务器重设其进程列表（Process List）为空。
2.用户通与其条目信用的积分（Entry Credit）相关的公钥提交付款
3.根据用于支付的公钥，轮值服务器接受该付款。
4.该服务器向网络广播该支付被接受。
5.用户看到支付被接受， 然后提交条目。
6.根据条目的ChainID，其中一台服务器把条目加入其进程列表，并添加进入到相应链的区块中（如果这是该链的第一个条目, 那就创建这个新链）。
7.服务器对网络广播该条目的确认，内容含有条目在进程列表中的位置（Index)，条目的哈希值（链接到条目付款），以及最新进程列表的哈希值。
8.所有其他服务器更新该服务器的进程列表，验证该列表，并更新该链的区块。
9.只要用户可以验证到相关的进程列表中包含自己的提交的数据条目，那么他们就可以有相当的信心相信它会被成功地被录入到Factom上。
10.在一分钟结束时，所有服务器确认进程列表高度，揭示一个确定性的秘密数值（该值为一个反向哈希值，即一条较长的，连续的区块链哈希值的原像值），还有被处理区块的一系列哈希值（将与进程列表中的最后一项相匹配）。
11.那一分钟的目录区块（Directory Block）是由所有服务器中定义的所有条目区块（Entry Block）组合到一起建造而生成的。因此，每个服务器都拥有所有的条目区块（Entry Block），所有的目录区块（Directory Block），和所有条目（all Entries）。
12.使用反向哈希值的集合来创造一个种子，为下一轮的ChainIDs重新分配服务器。
13.在完成10个目录区块后，请执行以下操作：
a 对最后一分钟的条目块创建梅克尔根（Merkle Root），按ChainID排序。
b 创建最后一分钟的目录区块，并计算其梅克尔根（Merkle Root）。
c 用10个目录区块的梅克尔根（Merkle Root）创建一个锚定
d用服务器的反向哈希值集合来创建一个种子，再用其选择下一个服务器来把锚定写到比特币区块链上。
14.重复。 （又从第1部开始循环）
在一分钟里，联合服务器为其所负责的链建立进程列表，以及构建这些链的条目区块，这些将用于在一分钟结束时创建目录区块。进程列表很重要，是服务器用来向网络发布其对条目的处理的决定。
联合服务器每四个小时重新排名。排名由用户投票决定，用户必须在Factom链上登记。登记信息包含任意数量的签名公共地址条目。一个用户的投票权重是由他们的个人资料的公共地址确定。计算一个公共地址投票权重总和的函数是：
●在过去六个月中购买的积分加权（当月乘6，上月乘5，以此类推）
●在过去六个月中使用的条目数加权（当月乘6，上月乘5，以此类推）
当我们说有n个服务器运行，排名前n个服务器是联合服务器，而另有n个为审计服务器。所有服务器都基于票数排名。n值最初指定为16，但这个数目是供社区内讨论，可以基于交易量浮动。
所有服务器必须在每一个心跳周期播出心跳条目。 （一个条目确认时间可作为一次心跳）如果服务器在超时了还没有收到心跳或条目确认，服务器就会广播服务器故障消息（SFM）。如果关于某个联合服务器的SFM数目超过一半，该联合服务器就会被认为是“故障”，并降格为审计服务器，被最高排名的审核服务器接管。升级的服务器将做完当前4小时任期。之后服务器重新排序，但发生故障的服务器必须再等另一个4小时任期。
联合服务器的多数可以在设置链上修改心跳周期和超时规定。参照比特币的传播时间，心跳应该为4秒，超时时间为8秒。
更多Factom共识机制的细节，以及我们正在开发的算法，可在“Factom共识机制”的文档中找到。
四、Factom系统概述
Factom由一组分层数据结构所构成
Factom由分层结构的区块(Block)组成，根部是目录区块(Directory Block)。这些区块(Block)构成了一个微型链, 链上存储着压缩过的引用(reference). 为了避免数据规模过大，目录块(Directory Block)中的引用(refrence)只是Entry Block 和 ChainID 的哈希值。这些Entry Block包含了引用(refrence). 这些引用(reference)指向了特定时间段内所有Entry. Entry Block也是微链的一部分。在Factom系统里大部分的数据存储在叶子节点上，也就是那些Entry。这些分层数据结构由比特币的算力维护。它们可以被概念化为不同的层。
Factom系统里不同的层和概念：
1）目录层(Directory Layer) – 负责管理Entry Block的梅克尔根(Merkle root)
2）Entry Block Layer – 组织指向Entry的引用(Reference)
3）Entry – 包含应用程序的原始数据或私人数据的哈希值
4）链(Chain) – 属于应用程序的一组Entry
目录层(Directory Layer) ：如何管理Entry Block的梅克尔根(Merkle root)
1211
目录层(Directory Layer)是Factom分层结构中的的第一级。它定义了哪些 Entry ChainID被更新过, 更新发生在那个目录块(Directory Block)负责的时间段。 （ChainID用于识别用户的Entry属于那个Chain; ChainID的生成将在后面讨论）。目录层(Directory Layer)含有ChainID和对应链块里Entry Block的梅克尔根(Merkel root)。
在目录块(Directory Block)中说引用的每个Entry Block占用64个字节（分别是两个32字节的哈希值，ChainID和Entry Block的梅克尔根）。包含一百万个这样Entry Block的一个目录块(Directory Block)的大小约是64 MB。如果平均每个Entry Block有5个Entry，64 MB的目录块(Directory Block)将管理者500万不同的Entry。
应用程序通过目录块(Directory Block)可以定位到特定的Entry Block, 无需下载所有的Entry Block。一个单独的应用只会对一部分ChainID有兴趣。这极大地减小了使用Factom系统时的带宽需要。例如，一个监控房地产转让的应用程序可以放心地忽略摄像机安全日志。
Factom服务器收集Etnry Block的梅克尔根(Merkle Root), 然后把它们打包到一个目录块(Directory Block)。十个连续目录块(Directory Block)再算出一个梅克尔根(Merkle Root)，这个梅克尔根(Merkle Root)会被记录到比特币链块。这给比特币链块带来最小的负担, 确又足以报账Factom数据的安全. 把梅克尔根(Merkle Root)写入比特币链块的过程被称为Anchor(锚定)。详情参见“附录：Timestamping into Bitcoin (在比特币上加盖时间戳)”。
Factom系统里, 目录块(Directory Block)的数据读写需要最多的带宽和存储。用户在建立了自己的Chain以后, 需要保存这个时间点以后所有的目录块(Directory Block)。
创建一个链(Chain)和对链(Chain)的第一次更新会增加目录块(Directory Block)的大小。为了避免目录块(Directory Block)过度膨胀, 把数据写入目录块(Directory Block)所需付的Entry Credit会高于把数据写入 Entry Block.
记录区块层(Entry Block Layer)：记录区块层如何管理哈希值和数据？
记录区块(Entry Block)是这个系统的第二分层。个体应用将会关注各种各样的ChainID. 在寻找记录的应用会需要记录区块, 可以从一个ChainID搜索到所有可能相关的记录。
每一个记录区块(Directory Block)内都为每个有更新的ChainID记录下一个Entry Block. Entry Block包含着Entry的哈希值。记录的哈希值同时证明了数据的存在和在分布式散列表（DHT）网络中找到记录的钥匙。（详细信息请查看“Factom点对点网络”章节）。
131
记录区块(Entry Block)包含了和一个链ID有关的全部记录(Entry)。如果某个记录(Entry)不是关联到某个记录区块(Entry Block)的话，那么可以认为这个记录(Entry)并不存在。这样的设计能让应用程序很容易的证伪, 方便的识别哪些记录(Entry)是真实可靠的.
记录区块(Entry Block)并不包含记录(Entry)。比起所有数据都被集合起来放入区块中，这种方式会让记录区块(Entry Block)的体积更小。把记录从记录区块中分离出来，也会让数据更加容易审计. 审计员可以在一个单独的链中发布记录，用来批准或拒绝一个普通链中的记录。审计员可以添加拒绝的理由在Entry中。如果一个应用程序信任这个审计员，那么就可以直接采用这个审计员对记录的决定(批准或拒绝), 不用再去重新审核一次记录(Entry)。然后这个应用就可以只下载那些已经被审计通过的记录(Entry)。多个审计员可以引用相同的记录，单个记录只会存在于分布式散列表(Distributed Hash Table, DHT)中一次。这些记录的容量应该会比刚开始的32字节大很多。忽略列表不需要让应用知道已经被忽略的完整对象。
一个记录会详述一宗土地转让的细节，会根据此类交易的类型决定记录在链的什么位置。一个或多个审计员会在他们自己的链上引用这条土地转让的哈希值记录，并添加加密签ࡧ
公证通Factom白皮书 1.0版
在区块链上建立不可更改的审计公证业务流程
摘要：
Factom利用比特币的区块链技术来革新商业社会和政府部门的数据管理和数据记录方式。
利用区块链技术帮助各种各样应用程序的开发，包括审计系统，医疗信息记录，供应链管理，投票系统，财产契据，法律应用，金融系统等。开发者能够创造新的应用程序，并把数据保存在区块链上面，同时不用受到直接把数据写入比特币区块链的各种限制：例如写入的数据速度，成本，大小等限制。
Factom维护了一个永久不可更改的、基于时间戳记录的、区块链数据网络。大大减少了进行独立审计、管理真实记录、遵守政府监管条例的成本和难度。
商业社会和政府部门可以利用Factom简化数据记录的管理，记录商业活动，并解决数据记录安全性和符合监管的问题。
Factom正在革新整个世界对数据的记录方式，并利用比特币区块链技术来保护您的数据安全。
一、概要
“诚信是具备颠覆性的” – 保罗·斯诺
在当今的全球经济中，信任是稀有的。这种信任的缺乏，造成了大量资源的投入来进行审计和记录核查，从而降低了全球效率，投资回报率和经济繁荣。此外，如2010年美国的次贷危机等事件表明，目前的审计和核查流程是非常不准确和低效的，容易造成问题。 Factom提供了世界上首个准确的，可核查的和不可更改的审计公证流程和方法，从此我们不再需要盲目信任。
在过去，记录靠手工完成，数据的保护，同步更新和真实性的验证都非常困难。其中的一部分流程被计算机自动化以后，并没有使这些事情变得容易，反而是变得更加困难，因为电脑记录是如此容易被更改。权限和可靠性被四分五裂的分割到无数的独立系统中。
区块链提供了一个分布式的机制进行数据锁定，使数据可以被核查和独立审计。比特币区块链是现存最值得信赖的不可变的数据存储，但这往往只限于比特币交易上。 Factom能使企业获得最新的区块链技术，而又无需在采用虚拟货币的问题上陷入麻烦。
在本文中，我们将介绍Factom是如何创建一个分布式的，自治的协议，并把比特币区块链从Bitcoin网络中剥离。我们将讨论 客户端自定义的记录链（Chains of Entries），客户端如何验证记录条目，分布式共识算法， 基于区块链锚定的安全机制等。
111
二、Factom设计目标
用Factom创建更快，更便宜，无膨胀的方式来开发区块链应用
中本聪推出的比特币区块链彻底改变了交易记录的方式。在这以前从未存在过永久的，分散的，和无需信任的分类账。开发商纷纷开始开发建立在这个分类帐之上的应用程序。不幸的是，由于比特币一些初始的设计权衡， 他们已经碰到了几个核心的约束和问题：
1）速度 – 因为比特币的分布式设计和工作量证明的共识方法，工作量难度会被调整到以保持大致10分钟确认时间。对于希望更大的安全性的应用中，多个确认可能是必需的。一个常见的要求是要等待6确认，这可能会导致等待时间超过一个小时。
2）成本 – 默认的交易成本大约是0.01 mBTC（约0.003美元美元于2014年11月）。 BTC的交易价格一直不停的波动。如果BTC的价格上涨，则交易成本也上去了。这对需要管理非常大的数字交易数据的应用程序来讲， 是一个严重的成本障碍。此外，还有许多因素，如对区块大小的限制和奖励减半等，会导致交易费用增加。
3）区块链膨胀 – 比特币区块大小限制目前是1MB，交易流量的上限是每秒7交易。任何应用程序想要使用区块链写入和存储信息都将会增加流量。这个问题已致使各方寻求增加区块大小限制。
Factom是旨在解决这三大核心约束的协议。 Factom协议为应用程序提供的功能和特性超越了虚拟货币。 Factom构建了一个标准的，有效的，安全的基础，这将使应用程序的运行速度更快，更便宜，并且不会造成区块链膨胀。
三、Factom生态系统
Factom生态系统的几个主要部件，描述如下：
121
一旦系统建立后，Factoids（即Factom币）和用户帐户会被激活，用户将会交易Factom币。Factom和比特币具有以下主要的互动：
1.应用程序用户使用Factom币（Factoids）购买数据条目信用（Entry Credit）
2.应用程序记录数据条目
3. Factom服务器创建条目区块和目录区块
4. Factom将目录区块的哈希值锚定到比特币区块链
这些数据条目和区块链互动的部分请细看下面的几个章节。
安全性和证明
Factom如何保障条目的安全记录？
Factom把比特币的功能拓展到其货币属性之外的事件记录的功能。 Factom设有最小的规则集，用于永久记录数据条目。 Factom让客户的应用程序来执行大多数的数据验证任务。唯一Factom强制实施的验证是那些通过协议要求交易Factoids，购买条目信用，并确保条目正确付款和记录。
Factom具有关于激励运行网络和内部一致性的一些规则，但它不能检查用户记录的信息本身的真实性和有效性。
比特币交易限制被限制为从一组输入值集合映射到到一组输出值集合。只要满足输入值条件的输入值集合（通常需要一定的签名）就可以保证系统输入的有效性。这是可以实现自动化一个验证过程，所以可以使审计过程是容易的。例如，为了记录的房地产的产权转让，Factom可以只记录转让发生那一刻的过程。现实世界中，房地产产权的转让的规则是非常复杂的。 例如，一个地方管辖机构可能对房地产购买者有不同的和特殊的要求，如果买家是外国人，农民，或兼职居民，则购买限制条件是不一样的。房地产的地段位置，房屋价格，或建筑类别等不同属性，也可以使房地产被归到不同的类别中。每个类别都可以有自己的规则来反映智能合约的验证和执行过程。在这种情况下，单独一个加密签名不足以充分验证所有权转移的有效性。 此时Factom更多是用来记录房地产所有权转移和交易的发生，而不是验证房地产所有权转移是否有效。
比特币矿工主要执行两个任务。首先，他们解决双重花费的问题。看到两次花同样的一笔资金的相互冲突的交易发生时，他们选择哪一个是可以受理的和接受的。矿工（连同其他全结点）的第二个任务是进行交易验证和审核。由于比特币矿工只受理有效的交易，一个被包含在区块的交易是可以被假定为已经被审核。轻型客户端并不需要知道比特币的完整历史来看接受的资金是否已经被花掉了。 （见SPV客户端）。
Factom服务器和审核服务器如何验证数据条目？
Factom把比特币矿工做的事情分为两个任务：按照顺序记录条目和审计条目的有效性。
1 – Factom服务器接受数据条目，并将它们装入到不同的区块，并修复条目的顺序。 10分钟后，该条目的顺序通过插入到比特币区块链的一个锚定而变得不可逆转。 Factom通过对10分钟内收集的数据创建哈希值，然后把这个哈希值记录到比特币的区块链来实现这个功能。
2 – 条目的审计是一个独立的过程，可以依靠信任第三方或不依靠信任第三方来完成。审计是至关重要的，因为条目在被包括在Factom数据集之前， Factom是无法验证它们的真伪的。
以信任为基础的审计，轻型客户端可以信任他们选择一个称职的审计师。一个项目被输入到系统中以后，审计人员将可以验证输入是否有效。审计师将提交自己的加密签名条目。签名会显示该条目通过了所有审计师认为需要做的的检查。审计要求的条件实际上可能是一个Factom链的一部分。以之前的房地产为例，审计师会仔细检查财产转移是否符合当地标准。审核员将公开证明，财产转移是有效的。
不依靠信任的审计系统将类似于比特币网络。如果一个系统的有效性像比特币网络的数学定义一样完美，那么它可以实现程序化的审计过程。如果用于转移的规则能够由计算机进行审核，则应用程序可以下载有关的数据，并进行自我审计和审核过程。该应用程序可以通过下载数据条目，验证数据条目，并决定条目是否有效，从而使该应用程序建立起对系统的感知。
Mastercoin, Counterparty, 和Colored Coin也有类似的信任模型。这些都是基于客户端的验证协议，这意味着交易被嵌入到比特币的区块链上。比特币矿工不审核其有效性；因此，基于这些协议的无效的交易如果被故意设计伪装成有效的交易也可以嵌入到比特币的区块链上。支持这些协议之一的客户端通过对区块链扫描并寻找潜在的交易，检查它们的有效性，并对控制这些数字资产的地方建立说明和解释（通常是一个比特币地址）。在这些协议中，都是由客户端来执行自我审计。
要把这些由客户端验证的协议搬到Factom上，将会只是一个如何定义协议中的交易并建立一个链来保存交易的问题。和比特币相比，交易协议在Factom下不会有太大的不同。不同之处在于信息在Factom上很容易表达，而不必以某种特殊方式对其进行编码并嵌入比特币的交易信息中。
证明否定
比特币，土地登记，以及许多其他系统需要解决的一个根本性的问题：证明否定。他们证明了某个“东西”已经被转移到某个人，并证明这个“东西”还没有被转移给其他人。在无界系统里，否定的证明是不可能的，而在一个有界系统里它是很有可能的。 加密货币通过限制交易数据可以存在的地方来解决这个问题。比特币交易只能在比特币区块链里找到。如果某个交易没在比特币区块链里被找到，那它在比特币协议下就不存在，因此，该比特币就尚未被发送两次（双花）。
某些土地所有权记录系统是相似的。假设在一个系统里，土地转让要在政府登记，而且法律制度规定，未记录的转让是无效的（sans litigation）。如果一个人要检查某个产权是否明确（即，没有其他人声称这片土地所有权），答案就在政府登记处。利用政府记录可以证明为否定，土地不被第三方拥有。如果产权登记不是必须的，政府的注册表只能证明什么已被登记。私人转让很可能存在，注册表也就不能代表全部的转让情况。
在上述两种情况下，否定可以在某个环境中得到证明。以万事达币（Mastercoin）为例，这个证明是强而有力的。而土地登记，则仅限于被注册的环境下，可能遭到一定的质疑和挑战。现实世界是复杂的。Factom的设计，针对的不只是精确的数字资产，而且是物质的世界中复杂的现实情况。
在Factom中，数据分类有层次结构。 Factom只在链中记录数据条目；诸多用户定义的链在Factom执行的协议中没有互相依赖关系。这不同于比特币，每一笔比特币交易是都存在潜在的双重支付，因此它必须被验证。和把所有数据合并在一起成一个总账相比，Factom通过把条目放到多个链当中，可以让应用程序在较小的空间内搜索数据。
如果Factom要用来管理土地转让，使用某个链来记录的应用程序可以安全地忽略在其他链上的条目，比如那些本来用于保安摄像机的记录的链就不与需要更新。如果政府法庭判决需要变更土地转让记录，那么和其相关的链将被更新，以反映上述判决的结果。但更改的历史不会丢失，并且如果这样的土地产权变更的更改从法律或其他角度来讲无效的话，它的记录的内容和顺序在Factom上都不能被更改或隐藏。
尼克·萨博（Nick Szabo）在关于“房产俱乐部”的论述中，与本系统有许多重叠。以下是他在论文“安全产权与所有者权限”中的一个要点：
虽然暴徒还可以通过暴力攫取物质资产，但延续存在的正确的所有权记录将是留在盗用者眼中的眼中钉。
应用程序如何验证Factom链？
Factom不验证条目；条目是由用户客户端和应用程序来验证的。只要应用程序了解并熟知该条链应遵循的规则，那么无效条目的存在也不会引起不合理的干扰。在链里的不遵守规则的条目可以被应用程序忽略。
用户可以给他们的链设置任意规则，并且可以使用任意方法给这条链的用户传达这条链的规则。在这条链中的第一个数据条目可以被设计成这条链的一组规则，或某个审计程序的哈希值，等等。这些规则可以被应用程序理解，并通过运行Factom，在网络中忽略掉不符合这些规则的客户端应用程序。
强制执行的序列可以在每条链的规则中指定。不符合这种顺序规定的条目将被应用程序拒绝。然而，那些被规则或审计程序拒绝的条目仍可能被Factom记录在这条链上。这种链的用户将需要运行审计程序，来验证这种序列。Factom服务器将不会使用审计程序来验证此类规则。
上面所述的应用程序验证（与用户自定义链相结合）提供了许多优点：
1.应用程序可以在Factom上录入任何应用程序可以理解的条目。比如，验证帐户报表的哈希列表，可以像资产的交易一样简单方便的被记录下来。
2.规则的执行是非常高效的。分布式网络必须执行验证规则，然后要求所有节点做所有验证。客户端验证只需要对这些规则关心的系统来执行验证。 Factom允许链使用任何一种语言来设计定义规则，可以使用任何外部数据，并选择在任何平台上运行。一个应用程序所做的决定，对另外一个应用程序不会产生任何影响。
3. Factom服务器对记录下来的条目的内容没有多少认知。我们用一个承诺方案来限制对条目的了解：在服务器承诺记录条目之后再透露该条目的内容。这使得Factom的记录条目的角色很简单，也使得各个服务器的工作流程很公开。 Factom服务器接受来自节点网络的信息，它们的决定和行为总是一目了然的。如不履行规则，就会被Factom自己的审核和来自Factom网络外面的审核所发现。所以，一个Factom服务器是否履行记录条目的责任就可以很容易被第三方核实; Factom不可能掩盖潜在的错误行为。
4.写入记录的速度可以非常快，因为由Factom服务器把所需检查的次数降至最低。
5.针对Factom某个链的证明不需要管其它任何链的内容。用户只需拥有他们使用的Factom的部分数据，可以忽略其余部分。
Factom联合服务器如何管理链？
究其核心，Factom是用一种去中心化的方式来收集，打包，安全保护数据，并把数据锚定到比特币的区块链上。 Factom以联邦服务器的网络来实现这个目标。这些服务器不断变换在系统中所承担的责任，永远不会只有一个服务器在控制整个系统，每个服务器都只是系统中的一部分。Factom的服务器每一分钟变换一次角色，没有服务器会永久控制系统的任何一部分。
在开始创建一个目录区块的时候，每个联邦服务器需要对某一部分的用户链负责。过程是这样的：
1.所有服务器重设其进程列表（Process List）为空。
2.用户通与其条目信用的积分（Entry Credit）相关的公钥提交付款
3.根据用于支付的公钥，轮值服务器接受该付款。
4.该服务器向网络广播该支付被接受。
5.用户看到支付被接受， 然后提交条目。
6.根据条目的ChainID，其中一台服务器把条目加入其进程列表，并添加进入到相应链的区块中（如果这是该链的第一个条目, 那就创建这个新链）。
7.服务器对网络广播该条目的确认，内容含有条目在进程列表中的位置（Index)，条目的哈希值（链接到条目付款），以及最新进程列表的哈希值。
8.所有其他服务器更新该服务器的进程列表，验证该列表，并更新该链的区块。
9.只要用户可以验证到相关的进程列表中包含自己的提交的数据条目，那么他们就可以有相当的信心相信它会被成功地被录入到Factom上。
10.在一分钟结束时，所有服务器确认进程列表高度，揭示一个确定性的秘密数值（该值为一个反向哈希值，即一条较长的，连续的区块链哈希值的原像值），还有被处理区块的一系列哈希值（将与进程列表中的最后一项相匹配）。
11.那一分钟的目录区块（Directory Block）是由所有服务器中定义的所有条目区块（Entry Block）组合到一起建造而生成的。因此，每个服务器都拥有所有的条目区块（Entry Block），所有的目录区块（Directory Block），和所有条目（all Entries）。
12.使用反向哈希值的集合来创造一个种子，为下一轮的ChainIDs重新分配服务器。
13.在完成10个目录区块后，请执行以下操作：
a 对最后一分钟的条目块创建梅克尔根（Merkle Root），按ChainID排序。
b 创建最后一分钟的目录区块，并计算其梅克尔根（Merkle Root）。
c 用10个目录区块的梅克尔根（Merkle Root）创建一个锚定
d用服务器的反向哈希值集合来创建一个种子，再用其选择下一个服务器来把锚定写到比特币区块链上。
14.重复。 （又从第1部开始循环）
在一分钟里，联合服务器为其所负责的链建立进程列表，以及构建这些链的条目区块，这些将用于在一分钟结束时创建目录区块。进程列表很重要，是服务器用来向网络发布其对条目的处理的决定。
联合服务器每四个小时重新排名。排名由用户投票决定，用户必须在Factom链上登记。登记信息包含任意数量的签名公共地址条目。一个用户的投票权重是由他们的个人资料的公共地址确定。计算一个公共地址投票权重总和的函数是：
●在过去六个月中购买的积分加权（当月乘6，上月乘5，以此类推）
●在过去六个月中使用的条目数加权（当月乘6，上月乘5，以此类推）
当我们说有n个服务器运行，排名前n个服务器是联合服务器，而另有n个为审计服务器。所有服务器都基于票数排名。n值最初指定为16，但这个数目是供社区内讨论，可以基于交易量浮动。
所有服务器必须在每一个心跳周期播出心跳条目。 （一个条目确认时间可作为一次心跳）如果服务器在超时了还没有收到心跳或条目确认，服务器就会广播服务器故障消息（SFM）。如果关于某个联合服务器的SFM数目超过一半，该联合服务器就会被认为是“故障”，并降格为审计服务器，被最高排名的审核服务器接管。升级的服务器将做完当前4小时任期。之后服务器重新排序，但发生故障的服务器必须再等另一个4小时任期。
联合服务器的多数可以在设置链上修改心跳周期和超时规定。参照比特币的传播时间，心跳应该为4秒，超时时间为8秒。
更多Factom共识机制的细节，以及我们正在开发的算法，可在“Factom共识机制”的文档中找到。
四、Factom系统概述
Factom由一组分层数据结构所构成
Factom由分层结构的区块(Block)组成，根部是目录区块(Directory Block)。这些区块(Block)构成了一个微型链, 链上存储着压缩过的引用(reference). 为了避免数据规模过大，目录块(Directory Block)中的引用(refrence)只是Entry Block 和 ChainID 的哈希值。这些Entry Block包含了引用(refrence). 这些引用(reference)指向了特定时间段内所有Entry. Entry Block也是微链的一部分。在Factom系统里大部分的数据存储在叶子节点上，也就是那些Entry。这些分层数据结构由比特币的算力维护。它们可以被概念化为不同的层。
Factom系统里不同的层和概念：
1）目录层(Directory Layer) – 负责管理Entry Block的梅克尔根(Merkle root)
2）Entry Block Layer – 组织指向Entry的引用(Reference)
3）Entry – 包含应用程序的原始数据或私人数据的哈希值
4）链(Chain) – 属于应用程序的一组Entry
目录层(Directory Layer) ：如何管理Entry Block的梅克尔根(Merkle root)
1211
目录层(Directory Layer)是Factom分层结构中的的第一级。它定义了哪些 Entry ChainID被更新过, 更新发生在那个目录块(Directory Block)负责的时间段。 （ChainID用于识别用户的Entry属于那个Chain; ChainID的生成将在后面讨论）。目录层(Directory Layer)含有ChainID和对应链块里Entry Block的梅克尔根(Merkel root)。
在目录块(Directory Block)中说引用的每个Entry Block占用64个字节（分别是两个32字节的哈希值，ChainID和Entry Block的梅克尔根）。包含一百万个这样Entry Block的一个目录块(Directory Block)的大小约是64 MB。如果平均每个Entry Block有5个Entry，64 MB的目录块(Directory Block)将管理者500万不同的Entry。
应用程序通过目录块(Directory Block)可以定位到特定的Entry Block, 无需下载所有的Entry Block。一个单独的应用只会对一部分ChainID有兴趣。这极大地减小了使用Factom系统时的带宽需要。例如，一个监控房地产转让的应用程序可以放心地忽略摄像机安全日志。
Factom服务器收集Etnry Block的梅克尔根(Merkle Root), 然后把它们打包到一个目录块(Directory Block)。十个连续目录块(Directory Block)再算出一个梅克尔根(Merkle Root)，这个梅克尔根(Merkle Root)会被记录到比特币链块。这给比特币链块带来最小的负担, 确又足以报账Factom数据的安全. 把梅克尔根(Merkle Root)写入比特币链块的过程被称为Anchor(锚定)。详情参见“附录：Timestamping into Bitcoin (在比特币上加盖时间戳)”。
Factom系统里, 目录块(Directory Block)的数据读写需要最多的带宽和存储。用户在建立了自己的Chain以后, 需要保存这个时间点以后所有的目录块(Directory Block)。
创建一个链(Chain)和对链(Chain)的第一次更新会增加目录块(Directory Block)的大小。为了避免目录块(Directory Block)过度膨胀, 把数据写入目录块(Directory Block)所需付的Entry Credit会高于把数据写入 Entry Block.
记录区块层(Entry Block Layer)：记录区块层如何管理哈希值和数据？
记录区块(Entry Block)是这个系统的第二分层。个体应用将会关注各种各样的ChainID. 在寻找记录的应用会需要记录区块, 可以从一个ChainID搜索到所有可能相关的记录。
每一个记录区块(Directory Block)内都为每个有更新的ChainID记录下一个Entry Block. Entry Block包含着Entry的哈希值。记录的哈希值同时证明了数据的存在和在分布式散列表（DHT）网络中找到记录的钥匙。（详细信息请查看“Factom点对点网络”章节）。
131
记录区块(Entry Block)包含了和一个链ID有关的全部记录(Entry)。如果某个记录(Entry)不是关联到某个记录区块(Entry Block)的话，那么可以认为这个记录(Entry)并不存在。这样的设计能让应用程序很容易的证伪, 方便的识别哪些记录(Entry)是真实可靠的.
记录区块(Entry Block)并不包含记录(Entry)。比起所有数据都被集合起来放入区块中，这种方式会让记录区块(Entry Block)的体积更小。把记录从记录区块中分离出来，也会让数据更加容易审计. 审计员可以在一个单独的链中发布记录，用来批准或拒绝一个普通链中的记录。审计员可以添加拒绝的理由在Entry中。如果一个应用程序信任这个审计员，那么就可以直接采用这个审计员对记录的决定(批准或拒绝), 不用再去重新审核一次记录(Entry)。然后这个应用就可以只下载那些已经被审计通过的记录(Entry)。多个审计员可以引用相同的记录，单个记录只会存在于分布式散列表(Distributed Hash Table, DHT)中一次。这些记录的容量应该会比刚开始的32字节大很多。忽略列表不需要让应用知道已经被忽略的完整对象。
一个记录会详述一宗土地转让的细节，会根据此类交易的类型决定记录在链的什么位置。一个或多个审计员会在他们自己的链上引用这条土地转让的哈希值记录，并添加加密签ࡧ
Jump to: