如何基于Factom协议创建有用的应用程序？

factom能够创造新的应用程序，并把数据保存在区块链上面，同时不用受到直接把数据写入比特币区块链的各种限制：例如写入的数据速度，成本，大小等限制。我们致力于让每一位开发者都有使用区块链技术的能力，并借此开发出下一代的应用程序。

应用程序’是用户端软件读取/写入Factom系统的通用术语，可作为人机界面的软件或者实现完全自动化，旨在收集链的组织数据。

应用程序作为分布式应用程序（DApps），同Factom进行沟通，以提供额外服务。例如，一台能够快速处理交易且带有极其精确时间戳的交易工具。由此，交易转为Factom链，可记录和确保分类账的安全性，其作用机制可为记账过程、提供准备金和提供通讯功能。

下面让我们共同探索当前比特币生态系统需要的两个应用程序。

我们来看看如何设计和完成一个安全的、分布式日志平台。日志分析是一项复杂的任务。此外，日志往往易伪造且多样化，因为日志由每个系统单独生成并存储到各种媒体平台（文件、数据库、云服务等）。随着Factom和一些单独设计的加密审计的出现，日志分析变得更安全、更简单且功能更强大。下面我们就举个例子。假设银行（B）、付款提供商（PP）和比特币公司（BC）之间互相展开交易：

1 - 用户访问BC网站并想买一些比特币

2 – 用户询价（5分钟内有效）

3 – 用户跳转到PP网站

4 - 然后PP连接B平台，用户帐户资金被扣除

5 – B告之PP用户帐户资金已被扣除

6 – PP告之 BC

7 - BC发送比特币给用户

以上步骤是全球多数固定利率比特币交易所的正常流程。出于某种原因，现在假设用户通过PP转移资金，BC在4小时后才接受到付款通知。那现在问题归咎于谁？用户？银行？付款提供商？如果类似问题持续几天或几周时间，数百上千项付款交易出现类似问题的话将会出现什么情况？谁该“认定”对这些损失进行负责？

基于当前技术，日志需要进行手动审计以及合法授权。随着Factom和相应审计程序的开发，我们便很容易检测出问题所在，使得记录变更等后期问题得到解决。基本上，每个系统（BB、PP、BC）都会在安全通讯渠道（Factom）实时公布相关操作记录。

下面我们将举例说明Factom如何应用于比特币交易审计流程。 所谓“偿付能力证明”逐渐成为了比特币交易审计流程的一项重要步骤。但是该方法显著劣势在于只能通过Factom安全通讯渠道进行解决。

Maxwell-Todd提案中建议采用Merkle tree对偿付能力进行证明，用户必须手动将账户余额申报到金融机构（FI），从而承担债务责任（用户账户余额FI数据库Merkle哈希值）。该提议方案针对足够多的用户能够验证账户写入树中。如果用户账户没有被记录的话，其存在的潜在威胁就是交易所数据库所有者可以生成虚假数据库的哈希值；不完整交易数据库将明显降低对客户的义务程度责任，只能作为验证方的验证方式。下面我们就列举几个欺诈性交易的场景：

●“少数大客户串通”攻击：证据表明大的比特币庄家在不同的交易所上面交易，并影响比特币的价格趋势。此类庄家需储备大量资金，便于快速执行订单。通常情况下，交易者可选择他们“信赖”的交易所，这样黑客或资金流动性出现问题时，他们可优先撤回资金。在这种情况下，在数据库进行哈希运算之前，交易所和交易员可能串通将数据库中少数大客户账户余额扣除。通常一个交易所中排名前10位的大客户中占有交易所5〜20％的资金，因此只需要串通其中几个大客户便会产生重大影响。

●“网站操纵”攻击：迄今为止，偿付能力证明审计将需要向（哈希树）机构网站进行汇报。但是这样完全不能担保用户账户的安全性，恶意交易所可能会对不同用户组公布不同用户账户状态/余额或者追溯更改账户状态。因此，我们有必要通过Factom的安全通讯渠道进行数据公布和发布。

第二类攻击可通过启用Factom进行解决，但第一类攻击未必能够通过Factom进行彻底解决。由于本文讨论焦点并非交易所审计机制，因此不会深入探究其技术细节。但是基本解决概念是交易数据库Merkle哈希频繁时间戳拷贝有助于用户在审计前后检测出投入或撤出的大量账户余额。这样一来，审计人员只需要查看大型投入或撤出账户余额。谨记：交易者最终会在某个时候投入或撤出资金，这些操作将显示在银行交易史或比特币转移史中。

传统意义上，检测此类欺诈交易都有固定流程，但是有关资料的准确性、可验证性、时间序列的不可更改问题仍然未得到解决。