diff --git a/host-spec/ad-netmessages.tm b/host-spec/ad-netmessages.tm deleted file mode 100644 index 5b686c0fa..000000000 --- a/host-spec/ad-netmessages.tm +++ /dev/null @@ -1,400 +0,0 @@ - - - - - - -<\body> - - - In this section, we will specify various types of messages which the - Polkadot Host receives from the network. Furthermore, we also explain the - appropriate responses to those messages. - - <\definition> - A is a byte array, > of length - |M|\<\|\|\>>> such that: - - \; - - <\equation*> - >|>|\M|M|\<\|\|\>>>>|>>>>> - - - \; - - - The body of each message consists of different components based on its - type. The different possible message types are listed below in Table - . We describe the sub-components of each - message type individually in Section . - - |||||||||||||>>||>|||>>|||>>|||>>|||>>|||>|||>>|||>|||>|||>|||>|||>|||>|||>|||>|||>|||>|||>>>>|List of possible network - message types.> - - - - This section disucsses the detailed structure of each network message. - - - - A Message represented by > is sent after a - connection with a neighbouring node is established and has the following - structure: - - <\equation*> - M\Enc,Hash,Hash,C|)> - - - Where: - - <\center> - ||||||:>||>|:>>||>|:>||>|>:>||>|>>||>>>|>>||>>>|>>||>>>> - - - \; - - In which, Role is a bitmap value whose bits represent different roles for - the sender node as specified in Table : - - \; - - <\with|par-mode|center> - <\small-table> - \; - - <\center> - ||||||||||||||||||>|>||>|||>|||>|||>>>> - - - \; - Node role representation in the - status message.> - - - - - A Block request message, represented by >, is sent to - request block data for a range of blocks from a peer and has the following - structure: - - <\equation*> - M\Enc,S,Hash,d,Max|)> - - - where: - - <\center> - ||||||:>||>|>:>||>|>:>||,64bit - integer>}>>|>>||> optional - type>>|>||>|>||>>>> - - - \; - - \; - - in which\ - - <\itemize-minus> - >, the requested data, is a bitmap value, whose bits - represent the part of the block data requested, as explained in Table - : - - - <\with|par-mode|center> - <\small-table> - \; - - <\center> - ||||||||||||||||||>|>||>|||>|||>|||>|||>>>> - - - \; - Bit values for block attribute - >, to indicate the requested parts of the data.> - - - <\itemize-minus> - > is SCALE encoded varying data type (see Definition - ) of either > - representing the block hash, >, or integer - representing the block number of the starting block of the requested - range of blocks. - - > is optionally the block hash of the last block - in the range. - - is a flag; it defines the direction on the block chain - where the block range should be considered (starting with the starting - block), as follows - - <\equation*> - d=|>||>>>>|\> - - - - Optional data type is defined in Definition - . - - - - A represented by > is sent in a - response to a requested block message (see Section - ). It has the following structure: - - <\equation*> - M\Enc - - - where: - - <\center> - ||||||:>||>|:>||>>>> - - - \; - - \; - - In which block data is defined in Definition . - - <\definition> - is defined as the follownig - tuple: - - - <\equation*> - ,Header,Body,Receipt,MessageQueue,Justification|)> - - - Whose elements, with the exception of >, are all of the - following (see Definition - ) and are defined as follows: - - <\center> - ||||||>:>||>>>|>:>||)>>|||)>>|||>|||>|||>>>> - - - \; - - - - A represented by > is sent when - a node becomes aware of a new complete block on the network and has the - following structure: - - <\equation*> - M\Enc|)> - - - Where: - - <\center> - ||||||>:>||)>>>>> - - - - - \ \ \ \ The transactions Message is represented by > and is - defined as follows: - - <\equation*> - M\Enc,\,C|)> - - - in which: - - <\equation*> - C\Enc|)> - - - Where each > is a byte array and represents a sepearate - extrinsic. The Polkadot Host is indifferent about the content of an - extrinsic and treats it as a blob of data. - - - - A represented by > is sent to - communicate messages related to consensus process: - - <\equation*> - M\Enc,D|)> - - - Where: - - <\center> - ||||||>:>||>>>|>||>>>>>> - - - \; - - in which - - <\equation*> - E\BABE>||>>|FRNK>||>>>>>|\> - - - \; - - The network agent should hand over to approperiate consensus - engine which identified by >. - - - - - -\; - - <\with|par-mode|right> - - - - \; - - - -<\initial> - <\collection> - - - - - - - -<\references> - <\collection> - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - - - -<\auxiliary> - <\collection> - <\associate|table> - |A.1>||List of possible - network message types.>|> - - |A.2>||Node role - representation in the status message.>|> - - |A.3>||Bit values for - block attribute |A>, to indicate the - requested parts of the data.>|> - - <\associate|toc> - |math-font-series||Appendix - ANetwork Messages> |.>>>>|> - - - A.1Detailed Message Structure - |.>>>>|> - - - |A.1.1Status Message - |.>>>>|> - > - - |A.1.2Block Request Message - |.>>>>|> - > - - |A.1.3Block Response Message - |.>>>>|> - > - - |A.1.4Block Announce Message - |.>>>>|> - > - - |A.1.5Transactions - |.>>>>|> - > - - |A.1.6Consensus Message - |.>>>>|> - > - - - \ No newline at end of file diff --git a/host-spec/ae-hostapi.tm b/host-spec/ae-hostapi.tm index fabeb3e5c..9421acffc 100644 --- a/host-spec/ae-hostapi.tm +++ b/host-spec/ae-hostapi.tm @@ -259,7 +259,7 @@ : <\itemize> - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 256-bit Blake2 storage root. @@ -286,7 +286,7 @@ Definition indicating the SCALE encoded block hash. - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 256-bit Blake2 changes root. @@ -757,8 +757,8 @@ as defined in Definition containing the BIP-39 seed which must be valid UTF8. - : a regular pointer to the buffer containing the - public key. + : a 32-bit pointer to the buffer containing the + 256-bit public key. > @@ -783,7 +783,7 @@ : an i32 integer indicating the key type ID as defined in Definition . - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 256-bit public key. : a pointer-size as defined in Definition @@ -826,14 +826,14 @@ : <\itemize> - : a regular pointer to the buffer containing + : a 32-bit pointer to the buffer containing the 64-byte signature. : a pointer-size as defined in Definition indicating the message that is to be verified. - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 256-bit public key. : a i32 integer value equal to if the @@ -898,7 +898,7 @@ as defined in Definition containing the BIP-39 seed which must be valid UTF8. - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 256-bit public key. @@ -924,7 +924,7 @@ : an i32 integer containg the key ID as defined in Definition - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 256-bit public key. : a pointer-size as defined in Definition @@ -974,15 +974,15 @@ : <\itemize> - : a regular pointer to the buffer containing + : a 32-bit pointer to the buffer containing the 64-byte signature. : a pointer-size as defined in Definition indicating the message that is to be verified. - : a regular pointer to the buffer containing the - public key. + : a 32-bit pointer to the buffer containing the + 256-bit public key. : a i32 integer value equal to if the signature is valid or a value equal to if otherwise. @@ -1001,15 +1001,15 @@ : <\itemize> - : a regular pointer to the buffer containing + : a 32-bit pointer to the buffer containing the 64-byte signature. : a pointer-size as defined in Definition indicating the message that is to be verified. - : a regular pointer to the buffer containing the - public key. + : a 32-bit pointer to the buffer containing the + 256-bit public key. : a i32 integer value equal to if the signature is valid or a value equal to if otherwise. @@ -1072,7 +1072,7 @@ as defined in Definition containing the BIP-39 seed which must be valid UTF8. - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 33-byte compressed public key. @@ -1098,7 +1098,7 @@ : an i32 integer containg the key ID as defined in Definition - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 33-byte compressed public key. : a pointer-size as defined in Definition @@ -1143,7 +1143,7 @@ : <\itemize> - : a regular pointer to the buffer containing + : a 32-bit pointer to the buffer containing the 65-byte signature. The signature is 65-bytes in size, where the first 512-bits represent the signature and the other 8 bits represent the recovery ID. @@ -1152,7 +1152,7 @@ indicating the message that is to be verified. - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 33-byte compressed public key. : a i32 integer value equal to if the @@ -1176,12 +1176,12 @@ : <\itemize> - : a regular pointer to the buffer containing + : a 32-bit pointer to the buffer containing the 65-byte signature in RSV format. V should be either or . - : a regular pointer to the buffer containing the - Blake2 hash of the message. + : a 32-bit pointer to the buffer containing the + 256-bit Blake2 hash of the message. : a pointer-size as defined in Definition indicating the SCALE encoded @@ -1207,11 +1207,11 @@ : <\itemize> - : a regular pointer to the buffer containing + : a 32-bit pointer to the buffer containing the 65-byte signature in RSV format. V should be either or . - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 256-bit Blake2 hash of the message. : a pointer-size as defined in Definition @@ -1304,7 +1304,7 @@ : a pointer-size as defined in Definition indicating the data to be hashed. - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 256-bit hash result. @@ -1324,13 +1324,13 @@ : - <\itemize-dot> + <\itemize> : a pointer-size as defined in Definition indicating the data to be hashed. - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 512-bit hash result. - + > @@ -1352,7 +1352,7 @@ : a pointer-size as defined in Definition indicating the data to be hashed. - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 256-bit hash result. @@ -1376,7 +1376,7 @@ : a pointer-size as defined in Definition indicating the data to be hashed. - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 128-bit hash result. @@ -1400,7 +1400,7 @@ : a pointer-size as defined in Definition indicating the data to be hashed. - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 256-bit hash result. @@ -1424,7 +1424,7 @@ : a pointer-size as defined in Definition indicating the data to be hashed. - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 64-bit hash result. @@ -1448,7 +1448,7 @@ : a pointer-size as defined in Definition indicating the data to be hashed. - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 128-bit hash result. @@ -1472,7 +1472,7 @@ : a pointer-size as defined in Definition indicating the data to be hashed. - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 256-bit hash result. @@ -1554,9 +1554,9 @@ > - Verifies if the local node is a potential validator. Even if this function - returns true, it does not mean that any keys are configured or that the - validator is registered in the chain. + Check whether the local node is a potential validator. Even if this + function returns , it does not mean that any keys are + configured or that the validator is registered in the chain. @@ -1574,11 +1574,12 @@ if it is not. - > + > - Given an extrinsic as a SALE encoded byte array, the system decodes the - byte array and submits the extrinsic in the inherent pool as an extrinsic - to be included in the next produced block. + Given a SCALE encoded extrinsic, this function submits the extrinsic to the + Host's transaction pool, ready to be propagated to remote peers. This + process is critical for issuing the message + . @@ -1599,18 +1600,36 @@ : a pointer-size as defined in Definition indicating the SCALE encoded as defined in Definition . - Neither on success or failure is there any additional data provided. + Neither on success or failure is there any additional data provided. The + cause of a failure is implementation specific. > Returns the SCALE encoded, opaque information about the local node's - network state. This information is fetched by calling into - , which include the and - possible by which the node is publicly known - by. Those values are unique and have to be known by the node individually. - Due to its opaque nature, it's unknown whether that information is - available prior to execution. + network state. + + <\definition> + The + structure, >, is a SCALE encoded blob holding information + about the the , >, of + the local node and a list of + (\M>), the node knows it can be reached + at: + + <\eqnarray*> + >||,\M|)>|)>>>>> + + + where: + + <\eqnarray*> + >||\b|)>>>|>||\b|)>>>>> + + + The information contained in this structure is naturally opaque to the + caller of this function. + > @@ -1626,10 +1645,9 @@ : a pointer-size as defined in Definition indicating the SCALE encoded as defined in Definition . - On success it contains the SCALE encoded network state. This includes - none or one followed by none, one or more IPv4 or IPv6 - by which the node is publicly known by. On - failure no additional data is provided. + On success it contains the structure as + defined in Definition . On failure, + an empty value is yielded where its cause is implementation specific. > @@ -1639,7 +1657,7 @@ <\verbatim> - (func $ext_offchain_timestamp_version_1 (result i64)) + (func $ext_offchain_timestamp_version_1 (result u64)) \ @@ -1647,7 +1665,7 @@ : <\itemize> - : an i64 integer indicating the current UNIX + : an u64 integer indicating the current UNIX timestamp as defined in Definition . @@ -1658,7 +1676,7 @@ <\verbatim> - (func $ext_offchain_sleep_until_version_1 (param $deadline i64)) + (func $ext_offchain_sleep_until_version_1 (param $deadline u64)) \ @@ -1666,7 +1684,7 @@ : <\itemize> - : an i64 integer specifying the UNIX timestamp + : an u64 integer specifying the UNIX timestamp as defined in Definition . @@ -1686,8 +1704,8 @@ : <\itemize> - : a pointer to the buffer containing the 256-bit - seed. + : a 32-bit pointer to the buffer containing the + 256-bit seed. > @@ -1710,9 +1728,9 @@ <\itemize> : an i32 integer indicating the storage kind. A - value equal to 1 is used for a persistent storage as defined in - Definition and a value equal - to 2 for local storage as defined in Definition + value equal to is used for a persistent storage as defined + in Definition and a value + equal to for local storage as defined in Definition . : a pointer-size as defined in Definition @@ -1722,6 +1740,33 @@ indicating the value. + > + + Remove a value from the local storage. + + + + <\verbatim> + (func $ext_offchain_local_storage_clear_version_1 + + \ \ (param $kind i32) (param $key i64)) + + + \; + + Arguments: + + <\itemize-dot> + : an i32 integer indicating the storage kind. A + value equal to is used for a persistent storage as defined + in Definition and a value + equal to for local storage as defined in Definition + . + + key: a pointer-size as defined in Definition + indicating the key. + + > Sets a new value in the local storage if the condition matches the current @@ -1744,9 +1789,9 @@ <\itemize> : an i32 integer indicating the storage kind. A - value equal to 1 is used for a persistent storage as defined in - Definition and a value equal - to 2 for local storage as defined in Definition + value equal to is used for a persistent storage as defined + in Definition and a value + equal to for local storage as defined in Definition . : a pointer-size as defined in Definition @@ -1782,9 +1827,9 @@ <\itemize> : an i32 integer indicating the storage kind. A - value equal to 1 is used for a persistent storage as defined in - Definition and a value equal - to 2 for local storage as defined in Definition + value equal to is used for a persistent storage as defined + in Definition and a value + equal to for local storage as defined in Definition . : a pointer-size as defined in Definition @@ -1828,7 +1873,8 @@ indicating the SCALE encoded as defined in Definition containing the i16 ID of the newly started request. On failure no - additionally data is provided. + additionally data is provided. The cause of failure is implementation + specific. > @@ -1864,7 +1910,8 @@ : a pointer-size as defined in Definition indicating the SCALE encoded as defined in Definition . - Neither on success or failure is there any additional data provided. + Neither on success or failure is there any additional data provided. The + cause of failure is implemenation specific. > @@ -2012,6 +2059,37 @@ on faiure. + > + + Set the authorized nodes which are allowed to connect to the local node. + This function is primarily used for private blockchains and is not necessarily + required for the public and open Polkadot protocol. + + + + <\verbatim> + (func $ext_offchain_set_authorized_nodes_version_1 + + \ \ (param $nodes i64) (param $authorized_only i32) + + + \; + + : + + <\itemize-dot> + : a pointer-size as defined in Definition + indicating the buffer of the SCALE + encoded array of 's. Invalid + 's are silently ignored. + + : If set to , then only the + authorized nodes are allowed to connect to the local node (whitelist). + All other nodes are rejected. If set to , then no such + restriction is placed. + + Interface that provides trie related functionality. @@ -2038,7 +2116,7 @@ the trie root gets formed. The items consist of a SCALE encoded array containing arbitrary key/value pairs. - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 256-bit trie root. @@ -2067,7 +2145,7 @@ compact encoded integers as described in Definition . - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 256-bit trie root result. @@ -2093,7 +2171,7 @@ the trie root gets formed. The items consist of a SCALE encoded array containing arbitrary key/value pairs. - result: a regular pointer to the buffer containing the 256-bit trie + result: a 32-bit pointer to the buffer containing the 256-bit trie root. @@ -2122,7 +2200,7 @@ compact encoded integers as described in Definition . - : a regular pointer to the buffer containing the + : a 32-bit pointer to the buffer containing the 256-bit trie root result. @@ -2263,7 +2341,7 @@ <\itemize> : the size of the buffer to be allocated. - : a regular pointer to the allocated buffer. + : a 32-bit pointer to the allocated buffer. > @@ -2281,7 +2359,7 @@ : <\itemize> - : a regular pointer to the memory buffer to be freed. + : a 32-bit pointer to the memory buffer to be freed. @@ -2344,200 +2422,207 @@ <\initial> <\collection> - + + - > - + + <\references> <\collection> - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > @@ -2554,11 +2639,11 @@ |A.3>|> Table of possible HTTP error types - |> + |> |A.4>|> Log Levels for the logging interface - |> + |> <\associate|toc> |math-font-series||Appendix @@ -2893,7 +2978,7 @@ |.>>>>|> > - |A.4.2|language||ext_hashing_keccak_512> + |A.4.2|language||ext_hashing_sha2_256> |.>>>>|> > @@ -2901,7 +2986,7 @@ |.>>>>|> > - |A.4.3|language||ext_hashing_sha2_256> + |A.4.3|language||ext_hashing_blake2_128> |.>>>>|> > @@ -2909,7 +2994,7 @@ |.>>>>|> > - |A.4.4|language||ext_hashing_blake2_128> + |A.4.4|language||ext_hashing_blake2_256> |.>>>>|> > @@ -2917,7 +3002,7 @@ |.>>>>|> > - |A.4.5|language||ext_hashing_blake2_256> + |A.4.5|language||ext_hashing_twox_64> |.>>>>|> > @@ -2925,7 +3010,7 @@ |.>>>>|> > - |A.4.6|language||ext_hashing_twox_64> + |A.4.6|language||ext_hashing_twox_128> |.>>>>|> > @@ -2933,7 +3018,7 @@ |.>>>>|> > - |A.4.7|language||ext_hashing_twox_128> + |A.4.7|language||ext_hashing_twox_256> |.>>>>|> > @@ -2941,244 +3026,252 @@ |.>>>>|> > - |A.4.8|language||ext_hashing_twox_256> - |.>>>>|> - > + A.5Offchain |.>>>>|> + - |A.4.8.1Version 1 - Prototype + |A.5.1|language||ext_offchain_is_validator> |.>>>>|> - > + > - A.5Offchain |.>>>>|> - + |A.5.1.1Version 1 - Prototype + |.>>>>|> + > - |A.5.1|language||ext_offchain_is_validator> + |A.5.2|language||ext_offchain_submit_transaction> |.>>>>|> > - |A.5.1.1Version 1 - Prototype + |A.5.2.1Version 1 - Prototype |.>>>>|> > - |A.5.2|language||ext_offchain_submit_transaction> + |A.5.3|language||ext_offchain_network_state> |.>>>>|> > - |A.5.2.1Version 1 - Prototype + |A.5.3.1Version 1 - Prototype |.>>>>|> > - |A.5.3|language||ext_offchain_network_state> + |A.5.4|language||ext_offchain_timestamp> |.>>>>|> > - |A.5.3.1Version 1 - Prototype + |A.5.4.1Version 1 - Prototype |.>>>>|> > - |A.5.4|language||ext_offchain_timestamp> + |A.5.5|language||ext_offchain_sleep_until> |.>>>>|> > - |A.5.4.1Version 1 - Prototype + |A.5.5.1Version 1 - Prototype |.>>>>|> > - |A.5.5|language||ext_offchain_sleep_until> + |A.5.6|language||ext_offchain_random_seed> |.>>>>|> > - |A.5.5.1Version 1 - Prototype + |A.5.6.1Version 1 - Prototype |.>>>>|> > - |A.5.6|language||ext_offchain_random_seed> + |A.5.7|language||ext_offchain_local_storage_set> |.>>>>|> > - |A.5.6.1Version 1 - Prototype + |A.5.7.1Version 1 - Prototype |.>>>>|> > - |A.5.7|language||ext_offchain_local_storage_set> + |A.5.8|language||ext_offchain_local_storage_clear> |.>>>>|> > - |A.5.7.1Version 1 - Prototype + |A.5.8.1Version 1 - Prototype |.>>>>|> > - |A.5.8|language||ext_offchain_local_storage_compare_and_set> + |A.5.9|language||ext_offchain_local_storage_compare_and_set> |.>>>>|> > - |A.5.8.1Version 1 - Prototype + |A.5.9.1Version 1 - Prototype |.>>>>|> > - |A.5.9|language||ext_offchain_local_storage_get> + |A.5.10|language||ext_offchain_local_storage_get> |.>>>>|> > - |A.5.9.1Version 1 - Prototype + |A.5.10.1Version 1 - Prototype |.>>>>|> > - |A.5.10|language||ext_offchain_http_request_start> + |A.5.11|language||ext_offchain_http_request_start> |.>>>>|> > - |A.5.10.1Version 1 - Prototype + |A.5.11.1Version 1 - Prototype |.>>>>|> > - |A.5.11|language||ext_offchain_http_request_add_header> + |A.5.12|language||ext_offchain_http_request_add_header> |.>>>>|> > - |A.5.11.1Version 1 - Prototype + |A.5.12.1Version 1 - Prototype |.>>>>|> > - |A.5.12|language||ext_offchain_http_request_write_body> + |A.5.13|language||ext_offchain_http_request_write_body> |.>>>>|> > - |A.5.12.1Version 1 - Prototype + |A.5.13.1Version 1 - Prototype |.>>>>|> > - |A.5.13|language||ext_offchain_http_response_wait> + |A.5.14|language||ext_offchain_http_response_wait> |.>>>>|> > - |A.5.13.1Version 1- Prototype + |A.5.14.1Version 1- Prototype |.>>>>|> > - |A.5.14|language||ext_offchain_http_response_headers> + |A.5.15|language||ext_offchain_http_response_headers> |.>>>>|> > - |A.5.14.1Version 1 - Prototype + |A.5.15.1Version 1 - Prototype |.>>>>|> > - |A.5.15|language||ext_offchain_http_response_read_body> + |A.5.16|language||ext_offchain_http_response_read_body> |.>>>>|> > - |A.5.15.1Version 1 - Prototype + |A.5.16.1Version 1 - Prototype |.>>>>|> > + |A.5.17|language||ext_offchain_set_authorized_nodes> + |.>>>>|> + > + + |A.5.17.1Version 1 - Prototype + |.>>>>|> + > + A.6Trie |.>>>>|> - + |A.6.1|language||ext_trie_blake2_256_root> |.>>>>|> - > + > |A.6.1.1Version 1 - Prototype |.>>>>|> - > + > |A.6.2|language||ext_trie_blake2_256_ordered_root> |.>>>>|> - > + > |A.6.2.1Version 1 - Prototype |.>>>>|> - > + > |A.6.3|language||ext_trie_keccak_256_root> |.>>>>|> - > + > |A.6.3.1Version 1 - Prototype |.>>>>|> - > + > |A.6.4|language||ext_trie_keccak_256_ordered_root> |.>>>>|> - > + > |A.6.4.1Version 1 - Prototype |.>>>>|> - > + > A.7Miscellaneous |.>>>>|> - + |A.7.1|language||ext_misc_chain_id> |.>>>>|> - > + > |A.7.1.1Version 1 - Prototype |.>>>>|> - > + > |A.7.2|language||ext_misc_print_num> |.>>>>|> - > + > |A.7.2.1Version 1 - Prototype |.>>>>|> - > + > |A.7.3|language||ext_misc_print_utf8> |.>>>>|> - > + > |A.7.3.1Version 1 - Prototype |.>>>>|> - > + > |A.7.4|language||ext_misc_print_hex> |.>>>>|> - > + > |A.7.4.1Version 1 - Prototype |.>>>>|> - > + > |A.7.5|language||ext_misc_runtime_version> |.>>>>|> - > + > |A.7.5.1Version 1 - Prototype |.>>>>|> - > + > A.8Allocator |.>>>>|> - + |A.8.1|language||ext_allocator_malloc> |.>>>>|> - > + > |A.8.1.1Version 1 - Prototype |.>>>>|> - > + > |A.8.2|language||ext_allocator_free> |.>>>>|> - > + > |A.8.2.1Version 1 - Prototype |.>>>>|> - > + > A.9Logging |.>>>>|> - + |A.9.1|language||ext_logging_log> |.>>>>|> - > + > |A.9.1.1Version 1 - Prototype |.>>>>|> - > + > \ No newline at end of file diff --git a/host-spec/c01-background.tm b/host-spec/c01-background.tm index 7c9bdb4a3..250c06592 100644 --- a/host-spec/c01-background.tm +++ b/host-spec/c01-background.tm @@ -1,8 +1,8 @@ - + - +> <\body> @@ -350,8 +350,8 @@ <\initial> <\collection> - - > + + @@ -359,32 +359,32 @@ <\references> <\collection> > - > - > - > - > + > + > + > + > > - > - > - > - > - > + > + > + > + > + > > - > - > - > - > - > - > - > - > + > + |>|?>> + |B,B>)|?>> + |\>BT|)>>|?>> + |\>|?>> + > + > + > > - > - > - > - > - > - > + |math-font-series|||P>>|?>> + |\>|?>> + > + |B>|?>> + |Enc>|?>> + > > > > diff --git a/host-spec/c04-networking.tm b/host-spec/c04-networking.tm index 95dca51c8..73cf6f9fc 100644 --- a/host-spec/c04-networking.tm +++ b/host-spec/c04-networking.tm @@ -1,631 +1,632 @@ - + -> +> <\body> This document in its current form is incomplete and considered work in progress. Any reports regarding - falseness or clarifications are appreciated. + deviation from the current Polkadot network protocol or clarifications are + appreciated. The Polkadot network is decentralized and does not rely on any central - authority or entity in order to achieve a its fullest potential of provided - functionality. Each node with the network can authenticate itself and its - peers by using cryptographic keys, including establishing fully encrypted - connections. The networking protocol is based on the open and standardized - protocol, including the usage of the distributed Kademlia - hash table for peer discovery. + authority or entity in order to achieve its fullest potential of provided + functionality. The networking protocol is based on a family of open + protocols, including the distributed Kademlia hash table which is used for + peer discovery. - + This chapter walks through the behavior of the networking implemenation of + the Polkadot Host and defines the network messages. Implementation details + of the used protocols are specified in external sources + as described in Section . + + The completeness of implementing the Polkadot networking protocol requires the usage of external documentation. <\itemize> - - - - - + - + is a modular peer-to->peer networking stack + composed of many modules and different parts. Included in + are multiplexing protocols and + . + + + - The Polkadot Host uses the addressing system to + identity and connect to peers. + + - + is a distributed hash table for decentralized + peer-to-peer networks. The Polkadot Host uses Kademlia for peer + discovery. + + - The Noise protocol is a + framework for building cryptographic protocols. The Polkadot Host uses + Noise to establish the encryption layer to remote peers. + + + - is a multiplexing protocol developed by + . The protocol allows to divide a connection to a peer + into multiple substreams, each substream serving a specific purpose. + Generally, Polkadot Host implementers are encouraged to prioritize + implementing , since it's the de facto standard in + Polkadot. is only required in order to communicate with + . + + + - is a multiplexing protocol like and + developed by HashiCorp. It's the de facto standard for the Polkadot Host. + This protocol should be prioritzed over . Section + described the subprotocol in more + detail. + - Protocol Buffers is a language-neutral, platform-neutral mechanism for + serializing structured data and is developed by Google. The Polkadot Host + uses Protocol Buffers to serialze specific messages, as clarified in + Section . - + - The Polkadot Host uses varies mechanism to find peers within the network, - to establish and maintain a list of peers and to share that list with other - peers from the network. + Each Polkadot Host node maintains a ED25519 key pair which is used to + identify the node. The public key is shared with the rest of the network + which allows nodes to establish secure communication channels.\ - The Polkadot Host uses various mechanism for peer dicovery. + Each node must have its own unique ED25519 key pair. When two or more nodes + use the same key, the network will interpret those nodes as a single node, + which will result in undefined behavior and can result in equivocation. + Furthermore, the node's as defined in Definition + is derived from its public key. + () is used to identify each node when they are + discoved in the course of the discovery mechanism described in Section + . - <\itemize> - Bootstrap nodes - hard-coded node identities and addresses provided - by network configuration itself. Those addresses are selected an updated - by the developers of the Polkadot Host. Node addresses should be selected - based on a reputation metric, such as reliability and uptime. + <\definition> + The Polkadot node's , formally + referred to as >, is derived from the ED25519 public key + and is structured as defined in the libp2p specification + (). + + + - mDNS - performs a broadcast to the local network. Nodes that might - be listing can respond the the broadcast. + The Polkadot Host uses various mechanisms to find peers within the network, + to establish and maintain a list of peers and to share that list with other + peers from the network, as follows: - Kademlia requests - Kademlia supports + <\itemize> + are hard-coded node identities and + addresses provided by the genesis state specification as described in + Appendix . + + protocol which performs a broadcast to the local + network. Nodes that might be listening can respond the the broadcast. + + defines this process in more detail. This protocol is an optional + implementation detail for Polkadot Host implementers and is not required + in order to participate in the Polkadot network. + + invoking Kademlia requests, where nodes respond with their list of available peers. + Kademlia requests are performed on a specific substream as described in + Section . - - - The Polkadot Host can establish a connection with any peer it knows the - address. uses the protocol - in order to establish an encryption and multiplexing layer. The Polkadot - Host supports multiple base-layer protocols: + + + Polkadot nodes connect to peers by establishing a TCP connection. Once + established, the node initiates a handshake with the remote peer's on the + encryption layer. An additional layer on top of the encryption layer, known + as the multiplexing layer, allows a connection to be split into substreams, + as described by the , + either by the local or remote node. + + The Polkadot node supports two types of substream protocols. Section + describes the usage of each type in + more detail: + + <\itemize-dot> + : After the protocol is + negotiated by the multiplexing layer, the initiator sends a single + message containing a request. The responder then sends a response, after + which the substream is then immediately closed. The requests and + responses are prefixed with their + encoded length. + + . After the protocol is negotiated, + the initiator sends a single handshake message. The responder can then + either accept the substream by sending its own handshake, or reject it by + closing the substream. After the substream has been accepted, the + initiator can send an unbound number of individual messages. The + responder keeps its sending side of the substream open, despite not + sending anything anymore, and can later close it in order to signal to + the initiator that it no longer wishes to communicate. + + Handshakes and messages are prefixed with their + encoded lengths. A + handshake can be empty, in which case the length prefix would be + . + + + Connections are established by using the following protocols: + + <\itemize-dot> + - a protol that is announced when a connection to + a peer is established. + + - a protocol that is announced when + negotiating an encryption protocol or a substream. + + - a protocol used during the + or negotiation. See Section + for more information. + + + The Polkadot Host can establish a connection with any peer of which it + knows the address. The Polkadot Host supports multiple networking + protocols: <\itemize> - TCP/IP - addresses in the form of - establish a TCP connection and negotiate a encryption and multiplexing - layer. + with addresses in the form of + to establish a TCP connection and negotiate + an encryption and a multiplexing layer. - Websockets - addresses in the form of - establish a TCP connection and negotiate the Websocket protocol within - the connection. Additionally, a encryption and multiplexing layer is - negotiated within the Websocket connection. + with addresses in the form of + to establish a TCP connection and negotiate + the Websocket protocol within the connection. Additionally, an encryption + and multiplexing layer is negotiated within the Websocket connection. - DNS - addresses in form of and + addresses in form of + and . + The addressing system is described in the specification. After a base-layer protocol is established, the Polkadot Host will apply - the Noise protocol. - - + the Noise protocol to establish the encryption layer as described in + Section . + + + + Polkadot protocol uses the > Noise framework to + build an encryption protocol. The Noise protocol is a framework for bulding + encryption protocols. utilizes that protocol for + establishing encrypted communication channels. Refer to the + specification for a detailed description. + + Polkadot nodes use the to establish a connection + between peers. Three following steps are required to successfully complete + the handshake process: + + <\enumerate-numeric> + The initiator generates a keypair and sends the public key to the + responder. The + and the + describe keypairs in more detail. + + The responder generates its own keypair and sends its public key + back to the initiator. After that, the responder derives a shared secret + and uses it to encrypt all further communication. The responder now sends + its static Noise public key (which may change anytime and does not need + to be persisted on disk), its public key and a + signature of the static Noise public key signed with the + public key. + + The initiator derives a shared secret and uses it to encrypt all + further communication. It also sends its static Noise public key, + public key and a signature to the responder. + + + After these three steps, both the initiator and responder derive a new + shared secret using the static and session-defined Noise keys, which are + used to encrypt all further communication. + + After the node establishes a connection with a peer, the use of - multiplexing allows the Polkadot Host to open substreams. Substreams allow - the negotiation of , - where each protocol servers a specific utility. - - The Polkadot Host adoptes the following, standardized - application-specific protocols: + multiplexing allows the Polkadot Host to open substreams. + uses the protocol|https://docs.libp2p.io/concepts/stream-multiplexing/#mplex> + or the protocol|https://docs.libp2p.io/concepts/stream-multiplexing/#yamux> + to manage substream and to allow the negotiation of + , where each + protocol servers a specific utility. + + The Polkadot Host uses multiple substreams, where its usage depends on a + specific purpose. Each substream is either a or a , as described in Section + . <\itemize> - Open a substream to a peer and initialize a ping to verify if a connection is till alive. If the peer - does not respond, the connection is dropped. + does not respond, the connection is dropped. This is a + . - Open a substream to a peer to ask - information about that peer. + information about that peer. This is a . - - Open a substream for Kademlia - requests. + - Open a substream for Kademlia + requests. This is a , + as defined by the standard. - Additional, non-standardized protocols: - <\itemize> - a request and response protocol that - allows the Polkadot Host to perform information about blocks. + allows the Polkadot Host to perform information about blocks. This is a + . - a request and response protocol that - allows a light client to perform information about the state. - - - a notification protocol which - sends transactions to connected peers. - - - a notification protocol which - sends blocks to connected peers. - - - - - - - ProtoBuf details: - - <\itemize> - syntax: proto3 - - package: api.v1 - - - - - Request block data from a peer. - - <\verbatim> - \; - - message BlockRequest { - - \ \ \ \ // Bits of block data to request. - - \ \ \ \ uint32 fields = 1; - - \ \ \ \ // Start from this block. - - \ \ \ \ oneof from_block { - - \ \ \ \ \ \ \ \ // Start with given hash. - - \ \ \ \ \ \ \ \ bytes hash = 2; - - \ \ \ \ \ \ \ \ // Start with given block number. - - \ \ \ \ \ \ \ \ bytes number = 3; - - \ \ \ \ } - - \ \ \ \ // End at this block. An implementation defined - - \ \ \ \ // maximum is used when unspecified. - - \ \ \ \ bytes to_block = 4; // optional - - \ \ \ \ // Sequence direction. - - \ \ \ \ Direction direction = 5; - - \ \ \ \ // Maximum number of blocks to return. An implementation - - \ \ \ \ // defined maximum is used when unspecified. - - \ \ \ \ uint32 max_blocks = 6; // optional - - } - - \; - - // Block enumeration direction - - enum Direction { - - \ \ \ \ // Enumerate in ascending order - - \ \ \ \ // (from child to parent). - - \ \ \ \ Ascending = 0; - - \ \ \ \ // Enumerate in descending order - - \ \ \ \ // (from parent to canonical child). - - \ \ \ \ Descending = 1; - - } - - \; - - - - - Response to Block Request. - - <\verbatim> - \; - - message BlockResponse { - - \ \ \ \ // Block data for the requested sequence. - - \ \ \ \ repeated BlockData blocks = 1; - - } - - \; - - // Block data sent in the response. - - message BlockData { - - \ \ \ \ // Block header hash. - - \ \ \ \ bytes hash = 1; - - \ \ \ \ // Block header if requested. - - \ \ \ \ bytes header = 2; // optional - - \ \ \ \ // Block body if requested. - - \ \ \ \ repeated bytes body = 3; // optional - - \ \ \ \ // Block receipt if requested. - - \ \ \ \ bytes receipt = 4; // optional - - \ \ \ \ // Block message queue if requested. - - \ \ \ \ bytes message_queue = 5; // optional - - \ \ \ \ // Justification if requested. - - \ \ \ \ bytes justification = 6; // optional - - \ \ \ \ // True if justification should be treated as present but - - \ \ \ \ // empty. This hack is unfortunately necessary because - - \ \ \ \ // shortcomings in the protobuf format otherwise doesn't - - \ \ \ \ // make it possible to differentiate between a lack of - - \ \ \ \ // justification and an empty justification. - - \ \ \ \ bool is_empty_justification = 7; // optional, false if absent - - } - - \; - - - - - ProtoBuf details: - - <\itemize> - syntax: proto3 - - package: api.v1.light - - - - - Enumerate all possible light client request messages. - - <\verbatim> - \; - - message Request { - - \ \ \ \ oneof request { - - \ \ \ \ \ \ \ \ RemoteCallRequest remote_call_request = 1; - - \ \ \ \ \ \ \ \ RemoteReadRequest remote_read_request = 2; - - \ \ \ \ \ \ \ \ RemoteHeaderRequest remote_header_request = 3; - - \ \ \ \ \ \ \ \ RemoteReadChildRequest remote_read_child_request = 4; - - \ \ \ \ \ \ \ \ RemoteChangesRequest remote_changes_request = 5; - - \ \ \ \ } - - } - - \; - - - - - Enumerate all possible light client response messages. - - <\verbatim> - \; - - message Response { - - \ \ \ \ oneof response { - - \ \ \ \ \ \ \ \ RemoteCallResponse remote_call_response = 1; - - \ \ \ \ \ \ \ \ RemoteReadResponse remote_read_response = 2; - - \ \ \ \ \ \ \ \ RemoteHeaderResponse remote_header_response = 3; - - \ \ \ \ \ \ \ \ RemoteChangesResponse remote_changes_response = 4; - - \ \ \ \ } - - } - - \; - - - - - Remote call request. - - <\verbatim> - \; - - message RemoteCallRequest { - - \ \ \ \ // Block at which to perform call. - - \ \ \ \ bytes block = 2; - - \ \ \ \ // Method name. - - \ \ \ \ string method = 3; - - \ \ \ \ // Call data. - - \ \ \ \ bytes data = 4; - - } + allows a light client to request information about the state. This is a + . - \; - + - a substream/notification protocol + which sends transactions to connected peers. This is a . - + - a substream/notification + protocol which sends blocks to connected peers. This is a + . - Remote call response. - - <\verbatim> - \; - - message RemoteCallResponse { - - \ \ \ \ // Execution proof. - - \ \ \ \ bytes proof = 2; - - } - - \; - - - - - Remote storage read request. - - <\verbatim> - \; - - message RemoteReadRequest { - - \ \ \ \ // Block at which to perform call. - - \ \ \ \ bytes block = 2; - - \ \ \ \ // Storage keys. - - \ \ \ \ repeated bytes keys = 3; - - } - - \; - - - - - Remote read response. - - <\verbatim> - \; - - message RemoteReadResponse { - - \ \ \ \ // Read proof. - - \ \ \ \ bytes proof = 2; - - } - - \; - - - - - Remote storage read child request. - - <\verbatim> - \; - - message RemoteReadChildRequest { - - \ \ \ \ // Block at which to perform call. - - \ \ \ \ bytes block = 2; - - \ \ \ \ // Child Storage key, this is relative - - \ \ \ \ // to the child type storage location. - - \ \ \ \ bytes storage_key = 3; - - \ \ \ \ // Storage keys. - - \ \ \ \ repeated bytes keys = 6; - - } - - \; - - - - - Remote header request. - - <\verbatim> - \; - - message RemoteHeaderRequest { - - \ \ \ \ // Block number to request header for. - - \ \ \ \ bytes block = 2; - - } - - \; - - - - - Remote header response. - - <\verbatim> - \; - - message RemoteHeaderResponse { - - \ \ \ \ // Header. None if proof generation has failed - - \ \ \ \ // (e.g. header is unknown). - - \ \ \ \ bytes header = 2; // optional - - \ \ \ \ // Header proof. - - \ \ \ \ bytes proof = 3; - - } - - \; - - - - - Remote changes request. - - <\verbatim> - \; - - message RemoteChangesRequest { - - \ \ \ \ // Hash of the first block of the range (including first) - - \ \ \ \ // where changes are requested. - - \ \ \ \ bytes first = 2; - - \ \ \ \ // Hash of the last block of the range (including last) - - \ \ \ \ // where changes are requested. - - \ \ \ \ bytes last = 3; - - \ \ \ \ // Hash of the first block for which the requester has - - \ \ \ \ // the changes trie root. All other - - \ \ \ \ // affected roots must be proved. - - \ \ \ \ bytes min = 4; - - \ \ \ \ // Hash of the last block that we can use when - - \ \ \ \ // querying changes. - - \ \ \ \ bytes max = 5; - - \ \ \ \ // Storage child node key which changes are requested. - - \ \ \ \ bytes storage_key = 6; // optional - - \ \ \ \ // Storage key which changes are requested. - - \ \ \ \ bytes key = 7; - - } - - \; - - - - - Remote changes response. - - <\verbatim> - \; - - message RemoteChangesResponse { - - \ \ \ \ // Proof has been generated using block with this number - - \ \ \ \ // as a max block. Should be less than or equal to the - - \ \ \ \ // RemoteChangesRequest::max block number. - - \ \ \ \ bytes max = 2; - - \ \ \ \ // Changes proof. - - \ \ \ \ repeated bytes proof = 3; - - \ \ \ \ // Changes tries roots missing on the requester' node. - - \ \ \ \ repeated Pair roots = 4; - - \ \ \ \ // Missing changes tries roots proof. - - \ \ \ \ bytes roots_proof = 5; - - } - - \; - - // A pair of arbitrary bytes. - - message Pair { - - \ \ \ \ // The first element of the pair. - - \ \ \ \ bytes fst = 1; - - \ \ \ \ // The second element of the pair. - - \ \ \ \ bytes snd = 2; - - } - - \; - - - - - ProtoBuf details: - - <\itemize> - syntax: proto3 - - package: api.v1.finality + - a substream/notification + protocol which sends GRANDPA votes to connected peers. This is a + . .> - - - Request a finality proof from a peer. - - <\verbatim> - \; - - message FinalityProofRequest { - - \ \ \ \ // SCALE-encoded hash of the block to request. - - \ \ \ \ bytes block_hash = 1; - - \ \ \ \ // Opaque chain-specific additional request data. - - \ \ \ \ bytes request = 2; - - } - - \; - - - - - Response to a finality proof request. - - <\verbatim> - \; - - message FinalityProofResponse { - - \ \ \ \ // Opaque chain-specific finality proof. - - \ \ \ \ // Empty if no such proof exists. - - \ \ \ \ bytes proof = 1; // optional - - } - - \; - + : the prefixes on those substreams are known + as protocol identifiers and are used to segregate communications to + specific networks. This prevents any interference with other networks. + is used exclusively for Polkadot. Kusama, for example, + uses the protocol identifier. + + + + The Polkadot Host must actively communicate with the network in order to + participate in the validation process or act as a full node. + + : The Polkadot network originally only used SCALE encoding for + all message formats. Meanwhile, Protobuf has been adopted for certain + messages. The encoding of each message is explicitly mentioned in their + corresponding definition. Encoding and message formats are subject to + change. + + + + When the node creates or receives a new block, it must be announced to the + network. Other nodes within the network will track this announcement and + can request information about this block. The mechanism for tracking + announcement and requesting the required data is implementation specific. + + Block announcements, requests and responses are sent over the + substream as defined in Definition + . + + <\definition> + The + initializes a substream to a remote + peer. Once established, all messages as defined + in Definition are created by the node are + sent to the substream. + + The is a SCALE encoded structure of the + following format: + + <\eqnarray*> + >||,h,h|)>>>>> + + + where: + + <\eqnarray*> + |||>>||>>||>>>>>>>|>||>>|>||>>|>||>>>> + + + + <\definition> + The message is sent + to the specified substream and indicates to remote peers the that node + has either created or received a new block. + + The message is a SCALE encoded structure of the + following format: + + <\eqnarray*> + ||,b|)>>>>> + + + where: + + <\eqnarray*> + >||>>||||>>||>>>>>>>>> + + + + + + Block requests can be used to retrieve a range of blocks from peers. + + <\definition> + The message is a Protobuf serialized structure of + the following format: + + <\big-table||||||>|>|>|>>||||>>>||||>>>||||>>>||||>||||>>>>>>> + Protobuf message. + + + where + + <\itemize-dot> + > indictes all the fields that should be included + in the request. It's encoded bitmask which applies + all desired fields with bitwise OR operations. For example, the + > value to request and + is (17). + + <\big-table||||||>|>>||>||>||>>>>> + Bits of block data to be requested. + + + > is a Protobuf structure indicating a varying + data type of the following values: + + <\big-table||||||>|>|>>|||>|||>>>>> + Protobuf message indicating the block to start from. + + + > is either the block hash or block number + depending on the value of >. An implementation defined + maximum is used when unspecified. + + is a Protobuf structure indicating the + sequence direction of the requested blocks. The structure is a varying + data type as defined in Definition + of the following format: + + <\big-table||||||||||>|>>||>||>||>||>>>>> + Protobuf structure. + + + > is the number of blocks to be returned. An + implementation defined maximum is used when unspecified. + + + + <\definition> + The message is received after sending a + message to a peer. The message is a Protobuf + serialized structure of the following format: + + <\big-table||||||>|>|>>|||>|||>>>>> + Protobuf message. + + + where is a Protobuf structure containing the + requested blocks. Do note that the optional values are either present or + absent depending on the requested fields (bitmask value). The structure + has the following format: + + <\big-table|||||||||||||||||||||||||>|>|>|>>||||>>||||>>||||>>||||>||||>||||>||||>>||||>||||>>>>> + Protobuf structure. + + + + + + Transactions as defined and described in Section + are sent directly to peers with which the + Polkadot Host has an open transaction substream, as defined in Definition + . Polkadot Host implementers should + implement a mechanism which only sends a transaction once to each peer and + avoids sending duplicates. Sending duplicate transactions might result in + undefined consequences such as being blocked for bad behavior by peers. + + The mechanism for managing transactions is further described in Section + . + + <\definition> + The is the + structure of how the transactions are sent over the network. It is + represented by > and is defined as follows: + + <\equation*> + M\Enc,\,C|)> + + + in which: + + <\equation*> + C\Enc|)> + + + Where each > is a byte array and represents a sepearate + extrinsic. The Polkadot Host is agnostic about the content of an + extrinsic and treats it as a blob of data. + + Transactions are sent over the substream. + + + + + The exchange of GRANDPA messages is conducted on the + substream. The process for the creation of + such votes is described in Section . + + \; + + <\with|par-mode|right> + + + + \; + +<\initial> + <\collection> + + + + + + + +<\references> + <\collection> + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + + + +<\auxiliary> + <\collection> + <\associate|table> + |1>|> + |language||BlockRequest> + Protobuf message. + |> + + |2>|> + Bits of block data to be requested. + |> + + |3>|> + Protobuf message indicating the block to start from. + |> + + |4>|> + |language||Direction> + Protobuf structure. + |> + + |5>|> + |language||BlockResponse> + Protobuf message. + |> + + |6>|> + |math-font-series||BlockData> + Protobuf structure. + |> + + <\associate|toc> + |math-font-series||font-size||4Networking> + |.>>>>|> + + + |math-font-series||1Introduction> + |.>>>>|> + + + |1.1External Documentation + |.>>>>|> + > + + |1.2Node Identities + |.>>>>|> + > + + |1.3Discovery mechanism + |.>>>>|> + > + + |1.4Connection establishment + |.>>>>|> + > + + |1.5Encryption Layer + |.>>>>|> + > + + |1.6Protocols and Substreams + |.>>>>|> + > + + |1.7Network Messages + |.>>>>|> + > + + |1.7.1Announcing blocks + |.>>>>|> + > + + |1.7.2Requesting blocks + |.>>>>|> + > + + |1.7.3Transactions + |.>>>>|> + > + + |1.7.4GRANDPA Votes + |.>>>>|> + > + + + \ No newline at end of file diff --git a/host-spec/c04a-networking.tm b/host-spec/c04a-networking.tm deleted file mode 100644 index aedcf60cf..000000000 --- a/host-spec/c04a-networking.tm +++ /dev/null @@ -1,285 +0,0 @@ - - - - - - -<\body> - > - - <\warning> - Polkadot network protocol is work-in-progress. The API specification and - usage may change in future. - - - This chapter offers a high-level description of the network protocol based - on . Polkadot network protocol - relies on . Specifically, the following libp2p modules are being - used in the Polkadot Networking protocol: - - <\itemize> - - - - - - - - - (kademlia) - - - - - - - For more detailed specification of these modules and the Peer-to-Peer layer - see libp2p specification document . - - - - Similar to other decentralized networks, each Polkadot Host node possesses - a network private key and a network public key representing an ED25519 key - pair . - - - - <\definition> - , formally noted by > is derived - from the node's public key as follows: - - >> \ and uniquely identifies a - node on the network. - - - Because the > is derived from the node's public key, - running two or more instances of Polkadot network using the same network - key is contrary to the Polkadot protocol. - - All network communications between nodes on the network use encryption - derived from both sides' keys. - - - - - - \ In order for a Polkadot node to join a peer-to-peer network, it has to - know a list of Polkadot nodes that already take part in the network. This - process of building such a list is referred to as . Each - element of this list is a pair consisting of the peer's node identities and - their addresses.\ - - - - \ Polkadot discovery is done through the following mechanisms: - - <\itemize> - : These are hard-coded node identities and - addresses passed alongside with the network configuration. - - , performing a UDP broadcast on the local network. Nodes - that listen may respond with their identity as described in the mDNS - section of . (Note: mDNS can be disabled - in the network configuration.) - - . Once connected to a peer node, a - Polkadot node can perform a random Kademlia `FIND_NODE` requests for the - nodes to respond by propagating their view of the - network. - - - - - A Polkadot node can establish a connection with nodes in its peer list. All - the connections must always use encryption and multiplexing. While some - nodes' addresses (eg. addresses using `/quic`) already imply the encryption - and/or multiplexing to use, for others the \Pmultistream-select\Q protocol - is used in order to negotiate an encryption layer and/or a multiplexing - layer. - - The following transport protocol is supported by a Polkadot node: - - <\itemize> - for addresses of the form `/ip4/1.2.3.4/tcp/5`. Once - the TCP connection is open, an encryption and a multiplexing layers are - negotiated on top. - - for addresses of the form `/ip4/1.2.3.4/tcp/5/ws`. - A TC/IP connection is open and the WebSockets protocol is negotiated on - top. Communications then happen inside WebSockets data frames. Encryption - and multiplexing are additionally negotiated again inside this channel. - - \ DNS for addresses of the form `/dns4/example.com/tcp/5` or - `/dns4/example.com/tcp/5/ws`. A node's address can contain a domain name. - - - - - \ The following encryption protocols from libp2p are supported by Polkadot - protocol: - - : A TLS-1.2-like protocol but without certificates - . Support for secio will likely to be - deprecated in the future. - - : Noise is a framework for crypto protocols based on - the Diffie-Hellman key agreement . Support for - noise is experimental and details may change in the future. - - \ - - The following multiplexing protocols are supported: - - <\itemize> - : Support for mplex will be deprecated in the future. - - . - - - - - Once a connection has been established between two nodes and is able to use - multiplexing, substreams can be opened. When a substream is open, the - protocol is used to negotiate which protocol to use - on that given substream.\ - - - - A Polkadot Host node should open several substreams. In particular, it - should periodically open ephemeral substreams in order to: - - <\itemize> - ping the remote peer and check whether the connection is still - alive. Failure for the remote peer to reply leads to a disconnection. - This uses the libp2p protocol specified in - . - - ask information from the remote. This is the protocol - specified in . - - send Kademlia random walk queries. Each Kademlia query is done in a - new separate substreams. This uses the libp2p protocol - specified in . - - - - - For the purposes of communicating Polkadot messages, the dailer of the - connection opens a unique substream. Optionally, the node can keep a unique - substream alive for this purpose. The name of the protocol negotiated is - based on the passed as part of the network configuration. - This protocol ID should be unique for each chain and prevents nodes from - different chains to connect to each other. - - The structure of SCALE encoded messages sent over the unique Polkadot - communication substream is described in Appendix - . - - Once the substream is open, the first step is an exchange of a - message from both sides described in Section . - - Communications within this substream include: - - <\itemize> - Syncing. Blocks are announced and requested from other nodes. - - Gossiping. Used by various subprotocols such as GRANDPA. - - Polkadot Network Specialization: . - - - \; - - <\with|par-mode|right> - - - - \; - - -<\initial> - <\collection> - - - - - - -<\references> - <\collection> - > - > - > - > - > - > - > - > - > - > - > - > - > - - - -<\auxiliary> - <\collection> - <\associate|bib> - parity_technologies_substrate_2019 - - protocol_labs_libp2p_2019 - - liusvaara_edwards-curve_2017 - - protocol_labs_libp2p_2019 - - protocol_labs_libp2p_2019 - - perrin_noise_2018 - - protocol_labs_libp2p_2019 - - protocol_labs_libp2p_2019 - - protocol_labs_libp2p_2019 - - <\associate|toc> - |math-font-series||1Network - Protocol> |.>>>>|> - - - 1.1Node Identities and Addresses - |.>>>>|> - - - 1.2Discovery Mechanisms - |.>>>>|> - - - 1.3Transport Protocol |.>>>>|> - - - |1.3.1Encryption - |.>>>>|> - > - - |1.3.2Multiplexing - |.>>>>|> - > - - 1.4Substreams |.>>>>|> - - - |1.4.1Periodic Ephemeral - Substreams |.>>>>|> - > - - |1.4.2Polkadot Communication - Substream |.>>>>|> - > - - - diff --git a/host-spec/host-spec.tm b/host-spec/host-spec.tm index 19b30be80..5ae817dac 100644 --- a/host-spec/host-spec.tm +++ b/host-spec/host-spec.tm @@ -1,4 +1,4 @@ - + > @@ -194,1377 +194,1395 @@ |.>>>>|> > - Discovery mechanism + Node Identities |.>>>>|> > - Connection establishment + Discovery mechanism |.>>>>|> > - Substreams + Connection establishment |.>>>>|> > - 4.2.Network Messages |.>>>>|> - + Encryption Layer + |.>>>>|> + > - API Package + Protocols and Substreams |.>>>>|> > - BlockRequest + Network Messages |.>>>>|> > - BlockResponse + Announcing blocks |.>>>>|> > - Light Package + Requesting blocks |.>>>>|> > - Request - |.>>>>|> - > - - Response - |.>>>>|> - > - - RemoteCallRequest - |.>>>>|> - > - - RemoteCallResponse - |.>>>>|> - > - - RemoteReadRequest - |.>>>>|> - > - - RemoteReadResponse - |.>>>>|> - > - - RemoteReadChildRequest + Transactions |.>>>>|> > - RemoteHeaderRequest + GRANDPA Votes |.>>>>|> > - RemoteHeaderResponse - |.>>>>|> - > - - RemoteChangesRequest - |.>>>>|> - > - - RemoteChangesResponse - |.>>>>|> - > - - Finality Package - |.>>>>|> - > - - FinalityProofRequest - |.>>>>|> - > - - FinalityProofResponse - |.>>>>|> - > - - 4.3. To be migrated |.>>>>|> - - - Node Identities and Addresses - |.>>>>|> - > - - Discovery Mechanisms - |.>>>>|> - > - - Transport Protocol - |.>>>>|> - > - - Encryption - |.>>>>|> - > - - Multiplexing - |.>>>>|> - > - - Substreams - |.>>>>|> - > - - Periodic Ephemeral Substreams - |.>>>>|> - > - - Polkadot Communication Substream - |.>>>>|> - > - Bootstrapping> |.>>>>|> - + Consensus> |.>>>>|> - + 6.1.Common Consensus Structures |.>>>>|> - + Consensus Authority Set |.>>>>|> - > + > Runtime-to-Consensus Engine Message |.>>>>|> - > + > 6.2.Block Production |.>>>>|> - + Preliminaries |.>>>>|> - > + > Block Production Lottery |.>>>>|> - > + > Slot Number Calculation |.>>>>|> - > + > Block Production |.>>>>|> - > + > Epoch Randomness |.>>>>|> - > + > Verifying Authorship Right |.>>>>|> - > + > Block Building Process |.>>>>|> - > + > 6.3.Finality |.>>>>|> - + Preliminaries |.>>>>|> - > + > GRANDPA Messages Specification |.>>>>|> - > + > Vote Messages |.>>>>|> - > + > Finalizing Message |.>>>>|> - > + > Catch-up Messages |.>>>>|> - > + > Initiating the GRANDPA State |.>>>>|> - > + > Voter Set Changes |.>>>>|> - > + > Voting Process in Round |.>>>>|> - > + > 6.4.Block Finalization |.>>>>|> - + Catching up |.>>>>|> - > + > Sending catch-up requests |.>>>>|> - > + > Processing catch-up requests |.>>>>|> - > + > Processing catch-up responses |.>>>>|> - > + > Availability & Validity> |.>>>>|> - + 7.1.Introduction |.>>>>|> - + 7.2.Preliminaries |.>>>>|> - + Extra Validation Data |.>>>>|> - > + > 7.3.Overal process |.>>>>|> - + 7.4.Candidate Selection |.>>>>|> - + 7.5.Candidate Backing |.>>>>|> - + Inclusion of candidate receipt on the relay chain |.>>>>|> - > + > 7.6.PoV Distribution |.>>>>|> - + Primary Validation Disagreement |.>>>>|> - > + > 7.7.Availability |.>>>>|> - + 7.8.Distribution of Chunks |.>>>>|> - + 7.9.Announcing Availability |.>>>>|> - + Processing on-chain availability data |.>>>>|> - > + > 7.10.Publishing Attestations |.>>>>|> - + 7.11.Secondary Approval checking |.>>>>|> - + Approval Checker Assignment |.>>>>|> - > + > VRF computation |.>>>>|> - > + > One-Shot Approval Checker Assignment |.>>>>|> - > + > Extra Approval Checker Assigment |.>>>>|> - > + > Additional Checking in Case of Equivocation |.>>>>|> - > + > 7.12.The Approval Check |.>>>>|> - + Retrieval |.>>>>|> - > + > Reconstruction |.>>>>|> - > + > Verification |.>>>>|> - > + > Process validity and invalidity messages |.>>>>|> - > + > Invalidity Escalation |.>>>>|> - > + > Message Passing> |.>>>>|> - + 8.1.Overview |.>>>>|> - + 8.2.Message Queue Chain (MQC) |.>>>>|> - + 8.3.HRMP |.>>>>|> - + Channels |.>>>>|> - > + > Opening Channels |.>>>>|> - > + > Workflow |.>>>>|> - > + > Accepting Channels |.>>>>|> - > + > Workflow |.>>>>|> - > + > Closing Channels |.>>>>|> - > + > Workflow |.>>>>|> - > + > Sending messages |.>>>>|> - > + > Receiving Messages |.>>>>|> - > + > 8.4.XCMP |.>>>>|> - + CST: Channel State Table |.>>>>|> - > + > Message content |.>>>>|> - > + > Watermark |.>>>>|> - > + > 8.5.SPREE |.>>>>|> - + Cryptographic Algorithms> |.>>>>|> - + A.1.Hash Functions |.>>>>|> - + A.2.BLAKE2 |.>>>>|> - + A.3.Randomness |.>>>>|> - + A.4.VRF |.>>>>|> - + A.5.Cryptographic Keys |.>>>>|> - + Holding and staking funds |.>>>>|> - > + > Creating a Controller key |.>>>>|> - > + > Designating a proxy for voting |.>>>>|> - > + > Controller settings |.>>>>|> - > + > Certifying keys |.>>>>|> - > + > Auxiliary Encodings> |.>>>>|> - + B.1.SCALE Codec |.>>>>|> - + Length and Compact Encoding |.>>>>|> - > + > B.2.Hex Encoding |.>>>>|> - + Genesis State Specification> |.>>>>|> - + Network Messages> |.>>>>|> - + D.Polkadot Host API> |.>>>>|> + + + D.1.Storage |.>>>>|> + - D.1.Detailed Message Structure + |.>>>>|> - + > + + Version 1 - Prototype + |.>>>>|> + > + + + |.>>>>|> + > + + Version 1 - Prototype + |.>>>>|> + > - Status Message + + |.>>>>|> + > + + Version 1 - Prototype + |.>>>>|> + > + + + |.>>>>|> + > + + Version 1 - Prototype + |.>>>>|> + > + + + |.>>>>|> + > + + Version 1 - Prototype + |.>>>>|> + > + + + |.>>>>|> + > + + Version 1 - Prototype + |.>>>>|> + > + + + |.>>>>|> + > + + Version 1 - Prototype + |.>>>>|> + > + + + |.>>>>|> + > + + Version 1 - Prototype + |.>>>>|> + > + + |.>>>>|> > - Block Request Message + Version 1 - Prototype + |.>>>>|> + > + + |.>>>>|> > - Block Response Message + Version 1 - Prototype + |.>>>>|> + > + + |.>>>>|> > - Block Announce Message + Version 1 - Prototype |.>>>>|> > - Transactions + |.>>>>|> > - Consensus Message + Version 1 - Prototype |.>>>>|> > - Neighbor Packet + |.>>>>|> > - Polkadot Host API> |.>>>>|> - + Version 1 - Prototype + |.>>>>|> + > - E.1.Storage |.>>>>|> + D.2.Child Storage |.>>>>|> - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - - |.>>>>|> - > - - Version 1 - Prototype - |.>>>>|> - > + D.3.Crypto |.>>>>|> + - - |.>>>>|> - > - - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - E.2.Child Storage |.>>>>|> - + Version 1 - Prototype + |.>>>>|> + > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 2 - Prototype |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - E.3.Crypto |.>>>>|> - + Version 1 - Prototype + |.>>>>|> + > + + + |.>>>>|> + > + + Version 1 - Prototype + |.>>>>|> + > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - - |.>>>>|> - > + D.4.Hashing |.>>>>|> + - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 2 - Prototype + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - - |.>>>>|> - > - - Version 1 - Prototype - |.>>>>|> - > + D.5.Offchain |.>>>>|> + - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - E.4.Hashing |.>>>>|> - + + |.>>>>|> + > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - E.5.Offchain |.>>>>|> - + Version 1 - Prototype + |.>>>>|> + > + + + |.>>>>|> + > - + Version 1- Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype - |.>>>>|> - > + D.6.Trie |.>>>>|> + - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - - |.>>>>|> - > + D.7.Miscellaneous |.>>>>|> + - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1- Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype - |.>>>>|> - > + D.8.Allocator |.>>>>|> + - + |.>>>>|> > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> > - E.6.Trie |.>>>>|> - - - + |.>>>>|> - > + > - Version 1 - Prototype + Version 1 - Prototype |.>>>>|> - > + > - - |.>>>>|> - > + D.9.Logging |.>>>>|> + - Version 1 - Prototype + |.>>>>|> > - + Version 1 - Prototype |.>>>>|> > - Version 1 - Prototype + Legacy Polkadot Host API> |.>>>>|> - > + - - |.>>>>|> - > + E.1.Storage |.>>>>|> + - Version 1 - Prototype + |.>>>>|> > - E.7.Miscellaneous |.>>>>|> - + + |.>>>>|> + > - + |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - E.8.Allocator |.>>>>|> - + + |.>>>>|> + > - + |.>>>>|> > - Version 1 - Prototype + Memory |.>>>>|> > - + |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - E.9.Logging |.>>>>|> - + Input/Output + |.>>>>|> + > - + Cryptograhpic Auxiliary Functions + |.>>>>|> + > + + |.>>>>|> > - Version 1 - Prototype + |.>>>>|> > - Legacy Polkadot Host API> + |.>>>>|> - + > - F.1.Storage |.>>>>|> - + + |.>>>>|> + > - + |.>>>>|> > - + To be Specced |.>>>>|> > - - |.>>>>|> + Offchain Worker + \ |.>>>>|> > - + |.>>>>|> > - + |.>>>>|> > - + |.>>>>|> > - + |.>>>>|> > - + |.>>>>|> > - + |.>>>>|> > - + |.>>>>|> > - + |.>>>>|> > - + |.>>>>|> > - + |.>>>>|> > - + |.>>>>|> > - Memory + |.>>>>|> > - + |.>>>>|> > - + |.>>>>|> > - Input/Output + |.>>>>|> > - Cryptograhpic Auxiliary Functions + Sandboxing |.>>>>|> > - + To be Specced |.>>>>|> > - + Auxillary Debugging API |.>>>>|> > - + |.>>>>|> > - + |.>>>>|> > - + Misc |.>>>>|> > - To be Specced + To be Specced |.>>>>|> > - Offchain Worker - \ |.>>>>|> + Block Production + |.>>>>|> > - + E.2.Validation |.>>>>|> + + + Runtime Entries> |.>>>>|> + + + F.1.List of Runtime Entries |.>>>>|> - > + - + F.2.JSON-RPC API for external services |.>>>>|> - > + - + F.3.Argument Specification |.>>>>|> - > + - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - Sandboxing + |.>>>>|> - > + > - To be Specced + |.>>>>|> - > + > - Auxillary Debugging API + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - Misc + |.>>>>|> - > + > - To be Specced + |.>>>>|> - > + > - Block Production + |.>>>>|> - > + > - F.2.Validation |.>>>>|> - + + |.>>>>|> + > - Runtime Entries> |.>>>>|> - + + |.>>>>|> + > - G.1.List of Runtime Entries + |.>>>>|> - + > - G.2.Argument Specification + |.>>>>|> - + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + |.>>>>|> - > + > - + + |.>>>>|> + > + + |.>>>>|> > - + |.>>>>|> > + + |.>>>>|> + > + + + |.>>>>|> + > + + + |.>>>>|> + > + + + |.>>>>|> + > + |.>>>>|> - + |.>>>>|> - + |.>>>>|> - + \; @@ -1712,7 +1730,7 @@ <\bibliography|bib|tm-alpha|host-spec> - <\bib-list|12> + <\bib-list|8> Jeff Burdges. Schnorr VRFs and signatures on the Ristretto group. , 2019. @@ -1748,18 +1766,6 @@ >, 8032. 2017. - Protocol labs. - Libp2p Specification. , - Protocol labs, , 2019. - - Ilari - LiusvaaraSimon Josefsson. Edwards-Curve - Digital Signature Algorithm (EdDSA). 2017. - - Trevor Perrin. - The Noise Protocol Framework. , , 2018. - MarkkuJuhani SaarinenJean-Philippe Aumasson. The BLAKE2 cryptographic hash and message authentication code (MAC). @@ -1769,11 +1775,6 @@ Alistair Stewart. GRANDPA: A Byzantine Finality Gadget. 2019. - - Parity - Technologies. Substrate Reference Documentation. - Rust , Parity Technologies, - , 2019. @@ -1795,803 +1796,785 @@ <\references> <\collection> - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - |\>|125>> - > - > - > - > - > - > - |\>|41>> - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + |>|15|c01-background.tm>> + > + > + > + > + > + > + > + > + > + > + |B,B>)|15|c01-background.tm>> + > + > + > + > + > + > + > + > + > + > + |\>BT|)>>|15|c01-background.tm>> + > + > + > + > + > + > + > + > + > + > + |\>|15|c01-background.tm>> + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + |math-font-series|||P>>|13|c01-background.tm>> + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + |\>|139>> + |\>|141>> + > + > + > + > + > + |\>|14|c01-background.tm>> + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + |B>|14|c01-background.tm>> + > + > + > + > + > + > + > + > + > + > + |Enc>|14|c01-background.tm>> + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + |\>|111>> + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > <\auxiliary> <\collection> <\associate|bib> - parity_technologies_substrate_2019 - - protocol_labs_libp2p_2019 - - liusvaara_edwards-curve_2017 - - protocol_labs_libp2p_2019 - - protocol_labs_libp2p_2019 - - perrin_noise_2018 - - protocol_labs_libp2p_2019 - - protocol_labs_libp2p_2019 - - protocol_labs_libp2p_2019 - w3f_research_group_blind_2019 david_ouroboros_2018 @@ -2619,22 +2602,22 @@ Examplary result of Median Algorithm in first sync epoch with |s=9> and |k=1>. - |> + |> |7.1>||Overall process - to acheive availability and validity in Polkadot>|> + to acheive availability and validity in Polkadot>|> |8.1>||Parachain Message - Passing Overview>|> + Passing Overview>|> - |8.2>||MQC - Overview>|> + |8.2>||Message Queue + Chain Overview>|> |8.3>||Parachain XCMP - Overview>|> + Overview>|> - |G.1>||Snippet to export - entries into tho Wasm runtime module.>|> + |F.1>||Snippet to export + entries into tho Wasm runtime module.>|> <\associate|gly> |math-font-series|||P>>|a @@ -2750,37 +2733,37 @@ |> <\associate|parts> - |subsection-nr|0> + - |subsection-nr|1> + - |subsection-nr|1> + - |subsection-nr|4> + - |subsection-nr|3> + - |subsection-nr|4> + - |subsection-nr|4> + - |subsection-nr|1> + - |subsection-nr|3> + - |subsection-nr|0> + - |subsection-nr|5> + - |subsection-nr|0> + - |subsection-nr|0> + - |subsection-nr|7> + - |subsection-nr|1> + - |subsection-nr|0> + <\associate|table> |3.1>|> @@ -2794,123 +2777,128 @@ Possible types of keys of mappings in the Changes Trie |> + |4.1>|> + |language||BlockRequest> + Protobuf message. + |> + + |4.2>|> + Bits of block data to be requested. + |> + + |4.3>|> + Protobuf message indicating the block to start from. + |> + + |4.4>|> + |language||Direction> + Protobuf structure. + |> + + |4.5>|> + |language||BlockResponse> + Protobuf message. + |> + + |4.6>|> + |math-font-series||BlockData> + Protobuf structure. + |> + |6.1>|> The consensus digest item for BABE authorities - |> + |> |6.2>|> The consensus digest item for GRANDPA authorities - |> + |> |6.3>|> \; - |> + |> |6.4>|> Signature for a message in a round. - |> + |> |A.1>|> List of public key scheme which can be used for an account key - |> + |> |A.2>|> List of key schemes which are used for session keys depending on the protocol - |> + |> |C.1>|> Genesis header values - |> + |> - |D.1>||List of possible - network message types.>|> - - |D.2>||Node role - representation in the status message.>|> - - |D.3>||Bit values for - block attribute |A>, to indicate the - requested parts of the data.>|> - - |E.1>|> + |D.1>|> Table of known key type identifiers - |> + |> - |E.2>|> + |D.2>|> Table of error types in ECDSA recovery - |> + |> - |E.3>|> + |D.3>|> Table of possible HTTP error types - |> + |> - |E.4>|> + |D.4>|> Log Levels for the logging interface - |> + |> - |G.1>||Detail of the + |F.1>||Detail of the version data type returns from runtime |language||version> - function.>|> + function.>|> - |G.2>|> - The tuple provided by |math-font-series||BabeApi_configuration>. - |> - - |G.3>|> - The tuple provided by |language||TaggedTransactionQueue_transaction_validity> - - in the case the transaction is judged to be valid. - |> - - |G.4>||Type variation - for the return value of |language||TaggedTransactionQueue_transaction_validity>.>|> - - |G.5>|> - Type variant whichs gets appended to Id 0 of - |math-font-series||TransactionValidityError>. - |> - - |G.6>|> - Type variant whichs gets appended to Id 1 of - |math-font-series||TransactionValidityError>. - |> - - |G.7>|> + |F.2>|> Possible values of varying data type |math-font-series||ApplyExtrinsicResult>. - |> + |> - |G.8>|> + |F.3>|> Possible values of varying data type |math-font-series||DispatchOutcome>. - |> + |> - |G.9>|> + |F.4>|> Possible values of varying data type |math-font-series||DispatchError>. - |> + |> - |G.10>|> + |F.5>|> Possible values of varying data type |math-font-series||CustomModuleError>. - |> + |> - |G.11>|> + |F.6>|> Possible values of varying data type |math-font-series||TransactionValidityError>. - |> + |> - |G.12>|> + |F.7>|> Possible values of varying data type |math-font-series||InvalidTransaction>. - |> + |> - |G.13>|> + |F.8>|> Possible values of varying data type |math-font-series||UnknownTransaction>. - |> + |> + + |F.9>|> + The tuple provided by |language||TaggedTransactionQueue_transaction_validity> + + in the case the transaction is judged to be valid. + |> + + |F.10>|> + The tuple provided by |math-font-series||BabeApi_configuration>. + |> <\associate|toc> |math-font-series||font-shape||1.Background> @@ -3037,1410 +3025,1428 @@ Block |.>>>>|> > - |3.3.3.Managaing Multiple - Variants of State |.>>>>|> - > - - |3.3.4.Changes Trie - |.>>>>|> - > - - |3.3.4.1.Key to extrinsics pairs - |.>>>>|> - > - - |3.3.4.2.Key to block pairs - |.>>>>|> - > - - |3.3.4.3.Key to Child Changes - Trie pairs |.>>>>|> - > - - |math-font-series||font-shape||4.Networking> - |.>>>>|> - - - 4.1.Introduction |.>>>>|> - - - |4.1.1.External Documentation - |.>>>>|> - > - - |4.1.2.Discovery mechanism - |.>>>>|> - > - - |4.1.3.Connection establishment - |.>>>>|> - > - - |4.1.4.Substreams - |.>>>>|> - > - - 4.2.Network Messages |.>>>>|> - - - |4.2.1.API Package - |.>>>>|> - > - - |4.2.1.1.BlockRequest - |.>>>>|> - > - - |4.2.1.2.BlockResponse - |.>>>>|> - > - - |4.2.2.Light Package - |.>>>>|> - > - - |4.2.2.1.Request - |.>>>>|> - > - - |4.2.2.2.Response - |.>>>>|> - > + |3.3.3.Managaing Multiple + Variants of State |.>>>>|> + > - |4.2.2.3.RemoteCallRequest + |3.3.4.Changes Trie |.>>>>|> - > + > - |4.2.2.4.RemoteCallResponse + |3.3.4.1.Key to extrinsics pairs |.>>>>|> - > + > - |4.2.2.5.RemoteReadRequest + |3.3.4.2.Key to block pairs |.>>>>|> - > + > - |4.2.2.6.RemoteReadResponse - |.>>>>|> - > + |3.3.4.3.Key to Child Changes + Trie pairs |.>>>>|> + > - |4.2.2.7.RemoteReadChildRequest + |math-font-series||font-shape||4.Networking> |.>>>>|> - > + - |4.2.2.8.RemoteHeaderRequest - |.>>>>|> - > + 4.1.Introduction |.>>>>|> + - |4.2.2.9.RemoteHeaderResponse + |4.1.1.External Documentation |.>>>>|> - > + > - |4.2.2.10.RemoteChangesRequest + |4.1.2.Node Identities |.>>>>|> - > + > - |4.2.2.11.RemoteChangesResponse + |4.1.3.Discovery mechanism |.>>>>|> - > + > - |4.2.3.Finality Package + |4.1.4.Connection establishment |.>>>>|> - > + > - |4.2.3.1.FinalityProofRequest + |4.1.5.Encryption Layer |.>>>>|> - > + > - |4.2.3.2.FinalityProofResponse + |4.1.6.Protocols and Substreams |.>>>>|> - > - - 4.3. To be migrated |.>>>>|> - - - |4.3.1.Node Identities and - Addresses |.>>>>|> - > + > - |4.3.2.Discovery Mechanisms + |4.1.7.Network Messages |.>>>>|> - > + > - |4.3.3.Transport Protocol + |4.1.7.1.Announcing blocks |.>>>>|> - > + > - |4.3.3.1.Encryption + |4.1.7.2.Requesting blocks |.>>>>|> - > + > - |4.3.3.2.Multiplexing + |4.1.7.3.Transactions |.>>>>|> - > + > - |4.3.4.Substreams + |4.1.7.4.GRANDPA Votes |.>>>>|> - > - - |4.3.4.1.Periodic Ephemeral - Substreams |.>>>>|> - > - - |4.3.4.2.Polkadot Communication - Substream |.>>>>|> - > + > |math-font-series||font-shape||5.Bootstrapping> |.>>>>|> - + |math-font-series||font-shape||6.Consensus> |.>>>>|> - + 6.1.Common Consensus Structures |.>>>>|> - + |6.1.1.Consensus Authority Set |.>>>>|> - > + > |6.1.2.Runtime-to-Consensus Engine Message |.>>>>|> - > + > 6.2.Block Production |.>>>>|> - + |6.2.1.Preliminaries |.>>>>|> - > + > |6.2.2.Block Production Lottery |.>>>>|> - > + > |6.2.3.Slot Number Calculation |.>>>>|> - > + > |6.2.4.Block Production |.>>>>|> - > + > |6.2.5.Epoch Randomness |.>>>>|> - > + > |6.2.6.Verifying Authorship Right |.>>>>|> - > + > |6.2.7.Block Building Process |.>>>>|> - > + > 6.3.Finality |.>>>>|> - + |6.3.1.Preliminaries |.>>>>|> - > + > |6.3.2.GRANDPA Messages Specification |.>>>>|> - > + > |6.3.2.1.Vote Messages |.>>>>|> - > + > |6.3.2.2.Finalizing Message |.>>>>|> - > + > |6.3.2.3.Catch-up Messages |.>>>>|> - > + > |6.3.3.Initiating the GRANDPA State |.>>>>|> - > + > |6.3.3.1.Voter Set Changes |.>>>>|> - > + > |6.3.4.Voting Process in Round |r> |.>>>>|> - > + > 6.4.Block Finalization |.>>>>|> - + |6.4.1.Catching up |.>>>>|> - > + > |6.4.1.1.Sending catch-up requests |.>>>>|> - > + > |6.4.1.2.Processing catch-up requests |.>>>>|> - > + > |6.4.1.3.Processing catch-up responses |.>>>>|> - > + > |math-font-series||font-shape||7.Availability & Validity> |.>>>>|> - + 7.1.Introduction |.>>>>|> - + 7.2.Preliminaries |.>>>>|> - + |7.2.1.Extra Validation Data |.>>>>|> - > + > 7.3.Overal process |.>>>>|> - + 7.4.Candidate Selection |.>>>>|> - + 7.5.Candidate Backing |.>>>>|> - + |7.5.1.Inclusion of candidate receipt on the relay chain |.>>>>|> - > + > 7.6.PoV Distribution |.>>>>|> - + |7.6.1.Primary Validation Disagreement |.>>>>|> - > + > 7.7.Availability |.>>>>|> - + 7.8.Distribution of Chunks |.>>>>|> - + 7.9.Announcing Availability |.>>>>|> - + |7.9.1.Processing on-chain availability data |.>>>>|> - > + > 7.10.Publishing Attestations |.>>>>|> - + 7.11.Secondary Approval checking |.>>>>|> - + |7.11.1.Approval Checker Assignment |.>>>>|> - > + > |7.11.2.VRF computation |.>>>>|> - > + > |7.11.3.One-Shot Approval Checker Assignment |.>>>>|> - > + > |7.11.4.Extra Approval Checker Assigment |.>>>>|> - > + > |7.11.5.Additional Checking in Case of Equivocation |.>>>>|> - > + > 7.12.The Approval Check |.>>>>|> - + |7.12.0.1.Retrieval |.>>>>|> - > + > |7.12.0.2.Reconstruction |.>>>>|> - > + > |7.12.1.Verification |.>>>>|> - > + > |7.12.2.Process validity and invalidity messages |.>>>>|> - > + > |7.12.3.Invalidity Escalation |.>>>>|> - > + > |math-font-series||font-shape||8.Message Passing> |.>>>>|> - + 8.1.Overview |.>>>>|> - + 8.2.Message Queue Chain (MQC) |.>>>>|> - + 8.3.HRMP |.>>>>|> - + |8.3.1.Channels |.>>>>|> - > + > |8.3.2.Opening Channels |.>>>>|> - > + > |8.3.2.1.Workflow |.>>>>|> - > + > |8.3.3.Accepting Channels |.>>>>|> - > + > |8.3.3.1.Workflow |.>>>>|> - > + > |8.3.4.Closing Channels |.>>>>|> - > + > |8.3.5.Workflow |.>>>>|> - > + > |8.3.6.Sending messages |.>>>>|> - > + > |8.3.7.Receiving Messages |.>>>>|> - > + > 8.4.XCMP |.>>>>|> - + |8.4.1.CST: Channel State Table |.>>>>|> - > + > |8.4.2.Message content |.>>>>|> - > + > |8.4.3.Watermark |.>>>>|> - > + > 8.5.SPREE |.>>>>|> - + |math-font-series||font-shape||Appendix A.Cryptographic Algorithms> |.>>>>|> - + A.1.Hash Functions |.>>>>|> - + A.2.BLAKE2 |.>>>>|> - + A.3.Randomness |.>>>>|> - + A.4.VRF |.>>>>|> - + A.5.Cryptographic Keys |.>>>>|> - + |A.5.1.Holding and staking funds |.>>>>|> - > + > |A.5.2.Creating a Controller key |.>>>>|> - > + > |A.5.3.Designating a proxy for voting |.>>>>|> - > + > |A.5.4.Controller settings |.>>>>|> - > + > |A.5.5.Certifying keys |.>>>>|> - > + > |math-font-series||font-shape||Appendix B.Auxiliary Encodings> |.>>>>|> - + B.1.SCALE Codec |.>>>>|> - + |B.1.1.Length and Compact Encoding |.>>>>|> - > + > B.2.Hex Encoding |.>>>>|> - + |math-font-series||font-shape||Appendix C.Genesis State Specification> |.>>>>|> - + |math-font-series||font-shape||Appendix - D.Network Messages> |.>>>>|> - + D.Polkadot Host API> |.>>>>|> + + + D.1.Storage |.>>>>|> + + + |D.1.1.|language||ext_storage_set> + |.>>>>|> + > + + |D.1.1.1.Version 1 - Prototype + |.>>>>|> + > + + |D.1.2.|language||ext_storage_get> + |.>>>>|> + > - D.1.Detailed Message Structure + |D.1.2.1.Version 1 - Prototype |.>>>>|> - + > + + |D.1.3.|language||ext_storage_read> + |.>>>>|> + > + + |D.1.3.1.Version 1 - Prototype + |.>>>>|> + > + + |D.1.4.|language||ext_storage_clear> + |.>>>>|> + > + + |D.1.4.1.Version 1 - Prototype + |.>>>>|> + > + + |D.1.5.|language||ext_storage_exists> + |.>>>>|> + > + + |D.1.5.1.Version 1 - Prototype + |.>>>>|> + > + + |D.1.6.|language||ext_storage_clear_prefix> + |.>>>>|> + > + + |D.1.6.1.Version 1 - Prototype + |.>>>>|> + > + + |D.1.7.|language||ext_storage_append> + |.>>>>|> + > + + |D.1.7.1.Version 1 - Prototype + |.>>>>|> + > + + |D.1.8.|language||ext_storage_root> + |.>>>>|> + > + + |D.1.8.1.Version 1 - Prototype + |.>>>>|> + > - |D.1.1.Status Message + |D.1.9.|language||ext_storage_changes_root> |.>>>>|> > - |D.1.2.Block Request Message + |D.1.9.1.Version 1 - Prototype + |.>>>>|> + > + + |D.1.10.|language||ext_storage_next_key> |.>>>>|> > - |D.1.3.Block Response Message + |D.1.10.1.Version 1 - Prototype + |.>>>>|> + > + + |D.1.11.|language||ext_storage_start_transaction> |.>>>>|> > - |D.1.4.Block Announce Message + |D.1.11.1.Version 1 - Prototype |.>>>>|> > - |D.1.5.Transactions + |D.1.12.|language||ext_storage_rollback_transaction> |.>>>>|> > - |D.1.6.Consensus Message + |D.1.12.1.Version 1 - Prototype |.>>>>|> > - |D.1.7.Neighbor Packet + |D.1.13.|language||ext_storage_commit_transaction> |.>>>>|> > - |math-font-series||font-shape||Appendix - E.Polkadot Host API> |.>>>>|> - + |D.1.13.1.Version 1 - Prototype + |.>>>>|> + > - E.1.Storage |.>>>>|> + D.2.Child Storage |.>>>>|> - |E.1.1.|language||ext_storage_set> + |D.2.1.|language||ext_default_child_storage_set> |.>>>>|> > - |E.1.1.1.Version 1 - Prototype + |D.2.1.1.Version 1 - Prototype |.>>>>|> > - |E.1.2.|language||ext_storage_get> + |D.2.2.|language||ext_default_child_storage_get> |.>>>>|> > - |E.1.2.1.Version 1 - Prototype + |D.2.2.1.Version 1 - Prototype |.>>>>|> > - |E.1.3.|language||ext_storage_read> + |D.2.3.|language||ext_default_child_storage_read> |.>>>>|> > - |E.1.3.1.Version 1 - Prototype + |D.2.3.1.Version 1 - Prototype |.>>>>|> > - |E.1.4.|language||ext_storage_clear> + |D.2.4.|language||ext_default_child_storage_clear> |.>>>>|> > - |E.1.4.1.Version 1 - Prototype + |D.2.4.1.Version 1 - Prototype |.>>>>|> > - |E.1.5.|language||ext_storage_exists> + |D.2.5.|language||ext_default_child_storage_storage_kill> |.>>>>|> > - |E.1.5.1.Version 1 - Prototype + |D.2.5.1.Version 1 - Prototype |.>>>>|> > - |E.1.6.|language||ext_storage_clear_prefix> + |D.2.6.|language||ext_default_child_storage_exists> |.>>>>|> > - |E.1.6.1.Version 1 - Prototype + |D.2.6.1.Version 1 - Prototype |.>>>>|> > - |E.1.7.|language||ext_storage_append> + |D.2.7.|language||ext_default_child_storage_clear_prefix> |.>>>>|> > - |E.1.7.1.Version 1 - Prototype + |D.2.7.1.Version 1 - Prototype |.>>>>|> > - |E.1.8.|language||ext_storage_root> + |D.2.8.|language||ext_default_child_storage_root> |.>>>>|> > - |E.1.8.1.Version 1 - Prototype + |D.2.8.1.Version 1 - Prototype |.>>>>|> > - |E.1.9.|language||ext_storage_changes_root> + |D.2.9.|language||ext_default_child_storage_next_key> |.>>>>|> > - |E.1.9.1.Version 1 - Prototype + |D.2.9.1.Version 1 - Prototype |.>>>>|> > - |E.1.10.|language||ext_storage_next_key> - |.>>>>|> - > - - |E.1.10.1.Version 1 - Prototype - |.>>>>|> - > - - |E.1.11.|language||ext_storage_start_transaction> - |.>>>>|> - > + D.3.Crypto |.>>>>|> + - |E.1.11.1.Version 1 - Prototype + |D.3.1.|language||ext_crypto_ed25519_public_keys> |.>>>>|> > - |E.1.12.|language||ext_storage_rollback_transaction> + |D.3.1.1.Version 1 - Prototype |.>>>>|> > - |E.1.12.1.Version 1 - Prototype + |D.3.2.|language||ext_crypto_ed25519_generate> |.>>>>|> > - |E.1.13.|language||ext_storage_commit_transaction> + |D.3.2.1.Version 1 - Prototype |.>>>>|> > - |E.1.13.1.Version 1 - Prototype + |D.3.3.|language||ext_crypto_ed25519_sign> |.>>>>|> > - E.2.Child Storage |.>>>>|> - + |D.3.3.1.Version 1 - Prototype + |.>>>>|> + > - |E.2.1.|language||ext_default_child_storage_set> + |D.3.4.|language||ext_crypto_ed25519_verify> |.>>>>|> > - |E.2.1.1.Version 1 - Prototype + |D.3.4.1.Version 1 - Prototype |.>>>>|> > - |E.2.2.|language||ext_default_child_storage_get> + |D.3.5.|language||ext_crypto_sr25519_public_keys> |.>>>>|> > - |E.2.2.1.Version 1 - Prototype + |D.3.5.1.Version 1 - Prototype |.>>>>|> > - |E.2.3.|language||ext_default_child_storage_read> + |D.3.6.|language||ext_crypto_sr25519_generate> |.>>>>|> > - |E.2.3.1.Version 1 - Prototype + |D.3.6.1.Version 1 - Prototype |.>>>>|> > - |E.2.4.|language||ext_default_child_storage_clear> + |D.3.7.|language||ext_crypto_sr25519_sign> |.>>>>|> > - |E.2.4.1.Version 1 - Prototype + |D.3.7.1.Version 1 - Prototype |.>>>>|> > - |E.2.5.|language||ext_default_child_storage_storage_kill> + |D.3.8.|language||ext_crypto_sr25519_verify> |.>>>>|> > - |E.2.5.1.Version 1 - Prototype + |D.3.8.1.Version 2 - Prototype |.>>>>|> > - |E.2.6.|language||ext_default_child_storage_exists> + |D.3.8.2.Version 1 - Prototype |.>>>>|> > - |E.2.6.1.Version 1 - Prototype + |D.3.9.|language||ext_crypto_ecdsa_public_keys> |.>>>>|> > - |E.2.7.|language||ext_default_child_storage_clear_prefix> + |D.3.9.1.Version 1 - Prototype |.>>>>|> > - |E.2.7.1.Version 1 - Prototype + |D.3.10.|language||ext_crypto_ecdsa_generate> |.>>>>|> > - |E.2.8.|language||ext_default_child_storage_root> + |D.3.10.1.Version 1 - Prototype |.>>>>|> > - |E.2.8.1.Version 1 - Prototype + |D.3.11.|language||ext_crypto_ecdsa_sign> |.>>>>|> > - |E.2.9.|language||ext_default_child_storage_next_key> + |D.3.11.1.Version 1 - Prototype |.>>>>|> > - |E.2.9.1.Version 1 - Prototype + |D.3.12.|language||ext_crypto_ecdsa_verify> |.>>>>|> > - E.3.Crypto |.>>>>|> - + |D.3.12.1.Version 1 - Prototype + |.>>>>|> + > + + |D.3.13.|language||ext_crypto_secp256k1_ecdsa_recover> + |.>>>>|> + > + + |D.3.13.1.Version 1 - Prototype + |.>>>>|> + > - |E.3.1.|language||ext_crypto_ed25519_public_keys> + |D.3.14.|language||ext_crypto_secp256k1_ecdsa_recover_compressed> |.>>>>|> > - |E.3.1.1.Version 1 - Prototype + |D.3.14.1.Version 1 - Prototype |.>>>>|> > - |E.3.2.|language||ext_crypto_ed25519_generate> + |D.3.15.|language||ext_crypto_start_batch_verify> |.>>>>|> > - |E.3.2.1.Version 1 - Prototype + |D.3.15.1.Version 1 - Prototype |.>>>>|> > - |E.3.3.|language||ext_crypto_ed25519_sign> + |D.3.16.|language||ext_crypto_finish_batch_verify> |.>>>>|> > - |E.3.3.1.Version 1 - Prototype + |D.3.16.1.Version 1 - Prototype |.>>>>|> > - |E.3.4.|language||ext_crypto_ed25519_verify> - |.>>>>|> - > + D.4.Hashing |.>>>>|> + - |E.3.4.1.Version 1 - Prototype + |D.4.1.|language||ext_hashing_keccak_256> |.>>>>|> > - |E.3.5.|language||ext_crypto_sr25519_public_keys> + |D.4.1.1.Version 1 - Prototype |.>>>>|> > - |E.3.5.1.Version 1 - Prototype + |D.4.2.|language||ext_hashing_sha2_256> |.>>>>|> > - |E.3.6.|language||ext_crypto_sr25519_generate> + |D.4.2.1.Version 1 - Prototype |.>>>>|> > - |E.3.6.1.Version 1 - Prototype + |D.4.3.|language||ext_hashing_blake2_128> |.>>>>|> > - |E.3.7.|language||ext_crypto_sr25519_sign> + |D.4.3.1.Version 1 - Prototype |.>>>>|> > - |E.3.7.1.Version 1 - Prototype + |D.4.4.|language||ext_hashing_blake2_256> |.>>>>|> > - |E.3.8.|language||ext_crypto_sr25519_verify> + |D.4.4.1.Version 1 - Prototype |.>>>>|> > - |E.3.8.1.Version 2 - Prototype + |D.4.5.|language||ext_hashing_twox_64> |.>>>>|> > - |E.3.8.2.Version 1 - Prototype + |D.4.5.1.Version 1 - Prototype |.>>>>|> > - |E.3.9.|language||ext_crypto_ecdsa_public_keys> + |D.4.6.|language||ext_hashing_twox_128> |.>>>>|> > - |E.3.9.1.Version 1 - Prototype + |D.4.6.1.Version 1 - Prototype |.>>>>|> > - |E.3.10.|language||ext_crypto_ecdsa_generate> + |D.4.7.|language||ext_hashing_twox_256> |.>>>>|> > - |E.3.10.1.Version 1 - Prototype + |D.4.7.1.Version 1 - Prototype |.>>>>|> > - |E.3.11.|language||ext_crypto_ecdsa_sign> - |.>>>>|> - > - - |E.3.11.1.Version 1 - Prototype - |.>>>>|> - > + D.5.Offchain |.>>>>|> + - |E.3.12.|language||ext_crypto_ecdsa_verify> + |D.5.1.|language||ext_offchain_is_validator> |.>>>>|> > - |E.3.12.1.Version 1 - Prototype + |D.5.1.1.Version 1 - Prototype |.>>>>|> > - |E.3.13.|language||ext_crypto_secp256k1_ecdsa_recover> + |D.5.2.|language||ext_offchain_submit_transaction> |.>>>>|> > - |E.3.13.1.Version 1 - Prototype + |D.5.2.1.Version 1 - Prototype |.>>>>|> > - |E.3.14.|language||ext_crypto_secp256k1_ecdsa_recover_compressed> + |D.5.3.|language||ext_offchain_network_state> |.>>>>|> > - |E.3.14.1.Version 1 - Prototype + |D.5.3.1.Version 1 - Prototype |.>>>>|> > - |E.3.15.|language||ext_crypto_start_batch_verify> + |D.5.4.|language||ext_offchain_timestamp> |.>>>>|> > - |E.3.15.1.Version 1 - Prototype + |D.5.4.1.Version 1 - Prototype |.>>>>|> > - |E.3.16.|language||ext_crypto_finish_batch_verify> + |D.5.5.|language||ext_offchain_sleep_until> |.>>>>|> > - |E.3.16.1.Version 1 - Prototype + |D.5.5.1.Version 1 - Prototype |.>>>>|> > - E.4.Hashing |.>>>>|> - + |D.5.6.|language||ext_offchain_random_seed> + |.>>>>|> + > - |E.4.1.|language||ext_hashing_keccak_256> + |D.5.6.1.Version 1 - Prototype |.>>>>|> > - |E.4.1.1.Version 1 - Prototype + |D.5.7.|language||ext_offchain_local_storage_set> |.>>>>|> > - |E.4.2.|language||ext_hashing_sha2_256> + |D.5.7.1.Version 1 - Prototype |.>>>>|> > - |E.4.2.1.Version 1 - Prototype + |D.5.8.|language||ext_offchain_local_storage_clear> |.>>>>|> > - |E.4.3.|language||ext_hashing_blake2_128> + |D.5.8.1.Version 1 - Prototype |.>>>>|> > - |E.4.3.1.Version 1 - Prototype + |D.5.9.|language||ext_offchain_local_storage_compare_and_set> |.>>>>|> > - |E.4.4.|language||ext_hashing_blake2_256> + |D.5.9.1.Version 1 - Prototype |.>>>>|> > - |E.4.4.1.Version 1 - Prototype + |D.5.10.|language||ext_offchain_local_storage_get> |.>>>>|> > - |E.4.5.|language||ext_hashing_twox_64> + |D.5.10.1.Version 1 - Prototype |.>>>>|> > - |E.4.5.1.Version 1 - Prototype + |D.5.11.|language||ext_offchain_http_request_start> |.>>>>|> > - |E.4.6.|language||ext_hashing_twox_128> + |D.5.11.1.Version 1 - Prototype |.>>>>|> > - |E.4.6.1.Version 1 - Prototype + |D.5.12.|language||ext_offchain_http_request_add_header> |.>>>>|> > - |E.4.7.|language||ext_hashing_twox_256> + |D.5.12.1.Version 1 - Prototype |.>>>>|> > - |E.4.7.1.Version 1 - Prototype + |D.5.13.|language||ext_offchain_http_request_write_body> |.>>>>|> > - E.5.Offchain |.>>>>|> - + |D.5.13.1.Version 1 - Prototype + |.>>>>|> + > + + |D.5.14.|language||ext_offchain_http_response_wait> + |.>>>>|> + > - |E.5.1.|language||ext_offchain_is_validator> + |D.5.14.1.Version 1- Prototype |.>>>>|> > - |E.5.1.1.Version 1 - Prototype + |D.5.15.|language||ext_offchain_http_response_headers> |.>>>>|> > - |E.5.2.|language||ext_offchain_submit_transaction> + |D.5.15.1.Version 1 - Prototype |.>>>>|> > - |E.5.2.1.Version 1 - Prototype + |D.5.16.|language||ext_offchain_http_response_read_body> |.>>>>|> > - |E.5.3.|language||ext_offchain_network_state> + |D.5.16.1.Version 1 - Prototype |.>>>>|> > - |E.5.3.1.Version 1 - Prototype + |D.5.17.|language||ext_offchain_set_authorized_nodes> |.>>>>|> > - |E.5.4.|language||ext_offchain_timestamp> + |D.5.17.1.Version 1 - Prototype |.>>>>|> > - |E.5.4.1.Version 1 - Prototype - |.>>>>|> - > + D.6.Trie |.>>>>|> + - |E.5.5.|language||ext_offchain_sleep_until> + |D.6.1.|language||ext_trie_blake2_256_root> |.>>>>|> > - |E.5.5.1.Version 1 - Prototype + |D.6.1.1.Version 1 - Prototype |.>>>>|> > - |E.5.6.|language||ext_offchain_random_seed> + |D.6.2.|language||ext_trie_blake2_256_ordered_root> |.>>>>|> > - |E.5.6.1.Version 1 - Prototype + |D.6.2.1.Version 1 - Prototype |.>>>>|> > - |E.5.7.|language||ext_offchain_local_storage_set> + |D.6.3.|language||ext_trie_keccak_256_root> |.>>>>|> > - |E.5.7.1.Version 1 - Prototype + |D.6.3.1.Version 1 - Prototype |.>>>>|> > - |E.5.8.|language||ext_offchain_local_storage_compare_and_set> + |D.6.4.|language||ext_trie_keccak_256_ordered_root> |.>>>>|> > - |E.5.8.1.Version 1 - Prototype + |D.6.4.1.Version 1 - Prototype |.>>>>|> > - |E.5.9.|language||ext_offchain_local_storage_get> - |.>>>>|> - > + D.7.Miscellaneous |.>>>>|> + - |E.5.9.1.Version 1 - Prototype + |D.7.1.|language||ext_misc_chain_id> |.>>>>|> > - |E.5.10.|language||ext_offchain_http_request_start> + |D.7.1.1.Version 1 - Prototype |.>>>>|> > - |E.5.10.1.Version 1 - Prototype + |D.7.2.|language||ext_misc_print_num> |.>>>>|> > - |E.5.11.|language||ext_offchain_http_request_add_header> + |D.7.2.1.Version 1 - Prototype |.>>>>|> > - |E.5.11.1.Version 1 - Prototype + |D.7.3.|language||ext_misc_print_utf8> |.>>>>|> > - |E.5.12.|language||ext_offchain_http_request_write_body> + |D.7.3.1.Version 1 - Prototype |.>>>>|> > - |E.5.12.1.Version 1 - Prototype + |D.7.4.|language||ext_misc_print_hex> |.>>>>|> > - |E.5.13.|language||ext_offchain_http_response_wait> + |D.7.4.1.Version 1 - Prototype |.>>>>|> > - |E.5.13.1.Version 1- Prototype + |D.7.5.|language||ext_misc_runtime_version> |.>>>>|> > - |E.5.14.|language||ext_offchain_http_response_headers> + |D.7.5.1.Version 1 - Prototype |.>>>>|> > - |E.5.14.1.Version 1 - Prototype - |.>>>>|> - > + D.8.Allocator |.>>>>|> + - |E.5.15.|language||ext_offchain_http_response_read_body> + |D.8.1.|language||ext_allocator_malloc> |.>>>>|> > - |E.5.15.1.Version 1 - Prototype + |D.8.1.1.Version 1 - Prototype |.>>>>|> > - E.6.Trie |.>>>>|> - - - |E.6.1.|language||ext_trie_blake2_256_root> + |D.8.2.|language||ext_allocator_free> |.>>>>|> - > + > - |E.6.1.1.Version 1 - Prototype + |D.8.2.1.Version 1 - Prototype |.>>>>|> - > + > - |E.6.2.|language||ext_trie_blake2_256_ordered_root> - |.>>>>|> - > + D.9.Logging |.>>>>|> + - |E.6.2.1.Version 1 - Prototype + |D.9.1.|language||ext_logging_log> |.>>>>|> > - |E.6.3.|language||ext_trie_keccak_256_root> + |D.9.1.1.Version 1 - Prototype |.>>>>|> > - |E.6.3.1.Version 1 - Prototype + |math-font-series||font-shape||Appendix + E.Legacy Polkadot Host API> |.>>>>|> - > + - |E.6.4.|language||ext_trie_keccak_256_ordered_root> - |.>>>>|> - > + E.1.Storage |.>>>>|> + - |E.6.4.1.Version 1 - Prototype + |E.1.1.|language||ext_set_storage> |.>>>>|> > - E.7.Miscellaneous |.>>>>|> - + |E.1.2.|language||ext_storage_root> + |.>>>>|> + > - |E.7.1.|language||ext_misc_chain_id> + |E.1.3.|language||ext_blake2_256_enumerated_trie_root> |.>>>>|> > - |E.7.1.1.Version 1 - Prototype + |E.1.4.|language||ext_clear_prefix> |.>>>>|> > - |E.7.2.|language||ext_misc_print_num> + |E.1.5.|language||>|language||ext_clear_storage> |.>>>>|> > - |E.7.2.1.Version 1 - Prototype + |E.1.6.|language||ext_exists_storage> |.>>>>|> > - |E.7.3.|language||ext_misc_print_utf8> + |E.1.7.|language||ext_get_allocated_storage> |.>>>>|> > - |E.7.3.1.Version 1 - Prototype + |E.1.8.|language||ext_get_storage_into> |.>>>>|> > - |E.7.4.|language||ext_misc_print_hex> + |E.1.9.|language||ext_set_child_storage> |.>>>>|> > - |E.7.4.1.Version 1 - Prototype + |E.1.10.|language||ext_clear_child_storage> |.>>>>|> > - |E.7.5.|language||ext_misc_runtime_version> + |E.1.11.|language||ext_exists_child_storage> |.>>>>|> > - |E.7.5.1.Version 1 - Prototype + |E.1.12.|language||ext_get_allocated_child_storage> |.>>>>|> > - E.8.Allocator |.>>>>|> - + |E.1.13.|language||ext_get_child_storage_into> + |.>>>>|> + > - |E.8.1.|language||ext_allocator_malloc> + |E.1.14.|language||ext_kill_child_storage> |.>>>>|> > - |E.8.1.1.Version 1 - Prototype + |E.1.15.Memory |.>>>>|> > - |E.8.2.|language||ext_allocator_free> + |E.1.15.1.|language||ext_malloc> |.>>>>|> > - |E.8.2.1.Version 1 - Prototype + |E.1.15.2.|language||ext_free> |.>>>>|> > - E.9.Logging |.>>>>|> - + |E.1.15.3.Input/Output + |.>>>>|> + > + + |E.1.16.Cryptograhpic Auxiliary + Functions |.>>>>|> + > - |E.9.1.|language||ext_logging_log> + |E.1.16.1.|language||ext_blake2_256> |.>>>>|> > - |E.9.1.1.Version 1 - Prototype + |E.1.16.2.|language||ext_keccak_256> |.>>>>|> > - |math-font-series||font-shape||Appendix - F.Legacy Polkadot Host API> + |E.1.16.3.|language||ext_twox_128> |.>>>>|> - + > - F.1.Storage |.>>>>|> - + |E.1.16.4.|language||ext_ed25519_verify> + |.>>>>|> + > - |F.1.1.|language||ext_set_storage> + |E.1.16.5.|language||ext_sr25519_verify> |.>>>>|> > - |F.1.2.|language||ext_storage_root> + |E.1.16.6.To be Specced |.>>>>|> > - |F.1.3.|language||ext_blake2_256_enumerated_trie_root> - |.>>>>|> + |E.1.17.Offchain Worker + \ |.>>>>|> > - |F.1.4.|language||ext_clear_prefix> + |E.1.17.1.|language||ext_is_validator> |.>>>>|> > - |F.1.5.|language||>|language||ext_clear_storage> + |E.1.17.2.|language||ext_submit_transaction> |.>>>>|> > - |F.1.6.|language||ext_exists_storage> + |E.1.17.3.|language||ext_network_state> |.>>>>|> > - |F.1.7.|language||ext_get_allocated_storage> + |E.1.17.4.|language||ext_timestamp> |.>>>>|> > - |F.1.8.|language||ext_get_storage_into> + |E.1.17.5.|language||ext_sleep_until> |.>>>>|> > - |F.1.9.|language||ext_set_child_storage> + |E.1.17.6.|language||ext_random_seed> |.>>>>|> > - |F.1.10.|language||ext_clear_child_storage> + |E.1.17.7.|language||ext_local_storage_set> |.>>>>|> > - |F.1.11.|language||ext_exists_child_storage> + |E.1.17.8.|language||ext_local_storage_compare_and_set> |.>>>>|> > - |F.1.12.|language||ext_get_allocated_child_storage> + |E.1.17.9.|language||ext_local_storage_get> |.>>>>|> > - |F.1.13.|language||ext_get_child_storage_into> + |E.1.17.10.|language||ext_http_request_start> |.>>>>|> > - |F.1.14.|language||ext_kill_child_storage> + |E.1.17.11.|language||ext_http_request_add_header> |.>>>>|> > - |F.1.15.Memory + |E.1.17.12.|language||ext_http_request_write_body> |.>>>>|> > - |F.1.15.1.|language||ext_malloc> + |E.1.17.13.|language||ext_http_response_wait> |.>>>>|> > - |F.1.15.2.|language||ext_free> + |E.1.17.14.|language||ext_http_response_headers> |.>>>>|> > - |F.1.15.3.Input/Output + |E.1.17.15.|language||ext_http_response_read_body> |.>>>>|> > - |F.1.16.Cryptograhpic Auxiliary - Functions |.>>>>|> + |E.1.18.Sandboxing + |.>>>>|> > - |F.1.16.1.|language||ext_blake2_256> + |E.1.18.1.To be Specced |.>>>>|> > - |F.1.16.2.|language||ext_keccak_256> + |E.1.19.Auxillary Debugging API |.>>>>|> > - |F.1.16.3.|language||ext_twox_128> + |E.1.19.1.|language||ext_print_hex> |.>>>>|> > - |F.1.16.4.|language||ext_ed25519_verify> + |E.1.19.2.|language||ext_print_utf8> |.>>>>|> > - |F.1.16.5.|language||ext_sr25519_verify> + |E.1.20.Misc |.>>>>|> > - |F.1.16.6.To be Specced + |E.1.20.1.To be Specced |.>>>>|> > - |F.1.17.Offchain Worker - \ |.>>>>|> + |E.1.21.Block Production + |.>>>>|> > - |F.1.17.1.|language||ext_is_validator> + E.2.Validation |.>>>>|> + + + |math-font-series||font-shape||Appendix + F.Runtime Entries> |.>>>>|> + + + F.1.List of Runtime Entries |.>>>>|> - > + - |F.1.17.2.|language||ext_submit_transaction> + F.2.JSON-RPC API for external services |.>>>>|> - > + - |F.1.17.3.|language||ext_network_state> + F.3.Argument Specification |.>>>>|> - > + - |F.1.17.4.|language||ext_timestamp> + |F.3.1.|language||Core_version> |.>>>>|> - > + > - |F.1.17.5.|language||ext_sleep_until> + |F.3.2.|language||Core_execute_block> |.>>>>|> - > + > - |F.1.17.6.|language||ext_random_seed> + |F.3.3.|language||Core_initialize_block> |.>>>>|> - > + > - |F.1.17.7.|language||ext_local_storage_set> + |F.3.4.|language||Metadata_metadata> |.>>>>|> - > + > - |F.1.17.8.|language||ext_local_storage_compare_and_set> + |F.3.5.|language||BlockBuilder_apply_extrinsic> |.>>>>|> - > + > - |F.1.17.9.|language||ext_local_storage_get> + |F.3.6.|language||BlockBuilder_finalize_block> |.>>>>|> - > + > - |F.1.17.10.|language||ext_http_request_start> + |F.3.7.|language||BlockBuilder_inherent_extrinsics> |.>>>>|> - > + > - |F.1.17.11.|language||ext_http_request_add_header> + |F.3.8.|language||BlockBuilder_check_inherents> |.>>>>|> - > + > - |F.1.17.12.|language||ext_http_request_write_body> + |F.3.9.|language||BlockBuilder_random_seed> |.>>>>|> - > + > + + |F.3.10.|language||TaggedTransactionQueue_validate_transaction> + |.>>>>|> + > - |F.1.17.13.|language||ext_http_response_wait> + |F.3.11.|language||OffchainWorkerApi_offchain_worker> |.>>>>|> - > + > - |F.1.17.14.|language||ext_http_response_headers> + |F.3.12.|language||ParachainHost_validators> |.>>>>|> - > + > - |F.1.17.15.|language||ext_http_response_read_body> + |F.3.13.|language||ParachainHost_validator_groups> |.>>>>|> - > + > - |F.1.18.Sandboxing + |F.3.14.|language||ParachainHost_availability_cores> |.>>>>|> - > + > - |F.1.18.1.To be Specced + |F.3.15.|language||ParachainHost_persisted_validation_data> |.>>>>|> - > + > - |F.1.19.Auxillary Debugging API + |F.3.16.|language||ParachainHost_check_validation_outputs> |.>>>>|> - > + > - |F.1.19.1.|language||ext_print_hex> + |F.3.17.|language||ParachainHost_session_index_for_child> |.>>>>|> - > + > - |F.1.19.2.|language||ext_print_utf8> + |F.3.18.|language||ParachainHost_session_info> |.>>>>|> - > + > - |F.1.20.Misc + |F.3.19.|language||ParachainHost_validation_code> |.>>>>|> - > + > - |F.1.20.1.To be Specced + |F.3.20.|language||ParachainHost_historical_validation_code> |.>>>>|> - > + > - |F.1.21.Block Production + |F.3.21.|language||ParachainHost_candidate_pending_availability> |.>>>>|> - > + > - F.2.Validation |.>>>>|> - + |F.3.22.|language||ParachainHost_candidate_events> + |.>>>>|> + > - |math-font-series||font-shape||Appendix - G.Runtime Entries> |.>>>>|> - + |F.3.23.|language||ParachainHost_dmq_contents> + |.>>>>|> + > - G.1.List of Runtime Entries + |F.3.24.|language||ParachainHost_inbound_hrmp_channel_contents> |.>>>>|> - + > - G.2.Argument Specification + |F.3.25.|language||GrandpaApi_grandpa_authorities> |.>>>>|> - + > - |G.2.1.|language||Core_version> + |F.3.26.|language||GrandpaApi_submit_report_equivocation_unsigned_extrinsic> |.>>>>|> - > + > - |G.2.2.|language||Core_execute_block> + |F.3.27.|language||GrandpaApi_generate_key_ownership_proof> |.>>>>|> - > + > - |G.2.3.|language||Core_initialize_block> + |F.3.28.|language||BabeApi_configuration> |.>>>>|> - > + > - |G.2.4.|language||hash_and_length> + |F.3.29.|language||BabeApi_current_epoch_start> |.>>>>|> - > + > - |G.2.5.|language||BabeApi_configuration> + |F.3.30.|language||BabeApi_current_epoch> |.>>>>|> - > + > - |G.2.6.|language||GrandpaApi_grandpa_authorities> + |F.3.31.|language||BabeApi_next_epoch> |.>>>>|> - > + > - |G.2.7.|language||TaggedTransactionQueue_validate_transaction> + |F.3.32.|language||BabeApi_generate_key_ownership_proof> |.>>>>|> - > + > - |G.2.8.|language||BlockBuilder_apply_extrinsic> + |F.3.33.|language||BabeApi_submit_report_equivocation_unsigned_extrinsic> |.>>>>|> - > + > - |G.2.9.|language||BlockBuilder_inherent_extrinsics> + |F.3.34.|language||AuthorityDiscoveryApi_authorities> |.>>>>|> > - |G.2.10.|language||BlockBuilder_finalize_block> + |F.3.35.|language||SessionKeys_generate_session_keys> |.>>>>|> > + |F.3.36.|language||SessionKeys_decode_session_keys> + |.>>>>|> + > + + |F.3.37.|language||AccountNonceApi_account_nonce> + |.>>>>|> + > + + |F.3.38.|language||TransactionPaymentApi_query_info> + |.>>>>|> + > + + |F.3.39.|language||TransactionPaymentApi_query_fee_details> + |.>>>>|> + > + |math-font-series||font-shape||Glossary> |.>>>>|> - + |math-font-series||font-shape||Bibliography> |.>>>>|> - + |math-font-series||font-shape||Index> |.>>>>|> - + \ No newline at end of file