[FEATURE]: provide call_args in call_data

[roaminro]

Is there an existing issue for this?

• I have searched the existing issues

New feature

As a smart contract developer I would like to be able to retrieve, from the authorize entry point, the arguments that were provded in a contract call.

Currently, authorize_arguments.call only provides contract_id and entry_point and relies on the data field to let smart contracts provide additional data. This means that if a smart contract call check_authority and does not provide the contract call args in data then authorize is not able to verify the contract call arguments.

The idea is to add a new field to call_data and provide the contract call args in this new field:

message call_data {
   bytes contract_id = 1 [(btype) = ADDRESS];
   uint32 entry_point = 2;
   bytes caller = 3;
   bytes data = 4;
   bytes call_args = 5;
}

Anything else?

authorize_arguments message definition

call_data message definition

[koinos-ci]

This issue is stale because it has been open for 30 days with no activity.

[roaminro]

not stale

[koinos-ci]

This issue is stale because it has been open for 30 days with no activity.

[koinos-ci]

This issue is stale because it has been open for 30 days with no activity.

[koinos-ci]

This issue is stale because it has been open for 30 days with no activity.

[mvandeberg]

I suppose this issue comes down to the following question. Should the call data be a requirement or a standard?

Let's consider the following scenarios. What if the calling contract lies or doesn't follow the standard, what should authorize return?

Well, it could just refuse to authorize if the data is not expected.

And if the data is incorrect, what is the worst that could happen? You would authorize a call to a contract that was unintended. But what harm could that do? That contract cannot use that authorization to take tokens from you because the token contracts will also check for authority.

The worst that can happen is that a dumb contract gets your authorization to do dumb contract things limited to the dumb contract's space.

I understand the motivation for the proposal, I do not think it adds any significant value. I am happy to continue the discussion.

[roaminro]

I feel like if we can provide the information in a trustless way then we should do it. Also, it would probably save Mana doing so since you would not be passing the arguments around from the contracts.

[koinos-ci]

This issue is stale because it has been open for 30 days with no activity.

[mvandeberg]

Making this change would require a hardfork as it changes how the framework behaves. So we need to decide if it is worth the pain of a hardfork to add this or if making it a part of an application standard makes more sense given the ease of implementation.

Note: We cannot simply add the behavior in a contract implemented system call because the contract does not have access to the full call stack that would be required for the implementation.

[roaminro]

I guess the application standard should be good enough for now, maybe we can revisit this item if/whenever a hardfork is planned one day.

Should I close this issue for now? Is there a place we should use to "save" items that could be part of a hardfork later?

[koinos-ci]

This issue is stale because it has been open for 30 days with no activity.