Design Rationale

The Zone Mailboxes mechanism provides an effective route for a user experiencing censorship from a Zone Executor to get his transactions included into a Zone.

Validators will enforce inclusion of these messages by blocking Zone finality until a proof of message inclusion is provided.

This raises the obvious denial of service attack where posting a message to a Zone’s Mailbox on chain is faster than proving the Zone State Transition Function (Zone STF), and thus an attacker may block Zone finality indefinitely by forcing an executor to throw away their in-progress proof whenever a new message is added to the mailbox.

To resolve this, we say that the Nth Zone execution after a message lands on chain must have included the message.

Specification

CL Transaction

We add a new transaction to Co-ordination Layer

struct PostZoneMailboxMsg {
  zone: ZoneID,
  payload: Vec<u8>
}

Validator

struct ValidatorState {
  ...
  // count number of transitions each zone has executed
  zone_iterations: BTreeMap<ZoneID, Iteration>,
  zone_mailboxes: BTreeMap<ZoneID, Mailbox>,
}

#[derive(Default)]
struct Mailbox {
	// Message batches are keyed by the zone iteration at which
	// those messages must be included.
  messages_by_deadline: BTreeMap<Iteration, MessageBatch>
}

struct MessageBatchState {
	messages: Vec<Message>
}

struct Message {
  zone: ZoneID,
  payload: Vec<u8>
}

type Iteration = u64;

Zone

Zone Transition

When a zone posts it’s transition to CL, it will now include proofs of inclusion for any messages processed from that Zone’s mailbox.

struct ZoneTransition {
  ...
  zone: ZoneID,
  // proofs of inclusion for any messages that might be in this
  // zones mailbox.
  included_msgs: BTreeMap<MessageHash, ProofOfInclusion>,
}

Zone State

To support proofs of inclusion, we impose some structure on the zone state commitment.

$$ state_Z=hash(root_{Z}|| root_{tx}) $$