search

ProtoSchool / protoschool.github.io

The code that runs the ProtoSchool website. Visit https://proto.school for interactive tutorials on decentralized web protocols. Explore IPFS and Filecoin through code challenges, code-free lessons, and local events.
https://proto.school
Other
166 stars 67 forks source link

Lesson Feedback%3A Merkle DAGs - Lesson 5 (Merkle DAGs: Verifiability) #806

Open Blu3Jy opened 2 years ago

Blu3Jy commented 2 years ago

URL of the lesson that's confusing: https://proto.school/merkle-dags/05

What's confusing about this lesson? Quoting the lesson:

And, if we want to embed that subgraph as a part of a larger DAG that’s different from the one we originally found it in, we’re free to, because the DAG’s CID, which is the CID of its root node, depends on the root node’s descendents and not its ancestors. That last point deserves greater emphasis: with Merkle DAGs, we can take the same DAG and seamlessly embed it in multiple other, larger DAGs simultaneously! This enables a massive, interconnected weave of DAGs, building on top of and borrowing pieces from one another.

As we embed the smaller DAG in a larger different DAG, when the CID of its new root node is re-calculated, is the older CID dropped and never used again or is a different DAG forked from it thus at the end of the process resulting in two DAGs existing?

What is it actually meant by the word "embed"?

mitchwagner commented 2 years ago

Hi, Blu3Jy,

Thanks for the feedback! I can understand the confusion. I think it might help to highlight that in this case, we are speaking in the abstract, rather than about implementation of DAGs within the IPFS/Filecoin ecosystem.

As we embed the smaller DAG in a larger different DAG, when the CID of its new root node is re-calculated, is the older CID dropped and never used again or is a different DAG forked from it thus at the end of the process resulting in two DAGs existing?

In this context, we intend the latter meaning - that is, if we have two DAGs, X and Y, and we "embed" X within Y by taking the root node of X and adding it as a child node of one of Y's nodes, then we have, via this operation, defined a new DAG Z whose root node's CID will be different from Y's root node's CID.

In the abstract, these, and the practically-infinite set of all DAGS, co-exist simultaneously, each specified by its unique CID. We don't have to drop or forget the CID of Y to specify Z - they're just mathematical constructs.

In practice, within IPFS, things work much the same. DAGs are not changed/mutated, with the original DAG forgotten, so much as "forked", like you mention in your question. However, the focus of this lesson is not the concrete implementation.

Does that explanation help?