fix doc links #487
fix doc links #487
Conversation
cam-schultz
requested review from
iansuvak,
feuGeneA,
geoff-vball,
minghinmatthewlam,
bernard-avalabs and
michaelkaplan13
contracts/teleporter/README.md
Outdated
|
|
||
| If the sending Subnet's validator set changes, then it's possible for the receiving Subnet to reject the underlying Warp message due to insufficient signing stake. For example, suppose Subnet A has 5 validators with equal stake weight who all sign a Teleporter message sent to Subnet B. 100% of Subnet A's stake has signed the message. Also suppose Subnet B requires 67% of the sending Subnet's stake to have signed a given Warp message in order for it to be accepted. Before the message can be delivered, however, 5 _more_ validators are added to Subnet A's validator set (all with the same stake weight as the original validators), meaning that the Teleporter message was signed by _only 50%_ of Subnet A's stake. Subnet B will reject this message. | ||
|
|
||
| The Warp protocol does not support re-signing in such a scenario, but Teleporter does. `retrySendCrossChainMessage` can be called for any message that has not been acknowledged as delivered to its destination. Under the hood, this packages the Teleporter message into a brand new Warp message that is re-signed by the current validator set. |
There was a problem hiding this comment.
I might be misunderstanding but isn't this behavior specific to the way that signable Warp messages are being handled right now? I.e. in the future there could be messages that are signable regardless of when the validator joined. The Teleporter comment still stands and I agree that we should mention retrySendCrossChainMessage but I don't think that the statement about Warp protocol as a whole is true in general.
There was a problem hiding this comment.
Fair point. We should think of a better way to distinguish Warp messages that are sent at a point in time (with a specific validator set's aggregate signature) versus a Warp message that's constructed on demand (with the current validator set's signature). I've rephrased it to make it clear that we're talking about Warp messages sent on chain.
|
|
||
| If the sending Subnet's validator set changes, then it's possible for the receiving Subnet to reject the underlying Warp message due to insufficient signing stake. For example, suppose Subnet A has 5 validators with equal stake weight who all sign a Teleporter message sent to Subnet B. 100% of Subnet A's stake has signed the message. Also suppose Subnet B requires 67% of the sending Subnet's stake to have signed a given Warp message in order for it to be accepted. Before the message can be delivered, however, 5 _more_ validators are added to Subnet A's validator set (all with the same stake weight as the original validators), meaning that the Teleporter message was signed by _only 50%_ of Subnet A's stake. Subnet B will reject this message. | ||
|
|
||
| Once sent on chain, Warp messages cannot be re-signed by a new validator set in such a scenario. Teleporter, however, does support re-signing via the function `retrySendCrossChainMessage`, which can be called for any message that has not been acknowledged as delivered to its destination. Under the hood, this packages the Teleporter message into a brand new Warp message that is re-signed by the current validator set. |
There was a problem hiding this comment.
I think this part is a little unclear. I think it would be more accurate to say that validators that were not online when the message was sent are not able to sign it, because we don't bootstrap validators.
There was a problem hiding this comment.
To me, this reads well and is a clear explanation of the scenario. I am fine with adding Geoff's summary up top and leaving the detailed explanation in as an example scenario.
There was a problem hiding this comment.
I tried a handful of variations that mentioned bootstrapping, but IMO they were all less clear than this description of "if the validator set changes, then signature verification may fail". This example isn't meant to be exhaustive, just to illustrate how Teleporter handles such a scenario.
contracts/teleporter/README.md
Outdated
| - [Message Delivery and Execution](#message-delivery-and-execution) | ||
| - [Resending a Message](#resending-a-message) |
There was a problem hiding this comment.
Nit: Github provides an outline/table of contents by default. Can we remove the manual one while we're here so it doesn't fall out of date in the future?
Why this should be merged
contracts/README.mdto be generic to apply to all of the subdirectories, rather than Teleporter specific.retrySendCrossChainMessagein the Teleporter protocol READMEHow this works
How this was tested
How is this documented