cyberway_wallet wallet description is designated to developers of CyberWay platform and applications running on CyberWay platform, as well as users of Golos blockchain interested in maintaining and contributing to Golos application functioning on CyberWay platform.cli_wallet application can be called in daemon mode by specifying the option –rpc-endpoint in the command line. The cli_wallet processes json-rpc requests when launched in this mode. The cli_wallet responses are also generated in the JSON format.cli_wallet, but adapted to the CyberWay architecture. This wallet should allow Bittrex to interact with Golos application on the CyberWay blockchain.cli_wallet. To support the interface with the cli_wallet application, Bittrex Exchange uses a proprietary special shell.cli_wallet is a wrapper around Golos blockchain libraries. Adaptation of this application to another architecture (for example, to CyberWay) is not possible.cleos wallet, which is CyberWay’s blockchain wallet, is architecturally different. This wallet should be universal for all CyberWay blockchain applications and embedding a protocol in it (similar to cli_wallet) for the Exchange may cause problems in the future. Adapting the cleos wallet to the cli_wallet protocol is also a technically complex decision.cyberway_wallet) which provides the interaction of the Bittrex Exchange with Golos running on CyberWay blockchain must meet the following requirements:cyberway_wallet with Bittrex must correspond to the Bittrex cli_wallet interface;cyberway_wallet wallet should provide filter to support retrieving of the transaction history;cyberway_wallet should provide reception, processing of the requests and output of results in JSON formatcyberway_wallet should function in the remote call mode using the API. cyberway_wallet must support a list of operations listed in section 6 (support of other operations in the first version of CyberWay is not provided).cyberway_wallet wallet is implemented as an application containing a set of scripts on nodejs. The application logic is an emulation of the cli_wallet wallet. As well as in cli_wallet, remote procedure calls from Bittrex in JSON format are sent to the rpc-port. The request contains the necessary array of parameters to perform a specific operation. Operations are performed as if they were executed in the console.cli_wallet and cyberway_wallet applications, as well as the interactions of the cyberway_wallet with the components of the blockchain nodes is shown in fig.1cli_wallet, Bittrex and Golos daemon (Golosd) is pictured at the top of the fig.1 (highlighted with a red dotted line). The lower part of the scheme represents a technical solution for cyberway_wallet implementation on CyberWay blockchain. The highlighted parts of the scheme in red speak of the new CyberWay components that comprise the wallet.cyberway_wallet accepts the request and forms a transaction with transfers included. The generated transaction is transferred to one of the nodeos services where it gets verified for its validity. Also, there is an event engine in nodeos service which is responsible for generating events. The blocks and transactions come to it from the network. Parsing happens here, as well as the formation of events and a meta-block, which compounds all the resulting information.cyberway_wallet receives a formed meta-block from the nodeos component through the Event Engine port — a CyberWay node plug-in creating packages in JSON format and sending them to its subscribers. The logic of cyberway_wallet extracts only transfer data from the received meta-block and stores them in a database in the transaction history table (important: the formed transaction is not instantly saved with the transfer operation in history, only after it’s gone to the network and emerged in one of the blocks signed by the producer block; the latter means that this transaction is valid and can be saved in data base). The information about transactions and transfer operations included in specific blocks and stored in the transaction history is crucial to Bittrex. Bittrex is regularly accessing transaction history in order to obtain the information about the transfers performed.transfer request with the account name and the number of funds desired to be transferred. The request goes to the rpc-port of the cyberway_wallet wallet. A transaction is formed in the wallet with a ‘transfer’ operation, the name of the account and its signature. The generated transaction is sent to the nodeos component, where basic data verification is performed including checking of an account presence and a signature match. The nodeos component receives all the information necessary to perform the verification from the state system database.nodeos to Event Engine port, the application cyberway_wallet extracts the transaction information from it and identifies the block in which it is located, and saves the received data to the transaction history table.cyberway_wallet to get transaction history. Using the specified key in the transaction, the Bittrex Exchange determines the user account in the database from which funds have come to the exchange balance.info operation is used to extract the information about a block. The operation signature is the following:info operation has no input parameters. The list of information received:
virtual_supply — virtual supply;
current_supply — current supply;
verage_block_size — average block size;
maximum_block_size — maximum block size;
last_irreversible_block_num — the last non-reversible block number;
hardfork_version — blockchain version;
head_block_num — current block number;
head_block_id — block identifier;
head_block_age — a block’s lifetime (in seconds).transfer operation is used when transferring the funds from one account’s wallet to the wallet of another. The operation signature is the following:from — the name of the sender account from which the funds will be transferred;
to — the name of the recipient account;
amount — the amount of funds transferred;
memo — transaction record, encrypted with the public «memo» key;
broadcast — true if the transaction is sent to the daemon.list_accounts operation serves to get a list of all the accounts ever registered in the blockchain. The operation signature is:lowerbound — the name of the first account returned. If there is none, the list will begin with the very first name followed by lowerbound;
limit — a value that limits the number of account names displayed on the monitor. The maximum value is 1000.lowerbound andlimit parameters allows you to have a page in the best viewable form. It is recommended to set first the value of lowerbound as an empty string (“”) to review the entire list of account names. Also, the last account name returned for the next call to list_account() should be transmitted to lowerbound parameter at each iteration. It helps to returns a list of all account names registered in the blockchain with their corresponding identifiers. The list is filtered by name in an alphabetical order.list_my_accounts operation is used to retrieve account information using the private key in the wallet. Please note that the wallet must be pre-unlocked. The operation has no input parameters. The operation signature is:import_key is used for a public private key in WIF format. The operation signature is the following:wif_key — private key in WIF format.get_account_history operation is used to get the transaction history for an account. The operation signature is the following:account — the name of the account whose history is being requested;
from — the serial number of the operation. The parameter is arbitrary and it’s default value is «-1» — the last operation number;
limit — the maximum number of operations requested. The value spans from 0 to 1000. The parameter is arbitrary and it’s default value is «100».get_account_history operation call:filter_account_history operation is used when retrieving the transaction history for an account filtered by certain attributes. The operation signature is the following:account — the name of the account whose history is being requested; from — the serial number of the operation. The parameter is arbitrary and it’s default value is «-1» — the last operation number; limit — the maximum number of operations requested. The value spans from 0 to 1000. The parameter is arbitrary and it’s default value is «100». query — parameter is a structure (object) and contains the following fields:cyberway_wallet test launch on the operations mentioned in section 6 showed that the implemented technical solution ensures the functioning of cyberway_wallet in accordance with the requirements of section 3.