Verifier — 是針對任何類型的交易，數(shù)據(jù)傳輸和活動的創(chuàng)新驗證技術。Verifier 的速度，準確性和安全性由區(qū)塊鏈的技術提供。

Verifier 是一款針對智能手機和平板電腦的應用程序以及基于優(yōu)步模型的Web版本，即通過客戶與服務提供商之間的直接交易提供的服務。 當需要確認身份或任何事實時，系統(tǒng)會隨機選擇準備前往該現(xiàn)場的負責代理人（驗證人），并以照片，視頻和其他材料的形式提交驗證。

Verifier 允許您準確地報告或了解發(fā)生/未發(fā)生某些事件或執(zhí)行/未執(zhí)行任何操作的事件。交付一個合適質量的包裹，要求在真實客戶的銀行開立賬戶，實地查看 - 這要歸功于驗證人，您可以在分散的可靠的人員的幫助下檢查任何事實。

代理收集的材料將被加密并通過電子郵件發(fā)送正式要求出示的證據(jù)。有防護密鑰的數(shù)據(jù)以散列形式通過一系列的模塊鏈被發(fā)送。這保證了數(shù)據(jù)內容在傳輸?shù)接嘘P部門或個人的過程中不被損壞或攔截。代理商將從相關方獲得報酬，并且可以在世界任何地方。 代理的主要工具是互聯(lián)網(wǎng)。 有規(guī)避風險的愿望嗎？ 可以一次將任務交給幾個獨立的代理。

Verifier不僅是一個應用程序。 其作為開放式代碼解決方案的潛力同樣令人感興趣。 通過嵌入和修改Verifier代碼，您可以將系統(tǒng)的功能擴展并更改為特定的任務和要求。

受眾群體

Verifier服務旨在滿足兩個主要市場— 公司對公司（B2B）和個人對個人（P2P）驗證服務的需求。

B2B – 利基，企業(yè)市場。

主要客戶是需要遵守KYC程序的公司金融部門。 這些銀行、交易所、保險公司和其他企業(yè)以及其他要求提供資產及抵押和其他企業(yè)服務的金融和法律服務的客戶。

P2P – 大眾市場。

任何人都可以使用 。Verifier要做到這一點，只需下載應用程序或訪問網(wǎng)站wed.Verifier. org 。 世界上的每一個互聯(lián)網(wǎng)用戶都將擁有無限的遠程體驗和服務的機會，這在以前只有大中型企業(yè)和收入水平很高的個人才能使用。

經(jīng)濟數(shù)據(jù)

1.代幣描述

Verifier 模塊服務基于通過使用模塊鏈技術在系統(tǒng)內安全傳輸數(shù)據(jù)。 代幣的發(fā)行旨在為驗證服務的啟動和進一步擴展提供資金。 籌集的資金將用于開發(fā)Verifier系統(tǒng)，以及用于增加項目受眾的營銷。 Verifier公司為了籌措資金發(fā)行代幣Verifier Tokens，稱為VRF，是基于以太坊平臺的智能合約。

2.代幣模式

120 000 000 VRF 代幣。

代幣定價：1 代幣等于 驗證申請的最低費用。 1 VRF = 0，1 美元。

代幣分度和額外發(fā)行：從技術上講，使用現(xiàn)有的數(shù)據(jù)結構，VRF可以劃分為小數(shù)點后第八位，所以0.0001 VRF是目前最小的數(shù)字。 如果有需要的話，保證代幣的更小部分的想法在未來可能是具有現(xiàn)實意義的。 目前還沒有預計執(zhí)行額外的發(fā)行。

3.代幣持有者收益

VRF 代幣旨在用作支付媒介在Verifier平臺上的加密系統(tǒng)中。 所有者可以支付系統(tǒng)內的服務費用，向系統(tǒng)中的其他參與者出售代幣，并將其換成其他加密貨幣。 所有通過網(wǎng)站上的代幣執(zhí)行的操作都通過智能合約記錄在區(qū)塊鏈。

