Technical specifications

Work Quest Technical Specification

The Work Quest technical specification document explains what its project will address as well as the process the company will partake in to achieve the project’s goals and objectives. By understanding the technical specifications, individuals are directed to the work that will be accomplished. The Work Quest platform’s objective is to create an online job marketplace connecting employers and employees from any part of the world. The platform will be powered by blockchain’s smart contract.

Work Quest Overall Structure

In the Work Quest system blockchain physically exists in the form of database duplicates, which are stored on each of the full nodes as a master or as a validator. Due to the presence of a high number of reading requests to the blockchain which is similar to the blockchain replicas, Work Quest has organized the following structure.

Available services in the network.

• Workers — they collect data coming directly to the blockchain
• Data — refers to various types of blocks and transactions such as sending, buying, and selling

N/B: Several identical services must come into play to prevent loss of data if a service may fail. The ideology is that no information should be lost during a process.

A sampling of data at the output of workshops is directed to the indexer, which in turn sorts, restructures, and finally indexes the data provided. Following this process, the data is stored in the man database (Master). The stored data is then replicated several times and place in deep storage (Deep).

Explorer users can make requests to search for different sorts of information on the blockchain. All the searches/requests go through a special balancer which then distributes the content and sends the ideal requests for reading from the Deep storage. It is as a result that data buffering occurs from the blockchain.

Also, the system comes with a writing information channel to the blockchain. The system uses a special Gateway API interface. This gateway is connected to the system nodes, desktop wallet the work of console, as well as wallet applications for mobile devices.

The structure of all the services is fully decentralized, users own seed-phase as well as private keys. Following corresponding transactions is the user signature after which they are sent to the network. The transactions are then processed and verified after which they are included in the block. Finally, they are written in a chain of blocks after validators reach a consensus following replication of each full node.

The Work Quest architecture features a special service Status. The available monitoring service tracks collects and provides general network parameters.

Stack of Technologies

• Programming Languages

The selected Work Quest programming language that ensures its functionality, namely validators (master node software) is Golang because it is compatible with the Cosmos SDK as well as Tendermint. On the other hand, Work Quest uses TypeScript to code the backend modules. This programing language is strictly typed and convenient in the development process. It also compiles in JavaScript and it is compatible with NodeJS with the added advantage that it runs on modern browsers. This programming code was applicable for Indexers and Workers.

To enable desktop wallet applications, Work Quest used ElectronJS programming language. It plays the role of creating cross-platform desktop applications that are based on JavaScipt, CSS, as well as HTML.

Cosmos SDK

Work Quest blockchain is developed based on Cosmos SDK. Cosmos SDK is a set of tools used to develop blockchain applications focused on addressing specific problems (tasks) to provide secure and reliable solutions. Such solutions include providing network communication between nodes that are involved in the formation of blocks. To achieve this, Cosmos SDK actively uses the Tendermint Core Library.

Work Net Blockchain is compatible with every blockchain present in the Cosmos Network as a result of building it on the Cosmos SDK. In this, in the event a node runs into a specified state followed by a duplication of the transaction, the results will always be the same despite the several sequences.

The added advantage for developers using the Cosmos SDK is that it allows for flexibility when determining the state of the application, state transition functions, as well as transaction types.

Tendermint

Overall, Tendermint is responsible for efficient relaying of blockchain changes so that each node on the network has a similar transaction log and blockchain state.

Tendermint refers to an advanced consensus solution that is based on the Byzantine Fault Tolerance (BFT), which guarantees the right operation of a computer network. This operation occurs as long as at least two-thirds of the network nodes that are involved in the block formation (validator) process work correctly.

Two main technical components comprise Tendermint. These components include the consensus mechanism engine and application interface.

The application interface for Wok Quest is termed Application Blockchain Interface (ABCI) is responsible for allowing transactions to be processed in any programming language. On the other hand, the consensus mechanism engine is called Tendermint Core and it is responsible for ensuring that all transactions are recorded in a similar order even when on different machines.

Multisignature

Work Quest will feature Multisignature (Multisig) addresses, which promote convenience during the allocation of funds or decision-making processes in the presence of independent participants. For example, for a shared wallet, funds can only be withdrawn if 80% or more of the participants agree to the transaction.

To promote its functionality, there are three types of transactions encoded: CreateMultisig, Create Transaction and Sign Transaction.

• CreateMultisig is responsible for creating a wallet with multi-signature in addition to indicating its owners, threshold value, and their voice weight.
• Create Transaction is responsible for the creation of a transaction to output the required number of coins to a specified address after which the transaction creator signs the transaction immediately. Each of these transactions is assigned a unique identifier.

Explorer

