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

Polynetwork support #908

Merged
merged 43 commits into from
Jan 8, 2021
Merged

Polynetwork support #908

merged 43 commits into from
Jan 8, 2021

Conversation

vaivaswatha
Copy link
Contributor

@vaivaswatha vaivaswatha commented Nov 19, 2020

Scilla library functions for polynetwork support

Copy link
Contributor

@anton-trunov anton-trunov left a comment

Choose a reason for hiding this comment

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

Hey, I understand this is a WIP PR, still I think some early input might be helpful

@vaivaswatha vaivaswatha marked this pull request as ready for review December 20, 2020 05:09
@vaivaswatha vaivaswatha requested a review from jjcnn as a code owner December 20, 2020 05:09
@vaivaswatha
Copy link
Contributor Author

Marking as ready for review. The main contract Polynetwork.scilla is more of a template than production ready. So it may be ok to ignore cosmetic issues in the contract, but any bug findings are appreciated. The library itself (Polynetwork.scillib) on the other hand needs thorough review.

@renlulu
Copy link
Contributor

renlulu commented Dec 20, 2020

Marking as ready for review. The main contract Polynetwork.scilla is more of a template than production ready. So it may be ok to ignore cosmetic issues in the contract, but any bug findings are appreciated. The library itself (Polynetwork.scillib) on the other hand needs thorough review.

Hey, I moved your contract Polynetwork.scilla (with some common design and enhancement) into this repo: https://github.com/Zilliqa/zilliqa-contracts/tree/main/contracts. This will be the main repository for polynetwork as you can see it forked from their repository. Anyways, many thanks to your hard work (both on scilla library support and contract itself). End 2 end testing will be continuing recently. Will sync with you along the way! Thanks!

Copy link
Contributor

@anton-trunov anton-trunov left a comment

Choose a reason for hiding this comment

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

I'm wondering why in a lot of not-related test cases we got a constant increase of gas usage by about 500 units?

@vaivaswatha
Copy link
Contributor Author

I'm wondering why in a lot of not-related test cases we got a constant increase of gas usage by about 500 units?

This is because we have a new library (two actually) and the eval-runner executable includes all libraries it can find to it's environment.

@anton-trunov
Copy link
Contributor

the eval-runner executable includes all libraries it can find to it's environment.

Ah, I see, thanks. Looks like this should be fixed at some point. I would expect having more libraries in the tests in the future and checking unrelated changes does not seem like a lot of fun to me :)

@vaivaswatha
Copy link
Contributor Author

the eval-runner executable includes all libraries it can find to it's environment.

Ah, I see, thanks. Looks like this should be fixed at some point. I would expect having more libraries in the tests in the future and checking unrelated changes does not seem like a lot of fun to me :)

I agree. At that point we must include a new test that will include all libraries though, and keep it updated when new libraries are added. This ensures there are no name clashes in our own libraries. Such a clash is now flagged by these implicit "all imports"

Copy link
Contributor

@jjcnn jjcnn left a comment

Choose a reason for hiding this comment

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

I haven't finished my review yet, but I wanted to make my initial comments visible.

I'll do my best to get the review done before I go on Christmas leave tomorrow evening, but if not I'll get it done between Christmas and New Years.

| BigEndian

(* does not throw exceptions *)
let osubstr : ByStr -> Uint32 -> Uint32 -> Option ByStr =
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
let osubstr : ByStr -> Uint32 -> Uint32 -> Option ByStr =
let substr_safe : ByStr -> Uint32 -> Uint32 -> Option ByStr =

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We have an unsafe substr and the o prefix indicates return of an option value. Since the name was suggested by @anton-trunov , let's see if he's ok with the new name too. If yes, I'll do this change.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm fine with renaming.

@vaivaswatha
Copy link
Contributor Author

Based on offline discussion, ignoring @jjcnn 's comments above, except for renaming osubstr to substr_safe. Thereby abandoning #922 too.

Copy link
Contributor

@jjcnn jjcnn left a comment

Choose a reason for hiding this comment

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

Review finished. I have some concerns both in terms of what the code does, and how it fits into our general process, but I don't know how to fix either.

I'd like to have a chat about it before I approve the PR, even if no changes are needed.

let ignore = builtin div zero_uint32 zero_uint32 in
default_val

let some_exn =
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm... This naming scheme is consistent with Jane Street's libraries, so maybe we should use substr_no_exn in the other function? I'm not sure - we're probably not consistent about things anyway.

fun (msg : ByStr) =>
fun (sig : ByStr64) =>
fun (recid : Uint32) =>
let pk = builtin ecdsa_recover_pk msg sig recid in
Copy link
Contributor

Choose a reason for hiding this comment

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

I just looked up what this builtin does, and I honestly don't understand it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

That's what I looked up, and that's the thing I don't understand. :-(

let nil_msg = Nil {Message} in
Cons {Message} msg nil_msg

contract Polynetwork(thisChainID : Uint64)
Copy link
Contributor

Choose a reason for hiding this comment

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

As far as I can tell this contract corresponds to the Solidity contract, but I'm not 100% certain because much of the library code is complete magic to me.

I'm concerned about how we will maintain this code. As far as I can tell we need to be downstream from the Solidity contract, but I don't understand the process by which that happens.

Copy link
Contributor

Choose a reason for hiding this comment

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

There doesn't seem to be an answer to this. Presumably we just have to trust that we'll be notified if something needs to be fixed. It's not ideal TBH, but I suppose it will have to do.

Copy link
Contributor

@jjcnn jjcnn left a comment

Choose a reason for hiding this comment

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

OK, I've checked Polynetwork.scillib and the testcases against the Solidity code, and there seems to be some sort of equivalence.

The only two outstanding issues are a naming issue, which is not essential, and a documentation issue, which is an issue for the documentation repo rather than for this PR.

let header_hash =
fun (header : ByStr) =>
let h1 = builtin sha256hash header in
let h2 = builtin sha256hash h1 in
Copy link
Contributor

Choose a reason for hiding this comment

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

In the Solidity contract there's a call to abi.encodePacked between the two hash calls. Is that an artefact from the Solidity implementation?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep, abi.encodePacked just keeps appending.

let rs_bs = builtin substr rs_v pos len in
let rs_bs64_opt = builtin to_bystr64 rs_bs in
let exnobj_bystr64 = 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 in
let sommer_bystr64 = @some_exn ByStr64 in
Copy link
Contributor

Choose a reason for hiding this comment

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

This whole bit is an implementation of slice, which is written in EVM assembly in the Solidity contract. I'm giving up there... :-(

Copy link
Contributor

Choose a reason for hiding this comment

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

Or is it? Is slice just a substring computation?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

slice is just substring computation, yes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So this computation here is separating the signature into two (r,s) components, and then the last byte is the v component. We don't do the + 27 though because that is an EVM specific thing. Our ecrecover doesn't need it.

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 had to do a lot of trial-and-error to get this right. Finally this helped: https://ethereum.stackexchange.com/questions/13778/get-public-key-of-any-ethereum-account

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 added this reference into the code now.

let nil_msg = Nil {Message} in
Cons {Message} msg nil_msg

contract Polynetwork(thisChainID : Uint64)
Copy link
Contributor

Choose a reason for hiding this comment

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

There doesn't seem to be an answer to this. Presumably we just have to trust that we'll be notified if something needs to be fixed. It's not ideal TBH, but I suppose it will have to do.

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