代幣的基礎價格等于呈現(xiàn)服務的最低成本，為0，1美元或 1VRF。

VRF 代幣需求的增長是由于在系統(tǒng)中購買代幣的交易數(shù)量的增加而產生的，并且隨著系統(tǒng)中用戶數(shù)量的增加而不斷增加。 服務的最低成本（靜態(tài)部分）將保持在同一水平。

技術說明

Verifier 是一個軟件包，旨在確認真實世界中的數(shù)據(jù)，事件，文檔和對象的真實性，使用區(qū)塊鏈技術驗證后傳輸?shù)臄?shù)據(jù)的可靠性。

在結構上，Verifier由以下組件（子系統(tǒng)）組成：

? 移動應用客戶;

? 管理和審閱系統(tǒng);

? 數(shù)據(jù)庫;

? 應用程序與服務器交互的API;

? 基于以太坊（Ethereum）的本地部署模塊，其中包含一系列可能發(fā)生外部呼叫的功能

Verifier的開發(fā)人員使用以下工具集：

? Java — 用于開發(fā)項目的服務器部分?；?Java 的解決方案構成了大量銀行解決方案的基礎。使用這種編程語言進行開發(fā)將使我們能夠針對大量交易項目的優(yōu)化，并且能夠以最小的勞動力消耗進一步與銀行系統(tǒng)進行整合。

? Objective C 和 Xcode — 適用于iOS的本機開發(fā)環(huán)境。

? Java 和 Android SDK — 適用于Android的本機開發(fā)環(huán)境。

? Angular 和 ReactJS — 這些框架將用于創(chuàng)建Web應用程序。

Verifier 區(qū)塊鏈將通過以太坊（Ethereum）的分支創(chuàng)建，并進一步創(chuàng)建自己的智能合約。

VRF 代幣的技術實現(xiàn)

VRF代幣與ERC20標準兼容，并基于以太坊（Ethereum ）區(qū)塊鏈系統(tǒng)。以太坊（Ethereum）最適合Verifier系統(tǒng)，因為它已成為加密貨幣行業(yè)通過區(qū)塊系統(tǒng)確保交易操作的首選。 ERC20是以太坊（Ethereum）代幣的標準，以及ERC20和以太坊（Ethereum ）系統(tǒng)之間的兼容性讓你能編寫提供對應于具體要求的Verifier系統(tǒng)的安全和可定制加密操作的智能合同，并可以很容易地在一個真正的分散式系統(tǒng)分配社會成員之間的代幣。

由于 VRF 代幣在以太坊模塊平臺重磅發(fā)布，并且需要在私人模塊中進行 VRF 代幣項目計算：

? 公共和私人社區(qū)不會相互影響。

? 以太坊公共網(wǎng)僅用于發(fā)送代幣。

? 將VRF代幣發(fā)送到錢包時，它收集有關服務器上部署的以太坊節(jié)點的信息并將其傳輸?shù)奖镜啬K。 該操作通過在錢包上收取代幣的功能來執(zhí)行。 因此，用戶具有用于發(fā)送代幣和內部余額，反映在私人Verifier區(qū)塊鏈中信息的地址。

當需要為完成的工作發(fā)送代幣時，系統(tǒng)將指示以太坊的智能合約，并將所需數(shù)量的代幣發(fā)送到外部地址。

1.智能合約

該項目實施了一套智能合同。 這些智能合約通過以下方法實施：

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

? 將Summary計算字符串保存到單元格

? 查詢（并返回）Summary計算字符串單元格

在第一個函數(shù)中，智能合約通過SHA-256和Stribog（全蘇國家標準P 34.11-2012）算法對數(shù)據(jù)進行散列。這些算法被選擇為散列中的加密標準。加密功能是單向的，不提供反向加密。此實施僅用于創(chuàng)建散列，稍后將作為檢驗基于驗證結果傳輸?shù)臄?shù)據(jù)的準確性的證據(jù)，以及證據(jù)表明當事方在爭議問題中提供的數(shù)據(jù)與Verifier系統(tǒng)傳輸?shù)臄?shù)據(jù)相符。

