type score = Bytes.t list module type PROTOCOL = sig type operation val parse_block_header : raw_block_header -> block_header option val parse_operation : Bytes.t -> operation option val apply : Context.t -> block_header option -> (Operation_hash.t * operation) list -> Context.t option Lwt.t val score : Context.t -> score Lwt.t (*...*) end Wenolonger compare states directly as in the mathematical model, instead we project the Context onto a list of bytes using the score function. List of bytes are ordered first by length, then by lexicographic order. This is a fairly generic structure, similar to the one used in software versioning, which is quite versatile in representing various orderings. Why not define a comparison function within the protocol modules? First off it would be hard to enforce the requirement that such a function represent a total order. The score projection always verifies this (ties can be broken based on the hash of the last block). Second, in principle we need the ability to compare states across distinct protocols. Specific protocol amendment rules are likely to make this extremely unlikely to ever happen, but the network shell does not know that. Theoperations parse_block_header and parse_operation are exposed to the shell and allow it to pass fully typed operations and blocks to the protocol but also to check whether these operations and blocks are well-formed, before deciding to relay operations or to add blocks to the local block tree database. The apply function is the heart of the protocol: - When it is passed a block header and the associated list of operations, it computes the changes made to the context and returns a modified copy. Internally, only the difference is stored, as in a versioning system, using the block’s hash as a version handle. - When it is only passed a list of operations, it greedily attempts to apply as many operations as possible. This function is not necessary for the protocol itself but is of great use to miners attempting to form valid blocks. 2.3.2 Amending the protocol Tezos’s most powerful feature is its ability to implement protocol capable of self-amendment. This is achieved by exposing two procedures functions to the protocol: - set_test_protocol which replaces the protocol used in the testnet with a new protocol (typically one that has been adopted through a stakeholder 6