Merge pull request #1478 from ACStoneCL/Binary_Serialization_Standard

Binary Serialization Standard

.github/workflows/main.yml

@@ -171,10 +171,6 @@ jobs:
         echo "Jekyll site is up..."
         echo "Testing if homepage responds correctly"
         curl --fail http://127.0.0.1:4000/
-        echo "Testing if a page responds correctly"
-        curl --fail http://127.0.0.1:4000/operators/setup-network/chain-spec/
-        echo "Testing if a page responds correctly"
-        curl --fail http://127.0.0.1:4000/concepts/serialization-standard/
       working-directory: ./docs
 
   deploy-preview:
@@ -233,14 +229,6 @@ jobs:
         run: |
           echo "Testing if homepage responds correctly"
           curl --fail https://$prod_pages_fqdn
-      - name: Test a random page
-        run: |
-          echo "Testing if a page responds correctly"
-          curl --fail https://$prod_pages_fqdn/operators/setup-network/chain-spec
-      - name: Test another random page
-        run: |
-          echo "Testing if a page responds correctly"
-          curl --fail https://$prod_pages_fqdn/concepts/serialization-standard
 
   rollback-if-tests-fail-prod:
     if: ${{ always() && (needs.system-tests-postdeployment-prod.result=='failure') }}

config/sidebar.config.js