在第二個函數(shù)中，智能合約在第一個智能合約散列之后將散列保留在模塊中。 后面的散列想要確認數(shù)據(jù)的有效性必須要通過這個函數(shù)來實現(xiàn)。

第三個智能合約具有雙重功能：

1.接收來自模塊的散列，以便將該散列的主要傳輸發(fā)送給客戶端，然后可以用它來確認數(shù)據(jù)的真實性。

2.在需要的情況下向區(qū)塊請求數(shù)據(jù)以提供給客戶端。

2.智能托管

在首發(fā)期間募集的所有資金都通過位于已安裝在以太坊區(qū)塊鏈的智能合約的智能托管服務獲得。

智能托管是一種工具，允許購買代幣的買家通過投票控制在基礎銷售期間募集的資金分期分配。

只有在 Verifier 項目團隊通過文檔和路線圖的幫助確認了以前的步驟之后，每一個下一階段的支出才有可能。

投票是在 VRF 代幣持有人的個人賬戶中實現(xiàn)的，從融資階段開始的24 小時內持續(xù)投票，并將結果存儲在智能合約中。 VRF 代幣的所有賬戶中擁有超過 30，000個 VRF 代幣的持有者都有投票權。

在超過51％的參與者投贊成票的情況下投票被認為是成功的，并且該投票會傳遞給 Verifier 團隊的錢包。 如果超過 49％投否定票，智能合約上的所有資金將按照代幣數(shù)量的比例分配給代幣持有者。

3.代理驗證人的注冊

私人驗證器

在確認用戶的身份后，創(chuàng)建具有此角色的新用戶。 用戶完成問卷后，將創(chuàng)建該帳戶的應用程序。 每個應用程序按現(xiàn)有代理程序的順序組成。

通過驗證后，用戶被激活并可以接收系統(tǒng)中的任務。 此外，在通過用戶驗證之后，將可以借助于Parity API調用為其創(chuàng)建的單獨的秘密錢包。

驗證者通過聯(lián)合公司注冊

當用戶注冊了此類用戶的業(yè)務合作伙伴角色時，會創(chuàng)建一個單獨的Web界面。 在界面中，顯示通過此合作伙伴注冊的所有用戶，他們執(zhí)行的任務統(tǒng)計以及薪酬統(tǒng)計。

擔任合伙人角色的用戶可以獨立更改每個以公司為受益人的工作的費用百分比。 通過合伙公司的個人賬戶注冊的用戶將獲得最終報酬或有關該任務獲得扣除利息的資金的信息。

在通過合作公司的個人主頁注冊用戶時，用戶不需要額外的驗證。 合作伙伴公司獨立承擔所提供數(shù)據(jù)的可靠性責任。

與代理驗證人進行的所有相互結算都是以法定貨幣進行，并通過合作伙伴公司的帳戶進行。 在這種情況下，匯總報告期間的所有報酬，并將總額發(fā)送給交易對方的賬戶。

具有合作伙伴公司角色的用戶可以自行決定連接用戶或刪除以前連接的任何用戶。

4.數(shù)據(jù)驗證算法

在確認應用程序進行驗證之后，服務器會向移動客戶端發(fā)送一個JSON文件，其中包含有關應用程序和要進行驗證的表單的信息。

移動客戶端創(chuàng)建兩個屏幕：第一個顯示應用程序的信息，第二個顯示數(shù)據(jù)驗證的形式。

當驗證站點到達驗證者時，驗證者按下按鈕開始驗證，如果驗證者的地理位置與應用程序中指定的地理位置一致（假定為 200 米），則應用程序移動到第二個畫面。 第二個屏幕上的驗證表單對于每個應用程序都是唯一的。 表單可以包含指令和輸入驗證字段列表。

填寫完表格后，數(shù)據(jù)將被發(fā)送到應用程序服務器。 在服務器上，數(shù)據(jù)散列被發(fā)送到主機，并且數(shù)據(jù)被重新打包成應用程序作者創(chuàng)建時所選擇的格式。

