什么是Verifier，在区块链中有什么用

很多朋友对什么是Verifier，在区块链中有什么用不是很了解，每日小编刚好整理了这方面的知识，今天就来带大家一探究竟。

验证器-是一种创新的验证技术，适用于任何类型的交易、数据传输和活动。验证器的速度、准确性和安全性由区块链技术提供。

Verifier是智能手机和平板电脑的应用程序，也是基于优步模式的网页版，即通过客户和服务提供商之间的直接交易提供服务。当需要确认身份或任何事实时，系统会随机选择前往现场的负责代理人(验证人)，并以照片、视频等材料的形式提交验证。

Verifier允许您准确地报告或了解某些事件的发生/不发生或任何操作的发生/不执行。交付合适质量的包裹需要在真实客户的银行开户，并进行实地检查——多亏了验证者，你可以在分散可靠的人员的帮助下检查任何事实。

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

验证器不仅仅是一个应用程序。它作为开放代码解决方案的潜力同样令人感兴趣。通过嵌入和修改验证器代码，您可以根据特定的任务和要求扩展和更改系统的功能。受众验证服务旨在满足两个主要市场的需求——企业对企业(B2B)和个人对个人(P2P)认证服务。B2B利基，企业市场。

主要客户是需要遵守KYC程序的公司财务部门。这些银行、交易所、保险公司和其他企业，以及为提供资产、抵押贷款和其他企业服务而需要金融和法律服务的其他客户。

P2P——大众市场。任何人都可以使用它。验证者可以通过下载应用程序或访问wed.verifier.org网站来完成。全球每一个互联网用户都将拥有无限的远程体验和服务的机会，而这在以前只有大中型企业和高收入水平的个人才能享受到。经济数据1。令牌描述

验证者模块服务基于使用模块链技术在系统中安全传输数据。发行代币的目的是为认证服务的启动和进一步扩展提供资金。筹集的资金将用于开发验证系统和增加项目受众的营销。为了筹集资金，Verifier Company发行了一种令牌，Verifier Tokens，名为VRF，是一种基于以太坊平台的智能合约。2.令牌模式120 000 000 VRF令牌。代币定价：1个代币等于验证申请的最低费用。1 vrf=0，1美元。

代币索引和额外发行：从技术上讲，利用现有的数据结构，VRF可以分到小数点后第八位，所以0.0001 VRF是目前最小的数。如果有必要的话，担保一小部分代币的想法在未来可能会有实际意义。目前预计不会增发新股。3.代币持有者的收入

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

对VRF代币的需求增加是由于在系统中购买代币的交易数量增加，并且随着系统中用户数量的增加而增加。服务的最低成本(静态部分)将保持在同一水平。技术描述验证器(Technical Description Verifier)是一个软件包，旨在确认现实世界中数据、事件、文档和对象的真实性，并使用区块链技术验证传输数据的可靠性。在结构上，验证器由以下组件(子系统)组成：移动应用客户端；

管理和审查制度；数据库；应用程序和服务器之间交互的API基于以太坊的本地部署模块，包含一系列可能引起外部调用的函数，使用以下由Verifier的开发者设置的工具：

Java——用于开发项目的服务器部分。基于Java的解决方案构成了许多银行解决方案的基础。使用这种编程语言进行开发，可以使我们优化大量的交易项目，以最小的人力消耗与银行系统进一步融合。Objective c和xcode-iOS的原生开发环境。Java和Android SDK-Android的本地开发环境。

Angular和react js——这些框架将用于创建Web应用程序。验证者区块链将通过以太坊的分支创建，并进一步创建自己的智能契约。

VRF令牌技术实现了VRF令牌与ERC20标准的兼容，并基于以太坊区块链系统。以太坊最适合验证者系统，因为它已经成为加密货币行业通过block系统保证交易操作的首选。

ERC20是以太坊令牌的标准，ERC20与以太坊系统的兼容性使您能够编写一个智能契约，提供对应于特定需求的验证者系统的安全性和可定制的加密操作，并能够在一个真正分布式的系统中在社会成员之间轻松分发令牌。

因为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. 智能合约的书写语言— Solidity

7. 用户帐户数量为— 1，所有请求实际上都是为了单个用户而执行的

8. （用于智能合同工作）账户系统的数量是— 1，所有的逻辑被同一个智能合同运用各种方法执行

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

1. 查询和结果表单— application/json

2. 代码交换— utf-8

3. 在单元终端逻辑的执行方式— 智能合约

4. 智能合约的书写语言— Solidity

5. 用户帐户数量为— 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 —根据源文档返回生成摘要的规则

以上知识分享希望能够帮助到大家！