@@ -2,17 +2,6 @@ module.exports = {
     concepts: [
         "concepts/index",
         "concepts/about",
-        "concepts/intro-to-dapps",
-        "concepts/addressable-entity",
-        "concepts/accounts-and-keys",
-        "concepts/key-types",
-        "concepts/transactions-and-transaction-lifecycle",
-        "concepts/global-state",
-        "concepts/smart-contracts",
-        "concepts/list-auth-keys",
-        "concepts/callstack",
-        "concepts/dictionaries",
-        "concepts/serialization-standard",
         {
             type: "category",
             label: "Design",
@@ -89,6 +78,31 @@ module.exports = {
                 "concepts/glossary/Z",
             ],
         },
+        {
+            type: "category",
+            label: "Binary Serialization Standard",
+            collapsible: true,
+            collapsed: true,
+            link: {
+                type: "doc",
+                id: "concepts/serialization/index",
+            },
+            items: [
+                "concepts/serialization/primitives",
+                "concepts/serialization/structures",
+                "concepts/serialization/types",
+            ],
+        },
+        "concepts/intro-to-dapps",
+        "concepts/addressable-entity",
+        "concepts/accounts-and-keys",
+        "concepts/key-types",
+        "concepts/transactions-and-transaction-lifecycle",
+        "concepts/global-state",
+        "concepts/smart-contracts",
+        "concepts/list-auth-keys",
+        "concepts/callstack",
+        "concepts/dictionaries",
     ],
     developers: [
         "developers/index",

source/docs/casper/concepts/design/casper-design.md

@@ -134,7 +134,7 @@ In the case where there is a reference to stored on-chain Wasm (smart contracts)
 
 ## Unforgeable Reference (URef) {#uref-head}
 
-This key type is used for storing any value except `Account`. Additionally, `URef`s used in Wasm carry permission information to prevent unauthorized usage of the value stored under the key. The runtime tracks this permission information. This means that if malicious Wasm attempts to produce a `URef` with permissions that the Wasm does not have, the Wasm has attempted to "forge" the unforgeable reference, and the runtime will raise a forged `URef` error. Permissions for a `URef` can be given across contract calls, allowing data stored under a `URef` to be shared in a controlled way. The 32-byte identifier representing the key is generated randomly by the runtime (see [Execution Semantics](#execution-semantics-head) for more information). The serialization for `Access Rights` that define the permissions for `URefs` is detailed in the [CLValues](../serialization-standard.md) section.
+This key type is used for storing any value except `Account`. Additionally, `URef`s used in Wasm carry permission information to prevent unauthorized usage of the value stored under the key. The runtime tracks this permission information. This means that if malicious Wasm attempts to produce a `URef` with permissions that the Wasm does not have, the Wasm has attempted to "forge" the unforgeable reference, and the runtime will raise a forged `URef` error. Permissions for a `URef` can be given across contract calls, allowing data stored under a `URef` to be shared in a controlled way. The 32-byte identifier representing the key is generated randomly by the runtime (see [Execution Semantics](#execution-semantics-head) for more information). The serialization for `Access Rights` that define the permissions for `URefs` is detailed in the [CLValues](../serialization/primitives.md#clvalue) section.
 
 
 ### Permissions for `URef`s {#uref-permissions}
@@ -152,7 +152,7 @@ The ability to pass `URef`s between contexts via `call_contract` / `ret`, allows
 
 ### `URef`s and Purses
 
-Purses represent a unique type of `URef` used for accounting measures within a Casper network. `URef`s exist as a top-level entity, meaning that individual entities do not own ‘URef’s. As described above, entities possess certain `Access Rights`, allowing them to interact with the given `URef`. While an account entity will possess an associated `URef` representing their main purse, this `URef` exists as a [`Unit`](../serialization-standard.md#clvalue-unit) and corresponds to a *balance* key within the Casper *mint*. The individual balance key within the Casper mint is the account entity's purse, with transfers authorized solely through the associated `URef` and the `Access Rights` granted to it.
+Purses represent a unique type of `URef` used for accounting measures within a Casper network. `URef`s exist as a top-level entity, meaning that individual entities do not own ‘URef’s. As described above, entities possess certain `Access Rights`, allowing them to interact with the given `URef`. While an account entity will possess an associated `URef` representing their main purse, this `URef` exists as a [`Unit`](../serialization/primitives.md#unit-clvalue-unit) and corresponds to a *balance* key within the Casper *mint*. The individual balance key within the Casper mint is the account entity's purse, with transfers authorized solely through the associated `URef` and the `Access Rights` granted to it.
 
 Through this logic, the Casper mint holds all motes on the network and transfers between balance keys at the behest of entities as required.
 
@@ -176,7 +176,7 @@ The `block_hash` is the `blake2b256` hash of the block header.
 
 #### Header {#header}
 
-The [block header](../serialization-standard.md#serialization-standard-block) contains the following fields:
+The [block header](../serialization/structures.md#block-header) contains the following fields:
 
 * `parent_hash`
 
@@ -226,7 +226,7 @@ The block body contains an **ordered** list of transaction hashes. All transacti
 
 The block body also contains the public key of the validator that proposed the block.
 
-Refer to the [Serialization Standard](../serialization-standard.md) for additional information on how blocks and transactions are serialized.
+Refer to the [Serialization Standard](../serialization/index.md) for additional information on how blocks and transactions are serialized.
 
 ## Tokens {#tokens-head}
 

source/docs/casper/concepts/design/networking-protocol.md

@@ -263,7 +263,7 @@ If the item was not found, `serialized_item` MUST contain a `FetchedOrNotFound::
 
 A node MUST not send any items to a peer that it itself has not verified.
 
-The following table shows which tag corresponds to which ID and item type. Type definitions for `DeployHash` and `GossippedAddress` can be found earlier in this document, other types are described following this section.  Further details of many of these types can be found in the [Serialization Standard](../serialization-standard.md), but be aware that those docs describe serializing using bytesrepr rather than bincode.
+The following table shows which tag corresponds to which ID and item type. Type definitions for `DeployHash` and `GossippedAddress` can be found earlier in this document, other types are described following this section.  Further details of many of these types can be found in the [Serialization Standard](../serialization/index.md), but be aware that those docs describe serializing using bytesrepr rather than bincode.
 
 | Tag                                      | ID type               | Payload (item) type        |
 | ---------------------------------------- | --------------------- | -------------------------- |

source/docs/casper/concepts/global-state.md

@@ -6,7 +6,7 @@ The storage layer for the Casper blockchain is called *global state* and has the
 
 :::note
 
-Refer to [Keys and Permissions](./serialization-standard.md#serialization-standard-state-keys) for further information on keys.
+Refer to [Keys and Permissions](./serialization/types.md#serialization-standard-serialization-key) for further information on keys.
 
 :::
 

source/docs/casper/concepts/glossary/D.md

@@ -26,7 +26,7 @@ Casper's Condor release introduces the [Transaction](./T.md#transaction). Legacy
 
 All deploys on a Casper network can be broadly categorized as some unit of work that, when executed and committed, affects change to the [global state](./G.md#global-state).
 
-Review the [deploy data structure](../serialization-standard.md#deploy) and the [deploy implementation](https://github.com/casper-network/casper-node/blob/master/node/src/types/deploy.rs#L475) for more details.
+Review the [deploy data structure](../serialization/structures.md#deploy) and the [deploy implementation](https://github.com/casper-network/casper-node/blob/master/node/src/types/deploy.rs#L475) for more details.
 
 ## Dictionary {#dictionary}
 

source/docs/casper/concepts/index.md

@@ -22,7 +22,7 @@ This section of the documentation covers the core concepts underpinning the Casp
 | [Transactions and the Transaction Lifecycle](./transactions-and-transaction-lifecycle.md) | Transactions are a concept fundamental to the Casper blockchain. Learn about transactions, what they are for, how to create and send them | 
 | [Smart Contracts](./smart-contracts.md) | Learn how to develop smart contracts on Casper | 
 | [Dictionaries](./dictionaries.md) | Learn about dictionaries, which are a primary construct for storing and retrieving data on the Casper platform | 
-| [Serialization](./serialization-standard.md) | Learn about serializing data types and the Casper Serialization Standard | 
+| [Serialization](./serialization/index.md) | Learn about serializing data types and the Casper Serialization Standard | 
 | [Design](./design/index.md) | The high-level design of a Casper network | 
 | [Economics](./economics/index.md) | Learn about the Casper on-chain economics | 
 | [Glossary](./glossary/index.md) | A compendium of all the terms used in Casper, in alphabetical order |