Verifier 允许您准确地报告或了解发生/未发生某些事件或执行/未执行任何操作的事件。交付一个合适质量的包裹，要求在真实客户的银行开立账户，实地查看 - 这要归功于验证人，您可以在分散的可靠的人员的帮助下检查任何事实。

代理收集的材料将被加密并通过电子邮件发送正式要求出示的证据。有防护密钥的数据以散列形式通过一系列的模块链被发送。这保证了数据内容在传输到有关部门或个人的过程中不被损坏或拦截。代理商将从相关方获得报酬，并且可以在世界任何地方。 代理的主要工具是互联网。 有规避风险的愿望吗？ 可以一次将任务交给几个独立的代理。

Verifier不仅是一个应用程序。 其作为开放式代码解决方案的潜力同样令人感兴趣。 通过嵌入和修改Verifier代码，您可以将系统的功能扩展并更改为特定的任务和要求。

受众群体

Verifier服务旨在满足两个主要市场— 公司对公司(B2B)和个人对个人(P2P)验证服务的需求。

B2B – 利基，企业市场。主要客户是需要遵守KYC程序的公司金融部门。 这些银行、交易所、保险公司和其他企业以及其他要求提供资产及抵押和其他企业服务的金融和法律服务的客户。

P2P – 大众市场。任何人都可以使用 。Verifier要做到这一点，只需下载应用程序或访问网站wed.Verifier. org 。 世界上的每一个互联网用户都将拥有无限的远程体验和服务的机会，这在以前只有大中型企业和收入水平很高的个人才能使用。

经济数据

1.代币描述

Verifier 模块服务基于通过使用模块链技术在系统内安全传输数据。 代币的发行旨在为验证服务的启动和进一步扩展提供资金。 筹集的资金将用于开发Verifier系统，以及用于增加项目受众的营销。 Verifier公司为了筹措资金发行代币Verifier Tokens，称为VRF，是基于以太坊平台的智能合约。

2.

代币模式

120 000 000 VRF 代币。代币定价：1 代币等于 验证申请的最低费用。 1 VRF = 0,1 美元。代币分度和额外发行：从技术上讲，使用现有的数据结构，VRF可以划分为小数点后第八位，所以0.0001 VRF是目前最小的数字。 如果有需要的话,保证代币的更小部分的想法在未来可能是具有现实意义的。 目前还没有预计执行额外的发行。

3.代币持有者收益

VRF 代币旨在用作支付媒介在Verifier平台上的加密系统中。 所有者可以支付系统内的服务费用，向系统中的其他参与者出售代币，并将其换成其他加密货币。 所有通过网站上的代币执行的操作都通过智能合约记录在区块链。代币的基础价格等于呈现服务的最低成本,为0,1美元或 1VRF。

VRF 代币需求的增长是由于在系统中购买代币的交易数量的增加而产生的，并且随着系统中用户数量的增加而不断增加。 服务的最低成本（静态部分）将保持在同一水平。

技术说明

Verifier 是一个软件包，旨在确认真实世界中的数据，事件，文档和对象的真实性，使用区块链技术验证后传输的数据的可靠性。

在结构上，Verifier由以下组件（子系统）组成：

• 移动应用客户;• 管理和审阅系统;• 数据库;• 应用程序与服务器交互的API;• 基于以太坊（Ethereum）的本地部署模块，其中包含一系列可能发生外部呼叫的功能

Verifier的开发人员使用以下工具集：

• Java — 用于开发项目的服务器部分。基于 Java 的解决方案构成了大量银行解决方案的基础。使用这种编程语言进行开发将使我们能够针对大量交易项目的优化，并且能够以最小的劳动力消耗进一步与银行系统进行整合。• Objective C 和 Xcode — 适用于iOS的本机开发环境。• Java 和 Android SDK — 适用于Android的本机开发环境。• Angular 和 ReactJS — 这些框架将用于创建Web应用程序。

Verifier 区块链将通过以太坊（Ethereum）的分支创建，并进一步创建自己的智能合约。

VRF 代币的技术实现

