{
  "trx_id": "6e1de04ffe5d14e3c3e2c74696266e9f287440e2",
  "block": 66899973,
  "trx_in_block": 2,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2022-08-18T03:47:06",
  "op": [
    "transfer",
    {
      "from": "ph-support",
      "to": "golos",
      "amount": "0.001 STEEM",
      "memo": ""
    }
  ]
}

{
  "trx_id": "7aa5b3d2d5a23b814f27bfe02f5b33a6780f93d3",
  "block": 66869587,
  "trx_in_block": 3,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2022-08-17T02:17:57",
  "op": [
    "transfer",
    {
      "from": "ph-support",
      "to": "golos",
      "amount": "0.001 STEEM",
      "memo": ""
    }
  ]
}

{
  "trx_id": "1554f2c49702dca661cfb3f1b4945c337509cf3e",
  "block": 36496510,
  "trx_in_block": 30,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-09-17T09:14:00",
  "op": [
    "vote",
    {
      "voter": "cyberwaydev",
      "author": "golos",
      "permlink": "cyberway-need-for-new-platform",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "1a6904be74dd7fd7b1650fe02063a0ff6e6f7e4d",
  "block": 36494903,
  "trx_in_block": 0,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-09-17T07:53:24",
  "op": [
    "vote",
    {
      "voter": "marina",
      "author": "golos",
      "permlink": "golos-transit-migration-process-to-cyberway-described",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "905377fef2b05c0ed0f45bcba4795260ca825b0e",
  "block": 36469967,
  "trx_in_block": 27,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-09-16T11:04:21",
  "op": [
    "vote",
    {
      "voter": "jekon80",
      "author": "golos",
      "permlink": "golos-transit-migration-process-to-cyberway-described",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "0230737010a029bff900cc4dadfc06d949b1f983",
  "block": 36469967,
  "trx_in_block": 22,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-09-16T11:04:21",
  "op": [
    "vote",
    {
      "voter": "artem.timofeev",
      "author": "golos",
      "permlink": "golos-transit-migration-process-to-cyberway-described",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "2676c878647d41ecefb31c681b70c712f92dc1f3",
  "block": 36469964,
  "trx_in_block": 25,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-09-16T11:04:12",
  "op": [
    "vote",
    {
      "voter": "honeythief",
      "author": "golos",
      "permlink": "golos-transit-migration-process-to-cyberway-described",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "f88bf8ca6561f288a9faf5c8d5c2840fe1e12f5f",
  "block": 36469906,
  "trx_in_block": 51,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-09-16T11:01:12",
  "op": [
    "vote",
    {
      "voter": "millibot",
      "author": "golos",
      "permlink": "golos-transit-migration-process-to-cyberway-described",
      "weight": 5000
    }
  ]
}

{
  "trx_id": "75a0acdc7d1fb161b3b3578e842118efab07f823",
  "block": 36469864,
  "trx_in_block": 6,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-09-16T10:59:03",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "cyberway",
      "author": "golos",
      "permlink": "golos-transit-migration-process-to-cyberway-described",
      "title": "Golos transit (migration) process to CyberWay described",
      "body": "# Golos transit (migration) process to CyberWay took place Aug 15th 2019!\nhttps://telegra.ph/file/2b5d5698c5fa28b3cd21e.jpg\n\n**Dear Golos users! Golos Core team had been working so hard on making this happen over the past few months. Not to mention the sleepless nights and tons of code - it all made sense, we’re so immensely happy it happened.**\n\nBy no means, the creation of CyberWay, a new blockchain platform based on EOS logic, will leave a memorable mark in the entire blockchain history. We did not simply launch the blockchain but we transferred an entire Golos blockchain history that spans almost 3 years to CyberWay blockchain to ensure the new technological path for Golos that was supported by stakeholders on the referendum (https://steemit.com/golos/@golos/referendum-results) held in April. We are immensely proud to be a part of such a large-scale event!\n\nAs you may know, the transit itself was carried out according to step-by-step instructions given in our [validators’ manual] (https://golos.io/cyberway/@goloscore/rukovodstvo-dlya-delegatov-po-tranzitu-blokcheina-golos). \n0.21.0 HardFork version was installed before the actual transit on the nodes of most Golos witnesses, allowing them to commit to the process of voting.\n\nEach Golos witness had to take a crucial step of advocating on the direction of further Golos blockchain development. Meaning taking a pace of supporting the decision of the majority of Golos stakeholders, recorded at the April 2019 referendum (i.e.voting for the sake of further Golos development considering the brand new technological basis of CyberWay protocol) either speaking out against the majority of stakeholders’ will. \n\nIt was necessary to collect at least 16 out (of 19 top witnesses) for the sake of correspondence to the fact that 75% of witnesses need the confirmation in order to advance the finalizing block of the chain: 16/21 = 76.19%). We were excited to receive the results as the vocalized majority promptly did vote for transit. Within the first hour and a half after launching the voting process, 16 witnesses have confirmed their transit support. \n\nWe’re so grateful for those indifferent ones who joined the Golos stakeholders discussions and portrayed a commitment in in-depth understanding of CyberWay blockchain developed by Golos Core team.\n\nThe following 16 top witnesses (listed below in alphabetical order) voted for the migration of the Golos to CyberWay chain: **@creator, @denis-skripnik, @dmilash, @goloscore, @golosio, @kuna, @ladyzarulem, @lex , @primus, @ropox, @steepshot, @stihi-io, @vik, @vvk, @yudina-cat, @xtar.**\n\nAs soon as the votes of 16 witnesses were received, preparations for the actual transit has started (such as terminating the Golos blockchain nodes).\n\nThe 29585430 block has shaped the CyberWay genesis https://github.com/cyberway/cyberway.launch/blob/master/genesis.json#L28 (\"initial_chain_id\": \"00000000000000000000000001c37016e410f925f188401ea072b29e0d27a382\")\n\n**meaning it has initialized the process of data migration to CyberWay chain and became the Golos chain assignee.**\n\nAt that particular instance the main branch of Golos blockchain has quit the Golos tokens emission also blocking the inclusion of new transactions in generated blocks these it would become possible to initialize these processes within the Golos application at the very start of CyberWay chain.\n\nLast Irreversible Block was indicated at the 29586410 block, thereby fixing the procedure of migration from the Golos to CyberWay blockchain.\n\nGraphene library lays in the basis of both Golos and CyberWay blockchains (although it’s generations are slightly different).\n\nThe 2.4 Graphene in Golos blockchain allows two or more blockchain branches of an alternative transaction history (with the same network identifier) to coexist. Each alternative branch advocates the finalizing block (LIB) in accordance with the consensus reached in the particular block branch. However, this usually leads to a node operating problem in individual chain since they tend to switch to the less suitable branch. To sidestep this issue,  nodes supporting an alternative transaction history need to change their chain_id.\n\nAn alternative block history fork was being handled by Golos Classic team (supporters of Golos development on Steam source code base) after voting process by the required number of delegates. \nTwo branches with the same network identifier formed in the same network, so that originally the blockchain node struggled to determine the main network chain. This peculiarity made it difficult to achieve the genesis for CyberWay blockchain. Consequently, the generation of the genesis files was completed at 16:37 PM Moscow time (UTC +3). According to this, the chain was finally launched in 3 minutes, at 17:00 PM.\n\nThe initial production of blocks schedule of CyberWay chain was predominantly formed by the witnesses of Golos blockchain who were first to install the software for CyberWay validators. It includes @nickshtefan, @creator, @goloscore, @golosio, @vik, @kuna, @ropox.\n\nFinal genesis files were published in the public domain at 17:00 Moscow time, in other words, CyberWay blockchain started at this momentum.\n\nCyberWay blockchain genesis is based on the system state data of the Golos blockchain, recorded at the time of the actual transition which allows to consider CyberWay platform as the successor of Golos blockchain. This fact was recorded in the genesis (see ‘initial_chain_id’ which coincides with the Golos block identifier on which the voting for migration was finalized).\n\nNot to mention, **anyone is capable of duplicating the procedure for generating genesis from Golos blockchain into CyberWay blockchain**\n\nIn the meanwhile, CyberWay blockchain is successfully functioning with the repository of the following validators:\n**@ladyzarulem, @anyx, @nickshtefan, @creator, @arcange, @ stihi-io, @goloscore, @kulturagolosa, @steepshot, @dmilash, @ denis-skripnik, @golosio, @mommo, @vik, @kuna, @ lex, @ropox, @xtar.**\n\nWe’d love to spread our gratitude out to all Golos users since Aug 15th event can be considered pioneering in the blockchain history.\n\nThank you to everyone who cares about both Golos and CyberWay, who had been no indifferent to our biweekly reports, left their feedback and believed that we will nail it!\nWe’re proud to be working on CyberWay shoulder to shoulder with the Golos IO dev team. It was such an honorable experience!\n\nP.S. Last but not least, we wish all the best to Golos classic blockchain which has managed to separate independently from the major Golos chain!",
      "json_metadata": "{\"tags\":[\"cyberway\",\"blockchain\",\"applications\",\"decentralization\"],\"users\":[\"creator\",\"denis-skripnik\",\"dmilash\",\"goloscore\",\"golosio\",\"kuna\",\"ladyzarulem\",\"lex\",\"primus\",\"ropox\",\"steepshot\",\"stihi-io\",\"vik\",\"vvk\",\"yudina-cat\",\"xtar\",\"nickshtefan\",\"anyx\",\"arcange\",\"kulturagolosa\",\"mommo\"],\"image\":[\"https://telegra.ph/file/2b5d5698c5fa28b3cd21e.jpg\"],\"links\":[\"https://steemit.com/golos/@golos/referendum-results\",\"https://golos.io/cyberway/@goloscore/rukovodstvo-dlya-delegatov-po-tranzitu-blokcheina-golos\",\"https://github.com/cyberway/cyberway.launch/blob/master/genesis.json#L28\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "c7865b768fa37d7a4965dbe856a81c9172036181",
  "block": 36225341,
  "trx_in_block": 5,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-09-07T22:33:06",
  "op": [
    "comment",
    {
      "parent_author": "golos",
      "parent_permlink": "golos-blockchain-transit-migration-a-witness-guide",
      "author": "steemitboard",
      "permlink": "steemitboard-notify-golos-20190907t223305000z",
      "title": "",
      "body": "Congratulations @golos! You received a personal award!\n\n<table><tr><td>https://steemitimages.com/70x70/http://steemitboard.com/@golos/birthday3.png</td><td>Happy Birthday! - You are on the Steem blockchain for 3 years!</td></tr></table>\n\n<sub>_You can view [your badges on your Steem Board](https://steemitboard.com/@golos) and compare to others on the [Steem Ranking](https://steemitboard.com/ranking/index.php?name=golos)_</sub>\n\n\n###### [Vote for @Steemitboard as a witness](https://v2.steemconnect.com/sign/account-witness-vote?witness=steemitboard&approve=1) to get one more award and increased upvotes!",
      "json_metadata": "{\"image\":[\"https://steemitboard.com/img/notify.png\"]}"
    }
  ]
}

{
  "trx_id": "29822157d8b4b2a2363c76bf6405a645a262f7a0",
  "block": 35634088,
  "trx_in_block": 45,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-08-17T14:51:18",
  "op": [
    "vote",
    {
      "voter": "smotritelmayaka",
      "author": "golos",
      "permlink": "golos-blockchain-transit-migration-a-witness-guide",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "9010a47238134b3a5e9f72fc465a2f595306ad72",
  "block": 35557064,
  "trx_in_block": 10,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-08-14T22:33:45",
  "op": [
    "vote",
    {
      "voter": "marina",
      "author": "golos",
      "permlink": "golos-blockchain-transit-migration-a-witness-guide",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "992b50d0ce80c51245d69057b48b9a5338f0fa0a",
  "block": 35555501,
  "trx_in_block": 42,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-08-14T21:15:30",
  "op": [
    "vote",
    {
      "voter": "nin4i",
      "author": "golos",
      "permlink": "golos-blockchain-transit-migration-a-witness-guide",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "4ba31812c2a989441b967898fddefb8a17f7b331",
  "block": 35543943,
  "trx_in_block": 8,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-08-14T11:36:30",
  "op": [
    "vote",
    {
      "voter": "chugoi911",
      "author": "golos",
      "permlink": "golos-blockchain-transit-migration-a-witness-guide",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "c5b04d77da7c199b78af45b66c56d1223b4f0201",
  "block": 35541161,
  "trx_in_block": 3,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-08-14T09:17:18",
  "op": [
    "vote",
    {
      "voter": "pinoy",
      "author": "golos",
      "permlink": "referendum-results",
      "weight": 1000
    }
  ]
}

{
  "trx_id": "5efe33f6093330a243af3f7d78d26560505a8283",
  "block": 35541035,
  "trx_in_block": 12,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-08-14T09:11:00",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "cyberway",
      "author": "golos",
      "permlink": "golos-blockchain-transit-migration-a-witness-guide",
      "title": "Golos blockchain transit (migration) - A witness' guide",
      "body": "# Golos blockchain transit (migration)\n## A witness’ guide\n\nThis guide provides generic, practical advice for witnesses of Golos blockchain for migration from Golos blockchain to Golos application running on top of CyberWay. The manual contains information about transit procedure as well as actions necessary to be taken by Golos witnesses, which ensure voting nd launch of CyberWay with the data taken from Golos blockchain.\n\n## Description of the Golos blockchain transit procedure\n\nThe transit procedure starts immediately upon the completion of 0.21.0 Hardfork and includes the following steps:  \n   * Voting for transit by Golos witnesses\n   * Snapshot dump of Golos system state from witnesses’ nodes.\n   * Golos chain work termination.\n   * Genesis file generation.\n   * CyberWay launch with data from Golos chain.\n   * Installation and deployment of Golos application.  \n\nThe fundamental condition for successful completion of the transit is that Golos application is installed and successfully deployed in CyberWay environment.  \n\n### Witnesses’ Voting for Transit \n\nAfter 0.21.0 Hardfork acceptance and by the moment of the actual beginning of transit (August 15th 2019 at 12 noon Moscow time), Golos witnesses will get access to the voting operation. Each Golos witness has to make a decision concerning the transit and send a transaction signed with his/her own key.  \n\nConsensus will be considered achieved if the number of witnesses who have agreed to transit is at least 16 out of the top 19 witnesses. As soon as consent transaction is received from the 16th witness and put into the last irreversible block (abbr., LIB), the voting process will be completed and the transaction containing the voting results will be sent to the block log.  \n\nAt that instant the witnesses voting procedure for transiting Golos to CyberWay blockchain will be considered successfully completed.  \n\n\n### Golos State Snapshot \n\n\nIf 16 Golos witnesses vote positively for transit, the script https://github.com/cyberway/golos.transit/blob/master/transit.sh will begin to run. All further transit procedures will be performed automatically.  \n\nThe procedure for taking a dump snapshot of Golos system state will be launched. Data files will be created to save a fixed state of Golos blockchain (system state) on those nodes in which the directories for uploading system state data are set in the configuration file.\n\n### Golos Termination \n \nGolos network will continue to produce empty blocks for the time set in the settings straight after receiving the transaction with the final consent of the 16th witness’, so that this transaction would fall into the LIB block on other witnesses’ nodes. However, during this cycle, the network will not process transactions and, consequently, operations such as publishing posts and comments, transferring funds, putting “likes”, etc. will not be performed. Emission and token transfer operations will also be stopped. This allows to register LIB block with consent to transit from the 16th witness on all nodes of the Golos blockchain.\n  \n \n### Genesis File Generation\n\n`Сreate genesis` utility generates a genesis file - the initial data for launching CyberWay - with the data taken during snapshot from Golos blockchain. This utility transfers all the information necessary to restart a paused chain on CyberWay and deploy Golos application. `Create genesis` utility will deliver the data from all the accounts, balances, open posts, etc. (i.e. Golos system data) to the new environment.  \n\nThe genesis generated by Golos Core team will be available via the link specified in the `genesis_data.link` file in [cyberway.launch github](http://github.com/cyberway/cyberway.launch) repository. `Genesis.info` file will be placed in the very same repository with a full description of the genesis parameters.  \n\n### CyberWay Launch\n\nCyberWay chain will be launched on the witnesses’ nodes which voted for the transit and, respectively, became validators on CyberWay. Before starting the chain the nodes must form a network. The connection will occur through seed nodes. The file with the seed nodes ip-addresses will be saved in [cyberway.launch github](http://github.com/cyberway/cyberway.launch) repository. As soon as the number of nodes connected by ip-address reaches the value specified in the genesis parameter CyberWay chain will be launched with all Golos blockchain data and the production of blocks will begin.  \n\n`Emit` pending transaction will be executed one hour after starting CyberWay, which will initiate the procedure of closing the posts.  \n\n## CyberWay Validator Node Requirements\n\nThe following hardware characteristics must be met for future CyberWay nodes:  \n   * Disk space amount - (at least) 80 GB;\n   * RAM memory - (at least) 16 GB.  \n\nThe nodes must have one of the following operating systems installed:  \n   * Ubuntu (versions recommended: 16.04 or 18.04);\n   * MacOS Darwin 10.12 (or later);\n   * Centos 7;\n   * Fedora 25 (or advanced);\n   * Mint 18.  \n\nThe following software must be installed on the nodes:\n   * docker;\n   * docker-compose.  \n \n\n## Sequence of Actions to be Taken by Witnesses\n\n### Installing the HF-0.21.0 Version to the Node\n\nThe installation procedure on the HF-0.21.0 node is similar to the installation procedure of previous versions and can be performed using the [HF-18 Installation Guide](https://github.com/GolosChain/golos/wiki/Build-instruction).  \n\nAttention! A replay of the chain is required as a must upon the completion of HF-0.21.0 installation.  \n\n> ** Note: **  \n> Witnesses not willing to support the transit decision made at the [referendum](https://steemit.com/golos/@golos/referendum-results) must not take any action. ** Non-participation is interpreted as voting “AGAINST.” **  \n> Witnesses approving the decision of the [referendum](https://steemit.com/golos/@golos/referendum-results) must vote. ** Participation is interpreted as voting \"FOR\". **\n\n\n### Voting for Transit\n\n*Attention! By following the instructions in this paragraph you vote for the transit and initiate the transit procedure automatically!*  \n\nAccess to `cyberway.launch` repository will open upon completion of the installation of HF-0.21.0 and the beginning of transit (12-00 Moscow time, August 15, 2019). Both auxiliary scripts and CyberWay launch data will be placed in this repository.  \n\n### Witnesses must initiate the transit procedure in any preferable way\n\n**Option_1**  \n\nWitnesses willing to complete the transit procedure using the genesis data generated directly on their node must:\n  * upload the contents of the `cyberway.launch` repository to the node using the command\n```\n       git clone https://github.com/cyberway/cyberway.launch.git\n```\n  * provide the following conditions:  \n    * Golos application must be installed in the docker container and the image name must remain as `golos-default`;\n    * The configuration file should be moved to /etc/golosd/config.ini;\n    * The contents of Golos application directory should be moved to /var/lib/golosd.\n  * run the script `start_check_state.sh`.  \n \nThe script mentioned above initiates the following processes:  \n  * Voting procedure;\n  * Waiting for network termination;\n  * Formation of genesis procedure;\n  * CyberWay launch with the genesis data.  \n\nThe option_1 transit procedure will be considered successfully completed if and only if:\n  * CyberWay environment has been installed in the docker container;\n  * /etc/cyberway/config.ini configuration file has been created;\n  * /var/lib/cyberway directory for storing data has been created;\n  * All the tcp-ports necessary are being ported.  \n\n> ** Note: **  \n> Transit wise it’s necessary that the node characteristics must comply with the requirements given in the subsection [Requirements for validator nodes](#cyberway-validator-node-requirements) .  \n\n**Option_2** (recommended)  \n\nWitnesses willing to complete the transit procedure using the genesis data generated by Golos Core team (i.e. with the minimum number of actions required):  \n\n  1) upload the contents of the `cyberway.launch` repository to the node using the command\n```\n        git clone https://github.com/cyberway/cyberway.launch.git\n```\n\n  2) vote either with `cli_wallet`\n```\n        cli_wallet transit_to_cyberway <witness’ account> true\n```\n\nor using a script call  \n```\n         sudo ./transit.sh transit-approve\n```\n 3) run the `start_light.sh` script  \n\nThe option_2 transit procedure will be considered successfully completed if and only if:  \n  * CyberWay environment has been installed in the docker container;\n  * /etc/cyberway/config.ini configuration file has been created;\n  * /var/lib/cyberway directory for storing data has been created;\n  * All the tcp-ports necessary are being ported.  \n\nWitnesses that install CyberWay on a separate server must perform the following steps  \n  * both 1) and 2) on the old node  \nand  \n  * both 1) and 3) on the server where CyberWay is installed.  \n\n\n## Sequence of actions to be taken by users who are not among the former Golos witnesses but are willing to become CyberWay validators \n\nUsers inclined to install CyberWay on their server and join the CyberWay blockchain must run the `start_light.sh` script taken from `cyberway.launch repository`.\n\n> ** Note: **  \n> Transitwise it’s necessary that the node characteristics must comply with the requirements given in the subsection [Requirements for validator nodes](#cyberway-validator-node-requirements) \n\n\n\n## Communication\n\nCommunication at the time of the transit will be conducted via two mediums:  \n\n  * [CyberWay_Validators](https://t.me/cyberway_validators) - a chat for feedback and information exchange between our dev team and the validators\n  * [CyberWay Launch Updates](https://t.me/joinchat/AAAAAFBrnD_sLTXlWw3lJg) - a channel to coordinate actions at the command execution level.",
      "json_metadata": "{\"tags\":[\"cyberway\",\"blockchain\",\"golos\",\"technology\",\"cosmos\"],\"links\":[\"https://github.com/cyberway/golos.transit/blob/master/transit.sh\",\"http://github.com/cyberway/cyberway.launch\",\"https://github.com/GolosChain/golos/wiki/Build-instruction\",\"https://steemit.com/golos/@golos/referendum-results\",\"#cyberway-validator-node-requirements\",\"https://t.me/cyberway_validators\",\"https://t.me/joinchat/AAAAAFBrnD_sLTXlWw3lJg\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "bc24e2a533df989b9b4ed4357fdb86c3610b8311",
  "block": 35540859,
  "trx_in_block": 2,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-08-14T09:02:12",
  "op": [
    "vote",
    {
      "voter": "yehey",
      "author": "golos",
      "permlink": "referendum-results",
      "weight": 1000
    }
  ]
}

{
  "trx_id": "13ac30361cdbeee9b8319ce12033a2d60b8c9ea0",
  "block": 35540455,
  "trx_in_block": 10,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-08-14T08:42:00",
  "op": [
    "vote",
    {
      "voter": "steemfond",
      "author": "golos",
      "permlink": "referendum-results",
      "weight": 490
    }
  ]
}

{
  "trx_id": "d8eac49c27ce2217a643c4fc91ff6876932b6b90",
  "block": 35540155,
  "trx_in_block": 21,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-08-14T08:27:00",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "golos",
      "author": "golos",
      "permlink": "referendum-results",
      "title": "Referendum results",
      "body": "**This post is a translation of the original @goloscore post via @golos dated by 22nd of April 2019:\nhttps://golos.io/transit/@goloscore/rezultaty-referenduma-po-voprosu-tranzita-na-cyberway**\n\nDear Golos community members!\n\nApril 21, at 9.07 a.m. Moscow time, the voting on the transit of Golos blockchain to CyberWay blockchain came to an end.\n\nWe are honored to have activity demonstrated by users and stackers of the platform. With a turnout of 53.76%, the decision to transit to CyberWay was supported by 53.52% of the voters.\n\nWe express our gratitude to everyone who had examined the materials presented earlier (posts, instructions, manuals, etc.) and portrayed his/her indifference in regards to platform’s destiny expressing their opinion - for or against the transition.\n\nWe kindly remind you that the issue of moving the current Golos to the CyberWay blockchain with the launch of Golos application on it was put to the vote. The reasoning for the proposed solution consisted of the following:\n\n* the technical imperfection of the current blockchain;\n* blockchain and client technical inseparability;\n* inflexibility in terms of changing the codebase;\n* an economic model that does not contribute to the growth of the value of the platform;\n* the inability to create different applications with different tokens;\n* low competitiveness compared to the other blockchains that allow you to create applications on smart contracts.\n \nThe wording of the question proposed for the referendum was as it follows:\n\n“Do you support the transit of Golos classic blockchain to the CyberWay blockchain with the launch of Golos application with the distribution of tokens proposed and the simultaneous cancellation of nodes of Golos classic?”\n\nIt was proposed to consider the decision as supported by the community if user accounts voted for it, at the time of the end of voting at least 50% + 1 token of the platform’s voting stack would be voted on it, provided that token holders would participate in at least 50% of the total stack platforms (minimum turnout).\n\nIt was proposed to consider the stack of user accounts as the aggregate stack of the platform, with the exception of active exchange accounts (@bittrex, @kunaio, @rudex, @livecoin). In order to calculate the mentioned stack, all tokens were derived from the Golos - GBG, SG - were converted to GOLOS tokens.\n\nThe holders of Golos tokens with at least 0.001 GOLOS amount listed on their balance participated in the vote (0.001 or less of Golos token have ~ 10190 accounts on their balance, of which ~ 7230 have zero balance). User accounts voted, with the exception of active exchange accounts (@bittrex, @kunaio, @rudex, @livecoin), including twins, accounts of bots, communities, organizations, and other private and collective accounts.\n\nThe voting technique was as follows - if the user supports the migration, he transferred 0.001 GOLOS to @golosvotingyes account; if he was against it, he transferred 0.001 GOLOS to @golosvotingno account (special technical accounts were created for this process by our team).\n\nA single user account was given an opportunity to vote once during the voting period set; tokens sent simultaneously to both technical accounts did not participate in the calculation. The revoting option was excluded.\n\nThe voting period was set to 10 calendar days - from April 12, 2019 (9:07 Moscow time, the time of the launch of the Vostok-1 spacecraft) to April 21, 2019 (9:07 Moscow time).\n \n \n**The results**\n\nTokens from 252 users were received on @golosvotingyes account, 252 accounts with a total stack of 53.52% voted.\nTokens from 33 users were received on @golosvotingno account, 33 accounts with a total stack of 0.24% voted.\nThus, holders of Voice tokens with a stack of 53.52% voted in favor of transit. “Against” - 0.24%. The total turnout was 53.76%. The decision to transit to CyberWay is considered to be supported and accepted.\n\nThank you to everyone who participated in the referendum. We recognize that each user had their own reasons for voting - however, the community has shown its active position.",
      "json_metadata": "{\"tags\":[\"golos\",\"transit\",\"cyberway\"],\"users\":[\"goloscore\",\"golos\",\"bittrex\",\"kunaio\",\"rudex\",\"livecoin\",\"golosvotingyes\",\"golosvotingno\"],\"links\":[\"https://golos.io/transit/@goloscore/rezultaty-referenduma-po-voprosu-tranzita-na-cyberway\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "0000000000000000000000000000000000000000",
  "block": 34136330,
  "trx_in_block": 4294967295,
  "op_in_trx": 0,
  "virtual_op": 4,
  "timestamp": "2019-06-26T11:52:45",
  "op": [
    "author_reward",
    {
      "author": "golos",
      "permlink": "cyberway-understanding-cliwallet",
      "sbd_payout": "0.015 SBD",
      "steem_payout": "0.000 STEEM",
      "vesting_payout": "75.611033 VESTS"
    }
  ]
}

{
  "trx_id": "5da9ab0b98ace8e989bb2887c7775b1c59486d88",
  "block": 33977942,
  "trx_in_block": 2,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-06-20T23:44:06",
  "op": [
    "vote",
    {
      "voter": "meedo",
      "author": "golos",
      "permlink": "cyberway-understanding-cliwallet",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "9bc18453462744e855df5f413228e16d977579df",
  "block": 33943356,
  "trx_in_block": 35,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-06-19T18:53:03",
  "op": [
    "vote",
    {
      "voter": "serejandmyself",
      "author": "golos",
      "permlink": "cyberway-understanding-cliwallet",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "65457dfcfae7b7acbb76b0e0c14a36133779e37d",
  "block": 33935290,
  "trx_in_block": 9,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-06-19T12:09:33",
  "op": [
    "comment",
    {
      "parent_author": "golos",
      "parent_permlink": "cyberway-understanding-cliwallet",
      "author": "sames",
      "permlink": "sames-re-golos-cyberway-understanding-cliwallet-20190619t120933376z",
      "title": "",
      "body": "hmm...\n\nPosted using [Partiko Android](https://partiko.app/referral/sames)",
      "json_metadata": "{\"app\":\"partiko\",\"client\":\"android\"}"
    }
  ]
}

{
  "trx_id": "afd767b911e27aaab7e2561b95f55b281f3ad45a",
  "block": 33935062,
  "trx_in_block": 16,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-06-19T11:58:09",
  "op": [
    "vote",
    {
      "voter": "bukiland",
      "author": "golos",
      "permlink": "cyberway-understanding-cliwallet",
      "weight": 100
    }
  ]
}

{
  "trx_id": "eb1600ceb9e4799a83fdae32e7f1abf542cb6037",
  "block": 33935060,
  "trx_in_block": 33,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-06-19T11:58:03",
  "op": [
    "vote",
    {
      "voter": "artem.timofeev",
      "author": "golos",
      "permlink": "cyberway-understanding-cliwallet",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "8a782978973af60f4aac53f44187dfc5376b48e4",
  "block": 33935060,
  "trx_in_block": 25,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-06-19T11:58:03",
  "op": [
    "vote",
    {
      "voter": "jekon80",
      "author": "golos",
      "permlink": "cyberway-understanding-cliwallet",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "3c3b209bd00af269c1ae19774c13ac9c84629d14",
  "block": 33935057,
  "trx_in_block": 31,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-06-19T11:57:54",
  "op": [
    "vote",
    {
      "voter": "honeythief",
      "author": "golos",
      "permlink": "cyberway-understanding-cliwallet",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "cbafb1b337a875583fe98b79bca3bee56bc954c5",
  "block": 33935033,
  "trx_in_block": 13,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-06-19T11:56:42",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "cyberway",
      "author": "golos",
      "permlink": "cyberway-project-roadmap",
      "title": "CyberWay: Project RoadMap",
      "body": "@@ -1615,14 +1615,15 @@\n %0A%0A!%5B\n-%D0%9F%D0%BE%D1%81%D1%82_1\n+RoadMap\n -Fig\n@@ -1667,79 +1667,60 @@\n /DQm\n-VWmyAt6yJok77G9P6rFHpY8hwZH1SKYD3912QxqeBjeJ/%25D0%259F%25D0%25BE%25D1%2581%25D1%2582_1\n+S4UzkSnvBDQDssE63rGLqdNAhphoCsp9GGcQAz5VuDn6/RoadMap\n -Fig\n",
      "json_metadata": "{\"tags\":[\"cyberway\",\"golos\",\"blockchain\",\"eos\",\"roadmap\"],\"image\":[\"https://cdn.steemitimages.com/DQmS4UzkSnvBDQDssE63rGLqdNAhphoCsp9GGcQAz5VuDn6/RoadMap-Fig_1.jpg\",\"https://cdn.steemitimages.com/DQmWuB5hGVm9jGBAHRo7vRxP4W6cN5yqZxVd2gngiZbZL81/Product%20Roadmap_ENG.jpg\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "2ca7c9ab20e58fc726ef6b90037ad93b760604f2",
  "block": 33934958,
  "trx_in_block": 3,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-06-19T11:52:57",
  "op": [
    "vote",
    {
      "voter": "steeming-hot",
      "author": "golos",
      "permlink": "cyberway-understanding-cliwallet",
      "weight": 1
    }
  ]
}

{
  "trx_id": "c4ab2f8d3550f0f4f424d84bfd993d74a42653d9",
  "block": 33934954,
  "trx_in_block": 7,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-06-19T11:52:45",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "cyberway",
      "author": "golos",
      "permlink": "cyberway-understanding-cliwallet",
      "title": "CyberWay. Understanding cli_wallet",
      "body": "## Annotation\n* This 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. *\n \n## 1. Functional features of cli_wallet operating on Golos blockchain\nThe cli_wallet application used in Golos blockchain is a software product - i.e. a wallet running in an interactive console mode.  \n \nThe `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.\n\n## 2. The need to develop a new wallet for the CyberWay platform\nDue to transferring of Golos application to the new Blockchain, CyberWay, Golos  developers decided to create a new wallet for Bittrex Exchange, similar to `cli_wallet`, but adapted to the CyberWay architecture. This wallet should allow Bittrex to interact with Golos application on the CyberWay blockchain.\n\nThe main direction of the Bittrex cryptocurrency exchange is purchase and sale of cryptocurrencies. Bittrex Exchange stores account data and their balances in its own user base. Bittrex adapts its software to interact with various blockchains. In particular, Bittrex interacts with blockchains created on the basis of the Steemit/Golos logic through the application `cli_wallet`. To support the interface with the `cli_wallet` application, Bittrex Exchange uses a proprietary special shell.\n \nThe app `cli_wallet` is a wrapper around Golos blockchain libraries. Adaptation of this application to another architecture (for example, to CyberWay) is not possible.\n\nThe `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.\n\n## 3. New CyberWay wallet requirements\n\nThe new wallet (hereinafter named as `cyberway_wallet`) which provides the interaction of the Bittrex Exchange with Golos running on CyberWay blockchain must meet the following requirements:\n- the interface of the `cyberway_wallet` with Bittrex must correspond to the Bittrex `cli_wallet` interface`;\n- the user interface should be saved. Despite the fact that smart contracts and the wallet will interact with other transactions, the user mustn’t feel the difference while forming the request;\n- the `cyberway_wallet` wallet should provide filter to support retrieving of the transaction history;\n- the `cyberway_wallet` should provide reception, processing of the requests and output of results in JSON format\n- the `cyberway_wallet` should function in the remote call mode using the API.\n\nIn the first version of CyberWay blockchain, the application `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).\n\n## 4. Description of the technical solution\nThe `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.\nThe cli_wallet wallet can be used by sending an API request to the rpc port. The execution occurs in the automated mode.\nTo store information about transactions with transfer operations, the Mongo database is supplemented with a transaction history table.\n \nThe block diagram of the interactions of Bittrex with the `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.1\n\n![Fig_1.jpg](https://cdn.steemitimages.com/DQmdzyStsrbUVedSKeRLhyVyNVV49R8VBFT9CmEFNPU7Wn7/Fig_1.jpg)\n\nThe interaction between `cli_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.  \n \nThe application `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.  \n \nThe application `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.\n\n## 5 Description of the transfer operation while using cyberway_wallet\nThe Bittrex exchange allows the user to perform the exchange of tokens of one blockchain for tokens of another as well as to exchange blockchain tokens for any other cryptocurrency (e.g., bitcoins). In order to commit a transaction, a user proceeds to the Bittrex website and creates an operation to transfer funds from his wallet to the Bittrex wallet, specifying his key in the transaction. The bittrex logic generates a `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.  \n \nAs soon as the generated meta block containing the transaction with the transfer operation is sent to `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.  \n \nAll transfer operations are controlled when the Bittrex regularly contacts the database (Mongo) through `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.\n\n## 6 Operations supported by cyberway_wallet wallet in the first release of CyberWay\n### 6.1 Operation info\nThe `info` operation is used to extract the information about a block. The operation signature is the following:\n```cpp\nvariant wallet_api::info() const\n```\n \nThe `info` operation has no input parameters. The list of information received:  \n`virtual_supply` — virtual supply;  \n`current_supply` — current supply;  \n`verage_block_size` — average block size;  \n`maximum_block_size` — maximum block size;  \n`last_irreversible_block_num` — the last non-reversible block number;  \n`hardfork_version` — blockchain version;  \n`head_block_num` — current block number;  \n`head_block_id` — block identifier;  \n`head_block_age` — a block’s lifetime (in seconds).  \n\n\n### 6.2 Transfer operation\nThe `transfer` operation is used when transferring the funds from one account’s wallet to the wallet of another. The operation signature is the following:\n\n```cpp\nannotated_signed_transaction wallet_api::transfer (\nstring from,\nstring to,\nasset amount,\nstring memo,\nbool broadcast\n)\n```\n\nParameters:  \n`from` — the name of the sender account from which the funds will be transferred;  \n`to` — the name of the recipient account;  \n`amount` — the amount of funds transferred;  \n`memo` — transaction record, encrypted with the public «memo» key;  \n`broadcast` — true if the transaction is sent to the daemon.\n  \n\n \n \n### 6.3 List_accounts operation\nThe `list_accounts` operation serves to get a list of all the accounts ever registered in the blockchain. The operation signature is:\n```cpp\nvector< account_name_type > wallet_api::list_accounts(\nconst string& lowerbound,\nuint32_t limit\n) \n```\n\nParameters:  \n`lowerbound` — the name of the first account returned. If there is none, the list will begin with the very first name followed by `lowerbound`;  \n`limit` — a value that limits the number of account names displayed on the monitor. The maximum value is 1000.  \n \nSetting the `lowerbound` and` limit` 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.\nIt 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.\n\n \n### 6.4 List_my_accounts operation\nThe `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:\n```cpp\nvector <golos::api::account_api_object> wallet_api::list_my_accounts()\n```\n\n\n### 6.5 Import_key operation\nThe operation `import_key` is used for a public private key in WIF format. The operation signature is the following:\n```cpp\nbool import_key(string wif_key) \n```\n\n\nParameter:  \n`wif_key` — private key in WIF format.  \n\n\nOperation example:  \n```\nimport_key 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3\n```\n\n### 6.6 Get_account_history() operation\nThe `get_account_history` operation is used to get the transaction history for an account. The operation signature is the following:\n```cpp\nmap< uint32_t, golos::plugins::operation_history::applied_operation >\nwallet_api::get_account_history(\n        string account,\n        uint32_t from,\n        uint32_t limit\n)  \n```\n\nParameters:  \n`account` — the name of the account whose history is being requested;\n`from` — the serial number of the operation. The parameter is arbitrary and it’s default value is «-1» — the last operation number;\n`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».\n\n\nAn example of `get_account_history` operation call:\n```cpp\nget_account_history cyberfounder -1 100\n```\n\n### 6.7 Операция filter_account_history\nThe `filter_account_history` operation is used when retrieving the transaction history for an account filtered by certain attributes. The operation signature is the following:\n```cpp\nhistory_operations filter_account_history(\nstring account,\nuint32_t from,\nuint32_t limit,\naccount_history_query query\n)\n```\nParameters:  \n`account` — the name of the account whose history is being requested;\n`from` — the serial number of the operation. The parameter is arbitrary and it’s default value is «-1» — the last operation number;\n`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». \n`query` — parameter is a structure (object) and contains the following fields:\n  * select_ops — list of operations that need to be obtained. The value may contain names of operations (including ending with «_operation»), as well as the following key words:\n    * ALL — all operations;\n    * REAL — only explicitly defined operations;\n    * VIRTUAL — only virtual operations;\n  * filter_ops — the list of operations to be deleted. Takes the same values as select_ops. This field is optional and defaults to the empty value;\n  * direction — «direction» of operation relative to the account (for example, the operation vote defines two accounts: the first is the one who votes and the second is the one whose post is voted for). This field is optional and takes the following values:\n    * any — no filtering by direction (default value);\n    * sender — determines the account as a sender (for example, creator or voter);\n    * receiver — determines the account as a receiver (for example, created or voted);\n    * dual — determines the account as both sender and receiver at the same time (for example, voting self post. That is, the case when account is determined ambiguously).\n \n\n\n\nAn operation can be called with one specified parameter (for example, filter_account_history (account)) in order to get 100 most recent account operations.\n\nAn example of filter_account_history() call:\n```cpp\nfilter_account_history cyberfounder -1 100 {\"select_ops\":[\"REAL\",\"interest\"], \"filter_ops\":[\"transfer\"]}\n\nfilter_account_history cyberfounder -1 100 {\"direction\":\"receiver\",\"filter_ops\":[\"producer_reward\"]}\n```\n \n## 7 A conclusion\nThe results of the `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.",
      "json_metadata": "{\"tags\":[\"cyberway\",\"blockchain\",\"smartcontract\",\"technology\"],\"image\":[\"https://cdn.steemitimages.com/DQmdzyStsrbUVedSKeRLhyVyNVV49R8VBFT9CmEFNPU7Wn7/Fig_1.jpg\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "0000000000000000000000000000000000000000",
  "block": 33152051,
  "trx_in_block": 4294967295,
  "op_in_trx": 0,
  "virtual_op": 5,
  "timestamp": "2019-05-23T06:32:12",
  "op": [
    "author_reward",
    {
      "author": "golos",
      "permlink": "cyberway-domain-name-smart-contract",
      "sbd_payout": "0.018 SBD",
      "steem_payout": "0.000 STEEM",
      "vesting_payout": "99.685892 VESTS"
    }
  ]
}

{
  "trx_id": "1d95b2ed19d55a8621e8e5dc36e9483bd8d0c26a",
  "block": 32954770,
  "trx_in_block": 4,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-05-16T10:01:30",
  "op": [
    "vote",
    {
      "voter": "yetaras",
      "author": "golos",
      "permlink": "cyberway-domain-name-smart-contract",
      "weight": 1500
    }
  ]
}

{
  "trx_id": "5ee02f41f046127e61198e04ec92612f72dcb4d1",
  "block": 32950691,
  "trx_in_block": 15,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-05-16T06:37:30",
  "op": [
    "vote",
    {
      "voter": "artem.timofeev",
      "author": "golos",
      "permlink": "cyberway-domain-name-smart-contract",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "61f159c65ceb46a4c886480f3c9490bacf575d1c",
  "block": 32950691,
  "trx_in_block": 13,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-05-16T06:37:30",
  "op": [
    "vote",
    {
      "voter": "jekon80",
      "author": "golos",
      "permlink": "cyberway-domain-name-smart-contract",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "b242fbf8730f8a5831c8c541ceced9366c0a2db7",
  "block": 32950688,
  "trx_in_block": 16,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-05-16T06:37:21",
  "op": [
    "vote",
    {
      "voter": "honeythief",
      "author": "golos",
      "permlink": "cyberway-domain-name-smart-contract",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "8fe6c836e591c224d7cdb3f83e9a6336b7a7dddb",
  "block": 32950585,
  "trx_in_block": 17,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-05-16T06:32:12",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "cyberway",
      "author": "golos",
      "permlink": "cyberway-domain-name-smart-contract",
      "title": "CyberWay. Domain name smart-contract",
      "body": "## Purpose of the cyber.domain smart contract development\nThe `cyber.domain` smart contract is designed to create and handle domain names, create or delete a link of domain names to accounts, change domain name owners, as well as to handle a purchase of domain names at auction.  \n\nThe `cyber.domain` contract includes:\n* a part of actions used to purchase a domain name at auction, including `checkwin`,` biddomain`, `biddmrefund`, `newdomain` and `declarenames`;\n* a part of internal domain actions, including `passdomain`, ` linkdomain`, `unlinkdomain` and `newusername`. Although a code of these actions is in the blockchain core, they are called up via smart contract;\n* a list of domain names used in transactions.\n\n\n## Requirements for domain names\nDomain names in CyberWay are formed in accordance with rules and procedures of the Domain Name System (DNS). The following requirements are imposed on the structure of domain names:\n  * a total number of characters in domain name should not exceed 253 pcs;\n  * a domain name consists of individual parts, separated by the symbol «dot»;\n  * the «dot» characters should not stand side by side in any domain name;\n  * a number of characters in a separate part of domain name should not exceed 63 pcs;\n  * the valid characters in the domain name are alphanumeric, plus «hyphen»;\n  * the capital letters in the domain name are unacceptable;\n  * a symbol «hyphen» should not be at the beginning or end of any domain name part;\n  * the further right part of domain name must contain at least one alphabetic character. A presence of numeric characters only is not allowed.\n\n\n## Domain name auction in the smart contract\nThe actions `checkwin`, `biddomain`, `biddmrefund` and `newdomain` are used to purchase a domain name at auction. The procedure for buying a domain name at the auction is the same as the procedure of buying an account name. The following rules apply to the procedure:  \n* the bids for the purchase of any domain name are accepted at auction at any time;  \n* the largest bid is used to determine only one domain name that can be purchased at the moment;\n* a domain name is considered to be purchased at auction if the following conditions are met:\n    * no more than a day is passed after betting on the current domain name;\n    * at least one day has passed since previous redemption of any domain name;\n* the number of domain names purchased at auction during a day should be no more than one;\n* upon completion of auction, a token transfer of the winner is not returned. \n\nThe winner can take advantage of the following opportunities:\n    * to create her/his own domain name using the operation `newdomain` and become its owner;\n\n\n\n\n\n   \n    * to create subdomain names from it by adding the «dot» symbol and а name to the domain name on the left (for example, an owner of the domain `golos.io` can create subdomains such as `api.golos.io`, `ws.golos.io` and etc). It should be noted, that unlike account names,  in `cyberway` the names are formed by adding parts to the right of word (for example, the names `cyber.msig`, `cyber.domain` can be formed from `cyber`). In this case the only direct inheritance of domain names is allowed. It means that if the owner has created a domain for the second level, a domain for the third level can’t be created (for example, the name `cyber.msig.a` can’t be formed from `cyber`).\n\n\n**Note:**  \n  *  The actions of the `cyber.domain` smart contract were originally intended for the distribution of domain names at auction. Later to this group of actions were added other actions, including such as creating a domain, transferring a domain, linking (or unlinking) a domain, declaring names used in transactions and creating a user name.  \n\n### The checkwin action \nThe `checkwin` action is used to register a domain name owner (a winner) at auction. This action does not require a special call and is called automatically with a certain periodic.  \n\nThe `checkwin` action has the following form:    \n```cpp\n[[eosio::action]] void checkwin();  \n```\nThis action has no input parameters. One has to have `cyber.domain` smart contract rights to call this action.  \n\n### The biddomain action\nThe `biddomain` action allows an account to bid at the auction. The action has the following form:  \n```cpp\n[[eosio::action]] void biddomain(\n    name bidder,\n    domain_name name,\n    asset bid\n);  \n```\nParameters:  \n`bidder` — an account name which bids at the action;  \n`name` — a domain name (a string value in accordance with the requirements) on which the bid is done;   \n`bid` — a structure value that specifies the bid.\n  \nTo perform this action the `cyber.domain` smart contract account should have the rights of the `bidder` account. If a bid with a bigger value appears at the auction, the bid with a smaller value is returned to the `bidder` account. The refunds are made automatically by internal calling `biddmrefund` from `biddomain`..   \n\n### The biddmrefund action\nThe action `biddmrefund` is used to return a bid which was made at the auction to purchase a domain name if a higher bid is made for the same domain name. The action has the following form:  \n```cpp\n[[eosio::action]] void biddmrefund(\n    name bidder,\n    domain_name name\n);  \n```\nParameters:  \n`bidder` —  the account name to which the funds are returned from the auction;   \n`name` — the domain name for which the bid was made.  \n\nIn case of exceptional situations (a network failure or an error in the node's operation), the `biddmrefund` action can be called apart from calling `biddomain` (non-standard calling `biddmrefund`)\n\n### The newdomain action \nThe `newdomain` action is used to create a new domain name. The action has the following form:  \n```cpp\n[[eosio::action]] void newdomain(\n    eosio::name creator,\n    domain_name name\n);\n```\nParameters:  \n`creator` — account name that creates a domain name;  \n`name` — domain name being created.  \n\nThe `newdomain` action can be used: \n  * to create domain name by the system account `cyber.domain`;  \n  * to create domain name by a winner of the domain name auction;  \n  * to create a sub-domain name by the owner of a direct parent domain.  \n\nThe smart contract account `cyber.domain` must be privileged or have a permission to transfer funds from `cyber'.namesaccount` (in case of a refund). Upon completion of this action, the `creator` account becomes the owner of the created domain name.\n\n## Declarations of the names used in transactions  \nIt is not enough for one domain name to define a user name. The matter is, the user name is linked to both the owner account and the domain account (usually, it is a smart contract) and has a structure of the form `name@domain`. The domain part defines a scope for the `name`. The accounts with the same name can exist in different scopes. There are several variants that support `username` data and allow a textual representation of a user name to match an account name.\n\n\n**Restrictions imposed on a user name value**  \n The following requirements are imposed on a user name structure:  \n  * a total number of characters in a user name should not exceed 32 pcs;   \n  * a user name can consist of individual parts separated by the symbol «dot»;  \n  * two «dot» symbols near each other are not allowed;  \n  * the valid characters in a user name should be alphanumeric, a symbol «hyphen» could be used as well ;  \n  * the capital letters in a user name are unacceptable;  \n  * a symbol «hyphen» should not be at the beginning or end of any user name part.  \n\n### The declarenames declaration\nThe `declarenames` declaration is used to submit a list of structures with information about the domain names (or user names) used in transactions and their respective accounts. The declaration has the following form: \n\n```cpp\n[[eosio::action]] void declarenames(\n    vector<name_info> domains\n);\n```\nParameter:  \n`domains` — an array of descriptions, each description of which is a structure in form of `name_info`.  \n\nThe `declarenames` declaration can be created by any account.   \n\n### The newusername declaration\nThe `newusername` declaration is used to create a user name. When creating the user name, three fields are used — `creator`, `owner`, `name`. The `newusername` declaration has the following form:  \n```cpp\n[[eosio::action]] void newusername(\n    name creator,\n    name owner,\n    username name\n); \n```\nParameters:  \n`creator` — an account name in scope of which the user name is created;  \n`owner`— an account name that is the domain name owner;  \n`name` —a string representation of the user name to be created.  \n\nThe lists of structures with information about the names used and the corresponding accounts are passed to the `newusername` declaration. The `newusername` declaration can be created by any account.  \n\nThe transaction requires a signature from the account `creator`.\n\n### The passdomain declaration\nThe `passdomain` declaration is used to transfer a domain name from one account to another one (to change the domain name owner). The `passdomain` declaration has the following form:  \n```cpp\n[[eosio::action]] void passdomain(\n    name from,\n    name to,\n    domain_name name\n); \n```\nParameters:  \n`from` — an account name from which a domain name is transferred and which owns it;  \n`to` — an account name to which the domain name is transferred and which will be a new domain name owner;  \n`name` — a string representation of the domain name to be transferred.  \n\nThe transaction requires a signature from the account `from` that is the domain name owner.  \n\n\n### The linkdomain declaration \nThe `linkdomain` declaration  is used to link a domain name to account name. The `linkdomain` declaration has the following form:  \n\n```cpp\n[[eosio::action]] void linkdomain(\n    name owner,\n    name to,\n    domain_name name\n);\n```  \nParameters:  \n`owner` — an account name that was a domain name owner;  \n`to` — an account name that becomes new a domain name owner;  \n`name` — a string representation of the domain name to be linked.  \n\n### The unlinkdomain declaration\nThe `unlinkdomain` declaration is used to remove domain name link from account name (unlinking a domain name from the account name). The `unlinkdomain` declaration has the following form:  \n```cpp\n[[eosio::action]] void unlinkdomain(\n    name owner,\n    domain_name name\n);\n```  \nParameters:  \n`owner` — an account name that was domain name owner (the domain name link is removed from the account name);  \n`name` — a string representation of the domain name to be unlinked.  \n \n**An example of using the declaration linkdomain and unlinkdomain**   \nLet account to have a contract and be assigned a hard-to-remembered name `ajhgsd23qw`. To eliminate this drawback, this account uses `linkdomain` to link the domain name `helloworld` to its contract. It is easier for users to remember such domain as `@helloworld` and send transfers to this name. In contrast to sending transfers to the account name `ajhgsd23qw` the domain name `@helloworld` will be converted to `ajhgsd23qw` and the `declarenames` action will be added to the transaction indicating the used domain names.  \n  \nTo stop using the domain name `@helloworld` the account has to call the `unlinkdomain` action. After that, the domain name `@helloworld` will not be converted to `ajhgsd23qw` and sending a transfer to it will be impossible.  \n \nThe `ajhgsd23qw` account in its environment can also create a user name for itself, for example,` admin`. In this case, the name `admin@@helloworld` will be converted to the name` ajhgsd23qw`. When adding a domain name, it is possible to use `admin@helloworld`.\n \n### The name_info struct declaration\nThe `name_info` structure is used to check the presence of all elements at the time of executing the procedure, as well as the existence of linking a domain name with the specified account. The `name_info` structure declaration has the following form:  \n\n```cpp\nstruct name_info {\n    domain_name domain;\n    name account;\n    vector<username> users;\n};\n```  \nParameters:   \n`domain` — a domain name;  \n`account` — an account name matching to the domain name;  \n`users` — a list of domain name users.\n \nThe input to the `declarenames` declaration is an array of structures. A number of accepted structures should not be equal to zero. An error occurs when attempting to send an empty array.  \n \nThere are no matches for user names because a user name, unlike domain name, does not change its account for the entire time.  \n\nThe following additional restrictions are introduced:  \n  * the structures must be sorted by domain name, that is, domain names must be arranged in ascending order. The exception is for a domain name that is an empty string. This is possible when the user name is not specified by the domain name, but explicitly in the smart contract. In this case, sorting should be done performed by account name — by field `.account`;  \n  * domain name must not contain two identical values ​​`.domain`, except for empty values ​​(“ ”);  \n  * the field `.account` in the domain name must not contain an empty value.  \n \n### Notes  \n  * Along with `declarenames` for internal use, there may be short account names as well. Such short names are replaced with the real account names. The conversion of internal short names to real account names is performed at the explorer level.   \n  * This implementation does not verify that the accounts specified in `declarenames` exist in other actions. The implementation of validation is difficult because the actual validation process requires a lot of resources to read the ABI file format and deserialize the action. A lack of such control causes a certain risk. That is a sender may add more information to the transaction, so the superfluous part of it will not be checked. As a result, it will have to pay extra for overused `bandwidth` resources.  \n  * This implementation does not contain information about positions of the used domain or user names. A transaction may contain an action with several account names as arguments, for example, `someaction(name 1, name 2, name 3, name 4, name 5)`. If user sends an action like `someaction(acc1, one@golos, two@golos, acc1, three@golos)` and it converts to (`someaction(acc1, acc1, acc1, acc1, acc3)` ), then `declarenames` will contain only used user names or domain names. At the same time, it is impossible to determine the positions where user names were used, for example:  \n```\ndeclarenames([{\n    domain:\"golos\",\n    account:N(acc1),\n    users:[\"one\",\"two\",\"three\"]\n}])\n```\n  * Implemented support for the names like `username@@account` ( a presence of the symbols «@@» in the name means that the right side is not a domain, but the account name). For example, if a transaction converts view names `alice@@token`, `bob@@oken`, `admin@@golos.io`, then the `declareames` declaration will contain the following arguments:\n```\ndeclarenames([\n    {domain:\"\", account:N(golos.io), users:[\"admin\"]},\n    {domain:\"\", account:N(token), users:[\"alice\",\"bob\"]}\n])\n```  \n## Long domain names\nWhen an account is created it is assigned a base32-encoded 8-byte identification name, which is a 12.5-character string. 60 bits are allocated for 12 characters. The remaining 4 bits are reserved for an additional symbol from the set {1,2,3,4, a, b, c, d, e, f, g, h, i, j}.  \n\nA user can also assign her/his domain name to an account. The length of each part of the domain name should not exceed 63 characters. The number of domain names assigned to an account can be more than one. Since a fee is charged for storing a domain name, the number of domain names is limited and depends on the user funds.  \n \nA domain name can be purchased at auction, and can also be created by the lower-level domain owner.  \n  \nAdding a domain name to an account allows a user to form domain transactions, the transactions with a link to the domain. Such transaction specify smart contract to be called and operations it performs. Domain name is not an identifier and can be transferred from one account to another.  \n\n****",
      "json_metadata": "{\"tags\":[\"cyberway\",\"blockchain\",\"smartcontract\",\"technology\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "4b776ca153497b9e96d52bfe9edd83b4ed7f90af",
  "block": 32720562,
  "trx_in_block": 13,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-05-08T06:45:48",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "cyberway",
      "author": "golos",
      "permlink": "cyberway-smart-contract-domain-name",
      "title": "CyberWay: Smart-contract / Domain Name",
      "body": "## Purpose of the cyber.domain smart contract development\nThe `cyber.domain` smart contract is designed to create and handle domain names, create or delete a link of domain names to accounts, change domain name owners, as well as handle a purchase of domain names at auction.  \n\nThe `cyber.domain` contract includes:\n* a part of actions used to purchase a domain name at auction, including `checkwin`,` biddomain`, `biddmrefund`, `newdomain` and `declarenames`;\n* a part of internal domain actions, including `passdomain`, ` linkdomain`, `unlinkdomain` and `newusername`. Although a code of these actions is in the blockchain core, they are called up via smart contract;\n* a list of domain names used in transactions.\n\n\n## Requirements for domain names\nDomain names in CyberWay are formed in accordance with rules and procedures of the Domain Name System (DNS). The following requirements are imposed on the structure of domain names\n  * total number of characters in domain name should not exceed 253 pcs;\n  * a domain name consists of individual parts, separated by the symbol «dot»;\n  * the «dot» characters should not stand side by side in any domain name;\n  * a number of characters in a separate part of domain name should not exceed 63 pcs;\n  * valid characters in the domain name are alphanumeric, as well as the symbol «hyphen»;\n  * capital letters in the domain name are unacceptable;\n  * a symbol «hyphen» should not be at the beginning or end of any domain name part;\n  * the further right part of domain name must contain at least one alphabetic character. A presence of numeric characters only is not allowed.\n\n\n## Domain name auction in the smart contract\nThe actions `checkwin`, `biddomain`, `biddmrefund` and `newdomain` are used to purchase a domain name at auction. The procedure for buying a domain name at the auction is the same as the procedure of buying an account name. The following rules apply to the procedure:  \n* the bids for the purchase of any domain name are accepted at auction at any time;  \n* the largest bid is used to determine only one domain name that can be purchased at the moment;\n* a domain name is considered to be purchased at auction if the following conditions are met:\n    * no more than a day is passed after betting on the current domain name;\n    * at least one day has passed since previous redemption of any domain name;\n* the number of domain names purchased at auction during a day should be no more than one;\n* upon completion of auction, a token transfer of the winner is not returned. \n\nThe winner can take advantage of the following opportunities:\n    * to create her/his own domain name using the operation `newdomain` and become its owner;\n\n\n\n\n\n   \n    * to create subdomain names from it by adding the «dot» symbol and а name to the domain name on the left (for example, an owner of the domain `golos.io` can create subdomains such as `api.golos.io`, `ws.golos.io` and etc). It should be noted, that unlike account names,  in `cyberway` the names are formed by adding parts to the right of word (for example, the names `cyber.msig`, `cyber.domain` can be formed from `cyber`). In this case the only direct inheritance of domain names is allowed. It means that if the owner has created a domain for the second level, a domain for the third level can’t be created (for example, the name `cyber.msig.a` can’t be formed from `cyber`).\n\n\n**Note:**  \n  *  The actions of the `cyber.domain` smart contract were originally intended for the distribution of domain names at auction. Later to this group of actions were added other actions, including such as creating a domain, transferring a domain, linking (or unlinking) a domain, declaring names used in transactions and creating a user name.  \n\n### The checkwin action \nThe `checkwin` action is used to register a domain name owner (a winner) at auction. This action does not require a special call and is called automatically with a certain periodic.  \n\nThe `checkwin` action has the following form:    \n```cpp\n[[eosio::action]] void checkwin();  \n```\nThis action has no input parameters. One has to have `cyber.domain` smart contract rights to call this action.  \n\n### The biddomain action\nThe `biddomain` action allows an account to bid at the auction. The action has the following form:  \n```cpp\n[[eosio::action]] void biddomain(\n    name bidder,\n    domain_name name,\n    asset bid\n);  \n```\nParameters:  \n`bidder` — an account name which bids at the action;  \n`name` — a domain name (a string value in accordance with the requirements) on which the bid is done;   \n`bid` — a structure value that specifies the bid.\n  \nTo perform this action the `cyber.domain` smart contract account should have the rights of the `bidder` account. If a bid with a bigger value appears at the auction, the bid with a smaller value is returned to the `bidder` account. The refunds are made automatically by internal calling `biddmrefund` from `biddomain`..   \n\n### The biddmrefund action\nThe action `biddmrefund` is used to return a bid which was made at the auction to purchase a domain name if a higher bid is made for the same domain name. The action has the following form:  \n```cpp\n[[eosio::action]] void biddmrefund(\n    name bidder,\n    domain_name name\n);  \n```\nParameters:  \n`bidder` —  the account name to which the funds are returned from the auction;   \n`name` — the domain name for which the bid was made.  \n\nIn case of exceptional situations (a network failure or an error in the node's operation), the `biddmrefund` action can be called apart from calling `biddomain` (non-standard calling `biddmrefund`)\n\n### The newdomain action \nThe `newdomain` action is used to create a new domain name. The action has the following form:  \n```cpp\n[[eosio::action]] void newdomain(\n    eosio::name creator,\n    domain_name name\n);\n```\nParameters:  \n`creator` — account name that creates a domain name;  \n`name` — domain name being created.  \n\nThe `newdomain` action can be used: \n  * to create domain name by the system account `cyber.domain`;  \n  * to create domain name by a winner of the domain name auction;  \n  * to create a sub-domain name by the owner of a direct parent domain.  \n\nThe smart contract account `cyber.domain` must be privileged or have a permission to transfer funds from `cyber'.namesaccount` (in case of a refund). Upon completion of this action, the `creator` account becomes the owner of the created domain name.\n\n## Declarations of the names used in transactions  \nIt is not enough for one domain name to define a user name. The matter is, the user name is binded to both the owner account and the domain account (usually, it is a smart contract) and has a structure of the form `name@domain`. The domain part defines a scope for the `name`. The accounts with the same name can exist in different scopes. There are several variants that support `username` data and allow a textual representation of a user name to match an account name.\n\n\n**Restrictions imposed on a user name value**  \n The following requirements are imposed on a user name structure:  \n  * a total number of characters in a user name should not exceed 32 pcs;   \n  * a user name can consist of individual parts separated by the symbol «dot»;  \n  * two «dot» symbols near each other are not allowed;  \n  * the valid characters in a user name should be alphanumeric, a symbol «hyphen» could be used as well ;  \n  * the capital letters in a user name are unacceptable;  \n  * a symbol «hyphen» should not be at the beginning or end of any user name part.  \n\n### The declarenames declaration\nThe `declarenames` declaration is used to submit a list of structures with information about the domain names (or user names) used in transactions and their respective accounts. The declaration has the following form: \n\n```cpp\n[[eosio::action]] void declarenames(\n    vector<name_info> domains\n);\n```\nParameter:  \n`domains` — an array of descriptions, each description of which is a structure in form of `name_info`.  \n\nThe `declarenames` declaration can be created by any account.   \n\n### The newusername declaration\nThe `newusername` declaration is used to create a user name. When creating the user name, three fields are used — `creator`, `owner`, `name`. The `newusername` declaration has the following form:  \n```cpp\n[[eosio::action]] void newusername(\n    name creator,\n    name owner,\n    username name\n); \n```\nParameters:  \n`creator` — an account name in scope of which the user name is created;  \n`owner`— an account name that is the domain name owner;  \n`name` —a string representation of the user name to be created.  \n\nThe lists of structures with information about the names used and the corresponding accounts are passed to the `newusername` declaration. The `newusername` declaration can be created by any account.  \n\nThe transaction requires a signature from the account `creator`.\n\n### The passdomain declaration\nThe `passdomain` declaration is used to transfer a domain name from one account to another one (to change the domain name owner). The `passdomain` declaration has the following form:  \n```cpp\n[[eosio::action]] void passdomain(\n    name from,\n    name to,\n    domain_name name\n); \n```\nParameters:  \n`from` — an account name from which a domain name is transferred and which owns it;  \n`to` — an account name to which the domain name is transferred and which will be a new domain name owner;  \n`name` — a string representation of the domain name to be transferred.  \n\nThe transaction requires a signature from the account `from` that is the domain name owner.  \n\n\n### The linkdomain declaration \nThe `linkdomain` declaration  is used to link a domain name to account name. The `linkdomain` declaration has the following form:  \n\n```cpp\n[[eosio::action]] void linkdomain(\n    name owner,\n    name to,\n    domain_name name\n);\n```  \nParameters:  \n`owner` — an account name that was a domain name owner;  \n`to` — an account name that becomes new a domain name owner;  \n`name` — a string representation of the domain name to be linked.  \n\n### The unlinkdomain declaration\nThe `unlinkdomain` declaration is used to remove domain name link from account name (unlinking a domain name from the account name). The `unlinkdomain` declaration has the following form:  \n```cpp\n[[eosio::action]] void unlinkdomain(\n    name owner,\n    domain_name name\n);\n```  \nParameters:  \n`owner` — an account name that was domain name owner (the domain name link is removed from the account name);  \n`name` — a string representation of the domain name to be unlinked.  \n \n**An example of using the declaration linkdomain and unlinkdomain**   \nLet account to have a contract and be assigned a hard-to-remembered name `ajhgsd23qw`. To eliminate this drawback, this account uses `linkdomain` to link the domain name `helloworld` to its contract. It is easier for users to remember such domain as `@helloworld` and send transfers to this name. In contrast to sending transfers to the account name `ajhgsd23qw` the domain name `@helloworld` will be converted to `ajhgsd23qw` and the `declarenames` action will be added to the transaction indicating the used domain names.  \n  \nTo stop using the domain name `@helloworld` the account has to call the `unlinkdomain` action. After that, the domain name `@helloworld` will not be converted to `ajhgsd23qw` and sending a transfer to it will be impossible.  \n \nThe `ajhgsd23qw` account in its environment can also create a user name for itself, for example,` admin`. In this case, the name `admin@@helloworld` will be converted to the name` ajhgsd23qw`. When adding a domain name, it is possible to use `admin@helloworld`.\n \n### The name_info struct declaration\nThe `name_info` structure is used to check the presence of all elements at the time of executing the procedure, as well as the existence of linking a domain name with the specified account. The `name_info` structure declaration has the following form:  \n\n```cpp\nstruct name_info {\n    domain_name domain;\n    name account;\n    vector<username> users;\n};\n```  \nParameters:   \n`domain` — a domain name;  \n`account` — an account name matching to the domain name;  \n`users` — a list of domain name users.\n \nThe input to the `declarenames` declaration is an array of structures. A number of accepted structures should not be equal to zero. An error occurs when attempting to send an empty array.  \n \nThere are no matches for user names because a user name, unlike domain name, does not change its account for the entire time.  \n\nThe following additional restrictions are introduced:  \n  * the structures must be sorted by domain name, that is, domain names must be arranged in ascending order. The exception is for a domain name that is an empty string. This is possible when the user name is not specified by the domain name, but explicitly in the smart contract. In this case, sorting should be done performed by account name — by field `.account`;  \n  * domain name must not contain two identical values ​​`.domain`, except for empty values ​​(“ ”);  \n  * the field `.account` in the domain name must not contain an empty value.  \n \n### Notes  \n  * Along with `declarenames` for internal use, there may be short account names as well. Such short names are replaced with the real account names. The conversion of internal short names to real account names is performed at the explorer level.   \n  * This implementation does not verify that the accounts specified in `declarenames` exist in other actions. The implementation of validation is difficult because the actual validation process requires a lot of resources to read the ABI file format and deserialize the action. A lack of such control causes a certain risk. That is a sender may add more information to the transaction, so the superfluous part of it will not be checked. As a result, it will have to pay extra for overused `bandwidth` resources.  \n  * This implementation does not contain information about positions of the used domain or user names. A transaction may contain an action with several account names as arguments, for example, `someaction(name 1, name 2, name 3, name 4, name 5)`. If user sends an action like `someaction(acc1, one@golos, two@golos, acc1, three@golos)` and it converts to (`someaction(acc1, acc1, acc1, acc1, acc3)` ), then `declarenames` will contain only used user names or domain names. At the same time, it is impossible to determine the positions where user names were used, for example:  \n```\ndeclarenames([{\n    domain:\"golos\",\n    account:N(acc1),\n    users:[\"one\",\"two\",\"three\"]\n}])\n```\n  * Implemented support for the names like `username@@account` ( a presence of the symbols «@@» in the name means that the right side is not a domain, but the account name). For example, if a transaction converts view names `alice@@token`, `bob@@oken`, `admin@@golos.io`, then the `declareames` declaration will contain the following arguments:\n```\ndeclarenames([\n    {domain:\"\", account:N(golos.io), users:[\"admin\"]},\n    {domain:\"\", account:N(token), users:[\"alice\",\"bob\"]}\n])\n```  \n## Long domain names\nWhen an account is created it is assigned a base32-encoded 8-byte identification name, which is a 12.5-character string. 60 bits are allocated for 12 characters. The remaining 4 bits are reserved for an additional symbol from the set {1,2,3,4, a, b, c, d, e, f, g, h, i, j}.  \n\nA user can also assign her/his domain name to an account. The length of each part of the domain name should not exceed 63 characters. The number of domain names assigned to an account can be more than one. Since a fee is charged for storing a domain name, the number of domain names is limited and depends on the user funds.  \n \nA domain name can be purchased at auction, and can also be created by the lower-level domain owner.  \n  \nAdding a domain name to an account allows a user to form domain transactions — transactions with binding to the domain. Such transaction specifies smart contract to be called and operations it performs. Domain name is not an identifier and can be transferred from one account to another.",
      "json_metadata": "{\"tags\":[\"cyberway\",\"blockchain\",\"smartcontract\",\"technology\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "e7cb6eafa6b762c39e2e8f7986bc42cb6d9a774a",
  "block": 31976741,
  "trx_in_block": 5,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-04-12T09:32:12",
  "op": [
    "comment",
    {
      "parent_author": "golos",
      "parent_permlink": "cyberway-project-roadmap",
      "author": "makishart",
      "permlink": "re-golos-cyberway-project-roadmap-20190412t093209636z",
      "title": "",
      "body": "Seems like a great project. Please release announcements also in English so we know what to do and to expect in the transition period.. (seems like the result will be 'yes')",
      "json_metadata": "{\"tags\":[\"cyberway\"],\"app\":\"steemit/0.1\"}"
    }
  ]
}

{
  "trx_id": "10da420ee0e78bbf3ec511ca9f31de514ed6b620",
  "block": 31948961,
  "trx_in_block": 23,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-04-11T10:22:21",
  "op": [
    "vote",
    {
      "voter": "makishart",
      "author": "golos",
      "permlink": "eos-transitioning-getting-into-details",
      "weight": 9900
    }
  ]
}

{
  "trx_id": "ae94aeeb9416c85447ab415a325de1daac752443",
  "block": 31092220,
  "trx_in_block": 11,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-03-12T15:39:09",
  "op": [
    "transfer",
    {
      "from": "dlease",
      "to": "golos",
      "amount": "0.001 STEEM",
      "memo": "BuildTeam is proud to announce the release of DLease.io - our flagship P2P leasing marketplace app, aimed at assisting Steemians in leasing and delegating STEEM POWER for daily passive returns, with recent yields as high as 20% APR. DLease.io is a professional grade app , designed to replace the current MinnowBooster.net leasing market which has to date facilitated nearly 20 Million STEEM POWER in lease value to happy BuildTeam customers. View the new app at https://dlease.io/ or read the announcement post on https://steemit.com/@dlease."
    }
  ]
}

{
  "trx_id": "0000000000000000000000000000000000000000",
  "block": 30739514,
  "trx_in_block": 4294967295,
  "op_in_trx": 0,
  "virtual_op": 5,
  "timestamp": "2019-02-28T09:32:06",
  "op": [
    "author_reward",
    {
      "author": "golos",
      "permlink": "cyberway-project-roadmap",
      "sbd_payout": "0.034 SBD",
      "steem_payout": "0.000 STEEM",
      "vesting_payout": "204.345884 VESTS"
    }
  ]
}

{
  "trx_id": "0818e6793ae8dc3cdd965187d5e1682436f2f28b",
  "block": 30667664,
  "trx_in_block": 12,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-25T21:36:57",
  "op": [
    "comment",
    {
      "parent_author": "golos",
      "parent_permlink": "cyberway-project-roadmap",
      "author": "partiko",
      "permlink": "partiko-re-golos-cyberway-project-roadmap-20190225t213657226z",
      "title": "",
      "body": "Hello @golos! This is a friendly reminder that you have 3000 Partiko Points unclaimed in your Partiko account!\n\nPartiko is a fast and beautiful mobile app for Steem, and it’s the most popular Steem mobile app out there! Download Partiko using the link below and login using SteemConnect to claim your 3000 Partiko points! You can easily convert them into Steem token!\n\nhttps://partiko.app/referral/partiko",
      "json_metadata": "{\"app\":\"partiko\"}"
    }
  ]
}

{
  "trx_id": "431f7bc0733363ac99df8c26844242b7ce19edd9",
  "block": 30540529,
  "trx_in_block": 13,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-21T11:35:24",
  "op": [
    "vote",
    {
      "voter": "yetaras",
      "author": "golos",
      "permlink": "cyberway-project-roadmap",
      "weight": 1500
    }
  ]
}

{
  "trx_id": "1bf953e002cb6e3038d5a909542bf67c13f12e84",
  "block": 30538403,
  "trx_in_block": 4,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-21T09:48:57",
  "op": [
    "vote",
    {
      "voter": "team",
      "author": "golos",
      "permlink": "cyberway-project-roadmap",
      "weight": 1000
    }
  ]
}

{
  "trx_id": "ad593ee653b2f956d1342d4736fc60a5234383cb",
  "block": 30538317,
  "trx_in_block": 27,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-21T09:44:36",
  "op": [
    "vote",
    {
      "voter": "bukiland",
      "author": "golos",
      "permlink": "cyberway-project-roadmap",
      "weight": 100
    }
  ]
}

{
  "trx_id": "4ad57581178b206e94261d56fc04f5959c6a1ced",
  "block": 30538218,
  "trx_in_block": 5,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-21T09:39:39",
  "op": [
    "vote",
    {
      "voter": "hamsa.quality",
      "author": "golos",
      "permlink": "cyberway-project-roadmap",
      "weight": 110
    }
  ]
}

{
  "trx_id": "c151eca08553b7e2fada8385ba248f62519bd7c3",
  "block": 30538173,
  "trx_in_block": 27,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-21T09:37:24",
  "op": [
    "vote",
    {
      "voter": "artem.timofeev",
      "author": "golos",
      "permlink": "cyberway-project-roadmap",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "4f8f79cc0585822743f612abfe710f8edc6bc55c",
  "block": 30538173,
  "trx_in_block": 22,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-21T09:37:24",
  "op": [
    "vote",
    {
      "voter": "jekon80",
      "author": "golos",
      "permlink": "cyberway-project-roadmap",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "510b296d5d85d48f508f3f1fd01fb0b0cccde5b9",
  "block": 30538170,
  "trx_in_block": 35,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-21T09:37:15",
  "op": [
    "vote",
    {
      "voter": "honeythief",
      "author": "golos",
      "permlink": "cyberway-project-roadmap",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "fd3bfe0a4bc9de1c2da8e2ea6cef18704c1bd973",
  "block": 30538091,
  "trx_in_block": 1,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-21T09:33:18",
  "op": [
    "vote",
    {
      "voter": "steeming-hot",
      "author": "golos",
      "permlink": "cyberway-project-roadmap",
      "weight": 5
    }
  ]
}

{
  "trx_id": "7025812666dfa50a53189dcf47cf23c3f2c131e0",
  "block": 30538067,
  "trx_in_block": 18,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-21T09:32:06",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "cyberway",
      "author": "golos",
      "permlink": "cyberway-project-roadmap",
      "title": "CyberWay: Project RoadMap",
      "body": "**CyberWay goals**\n\nThe main goal of the project is to create new CyberWay blockchain platform based on EOS logic that has:\n\n* decentralized governance: stakers (vote for validators), validators (run blockchain), workers (build blockchain);\n\n* in-build rights guaranteed by technology: blockchain assets belong to users, every user has a right to make a transaction, smart contracts are executed upon payment\n\n* application-friendly: free user onboarding, claim for bandwidth from application developers, free transactions.\n\nCyberWay blockchain is the protocol that enables development of applications that are built on individual smart contracts; thus are flexible in terms of business logic. It lacks censoring and is free of God’s mode of EOS.\n\n**Main project stages:**\n\nStage 1: blockchain development and development of Golos application (golos.io) on CyberWay smart contracts. Data migration from Golos blockchain platform to CyberWay.\n\nStage 2: blockchain development and development of other applications based on smart contracts developed for the Golos application.\n\n**List of works for stage 1:**\n\n1) Analysis of the EOS blockchain platform functionality (done).\n2) Development of environment for CyberWay based on EOS logic (fork) (done).\n3) CyberWay platform architecture development (done).\n4) Smart contracts development for the CyberWay platform (done).\n5) Development and deployment of MainNet.\n\nFor now, the works listed in clauses 1-4 are finished.  \nFig 1 and 2 show the sequence of actions for CyberWay development. \nThe work outlined is to be finished in April if no obstacles will take place.\n\n![Пост_1-Fig_1.jpg](https://cdn.steemitimages.com/DQmVWmyAt6yJok77G9P6rFHpY8hwZH1SKYD3912QxqeBjeJ/%D0%9F%D0%BE%D1%81%D1%82_1-Fig_1.jpg)\nFig.1 — Workflow diagram for the development and deployment of MainNet\n\n![Product Roadmap_ENG.jpg](https://cdn.steemitimages.com/DQmWuB5hGVm9jGBAHRo7vRxP4W6cN5yqZxVd2gngiZbZL81/Product%20Roadmap_ENG.jpg)\nFig.2 — The scope of work to be completed in the development and deployment of MainNet",
      "json_metadata": "{\"tags\":[\"cyberway\",\"golos\",\"blockchain\",\"eos\",\"roadmap\"],\"image\":[\"https://cdn.steemitimages.com/DQmVWmyAt6yJok77G9P6rFHpY8hwZH1SKYD3912QxqeBjeJ/%D0%9F%D0%BE%D1%81%D1%82_1-Fig_1.jpg\",\"https://cdn.steemitimages.com/DQmWuB5hGVm9jGBAHRo7vRxP4W6cN5yqZxVd2gngiZbZL81/Product%20Roadmap_ENG.jpg\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "8c5274d56e7c63ccd88c1401d79ad83237f5ed29",
  "block": 30496447,
  "trx_in_block": 9,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-19T22:49:42",
  "op": [
    "vote",
    {
      "voter": "nesmeliy",
      "author": "golos",
      "permlink": "cyberway-need-for-new-platform",
      "weight": 500
    }
  ]
}

{
  "trx_id": "f722d0da4d6de72c6518c1df802ddb3abaf992e9",
  "block": 30492757,
  "trx_in_block": 14,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-19T19:45:12",
  "op": [
    "vote",
    {
      "voter": "aleco",
      "author": "golos",
      "permlink": "cyberway-need-for-new-platform",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "f585005e0660ef11e94645769ad2289065d8e1cb",
  "block": 30492170,
  "trx_in_block": 19,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-19T19:15:48",
  "op": [
    "vote",
    {
      "voter": "yetaras",
      "author": "golos",
      "permlink": "cyberway-need-for-new-platform",
      "weight": 1500
    }
  ]
}

{
  "trx_id": "358a4b500fa5c676e22b862378e68ce537d72631",
  "block": 30491999,
  "trx_in_block": 6,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-19T19:07:15",
  "op": [
    "vote",
    {
      "voter": "hozn4ukhlytriwc",
      "author": "golos",
      "permlink": "cyberway-need-for-new-platform",
      "weight": 1500
    }
  ]
}

{
  "trx_id": "ccd5fc8ec8869953bf02331cd5559712bb3aa570",
  "block": 30491337,
  "trx_in_block": 37,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-19T18:34:09",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "cyberway",
      "author": "golos",
      "permlink": "cyberway-need-for-new-platform",
      "title": "CyberWay: Need For New Platform",
      "body": "@@ -434,12 +434,17 @@\n  is \n-good\n+excellent\n  in \n",
      "json_metadata": "{\"tags\":[\"cyberway\",\"golos\",\"blockchain\",\"eos\",\"fork\"],\"image\":[\"https://cdn.steemitimages.com/DQmVWmyAt6yJok77G9P6rFHpY8hwZH1SKYD3912QxqeBjeJ/%D0%9F%D0%BE%D1%81%D1%82_1-Fig_1.jpg\",\"https://cdn.steemitimages.com/DQmUndkBduUvUXGrUrPKGVXsv9RRH2tMyVwLk8Q5dXHzryN/%D0%9F%D0%BE%D1%81%D1%82_1-Fig_2.jpg\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "bea414b29e359ef85eb163e023663d59c399569e",
  "block": 30491317,
  "trx_in_block": 5,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-02-19T18:33:09",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "cyberway",
      "author": "golos",
      "permlink": "cyberway-need-for-new-platform",
      "title": "CyberWay: Need For New Platform",
      "body": "In anticipation of the release of a new blockchain called CyberWay Golos Сore team (the team developing golos.io) informs the community about the key technical provisions of the product. As mentioned previously, CyberWay is a fork of the well-known EOS platform. Keeping in mind that CyberWay inherits some EOS codebase, it's important to take a look at the differences of these two platforms.\n\n## Reasons for creating CyberWay  \nEOS is good in terms of performance characteristics and smart contracts functionality. However, building applications on top of it without creating additional add-in is impossible. \n\nOther reasons for choosing a separate way for CyberWay are given below:   \n\n* High costs of used memory in EOS. As of January 2019 (according to the eosrp.io source), a price for 1 KB of RAM data for storing was around $ 0,571. This means that storing only user data and consensus data on posts and voting results for a week (for a platform like golos.io) might require of at least 400 MB and could cost a minimum of $ 200,000.  \n\n* EOS smart contract data is stored in a huge hash table in shared memory and access to this data is possible via functions. The disadvantage of this solution is that in this case it is difficult to build search and aggregate queries. As a result the processing of data from this table becomes cumbersome. The most effective solution is to create cache services that would read data from blocks and save them straight to the databases where they can be easily processed. Implementing such a solution directly on the EOS platform is quite complicated.  \n\n* The EOS system system operates in accordance with the adopted Constitution representing a set of rules for resolving disputes in the form of a textual description (for example, if any user data are not used during 3 years the ownership of them shifts to EOS). It’s obvious that not every community could adopt the current EOS Constitution. That limits the user base of EOS and hinders application development.  \n\n* The EOS platform is focused on creating blocks with a maximum achievable frequency — two blocks per second. Such a high performance can be effective in marketing, but it limits the feasible complexity of smart contracts. CyberWay will meet demand of application developers that prefer reliability over speed (the goal for CyberWay is to have a block per 3 second).\n\n* Besides Constitution, EOS has privileged accounts or privileged smart contracts. This could be a code that is associated with the privileged contract, for example, Ricardian contract that could be set as decision maker. Such privileged contracts do restrict decentralization. The resilience to censorship, the lack of a single point of failure and other manifestations of reliability of blockchain technologies are crucial for some applications and businesses. Regardless of general share of such businesses, the choice of a centralized solution as a rule is the way more preferable.\n\n## Distinctive features of CyberWay and EOS platforms\n### Differences in platform architecture\n\n![Пост_1-Fig_1.jpg](https://cdn.steemitimages.com/DQmVWmyAt6yJok77G9P6rFHpY8hwZH1SKYD3912QxqeBjeJ/%D0%9F%D0%BE%D1%81%D1%82_1-Fig_1.jpg)\nFig. 1 — Structural diagram of EOS platform  \n\n![Пост_1-Fig_2.jpg](https://cdn.steemitimages.com/DQmUndkBduUvUXGrUrPKGVXsv9RRH2tMyVwLk8Q5dXHzryN/%D0%9F%D0%BE%D1%81%D1%82_1-Fig_2.jpg)\nFig. 2 — Structural diagram of CyberWay platform \n\n**The main differences between EOS and CyberWay:**\n\n* The difference is in the set of functions that are transferred from smart contracts to the input of web assemblers. CyberWay has its own set of functions coming from smart contracts and used for bandwidth subsystem and data storage. Unlike EOS, CyberWay has event generator. The web assembler does not compile any functions but converts them into calls within blockchain thus creating embedded functions for the event generator.\n* The way of accessing system state data.\nIn EOS system state data are stored in a database located directly on the blockchain node. The client does not have any direct access to the database meaning he is forced to contact blockchain node to obtain data. System state data in CyberWay are stored in a database management system (DBMS) and conveniently placed outside the blockchain node.\n\n* The way of analyzing events and data processing. When it comes to EOS, the analysis of events occurring in the blockchain is done via plug-ins. CyberWay has event generator that forms events on operations inside the blockchain and sends them straight to the event queue. Event information is processed by microservices. The structure of the interactions between microservices and the blockchain is client dependent. This allows to build a flexible infrastructure for processing information that appears inside blockchain.\n\n* The way how bandwidth is allocated.\nBandwidth resources in EOS are allocated to all accounts regardless of their activity. In the case of low user activity resources allocated to “silent” users are not used. CyberWay bandwidth resources could be allocated to the applications and granted by them to the end users on demand according to the activities of users. This ensures more efficient bandwidth usage.\n\n**Detailing the differences in bandwidth subsystems**\n  \nThe bandwidth subsystem allows the user to perform transactions in accordance with his or her share in the network.\n\nIn EOS system the newbies are given funds to the extent necessary to complete a transaction. It is assumed that any new user knows how to work in the system. He has to have a certain amount of staked tokens on his own balance to execute transactions.\n\nA newly attracted CyberWay user may not be familiar with the system. He could start using any CyberWay-based application without any tokens in his wallet. When any user-generated transaction happens the application uses its own tokens to put it forward. In this case when user is no longer active no bandwidth resources are blocked. \n\nIf a user is ready to use CyberWay on his own he could buy system tokens and block them for transactions. Once the time has elapsed, the allocated and blocked bandwidth funds can be returned back to the liquid state.\n\nUnlike EOS, CyberWay is built to attract not only users but applications as well and optimize the allocation of system tokens.\n\n**Database differences**  \n\nIn EOS system state data are kept directly on a node in the database that construes a separate part of shared memory. This architecture limits the client's operations.  The client can not get direct access to the database. \nThe applications can only access the database indirectly via EOS node using very primitive set of functions. \nCyberWay system state data are located in the DBMS outside blockchain node, including consensus information. The DBMS is designed to store consensus data only. Big data (English big data) are stored in a separate database and contain all the necessary information about events in the system.\n\nThe access to the mentioned database is implemented via intrinsic functions called by WebAssembler virtual machine. There is no direct compilation of these functions as WebAssembler converts them into calls within the blockchain itself and creates embedded functions. The calls to the event engine are also added to this set of features. Calls for the event generator are also part of this set of functions. a mechanism inside the blockchain into which an arbitrary contract can add its own events (known as data sets) that will be delivered to the new microchip on the external microservice.\n\nAny of the smart contracts can call a function while generating any event and, therefore, trigger the event generator. The event generator puts the event in the event queue. The events are consequently distributed to their respective recipients in the form of ready-made API calls with operations and parameters.\n\nThe CyberWay architecture is allowing to shape a microservice infrastructure around the blockchain site using the event model. It particularly allows you to implement both repository of social applications texts outside the blockchain and a history of operations performed in the blockchain one.\n\nUnlike EOS, CyberWay architecture provides the client with flexible access to any of the repositories and grants any information of interest while in EOS each client request leads to a set of queries in the database. CyberWay allows the data needed to be gathered in different blocks. As a result, customers make a request to the database, where the aggregated and processed information is stored.\n\nThis structure makes  implementing a repository for texts of social applications outside the blockchain possible, as well as a repository of the history of operations performed in the blockchain.\n\n## Other differences between CyberWay and EOS\n\nAlthough CyberWay inherits EOS logic it contains a number of features that distinguish it from EOS. Below are the most important features of CyberWay: \n\n* Ability to process long domain names of accounts. Unlike EOS, where a domain name is limited to 12,5 characters, CyberWay limits domain name to 253 characters. The separated part of the domain name could be up to 63 characters. The long domain name allows the applications to offer services. At the same time the hierarchical structure ensures interconnections as the user could have a unique name (alias) within each service.\n\n* Set of rules that ensures participation of users in selection of block producers. The users participating in the voting for block producers get remuneration as a percentage of rewards that validators receive for the blocks they oproduce. The users who do not participate in the voting, do not get remuneration, and thus are diluted by inflation the annual percentage of token emissions.\n\n* Any user can propose or implement a new functionality for CyberWay thanks to funds allocated for Workers from the reward pool.  \n  \n* The absence of supervisory authority in CyberWay. In EOS, all the rules are specified by a special document — the Constitution. The key decisions are made by ECAF (The EOSIO Core Arbitration Forum) and block producers are obliged to fulfill them. CyberWay does not have any special forums. Thus, all users have equal rights when interacting with the blockchain.  \n\n* The absence of  both \"grey\" and \"black\" lists of accounts in Cyber Way. In EOS, block producers have «black» and «gray» lists of users. ECAF can make a ruling and put any user on these lists (taking into account the evidence of his or her malicious actions). A user who is unable to operate on the blockchain. The mentioned lists are synchronized outside the blockchain. \n\n* CyberWay plans to increase the number of block producers till 101 in the future in order to create greater decentralization.  \n\n## Ancillary\nOne of the first applications to be implemented on CyberWay will be the Golos application. This application will be identical to Golos.io in terms of functionality. CyberWay capabilities will be demonstrated basing on this application.",
      "json_metadata": "{\"tags\":[\"cyberway\",\"golos\",\"blockchain\",\"eos\",\"fork\"],\"image\":[\"https://cdn.steemitimages.com/DQmVWmyAt6yJok77G9P6rFHpY8hwZH1SKYD3912QxqeBjeJ/%D0%9F%D0%BE%D1%81%D1%82_1-Fig_1.jpg\",\"https://cdn.steemitimages.com/DQmUndkBduUvUXGrUrPKGVXsv9RRH2tMyVwLk8Q5dXHzryN/%D0%9F%D0%BE%D1%81%D1%82_1-Fig_2.jpg\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "0d33209b3ed387066474527b49741503a31c790b",
  "block": 26453302,
  "trx_in_block": 5,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-10-02T11:03:12",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "golos",
      "author": "golos",
      "permlink": "technical-specification-for-workers-possible-scenarios",
      "title": "Technical specification for Workers. Possible scenarios",
      "body": "@@ -11857,56 +11857,8 @@\n /p%3E%0A\n-%3Cp%3E%3Cimg src=%22https://imgur.com/a/etiWCIi%22/%3E%3C/p%3E%0A\n %3C/ht\n",
      "json_metadata": "{\"tags\":[\"golos\",\"blockchain\",\"eos\",\"code\",\"transition\"],\"users\":[\"denis4inet\"],\"app\":\"steemit/0.1\",\"format\":\"html\"}"
    }
  ]
}

{
  "trx_id": "1260f9ea09fbc7971e47fc99345a696728d442ea",
  "block": 26453276,
  "trx_in_block": 40,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-10-02T11:01:54",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "golos",
      "author": "golos",
      "permlink": "technical-specification-for-workers-possible-scenarios",
      "title": "Technical specification for Workers. Possible scenarios",
      "body": "@@ -11853,28 +11853,16 @@\n s).%3C/p%3E%0A\n-%3Cp%3E%3Cbr%3E%3C/p%3E%0A\n %3Cp%3E%3Cimg \n",
      "json_metadata": "{\"tags\":[\"golos\",\"blockchain\",\"eos\",\"code\",\"transition\"],\"users\":[\"denis4inet\"],\"app\":\"steemit/0.1\",\"format\":\"html\",\"image\":[\"https://imgur.com/a/etiWCIi\"]}"
    }
  ]
}

{
  "trx_id": "73d9cb48da402066d70fafee18682cc1295b392c",
  "block": 26453213,
  "trx_in_block": 19,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-10-02T10:58:45",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "golos",
      "author": "golos",
      "permlink": "technical-specification-for-workers-possible-scenarios",
      "title": "Technical specification for Workers. Possible scenarios",
      "body": "@@ -11853,15 +11853,75 @@\n s).%3C/p%3E%0A\n+%3Cp%3E%3Cbr%3E%3C/p%3E%0A%3Cp%3E%3Cimg src=%22https://imgur.com/a/etiWCIi%22/%3E%3C/p%3E%0A\n %3C/html%3E\n",
      "json_metadata": "{\"tags\":[\"golos\",\"blockchain\",\"eos\",\"code\",\"transition\"],\"users\":[\"denis4inet\"],\"app\":\"steemit/0.1\",\"format\":\"html\",\"image\":[\"https://imgur.com/a/etiWCIi\"]}"
    }
  ]
}

{
  "trx_id": "230568697754285c0c11c35900170cdfc94cdff0",
  "block": 26453119,
  "trx_in_block": 37,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-10-02T10:54:03",
  "op": [
    "vote",
    {
      "voter": "steeming-hot",
      "author": "golos",
      "permlink": "technical-specification-for-workers-possible-scenarios",
      "weight": 75
    }
  ]
}

{
  "trx_id": "d61a6b161541f7ff2da26a8d06484ca6da202d0c",
  "block": 26453103,
  "trx_in_block": 11,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-10-02T10:53:15",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "golos",
      "author": "golos",
      "permlink": "technical-specification-for-workers-possible-scenarios",
      "title": "Technical specification for Workers. Possible scenarios",
      "body": "@@ -10718,16 +10718,24 @@\n  stage.%3C\n+/p%3E%0A%3Cp%3E%3C\n br%3E%0A2. R\n@@ -10751,32 +10751,40 @@\n ment conditions:\n+%3C/p%3E%0A%3Cp%3E\n a. The signing o\n",
      "json_metadata": "{\"tags\":[\"golos\",\"blockchain\",\"eos\",\"code\",\"transition\"],\"users\":[\"denis4inet\"],\"app\":\"steemit/0.1\",\"format\":\"html\"}"
    }
  ]
}

{
  "trx_id": "cb5703559a8fb539420413ec7dfa441a92e9fe50",
  "block": 26453083,
  "trx_in_block": 19,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-10-02T10:52:15",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "golos",
      "author": "golos",
      "permlink": "technical-specification-for-workers-possible-scenarios",
      "title": "Technical specification for Workers. Possible scenarios",
      "body": "@@ -1682,17 +1682,16 @@\n ng%3E%3Cbr%3E%0A\n- \n 1. An in\n@@ -11837,27 +11837,15 @@\n s).%3C/p%3E%0A\n-%3Cp%3E%3Cbr%3E%3C/p%3E%0A\n %3C/html%3E\n",
      "json_metadata": "{\"tags\":[\"golos\",\"blockchain\",\"eos\",\"code\",\"transition\"],\"users\":[\"denis4inet\"],\"app\":\"steemit/0.1\",\"format\":\"html\"}"
    }
  ]
}

{
  "trx_id": "7161124d3c7b25681de3a19c2a324bf4790fb34b",
  "block": 26453052,
  "trx_in_block": 7,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-10-02T10:50:42",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "golos",
      "author": "golos",
      "permlink": "technical-specification-for-workers-possible-scenarios",
      "title": "Technical specification for Workers. Possible scenarios",
      "body": "<html>\n<p>Golos • Core team is thrilled to share the latest news related to the blockchain development.</p>\n<p>We’d like to present you a feature of workers that is being developed based on demand from the community. A third-party developer @denis4inet has joined us to accomplish this task for a bounty (approx. 60,000 GOLOS, the final reward amount to be announced after successful completion of the task).&nbsp;</p>\n<p>The main goal of this post is to provide the necessary information to the end users, to describe possible technical issues and to give detailed scenarios with an actual roadmap. Below you will find a technical specification of the feature. This feature is being implemented for the new Golos blockchain as well as the current one.&nbsp;</p>\n<p>One of the most important goals we want to achieve is to ensure the quality control of the development via workers (through technical specification and final work acceptance).&nbsp;</p>\n<p>&nbsp;<strong>Technical specification for the development of workers</strong></p>\n<p><em>Please pay attention to the fact that any technical specification can be corrected and adjusted as a result of the further analysis and comparison of various proposed models of workers in different blockchain systems available.</em></p>\n<p>The &nbsp;funds for workers will be replenished through:</p>\n<ul>\n  <li>Percentage from emission;</li>\n  <li>Voluntary contributions from sponsors.</li>\n</ul>\n<p><strong>Scenario # 1</strong> - Task: The development proposal comes from community&nbsp;</p>\n<p><strong>Scenario # 2</strong> - Task: The code is done and delivered by a worker&nbsp;</p>\n<p><br></p>\n<p>&nbsp;<strong>Scenario # 1</strong><br>\n 1. An incoming proposal from an active member of the community (for example, from a witness, a worker or any other user):</p>\n<p>a. An incoming proposal from an active member of the community manifesting the implementation of any functionality at the expense of funds allocated from the pool.b. Voting and commenting on the proposal given by community members:</p>\n<ul>\n  <li>The proposal is going to collect both positive and negative feedback from the community. In order to simplify the model, reviews won’t have any weight;</li>\n  <li>The voting period is determined by the parameters of the contract (1 week by default, which corresponds to the GOLOS payment window);</li>\n  <li>Community members’ voting is necessary to sort out the offers on the client's side, though it does not imply any restrictions on voting for performance.</li>\n</ul>\n<p>c. The author is capable of deleting his own proposal if his/her proposal has not received any approval yet.d. Transition to the stage of drafting the technical specification.</p>\n<p>&nbsp;</p>\n<p>2. An incoming proposal from a sponsor:a. A proposal comes from someone who wants to fund its development (a sponsor).b. Blocking (or \"freezing\") of funds received from the sponsor on a special account linked to the specific task.c. Voting and commenting on the proposal by community members:</p>\n<ul>\n  <li>The proposal is designed to collect both positive and negative feedback from the community. In order to simplify the model, reviews won’t have any weight;</li>\n  <li>The voting period is determined by the parameters of the contract (1 week by default, which corresponds to the GOLOS payment window);</li>\n  <li>Community members’ voting is necessary to sort out the offers on the client's side, though it does not imply any restrictions on voting for performance.</li>\n</ul>\n<p>d. The sponsor is capable of deleting his own proposal if his proposal has not received any approval yet. The frozen funds will be transferred back to sponsor.e. Transition to the stage of drafting the technical specification.<br>\nFor selected proposals the option “to fill out the technical specification” becomes available.</p>\n<p><br></p>\n<p>&nbsp;3. Technical specification development:<br>\n<em>Drafting of the technical assignment is mandatory in order to prevent the possibility of refund when the work assigned to a worker is incomplete, as well as for work that does not comply with the technical specification.</em></p>\n<p>a. An offer for the development of the technical specification is placed. The scheme for accepting this work is the following:</p>\n<ul>\n  <li>The volume of the technical specification depends on the complexity of the offer;</li>\n  <li>The application must contain the details of the technical specification as well as the estimated time for the assignment of the task by the worker;</li>\n  <li>The application must contain information covering the estimated cost of preparation of the technical specification and the implementation of the task by the worker;</li>\n  <li>The application must contain information related to the possibility of an equal reward within a given time interval.</li>\n</ul>\n<p>b. The witnesses vote for a proposal via voting on applications for development of the technical specification. Each vote of a witness must be accompanied by an explanation of the decision:</p>\n<ul>\n  <li>An application should get approvals from the witnesses. When the required number of votes (50% + 1 of the witnesses) is collected, the review stage of the proposal is considered to be complete and the task of drafting the technical specification will be given out to the developer;</li>\n  <li><em>The estimated costs of both drafting and also the completion of the task by worker should be indicated in the body of the application;</em></li>\n  <li>Consideration refusal. When the required number of votes (50% + 1 of the witnesses) is not collected, the proposal is considered as rejected;</li>\n  <li>Changing one witnesses’ opinion (can’t exceed 1 time). The witness may withdraw his decision which may affect the final result after application examination;</li>\n  <li>Indecision delay. The witness may ask the developer who proposed to write the technical specification to clarify any part of the application before taking any decision;</li>\n  <li>After a certain time, the offer will be eliminated and the blocked (\"frozen\") funds of the sponsor will be refunded.</li>\n</ul>\n<p>c. The blocking (\"freezing\") of a certain amount of the pool funds is allocated to:</p>\n<ul>\n  <li>Development of the technical specification;</li>\n  <li>Work execution and submission of final report.</li>\n</ul>\n<p>d. Development and publication of technical specification.</p>\n<p>e. Transition to the stage of the search for a worker which will execute the technical specification.</p>\n<p><br></p>\n<p>4. Performance stages:</p>\n<p>a. The workers bid for technical tasks. The offer from a worker must contain the following information:</p>\n<ul>\n  <li>Deadlines;</li>\n  <li>Reward amount;</li>\n  <li>Additional information - for instance, a candidate's CV in free form.</li>\n</ul>\n<p>b. The author of the technical specification screens the incoming offers from workers and chooses the best candidate:</p>\n<ul>\n  <li>The author of the technical specification can appoint as the executor himself ;</li>\n  <li>The author of the technical specification can assign the task to the selected worker.</li>\n</ul>\n<p>c. Possible additional funds from sponsors for the assignment:</p>\n<ul>\n  <li>Transfer part of funds allocated for the task execution in a pool from a blocked (\"frozen\") account;</li>\n  <li>Blocking (\"freezing\") of funds received from the sponsors on a special account for the task.</li>\n</ul>\n<p><em>In case of refusal to perform/skip the work in the process by the worker, the funds allocated to this task in the pool become \"unfrozen\" and get transferred to a free state. Any worker refund is not carried out.</em></p>\n<p>d. The task can be executed by the worker only.</p>\n<p>e. The worker must regularly publish the work updates in terms of reports which may include:</p>\n<ul>\n  <li>Date of publication;</li>\n  <li>Short description.</li>\n</ul>\n<p>f. While work is being done, the witnesses can vote with remarks (50% +1 of the witnesses) to mark proposal as unfulfilled and unblock funds in the reward pool.g. The work done is accepted by the author of the technical specification. Compilation and publication of the act on acceptance of the work performed. An incomplete work (work in progress) can not be accepted.</p>\n<p>h. Transition to the stage of reward payment.</p>\n<p><br></p>\n<p>5. Reward payment conditions:a. The signing of the act of acceptance by witnesses. The possible actions of witnesses:</p>\n<ul>\n  <li>Agreement. When the required number of signatures (50% +1 of the number of witnesses) for the delivered word under the act of acceptance is collected, the payment stage starts;</li>\n  <li>Disagreement. If the necessary number of signatures (50% + 1 of the witnesses) under the act of acceptance is not collected, the payment is denied and money is returned to the pool of rewards, as well as to the accounts of the sponsors;</li>\n  <li>Indecision delay. Any witness could ask for clarification related to any part of the act before he/she takes his/her decision.</li>\n</ul>\n<p>b. In the event of approval of the final work by witnesses, the payments for the code delivery and for development of the technical specification are processed in accordance with a schedule of approved payments, or partly (from the \"frozen\" funds of the sponsors and also from the pool of rewards in accordance with the schedule of approved payments).<br>\n&nbsp;</p>\n<p>&nbsp;<strong>Scenario # 2</strong></p>\n<p>1. Submission of the application for payment for code delivery:a. An incoming proposal from a member of the community to pay for any functionality from funds allocated from the pool. The proposal must contain the following:</p>\n<ul>\n  <li>Type: <em><strong>Work executed </strong></em>or a <em><strong>Completed Technical specification</strong></em>;</li>\n  <li>The work acceptance act;</li>\n  <li>Worker’s account;</li>\n  <li>Worker’s reward amount;</li>\n  <li>Payment period. The payment can be made in equal parts for a certain period of time.</li>\n</ul>\n<p>b. Voting and commenting:</p>\n<ul>\n  <li>The proposal is designed to collect both positive and negative feedback from the community. In order to simplify the model, reviews won’t have any weight;</li>\n  <li>The voting period is determined by the parameters of the contract (1 week by default, which corresponds to the GOLOS payment window);</li>\n  <li>Community members’ voting is necessary to sort out the offers on the client's side, though it does not imply any restrictions on voting for performance.</li>\n</ul>\n<p>c. The author is capable of deleting his own proposal if this proposal has not received any approval yet.d. After the end of voting, the application moves to the “reward” stage.<br>\n2. Reward payment conditions:a. The signing of the act of acceptance by witnesses. The possible actions of witnesses:</p>\n<ul>\n  <li>Agreement. When the required number of signatures (50% +1 of the number of witnesses) for the act of construction is collected, everyone is transitioned to the stage of payment of rewards;</li>\n  <li>Disagreement. If the necessary number of signatures (50% + 1 of the witnesses) for the act of construction is not collected, the payment of the fee will be denied and the money will be returned to the pool of rewards, as well as to other accounts of the sponsors;</li>\n  <li>Indecision delay. The witness may ask for clarification related to any part of the act before the witness takes his decision.</li>\n</ul>\n<p>b. In the event of approval of the final work by witnesses, the payment for the work and drafting of the technical specification is carried out from the pool of rewards in accordance with the schedule of approved payments, or partly (from the \"frozen\" funds of the sponsors and also from the pool of rewards in accordance with the schedule of approved payments).</p>\n<p><br></p>\n</html>",
      "json_metadata": "{\"tags\":[\"golos\",\"blockchain\",\"eos\",\"code\",\"transition\"],\"users\":[\"denis4inet\"],\"app\":\"steemit/0.1\",\"format\":\"html\"}"
    }
  ]
}

{
  "trx_id": "44678c2b3c4ed722aabca885206c418d3a29007a",
  "block": 25723100,
  "trx_in_block": 32,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-09-06T13:05:12",
  "op": [
    "vote",
    {
      "voter": "tsto",
      "author": "golos",
      "permlink": "eos-transitioning-getting-into-details",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "3acdb6ce96fa35feb0f040292e337986131a1bf2",
  "block": 25723093,
  "trx_in_block": 6,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-09-06T13:04:51",
  "op": [
    "vote",
    {
      "voter": "tsto",
      "author": "golos",
      "permlink": "eos-transitioning-the-introduction",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "15baf5937fd4f523547d1fd97f0aa7a3f1d919b5",
  "block": 25721132,
  "trx_in_block": 37,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-09-06T11:26:45",
  "op": [
    "comment",
    {
      "parent_author": "golos",
      "parent_permlink": "eos-transitioning-getting-into-details",
      "author": "steemitboard",
      "permlink": "steemitboard-notify-golos-20180906t112647000z",
      "title": "",
      "body": "Congratulations @golos! You have completed the following achievement on the Steem blockchain and have been rewarded with new badge(s) :\n\n[![](https://steemitimages.com/70x80/http://steemitboard.com/notifications/posts.png)](http://steemitboard.com/@golos) Award for the number of posts published\n\n<sub>_Click on the badge to view your Board of Honor._</sub>\n<sub>_If you no longer want to receive notifications, reply to this comment with the word_ `STOP`</sub>\n\n\n\n**Do not miss the last post from @steemitboard:**\n<table><tr><td><a href=\"https://steemit.com/steemfest/@steemitboard/steemfest-steemitboard-support-the-travel-reimbursement-fund\"><img src=\"https://steemitimages.com/64x128/https://cdn.steemitimages.com/DQmawPYDAwfrQM8YU6ejD1f87g64cvsmEFn8RQKHJMs4zxg/image.png\"></a></td><td><a href=\"https://steemit.com/steemfest/@steemitboard/steemfest-steemitboard-support-the-travel-reimbursement-fund\">SteemFest³ - SteemitBoard support the Travel Reimbursement Fund.</a></td></tr></table>\n\n> Support [SteemitBoard's project](https://steemit.com/@steemitboard)! **[Vote for its witness](https://v2.steemconnect.com/sign/account-witness-vote?witness=steemitboard&approve=1)** and **get one more award**!",
      "json_metadata": "{\"image\":[\"https://steemitboard.com/img/notify.png\"]}"
    }
  ]
}

{
  "trx_id": "d10790d37295c298a6001dd42106fb289b767cb0",
  "block": 25717023,
  "trx_in_block": 71,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-09-06T08:01:15",
  "op": [
    "vote",
    {
      "voter": "alphabot",
      "author": "golos",
      "permlink": "eos-transitioning-getting-into-details",
      "weight": 100
    }
  ]
}

{
  "trx_id": "9e1fe404beeb34774db7cc28fa328a29f861cb11",
  "block": 25717020,
  "trx_in_block": 10,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-09-06T08:01:06",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "golos",
      "permlink": "eos-transitioning-getting-into-details",
      "title": "EOS transitioning: getting into details",
      "body": "@@ -670,24 +670,36 @@\n trong%3E%3C/h2%3E%0A\n+%3Cp%3E%3Cbr%3E%3C/p%3E%0A\n %3Cp%3ETo study \n@@ -911,24 +911,24 @@\n . %3C/p%3E%0A\n-\n %3Cp%3EDuring th\n@@ -4934,24 +4934,36 @@\n trong%3E%3C/h2%3E%0A\n+%3Cp%3E%3Cbr%3E%3C/p%3E%0A\n %3Cp%3EThis post\n@@ -9693,24 +9693,36 @@\n le API%3C/h2%3E%0A\n+%3Cp%3E%3Cbr%3E%3C/p%3E%0A\n %3Cp%3EThe next \n@@ -11486,16 +11486,28 @@\n on%3C/h2%3E%0A\n+%3Cp%3E%3Cbr%3E%3C/p%3E%0A\n %3Cp%3EWhat \n@@ -13889,16 +13889,28 @@\n es%3C/h2%3E%0A\n+%3Cp%3E%3Cbr%3E%3C/p%3E%0A\n %3Cp%3EAs me\n@@ -15694,24 +15694,24 @@\n d data.%3C/p%3E%0A\n-\n %3Ch2%3ETheory a\n@@ -15727,16 +15727,28 @@\n ce%3C/h2%3E%0A\n+%3Cp%3E%3Cbr%3E%3C/p%3E%0A\n %3Cp%3EThe c\n",
      "json_metadata": "{\"tags\":[\"blockchain\",\"transition\",\"eos\",\"dev\",\"golos\"],\"links\":[\"https://steemit.com/golos/@golos/eos-transitioning-the-introduction\"],\"app\":\"steemit/0.1\",\"format\":\"html\"}"
    }
  ]
}

{
  "trx_id": "be16b8749a7ee316bc60d722487cd694eca5606d",
  "block": 25717002,
  "trx_in_block": 31,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-09-06T08:00:12",
  "op": [
    "vote",
    {
      "voter": "fastresteem",
      "author": "golos",
      "permlink": "eos-transitioning-getting-into-details",
      "weight": 100
    }
  ]
}

{
  "trx_id": "5143e960ac8b1aaa7b4a17701b30e6dde11f09d2",
  "block": 25716999,
  "trx_in_block": 53,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-09-06T08:00:03",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "golos",
      "permlink": "eos-transitioning-getting-into-details",
      "title": "EOS transitioning: getting into details",
      "body": "@@ -18018,135 +18018,8 @@\n h3%3E%0A\n-%3Cp%3E%3Cbr%3E%3C/p%3E%0A%3Cp%3E%3Cbr%3E%3C/p%3E%0A%3Cp%3E%3Cbr%3E%3C/p%3E%0A%3Cp%3E%3Cbr%3E%3C/p%3E%0A%3Cp%3E%3Cbr%3E%3C/p%3E%0A%3Cp%3E%3Cbr%3E%3C/p%3E%0A%3Cp%3E%3Cbr%3E%3C/p%3E%0A%3Cp%3E%3Cbr%3E%3C/p%3E%0A%3Cp%3E%3Cbr%3E%3C/p%3E%0A%3Cp%3E%3Cbr%3E%0A %3C/p%3E%0A\n %3C/ht\n",
      "json_metadata": "{\"tags\":[\"blockchain\",\"transition\",\"eos\",\"dev\",\"golos\"],\"links\":[\"https://steemit.com/golos/@golos/eos-transitioning-the-introduction\"],\"app\":\"steemit/0.1\",\"format\":\"html\"}"
    }
  ]
}

{
  "trx_id": "28d83f8c3943a4630ec257985c687bef3ec046c5",
  "block": 25716994,
  "trx_in_block": 12,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-09-06T07:59:48",
  "op": [
    "vote",
    {
      "voter": "ax3",
      "author": "golos",
      "permlink": "eos-transitioning-getting-into-details",
      "weight": 100
    }
  ]
}

{
  "trx_id": "567d580a819168e29338ef8ad06ebc0cbd8c72d4",
  "block": 25716991,
  "trx_in_block": 31,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-09-06T07:59:39",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "blockchain",
      "author": "golos",
      "permlink": "eos-transitioning-getting-into-details",
      "title": "EOS transitioning: getting into details",
      "body": "<html>\n<p>&nbsp;A lot of users have both questions and doubts regarding the variety of directions related to the possible scenario of Golos Сore transition to the EOS code base. This post is not an attempt to cover all of those &nbsp;questions, it serves as one of the introductory parts. The possible quantity of parts is difficult to predict at the very moment since the number of questions may grow as new details of the move to the new platform emerge.<br>\nIt is important to point that now we are at the end of research of the EOS code base. In this post we will elaborate on technical issues.</p>\n<p><br></p>\n<h2><strong>Transitioning to EOS (Part 1: Research)</strong></h2>\n<p>To study the options for further development of Golos project we initiated a research on EOS platform. The original goal was to study EOS in order to be able to import technical improvements into the Golos codebase.&nbsp;</p>\n<p>During the study process it became quite clear that the best way could be to fork EOS, introduce certain changes and move Golos to completely new blockchain with absolutely new opportunities for our community. Golos Core in this case could focus on blockchain development rather than being forced to make changes for the end clients of the blockchain.</p>\n<p>For research purposes only, we have divided current Golos architecture into the following subsystems and analyzed the intersections with the EOS platform:</p>\n<ol>\n  <li>Built-in database in shared memory</li>\n  <li>Network subsystem</li>\n  <li>Transaction verification subsystem with hierarchical authorization system</li>\n  <li>Bandwidth subsystem</li>\n  <li>Add-in over database with routines and consensus indices</li>\n  <li>Set of operations and operation handlers&nbsp;</li>\n  <li>Set of plugins for additional processing of information entering the blockchain</li>\n  <li>API for issuing information from a block and from the database of all blocks signed</li>\n</ol>\n<p>All the operations above as well as their handlers we divided into the following subgroups:</p>\n<ol>\n  <li>Accounts (profile, keys, recovery, authority)</li>\n  <li>Posts and comments (creation, editing, deleting, beneficiary system)</li>\n  <li>Voting for posts</li>\n  <li>Market (transfers, conversions taking into account the restrictions imposed on transfers between 3 types of assets: GBG, delegation, etc.)</li>\n  <li>Witnessing system (voting, changing parameters, mining)</li>\n  <li>Transaction proposals</li>\n  <li>Custom operation for plugins</li>\n</ol>\n<p>We have identified the following subsystems for analysis in the EOS codebase:</p>\n<ol>\n  <li>Database in a shared memory similar to Golos</li>\n  <li>Network subsystem</li>\n  <li>Transaction verification subsystem with hierarchical authorization system</li>\n  <li>Bandwidth accounting subsystem</li>\n  <li>Block manufacturers</li>\n  <li>Virtual machine WebAssembler for smart contracts</li>\n  <li>Business logic layer linking accounts, bandwidth and smart contracts in a virtual machine</li>\n  <li>Smart contracts library</li>\n</ol>\n<p>During the analysis we figured out which systems could be inherited by the new Golos blockchain (Golos on the EOS codebase) - for further details, <a href=\"https://steemit.com/golos/@golos/eos-transitioning-the-introduction\">see our previous post</a>.</p>\n<p>To make your life easier we will list them again. When migrating to the new Golos platform the following subsystems from EOS can be inherited:</p>\n<ol>\n  <li>Built-in database (explanation below)</li>\n  <li>Network subsystem</li>\n  <li>Adapted account system to the requirements for migrating Golos users</li>\n  <li>Transaction verification subsystem with the hierarchical authorization system and with the necessary changes for Golos platform</li>\n  <li>Bandwidth accounting subsystem</li>\n  <li>Block producers with the changes, some of which were mentioned in the post of Nikolai Stefan</li>\n  <li>Subsystem market in smart contracts</li>\n  <li>Transaction proposal in smart contracts</li>\n</ol>\n<p><br></p>\n<p>The current Golos economy could be implemented in the form of the following smart contracts:</p>\n<ol>\n  <li>User profiles</li>\n  <li>Create / edit / delete posts / comments, vote for posts</li>\n  <li>Rules for converting a token into a vest, token issuance</li>\n</ol>\n<p><br></p>\n<p>In addition to that the following smart contracts can be added into the new blockchain:</p>\n<ol>\n  <li>Application moderators - those who set the rules for the application tokens issuance and distribution, the rules for bandwidth distribution among application users</li>\n  <li>Application workers - those who develope application codebase</li>\n</ol>\n<p><br></p>\n<p>In this post we will go deeper into the changes we want to implement. According to our estimates, the Golos Core team of 7 C ++ programmers can develop the proposed solutions within 6 months.</p>\n<p><br></p>\n<h2><strong>Technical drawbacks of Golos</strong></h2>\n<p>This post is also intended to provide answers to the questions that are left after our first post. As it was stated before, a task of transition is to create a new competitive advantage for the Golos.</p>\n<p>When considering the possibility of an integration with the new platform, third-party observers may have an improper impression that the following implementation requires an immense amount of code to be transferred but, fortunately, this does not match the reality, and one of the goals of this post is to outline all the obvious reasons in detail.</p>\n<p><br></p>\n<p><strong>Burdensome heritage&nbsp;</strong></p>\n<p>First of all, the current Golos codebase seems to be overloaded with conditional operators necessary to support economy transition from one state to another. All the past Golos hardforks were inherited from Steem and left traces in the code. These conditional operators make it difficult to add new functionality. They can be reworked (the famous refactoring) but it will require loads of resources without any functional bonuses.</p>\n<p>There are different ways that could help to get rid of the inherited burden. And each has their pros and cons.</p>\n<p>The transition to any new platform allows you to preserve the current Golos economy, but get rid of all discrepancies that had been pending since the times of Bitshares and move faster in adding new functionality.</p>\n<p>What are the advantages of switching to a system built on the EOS codebase (we’d like to underline that it's not about switching to EOS directly)?</p>\n<p>The technology of smart contracts lets free the code from storing of conditional operators, as loading a smart contract into a blockchain is a standard operation as well as data loading. The smart contract does not need to store all the conditions of economic transition because it will not receive and process the old data.</p>\n<p>This significantly reduces the amount of code that we have to move to the new platform.</p>\n<p><br></p>\n<p><strong>Inefficient database</strong></p>\n<p>Secondly, Golos daemon currently performs a lot of tasks: from synchronizing data on the network to issuing information on requests from blockchain clients. Each layer uses its own set of technologies. The issue that we would like to focus on is the storage subsystem that allows storing the system state (in fact, the database inside the daemon). The implementation built on boost :: multi_index immensely simplifies the business logic inside the application. But the database is not only a convenience in the implementation of business logic. For this database to be efficient it has to have several different subsystems.</p>\n<p>At the moment, these subsystems are not present in the daemon. With enough RAM the daemon has direct access to the data without any middlemen.</p>\n<p>But do not forget the details. In order for a daemon to have the ability to issue information and not just modify it, there is a single mutex in the code that allows a lot of read requests and completely blocks access to data when it needs to be changed. This leads to the fact that read requests block the execution of transactions from the newcomer blocks. When there are new transactions for changing the data there is a complete blocking of the read requests. The set of databases that exist in the IT world has a lot of strategies for blocking both individual tables and point locking of individual records. In Golos daemon only one strategy is implemented: global blocking of access to all data.</p>\n<p>If you look at the history of commits, you can find out that Golos Core has recycled the system of locks, introduced new mechanics to improve “daemon sensitivity”. The result was not only a growth in daemon responsiveness, but also greater data integrity. For comparison, in the Steem code, and even in the EOS code, there are still bugs that lead to data corruption under certain conditions. Perhaps some of you remember an error when at the start of the daemon you encountered a locked state. Or that to solve this problem it was required to delete the file shared_memory.meta (which now by the way is not there at all).</p>\n<p>The daemon work is directly related to the responsiveness of the system as a whole. To address the issue of responsiveness all the existing Golos clients export data to external databases and use their capabilities to respond to queries. And that is not all. Everyone is accustomed to doing replay when a new version of the daemon is released, although only a couple of fields in the non-consensus data component have changed.</p>\n<p>All this makes us wonder is there a real need or necessity to store the system state in the format that is used now?</p>\n<h2>The inflexible API</h2>\n<p>The next point is the need to implement your API layer inside the daemon as there is no other way to get data from the state, because only the daemon knows how they are stored. This API is a rigidly fixed set of functions with a set of arguments.</p>\n<p>You might remember hot dicussions around API cchanges as the functionality of clients is strictly limited by the set of functions and the slightest changes in the API lead to the need to rewrite the clients.</p>\n<p>To implement the API layer in the daemon, there are many plug-ins, each with its own business logic, which does not participate in consensus at all. Any new client for the blockchain has to adjust to the current API. This is nonsense in the modern IT world. As a result Golos blokchain has long been a blockchain of one application golos.io.</p>\n<p>The Golos Core team spends a lot of time processing and fixing bugs in APIs and plugins, which, by and large, is done to maintain the functionality of one client. And for the implementation of some new functionality, the client - golos.io - is forced to wait for the release of a new softfork.</p>\n<p>We would like to expand daemon capabilities and add to it the flexibility in query processing by implementing GraphQL or any other mechanism for processing incoming requests and generating responses to them. Is this reasonable? This will make the blockchain itself almost a database, although it will still be a bit far from it.</p>\n<p>From what is mentioned it’s clear that Golos (from a technical point of view) is all about distributed database with a very thick and very tough API layer. Getting rid of the API will significantly reduce an amount of code that has to be transferred to the new platform.</p>\n<p><br></p>\n<h2>Improving imperfection</h2>\n<p>What captivates us in EOS? First, it has the same storage system as Golos and Steem. But there is a significant difference which is EOS RAM. The cost of storing data in EOS is such that moving Golos on it as an application becomes extremely expensive. There is one large hash table in EOS for data access, the keys are a username, a name of the smart contract, a table name, a key id in the table. As a value a row of the smart contract table is used. This is what allows you to keep track of user-consumed RAM.</p>\n<p><br></p>\n<p><strong>External database</strong></p>\n<p>The solution we are proposing is to export of data to an external database and a transformation of the new blockchain into a controller over the database.</p>\n<p>The Golos code has a plugin that can export data to MongoDB, however, this is not a solution that will make data access flexible. The plan is to integrate more deeply blockchain and the external database and it consists of the following stages:</p>\n<p>- Create an access interface from the boost :: multi_index library to an external data source</p>\n<p>- Create a data cache layer in the daemon's RAM</p>\n<p>- Write a driver for access to MongoDB</p>\n<p>The blockchain will store its state in the external database and not in the internal data format. EOS RAM in our blockchain will cease to exist in its EOS terms, but will become a data caching layer, the bandwidth to which will be accounted similar to the rules that are defined in EOS for bandwidth accounting for a network subsystem and a CPU subsystem.</p>\n<p>Data storage setup of several layers enables an easy addition of drivers for other types of databases that can be better suited for different types of nodes. For example, using RocksDB or LevelDB as databases can allow a node to be held without external dependencies with less requirements on system resources. This type of repository may be better suited for seed or delegate nodes.</p>\n<p>This approach has a number of advantages:</p>\n<ol>\n  <li>Flexible access to data thanks to the power of modern databases</li>\n  <li>High speed processing of read requests&nbsp;</li>\n  <li>Availability of tools for data backup</li>\n  <li>Availability of tools for expanding the data structure without a need for a replay&nbsp;</li>\n  <li>Ability to scale data storage using modern databases</li>\n</ol>\n<p><br></p>\n<h2>Technical difficulties</h2>\n<p>As mentioned earlier, not all technical issues are crystal clear. There are a number of possible technical barriers that have to be investigated.</p>\n<p>One possible problem is an increased access time to data since this is an external storage. This point is critical since a blockchain node has to be able to process the blocks. And this is superimposed on the fact that the time between blocks in the classic EOS is only half a second. The situation is a little bit improved by the fact that a node while storing data in an external database stops processing requests for information, and it only needs to do several requests for a change when processing a transaction. Even if this is not enough in the new EOS-based blockchain we can increase a processing time for each block.</p>\n<p>The next problem is data integrity when a node is stopped. It is not critical as a blockchain has a built-in session mechanism for rolling back the blocks for forks and for rolling back of transactions when a new block is received. This mechanism is perfectly integrated with the database transaction mechanism. As we have a chain of blocks with transactions, we can restore the system state from any stop point.</p>\n<p>And perhaps the last technical issue is a &nbsp;trust factor. A node has to trust to the data stored in the external storage. To be frank, trust to a system state exists in the classical Golos as well as it is difficult to verify data integrity if they are issued on demand. To solve this problem one can add a private-public key pair for each node of the blockchain. So, a node will be able to sign the exported data with the key and check their integrity when downloading from the repository. Similarly, a client will be able to verify data integrity by checking downloaded data.</p>\n<h2>Theory and practice</h2>\n<p>The community may have a feeling that the ongoing research and preparation for the move can freeze the development of Golos blockchain. But thanks to the similarity of projects, prototyping of the external storage - if desired by delegates and community - can be implemented on Golos platform (taking into account the benefits that external storage can bring to the system, it seems a reasonable action). As storage implementation for two blockchains is the same, this will allow us to test the theory by implementing this technology in the current Golos.</p>\n<p>Below is a plan we have for transferring data to the external database.</p>\n<p><strong>1 stage of implementation:</strong></p>\n<p>- To implement interface at the boost :: multi_index level to access the external data store</p>\n<p>- To implement interfaces for integrating chainbase session objects into an external data store transaction</p>\n<p>- To develop a driver for storing data in MongoDB</p>\n<p><strong>1 stage of testing:</strong></p>\n<p>- To measure time required for a complete replay of the blockchain with the same set of plug-ins on the same hardware with internal and external data storage</p>\n<p>- to write load tests with a heterogeneous set of transactions in blocks</p>\n<p>- To measure time necessary to perform different types of transactions</p>\n<p><strong>2 stage of implementation:</strong></p>\n<p>- To add data verification mechanisms to the external data store</p>\n<p><strong>2 stage of testing:</strong></p>\n<p>- To re-measure time with the data verification mechanism turned on</p>\n<p><strong>3 stage of implementation:</strong></p>\n<p>- To add a layer of data caching in RAM from the external storage</p>\n<p><strong>3 stage of testing:</strong></p>\n<p>- To re-measure time with data caching enabled and with the data verification mechanism turned on / off</p>\n<p><em>+ Release of the product version of Golos blockchain with data storage in MongoDB.</em></p>\n<p><br></p>\n<h3>All the processes listed above could be implemented within 2 months. After the 1st phase of implementation it will be possible to deploy Golos blockchain with an external data store, allowing the community enthusiasts to test the new technology.</h3>\n<h3>During next stage the external database could be converted into the genesis of the blockchain built on a new platform.</h3>\n<p><br></p>\n<p><br></p>\n<p><br></p>\n<p><br></p>\n<p><br></p>\n<p><br></p>\n<p><br></p>\n<p><br></p>\n<p><br></p>\n<p><br>\n&nbsp;</p>\n</html>",
      "json_metadata": "{\"tags\":[\"blockchain\",\"transition\",\"eos\",\"dev\",\"golos\"],\"links\":[\"https://steemit.com/golos/@golos/eos-transitioning-the-introduction\"],\"app\":\"steemit/0.1\",\"format\":\"html\"}"
    }
  ]
}

{
  "trx_id": "1f59f1e9dfa16f3acf85a6da55332ac4885b262c",
  "block": 25027780,
  "trx_in_block": 58,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-08-13T09:22:12",
  "op": [
    "claim_reward_balance",
    {
      "account": "golos",
      "reward_steem": "0.056 STEEM",
      "reward_sbd": "0.074 SBD",
      "reward_vests": "217.100882 VESTS"
    }
  ]
}

{
  "trx_id": "1cfbe7218696a483cd6e94d34eb3ac143ebe5cda",
  "block": 25027749,
  "trx_in_block": 30,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-08-13T09:20:39",
  "op": [
    "vote",
    {
      "voter": "golos",
      "author": "dahaz159",
      "permlink": "ezira-hangout-19-or-ezira-state-of-the-network-or-2018-8-12-or-1pm-utc",
      "weight": 10000
    }
  ]
}