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

Initial PR with Go Code (WIP) #9

Open
wants to merge 64 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@SomniaStellarum

SomniaStellarum commented Oct 19, 2018

No description provided.

@avive avive changed the title from Initial PR with Go Code to Initial PR with Go Code (WIP) Oct 22, 2018

@avive

This comment has been minimized.

Member

avive commented Oct 22, 2018

So exciting to see progress on this! I'm working on the blackbox verifier so was asked by my research team not to look at your code until I'm done so it won't influence my design decisions (even subconsciously) and so we communicate all interfaces via the spec and don't assume things we see in each other code... let's connect on Gitter to discuss next steps...

@avive

Committing comments

h.BaseHash.Reset()
for _, v := range vs {
// Can safely ignore error as not supposed to return error. TODO: Check
_, _ = h.BaseHash.Write(v)

This comment has been minimized.

@avive

avive Nov 6, 2018

Member

nice idea!

}
// Encode outputs a []byte encoded in utf8
func (b *BinaryID) Encode() (v []byte) {

This comment has been minimized.

@avive

avive Nov 6, 2018

Member

Please check []byte(string) - I think this may give us the utf-8 encoding of a binary string because utf-8 is backward compatible with ascii and we only have ascii chars in a binary string...

This comment has been minimized.

@SomniaStellarum

SomniaStellarum Nov 6, 2018

I had already written BinaryID with a BigEndian encoding and a length parameter, so that's why it's not doing what you're saying here. We can replace BinaryID with an interface pretty easily and swap in an implementation using utf-8 under the hood. I'm planning on doing that later and setting up some benchmarks to figure out what is the best option. It's still encoding it as utf-8 when it hashes, so it should match the spec.

This comment has been minimized.

@avive

avive Nov 8, 2018

Member

ok - this sounds like a good idea. We need to sync on args packing so we can run our black box verifier on your prover proofs soon...

This comment has been minimized.

@SomniaStellarum

SomniaStellarum Nov 8, 2018

Yeah, definitely. I think we can merge the PR first though, but I think this is either the next step or the one after that. I also want to make sure our verifier is correctly checking our proof, which currently it isn't.

This comment has been minimized.

@avive

avive Nov 9, 2018

Member

let's please first verify the verifier with tests for non-interactive and interactive proofs. lmk once this was done and we will do a full review and merge...

return 0
}
func WriteToFile(data []byte) error {

This comment has been minimized.

@avive

avive Nov 6, 2018

Member

You want to use a large ram buffer and only flush it occasionally to the file and only open the file when dag generation starts and close it when it ends. This will greatly speeds up dag generation time for large values of n.

This comment has been minimized.

@SomniaStellarum

SomniaStellarum Nov 6, 2018

To be honest, I'm planning on quashing util.go completely. I've moved the fileio operations into fileio.go and storageio.go. It's now only opening the file once at the start of the program and runs a separate goroutine to handle file I/O operations. It's also operating on an interface so we can layer on different functionality depending on what we need/want. For example, the storage could be on a different server connected by RPC or the storage could store different layers of the DAG in a different way (this is how we'd implement storing the top m layers).

This comment has been minimized.

@avive
Show resolved Hide resolved server/go/poet/hash.go Outdated
j := b.Length - i
stringBit := string(v[j-1])
if stringBit == "1" {
b.FlipBit(j)

This comment has been minimized.

@zalmen

zalmen Nov 19, 2018

Member

why does b start counting indexes from 1 and not from 0 like common arrays?

This comment has been minimized.

@SomniaStellarum

SomniaStellarum Nov 19, 2018

For some reason, this is showing on the wrong line of code here, but I'm guessing it's in reference to line 221. The reason was it is coded that way is because we're immediately calling GetBit, which is expecting a number in the range of 1 to Length. I suppose GetBit could be written to take in a number starting from 0, but I just found it was easier to reason about it with that convention.

b.Val = make([]byte, l)
for i := 0; i < b.Length; i++ {
j := b.Length - i
stringBit := string(v[j-1])

This comment has been minimized.

@zalmen

zalmen Nov 19, 2018

Member

why do you compare the string representation instead of the straight forward byte representation?

This comment has been minimized.

@SomniaStellarum

SomniaStellarum Nov 19, 2018

It should be a byte comparison here. I'll change it in the next commit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment