Git Product home page Git Product logo

Comments (6)

DavidVorick avatar DavidVorick commented on August 12, 2024

I guess I also don't know where CatchUp would go. And bootstrapping. Does that get it's own file? Does it go in genesis.go? Do we merge genesis.go and bootstrap.go into a single file named 'synchronizingwiththenetwork.go'?

Also it feels like encoding.go, signatures.go, hash.go, erasure.go all really don't belong in this package. Seems like they more belong as libraries.

Also don't know where the proof of storage stuff would go. In hash.go? In it's own file? Does it join a library with the rest of the files? Also, each of those files should probably be in a separate library, instead of all being in one larger library.

from sia.

lukechampine avatar lukechampine commented on August 12, 2024

Are the dividers supposed to indicate separate packages, or what?

My thoughts:

  • erasure.go should live alongside the client code. It's purely a layer on top of the actual protocol.
  • I support merging genesis and bootstrap into synchronize.go. CatchUp goes here.
  • Definitely support splitting verify.go into txns, blocks, contracts.
  • It feels a bit silly to have separate packages for encoding, hash, etc. when they're only one file. But perhaps they'll grow, or we'll have an excuse to separate them into multiple files. So I'm okay with it.
  • Proof of storage is tricky. I think it either belongs in its own file, or with contracts.go if it isn't too long already.
  • The network code is kind of intermingled with the State code right now. I'd like to untangle them, maybe by creating a Client type that contains both, or something similar. This would mean synchronize.go belongs with the client, not the protocol.

from sia.

lukechampine avatar lukechampine commented on August 12, 2024

Just ran make test and found out I broke sia_test.go by not initializing the State's TCPServer. Definitely leaning towards separating them.

from sia.

DavidVorick avatar DavidVorick commented on August 12, 2024

proof of storage I feel would go in the same package as the merkle tree stuff. So hash.go in the monolithic model.

from sia.

DavidVorick avatar DavidVorick commented on August 12, 2024

Should network be its own package?

from sia.

lukechampine avatar lukechampine commented on August 12, 2024

yes. I guess you could shove it all into the client, but I don't think that makes a lot of sense. It forces any client author to write all the network code too.

from sia.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.