gistfile1.txt

mod new1 {
	use super::{Number, Hash};

	/// The header of a block. This is the minimal amount of data required to sync the chain at
	/// minimal viable security. It contains nothing more than cryptographic references.
	struct Header {
		/// Cryptographic reference to the previous block's header.
		parent: Hash,
		/// Cryptographic reference to pieces of extrinsic information (assumed to be an ordered
		/// list of `Extrinsic`, keyed into a Merkle trie by a 0-based index). Extrinsic
		/// information is usually just a set of transactions, but we make no specific
		/// requirements that are typical of transactions, e.g. signatures, in this case.
		extrinsics: Hash,
		/// A hash of the post-execution information ("receipt") for this block.
		receipt: Hash,
	}

	/// A block-level event. Encodes something that happened in-block which is important to
	/// light-clients. There are a number of reserved event types.
	type Event = Vec<u8>;

	/// A block receipt - contains all relevant post-execution information of the block.
	struct Receipt {
		/// The number of blocks that have preceded this in the chain.
		number: Number,
		/// The Merkle-trie hash of the final state of storage.
		storage_root: Hash,
		/// A list of events that this block's execution generated. Will contain parachain activity
		/// information as well as any important information on authority set transitions for light
		/// clients.
		/// NOTE: Information on "transaction receipts" (i.e. logs) are not contained here. Chains that
		/// need them will clear a particular location in storage and place them in storage during
		/// execution. The runtime will then form a merkle-trie root from this stored data and deposit
		/// it as an event in the digest. Native, runtime-specific, code will read storage for the logs
		/// and place them in a database so that (again, runtime-specific) light-client logic is able
		/// to query for particular logs and verify data through the digest.
		digest: Vec<Event>,
	}
	
	/// A header that includes the receipt, so that everything needed for a light-client to sync is contained.
	/// Note that a corresponding `Header` (and thus the header hash) can be constructed through the hash of
	/// the receipt and the `parent` and `extrinsics` fields.
	/// This structure is requested by light-clients when syncing blocks that happen after a trusted foundation
	/// block (i.e. genesis or a recent hard-coded hash+number failsafe). For syncing blocks prior to that point,
	/// where it is not necessry to track authority changes on every block, the normal `Header` can be used.
	struct FatHeader {
		parent: Hash,
		extrinsics: Hash,
		receipt: Receipt,
	}

	/// A single, isolatable chunk of extrinsic information.
	type Extrinsic = Vec<u8>;

	/// A full set of `Extrinsic` data.
	type Extrinsics = Vec<Extrinsic>;

	/// A "full" block.
	struct Block {
		/// The header.
		fat_header: FatHeader,
		/// The extrinsic information to which the header refers.
		extrinsics: Extrinsics,
	}
}