Skip to content

MVP description

Jump to bottom
rs-blashyrkh edited this page Feb 21, 2018 · 3 revisions

MVP description

Software components

  1. PROVER Swype-ID mobile application (MOBILE CLIENT)
  2. Smart contract in the Ropsten network (SMART CONTRACT)
  3. Server that counterparts the mobile software (SERVER)
  4. Web-server intended to verify video files (WEB)
  5. Ropsten Ethereum node (NODE)
  6. PROVER Clapperboard mobile application (CLAPPERBOARD)

Verified video creation protocol

  1. Alice requests the swype-code by invoking of "requestSwypeCode" method of the SMART CONTRACT. The swype-code itself is determined by transaction hash and block hash of the transaction of "requestSwypeCode" method invocation: SWYPEID=SHA256(TXHASH|BLOCKHASH)%MODULO. The request is initiated by MOBILE CLIENT, which communicates with the SERVER which in turn communicates with the NODE. Since the SMART CONTRACT method is called from the user's account, it's possible for Alice to call the method manually using his own ethereum node.

  2. Alice records video file using MOBILE CLIENT or by any other means. The video file must contain circular movement ("OK, Prover") and swype-code.

  3. Alice calculates SHA256 of video file and invokes "submitMediaHash" method of the SMART CONTRACT. The method accepts two parameters: video file hash and the hash of the corresponding "requestSwypeCode" transaction. This functionality is also implemented in the MOBILE CLIENT.

  4. Alice publishes video file anywhere.

Video file verification protocol

  1. Bob wants to verify the authorship of the given video file. Particularly, he wants to be sure that Alice (who gave him a link to the video) is really the author of the video file. Bob calculates SHA256 hash of the file.

  2. Bob looks up for event in the blockchain emitted by the "submitMediaHash" method. As a result he receives issuer's address, transaction hash of "requestSwypeCode" transaction, and timestamp of the transaction.

  3. Bob reads attributes of the "requestSwypeCode" transaction found at step 2, particluarly timestamp and block hash.

  4. Bob calculates SWYPEID.

  5. Bob verifies that the swype-code corresponding to the found SWYPEID is present in the video file.

  6. Bob verifies that both "submitMediaHash" and "requestSwypeCode" transactions were emitted from Alice's account.

Steps 1-5 can be done using the WEBSITE. Bob have to upload the video file to the WEBSITE and receive information about author address and swype-code validity.

MOBILE CLIENT - SERVER communication protocol

  1. MOBILE CLIENT sends "/hello?user=0x...." request to the SERVER. MOBILE CLIENT passes user address to the server.

  2. SERVER returns: SMART CONTRACT address, current gas price, user address balance, number of transactions sent from the user address (needed to construct new transaction).

  3. MOBILE CLIENT builds and signs "requestSwypeCode" invocation transaction and sends its hex representation to the SERVER using request "/request-swype-code?hex=0x..."

  4. SERVER broadcasts the transaction to the network, returns transaction hash to the MOBILE CLIENT.

  5. MOBILE CLIENT sends "/request-swype-code?txhash=0x..." to SERVER, passing transaction hash received at the step 4.

  6. SERVER checks for transaction confirmation. If the transaction is confirmed (i.e. included into block), swype code is calculated and returned to MOBILE CLIENT. If the tranaction is not confirmed, null is returned.

  7. Steps 5-6 are repeated until SERVER returns non-null swype-code.

  8. MOBILE CLIENT asks user to enter the swype-code and assists in it.

  9. User captures video file using MOBILE CLIENT. When the process is finished, SHA256 hash function of the video file is calculated.

  10. [Optional] MOBILE CLIENT sends "/hello/user=0x..." requests to receive new gas price.

  11. MOBILE CLIENT builds and signs "submitMediaHash" invocation transaction and sends its hex representation to the SERVER using request "/submit-media-hash?hex=0x..."

  12. SERVER broadcasts the transaction to the network, returns transaction hash to the MOBILE CLIENT.

Step 10 should be done if the network gas price could significantly change during a capturing of video file.

Swype-code calculation

Swype-code is defined in domain of 9 points placed in orthogonal grid:

1 2 3

4 5 6

7 8 9

Swype-code always starts from the center (point 5).

Given the SWYPEID (ordinal number) of the swype code, the swype-code (sequence of points) is calculated this way:

  1. First point of the resulting sequence is "5".
  2. We define "current point", it's "5" now.
  3. M:=1
  4. NN - number of neighbours of the current point. Points "1", "3", "7" and "9" have 3 neighbours, points "2", "4", "6" and "8" have 5 neighbours, point "5" has 8 neighbours. We define N as ordered list of neighbours of the current point. For current point "3" N[0] is "2", N[1] is "5", N[2] is "6".
  5. N[(SWYPEID*NN)/MODULO] - the next point of the swype-code.
  6. M:=M*NN
  7. SWYPEID:=(SWYPEID*NN)%MODULO
  8. Steps 4-7 are repeated until M>=MODULO.

In current implementation MODULO is 27000, which gives 27000 different swype-codes up to 9 points long.

Fast swype-code generation mode

In some cases an immediate swype code generation is required. "Fast mode" covers such cases, but it's worth noting that fast swype code generation is not recorded in blockchain, which may allow certain types of attack.

  1. MOBILE CLIENT sends "/fast-request-swype-code?user=0x..." request to the SERVER. MOBILE CLIENT passes user address to the server.

  2. SERVER calculates the swype code: SWYPEID=SHA256(BLOCKHASH|USER)%MODULO, where BLOCKHASH is 32-bytes hash of some recent block (2-3 confirmations should be enough). USER is user address converted to 20-bytes binary form.

  3. SERVER returns swype code and reference block hash to the MOBILE CLIENT.

  4. Reference block hash is being used instead of requestSwypeCode transaction hash.

Validation process supports the "fast mode" this way: if requestSwypeCode txhash is not found in the blockchain, block with this hash is being looked for. If the block is found, it's the reference block.

QR-code clapperboard

Alternative method of video file verification implies a presence of QR-code generated by the CLAPPERBOARD in the video stream. This method is useful if video is being captured by stationary camera.

  1. User (with CLAPPERBOARD software) initiates "/hello?user=0x...." request to the SERVER. CLAPPERBOARD passes user address to the server.

  2. SERVER returns: SMART CONTRACT address, current gas price, user address balance, number of transactions sent from the user address (needed to construct new transaction).

  3. User enters a comment - associated with the video being captured - to be placed in blockchain.

  4. CLAPPERBOARD builds and signs "submitMessage" invocation transaction and sends its hex representation to the SERVER using request "/submit-message?hex=0x..."

  5. SERVER broadcasts the transaction to the network, returns transaction hash to the CLAPPERBOARD.

  6. CLAPPERBOARD sends "/submit-message?txhash=0x..." to SERVER, passing transaction hash received at the step 5.

  7. SERVER checks for transaction confirmation. If the transaction is confirmed (i.e. included into block), block hash is returned to CLAPPERBOARD. If the tranaction is not confirmed, null is returned.

  8. Steps 6-7 are repeated until SERVER returns non-null block hash.

  9. CLAPPERBOARD combines binary representation of the transaction hash (step 5) with first (leftmost) 14 bytes of the block hash (step 7), producing 46-bytes binary string. This binary string is interpreted as big-endian binary representation of decimal number. The number is represented as 4Q numeric QR-code, which is displayed at the screen of CLAPPERBOARD.

  10. User makes the mobile device with displayed QR-code be caught on camera capturing the video stream.

Clone this wiki locally