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

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

Verifier 允許您準(zhǔn)確地報(bào)告或了解發(fā)生/未發(fā)生某些事件或執(zhí)行/未執(zhí)行任何操作的事件。交付一個(gè)合適質(zhì)量的包裹，要求在真實(shí)客戶(hù)的銀行開(kāi)立賬戶(hù)，實(shí)地查看 - 這要?dú)w功于驗(yàn)證人，您可以在分散的可靠的人員的幫助下檢查任何事實(shí)。

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

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

受眾群體

Verifier服務(wù)旨在滿足兩個(gè)主要市場(chǎng)— 公司對(duì)公司（B2B）和個(gè)人對(duì)個(gè)人（P2P）驗(yàn)證服務(wù)的需求。

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

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

P2P – 大眾市場(chǎng)。

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

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

1.代幣描述

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

2.代幣模式

120 000 000 VRF 代幣。

代幣定價(jià)：1 代幣等于 驗(yàn)證申請(qǐng)的最低費(fèi)用。 1 VRF = 0，1 美元。

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

3.代幣持有者收益

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

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

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

技術(shù)說(shuō)明

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

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

? 移動(dòng)應(yīng)用客戶(hù);

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

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

? 應(yīng)用程序與服務(wù)器交互的API;

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

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

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

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

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

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

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

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

VRF代幣與ERC20標(biāo)準(zhǔn)兼容，并基于以太坊（Ethereum ）區(qū)塊鏈系統(tǒng)。以太坊（Ethereum）最適合Verifier系統(tǒng)，因?yàn)樗殉蔀榧用茇泿判袠I(yè)通過(guò)區(qū)塊系統(tǒng)確保交易操作的首選。 ERC20是以太坊（Ethereum）代幣的標(biāo)準(zhǔn)，以及ERC20和以太坊（Ethereum ）系統(tǒng)之間的兼容性讓你能編寫(xiě)提供對(duì)應(yīng)于具體要求的Verifier系統(tǒng)的安全和可定制加密操作的智能合同，并可以很容易地在一個(gè)真正的分散式系統(tǒng)分配社會(huì)成員之間的代幣。

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

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

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

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

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

1.智能合約

該項(xiàng)目實(shí)施了一套智能合同。 這些智能合約通過(guò)以下方法實(shí)施：

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

? 將Summary計(jì)算字符串保存到單元格

? 查詢(xún)（并返回）Summary計(jì)算字符串單元格

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

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

第三個(gè)智能合約具有雙重功能：

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

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

2.智能托管

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

智能托管是一種工具，允許購(gòu)買(mǎi)代幣的買(mǎi)家通過(guò)投票控制在基礎(chǔ)銷(xiāo)售期間募集的資金分期分配。

只有在 Verifier 項(xiàng)目團(tuán)隊(duì)通過(guò)文檔和路線圖的幫助確認(rèn)了以前的步驟之后，每一個(gè)下一階段的支出才有可能。

投票是在 VRF 代幣持有人的個(gè)人賬戶(hù)中實(shí)現(xiàn)的，從融資階段開(kāi)始的24 小時(shí)內(nèi)持續(xù)投票，并將結(jié)果存儲(chǔ)在智能合約中。 VRF 代幣的所有賬戶(hù)中擁有超過(guò) 30，000個(gè) VRF 代幣的持有者都有投票權(quán)。

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

3.代理驗(yàn)證人的注冊(cè)

私人驗(yàn)證器

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

通過(guò)驗(yàn)證后，用戶(hù)被激活并可以接收系統(tǒng)中的任務(wù)。 此外，在通過(guò)用戶(hù)驗(yàn)證之后，將可以借助于Parity API調(diào)用為其創(chuàng)建的單獨(dú)的秘密錢(qián)包。

驗(yàn)證者通過(guò)聯(lián)合公司注冊(cè)

當(dāng)用戶(hù)注冊(cè)了此類(lèi)用戶(hù)的業(yè)務(wù)合作伙伴角色時(shí)，會(huì)創(chuàng)建一個(gè)單獨(dú)的Web界面。 在界面中，顯示通過(guò)此合作伙伴注冊(cè)的所有用戶(hù)，他們執(zhí)行的任務(wù)統(tǒng)計(jì)以及薪酬統(tǒng)計(jì)。

