diff --git a/print.html b/print.html index eb814e8..e6ea356 100644 --- a/print.html +++ b/print.html @@ -1568,8 +1568,7 @@ sharing if multiple parachains use the same data (e.g. same smart contracts).

Summary

The only requirement for collator nodes is to provide valid parachain blocks to the validators of a backing group and by definition the collator set is trustless. However, in the case of elastic scaling, for security reason, collators must be trusted - non-malicious. CoreIndex commitments are required to remove this limitation. Additionally we are introducing a SessionIndex field in the CandidateReceipt to make dispute resolution more secure and robust.

Motivation

-

At present time misbehaving collator nodes can prevent their parachain from effecitvely using elastic scaling by providing the same valid block to all backing groups assigned to the parachain. This happens before the next parachain block is authored and will prevent the chain of candidates to be formed, reducing the throughput of the parachain to a single core. -There are no special requirements from collators to do it, just being a full node is sufficient and there are no methods of punishing or rewarding good behaviour.

+

At present time misbehaving collator nodes, or anyone who has acquired a valid collation can prevent a parachain from effecitvely using elastic scaling by providing the same valid block to all backing groups assigned to the parachain. This happens before the next parachain block is authored and will prevent the chain of candidates to be formed, reducing the throughput of the parachain to a single core.

This RFC solves the problem by enabling a parachain to provide the core index information as part of it's PVF execution output and in the associated candidate receipt data structure.

Once this RFC is implemented the validity of a parachain block depends on the core it is being executed on.

Stakeholders

@@ -1584,7 +1583,7 @@ There are no special requirements from collators to do it, just being a full nod

Reclaiming unused space in the descriptor

The CandidateDescriptor currently includes collator and signature fields. The collator includes a signature on the following descriptor fields: parachain id, relay parent, validation data hash, validation code hash and the PoV hash.

However, in practice, having a collator signature in the receipt on the relay chain does not provide any benefits as there is no mechanism to punish or reward collators that have provided bad parachain blocks.

-

This proposal aims to remove the collator signature and all the logic that checks the collator signatures of candidate receupts. We use the first 6 bytes to represent the core and session index, and fill the rest with zeroes. So, there is no change in the layout and length of the receipt. The new primitive is binary compatible with the old one.

+

This proposal aims to remove the collator signature and all the logic that checks the collator signatures of candidate receipts. We use the first 6 bytes to represent the core and session index, and fill the rest with zeroes. So, there is no change in the layout and length of the receipt. The new primitive is binary compatible with the old one.

Backwards compatibility

There are two flavors of candidate receipts which are used in network protocols, runtime and node implementation: