Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add owner policy #872

Draft
wants to merge 13 commits into
base: master
Choose a base branch
from
Draft

Add owner policy #872

wants to merge 13 commits into from

Conversation

AurelienFT
Copy link
Contributor

@AurelienFT AurelienFT commented Nov 18, 2024

FuelLabs/fuel-specs#617

Checklist

  • Breaking changes are clearly marked as such in the PR description and changelog
  • New behavior is reflected in tests
  • If performance characteristic of an instruction change, update gas costs as well or make a follow-up PR for that
  • The specification matches the implemented behavior (link update PR if changes are needed)

Before requesting review

  • I have reviewed the code myself
  • I have created follow-up issues caused by this PR and linked them here

After merging, notify other teams

[Add or remove entries as needed]

@AurelienFT AurelienFT self-assigned this Nov 18, 2024
@AurelienFT AurelienFT marked this pull request as ready for review November 19, 2024 13:58
@AurelienFT AurelienFT requested a review from a team November 19, 2024 13:58
CHANGELOG.md Outdated Show resolved Hide resolved
@@ -622,6 +624,12 @@ fn get_transaction_fields() {
op::eq(0x10, 0x10, 0x11),
op::and(0x20, 0x20, 0x10),

op::movi(0x19, 0x00),
op::movi(0x11, owner_idx as Immediate18),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question for me to understand: why Immediate18? By looking at the specs and the implementation of GTF, I would expect Immediate12 here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know I just followed the existing pattern. Maybe @Dentosal knows

@@ -622,6 +624,12 @@ fn get_transaction_fields() {
op::eq(0x10, 0x10, 0x11),
op::and(0x20, 0x20, 0x10),

op::movi(0x19, 0x00),
op::movi(0x11, owner_idx as Immediate18),
op::gtf_args(0x10, 0x19, GTFArgs::PolicyOwner),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another question for me to understand here.
I guess the PolicyOwner field is taken from the transaction included in the frame pointer. What is the value of the register 0x19 here used for? From the specs i can infer that it is related to the part of the field that we want to read, but it is not clear if this is the start or end offset or something else.

Anyway, not related to this PR (also probably this value is ignored since I'd expect the owner value to be fixed size).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above I jsut copy pasted the existing. cc @Dentosal

@acerone85
Copy link
Contributor

Another question for me to understand:
What is the motivation behind this change? I.e. why is it important for transactions to have an explicit user, and how it is going to be used by applications?

@AurelienFT
Copy link
Contributor Author

Another question for me to understand: What is the motivation behind this change? I.e. why is it important for transactions to have an explicit user, and how it is going to be used by applications?

The motivation is explained here : FuelLabs/fuel-specs#617 but in other word the smart contract sometimes wants to be able to know who is the caller (partially because dev are use to EVM msg.sender and also to have a common standard of who is the owner is needed by contract). This will allow contracts to have the language when speaking about owners instead of the current anarchy.

acerone85
acerone85 previously approved these changes Nov 24, 2024
@@ -133,6 +133,8 @@ pub enum ValidityError {
TransactionInputsMax,
TransactionOutputsMax,
TransactionWitnessesMax,
TransactionOwnerIndexDoesntExist,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a nit:

Suggested change
TransactionOwnerIndexDoesntExist,
TransactionOwnerIndexOutOfBounds

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ok with that. Changed.

Comment on lines 332 to 338
if owner >= tx.inputs().len() {
Err(ValidityError::TransactionOwnerIndexDoesntExist)?
}
// SAFETY: `owner` is guaranteed to be a valid index because it was checked above.
if !&tx.inputs()[owner].input_owner().is_some() {
Err(ValidityError::TransactionOwnerInputHasNoOwner)?
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we avoid manual safety check with something like:

        if tx
            .inputs()
            .get(owner)
            .and_then(|input| input.input_owner())
            .is_none()
        {
            return Err(ValidityError::TransactionOwnerInputHasNoOwner);
        }

?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I will change that. (not the whole code to mentionned because otherwise we will loose the two different errors)

@@ -321,6 +322,24 @@ where
Ok(())
}

pub(crate) fn check_owner<T>(tx: &T) -> Result<(), ValidityError>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think adding some UTs to this function makes sense?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really think so it's well tested with the other tests and it's not a practice we currently have for validation rules. I don't find this one more sensible or difficult to understand.

@xgreenx xgreenx marked this pull request as draft November 26, 2024 23:22
@xgreenx
Copy link
Collaborator

xgreenx commented Nov 26, 2024

I marked this PR as a Draft for now until we resolved https://forum.fuel.network/t/proposal-for-note-inputs/7094 proposal=)

Base automatically changed from add_expiration_policy to master December 2, 2024 22:44
@AurelienFT AurelienFT dismissed acerone85’s stale review December 2, 2024 22:44

The base branch was changed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants