-
Notifications
You must be signed in to change notification settings - Fork 78
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
Polynetwork support #908
Conversation
There was a problem hiding this 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
7643bbe
to
4627dc5
Compare
01ecf0f
to
10c6d4a
Compare
Marking as ready for review. The main contract |
Hey, I moved your contract |
There was a problem hiding this 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?
This is because we have a new library (two actually) and the |
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" |
There was a problem hiding this 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.
src/stdlib/Conversions.scillib
Outdated
| BigEndian | ||
|
||
(* does not throw exceptions *) | ||
let osubstr : ByStr -> Uint32 -> Uint32 -> Option ByStr = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let osubstr : ByStr -> Uint32 -> Uint32 -> Option ByStr = | |
let substr_safe : ByStr -> Uint32 -> Uint32 -> Option ByStr = |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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 = |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is documented here https://scilla.readthedocs.io/en/latest/scilla-in-depth.html?highlight=ecdsa#crypto-built-ins.
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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... :-(
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
Scilla library functions for polynetwork support