驗證者之間分配任務的算法

當新任務進入系統(tǒng)時，算法必須選擇位于驗證對象緊鄰的代理。 如果任務需要特殊能力，那么即使在設施附近還有其他代理人，也要優(yōu)先考慮具有此能力的代理人。在確定來自10個職位的潛在代理人名單之后，他們中的每一個都會發(fā)送包含任務數(shù)據(jù)的推送通知。

代理人在不超過兩分鐘時間內作出決定。 如果沒有用戶響應該請求，則該消息再次被發(fā)送給更廣泛的用戶。 在沒有所需能力的代理人的情況下，系統(tǒng)必須通知客戶此操作無法執(zhí)行，并提供重新設定應用程序而無需指定權限。

在確認應用程序之后，驗證者以JSON文件的形式接收訂單數(shù)據(jù)，其中包含字段和數(shù)據(jù)類型列表以及有關驗證對象的信息。

與外部當事人的配合

與外部交易當事人的交流有兩種形式。

使用SFTP協(xié)議

使用SFTP協(xié)議以JSON格式交換文件。 對于需要處理的數(shù)據(jù)訪問 FTP 服務器是從銀行側和Verifier側以指定的頻率完成的。 銀行從FTP服務器上的指定目錄接收JSON格式的文件數(shù)據(jù)。 響應文件名稱對應于請求文件中指定的應用程序編號。

使用API來請求獲取信息

在這個版本中，在服務驗證器端，實現(xiàn)了RESTful API，通過HTTP協(xié)議（GET / POST-查詢）直接訪問銀行。 請求/回復的數(shù)據(jù) - JSON目標，編碼 - UTF-8。 請求/回復假設為一組靈活的字段并依賴于特定的查詢。

使用的區(qū)塊鏈類型

1. 技術 — 以太坊 （比特幣 2.0）

2. 區(qū)塊鏈客戶 — 奇偶校驗位

3. 組織單元 — 私人（本地（內聯(lián)網(wǎng)）單元，沒有連接全球單元）

4. 與單元通信的模式 — RPC，POST請求

5. 在單元終端執(zhí)行邏輯的方式 —智能合約

6. 智能合約的書寫語言 — Solidity

7. 用戶帳戶數(shù)量為— 1，所有請求實際上都是為了單個用戶而執(zhí)行的

8. （用于智能合同工作）賬戶系統(tǒng)的數(shù)量是 — 1，所有的邏輯被同一個智能合同運用各種方法執(zhí)行

服務器部分與以太坊區(qū)塊鏈的交互

為了與模塊進行通信，建議使用運行在 HTTP 協(xié)議上的 JSON-RPC 客戶端，例如 web3j。 此API實施允許您使用來自本地 Java 代碼的智能合約，錢包，交易等 。

1. 查詢和結果表單 — application/json

2. 代碼交換 — utf-8

3. 在單元終端邏輯的執(zhí)行方式 — 智能合約

4. 智能合約的書寫語言 — Solidity

5. 用戶帳戶數(shù)量為 — 1，所有請求實際上都是為了單個用戶而執(zhí)行的

6. （用于智能合同工作）賬戶系統(tǒng)的數(shù)量是 一1，所有的邏輯被同一個智能合同運用各種方法執(zhí)行

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

a. eth_accounts — 返回主機當前節(jié)點的活動帳戶列表

b. eth_getBalance — 返回所選帳戶的余額（在以太坊中）

c. eth_call — 調用智能合約方法

d. eth_sendTransaction — 調用單元中要執(zhí)行的請求

e. eth_getTransactionReceipt — 調用關于事務信息的請求

8. 在智能合約框架內執(zhí)行的方法：

a. getHash — 對發(fā)送的UTF-8字符串進行HASH計算的SHA-256方法

b. getHashGOST — 通過Stribog方法對傳輸?shù)腢TF-8字符串進行HASH計算（全蘇國家標準 P 34.11-2012）

c. getSummaryRules —根據(jù)源文檔返回生成摘要的規(guī)則