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

encodeParam and encodeParams functions #456

Open
wants to merge 53 commits into
base: next
Choose a base branch
from
Open

Conversation

leftab
Copy link

@leftab leftab commented Nov 9, 2018

Fixes #427

Adds the following functions:

  • encodeParam(Param param) internal pure returns (uint256)
  • encodeParams(Param[] params) internal pure returns (uint256[])

I didn't add the encodeParam(uint8 id, uint8 op, uint240 value) function since I think encodeParam(Param param) covers pretty much the same use cases and is easier to use.

TODO:

  • Sanity check gas usage (these changes shouldn't cause any gas increases)

@coveralls
Copy link

coveralls commented Nov 9, 2018

Coverage Status

Coverage increased (+0.008%) to 99.548% when pulling 7366642 on leftab:dev into 37f8eff on aragon:dev.

Copy link
Contributor

@sohkai sohkai left a comment

Choose a reason for hiding this comment

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

Looking really good! Just thinking we could expose this as its own contract separate from ACLSyntaxSugar.

@@ -86,6 +86,31 @@ contract ACLSyntaxSugar {


contract ACLHelpers {

enum Op { NONE, EQ, NEQ, GT, LT, GTE, LTE, RET, NOT, AND, OR, XOR, IF_ELSE } // op types
Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think about putting this in another contract, e.g. ACLParams?

Copy link
Author

Choose a reason for hiding this comment

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

Good idea! I agree they fit more inside ACLParams


function encodeParam(Param param) internal pure returns (uint256) {
return uint256(param.id) << 248 | uint256(param.op) << 240 | param.value;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

We could also expose the helpers in ACLHelpers.

Copy link
Author

Choose a reason for hiding this comment

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

I exposed all the functions except those having struct params since they would require the experimental ABI encoder.

Assert.equal(uint256(params[1].op), uint256(op1), "Encoded op is not equal");
Assert.equal(uint256(params[1].value), uint256(value1), "Encoded value is not equal");
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's test encodeOperator and encodeIfElse as well :)

Copy link
Author

Choose a reason for hiding this comment

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

Done :)

Copy link
Author

Choose a reason for hiding this comment

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

I noticed that the encodeOperator and encodeIfElse functions are in a separate file in the test folder. Do you think it would be a good idea if I move them to the ACLHelpers contract?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, I think it's a good idea, but let's wait for @sohkai opinion, maybe there is a reason I don't know for them to be there.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah I didn't notice they were only in the tests.

I think moving them could be helpful; AFAIK they're not simply because we only used them in test functionality. We should either add comments to explain how they work or make encodeOperator() more explicit (it's a bit confusing at first why it builds off of encodeIfElse()).

@leftab
Copy link
Author

leftab commented Nov 20, 2018

Thanks for the review @sohkai ! I applied the changes but somehow the Travis tests seems to fail now. I'm a bit perplexed since everything looks fine when I run the tests locally.

Allows a frontend to follow all `SetApp()` events emitted from the start of a KernelProxy's lifespan.
@sohkai
Copy link
Contributor

sohkai commented Jan 11, 2019

@leftab Sorry for the hiatus on this—will get back to looking at this shortly :).

I think the CI broken when there was a ganache bug with account values or gas used; if you merge with master it should be fixed now :).