VRF代币与ERC20标准兼容，并基于以太坊（Ethereum ）区块链系统。以太坊（Ethereum）最适合Verifier系统，因为它已成为加密货币行业通过区块系统确保交易操作的首选。 ERC20是以太坊（Ethereum）代币的标准，以及ERC20和以太坊（Ethereum ）系统之间的兼容性让你能编写提供对应于具体要求的Verifier系统的安全和可定制加密操作的智能合同，并可以很容易地在一个真正的分散式系统分配社会成员之间的代币。

由于 VRF 代币在以太坊模块平台重磅发布，并且需要在私人模块中进行 VRF 代币项目计算：

• 公共和私人社区不会相互影响。• 以太坊公共网仅用于发送代币。• 将VRF代币发送到钱包时，它收集有关服务器上部署的以太坊节点的信息并将其传输到本地模块。 该操作通过在钱包上收取代币的功能来执行。 因此，用户具有用于发送代币和内部余额，反映在私人Verifier区块链中信息的地址。

当需要为完成的工作发送代币时，系统将指示以太坊的智能合约，并将所需数量的代币发送到外部地址。

1.智能合约

该项目实施了一套智能合同。 这些智能合约通过以下方法实施：

使用SHA -256和Stribog算法计算给定字符串的散列值

• 将Summary计算字符串保存到单元格• 查询（并返回）Summary计算字符串单元格

在第一个函数中，智能合约通过SHA-256和Stribog（全苏国家标准P 34.11-2012）算法对数据进行散列。这些算法被选择为散列中的加密标准。加密功能是单向的，不提供反向加密。此实施仅用于创建散列，稍后将作为检验基于验证结果传输的数据的准确性的证据，以及证据表明当事方在争议问题中提供的数据与Verifier系统传输的数据相符。

在第二个函数中，智能合约在第一个智能合约散列之后将散列保留在模块中。 后面的散列想要确认数据的有效性必须要通过这个函数来实现。

第三个智能合约具有双重功能：

1.接收来自模块的散列，以便将该散列的主要传输发送给客户端，然后可以用它来确认数据的真实性。2.在需要的情况下向区块请求数据以提供给客户端。

2.智能托管

在首发期间募集的所有资金都通过位于已安装在以太坊区块链的智能合约的智能托管服务获得。

智能托管是一种工具，允许购买代币的买家通过投票控制在基础销售期间募集的资金分期分配。

只有在 Verifier 项目团队通过文档和路线图的帮助确认了以前的步骤之后，每一个下一阶段的支出才有可能。

投票是在 VRF 代币持有人的个人账户中实现的，从融资阶段开始的24 小时内持续投票，并将结果存储在智能合约中。 VRF 代币的所有账户中拥有超过 30,000个 VRF 代币的持有者都有投票权。

在超过51％的参与者投赞成票的情况下投票被认为是成功的，并且该投票会传递给 Verifier 团队的钱包。 如果超过 49％投否定票，智能合约上的所有资金将按照代币数量的比例分配给代币持有者。

3.代理验证人的注册

私人验证器

在确认用户的身份后，创建具有此角色的新用户。 用户完成问卷后，将创建该帐户的应用程序。 每个应用程序按现有代理程序的顺序组成。通过验证后，用户被激活并可以接收系统中的任务。 此外，在通过用户验证之后，将可以借助于Parity API调用为其创建的单独的秘密钱包。

验证者通过联合公司注册

当用户注册了此类用户的业务合作伙伴角色时，会创建一个单独的Web界面。 在界面中，显示通过此合作伙伴注册的所有用户，他们执行的任务统计以及薪酬统计。担任合伙人角色的用户可以独立更改每个以公司为受益人的工作的费用百分比。 通过合伙公司的个人账户注册的用户将获得最终报酬或有关该任务获得扣除利息的资金的信息。在通过合作公司的个人主页注册用户时，用户不需要额外的验证。 合作伙伴公司独立承担所提供数据的可靠性责任。与代理验证人进行的所有相互结算都是以法定货币进行，并通过合作伙伴公司的帐户进行。 在这种情况下，汇总报告期间的所有报酬，并将总额发送给交易对方的账户。具有合作伙伴公司角色的用户可以自行决定连接用户或删除以前连接的任何用户。

4.数据验证算法

在确认应用程序进行验证之后，服务器会向移动客户端发送一个JSON文件，其中包含有关应用程序和要进行验证的表单的信息。

移动客户端创建两个屏幕：第一个显示应用程序的信息，第二个显示数据验证的形式。

当验证站点到达验证者时，验证者按下按钮开始验证，如果验证者的地理位置与应用程序中指定的地理位置一致（假定为 200 米），则应用程序移动到第二个画面。 第二个屏幕上的验证表单对于每个应用程序都是唯一的。 表单可以包含指令和输入验证字段列表。

填写完表格后，数据将被发送到应用程序服务器。 在服务器上，数据散列被发送到主机，并且数据被重新打包成应用程序作者创建时所选择的格式。

验证者之间分配任务的算法

当新任务进入系统时，算法必须选择位于验证对象紧邻的代理。 如果任务需要特殊能力，那么即使在设施附近还有其他代理人，也要优先考虑具有此能力的代理人。在确定来自10个职位的潜在代理人名单之后，他们中的每一个都会发送包含任务数据的推送通知。

代理人在不超过两分钟时间内作出决定。 如果没有用户响应该请求，则该消息再次被发送给更广泛的用户。 在没有所需能力的代理人的情况下，系统必须通知客户此操作无法执行，并提供重新设定应用程序而无需指定权限。在确认应用程序之后，验证者以JSON文件的形式接收订单数据，其中包含字段和数据类型列表以及有关验证对象的信息。

与外部当事人的配合与外部交易当事人的交流有两种形式。

使用SFTP协议

使用SFTP协议以JSON格式交换文件。 对于需要处理的数据访问 FTP 服务器是从银行侧和Verifier侧以指定的频率完成的。 银行从FTP服务器上的指定目录接收JSON格式的文件数据。 响应文件名称对应于请求文件中指定的应用程序编号。

使用API来请求获取信息

在这个版本中，在服务验证器端，实现了RESTful API，通过HTTP协议（GET / POST-查询）直接访问银行。 请求/回复的数据 - JSON目标，编码 - UTF-8。 请求/回复假设为一组灵活的字段并依赖于特定的查询。使用的区块链类型

1. 技术 — 以太坊 (比特币 2.0)2. 区块链客户 — 奇偶校验位3. 组织单元 — 私人（本地（内联网）单元，没有连接全球单元）4. 与单元通信的模式 — RPC，POST请求5. 在单元终端执行逻辑的方式 —智能合约6. 智能合约的书写语言 — Solidity7. 用户帐户数量为— 1，所有请求实际上都是为了单个用户而执行的8. （用于智能合同工作）账户系统的数量是 — 1，所有的逻辑被同一个智能合同运用各种方法执行

服务器部分与以太坊区块链的交互

为了与模块进行通信，建议使用运行在 HTTP 协议上的 JSON-RPC 客户端，例如 web3j。 此API实施允许您使用来自本地 Java 代码的智能合约，钱包，交易等 。

1. 查询和结果表单 — application/json2. 代码交换 — utf-83. 在单元终端逻辑的执行方式 — 智能合约4. 智能合约的书写语言 — Solidity5. 用户帐户数量为 — 1，所有请求实际上都是为了单个用户而执行的6. （用于智能合同工作）账户系统的数量是 一1，所有的逻辑被同一个智能合同运用各种方法执行

7. 模块端使用的基本方法：

a. eth_accounts — 返回主机当前节点的活动帐户列表b. eth_getBalance — 返回所选帐户的余额（在以太坊中）c. eth_call — 调用智能合约方法d. eth_sendTransaction — 调用单元中要执行的请求e. eth_getTransactionReceipt — 调用关于事务信息的请求

8. 在智能合约框架内执行的方法:

a. getHash — 对发送的UTF-8字符串进行HASH计算的SHA-256方法b. getHashGOST — 通过Stribog方法对传输的UTF-8字符串进行HASH计算（全苏国家标准 P 34.11-2012）c. getSummaryRules —根据源文档返回生成摘要的规则

关于更多

Verifier

信息：https://www.verifier.org/

风险提示

：区块链投资具有极大的风险，项目披露可能不完整或有欺骗。请在尝试投资前确定自己承受以上风险的能力。区块网只做项目介绍，项目真假和价值并未做任何审核。