diff --git a/docs/api/http.md b/docs/api/http.md index 38014221..48b95d97 100644 --- a/docs/api/http.md +++ b/docs/api/http.md @@ -836,7 +836,7 @@ curl http://127.0.0.1:8090/wallet/getnodeinfo Return: The node information #### wallet/getchainparameters -Description: Query the parameters of the blockchain used for witnessses to create a proposal +Description: Query the parameters of the blockchain used for SR(Super Representatives) to create a proposal ``` curl -X POST http://127.0.0.1:8090/wallet/getchainparameters ``` @@ -1318,7 +1318,7 @@ The following are voting and SR related APIs: - [wallet/getnextmaintenancetime](#walletgetnextmaintenancetime) #### wallet/createwitness -Description: Apply to become a witness +Description: Apply to become a super representative ```console $ curl -X POST http://127.0.0.1:8090/wallet/createwitness -d '{ @@ -1337,7 +1337,7 @@ Return: Transaction object #### wallet/updatewitness -Description: Update the witness' website url +Description: Update the super representative' website url ```console $ curl -X POST http://127.0.0.1:8090/wallet/updatewitness -d '{ @@ -1356,16 +1356,16 @@ Return: Transaction object #### wallet/listwitnesses -Description: Qyery the list of the witnesses +Description: Qyery the list of the super representatives ``` curl -X POST http://127.0.0.1:8090/wallet/listwitnesses ``` Parameters: N/A -Return:witness list +Return:SR(Super Representatives) list #### wallet/withdrawbalance -Description: Withdraw reward to account balance for witnesses +Description: Withdraw reward to account balance for super representatives ```console $ curl -X POST http://127.0.0.1:8090/wallet/withdrawbalance -d '{ @@ -1386,7 +1386,7 @@ Note: It can only withdraw once for every 24 hours #### wallet/votewitnessaccount -Description: Vote for witnesses +Description: Vote for super representatives ```console $ curl -X POST http://127.0.0.1:8090/wallet/votewitnessaccount -d '{ @@ -1403,21 +1403,21 @@ $ curl -X POST http://127.0.0.1:8090/wallet/votewitnessaccount -d Parameters: - `owner_address`: Owner address, default hexString -- `votes`: 'vote_address' stands for the address of the witness you want to vote, default hexString, 'vote_count' stands for the number of votes you want to vote +- `votes`: 'vote_address' stands for the address of the super representative you want to vote, default hexString, 'vote_count' stands for the number of votes you want to vote - `permission_id`: Optional, for multi-signature use Return: Transaction object #### wallet/getBrokerage -Description: Query the ratio of brokerage of the witness +Description: Query the ratio of brokerage of the super representative ```console $ curl -X GET http://127.0.0.1:8090/wallet/getBrokerage -d '{ "address":"41E552F6487585C2B58BC2C9BB4492BC1F17132CD0"}' ``` -Parameter `address`: The address of the witness's account, default hexString +Parameter `address`: The address of the SR's account, default hexString -Return: The ratio of brokerage of the witness +Return: The ratio of brokerage of the SR #### wallet/updateBrokerage Description: Update the ratio of brokerage @@ -1430,7 +1430,7 @@ $ curl -X POST http://127.0.0.1:8090/wallet/updateBrokerage -d '{ Parameters: -- `owner_address`: The address of the witness's account, default hexString +- `owner_address`: The address of the SR's account, default hexString - `brokerage`: The ratio of brokerage you want to update to @@ -2661,13 +2661,13 @@ Return: Two lists will return, one is the list of addresses the account has dele ### Voting & SRs #### walletsolidity/listwitnesses -Description: Query the list of witnesses +Description: Query the list of super representatives ``` curl -X POST http://127.0.0.1:8091/walletsolidity/listwitnesses ``` Parameters: N/A -Return: List of all witnesses +Return: List of all super representatives ### TRC10 Token diff --git a/docs/api/rpc.md b/docs/api/rpc.md index bd453163..4a5313aa 100644 --- a/docs/api/rpc.md +++ b/docs/api/rpc.md @@ -29,7 +29,7 @@ rpc BroadcastTransaction (Transaction) returns (Return) {} Nodes: Fullnode Description: -Transfer, vote, issuance of token, or participation in token offering. Sending signed transaction information to node, and broadcasting it to the entire network after witness verification. +Transfer, vote, issuance of token, or participation in token offering. Sending signed transaction information to node, and broadcasting it to the entire network after super representatives verification. **4. Create an account** @@ -50,7 +50,7 @@ rpc VoteWitnessAccount (VoteWitnessContract) returns (Transaction) {} ``` Nodes: FullNode -**7. Query the ratio of brokerage of the witness** +**7. Query the ratio of brokerage of the super representative** ```protobuf rpc GetBrokerageInfo (BytesMessage) returns (NumberMessage) {} ``` diff --git a/docs/clients/wallet-cli-command.md b/docs/clients/wallet-cli-command.md index 15ebf601..1a5cd043 100644 --- a/docs/clients/wallet-cli-command.md +++ b/docs/clients/wallet-cli-command.md @@ -206,10 +206,10 @@ wallet>UpdateAccountPermission [ownerAddress] [permissions] This command is used to assign permissions to other accounts, is utilized for **multi-signature** transactions, which allows other users to access the account with paritcular permission in order to better manage it. There are three types of permissions: * owner: access to the owner of account -* active: access to other features of accounts, and access that authorizes a certain feature. Block production authorization is not included if it's for witness purposes. -* witness: only for witness, block production authorization will be granted to one of the other users. +* active: access to other features of accounts, and access that authorizes a certain feature. Block production authorization is not included if it's for SR purposes. +* witness: only for super representatives, block production authorization will be granted to one of the other users. -**NOTE** the parameter`Permission` must written in JSON format and entered in line. If the owner accountis not SR, then do not assign witness permission. +**NOTE** the parameter`Permission` must written in JSON format and entered in line. If the owner accountis not SR, then do not assign super representative permission. ```shell wallet> updateaccountpermission TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8 {"owner_permission":{"keys":[{"address":"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8","weight":1}],"threshold":1,"type":0,"permission_name":"owner"},"active_permissions":[{"operations":"7fff1fc0033e0000000000000000000000000000000000000000000000000000","keys":[{"address":"TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej","weight":1},{"address":"TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE","weight":1}],"threshold":2,"type":2,"permission_name":"active12323"}]} { @@ -1886,7 +1886,7 @@ wallet> getproposal 34 Voting requires Tron Power, which can be obtained by freezing funds. ``` -wallet> votewitness [witness address] [Tron Power Amount] +wallet> votewitness [SR(Super Representatives) address] [Tron Power Amount] ``` * The share calculation method is: 1 unit of share can be obtained for every 1TRX frozen. @@ -1898,11 +1898,11 @@ For example: ```shell wallet> freezeBalance 100000000 3 1 address # Freeze 10TRX and acquire 10 units of Tron Power -wallet> votewitness [witness1] 4 [witness2] 6 # Cast 4 votes for witness1 and 6 votes for witness2 at the same time +wallet> votewitness [SR1] 4 [SR2] 6 # Cast 4 votes for SR1 and 6 votes for SR2 at the same time -wallet> votewitness [witness1] 10 # Voted 10 votes for witness1 +wallet> votewitness [SR1] 10 # Voted 10 votes for SR1 ``` -The final result of the above command was 10 votes for witness1 and 0 vote for witness2. +The final result of the above command was 10 votes for SR1 and 0 vote for SR2. ### ListWitnesses @@ -1935,14 +1935,14 @@ wallet> listwitnesses ``` ### GetBrokerage -View the ratio of brokerage of the witness. +View the ratio of brokerage of the SR(Super Representatives). -After voting for the witness, you will receive the rewards. The witness has the right to decide the ratio of brokerage. The default ratio is 20%, and the witness can adjust it. +After voting for the super representative, you will receive the rewards. The super representative has the right to decide the ratio of brokerage. The default ratio is 20%, and the super representative can adjust it. -By default, if a witness is rewarded, he will receive 20% of the whole rewards, and 80% of the rewards will be distributed to his voters. +By default, if a super representative is rewarded, he will receive 20% of the whole rewards, and 80% of the rewards will be distributed to his voters. -`OwnerAddress` is the address of the witness's account, it is a base58check type address. +`OwnerAddress` is the address of the SR's account, it is a base58check type address. ```shell wallet> getbrokerage TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8 The brokerage is : 20 @@ -1959,11 +1959,11 @@ The reward is : 0 ### UpdateBrokerage -Update the ratio of brokerage, this command is usually used by a witness account. +Update the ratio of brokerage, this command is usually used by a super representative account. ``` shell wallet> updateBrokerage [OwnerAddress] [brokerage] ``` -`OwnerAddress` is the address of the witness's account, it is a base58check type address. +`OwnerAddress` is the address of the super representative's account, it is a base58check type address. `brokerage` is the ratio of brokerage you want to update to, the limit of it: 0-100. diff --git a/docs/introduction/dpos.md b/docs/introduction/dpos.md index 3b8eb21b..425e1bd3 100644 --- a/docs/introduction/dpos.md +++ b/docs/introduction/dpos.md @@ -6,12 +6,12 @@ Blockchain is a distributed accounting system. In a blockchain system, there can There are several types of consensus, and the most commonly used are POW, POS, and DPoS. Definitely, different blockchain systems will have a unique way of implementation. This article will mainly introduce the DPoS consensus on which TRON based. We will also explain the basic components and mechanisms of DPoS. ## Block Producing Process -The witnesses of the blockchain network collect the newly generated transactions in the blockchain network and verify the legality of these transactions, then package the transactions in a block, record them as a new page on the ledger, and broadcast the page to the entire blockchain network. Other nodes will receive the new page and verify the legality of the transaction data on the page and add it to their own ledger. The witnesses will repeat this process so all new transaction data in the blockchain system can be recorded in the ledger. +The SR(Super Representatives) of the blockchain network collect the newly generated transactions in the blockchain network and verify the legality of these transactions, then package the transactions in a block, record them as a new page on the ledger, and broadcast the page to the entire blockchain network. Other nodes will receive the new page and verify the legality of the transaction data on the page and add it to their own ledger. The SR(Super Representatives) will repeat this process so all new transaction data in the blockchain system can be recorded in the ledger. ## DPoS overview -The role of consensus is to select the witnesseses in the blockchain system. The witnesseses verify the transaction data and keep the account in order to broadcast new accounts to other nodes in the network and obtains the approval of the new accounts from other nodes. As a specific implementation of consensus, DPoS works in the following way: +The role of consensus is to select the SR(Super Representatives) in the blockchain system. The SR(Super Representatives) verify the transaction data and keep the account in order to broadcast new accounts to other nodes in the network and obtains the approval of the new accounts from other nodes. As a specific implementation of consensus, DPoS works in the following way: -The DPoS consensus selects some nodes as witnesseses in the blockchain system based on the number of votes they receive. First, when the blockchain system starts to operate, a certain number of tokens will be issued, and then the tokens will be given to nodes in the blockchain system. A node can apply to be a witnesses candidate in the blockchain system with a portion of the tokens. Any token-holding node in the blockchain system can vote for these candidates. Every t period of time, the votes for all the candidates will be counted. Top N candidate nodes with the most votes will become witnesseses for the next t period. After t period of time, the votes will be counted again to elect the new witnesseses, and the cycle continues. +The DPoS consensus selects some nodes as SR(Super Representatives) in the blockchain system based on the number of votes they receive. First, when the blockchain system starts to operate, a certain number of tokens will be issued, and then the tokens will be given to nodes in the blockchain system. A node can apply to be a super representative candidate in the blockchain system with a portion of the tokens. Any token-holding node in the blockchain system can vote for these candidates. Every t period of time, the votes for all the candidates will be counted. Top N candidate nodes with the most votes will become SR(Super Representatives) for the next t period. After t period of time, the votes will be counted again to elect the new SR(Super Representatives), and the cycle continues. Let's see how it's realized in the context of TRON: @@ -20,13 +20,13 @@ Let's see how it's realized in the context of TRON: - TRON token: refers to the equity token issued by and circulating in TRON, known as TRX. -- Witnesses candidates: nodes eligible for becoming witnesseses in TRON. +- super representative candidates: nodes eligible for becoming super representatives in TRON. -- Witnesses: nodes in TRON qualified for book-keeping. They are usually called witnesses in DPoS consensus. In TRON, there will be 27 witnesseses, which are also called super nodes (or SR). Here, we will not distinguish between bookkeeper, witness, supernode, SR, etc. +- SR(Super Representatives): nodes in TRON qualified for book-keeping. They are usually called super representatives in DPoS consensus. In TRON, there will be 27 super representatives, which are also called super nodes (or SR). Here, we will not distinguish between bookkeeper, witness, supernode, SR, etc. - Bookkeeping: the process of verifying transactions and recording them in a ledger. Because ledgers in TRON are carried by blocks, the bookkeeping process is also called block generation. We will not distinguish between bookkeeping and block generation in the document. -- Bookkeeping order: block generation order. The descending order of the 27 witnesseses based on the number of votes they receive. +- Bookkeeping order: block generation order. The descending order of the 27 super representatives based on the number of votes they receive. - Slot: In TRON, every three seconds is regarded as one slot. Under normal circumstances, each SR will produce a block within the corresponding slot time. Therefore, the average block interval of TRON is approximately three seconds. If an SR fails to produce a block for some reasons, the corresponding slot will be vacant and the next SR will produce a block in the following slot. During the maintenance period, block production will skip two slots. @@ -47,41 +47,41 @@ In TRON, voting for candidates is a special transaction. Nodes can vote for cand 3. Vote counting -During each maintenance period, the votes for candidates will be counted. The top 27 candidates with the most votes will be the witnesses for the next Epoch. +During each maintenance period, the votes for candidates will be counted. The top 27 candidates with the most votes will be the super representatives for the next Epoch. ## Block generation mechanism -During each Epoch, the 27 witnesses will take turns to generate blocks according to the bookkeeping order. Each witness can only generate blocks when it is their turn. Witnesses package the data of multiple verified transactions into each block. The hash of the previous block will be included in each new block as the parentHash. The witness will sign the data of this block with his/her private key and fill in witness_signature, along with the address of the witness, the block height, and the time that block is generated, etc. +During each Epoch, the 27 super representatives will take turns to generate blocks according to the bookkeeping order. Each super representative can only generate blocks when it is their turn. Super representatives package the data of multiple verified transactions into each block. The hash of the previous block will be included in each new block as the parentHash. The super representative will sign the data of this block with his/her private key and fill in witness_signature, along with the address of the super representative, the block height, and the time that block is generated, etc. Through storing the hash of the previous block, blocks are logically connected. Eventually, they form a chain. A typical blockchain structure is shown in the following picture: ![image](https://raw.githubusercontent.com/tronprotocol/documentation-en/master/images/blockchain_structure.png) -In ideal circumstances, the bookkeeping process in a DPoS consensus-based blockchain system proceeds according to the bookkeeping order calculated in advance. Blocks are generated by witnesses in turn (see figure a). However, in reality, the blockchain network is a distributed and untrusted complex system in the following three ways. -- Due to poor network environment, blocks generated by some witnesses cannot be received by other witnesses in valid time (see figure b1 and b2). -- The normal operation of a certain witness cannot always be guaranteed (see figure c). -- Some malicious witnesses will generate fork blocks in order to fork the chain (see figure d). +In ideal circumstances, the bookkeeping process in a DPoS consensus-based blockchain system proceeds according to the bookkeeping order calculated in advance. Blocks are generated by super representatives in turn (see figure a). However, in reality, the blockchain network is a distributed and untrusted complex system in the following three ways. +- Due to poor network environment, blocks generated by some super representatives cannot be received by other super representatives in valid time (see figure b1 and b2). +- The normal operation of a certain super representative cannot always be guaranteed (see figure c). +- Some malicious super representatives will generate fork blocks in order to fork the chain (see figure d). ![image](https://github.com/tronprotocol/documentation-en/raw/master/images/longest_chain1_en.jpg) ![image](https://github.com/tronprotocol/documentation-en/raw/master/images/longest_chain2_en.jpg) -As mentioned above, the basis for the blockchain system to operate normally is that most of the nodes in the system are honest and reliable. Furthermore, the primary guarantee for the security of the blockchain system is the security of the ledger, meaning that illegal data cannot be written into the ledger maliciously and ledger copies saved on each node should be consistent as well. Based on the DPoS consensus, the bookkeeping process is carried out by witnesses. Therefore, the safety of TRON depends on the reliability of the majority of the witnesses. TRON has put confirmed blocks in the system which are irreversible. At the same time, in order to resist the malicious behaviors of a small number of witness nodes, TRON recognizes the longest chain as the main chain based on "the longest chain principle". +As mentioned above, the basis for the blockchain system to operate normally is that most of the nodes in the system are honest and reliable. Furthermore, the primary guarantee for the security of the blockchain system is the security of the ledger, meaning that illegal data cannot be written into the ledger maliciously and ledger copies saved on each node should be consistent as well. Based on the DPoS consensus, the bookkeeping process is carried out by super representatives. Therefore, the safety of TRON depends on the reliability of the majority of the super representatives. TRON has put confirmed blocks in the system which are irreversible. At the same time, in order to resist the malicious behaviors of a small number of super representatives nodes, TRON recognizes the longest chain as the main chain based on "the longest chain principle". **The confirmed block principle** -The newly produced blocks are in unconfirmed state, and only those blocks that are "approved" by more than 70% (i.e. 27 * 70% = 19, rounded down) of the 27 Witnesses are considered to be irreversible blocks, commonly referred to as solidified blocks, and the transactions contained in the solidified blocks have been confirmed by the entire blockchain network. The way to "approve" the unconfirmed state block is that the Witness producing subsequent blocks after it, as shown in Figure d, the Witness C produces block 103, the Witness E produces 104' on the basis of block 103, the block 105', 106', and 107' produced respectively by the Witness G, A and B, are also subsequent blocks of the 103rd block, which means these four blocks approve the 103rd block. It can be seen that when the block of height 121 is produced, the 103rd block becomes a solidified block, since by this time the 103rd block has 19 subsequent blocks, and the point to be emphasized here is that the Witnesses producing these 19 blocks must be different from each other and from the Witnesses producing the 103rd block. +The newly produced blocks are in unconfirmed state, and only those blocks that are "approved" by more than 70% (i.e. 27 * 70% = 19, rounded down) of the 27 super representatives are considered to be irreversible blocks, commonly referred to as solidified blocks, and the transactions contained in the solidified blocks have been confirmed by the entire blockchain network. The way to "approve" the unconfirmed state block is that the SR producing subsequent blocks after it, as shown in Figure d, the SR C produces block 103, the SR E produces 104' on the basis of block 103, the block 105', 106', and 107' produced respectively by the SR G, A and B, are also subsequent blocks of the 103rd block, which means these four blocks approve the 103rd block. It can be seen that when the block of height 121 is produced, the 103rd block becomes a solidified block, since by this time the 103rd block has 19 subsequent blocks, and the point to be emphasized here is that the super representatives producing these 19 blocks must be different from each other and from the super representatives producing the 103rd block. **The longest chain principle** -When a fork occurs, an honest witness would always choose to produce blocks on the longest chain. +When a fork occurs, an honest super representative would always choose to produce blocks on the longest chain. ## Incentive model To ensure the safe and efficient operation of the blockchain system, TRON sets up an incentive model to encourage more nodes to join the network, thereby expanding the scale of the network. Every time a block is generated by the TRON network, a block reward of 16 TRX will be awarded to the super representative who produced the block, and a voting reward of 160 TRX will be awarded to all super representatives and super partners (super representative candidates who ranking 28th~ 127th are also called super partners), and they share the voting rewards proportionally according to the number of votes they get. At the same time, super representatives and partners will also deduct the rewards according to their commission ratio, and distribute the remaining part to voters according to the voter voting ratio. ## Proposal-based parameter adjustment -An important characteristic of DPoS is that any parameter adjustment can be proposed on the chain, and witnesses will decide whether to approve the proposal by starting a vote. The advantage of this method is that it avoids hard fork upgrades when adding new features. For the current dynamic parameters and values ​​of the TRON network, as well as past proposals, please refer to [here](https://tronscan.org/#/sr/committee). +An important characteristic of DPoS is that any parameter adjustment can be proposed on the chain, and super representatives will decide whether to approve the proposal by starting a vote. The advantage of this method is that it avoids hard fork upgrades when adding new features. For the current dynamic parameters and values ​​of the TRON network, as well as past proposals, please refer to [here](https://tronscan.org/#/sr/committee). ## Appendix: Reference Documentations diff --git a/docs/introduction/overview.md b/docs/introduction/overview.md index 68f443a8..8ffa79a5 100644 --- a/docs/introduction/overview.md +++ b/docs/introduction/overview.md @@ -30,11 +30,11 @@ Example (Using wallet-cli): ```text freezebalancev2 10,000,000 3 // stake 10 TRX to get 10 TRON Power(TP) -votewitness witness1 4 witness2 6 // Vote 4 votes for witness1, 6 votes for witness2 -votewitness witness1 3 witness2 7 // Vote 3 votes for witness1, 7 votes for witness2 +votewitness SR1 4 SR2 6 // Vote 4 votes for SR1, 6 votes for SR2 +votewitness SR1 3 SR2 7 // Vote 3 votes for SR1, 7 votes for SR2 ``` -The final output above is: Vote 3 votes for witness1, 7 votes for witness2 +The final output above is: Vote 3 votes for SR1, 7 votes for SR2 ## 2.3 Reward for Super Representatives @@ -1025,7 +1025,7 @@ receiverAddress: recipient account address |Type|Fee| | :------|:------:| -|Create a witness|9999 TRX| +|Create a SR(Super Representative)|9999 TRX| |Issue a TRC-10 token|1024 TRX| |Create an account|1 TRX| |Create an exchange|1024 TRX| diff --git a/docs/mechanism-algorithm/multi-signatures.md b/docs/mechanism-algorithm/multi-signatures.md index 7e4e3620..d02b20e7 100644 --- a/docs/mechanism-algorithm/multi-signatures.md +++ b/docs/mechanism-algorithm/multi-signatures.md @@ -54,10 +54,10 @@ message AccountPermissionUpdateContract { - `owner_address`: The account applies multi-signatures - `owner`: Owner permission -- `witness`: Witness permission (if is witness) +- `witness`: Witness permission (if the account is a SR(Super Representative)) - `actives`: Active permission -This will override the Original account permission. Therefore, if you only want to modify the owner permission, witness (if it is a witnss account) and active permission also need to be set +This will override the Original account permission. Therefore, if you only want to modify the owner permission, witness (if it is a SR account) and active permission also need to be set #### Permission @@ -126,7 +126,7 @@ Owner permission's features: ### Witness Permission -Super representatives can use this permission to manage block producing. Only witness account has this permission. +Super representatives can use this permission to manage block producing. Only SR(Super Representative) account has this permission. Usage scenario example: A super representative deploys a witness node on cloud server. In order to keep the account on the cloud server safe, you can only give the block producing permission to the account you put on cloud server. Because this account only owns block producing permission, no TRX transfer permission, so even if the account on the cloud server is leaked, the TRX will not be lost. @@ -140,10 +140,10 @@ Witness node configuration: # config.conf // Optional.The default is empty. -// It is used when the witness account has set the witnessPermission. -// When it is not empty, the localWitnessAccountAddress represents the address of the witness account, -// and the localwitness is configured with the private key of the witnessPermissionAddress in the witness account. -// When it is empty,the localwitness is configured with the private key of the witness account. +// It is used when the SR(Super Representative) account has set the witnessPermission. +// When it is not empty, the localWitnessAccountAddress represents the address of the SR(Super Representative) account, +// and the localwitness is configured with the private key of the witnessPermissionAddress in the SR(Super Representatives) account. +// When it is empty,the localwitness is configured with the private key of the SR(Super Representatives) account. //localWitnessAccountAddress = diff --git a/docs/mechanism-algorithm/sr.md b/docs/mechanism-algorithm/sr.md index 335c4afa..b3bff202 100644 --- a/docs/mechanism-algorithm/sr.md +++ b/docs/mechanism-algorithm/sr.md @@ -18,19 +18,19 @@ Example (Using wallet-cli): ```console > freezebalancev2 10,000,000 3 // Stake 10 TRX to get 10 TRON Power(TP) -> votewitness witness1 4 witness2 6 // Vote 4 votes for witness1, 6 votes for witness2 -> votewitness witness1 3 witness2 7 // Vote 3 votes for witness1, 7 votes for witness2 +> votewitness SR1 4 SR2 6 // Vote 4 votes for SR1, 6 votes for SR2 +> votewitness SR1 3 SR2 7 // Vote 3 votes for SR1, 7 votes for SR2 ``` -The final output above is: Vote 3 votes for witness1, 7 votes for witness2 +The final output above is: Vote 3 votes for SR1, 7 votes for SR2. -### Witnesses Brokerage +### Super Representatives Brokerage The default ratio is 20%. Super representatives and super representative partners can query the brokerage ratio through the `wallet/getBrokerage` interface, and can also modify the brokerage ratio through the `wallet/updateBrokerage` interface. -If a witness get 20% of the reward, and the other 80% will be awarded to the voters. If the brokerage ratio is set to 100%, the rewards are all obtained by the witness; if set to 0, the rewards are all sent to the voters. +If a SR(Super Representatives) get 20% of the reward, and the other 80% will be awarded to the voters. If the brokerage ratio is set to 100%, the rewards are all obtained by the SR; if set to 0, the rewards are all sent to the voters. -## Reward for Witnesses +## Reward for SR(Super Representatives) ### Votes Reward @@ -52,13 +52,13 @@ Reward may be less than the theoretical number due to missed blocks and maintena ## Reward for Voters -If you vote for a Super Representative: +If you vote for a SR(Super Representative): -the daily Voter Rewards = (((the number of votes you vote to a witness) * 4,608,000 / total votes) * 80%) + ((460,800 / 27) * 80%) * (the number of votes you vote to a witness) / (the total number of votes a witness receives) TRX +the daily Voter Rewards = (((the number of votes you vote to a SR) * 4,608,000 / total votes) * 80%) + ((460,800 / 27) * 80%) * (the number of votes you vote to a SR) / (the total number of votes a SR receives) TRX If you vote for a Partner: -the daily Voter Rewards = (((the number of votes you vote to a witness) * 4,608,000 / total votes) * 80%) TRX +the daily Voter Rewards = (((the number of votes you vote to a SR) * 4,608,000 / total votes) * 80%) TRX ## Committee