import useBaseUrl from '@docusaurus/useBaseUrl';
Accounts and Cryptographic Keys
The Casper blockchain uses an on-chain account-based model, uniquely identified by an AccountHash derived from a specific PublicKey. The AccountHash is a 32-byte hash derived from any of the supported PublicKey variants below to standardize keys that can vary in length.
By default, a transactional interaction with the blockchain takes the form of a Deploy cryptographically signed by the key-pair corresponding to the PublicKey used to create the account.
This is an Alpha version of the Casper Docs Redux.
Any suggestions please email to devrel@casper.network, or
- submit an issue on Github
Understanding Call Stacks
Users wishing to interact with a Casper network must do so through sending a Deploy. All Deploys consist of session code run in the context of the user account that sent the Deploy. The session code may install contract code to global state, or interact with previously installed contract code.
When the session code within a Deploy interacts with one or more contracts, this is the beginning of a Call Stack. A call stack is the chronological order in which contracts call other contracts, initiated by an instance of session code.
The Caller
diff --git a/1.5.X/concepts/design/casper-design/index.html b/1.5.X/concepts/design/casper-design/index.html index bd63f4ab..a93daafd 100644 --- a/1.5.X/concepts/design/casper-design/index.html +++ b/1.5.X/concepts/design/casper-design/index.html @@ -10,12 +10,12 @@ - +This is an Alpha version of the Casper Docs Redux.
Any suggestions please email to devrel@casper.network, or
- submit an issue on Github
import useBaseUrl from '@docusaurus/useBaseUrl';
Casper Network Design
Introduction
Casper is a Proof-of-Stake blockchain platform with an account-based model that performs execution after consensus. A Casper network stores data in a structure known as Global State. Users interact with global state through session code sent in a Deploy. Deploys contain Wasm to be executed by the network, thus allowing developers to use their preferred programming language rather than a proprietary language.
diff --git a/1.5.X/concepts/design/highway/index.html b/1.5.X/concepts/design/highway/index.html index c4d422c5..fdff891c 100644 --- a/1.5.X/concepts/design/highway/index.html +++ b/1.5.X/concepts/design/highway/index.html @@ -10,12 +10,12 @@ - +This is an Alpha version of the Casper Docs Redux.
Any suggestions please email to devrel@casper.network, or
- submit an issue on Github
The Highway Consensus Protocol
What is Consensus?
Consensus is the backbone of any distributed network. The decentralized nature of a blockchain requires a method through which disparate entities can agree on one immutable truth. This involves determining the validity of transactions, resolving conflicts, and finalizing blocks to be added to the chain by the network. A consensus protocol is a set of mechanisms and rules within the distributed network with which all actors must comply.
These rules outline the type of messages sent over the network, when they are sent and how to process them. Within the context of a blockchain, the consensus protocol decides which blocks are added to the chain by the network and the order in which they are added. This determines the state of the distributed ledger and ensures that all nodes agree on that state.
diff --git a/1.5.X/concepts/design/networking-protocol/index.html b/1.5.X/concepts/design/networking-protocol/index.html index 6952cd69..d4fb8c2e 100644 --- a/1.5.X/concepts/design/networking-protocol/index.html +++ b/1.5.X/concepts/design/networking-protocol/index.html @@ -10,12 +10,12 @@ - +This is an Alpha version of the Casper Docs Redux.
Any suggestions please email to devrel@casper.network, or
- submit an issue on Github
Casper Node Networking Protocol
Casper Node Networking Protocol (Mainnet Protocol Version 1.5.0)
This is a description of the casper-node's networking protocol. This document follows the conventions laid out in RFC2119.
Connection Level
diff --git a/1.5.X/concepts/design/p2p/index.html b/1.5.X/concepts/design/p2p/index.html index 49a35db8..5a6f24fc 100644 --- a/1.5.X/concepts/design/p2p/index.html +++ b/1.5.X/concepts/design/p2p/index.html @@ -10,12 +10,12 @@ - +This is an Alpha version of the Casper Docs Redux.
Any suggestions please email to devrel@casper.network, or
- submit an issue on Github
Network Communication
Identity
Each node has an identity on the network (which is not the same as its identity in the consensus process). The network identity (ID) is based on the fingerprint of the public key of a TLS certificate. A node generates a new private key each time it starts, ensuring a unique ID.
Each identity is linked with an address, which is an IP and port pair where the node is reachable. This address is also called an endpoint.
diff --git a/1.5.X/concepts/design/reading-and-writing-to-the-blockchain/index.html b/1.5.X/concepts/design/reading-and-writing-to-the-blockchain/index.html index ccb53458..38f8afd5 100644 --- a/1.5.X/concepts/design/reading-and-writing-to-the-blockchain/index.html +++ b/1.5.X/concepts/design/reading-and-writing-to-the-blockchain/index.html @@ -10,12 +10,12 @@ - +This is an Alpha version of the Casper Docs Redux.
Any suggestions please email to devrel@casper.network, or
- submit an issue on Github
Reading and Writing Data to Global State
Casper features several means of reading and writing data to global state, depending on user needs and complexity. Reading data from global state can be done by dApps off-chain or by smart contracts on-chain. Writing data requires on-chain interactions due to the nature of the system. Storage in global state can be accomplished using Dictionaries or NamedKeys.
note
Due to the nature of Casper's serialization standard, NamedKeys should be used sparingly and only for small data sets. Developers should use dictionaries for larger mapped structures.
Using the Casper JSON-RPC
diff --git a/1.5.X/concepts/dictionaries/index.html b/1.5.X/concepts/dictionaries/index.html index 20ee3c2d..b63b2a8a 100644 --- a/1.5.X/concepts/dictionaries/index.html +++ b/1.5.X/concepts/dictionaries/index.html @@ -10,12 +10,12 @@ - +This is an Alpha version of the Casper Docs Redux.
Any suggestions please email to devrel@casper.network, or
- submit an issue on Github
Understanding Dictionaries
In a Casper network, you can now store sets of data under Keys. Previously, URefs were the exclusive means by which users could store data in global state. To maintain persistent access to these URefs, they would have to be stored within an Account or Contract context. In the case of Contracts, sustained and continuous use of URefs would result in the expansion of the associated NamedKeys structures.
Individual value changes to data stored within the NamedKeys would require deserializing the entire NamedKeys data structure, increasing gas costs over time and thus having a negative impact. Additionally, users storing large subsets of mapped data structures would face the same deep copy problem where minor or single updates required the complete deserialization of the map structure, also leading to increased gas costs.
As a solution to this problem, the Casper platform provides the Dictionary feature, which allows users a more efficient and scalable means to aggregate data over time.
This is an Alpha version of the Casper Docs Redux.
Any suggestions please email to devrel@casper.network, or
- submit an issue on Github
Staking Concepts
The Casper network is a Proof-of-Stake blockchain that allows validators to stake the Casper native token CSPR on the network. Validators receive CSPR as an incentive for continuing to maintain and secure the network. CSPR rewards are distributed as blocks are validated into existence and organized into eras.
Consensus mechanism: Casper operates using a Proof-of-Stake consensus mechanism per the Highway Protocol, a specification of Correct-by-Construction Casper (CBC Casper).
Number of validators: The Casper Mainnet supports up to 100 validators on the network. This number is chosen to strike a balance between performance and decentralization. This platform parameter can be increased through upgrades as development continues and performance improves. In addition, validators can stake on the Casper Mainnet through a process of permission-less bonding by participating in an auction for the validator slot.
diff --git a/1.5.X/concepts/economics/consensus/index.html b/1.5.X/concepts/economics/consensus/index.html index c8e16792..d8dea804 100644 --- a/1.5.X/concepts/economics/consensus/index.html +++ b/1.5.X/concepts/economics/consensus/index.html @@ -10,12 +10,12 @@ - +This is an Alpha version of the Casper Docs Redux.
Any suggestions please email to devrel@casper.network, or
- submit an issue on Github
Consensus Economics
Highway consensus is a continuous, trust-less process where a fixed set of validators engage in scheduled communication to advance the linear chain of finalized blocks, representing the history of changes to the global state of the blockchain. The fixed set of validators may change at each era boundary. The economics of this layer revolve around validator selection and incentivization of participation according to the schedule.
Entry
After genesis, the system selects a set of validators using a stake auction process. The auction takes place in the last block of an era, also called a switch block. An auction contract governs the validator selection process, and a chainspec configuration file specifies a few key parameters:
diff --git a/1.5.X/concepts/economics/delegation/index.html b/1.5.X/concepts/economics/delegation/index.html index 9a335ec9..cbb05ee6 100644 --- a/1.5.X/concepts/economics/delegation/index.html +++ b/1.5.X/concepts/economics/delegation/index.html @@ -10,12 +10,12 @@ - +This is an Alpha version of the Casper Docs Redux.
Any suggestions please email to devrel@casper.network, or
- submit an issue on Github
Delegation Details
This section provides a detailed explanation of the delegation cost mechanism, how the gas cost relates with delegations, where to find the details etc. Please note that the cost amounts are likely to change with time and you may have to check the latest release details to get the most up-to-date and accurate details.
Delegation Cost
The delegation cost is defined in the chainspec.toml file for each Casper network. In this example chainspec, the delegation is set to cost 2.5 CSPR. However, when you perform the delegation, you see that it costs a little more than what is specified in the chainspec. Let’s discuss why this happens.
This is an Alpha version of the Casper Docs Redux.
Any suggestions please email to devrel@casper.network, or
- submit an issue on Github
Gas and Resources
What is gas?
Gas is a conceptual measure of resources utilized when executing transactions on the blockchain. Gas cost is the amount of gas consumed during the processing cycles that execute a transaction on the network. It is directly correlated with the amount of computer processing a validator needs to provide in order to execute a transaction.
Gas fees are consumed on the network irrespective of whether your transaction was successful or not. Even when a transaction fails, you have to pay the transaction fee because your deploy consumed resources and space on the block as the validator attempted to execute it on your behalf.
diff --git a/1.5.X/concepts/global-state/index.html b/1.5.X/concepts/global-state/index.html index 652d4010..7142b079 100644 --- a/1.5.X/concepts/global-state/index.html +++ b/1.5.X/concepts/global-state/index.html @@ -10,12 +10,12 @@ - +This is an Alpha version of the Casper Docs Redux.
Any suggestions please email to devrel@casper.network, or
- submit an issue on Github
Global State
Introduction
The storage layer for the Casper blockchain is called global state and has the semantics of a key-value store with additional permissions logic. All accounts, contracts, and any associated data they have are stored in global state. Not all users can access all data, so permissions need to be set accordingly.
note
Refer to Keys and Permissions for further information on keys.
This is an Alpha version of the Casper Docs Redux.
Any suggestions please email to devrel@casper.network, or
- submit an issue on Github