Add an gRPC endpoint for request verification

[ntchjb]

Fixed: BAND-220

When new oracle request is arrived on bandchain, yoda received the event and trying to request data from data provider. When there is a data provider that requires payment in order to access the data, the data provider should setup a server to check the request sent by yoda before providing data. The server may use this gRPC endpoint to verify the request sent by yoda to make sure that data provider will provide data to correct reporter account.

Implementation details

The gRPC endpoint is at /oracle/verify_request. It requires the following information for verification before report the data

• Chain ID
• A validator address
• A request ID
• An data source's external ID
• Public key of a reporter
• Report's signature for the content of RequestVerification proto message.

It will verify the following logic

• Request should not be empty
• Provided chain ID should match validator's chain ID
• Provided signature should be valid, which means this query request should be signed by the given reporter
• Provided reporter should be authorized by the given validator
• Provided request ID should exist on chain
• Provided validator should be assigned to response to the request
• Provided external ID should be required by the request determined by oracle script
• Provided validator should not have reported data for the request
• The request should not be expired

There is also CLI command provided for ease of use and testing.

bandd query oracle verify-request [chain-id] [validator-addr] [request-id] [data-source-external-id] [reporter-addr] [reporter-signature-hex] [flags]

In order to query via grpc-gateway, it can be done by sending GET request to /oracle/v1/verify_request with following parameters

• chain_id: current chain ID
• validator: validator account
• request_id: request ID
• external_id: raw request's external ID
• reporter: reporter's public key in bech32 format
• signature: signature of all above data in base64 format. This can be done by following example code

  // privKey is secp256k1 private key
  privKey, _, err := cosmoscrypto.UnarmorDecryptPrivKey(reporterPrivKey, reporterPrivKeyPasswd)
  requestVerification := oracletypes.NewRequestVerification(chainID, testvaladdr, types.RequestID(requestID), types.ExternalID(externalID))
  // GetSignBytes marshals the struct into JSON and sort all properties in ASC alphanumeric order
  signature, err := privKey.Sign(requestVerification.GetSignBytes())

The following example command sends HTTP GET request

curl -G -X GET \
--data-urlencode "chain_id=bandchain" \
--data-urlencode "validator=bandvaloper1p40yh3zkmhcv0ecqp3mcazy83sa57rgjde6wec" \
--data-urlencode "request_id=0" \
--data-urlencode "external_id=1" \
--data-urlencode "reporter=bandpub1addwnpepqw4dfcp7k93c3xaa6jphvrez9s6f29aaem5eqlaag8ag3xcdgndfs7cda04" \
--data-urlencode "signature=H317sxHzJllFK9X1u1KtTc8jzLzVmVcimdU0d90PzAYSfcrUgTcxkk5WAmdYaF/Ml2p3cAwIMwKN7Wt+LOn7Fw==" \
localhost:1317/oracle/v1/verify_request

Please note that in unit test, there is a method that will be deprecated and unsupported soon, begins at v0.43.0, which is Bech32ifyPubKey (also affeects MustBech32ifyPubKey). Start at v0.43.0, we need to change the way to input reporter's public key by encoding the public key using protobuf's Any type field. See cosmos/cosmos-sdk#7357 for more information

Please ensure the following requirements are met before submitting a pull request:

• The pull request is targeted against the correct target branch
• The pull request is linked to an issue with appropriate discussion and an accepted design OR is linked to a spec that describes the work.
• The pull request includes a description of the implementation/work done in detail.
• The pull request includes any and all appropriate unit/integration tests
• You have added a relevant changelog entry to CHANGELOG_UNRELEASED.md
• You have re-reviewed the files affected by the pull request (e.g. using the Files changed tab in the Github PR explorer)

[taobun]

I think it should return 502 (Internal server error). If a request existed it should have a data source for every raw requests

[ntchjb]

I think there is another possibility that a client sends some random external ID that does not exists in the request, which causes data source ID to be nil.