@sohkai sohkai added this to the A1 Sprint: 3.2 milestone Jan 14, 2019
contract ACLHelpers {
function decodeParamOp(uint256 _x) internal pure returns (uint8 b) {
contract ACLHelpers is ACLParams {

Copy link
Contributor

Choose a reason for hiding this comment

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

Why are we adding 2 newlines here? Not a big deal, but we don't usually do that.

Copy link
Author

Choose a reason for hiding this comment

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

Oh I didn't know that, sorry. It's fixed.

contract ACLHelpers is ACLParams {


function decodeParamOp(uint256 _x) public pure returns (uint8 b) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are we converting these 3 functions from internal to public?

Copy link
Author

Choose a reason for hiding this comment

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

So it can be used by composition instead of only by inheritance. Do you think it would impact gaz usage and we should keep them internal?

Copy link
Contributor

Choose a reason for hiding this comment

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

Most likely wouldn't impact gas by very much (more or less only on deployment), but wondering how useful this would be. Do you think outside contracts might want access to this functionality, which is only accessible on the ACL?

We should also make sure encodeParams() and encodeParam() are the same visibility as their decode counterparts.

Copy link
Author

Choose a reason for hiding this comment

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

Sorry for the delay. hmm.. it’s been so long that I don’t even remember haha! I guess I wanted the encodeParam and encodeParams functions public, but it’s not supported yet anyway. I converted them back to internal and exposed the encodeOperator and encodeIfElse functions. The two functions are used in the ACL Interpreter tests and I made encodeOperator a little bit more explicit.

Copy link
Author

Choose a reason for hiding this comment

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

What do you think if I move the ACLHelpers contract into its own ACLHelpers.sol file? It would be a breaking change however.

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's mark it as something we should do in the future 👍 .

}

function testEncodeParams() public {
Param[] memory params = new Param[](6);
Copy link
Contributor

Choose a reason for hiding this comment

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

Why 6? Only 4 are being used, right? (not a big deal)

Copy link
Author

Choose a reason for hiding this comment

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

True! :)


uint256[] memory encodedParam = encodeParams(params);

(uint32 id0, uint32 op0, uint32 value0) = decodeParamsList(encodedParam[0]);
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we could use a loop here.

Copy link
Author

Choose a reason for hiding this comment

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

Totally!

@leftab
Copy link
Author

leftab commented Jan 21, 2019

@sohkai @bingen Sorry guys for the delay, we've been quite busy working on our demo for Aracon and the end of the Drive app milestone. I should be able to post an update this week.

@leftab
Copy link
Author

leftab commented Feb 15, 2019

As for the gas usage sanity check, since the new functions are not used in aragonOS and are internal, there should be no impact on gas usage.

@sohkai
Copy link
Contributor

sohkai commented Feb 15, 2019

@leftab Will check the compiled bytecode of the ACL. I don't see why it would change with this change, but need to be sure (don't want it to accidentally change from our initial deployment).

}
}


contract AcceptOracle is IACLOracle {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we rename this file, since it only contains test ACLOracles now?

Copy link
Author

Choose a reason for hiding this comment

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

Renamed it to ACLOracleHelper

@@ -0,0 +1,15 @@
pragma solidity ^0.4.24;
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we add the MIT header here (e.g. see https://github.com/aragon/aragonOS/blob/dev/contracts/acl/IACL.sol#L1)?

Copy link
Author

Choose a reason for hiding this comment

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

Done! ;) Is there a rule of thumb on which file an MIT header should be added?

Copy link
Contributor

Choose a reason for hiding this comment

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

I need to write more documentation on this, but on all the unpinned contracts (since they're the only ones meant to be used by apps, which frees them up to use any licensing model they want).

@sohkai
Copy link
Contributor

sohkai commented Mar 7, 2019

@leftab I've pushed a commit to split ACLHelpers from ACLSyntaxSugar and clean up some formatting.

Unfortunately though, it looks like the changes do cause a bytecode difference against the old contracts :(. Going between this PR and dev, there's a bit of difference at the very end of the deployed bytecode:

screen shot 2019-03-07 at 7 51 25 pm

Will have to investigate further to see what's exactly causing this, but it does mean it's a bigger change than expected. As far as I can tell it happens immediately as the struct and enum are moved out, which is quite odd behaviour for the compiler.

@sohkai sohkai removed this from the A1 Sprint: 4.1 milestone Mar 7, 2019
@sohkai sohkai added this to the aragonOS 5.0 milestone May 18, 2019
@sohkai
Copy link
Contributor

sohkai commented May 18, 2019

@leftab Because this wasn't pulled into some of the minor aragonOS 4.x releases, due to the incompatible bytecode (and because we didn't want to risk re-deploying the ACL for 0.7), we'll roll this into aragonOS 5 :).

@sohkai sohkai changed the base branch from dev to next July 11, 2019 09:29
@CLAassistant
Copy link

CLAassistant commented Aug 8, 2019

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
3 out of 4 committers have signed the CLA.

✅ usetech-llc
✅ leftab
✅ sohkai
❌ a33bcn
You have signed the CLA already but the status is still pending? Let us recheck it.

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.

Add a function to convert an ACL Param to uint256
7 participants