The Explorer unit assists Work Quest users to understand the functionality of a Work network as well as trace necessary information about transactions. Work Quest must ensure they can provide the required information despite a large amount of information available. Therefore, the platform organizes storage in a database that can satisfy a huge number of requests and in turn provide the required information for users.

How the process is organized:

Events are generated from state changes in the blockchain monitored by special services. These services analyze incoming information from transactions and blocks and then transfer this information to the Index. It is at the Index that data is sorted and indexed.

The searched data is written to the PostgreSQL database after which they are written to the master database (Master). For safety purposes, the information is then replicated on deep storage (DeepS). Through a Load Balancer, which is responsible for organizing load balancing, the DeepS database receives all requests from the Explorer. In the event a load increases, deepS databases will be added. Databases will provide information about events and states in the blockchain fast through indexing and partitioning.

Wallet

Work Quest wallets are non-custodial (decentralized). Private keys, as well as seed phrases, are stored on the user side thus eradicating Work Quest’s ability to access them. The owners of wallets are fully responsible for the safety of private data and funds.

Private keys are generated based on the BIP39 standard.

Elliptical curve secp256k1

The Seed Phase consists of 24 words.

Address format (Bech32)

Blockchains feature unique address formats, which represent a sequence of letters and numbers in Latin. Being in Latin, many users cannot read them correctly. The Bech32 address is never more than 90 characters including:

• Easy to read the part which comprises of data regarding the owner of the address that is usually a minimum of one character.
• A separator that always equals “1”
• The data portion which is at least 6 characters in length consisting of alphanumeric characters
• Checksum which comprises of the last six characters that contain no information

N/B: All letters are presented in lower case. However, these letters may be converted into uppercase letters for generating QR codes.

Roles

• Validator

A validator is a member of the Work network who plays the role of keeping a blockchain replica, provide transaction verification, blockchain formation, as well as participating in the consensus-building process.

The validator has voting power and the higher the stake of a validator, the more power they have. Also, the bigger the stake size, the more voice power and the more it produces blocks. In turn, the higher the received rewards. In the event the validator does not perform their duties efficiently, they get fined. These fines cause the loss of part of their stake.

Key validator responsibilities:

• Ensure reliability of its work
• Be readily available on the network
• Perform relevant duties in the consensus-building procedure
• Guarantee access of Work network internal services to its blockchain replica
• Ensure integrity of stored data
• Delegator

A delegator refers to a Work Net member who leases his funds to a validator. Leasing means that the transferred funds are simply blocked in the account of the delegator and until he unbinds his funds, he cannot dispose of them. This transfer process is called delegation which is the transfer of user rights and responsibilities.

• User

Users refer to all the other members of the Work network. The platform sees each user as a potential delegator and/or validator.

Delegation

Delegation refers to the process of binding user coins to the validator(s), which is performed using a special transaction Delegate. A delegator refers to the user who delegates coins. The delegated funds are blocked in the user’s account. However, they are not displayed in the user’s account balance. Though the balance is not displayed, the funds are displayed in the common validator stake. In turn, it increases its weight on other validators as well as the strength of the consensus mechanism voice. Therefore, a validator cannot gain access to the funds.

Validators are competitive and those with a large stake mostly participate in consensus-building with more rewards.

Work Net has an unbound operation for delegated coins. This operation will be initiated and sent to the network either by the user, automatically, software, or by a validator. When the user performs the process, the funds reflect immediately on the user’s balance. In the other cases, the funds will be available in 432,000 blocks (~ 30 days).

Keep in mind that validators are fined for poor quality or incorrect work. Therefore, the number of delegated coins is likely to decrease depending on the number of fines.

Rewards are credited every 120 blocks. The amount of the reward is dependent on different factors including the number of delegated coins, the number of validators, the total amount of stakes, the size of the basic block reward, and slashes imposed.

Block structure

A block in the blockchain contains service information such as user transactions, validator signatures, WUSD issuance transactions, commissions, and the hash of the current and previous block.

Generation of blocks occurs every 5.5–6 seconds in Work Net blockchain. Each block contains 0–10,000 transactions with about 180 bytes each.

Depending on the emission model, it will determine the rewards of a block starting with fifty WUSD followed by a subsequent increase every 432,000 blocks (- 30 calendar days).

Data Structure

The block includes the following list of basic data types:

• Block
• Title (Header)
• Version
• Block Identifier (BlockID)
• Time
• Data (for transactions)
• Confirmations and votes (Commit and Vote)
• Evidence Data and Evidence

Header

A block header comprises metadata about both the block and the consensus. Also, it includes data confirmation in the current and previous block as well as the result returned by the application.

Transactions

A list of transactions comprises data, which arbitrary byte arrays.

Make sure to subscribe to our channels:

Website
Twitter
Telegram group
Telegram announcements