#29 Proposal to enable 3 new VM features

First proposed by: Justin Sun

Proposal submitted by: BlockchainOrg (TRON Foundation)

Description

After the proposal is approved, three new features of TVM (#TRON Virtual Machine) will be opened
: support for parallel signature verification, multiple signature signature verification,
and judge whether the address is the contract address.

After the proposal is approved, it will further enrich the application scenarios of smart contracts.

TIPS included in proposal

Code Changes

Technical information

(source)

1. Support parallel signature verification in TVM

The ‘batchvalidatesign’ keyword can be used in the contract for parallel signature verification:

batchvalidatesign(bytes32 hash, bytes[] signatures, address[] addresses)

Example:

pragma experimental ABIEncoderV2;

contract Demo {
    function testBatch(bytes32 hash, bytes[] memory signatures, address[] memory addresses) public returns(bytes32) {
        return batchvalidatesign(hash, signatures, addresses);
    }
}

Because ‘batchvalidatesign’ is implemented by the precompiled contract (0x9) in TVM, it can also be used in the following way:

function testBatch(bytes memory data) public returns(bool, bytes memory) {
    return address(0x9).delegatecall(data); // data is a parameter that needs to be spliced by itself
}

This new feature can be used to support multiple users to sign the same data content (hash).

batchvalidatesign can verify up to 16 signatures at the same time.

batchvalidatesign consumes 1500 energy to verify per signature. If 5 signatures are verified at the same time, 1500*5 = 7500 energy will be consumed.

2. Support to judge whether the address is a contract address in TVM

In the development of smart contracts, developers may often encounter the situation of calling another contract in a contract, but some contracts may not want to be invoked by other contracts, and the call can be restricted by using ‘isContract’.

For example:

pragma solidity ^0.5.9;
contract Lib {
    modifier onlyHuman {
        require(!msg.sender.isContract, "contract address is restricted");
        _;
    }
}

contract Core is Lib {

    constructor () public  {
    }

    function do_some_thing() internal {}
    function call_a_function()  public onlyHuman returns (bool) {
        do_some_thing();
        return true;
    }
}

contract Client {
    Core core;
    constructor () public  {
        core = new Core();
    }
    function call_core()  public {
        // This will revert because onlyHuman
        core.call_a_function();
    }
}

3. Support multi signature verification in TVM

TRON blockchain supports the multi signature feature of the account, and is widely used in scenarios such as permission control. This time, multi signature feature is also supported in TVM.

In the contract, you can use the validatemultisign keyword for multi signature verification.

validatemultisign(address accountAddress, uint256 permissionId, bytes32 content, bytes[] signatures);

The following example is an application scenario using a multi signature account to transfer to other accounts:

pragma experimental ABIEncoderV2;

contract safeVaultDemo {

    constructor() public payable {
        //can deposit here
    }

    function withDraw(address a, uint256 perid, bytes32 hash, bytes[] memory signatures, address payable toAddress, uint amount) public {
        require(validatemultisign(a, perid, hash, signatures), "validate multiSign error");
        //transfer TRX
        toAddress.transfer(amount);
    }
}

Since validatemultisign is also implemented by the precompiled contract (0xa) in TVM, it can also be used as follows:

function withDraw(bytes memory data, address payable toAddress, uint amount) public returns(bool, bytes memory) {
    require(address(0xa).delegatecall(data), "validate multiSign error"); // data is a parameter that needs to be spliced by itself
    //transfer TRX
    toAddress.transfer(amount);
}

Multi signatures can only support signatures of up to five private keys.

validatemultisign consumes 1500 energy to verify per signature. If three signatures are verified at the same time, 1500 * 3 = 4500 energy will be consumed.

Vote Results

Proposal has gathered enough votes to be approved

Approved By

  • TRON-Family (Candidate)
  • CryptoChain
  • TronWalletMe
  • TronSpark
  • CryptoGuyInZA
  • SR-TRON-Europe (Candidate)
  • bitwirespool
  • Binance Staking
  • BitGuild
  • Infinity-Stones
  • BlockchainOrg (TRON Foundation)
  • JustinSunTron (TRON Foundation)
  • BitTorrent (TRON Foundation)
  • uTorrent (TRON Foundation)
  • TRXMarket (TRON Foundation)
  • TRONScan (TRON Foundation)
  • TRONLink (TRON Foundation)
  • TRONGrid (TRON Foundation)
  • callmeSR (TRON Foundation)
  • TRONALLIANCE (TRON Foundation)
  • TheLastMe (TRON Foundation)
  • Poloniex (TRON Foundation)
  • Huobi_pool

(Candidates do not add to the required 19 votes and are only used to show their support and involvement, consider voting for candidates who actively participate in the elections)

Abstained votes

  • Skypeople
  • Sesameseed
  • KryptoKnight (belongs to Infinity-Stones)
  • HitBTC
  • TRXUltra (belongs to HitBTC)
  • MinerGate (belongs to HitBTC)
1 Like

oh…does it mean only trc20 can communicate with smart contract code?

i might need to reword that. What it means is that you are no longer be able to send TRC10 or TRX directly to a smart contract address from a wallet. Developers are still able to use tokenId, tokenValue, callValue in their smart contract calls.

This change is to prevent users from losing funds because there is currently no way to retrieve TRC10 or TRX which has been directly sent to a smart contract wallet.

2 Likes

ah. I understand. thank you making it more clear.

Thanks for clarifying that Rovak.

JS announces proposal #32 and this is #29. Is there some confusion in the numbers or are they linked?

1 Like

Every proposal is assigned an ID which can be found in the API https://api.trongrid.io/wallet/listproposals and the list of proposals on tronscan.

In this case i use 29 because this proposal has been assigned ID 29 and is the 29th proposal that has been proposed.

Number 32 refers to the ID of the parameter that is changed in the proposal which in my opinion
might cause confusion because it is just an ID in the code and can be changed multiple times by multiple proposals.

Example:

{
  "proposal_id": 29,
  "proposer_address": "41d376d829440505ea13c9d1c455317d51b62e4ab6",
  "parameters": [
    {
      "key": 32,
      "value": 1
    }
  ],
  "expiration_time": 1582524000000,
  "create_time": 1582255857000
}
2 Likes

At this moment the proposal has gathered enough votes to get approved soon. At the time this proposal was made 1 team (TRON Foundation) had more than 9 active Super Representatives which means they have enough SRs to block the vote and puts the other teams in a disadvantage.

Approved By

  • TRON-Family (Candidate)
  • CryptoChain
  • TronWalletMe
  • TronSpark
  • CryptoGuyInZA
  • SR-TRON-Europe (Candidate)
  • bitwirespool
  • Binance Staking
  • BitGuild
  • Infinity-Stones
  • BlockchainOrg (TRON Foundation)
  • JustinSunTron (TRON Foundation)
  • BitTorrent (TRON Foundation)
  • uTorrent (TRON Foundation)
  • TRXMarket (TRON Foundation)
  • TRONScan (TRON Foundation)
  • TRONLink (TRON Foundation)
  • TRONGrid (TRON Foundation)
  • callmeSR (TRON Foundation)
  • TRONALLIANCE (TRON Foundation)
  • TheLastMe (TRON Foundation)
  • Poloniex (TRON Foundation)
  • Huobi_pool

(Candidates do not add to the required 19 votes and are only used to show their support and involvement, consider voting for candidates who actively participate in the elections)

Abstained votes

  • Skypeople
  • Sesameseed
  • KryptoKnight (belongs to Infinity-Stones)
  • HitBTC
  • TRXUltra (belongs to HitBTC)
  • MinerGate (belongs to HitBTC)
2 Likes

Thanks for the update @Rovak does the abstained votes means they do not agree with the proposal or does it mean a “no show” ?

abstained doesn’t specify if they do not agree or no show. I believe Sesameseed provided valid reasons for not approving this proposal.

Because preventing sending TRX or TRC10 to a smart contract doesn’t fix the core problem of not supporting the smart contract fallback functions. And i fully agree with Sesameseed on not approving this. The other SR’s might have approved this proposal to easily and should have required more discussion.

I expressed my thoughts on Discord on this issue:

2 Likes

That is something that can definitely be fixed. Can we make a proposal to change the proposal fields?
-Approved
-Unapproved
-Abstained
-No action
Need to know that SRs are responsive and pressing the buttons when it matters.

1 Like

agree. it is much clear to use assigned ID.