Deployed contract name support in getContractState

[chenzhitong]

close #426

[shargon]

It will fetch all the smart contracts, we should test it with at least 100k smart contracts. In order to avoid a possible Denial of Service

[superboyiii]

It will fetch all the smart contracts, we should test it with at least 100k smart contracts. In order to avoid a possible Denial of Service

Maybe we could move getcontractstate to somewhere like ApplicationLogs, then it could get contract state indenpently from the beginning just with a little adjustment on that plugin?

[cloud8little]

@devhawk what do you think? if it is possible to cause Denial of Service, we need to reconsider what the API benefits. Otherwise there is no conclusion on this.

[devhawk]

I understand the need for a stable contract identifier, but the choice of generating it from a combination of the original deployed contract hash + the original contract deployer address is not very developer friendly. I think there needs to be a mechanism for developers to be able to retrieve information about their deployed contracts w/o having to understand the algorithm that generates the identification hash.

If we don't make this change to getContractState, another option could be to introduce a new contract search RPC method that returns an array of all contacts identification hashes (along with associated metadata) that matches a given name.

[erikzhang]

I don't think it is possible to map name to contract. Because the name is not unique.

[chenzhitong]

returns an array of all contacts identification hashes (along with associated metadata) that matches a given name.

@erikzhang , Is it okay to do what @devhawk said?

request:
'getcontractstate' or create a new RPC method, such as getcontractbyname?

{
  "jsonrpc": "2.0",
  "method": "getcontractstate",
  "params": ["hello"],
  "id": 1
}

response:
Array of scripthash or contract metadata that matches a given name.

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": [
        "0x99042d380f2b754175717bb932a911bc0bb0ad7d",
        "0x1bc09179180b0ad7bb932540f2b7717bd542d39a"
    ]
}

or

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": [
        {
            "id": 8,
            "hash": "0x99042d380f2b754175717bb932a911bc0bb0ad7d",
            "script": "",
            "manifest": {
                ...
            }
        },
        {
            "id": 9,
            "hash": "0x1bc09179180b0ad7bb932540f2b7717bd542d39a",
            "script": "",
            "manifest": {
                ...
            }
        }
    ]
}

[devhawk]

I don't think getcontractstate should return different data depending on the input parameters as you've mocked up @chenzhitong. I'd rather introduce a new RPC method.

Does the thing we used to call "script hash" have a new name? I called it "invocation hash" in #426 but I just made that up on the fly. I'd suggest getinvocationhashesbyname (or whatever we end up calling it) as the name of the new RPC method.

[ProDog]

For native contract, we supports get contract state by hash, name or id, so I think for the other contracts should also be the same, or support, or don't support name and id.

[chenzhitong]

Related PR #462

[bettybao1209]

Related PR #462

It seems the issue #426 has not been solved.

[devhawk]

It seems the issue #426 has not been solved.

Agreed @bettybao1209

[devhawk]

(sorry, reopened by accident)