From 1822272fe65ef02921a7abfb20106dfc85260c5b Mon Sep 17 00:00:00 2001 From: Devendran Date: Tue, 24 Jun 2025 14:21:04 +0530 Subject: [PATCH 1/3] Remove CasperLabs references[CD-96] --- docs/concepts/economics/index.md | 2 +- docs/concepts/glossary/index.md | 2 +- docs/concepts/serialization/primitives.md | 2 +- docs/concepts/serialization/structures.md | 216 ++++++++---------- docs/concepts/serialization/types.md | 34 +-- docs/developers/cli/opcode-costs.md | 160 +++++++++++++ docs/operators/setup/install-node.md | 6 +- .../concepts/accounts-and-keys.md | 2 +- .../version-2.0.0/concepts/economics/index.md | 2 +- .../version-2.0.0/concepts/glossary/index.md | 2 +- .../concepts/serialization/structures.md | 6 +- .../concepts/serialization/types.md | 2 +- versioned_docs/version-2.0.0/disclaimer.md | 72 +++--- .../operators/setup/install-node.md | 6 +- 14 files changed, 320 insertions(+), 194 deletions(-) diff --git a/docs/concepts/economics/index.md b/docs/concepts/economics/index.md index 66fc24c4b..a9ccf7138 100644 --- a/docs/concepts/economics/index.md +++ b/docs/concepts/economics/index.md @@ -59,7 +59,7 @@ The fee elimination model will be different from the refund model introduced on ## Ecosystem {#ecosystem} -The ecosystem layer encompasses dApp design and operation. Casper Labs maintains multiple partnerships with prospective dApp developers, and we anticipate devoting significant resources to research the economics of prospective dApps. +The ecosystem layer encompasses dApp design and operation. Casper Association maintains multiple partnerships with prospective dApp developers, and we anticipate devoting significant resources to research the economics of prospective dApps. ## Macroeconomy {#macroeconomy} diff --git a/docs/concepts/glossary/index.md b/docs/concepts/glossary/index.md index f5d40e5c3..58a76ba5a 100644 --- a/docs/concepts/glossary/index.md +++ b/docs/concepts/glossary/index.md @@ -5,7 +5,7 @@ slug: /glossary # Glossary -These definitions are correct in the context of the Casper Labs. They may (and probably will) have slightly different semantics in other contexts, including other blockchain contexts. +These definitions are correct in the context of the Casper Association. They may (and probably will) have slightly different semantics in other contexts, including other blockchain contexts. --- diff --git a/docs/concepts/serialization/primitives.md b/docs/concepts/serialization/primitives.md index 77ef1bc41..14ae5799a 100644 --- a/docs/concepts/serialization/primitives.md +++ b/docs/concepts/serialization/primitives.md @@ -21,7 +21,7 @@ enum CLType { String, // e.g. "Hello, World!" URef, // unforgeable reference (see above) Key, // global state key (see above) - PublicKey // A Casper system PublicKey type + PublicKey, // A Casper system PublicKey type Option(CLType), // optional value of the given type List(CLType), // list of values of the given type (e.g. Vec in rust) ByteArray(CLType, u32), // same as `List` above, but number of elements diff --git a/docs/concepts/serialization/structures.md b/docs/concepts/serialization/structures.md index 1a9693dbd..fa918a5a3 100644 --- a/docs/concepts/serialization/structures.md +++ b/docs/concepts/serialization/structures.md @@ -2,7 +2,11 @@ ## Account {#serialization-standard-account} -An Account is a structure that represented a user on a Casper network. The account structure consists of the following fields: +An Account is a structure that represented a user on a legacy Casper network. Alongside the Casper 2.0 protocol release, `Accounts` were replaced with `AddressableEntities` of the type `Account`. + +**Important:** Addressable Entity is turned off in Casper 2.0 and will be enabled in a future release. + +The account structure consists of the following fields: - [`account_hash`](./types.md#account-hash) @@ -16,7 +20,7 @@ An Account is a structure that represented a user on a Casper network. The accou ## AddressableEntity {#addressable-entity} -An Addressable Entity is a structure that represents an entity on a Casper network. +An Addressable Entity is a structure that represents an entity on a Casper network. **Important:** Addressable Entity is turned off in Casper 2.0 and will be enabled in a future release. @@ -26,20 +30,17 @@ The addressable entity consists of the following fields: - [`byte_code_hash`](./types.md#byte-code-hash) -- [`entry_points`](./types.md#entrypoints) - - [`protocol_version`](./types.md#protocolversion) -- `main_purse`: The entity's main purse `URef`. You may find information on `URef` serialization [here](./primitives.md#clvalue-uref). +- [`main_purse`]: The entity's main purse `URef`. You may find information on `URef` serialization [here](./primitives.md#clvalue-uref). - [`associated_keys`](./types.md#associatedkey) - [`action_thresholds`](./types.md#entity-action-thresholds) -- [`message_topics`](./types.md#message-topics) - - [`entity_kind`](./types.md#entity-kind) + ## Block {#serialization-standard-block} A block is the core component of the Casper linear blockchain, used in two contexts: @@ -47,27 +48,28 @@ A block is the core component of the Casper linear blockchain, used in two conte 1. A data structure containing a collection of transactions. Blocks form the primary structure of the blockchain. 2. A message that is exchanged between nodes containing the data structure as explained in (1). -Each block has a globally unique ID, achieved by hashing the contents of the block. +The block is a polymorphic structure that assumes one of the well-defined variants: +* `V1` which type is `BlockV1` (it has a binary `prefix` of 0) +* `V2` which type is `BlockV2` (it has a binary `prefix` of 1) -Each block points to its parent. An exception is the first block, which has no parent. - -A block is structurally defined as follows: +To byte-serialize a `Block` you first need to serialize it's binary prefix and then write the bytes of the byte-serialized representation of it's variant. -- `hash`: A hash over the header of the block. -- `header`: The header of the block that contains information about the contents of the block with additional metadata. -- `body`: The block's body contains the proposer of the block and hashes of deploys and transfers contained within it. +## BlockV1 {#block-v1} -Further, a block may consist of one of the following types: +This type: +* encapsulates block data that used to be produced in versions of the nodes prior to 2.0. +* represents a historical block that was produced prior to 2.0 +Each block: +* has a globally unique ID, achieved by hashing the contents of the block. +* points to its parent. An exception is the first block, which has no parent. -- `Version1`: A legacy block created prior to the Casper 2.0 upgrade. - -- `Version2`: A modern block. - -### BlockHash {#block-hash} +A block is structurally defined as follows: -The block hash is a `Digest` over the contents of the block Header. The `BlockHash` serializes as the byte representation of the hash itself. +- `hash`: A hash over the header of the block. It's type is `BlockHash` +- `header`: The header of the block that contains information about the contents of the block with additional metadata. It's type is `BlockHeaderV1`. +- `body`: The block's body contains the proposer of the block and hashes of deploys and transfers contained within it. It's type is `BlockBodyV1`. -### BlockHeader {#block-header} +### BlockHeaderV1 {#block-header-v1} The header portion of a block, structurally, is defined as follows: @@ -76,15 +78,13 @@ The header portion of a block, structurally, is defined as follows: - `body_hash` the hash of the block body. It serializes to the byte representation of the body hash. The serialized buffer of the `body_hash` is 32 bytes long. - `random_bit` is a boolean needed for initializing a future era. It is serialized as a single byte; true maps to 1, while false maps to 0. - `accumulated_seed` is a seed needed for initializing a future era. It serializes to the byte representation of the parent Hash. The serialized buffer of the `accumulated_hash` is 32 bytes long. -- `era_end` contains equivocation and reward information to be included in the terminal finalized block. It is an optional field. Thus if the field is set as `None`, it serializes to _0_. The serialization of the other case is described in the EraEnd. +- `era_end` contains equivocation and reward information to be included in the terminal finalized block. It is an optional field. Thus if the field is set as `None`, it serializes to _0_. The serialization of the other case is described in the `EraEndV1`. - `timestamp` The timestamp from when the block was proposed. It serializes as a single `u64` value. The serialization of a `u64` value is described in the CLValues section. - `era_id` Era ID in which this block was created. It serializes as a single `u64` value. - `height` The height of this block, i.e., the number of ancestors. It serializes as a single `u64` value. - `protocol_version` The version of the Casper network when this block was proposed. It is 3-element tuple containing `u32` values. It serializes as a buffer containing the three `u32` serialized values. Refer to the CLValues section on how `u32` values are serialized. -Both `BlockHeaderV1` and `BlockHeaderV2` serialize in the same way. - -### EraEndV1 {#eraendV1} +#### EraEndV1 {#eraendV1} `EraEndV1` as represented within the block header, is a struct containing two fields. @@ -106,18 +106,6 @@ When serializing the overarching struct of `EraEndV1`, we first allocate a buffe Note that `EraEndV1` is an optional field. Thus the above scheme only applies if there is an `EraEndV1`; if there is no era end, the field simply serializes to _0_. -### EraEndV2 {#eraendV2} - -`EraEndV1` as represented within the block header, is a struct containing four fields. - -- `equivocators`: A vector of `PublicKey` listing equivocators for the era. -- `inactive_validators`: A list of inactive validators for the era. -- `next_era_validator_weights`: A map of validators and their weights for the era to follow. -- `rewards`: A Binary Tree Map of `PublicKey` and `u64`. -- `next_era_gas_price`: The next era's gas price as a `u8`. - -Note that `EraEndV2` is an optional field. Thus the above scheme only applies if there is an `EraEndV2`; if there is no era end, the field simply serializes to _0_. - ### BlockBodyV1 {#blockbodyV1} The body portion of a block, prior to the Casper 2.0 upgrade, is structurally defined as: @@ -132,6 +120,52 @@ When we serialize the `BlockBodyV1`, we create a buffer that contains the serial - `deploy_hashes` serializes to the byte representation of all the deploy_hashes within the block header. Its length is `32 * n`, where n denotes the number of deploy hashes present within the body. - `transfer_hashes` serializes to the byte representation of all the deploy_hashes within the block header. Its length is `32 * n`, where n denotes the number of transfers present within the body. +## BlockV2 {#block-v2} + +This type represents a contemporary block that is produced by the network. A block is the core component of the Casper linear blockchain, used in two contexts: +1. A data structure containing a collection of transactions. Blocks form the primary structure of the blockchain. +2. A message that is exchanged between nodes containing the data structure as explained in (1). + +Each block has a globally unique ID, achieved by hashing the contents of the block. + +Each block points to its parent. An exception is the first block, which has no parent. + +A block is structurally defined as follows: + +- `hash`: A hash over the header of the block. It's type is `BlockHash` +- `header`: The header of the block that contains information about the contents of the block with additional metadata. It's type is `BlockHeaderV2`. +- `body`: The block's body contains the proposer of the block and hashes of deploys and transfers contained within it. It's type is `BlockBodyV2`. + +### BlockHeaderV2 {#block-header-v2} + +The header portion of a block, structurally, is defined as follows: + +- `parent_hash` is the hash of the parent block. It serializes to the byte representation of the parent hash. The serialized buffer of the `parent_hash` is 32 bytes long. +- `state_root_hash` is the global state root hash produced by executing this block's body. It serializes to the byte representation of the `state root hash`. The serialized buffer of the `state_root_hash` is 32 bytes long. +- `body_hash` the hash of the block body. It serializes to the byte representation of the body hash. The serialized buffer of the `body_hash` is 32 bytes long. +- `random_bit` is a boolean needed for initializing a future era. It is serialized as a single byte; true maps to 1, while false maps to 0. +- `accumulated_seed` is a seed needed for initializing a future era. It serializes to the byte representation of the parent Hash. The serialized buffer of the `accumulated_hash` is 32 bytes long. +- `era_end` contains equivocation and reward information to be included in the terminal finalized block. It is an optional field. Thus if the field is set as `None`, it serializes to _0_. The serialization of the other case is described in the `EraEndV2`. +- `timestamp` The timestamp from when the block was proposed. It serializes as a single `u64` value. The serialization of a `u64` value is described in the CLValues section. +- `era_id` Era ID in which this block was created. It serializes as a single `u64` value. +- `height` The height of this block, i.e., the number of ancestors. It serializes as a single `u64` value. +- `protocol_version` The version of the Casper network when this block was proposed. It is 3-element tuple containing `u32` values. It serializes as a buffer containing the three `u32` serialized values. Refer to the CLValues section on how `u32` values are serialized. +- `proposer` public key of the proposer of the block. It's type is `PublicKey` +- `current_gas_price` gas price of the block. It is an unsigned 8 bit number. +- `last_switch_block_hash` it is an optional block hash pointing to the last switch block. It's type is `BlockHash`, but since it's optional, rules of serializing (optional fields)[./primitives.md#clvalue-option] apply. + +### EraEndV2 {#eraendV2} + +`EraEndV2` as represented within the block header, is a struct containing four fields. + +- `equivocators`: A vector of `PublicKey` listing equivocators for the era. +- `inactive_validators`: A list of inactive validators for the era. +- `next_era_validator_weights`: A map of validators and their weights for the era to follow. +- `rewards`: A Binary Tree Map of `PublicKey` and `u64`. +- `next_era_gas_price`: The next era's gas price as a `u8`. + +Note that `EraEndV2` is an optional field. Thus the above scheme only applies if there is an `EraEndV2`; if there is no era end, the field simply serializes to _0_. + ### BlockBodyV2 {blockbodyv2} A modern block is structurally defined as: @@ -140,6 +174,20 @@ A modern block is structurally defined as: - [`rewarded_signatures`](./types.md#rewarded-signatures): A list of identifiers for finality signatures for a particular past block. It serializes as a vector of `SingleBlockRewardedSignatures` which describes signatures for a single ancestor block. The first entry represents the signatures for the parent block, the second for the parent of the parent, and so on. + +## BlockHash {#block-hash} + +The block hash is a `Digest` over the contents of the block Header. The `BlockHash` serializes as the byte representation of the hash itself. + + +## ByteCodeAddr {#byte-code-addr} + +An address for ByteCode records stored in global state. Comes in one of three variants: +- `Empty`. It serializes as a `u8` tag of `0`. +- `V1CasperWasm`. It serializes as a `u8` tag of `1` followed by 32 bytes interpreted as hex-encoded address. +- `V2CasperWasm`. It serializes as a `u8` tag of `2` followed by 32 bytes interpreted as hex-encoded address. + + ## Contract {#contract} A contract struct containing the following fields: @@ -242,7 +290,7 @@ The hash of the name of a message topic, serialized as a [`u8`](./primitives.md# ## Transaction {#transaction} -A versioned wrapper for a transaction or deploy. It serializes as a `u8` tag of `0` followed by a [`Deploy`](#serialization-standard-deploy) or a `u8` tag of `1` followed by a [`TransactionV1`](#transactionV1). +Please see the [Transaction serialization document](./transaction.md) ### Deploy {#serialization-standard-deploy} @@ -307,61 +355,16 @@ A `struct` containing configuration values associated with `deploys`. The struct ### TransactionV1 {#transactionV1} -A unit of work sent by a client to the network, which when executed can cause global state to be altered. It is structurally defined as follows: +Please see the [Transaction serialization document](./transaction.md) -- [`TransactionV1Hash`](#transactionv1hash) - -- [`TransactionV1Header`](#transactionv1header) - -- [`TransactionV1Body`](#transactionv1body) +### TransactionHash {#transactionhash} -- `approvals`: A list of signatures. +A versioned wrapper for transaction hash or deploy hash. It serializes as either a `u8` tag of 0 followed by a [`DeployHash`](#deploy-hash) or a `u8` tag of 1 followed by a [`TransactionV1Hash`](#transactionv1hash). ### TransactionV1Hash The transaction hash is a digest over the contents of the transaction header. The transaction hash serializes as the byte representation of the hash itself. -### TransactionV1Header - -The header portion of a transaction, structurally, is defined as follows: - -- `chain_name`: Chain name is a human-readable string describing the name of the chain as detailed in the chainspec. It is serialized as a [String](./primitives.md#clvalue-string). -- `timestamp`: A timestamp is a struct that is a unary tuple containing a `u64` value. This value is a count of the milliseconds since the UNIX epoch. Thus the value `1603994401469` serializes as `0xbd3a847575010000`. -- `ttl`: The **Time to live** is defined as the amount of time for which the transaction is considered valid. The `ttl` serializes in the same manner as the timestamp. -- `body_hash`: Body hash is a hash over the contents of the [transaction body](#transactionv1body). It serializes as the byte representation of the hash itself. -- [`pricing_mode`](./types.md#pricingmode) -- [`initator_addr`](./types.md#initiatoraddr) - -### TransactionV1Body - -The body of a `TransactionV1`, consisting of the following: - -- [`args`](./types.md#runtimeargs) -- [`target`](#transactiontarget) -- [`entry_point`](#transactionentrypoint) -- [`scheduling`](#transactionscheduling) - -### TransactionRuntime {#transactionruntime} - -The runtime used to execute a transaction, serialized as a [`u8`](./primitives.md#clvalue-numeric). Currently, only the `VmCasperV1` is available, which serializes as a `0`. - -### TransactionEntryPoint {#transactionentrypoint} - -An entry point of a transaction, serialized as a [`u8`](./primitives.md#clvalue-numeric) value based on the type of entry point. The following table outlines the available types: - -| Tag | Entry Point | -| --- | ----------- | -| 0 | Custom | -| 1 | Transfer | -| 2 | Add_Bid | -| 3 | Withdraw_Bid | -| 4 | Delegate | -| 5 | Undelegate | -| 6 | Redelegate | -| 7 | Activate_Bid | -| 8 | ChangePublicKey | -| 9 | Call | - ### TransactionConfig {#transactionconfig} A `struct` containing configuration values associated with `Transactions`. The structure contains the following fields: @@ -396,46 +399,7 @@ A `struct` containing configuration values associated with `TransactionV1s`. The A versioned wrapper for transaction hash or deploy hash. It serializes as either a `u8` tag of 0 followed by a [`DeployHash`](#deploy-hash) or a `u8` tag of 1 followed by a [`TransactionV1Hash`](#transactionv1hash). -### TransactionHeader {#transactionheader} - -A versioned wrapper for transaction header or deploy header. It serializes as either a `u8` tag of 0 followed by a [`DeployHeader`](#deploy-header) or a `u8` tag of 1 followed by a [`TransactionV1Header`](#transactionv1header). - ### TransactionId {#transactionid} The unique identifier of a `Transaction`, serialized as its [`TransactionHash`](#transactionhash) and [`ApprovalsHash`](#approvals-hash). -### TransactionScheduling {#transactionscheduling} - -The scheduling mode of a transaction, serialized as a [`u8`](./primitives.md#clvalue-numeric) tag identifying the type: - -- `Standard` serializes as a `0`. - -- `FutureEra` serializes as a `1` followed by a future [`era_id`](./types.md#eraid). - -- `FutureTimestamp` serializes as a `2` followed by a future [`timestamp`](./types.md#timestamp). - -### TransactionInvocationTarget {#transactioninvocationtarget} - -The identifier of a `stored` transaction target, serialized as one of the following: - -- `InvocableEntity` serializes as a `u8` tag of `0` followed by the hex-encoded entity address serialized as the byte representation of itself. - -- `InvocableEntityAlias` serializes as a `u8` tag of `1` followed by the alias serialized as a [`string`](./primitives.md#clvalue-string). - -- `Package` serializes as a `u8` tag of `2` followed by the [`package hash`](./types.md#package-hash) and optionally the [`entity_version`](./types.md#entityversionkey). - -- `PackageAlias` serializes as a `u8` tag of `3` followed by the alias serialized as a [`string`](./primitives.md#clvalue-string) and optionally the [`entity_version`](./types.md#entityversionkey). - -### TransactionTarget {#transactiontarget} - -The execution target of a transaction, serializing as a [`u8`](./primitives.md#clvalue-numeric) that identifies the type, followed by any additional data. - -- `native` serializes as a `0`. - -- `stored` serializes as a `1` followed by the [`id`](#transactioninvocationtarget) and [`runtime`](#transactionruntime). - -- `session` serializes as a `2` followed by the [`kind`](#transactionsessionkind), [`module_bytes`](#payment--session) and [`runtime`](#transactionruntime). - -### TransactionWithExecutionInfo {#transaction-with-execution-info} - -A `struct` containing a`Transaction` with execution info. It serializes as a [`Transaction`](#transaction) followed by an [`Option`](./primitives.md#clvalue-option) of `ExecutionInfo`. diff --git a/docs/concepts/serialization/types.md b/docs/concepts/serialization/types.md index ec010403b..4ee39a309 100644 --- a/docs/concepts/serialization/types.md +++ b/docs/concepts/serialization/types.md @@ -214,7 +214,7 @@ Hex-encoded bytes serialized as a `u32` value describing the length of the bytes ## ByteCodeKind -The type of byte code, serialized as a single `u8` value. A `0` indicates empty byte code, while a `1` indicates a `V1CasperWasm` to be executed with the first version of the Casper execution engine. +The type of byte code, serialized as a single `u8` value. A `0` indicates empty byte code. `1` indicates a `V1CasperWasm` to be executed with the first version of the Casper execution engine. `2` indicates a `V2CasperWasm` to be executed with the first version of the Casper execution engine. ## Caller {#caller} @@ -252,6 +252,9 @@ ChainspecRegistry is a unique key variant which contains a mapping of file names The checksum registry. It serializes as a `BTreeMap` where the first 4 bytes represent a `u32` value describing the number of checksum names as strings and [digests](#digest) held within. The remainder consists of a repeating pattern of serialized strings and then digests of the length dictated by the first four bytes. +## ContractRuntimeTag {#contract-runtime-tag} +A tag for the contracts runtime tag, serialized as a single `u8` tag of 0 for `VmCasperV1`, 1 for `VmCasperV2`. + ## Delegator {#delegator} Represents a party delegating their stake to a validator (or "delegatee"). The structure consists of the following fields: @@ -378,9 +381,9 @@ The context of method execution. It serializes as one of the following: - `Caller`: Serializes as a single `u8`, `0b00000000` -- `Called`: Serializes as a single `u8`, `0b00000001` +- `DirectInvocationOnly`: Serializes as a single `u8`, `0b00000001` -- `Factory`: Serializes as a single `u8`, `0b10000000` +- `SelfOnward`: Serializes as a single `u8`, `0b10000000` ## EntrypointV2 @@ -486,10 +489,6 @@ A (labeled) "user group". Each method of a versioned contract may be associated They are serialized as a `BTreeMap` where the first 4 bytes represent a `u32` value describing the number of user groups and `BTreeSets` of [`URef`](./primitives.md#clvalue-uref)s held within. The remainder consists of a repeating pattern of serialized user groups and `BTreeSets` of the length dictated by the first four bytes. -## InitiatorAddr {#initiatoraddr} - -The address of the initiator of a [`TransactionV1`](./structures.md#transactionV1), which serializes as a `u8` of `0` followed by a [`PublicKey`](#publickey) or a `1` followed by an [`AccountHash`](#account-hash). - ## Keys {#serialization-standard-state-keys} A _key_ in [Global State](../design/casper-design.md) is one of the following data types: @@ -687,23 +686,6 @@ The lock status of the package, serialized as a [`boolean`](./primitives.md#clva Parameter to a method, structured as a name followed by a `CLType`. It is serialized as a [`String`](./primitives.md#clvalue-string) followed by a [`CLType`](./primitives.md#clvalue-cltype). -## PricingMode {#pricingmode} - -The pricing mode of a transaction, with two possible variants. It serializes as a `u8` tag followed by additional data based on the following table: - -| Tag | PricingMode| Description | -| --- | ---------- | ----------- | -| 0 | Classic | The original payment model, in which the creator of a transaction specifies how much they will pay and at which gas price. | -| 1 | Fixed | The cost of the transaction is determined by the cost table, per the transaction kind. | - -### Classic {#pricingmode-classic} - -After the `0` tag, a `Classic` `PricingMode` serializes as the [`u64`](./primitives.md#clvalue-numeric) `payment_amount` followed by the `u64` value of the `gas_price`. - -### Fixed {#pricingmode-fixed} - -After the `1` tag, a `Fixed` `PricingMode` serializes as the [`u64`](./primitives.md#clvalue-numeric) `gas_price_tolerance`. - ## ProtocolVersion {#protocolversion} A newtype indicating the Casper Platform protocol version. It is serialized as three [`u32`](./primitives.md#clvalue-numeric) values indicating major, minor and patch versions in that order. @@ -770,9 +752,9 @@ Entity types for system contracts, serialized as a single `u8` tag identifying t | Tag | System Contract | | --- | --------------- | | 0 | `Mint` | -| 1 | `Auction` | +| 1 | `HandlePayment` | | 2 | `StandardPayment` | -| 3 | `HandlePayment` | +| 3 | `Auction` | ## TimeDiff {#timediff} diff --git a/docs/developers/cli/opcode-costs.md b/docs/developers/cli/opcode-costs.md index af1ab55b4..e7bb627d3 100644 --- a/docs/developers/cli/opcode-costs.md +++ b/docs/developers/cli/opcode-costs.md @@ -11,6 +11,166 @@ The static cost is a **fixed cost for each opcode that is hardcoded** and **vali If you are building for a private network or other instance of Casper, you will need to verify these costs in the associated `chainspec.toml`. +## OpCodeCosts + +|Attribute |Description | Cost | +|----------------- |-----------------------------------------------|-----------------| +|bit | Bit operations multiplier. | 300 | +|add | Arithmetic add operations multiplier. | 210| +|mul | Mul operations multiplier. | 240| +|div | Div operations multiplier. | 320| +|load | Memory load operation multiplier. | 2_500| +|store |Memory store operation multiplier. | 4_700| +|const | Const store operation multiplier. | 110| +|local | Local operations multiplier. | 390| +|global | Global operations multiplier. | 390| +|integer_comparison | Integer operations multiplier. | 250| +|conversion | Conversion operations multiplier. | 420| +|unreachable | Unreachable operation multiplier. | 270| +|nop | Nop operation multiplier. | 200| +|current_memory | Get the current memory operation multiplier. | 290| +|grow_memory | Grow memory cost per page (64 kB). | 240_000| + +## ControlFlowCost + +|Attribute |Description | Cost | +|----------------- |-----------------------------------------------|-----------------| +|block | Cost for `block` opcode. | 440| +|loop | Cost for `loop` opcode. | 440| +|if | Cost for `if` opcode. | 440| +|else | Cost for `else` opcode. | 440| +|end | Cost for `end` opcode. | 440| +|br | Cost for `br` opcode. | 35_000| +|br_if | Cost for `br_if` opcode. | 35_000| +|return | Cost for `return` opcode. | 440| +|select | Cost for `select` opcode. | 440| +|call | Cost for `call` opcode. | 68_000| +|call_indirect | Cost for `call_indirect` opcode. | 68_000| +|drop | Cost for `drop` opcode. | 440| + +## `Br_Table` OpCode Costs + +|Attribute |Description | Cost | +|----------------- |-----------------------------------------------|-----------------| +|cost | Fixed cost per `br_table` opcode. | 35_000| +|size_multiplier | Size of target labels in the `br_table` opcode will be multiplied by `size_multiplier`. | 100| + +## External Function Costs + +The following costs are for low-level bindings for host-side ("external") functions. More information on the Casper external FFI can be found [here](https://docs.rs/casper-contract/latest/casper_contract/ext_ffi/index.html). + +|Host-Side Function| Cost | Arguments | +| ---------------- | ---- | --------- | +| add | 5_800 | [0, 0, 0, 0] | +| add_associated_key | 1_200_000 | [0, 0, 0] | +| add_contract_version | 200 | [0, 0, 0, 0, 120_000, 0, 0, 0, 30_000, 0, 0] | +| blake2b | 1_200_000 | [0, 120_000, 0, 0] | +| call_contract | 300_000_000 | [0, 0, 0, 120_000, 0, 120_000, 0] | +| call_versioned_contract | 300_000_000 | [0, 0, 0, 0, 120_000, 0, 120_000, 0] | +| create_contract_package_at_hash | 200 | [0, 0] | +| create_contract_user_group | 200 | [0, 0, 0, 0, 0, 0, 0, 0] | +| create_purse | 2_500_000_000 | [0, 0] | +| disable_contract_version | 200 | [0, 0, 0, 0] | +| get_balance | 3_000_000 | [0, 0, 0] | +| get_blocktime | 330 | [0] | +| get_caller | 380 | [0] | +| get_key | 2_000 | [0, 440, 0, 0, 0] | +| get_main_purse | 1_300 | [0] | +| get_named_arg | 200 | [0, 120_000, 0, 120_000] | +| get_named_arg_size | 200 | [0, 0, 0] | +| get_phase | 710 | [0] | +| get_system_contract | 1_100 | [0, 0, 0] | +| has_key | 1_500 | [0, 840] | +| is_valid_uref | 760 | [0, 0] | +| load_named_keys | 42_000 | [0, 0] | +| new_uref | 17_000 | [0, 0, 590] | +| random_bytes | 200 | [0, 0] | +| print | 20_000 | [0, 4_600] | +| provision_contract_user_group_uref | 200 | [0, 0, 0, 0, 0] | +| put_key | 100_000_000 | [0, 120_000, 0, 120_000] | +| read_host_buffer | 3_500 | [0, 310, 0] | +| read_value | 60_000 | [0, 120_000, 0] | +| read_value_local | 5_500 | [0, 590, 0] | +| remove_associated_key | 4_200 | [0, 0] | +| remove_contract_user_group | 200 | [0, 0, 0, 0] | +| remove_contract_user_group_urefs | 200 | [0, 0, 0, 0, 0, 120_000] | +| remove_key | 61_000 | [0, 3_200] | +| ret | 23_000 | [0, 420_000] | +| revert | 500 | [0] | +| set_action_threshold | 74_000 | [0, 0] | +| transfer_from_purse_to_account | 2_500_000_000 | [0, 0, 0, 0, 0, 0, 0, 0, 0] | +| transfer_from_purse_to_purse | 82_000_000 | [0, 0, 0, 0, 0, 0, 0, 0] | +| transfer_to_account | 2_500_000_000 | [0, 0, 0, 0, 0, 0, 0] | +| update_associated_key | 4_200 | [0, 0, 0] | +| write | 14_000 | [0, 0, 0, 980] | +| dictionary_put | 9_500 | [0, 1_800, 0, 520] | +| enable_contract_version | 200 | [0, 0, 0, 0] | +| manage_message_topic | 200 | [0, 30_000, 0, 0] | +| emit_message | 200 | [0, 30_000, 0, 120_000] | +| cost_increase_per_message | 50 | | + +### `Auction` System Contract Costs + +These are the costs of calling `auction` system contract entrypoints. + +|Entrypoint |Description | Cost | +|----------------- |-----------------------------------------------|-----------------| +|get_era_validators | Cost of calling the `get_era_validators` entrypoint. | 10_000| +|read_seigniorage_recipients | Cost of calling the `read_seigniorage_recipients` entrypoint. | 10_000| +|add_bid | Cost of calling the `add_bid` entrypoint. | 2_500_000_000| +|withdraw_bid | Cost of calling the `withdraw_bid` entrypoint. | 2_500_000_000| +|delegate | Cost of calling the `delegate` entrypoint. | 2_500_000_000| +|undelegate | Cost of calling the `undelegate` entrypoint. | 2_500_000_000| +|run_auction | Cost of calling the `run_auction` entrypoint. | 10_000| +|slash | Cost of calling the `slash` entrypoint. | 10_000| +|distribute | Cost of calling the `distribute` entrypoint. | 10_000| +|withdraw_delegator_reward | Cost of calling the `withdraw_delegator_reward` entrypoint. | 10_000| +|withdraw_validator_reward | Cost of calling the `withdraw_validator_reward` entrypoint. | 10_000| +|read_era_id | Cost of calling the `read_era_id` entrypoint. | 10_000| +|activate_bid | Cost of calling the `activate_bid` entrypoint. | 10_000| +|redelegate | Cost of calling the `redelegate` entrypoint. | 2_500_000_000| +|change_bid_public_key | Cost of calling the `change_bid_public_key` entrypoint. | 5_000_000_000 | + +### `Mint` System Contract Costs + +These are the costs of calling `mint` system contract entrypoints. + +|Entrypoint |Description | Cost | +|----------------- |-----------------------------------------------|-----------------| +|mint | Cost of calling the `mint` entrypoint. | 2_500_000_000| +|reduce_total_supply | Cost of calling the `reduce_total_supply` entrypoint. | 10_000| +|create | Cost of calling the `create` entrypoint. | 2_500_000_000| +|balance | Cost of calling the `balance` entrypoint. | 10_000| +|burn | Cost of calling the `burn` entrypoint. | 10_000| +|transfer | Cost of calling the `transfer` entrypoint. | 10_000| +|read_base_round_reward | Cost of calling the `read_base_round_reward` entrypoint. | 10_000| +|mint_into_existing_purse | Cost of calling the `mint_into_existing_purse` entrypoint. | 2_500_000_000| + + +### `Handle_Payment` System Contract Costs + +These are the costs of calling entrypoints on the `handle_payment` system contract. + +|Entrypoint |Description | Cost | +|----------------- |-----------------------------------------------|-----------------| +|get_payment_purse | Cost of calling the `get_payment_purse` entrypoint. |10_000| +|set_refund_purse | Cost of calling the `set_refund_purse` entrypoint. |10_000| +|get_refund_purse | Cost of calling the `get_refund_purse` entrypoint. |10_000| +|finalize_payment | Cost of calling the `finalize_payment` entrypoint. |10_000| + +### `Standard_Payment` System Contract Costs + +These settings manage the costs of calling entrypoints on the `standard_payment` system contract. + +|Entrypoint |Description | Cost | +|----------------- |-----------------------------------------------|-----------------| +|pay| Cost of calling the `pay` entrypoint and sending an amount to a payment purse. |10_000| + +## StorageCosts + +|Attribute |Description | Cost | +|----------------- |-----------------------------------------------|-----------------| +|gas_per_byte | Gas charged per byte stored in global state. | 1_117_587| :::note diff --git a/docs/operators/setup/install-node.md b/docs/operators/setup/install-node.md index 975018905..f8385f0b3 100644 --- a/docs/operators/setup/install-node.md +++ b/docs/operators/setup/install-node.md @@ -11,7 +11,7 @@ Ensure the requirements listed in the following sections are met before you star The following ports are used by the node: - 35000 (required to be externally visible) -- 7777 RPC endpoint for interaction with JSON-RPC API +- 7777 RPC endpoint for interaction with JSON-RPC API (The default port for JSON-RPC server, is now served by Casper Sidecar from Casper 2.0 onwards) - 8888 REST endpoint for status and metrics (having this accessible allows your node to be part of network status) - 9999 SSE endpoint for event stream @@ -125,9 +125,9 @@ In the past, we have used a lower `trusted_hash`. Connecting at the tip, we now ### Node Address -NODE_ADDR can be set to an IP of a trusted node, or to Casper Labs' public nodes +NODE_ADDR can be set to an IP of a trusted node, or to Casper Association's public nodes -You can find active peers at https://cspr.live/tools/peers or use the following Casper Labs public nodes: +You can find active peers at https://cspr.live/tools/peers or use the following Casper Association public nodes: * Testnet - NODE_ADDR=https://node.testnet.casper.network diff --git a/versioned_docs/version-2.0.0/concepts/accounts-and-keys.md b/versioned_docs/version-2.0.0/concepts/accounts-and-keys.md index 390b18cb1..6b07684f2 100644 --- a/versioned_docs/version-2.0.0/concepts/accounts-and-keys.md +++ b/versioned_docs/version-2.0.0/concepts/accounts-and-keys.md @@ -10,7 +10,7 @@ By default, a transactional interaction with the blockchain takes the form of a The Casper platform supports two types of keys for creating accounts and signing transactions: - [Ed25519](#eddsa-keys) keys, which use the Edwards-curve Digital Signature Algorithm (EdDSA) and are 66 characters / 33 bytes long and comprising of; - - - `01` - 1 byte prefix (indicates `Ed25519` key type in Casper) + - `01` - 1 byte prefix (indicates `Ed25519` key type in Casper) - 32 bytes of actual `Ed25519` public key data - Example: [`01a0d23e084a95cdee9c2fb226d54033d645873a7c7c9739de2158725c7dfe672f`](https://cspr.live/account/01a0d23e084a95cdee9c2fb226d54033d645873a7c7c9739de2158725c7dfe672f) diff --git a/versioned_docs/version-2.0.0/concepts/economics/index.md b/versioned_docs/version-2.0.0/concepts/economics/index.md index bd61cbc94..949adcf75 100644 --- a/versioned_docs/version-2.0.0/concepts/economics/index.md +++ b/versioned_docs/version-2.0.0/concepts/economics/index.md @@ -59,7 +59,7 @@ The fee elimination model will be different from the refund model introduced on ## Ecosystem {#ecosystem} -The ecosystem layer encompasses dApp design and operation. Casper Labs maintains multiple partnerships with prospective dApp developers, and we anticipate devoting significant resources to research the economics of prospective dApps. +The ecosystem layer encompasses dApp design and operation. Casper Association maintains multiple partnerships with prospective dApp developers, and we anticipate devoting significant resources to research the economics of prospective dApps. ## Macroeconomy {#macroeconomy} diff --git a/versioned_docs/version-2.0.0/concepts/glossary/index.md b/versioned_docs/version-2.0.0/concepts/glossary/index.md index f5d40e5c3..58a76ba5a 100644 --- a/versioned_docs/version-2.0.0/concepts/glossary/index.md +++ b/versioned_docs/version-2.0.0/concepts/glossary/index.md @@ -5,7 +5,7 @@ slug: /glossary # Glossary -These definitions are correct in the context of the Casper Labs. They may (and probably will) have slightly different semantics in other contexts, including other blockchain contexts. +These definitions are correct in the context of the Casper Association. They may (and probably will) have slightly different semantics in other contexts, including other blockchain contexts. --- diff --git a/versioned_docs/version-2.0.0/concepts/serialization/structures.md b/versioned_docs/version-2.0.0/concepts/serialization/structures.md index 4d1985265..fa918a5a3 100644 --- a/versioned_docs/version-2.0.0/concepts/serialization/structures.md +++ b/versioned_docs/version-2.0.0/concepts/serialization/structures.md @@ -2,7 +2,11 @@ ## Account {#serialization-standard-account} -An Account is a structure that represented a user on a Casper network. The account structure consists of the following fields: +An Account is a structure that represented a user on a legacy Casper network. Alongside the Casper 2.0 protocol release, `Accounts` were replaced with `AddressableEntities` of the type `Account`. + +**Important:** Addressable Entity is turned off in Casper 2.0 and will be enabled in a future release. + +The account structure consists of the following fields: - [`account_hash`](./types.md#account-hash) diff --git a/versioned_docs/version-2.0.0/concepts/serialization/types.md b/versioned_docs/version-2.0.0/concepts/serialization/types.md index c27f08dc1..cf97f0b7f 100644 --- a/versioned_docs/version-2.0.0/concepts/serialization/types.md +++ b/versioned_docs/version-2.0.0/concepts/serialization/types.md @@ -214,7 +214,7 @@ Hex-encoded bytes serialized as a `u32` value describing the length of the bytes ## ByteCodeKind -The type of byte code, serialized as a single `u8` value. A `0` indicates empty byte code. `1` indicates a `V1CasperWasm` to be executed with the first version of the Casper execution engine. `2` indicates a `V2CasperWasm` to be executed with the first version of the Casper execution engine +The type of byte code, serialized as a single `u8` value. A `0` indicates empty byte code. `1` indicates a `V1CasperWasm` to be executed with the first version of the Casper execution engine. `2` indicates a `V2CasperWasm` to be executed with the first version of the Casper execution engine. ## Caller {#caller} diff --git a/versioned_docs/version-2.0.0/disclaimer.md b/versioned_docs/version-2.0.0/disclaimer.md index 4056490bd..0a44b44cd 100644 --- a/versioned_docs/version-2.0.0/disclaimer.md +++ b/versioned_docs/version-2.0.0/disclaimer.md @@ -2,58 +2,74 @@ id: disclaimer title: Disclaimer --- -# Disclaimer {#disclaimer} +# Legal Disclaimer {#disclaimer} -By accepting this CasperLabs Tech Spec (this "Whitepaper"), each recipient hereof acknowledges and agrees that is not authorised to, and may not, forward or deliver this Whitepaper, electronically or otherwise, to any other person or reproduce this Whitepaper in any manner whatsoever. Any forwarding, distribution or reproduction of this Whitepaper in whole or in part is unauthorised. Failure to comply with this directive may result in a violation of applicable laws of any affected or involved jurisdiction. +This disclaimer applies to all users of the Casper documentation and any releated use of the Casper network, including but not limited to Developers, Operators, Users, and researchers ("you"). It governs your use of any and all information, tools, code samples, APIs, SDKs, specifications, and other materials provided by or on behalf of the Casper Association or its contributors ("we", "us", or "our") in this documentation. -Nothing in this Whitepaper constitutes an offer to sell, or a solicitation to purchase, the tokens native to the Casper blockchain ("CSPR”). In any event, were this Whitepaper to be deemed to be such an offer or solicitation, no such offer or solicitation is intended or conveyed by this Whitepaper in any jurisdiction where it is unlawful to do so, where such an offer or solicitation would require a license or registration, or where such an offer or solicitation is subject to restrictions. In particular, any CSPR to be issued have not been, and, as of the date of issuance of this Whitepaper, are not intended to be, registered under the securities or similar laws of any jurisdiction, whether or not such jurisdiction considers the CSPR to be a security or similar instrument, and specifically, have not been, and, as of the date of issuance of this Whitepaper are not intended to be, registered under the U.S. Securities Act of 1933, as amended, or the securities laws of any state of the United States of America or any other jurisdiction and may not be offered or sold in any jurisdiction where to do so would constitute a violation of the relevant laws of such jurisdiction. +By accessing, browsing, or using this documentation in any way, you agree to be legally bound by the terms of this disclaimer in full. If you do not agree, you must not use this documentation. -This Whitepaper constitutes neither a prospectus according to Art. 652a of the Swiss Code of Obligations (the "CO”) or Art. 1156 CO nor a prospectus or basic information sheet according to the Swiss Financial Services Act (the "FinSA”) nor a listing prospectus nor a simplified prospectus according to Art. 5 of the Swiss Collective Investment Schemes Act (the "CISA”) nor any other prospectus according to CISA nor a prospectus under any other applicable laws. +The information shared in this documentation is not all-encompassing or comprehensive and does not in any way intend to create or put into implicit effect any elements of a contractual relationship. -The CSPR are not expected to be instruments in an offer and sale which are subject to the jurisdiction or oversight of the U.S. Securities Exchange Commission (the "SEC”). In any event, however, CSPR have not been approved or disapproved by, and are not expected to be approved or disapproved by, the SEC nor by the securities regulatory authority of any state of the United States of America or of any other jurisdiction, and neither the SEC nor any such securities regulatory authority has passed, or is expected to pass, upon the accuracy or adequacy of this Whitepaper. +**No Warranties** -The distribution of this Whitepaper and the purchase, holding, and/or disposal of CSPR may be restricted by law in certain jurisdictions. Persons reading this Whitepaper should inform themselves as to (i) the possible tax consequences, (ii) the legal and regulatory requirements, and (iii) any foreign exchange restrictions or exchange control requirements, which they might encounter under the laws of the countries of their citizenship, residence or domi-cile and which might be relevant to the purchase, holding or disposal of CSPR. No action has been taken to authorise the distribution of this Whitepaper in any jurisdiction in which such authorisation might be required. +All content is provided on an “as is” and “as available” basis. To the fullest extent permitted by law, we disclaim all warranties, representations, or guarantees of any kind—express, implied, statutory, or otherwise—including, but not limited to, any implied warranties of merchantability, fitness for a particular purpose, non-infringement, or accuracy. No reliance should be placed on any information, code, or representations contained herein for making decisions or taking actions of any kind. -No action has been or is intended to be taken by CasperLabs Networks AG and/or any of its affiliates in any jurisdiction that would or is intended to, permit a public sale or offering of any CSPR, or possession or distribution of this Whitepaper (in preliminary, proof or final form) or any other sale, offering or publicity material relating to the CSPR, in any country or jurisdiction where action for that purpose is required. Each recipient of this Whitepaper is reminded that it has received this Whitepaper on the basis that it is a person into whose possession this Whitepaper may be lawfully delivered in accordance with the laws of the jurisdiction in which it is located and/or bound and it may not nor is it authorised to deliver this document, electronically or otherwise, to any other person. If the recipient receives this document by e-mail, then its use of this e-mail is at its own risk and it is the recipient’s responsibility to take precautions to ensure that such e-mail is free from viruses and other items of a destructive nature. +We do not warrant that: +- The documentation is complete, correct, current, or free from errors; +- Any code examples, APIs, or SDKs are secure or suitable for use; +- The functionality of the Casper network or related software will meet your requirements; +- Your use of the documentation will not result in unintended consequences, including security breaches, financial losses, or application failures. -#### Preliminary Nature of this Whitepaper {#preliminary-nature-of-this-whitepaper} +The content in this documentation speak only as of the date of this documentation and we may modify or update this documentation at our discretion but are not obligated to do so. -This Whitepaper is a draft and the information set out herein is of a preliminary nature. Consequently, neither CasperLabs Networks AG nor any of its affiliates assumes any responsibility that the information set out herein is final or correct and each of the foregoing disclaims, to the fullest extent permitted by applicable law, any and all liability whether arising in tort, contract or otherwise in respect of this Whitepaper. Neither this Whitepaper nor anything contained herein shall form the basis of or be relied on in connection with or act as an inducement to enter into any contract or commitment whatsoever. Recipients should note that the final structuring of CSPR and the Casper blockchain is subject to ongoing technical, legal, regulatory and tax considerations and each is, therefore, subject to material changes. In particular, neither the applicability nor the non-applicability of Swiss financial market regulations on the CSPR sale has not been confirmed by the Swiss Financial Market Supervisory Authority ("FINMA”). CasperLabs Networks AG and all its affiliates reserve the right to not assist in the completion of the software underlying CSPR and the CasperLabs blockchain, to not participate in the issuance or creation of CSPR or to change the structure of CSPR and/or the Casper blockchain for any reason, each at its sole discretion. +**Your Responsibility** -#### Forward-Looking Statements {#forward-looking-statements} +You are solely responsible for: +- Ensuring the correctness, security, and suitability of any code or architecture based on the documentation; +- Testing your smart contracts, dApps, integrations, and tooling thoroughly before deploying or using them in a live environment; +- Keeping up to date with changes to the Casper protocol, tooling, and security advisories; +- Complying with all applicable local, national, and international laws and regulations. -This Whitepaper includes "forward-looking statements”, which are all statements other than statements of historical facts included in this Whitepaper. Words like "believe”, "anticipate”, "expect”, "project”, "estimate”, "predict”, "intend”, "target”, "assume”, "may”, "might”, "could”, "should”, "will” and similar expressions are intended to identify such forward-looking statements. Such forward-looking statements involve known and unknown risks, uncertainties and other factors, which may cause the actual functionality, performance or features of the Casper blockchain and/or CSPR to be materially different from any future functionality, performance or features expressed or implied by such forward-looking statements. Such forward-looking statements are based on numerous assumptions regarding the CasperLabs Networks AG’s and/or any of its affiliates’ present and future expectations regarding the development of the Casper blockchain and the associated software. +We strongly recommend conducting your own due diligence and consulting with legal, financial, or technical professionals as appropriate. You are solely responsible for evaluating and using any information, tools, APIs, or code samples described herein. -These forward-looking statements speak only as of the date of this Whitepaper. CasperLabs Networks AG and its affiliates expressly disclaim any obligation or undertaking to release any updates of or revisions to any forward-looking statement contained herein to reflect any change in CasperLabs Networks AG’s and/or any of its affiliates’ expectations with regard thereto or any change in events, conditions or circumstances on which any such statement is based. +**No Advice** -#### Risk Factors {#risk-factors} +Nothing in this documentation constitutes legal, financial, investment, or professional advice of any kind. You should not act or refrain from acting based on information in this documentation without seeking advice from qualified professionals in relevant fields. -Furthermore, by accepting this Whitepaper, the recipient of hereof (the "Recipient”) acknowledges and agrees that it understands the inherent risks associated with blockchain and distributed ledger technology, tokens and cryptocurrencies in general and the CSPR in particular, including, but not limited to, those outlined hereinafter. +This documentation or any other associated content does not constitute any advice to buy or sell Casper tokens. -- **Risks associated with CasperLabs Networks AG’s experience**: the Recipient is aware that CasperLabs Networks AG and its affiliates constitute a start-up group of companies. Inability of such companies to manage their affairs, including any failure to attract and retain appropriate personnel, could affect the completion and functionality of the Casper blockchain. +**Risk** -- **Risks associated with CSPR relative value**: the Recipient understands and accepts that a purchaser of CSPR may experience financial losses relative to other assets, including fiat currency and/or any other cryptocurrency (including any cryptocurrency used to acquire CSPR). Potential purchasers and holders of CSPR are urged to carefully review this Whitepaper and assess and understand the risk factors relating to the CSPR and the Casper blockchain before acquiring CSPR (when and if CSPR become available). +You acknowledge and agree that you fully understand and accept the inherent risks associated with blockchain technology, distributed ledger systems, cryptocurrencies, and specifically the Casper network, its blockchain and its CSPR token. Key Risks Include (but are not limited to): -- **Risks associated with (intellectual) property rights**: the Recipient understands and accepts that, due to a lack of originality of the software and to the immaterial character of the CSPR, there may be no title of ownership in and to the intellectual property rights relating to CSPR. +- **Technical Risks**: The Casper network, blockchain and associated smart contracts remain under development and may contain undiscovered vulnerabilities, bugs, or be subject to unexpected failures or attacks; +- **Security Risks**: Loss of private keys, wallet mismanagement, and potential hacks may result in irreversible loss of CSPR token. +- **Regulatory Risks**: Evolving global regulations could impact the legality, accessibility, or operation of the Casper platform and the issuance or use of CSPR token. +- **Operational Risks**: Casper Association is an early-stage ventures with limited operational history, and their ability to deliver and maintain the Casper blockchain is not guaranteed. +- **Market and Liquidity Risks**: There is no assurance of a stable or liquid market for CSPR token. Value may fluctuate significantly or decline to zero. +- **Consensus and Network Governance Risks**: Validators control the Casper network’s operation and may make decisions that adversely affect the network or token holders, including forks or protocol changes. +- **Intellectual Property Risks**: Due to the open-source and digital nature of the project, no assurances are made regarding exclusivity or enforceable ownership of intellectual property. -- **Risks associated with blockchain**: the Recipient understands and accepts that the smart contract, the underlying software application and software platform (i.e. the Casper blockchain) is still in an early development stage and unproven. The Recipient understands and accepts that there is no warranty that the process for creating the CSPR and/or the Casper blockchain will be uninterrupted or error-free and acknowledges that there is an inherent risk that the software could contain weaknesses, vulnerabilities or bugs causing, inter alia, the complete loss of CSPR. The Recipient understands and accepts that, after launch of the Casper blockchain, the smart contract and/or underlying protocols and/or the Casper blockchain and/or any other software involved may either delay and/or not execute a contribution due to the overall contribution volume, mining attacks and/or similar events. +**Limitation of Liability** -- **Risk of weaknesses in the field of cryptography**: the Recipient understands and accepts that cryptography is a technology that evolves relatively fast over time. At the same time, methods and tools to decrypt, access and/or manipulate data stored on a distributed ledger or blockchain are highly likely to progress in parallel and in addition, new technological developments such as quantum computers may pose as of now unpredictable risks to the CSPR and the Casper blockchain that could increase the risk of theft or loss of CSPR (if and when CSPR are created and/or issued). +The Casper Association, its contributors, affiliates, directors, officers, employees, agents, contributors, operators or licensors shall have no liability for damages of any kind arising out of the use, reference to, or reliance on this documentation or any of the content contained herein, even if advised of the possibility of such damages. -- **Regulatory risks**: the Recipient understands and accepts that it is possible that certain jurisdictions will apply existing regulations on, or introduce new regulations addressing, distributed ledger technology and/or blockchain technology based applications, which may be contrary to the current setup of the smart contract or the CasperLabs Networks AG project and which may, inter alia, result in substantial modifications of the smart contract and/or the CasperLabs Networks AG project, including its termination and the loss of the CSPR, if and when created and/or issued, or entitlements to receive CSPR, for the Recipient. +In no event will the Casper Association, its contributors, affiliates, directors, officers, employees, agents, contributors, operators or licensors be liable to any person or entity for any damages, losses, liabilities, costs or expenses of any kind, whether direct or indirect, consequential, compensatory, incidental, actual, exemplary, punitive or special, for the use of, reference to, or reliance on this documentation or any of the content contained herein, including, without limitation, any loss of business, revenues, profits, data, use, goodwill, damages from security vulnerabilities or smart contract bugs or other intangible losses. -- **Risks associated with abandonment / lack of success**: the Recipient understands and accepts that the creation of the CSPR and the development of the Casper blockchain as well as the CasperLabs Networks AG project may be abandoned for a number of reasons, including lack of interest from the public, lack of funding, lack of prospects (e.g. caused by competing projects) and legal, tax or regulatory considerations. The Recipient therefore understands that there is no assurance that, even if the CSPR/CasperLabs blockchain project is partially or fully developed and launched, the Recipient will receive any benefits through the CSPR held by it (if and when created and/or issued). +This limitation applies whether the alleged liability is based on contract, tort, negligence, strict liability, or any other basis, even if advised of the possibility of such damages. -- **Risks associated with a loss of private key**: the Recipient understands and accepts that CSPR, if and when created and/or issued, will only be accessed by using a wallet technically compatible with CSPR and with a combination of the Recipient’s account information (address) and private key, seed or password. The Recipient understands and accepts that if its private key or password gets lost or stolen, the CSPR associated with the Recipient’s account (address) will be unrecoverable and will be permanently lost. +**Forward Looking Statements** -- **Risks associated with wallets**: the Recipient understands and accepts that CasperLabs Networks AG or any of its affiliates, employees, partners or advisors are in no way responsible for the wallet to which any CSPR are transferred. The Recipient understands and agrees that it is solely responsible for the access and security of its wallet, for any security breach of its wallet and/or with any loss of CSPR resulting from its wallet service provider, including any termination of the service by the wallet provider and/or bankruptcy of the wallet provider. +This documentation may contain forward-looking statements that reflect the Casper Association’s current views with respect to future events or performance. These statements are inherently subject to risks, uncertainties, and assumptions, many of which are beyond the Casper Association's control. Actual results may differ materially from those expressed or implied in any forward-looking statements. The Company undertakes no obligation to update or revise any forward-looking statements to reflect future events or circumstances. -- **Risks associated with theft/hacks**: the Recipient understands and accepts that the smart contract, the website, the underlying software application and software platform (i.e. the Casper blockchain), during its development and after its launch, may be exposed to attacks by hackers or other individuals that could result in an inability to launch the Casper blockchain or the theft or loss of CSPR. Any such event could also result in the loss of financial and other support of the CasperLabs Networks AG project impacting the ability to develop the CasperLabs Networks AG project and Casper blockchain. +**Third-Party Content** -- **Risks associated with mining attacks**: the Recipient understands and accepts that, as with other cryptocurrencies and tokens, if and when launched, the Casper blockchain is susceptible to attacks relating to validators. Any successful attack presents a risk to the smart contract, expected proper execution and sequencing of transactions, and expected proper execution and sequencing of contract computations. +This documentation may reference or link to third-party libraries, platforms, or resources. We are not responsible for and do not endorse the accuracy, security, or legality of such external resources. Your use of third-party content is at your own risk and subject to those parties' own terms and policies. -- **Risks associated with a lack of consensus**: the Recipient understands and accepts that the network of validators will be ultimately in control of the genesis block and future blocks and that there is no warranty or assurance that the network of validators will perform their functions and reach proper consensus and allocate the CSPR to the Recipient as proposed by any terms. The Recipient further understands that a majority of the validators could agree at any point to make changes to the software and/or smart contracts and to run the new version of the software and/or smart contracts. Such a scenario could lead to the CSPR losing intrinsic value. +**Changes and Updates** -- **Risks associated with liquidity of CSPR**: the Recipient understands and accepts that with regard to the CSPR, if and when created and/or issued, no market liquidity may be guaranteed and that the value of CSPR relative to other assets, including fiat currency and/or any other cryptocurrency (including any cryptocurrency used to acquire CSPR) over time may experience extreme volatility or depreciate in full (including to zero) resulting in loss that will be borne exclusively by the Recipient. +We may update, modify, or remove content from this documentation at any time without notice. It is your responsibility to regularly review this disclaimer and the documentation for changes. -- **Risks associated with forking**: the Recipient understands and accepts that hard and soft forks as well as similar events may, inter alia, lead to the creation of new or competing tokens to the CSPR, adversely affect the functionality, convertibility or transferability or result in a full or partial loss of units or reduction (including reduction to zero) of value of the Recipient’s CSPR (if and when created and/or issued). +**Governing Law and Jurisdiction** + +This disclaimer shall be governed by and construed in accordance with the laws of Switzerland, without regard to its conflict of law principles. Any disputes arising from or related to the use of this documentation shall be subject to the exclusive jurisdiction of the competent courts of Zug, Switzerland. diff --git a/versioned_docs/version-2.0.0/operators/setup/install-node.md b/versioned_docs/version-2.0.0/operators/setup/install-node.md index 975018905..5e7337588 100644 --- a/versioned_docs/version-2.0.0/operators/setup/install-node.md +++ b/versioned_docs/version-2.0.0/operators/setup/install-node.md @@ -11,7 +11,7 @@ Ensure the requirements listed in the following sections are met before you star The following ports are used by the node: - 35000 (required to be externally visible) -- 7777 RPC endpoint for interaction with JSON-RPC API +- 7777 RPC endpoint for interaction with JSON-RPC API. (The default port for JSON-RPC server, is now served by Casper Sidecar from Casper 2.0 onwards) - 8888 REST endpoint for status and metrics (having this accessible allows your node to be part of network status) - 9999 SSE endpoint for event stream @@ -125,9 +125,9 @@ In the past, we have used a lower `trusted_hash`. Connecting at the tip, we now ### Node Address -NODE_ADDR can be set to an IP of a trusted node, or to Casper Labs' public nodes +NODE_ADDR can be set to an IP of a trusted node, or to Casper Association public nodes -You can find active peers at https://cspr.live/tools/peers or use the following Casper Labs public nodes: +You can find active peers at https://cspr.live/tools/peers or use the following Casper Association's public nodes: * Testnet - NODE_ADDR=https://node.testnet.casper.network From d123273603660d09bd9cb6ca115e472168ecfb45 Mon Sep 17 00:00:00 2001 From: Devendran Date: Tue, 24 Jun 2025 15:24:04 +0530 Subject: [PATCH 2/3] Fix rpc schema and account info --- condor/jsonrpc-comp/rpc-2.0/schema.json.md | 4 ++-- docs/concepts/serialization/structures.md | 4 +--- .../version-2.0.0/concepts/serialization/structures.md | 4 +--- 3 files changed, 4 insertions(+), 8 deletions(-) diff --git a/condor/jsonrpc-comp/rpc-2.0/schema.json.md b/condor/jsonrpc-comp/rpc-2.0/schema.json.md index e70c78ce5..53528f4c1 100644 --- a/condor/jsonrpc-comp/rpc-2.0/schema.json.md +++ b/condor/jsonrpc-comp/rpc-2.0/schema.json.md @@ -6,8 +6,8 @@ "title": "Client API of Casper Node", "description": "This describes the JSON-RPC 2.0 API of a node on the Casper network.", "contact": { - "name": "Casper Labs", - "url": "https://casperlabs.io" + "name": "Casper Association", + "url": "https://docs.casper.network" }, "license": { "name": "APACHE LICENSE, VERSION 2.0", diff --git a/docs/concepts/serialization/structures.md b/docs/concepts/serialization/structures.md index fa918a5a3..1eef87d56 100644 --- a/docs/concepts/serialization/structures.md +++ b/docs/concepts/serialization/structures.md @@ -2,9 +2,7 @@ ## Account {#serialization-standard-account} -An Account is a structure that represented a user on a legacy Casper network. Alongside the Casper 2.0 protocol release, `Accounts` were replaced with `AddressableEntities` of the type `Account`. - -**Important:** Addressable Entity is turned off in Casper 2.0 and will be enabled in a future release. +An Account is a structure that represented a user on Casper network. The account structure consists of the following fields: diff --git a/versioned_docs/version-2.0.0/concepts/serialization/structures.md b/versioned_docs/version-2.0.0/concepts/serialization/structures.md index fa918a5a3..1eef87d56 100644 --- a/versioned_docs/version-2.0.0/concepts/serialization/structures.md +++ b/versioned_docs/version-2.0.0/concepts/serialization/structures.md @@ -2,9 +2,7 @@ ## Account {#serialization-standard-account} -An Account is a structure that represented a user on a legacy Casper network. Alongside the Casper 2.0 protocol release, `Accounts` were replaced with `AddressableEntities` of the type `Account`. - -**Important:** Addressable Entity is turned off in Casper 2.0 and will be enabled in a future release. +An Account is a structure that represented a user on Casper network. The account structure consists of the following fields: From 30d3887215714a13f163af5353d5f04a7e05082e Mon Sep 17 00:00:00 2001 From: Devendran Date: Wed, 2 Jul 2025 18:08:28 +0530 Subject: [PATCH 3/3] Fix typo in serialization types --- docs/concepts/serialization/types.md | 2 +- versioned_docs/version-2.0.0/concepts/serialization/types.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/concepts/serialization/types.md b/docs/concepts/serialization/types.md index 4ee39a309..138f68ebc 100644 --- a/docs/concepts/serialization/types.md +++ b/docs/concepts/serialization/types.md @@ -214,7 +214,7 @@ Hex-encoded bytes serialized as a `u32` value describing the length of the bytes ## ByteCodeKind -The type of byte code, serialized as a single `u8` value. A `0` indicates empty byte code. `1` indicates a `V1CasperWasm` to be executed with the first version of the Casper execution engine. `2` indicates a `V2CasperWasm` to be executed with the first version of the Casper execution engine. +The type of byte code, serialized as a single `u8` value. A `0` indicates empty byte code. `1` indicates a `V1CasperWasm` to be executed with the first version of the Casper execution engine. `2` indicates a `V2CasperWasm` to be executed with the second version of the Casper execution engine. ## Caller {#caller} diff --git a/versioned_docs/version-2.0.0/concepts/serialization/types.md b/versioned_docs/version-2.0.0/concepts/serialization/types.md index cf97f0b7f..f038c7242 100644 --- a/versioned_docs/version-2.0.0/concepts/serialization/types.md +++ b/versioned_docs/version-2.0.0/concepts/serialization/types.md @@ -214,7 +214,7 @@ Hex-encoded bytes serialized as a `u32` value describing the length of the bytes ## ByteCodeKind -The type of byte code, serialized as a single `u8` value. A `0` indicates empty byte code. `1` indicates a `V1CasperWasm` to be executed with the first version of the Casper execution engine. `2` indicates a `V2CasperWasm` to be executed with the first version of the Casper execution engine. +The type of byte code, serialized as a single `u8` value. A `0` indicates empty byte code. `1` indicates a `V1CasperWasm` to be executed with the first version of the Casper execution engine. `2` indicates a `V2CasperWasm` to be executed with the second version of the Casper execution engine. ## Caller {#caller}