Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Clarity <-> MARF #1084
This PR integrates the MARF into Clarity (#1055)
The big items:
Things left unaddressed:
@@ Coverage Diff @@ ## develop #1084 +/- ## =========================================== - Coverage 80.34% 80.33% -0.01% =========================================== Files 98 105 +7 Lines 23786 23648 -138 =========================================== - Hits 19110 18998 -112 + Misses 4676 4650 -26
jcnelson left a comment
The code overall looks great. Thanks for integrating the MARF into Clarity so quickly!
However, there's something that was overlooked in the tests (and to a lesser extent, the API): dealing with forks. As far as I could see, there are no tests as to what happens if the chain forks. Are clarity objects created in one fork absent in the other, and vice versa? Are clarity objects created prior to the fork present in both? The MARF was designed to address this situation, and it looks like the code uses the MARF to do so, but there needs to be tests. This also means that the MARF API should expose to Clarity a way to get the longest fork (if one is not given), and the Clarity datastore
Related, I think the Clarity CLI should support the notion of simulated-mining of forks at some point -- I should be able to build multiple children off of a single parent, and I should be able to launch different contracts and tokens in different forks.
Yep -- I can add some tests that perform forks. The expected outcome is that the side store will store the mapping of MARFValue (hashed values) to values for all forks processed, but that the clarity db's "view" of the data will be the one presented by the open MARF block.
Yeah, I think there should be an API exposed, but Clarity's interface with the MARF ultimately wouldn't be affected by it -- rather the caller of the Clarity VM would handle it outside of the context of Clarity -- e.g., the way that the routines in the clarity local environment (clarity.rs) handle beginning and committing the marf blocks.
I don't think that's necessarily the case. Any given Clarity context is only ever the execution context for a single transaction, so a context doesn't really need to be aware of whether or not it is in a fork (what's more, there's only ever one block that a context calls