Simplify contract language#66
Conversation
Proof-of-history is generic, but now that we're using it entirely for tokens, we can specialize the type and start doing more interesting things than just Eq and Serialize operations.
And boot recursive spending plans. That path required heap allocations. Since we don't have a need for this generality right now, reduce the language to the smallest one that can pass our test suite.
Codecov Report
@@ Coverage Diff @@
## master #66 +/- ##
==========================================
+ Coverage 92.65% 93.04% +0.39%
==========================================
Files 14 15 +1
Lines 1171 1194 +23
==========================================
+ Hits 1085 1111 +26
+ Misses 86 83 -3
Continue to review full report at Codecov.
|
|
Also, the simpler contract language here has fewer edge cases to worry about. You can see in that first commit that I started to go down the route of allowing a spending plan to make multiple payments. That opened up the ability to create a Race spending plan that will pay out on both branches until one completes (that's bad!) I closed that hole by changing the Race instruction to race two Conditions instead of two Plans. It's now safe to add back an instruction for multiple payments, but that's not done here because we don't yet have a hard requirement for that. |
2 participants
With these patches, we drop support for transactions of generic assets and instead focus only on tokens. The difference is basically that if you add two tokens, you get another token, whereas if you add two generic assets, you get a set of two assets. Maintaining that subtle difference (unique assets vs anonymous assets) turns out to be more painful than anticipated. I wrote it that way to show off the generality of proof-of-history, but we don't actually need anything that general in the near-term.