擔(dān)任合伙人角色的用戶(hù)可以獨(dú)立更改每個(gè)以公司為受益人的工作的費(fèi)用百分比。 通過(guò)合伙公司的個(gè)人賬戶(hù)注冊(cè)的用戶(hù)將獲得最終報(bào)酬或有關(guān)該任務(wù)獲得扣除利息的資金的信息。

在通過(guò)合作公司的個(gè)人主頁(yè)注冊(cè)用戶(hù)時(shí)，用戶(hù)不需要額外的驗(yàn)證。 合作伙伴公司獨(dú)立承擔(dān)所提供數(shù)據(jù)的可靠性責(zé)任。

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

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

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

在確認(rèn)應(yīng)用程序進(jìn)行驗(yàn)證之后，服務(wù)器會(huì)向移動(dòng)客戶(hù)端發(fā)送一個(gè)JSON文件，其中包含有關(guān)應(yīng)用程序和要進(jìn)行驗(yàn)證的表單的信息。

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

當(dāng)驗(yàn)證站點(diǎn)到達(dá)驗(yàn)證者時(shí)，驗(yàn)證者按下按鈕開(kāi)始驗(yàn)證，如果驗(yàn)證者的地理位置與應(yīng)用程序中指定的地理位置一致（假定為 200 米），則應(yīng)用程序移動(dòng)到第二個(gè)畫(huà)面。 第二個(gè)屏幕上的驗(yàn)證表單對(duì)于每個(gè)應(yīng)用程序都是唯一的。 表單可以包含指令和輸入驗(yàn)證字段列表。

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

驗(yàn)證者之間分配任務(wù)的算法

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

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

在確認(rèn)應(yīng)用程序之后，驗(yàn)證者以JSON文件的形式接收訂單數(shù)據(jù)，其中包含字段和數(shù)據(jù)類(lèi)型列表以及有關(guān)驗(yàn)證對(duì)象的信息。

與外部當(dāng)事人的配合

與外部交易當(dāng)事人的交流有兩種形式。

使用SFTP協(xié)議

使用SFTP協(xié)議以JSON格式交換文件。 對(duì)于需要處理的數(shù)據(jù)訪問(wèn) FTP 服務(wù)器是從銀行側(cè)和Verifier側(cè)以指定的頻率完成的。 銀行從FTP服務(wù)器上的指定目錄接收J(rèn)SON格式的文件數(shù)據(jù)。 響應(yīng)文件名稱(chēng)對(duì)應(yīng)于請(qǐng)求文件中指定的應(yīng)用程序編號(hào)。

使用API來(lái)請(qǐng)求獲取信息

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

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

1. 技術(shù) — 以太坊 （比特幣 2.0）

2. 區(qū)塊鏈客戶(hù) — 奇偶校驗(yàn)位

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

4. 與單元通信的模式 — RPC，POST請(qǐng)求

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

6. 智能合約的書(shū)寫(xiě)語(yǔ)言 — Solidity

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

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

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

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

1. 查詢(xún)和結(jié)果表單 — applicaTIon/json

2. 代碼交換 — utf-8

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

4. 智能合約的書(shū)寫(xiě)語(yǔ)言 — Solidity

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

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

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

a. eth_accounts — 返回主機(jī)當(dāng)前節(jié)點(diǎn)的活動(dòng)帳戶(hù)列表

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

c. eth_call — 調(diào)用智能合約方法

d. eth_sendTransacTIon — 調(diào)用單元中要執(zhí)行的請(qǐng)求

e. eth_getTransacTIonReceipt — 調(diào)用關(guān)于事務(wù)信息的請(qǐng)求

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

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

b. getHashGOST — 通過(guò)Stribog方法對(duì)傳輸?shù)腢TF-8字符串進(jìn)行HASH計(jì)算（全蘇國(guó)家標(biāo)準(zhǔn) P 34.11-2012）

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