-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prohibit contract IDs in contract keys and add key maintainers to exercises #4048
Conversation
8e550cc
to
1f1c197
Compare
Mmm, OK, I'm getting some CI errors that I can't make sense of, I will figure it out tomorrow and reopen the PR |
…rcises CHANGELOG_BEGIN - [DAML-LF] Prohibit contract IDs in contract keys completely. Previously, creating keys containing absolute (but not relative) contract IDs was allowed, but `lookupByKey` on such a key would crash. Minor backwards incompatibility. CHANGELOG_END
1f1c197
to
1d1f228
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice thanks.
Though, I would like that @S11001001 takes a look at transaction encoding code.
@@ -59,6 +59,7 @@ private[digitalasset] object VersionTimeline { | |||
// * change the following line when LF 1.8 is frozen. | |||
// * do not insert line after this once until 1.8 is frozen. | |||
This(This(ValueVersion("7"))), | |||
This(That(TransactionVersion("9"))), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Move this line before the FIXME
comment. between line 57 and 58.
It is fine since GenMap (the only addition to value version 7) has never been release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed now
daml-lf/interpreter/src/main/scala/com/digitalasset/daml/lf/types/Ledger.scala
Outdated
Show resolved
Hide resolved
daml-lf/interpreter/src/main/scala/com/digitalasset/daml/lf/types/Ledger.scala
Outdated
Show resolved
Hide resolved
daml-lf/interpreter/src/main/scala/com/digitalasset/daml/lf/types/Ledger.scala
Outdated
Show resolved
Hide resolved
() | ||
} | ||
case (None, _) | (Some(_), true) => | ||
case (None, _, _) | (Some(_), true, _) => | ||
Right(()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Cosmetic]
I found this pattern matching with booleans a bit confusing.
I woul prefer something like
_ <- e.key match {
case Some(KeyWithMaintainers(k, maintainers))
if !(transactionVersion precedes minContractKeyInExercise) =>
if ((transactionVersion precedes minMaintainersInExercise) && maintainers.nonEmpty)
Left(EncodeError(transactionVersion, isTooOldFor = "maintainers in NodeExercises"))
else
encodeVal(k).map { encodedKey =>
exBuilder.setContractKey(encodedKey._2)
exBuilder.addAllKeyMaintainers(maintainers.toSet[String].asJava)
()
}
case _ =>
Right(())
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also messed up the logic here. I also changed the style now but I'm ambivalent to that.
@@ -232,9 +239,9 @@ object TransactionCoder { | |||
keyWithMaintainers: TransactionOuterClass.KeyWithMaintainers) | |||
: Either[DecodeError, KeyWithMaintainers[Val]] = | |||
for { | |||
mainteners <- toPartySet(keyWithMaintainers.getMaintainersList) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
daml-lf/transaction/src/main/scala/com/digitalasset/daml/lf/transaction/TransactionCoder.scala
Outdated
Show resolved
Hide resolved
daml-lf/transaction/src/main/scala/com/digitalasset/daml/lf/transaction/TransactionCoder.scala
Outdated
Show resolved
Hide resolved
daml-lf/transaction/src/main/scala/com/digitalasset/daml/lf/transaction/TransactionCoder.scala
Outdated
Show resolved
Hide resolved
daml-lf/transaction/src/main/scala/com/digitalasset/daml/lf/transaction/TransactionCoder.scala
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please change the order of This(That(TransactionVersion("9")))
in VersionTimeline.
Co-Authored-By: Remy <remy.haemmerle@daml.com>
…ansaction/TransactionCoder.scala Co-Authored-By: Remy <remy.haemmerle@daml.com>
@@ -55,6 +55,7 @@ private[digitalasset] object VersionTimeline { | |||
This(That(TransactionVersion("8"))), | |||
Both(This(ValueVersion("5")), LanguageVersion(LMV.V1, "6")), | |||
Both(This(ValueVersion("6")), LanguageVersion(LMV.V1, "7")), | |||
This(That(TransactionVersion("9"))), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear, you intend to invalidate prior valid transactions with contract IDs in contract keys. I am not really comfortable with this, but will defer to @remyhaemmerle-da's judgement.
As defined, it would be improper to only mention this restriction in a since version 9 section in transaction.rst (as commented elserwhere), since you are imposing the restriction retroactively.
@@ -315,6 +322,8 @@ class TransactionCoderSpec | |||
(x: GenNode[Nid, Cid, Val]) => withoutExerciseResult(withoutContractKeyInExercise(x))) | |||
else if (txvMin precedes minContractKeyInExercise) | |||
transactionWithout(tx, (x: GenNode[Nid, Cid, Val]) => withoutContractKeyInExercise(x)) | |||
else if (txvMin precedes minMaintainersInExercise) | |||
transactionWithout(tx, (x: GenNode[Nid, Cid, Val]) => withoutMaintainersInExercise(x)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to do withoutMaintainersInExercise
in both prior if
branches (see how withoutContractKeyInExercise
is also done in the branch prior its precedence test), or (ideally) reorganize this function so the precedence tests are independent of each other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added and reorganized. Less efficient when no changes need to be done, but this is test code.
daml-lf/spec/transaction.rst
Outdated
@@ -503,6 +505,11 @@ Containing the result of the exercised choice. | |||
New optional field `contract_key` is now set when the exercised | |||
contract has a contract key defined. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Restriction on key contents must be mentioned here, and also under message KeyWithMaintainers
.
Incidentally, it would be cleaner to use message KeyWithMaintainers
instead of adding field key_maintainers
as well, but I'll let @remyhaemmerle-da speak on that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added and using KeyWithMaintainers
now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The restriction still must be mentioned here, because this part does not use KeyWithMaintainers
, even though it will in version 9.
daml-lf/spec/transaction.rst
Outdated
|
||
The key may not contain contract IDs. This change is backwards | ||
incompatible; that is, transactions containing contract IDs in keys | ||
cannot be deserialized any more. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned in a previous comment
it would be improper to only mention this restriction in a since version 9 section in transaction.rst (as commented elsewhere), since you are imposing the restriction retroactively.
That's because you can always read the spec such that if you are dealing with version n, you can ignore all sections since version e where e > n; that is not the case here.
Effectively, the restriction you are introducing is since version 3, in other words, on all KeyWithMaintainers
.
daml-lf/spec/transaction.rst
Outdated
@@ -503,6 +505,11 @@ Containing the result of the exercised choice. | |||
New optional field `contract_key` is now set when the exercised | |||
contract has a contract key defined. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The restriction still must be mentioned here, because this part does not use KeyWithMaintainers
, even though it will in version 9.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With these changes we make clear that the new restriction is not associated with version 9.
Co-Authored-By: Stephen Compall <stephen.compall@daml.com>
…-asset/daml into add-key-maintainers-to-exercises
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need futher discussion with me and @gerolf-da
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add to the changelog something to explain the change in contract key.
Thanks for the help.
As discussed with @bame-da @remyhaemmerle-da and @gerolf-da , this completely removes the support for contract IDs in contract keys. This is a backwards incompatible change, but
lookupByKey
already didn't support such keys, so it is unlikely that this was used.Additionally, this adds key maintainers to
NodeExercises
. I also took the opportunity to remove some duplication in the compiler around keys and maintainers.Pull Request Checklist
CHANGELOG_BEGIN
andCHANGELOG_END
tagsNOTE: CI is not automatically run on non-members pull-requests for security
reasons. The reviewer will have to comment with
/AzurePipelines run
totrigger the build.