search

filecoin-project / specs

The Filecoin protocol specification
https://spec.filecoin.io
Other
367 stars 170 forks source link

Implementation team questions about the spec #442

Open pooja opened 5 years ago

pooja commented 5 years ago

From Soramitsu:

pooja commented 5 years ago

From Lotus:

P0:

P1:

P2:

pooja commented 5 years ago

@sternhenri @whyrusleeping Could I get one of you to please respond to the questions from Soramitsu ASAP (i.e. by end of week)? These are mostly questions about status, so hopefully shouldn't be too hard to answer! These are urgent though, so would appreciate your help here.

mhammersley commented 5 years ago

@dignifiedquire and @sternhenri are planning on getting to this today

whyrusleeping commented 5 years ago

Do we know who is responsible for translation of character address to bytes?

Not sure what is being asked here

Proof of Space-Time and other proofs – are they finished in Rust language? Can we start writing bindings over them?

Yes, see https://github.com/filecoin-project/go-sectorbuilder for the go bindings

What are the list of libp2p protocols we should support? What is used for security, muxing, transport?

see: https://github.com/filecoin-project/specs/blob/master/networking.md

Is the usefulness of peers clearly defined or there is room for different interpretations?

Thats up to the client

Recommendation 25-50 connection slots while a node should not attempt to connect to more than 10 bootnodes. Is this consistent?

Seems acceptable, this is technically up to the client, so the specs here are just recommendations

The spec for Bitswap is WIP can we use it already?

Yeah, its pretty stable. though I think we might actually not need bitswap anymore if we're using graphsync or blocksync.

Is “checking signatures” resolved?

Not fully, ideas welcome.

Storage deal Make - there are some ToDos. What is the current status of this design?

Overall, quite solid, there are some details being fleshed out. Should land in the next couple weeks.

How to resolve cases when there are discrepancies between spec and go implementation.

The spec is the grand source of truth, any implementation not doing what the spec says is incorrect.

Any plans for preparing cross implementation tests?

Absolutely, we're planning on starting some of that up in the next month or so. Hard to give exact timelines, but its a high priority.

sternhenri commented 5 years ago

Thanks @whyrusleeping !

pooja commented 5 years ago

Thanks @whyrusleeping! @sternhenri @dignifiedquire Could y'all take a look at the Lotus questions above, esp the P0 ones?

sternhenri commented 5 years ago

Are we actually going to use a VDF in consensus? TBDetermined. Requires a final convo w Why, Nicola (preferably), should be answered by eonextweek.

GenerateTicket is undefined in expected-consensus.md Look up Ticket Generation instead

Retrieval protocol question: Should we always reference data by an ipfs cid? Seems an ok solution to me, though I may be missing context... May be worth having a non-ipfs format.. IPLD should be the standard here imo.

Retrieval Protocol currently references data by CID. This works for cases where people use ipfs/bitswap to transfer data, but what if we ship a hard drive over? Do we always require users ipld format their data? see above

Clarity on faults please! On it soon with @dignifiedquire, need ok from @jbenet on collateral piece as well to proceed.

Gas costs Small group should just decide.

Actor method error values Ibid, maybe we should just have a day for the above two.

Rational PoSt construction (technically merged, but not 'done' until faults are done) Dig is on it I am guessing... A week or two off.

GregTheGreek commented 5 years ago

In the spec, the slashing portion of consensus states:

During a fork, an attacker would have a 30% chance of winning on each fork, meaning they could continue to mine on both forks

Is it intended that a node will have to monitor forks? How is this possible, if a fork doesn't meet the nodes consensus shouldn't that be discarded?

sternhenri commented 5 years ago

Hi @GregTheGreek. No, the node chain maintainer will monitor the latest head and evaluate new blocks as they are received to either update the chain head or discard them.

However, in the case you highlight, we are considering an adversarial miner attempting to grind. The assumption is that this adversary would be running a custom node that does indeed track each fork (or a subset of them) in order to increase their earnings by deviating from the protocol and not discarding those nodes. When provable, this behavior (mining across forks in a given round) would be slashed.

Does that answer your question?